Posts

Posted on

Jim Collins: “Good to Great” Website

Jim Collins book “Good to Great” has been a best selling business book for several years. But I am not so sure everyone knows about Jim Collins web site. It as on-line mini-lectures, and much more material that reinforces the concepts outlined in the book.

As for how the concepts in the book relate to “lean thinking” – I believe they are 100% congruent. Examining Toyota in the context of the model outlined in the book shows everything Collins calls out as the crucial factors that separate sustainable improvement from the flash-in-the-pan unsustainable variety.

The only difference I can see between Toyota and the companies that were profiled is that Toyota has had these ingredients pretty much from the beginning, and Collins’ research was looking at companies that acquired them well into their existence.

Posted on

How The Sensei Sees

Steven Spear told an interesting story in our session with him.

A Toyota sensei, very senior, was looking at a process unlike anything in his previous experience base. The researchers watching expected him to do “analysis by analogy” – to take what he observed, find a matching analogy in his deep experience, and then draw conclusions about the current situation.

This model, by the way, is a commonly accepted one for how “experts” work with new situations.

But that isn’t what happened. The insights were very fundamental, and quite specific to the process he was seeing for the first time.

The way he worked was revealed in the way he described the issues.

“Ideally,” he would say, “it should be ___________ . But the problem is __________ .”

In describing the “problem” he would describe the departure from the ideal situation. In so doing he was seeing problems, not as “seeing waste” but as seeing “departure from the ideal.”

This was, at least for me, a fairly significant ah-ha. I realized two things immediately.

  1. If I may be so bold, I got some insight into what I did in the same situation. At the risk of over-stating myself, I have found I am fairly good at getting to the core issues when looking at a process. Becoming a little more concious about it will, first, let me be better at it and, more importantly it will allow me to be much better at teaching others to do it.
  2. Tying back to #1, we teach this wrong. We teach people to look for “waste.” We teach them to look for ways to “make the process better.” We are always measuring “what could be” from a baseline of “what is.” This is totally backwards.

What we should be doing is measuring “what is” from a baseline of “what is perfect?”

What is the difference? I think it is important on a couple of levels. First is simple engagement of the workforce.

Ask someone “How can we make your work better than it is?” And the question carries all kinds of baggage. It says “Obviously you don’t do it as well as you could.” Whether or not it is meant this way is irrelevant. That is how it, all too often, comes across. The common symptom of this thinking is when you hear “This is as good as we can make it.”

Ask, instead, “Where is this process imperfect?” or “What gets in your way of doing this perfectly?” and you disarm the above objection. Anyone who works in the midst of complexity encounters dozens or hundreds of things every day that must be worked around or somehow coped with. All of those things take time, effort, energy, and each decision about how to handle something unforseen brings in the possibility of getting it wrong – making a mistake.

Think about it – how many mistakes result from someone just trying to figure out what should be done to correct some kind of anomaly, and making the wrong judgment?

Over the next few posts I am going to continue to beat these concepts to death from different angles. Forgive me in advance – it is my way of exploring it in my mind, and I am using you, the reader, as a sounding board. Writing things down forces me to think about them in more detail.

Posted on

Toyota falls short of GM in global sales – Yahoo News… So What?

Toyota falls short of GM in global sales – Yahoo News

This news article is interesting, because it totally misses the point.

First, in the fine print, Toyota fell short of GM, yes, by about 3,000 total cars out of about 9.3 million cars. So, in my book, that is a tie because +/- a couple of thousand out of nearly 10 million is just noise.

But what is missed is the bottom line – profit.

Take a look at the numbers that matter:

These results are not something that comes from a quarter-by-quarter strategy to “maximize shareholder value.” Rather they come from a consistent year-to-year pursuit of being an ever-better supplier to their customers.

So many companies equate top-line sales with success. Apparently the press does as well – assigning significant meaning to “total number of cars sold” without even mentioning the simple fact that one company is giving them away at a loss, and the other is actually making money.

Posted on

Upgrade and New Look

As you may have noticed, there is a new look. This is the result of finally getting around to upgrading WordPress, and the unintended consequence that the new version “broke” the theme I was using. So I finally found another theme (which is easier than rolling my own or dissecting someone else’s code to figure out the problem), implemented it, and here we are.

There are still a few glitches in the categories, etc. which I am cleaning up but basically it works.

If you see anything weird, please let me know (a comment to this post is fine).

Posted on

Lean in Health Care

A little over a month ago I had an opportunity to spend about 4 hours in a small-group session with Steven Spear. For those readers who don’t already know, Steve is a researcher and practitioner who has made his name in understanding the Toyota Production System as Toyota actually does it.

He first came to the attention of the “lean” community with the 1999 publication of Decoding the DNA of the Toyota Production System, a paper summarizing his PhD research and dissertation.

Since then he has become active in improving the health care system. I’ll leave a full bio to your Google skills.

While health care certainly has a lot of room for improvement, I think the rest of us have a lot to learn from experience and insights being gained in efforts to apply the TPS to health care.

I plan to put together the next few posts intertwining these topics. But first, I wanted to share some interesting performance numbers we heard from Steven Spear.

  • During a hospital stay in the U.S. health care system, the patient’s risk of being injured or killed by the efforts to deliver treatment are roughly on-par with the risks of base jumping. For those of you who don’t know, base jumping is jumping off ‘B’uildings, ‘A’erials, ‘S’pans and ‘E’arth and (hopefully) then parachuting to a (hopefully) safe landing without hitting the thing you are jumping from.
  • Hour-per-hour, you would be safer on an infantry patrol in Bagdad than staying in a hospital.

Now, before you start shaking your head and pointing out just how terrible this is, please consider:

  • As a product moves through your own system, what are the odds it makes it through absolutely unscathed and in perfect condition? Do you do any better than this?
  • If you were to study your own processes do you honestly think they are any more effective at delivering a defect-free outcome at each and every step?
  • Do you even know where, when, and why, those processes fail to deliver a defect-free outcome?

I would contend that most of us have no idea.

Posted on

Why I Don’t Like Two-Bin Systems

On the surface, a “two bin system” seems a great, simple solution to a part resupply process that could otherwise get complex.

And, on the surface, I don’t argue with that.

But two-bin has some limitations. And because it is so simple to set up, those limitations are frequently not understood or taken into account.

What is “Two Bin?”

Although it may be obvious to all, I want to define “two bin” to reduce the chance that what is “obvious” is actually less so.

“Two bin” is a simple pull system. The parts are supplied by two rotating containers. When a bin is empty, it is returned to the supplying process to refill. The second bin supplies parts while the first one is being filled.

The same system can be applied to things much bigger than “bins.” I have seen carts carrying fabricated steel parts weighing many hundreds of pounds set up the same way.

When does it work?

In general, two-bin is OK when two criteria are met:

  1. The parts are relatively cheap. That is you don’t worry too much about having more than you actually need. This comes with a warning, however. It is easy to have a ton of money tied up in relatively small excesses of hundreds of parts. It does all add up.
  2. This is critical: The time to replenish and return a full bin is short compared to the time to use the parts contained in a full bin.

In this scenario, the first bin is empty, and long before the Team Member has emptied the second bin, the first one is safely returned and is behind it on the shelf.

So What’s The Problem?

There are problems at two levels. I am going to emphasize the practical one, then talk about the philosophical one.

At The Practical Level

First, let me explain how this system would work if it were being done with kanban cards as signals.

One of the rules of kanban cards is that the card is removed from the container when the first part is consumed. That is, the container is NOT empty.

In this type of system, the number of containers circulating is +1 over the number of cards circulating. If you think about it, this makes sense. Let’s say there are five cards circulating, and the container size is 10. If all of the full containers were on the rack, and one part is used from the first container, then the rules state that the card is removed and signals bringing another bin.

If production stops at that point, the worst-case scenario of kanban is realized: The card is returned with another bin of 10 parts. There are now 5 full bins on the shelf, each with a card attached, plus the one bin of 9 parts.

What this has to do with two-bin: Two bin is mathematically identical to a one-card kanban loop.

At a practical level: Do the math for kanban. If your system, with your replenishment quantity and times won’t work with one kanban card, a two-bin won’t work either.

At a Philosophical Level

The problem comes in in practice. Two-bin is easy to set up, and frequently the people doing so don’t do the math. And it usually works.

What results is a pull system that has locked down the number of circulating containers (two), and if there are perceived problems the reflex is to alter the quantity of parts in each bin.

If the system is running a little close to the edge, the materials people will up the parts quantity per-bin from, say, seven parts to ten parts.

Then the system fails.

Why?

With kanban, you signal for replenishment when the first part is removed from the bin. Having more parts in the bin means it takes longer to empty the bin. Your supplier has more time to return with a full bin.

With two-bin, you signal for replenishment when the last part is removed from the bin. Having more parts in the bin means it takes longer to empty the bin. Adding more parts to the bin delays the notification to your supplier that you have started using parts.

While it doesn’t always happen, there are cases when adding even a few parts to the bins will cause two-bin to fail because of this.

No matter what system you use, you must thoroughly understand how it works, why it works. You must think through (and try) every step of the process, not just talk about it.

You must ask questions and understand every detail:

  • If there are hundreds of bins, and they all have part-specific labels, how will they be sorted and routed to the appropriate supplying process?
  • How will the bins be used to visually manage the replenishment process?

These are questions with obvious answers in card systems (that use generic bins), but are frequently not well thought through in the rush to implement the “simpler” circulating bin systems.
Also keep in mind: If you are not constantly monitoring actual use, execution and results against your assumptions and expectations of what should be happening, you might be using pull, but you are not applying the Toyota Production System.

So?

  • Go ahead and use two-bin if you want to. Just do the math and make sure it will work for you.
  • However, if you use cards, or other signals, anywhere consider the complexity you are introducing with more than one system. The rules are different depending on the parts. Remember, you are asking your customers to keep track of all of this.
  • Generally speaking, if your system is operating close to the edge, it is better to use more containers that are smaller. Things will circulate more quickly, and your supplying process will have a much better picture of your consumption patterns.
  • Remember – your objective is to move closer to single-piece-flow. If you move away from that (with bigger containers) you are doing the opposite of kaizen.
Posted on

Adventures in Airline Travel

Today I flew from my home in the Seattle area to New York’s La Guardia airport. This seems to nearly always be an adventure, but this one was unusual, so I wanted to comment on the customer’s perspective.

The flight routed through the airline’s major hub in Minneapolis (MSP) (so now you know which airline if you fly at all). No sooner than I had turned my cell phone on at the gate at MSP than it buzzed. I answered, and it was the airline’s computer talking.

I was informed that my flight from MSP to LGA had been canceled. This is never good news. I was informed that I had been re-booked on another airline (Midwest), and to contact the gate agent before going to the other airline’s counter. I was read a confirmation number, though sitting in an airline seat I really had no opportunity to write anything down, and was informed that all of the details were available on the airline’s web site – which is really no help unless I am on line in the airport. No big deal.

The gate agent is polite, lets me know that the other airline is “way over in Humphrey Terminal” and suggests another flight into Newark. “No, that’s OK, I want to go to La Guardia.”

I was much more concerned, at this point, about my luggage. Airlines, in general, do a reasonably OK job recovering from these things and getting people where they need to go. As a group, however, they don’t seem to “get” that it is important to the passengers (at least important to this passenger) that the luggage get there more or less at the same time I do.

I was cheerfully told that my luggage would be on their next flight to LGA, and I could pick it up “at my convenience.” This choice of words was interesting, it implied that I would easily just head back to the airport when my luggage got there.

One of the blind spots of all airlines is the illusion that the airport terminal is the final destination. Their job ends once they unload you there.

My only other option was to fill out a “missing luggage” claim with the secondary carrier (since they are responsible as the last airline I flew on), then they would get with the original carrier, arrange delivery to the hotel, etc. I pretty much resigned myself to having to go through that nutroll, and hoping beyond hope that it would get to the hotel overnight so I didn’t have to show up at Corporate HQ in “Seattle Casual.”

(I should relate the story of lost luggage when I had an 18 hour stay in Berlin sometime…)

Midwest Airlines flight 5 from Minneapolis to La Guardia stops in Milwaukee. When we arrived, we were informed this 30 minute stop was going to be a 2 hour stop due to “weather delays” in La Guardia. Not sure what that was about, the weather in La Guardia is beautiful tonight, but whatever. We actually got “release” after 1 hour, got on the plane, and headed east.

One thing I have to say – Midwest has a nice little niche service, and features “the most comfortable coach seating in the industry” by their claim. The seats certainly are nice, and I can’t complain about warm, gooey chocolate chip cookies either.

When I got to LGA, I thought “what the hell”, grabbed the shuttle bus and headed over to the NWA terminal to just see if they even knew where the luggage was. I arrived, was walking toward the luggage service office and there, coming out of the conveyor was my suitcase. How the hell that happened, I will never know. I picked it up, headed out of the terminal, caught the shuttle to the rental counter, waited behind the couple who could not rent a car because HE had the credit card and SHE had the driver’s license, got my car, and here I am.

Short Story: Somtimes good customer service happens purely by accident. It shouldn’t, but sometimes it does. Of course, the airline industry does a very good job of managing my expectations (i.e. keeping them low). I am always pleasantly surprised when they manage to deliver what they minimally promised.

Note To The Airlines: I try to not be one of those people who abuses the carry-on rules. If I have too much stuff, I check it. However – as a customer, it is important to me to arrive with my luggage. Sometimes that it more important than getting to the destination as soon as possible.

Posted on

Really Long Takt Times

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted on

Systematic Problem Solving

If I were to look at the experience of the organization profiled in the last three posts “A Systematic Approach to Part Shortages” I believe their biggest breakthrough was cultural. By applying the “morning market” as a process of managing problems, they began a shift from a reactive organization to a problem solving culture.

I can cite two other data points which suggest that when an organization starts managing problem solving in a systematic way, their performance begins to steadily improve. Even managing problem solving a little bit better results in much more consistent improvement and less backsliding. Of course my personal experience is only anecdotal. That is certainly true by the time you read it here as I try to filter things. But consider this: The key difference with Toyota’s approach that Steven Spear pointed out in “Decoding the DNA of the Toyota Production System” (as well as his PhD dissertation) was that the application of rules of flow triggered problem solving activity whenever there was a gap between expected and actual process or expected and actual outcome.

Does this mean you should go out and implement morning market’s everywhere? Again, based on my single company data point, no. That doesn’t work any more than attaching kanban cards to all of your parts and calling it a pull system. It is not about the white boards, it is not even about reviewing the problems every day. Reactive organizations do that too. In most cases in the Big Company that implemented morning markets everywhere, that is what happened – they morphed into another format for the Same Old Stuff.

Here are some of the things my example organization did that I think contributed to success in their cultural shift.

  • They separated “containment” and “countermeasure” as two separate and distinct responses. This was to make sure that they all understood “containment” is what is done immediately to re-start production while preserving safety and quality. “Containment” was not a countermeasure as it rarely (if ever) actually addressed the root cause. It only isolated the effect of the problem as far upstream as possible. The rule of thumb was simple:
    • Containment nearly always adds time, cost, resources, etc.
    • A true countermeasure nearly always removes not only the containment, but reduces time, cost, resources.
  • They didn’t use the meetings to discuss solutions. They only addressed two things:
    • A quick update on the status of ongoing problem solving.
    • A quick overview of new problems from yesterday.

I think this is an important point because too many meetings get bogged down with people talking about problems, and speculating what the causes are. That is completely non-productive.

  • The actual people working on problems attended the meeting. I cannot over-emphasize how important this is. They did not send a single representative. Each person with expected activity reported his or her progress over the last 24 hours. It is difficult to stand in front of a group and say “I didn’t do anything.”
  • They blocked out time to work on problems. I probably should have put this one first. The manufacturing engineers and other professional problem solvers agreed not to schedule anything else for at least two hours every morning. This time was dedicated to working on the shop floor to understand the problem, and physically experiment with solutions. There was a lot of resistance to this. But over a couple of months it became close to the norm. It helped a lot because it started to drive the group to consider where they really spent their time vs. what they needed to get done. There was no doubt in the past that solving these problems was important, but it was never urgent. Nobody was ever asked why they weren’t working on a shop floor issue. That had been a “when I am done with everything else activity.” Gradually the group developed a stronger sense of the shop floor as their customer.
  • They didn’t assign problems until someone was available to work on them. This came a little later, when the problem-solvers were missing deadlines. The practice had been to assign a responsible person in the morning when the problem was first reviewed. Realistically a person can work on one problem a time, and perhaps work on another when waiting for something. They established a priority list. The priority was set primarily by manufacturing. When a problem-solver became available, the next item on the list was assigned. Once a problem was assigned, nothing would over-ride that assignment except a safety issue or a defect that had actually escaped the plant and reached a customer.
  • They got everyone formal training on problem solving with heavy emphasis on true root cause. People were expected to follow the method.
  • A problem was not cleared from the board until a long term countermeasure had been implemented and verified as working.

By blocking out time, they were able to establish some kind of expectation for productivity. After that, if problems were accumulating faster than they were being cleared, they knew they had a methods or resource issue. The same was true for their other tasks which were worked on during the rest of the day.

This was the start of establishing a form of standard work for the problem solvers.

21 Oct 08 – There is more on the subject here and here

Posted on

A Systematic Approach to Part Shortages – Part 3

The third element of this organization’s successful drive to eliminate part shortages was a systematic approach to problem solving. They made it a process, managed just like any other process, rather than something people did when they had time. Even though this is “Part 3” of this series, in reality they put this into place at the same time, and actually a little ahead, of kanban and leveling.

The Morning Market

The idea of the “morning market” came from a chapter in Imai’s book “Gemba Kaizen.” He describes a process where the previous day’s defects are physically set out on a table and reviewed first thing in the morning – “while they are fresh” hence the analogy to the morning markets.

This organization had been trying to practice the concept of a morning market for a few weeks, and was beginning to get it into an actual process. Because supplier problems constituted a major cause of disruption, they set up a separate morning market for defective purchased parts.

That process branched yet again into a morning market for part shortages. And this evolved into a bit of a mental breakthrough.

They started looking at process defects.

Every shortage, every day, was recorded on the board.

Each morning the previous day’s shortages were reviewed. They were grouped into three categories based on knowledge of the cause – just like outlined in the book.

  • “A” problems – they knew the cause, knew the countermeasure, but had some excuse reason why it could not be implemented right away.
  • “B” problems – they knew the cause, but did not have a good countermeasure yet.
  • “C” problems – knew the symptom (parts weren’t there) but didn’t know why.

The mental breakthrough was systematically investigating the reason each and every shortage occurred. What they found was that in the vast majority of cases it was an internal process breakdown, rather than some problem at the supplier, that caused the shortage. This was a bit of a revelation.

They began systematically fixing their processes, one problem at a time.

Over time things got better. Simultaneously they were implementing the kanban system. Kanban comes with its own set of possible problems, like cards getting lost. Once again, when they found problems they went into the morning market and were systematically addressed.

After a few months into their kanban implementation, for example, they started turning in card audits with far less than 2% irregularities, and then it was not unusual for a card audit to find no problems at all. Why? They had addressed the reasons why cards end up somewhere other than where they should be. Instead of blaming people, they looked for why people acting in good faith would not follow the process.

This was also an attitude shift – assume a flaw in the process itself, or in communication, before looking for “who did it.”

Eventually the warehouse team had their own morning market. As did the receiving team. As did the parts picking team. As did assembly. Each looked at any case where they were not able to deliver exactly what their downstream customer needed.

About 8 months into this, another group in an adjacent building, was trying to work through their own issues. They came over for a tour. One of the supervisors, visibly shaken, came to me and said

“Now I get it. These people work together in a fundamentally different way.”

And they did. They worked as a team, focusing on the problems, not on each other.

And that, readers, is the goal of “lean manufacturing.” If you aren’t working toward that, then you aren’t really implementing anything.