How would Taiichi Ohno feel about this?

I think Ohno would ask, "Does your output now match your customers requirements?" From a personnel response your example of 30 outside people is not typical of a TPS kaizen event. And so, from this atypical example a good point could be made by anyone... Goldratt could have chosen a more honest comparison. His point of focusing on bottleneck "Herbies" vs TPS Lean focusing on the value stream could have been made with a more honorable example.

As for comparing the two projects: What were the two projects?

The TPS project could be where they are trying to take out another person by improving the processes within a multi operation cell after a succession of previously successful improvement events. As compared to the TOC project where the team was looking at a high scrap, high labor, high overtime, high backlog, very problematic area with much more opportunity for improvement than the TPS project.

Or, in other words the TOC project had a lot of "low hanging fruit" as compared with the TPS project reaching high for their improvement. Maybe the TPS project was breaking paradigms while the TOC project was solving problems.

In conclusion, to imply that Toyota is not concerned with bottlenecks is false. They are, they just call it takt time. I for one like what both the TOC and the TPS systems have to offer and will use both ways of thinking to promote improvements.

Sincerely,

Bob Schroer
Wizard of WOW
Hi-Stat Manufacturing

Dear Critical Path:

You had an interesting luncheon. The question you posed was a good one except you were outgunned. Goldratt has built a very good reputation and has developed a world wide consultant practice based on TOC. I have found when I talk to an "expert" that I have to choose my words very carefully.

The argument of Lean vs. TOC is an exercise. It is like asking a Ph.D. in Statistics what he or she thinks of Six Sigma. The retort will be a diatribe of statistical theory that attacks Six Sigma as a concept that is statistically incorrect. Six Sigma has some flaws and it is not founded perfectly in robust statistics. The bigger issue is the drive for 3.4 defects per million. Industry is not looking for statistical robustness they are looking for concepts that will radically reduce defects. Six Sigma provides some different insight into quality and improvement.

Another pitched battle that I have had to arbitrate many times is the fight between the believers in Enterprise Resource Planning (the next step beyond MRP II) and Just in Time (Kanban, etc). Each believer is dogmatic in his or her beliefs. In fact there is a place for both.

There are situations where ERP is required as the engine that runs the business. Within the business structure there is a place where ERP stops and JIT takes over. The key point is that both concepts work and in many cases they support each other. The zealot has a blind side, if it is not a total ERP based initiative or JIT based initiative then the institution is going in the wrong direction. The same statement applies to Lean, TOC, and all the other concepts being put forth as the ultimate solution.

TOC works, so does Lean. In fact Re-engineering, Quality Functional Deployment, Design of Experiments, etc. all work. Each are a road map for achieving the goals of reducing cycle time, increasing throughput, improving quality, improving safety, and finally reducing cost. The result on a global basis is increased customer, shareholder, employee and in some cases community satisfaction.

Goldratt is a little unfair when he states that the principal applications are car companies. Companies like UTC, GE, and Boeing have used Lean driven methodology in improving their processes and in turn their metrics. There is a good casebook written by Jeffrey Liker called "Becoming Lean". It tracks many companies in using Lean methodology.

Track through time the 'buzz" words or to be diplomatic, the improvement concepts, and you will find a deluge of techniques. Unfortunately management picks them up as the Holy Grail and forces implementation until another book or theory is published. TOC applications have been successful but there have also been failures. It is not the failure of TOC, it is the failure of the leadership to understand the techniques and tie them to a Vision, Goals, Strategies and a fully developed implementation plan.

If I laid out all the concepts that are being sold and advocated they all have the same objectives. Lean is a nice 'buzz" word. Dissect it and it leads you in the same direction as TOC. The paths are slightly different but if you compare the results the metrics are the same. It some cases Lean gets you there faster and in some cases TOC gets you there faster.

The key is: what methods fit the Strategies the institution has selected to achieve their Vision and Goals? The important point is that the leadership has a tough job to determine what is the best technique or techniques that are required to meet the Vision, Goals and Strategies of the enterprise. In some cases "one size does not fit all."

Bruce Gissing

CP: Yes, it truly is a "What is the center of your universe?" problem when talking to these experts. Goldratt's examples seem unfair, yet many readers echoed that his criticism is exactly what happens during many lean production projects, with some adding that TOC is by no means immune to the same misapplication.

Each of the other quality efforts you mention above run the risk of falling into the camp where "a little knowledge is a dangerous thing." Jim Womack is clear when he points out that most people in a Lean implementation rush into kaizen without first mapping the value stream. You are right on the money - Leadership - sometimes in the form of Hoshin Policy Deployment, makes the difference in aligning the organization for Lean, TOC, Six Sigma, whatever is appropriate for the culture. --Gregg

Dear Critical Path:

Using an operations analogy for product development is not a good approach to solving product development problems. A book that was suggested by the Management Roundtable approximately a year ago emphasizes this: "Managing the Design Factory". In fact, I find this book and its philosophy of product development management (by Reinertsen) to be more practical and have a better understanding of the challenges than Goldratt and the "Critical Chain".

Specifically, I disagree with the concept of focusing on the bottleneck areas of the product development process. Unlike an operations environment, where continual improvement may have been around the company for years and the potential and payback for process improvement may be limited, I suggest that the opportunity for improvement in the product development process exists in all areas of the process and is significant for most organizations today. Also, I suggest that, unlike the operations environment where you can compartmentalize the process so that you can focus on some key bottleneck areas, in product development the ability to compartmentalize the process will not result in significant improvement due to a significantly changing environment, and due to the differences of each project and its driving requirements. Please note that I am not suggesting that you don't understand your bottlenecks, but that I am suggesting that you don't look only at your bottlenecks.

Jerry Groen
Abbott Laboratories
Hospital Products Division

CP: I agree with you on your points. Any approach towards achieving a "lean" or shop-floor-resembling throughput in product development will require the "systems approach" which you allude to. With TOC, Goldratt is clear that when focusing on constraints, you don't necessarily begin by exploiting the biggest bottleneck. Since it is a near fundamental TOC law that once a constraint is alleviated, the bottleneck will move around and appear elsewhere, Goldratt suggests you often must fix THAT bottleneck first. In product development, you have to draw back a few more dimensions, peel back a few more layers, and utilize decision making criteria such as the economic analysis which Reinertsen and Preston Smith discuss, and consider things as "interdependencies" with many "downstream effects", and choose your tradeoffs according to what best impacts the bottom line or similar "success metric". -- Gregg

Dear Critical Path:

The Goldratt approach of looking for bottlenecks makes intuitive sense in that most systems are non-linear and dynamic and the challenge is to always find the high leverage points (or Lorenz Attractors in chaos theory) so slight changes in these nodes can have a huge impact on the system such as throughput or inventory reduction. Narrowly focused Lean Thinking Kaizen events can be real time sinks and could certainly sub optimize the total system.

Where to start is always the issue. With implementing that rather large TQM elephant, I have often thrown up my hands and taken the position that where you start doesn't make any difference because it is like a three ring circus -- which door to enter doesn't make any difference because once you get inside the big top, it's the same show. Goldratt's emphasis/focus on bottleneck makes intuitive sense, but I have not yet been able to cite any specific applications.

Bill Slabey
President
Ivon

CP: To Dr. Goldratt's credit, he was very forthright in telling us that TOC is compatible with every other process improvement technique he has seen except for the Balanced Scorecard and Activity Based Costing (which, he is quick to point out, come from the same place). Other than Lean/TPS, he mentioned TQM, JIT, and a few others as harmonious.

TOC is at his heart, naturally, since it is composed of his blood and sweat, so one can't blame him for the zealous way he promotes it, which in my mind is justified by the results it achieves. I would expect similar positioning from Ohno, Womack, Shigeo Shingo, Deming or Juran with their respective schools of thought. I advise anyone interested in this subject to get the latest edition of The Goal, and read the recently added supplement, "My Saga," which goes into further detail on how TOC came to be, and Dr. Goldratt's struggles to spread his message. -- Gregg

Dear Critical Path:

TOC vs Lean is analogous to the argument between Throughput vs ABC costing, Reengineering vs Kaizen. To be successful you must do both. But to sustain TOC or reengineering across business cycles is very difficult.

Both TOC and Reengineering take a very focused view with the objective of achieving huge improvements via a complete change in how the system works as a whole, and truly understanding critical elements. Kaizen focuses on the process of continuous incremental improvement. These initiatives come in conflict when they are competing for resources or when a Kaizen (or ABM) process conflicts with TOC to achieve perceived cost reduction. In the real world systems are rarely so well ordered that a TOC snapshot just falls into place. Reality is wandering bottlenecks, changing market conditions, and a general mess. TOC provides an invaluable umbrella to put some order to the chaos, and focus on what will really benefit the business. Two steps in TOC both benefit and come in conflict with Kaizen. The Subordination step can often take advantage of Kaizen efforts to help non constraint operations avoid becoming temporary bottlenecks.

Incremental improvements may be the cheapest path to protective capacity. The conflict arises when attempts to cash in on local improvement efforts violate the TOC requirement of protective capacity. There are two rules that should help here:

When evaluating the economic value of an incremental improvement, expectations and savings should always reflect the entire system as opposed to the local step.

Any incremental improvement must not compromise protective capacity or the throughput of the system.

When the constraint is elevated it can move or put increased pressure on other operations. Kaizen efforts that may have seemed of little value earlier now are critical to maintaining flow.

In defense of Goldratt, it is very difficult to sustain TOC thinking in an organization. Lean Thinking, Kaizen, ABM, JIT, and a host of other initiatives can destroy the TOC infrastructure. TOC seems to suffer most during economic downturns when cost reduction replaces throughput as the main objective. Business seems to have a long memory when it comes to cost reduction, but a real problem with restarting TOC. The bottom line is that Kaizen or Lean Thinking can be very positive and complementary forces with TOC, but only when the TOC process is the main driver, and is used as a platform to evaluate any actions suggested by the other initiatives. A business that can incorporate both TOC and Lean Thinking, in that order, can conquer the world.

Vail Brown
Reengineering Consultant
Goodyear Tire & Rubber Co.

Dear Critical Path:

In my mind TOC/DBR,KANBAN,MRP have got different degrees of difficulties and operate well in different scenarios. If one shoe size fits all, approach needs to be adopted then TOC/DBR I would think is the only bet. In my opinion KANBAN is the easiest as it is a physical simple system but when it comes to finding out where one should be concentrating for better returns TOC gives a better answer. If the plant design is on KANBAN (for minimum inventory), one needs to have sufficient protective capacity to produce what is needed, when it is needed. If you try implementing KANBAN in an environment where there is lot of variability in the end product, have long set up times etc., you are asking for a life which would be hell. MRP is more of a long term planning tool which can be effectively
used for letting suppliers know of the forecast. It is being used where KANBAN is implemented. MRP in a complex environment, will bring in wrong material at the wrong time. End result invariably being lot of inventory on site. KANBAN restricts production based on remaining buffers of quantities. Material is pushed to fill those buffers. Pulls from customers are normally only from those quantity buffers. These buffers in KANBAN are at fixed points. TOC extends this idea in the complex world by making buffers as time. TOC places buffers at both fixed as well as strategic points to get maximum advantage. Time buffers need extra business processes to measure and monitor so is not as easy as KANBAN cards.

For those who understand LEAN well know that balancing the flow is what is needed and not balancing the capacity. Balancing of Capacity either reduces the capability to produce or results in increase of cycle time in the plant. Those who do not know about this can be constricting a business to oblivion. TOC does not very clearly define everything because of variability in life and leaves quite a few things to judgment, however it provides a process to correct the judgment continuously.  So KANBAN and LEAN are specializations of TOC/DBR. KANBAN and Lean can be construed to be a sub-set of TOC/DBR.  TOC being higher level has some features which can be used either to improve the KANBAN processes, or make sure the site does not become a complex environment where TOC/DBR is mandatory.

Nagendra Arora
ArvinMeritor