Lean Dilemma: System Principles vs. Management Accounting Controls

Today I came across an article called Lean Dilemma:Choose System Principles or Management Accounting Controls, Not Both by H. Thomas Johnson.

It is, or it should be a thought-provoking read, especially for a CEO or other senior manager.

The author also wrote “Profit Beyond Measure” which I have not read, but based on this article, I will.

My personal challenge question is: What is the ROI on an environment where people work so well together that no detail is overlooked? It is, of course, impossible to calculate. Nevertheless, no one would argue that such a company would be a formidable competitor in any market.

Perhaps what you measure is what you get.
More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.

Today the mantra of “Sarbanes-Oxley” is being used as justification to plant, fertilize and cultivate a garden of chokeweed that will embrace and strangle any attempt to streamline processes. I have run into the same “regulations won’t allow it” excuse in the aerospace industry (“the FAA won’t allow that”), in health care products (“the FDA requires this”), and, believe it or not, in ISO-9000 registrations. (“That violates ISO”) Of course, in every case, it was a smoke screen.

Once the assumptions are challenged, and the actual requirements are studied and understood, there is always a way to comply with the letter and spirit of the requirements with minimal (or no) waste. The problem comes in when people confuse the requirements themselves with the policies of the company to implement them. Those policies can be changed with the stroke of a pen, sometimes followed by convincing an auditor that the new way is better.

But I digress. Toyota operates in the USA and is subject to exactly the same regulations and financial securities laws as everyone else – yet, somehow, they manage to operate without these things as justifications for the status quo.

Read the article – tell me what you think.

Edit – 9 August – Someone pointed out to me that there are people who are turned off by Johnson’s environmental stewardship message toward the end of the article. My view is that intelligent people should be able to read the article and agree or disagree with that message, while still “getting” the core message: Traditional management accounting controls damage shareholder value.

Art of Lean

Art Smalley has a fantastic web site called Art of Lean.

I highly recommend it to anyone who is looking for “where to begin.”

Pay special attention to the e-learning piece on “Basic Stability.” This is where the money is, folks. Most of the waste (probably almost all of the waste) in your operation today is the result of inconsistency and variation. If you can get the daily problem solving engine started and systematically attack sources of variation in your operation every day, you will probably double your productivity over a couple of years. Is that worth it? I didn’t make that number up. I know a plant that got just those results and did nothing more than attack variation to get there.

Is The MRP Algorithm Fatally Flawed?

(Links updated Feb 24, 2010)

Robert Johnston, now at the University of Melbourne   holding the John Skarkey Chair of Information Systems and Organisation at the UCD School of Business in Ireland, did his PhD work at Monash University in Australia. His dissertation, “The Problem With Planning” presents a thought provoking thesis.

– Early robotics and computational intelligence models were built on a model which research at MIT debunked as unworkable in the 1980’s.

– The MRP algorithm uses the same model.

– Therefore, MRP is also unworkable.

Further, his dissertation goes on to postulate that the successful models currently being exploited by the latest research at MIT (which, by the way, are commercially exploited by the Roomba) share many similar characteristics with kanban systems.

I will extrapolate a bit and comment that kanban systems are a subset of a general shop floor information management model that is outlined in “Decoding the DNA of the Toyota Production System” by Spear and Bowen. Johnston’s work pre-dates Spear’s publication, so it is not referenced, but if you actually read Spear’s dissertation you can see the similarities in the details.

And yes, when I wrote to Dr. Johnston his first comment back was surprise that someone had actually read his dissertation. Take a look. Chapters 1-5 are mostly theoretical background and history. The interesting part starts at Chapter 6.

Hoopla – Another Quality Story

As I said in a previous post, I am spending the majority of my time in China right now.

As part of his preparation for attending a corporate class, one of my kaizen specialists was reviewing some of the training materials. From the other side of the cubicle wall he asks “What is ‘hoopla?” Although his English is very good, he is Chinese, and “hoopla” just isn’t a word that they teach in the universities.

Now I know for sure he is not the first non-native English speaker to read that material, and I also strongly suspect many before him did not know what “hoopla” means. But the others just made a guess from the context and kept reading.

Derrick, though, applied the first two steps of jidoka – he Detected a problem – something wasn’t right, didn’t meet the standard, or seemed to be in the way. Then he Stopped the process, and called for assistance. Instead of guessing what to do, the Team Member pulled the andon (got his Team Leader’s attention) and pointed out the problem.

The standard in this case is that the person reading the material can understand it, or at least understand the words that are not specifically being explained by the material. In this case, that didn’t happen. “Hoopla” was not understood, so the andon was pulled.

The third step is Fix or correct the problem, restore the standard (without compromising safety or customer quality in any way) and re-start the process. I explained what “hoopla” means, and Derrick could keep reading.

The fourth step is Investigate the Root Cause, Apply a Countermeasure. I sent an email to our training developer and mentioned what has now become “the hoopla incident.” The ensuing discussion among the training developers has resulted in a set of standards and guidelines for writing materials. Among other things, it calls out the need to avoid idioms and slang that might not be understood by non-native speakers. It also addresses other issues which will both make the materials easier for non-native speakers to read and make it easier for translators working to port the material to German, French, Spanish or… Mandarin.

W e should have some hoopla! The process worked – all because someone called out something he didn’t understand instead of just dealing with it on his own.

A Quality Story

On a cloudy morning a few years ago I started my truck, turned on the headlights and noticed one of them was not working. While changing a headlight isn’t that big a deal, I needed a state safety inspection anyway, and I really didn’t want to mess around under the hood.

So I called the auto repair and tire place up the road, and arranged to come in.

When I got there, I explained that the right headlight was out. Since I knew from experience that the left one would probably fail in a few weeks, I said “Go ahead and change the left one too, and I need the state safety inspection.”

Unfortunately they only had one headlight in stock, so they couldn’t change both, I said OK and got a soda to wait.

A while later, everything was good-to-go, I drove back to work and went home that evening. The next day was sunny.

The following day, however, was cloudy again. I turned on the headlights in the garage, and the right headlight was still out. Hmmm. I took a quick look and noticed that the LEFT headlight was new. They had changed the wrong one.

When I got back to work, I called the shop, explained the issue, and they said come over and they would make it right. (Meaning they would replace the RIGHT headlight at no charge.) After handing the keys back in, the mechanic who did the work came out and tried to convince me that he had simply followed the instructions, and it wasn’t his fault.

OK — let’s break down this situation from the perspective of quality and delivery.

Starting from the end of the story, why did the mechanic feel obligated to try to convince me that I had responsibility for a mistake that the owner had already agreed to correct? What could possibly be gained by trying to make the customer feel wrong here?

Now let’s go back to the beginning.
Customer reports a headlight is out. What is the very first thing you would do? How would you confirm the problem?

Turn on the headlights and check. This takes about 10 seconds. If there was a confusing communication about the problem, this is the time to discover it.

Once the repair has been completed, how would you confirm that it worked?
Turn on the headlights and check. This would verify that the results were as intended. (What does the customer need here? Two headlights that work.)

The other item that was on the instruction was a state safety inspection. Now I am not an expert on the New York State safety inspection, but I am willing to bet at least a can of soda that it includes the headlights. So as part of that inspection, the mechanic should turn on the headlights and check.

Even if the problem had gone undetected up to this point, it should have been caught here. Obviously the “inspection” was just a paperwork drill in this case.

Of course, as the customer, I also failed to turn on the headlights and check when I picked up the vehicle. Silly me.

What is the point of all of this?

The first step of solving any problem is to understand or verify the current condition and compare it with your expectations or standard. (More about standards and expectations later.)

Once a countermeasure had been developed and put into place, the situation must be re-checked to ensure that the countermeasure worked as intended and the process or system is back to the standard condition.

Any process has some kind of intended result. In this case, the headlight repair process should result in two headlights that work. Yet the results were not verified, and the incorrect product was delivered to the customer.

So what did all of this cost?

It cost me my time.
It cost the repair place

  • Double the mechanic time.
  • A headlight +the time to go get one during business hours (because they had not replaced the one they installed on the left two days earlier).
  • Good will. (Later, when they failed to tighten the filter after an oil change, I stopped doing business there altogether. One mistake I was willing to overlook, but I was starting to see a trend developing. I also later had some extensive maintenance and repairs done on the truck, but I didn’t have them done there because I could not trust them to change a headlight or change the oil.)

By the way, I still have the truck. It is coming up on 200,000 miles and runs great.

Back in China

At the end of the last post I promised to write more when I was over the jet-lag of returning from three weeks in China. Well.. I didn’t, and how I am back over here.

While I was in the USA I took some time off, or at least I did during my “day job.” Since I live near Seattle, it is 5:00 pm there when the people here in China get to work and the Blackberry starts buzzing. Thus I am on and off email until either: Things get quiet long enough for me to just decide to go to sleep or 2:00 am when they end the workday here at 5pm.

For better or worse, my approach here has been to try to establish from the beginning a sense that we don’t wait for an “event” to study a process and look for improvements. Instead, we study and improve every time we do it. I am trying to instill a culture that continuously compares “what is happening” vs. “what should be happening” and acts whenever there is a gap.

Overall, however, I find the main role here is to get the right people equipped with the right skills and tools, and ensure they are working on the right things, then supporting them.

“Working on the right things” means taking responsibility for what is not going to get done right now rather than assigning a dozen “#1 priorities.”

The Essence of Just-In-Time

The Essence of Just-In-Time

This is a working paper by Steven Spear of Harvard Business School. Spear’s PhD work was summarized in a landmark and well-circulated Harvard Business Review article titled “Decoding the DNA of the Toyota Production System.” I will leave it to the reader’s Google savvy to turn up the DNA article for yourself.

This working paper is much more raw than a finely edited HBR article. But it gets to the core research and conclusions without any fluff.

As you read it, compare what is described here with the focus of your own implementation.

Do you find any gaps?

I’ll comment more myself when I am not totally jet-lagged… I just got back from China. 😉

5 Seconds Matter

I was with the factory’s kaizen leader, and we were watching an operation toward the end of the assembly line.The takt time of this particular line was on the order of 400 minutes, about one unit a day. The exact takt really doesn’t matter, it was long compared to most.

One of the Team Members needed to pump some grease into a fitting on the vehicle he was building. But his grease bucket was broken. We watched as he wandered up the line until he found a good grease bucket, retrieved it, went back to his own position and continued his work. The entire delay was much less than a minute. No big deal when you compare it to 400+ minutes, right?

Let’s do some math.

There are six positions on this particular line. Each one has two workers, a few have three, for a total of 14.

What if, every day, each worker finds three improvements that each save about 5 seconds. That is a total of 15 seconds per worker, per day. Getting a working grease bucket would certainly be one (maybe two) of those improvements. (Consider that the worker he took it from now doesn’t have to come and get it back!)

That is 14 workers x 15 seconds = 210 seconds a day.
210 seconds x 200 days / year = 42,000 seconds / year.
42,000 seconds / 60 = 700 minutes
700 minutes / the 400 minute takt time = we are close to having a line that works with 12 instead of 14 workers.

What is that grease bucket really worth?

Of course your mileage may vary.

But how often do you pay attention to 5 second delays?

Of course getting the grease bucket is really just simple 5S — making sure the Team Member has the things he needs, where and when he needs them.

So how would 5S apply in this case?
Mainly a good visual control would alert the Team Leader, or any other alert leader, to the fact that the grease bucket is out of place. A good leader will see that and ask a simple question:

Why?

And from that simple question comes the whole story, and an improvement opportunity.
But in order to ask “Why?” there must first be recognition that something isn’t right. And this is the power of a standard.

The Chalk Circle – Continued

Yesterday I wrote a little about my own experience with Taiichi Ohno’s “chalk circle” as well as some stories I have gathered from others during the years.

Although the insights I got from Iwata-sensei changed my perspective, it was some years later that a few other things got solidified.

My colleagues and I had been hired as a team of “experts” to help a major household-name company implement “lean manufacturing” into their production and logistics processes.

A couple of years into the effort, it was still a struggle.

Although there were a lot of kaizen events happening, it was a continual battle to sustain the results. We were quickly reaching the point where 100% of our effort would be expended simply re-implementing areas where we had already been. That is the danger point when forward progress stops and the program stalls.

Of course we were busy lamenting about the “lack of management commitment” to support and sustain the great work these teams were doing.

The next week we were around the table trying to figure out a countermeasure.

First we had to understand the problem.

As we talked and shared, we discovered that each of us had one area, a single operation, that was showing better results than the others. Operationally, these areas were actually quite diverse. What did they have in common?

Each of them was the area under our respective responsibility that had the weakest or no internal infrastructure for kaizen events. In fact the most successful implementations were happening in the operations that held the least number of week-long kaizen events.

Needless to say, that realization was interesting. So what else did they have in common?

Because we did not have our internally trained people leading kaizen in those areas, we were coordinating and leading the effort personally. One of us, not someone we had trained, was guiding those areas through their implementation.

Why were our results different than the people we trained? What did we do differently?

As we talked, we found that we all would take the line leaders, the managers, the people responsible, to their shop floors, and teach them how to spot problems and what to do about it.

We would stand with them, observe something happening, and ask “What do you see?” We would continue to ask questions until they saw the things that we did. Then we would begin asking about causes. “Why does this happen?” Our objective was to teach the leaders to be intensely curious about what was going on, to compare what they saw against a picture in their mind of an ideal state, and further be curious about why there was a difference.

We paid attention to progress, focused their attention into areas that needed work, and always, constantly, asked questions.

  • “What is supposed to be happening here?”
  • “What is really happening?”
  • “Is that really what you want?”
  • “Why is there a difference? What is in the way?”
  • “Does the Team Member know what to do? How do you know? How does he learn?”
  • “Is this process on track? How can you tell?”
  • “How many are supposed to be here? Why are there extras?”
  • “Why is no one working here? Where did they go?”

Not because we wanted answers, but we were teaching them the questions.

These are the same questions that Iwata-sensei was asking me years earlier.
It was an insightful and team-building moment when we realized that, in spite of our diverse backgrounds (we had not met prior to working here), we all approached things pretty much the same way. The second insight was that, in spite of our diverse backgrounds, we had all learned pretty much from the same teachers, and those teachers had been taught directly by Ohno.

If a line leader “got” what we were trying to get across, they wouldn’t ever see their operation the same way. They would be constantly comparing what they saw (what is actually happening) against some kind of expectation or standard — explicit or implicit — or against an ideal state (what should be happening).

They would see any gap between what should be happening and what was actually happening as a problem to be addressed and at the minimum, corrected.

They would begin to ask different questions of their people, and manage activities toward identifying these gaps and closing them.

Our question to ourselves was: If this worked so well, what did we have everyone else doing?

When we asked this, Dave stands up and starts through his certification program to teach his kaizen leaders how to

  • Present the various training modules
  • Prepare the various forms and reports
  • Organize kaizen events

Then someone, I don’t remember who, asked “Who is teaching the leaders how to manage the new system?”

A long pause followed.

Then Dave said, “oh shit.”

Maybe Dave said it, but we all thought it.

We had started happily blaming the leaders. Then we realized no one was teaching the leaders. THAT was our fault. We weren’t teaching anyone to teach the leaders. Now the question was “What do we do about it?”

Now we understood the current condition and the gap we needed to close.