“Management Resistance” or Poor Process?

At leanblog.org, Mark Graban recently posted about the latest State of Lean survey from the LEI. His observation is that the survey seems to be a search-for-blame (looking for the sources of resistance) rather than focused on root cause for the resistance itself. Following a couple of links in that post takes us back a year to his comments on the 2007 survey, and then to an attempt to go through 5 Why’s.

I just took the survey myself, and felt the same way. It is really easy for the “lean guys” to cite “management resistance” as a root cause. Certainly there are instances when local leaders are outwardly hostile or passive-aggressive about the proposed changes. But I’d like to explore this a bit.

Just as it is easy to blame the Team Member’s inattention for an accident or a defect, it is easy to blame leaders for failure to embrace the kaizen culture. In both cases, though, the kaizen culture itself mandates exhausting every other possibility before we shift our focus from “process” to “person” as the problem. And even if “person” ends up in the chain of causes, again, the kaizen culture demands that we ask “Why?” a few more times and try to get to the reasons why a person behaves the way he or she does. Although not put quite in these terms, these are people principles which have been taught since the early 1940’s as part of TWI Job Relations.

Back last July I related a story in “The Chalk Circle – Continued” where the “lean leaders” of a large company were busy blaming management non-involvement for the continuous backsliding we were experiencing. At the end of the story, Dave’s “oh shit” comment sums it up when we realized that the last “Why?” in our chain pointed, not at the leaders, but at us. The way we got there was (by accident) staying on a “process” path in our discussions.

Since then I have learned a few things, but I think the basic message still stands.

First, I’d like to propose to re-frame the problem because I think “leader resistance” is pejorative. I’d like to go through a series of questions. The first is getting a little more clear on what, exactly, we are asking of these leaders. Accepting that the opposite of “resistant” is “engaged” for the purposes of this discussion:

What do “engaged leaders” do?
Without a clear picture in our heads as an answer to this question, we cannot develop effective countermeasures. Honestly, I don’t think there is a strong consensus out there. I can go into why that is, but it is a topic for another (lengthy) post.

Suffice it to say that we need a working definition. I was going to render an opinion here, but I decided instead to drop the question into the LEI site’s forums, and see what others think. (If you are not a member you will have to register first, but that is no big deal.)

You can also leave a comment here.

After I see where people are going, I’ll ask another question.

The Paper Shuffle

This post is in response to Ethan’s post on “The White Board.” He asked about the paper shuffle – admin processes.

This seems to be a hot topic today. First, because these techniques are increasingly being applied to operations that don’t do manufacturing. They are service delivery, information processing, and creative processes instead. And second, I think, because manufacturing companies are realizing that these paper (or information) processes are often the ones that cause havoc on the shop floor.

Many consultants (and others) like to differentiate between “manufacturing processes” and “non-manufacturing” or “administrative” (or “office”) processes and say that there is a fundamental difference in how these types of processes need to be approached.

They go so far as to produce separate products and methods for “administrative kaizen.” Part of this, I suppose, is sales and marketing. But part of it is, I think, a sincere belief.

Ironically, these same people are (usually) cheerfully adamant that there is no fundamental difference in approach for kaizen between custom circuit boards and airliners. They are right about this. But I question whether 747’s and circuit boards are less different than lawnmowers and insurance claims.

I do believe that, in most cases, there has not been a lot of thought applied to what administrative processes are actually trying to accomplish, nor exactly what tasks are required to do it. But this isn’t something that makes administrative kaizen unique, it just requires a bit more work up front.

The First Questions

These questions should really be asked for any kaizen activity. For this process:

  1. What is the intended outcome?
  2. How is the actual outcome checked?

To paraphrase, what, exactly, does the customer expect? How does the customer expect it? When does the customer expect it? Where?

and.. how do you verify that what you delivered, how you delivered it, when you delivered it, where you delivered it, and exactly match what the customer expects?

Answering these questions gives you the definition and confirmation criteria of a “defect-free outcome.” If you don’t have answers to these questions STOP, because you will have no way to know if your process works or not.

The Second Questions

  1. What tasks need to be performed, in what sequence, to assure the defect-free outcome (defined above) is produced?
  2. As you perform each task, how can you check that it was done as expected, in the sequence expected, in the time expected?
  3. As you perform each task, what is the expected result of that step and how do you check that you got it?

In other words, just what is required to just meet the customer’s exact requirement? This is the “just” of “just in time.” (At least part of it.)

The Third Question

What conditions are required for the process to succeed?

What information, tools, materials, environment, skills, software, hardware must be present?
If a manufacturing process, what is air pressure required for your tools to run to the proper torque?
What information must be present for the approval process to evaluate?
What parts are required?
What forms must be signed? By whom?

In a larger sense, this question defines what your process needs from its suppliers. Again, “just” what is needed? “Just” when is it needed?

Between these three sets of questions you have (hopefully) defined an ideal. Your actual process might not come anywhere close to the ideal, but until you think through what is necessary, there is really nothing compare to. You could look at your current process and say “this is pretty bad” (or “pretty good,” for that matter) but I ask “Compared to what?” and that comparison is vs. the ideal.

It is certainly true that (usually) manufacturing processes are further along with these answers, but that doesn’t mean they are fundamentally different.

What about one-time processes?

There is no such thing.
“What? Is he crazy? We have to customize every time!”
Yes you do customize. But if what you did was totally unique and had to be created from scratch each time, then you are claiming you have no experience in your field. Even something as uniquely complex as a building construction project or a tailored treatment plan for a cancer patient, still has answers to the above questions. There is some outcome you are trying to achieve, and you really ought to know what it looks like. And you construct a specific sequence of tasks which you believe will get that done. And those sub-tasks are all things you already know how to do, or have a good idea what to expect when you try them. You still have (or should have) a verifiable outcome, and your best estimate of what is required for success. You may answer these questions every time, but you still answer them.

What Kind of Process?

Your improvement approach depends a little on the nature of the process. This has less to do with “manufacturing” or “non-manufacturing” than it has to do with the nature of the variation drivers.

Is largely repetitive?
A surprising number of administrative processes fit into this category. Almost all accounting transaction processing does. So do order entry, insurance claims, medical records updating, routine approvals (contracts, loans, etc), and preparing routine reports. Those are just the ones that come to mind right now.

What makes them seem different from “manufacturing” processes is that no one has ever really thought of them as repetitive. But once people grok that these tasks are mostly doing the same thing over and over, then just about every trick in the manufacturing kaizen book directly applies.

Here are a few things to keep in mind:

A lot of repetitive process are buried in noise. People do not have what they need, so they have to go on safari. In manufacturing it is possible to see this happening because the Team Members usually have to stop working and go looking. But administrative people do their hunting and gathering from their desks, so they (and their leaders) are often unaware that they have “stopped working” – but they have. They just look like they are working. The process feels irregular because the hunting and gathering gets mixed in with the “doing.”

In manufacturing we say “do not launch the job until the parts are available.” The solution is the same in admin – a front-end process of triage.

Triage is a term from the medical community. In a largely repetitive administrative process, the idea is to ensure the people have what they need before they start. A quick assessment of the documents can quickly divide incoming requests into three categories:

  1. Everything needed is here, it is routine. Drop into the work queue.
  2. It is routine, but incomplete. Finish the information gathering first. Do not send it to the work queue until it is complete and routine.
  3. This is a true exception. Process it off-line, not as part of the routine work.

Consider the alternative. Most of the packets can be processed in an hour. But if one is incomplete, there is another hour or two of research, interruptions, information gathering to do. While that one is being worked on, there are two more routine ones that are not getting done. Every time the process is interrupted, more work falls behind.

A true exception that takes two days, meanwhile, stalls 16 routine ones.

By separating the routine from the non-routine, you allow at least part of the process to stabilize. With stability comes standardization, and with standardization comes kaizen opportunities.

Is is truly non-repetitive?
If you apply the thinking described above, surprisingly few processes drop into this category. But there are true exceptions. Preparing complex bids and proposals, true research and design, some trials and tests, and true creative work come to mind as some possible examples.

Nevertheless, “the questions” that I posed at the beginning still apply, and the better you ask them, the more clear you are.

In the end, you want to have a plan. This consists of:

  • A defined, verifiable outcome. A definition of “success.”
  • A defined series of verifiable tasks, listed in a specific sequence, with expected timing.

To put the same thing in the terms used in “Decoding the DNA of the Toyota Production System” – your activities are “Highly specified in terms of content, sequence, timing and outcome.” Further, you have checks on execution (content, sequence, timing) and checks on the outcome.

What’s the point? Kaizen is a process of applying structured learning.

In both of the above cases you have defined what you are going to do, and defined what you expect as a result. You are checking to see if what you actually do differs from what you planned to do; and you are checking to see if your actual result differs from the expected result.

When you see a difference STOP. Does this mean literally stop in place? Sometimes, but usually no. But it does mean to stop pretending you are still following the plan as intended, because you aren’t. You are now processing an exception to the plan. This simple consciousness is the first step in learning.

Why did the Team Member have to depart from the plan? Maybe there was something you didn’t think of. Maybe you designed a process that is actually impossible. Maybe there is a vital tool, fixture, part missing. Maybe information is missing or wrong. Whatever it is, see it, fix it, understand why it happened and then fix that.

What Makes Administrative Kaizen Hard?

The “Big Picture” is often invisible.
Many administrative processes involve a lot of complex interconnections. Nobody ever designed them, they just morphed into what they are as local people tried to deal with the effects of system problems. Since there is no real architecture, it is probable that nobody actually knows how the whole things works, or understands the unintended consequences of local countermeasures that cause problems elsewhere. (A disturbing percentage of corporate information systems follow the same general architecture.)

Countermeasure
There are two broad approaches. The first is to decide that whatever is the current process, it is too complex and too broken to fix. Start over. Honestly, I think this isn’t done often enough. Go through the questions listed above and systematically engineer how things are supposed to go.

The other (and more common) approach is to try to fix it. That means:

  • Thoroughly understanding how it works today.
  • Looking for:
    • Ambiguity – places where people are unsure what is expected.
    • Breakdown – places where there is a difference between what you expect (should happen) and what really happens.
    • Rework – places where people have to fix something that should have been done differenty.
    • Overprocessing – places where people are doing, again, something that has already been done. (Data entry is notorious for this… re-entering information that is already in the computer.)
  • Systematically addressing these issues starting at the customer end and working your way back.

Most “kaizen events” stop at this point, and they fail to anchor the improvements. Again, this is not unique to administrative processes, but it is much easier to omit this step, and much harder to see the consequences.

The vital step is, as you define what should be happening, to also put in those “checks.” Any departure from your specified outcome, or your specified process to produce that outcome, is a “problem” and problems must be identified and corrected immediately; then they must be understood. The learning gained must be applied to make the process itself more robust.

At the end, administrative kaizen is exactly the same as manufacturing kaizen, but most of us do both badly, and manufacturing kaizen is more tolerant of a poor approach. This, I believe, is why many people think the two are fundamentally different.

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.

Attack on Ambiguity

When real effort is spent getting to the cause of problems (vs. a reflex to find someone to blame), ambiguity often enters into the picture.

Problem solving is a process of asking questions and clarification.

Is a “defect-free” outcome of the process specified? Does the Team Member know what “success” is?
Is there a way for the Team Member to actually verify the result?
Does that check give the Team Member a clear Yes/No; Met/Not Met; Pass/Fail response? Or is there interpretation and judgment involved?

If there is good specification for “defect-free” – is there a specification for how to achieve it? Do you know what must be done to assure the result that you want? Does the Team Member know? Is the Team Member guided through the process? Are there verifications (poka-yoke, etc) at critical points?

If all of the above is in place, do you know what conditions must be in place for success? What is the minimum pressure for your air tools? Is there a pressure gage? Does it cut off the tool if the pressure is too low? Is there some visual check that all of the required parts, pieces, tools are there before work starts? Thank about the things you assume are there when the Team Member gets started.

For ALL OF THE ABOVE, if something isn’t right, is there a clear, unambiguous way to alert the Team Member immediately?
Is there a clear way for the Team Member to alert the chain-of-support that something isn’t right?

If there is a defined result, a defined process to achieve it, and all of the conditions required for success are present –
Is the Team Member alerted if he deviates from the specified process, or if a critical intermediate result is not right?
More poka-yoke.

Now you have the very basics for consistent execution.

Is the process carried out as you expect?
Is the result what you expected?

If not, then the process may be clear, but it clearly does not work. Stop, investigate. Fix it.

All of this is about getting more and more about what is SUPPOSED to happen and compare it to what is REALLY happening… continuously. I say continuously because “continuous improvement” does not happen unless there is continuous checking and continuous correction and problem solving. If you want “continuous improvement” you cannot rely on special “events” to get it. It has to be embedded into the work that is done every day.

Ask “Why?” – but How?

Get to the root cause by “Asking Why?” five times.
We have all heard it, read it. Our sensei’s have pounded it into us. It is a cliché, obviously, since getting to the root cause of a problem is (most of the time) a touch more complicated than just repeatedly asking “Why?”

Isn’t it?

Maybe not. Maybe it is a matter of skill.

Some people are really good at it. They seem to instinctively get to the core issue, and they are usually right. Others take the “Problem Solving” class and still seem to struggle. So what is it that the “naturals” do unconsciously?

Let me introduce another piece of data here. “Problem Solving” is taught to be an application of the scientific method. The scientific method, in turn, is hypothesis testing. How does that relate to “ask why? five times” ?

Each iteration of asking “why?” is an iteration of hypothesis testing.

How do you “ask why?”

Observe and gather information.
Formulate possible hypotheses.
For each reasonable possibility, determine what information would confirm or refute it. (Devise experiments, which really means “Decide what questions to ask next and figure out a way to answer them.”)
Observe, gather information, experiment. Get answers to those questions.
Confirm or refute possible causes.

At each level, a confirmed cause is the result of “observe and gather information” so the process iterates back to the top.

Eventually, though, a point is reached where going further either obviously makes no sense, or is of no additional help. If you are now looking at something you can fix, you are at the “root cause” for the purpose of the exercise. Yes, you can probably keep going, but part of this is knowing how far is far enough.

Is this something I can fix easily?
Does it make sense to go further?

Otherwise, iterate again.

Now: Devise a countermeasure.

A countermeasure, itself, is a hypothesis. You are saying “If I take this action, I should get this result” i.e. the problem goes away.

Put the countermeasure into place. Does it work? That is yet another experiment only now you are (hopefully) confirming or refuting your fix on every production cycle. The andon will tell you if you are right.

We tell people “Ask why five times” but we really don’t teach them how to “ask why.”

The book examples usually show this neat chain of cause/effect/cause/effect, but the real world isn’t that tidy. When the problem is first being investigated, each level often has many possibilities. Once the chain is built then the chain can be used as a check.

But that isn’t how you GET there.

Why don’t the books do a good job teaching this?

“They” say that critical thinking is difficult to teach. I disagree. If the people who do it unconsciously can step back and become consciously competent, and know how they do it, then it breaks down into a skill, and a skill can be taught.

A Real World Example
My computer works, but it’s network connection to the outside world doesn’t.
OK. What could be wrong?
It could be software in the computer.
It could be a problem with the hardware.

Look at where the cable plugs into the back of the computer. Are the little lights flashing? No? Then there is no data going through that connection.

How could that be?

Well.. the it could be a problem in the computer or operating system.
It could be a problem with the hardware in the computer.
It could be a bad cable.
It could be a problem behind the network jack on the wall.

The QUICKEST thing to do is unplug the cable and plug my co-worker’s cable into the computer. (Please make sure he isn’t busy with email before you do this!). Do the lights come on? Yes? Does your network stuff work now? Yes? Then it isn’t anything in the computer. You have just done a hypothesis test – conducted an experiment.

Take his KNOWN GOOD cable out of the wall and plug it into your jack. Does your network work now? Yes? You have a bad cable. No? It is a problem behind the jack.. call I.T. and tell them. (unless you are at home, then head to the little blue box in the basement and start looking at flashing lights down there. But same process.. as you systematically eliminate internal causes, you are left with an external one.)

This is a natural flow, but most people wouldn’t describe it as “asking why?” or “hypothesis testing” – and the big words scare them off.

Still – when you (the lean guru) are teaching others, it is important for them to understand HOW TO ASK WHY is just a process of learning by systematic elimination of the impossible. (Whatever remains, however unlikely, must be the truth – Author Conan Doyle through Sherlock Holmes)

The Value of People

How can some companies not only survive, but thrive when operating in “high cost labor” areas, while others are struggling even as they are busy chasing the lowest possible costs?

I would like to suggest that one key difference is the attitude toward people. On the one hand is the “people as cost” model. This model usually has a couple of built-in assumptions.

  • The number of people required to do a particular task is fixed, often against some kind of earned-hours standard.
  • The cost driver is wages, salaries and benefits.

On the other hand is the (seemingly) rare organization that truly believes that people are their strength, or the well worn out “our greatest asset.”

The assumptions which are required for this belief are:

  1. People’s net productivity can always be improved.
  2. The cost driver is the amount of time wasted coping with all of the small problems that keep things from going perfectly.

The above assumptions, of course, are anchored in a faith-based position that perfection is possible. (see “Chatter as Signal“)

So… what kinds of actions to each of these two models drive?

The first one – people are cost – says to find the cheapest possible labor and hire it. Since factory wages in China are (right now) running about 1/12 or less of those in the USA or Europe, that seems a logical choice. Here’s the rub.

You can outsource the entire job to another company – give the work to the lowest bidder. Now, if you truly believe that the amount of labor is fixed, and that only lower wages can change cost, then this is the obvious choice. You are relying on your superior supply chain management system to ensure you select a supplier that can maintain, and maybe even improve, the quality they deliver, plus hold the line against increases in materials, energy, and their own labor costs. In short, you are looking for a supplier who believes the opposite of what you do. Your ideal supplier knows they can bid aggressively, get your work, and then improve their profit position by applying continuous improvement.

Or you can export the production and set up your own operation in a “low wage area.” You are shifting your core beliefs about people to another culture, and another language. Communication (believe me!!) is a major issue, even if the managers work for you.

AND.. if “labor is cheap” then the solution to problems is to throw people at them. The cost differential you actually get almost NEVER reaches the advantage of a 1:1 substitution. Oh – and you just added 3-4 weeks to your lead / response times.

If, on the other hand, you take the attitude that the most precious resource in your operation is people’s time – no matter what you pay them, and take the attitude that to deliberately waste anyone’s time is to show great disrespect, then I would suggest that even in high-wage areas you can drive levels of improvement in productivity, quality and response to your customers that would be difficult to beat anywhere.

So – before you reflexively outsource or relocate to a “low wage area” please check your attitude about people. What are your expectations, and why is it that you don’t believe your own people are capable of delivering a 10x improvement?

Who are your competitors? What do they do?
What would you do if you had to compete with Toyota? or Komatsu? (to name two that come to mind) They are building product in your back yard, why can’t you?

Afterthought: Some companies end up outsourcing the skills they need to improve their own products and systems. They no longer understand the technology they sell, they no longer know how to make what they sell. I remember a time when I reminded an (arrogant) procurement executive that it was possible to outsource the entire procurement process just as easily. Another team had outsourced all of their direct labor management… they contracted the labor and the first level supervisors into their factory. Where did they really believe this was leading?

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.