Posts

Posted on

Get Your Ducks In A Row For Lean Accounting

I have known Russ Field since working with him on a few projects in a large Seattle (now Chicago) based aerospace company. Recently he posted a very (typically Russ) thorough reply on NWLEAN to a question about value stream accounting. I asked him to take the same basic material, clean it up a little, and let me publish it here as a guest post.

Added Feb 21: There are some good comments to this post as well.

Enabling Material-Only Costing in Value Streams

—————– By Russell Field ——————

For some time now, the value stream concept has been a topic of energetic debate. If you choose to implement that approach, you’ll find there is more than one reasonable way to organize them, each with its own requirements for management, measurement and performance assessment.

This discussion centers on the value stream design described in three excellent books:

Aside from my own experiences and observations, these works are the primary references for this article. I recommend them highly for anyone wanting to better understand the concepts and related impacts on the Finance function as a business “leans out”.

NOTE: This article is not an endorsement of this particular value stream form. Rather, it is examination of its enabling and prerequisite conditions.

The really short message, as in so many things, is “Don’t get the cart before the horse!” In this case, if material-only cost accounting procedures (discussed later) are implemented before the factory processes have been realigned and proven, the best which can be expected is a different flavor of misrepresentation.

First, though, some baseline thoughts.

“TRADITIONAL STANDARD COSTING” vs. COSTING OF (LABOR) STANDARDS

Remember, words have meaning. I’ve seen many discussions derailed because of confusion between these two phrases. The philosophy and practice of “Traditional Standard Costing” is not the same as the “costing of (labor) standards”.

The question is not whether I should know the cost of one widget, or the labor content (time) of that widget, or even the labor contribution ($$) to the cost of that widget; rather, the questions are how I should determine the hourly rate ($$) to apply to the labor content (time), and how I should account for other costs of producing that widget.

BUT – even those questions become academic in a value stream where all products have the same labor content and where all costs are contained within the value stream (more on that later); that’s when we can start talking about the average cost per unit at the value stream level.

“LEAN ACCOUNTING” vs. “ACCOUNTING FOR LEAN”

As described in AWCO (pg. 36), these are two different concepts.

“Lean Accounting” refers to the use of Lean tools and techniques to make the accounting process more efficient.

“Accounting for Lean” “… represents an accounting process that captures the benefits of a Lean implementation as well as motivates Lean behavior.”

MATURITY PATH OF “ACCOUNTING FOR LEAN”

Both PLA (Chapt. 2; pg. 141 et al) and WC (pg. 165 et al) make the point that changes in accounting techniques should be made in conjunction with or immediately following the successful implementation of Lean procedures on the shop floor (we won’t get into Service vs. Production in this article). To change the cost accounting processes BEFORE leaning out Operations merely confuses the situation and causes unnecessary churn.

That said, let’s proceed.

In my opinion, the ability to successfully implement and sustain the accounting techniques described in the books noted earlier is dependent upon getting the process “ducks” into four rows:

  1. Organization by value stream
  2. Elimination of task-level labor tracking
  3. Stabilization of overall value stream-level labor costs
  4. Lowering of inventory levels

Underlying each of these “duck rows” is, of course, a set of enabling conditions.

DUCK ROW #1) Organization by value stream

There’s plenty of material out there on value stream mapping, so for this discussion let’s just say there are some key characteristics:

  1. Similar process flows (or “routings”);
  2. Similar production cycle times (AKA “work content”);
  3. Similar physical size of product;
  4. Ideally, personnel dedicated to the value stream; and
  5. Again ideally, no “monuments” or shared resources (there are, of course, ways of dealing with shared resources and personnel, but I did say “ideally”).

In other words, this approach emphasizes segregation of product families with high similarity in multiple categories. What does all this buy us?

a) If every product follows the same process flow or path, physical segregation and rearrangement is much simpler. Additionally, there is a high likelihood that each product will use each resource (or resource type), further reducing the need for cost allocation between product lines/families.

b) If each product takes about the same amount of time at each task/resource, then the overall work content of all products is about the same.

c) If product size is similar, that helps keep the number of people needed and the need for additional, product-specific moving/handling equipment to a minimum (and supports similar work content).

d) & e) If people and equipment aren’t shared outside the value stream, then all of their costs can be attributed to the value stream.

NET RESULTS:

  1. The major sources of cost are captive within the value stream, so the need for allocation is minimized if not eliminated.
  2. Every product in the value stream population takes about the same flow time and has about the same total work content (which also minimizes allocation requirements).
  3. Some key sources of variation in that flow time and labor content are sorted out of the value stream by design.

DUCK ROW #2) Elimination of task-level labor tracking

There are two sub-elements here: “Stabilize task cycle times” and “Establish a common wage structure”. In order to reach these goals, we must create certain conditions.

a) Stabilize task cycle times

In order to create an environment in which a given task takes the same amount of time and effort regardless of who executes it, we need:

  1. Stable, high-quality processes (“reasonably under control and low variability”, PLA pg. 140/141 et al); this cuts down on how many times a job needs to be done, and how much input is wasted.
  2. Standard work; standardizing process steps helps assure that the job is done the same way each time.
  3. A cross-trained, multi-skilled workforce; in full implementation, this means that any member of the workforce can step in and execute any task.

b) Common wage structure

Note that a cross-training and multi-skilling not only helps stabilize task times, but also aids breaking down the “craftsman/guild” barriers to a common wage. For that, we need:

  1. A cross-trained, multi-skilled workforce
  2. Simplified processes; among other things, this makes cross-training and multi-skilling considerably easier.

NET RESULTS:

1) I no longer need to track how much time was spent executing an individual task; with high quality, standard work and cross-training, I know how long it takes because I know the plan.

2) I no longer need to track who executed the task in order to determine an appropriate rate (accountability/traceability is another issue), because everyone gets paid pretty much the same (within a job category, at least).

In short, I no longer need to run all over the production floor, tracking activity durations or costs at the task level. In fact, to the degree that the process paths and work content are very similar, I don’t even need to track them at the Item level.

DUCK ROW #3) Stabilization of overall value stream-level labor costs

Once I have eliminated the need for task-level labor tracking, then I need only to stabilize my labor population in order to keep my overall value stream labor costs at a fairly constant level.

The high-quality processes I put in place to stabilize my task cycle times will help by assuring that labor is used only for production (and not rework or re-make), but I also need to level my demand, either artificially within my walls or by working with the customer base toward that end (I may also need to level-sequence my product mix if I still have significant difference in work content between products).

In that way, I always have about the same amount of work to be done, and don’t need to bring people in, pull them back out, put them back in, or shake them all about (do the “Production Hokey Pokey”!).

NET RESULT:

I have a consistent amount of work to be done in the value stream, so I’m able to maintain a fairly fixed workforce population.

DUCK ROW #4) Lowering inventory levels

Once the inventory turn rate gets down to, or drops below the overall value stream cycle time, product is going out the door very soon after completion. Assuming a FIFO approach, I don’t need to put a lot of effort into tracking my inventory costs because a) they’re per current rates and b) there aren’t many pieces anyway.

NET RESULT:

I don’t have to keep separate track of what I have invested in each lot, batch or item. Even radical changes in material costs flush through the value stream very quickly.

SO:

IF I don’t have to mess with spreading/allocating costs;

AND IF every time I make a given product, it takes the same amount of time;

AND IF all the products I make in my value stream take the same amount of time;

AND IF anyone who makes it gets paid the same wage;

AND IF I don’t have to constantly change the size of my labor population,

THEN I can apply a flat hourly $$ rate – based on total value stream cost – to the product’s work standards (planned work content). In fact, at full maturity I may even be able to simply average my total periodic value stream costs over the number of pieces shipped – AKA “average cost per unit” (PLA pg. 124 et al).

If my value stream is fully segregated and mature, this is the closest I need to get to “overhead allocation”. I don’t have to account for variation in order quantity, labor expense or the like because I’ve designed/driven out those variations. I know what the labor content is because of the stable processes and high reliability; there’s no rework to account for because of the high quality; a worker is a worker is a worker from both a skill and pay standpoint, and I’m controlling the number of workers on the payroll (NOTE: Worker interchangeability must not be confused with worker dispensability / replaceability; it can take quite a while to adequately cross-train good personnel).

And the ONLY thing I really need to track is material consumption (you can throw in some consideration for features and characteristics costing if appropriate). Hence the term, “material-only cost system” (WC, pg. 38).

To recap, in order to enable truly simple, material-only costing we need to:

  1. Organize by value stream, driving out key categories of variation;
  2. Work to eliminate the need for task-level tracking of labor input and rates;
  3. Stabilize the overall value stream labor costs; and
  4. Lower inventory levels to less than one value stream cycle (or 5 days as some suggest).

To do all that, the fundamental enablers include:

  1. A value stream organized around product families with high similarity in routings, process time/work content, physical size and the ability to segregate personnel and resources
  2. Stable, reliable processes
  3. Standard work
  4. Cross-trained, multi-skilled workforce
  5. Simplified processes
  6. Stable, level demand

Of course, these enablers presuppose the existence of lower-level enablers (e.g. accurate BOMs and routings, and having appropriate metrics in place).

So what? My whole point is that there’s more to successfully implementing Lean Accounting techniques described in PLA, WC and AWCO than simply ceasing or starting to gather certain data or collect certain costs. If you already have these enablers in place, then you are better positioned to embrace the related accounting practices.

NOW – the BIG question is, “How do we manage our business until we can get these enablers firmly in place?”

I refer you again to the books noted above. All offer some good thoughts on this subject, but I will reiterate the sentiments expressed under the heading of “MATURITY PATH OF ‘ACCOUNTING FOR LEAN'”. Bottom line: “Don’t get the cart before the horse!”

Your current accounting processes are likely adequate for traditional manufacturing environments, especially those which are still largely mass-production oriented (PLA, pg. 4 et al). Both PLA and WC specifically discuss synchronizing the evolution of Lean Production Operations and “accounting for Lean” (and yeah, I capitalized it).

Posted on

Metrics and Customers

Metrics are a fairly common topic of discussion on the various lean manufacturing forums. One theme that comes up fairly frequently is how to determine “what counts” in this-or-that measurement.

For example, a recent post asked about measuring lead times. The way they were measuring lead time only counted the time from when the order was actually started on the shop floor. But it didn’t include the latent time between the time the customer placed the order and when processing it actually started.

A rule of thumb I like to apply in these cases is “What is the customer’s experience?”

In this case, the customer starts waiting on the order the moment he informs the company he wants something. The customer really doesn’t care whether the order is waiting in order-entry, waiting for the computer to run its batch process, or whether it is stuck in production queues. Time is time from the customer’s viewpoint.

Of course this doesn’t mean I would ignore the internal components of the lead time… but I would include all of them because that is what the customer experiences.

While I am on the topic of metrics, I want to reiterate the importance of also having a specification or standard. It is not enough to simply measure something and graph it. That does nothing but consume people’s time. Each instance must be compared against a specification. “Lead time” doesn’t tell me anything. What I want to know is “Was this order on time?” Yes or no? How late was it? What delayed this one? Why? Then launch into the problem solving process.

Once a standard is being consistently met it is appropriate to then ask whether you want to set the bar higher. But to try to simply measure your way into excellence, without regard for stability and sources of variation, is an exercise in frustration.

As you look at the various things you measure, ask yourself if your metrics are reflecting the experience of the internal or external customer. That can help reduce some of the questions about what is “in” or “out” of the measurement.

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.