There is broad agreement in industry that a pull system is in almost all cases better than a push system. The most famous way to establish a pull system is to use a kanban system. The idea of kanban is so much associated with pull production that the two terms are sometimes even used synonymously. However, there are other ways to implement pull. Another useful approach is CONWIP, standing for Constant Work In Progress and developed by Mark Spearman and Wallace Hopp in 1990. In this small series of posts, I would like to go into the details of CONWIP and its similarities to and differences from kanban. This first post will explain the basics, the next two posts will go into more details by answering some frequently asked questions, and the fourth post will discuss advantages and disadvantages of CONWIP.
In my last post, I started to show the main reasons why EPEI leveling with a fixed repeating schedule so often fails (for details on EPEI leveling, see Theory of Every Part Every Interval (EPEI) Leveling). This post continues with more reasons and also gives some advice on how to reduce the damage or even increase its chances of success. It also has a suggestion for a test to determine if your system is ready for leveling.
Again, there seems to be a lean religion that claims that putting up a leveling box will lead to salvation. Well, Lean is not a religion or magic. Lean is hard work, and you actually need to understand what you are doing. Just copying something without understanding is a good way to fail, especially with leveling.
In my last post I presented the EPEI leveling pattern (also known as EPEC, EPEx, Heijunka, fixed repeating pattern, or simply leveling). While in theory this approach looks pretty solid, in my experience it rarely works in practice. In fact, most of these types of leveling that I have seen were complete rubbish. They were a dog-and-pony-show to please management at the expense of performance and shop floor efficiency.
Furthermore, lean manufacturing seems often to be confused with a religion. People believe that if you put up a leveling box your manufacturing system will have salvation. Well, Lean is not a religion. Lean is hard work, and you actually need to understand what you are doing. Just copying something without understanding is a good way to fail, especially with leveling.
The theory about this type of leveling is not very difficult. Unfortunately, hard facts of reality often nullify any possible advantage of this type of leveling. In fact, most of these types of leveling that I have seen were complete rubbish. They were a dog-and-pony-show to please management at the expense of performance and shop floor efficiency. In this post I will explain to you how it is supposed to work in theory. In the next post I will explain why it rarely works in practice .
One approach to leveling (also known as heijunka [平準化], or production smoothing) is capacity leveling: Do not add more production orders into the system than what the system can handle. Try to produce the same total quantity every day. Doable for almost everybody, and one of my favorites. In fact, if you are using a pull system like kanban or CONWIP, then you are already almost there.
This approach is not the highest and best form of leveling, but it is doable for almost all firms. Some other approaches, notably an Every Product Every Cycle (EPEC) approach, often do more harm than good.
Eliyahu Goldratt developed different methods on how to manage production systems. These methods are nowadays known as the Theory of Constraints, or TOC for short. One key method described is called Drum-Buffer-Rope, or DBM for short. Similar to Kanban or CONWIP, it aims to constrain the work in progress (WIP) in the system. There is much discussion on which method is better than the other, although the result often depends heavily on with which method the respective author earns its living. In this post I will present how Drum-Buffer-Rope works, and discuss its advantages and shortcomings.
In my previous two posts, I described how to calculate the number of kanbans (Post 1 and Post 2). However, this calculation is complex, and the result is nothing more than a very rough estimate. Hence my preferred method for determining the number of kanbans is, broadly speaking, “just take enough, and then see if you can reduce them.” In this post, I would like to explain this approach and also discuss how and when to update the number of kanbans.
This is the second post on kanban calculation (if possible, please read the first post on kanban calculation first). There are two possible approaches. First, you can calculate the number of kanbans using a kanban formula (due to its length, split into a first post and this second post). Alternatively, you can estimate the number of kanbans and adjust the system as it is running (as shown in a third post).