The TPS vs. Toyota’s Production System

Up to this point I have resisted weighing in on the Toyota quality story largely because:

  1. I don’t have anymore insight than anyone else.
  2. The signal-to-noise ratio in the story seems really low, and I didn’t feel I would contribute much.

But there is another story in the back channels of the “lean” community.

Many of us (myself included) have been holding up Toyota as an example of “doing it right,” with good reason.

Toyota, of course, has never publicly claimed to be an icon of perfection, but we have held it up as one.

Now, when their imperfections are exposed, I am seeing a backlash of sorts, questioning whether the Toyota Production System is flawed somehow. This raises some really interesting questions cutting across the principles themselves; the psychology of various groups of practitioners; and of course Toyota’s practice of “The Toyota Production System.”

Are the principles themselves flawed?

We have a whole industry built on extolling the perfection of Toyota. Now we are seeing a bit of a boomerang effect. Say it ain’t so, but believe it or not, there is a population of people out there who are pretty sick of hearing “Toyota this..” and “Toyota that…” and having themselves held up to Toyota and being told they are coming up short.

Shame on us, the lean manufacturing community, for setting that situation up, but now we have to defend the principles on merit and establish credibility for ourselves rather than using Toyota as a crutch. Hopefully the adversity will sort out some of the practitioners who are still advocating rote copy of the tools and artifacts.

So, no, the principles are not flawed, not unless you didn’t believe in scientific thinking to begin with. It is a fallacy to confuse failure to adhere to the principles with failure of the principles themselves. The truth has always been that the Toyota Production System defines an ideal, and Toyota’s practice, like everyone else’s, comes up short sometimes.

So what will happen?

I can imagine that consultants the world over are figuring out how to re-brand their offerings to show how they “close the gaps” in the Toyota Production System to go “beyond lean.”

Meanwhile, though, those who are grounded are going to have to get more grounded. Stay focused on the process, the objectives, what is happening right in front of you. Ask the same questions. Tighten up on your teaching skills because the concepts are going to have to make sense in the here and now. No longer will they be blindly accepted because “That is how Toyota does it.”

 

Information Transfer Fail

While the dentist was looking over my x-rays, he saw something he would like checked out by a specialist. He used words like “sometimes they..” and “might be…” when describing the issue he saw.

I get a referral. The information on the referral slip is the name of the referring dentist (which I can’t read), no boxes checked, and “#31” in the comments.

I call the specialist and start getting technical questions about what my dentist wants them to look at / look for, etc.

So the process is to use the patient as a conduit for vaguely expressed (in layman’s terms) technical information between highly trained specialists.

Sadly, I think this happens all of the time in the health care industry. It seems that there is so much focus on optimizing the nodes that nobody really “gets” that the patient’s experience (and ultimately the outcome of the process) is defined more by the interactions and interfaces than it is by the nodes themselves.

I am really not sure how fundamentally different this is from a pilot asking a passenger to find the maintenance supervisor and tell the mechanic about a problem with a plane.

The net effect is, as I am writing this, the specialist’s office is calling the referring dentist and asking them what, exactly, they want done.. a net increase of 100% in the time involved for all parties to communicate.

While the national debate is on how we pay for all of this, we aren’t asking why it costs so much (or kills more people than automobile accidents do).

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

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.

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.

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.

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.

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.