Focus and Leverage Part 316

In this posting we will complete our series on excerpts from The Ultimate Improvement Cycle – Maximizing Profits Through the Integration of Lean, Six Sigma and the Theory of Constraints. In previous postings we have learned how this integration came about and how to implement the first three steps.  We've also seen what the recommended "tools" are.  In the final step of the UIC, Control, we now turn our attention on how to control/sustain the gains we have made.

Step 4: Control

In step 4a, you develop a plan for how to elevate the current constraint (if this step is needed) and define appropriate protective controls. The premise here is, if in the previous nine steps, you have not broken the constraint (i.e., increased the capacity of the constraint), you may have to acquire more resources and even spend money to do so. Spending money, in this context, simply means that you have to add additional resources, by adding additional labor, additional time (i.e., overtime or additional shifts), additional equipment, or a combination thereof to break the constraint. Based upon my experience, if you have to elevate the constraint, you are talking only about minimal labor increases without spending money on new equipment, but in reality, sometimes you do have to spend.

 

 

Sometimes, any labor increase can be achieved with overtime or additional shifts. However, in the event that you must spend money, you must do so under control, only after performing a detailed analysis of constraint processing times, and only by adding labor or equipment that is needed for the constraint to satisfy the needs of the market. Because your objective is to break the current constraint, you must be mindful that any labor increase may only be temporary, so having a flexible workforce facilitates this increase.

Also included in this step is an analysis of what type of protective controls you must develop to protect the improvements and not lose the gains you have already made. Many times just a simple audit of the process is enough to ensure that you maintain the gains. Other times, a simple control chart of throughput or processing time is sufficient. One thing you learned from the TOC is that once a constraint has been broken, you must never allow inertia to cause a system constraint. What inertia refers to is that within any organization, in the course of attempting to break the constraint, you sometimes develop specific rules or policies, so you must not fail to review these rules and policies to ensure their applicability is still relevant. If it is not, get rid of them. Without doing this, these rules and policies could actually become future constraints themselves.

In step 4b, if it is needed, you will elevate the constraint, which is simply the execution of part of the plan you developed in step 4a. If you need to add capacity to your constraint, you do so only according to your plan—and no more. It is possible and even more likely that you have already broken your constraint during the first nine steps of this process. If this is the case, you simply move to step 4c. Remember, even if you might have broken the constraint during the first nine steps, you must still review any rules and policies that you might have implemented during this process so as to avoid system inertia. In the final step, step 4c, you will implement protective controls to make certain that you maintain the gains you have made to this point.

Be sure to avoid system inertia; in fact, Dettmer advises you to “remember that the cycle never stops: there’s always another constraint waiting behind the one we’re working on now. Also, in successive cycles of the five focusing steps you might have to revisit a constraint you thought you’d previously broken.”21 Clearly, Dettmer is correct to say that you always have to remember that the cycle never stops, but the real concern here is that you must always keep your eye on the ball for non-constraints becoming constraints.  It is why I place so much emphasis on planning the changes rather than making changes blindly. It is also why, in the first step, I stress locating both the current and next constraint. You must be on guard and ready for constraints coming at you from all directions, but if you follow the Ultimate Improvement Cycle, I am confident you will be successful. In addition, any of the activities that you complete in any of the previous steps may result in the constraint being broken. If this happens, be prepared to move to it and start the cycle again.

Now that you have completed the first rotation of this improvement cycle, you are now ready to start the second cycle of improvement on the next constraint.  Fortunately, in the first step of this initial cycle, you are able to logically think through and predict where this new constraint would be. If you did this step correctly, in the first improvement cycle, you should be able to begin with step 1b of the second cycle of improvement relatively quickly, except for preparing for the third cycle of improvement. You should always identify where you believe the next constraint operation could be before starting any improvement in the current constraint. It should come as no surprise that this cyclic process is a continuous improvement cycle that never really ends. Remember, because throughput theoretically has no upper limit, you should be continually improving your throughput and profits, now and in the future.

This completes my series on the development and implementation of the Ultimate Improvement Cycle and I hope it proves to be helpful to those of you who might never have heard of this integration before.  I have used this strategy for over a decade in some form or another and all I can tell you is that it works very well.  I wish I could post the entire book for you, but such is not the case.  For those of you interested, my publisher is Taylor-Francis and the book can also be found on Amazon.

Bob Sproull