Line Balancing Example and Theory of Constraints

Pete’s Note: We’re pleased to have Gary Netherton provide a guest post for us today. In this post, he shares a dialogue between operators around how to balance a line, which inevitably leads to an educational lesson on the Theory of Constraints, and methods for line balancing such as reducing cycle time, doubling, and moving work elements. He shares a line balancing example with application in the theory of constraints.

Enjoy his post and learn more about Gary after the article.

Ever have processes that need fixed but the team seems to have their own ideas about which processes need fixed first?  As a result, you end up fixing problems that seem to create problems elsewhere.  It seems that you end up right where you started.

How did you manage to do that?

It is actually pretty simple.  You don’t choose your best target for improvement.  Or, as Eliyahu Goldratt would say, you don’t identify and attack your constraint.

How do you do that?

Well, that is actually pretty simple, too . . .  if you take the time to do it correctly.  This often means more than walking the floor and looking for a buildup of inventory between operations (though that is a very good start).  One of the best ways to start is by mapping the process.  Some might suggest a value stream map while others may say a process flow diagram will suffice.  Either is a good option, but I recommend choosing the one that works for you.

After you have a picture of what your process looks like, pull out the old stopwatch.  Take about 10 cycle time measurements for each operation that you’ve identified on your flow diagram.  When you are done, average them out and create a Pareto diagram of the operations.

The first, tallest bar on your diagram is your constraint.

Complete a detailed review of that operation.  Look for opportunities to speed it up or pass off some of its activities to another operation (that’s called line balancing . . . an important part of eliminating constraints).  The idea is to either speed up that operation (if possible) or to share part of that operations activities with other operations.  In the end, the goal is for all of the operations to take about the same amount of time (except the last one . . . it should be your fastest).

But what if I can’t speed it up OR share with other operations?

Well, there is one more option, but this is a last resort.  In the event that an all-encompassing operation cannot be split up or sped up like, for example, some kind of functional test you might need to consider doubling that operation.

Doubling?

Yes, doubling the operation is the equivalent of putting a fork in the river.  Operation C can either feed station D-1 or D-2, whichever is free.  By having two D stations, you essentially reduce the overall cycle time of that operation.  Then either of the D stations can feed the next operation.  Granted, this operation may be a bit capital-intensive, but it can pay for itself in increased productivity if done correctly.

Using the Theory of Constraints the equivalent of a chain is as strong as its weakest link the team can attack items in a sensible order.  And once that is complete, the cycle can start all over again (like PDCA).  Restudy, re-graph, and research the weakest link (slowest operation).  Attack that constraint and watch as the team starts to see improvements.

Gary Netherton is a multi-certified quality professional with project management experience in leading quality and manufacturing efforts from product and product launch to problem-solving using Six Sigma, PDCA, and other quality tools. His expertise is advanced product quality planning as well as data collection and analysis. He currently reside and work near the Seattle area of Washington.