Bottleneck Busters Blog

Of course, in hindsight, it made perfect sense.  Efficiency was measured as the number of parts you made divided by the estimated number of part you could make, base upon the cycle time of the machine.  The bottleneck was the operation that most restricted flow, so it was rarely blocked or starved.  So the bottleneck efficiency was high – a “hand grenade close” estimate was taking the downtime percent and subtracting it from 100%.

Faster machines could, according to their cycle time, produce more parts than the bottleneck.  In reality, they spend a lot of their time waiting for Herbie – blocked or starved, as well as down.  Over time, they made no more parts than the bottleneck, but had a higher capacity, thus their efficiency had to be lower.

And the two machines we were studying?  I dubbed them the “anti-bottlenecks” – the fastest machines in the plant!  The stock cutting machines was really fast – it ran hundreds of parts in an hour.  The press, too, had a cycle time of a few seconds.  The bottleneck cycle time was just under 60 seconds, so these machines were several times faster than the constraint.

And what was the biggest delay for both of these machines?  If you guess “Waiting for baskets,” go out an buy that cupie doll you have always wanted.   What, then, was the action plan to improve the efficiency of this plant?  Buy more baskets!!!

But I had a hard lesson to learn that day myself.  After collecting the data from delay studies and a quick study on the bottleneck, I entered into the bottleneck analysis program C-Thru.  Of course, it confirmed my analysis, and demonstrated that improving the stock cutter and the press would have no impact on throughput or efficiency.  Further, buying more baskets would only improve efficiency during the time it took to fill those baskets.  After that, efficiency would return to today’s level. 

Fixing the bottleneck, however, would have a huge impact on throughput.  That area had to be the focus of improvements.  Studying the bulletin board further, I found that most of the action plans resulting in INCREASING the cycle time of the constraint, thus reducing what little blocking and starving there was, AND increasing efficiency.  Of course, throughput for the plant went down as well, but that was not obvious to them. It was clear to me that those changes would have to be removed.

Armed with my analysis, I went to the plant sponsor (who was also the efficiency program champion) and, in front of my folks and the other central office people there “to help” told them he was doing EXACTLY the wrong thing.  This program was damaging the plant, not helping it.  He would have to undo all those award-winning suggestions on the bottleneck.  He would have to stop worrying about the least efficient machines and focus the plant’s efforts on the most efficient machine. 

I think he listened for about a minute and then tuned me out.  After my report out, he thanked me for my analysis, and said that they were going to continue push the efficiency program as the way to save the plant.  I was stunned.  All I could think to say was, “Then I come by on the day they close the plant.”  He gave me a funny look, shook his head, and left. 

Of course, the plant’s performance continued to suffer, until the plant was eventually sold.  It then closed, but not officially under the GM logo.  For a while, I blamed the sponsor’s ignorance and politics for not following my advice  But after going through Jonah training and Clouds, I realized that in my rush to tell him the answer (and prove myself right, of course) I had not resolved his conflict.  That was a tough lesson.  Could I have saved the plant?  Probably not – those skills and experience would come with time, and much of my learning at this point in my career with TOC was trial and error.  But I still wonder about it just the same.

I use this example in my training classes all the time, for it reinforces several key points:

• The bottleneck is usually the most efficient machine (or has the highest utilization or highest OEE).  I often use this as a quick quiz to see if someone really understands TOC as much as they say they do. 

• Use inventory to find the bottleneck, especially the first time through.

• You have to understand the conflict your client faces to be able to solve it for him, thus shifting his paradigm to one that includes your solution.

• Efficiency measures have a very limited usefulness, and probably could be set aside, for all intents and purposes.

• You have the ability to save your plant, or elevate it to the next level or performance. And it’s your job to do that, so don’t wait for someone to tell you it’s your job.

Posted by KevinAKohls at 11:53 PM | Permalink | Comments (0) | TrackBacks (0)

It’s been a couple years since I left GM, and it’s been much longer than that since I witnessed something that I still use as an example today when I see plants focusing on improving efficiency, utilization, or even (don’t say it) OEE. 

We were just getting started in the Throughput Improvement game, and the “green” team that we had put together from various parts of the corporation was lacking some basic IE 101 skills.  When I heard that one of the experienced IE’s in our department was giving a class in delay studies at a local plant, I jumped at the chance to get a few of my folks in the training.

Despite being an EE, I had a wealth of experience in IE studies, since I was sponsored by Industrial Engineering at the Cadillac Clark Street plant (now a weed-filled lot).  Riding freight elevators to document usage, performing cycle time studies, chasing AGV's for downtime info, etc., were all part of my co-op experience, so I had a solid foundation. But I wanted my folks to see how it was done in the plant, and thus the emphasis on getting out of the class room and on to the plant floor.

It was fairly well known that the plant we were visiting was in trouble – poor throughput, long lead times, etc.  There was a lot of “outside help” in the plant trying to improve the situation, but we were only here for the class, so I doubted we’d be able to see or do much.  As we walked through the plant it was obvious that there was a huge efficiency push going – banners and signs were located throughout the plant extolling workers to be more efficient and productive.  In the middle of the plant we passed a bulletin board with pictures of a team of operators smiling out of photos whose backdrops were a pizza parlor, a baseball game, etc. Along with the photos were cheap ribbons indicating they were #1 in the plant in efficiency. Lists of successfully installed action plans rounded out the board.  I was starting to get a sick feeling in my stomach. 

After a review of the basics, my folks were broken down into teams and asked to collect data on the worst machines.  One was a fairly simple machine that cut metal stock into lengths for leaf springs.  The other was a press used to stamp out parts needed for the suspension.  Why these machines?  Because the data showed that these two operations were the least efficient in the plant. 

Did these machines have problems?  Certainly – parts jammed inside the machine, dies had to be replaced, tools sharpened, etc.  Were the operators working hard?  Yes and no – when they worked, it was like watching industrial athletes.  But all too often they had to stop and wait.  Why?  Well, the delay study showed they both had the same root cause delay.  Any idea?  Read on.

My TOC background and my reading of The Goal told me that we should be doing a delay study on the bottleneck.  Was one of these two machines the bottleneck in the plant?  The simplest method was to do what Jonah showed Alex to do in his plant – look for the inventory!

While the others slaved over their stopwatches and clipboards, I hunted for inventory.  It didn’t take long, because I was pretty sure I knew where to look.  There, near the middle of the plant, right next to the bulletin board, photos, and ribbons, was bay upon bay of inventory, stacked floor to ceiling in baskets, right before the most efficient area in the plant – the bottleneck!

(Continued in the next Blog Entry!) 

Posted by KevinAKohls at 11:42 PM | Permalink | Comments (0) | TrackBacks (0)

Since I blogged the other day about clients not buying in to the solution, I feel compelled to write about another situation.   This is the case where the client understands the pain, is not happy about where they are at, but “are too busy drowning to learn how to swim.” 

Oh, they want to learn more, but I find I have to be VERY patient with this client, even though I want to point out their situation will get better the faster they learn about the solution I am proposing.  But scheduling a meeting with the right people takes weeks or months, and then when I go to do the pitch, another emergency has arisen, and they ask if I can come back another time (at my own expense, of course) to make another presentation. 

Working with these clients is a tough decision.  I usually have to set a limit on my involvement, to make sure I am not taken advantage of.  I look for several things in making this decision.  Clearly, one of the factors is communication.  If they are actively engaged in a two way discussion, and understand their Undesirable Effects, or they can admit the pain/problems they are experiencing, that’s a plus. Another is their willingness to work with me. If they offer to pay for my trip the next time, or set aside time on a weekend to hear a pitch, that’s also a step in the right direction.

Finally, I look to see if this potential client has the ability to realize that they will be better off if they take the time to take swimming lessons.  To that end, they must be able to draw a line, and say that this presentation I am going to give is just about the most important thing this company has to do to improve.  I have to see this type of behavior at some point to keep working with this client.

A few never get there.  They don’t even get the joke within the title of this blog.  They often take about all the emergencies as “one time events,” but then admit they occur two to four times a month.  Their management system creates emergencies at a predictable rate as a side effect of their process. Tougher still is the fact that my contact is usually a middle manager who “gets it,” and wants to get off the treadmill. But they are having trouble convincing their leadership and other managers.  

This may be due to the fact that a number of these managers are essentially professional “fire-fighters,” and enjoy the challenge that comes with these emergencies.  They may actually fear the stability that might be generated by a new process, because their fire fighting skill will not be valued.  I look for these signs when faced with “drowning” clients.  For these clients, I have to justify it as a “cycle of life” in the business world, and move on.  

Lucky, most get it, and with a bit more patience on my part, they set aside the time for swimming lessons, and even for swim practice.  For a few, I have dreams of the Olympics…

Posted by KevinAKohls at 11:17 PM | Permalink | Comments (0) | TrackBacks (0)

Moving from the corporate world to the consulting world has it share of differences, and things that are the same.  As the Throughput Improvement Process progressed through GM, I got a lot of high level support, from people like Gary Cowger, Tom LaSorda (when he was there), and others.  When that level of support existed, there was little doubt that the plant was going to would listen to what I had to say, and at least give a pilot program a worthwhile effort.  They were pretty much sold after that.

In the consulting world, I run across a lot of potential customers that would be great to work with.  They have an interesting product, they have a lot of sharp people, they are poised to grow significantly, etc.  Many times the need for the solution I am offering is very apparent, at least to me.  But the question I ask myself now is, “is there enough pain?”

It has become a filtering process to help me decide who I am going to spend time with, and who am I going to push farther down the list of prospects, especially for follow up work.  Many of my potential clients are interested in the Theory of Constraints, simulation, data collection, scheduling, project management, etc.  But often it is just that – curiosity.  They don’t really feel enough pain to change their paradigm to the solution that I am describing to them.   

For some of these clients, I could rattle off a list of Undesirable Effects that are due to one conflict or constraint.  I could then follow that with a proven solution that I can clearly explain will have benefit to them.  I could go through a list of clients that would be willing to sing the praises of that solution in their company.  But for this client to make the change from where they are to the new process I am proposing is a tough choice for them, because they fear the solution more than their current situation.  For most of my clients to make the jump, they have to feel that of pain from their current situation is so bad that they are willing to try any solution that makes sense.

Some of the consultants who I work with get stuck on this – they see a client they would REALLY like to worth with, and who they think they can provide a lot of benefit.  But they are frustrated that the client doesn’t want to move to the new solution.  These consultants keep going back to these clients, constantly trying this method or that method to get the client to buy their solution. But their target clients are fairly comfortable with their current situation, and see little reason to move.  Like in the Mermaid situation in a previous posting, they are okay dealing with the problems they have.  I have to advise these fellow consultants to move on to other clients, because if their potential clients don’t feel the pain, the chances of your solution being adopted are slim to none. They are better off quickly moving on to the next potential client, and hope that this one is squirming with pain.  Then they might see a client “getting off the pot,” and adopting the proposed solution.

Posted by KevinAKohls at 10:56 PM | Permalink | Comments (0) | TrackBacks (0)