Author: Mark

Posted on

Costs and Kaizen

How does kaizen actually show up on the bottom line?
This is a question that gets asked a lot, and honestly, we owe the asker a better answer than “it just does, trust us.” (Even though this is true.)

Here’s my thinking – it shows up two ways.
One is intangible. By that I mean it is incredibly difficult to quantify, even afterwards. But it is there.

IF the organization manages to get the continuous improvement engine running – meaning they understand that “pursue perfection” is not a “step in implementation” but rather the thing that gets it going in the first place – then, over time, everything starts running more smoothly.

It is hard to put a hard-monetary return on things like:

  • Everybody is working together, as a team, toward the organization’s overall goals.
  • Everybody understands who the customer is, and keeps their focus there.
  • Every instance of a problem causes the organization to improve and learn.
  • Everybody comes to work knowing what they must do to succeed; knowing they can do it; knowing that, if there is a problem, they will find out right away; knowing that they will get support in resolving it.

In short, the organiztion performs, and that performance is getting better and better.
What is that worth? Is it better to have a superbly performing organization, or one which requires continuous micro-management of every detail? (Hint: It isn’t about hiring better people, it is about creating working conditions and processes where regular, competent people can create superb performance.)

But it is possible to understand some direct, tangible returns as well. In fact it is possible to set solid targets, understand what must be done to reach them, and track progress on activities and results.

Any organization that is self-funding (including a non-profit) must offer some kind of value to its paying customers. If “value” is what the customer is willing to pay, then it is easy to determine the, ah, value of the value.

“Value add” defines the economic result of a transformation process. We buy some stuff at some cost (value), transform it into something that is worth more to the customer, and sell it. The difference between what we paid for the stuff we bought, and what the customer paid for the product or service we sold is the “value add.”

Note that this has absolutely nothing to do with what it cost to make that transformation. Nothing at all. It is possible to add value and lose money at the same time. It happens every day.

It does cost something to run the operation that adds the value. When those costs are less than the total value added (over some period), then the organization gets to keep some of the money as profit.

When those costs are more than the amount of value added, then someone has to fund the gap – the owners / shareholders, debt, the money has to come from somewhere.

When it comes to costs, I like to keep things really simple and easy to understand.

Costs are incurred two ways, and in the details, they intermix.

  1. In order to operate, we spend money every day on things like payroll, rent, utilities. This is cash burn.
  2. We have stuff needed to operate. This is cash tied up in the business, capital, inventory, etc. Just having that stuff costs money, and a lot of this stuff depreciates. That depreciation can, in turn, be counted the same as cash burn, but real life is more abstract than that because, while payroll must be paid, “depreciation” is something we can hold our breath about.

I have not included the cost for materials that are transformed into finished product here. That cost is captured in “value add.” The above two things add up to the cost to add that value, and those costs are largely fixed (in the classic sense of the word), whether we make anything or not.

Aside from the actual materials that are bought, transformed, and sold, there are very few truly “variable costs.”

“Continuous improvement” means to continuously increase value add, and continuously decrease what it costs to add that value.

There are fundamentally four ways in increase value-add.

  1. Improve the product offering so that customers will pay more. Ideally this is done without increasing any costs. This is really the only leverage point of purely service businesses.
  2. Pay less for the raw materials and parts – push your suppliers for lower prices.
  3. Change the engineering design to one that is less expensive to source.
  4. Examine your make / buy. Look for high-leverage items that your currently purchase. These are items which:
    1. We could make if we wanted to.
    2. Have a very high differential between the cost of the pieces and what we pay for them. (i.e. the supplier has a very high value-add to us.)

    Now, here’s the rub (and where this ties in to kaizen). If you have been doing a good job at kaizen, you have made some people available. If you know how to make these high leverage parts, can you put those people to work making them? A lot of this depends on the capital required, etc. but, as a general rule, the further up the supply chain you reach, the higher your value add. It comes down to capability and cost. And if you are using labor made available through kaizen, it does not matter what this labor costs. If you are adding more value today than you were yesterday, and incurring exactly the same costs to do so, your profit is higher. And the last time I checked, that was the name of the game.

Aside from increasing value-add, the other objective is to do so at the lowest possible cost, and there is a bit of a circular reference here.

Good kaizen can free up a lot of time. I suppose, if you wanted to do scorched-earth kaizen, you could immediately lay those people off. (Don’t expect much help with further improvements after that.) Aside from the ethical issues, these kinds of actions are really disruptive to the organization, in ways that are difficult to quantify.

If you are trying to simply increase production volume (the right kind of problem to have), then dealing with this issue is fairly simple, you just avoid hiring more people. You increase output without increasing payroll.

But also take a look at the in-sourcing option mentioned above. A lot of organizations overlook these kinds of opportunities today.

Like I said, this model is very simple. It is essentially the “throughput accounting” model offered by the Theory of Constraints folks. (Believe me, I don’t just make this stuff up.) Traditional cost accounting models can be mapped directly into this model. I just find it a lot easier to understand, and more importantly, to explain to the people who actually have to make all of these things happen.

Posted on

There Are (almost) No Big Problems

In a “management by metrics” world, problems are detected when performance indicators are off track. Perhaps inventory is too high, first pass quality is a problem. Maybe operational availability is tanking.

Once the problems are abstracted into numbers, the numbers become the problem. The solution, then, is usually a directive to reverse the trend, to improve this measurement or that measurement, to get things back on track.

Here is the rub: The numbers aren’t the problem. They don’t even tell you what the problem is without a whole lot of investigation, digging, and stratification. And why was this investigation and stratification necessary in the first place? Because now you are trying to sort out a batch of problems that weren’t dealt with, one-by-one, at the moment they occurred.

The further you go up in the organization, the more things are aggregated and summarized. And the more they are aggregated and summarized, the more things look like big problems, even though they are composed of many (hundreds, sometimes) of little problems.

Let me cite an example. I was in a factory where the site manager was proudly showing off his real time display of Overall Equipment Effectiveness (OEE). Each time the equipment slowed, for any reason, the display would immediately change. He could see, at an instant, how the day’s OEE compared with his target, and, he said, “take action.”

But exactly what action is he going to take?
Even the real-time display lags the actual problem.
Two weeks ago a lubrication point was missed. Today something is overheating, and we need to slow or stop the machine to deal with it.

A bracket securing a roller is loose, today the machine is stopping all the time as they clear jams.

A hole in a screen let chips and debris clog a filter, and the coolant pumps are overheating.

This list can go on. The point is that the things that actually slow down or stop the machinery are second, third, fourth levels in chains of events. The actual problem had no immediate effect on the machinery.

In this system, the very best they will ever do is fix it fast and hold the number at some level. They will never be able to actually improve it, because they aren’t dealing with the underlying systemic issue: They aren’t finding and dealing with the actual root causes.

When you get to financial measures, things are even more abstract.

Inventory levels (or inversely, inventory turns) is a great example. “We have too much inventory!” “Our inventory levels are above the industry norm!”

In the boardroom, or in the Chief of Operations’ office, this is all they can see. Because most leaders in that position really like direct action, they.. um.. “direct” that some “action” be taken.

So the organization goes to war against inventory.

Two levels down, “We have too much inventory” is still characterized as the problem because that is what they have to report every month.

Two more levels down it is often still attacking the symptom – too much inventory.

But inventory isn’t the problem.

The problem is an engineering change that missed one part on the bill of material update, delaying production for a day while all of the other parts continued to roll in.

The problem is a paint system that is unreliable, so the factory obsesses on maintaining four hours of buffer on either side of it.

The problem is pressure to keep the line moving, so people work ahead, and push incomplete or problem units into the “hospital” for later repair.

The problem is that the upstream processes have to be ready to respond to massive fluctuations in assembly’s demand.

The problem is a broken jig, local initiative to make something else instead, resulting in too much of what nobody needs and none of what they do – because they don’t want to waste time doing nothing.

An additional problem is that the typical organizational response to these problems is to add more inventory because each local unit needs to protect itself from the dysfunction problems of their suppliers and customers.

Worse, just “taking out inventory” is going to tank everything else because the underlying problems are still there.

Inventory isn’t the problem.

The problem is that each of these small problems is too small to bother addressing as a systematic breakdown that leads to “too much inventory.” While the high-level leaders are looking for a big problem, they are missing their real responsibility.

It isn’t to “do something about inventory.”
It is to ensure that the small problems that occur every day, the ones which cause all of that inventory to accumulate in the first place, actually get addressed. Actually no. Their responsibility is to ensure there are systems in place which catch those problems and address them. They do this by teaching, setting example, then checking.

Leaders – if you want to “do something about inventory” you have to do it by setting an expectation that:

  • Processes are well defined.
  • Those processes are followed.
  • When there is a problem following the process, it is raised immediately.
  • When a problem is raised, it is swarmed, fixed, understood and prevented.

You handle big problems by making sure the small ones are dealt with, every day, all day.

Then your OEE will go up quickly. OEE is an indicator of how well you respond to problems, not how well your machines run.

One more thing – for my Health Care readers.
You can substitute “medication errors” for any of this. But until there is a system in place that alerts anytime someone spots the possibility of confusion, medication errors will occur at pretty much the same rate they always have.

Posted on

Keep it Simple

We have created an entire generation (or two) of managers who are very savvy with cost accounting models. They know exactly how “costs” and “profits” are calculated, and they know exactly what inputs to manipulate in order to make the numbers as good as possible.

They know, for example, how “inventory turns” are calculated, that “average inventory” is determined by end-of-quarter snapshots, and how to turn off production and pull in next quarter’s sales to starve the system for a week. Of course, anybody can also claim reduced oxygen consumption by holding his breath when it is being checked.

I put the terms “costs” and “profits” in quotes because one of the features characteristics problems(?) with modern cost accounting is that the models are complex. They are that way, not because costs are complex, they aren’t. They are that way because reporting is complex. They are that way because managers want to be secure in a fantasy that they can have a unit cost for every unit of production. “This product cost $4.72 to produce.” And once they have that number, they can calculate margins, forecast profits.

Here is the rub: That $4.72 cost figure is the result of a process that answers “What is 1+1?” with the statement: “It depends on your assumptions.” And by the time the PowerPoint Rangers are done with the summary, those assumptions are long buried and forgotten.

That unit cost figure is valid only for a certain level of production, because it includes allocation of costs that do not change as production levels change. Other costs that do change, change in non-linear ways.

There are lots of way to allocate fixed costs. Depending on which one you use (especially in multi-product operations), can completely alter the profit / loss numbers for a particular product.

So, while all of this cost accounting stuff is necessary to report taxes, and to report to the shareholders analysts, we forget that it is just a model. Aside from the top line (total sales) and the bottom line (the actual money we can keep), everything else is just someone’s representation of where the money actually went.

Here is my admittedly simplistic take.

A manufacturing company makes profit by adding value at a higher rate than they incur costs.
The value they add is the difference between what they pay for the parts and raw materials that are transformed into the final product, and the actual, real, cash-across-the-table revenue they get for the product when it is actually sold to a real customer who does not work for the same company. (This has nothing to do with internal transfer pricing, etc. because that is all just shuffling things from one column to another for the benefit of the cost accounting model. Until you actually cash the customer’s check, you have not sold the product.)

Since the idea of “unit cost” is really an artifact of whatever particular cost allocation you choose to use, then the idea of “unit margin” is equally dubious.

When I ask the finance folks to tell me how many units I need to sell to break even, they start by calculating a margin, then dividing the cost of operation by that margin, and presto!, break even.

Bzzzzt. The rub is that the margin per unit is only an estimate until the period is over, total costs are added up, and total margin is allocated across production. To use estimated margin to determine a break-even sales level is a circular reference.

But I can calculate how much value is added to each unit. [What can sell it for] – [What I pay for the pieces].

My break even is even simpler. Assuming that 100% of the value-add is allocated against the cost of running the factory (Total monthly payroll, total utilities, total everything except what I paid for what I will sell), until 100% of those costs are covered. With luck and good management, that happens before the end of the period. The total value add of the next unit is profit. And the total value add of every other unit after that is profit. This holds true whether you do it for a hour, a day, a week, a month, a year.

Now I can take projected sales, and determine, at any given rate of production (which drives a lot of the fixed costs), when I break even, and how much profit I can expect. Isn’t that what we are after anyway?

Why does everyone make it so complicated?

And yes, I know it is more complicated than this, but it isn’t THAT much more complicated.

Posted on

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

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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)

Posted on

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?