I got a question from a reader and Theory of Constraints fan:
“One of the topics that I'm struggling with is the relationship between Kaizen and TOC. When Norman Bodek talks about the savings people have gotten through Kaizen, does he actually get measurable increase in throughput?
I'm tempted to implement his ideas, but wonder if they are going to make an impact if they are not addressing the current constraint in the system.”
I won't try to answer on Norman's behalf, but these are my thoughts.
I'm sure there have been situations where his “quick and easy kaizen” method have been used to tackle throughput problems.
One thing I always focus on, with Lean, is solving the right problem, not just implementing Lean tools. For example, I'm working with a hospital's radiology department, where MRI throughput and capacity is the most pressing issue. So, almost everything we're working on is in the name of breaking that constraint. We're not calling it TOC, but (in my mind) the influence is there.
So, I think the best answer is that you certainly can try using Norman's methods to engage employees in how to improve throughput. I don't see why there would be any conflict. Now, it throughput increases are going to lead to job loss, then that method won't work. Management has to make the usual Lean commitment to not have Lean lead to layoffs (have to try to grow your way out of that problem).
Do you have thoughts on this? Click “comments” to participate.
Subscribe via RSS | Lean Blog Main Page | Podcast | Twitter @MarkGraban
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
I don’t see any conflict either. Whatever the problem is, some portion of it can be solved by engaging people and performing point kaizen. Problems related to improving throughput may require additional strategies, but quick & easy kaizen certainly won’t hurt the situation. Even if the ideas generated don’t directly contribute to increased throughput, they may at least reduce variation, and thus lay the foundation for improved flow.
I don’t see a conflict but I don’t believe TOC dovetails easily. When I think of TOC in terms of lean I think of bottlenecks and my experience with bottlenecks is not great. Nine times out of 10 work flow issues are related to high variability not not a bottleneck. Don’t get me wrong, I always look for them (low hanging fruit) and do a point Kaizen but it’s always in context of the entire problem. Someone could argue that TOC looks for shifting constraints but if everything is a constraint then nothing is a constraint. I think you’re better with maps and measurements.
http://www.waittimes.blogspot.com
When we are looking at a series of process steps and we are considering various improvement ideas, TOC can help us as an overarching ideal. It may make sense to improve something that does not improve the throughput but sets the stage for another improvement that will use the first as a stepping stone. More often though, we will focus on the constrained resource and improve it. We will then look for the new constraint and improve it. Most companies want to reduce their waste and the waste of unused capacity to build products customers want to buy can be reduced by making that capacity accessible through improving throughput of an integrated constrained resource.
Understanding capacity is a shared principle between Lean, TPS, and TOC. TOC calls steps that are “under capacity” as bottlenecks, lean/TPS refers to steps who have been measured to be under capacity as not meeting TAKT time.
I don’t think either is looking for shifting constraints (the Goal specifically mentions shifting constraints as not being bottlenecks).
There is a lot of overlap between Lean and TOC. Both require reductions in WIP. The the language is different, both use the reductions in inventory to identify bottlenecks and fix them. TOC very explicitly points out that reducing costs only gets you so far; improvements in throughput are where the big bottom-line gains are. Lean’s “wastes,” while perhaps easily identified as costs, are also conditions that reduce throughput (e.g. SMED increases throughput). Perhaps the only real difference is that Lean also includes an element of continuous improvement–reducing waste wherever it’s found–while TOC remains a more top-down approach, focused on improvements to the bottom line.
Perhaps this is the source of confusion. Lean thinking can be (perhaps incorrectly) applied without identifying the “rocks” or having any measure of the effectiveness of the improvement; TOC forces practitioners to make improvements based on their impact to throughput and the bottom line.
Flow plays a central role in Lean. In “The Toyota Way” we’re encouraged to first get some basic level of stability in our processes and then right away get into linking processes together to create flow. In my opinion, one of the main reasons for putting “flow” at the front end of the lean transition is because this helps us see the whole value stream and forces us to prioritize and attack the bottlenecks first.
In my opinion, one of the problems companies run into when they get the “process improvement” bug is that if they actually make a meaningful improvement to a process, it is often the wrong process and thus has little impact. I believe linking processes together and focusing on flow helps us make sure we get our priorities straight. Thus, I would say Lean definitely embraces the main value proposition of TOC.
TOC presents logical trees as methods for breakthrough thinking. It is supposed to create big impact and within no time and without investment. It does not sound like Lean with its continuous improvement. They are different toolboxes developed for different environments. However I like to have all their tools in my own toolbox right beside the hammer and six sigma.