Supplier Selection: Beyond Quality, Delivery, Cost

Do you have a responsibility to make sourcing decisions on anything other than Quality, Delivery, Cost? This news item about a mass-fatality industrial fire in China opens up some interesting thoughts about sourcing over here.

For future reference after the link dies, the lead of the story is:

A fire at an illegal shoe factory in eastern China has left 34 people dead..

That, by the way, is a great lead. It summarizes the whole thing in a few words:

  • China
  • illegal factory
  • fire
  • 34 dead

The rest is just syntax glue. But, as usual, I digress. What the hell is the point?

Just to be clear, by the way, the original breaking-news story in no way implies that this factory was producing for export, or for that matter, for any other company. So the story is just a lead-in for this post.

Back to the lead of this article: What is your obligation, as a purchasing company, to consider things other than quality, delivery, cost in your sourcing decision?

With the rush to source in China, it is very easy to overlook even obvious things like quality. Just ask Mattel. But if gross violations of China’s internal health, safety and environmental regulations give a potential supplier a cost advantage, do you know it? Do you make a conscious decision to let that “advantage” stand? Or do you go and look for yourself, and include only suppliers which comply with the letter and the spirit of the law – as well as “do the right thing?”

Chinese health, safety and environmental regulations, by the way, are in many cases stricter than what you find in the USA or Europe. Compliance and enforcement, though, is… ah… spotty.

This is, in my mind, an ethical decision, not a legal or financial one. I can only raise the question and let you answer it in your own mind.

One more thing. This was reported on the BBC. The only way I can read BBC news on the internet in China is to go through my corporate VPN. If you try to access BBC News on a normal internet connection, you will get a “Server not responding” error because BBC is not considered appropriate for the Chinese people to read. Frankly, it seems a little arbitrary since every other news service is more or less accessible. Maybe I will start another blog sometime and just talk about “other stuff.”

Adapt, Evolve

I encountered a new level of sophistication in comment spam engines today. This one actually hosts a “blog” of its own. The engine parses quotes from other blogs, posts them as comments in those blogs and links back to itself. On its host site, it looks like a “blog” but, in reality, it is nothing more than a link farm and host for Google ads.

I wrote a note to Google regarding a possible policy violation. In reality, I suppose I wouldn’t mind so much if it just posted things on its own site, but to make me deal with it, and have Google financing it, was a little much.

In an odd ironic twist, the spam filters are the dumb, but automated guardians and the spambots’ algorithms are created by clever people. In this war, people still win pretty much every time.

I suppose I can tie this back to my topic:

In spite of what some would want to believe, the Toyota Production System is not about blind execution of algorithmic standards. It is about continuous evaluation of those standards against a standard of perfection. It is shaped by people, but in ways which are unpredictable except in the macro sense.

As conditions change, the system adapts. As things break, it fixes itself. But all of this only happens if the organization actively works, every day, to ensure that people’s minds are fully engaged doing the right things, the right way.

The Seventh Flow

Those of you who are familiar with Shingijutsu’s materials and teaching (or at least familiar with Nakao-san’s version of things) have heard of “The Seven Flows.” As a brief overview for everyone else, the original version, and my interpretations are:

  1. The flow of people.
  2. The flow of information.
  3. The flow of raw materials (incoming materials).
  4. The flow of sub-assemblies (work-in-process).
  5. The flow of finished goods (outgoing materials).
  6. The flow of machines.
  7. The flow of engineering. (The subject of this post.)

A common explanation of “the flow of engineering” is “the footprints of the engineer on the shop floor.” I suppose that is nice-sounding at a philosophical level, but it doesn’t do anything for me because I still didn’t get what it looks like (unless we make engineers walk through wet paint before going to the work area).

Common interpretations are to point to all of the great gadgets, gizmos and devices that it does take an engineer (or at least someone with an engineer’s mindset, if not the formal training) to design and produce.

I think that misses the point.

All of those gizmos and gadgets should be there as countermeasures to real, actual problems that have either been encountered or were anticipated and prevented. But that is not a “flow.” It is a result.

My “put” here is that “The Flow Of Engineering” is better expressed as “The Flow of Problem Solving.”

When a problem is encountered in the work flow, what is the process to:

  • Detect that there even is a problem. (“A deviation from the standard”)
  • Stop trying to continue to blindly execute the same process as though there was no problem.
  • Fix or correct the problem to restore (at a minimum) safety and protect downstream from any quality issues.
  • Determine why it happened in the first place, and apply an effective countermeasure against the root cause.

If you do not see plain, clear, and convincing evidence that this is happening as you walk through or observe your work areas, then frankly, it probably isn’t happening.

Other evidence that it isn’t happening:

At the cultural and human-interaction level:

  • Leaders saying things like “Don’t just bring me the problem, bring a solution!” or belittling people for bring up “small problems” instead of just handling them.
  • People who bring up problems being branded as “complainers.”
  • A system where any line stop results in overtime.
  • No simple, on/off signal to call for assistance. No immediate response.
    • If initially getting help requires knowing who to phone, and making a long explanation before anyone else shows up, that ain’t it.
  • “Escalation” as something the customer (or customer process) does when the supplying organization doesn’t respond. Escalation must be automatic and based on elapsed-time-without-resolution.

Go look. How is your “Flow of Problem Solving?

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?”

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.

“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.

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.

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.

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.”

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.