A3 – A Process, Not A Form

Kris Hallan is a frequent contributor on the LEI forum at lean.org.
In this post, he outlines some great experiences with trying to implement the “A3 process” in his organization. Lean Forums – A3.

One thing that really drove home what goes wrong most of the time with the A3 process, and frankly, with most well-intentioned efforts to bring good analysis into organizations, was his experience of an early effort to try to “require” it without having the behaviors to back it up:

One of the worst things you can do is require an A3 be written and then allow a poor A3 to get past you. This has a tendency to happen when you put an A3 mandate on something that you don’t necessarily have control over. For instance, we started by requiring all CAPEX [capital expenditure – ed] projects to be proposed using the A3 format (hoping that the A3 thought process would come with the format).

What we got was a lot of projects summarized on A3s and virtually no feedback to go back and improve anything. No one learned anything from the process, no hanei occured, and nemawashi was non-existent. It became a box that everyone had to check. This can have a very detrimental effect on people’s attitude toward A3. Since they don’t take it seriously, they can’t really learn anything from it. I would say that this actually moved us backwards in our understanding of problem solving.

I could not agree more. I have seen this in other companies. This is PLAN-DO without the CHECK and ACTion. Set an expectation, go through the motions of compliance, but don’t ever bother to see if it is actually working the way that is expected.

The good news, further into his post, is that Kris’s organization figured it out and found that doing it thoroughly is more important (and quicker!) than doing it fast.

Andon Leadership

On a world-class automobile assembly line, the actual work is continuously being compared to the planned work. In each work zone, there is a planned sequence of tasks which are expected to produce a specified output.

If there is any departure at all from the planned sequence, if things get behind the planned timeline, if the necessary conditions are not there, if any process step does not complete as required then either the Team Member or an automated system turns on a help call – an andon.

The response is immediate. The first response is within seconds with a priority of clearing the problem. The line itself is still moving, but if the problem is not cleared before the end of the takt time the line automatically stops – things go from “yellow” to “red.” When that happens, the responsibility for the problem also shifts up a level in the response chain.

The priority is still to clear the problem quickly – and clearing the problem means to restore conditions required for safety and quality without compromise.

Once the problem is cleared, and the line re-started, the rest of the problem solving process engages to find the cause of the problem and address it in the system itself. If the problem is outside of the bounds, or outside of the capability, of the original Team Leader to solve, then his chain-of-support will engage to help him solve it so that his skills can be improved.

In summary – we have a sequence of tasks to be accomplished over about six hours that, in the end, will result in a car. That sequence of tasks is further broken down into sub-intervals where progress against the plan is checked. If problems develop, the system responds, swarms the problem to clear it, understand it, and adjust the process if necessary.

None of the above should be a surprise.

But what happens in your management monthly reviews?

Huh? How are management monthly reviews related to an assembly line?

Let’s see. In a reasonably functional organization the business plan is (or should be!) a series of tasks to be accomplished over a period of time that, in the end, will deliver specified results. That sequence of tasks is further broken down into sub-intervals where progress of the plan is checked.

But in a typical monthly review, the analogy ends there. When problems develop, the reasons are discussed, mentioned, and worked around. In dysfunctional organizations only the objectives are discussed, and in truly dysfunctional organizations the objectives themselves are adjusted to match what is accomplished.

Shift your thinking a bit, and apply the assembly line analogy to its end-state.

The monthly review is the fixed-stop position. Up to this point, the person responsible for the task “owns” it. He should be checking progress and ensuring that things are getting done as specified, and that the results being achieved are as anticipated (predicted). He should be monitoring conditions and making sure that the operating assumptions are holding. Ideally those checks are built-in to the process and planning so that they are at least semi-automatic.

If all is “green” going into the monthly review, then things are great.

But if something is “off” – yellow – that is equivalent to an andon call. The responsible person is that first-responder. He has until the next review to clear the problem. Think about the ramifications here. This means that if the reviews with the boss are every month, the responsible manager better not wait until the week before to find out what is happening so he can report on it. He has to stay in touch with what is happening.

The monthly review is the fixed-stop-position at the review, and the “andon” goes red.

The reviewing manager now “owns” the problem. His job is now to ensure that there are effective countermeasures in place to get things back on track. That does not absolve the responsible manager, but rather, this becomes a “check” and an “act” for his professional development by the more senior leader.

Again, think of the ramifications. The responsible manager must not only be in touch with what is happening, he also needs to make sure his people are being developed and pushed to fully understand the problems as they occur.

The job of these leaders, at each level, is not only to keep intimately in touch with what is going on, but also be fully aware of the skills, gaps and development of their people. If someone should be able to handle an issue, but can’t, that is a skill gap that, like any other gap, must be addressed (in this case by developing the person).

In mediocre organizations, professional development is owned and overseen by H.R. and may be tied to the annual review process. In organizations that “get it” professional development is a natural part of the leadership process, and happens at all levels in the natural course of getting things done.

One-off and Customization

One of the questions that comes up frequently in “lean” discussions is the issue of non-repetitive work. This is especially an issue with complex information processes such as bid proposals, estimates, etc.

While it is true that breaking down and understanding truly repetitive work is easier, the same principles apply to more complex tasks.

But first, I’d like to challenge some thinking. If you were to tell me that “every time we do this it is totally custom,” my question would be “If it has never been done before, why can’t everyone do it just as well as you?” What makes up your expertise? Why do your customers come to you?

I’ll answer: Because you know how to do it. Obvious, right? But that’s the point. You have experience, because you have done it before. You have a process of some kind. And you carry out that process to produce your customized product.

Further, you have some kind of idea of what a “defect free product” is. You understand what you want to accomplish.

Complex operations are built up from simple ones. The tasks that are done over and over are these simple operations. These simple operations are great sources of waste because (typically) no one ever examines them.

The idea that “lean” only works for repetitive processes is largely the fault of the “lean industry.” It focuses so much on takt time and removing waste that it has not, so far, gotten to the actual heart of what makes continuous improvement work.

In an ideal repetitive process running to takt time, there are a number of key ingredients.

  • There is a highly specified work sequence that calls out the content, timing, sequence and intended outcome of the work. EVERY time that work sequence is carried out, the actual content, sequence, timing and outcome is being compared to what was specified. ANY departure from the specified work (or result) is going to trigger some kind of immediate response to correct the immediate issue, and then start the process of problem solving to find the reason this happened. This is jidoka.
  • Although I mentioned timing above, the importance of time is elevated. Taiichi Ohno is quoted as saying “Time is the shadow of motion.” Ohno was a great student. The idea that it is important to study motion itself rather than focusing on time comes from the pioneer Frank Gilbreth. In application, by specifying how long each normal operation should take, and checking the actual timing, it is possible to detect when unplanned motions creep into the work. This is the purpose of takt time and work balance. It is no more, and no less, than a tool for verifying planned vs. actual so that action can be taken immediately if there is a difference.
  • There is a specified amount of work-in-process. Each piece has a reason to be there. There is some means of detecting any departure from that standard, and any departure triggers an immediate response to understand why.

As you scale up from a work cell to an entire factory, these mechanisms scale as well, but the principle is always the same:

  • Tightly specify what you expect to do, when it should be done, who should do it, where it should happen, and how it should happen.
  • Tightly specify (understand) the intended “defect free” result of each step.
  • Have a way to verify, continuously, that what you are actually doing (and when, who, where and how) matches what you planned.
  • If When you DETECT any departure from what you specified, STOP pretending you are still running to plan; FIX or CORRECT whatever got you off plan and get back on plan; then work to understand and SOLVE THE PROBLEM. This is how the organization learns and acquires what Deming calls “profound knowledge” of itself and its processes.

In a complex one-off situation, you might never carry out that plan again. But plan carefully, applying everything you know… all of your expertise. Understand the elemental tasks that you do all of the time. Understand how long each should take. Understand what result you should get at each step.

As you carry out the plan, if when there are unforeseen real world issues, STOP long enough to understand their impact and start asking questions. First, what must we do to get this back on track?

If someone had to improvise, why? What knocked him off the plan or process?

If someone had to finish up work he got from upstream, why? Was the specification for a “defect free” transfer vague? Does it need clarification?

This can go on, but the bottom line is that most organizations with complex processes expect their people to accommodate and cope with noise in the system. They say “every time is different, we can’t possibly plan that well.”

The ones who are getting better every day say “We should be able to plan this perfectly. Why couldn’t we this time?” In simply asking that question, they get better each time they do it.

So – in the context of the original question. When putting together a complex bid and proposal, there are (I presume) steps you routinely go through. This is so even if you are not aware of what they are. Study those steps. Study the intermediate products. Understand where one step ends and the next begins. Understand what must be present (information, resources, etc.) for that step to execute successfully. If, at any point, those things are not there then STOP and understand WHY. Don’t just ask the people who SHOULD have those things to go find them.

You wouldn’t have an assembler on the shop floor hunt down missing parts. Don’t have a professional engineer hunt down information he should have received.

Check, at each intermediate step, that it was done as you expect.

At the end of the process, check that the bid is what you want it to be. If it needs rework (meaning someone didn’t approve it), understand why, and work on what information the process didn’t have the first time through. Next time, get it right.

The proposal itself is packaging. It is also your first cut at the plan for execution.

If you get the bid, and execute your plan, any departure from what you originally proposed should be understood. Why? What happened? What didn’t you see coming? Some things are truly different, and you are only estimating. But compare your actual vs. your estimate so that next time you can do a better job estimating.

There will always be imperfections. The question is in whether the organization chooses to bury them in waste or learn from them.

Hospital Error – Heparin in the news again

Corpus Christi, Texas: Hospital error blamed for more infant overdoses – Yahoo! News

Key points of the story are:

  • 14 babies received heparin overdoses while in intensive care.
  • Two premature twins died, though it is unknown if this was the cause.

…pharmacy workers at Christus Spohn Hospital South made what the hospital called a "mixing error." The two workers went on voluntary leave.

The heparin, which was 100 times stronger than recommended, was given to 14 infants in the hospital’s neonatal intensive care unit on July 4.

As I have cited on previous posts, medication errors are one of the most common ways hospitals unintentionally injure or kill patients in their efforts to treat them.

I am reasonably certain that the two workers who went on "voluntary leave" (yeah, right) will absorb more than their share of blame as the system solves the problem by asking the "Five Who?" questions.

The article then goes on to cite a history of similar incidents in hospitals all over the country, though it is sometimes unclear in the writing if it is talking about this case or a previous one.

So what should happen?

First, determine where the actual root error occurred. If the manufacturer shipped mislabeled product, for example, then the problem happened THERE, not in the hospital. That isn’t to say we can’t do a better job in the hospital catching those things, but that isn’t the root cause in this case.

Any investigation should center on an assumption that the workers were operating in good faith, paying as much attention as can be expected of a normal human being, and were positive that they were doing this right. They did not want to injure or kill their customers.

Somehow, then, the process of mixing (either in the hospital or at the manufacturer) allows a 100x error to go by without SCREAMING for attention. And scream it must. Humans doing routine things in routine ways operate on an assumption that everything is routine until presented with overwhelmingly compelling evidence to the contrary.

Any hunt for "who did it" is motivated by extracting retribution rather than solving the problem. Once again, I refer the reader to the great work by Sidney Dekker on human error. We can all learn and apply it to everything that people need to do correctly – safety, quality, any other process or procedure.

Safety and Lean Manufacturing

This is a (belated) response to a post from Patsi Sells on The Whiteboard. She asked about safety and kaizen.

When first implementing some of the tools and mechanics of the TPS (especially in a manufacturing environment), many of the initial efforts seem to run afoul of the industrial safety professionals. My experience suggests a couple of basic causes.

  • Safety countermeasures are not seen as necessarily directly contributing to production of the product. Thus, they are often lumped in to “not value added” or “waste” – at least by implication, if not directly, by over-enthusiastic kaizen event leaders.
  • Safety professionals can be stuck on specific countermeasures vs. looking at the actual risk and identifying other possible countermeasures.
  • Safety professionals are concerned (and rightly so) about repetitive motion injury. They perceive that takt driven standard work might increase the risk of this.
  • There is overall a general lack of understanding of the difference between regulatory compliance and keeping people safe. While these two things overlap, neither is necessary nor sufficient to assure the other.

Let me start with the last point since it probably raised the most eyebrows.

An industrial safety program has two distinct and discrete objectives:

  1. To keep people from getting hurt.
  2. To comply with all laws and regulations

As I said above, while meeting both of these objectives are absolutely necessary, meeting the requirements of one does not guarantee meeting the requirements of the other. To put it more directly –

  • It is possible to be fully compliant with all health, safety and environmental regulations and still have a workplace which is extremely dangerous.
  • It is possible to have a very healthy, safe and environmentally friendly workplace and still run afoul of laws and regulations.

Thus, it is necessary to ensure that each of these things are discretely addressed in any successful program.

It is important for both kaizen and safety professionals to be aware of this. Some things are simply required by law, even if they are wasteful, and sometimes interpretation is up to the whim of a local inspector who might be having a bad day. Whatever the case, for each regulatory requirement there must be a specific, targeted countermeasure, just as there must be one for each physical risk. Sometimes these things overlap, but sometimes they do not, and that is the key point here.

I will digress for a paragraph and make this point however: If you have the basics of workplace organization in place, you make a much better first impression on a health and safety inspector than if the place is a mess. If your fire department sees the fire extinguishers are all where they should be and up to date, access aisles and evacuation doors clear, etc. he is more biased toward the assumption that you have your basic act together than if the place is a mess. Everyone has some violations, but when they are blatant, simple things it starts you off with a bad impression, and inspectors usually start digging.

Moving beyond simple regulatory compliance, the objectives of “lean manufacturing” and safety are 100% congruent. Ethically it is never acceptable to knowingly put people in harm’s way for the sake of production. At a more pragmatic level, a hazardous workplace will adversely affect quality, production, cost, delivery and morale. I will not descend to the level of cost-justifying safety simply because it isn’t necessary. But it is equally true that an unsafe workplace has higher costs than a safe one.

The good news is that the kaizen process is incredibly effective at dealing with safety hazards.

Moving up on the above list, one of the biggest places where the safety professionals can help smooth out the work is with their expertise in ergonomics.

What the kaizen people should take a little time to understand is this: Motions with poor ergonomics nearly always take longer than motions with good ergonomics. To put it a little more clearly: Ergonomic improvements are kaizen. Once a good team understands the difference between good and bad ergonomics, they can quickly see many small improvements which all accumulate.

By standardizing the method, we standardize the good ergonomics. Where there are no standard methods, the Team Members will each develop their own which may, or may not, be the safest way to do the job.

Standardizing the right motions reduces the chance of repetitive motion injury. And paying attention to why unusual motions are necessary comes back to reducing variation and overload (muri, mura) in the workplace.

At the next level up, standard work is your best friend.

To develop any process you first take a good look and specify exactly what result you expect to achieve.
Define a defect-free outcome.
Part of that definition is “perfectly safe.” No one is going to argue with this. Of course you want a process that is perfectly safe, and produces a defect free outcome. Who wants the opposite? But until “defect free” and “perfectly safe” are explicitly defined or specified, there may be room for interpretation. Do this before working on the process steps.

Next define the work you believe will deliver a perfectly safe, defect-free outcome. Define the content, sequence and timing of the work.

Now you have a specification for content, sequence, timing and outcome – the four elements of activity that Steven Spear called out in “Decoding the DNA of the Toyota Production System.”

Next – try it. Run the process exactly as you specified it. Verify two things:

  • That the Team Member can perform the process as specified – there is nothing keeping him from doing it.
  • That the Team Member actually does it that way and put in guides, controls, mistake-proofing where things go off track.

Check your results.
Was it perfectly safe? Did you see any risks? How are the ergonomics?
Adjust as necessary, then repeat.

Was the result defect free? How do you know? Is there a way for the Team Member (or an automatic step) to verify the result?

In practice, you are “trying it” and “checking the results” not just when you are developing the process, but every time it is done.

If a defect is produced at some point, then you know either:

  • The process didn’t work as you expected.
  • For some reason (which you don’t know yet), the Team Member did something different, or omitted a step.

Likewise, if the Team Member so much as skins a knuckle, you know the same things: The process is not perfectly safe or the process wasn’t (or couldn’t be) followed.

In most cases where the process was not followed you likely had a Team Member doing something in good faith to “get the job done.” This is the time to gently remind him that, when he can’t follow the process as designed, to please pull the andon and let someone know. Maybe you will have to make an exception to correct the current situation, but you HAVE to know if the process isn’t working or is unworkable.

Bottom line?
You get perfect safety exactly the same way you get perfect quality.
The methods and approach for getting it, and the methods and approach for correction and countermeasure are exactly the same.

Remember:
The right process produces the right result.

If you aren’t getting the result you want, then take a look at the process.

Chatter in an ISO Process

I have been in, or encountered, a number of organizations which had (or were working on) ISO-900x quality registrations. While I am fully aware of the intent of the ISO requirements, in the cases I have seen, the effect seems to fall well short of the goal.

On the surface, the types of processes mandated by ISO 9001 seem quite reasonable. They require knowing what your processes are, having documentation for them, and having systems that address problems to root cause.

The requirements are not a lot different from what I mentioned a couple of posts ago in Chatter as Signal. The example of the U.S. Navy’s nuclear propulsion operations would certainly meet the criteria (and then some).

So the question is:
What is fundamentally different about an organization with a “paper only” ISO certification that struggles with chaos every day vs. one which is truly process driven (whether they have an ISO certification or not)?

Chatter as noise.
Chatter as signal.

The Importance of Heijunka

My friend Tom poses an interesting question to production managers:

“If I ask you to produce different quantities and types of products every day, what quantity of people, materials, machines, and space do you need?”

Of course the answer is usually, at best, inarticulate and, at worst, a blank stare. There isn’t any way to know. Add to this the well-established research of the “bullwhip effect” which amplifies the magnitude of these fluctuations as you move up the supply chain, and it is easy to see the suppliers are really set up to fail.

Then he asks another question:

“If I ask you to produce the same quantities and types of products every day, or every hour, could you then answer the question?”

And, of course, the answer is that this is a “no brainer.” It would be very easy.

So the rhetorical question to ask is: Why does Toyota place such emphasis on heijunka?”
But my question is “Why don’t we all do it?”

Heijunka is a process of dampening variation from the production schedule. In English it is called “production leveling.” It comes in two steps:

  • Leveling the daily workload – smoothing out variations in the overall takt time.
  • Leveling the product mix within the daily work load – smoothing out variations in the demand from upstream processes.

Production leveling, however, is difficult, and the management has to have the fortitude to do it. Honestly, most don’t. They don’t like to deliberately set the necessary inventory and backlog buffers into place. So I’d like to explore some of the consequences of not doing it and then ask if these costs are worth it.

Consider this analogy.

Take a look at what modifications are necessary for a vehicle to traverse a rough, irregular road. The suspension must be beefed up, more power is required, the drive train is far more complex for 4×4. The road itself is unmarked, so the driver does not know where he is or where he is going without sophisticated navigation equipment.

Most of this additional hardware is actually unnecessary most of the time. But it might be needed, so it has to be there… just in case.

The driver of this vehicle is primarily concerned with what is right in front of the vehicle, and far less concerned about what is a mile (or even a few dozen meters) up the road. He will deal with that problem when he comes to it. Driving in this environment requires skill, training, experience, and continuous vigilance. People do this for recreation just for these reasons.

Now smooth out the road. Straighten out the hard curves. Give it some pavement. Put in signs so it is possible to navigate as you go. The same speed can be maintained by a vehicle which is lighter, has less power, a simpler drive system, a simpler suspension. Even though the engine is smaller, it is more efficient because it can run at a constant power output, the sudden accelerations are not necessary. Everything is easier.

The vehicle is much less expensive and much more efficient. The driver’s task is far simpler.

When you allow outside-induced variation to work its way through your system, you are putting potholes in the road. You are introducing sudden turns, sudden changes. Sometimes you are washing out entire bridges. People must be more and more vigilant and they simply miss more things. Their mental planning horizon shrinks to what they are working on right now, and maybe the next job. They certainly aren’t checking what they need tomorrow. They will worry about that in the morning.

The Effect on Materials

Even in the worst managed operations, people generally want to be able to provide what they are supposed to. They are motivated to be “good suppliers.” They also intrinsically understand that if they are idle (not producing) this is not good. Even if they are not provided with the tools and resources to do so, they will do the best they can to succeed – even if those things hurt the overall organization.

(I should note that most “management by measurement” systems actually encourage people to do things that hurt the overall organization, but that is another article.)

When these well meaning people encounter problems, they try to mitigate the effects of those problems with the resources they have available.

  • If their upstream suppliers do not deliver reliably they will add inventory so they have what they need.
  • Likewise, if their upstream suppliers do not deliver good quality, they will add some more inventory to make sure they have enough good material.
  • If there is quality fallout within their own process, they will add inventory and up production to cover that. By the way, that increase of production also increases the demand on the upstream suppliers, sometimes in unpredictable ways.
  • If their customers have irregular demand patterns, they will add inventory so the customers can have what they need, when they need it.
  • If there is batch transportation either upstream or downstream from them, they have to accumulate inventory for shipping.
  • If there are on a different shift schedule from either their customer or supplier, inventory accumulates to accommodate the mismatch.

Do you notice a theme here? The key point is: Without the system level view from their leadership, and without the problem solving support, all they can do is add inventory to cope.

Without leveling, any variation in demand will propagate upstream. At each step, two things happen:

  1. Processes that accumulate and batch orders progressively add to the amplitude of the variation.
  2. Irregularities within each process are added to the variation that comes from the customer.

By the time this hits your supply base, it is a tsunami. First the beach goes dry as it looks like the order base has dried up. (This is why you need to constantly reassure your suppliers with a forecast – because they can’t see regularity in your orders.) Then all of that water comes rushing in at once – and your suppliers can’t cope. Worse, they may have allocated the capacity elsewhere because they were tired of waiting on you. Lead times go up, things get ugly.

But even internally, all of this self-protection just adds more and more noise to the system.
So they add more and more inventory.

For a management team that is reluctant to deliberately add some inventory or backlog buffer to contain sources of variation and protect the rest of the system here is some news: Your people are already doing it, and in aggregate, they are adding FAR more inventory than would be needed with a systematic approach. They can only see the local problems, and each is just trying to be reliable – even if their efforts work in the opposite direction and actually introduce more variation into the system.

The Effect on People

I live in the Pacific Northwest of the USA. A fact of life living here is that, occasionally, the earth literally moves under our feet. I can tell you from experience that this is psychologically unsettling.

In our factories we do the same thing to people when the schedule changes every day. In the name of flexibility we shift requirements up and down. Add to that chasing shortages and hot list jobs around, and the daily work place is chaos. People are not sure if they are succeeding. Or, at best, they declare victory because they were not buried today.

Daily kaizen? That is just not going to happen in this environment. When you start talking about introducing flow, you threaten the self-protecting inventory buffers, and I can assure you that you will have a fight on your hands. Why? Because your people believe they need these buffers to get the job done – the job you want them to do. Now you are taking that away? Are you insane?

This is why it is critical to establish a basic takt as early as possible, then immediately start aligning the expectation to just meeting that takt.

Anything that keeps people from meeting takt becomes a problem and must be addressed. This is jidoka. Heijunka is a block in the foundation of the TPS “house” for a reason. Unless people are standing on solid ground, they can’t even consider anything like “just in time” or “stop and respond to problems” because they are spending all of their mental bandwidth just trying to figure out what is going on hour by hour.

Conclusion

When I was a military officer, we were trained in tactics designed to present our opponent with a constantly changing picture of what was happening. We wanted to inject as much confusion and uncertainty as possible. The mechanics of defeat on the battlefield are simple: The force subjected to this first shifts from action to reaction. They lose initiative, and therefore lose psychological control. Next the horizontal control linkages start breaking down. Each sub-unit starts to feel isolated from the others. They feel less a team and more on their own. Then, as more and more of their attention is shifted to self-preservation, the vertical chain of command breaks down. Each sub-unit is now mentally isolated and can be defeated in detail.

Ironically many factories are managed such that the workers on the shop floor are subjected to exactly these same conditions – and we wonder why they have a cynical view. We are defeating ourselves.

Chatter as Signal

As I promised, I am going to continue to over-play the afternoon my team spent with Steven Spear.

In his forthcoming book “Chasing the Rabbit” (to be published in the fall), he profiles what is different about those companies which seem to easily be increasing their lead against competitors when there is no apparent external advantage.

One of the core concepts he discussed was the nature of complexity in organizations, processes and products. It is the way this complexity is managed and handled that distinguishes the leaders from the pack of competitors that are fighting and jostling for second place.

In a complex system, there are invariably things people miss. Something is not defined, is ambiguous, or just plain wrong. These little things cause imperfection in the way people do things. They encounter these unexpected issues, and have to resolve them to get the job done.

This is “chatter” in Spear’s words. The sound made when imperfect parts try to mesh together.

Most organizations accept that they cannot possibly think of everything, that some degree of chatter is going to occur, and that people on the spot are paid to deal with it. That is, after all, their job. And the ones that are good at dealing with it are usually the ones who are spotlighted as the star performers.

The underlying assumptions here are:

  • Our processes and systems are complex.
  • We can’t possibly think of and plan for anything that might go wrong.
  • It is not realistic to expect perfection.
  • “Chatter is noise” and an inevitable part of the way things are in our business.

On the other hand, the organizations that are pulling further and further ahead take a different view.
Their underlying assumptions start out the same, then take a significant turn.

  • Our processes and systems are complex.
  • We can’t possibly think of and plan for anything that might go wrong.
  • But we believe perfection is possible.
  • Chatter is signal” and it tells us where we need to address something we missed.

We have all heard about Toyota’s jidoka and andon processes, so let me bring out another example, again, that was used by Spear.

The U.S. Navy has been operating nuclear reactors with a 100% (reactor) safety record for nearly (over?) 50 years. And they operate a lot of nuclear reactors. When they started, they were in totally new and unfamiliar territory – they were doing things that had never been done before. In fact, no one was even sure if it was possible.

They asked the question: How should this nuclear reactor be operated? They answered it with a set of incredibly specific procedures which everyone was expected to follow – exactly, without deviation in any way. These procedures represent the body of experience and knowledge of the U.S. Navy for operating nuclear reactors.

Here is the key point: ANYONE who departs from the procedure, in any way, no matter how trivial or minor, must report “an incident” which rockets up the chain of command. The reasons for the departure are understood. If there was something outside the scope of the procedure, the new procedure covers it. If something was unclear, it is clarified.

This may not be the Toyota Production System at work, but it is a version of something that makes it work: Jidoka.

If the process is not working, can not work, or conditions are not exactly as specified for the process to succeed, then STOP the process, understand the condition, correct it, restore the system to safe, quality operation, and address the reason it was necessary to do this.

Chatter is signal.

So – at a Toyota assembly line in Japan some years ago, I observed a Team Member drop a bolt. He pulled the andon cord and signaled a problem.

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.