Category: The Basics

Posted on

Grassroots Innovation: Business is Like Swimming, Not Running

Grassroots Innovation: Business is Like Swimming, Not Running

Let’s take Greg Eisenbach’s totally on-target analogy and expand just a bit. Greg points out:

…a world class swimmer is only 9 percent mechanically efficient. This means 91 calories out of 100 in swimming are lost due to friction.

For the non-world class swimmer the best way to increase your speed is not to spend more calories, but figure out how to become more efficient. A gain from 3% efficiency to 4% efficiency would represent a 33% increase.

Business is the same way.

This probably explains why a little thing like the new technology in competitive swimming suits had such a huge (and controversial) impact in the 2008 competitive season. In competitive swimming, small advantages are huge advantages.

One of the big differences, though, between swimming and business is that a competitive swimmer knows, in real time, that he is winning or losing. Triathlons aside, a typical swim race is under a minute, a long one might be a couple. In this competitive environment, it is impossible to be complacent and believe you are in the race when, in fact, you are not.

On the other hand, I have worked with a number of businesses (or operations within larger businesses) that have had a truly amazing capacity for denial. What else can explain a headline in a company’s internal newspaper that exclaimed the “big order” when, in fact, the customer had placed a mixed order, giving 80% of it to the competitor… but no mention of that inconvenient truth. So when this company also wonders why people feel “no sense of urgency” you have to wonder. Of course the real story was all over the local news, about how the competitor had gotten the bulk of the order, and how the local company had “lost” it, only getting 20%. What does that do for the corporate credibility? Not much.

World class swimmers are 9% efficient. World class manufacturing value streams are about 40% value-add. (By % value-add I mean the time the product is actually in the value stream vs. the time something that matters is actually being done to it.)

Contrast this with a typical manufacturing flow where the value-add can easily drop into single digits.

This is basic stuff, but sometimes we forget what this lean stuff is about.

Consider a 10% value-add flow. Out of 100 minutes in the plant, 10 minutes are spent actually processing. The other 90 minutes are just sitting, moving, counting, stacking, etc.

Let’s say I spend my time and energy to speed up the value-adding process (like make the chips fly faster, speed up the processing time, find some high-tech fast curing compound). Let’s say I am really successful and cut that value-adding time in half. Whoo-hoo.

Now out of 95 minutes in the plant, 5 minutes are spent actually doing something.

Not exactly a stellar improvement, no real impact on lead time, no reduction in inventory, no reduction in waste. All of the original costs are still there, and I have probably just added more.

On the other hand, if I were to focus my time and energy on reducing that 90 minutes of “other stuff” I run into a couple of realities.

First, all of that “other stuff” costs time, money, space and accumulates inventory. It adds to lead time. Cutting it in half cuts the lead-time from 100 to 55.

And critically important – these changes are typically pretty easy to make. They don’t require engineering or computer science degrees, they just require watching the work and asking “Why is this stopping, why can’t it just go to the next operation right away?”

Greg is dead-on with his analogy. The difference, though, is that there is much higher potential for businesses to improve than there is for swimmers.

But like swimming, small advantages are huge advantages. It isn’t the companies that make the “blitz” type of changes that are sustaining world-class players. It is the companies that, every day, scratch out another little improvement.

It is those “a little every day” companies that, over time, build an insurmountable lead. They engage more of their people, and they learn as an organization what continuous improvement is all about. The “blitz” approach retains the knowledge in the few experts who are responsible for all of the kaizen activity. As good as they may be, they can’t be everywhere.

Posted on

The TPS In Four Words

ptolematic_universeIn the world of science, great discoveries simplify our understanding. When Copernicus hypothesized that everything in the universe does not revolve around the Earth, explaining the motions of things in the sky got a lot easier.

In general, I have found that if something requires a great deal of detail to explain the fundamentals, there is probably another layer of simplification possible.

Even today, a lot of authors explain “lean manufacturing” with terms like “a set of tools to reduce waste.” Then they set out trying to describe all of these tools and how they are used. This invariably results in a subset of what the Toyota Production System is all about.

Sometimes this serves authors or consultants who are trying to show how their process “fills in the gaps” – how their product or service covers something that Toyota has left out. If you think about that for a millisecond, it is ridiculous. Toyota is a huge, successful global company. They don’t “leave anything out.” They do everything necessary to run their business. Toyota’s management system, by default, includes everything they do. If we perceive there are “gaps” that must be filled, those gaps are in our understanding, not in the system.

So let me throw this out there for thought. The core of what makes Toyota successful can be expressed in four words:

Management By Hypothesis Testing

I am going to leave rigorous proof to the professional academics, and offer up anecdotal evidence to support my claim.

First, there is nothing new here. Let’s start with W. Edwards Deming.

Management is prediction.

What does Deming mean by that?

I think he means that the process of management is to say “If we do these things, in this way, we expect this result.” What follows is the understanding “If we get a result we didn’t expect, we need to dig in and understand what is happening.”

Control ChartAt its most basic level, the process of statistical process control does exactly that. The chart continuously asks and answers the question “Is this sample what we would expect from this process?” If the answer to that question is “No” then the “special cause” must be investigated and understood.

If the process itself is not “in control” then more must be learned about the process so that it can be made predictable. If there is no attempt to predict the outcome, most of the opportunity to manage and to learn is lost. The organization is just blindly reacting to events.

Here is another quote, attributed to Taiichi Ohno:

Without standards, there can be no kaizen.

Is he saying the same thing as Deming? I think so. To paraphrase, “Until you have established what you expect to do and what you expect to happen when you do it, you cannot improve.” The quote is usually brought up in the context of standard work, but that is a small piece of the concept.

So far all of these things relate to the shop floor, the details. What about the larger concepts?

What is a good business strategy? Is it not a defined method to achieve a desired result? “If we do these things, in this way, at these times, we should see this change in our business results.” The deployment of policy (hoshin planning) is, in turn, multiple layers of similar statements. And each of the hoshins, and the activities associated with them, are hypothesized to sum up to the whole.

The process of reflection (which most companies skip over) compares what was planned with what was actually done and achieved. It is intended to produce a deeper level of learning and understanding. In other words, reflection is the process of examining the experimental results and incorporating what was learned into the working theory of operation, which is then carried forward.

Sales and Operations Planning, when done well, carries the same structure. Given a sales and marketing strategy, given execution of that strategy, given the predicted market conditions, given our counters to competitor’s, we should sell these things at this time. This process carries the unfortunate term “forecasting” as though we are looking at the weather rather than influencing it, but when done well, it is proactive, and there is a deliberate and methodical effort to understand each departure from the original plan and assumptions.

Over Deming’s objections, “performance management” and reviews are a fact of life in today’s corporate environment. If done well, then this activity is not focused on “goals and objectives” but rather plans and outcomes, execution and adjustment. In other words, leadership by PDCA. By contrast, a poor “performance management system” is used to set (and sometimes even “cascade”) goals, but either blurs the distinction between “plans” (which are activities / time) and “goals” which are the intended results… or worse, doesn’t address plans at all. It gets even worse when there are substantial sums of money tied to “hitting the goals” as the organization slips into “management by measurement.” For some reason, when the goals are then achieved by methods which later turn out to be unacceptable, there is a big push on “ethics” but no one ever asks for the plan on “How do you plan to do that?” in advance. In short, when done well, the organization manages its plans and objectives using hypothesis testing. But most, sadly, do not.

Let’s look at another process in “people management” – finding and acquiring skills and talent, in other words, hiring.

In average companies, someone needing to hire someone puts in a “requisition” to Human Resources. HR, in turn, puts that req out into the market by various means. They get back applicants, screen them, and turn a few of them over to the hiring manager to assess. One of them gets hired.

What happens next?

The new guy is often dropped into the job, perhaps with minimal orientation on the administrative policies, etc. of the company, and there is a general expectation that this person is actually not capable of doing the work until some unspecified time has elapsed. Maybe there is a “probation period” but even that, while it may be well defined in terms of time, is rarely defined in terms of criteria beyond “Don’t screw anything up too badly.”

Contrast this with a world-class operation.

The desired outcome is a Team Member who is fully qualified to learn the detailed aspects of the specific job. He has the skills to build upon and need only learn the sequence of application. He has the requisite mental and physical condition to succeed in the work environment and the culture. In any company, any hiring manager would tell you, for sure, this is what they want. So why doesn’t HR deliver it? Because there is no hypothesis testing applied to the hiring process. Thus, the process can never learn except in the case of egregious error.

If we can agree that the above criteria define the “defect free outcome” of hiring, then the hiring process is not complete until this person is delivered to the hiring manager.

Think about the implications of this. It means that HR owns the process of development for the skills, and the mental and physical conditioning required of a successful Team Member. It means that when the Team Member reports to work in Operations, there is an evaluation, not of the person, but of the process of finding, hiring, and training the right person with the right skills and conditioning.

HR’s responsibility is to deliver a fully qualified candidate, not “do the best they can.” And if they can’t hire this person right off the street, then they must have a process to turn the “raw material” into fully qualified candidates. There is no blame, but there are no excuses.

Way back in 1944, the TWI programs applied this same thinking. The last question asked on the Job Relations Card is “Did you accomplish your objective?” The Job Instruction card ends with the famous statement “If the worker hasn’t learned, the teacher hasn’t taught.” In other words, the job breakdown, key points and instruction are a hypothesis: If we break down the job and emphasize these things in this way, the worker will learn it over the application of this method. If it didn’t work, take a look at your teaching process. What didn’t you understand about the work that was required for success?

I could go on, but I have yet to find any process found in any business that could not benefit from this basic premise. Where we fail is where we have:

  • Failed to be explicit about what we were trying to accomplish.
  • Failed to check if we actually accomplished it.
  • Failed to be explicit about what must be done to get there.
  • Did something, but are not sure if it is what we planned.
  • Accepted “problems” and deviation as “normal” rather than an inconsistency with our original thinking (often because there was no original thinking… no attempt to predict).

As countermeasures, when you look at any action or activity, contentiously ask a few questions.

  • What are we trying to get done?
  • How will we know we have done it?
  • What actions will lead to that result?
  • How will we know we have done them as we planned?

And

  • What did we actually do?
  • Why is there a difference between what we planned and what we did?
  • What did we actually accomplish?
  • Why is there a difference between what we expected and what we got?

The short version:

  • What did we expect to do and accomplish?
  • What did we do and get?
  • Why is there a difference?
  • What are we doing about it?
  • What have we learned?
Posted on

TPS Failure Modes – Part 1

Following on from the buzz created by the last couple of posts, I would like to go back in time a bit.

In 2005 Steven Spear wrote a working paper called “Why General Motors Lost and Toyota Won.” A reader can clearly the see emerging themes that were developed into his book Chasing the Rabbit .

Spear talks about the leverage of “operationally outstanding” in changing the game, the capabilities he sees in “operationally outstanding” organizations, then “Failure Modes at Becoming Toyota Like.”

I would like to dwell a bit on these failure modes, and reflect a little on what they look like.

Failure Mode 1: Copy Lean Tools Without Making Work Self Diagnostic

So what does “self diagnostic” mean?

For something to be “self diagnostic” you need two pieces of information:

  • What is supposed to happen.
  • What actually happens.

Then you need some mechanism that compares the two and flags any difference between them. This sounds complicated, but in reality, it isn’t.

Let’s look at a common example: At the most basic level, this is the purpose of 5S.

5S as a Self Diagnostic Tool

In 5S, you first examine the process and seek to understand it. Then, applying your best understanding, you decide what is necessary to perform the process, and remove everything else. Applying your best understanding again, you seek to locate the items where they would be used if the process goes the way you expect it to.

You improve the self-diagnostic effect by marking where things go, so it immediately clear if something is missing, out of place, or excess.

Then you watch. As the process is carried out, your “best understanding” is going to be tested.

Can it be done with the things you believed are necessary? If something else is required, then you have an opportunity to improve your understanding. Get that item determine where it is used, and carry out the operation. But go a little deeper. Ask why you didn’t realize this was needed when you examined the process. Challenge your process of getting that initial understanding and you improve your own observation skills.

Is everything you believed is necessary actually used? If not, then you have another opportunity to improve your understanding. Is that item only used sometimes? When? Why? Is it for rework or exceptions? (see failure mode #2!) Why did you believe it was necessary when you did your initial observation?

Does something end up out of place? Is it routinely used in a place other than where you put it? This is valuable information if you now seek to understand how the process is different from what you expected.

Now think about the failure mode: What does fake-5S look like? What is 5S without this thinking applied?

How do you “do” 5S?

Look long and hard if you are trying to audit your way into compliance rather than using it as a diagnostic for your understanding of your process.

Though the jargon “self diagnostic” sounds academic, we have all talked about visual controls “distinguishing the normal from the abnormal” or other similar terms. It is nothing new. What makes this a failure mode is that people normally don’t think it is that important when Spear cites a mountain of evidence (and I agree) that this is critical to success. You can only solve the problems you can see.

Another Example: Takt Time

What is takt time? Before you whip out your calculators and show me the math, step back and ask the core question of “What it is” rather than “how to calculate it.” What is it?

Takt time is part of a specification for a process – it defines what should be happening. By setting takt time you are saying “IF our process can routinely cycle at this interval, then we can meet our customer’s demand. Takt time defines both part of a “defect free” outcome of your work cycle as well as a specification for process design.

Then you apply your very best knowledge of the process steps and sequence and set out a work cycle which you believe can be accomplished within the takt. It becomes self-diagnostic when you check, every time if the actual work cycle was the same as the intended work cycle. An easy way to check is to compare the actual time with the designed time.

In Decoding the DNA of the Toyota Production System, Spear cites an example of seat installation.

At Toyota’s plants, […] it is instantly clear when they deviate from the specifications. Consider how workers at Toyota’s Georgetown, Kentucky, plant install the right-front seat into a Camry. The work is designed as a sequence of seven tasks, all of which are expected to be completed in 55 seconds as the car moves at a fixed speed through a worker’s zone. If the production worker finds himself doing task 6 (installing the rear seat-bolts) before task 4 (installing the front seat-bolts), then the job is actually being done differently than it was designed to be done, indicating that something must be wrong. Similarly, if after 40 seconds the worker is still on task 4, which should have been completed after 31 seconds, then something, too, is amiss. To make problem detection even simpler, the length of the floor for each work area is marked in tenths. So if the worker is passing the sixth of the ten floor marks (that is, if he is 33 seconds into the cycle) and is still on task 4, then he and his team leader know that he has fallen behind.

assembly-valencien-640

On this assembly line, time is used, not so much to pace the work, but as a diagnostic tool to call out instances when the work departs from what is intended – or in simpler terms, when there is a problem.

All of this has been about checking that the process is being carried out as expected. But, bluntly, the customer really doesn’t give a hoot about the process. The customer is interested in the output. How do you know that the output of your process is actually helping your customer?

To know that you first have to be really clear on a couple of things:

  • Who your customer actually is.
  • What value do you provide to that customer?

Put another way, can you establish a clear, unambiguous specification of what a defect free outcome is for each supplier-customer interface in your process? Can you follow that trap line of supplier-customer interfaces down to the process of delivering value to your paying customers?

To make this self-diagnostic, though, you have to not only specify (what should be happening), you have to check (what is actually happening), and you have to do it every time.

So poka-yoke (mistake proofing) is a way to verify process steps. Other mistake proofing will detect problems with the outputs. All are (or should be) designed to diagnose any problems and immediately halt the process or, at the very least, alert someone.

The theme that is emerging here is the concept of PLAN-DO and CHECK, with the CHECK being thoroughly integrated into the process itself, rather than a separate function. (Not that it can’t be, but it is better if CHECK is continuous.)

The Supply Chain

I was walking through the shop one afternoon and spotted an open bundle of steel tube – about half of them remaining. They used kanban to trigger re-order. The rule of kanban is that the kanban card is pulled and placed in the post when the first part is consumed. To make this clear, they literally attached the kanban to the bands with a cable tie. Thus, breaking the band would literally release the kanban. Simple, effective.

But, though this bundle had been opened, there was the kanban card still attached to the (now broken) banding. It was lurking at the base of the pallet, but visible.

I went and got the supervisor, and told him that “You are going to have a shortage of 4×5 tube on Wednesday, and it is your fault. Would you like to know why?” I guess I should point out that I had a pretty good relationship with this guy, so he knew I was playing him a little. Then I just said “Look, and tell me what you see.”

It took a few seconds, but he saw the kanban, said “Argh” and started to pick it up to put into the post. I stopped him and asked if it was his responsibility to do that. No, it was the welder’s responsibility. “Then you should take a minute with him, and do what I just did with you.”

Then I asked him how often the kanban cards were collected. (I knew, I wanted to check that he knew.) “Daily, about 1 pm.”

“How often do you walk by here every day?” He said at least twice, in the morning and right after lunch. “So all you need to do is take a quick glance as you walk by, twice a day, and you will always get that kanban into the post before 1pm.”

He did, and their periodic shortages dropped pretty much to zero.

Why?

First, the system was set up JIT. We knew the expected rate of use of that part. We knew the supplier’s lead time and delivery frequency. We knew the bundle size. MATH told us the minimum number of kanban cards that would need to circulate in this loop to ensure the weld cell never ran out… unless one of the inputs was wrong or unless the process operated differently than we expected.

We also knew that, given the rate of consumption, how many bundles should be in the shop at any given time, and we had space market out for just that amount. Thus, we could tell immediately if something was received early, or if our rate of consumption fluctuated downward. (Because a pallet would arrive, but there would be no place to put it.)

We could have just had a Team Member come by once a day and check if a bundle had been opened, and send an order to replenish it. We could have been even more sophisticated and just set up a barcode scan that would trigger a computer order.

But if we had set up the process that way, how could the Supervisor distinguish between “Ordered” or “Not Ordered?” It was that stray out-of-place kanban card that told him.

Bin with kanban cardThus, physical kanban cards, physically attached to the materials, represent a self-diagnostic check. If the card is there, then that container should be full. Quick to check. If the container is not full, there should be no card. Quick to check. If a container arrives with no card, it was not properly ordered and is likely excess (or at least calls for investigation). Quick to check. The physical card, the seeming crude manual operation, provides cross-checks…self-diagnosis… simply and cheaply in ways that few automated systems replicate.

So far these have all been manufacturing examples. But Spear is clear that all work is self-diagnostic, not just manufacturing.

What non-manufacturing work fits into this model?

(Hint: All of it.)

What about a project plan? Though in reality, most project plans don’t. Read Critical Chain by Goldratt to understand the difference – and produce and manage project plans that are much more likely to finish on time.

What about a sales plan? Do you predict your monthly sales? Do you check to see if week 1 actual sales deviated from what was expected? Do you plan on activities that you believe will hit your sales targets? Which customers are you calling on? What do you predict they will do? (Which tests how well you really know them.) Do you actually call on those customers? Do they need what you thought they would? Or do you learn something else about them? (Or do you make a best guess “forecast” and wait for the phone to ring?)

Once you have a sales plan, do you put together a manufacturing and operations plan which you believe will match production to sales? How much variation do you expect to accumulate between production and sales over the course of that plan? Do you put alarm thresholds on your finished goods or your backlog levels that would tell you when that predicted variation has been exceeded?

How do you (and how often do you) compare actual sales (volume, models, and revenue) against the plan? Do you know right away if you are off plan? How long will you tolerate being off plan before you decide that something unexpected is happening? Is there a hard trigger point already set out for that? Or do you let the pain accumulate for a while?

A lot of companies were caught totally by surprise a few months ago when their sales seemed to fall off a cliff. Question: Did you have rising inventory levels before that? Was there a threshold that forced attention to something unexpected? Or did you increasingly tolerate and normalize deviance from your intended business plan?

At the next levels up – you have a business plan of some kind. You have financial targets. Do you have specific actions you plan to take at specific times? Do you check if those actions were actually taken? Do those actions have some kind of predicted outcome associated with them? Do you check if the actual outcome matches what you predicted? If you just “try something to see what happens” you might learn, but you might not. If you predict, then try to see IF it happens, you are more likely to gain more understanding from that experience.

When you design a product, do you have performance specifications? Do you test your design(s) against those performance specifications? Do you do that at every stage, or just at the end?

When you say “We need training” have you first specified what the work process is? Have you studied the situation and determined that people do not have the skills or knowledge to do the job? Have you specified what those skills are?

Have you developed the training to specifically develop those skills? Do you have a way to verify that people got the skills required? Do you check if, now, they can perform the work that they could not perform before? If you didn’t do the last, why did you “train” them at all? How do you know it was not just entertainment?

“Management Is Prediction”

deming

This quote, attributed to W. Edwards Deming, really sums up what this is about. By specifying an outcome – “defect free” (which implies you know that is), within a certain time; and by specifying the process steps; you are predicting the outcome.

“If we do these things, in this sequence, it should require this amount of time, and produce this result.”

Then do it, and check:

Does what you really had to do reflect the tasks you thought would be required?

Does the order you really did them in reflect what was in the plan?

Does the time required reflect the time you planned on?

Did it produce the intended result?

Building those checks into the process itself makes it self-diagnostic.

Try This

Go study a process, any process. Just watch. Constantly ask yourself:

How does this person know what to do?

How does this person know if s/he is doing it right?

What alerts this person if s/he makes a mistake?

How does this person know s/he succeeded?

If there are clear, unambiguous answers right in front of you – without research, without requiring vigilance or luck on the part of the Team Member, then you probably have something approaching self-diagnostic work. Likely, you don’t. If that is the case, don’t say you are “doing lean.” You are only going through the motions.

Posted on

Expectations

This is a bit of a more pragmatic breakdown from the “How Strong Is Your Immune System?” I plan to follow-up with some practical approaches and tools to implement and conduct the kind of problem solving that needs to be done every day.

As we “promote lean,” what expectations to we set?
How well do those promises match up with what is delivered?
If there is a gap, does it dampen the enthusiasm of “management support?”

I think this is important for us to understand.

In the enthusiasm to “make the case” many lean manufacturing proponents point (and rightly so) to the higher performance levels of organizations that have done it. They talk about greatly improved quality, much faster inventory turns, greater returns on capital, much quicker response and throughput. By whatever measure, these systems clearly perform better.

The implementers start teaching the system through its mechanics. Takt time to pace everything; one-piece-flow; pull systems, supermarkets and kanban; quick changeovers; standard work; mistake-proofing.

Now I will be the first to tell you – this is how I was taught – the “just do it, and you will understand” approach. But no matter how well-intended, there is the danger of a diluted message: “Copy the mechanics of how these operations work, and you too can have these results.” Or, put another way, it “Don’t ask questions, just do it” gets (mis)translated into “You don’t have to understand it.”

Wrong. You do.

An expectation is created that, by implementing the basic mechanics of takt, flow and pull, these terrific results can be achieved and sustained.

Here’s the rub. All of the “tools of lean” are designed to force problems to the surface and make them too obvious to ignore. There is an implied expectation that the organization will see these problems and take on the challenge of tackling them as they emerge – true kaizen.

Of course all of this presumes that the organization has the resources, skill and most importantly the stomach to deal with these problems quickly and efficiently.

Bluntly, most don’t. If they did then none of this would have been necessary in the first place.

By implementing the tools alone, they are in effect taking a Newcomen steam engine – primitive, big, inefficient, slow, but functional through brute force- and replacing it with a state of the art steam turbine.

Yes, the turbine is much more efficient, but if you took one and dropped it into the year 1715 it wouldn’t run for very long. They didn’t have the resources or the skill to operate or maintain it.

So, in our lean- implementing factory, the new system is put in and in fairly short order, all of the previously hidden and tolerated problems are now revealed.

And it reveals the problem of “no process to devote the time or to develop the resources and skills to handle those problems” – to detect them, fix them, understand them and solve them.

Lacking the time and skills, the first line leaders do what they must to get the job done… they return to the tried-and-true countermeasures that keep the problems from disrupting things too much:

Kaizen Deterioration Reinforcing Loop

This is the fate of many so-called “kaizen events” which seek to make great change in a hurry.

So why does this happen?

I can speculate that it is a combination of ignorance on the part of some implementers who “got” the “just do it” part but didn’t pick up the “think for yourself” part.

Somewhere, sometime, someone established a precedent that making dramatic but unvalidated changes to a system was “kaizen.” Perhaps, at some point, a sensei said “Don’t ask questions, try this…” with the intention that people would try it and learn what problems came up, only to have it turned into “Do this” without any follow-up or understanding.

Others, perhaps, have an underlying fear that if they revealed just how much work and change was really involved that the leaders would be scared off and not take the first steps.

Now, to be clear, a certain amount of “just try it” is required to anchor that initial leap of faith. But the implementers must be prepared to immediately guide, lead, teach, coach and build the problem solving capability of the organization.

But, in the end, digging further into “Why?” doesn’t give us any more actionable information. “The system is designed to surface problems, and there is no process to handle them” is a root cause that can be directly addressed. It is simply important to acknowledge the truth.

What to do about it. I’ll get into more detail in future posts, but to begin, here are some things to think about:

  1. Small steps. (Note that “small steps” ≠ “slow steps”). Kaizen can be done rapidly, but it must be done deliberately in a context of understanding. Understand why things are the way they are, understand the effect your change should have. Try it out – ideally simulate if first – and see what problems surface. Solve those problems, then implement your change.
  2. Dedicate and manage time for solving problems. This is briefly covered by a couple of previous posts, “Why Doesn’t Daily Kaizen Happen?” and “Systematic Problem Solving” but is worth repeating. Problem solving and kaizen are work, just like anything else. If you want it to happen, you need to allocate time, resources and management to organize it.
  3. Develop a systematic approach, then follow it. I am going to go into some detail on this over the next few posts, but I need to emphasize the last part: then follow it. Too many “standards” are declared, then ignored.
  4. Don’t wait for “the next event” to make improvements.
  5. Just get started. Don’t wait until you are ready, you never will be. The only way to learn is to practice, observe yourself, see what works, what doesn’t, and learn. This, in turn, requires something that is sadly in very short supply in most corporations: humility. Learning means acknowledging, usually in public, that “we don’t have the answers” and perhaps that is the most important lesson.

I could digress into a leadership roles discussion here, but I won’t. But if you want to do a bit of pre-reading for future discussions, find a copy of “Learning to Lead at Toyota” by Steven Spear, and as you read it think about the role of the leader in that story. Bob, the protagonist, starts out with one role, and learns his role is actually quite different. There will be a quiz later.

Posted on

A Firefighting Culture

In honor of October being Fire Prevention Month (at least here in the USA), I’d like to talk about firefighting.

“We have a firefighting culture.”

“We spend all of our time fighting fires.”

We have all heard (and sometimes made) these statements. But I would like to take a couple of minutes and look at what real firefighters do.

They don’t just run in and spray water everywhere in an effort to “do something.”

They study fire. They seek to understand how fires start, how they burn, how they spread. They understand the interactions between fire, air, the specific environment (building structure, outdoor terrain, etc).

They develop a plan to attack the fire. They make themselves reasonably sure that if they do (a), (b), and (c) that the fire will respond in a predictable way.

They execute the plan.

They watch the results. If the fire behaves the way they predicted it would, they continue with the plan. If something unexpected happens, they pause their thinking long enough to understand what additional factor may be at play; what they might not have known or considered. They seek to understand the situation whenever something is going differently than what they predicted.

They adapt the plan to account for the new information or the changed circumstances.

They continue to do this until the situation is under control, and the fire is out.

While doing these things, they work methodically. They verify success at each step of the plan – they do not move ahead of their confirmed progress (which would put fire behind them and block their escape route).

While theirs is a dangerous business, they do not, as a matter of course, put human life in jeopardy simply to save property. Heroics are reserved for saving the lives of others.

Once the fire is out, the fire investigators arrive. They seek to understand how this fire started. Where did fuel, oxygen and a source of ignition come together and how? What fire suppression mechanisms failed, and why? How, why, did it spread? Did containment fail? This information is incorporated into the knowledge base of the society in general in the form of regulations, building codes, electrical codes – countermeasures.

In short – firefighters relentlessly follow PDCA.

Now, I must admit that, occasionally, in the excitement of the moment, firefighters get ahead of themselves, or rush into something they don’t fully understand. We usually know when this has happened because there are somber processions and bagpipe music. But even then, they seek to understand what happened, why, and improve their process to prevent recurrence.

Now, the next time you say “All we do is fight fires” consider the above. My guess is that you aren’t fighting anything. Rather, you are running around, making a lot of noise, but tomorrow the building is still burning – just in a different place.

Don’t forget to check your smoke alarms and change the batteries!

Be sure to read the follow-on post here: /2011/01/17/firefighting-kata/

Posted on

The Power of Vision

In the last post I brought up the advantage of having a long range plan vs. quarter-to-quarter thinking. I’d like to explore the concept a little more by way of an analogy.

Put yourself in the spring of 1961.
The USSR, by all demonstrative measures, is ahead of the USA in human space flight, and seems to be increasing that lead. On April 12, Yuri Gagarin orbited the Earth. On May 5, Alan Shepard went up, and came down on a 15 minute trajectory.

At the time, there were important geo-political reasons for establishing a public perception of technological leadership, and space exploration seemed to be the place to do it.

On May 25, President Kennedy made a public commitment to regain, and maintain, that leadership. He could have done it with corporate-speak:

This nation will become the world leader in space exploration.

But he didn’t. He said:

“I believe that this nation should commit itself, to achieving the goal, before this decade is out, of landing a man on the moon, and returning him safely to the Earth.”

Only the second statement is actionable. Only the second statement carries the possibility of failure. And only the second statement galvanizes action. In pursuing that goal with that degree of commitment, it achieved the first – to demonstrate world leadership in space exploration, not with words, but with action.

Of course the first statement carries no risk, since there is no actual performance requirement. Perhaps that is why corporate-speak carries that kind of language today. The shareholders can’t fire the board for not achieving something that was never articulated. The statement leaves open the capability to re-define the goal so that it matches what was actually done – something that happens all too often in today’s world.

So when one company says “We are going to sell more products next year.” and another says “We are on year 2 of our 10 year plan to be #1 in sales with 15% market share.” which one do you think can align actions of the people in the company?

To continue, when Kennedy made that speech:

  • The United States had a human space flight experience totaling 15 minutes.
  • The world had human space flight experience totaling under 2 hours.

Nobody actually knew, for sure, what the moon was made of.

To be sure, the visionaries within NASA had been thinking about sending someone to the moon for a long time. And in May, 1961 there were competing strategies in play at NASA for getting it done. They either involved an unimaginably HUGE rocket (think twice the size of the one that actually did it), or two or three Saturn class rockets to launch and assemble the lunar spacecraft in orbit. But when faced with a deadline of “before this decade is out,” the challenges were immense. Another strategy, considered a bit crackpot at the time, was named “lunar orbit rendezvous.” It involved a smaller (but still huge) rocket to send a throw-away lander on the moon along with a re-entry capsule. The capsule remains in lunar orbit, the lander lands, takes off, docks with the capsule. The crew transfers to the capsule, and they head home. As each piece fulfilled its intended purpose, it would be discarded.

It became increasingly clear, in the months that followed the speech, that neither of the “mainstream” approaches would get the job done with the time and resources available.

During the summer, consensus formed around the lunar orbit rendezvous scenario.
Key Point: Once they decided to pursue that option all further pursuit of the others was stopped. They committed. They did not have the resources to do otherwise.

In the corporate world, how often does that happen? Once a project, or even an idea, has any kind of resourcing or momentum behind it, stopping it is incredibly difficult. More things to do get added, but it seems that nothing gets taken off. This is equally true of “improvement schemes.” I recall a company that had active people in various improvement initiatives. There was the “Workout” group. There were the TQM people. There were the Six Sigma folks. (It took me a while to realize that the TQM and Sigma people considered each other competitors, where I had initially lumped them in together.) Then there were the “Lean guys” who had just come in. There were also pockets of Theory of Constraints believers, the agile guys, everyone saying they had “the answer.”

Back to NASA.

Landing a person on the moon by the end of the decade was a clearly articulated vision for accomplishing the high level mission of becoming “the world leader in space exploration.” That was the hoshin.

After a round of “catchball” a strategy was selected from the options available. Note that the catchball didn’t negotiate the goal. That was stated. The question was not whether to do it, but how to do it. The strategy was Lunar Orbit Rendezvous (LOR). They committed to the strategy and ceased all distracting activity to focus 100% of their energy on getting it done.

To make LOR work, they had to learn three things:

  1. Can people stay and work together in space for the 10-14 days required for the trip?
  2. Can people work outside the spacecraft in protective suits?
  3. Can one space vehicle locate and dock with another?

We do these things routinely today, but in 1961 nobody knew the answers.

These three things were the ONLY major objectives of Project Gemini.

The fourth big task was to develop the Saturn V as well as the facility to assemble and launch the rockets.

This goal is very sticky.
Any time one of the hundreds of thousands of Team Members working at NASA and in the contractors had a decision to make, the criteria was simple: “Will this action help the effort to put a man on the moon by the end of the decade?” If the answer was “No” then don’t do it. Great idea. But don’t do it. We don’t have the time or energy for the distraction.

The second thing it did, and this is even more important, is in the face of major setback – the Apollo 1 fire in January 1967, the organization was able to recover, regroup and stay on course because they had a sense of destiny. There was a clear goal, and they were working to meet it. It provided a compass that pointed the way when all other navigational references were blacked out.

Contrast this with the way NASA has been run during the Shuttle era. The massive amounts of energy involved in space travel mean this is, and is likely to remain, a risky business. But in the shuttle era, the tragedies seem to have created doubt and loss of confidence. There is no higher purpose other than space flight for its own sake. They are running it like a business.

“But we ARE a business! you may say. Sure you are. But the truly excellent businesses, those with the ability to adapt to changing situations quickly and recover are the ones whose sense of “self” transcends quarterly profits and financials. They are successful because they stand for something more.

A few years ago I remember standing outside in the Seattle area during an earthquake that lasted close to a minute. It was an unsettling experience because the ground itself was moving. Leadership’s job is largely providing a sense of solid ground so everyone else can operate without feeling off balance. This is done with very clear goals that are

  • Simple to understand.
  • Unexpected – they compel attention
  • Concrete – they can be seen, touched, felt.
  • Credible – they make sense in the larger context.
  • Emotional – they appeal to people’s feelings and
  • have Stories – they can be communicated in a way people can visualize.

Kitchen sink “KPI” lists don’t do this.

Posted on

Beyond the Value Stream

As I mentioned a long time ago, Art Smalley’s web site, http://artoflean.com, is an excellent resource for learning. His thinking is cutting edge – he has kept up in the field.

I am mentioning it here because he has a couple of really good resources available.

Learning From Toyota is a presentation that challenges some of the conventional thinking about what “lean” is… or better, contrasts the current “lean industry” from Toyota’s thinking and approach.

The Eight Basic Questions of TPS is a longer article on the same topic.

In both cases, Art emphasizes that the classic approach of mapping value streams and implementing flow cover only a very small fraction of what makes up the system. Indeed, in my opinion, those steps will uncover (e.g. confront) many more previously buried problems than they resolve. Yet so many practitioners, many of them even taking your money as consultants, never go beyond these basic steps.

Look at the “classic” questions and Art’s questions, and see for yourself how different the path is.

Posted on

Anchoring a Problem Solving Culture

More than a few organizations I know are starting to understand the importance of establishing a culture of problem solving. Hopefully they are shifting from a tools implementation model to one which emphasizes how people respond to the daily friction generators.

In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.

The organization must reset its definition of “a problem.”

I started to get at this mindset back in January with the post “Chatter as Signal.”

In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.

Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.

When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”

The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”

Maybe the term “problem” is unfortunate.

A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”

In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.

The organization must have a process for immediately detecting and responding to problems.

It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.

But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.

Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.

Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?

But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?

The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.

The organization must have a process for managing problem solving.

When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.

Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages

However it is done, however, the organizations that do it well:

  • Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
  • Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
  • They manage their talent. The organization I talked about in the “Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
    • Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
    • Don’t jerk them from one thing to the next without allowing them completion.
  • They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.

They deliberately and systematically develop their problem solving skills at all levels.

It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.

Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.

This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.

This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.

As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.

Posted on

Theological Debates

A frequent topic in the lean.org forums is some version of “what is the difference between lean and ____” where the blank is one of the industry buzzwords. Some of the common ones are various prefixes to “Sigma.” Others are old standards such as TQM, SPC, TOC, etc. These discussions are always interesting as the various camps line up. “Lean looks at waste, while xxx-Sigma looks at variation” is a common one. Apparently “Agile” is about high-tech machinery, and of course, none of that is found in “lean.”

My put on all of this is pretty simple. It’s all the same, people.

There is nothing about TPS that excludes any level of machining technology, so long as that technology is applied as a solution to a problem rather than for its own sake. The last time I checked, Toyota, and TPS, were obsessive about stamping out variation. Constraints? Yup. You bet I know what the constraint is, and you bet I manage it tightly. If I have done everything right, my enterprise constraint is production (rather than sales), but just barely. And internally, if I have done it right, my constraint is manual work rather than technology. Why? Because every Team Member can work on improving manual work cycles. Not the case with an engineering constraint.

In the end, this is all about the rational, deliberate application of skilled problem solving, using the scientific method, aka PDCA.

If you are looking at “which one to implement” stop fretting about it. Go out to your work area, stand and watch a while, see what is stopping your good people from doing a great job, and start fixing it.

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.