Really Long Takt Times

One question I see coming up a lot in various forums is how to deal with issues unique to very long takt times. By “very long” I usually hear about many hours, sometimes days, occasionally weeks. Because it comes up fairly often, I thought I would take a shot at addressing it here.

I think the biggest hurdle for people to get over is the issues are largely the same as shorter takt times. They are just harder to see because the work starts to lose a human time scale. The trick is to get it back onto a time scale that people can relate to.

By this I mean that a person, generally, loses a sense of how long something is taking once it goes beyond a dozen minutes or so. In contrast, the stereotypical automobile line has a takt of about 60 seconds. Once an auto assembly worker loses 3 or 4 seconds of time, there is really no way she will be able to complete the programmed work cycle without help or stopping the line for at least a few seconds.

As work cycles get longer, though, the work remaining until “done” gets more and more disassociated from “now” and the idea of the necessity to maintain a particular work pace becomes abstract. This is less of a technical issue than one of human psychology. People, in general. tend to believe they can finish something in time long after that is no longer true. (Ask any college freshman working on a term paper.)

The countermeasure is the same as a manager would apply to any long project: milestones.

When the takt times are relatively short, the “milestones” are the takt intervals themselves. Each takt time signals a stage of work that must be complete. If this is not true, the line will (should) be stopped at that point. (Remember – “Never pass along a defect” and this includes incomplete work.) The problem will be corrected, and the cause understood. Oh – actually this is not quite true. A Toyota assembly line has the work zone divided into 10 sub-intervals, and the worker has a good idea what work should be completed at what point.

However, since most of us are likely just beginning – If your takt time is longer than a couple of dozen minutes, then, define the work in stages. In one operation I suggested the following:

Take about 85% of your long takt time, and divide that into quarters. Define what job should normally be complete by the time each of those check points comes up. As an example – if the takt time was 100 minutes, then determine the expected work completion at 20, 45, 65 and 85 minutes. Give the Team Member a way to know where he is at that point vs. the expectation, and a way to call for help if he is off by even a little bit. He should also call for help before that point if he is disrupted by something that he knows will cause a delay.

This is just a starting point to start to stabilize the system and build your support structure. If you reach the point where things are running smoothly at this level of granularity, then cut those time intervals in half.

At each point you will find more problems. The problems are likely to be smaller, but there will be more of them. All of those problems are sources of friction, and therefore wasted motion and time, on your system.

BUT – before you start down this road, have a few things in place first.

  • Establish credibility for the concept that you are genuinely doing this to see problems that are making the worker’s jobs difficult. If you use it, just once, to initiate a negative consequence for “not working fast enough” then forget it.
  • Actually work the problems. This means work them to eliminate the causes. Put in a process for managing the problems, make it visible so that the people working can see you are working on them. Again, this is to maintain credibility. If problems get recorded and sunk into a black hole (like a database in a computer somewhere), then you are not assuring the people on the line that you actually care.
  • Build your immediate responses (escalation) system. This mean team leaders (first responders) who can, and do, respond to help calls quickly. The only thing worse than having no way to call for help is to call and have no one respond. Again, the system loses credibility after about the third andon pull with no response.
  • Don’t worry too much about every detail within the work interval. The important thing, at first is to make sure that the same things get done within that interval. Detailed sequence standardization will come in time.

Summary: The key to managing really long takt times is to break the work into time-based intervals, and manage to those, rather than the entire work cycle itself.

A Systematic Approach to Part Shortages – Part 2

For kanban to work well, there has to be a solid foundation under it. That foundation is production leveling or heijunka.

Before I get to far into this, though, I would like to point something out: At the mention of leveling, people who are only just learning about kanban will point out all of the good reasons why leveling is difficult. Here is a key point: The problems caused by running kanban without good leveling pale in comparison to the total chaos that ensues if you try to run MRP without leveling. I’ll stay out of that little rabbit hole until another day though.

Production leveling has two parts.

  1. Leveling the production volume.
  2. Leveling the production mix.

The operation I described in Part 1 was relatively small, so it was a simple matter to set up a totally manual system to do this. By small I mean they had two major assembly lines running at a rates on the order of 10 units / day. The product was about the size and complexity of a medium to large-sized photocopier (though not a photocopier). The assembly lines had about half a dozen positions each. There were several hundred parts from about as many suppliers. (Different story.)

The objective in leveling volume is for the production line to see demand as an image of the takt time, and to protect that signal from variation in actual orders and shipping. At the same time, the shipping dock was to see deliveries to the finished goods buffer at takt time, regardless of minor and medium problems in production.

To accomplish this they separated the “big lump” of inventory that typically existed in shipping into two physically separate buffers.

The Withdrawal Loop

Customers, unfortunately, rarely order at takt time. The purpose of the buffer in shipping was to absorb this variation and make the actual demand appear as if it arrived exactly at takt. The organization also tried to take out some of the bigger spikes in customer orders by working with dealers to get more transparency into actual customer order patterns; as well as trying to level actual promise-to-ship dates at least weekly if they couldn’t get it to daily. That helped a lot. A more sophisticated order entry system would have worked better, but that luxury wasn’t in place yet.

Back to the buffers. Each unit in shipping had a withdrawal kanban card attached to it. As orders were released, a unit would be pulled from this buffer and shipped. The withdrawal card went back to the production control department. Those cards were placed in the inventory management box. This box had series of slots that indicated authorized inventory levels. A card in one of the slots indicated inventory we didn’t have, an empty slot indicated inventory on-hand.

There were limit markers at near each end of the row of slots. As long a the end of the row of cards stayed between those limit markers, everything was regarded as OK. They did not try to chase a particular level of inventory with production.

The scheduled production rate was 10 units / day.

Each morning Production Control would take 10 cards from their box and put them into the leveling box in shipping. That box had slots that corresponded to times of day. The cards were evenly distributed at the takt-time interval. As that time came up, shipping would take the withdrawal card from the box, go to the end of the production line, attach their card to a unit, and move it to the shipping buffer.

This seemed like a lot of trouble, but it served a purpose. It was to hide the irregularities of shipping schedules and actual order dates from assembly. They saw a clean, paced signal exactly at takt time. The process was designed so that assembly saw a perfect customer, even if the customers were far from perfect.

If management didn’t like the size of the shipping buffer, they knew exactly what problem(s) must be solved to reduce it – they needed to improve the dealer ordering and management processes so dealers would stop using deep reorder points and ordering weeks worth of product at once.

The Production Loop

When units were withdrawn from the end of the line, they were actual pulled from a FIFO buffer. In this case, the buffer held about 4 hours of production. Why? Most problems in production were cleared within that time. Only a bigger problem would starve the buffer and affect the withdrawal loop. Thus the purpose of this buffer was to make assembly appear as a perfect supplier to their perfect customer. They could supply exactly at the agreed-upon takt time.

Each of these units had a production kanban card attached to it. When shipping came to pull a unit, they would pull the production card and leave it in a kanban post. They would attach their withdrawal card and take the unit. Thus switching the cards transfers ownership of the product from one loop to the next. Since a kanban card authorizes a specific quantity to be in a specific location, if someone wants to take something somewhere else they need to attach a card authorizing them to do so. That was the case here.

The production cards went to the front of the assembly line. There were three slots there. One green, one yellow, one red. If everything was running smoothly, the card would go into the green slot, and when the next unit was started, the card would be pulled from the box and attached to the unit.

If the line were a little bit behind, there might still be a card in the green slot. Then the next card would go into the yellow slot. This would automatically signal the assembly manager that there was something that needed some attention.

The next card would end up in the red slot. This was the point when, if they weren’t already there for a known problem, they were in “line stop” mode. Anyone who could be helping to clear the problem should be helping to clear the problem. Why? The money machine has stopped running. Everyone is now being paid only because the shareholders are lending them money. The idea is to get the money machine running as quickly as possible, and it is the most important thing. This was a simple phased escalation process, and was part of their overall andon / escalation system.

Did it work?

All I can say is that it worked a hell of a lot better than what they were doing before. It took two or three serious tries to get this into place and keep it working, and they probably fell off the wagon a couple of times after that. There were always immense pressures to “reduce inventory” at the end of the quarter, for example, which would have management directing to starve out the shipping buffer, or push it out early. But, in general, when it was working, overtime was lower, things were more predictable, problems were identified very quickly.

But…

Yes, it looks like a lot of manual work involved. But I want to be really clear – the total time spent moving all of these cards around was a fraction of the time that had previously been spent investigating status, working action messages, making calls to find out what was happening, etc, etc. For some reason people seem to think that deliberate activities raise the total amount of labor involved, and that somehow, the time spent running after information and chasing problems is free.

Setting a standard and following it injects an element of stability and calm into an otherwise chaotic workplace. Once this basic foundation is in place it is far easier to improve overall efficiency because now there is an actual process to improve.

A Systematic Approach to Part Shortages – Part 1

The short story of assembly problems is lack of parts. Part shortages drive all kinds of waste, including: juggling the schedule; expediting; bigger lots or batches – and all of these things end up causing shortages later on in a self-reinforcing death spiral.

So how did an assembly shop which built about 10 units / day, and suffered between a dozen and 20 line-stopping part shortages a day end up eliminating all but a few (3-5) a week?

Three things, more or less at the same time. This post talks about the first:

Implement a kanban system to replace MRP ordering. They systematically studied how kanban is supposed to work, and, over a few months, put in a kanban system which I am proud to say was really pretty good. The assembly line was fed by kit carts which were picked at takt time from a small supermarket on the shop floor. The supermarket held a day or two of parts. The parts with local suppliers were replenished right from the receiving dock. Parts which had to still be purchased in larger quantities were stored in a warehouse area, and the shop floor supermarket was replenished from the warehouse daily.

The daily warehouse replenishment established the concept of isolating the problem. Their daily replenishment allowed them to set up the shop floor supermarket as if all of their suppliers were delivering daily.

All parts in the shop-floor supermarket and the warehouse were under kanban control. This means they had kanban cards physically attached to the parts (if they were separate) or the containers.

Some things they learned over time:

  • The rules of kanban state that the card should be pulled and placed in the post when the first part is removed from the container. The quickly learned this was far more likely to happen if they secured the card in a place where it was in the way of either opening the container (over the folding lid, for example) or had to be moved (e.g. picked up) to get the first part out. At that point the card is in the person’s hand and he has to put it somewhere.
  • The number 1 reason for lost cards was that “put it somewhere” was a pocket.
  • The number 1 reason why the card ended up in a pocket was that the kanban post was more than a step away from the place where the card was pulled. That meant the person put it in the pocket “for a second” while he got the parts.

In the above case the countermeasure was simple. Put kanban collection points everywhere where parts are handled.

  • The first time they tried putting a pull system in for parts ordering they hadn’t put in heijunka (production volume and mix leveling) first. That was a problem, and “problem” is an understatement.

The countermeasure was (obviously) to simultaneously implement a schedule leveling system to drive the upstream system at takt. More about that in Part 2.

  • They invariably had some parts where they had more than they needed.

The countermeasure was “black cards” (though I would have preferred bright orange cards) that signified “excess inventory.” These cards allowed them to maintain kanban control of all inventory, but they did not signal replenishment.

When a card was pulled, the shop floor coordinator would scan a barcode on the card. This scan triggered an order release to the supplier, and authorized the supplier to ship the indicated quantity.

Actual card from this organization being scanned.
Actual card from this organization being scanned.

They had agreements with the suppliers that there would be an email acknowledgment of the order within 2 hours. When the card was scanned, it was placed in a slot labeled with the time when the acknowledgment was expected. When (if) that time passed and the acknowledgment had not been received, the card went to the buyer who phoned the supplier. “Did you get my order? I need the acknowledgment within 2 hours like we agreed.”

This served two purposes. First, it verified receipt of the order and eliminated a known cause of shortages. Second it “trained” the suppliers that this time the customer actually expected them to honor the agreement. They really didn’t want that call from the buyer who had better things to do.

Once the acknowledgment was received, the card went to the receiving dock. Here it was placed in a slot that indicated the day (and later on, the time window) when those parts were supposed to arrive.

Like the above case, if the time passed, the card went to our poor hapless buyer. He phoned the supplier with a simple question: “Where’s my parts?”

This reinforced that, once again, there was an expectation to honor agreements. They really didn’t care that much (at this point) what the supplier’s lead time was. Only that it was honored. The main objective when starting out was simple consistent execution.

When the parts came in, the card was retrieved, matched with the order to verify, then scanned again to trigger a receipt transaction. If there were exceptions – guess what – another phone call.

The card was then attached to the container. Since the card specified the storage location, put-away was fairly straight forward. No location lookups required.

The previous condition had been that there was no matching of receipts against expectations. Thus if parts were late, or didn’t show up at all, no one noticed until they ran out. Big problem. By trapping and surfacing problems at the two main failure points in the system, most of those problems went away after a few months.

For the purists who are reading – yes, this process has some compromises and probably is a bit obsessive on checks. Call those training wheels until there is a sense of balance. All I can say is that it worked and, in the long run, ended up to be a lot less work than chasing down and expediting shortages all day.

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?

“Sticky” Visual Controls

The textbook purpose of visual controls is “to make abnormal conditions obvious to anyone.” But do your visual controls pass the Sticky test, and compel action?

Simple: Does your control convey a single, simple message? Or does it “bury the lead story” in an overwhelming display of interesting, but irrelevant, information. According to Spear and Bowen (“Decoding the DNA of the Toyota Production System”) information connecting one process to another is “binary and direct.” The signal is either “On” – something is required of “Off” – nothing is required. There is no ambiguity.

Take a look at some of your visual controls. Do they pass the test? Do they clearly convey that something needs attention, or is that fact subject to interpretation?

Unexpected: Why would a visual control need to be “unexpected?” Consider the opposite. Who pays attention to car alarms these days? Yes, they are annoying, but because they so often mean nothing, nobody pays attention to them. We expect car alarms to be false alarms. If your visual control is to mean something, you must respond each time it tells you to. If it is a false alarm, you have detected a problem. Congratulations, your system is working. But it will only continue to work if you follow-through: STOP your routine; FIX or correct the condition; INVESTIGATE the root cause and apply a countermeasure. All of this jargon really means you must adjust your system to prevent the false alarm. Failure to do so will render the real alarm meaningless. It will “Cry Wolf” and no one will take it seriously.

Concreteness: Is it very clear? Do people relate to what your visual control is telling them? Does the Team Leader know that the worker in zone 4 needs help, and that the line will stop in a few minutes if he doesn’t get it?

Credibility: If the condition is worsening, does your visual control show it? Does it warn of increased risk? A typical example would be an inventory control rack with a yellow and red control point on it. Yellow means “Do something” Red means “You better start expediting or making alternate plans because you are going to run out.” Setting the red limit too far up, though, sends out false alarms (see unexpected), and eventually everyone “knows” the process can eat a little into the red with no problem. Why have yellow? What visual control can you put at the yellow line that tells you someone has seen it and is responding to the problem? (Left as an exercise for the reader.)

Emotions: How does your visual control compel action? Does it penetrate consciousness? A few words of warning on an obscure LCD panel aren’t going to mean very much unless someone reads them. How do you get the attention of the person who is supposed to respond? “He should have paid more attention” is the totally wrong way to approach missed information.

Stories: I really connected with this one. Stories are a great way to teach. Simulations are interactive stories. When teaching the andon / escalation process in a couple of different plants we divided the group into small teams, gave them a real-life defect or problem scenario and had them construct a stick-figure comic book that told the story of what would happen. That has proven a great way to reinforce and personalize the theoretical learning.

I will admit that these analogies can be a bit of a stretch, but the real issue is there. Visual controls are critical to your operation because they highlight things that must compel a response.

Your system is not static, or even really stable. It is either improving continuously through your continuous intervention, correction and improvement based on the problems you discover; or it is continuously deteriorating because those little problems are slowly eroding the process with more and more work-arounds and accommodations.

Go to your work area and watch. What happens when there is a problem or break in the standard? What do people do? Can they tell right away that something is out of the ordinary? How can they tell? For that matter, how can you tell by watching? If you are not sure, then first work to clarify the situation and put in more visuals. That will force you to consider what your standard expectations are, and think about responding when things are different than your standard.

Hidden Negative Consequences

“Stop the line if there is a problem” is a common mantra of lean manufacturing. But it is harder than first imagined to actually implement.

The management mindset that “production must continue, no matter what” is usually the first obstacle. But even when that is overcome, I have seen two independent cases where peer social pressure between the workers discouraged anyone from signaling a problem. The result was that only problems that could not be ignored would come to anyone’s attention – exactly the opposite of the intention.

Both of these operations had calculated takt time using every available minute in the day. (Shift Length – Breaks etc.) Further, they had a fairly primitive implementation of andon and escalation: The line stop time would usually be tacked onto the end of the shift as overtime. (The alternative, in these instances, is to fall behind on production, and it has to be made up sometime.)

So why were people reluctant to call for help? Peer pressure. Anyone engaging the system was forcing overtime for everyone else.

Countermeasure?

On an automobile line, the initial help call does not stop the line immediately. The Team Leader has a limited time to clear the problem and keep the line from stopping. If the problem is not cleared in time, the problem stops the line, not the person who called attention to it. This is subtle, but important. And it gives everyone an incentive to work fast to understand and clear the problem – especially if they know it takes longer to clear the problem if it escapes down-line and more parts get added on top.

There are a number of ways to organize your problem escalation process, but try to remember that the primary issue is human psychology, not technology.

Hoopla – Another Quality Story

As I said in a previous post, I am spending the majority of my time in China right now.

As part of his preparation for attending a corporate class, one of my kaizen specialists was reviewing some of the training materials. From the other side of the cubicle wall he asks “What is ‘hoopla?” Although his English is very good, he is Chinese, and “hoopla” just isn’t a word that they teach in the universities.

Now I know for sure he is not the first non-native English speaker to read that material, and I also strongly suspect many before him did not know what “hoopla” means. But the others just made a guess from the context and kept reading.

Derrick, though, applied the first two steps of jidoka – he Detected a problem – something wasn’t right, didn’t meet the standard, or seemed to be in the way. Then he Stopped the process, and called for assistance. Instead of guessing what to do, the Team Member pulled the andon (got his Team Leader’s attention) and pointed out the problem.

The standard in this case is that the person reading the material can understand it, or at least understand the words that are not specifically being explained by the material. In this case, that didn’t happen. “Hoopla” was not understood, so the andon was pulled.

The third step is Fix or correct the problem, restore the standard (without compromising safety or customer quality in any way) and re-start the process. I explained what “hoopla” means, and Derrick could keep reading.

The fourth step is Investigate the Root Cause, Apply a Countermeasure. I sent an email to our training developer and mentioned what has now become “the hoopla incident.” The ensuing discussion among the training developers has resulted in a set of standards and guidelines for writing materials. Among other things, it calls out the need to avoid idioms and slang that might not be understood by non-native speakers. It also addresses other issues which will both make the materials easier for non-native speakers to read and make it easier for translators working to port the material to German, French, Spanish or… Mandarin.

W e should have some hoopla! The process worked – all because someone called out something he didn’t understand instead of just dealing with it on his own.

The Chalk Circle – Continued

Yesterday I wrote a little about my own experience with Taiichi Ohno’s “chalk circle” as well as some stories I have gathered from others during the years.

Although the insights I got from Iwata-sensei changed my perspective, it was some years later that a few other things got solidified.

My colleagues and I had been hired as a team of “experts” to help a major household-name company implement “lean manufacturing” into their production and logistics processes.

A couple of years into the effort, it was still a struggle.

Although there were a lot of kaizen events happening, it was a continual battle to sustain the results. We were quickly reaching the point where 100% of our effort would be expended simply re-implementing areas where we had already been. That is the danger point when forward progress stops and the program stalls.

Of course we were busy lamenting about the “lack of management commitment” to support and sustain the great work these teams were doing.

The next week we were around the table trying to figure out a countermeasure.

First we had to understand the problem.

As we talked and shared, we discovered that each of us had one area, a single operation, that was showing better results than the others. Operationally, these areas were actually quite diverse. What did they have in common?

Each of them was the area under our respective responsibility that had the weakest or no internal infrastructure for kaizen events. In fact the most successful implementations were happening in the operations that held the least number of week-long kaizen events.

Needless to say, that realization was interesting. So what else did they have in common?

Because we did not have our internally trained people leading kaizen in those areas, we were coordinating and leading the effort personally. One of us, not someone we had trained, was guiding those areas through their implementation.

Why were our results different than the people we trained? What did we do differently?

As we talked, we found that we all would take the line leaders, the managers, the people responsible, to their shop floors, and teach them how to spot problems and what to do about it.

We would stand with them, observe something happening, and ask “What do you see?” We would continue to ask questions until they saw the things that we did. Then we would begin asking about causes. “Why does this happen?” Our objective was to teach the leaders to be intensely curious about what was going on, to compare what they saw against a picture in their mind of an ideal state, and further be curious about why there was a difference.

We paid attention to progress, focused their attention into areas that needed work, and always, constantly, asked questions.

  • “What is supposed to be happening here?”
  • “What is really happening?”
  • “Is that really what you want?”
  • “Why is there a difference? What is in the way?”
  • “Does the Team Member know what to do? How do you know? How does he learn?”
  • “Is this process on track? How can you tell?”
  • “How many are supposed to be here? Why are there extras?”
  • “Why is no one working here? Where did they go?”

Not because we wanted answers, but we were teaching them the questions.

These are the same questions that Iwata-sensei was asking me years earlier.
It was an insightful and team-building moment when we realized that, in spite of our diverse backgrounds (we had not met prior to working here), we all approached things pretty much the same way. The second insight was that, in spite of our diverse backgrounds, we had all learned pretty much from the same teachers, and those teachers had been taught directly by Ohno.

If a line leader “got” what we were trying to get across, they wouldn’t ever see their operation the same way. They would be constantly comparing what they saw (what is actually happening) against some kind of expectation or standard — explicit or implicit — or against an ideal state (what should be happening).

They would see any gap between what should be happening and what was actually happening as a problem to be addressed and at the minimum, corrected.

They would begin to ask different questions of their people, and manage activities toward identifying these gaps and closing them.

Our question to ourselves was: If this worked so well, what did we have everyone else doing?

When we asked this, Dave stands up and starts through his certification program to teach his kaizen leaders how to

  • Present the various training modules
  • Prepare the various forms and reports
  • Organize kaizen events

Then someone, I don’t remember who, asked “Who is teaching the leaders how to manage the new system?”

A long pause followed.

Then Dave said, “oh shit.”

Maybe Dave said it, but we all thought it.

We had started happily blaming the leaders. Then we realized no one was teaching the leaders. THAT was our fault. We weren’t teaching anyone to teach the leaders. Now the question was “What do we do about it?”

Now we understood the current condition and the gap we needed to close.

The Essence of Jidoka

SME: The Essence of Jidoka – dead link

You can download it here.

This link is to an article I wrote for the SME online “Lean Directions” site back in 2002. I am including it on this site for the sake of completeness. I noticed that the Wikipedia article on the same subject is largely derived from this, which I simply consider flattery.