Different Ways to Do Kaizen

Kaizen (改善), or continuous improvement, is a cornerstone of lean manufacturing. If you stop becoming better, you will fall behind. But not all improvement activities are equal. There are different ways to do kaizen projects suitable for different situations. Let me give you an overview:

Just Do It

Kaizen comes in different forms, mostly distinguished by the complexity of the problem they try to solve and subsequently the duration. The easiest way to do kaizen is for small problems. For example, if there is a problem with the arrangement of material at the workplace, then it is often quick and easy to develop or try out a different solution and implement it. For this, you often need only the team leader and the operators. This can, in its easiest form, take mere hours (for example, if the operator suggests a change, the team leader thinks about it and approves it, and they move the boxes around) to weeks (for example, if they need to get some equipment or material).

Such a just-do-it approach can also be started through gemba walks or waste walks. You walk the shop floor on your own or as a small group and look for improvement potentials. The smaller potentials can be kicked off right away, albeit for larger issues you may still need a kaizen blitz or task force.

Kaizen Blitz

The kaizen blitz has a very catchy name, which definitely helped with its popularity in modern industry. It sounds like it is fast, which is always popular with management. But in reality, it is not really a “blitz,” and the speed can be comparable to a well-managed small project.

In any case, the German word blitz means flash, or lightning, but as a German it reminds me uncomfortably of the Blitzkrieg during the horrors of World War II, and I would like my lean implementation to be less martial… In any case, depending on the set-up, a kaizen blitz can take from two weeks to five months.  The actual “blitz” itself is only two days to two weeks, but there may be plenty of preparation beforehand and implementation afterwards. To me, it is just a fancy name for a workshop with some preparation and follow-up.

You start with a few weeks preparing the workshop. This preparation can take two weeks to two months, but the preparation does not involve the entire team, and is also not a full-time activity. Rather, you define the problem, set up a team, and gather the needed data for the workshop.

The actual workshop, however, is a full-time activity for the project team, taking between two days and two weeks depending on the complexity of the problem. During the workshop you present the problem, analyze the root cause, develop (ideally multiple) solutions, pick the best of them, and plan (or sometimes even do) the implementation. Especially for shorter workshops, an A3 may be sufficient for documentation.

After the workshop follows the implementation. This is also not a full-time activity, as there may be quite a few periods waiting for material/machines/programs and other stuff, but it can take months. Please do not forget the Check and Act of the PDCA.

Different from the just-do-it approach, a kaizen blitz needs some more management overhead. People have to be made available for the time needed. Expenses have to be approved. A meeting room has to be reserved for the workshop. Buy-in of and support from other departments may have to be arranged, etc.

The advantage of a kaizen blitz is the focus on a singular topic for the duration of a workshop. This *can* make the progress faster, but there is no guarantee of that. On the other hand, it is quite possible that some steps in solving the problem may cause a delay, which would clash with the single workshop approach. For example, if you want to run a production trial with a new setup of some sorts, or if you need to run some computer simulations, it may take one or more days to get the results form the trial. Hence, this would be impractical to do during the workshop. For such issues, a task force would be better.

Task Force

A task force or a project team is somewhat similar to a kaizen blitz, but it does not have the rigid structure of a single workshop of multiple days. It could be the same, but it could also be a short series of workshops with some days in-between to prepare more data. For me, all kaizen blitzes are task forces, but not all task forces are kaizen blitzes. Personally, I prefer the task force, as the necessity to limit yourself to a single workshop is a constraint that is not worth the possible benefit of a faster workshop. Make the solution fit the problem, not the other way round.

Long-Term Projects

A long-term project is used for bigger challenges. If you set up a new larger assembly line, build a new plant, or develop a new product, you are probably busy for months or years. Similar to a Kaizen blitz or a task force, you need to define the problem, set up a core team, and prepare the data. Different from a kaizen blitz, however, some members of the core team may be fully assigned to the project, and the teams are probably bigger, including temporary members. There may even be a full-time project manager whose major part of his work is the coordination of the different team members and other contributors. There will also be probably multiple shorter and longer workshops. They may also have one permanently assigned meeting room, often called a war room or in Japanese an Obeya. Documentation of the project will be more extensive, and an A3 may no longer suffice.

Projects with Suppliers

Projects with suppliers or other companies can be of short, medium, or long duration. Different from all the other projects, however, is the need to go though the hierarchy. Some people, probably quite high up in the hierarchy, need to support this to make multiple companies move in the same direction. Another difference is the willingness to share data. Depending on how much you trust your supplier, you may not want to give him critical data. If you work with your competitors, there may be even more hesitation. But apart from that, you still have a project team that meets regularly to drive the project forward.

Overall, there are many ways to do continuous improvement depending on the size of the problem and other circumstances. Make sure to always do PDCA to check if the solution actually made it better and not worse. Now, go out, improve your system, and organize your industry!

PS: I was inspired to write this blog post by the excellent book by Michel Baudin and Torbjörn Netland. The entire book is recommended reading 🙂: Baudin, Michel, and Torbjørn Netland. 2022. Introduction to Manufacturing: An Industrial Engineering and Management Perspective. 1st edition. New York, NY: Routledge.