Another Customer Story

I was in a newly opened store of a large big-box outdoor sports store, and saw an item on display that I had already decided to buy this summer. The displayed price was actually a bit less than what I had been encountering online, so I went ahead.

Unfortunately the one “in stock” on the shelf turned out to be a different model (in the wrong slot), and I didn’t complete the transaction. (A retail nightmare, where the customer clearly wants to buy a big-ticket item you thought you had, but actually didn’t.)

The salesperson behind the counter offered that I could order the item from their web site, have it shipped to the store, and I could pick it up without incurring any shipping charges. Seemed fair enough.

I went online, but the online price was higher than the in-store price. In a sort of reverse from the story I told in December, I emailed customer service and asked if they would match the in-store price for the item.

In a few minutes I got a reply, with an “Incident Number” that said they would, but I would have to call in the order to the 800 number.

All well and good.

I called, and of course “catalog sales” had to refer me to customer service.

Customer service, in turn, had no way to look up the “Incident Number” on the email. “I don’t have any way of referring to that…” (Yeah, go ahead and tell the customer what you can’t do.)

I was referred to someone else (in email? I don’t know). He could not look up the number either, so I read the email exchange back to him. He honored the price, took the order, and it is on the way.

But really?

What is the “incident number” even for if nobody can reference it? In this day and age of networked and cross-linked everything…. what can I say? Perhaps my old I.T. background showing here.

Bottom line:

Turn around and face your systems from the customer’s perspective. Spend some time in the chalk circle. Think through how your process responds to unusual situations.

If a customer refers to something that you should know about your own process, but don’t, there is a kaizen opportunity here. You have an obstacle in the way of smooth seamless customer service. What concrete steps(s) will move you toward eliminating that barrier and smoothing things out?

Scrap Bin Kaizen

If you are in a production operation, be it a factory or even administration, take a look in your scrap bins (or trash cans). What you find there can be very informative.

Is all scrap treated the same? In a lot of metal working operations, I see routine drop scrap mixed in with scrapped parts and products – things that were not intended to end up there.

If that is the case, what does it tell you about the attitude around scrapping a part? Is it routine, just part of getting the job done, like drop scrap?

If you find a scrapped part, can you find the defect or flaw that caused it to be unusable? How much work (and cost) was added after that defect was created? All of that is additional cost that added no value.

Was it painted? Partly assembled? Did it go through a bottleneck operation and consume capacity of the entire factory?

What about your trash cans or recycle bins in the office?

Do you see signs of frequent paper jams in printers and copiers? These events suck time away, and more than just the time to clear them. They cause a mental shifting of thought pattern away from the productive work that takes additional time to recover.

Here are a couple of thoughts.

Separate the routine drop scrap from bad parts that were supposed to be good parts. If you sacrifice parts to adjust in changeovers, separate those out into their own category.

Each of these is a different line of inquiry starting with the question “Why?”

Consider taking your bad parts from the last 24 hours and bringing them to a central location (or a location in the department). Conduct a “morning market” and get to the bottom of at least a couple of the root causes. You don’t have to solve all of them at once, just pick one and drive it to ground. Then another.

Scrap is not simply a material and time waste. It is a reflection of how well you really understand your processes.

Simple Solutions

Carlos Villela’s blog has a great story about simple solutions. I really have no idea if it is true or not – indeed, a couple of the details don’t hang together. On the other hand, I have seen for myself the kind of thinking that is described in this story.

Link to full story: Networks are smart at the edges.

The factory is having a quality issue. The response is pretty typical:

The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.

And a great solution. It stops the line and forces someone to pay attention to the problem. While I would usually add that these instances need to be followed up by problem solving to eliminate the issue, even if I were doing so, I wouldn’t eliminate the final verification check. Even Toyota performs a thorough and rigorous final inspection. But that’s not the point here.

It turns out, the number of defects picked up by the scales was 0 after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the precision scales were installed. A few feet before it, there was a $20 desk fan, blowing the empty boxes out of the belt and into a bin.

“Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.

Like the Dilbert cartoon about 25 critical focus areas, this is more funny because the original reaction is totally typical, especially in companies who are comfortable with technology, controls, automation, etc.

Cudos to the CEO who realized, at least, that “No problem is a problem” and went to investigate at the actual gemba.

Once the team had a challenge (in this case small-Peanut-MMsprovided by the annoying bell) they dealt with what they saw as the issue.

Oh – and this graphic? It is an inside joke for some of my readers. Maybe we should have put some fans on the conveyer.

Thanks to Hal for sending the original link to this article.

NPR: Hospitals New Face Pressure to Reduce Infection Rates

This article on NPR is chiefly about the dilemma that hospital administrators are facing as escalating government reporting requirements are being tied to their Medicare payments. (For my non-US readers, Medicare is the U.S. government medical insurance program for seniors and retirees. It pays a huge portion of hospital’s revenue, and thus, its policies carry a lot of weight).

The article’s lead does a good job of summing up the issue:

Under laws in more than two dozen states and new Medicare rules that went into effect earlier this year, hospitals are required to report infections — risking their reputations as sterile sanctuaries — or pay a penalty. That’s left hospital administrators weighing the cost of ‘fessing up against the cost of fines.

So, in effect, the administrators are faced with weighing the financial impact of lost Medicare payments vs. the financial impact of telling the truth about their infection rates. This is, in my mind, yet another symptom of the General Motors style of management that is taught by every MBA program in the world.

It also suggests that there is a viable alternative of continuing to maintain the illusion that it is not a problem.

Is it a problem? Hospital infections kill about 90,000 people a year in the USA. Compare that with the 40,000 or so that are killed in traffic accidents, and you get the idea.

Add to that the fact that the patient ends up getting billed (and usually insurance pays the bulk) for the treatment of these infections.

Fundamentally this is about quality, and the problem is certainly not limited to health care. (it is just that lives are at stake)

How does your company respond when there is a known issue that is impacting quality?

If you deliver a defective product or service, do you charge your customers for the rework? This is not a facetious question. Some companies do.

Do you avoid collecting information for fear of revealing the true magnitude of a problem?

Do your workers fear bringing it up when they are directed to carry out inappropriate actions, or actions which violate the company’s written policies and procedures?

Is it OK to improvise outside of your known process in order to get the part out the door?

Back to the hospital – we know how to tackle this problem. It is merely extremely difficult. That doesn’t make it impossible. I am glad it is getting attention. I am disappointed that it takes government generated threats of visibility to get action.

WWII Visual Control

PC posted a really interesting bit of visual control history in the forums. Click on the link to read his whole post, there is a second part about lack of visual controls.

In a recently aired episode of Showdown: Air Combat the host, a USAF fighter jock, asked about a series of colored stripes painted on a bit of sheet metal attached to the landing gear of a beautifully restored A6M Zero .

The piece of aluminum sheet is attached to the landing gear and fairs in the landing gear bay when retracted. The plane’s pilot/historian explained that they were an indicator for the ground (or deck) crew. As the landing gear’s hydraulic struts compress they align with the different stripes, allowing the crew to instantly see the load condition of the aircraft.

So for the cost of nothing more than a few square inches of paint they had an immediate, reliable, easy to use (from a distance, even), intuitive “mechanism” for the aircraft handlers to obtain critical fuel+ordinance info on the planes at any time.

While weight is always critical on an aircraft, it is even more critical on a WWII era aircraft carrier, before there were catapults. Where I can see this simple visual check becoming really valuable is if the crew spots one that is different than the others.

Here is a question – how can you adopt this principle to make a quick, visual weight check to assure, for example, that everything is in the package before it ships?


Rapid PDCA with 3P

“3P” is not a Toyota term. The workshop structure was taught by Shingijutsu and is now being propagated by people who learned it while working in their client companies.

The most visible characteristic of 3P, the Production Preparation Process, is the idea of creating quick and dirty mock-ups of the product and the process. These mockups are often constructed of wood, cardboard, PVC pipe – materials at hand.


The idea is to be able to quickly and cheaply try out, and experience, a process (or product) so that problems can be surfaced, opportunities for improvement can be seen, and the PDCA cycle can be turned far more rapidly than would otherwise be possible.

The purpose of the mockup is to create a gemba of sorts, where you would not otherwise have one. Now, rather than doing an abstract analysis, you have something that people can see, touch, and interact with. Doing so forces details to the surface that are simply invisible in abstract models in computers or on paper.

Some companies use the process to design their products as well as the processes that are used to manufacture them.

Last week one of my clients took their first steps into this process. The photo above has been pixelated so as not to reveal details about their product design.

They had done pretty extensive analysis using traditional industrial engineering methods, and had a CAD drawing of the proposed layout. That was the starting point.

The first step, then was to create that layout in real-size. That took the team about 90 minutes.

They assembled some tables, got some boxes and cardboard, and represented the machines, the work positions, the material and people flow.

Even as they were doing this, some of the team members saw things that they questioned, such as an ergonomically awkward operation. Others simply had questions. Why? Because in translating the drawing into the real world, even a superficial one, details already had to be resolved.

Once they had the starting condition mocked up, the team took prototype parts of the product and went through the motions of a team member trying to assemble it.

This felt a little awkward at first, but they began to see more opportunities, and resolve more detail.

We did a little coaching, pointing out motions that could be eliminated, others that could be consolidated. We talked about the smooth flow of people’s work, and looked for opportunities to better match the work flows to the takt time.

In the next couple of hours the team went through dozens of small PDCA cycles, each time adding a little more detail, adding a physical control, or a visual control. They found “knacks” that enabled quicker assembly with less adjustment.

They identified exactly how and where parts should be presented to the assembler.

They discovered small design and packaging changes that could make a big difference in the assembly time and quality. It did not hurt that the design engineer was trying to work out the details of one of the more awkward elements of the assembly.

They found key points that were critical to quality, examined the vulnerability to simple mistakes, and worked on how to make those more clear.


They identified characteristics that would help the machines better support the work flow. How do parts move in, move out? Where do the hands go to start the machine? How does the location of the controls support (or hinder) the work steps that come before and after?

As they looked at test operations, they started working out what they wanted to happen when there was a problem. They started to work out a line stop protocol and added andons to those machines, so they could signal an abnormal result.

Curious visitors, some senior managers, others just happening by and wondering what was going on, were enlisted as test subjects. Is the work cycle simple and clear? Is it easy to teach? Is the layout intuitive?

What can we do to make the visuals more clear, and to lay things out to guide the correct process sequence? Which “knacks” have to be taught? How quickly can a “new operator” be brought up to speed and make the takt time?

Over three days, the details came into sharper and sharper focus.

In the end, the team had constructed a full size model of their target condition. They are clear how the process needs to operate to give them the performance they want; and they are equally clear about the next problems that must be solved to get there.

They can specify their equipment with far more insight, and many of the details of how to guide the product and people through the process are now much better understood.

And, as a side benefit, this cross functional team has communicated far more than they would have otherwise with meetings and email. They have spent three days embedded in a joint project to envision what they want this to look like.

To be clear, a lot of work remains, and many more details remain to be worked out. But over three days this team now has a much more clearly aligned concept of what they are striving to achieve.

What Does Your Customer See?

Travel plans sometimes come together at the last minute. I went to the green company’s web site to rent a car, and got a message saying the site was down for maintenance.

It said to please call the 800 number if I wanted to make a reservation.

I called the number.

The nice person on the phone asked if I wanted to make a new reservation or discuss a current one.

I said new reservation.

“Oh, our system is down for maintenance. Can you try again in a few hours?”

It was already midnight, so I really didn’t want to do that.

“That’s OK, I’ll just call Hertz.”
Which I did.

I encountered two problems here.
First was the message that implied that a human could make a reservation while the system was down. The accurate message would have been “Our system is down for maintenance. If you want to make a reservation, please try again in a few hours.”

And, since this is the de-facto process, I have to assume that the company is doing it this way on purpose.

Then again…
Do their executives rent cars through the online system? Do they experience what their customers do? Do they see the “we’re closed, please go away” sign that is part of their normal process every Saturday night?

Another company once put me on hold. The system kicked to a local radio station rather than silence. And so I was waiting for a customer service response while listening to Mick Jagger “I don’t get no… sat is fact ion…”

Boeing Moving Line

Boeing’s “PTQ” (Put Together Quickly) videos show a time lapse of an airliner in production. They have been producing the for years – certainly since I was working there.

This one, though, shows something a little special.

When I first started working there, the idea of a line stop was unthinkable. The plane moved on time, period. Any unfinished work “traveled” with the plane, along with the associated out-of-sequence tasks and rework involved.

The fact that the 737 is now built on a continuously moving assembly line in Renton is fairly well known.

But what struck me in this PTQ video is that one of the things highlighted in it is a line stop. It happens pretty quickly at about 1:57.

The video is also full of rich visual controls to allow the team to compare the actual flow vs. the intended flow. See many many you can spot.

Customer Service Opportunities

Today was traveling on behest of a large corporation, so the travel arrangements were made through them. It all went about as routinely as could be expected on the last weekend before Christmas… for me.

Unfortunately the guy I am supposed to meet here had flights going through D.C. that were on a collision trajectory with a snow storm on the east coast today. Flight cancelled.

OK, I need to continue on, then shift my departure out 24 hours – hang around here another day.

Fortunately at the bottom of the itinerary emailed by the corporate travel company is the handy “In case of problems” etc. phone number:

CONTACT xxx TRAVEL 1-800-3xx-xxxx

So I call the number.

A couple of layers of voice menu prompts (including a reminder that airlines are implementing luggage policies, please check your airline’s web site – totally useless information that only delays the response I am trying to get), I end up with the “hold music” being reminded periodically that “Your call is important to us…” etc.

A human comes on the line and I am cheerfully informed that this is not the 800 number I should call. I am reminded that MY reservation was made through the online system (which it was not, I talked to a human being when I made it), and that I need to call “them.” And, kindly, I am forwarded to “them.”

After 20 minutes of hold music, my plane is boarding, so I have to drop the call.

Try again from the seat.

Different initial operator who makes a little more effort to make me wrong for calling the ONLY number that they print on the itinerary they send, otherwise same result. They are closing the cabin door, I have to drop the call.

There actually is a lesson here.

What defines how well a process or system works is not so much the individual components, but the interfaces between them. In this case the “interface,” if you can call it that, is the hapless (and irritated) customer. I am the one who has to integrate various otherwise separate components of this fractured process.

The other story is the reason they were likely so busy today. After all, a major snow storm socked the east coast and caused havoc in the flight schedules that went through there. I am sure there were plenty of people who were impacted, and calling them for assistance re-booking flights, etc. And after all, there really is no way to predict when that will happen so they could be prepared, right? The really cool thing about 21st century communications technology is that you can can not only monitor live weather conditions and radar in real time, if you need to react, “extra people” don’t even need to leave home to be available… they don’t even need to be in the same state or even country. It is possible to plan and prepare for extraordinary mind-boggling never-forget-it customer service, if it is important to you.

In the end, it is about making a conscious decision about the experience you really want your customer to have, and then structuring your processes, deliberately, to deliver that experience – and be sensitive and alert you when they do not. It is not that big a shift from “serving customers” to “customer service,” nor does it cost more in the long haul. “Quality is free” – if you understand how to do it.

Looking at the wrong stuff: America’s Best Hospitals: The 2009-10 Honor Roll

This news piece, America’s Best Hospitals: The 2009-10 Honor Roll, originally got my attention because I hoped someone might be actually be paying attention to the things that make a real difference in our national debate about health care.

Unfortunately, it looks like more of the same.

This survey looks at things like technical capability – what kinds of specialty procedures these hospitals can perform, and their general reputation  and then ranks them accordingly.

But where are we asking about the basics?

Which hospitals kill or injure the fewest of their patients? What is the rate of post-operative or other opportunistic infection? How about medication errors? These are the things that all hospitals should be “getting right” and yet the evidence is overwhelming that most don’t. Further, nobody seems to be paying attention to it except tort lawyers.

Now take a look at this post on Steven Spear’s blog, and especially the Paul O’Neal commentary that he links to.

Tell me what makes a “good” hospital?