Author: Mark

Posted on

Hidden Negative Consequences

“Stop the line if there is a problem” is a common mantra of lean manufacturing. But it is harder than first imagined to actually implement.

The management mindset that “production must continue, no matter what” is usually the first obstacle. But even when that is overcome, I have seen two independent cases where peer social pressure between the workers discouraged anyone from signaling a problem. The result was that only problems that could not be ignored would come to anyone’s attention – exactly the opposite of the intention.

Both of these operations had calculated takt time using every available minute in the day. (Shift Length – Breaks etc.) Further, they had a fairly primitive implementation of andon and escalation: The line stop time would usually be tacked onto the end of the shift as overtime. (The alternative, in these instances, is to fall behind on production, and it has to be made up sometime.)

So why were people reluctant to call for help? Peer pressure. Anyone engaging the system was forcing overtime for everyone else.

Countermeasure?

On an automobile line, the initial help call does not stop the line immediately. The Team Leader has a limited time to clear the problem and keep the line from stopping. If the problem is not cleared in time, the problem stops the line, not the person who called attention to it. This is subtle, but important. And it gives everyone an incentive to work fast to understand and clear the problem – especially if they know it takes longer to clear the problem if it escapes down-line and more parts get added on top.

There are a number of ways to organize your problem escalation process, but try to remember that the primary issue is human psychology, not technology.

Posted on

Be Sure: What Are You Trying To Accomplish?

And how will you know you have accomplished it?

This article on Tech Republic is about defense against a hacker strategy called “Social Engineering” wherein the hacker uses a ruse to gain someone’s trust. The goal (for the hacker) is to leverage human nature and get information or access.

So what does this have to do with lean thinking?

It emphasizes the nature of policies with unintended consequences. I have seen all kinds of environments where a Team Member would suffer negative consequences for doing the very thing required to assure safety, quality, delivery or reduce costs. Never happens in your company, right? The examples in the article are mainly in items (2), (3), and (4).

I especially like (4) where the hacker poses as a person in power and simply intimidates the Team Member into giving him the information he wants. What is the countermeasure?

Strict policies and procedures created to discourage this kind of bullying. If it’s allowed from management, someone engaging in social engineering will be able to employ it.

Think about it. If someone abusing his authority is normal behavior, then your Team Member will not be able to detect this condition something out of the ordinary.

In another context, if a Team Member is routinely told “We’ll fix it in inspection” or to otherwise ignore a defect and allow it to pass on, then he will quickly stop reporting them.

Think through the behavior you want people to exhibit. Then, study (stand in the chalk circle again) and see for yourself what the actual behavior is. If it is different than what you expect or what you want, start asking the 5 Why’s. What people do every day is the norm of your organization. It is the path of least resistance. If you want people to do something different, then you must make the right way the easiest way.

This accomplished by a combination of mistake-proofing, policies and procedures that support people who do the right thing, and continuous two-level checking by leaders to reinforce and encourage.

In Item (2) in the article, the author talks about the “I don’t want to get in trouble” excuse. In his example, there is a negative consequence for reporting a lost or misplaced ID badge, so everyone works to avoid reporting the problem. Perhaps the intent was to have people pay more attention. As Deming said, you must drive out fear, and this isn’t the way to do it.

Remember: The right process will produce the right results. Think:

What results are you trying to accomplish? How will you know you have accomplished them? (How will you check or verify your results?)

The more clear you are on the target condition, the better equipped you are to think through how you will achieve it. When dealing with people, it is easier than you think to build negative consequences for the very thing you want them to do.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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

Posted on

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

Posted on

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.