Posts

Posted on

Overburdened with Andon Calls

Bryan Zeigler has a great post on his “Lean is Good” blog site. Titled “Andon Calls and Muri,” he describes Toyota’s phenomenal  capacity for responding to problems, and then takes us back to where the rest of us are with some really great questions:

If it is physically impossible to answer every andon call in order to work on every problem, is it best to fix the first one that comes sequentially?  Then do work arounds and rework until we can respond to another one?

I have always used systems to prioritize what problems we work on whether it be pareto charts, value stream maps, or just plain standing in the circle.  Once directions, or as Toyota Kata describes them, process target conditions, are established and the highest priority items are “fixed” and then we move on the the next most important challenge.

Working on all problems in the process would overburden the organization’s problem solvers.  This would be a form of dreaded muri right?  I’ve read and heard much about the Toyota staffing levels required to operate TPS effectively.  Most range from 5 to 7 employees under each level of leadership position.  Again, my experiences are more like 30 to 40 employees under a 1st line leader.

Two questions:

  1. What percentage of daily problems are organizations that you work in staffed to handle?
  2. What philosophies do you utilize to ensure you don’t introduce Muri to the problem solving teammates in the organization?

Great observation, and great questions. And Bryan is certainly not the only one who has had the insight to ask them.

At this point, I have to issue a bit of a disclaimer. I have spent a full day on the shop floor in Bryan’s workplace. I can visualize exactly what he is talking about. Unfortunately schedules didn’t allow me to meet him, but I have a pretty good sense of the situation he is dealing with.

Since pretty much everyone has these issues when they start to contemplate andon calls, let’s start by reviewing the theoretical base, then moving into reality.

The core principle of jidoka is “Stop and respond to every abnormality.” That is what we are trying to do here. This means there must be a clear definition of what is “normal” and what is “abnormal.”

In the strictest sense, if it isn’t clearly defined as “normal” it is ambiguous.

In a system where the most basic fundamental is to define processes, ambiguity is a problem as well. Put another way, “ambiguity” is, by definition, “abnormal.”

So, in effect, we are asking the team member to let us know when anything is not clearly consistent with the defined norms.

The first response to an andon call is to clear the problem. If the “problem” is lack of clarity then deal with that. Replace uncertainty with clarity. Set some kind of an hard criteria for what does, and does not, need your attention. This means take management responsibility for the fact that the problem exists, and you aren’t going to do anything about it right now.

The next step is critical: If you can’t solve it right now, contain it.

“Containing the problem” means establish a temporary standard of some kind. Some kind of action that allows the team member to resume safe, defect free work. You might have introduced some inefficiency into the process, but safety and quality take priority.

And here is the dangerous part. You have the problem more or less under control. You can easily walk away and move on to the next one.

But consider this: You have the tiger in a cage. You are in the cage with it. You have to keep feeding the tiger (with time, resources) so it doesn’t eat your process. The only way to make the tiger go away is to get to the root cause.

This temporary standard does, however, give you a measure of stability. You can organize your problem solving efforts and focus on the ones that are the most critical to you. Meanwhile, however, you are burning resources feeding all of those tigers.

Typically a temporary countermeasure (problem containment) is some adjustment to the process. You have set a new standard work sequence that includes the steps required to keep this problem from affecting customers or escaping downline.

Yes, it is a work-around. But it is one you developed deliberately for a specific reason, until you can get to clearing that issue for good.

As you continue to identify problems and at least get them contained in some way, continue to refine the things you want to call attention to.

First, be explicitly clear on what things must trigger an andon call. These are the things you really want to know about when they happen. For sure it should be any safety issue and any issue that threatens quality. It could be an issue you are currently focused on resolving, such as late parts delivery, an upstream quality issue, a piece of unreliable equipment.

Then establish the time trigger. To do this you need to have three things pretty clear in your mind.

  • A good idea of how long the process is supposed to take.
  • A method for the team member to know when he is behind, and how much.
  • A standard for how much delay you are willing to tolerate. Put another way, how long to are you willing to let the team member get behind before he tells someone? My suggestion here is no more time than you can help him catch up. If he gets further behind than that, you are going to pass the problem to another part of the process downstream in the form of a late delivery.

Now you have some simple rules.

Please try to perform the standard work so we can see any problems with it.

  • If any unsafe condition exists, stop and pull the andon. Wait until we can clear the hazard.
  • Do not knowingly ship bad quality to the next process. Pull the andon so we can come, assess, and decide how we are going to deal with that.
  • If you have this problem, this problem, or this problem, stop and pull the andon so we can come and clear the problem as well as understand it as soon as it happens.
  • If you accumulate any delays longer than xx minutes, pull the andon.

This puts you in control. You get to decide how much excess capacity (how many extra people) to pad delays. You get to decide what problems trigger a call. You get to decide what you can handle.

All I ask is:

  • Do not tolerate unsafe conditions. Always stop the process and always initiate a call.
  • Do not tolerate a process that routinely passes bad quality down stream. Always initiate a call. Don’t put the team member in a position where he has to judge what “good enough” is. Have a hard standard and stick to it.
  • Always thank the team member for bringing problems to your attention. Never discourage an andon call.
  • Never allow an andon call to go unanswered. Set a response time standard, measure it, and apply the same problem solving principles to that.

The other thing I would suggest is a system to manage problem solving. There are some suggestions in this post on morning markets.

The key point is that any problem you decide not to work on has to have some kind of temporary countermeasure incorporated into your expectations. If you do something that adds time, you must allow time for it to be done. Doing otherwise is introducing overburden – or to Bryan’s point, shifting the overburden from your problem solving back to the team member.

If you pay attention to what is really happening, and take management responsibility for all of the problems that the team members encounter, then (and only then) can you set rules about which ones you will, and will not, work on right now.

The hardest part of all of this? It is the “taking management responsibility” part. Getting an effective andon call process into place requires as much (actually more) process discipline in the leader’s ranks as it does on the shop floor. This is discipline not to panic, not to wish problems away, and to respond as though the team member is doing you a favor for calling out a problem vs. causing it.

An andon call process is a vital step toward truly engaging the team members. And it begins the shift from intermittent improvement to continuous improvement.

Posted on

Health Insurance Overprocessing Muda

If I had a category for “What are they thinking?” I would probably tag this post with it.

Patient has an eye exam that is covered by her health insurance.

The doctor’s office bills the insurance company.

The insurance company disallows $29.32 in charges because they are above a contractual amount.

The insurance company sends a check for $29.32 to the patient to cover the disallowed charges when she gets the bill from the doctor for the balance.

Do I even need to frame a “Why?” question here?

I think it stands on its own.

Just scratching my head.

Yes, I saw the statements and the check with my own eyes.

Posted on

leanblog.org “10 Lean Things Not to Say”

Fellow blogger Mark Grabon recently posted “10 Things I Wish Lean Practitioners Wouldn’t Say in 2010” on his leanblog.org.

I like it enough that my thoughts won’t fit in an appropriate comment on his blog, so I’ll write them here. Go back and read his post first, though, or you won’t make sense of this one.

Added last: This turned into a stream of consciousness that ranges on a variety of topics. You are getting a bit of insight into how my mind works here.  🙂

“Lean them out” — “Get them lean” — “What would lean say?” — “Is that lean?”

In the context of “lean production” or “lean manufacturing,” the word “lean” is an adjective. It is not a noun, it is not a verb. I would argue that you can’t even get agreement about what it means in a room of “experts.” Today we have spliced other words to it, like “Sigma” that dilute it even more – implying that it needs something else to be complete without every saying what was missing in the first place.

The word “lean” has taken on a life of its own. As Mark points out, it even issues judgments as in “What would lean say about…” as though phrasing the question this way somehow quotes an objective source instead of someone’s opinion.

Sensei says…

Aside from introducing the word “lean” into the vernacular, Womack and Jones also made having a “Sensei” an imperative. Now I am seeing consultants, even non-Japanese ones, brand themselves as “Sensei.” Worse, there are consultants and other agencies who preport to “certify you” as a “Sensei.”

As Mark points out, the Western use of the term differs from the everyday use in Japan. Our meaning likely comes from martial arts classes. When I was at a previous company, people I worked with tried to apply the term to me. Like Mark, I objected. As they were insisting, I “allowed” them to use the word “sempai” and told them that was just someone who had been in the martial arts class a week longer. In reality, the only thing that differentiates teachers and students in the business is a bit of experience and something to say. But, as I said previously, what sets apart a master is that he has mastered learning.

Counting kaizen events.

Bluntly, this is one of the most effective ways I know to derail a journey of continuous improvement. The behaviors that are driven by counting kaizen events are counter to the very things we are trying to accomplish. If you aren’t sure why, ask yourself if a team member taking his own initiative and drilling some holes in a block of wood so that he can hold his bolts is a kaizen event or not.

Variations on the theme of Buy In / Resistance to Change are pervasive in the forums and in real life. And professional kaizen practitioners are not immune to denying that someone has found a breakthrough that they hadn’t.

But, sorry folks, there is nowhere on Earth where you can avoid the necessity to understand other people’s needs and feelings and take them into account. Not, at least, where you are dealing with other people. So, even if you are in a company that totally “gets it,” you had best develop the skills to do this.

Why? Because you aren’t going to “lean anybody out” without their total, complete and enthusiastic cooperation. The reason is simple. Until they are doing it themselves, without prompting, without being pushed, without being boxed in by coercive approaches, it simply isn’t working. You can’t force people to be creative problem solvers. They have to like doing it.

This is the challenge of the true change agent. Like what I said in the previous post about job shops, if you aren’t getting clear answers about how to get people involved, you are talking to the wrong person. Try someone else.

And finally is the jargon of our community. Some of it is Japanese, other terms are inherited from other disciplines like organizational development.

Jargon has two purposes. One is it provides people in a specific field or organization a clear means of communicating with one another. The legal profession, for example, is full of Latin terms that require paragraphs to define. So are military organizations. And an organization will often have a language of its own that members use internally. You won’t know the difference between a blueline, a greenline or an IW unless you have worked in Boeing Commercial Airplanes.

Toyota has this corporate jargon. They have redefined a fair number of common Japanese terms that, today, carry very specific meanings within the Toyota context. Kanban, jidoka, yamazumi and even kaizen are some of those words. That is all well and fine for Toyota. It gives them a common shorthand so they can communicate more efficiently.

The more insidious use of jargon, though, is for a group to use it to exclude others from the “in” circle. Rather than being a shorthand to enable communication within the group, jargon becomes an obfuscation to disable communication, establish a sense of mystery, and differentiate those who “know” from those who are not yet enlightened.

So how do I feel about Japanese jargon in this context? Only you know. Look in the mirror. Check your purpose. Why do you feel the need to use it? How do you feel when you use it? Do you feel that it shows you know more than someone who does not use it? Do you take pride in making elaborate explanations of these terms? If so, I feel you are doing it for the wrong reasons. I don’t say not to use it. I do say to check your intentions. Are you doing so out of respect for people, or to elevate your own status? Then act according to your own conscience.

I have gone a lot deeper into this stuff than Mark did, and I am not nearly as well organized. Ah well. You get the benefit of seeing one of my raw brain dumps.

Posted on

Job Shops

“We are a job shop.”

“We never do the same thing twice.”

These are common truths spoken by people who are struggling with how to apply lean production principles to their operation. They want to do better, but don’t see how something that originated in the relentless repetition of an automobile assembly line can work for them.

This is a reasonable reaction in the face of an overwhelming amount of literature and advice that is geared to these repetitive environments. An example of this is the common “elements of standard work” that come right out of Toyota and Shingijutsu:

  • Repeating work sequence (standard work)
  • Balanced to the takt time (which implies repetitive demand)
  • Standard work-in-process (or standard in-process stock)

Another example is “Takt, Flow and Pull” as the key elements of just-in-time production.

All of these things are absolutely true, but as instances of more fundamental principles.

Can lean production principles be applied to a job shop? Absolutely. It just requires someone with a bit more experience who knows how to interpret the situation and apply the principles rather than dogmatically apply a standard toolbox. It’s like the difference between the author who applies the basics of creating a compelling story, and the performer who expertly interprets the script written by others.

I have run into a fair number of “job shops” over the last 20 or so years. This is what I have observed:

A fair percentage of them actually have underlying repetition. It is just obscured by the job shop mentality. That is, they run them like job shops, so they become job shops. Even if only a portion of the work is repetitive, slicing this off and stabilizing it creates that much more mental bandwidth for dealing with the rest of it.

But even the true job shops, the ones who do custom work never to see that customer again are experts at what they do.

Expertise comes from experience.

Experience, in turn, comes from having done it many times before.

There is something they are good at. Each job may be custom, but it is built up from basic elements – the things they are experts at doing. Identifying those elements can clear out a lot of the seeming complexity. True process then emerges as they focus on how those elements are executed and organized, and paying attention to the interactions between them, the people, the customer. Then they work on getting better and better at creating stable processes that may only be carried out one time. But even then, there is knowledge to be gained that can be incorporated into doing it better next time, and that is the essence of kaizen.

Key point: If you are struggling with how to apply these principles, and aren’t getting answers that make sense to you, then (bluntly) you are talking to the wrong people. Keep at it until you find someone who can look at your situation and ask the right questions.

Posted on

Simple and Easy Processes

In the last post I commented on Ron Popeil’s product development approach – to make the product easy to demonstrate drives making it easy to use, which creates more value for the customer.

Let’s take the same thinking back to your internal customers.

What if, rather than just writing a procedure, you had to go and demonstrate it to the people who had to follow it? What if you had to demonstrate it well enough that they saw the benefit of doing it that way, and could demonstrate it back to you to confirm that they understood it? If you broke down the work and organized it to be easy to demonstrate and teach, would it look any different? (Hmmm. TWI Job Instruction actually sounds a lot like this.) Would you still ask “Why didn’t they just follow the procedure?”

Look at the information displays and the controls on your equipment. Do they provide total transparency that things are working? Or do they abstract and obscure reality in some way? Can your internal customer be sure things are going as expected?

Do controls give clear feedback that they are being set correctly? Are sequences of operations readily apparent?

How many “blinking 12:00” situations do you have out there on your shop floor – things that have been put into place, but nobody uses because nobody can really figure it out?

Come back to the design of the product itself. Is the manufacturing and assembly process apparent, obvious, and as simple as you can make it? Would it be designed differently if you had to demonstrate how to fabricate and assemble it?

How about your administrative processes? I recall, many years ago, a “process documentation process” being taught. In the class they were using “baking cookies” as a demonstration example. Yet the instructors, who presumably were experts, actually struggled trying to show how this works. This “process” was far less clear than they had thought it was when they had simply thought through it. “It did not work on TV.”

Look at your computer programs and their user interfaces. What makes sense to a programmer rarely makes sense in actual use. Watch over someone’s shoulder for a while. Could you easily demonstrate this process to someone else?

Ron Popeil cooks real chickens and real ribs in the production of his infomercials. He does not use contrived or carefully limited demonstration examples. As you look at your examples and exercises, how well do they stand up to the real world application? Can you go out to the shop floor and demonstrate your “product” in actual use?

This post is full of questions, not answers. I don’t have the answers. Only you (can) know how well your processes are engineered.

Design your production system (for product or service) as carefully as you would design the product or service itself.

Posted on

Developing Products to Create Value

I am reading Malcom Gladwell’s somewhat new book What the Dog Saw. It is an anthology of articles he has written for New Yorker magazine over the last few years.

The first chapter is about Ron Popeil, the icon of infomercials and “Set it… and Forget it.” Gladwell describes a fascinating product development slant – make the product easy to demonstrate. In making it easy to demonstrate, its benefits must be obvious. Its features must make it easy to use and simple. Complexity just does not cut it. And it must work, right out there in the open.

The chapter spends a lot of time on the Showtime Rotisserie. In the sales presentation, it is the product, not the salesman, who is made the center of attention. What it can do for you, how easy it is to use, and how it functions. The front is transparent, and angled so the customer can see the product work, in use (and during a demonstration on TV). The controls are simple enough that he can say “Set it… and forget it.” It is engineered (and was re-engineered in development) to prepare visually appealing perfectly cooked food. As it was being designed, it was continuously being used as it would be in a demonstration – the pitch and the product were developed simultaneously.

Because I love examples of opposites, this is the part that really drove the difference home for me:

If Ron [Popeil] had been the one to introduce the VCR, in other words he would not simply have sold it… He would have changed the VCR itself, so that it made sense in an infomercial. The clock, for example, wouldn’t be digital. (The haplessly blinking unset clock has, of course, become a symbol of frustration.) The tape wouldn’t be inserted behind a hidden door – it would be out in plan view, just like the chicken in the rotisserie, so that if it was recording you could see the spools turn. The controls wouldn’t be discrete buttons; they would be large, and they would make a reassuring click as they were pushed up and down, and each step in the taping process would be identified with a big, obvious numeral so that you could set it and forget it. And would it be a slender black, low profile box? Of course not. Ours is a culture in which the term “black box” is synonymous with incomprehensibility. Ron’s VCR would be in red-and-white plastic, both opaque and transparent, or maybe 364 Alcoa aluminum, painted in some bold primary color, and it would sit on top of the television, not below it, so that when your neighbor or your friend came over he would spot it immediately and say “Wow, you have on of those Ronco Tape-O-Matics!”

All of this is about creating value for the customer – value that, in the customer’s mind, exceeds “four easy payments of $39.95.” When that happens, the customer buys the product.

We spend a lot of time thinking about how well manufacturing and supply chain issues are taken into account during product development. But just as important is he customer interface.

Take a look at your product development process. How involved are the people who have to sell it? How involved are customers and users who have to use it, maintain it? Do they get to try out their processes on your prototypes as you go? Or are specifications just tossed over the fence for engineers to figure out and turn into what they think is the ideal product?

Posted on

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.

Posted on

TheLeanEdge.org

Michael Ballé made me aware of a new site, http://theleanedge.org, that he has started.

Its tagline is “a site for lean dialogue with the authors.”

He has assembled a panel of some of the most prominent names in the field including:

  • Michael Ballé
  • Art Smalley
  • Jeff Liker
  • Mike Rother
  • Robert Austin

where they are discussing issues and answering questions.

It is just getting started, but I think it is going to be a great resource for the community. You can’t go wrong reading what these people have to say.

Posted on

I.E. and Kaizen

There is an interesting thread developing on the NWLEAN discussion group. Kris Hallan, a regular reader here, asked a great question about the contributions of the industrial engineering pioneers to what, today, we regard as “lean production.”

This, in turn, sparked some debate about whether Taylor, the Glibreths, and others were actually following lean methods; about whether traditional industrial engineering is bogged down in over analysis, and a host of other issues.

Because not all you are following NWLEAN, I wanted to share my thoughts here as well.

The pioneers all did very good work advancing the field of knowledge.

The Gilbreths, for example, are credited with the realization that “time is the shadow of motion.”

Ohno and Toyoda were both adamant that everything they applied to build cars was simply an extension of what they saw at the Rouge plant.

The neat thing about knowledge and technology is that each generation has an opportunity to build on the last. Sometimes this is incremental, sometimes it is a profound shift. But in either case, it is the previous work that establishes the foundation – either something to extend, or a refutable hypothesis to test and reject.

If I really look at the shift that separates traditional I.E. from the more modern approach, it is in who holds the knowledge of the process AND how to improve it.

Taylor separated thinking about the process from determining the best way to perform it. He (and the Gilbreths) learned to observe with a keen eye, and optimize the motions he saw. Great stuff. Nobody did that before. Everything we do today is built on that foundation.

Today I see two levels of lean practice.

The first, and far more common, is the “outside expert” – the kaizen workshop leader, for example. In this model, this expert comes from outside the actual process. He acknowledges that the people doing the work probably know the best way to do it. But the work of exactly HOW to improve things – the magic of kaizen if you were, belongs to the expert. He is the one who facilitates improvements. While “process improvement” is the domain of the people doing the work, the “process of improvement” is owned by the outside expert.

So the skill of “improvement” is separate from the skill of “doing the work.”

I see this all of the time. Its dark side is manifested in “How do I make them follow standard work?” as if that is even possible through coercion or some punishment/reward system.

This is really an extension of the Taylor model of separating “thinking” and “doing.” In this case, however, it is “thinking about how improvement should be done” and “doing the improvements” vs. the work itself.

But something slightly different is happening in the organizations I see pulling ahead.

In those, the “skill of how to improve” is also manifested in the people doing the work. “Improvement” is part of that work itself, not something separate. There is time and resource specifically allocated to it, just as there is for production. EVERYBODY is focused on not only making improvements, but also improving how they do improvements themselves.

To the outside observer, the difference in the teaching and implementation processes are very subtle. But the difference in the culture and results that emerge can be profound.

The key difference is in letting go, finally, of the Taylor model and working to incorporate the knowledge and skill of process improvement into the entire organization – everybody – rather than keeping it in a small cadre.

I think this is one of the distinctions between a practitioner and a true sensei.

Posted on

10% Off Coupon from LEI

The Lean Enterprise Institute is offering 10% discounts in their book store, and is asking bloggers to pass that along. I am happy to do so.

To use it, people just go to the Lean Enterprise Institute’s online Store at  http://www.lean.org/Bookstore/ and enter THANKYOU09 in the discount code field at checkout. The offer is good through Jan 31, 2010.

As 2009 winds down, I look back at a year that presents me with many opportunities for reflection. I am working on a couple of posts as a result.

Thank you all for your gift of “listening.”

Mark