TOC Bottleneck versus Lean Pacemaker – Part 2

Last night we discussed the main tenets of TOC. Tonight we will introduce the Lean Pacemaker showing how it may not always be the constraint in our system. This, my friends, is where the TOC and Lean proponents often “bow up” and butt heads a bit.

Lean Pacemaker

In a Lean system we normally want to schedule production at one process. This process, called the pacemaker, is normally towards the end of the line (sometimes final assembly). The basic idea is that we schedule production at this pacemaker allowing it to then “pull” material to it. A key rule for selecting the pacemaker is that all processes after it must “flow” to the customer.

The Debate

The debate over TOC Bottlenecks and Lean Pacemakers is best summarized by John Shook. I have never met John but have read much of his writing and can safely say he has likely forgotten more about Lean than I will ever know.

I came across an article on the LEI website awhile back where John explained some of the key differences between Lean and TOC. You can find the full article here. I will quote a portion of this article below as it summarizes the point I am trying to make perfectly.

Secondly, there is a fundamental difference between TOC “bottlenecks” and TPS “pacemakers,” though they are frequently misunderstood to be roughly analogous. What is analogous is that TPS, like TOC, strives to identify and “break” bottlenecks. But, TPS does not allow a bottleneck to set the pace of the value stream. After all, the bottleneck may exist for any number of problematic reasons – excessive downtime, poor quality, long changeover times, etc. Why would I choose to let an operation with such problems determine the way I flow my entire value stream? Of course, I have to deal with the problem operation (the bottleneck), and there are numerous techniques to do so, but I will not let it dictate the pace (takt) of my entire product flow!

Which Method is Right?

I personally believe in the end TOC and Lean practitioners are actually teaching very similar things. Let me explain.

Both Lean and TOC teach that bottlenecks must be broken. In a Lean system we know that if a process cycle time is greater than takt time we have an issue that must be resolved. This is roughly analogous to the TOC step of “elevate the constraint.”

Also, drum-buffer-rope is very similar to the Lean pull system. Sure there are some differences but the concepts are close.  However, as Mr. Shook explained a Lean system will not allow a bottleneck to automatically be the pacemaker for the reasons he explained.

I must admit, I personally agree with Mr. Shook on this point. It makes little sense to me to allow the chubby kid to set the pace. As Jon Miller commented after last nights post, we should help Herbie lose weight!

And while they may not admit it, I really believe most TOC proponents believe the same thing. They just explain things a bit differently.  I hope this helps explain some of the differences and similarities between TOC and Lean.  Hot sports opinions are of course very welcome by clicking the “comments” link below.


  1. Vivek Chopra

    April 13, 2011 - 1:56 am

    “Why would I choose to let an operation with such problems determine the way I flow my entire value stream? ”
    I agree but disagree :). As you rightly pointed out, TOC also says that the constraint, if it exists within the organization, has to be broken (which will, by the way, expose a different constraint, which again we have to manage…so there is always some constraint). Irrespective of whether we are breaking or not, we are always left with a constraint which limits the through-put of the organization. According to TOC there will be no situation where there will be zero constraint because that would mean that the organization can increase throuput without bounds.
    So we are always left with some constraint whether we like it or not -we can’t really avoid that. We would obviously like to be in a happy position where we can choose our constraint but we may not always have that luxury. One can always choose a pacemaker process as separate from a constraint process and schedule it but one will probably realize over time, that it is still the constraint which is threatening the schedule at the pacemaker and so has to be managed separately.

    • Ron Pereira

      April 13, 2011 - 7:25 am

      Hi Vivek, thanks for the great comment.

      The key, from a lean perspective, is to ensure value flows according to what the customer requests. So while we are always aware of our “constraints” or any process with cycle time greater than takt time, we will NOT allow it to dictate production. Instead, we break the bottleneck by removing waste or adding resources if needed so it operates below takt time.

      But, again, a lean pacemaker is not necessarily the bottleneck…. instead it is the process furthest downstream whereby everything flows smoothly.

      So with Goldratt’s famous Herbie analogy… we lean folk agree to take the junk from his backback and such. But, most likely, this won’t be enough to make his cycle time less than takt time so lean proponents would also help the young lad lose weight – no pun intended!

      • Sam Wilding

        November 15, 2012 - 10:08 am

        Again like Vivek, I slightly disagree with the “Why would I choose to let an operation with such problems determine the way I flow my entire value stream? ” statement. First I would say that you don’t have a choice in the short-term of whether or not an operation determines the flow of the value stream. Until the constraint is broken and moved externally, the flow is determined by the internal contraint (again, this is short term). Secondly, I would argue that at times it may be desirable to have an internal operation determine the pace of the value stream. For example, if a comany does not have the necessary capital to expand the capacity of their bottleneck operation, a good strategy would be to optomize around that constraint until enough capital can be secured. There may be other situations as well. I know that’s not a complete disagreement, but I think it’s an important point to remember.

        In my view, TOC is a perfect way to systematically approach a Lean operation. Let me explain: TOC helps target Lean efforts on operations for which improvement yields the most benefit to the value stream. In the Herbie example, TOC identifies Herbie as the constraint and the applies the simplest fixes to optomize Herbie’s performance. Then Lean comes in to further optimize Herbie (making him thinner or whatever). Keep in mind that making Herbie lose weight takes a signifcant amount of time and effort. Now suppose the Herbie constraint is broken, but another boy is now the constraint. Repeat the same process until the constraint becomes customer demand. When the constraint is customer demand, TOC and Lean overlap almost completely, and the flow of the value stream is no longer determined by an internal operation.