In lean manufacturing – or in fact, in any kind of production system – you have to solve problems. Depending on the problem, you may need a creative solution and have to access the wisdom of the crowd. For this I have a workshop structure that I frequently use for problems that have lots of different options. Let me show you my workshop structure with which I’ve had quite good results.
Problem Solving
How to Do Brainstorming
A lot of lean is about problem solving, and most of these problems are complex and difficult. Otherwise, someone would have solved them already. Hence, I would like to introduce you to different creativity techniques for problem solving. Most of them can be used in groups to access the collective wisdom and creativity. Most of them are also suitable to develop a number of alternative solutions, of which you can pick the best ones (see my previous post on Japanese Multidimensional Problem Solving). Many of them can be combined in sequence. Let me start with the most common one, brainstorming:
The Many Flavors of the PDCA
In my last posts I explained the PDCA (Plan, Do, Check, Act), common mistakes, and its history. However, there is a whole fruit stand of additional versions with some modifications that have popped up: PDSA, SDCA, OODA, ODCA, DMAIC, LAMDA, FACTUAL, Kata, and 8D – and probably more that I do not know of. Let me explain a bit on the different offshoots and alternatives of the PDCA.
Common Mistakes with the PDCA (and Some History)
In my previous post I explained how the PDCA (Plan, Do, Check, Act) should work. However, while most people know the PDCA in theory, I find that the practical implementation is often lacking. And, quite frankly, I am also sometimes sloppy with the PDCA way more often than I would like to admit. Time for some reflection and observation on what works, and why so often it does not.
Hence, in this post I will show common pitfalls and problems when doing a PDCA. Also, simply because it is one of my pet interests, I will also show a bit of the history of the PDCA and its origins in quality control.
The Key to Lean – Plan, Do, Check, Act!
Plan-Do-Check-Act (or PDCA) is one of the key elements in lean manufacturing, or for that matter in any kind of improvement process. In my view, it is the most basic framework for any kind of change. All other lean tools are only on top of the PDCA.
In my experience, most lean projects in the Western world fail not because they do not have some detailed tool, but because the PDCA is neglected. Of course, (almost) everybody knows what the PDCA is, but there is a huge difference between knowing the theory and doing it correctly. In this post I will explain in more detail how PDCA should work. In my next posts I will show you the common pitfalls of PDCA, its history, and the many, many different variants of the PDCA that are out there.
The A3 Report – Part 3: Limitations and Common Mistakes
In the last two posts I showed you the basics of the A3 report and the (possible) content of the A3 report. In this last post of this series, I would like to talk about common mistakes and the limitations of the A3 report. Overall, for me the A3 report is a minor tool to help organize the real work of problem solving, despite all the fuzz some make about the A3 report.
The A3 Report – Part 2: Content
In my last post I wrote about four basic factors for an A3 report (one sheet / A3 size / with pencil / on the shop floor). This week I would like to show you what goes in an A3 report. The important framework here is PDCA (Plan, Do, Check, Act). However, in my view there is no single perfect A3 template that will fit all of your problems. Rather, an A3 is created on the go. Make the tool fit the problem, not the other way round!
The A3 Report – Part 1: Basics
If you know your way around lean, you surely have hear about the A3 report, famously named after the DIN-A3 paper size. It is also known as the A3 problem-solving sheet. The goal is to get all the necessary data on one sheet of A3 paper using pencil while you are on the shop floor. The A3 report is commonly used for problem solving, but also for project management or status reports.