Month: August 2007

Posted on

Think From The Customer’s Perspective

I was browsing my web email, and I saw an ad for web hosting. The ad was actually set out pretty well because I remember the two pieces of key information: Web hosting for $9.95 a month (free domain, etc.) and the prominent text on the ad: “Superpages.com”

Well, I suppose the ad authors can be forgiven if I didn’t click through the ad. Instead, I typed “superpages.com” into my browser.

The page so prominently called out in the ad carried not even a hint that superpages.com offers web hosting. And by now the ad was no longer displayed.

I typed “superpages” and “web hosting” into the search engine, and found a news article that repeated a 2005 press release. About 2/3 of the way down, it mentioned “my.superpages.com” so I tried that.

There is a mention on that page of web hosting, but it took two more clicks to finally get a page that mentions any details. I stopped at that point.

A couple of things come to mind here.

First – take the perspective of your customer, or better, find someone who doesn’t know the details or designer’s intent of your system and have them navigate it in unexpected ways. Just how many obstacles do you throw in front of the customer who wants to buy your product? How much digging must the prospective customer do in order to get basic information?

Second – and this is much harder – take the perspective of your competitor’s customer. Go buy their product. Experience what their customers experience. Don’t rely on market surveys, go and see for yourself. (“genchi genbutsu”)

What if:

Airline executives bought tickets through their own web site, rode in coach, and checked in just like everyone else – every time, not just as an experiment. They need to be a “frequent flyer” just like the very customers they are trying to retain. What if those same airline executives had to do 50% of their travel on competitor’s airlines? In coach, waiting in the same lines as everyone else.

Do you think it would be interesting for an executive of a prominent red-tailed airline to know that the “elite” line for check-in is much slower than the regular one? Or that they mix re-booking for a canceled flight in with first-class check-in and slow the process to a crawl? What would be that airline executive’s experience if he were to wait in line and just listen to his customers talk to each other? (He would hear the complaints nobody bothers to make because they think nobody cares.)

What would that airline executive’s experience be if he sat in the seat across from the flight attendant who lets all of the customers know what a terrible place his airline is to work. (I have had this experience twice, with the same flight attendant, but I fly a lot.)

What if Ford executives were directed to buy and drive….. Toyotas, and get them serviced at their local dealer just like everyone else. Would they learn anything? Not that Toyota is perfect, certainly their U.S. dealer network is pretty much just like everyone else’s. But that Ford executive might just find a weakness to exploit. What kind of car does Alan Mullally drive? What if auto executives had to buy their cars from heavy-handed closers just like everyone else?

But all of us frequent flyers can laugh about the airlines. What about your company? Do you really know what your customers experience?

Market surveys just don’t do this. They aggregate, consolidate, take averages, and generally dull the senses to what is really happening.

Go and see for yourself.

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