Category: Quality

Posted on

What Nukes?

Cruise Missiles

Warning to Reader: This piece has a lot of free-association flow to it!

Oops. A few weeks ago a story emerged in the press that a B-52 had flown from North Dakota to Louisiana with half-a-dozen nuclear armed missiles under its wing. The aircrew thought they were transporting disarmed missiles. This is a rather major oh-oh for the USAF, as in general, they are supposed to keep track of nuclear warheads. (Yeah, I am understating this. I, by the way, can speak from a small amount of experience as I once held a certification to deal with these things, so I have some idea how rigorous the procedures are.)

Normally the military deals with nuclear weapons issues with a simple “We do not confirm or deny…” but in this case they have released an unprecedented amount of information, including a confirmation that nukes were on a particular plane in a particular location at a particular time.

The news story of the report summarized a culture of casual disregard for the procedures – the standard work – for handling nukes. I quote the gist of it here:

A main reason for the error was that crews had decided not to follow a complex schedule under which the status of the missiles is tracked while they are disarmed, loaded, moved and so on, one official said on condition of anonymity because he was not authorized to speak on the record.

The airmen replaced the schedule with their own “informal” system, he said, though he didn’t say why they did that nor how long they had been doing it their own way.

“This was an unacceptable mistake and a clear deviation from our exacting standards,” Air Force Secretary Michael W. Wynne said at a Pentagon press conference with Newton. “We hold ourselves accountable to the American people and want to ensure proper corrective action has been taken.”

So what’s the point, and what has this got to do with lean manufacturing?

The right process produces the right result.

As true as this is, it isn’t the point. The point is that the Airmen didn’t follow the procedures. And now the Air Force will apply the “Bad Apple” theory, weed out the people who are to blame, re-emphasize the correct procedures everywhere else, and call it good.

How often do you do this when there is a quality problem, an accident or a near miss? How often to you cite “Human Error” or “not following procedures” or “didn’t follow standard work” as a so-called root cause?

You need to keep asking “why” some more, probably three or four more times.


Field Guide to Understanding Human ErrorTo this end, I believe Sydney Dekker’s book “Field Guide To Understanding Human Error” should be mandatory reading for all safety and quality processionals.

Dekker has done most of his research in the aviation industry, and mostly around accidents and incidents, but his work applies anywhere that people’s mistakes can result in problems.

In the USAF case cited above, there was (according to the reports in the open press) a culture of casual disregard for the established procedures. This probably worked for months or years because there wasn’t a problem. The “norms” of the organization differed from “the rules” and I would speculate there was considerable peer pressure, and possibly even supervisory pressure, to stick with the “norms” as they seemed to be adequate.

Admittedly, in this case, things went further than they normally do, but let’s take it away from nuclear weapons and into an industrial work environment.

Look at your fork truck drivers. Assuming they got the same training I did, they were taught a set of “rules” regarding always fastening seat belts, managing the weight of the load, keeping speed down and under control, checking what is behind and to the sides before starting a turn (as the rear-end swings out.. the opposite of a car). All of these things are necessary to ensure safe operation.

Now go to the shop floor. Things are late. The place is crowded. The drivers are under time pressure, real or perceived. They have to continuously mount and dismount. The seatbelt is a pain. They get to work, have the meeting, then are expected to be driving, so there is no real time for the “required” mechanical checks. They start taking little shortcuts in order to get the job done the way they believe they are expected to do it. The “rules” become supplemented by “the norms.” This works because The Rules apply an extra margin of safety that is well above the other random things that just happen around us every day. The Norms – the way things are actually done erode that safety margin a little bit, but normally nothing happens.

Murphy’s Law is wrong. Things that could go wrong usually don’t.

The “Bad Apple” theory suggest that accidents (and defects) are the fault of a few people who refuse to follow the correct procedures. “If only ‘they’ followed ‘the rules’ then this would not have happened.” But that does not ask why they didn’t do it that way.

Recall another couple of catastrophes: We have lost two Space Shuttle crews to the same problem. In both the Challenger and Columbia accident reports, the investigators cite a culture where a problem which could have caused an airframe loss happened frequently. Eventually concern about it became routine. Then, one time, other factors come into play and what usually happens didn’t happen and we are wringing our hands about what happened this time. Truth is it nearly happened every time. But we don’t see that because we assume that every bad incident is an exception, the result of something different this time. In reality, it is usually just bad luck in a system which eroded to the point where luck was relied upon to ensure a safe, quality outcome. In this case they didn’t single out “bad apples” because the investigations were actually done pretty well. Unfortunately the culture at NASA didn’t adjust accordingly. (Plus Space Flight involves the management of unimaginable amounts of energy, and sometimes that energy goes where we don’t want it to.)

So – those quality checks in your standard work. Do you have explicit time built in to the work cycle to do them? Are your team members under pressure real or perceived to go faster?

What happens if there is an accident or a defect? Does the single team member who, today, was doing the same thing that everyone does every day get called out and blamed? Just look at your accident reports to find out. If the countermeasure is “Team Member trained” or “Team Member told to pay more attention” or just about anything else that calls out action on a single Team Member then… guilty.

What about everybody else? Following an incident or accident, the organization emphasizes following The Rules. They put up banners, have all-hands meetings, maybe even tape signs up in the work place as reminders and call them “visual controls.” And everything goes great for a few weeks, but then the inevitable pressure returns and The Norms are re-asserted.

Another example: Steve and I were watching an inspection process. The product was small and composed of layers of material assembled by machine. Sometimes the machine screwed up and left one out. More rarely, it screwed up and doubled something up. As a countermeasure, the Team Member was to take each item and place it on a precise scale, note the weight, and compare the weight to a chart of the normal ranges for the various products.

There were a couple of problems with this. First, the human factors were terrible. The scale had a digital readout. The chart was printed and taped to the table. The Team Member had to know what product it was, reference the correct line on the chart, and compare a displayed number with a set of displayed numbers which were expressed to two decimal places. So the scale might say “5.42” and she had to verify whether that was in or out of the range of “5.38 – 5.45”

Human nature, when reading numbers, is that you will see what you expect to see. You might recall that it was different after five or six more reads. So telling the Team Member to “pay more attention” if she made a mistake was unreasonable. Remember, she is doing this for a 12 hour shift. There is no way anyone could pay attention continuously in this kind of work. If a defective item got through, though, there would be a root cause of “Team Member didn’t pay attention.” She is set up to fail.

But wait, there’s more!

She was weighing the items two at a time. Then she was mentally dividing the weight by two, and then looking it up. Even if she was very good at the mental math and had the acceptable range memorized, that isn’t going to work. Plus, and this is the key point, in the unlikely but possible scenario where the machine left out a layer in one item, then doubled up the next, the net weight of the two defective items together would be just fine.

“Why do you weight two at a time?” Answer: “It’s faster.” This is true, but:

  • It doesn’t work.
  • She doesn’t need to go faster.

Her cycle time for weighing single items was well within the required work pace. But the supervisor was under pressure for more output because of problems elsewhere, and had translated that pressure to the Team Member in a vague “work faster if you can” way. It was the norm in that area, which was different from the rules.

Where is all of this going?

The Air Force has ruined 70 careers as a result of the cruise missile incident. They may have been right to do so, I wasn’t there, and this was a pretty serious case. But the fact that it got to this point is a process and system breakdown, and it goes way beyond the base involved.

Go to your own shop floor. Stand in the chalk circle. Watch, in detail, what is actually happening. Compare it with what you believe should be happening. Then start asking “Why?” and include:

“Why do people believe they have to take this shortcut?”

Posted on

Be A Perfect Supplier; Be A Perfect Customer

Operations that work to the “push” are well known for complex and interdependent problems. What looks like a problem in one area often has causes, or parts of causes, in other areas. Quality problems, delivery problems (late, too much, too little, wrong stuff), sub-optimizing attempts to reduce local cost.. all of these things propagate unchecked through the plant. To fix one area means having to fix almost all of the others at once. This initial improvement gridlock is pretty common.

When you start talking about implementing JIT in an environment like that, the pushback is visceral and, to be honest, legitimate. The only reason they get anything done is because the system runs to sloppy tolerances and doesn’t expect much. JIT demands a degree of mutual vulnerability, at least it seems that way when it is first presented.

The other really big psychological issue is that lean is often presented as a solution to all of these problems. Quite correctly, the survivalist shop floor supervisors don’t see that. And they are right. The problems do not go away when you implement flow. I sometimes find it surprising how many people don’t get that. All they see is fewer problems in operations that have flow, and they mix up cause and effect. Good flow is the result of solving the problems. Not the other way round, but I digress.

If you are dealing with this problem gridlock, where do you start? The first step is to contain the problems as close as possible to their sources.

The objective is to apply what temporary countermeasures are necessary to appear as a perfect supplier to your downstream customers; and the appear as a perfect customer to your upstream suppliers.

So what is a “perfect supplier?” That is probably the easier of the two logical questions to answer. A perfect supplier is capable of supplying what you need; when you needed it; with perfect quality; one-by-one; at takt.

What is a “perfect customer?” This one is a little harder, but it is good to look back at what makes a perfect supplier. Ask yourself – what things does the customer do that makes it difficult to be a good supplier? What does a bad customer look like?

  • They order or demand things in batches.
  • They give no advance notice about what they need.
  • Their demand is unpredictable and inconsistent.

A lot of this seeming unpredictability actually originates in the supplying process. I recall a case where the manager of a fabrication shop swore that his customer’s demands were totally random. At the assembly plants, though, they operated to takt with a steady mixed-model schedule. There was very little change from one day to the next. Why the big disconnect? The fabrication ship ran things in big batches, and set up big batch pull signals. Naturally those big batch pull signals would go a long time between trigger points, so they would seem to come back at arbitrary times, for huge amounts. Self-inflicted gunshot wound. Once they took the simple step of shipping things in smaller containers, a lot of that seeming instability went away. Smaller containers meant more frequent releases of pull orders, which gave them a cleaner picture of the demand picture. Think of it this way: The smaller the pixels on your screen, the more resolution you have in the image.

So that does the perfect customer look like? Level, predictable demand at takt with no major fluctuations.

Think of the purpose of heijunka or leveling production. Because customer demand arrives in spikes, batches, lumps, the leveling process is necessary to make that demand appear to be arriving exactly at takt time.

Although the books, such as Learning To See say there is only one pacemaker process or scheduling point, non-trivial flows frequently require re-establishing the pulse.

This is especially true if orders are batched up either through the ordering process itself or the delivery process. An example of this is a manual kanban process between an assembler and the supplier. Even though there is a paced assembly line and good leveling, kanban cards are collected and delivered to the supplying process in transportation-interval “chunks.” The supplier needs to have their own heijunka board to re-level the demand and pick at takt from the supermarkets. The alternative is that the demand arrives at the production cells in those same batches, and the smooth takt image is lost.

In a Previous Company we were working a project to establish pull on a trans-continental value stream that had five major operations, all in different geographic locations. To use the word “monument” does not even begin to describe the capital infrastructure involved, and there were a lot of these assets shared with other value streams, so relocating and directly connecting flows was out of the question. There were unreliable processes, big batches, transportation batches, end-using customers’ orders in huge, sudden surges based on their surge based business cycle. Step by step we isolated inventory buffers and ended up putting in heijunka to re-level the demand at nearly every stage of the process. It was big, ugly, cumbersome, but it worked to isolate problems within a process vs. pass them up and down stream.

The objective was simple: Use inventory buffers and heijunka to make each process in the chain appear as a perfect customer to its suppliers – always pulling exactly at takt. The consuming process “owned” the inventory buffers necessary to do this. Reason: Simple. The problems that cause them to be a less-than-perfect customer are theirs, so they own the inventory that is necessary to protect their suppliers from those problems. Likewise, that process owned whatever inventory was necessary them to appear to be a perfect supplier. They had to enable their customer to pull one-by-one, exactly at takt, from them, even if their problems kept them from producing that way.

Never mind that the downstream process didn’t actually consume at takt. THEIR inventory buffer translated their spiky signal into one which reflected the takt time.

All of this was very sophisticated and complicated, but in the long haul it worked. Megabucks of inventory came out of the system. Megabucks remained, but we knew exactly why it was there, and who had to solve what problems to reduce it.

If you can’t be a perfect customer, create the illusion that you are.

If you can’t be a perfect supplier, create the illusion that you are.

Then you own the problems yourself, you own the inventory-consequences of having those problems, and you control your own destiny.

Posted on

“Packaging” is spelled M-U-D-A

In Mike Wroblewski’s blog “Got Boondoggle?” he comments on just how much packaging and dunnage is not visible in Toyota’s Industrial Equipment plant. Of course that is remarkable because of just how common it is to find the opposite condition. Factories (and offices) have lots of packaging around, and spend lots of time dealing with it.

Toyota has been working on this a long time. They have the added advantage of being an 800 pound gorilla with most of their suppliers. They can specify packaging and insist on things being done a certain way. In a lot of cases it is the supplier that is the 800 pound gorilla, and a lot of small companies have a hard time being heard. But you can still make a lot of difference if you apply the principle that packaging is muda.

A frequently invoked (and overworked analogy) is the assembler or operator as a surgeon. Everything must be ready for the value-add operation to be performed waste free. If there is waste in the process, keep it away from this point. Surgical instruments come in packages. But I can assure you the surgeon is not unwrapping the scalpel. So who is?

The instruments are prepared and made ready for use by the staff.

Now take this to your factory floor. The first step is to keep dunnage and packaging out of the production area. There are actually a lot of advantages to doing this. The chief one is obviously optimizing your value-add time. But all of that packaging also takes up space. EVERYTHING that enters the production area MUST have a process (meaning a person!) to get it OUT of the production area. Since you have to unpackage that stuff anyway, do it before it gets to production. This means that someone else picks the part and prepares it for use just like the staff in the operating room.

Do this and you have applied one of the principles Liker and Meier point out in The Toyota Way Fieldbook – if you can’t eliminate sources of variation, then isolate them. In other words, set up a barrier that contains the waste so that your value-adding operation sees the result of a perfect supplier.

You can then take the next step: Do this at receiving. If the parts do not arrive from the supplier packed the way that your internal material conveyance system needs them, then put the resources into receiving to convert what you get from your suppliers into what you wish you got from them.

This is applying the principle of systematically pushing waste upstream, closer to the point where it originates. The other thing you have done is force yourself to dedicate resources to deal with this waste instead of spreading it so thin the cost is hidden. You will know what it costs you in terms of people, time, space, etc. to deal with the fact that your suppliers don’t ship what you need. By highlighting the problem instead of burying it, you have the opportunity to address it.

One more thing – it might seem easier to take these little wastes and spread them thin. After all, if everybody just does one or two trivial tasks, it doesn’t seem so bad, does it? It is those trivial wastes, those 5 second, 30 second, 1 minute little things that accumulate to half your productivity. It takes work to see them and eliminate them. Don’t add more to the process on purpose.

Posted on

Invert the Problem

One very good idea-creation tool is “inverting the problem” – developing ideas on how to cause the effect you are trying to prevent. This is a common approach for developing mistake-proofing, but I just saw a great use of the idea for general teaching.

Ask “How could we make this operation take as long as possible?” Then collect ideas from the team. Everything on the flip chart will be some form of waste that you are trying to avoid. In many cases, I think, even the most resistant minds would concede that nothing on this list is something we would do on purpose.

It follows, then, that if we see we are doing it that we ought to try to stop doing it. And that is what kaizen is all about.

Posted on

Who Took My Grease Pencil?

I was in a popular “Gold Rush” themed restaurant the other night, and they were struggling with a new table assignment system.

In the past the system was very simple. When you arrived, you told them your name, the number in your party. They wrote your name on a list, and gave you a pager. They had a laminated chart of the table layout, and marked tables as occupied, uncleared and available with a grease pencil. As tables became available, they moved down the list, triggered the pager, and took guests to the table. As tables were cleared and bussed, they were reported as available.

No more. Now there is a computer screen with the layout on it. They hand you the pager, and I suppose it gets logged in to “the system” as a party of 2, or whatever. And the computer pages you when an appropriate table is available. Sounds great, doesn’t it?

Of course the system is new, and the team was struggling a bit. That is expected, it is unfamiliar. But as we handed in our pager, I commented “I thought the grease pencil worked just fine.” The response was “Tell me about it.”

Now I suppose the technology enables them to track all kinds of great metrics like table turnover, etc. But if it is like most similar software implementations, those benefits are solutions in search of a problem. They are justifications for the expenditure.

I am always very wary when someone proposes to replace a functioning manual process with a computerized one. The main reason is this: The people who do the process no longer can improve it.

With a chart and a grease pencil, the team owns the process and readily understands the (non-) technology behind it. If they find a better way, it is easy for them to make an improvement.

Bury the process in a computer and you take that away. All the team can do is blindly execute whatever the programmer thinks should be happening. Programmers are smart people, but they generally do not have to execute their process hundreds of times a day. Maybe a few times – or even a few days – for testing, but not day after day. They do not, and can not, see the small issues that accumulate to become aggravation.

Before you introduce a “high tech” solution into your work area, think long and hard.

EXACTLY what is the current situation? EXACTLY what standard of performance is not being met by the current process? EXACTLY what are you trying to achieve? Remember that “automating the process” is a countermeasure, and that a “manual process” is not a problem. Let me say that again: If your problem statement says “Process is manual” then you do not yet understand the problem, and there may not BE a problem. What, exactly, about this manual process does not meet your expectations?

If the problem is that the process is labor-intensive or cumbersome, then you are getting closer. But jumping to automation still is not appropriate here. Have you carefully studied the process to see why it is labor-intensive or cumbersome? Have you looked at every step, every motion, and evaluated:

  • Why is it necessary?
  • What is the purpose?

Don’t know? Then that step is a candidate for elimination as pure waste.

  • Where should it be done?
  • When should it be done?
  • Who should perform this step?

These questions give you insights that let you combine operations. Administrative processes, especially, are full of redundant work – people looking up or entering the same information at different times in different places, or copying information from one place to another. Your goal is to take the remaining operations, the ones which passed the “Who / What” test and rearrange the steps into the best logical sequence, with the right people doing them.

  • How should this task be done?

Take the remaining steps and simplify. Make the job easier and quicker. Jigs, fixtures. In administrative processes – forms, templates. Find sources of error and mistake-proof them. Work out the method.

When you are done with all of this, then take a look at what is left. NOW, if there is a problem that has not, or cannot, be solved within the existing context you might consider an automated solution as one possible countermeasure… but don’t reflex there, unless you want to turn your kaizen over to programmers.

Last Thought – what about those great metrics the automated system can collect? Question: Do they pass the “Who Cares?” test? What is your plan to use those measurements to know where you are, and are not, performing to your standard? What is your plan to use that information to target improvement activity? Keep in mind that you cannot get performance simply by measuring it, any more than calculating your fuel mileage makes your car drive further. The purpose of measurement is to compare What Should Be Happening vs. What Is Actually Happening so you can compare your results against your predictions to see if the process is working the way you expect it to.

Posted on

Kaizen Events – Why and Why Not… continued

The other day I wrote about the situations where I felt a 5 day kaizen event was actually useful. I want to add one more.. sort of. Actually I want to elaborate on “education.”

Sometimes in the early stages of an implementation, there are influential people who need to be won over. Now for those who are cynical, there is not a lot of hope of that, at least not now. But for the people who are honest skeptics – meaning they will take in what information they have and assess it – those first few kaizen activities can have a high emotional impact.

Here is where you, the change agent, have an opportunity to make this “sticky.” Back in August I wrote a couple of posts that suggested that deliberately applying the elements of “stickiness” outlined in the excellent book “Made To Stick” would go a long way in building and sustaining an initial momentum. An initial kaizen event that is specifically structured to be high-impact can go a long way to do that.

In this special case you are producing a “reality show.” You are building a structure and a situation that will give your participants a specific experience. You want to create the six elements of “stickiness” that are covered in the book.

Simple. You want to send a simple and direct core message, a take-away, that everyone involved will be able to relate to. They have to understand experience just how much waste (and therefore opportunity) exists in the operation. They have to experience for themselves the power of engaging the people who do the work, of seeing for themselves, living in the conditions that exist in the work area every day. They need to experience the drag that is put on effective operations by all of the short-sighted decisions that are made every day.

Unexpected. You want to structure this kaizen event so that there is a big change in the performance of the operation, preferably in a way that was thought to be impossible. The highest-impact thing you can do is to create flow across several previously isolated process islands. This will typically crash inventory levels by one, and sometimes two, orders of magnitude, with a relative increase in velocity.

Concreteness. Same as above, actually. By participating directly in something that produces tangible, and real, results they immediately begin to learn application vs. academic theory.

Credibility. Again – direct participation in seeing the problems, clearing and solving those problems, brings credibility to the message – that a dramatic performance improvement is something we can do if we just pay attention to the right things.

Emotions. The purpose of the report-out at the end of these events is to allow the team that did the work to get.. and take.. credit for what they did. The report-out also emotionally engages the team in their work and their results.

Stories. If it is done well, the experience starts to be shared. People inevitably talk about the improvements they made, and how they solved this or that problem. People love to solve problems, and they like to talk about what they have done and what they learned in the process. When the General Manager starts telling these stories from her personal experience, people tend to pay attention. Hopefully they begin to say: “I’ll have what she’s having.”

Posted on

Kaizen “Events” – Why and Why Not

To many people, 5 day “kaizen events” are the way to implement lean manufacturing, and the way to improves processes. There is another, larger, group which insists that “events” are only one method, but in actual practice, kaizen events are all they do.

At the risk of being branded a heretic I propose there are two, maybe three, cases where kaizen events are the most appropriate tool. This is based on my personal experience, so your mileage may vary.

  1. Teaching. My contacts with long-time Toyota veterans are consistent – they have week-long events. They call them PKT or Practical Kaizen Training. The purpose is to:
    1. Teach leaders (and potental leaders) how to truly grasp the current situation – to see the actual issues being experienced by the workers as they do the work.
    2. Teach those leaders the cumulative effect of many small improvements, especially focused on the problems that disrupt routine work.
    3. Teach leaders that most of these problems are quick and simple fixes, if only someone did something about them.
    4. Teach leaders to teach others to observe, see problems, and solve them.
  2. Stabilization after a major change. Implementing flow often involves making major changes to the material and work flow. Those changes naturally introduce instability (or more properly, they reveal problems that have always been there, but hidden). It is crucial to have a team ready to intervene and quickly see, fix and then develop countermeasures for those problems. The week would start with the major change, then the team would focus on observing the actual (resulting) work, seeing problems (sources of instability), and devising and implementing countermeasures. The objective is to make the change, and leave it in a stable, sustainable state. All too many kaizen events do the opposite – make the big change at the end of the week after a lot of debate, and leave an unstable process for the Team Members to cope with on their own. This is “drive by kaizen” and leaves a bad taste in people’s mouth.
  3. Gathering a team to solve a specific problem. This is different than implementing a major change above. In #2, you already know what you want to do, you are just doing it and re-stabilizing the process. In this case, you know the problem, or what must be accomplished, but the local team does not have the time or wherewithal to actually solve the problem Some examples:
    • Achieving a dramatic reduction in changeover time.
    • Understanding and solving a nagging quality problem.
    • Setting up a layered maintenance checks on a machine.

All of this implies one important thing: That the kaizen event is planned based on a thorough understanding of the current situation. This can only be gained by careful observation and study. Note that none of the above items describes a scenario of bringing a team together to implement vague or unreachable goals and targets. Enough for now, before I start rambling again.

Posted on

Training – Critical Questions To Ask

There is lots of “Lean Training” out there, and the quality ranges across the board.

“Lean training” is a megabucks business, and anyone who can assemble a pack of PowerPoint slides and a web site is offering “lean training” out there. It is certainly a case for buyer-beware. So how do you evaluate all of the alternatives, especially if you are just learning and might not be in a position to judge? (Irony: If you are in a position to critically judge these training programs, you probably don’t need them.)

What is being taught and how?
In my experience, most people will readily agree that the tools and artifacts usually associated with the Toyota Production System or Lean Manufacturing are not the system itself. Rather, it is critical for people (and especially leaders at all levels) to understand the thinking behind the tools and artifacts.

The way Toyota teaches the thinking in their new plants is through structured experience. Key leaders are assigned coordinators as mentors. Leaders are taken to established plants to immerse into the system itself. The mentoring continues as the new plant is brought on-line. The process is long, resource intense and expensive. As a result the people who were trained this way are highly sought after in industry. (Another story for the future sometime.) Steven Spear’s article, “Learning to Lead at Toyota” does a great job giving the reader a feel for how this is done. The learning process is entirely experiential.

On the other hand, “talking head lecture” and PowerPoint slides are probably the least effective way to teach this stuff. Even with a couple of simulations with toy trucks or Legos, a classroom-only exercise is only going to get the general concepts across.

If you accept that the real learning comes from guided experience, then it follows to ask if the time spent in the classroom reduces the time required for experiential learning by at least as much. If a week in the classroom (plus the travel time, etc. away from the job) does not return at least two weeks of reduction in the hands-on learning, then it isn’t worth it… no matter how “feel good” it is.

What is the emphasis on direct observation of actual problems? One of the core skills for leaders to learn is how to see problems. If you ask “How much time is spent to watch and understand the work?” the answer you get will tell you a great deal about how well the trainer actually understands the TPS. A high-pressure “kaizen event” especially one which emphasizes just-do-something over first understanding the actual situation – is going to teach exactly the wrong things. Action without understanding results in chaos.

How much of the training involves making actual improvements to actual work? The more the better, but only in the context above.

The classic 5 day kaizen event was originally an educational exercise, and it works very well for this if it is planned and led with learning in mind.

What is the reputation of the teachers? Disregard client testimonials. Ask to speak to some long-term customers. I say long-term because in the initial stages of lean implementation things are pretty easy. A typical medium-sized factory, for example, can get most of the mechanics into place over a few months with aggressive leadership. But if the teachers do not understand (or understand and do not teach) the leadership how to detect, escalate and solve the thousands of problems that will inevitably be flushed to the surface, the implementation cannot sustain for long.

Recognize Reality: The only way to really lean this stuff is to through experience. And not just any experience. Just being told how to implement kanban, fill out the standard work forms, take cycle times, etc. is not learning the things you must know to sustain your gains and build on the initial momentum.

The critical skill – the one that (so far) is only learned through mentored experience – is how to direct actions through guidance and teaching vs. just telling people what to do or how to do it.

Posted on

Takt Time and Leveling – What’s The Point?

A few days ago I wrote about asking “What is your takt time?” and the likely responses to that question. But in my list of common responses, I left one out – “What’s the point? We get everything out by the time the truck leaves.”

Here’s a real-life example: In a high-volume consumer goods factory we had a daily transportation cycle. Shipments left once a day. Parts and materials arrived once a day. Although the operation was not without its glitches, the process itself incorporated a lot of automation (another story entirely), and the time through the machinery was pretty quick.

We were trying to implement the production leveling (heijunka) into the enterprise flow between the factory and the distribution system. While the mechanics were very straight forward, leveling the model mix during the course of the day encountered a logical question: What’s the point?

And what is the point? With or without model-mix leveling the same stuff ended up on the truck at the end of the day, and the total amount of inventory in the factory was not going to dramatically change. So why go through the trouble, especially of working changeovers on the packaging equipment, when there was apparent no net effect?

The question is a logical one until we understand that takt time (or pitch in this case) is not a production quota. It is part of a standard.

What’s so important about standards?
Without a standard, you can’t detect a problem.

Daily management is about rapidly detecting, correcting and solving problems. This is much easier to do when dealing with small problems before they grow into big ones.

The “What’s the point?” question even gets asked in the course of many lean manufacturing implementations. The operation reaches a level of performance that is “good enough” – for example, everything makes it onto the truck by the end of the day – and they are satisfied with that level of performance. This is when continuous improvement stops.

Have all of the problems been solved? Has all of the waste been removed? Of course not. But the next level of problems, and therefore the next level of performance, is under the radar.

In the factory I described above they had more demand than they could handle. They were already working 24/7, and were working to add capacity. They wanted to speed up the automation, and possibly even add additional lines. Yet, during the course of a day:

  • They lost many units to defects.
  • The lost production to machine stoppages and slow-downs.
  • They had part shortages and frequently substituted one product for another in the shipments, and made it up tomorrow.
  • Because they were “behind” they relentlessly kept the lines running, only to find defective product in final inspection.

The list goes on. They are all familiar things.

So what is the point of applying leveling product mix and establishing the discipline of a takt time or pitch?

Honestly, there isn’t any point unless they also implement a leadership process to immediately call out and respond to any slippage or deviation from the intended pace and sequence of production.

So – what started out as a question about a common tool or technique in the TPS has come around to what the core issue really is when that “What’s the point?” question is asked: Lean manufacturing is not about the tools and techniques. It is a system to assist a proactive leadership culture that is almost obsessed with finding and fixing the problems that keep them from achieving perfect safety, perfect quality, perfect flow, with zero waste.

A “problem” is any deviation from the standard. (And if you don’t have a standard, that is a problem.)

Two key questions:

Are we meeting the standard? If the answer is “yes” then:

Are we looking at perfection?

One or the other of those questions is going to drive you to address the next level of problems.

Posted on

Getting A Plant Tour

A couple of days ago I wrote about how to host a tour. Here are some thoughts on how to get one. As always, I’d love to hear your comments and experiences.

Don’t expect your hosts to change your “cement heads.” I have had requests from groups who wanted to send their “resistant managers” to our factory so we can show them things that will change their minds. Doesn’t work. Sorry, that is your job. My experience is that people who don’t want to see the benefits will always find all of the things that are “unique” about their circumstance, and special case reasons why the other place is doing so much better.

Go to learn, not to look. In my last post I made reference to “industrial tourists.” Those are groups that are more interested in the layout and clever gizmos than in the thinking behind them. They are, at best, looking for ideas and technical solutions to their problems. Copying others’ solutions is not thinking.

Going to learn is a different attitude. When you look at a layout, or other technical solution, ask yourself this: “What problem does that solve?” How does it save time? How does it remove variation from the process? What did the operation look like before they did that? Force yourself to think in four dimensions. Not just what you see now, but what it would have looked like in the past. WHY did they do this?

Although many people think lean manufacturing is counter-intuitive, I think that with this line of thinking you will find it actually is just common-sense solutions to the problems that everyone has, every day.

Nobody is perfect. Even a Toyota plant has obvious issues. If you end up fault-finding, you will miss the good stuff. I was touring a Toyota plant with a group a couple of years ago and it had obviously slipped. This is old news, and one of the reasons for their internal back-to-basics approach. But two things came to light: The rich visual controls made it easy for total strangers on the 1 hour tour to SEE the difference between “what should be” and “what is.” Wow. Try that in YOUR factory. And, reading the news stories, it was a problem they were taking very seriously and doing something about it vs. not noticing the deterioration and just letting things go.

Every plant has issues. Some have great material flow and pull systems, but only average problem solving. Others have a great technical base for home-grown tools, fixtures and machines. A few have great problem solving (They seem to be doing better than others.) Take in what is working, and what is holding them back. What would be the next problem they are working on?

Pay attention to the people. People are the system. How do they interact with the physical artifacts (layout, machines, etc.) An operation that has their stuff together will have people who are obviously comfortable with the pace of work. It will be obvious they get support when there are problems.

Don’t ask too many questions. What? Aren’t you there to learn? Yes. But try to learn with your eyes first. Even if you are moving, “stand in the chalk circle” and see the problems and the solutions. Sharpen your observation skills before you take the tour. Practice in your own plant. When I am hosting visitors and we have the time, my response to a question is to show them where to look for their answer, then ask them what they saw.

If allowed, make sketches. Most operations will have a prohibition against photographs. Even if they allow photos, however, you will capture much more if you stand and sketch what you see. You don’t have to produce a work of art. The purpose is to force your eye to pay attention to the small details. You will see much more through the eyes of the artist than you will through a camera.

Remember they are in the business of production, not consulting.
“Be a good guest” and remember that everybody there has a real job.

Edit 5 Sept: And Jon Miller correctly pointed out something I missed:

Give Back. You will bring “fresh eyes” to their environment and see things they do not. Everyone suffers from a degree of blindness to the familiar. If you are really going to see and learn, you will gain insights that can help your hosts in their own improvements. Ask them the questions that will help them see what you see.