TPS Failure Modes – Part 1

Following on from the buzz created by the last couple of posts, I would like to go back in time a bit.

In 2005 Steven Spear wrote a working paper called “Why General Motors Lost and Toyota Won.” A reader can clearly the see emerging themes that were developed into his book Chasing the Rabbit .

Spear talks about the leverage of “operationally outstanding” in changing the game, the capabilities he sees in “operationally outstanding” organizations, then “Failure Modes at Becoming Toyota Like.”

I would like to dwell a bit on these failure modes, and reflect a little on what they look like.

Failure Mode 1: Copy Lean Tools Without Making Work Self Diagnostic

So what does “self diagnostic” mean?

For something to be “self diagnostic” you need two pieces of information:

  • What is supposed to happen.
  • What actually happens.

Then you need some mechanism that compares the two and flags any difference between them. This sounds complicated, but in reality, it isn’t.

Let’s look at a common example: At the most basic level, this is the purpose of 5S.

5S as a Self Diagnostic Tool

In 5S, you first examine the process and seek to understand it. Then, applying your best understanding, you decide what is necessary to perform the process, and remove everything else. Applying your best understanding again, you seek to locate the items where they would be used if the process goes the way you expect it to.

You improve the self-diagnostic effect by marking where things go, so it immediately clear if something is missing, out of place, or excess.

Then you watch. As the process is carried out, your “best understanding” is going to be tested.

Can it be done with the things you believed are necessary? If something else is required, then you have an opportunity to improve your understanding. Get that item determine where it is used, and carry out the operation. But go a little deeper. Ask why you didn’t realize this was needed when you examined the process. Challenge your process of getting that initial understanding and you improve your own observation skills.

Is everything you believed is necessary actually used? If not, then you have another opportunity to improve your understanding. Is that item only used sometimes? When? Why? Is it for rework or exceptions? (see failure mode #2!) Why did you believe it was necessary when you did your initial observation?

Does something end up out of place? Is it routinely used in a place other than where you put it? This is valuable information if you now seek to understand how the process is different from what you expected.

Now think about the failure mode: What does fake-5S look like? What is 5S without this thinking applied?

How do you “do” 5S?

Look long and hard if you are trying to audit your way into compliance rather than using it as a diagnostic for your understanding of your process.

Though the jargon “self diagnostic” sounds academic, we have all talked about visual controls “distinguishing the normal from the abnormal” or other similar terms. It is nothing new. What makes this a failure mode is that people normally don’t think it is that important when Spear cites a mountain of evidence (and I agree) that this is critical to success. You can only solve the problems you can see.

Another Example: Takt Time

What is takt time? Before you whip out your calculators and show me the math, step back and ask the core question of “What it is” rather than “how to calculate it.” What is it?

Takt time is part of a specification for a process – it defines what should be happening. By setting takt time you are saying “IF our process can routinely cycle at this interval, then we can meet our customer’s demand. Takt time defines both part of a “defect free” outcome of your work cycle as well as a specification for process design.

Then you apply your very best knowledge of the process steps and sequence and set out a work cycle which you believe can be accomplished within the takt. It becomes self-diagnostic when you check, every time if the actual work cycle was the same as the intended work cycle. An easy way to check is to compare the actual time with the designed time.

In Decoding the DNA of the Toyota Production System, Spear cites an example of seat installation.

At Toyota’s plants, […] it is instantly clear when they deviate from the specifications. Consider how workers at Toyota’s Georgetown, Kentucky, plant install the right-front seat into a Camry. The work is designed as a sequence of seven tasks, all of which are expected to be completed in 55 seconds as the car moves at a fixed speed through a worker’s zone. If the production worker finds himself doing task 6 (installing the rear seat-bolts) before task 4 (installing the front seat-bolts), then the job is actually being done differently than it was designed to be done, indicating that something must be wrong. Similarly, if after 40 seconds the worker is still on task 4, which should have been completed after 31 seconds, then something, too, is amiss. To make problem detection even simpler, the length of the floor for each work area is marked in tenths. So if the worker is passing the sixth of the ten floor marks (that is, if he is 33 seconds into the cycle) and is still on task 4, then he and his team leader know that he has fallen behind.

assembly-valencien-640

On this assembly line, time is used, not so much to pace the work, but as a diagnostic tool to call out instances when the work departs from what is intended – or in simpler terms, when there is a problem.

All of this has been about checking that the process is being carried out as expected. But, bluntly, the customer really doesn’t give a hoot about the process. The customer is interested in the output. How do you know that the output of your process is actually helping your customer?

To know that you first have to be really clear on a couple of things:

  • Who your customer actually is.
  • What value do you provide to that customer?

Put another way, can you establish a clear, unambiguous specification of what a defect free outcome is for each supplier-customer interface in your process? Can you follow that trap line of supplier-customer interfaces down to the process of delivering value to your paying customers?

To make this self-diagnostic, though, you have to not only specify (what should be happening), you have to check (what is actually happening), and you have to do it every time.

So poka-yoke (mistake proofing) is a way to verify process steps. Other mistake proofing will detect problems with the outputs. All are (or should be) designed to diagnose any problems and immediately halt the process or, at the very least, alert someone.

The theme that is emerging here is the concept of PLAN-DO and CHECK, with the CHECK being thoroughly integrated into the process itself, rather than a separate function. (Not that it can’t be, but it is better if CHECK is continuous.)

The Supply Chain

I was walking through the shop one afternoon and spotted an open bundle of steel tube – about half of them remaining. They used kanban to trigger re-order. The rule of kanban is that the kanban card is pulled and placed in the post when the first part is consumed. To make this clear, they literally attached the kanban to the bands with a cable tie. Thus, breaking the band would literally release the kanban. Simple, effective.

But, though this bundle had been opened, there was the kanban card still attached to the (now broken) banding. It was lurking at the base of the pallet, but visible.

I went and got the supervisor, and told him that “You are going to have a shortage of 4×5 tube on Wednesday, and it is your fault. Would you like to know why?” I guess I should point out that I had a pretty good relationship with this guy, so he knew I was playing him a little. Then I just said “Look, and tell me what you see.”

It took a few seconds, but he saw the kanban, said “Argh” and started to pick it up to put into the post. I stopped him and asked if it was his responsibility to do that. No, it was the welder’s responsibility. “Then you should take a minute with him, and do what I just did with you.”

Then I asked him how often the kanban cards were collected. (I knew, I wanted to check that he knew.) “Daily, about 1 pm.”

“How often do you walk by here every day?” He said at least twice, in the morning and right after lunch. “So all you need to do is take a quick glance as you walk by, twice a day, and you will always get that kanban into the post before 1pm.”

He did, and their periodic shortages dropped pretty much to zero.

Why?

First, the system was set up JIT. We knew the expected rate of use of that part. We knew the supplier’s lead time and delivery frequency. We knew the bundle size. MATH told us the minimum number of kanban cards that would need to circulate in this loop to ensure the weld cell never ran out… unless one of the inputs was wrong or unless the process operated differently than we expected.

We also knew that, given the rate of consumption, how many bundles should be in the shop at any given time, and we had space market out for just that amount. Thus, we could tell immediately if something was received early, or if our rate of consumption fluctuated downward. (Because a pallet would arrive, but there would be no place to put it.)

We could have just had a Team Member come by once a day and check if a bundle had been opened, and send an order to replenish it. We could have been even more sophisticated and just set up a barcode scan that would trigger a computer order.

But if we had set up the process that way, how could the Supervisor distinguish between “Ordered” or “Not Ordered?” It was that stray out-of-place kanban card that told him.

Bin with kanban cardThus, physical kanban cards, physically attached to the materials, represent a self-diagnostic check. If the card is there, then that container should be full. Quick to check. If the container is not full, there should be no card. Quick to check. If a container arrives with no card, it was not properly ordered and is likely excess (or at least calls for investigation). Quick to check. The physical card, the seeming crude manual operation, provides cross-checks…self-diagnosis… simply and cheaply in ways that few automated systems replicate.

So far these have all been manufacturing examples. But Spear is clear that all work is self-diagnostic, not just manufacturing.

What non-manufacturing work fits into this model?

(Hint: All of it.)

What about a project plan? Though in reality, most project plans don’t. Read Critical Chain by Goldratt to understand the difference – and produce and manage project plans that are much more likely to finish on time.

What about a sales plan? Do you predict your monthly sales? Do you check to see if week 1 actual sales deviated from what was expected? Do you plan on activities that you believe will hit your sales targets? Which customers are you calling on? What do you predict they will do? (Which tests how well you really know them.) Do you actually call on those customers? Do they need what you thought they would? Or do you learn something else about them? (Or do you make a best guess “forecast” and wait for the phone to ring?)

Once you have a sales plan, do you put together a manufacturing and operations plan which you believe will match production to sales? How much variation do you expect to accumulate between production and sales over the course of that plan? Do you put alarm thresholds on your finished goods or your backlog levels that would tell you when that predicted variation has been exceeded?

How do you (and how often do you) compare actual sales (volume, models, and revenue) against the plan? Do you know right away if you are off plan? How long will you tolerate being off plan before you decide that something unexpected is happening? Is there a hard trigger point already set out for that? Or do you let the pain accumulate for a while?

A lot of companies were caught totally by surprise a few months ago when their sales seemed to fall off a cliff. Question: Did you have rising inventory levels before that? Was there a threshold that forced attention to something unexpected? Or did you increasingly tolerate and normalize deviance from your intended business plan?

At the next levels up – you have a business plan of some kind. You have financial targets. Do you have specific actions you plan to take at specific times? Do you check if those actions were actually taken? Do those actions have some kind of predicted outcome associated with them? Do you check if the actual outcome matches what you predicted? If you just “try something to see what happens” you might learn, but you might not. If you predict, then try to see IF it happens, you are more likely to gain more understanding from that experience.

When you design a product, do you have performance specifications? Do you test your design(s) against those performance specifications? Do you do that at every stage, or just at the end?

When you say “We need training” have you first specified what the work process is? Have you studied the situation and determined that people do not have the skills or knowledge to do the job? Have you specified what those skills are?

Have you developed the training to specifically develop those skills? Do you have a way to verify that people got the skills required? Do you check if, now, they can perform the work that they could not perform before? If you didn’t do the last, why did you “train” them at all? How do you know it was not just entertainment?

“Management Is Prediction”

deming

This quote, attributed to W. Edwards Deming, really sums up what this is about. By specifying an outcome – “defect free” (which implies you know that is), within a certain time; and by specifying the process steps; you are predicting the outcome.

“If we do these things, in this sequence, it should require this amount of time, and produce this result.”

Then do it, and check:

Does what you really had to do reflect the tasks you thought would be required?

Does the order you really did them in reflect what was in the plan?

Does the time required reflect the time you planned on?

Did it produce the intended result?

Building those checks into the process itself makes it self-diagnostic.

Try This

Go study a process, any process. Just watch. Constantly ask yourself:

How does this person know what to do?

How does this person know if s/he is doing it right?

What alerts this person if s/he makes a mistake?

How does this person know s/he succeeded?

If there are clear, unambiguous answers right in front of you – without research, without requiring vigilance or luck on the part of the Team Member, then you probably have something approaching self-diagnostic work. Likely, you don’t. If that is the case, don’t say you are “doing lean.” You are only going through the motions.

Behind The Scenes Of An Outlier

Yesterday when I published Gipsie Ranney’s white paper “Remembering Nummi” I did so because I thought she made some points that others would be interested in.

Let me take you behind the scenes of WordPress. One of the things this little program makes available is a stats tracker. This is the graph of daily “Site Views” over the last month. I think the graph speaks for itself:

graph1Needless to say “Remembering Nummi” got some legs under it.

Looking at the graph, you can see that this site has a pretty steady pulse to it. The dips are weekends. The little (second highest) spike you see correlates with a link back from a site in Europe. Looking at this, and other information, I can reasonably conclude that I have a couple of dozen regular readers, probably from feeds, and the difference is click through traffic from other sites and search engine traffic.

Something different obviously was going on today.

I also see the regular sources of click-throughs to this site. This is a pretty typical list:

gembapantarei.com/2009/01/the_essenti…
leanblog.org
google.com/reader/view
leansupermarket.com/servlet/Page?temp…
google.ca
gembapantarei.com
gembapantarei.com/2009/01/finding_tim…
linkedin.com/mbox?displayMBoxItem=…
us.mc354.mail.yahoo.com/mc/showMessag…
search.conduit.com/Results.aspx?q=Typ…
170.2.59.38:15871/cgi-bin/afterWorkOp…
my.yahoo.com/p/3.html
translate.google.com.br/translate?hl=…

But here is today’s:

tmalive.tma.toyota.com/toyota/story.c…
dailynews.tma.toyota.com/story.cfm?st…
clipsheet.ford.com/article_view.cfm?a…
clipsheet.ford.com/article_view.cfm?a…
dailynews.tma.toyota.com
clipsheet.ford.com/article_view.cfm?a…
toyota.lonebuffalo.com/story.cfm?stor…
global.clipsheet.ford.com/article_vie…
tmalive.tma.toyota.com/toyota
global.clipsheet.ford.com/article_vie…
dailynews.toyota.com/story.cfm?story_…

So I conclude that “Remembering NUMMI” got picked up by a couple of news clipping services and fed into Toyota and Ford.

First, then, is a “Welcome” to any new readers from these great companies. Please feel free to peruse, comment, and even offer to write a guest post.

Though I cannot attribute to anything other than who does, or does not, subscribe to a particular clipping service, I did find it ironic that this article, really taking a critical look at the need for government guaranteed “bailout” loans to the automotive industry, was read exclusively by people in two companies who (so far) have not asked for any help. (I speak primarily of Ford here – they conspicuously said “We can get by for right now, thank you.

To this I offer a personal comment – as a former Boeing employee I have met (though certainly did not know) Alan Mullaly (now CEO of Ford). While no leader is perfect, I believe he is certainly capable of helping the Ford culture to “confront the brutal facts” of their business. My main question about Ford is whether they had already hit the iceberg when they brought him on board.

To GM and Chrysler, though, I guess I would offer: Gipsie Ranney seems to be talking to you guys. It would behoove you to listen to her. Yes there are devestating external factors at work, but guys… your boat was leaking faster than the bilge pumps were pumping long before the storm. Stop blaming the weather and take a look inside. That is where your issues are.

Remembering NUMMI: Gipsie Ranney

Gipsie Ranney is a consultant with The Deming Cooperative.

A white paper she recently wrote, contrasting NUMMI with The Big Three, has been circulating by email. I requested, and received, her permission to publish it here.

Remembering NUMMI

Gipsie B. Ranney
January, 2009

The discussions of a bailout for the U.S. owned auto industry – The Big Three – and the recommendation that a czar be named to oversee them so that they don’t waste U.S. taxpayers’ money has led me to think about an experience I had in the early 1990s. I had the opportunity to tour the New United Motor Manufacturing (NUMMI) factory in Fremont, California. Thinking back on that experience has led me to wonder how much good an injection of cash would do.

Much has been written about Toyota’s production system, but my observations on that visit may help to shed additional light on the differences between Toyota and The Big Three and what the likely outcome of attempts to cure what ails The Big Three may be. As you probably know, NUMMI was established as a joint venture between General Motors and Toyota. Middle management personnel from GM were sent to NUMMI to spend time learning about how Toyota did things. The tour I made was conducted by some of those GM employees. As I understood it, the GM employees who were sent to NUMMI were required to write at least one white paper about what they had learned. Rumor had it that only a few people back in GM ever read those papers and employees who came back to GM from NUMMI found themselves unable to get back into the career progression at GM, so there were few who volunteered to go after the initial volunteers. This led me to believe, after my visit, that perhaps the best opportunity GM would ever have to learn something useful was being thrown away.

Before the tour, I didn’t think I was going to see anything remarkable. I thought I would confirm my belief at the time that all The Big Three had to do was get busy on improvement and all would be well. I came away shaken by what I learned. The most important things I learned were about thinking. Toyota clearly thought differently about producing vehicles. Whether they have maintained these ways of thinking in spite of opportunities to be diminished by adopting the practices of The Big Three will have to be answered by someone else.

Before the Fremont factory had been turned over to NUMMI, I was told it had the worst record of management/labor conflict of any U.S. automotive plant. Now, management/labor conflict was nearly non-existent. Further, I was told that among the assembly plants connected to GM, the NUMMI factory (since Toyota entered the picture) had the best quality record, although it had the worst quality record of any Toyota assembly plant. It was my understanding that the top management of the NUMMI factory were Japanese, as were the engineering staff.

The first area we visited in the factory was the incoming materials warehouse. This warehouse was devoted to parts and materials supplied within the United States. Of course, the warehouse had visual controls. There were areas painted on the floor with signs over them that said how much of what items should be there. As I recall, supplies came into the warehouse on a four-hour cycle; that is, suppliers shipped enough of an item to last for four hours. These supplies would be on their way somewhere in a new vehicle in four hours. This was part of the JIT (Just in Time) materials supply system that has been copied throughout the U.S. (I was amused at the time by ads I saw in airline magazines offering to warehouse a supplier’s parts and send them JIT to their destination. This was a new, more expensive version of the push system for production and management of inventory that I suspect still exists.)

The answer to a question asked by someone else on the tour was stunning to me. The person asked what kind of computerized inventory system they had at NUMMI. The leader of the tour at the time – a materials management person – responded, “we don’t have one; the Japanese say that computerized inventory systems lie.” I was somewhat familiar with inventory at Big Three factories. Huge inventories of component parts were maintained. It sometimes took days of shut down to do a complete physical count of inventory. We were told that NUMMI could do a complete physical count in four hours – that made sense, since that was generally all the inventory that was there except for parts shipped in from Japan. Why the huge inventories in Big Three factories? Partly because the production system was a push system – vehicles were built to satisfy sales forecasts that were often overly enthusiastic, and partly because the parts were there Just in Case. If there was a failure on the production line, there needed to be lots of spare parts to keep production going. I had heard horror stories about production lines that were halted for lack of parts that were the right size, even though there were hundreds of thousands of parts – of the wrong size – in inventory. I had consulted with several companies that had a very difficult time matching up the records of inventory in their information system with the actual physical inventory. That is, the computerized inventory system contained “lies.” They spent a lot of time and effort trying to decide what the correct numbers were. As a result of the design and operation of their production and supply systems, NUMMI was able to avoid the expense of the computerized record system and the expense associated with management of huge inventories. Whatever was spent trying to keep the records straight and keep track of where the parts were in Big Three factories was not being spent at NUMMI.

A friend commented that he believes the material flow system used by Toyota may provide their biggest competitive advantage. In American manufacturing systems, one of the first steps in providing for material needed to produce a product is to create a Bill of Material (BOM) based on the design of the product. The BOM lists all of the parts needed; for example, a car needs one engine, four wheels, one catalytic converter, one steering wheel, two headlights, and so on. When the production of one car is planned, the BOM is used to order all the parts needed to produce the car. When the parts arrive, the appropriate electronic records of inventories are altered accordingly. Then when the car is produced, the BOM is used to delete the parts used from the inventory records. This is known as “backflushing.” Engineering changes involving changes to part content of a product should lead to corresponding changes to the BOM. When this doesn’t happen accurately or soon enough, use of the BOM and backflushing leads to accumulating errors in inventory records and incorrect orders. The result is computerized inventory systems full of “lies.” One company expects to save approximately ninety percent of the cost associated with inventory by switching to Toyota’s Kanban system. My friend pointed out that the Kanban system is self-correcting and does not require the labor hours, elaborate information systems, and inventory expense associated with traditional systems of material management. Another friend pointed out that many of the practices Toyota uses to manage material may have been adopted by The Big Three. That may be the case, but this example illustrates differences in purposes, concepts, and questions, and therefore methods, that can exist in organizations’ approaches to their work.

Use of the traditional approach to materials management and the consequent cost of inventory leads to distraction of the management that prevents them from addressing issues of greater importance to the future of the enterprise. The statement, “you can’t manage what you don’t measure” has become a mantra for American business. But, as a friend has observed, when one decides to measure something and attaches a meaning to the measurements, one has framed the questions to be addressed and defined suitable answers. NUMMI had no interest or need to keep detailed records of inventory. They had changed the question from “how do we manage inventory and reduce inventory cost?” to “how should material flow through the system?” The Big Three could gain great benefit from asking themselves what the important questions might be. I have often wondered how often managers of American businesses fall into the trap of using existing measures for no other reason than because they are there – required by regulation or for tax reporting purposes, rather than deliberately choosing indicators that will help them manage. Questions should precede answers.

At NUMMI, some automobile components were imported from Japan. One of these was the engine. Another person on the tour told us that a materials director at the engine division of a Big Three company had just issued an edict that the purchase price of every part being supplied from other divisions and outside suppliers had to be reduced by exactly the same percentage in the next year: ten percent. While touring the area where engines were inserted into the vehicles at NUMMI, the tour guide related that the Japanese had evaluated the importance of every engine component to the proper functioning of the engine. He said that they would then attempt to reduce the purchase price of components that were not as important while they invested resources in improvement and perhaps paid a higher price for components that were critical to reliability. The contrast between the foolish edict to reduce the prices of everything by the same percentage and the intelligent consideration of functionality and reliability of the product was another example of a difference in thinking – Toyota’s approach being far more mature.

In the stamping area, we learned that the same approach was used to design and build the dies that were used to stamp parts of the vehicle body. The material used on the surface of the die was very expensive, but extremely hard, while the other parts of the die were far less expensive than what was used in US companies. NUMMI’s dies served longer and were, overall, less expensive to build. These two examples illustrate the notion of optimizing an entire product system in terms of cost and performance, rather than sub-optimizing by trying to minimize each individual component’s up front cost. These are different ways of thinking about purpose and method.

At the time I visited, the NUMMI factory was not highly automated in terms of the use of robots. We saw robots helping factory workers put the seats in vehicles. We were told that robots were not used in the factory to replace workers; they were used to assist workers when the work was physically very demanding or difficult. I was reminded of a Big Three assembly plant where robots were installed to replace the welders who welded the frames of vehicles together. After a short time, the robots were removed and replaced by humans. The reason was that there was so much variation in the components coming in to be welded that the robots got confused and were making pretzels instead of frames. The human welders had been adjusting to that variation for years.

The replacement of people by machines is a favorite method used in the U.S. to affect accounted costs. However, direct labor is often the least expensive per hour kind of labor in a company. Machines must be maintained (or should be) and the software associated with automation and other computer operated equipment must be revised to accommodate changes in production processes. The labor expense associated with these activities is often more expensive per unit time than direct labor. Some of these expenses even show up as engineering or information systems expense. Sometimes, humans are needed instead of automation run by software because they are more adaptable and more easily maintained. The more complexity in any production system, the more opportunities there are for failure. The point here is that choices made in the design of a production system must be considered from a total system viewpoint, rather than from a simplistic, accounted cost viewpoint. I understand that Toyota’s new U.S. factories are highly automated. I would expect them to have been sensible about the design of these systems and to consider the possible consequences of their choices.

Lots of attention is paid to the cost of labor, and labor cost has been a favorite excuse for lack of competitiveness. But the options for ways to be non-competitive are limitless. I was told that one of The Big Three required that measurements on approximately 1200 “key indicators” were required to be reported to the central administration monthly. There were probably thousands of people accounted for in overhead doing the work to make those reports. There were not enough executives in the central administration to review all those numbers and probably a rare few of them knew what to make of the numbers if they did review them.

There is no question that existing obligations are major factors in the financial problems The Big Three are having. It is interesting that the big focus is on organized labor and the obligations for benefits to salaried retirees are not discussed nearly as much. The UAW certainly isn’t lovable, and the concessions they have obtained in terms of pay and benefits have been enormous and seriously detrimental in the long run. But one question keeps coming to my mind with regard to those concessions. Did the UAW simply issue an edict that there would be concessions? Of course, the answer is no. It takes two to make a contract and the management of The Big Three agreed to those contracts with the UAW. Surely there was someone in the management of each company that did some computations to see what the concessions would cost the company in the short term and the long term. I suspect that there was an extreme desire each time a new contract was negotiated to avoid a strike. After all, a strike would happen right away and would affect that year’s bonuses, but the consequences of the concessions would come to roost in the future and it would be more difficult to find someone to blame.

The central administrations of The Big Three tend to issue edicts to their organizations about what performance is expected. An edict issued in one of the companies stated that warranty cost was to be reduced by fifty percent this year to next year. The design and testing of a vehicle and its components takes several years. Major redesigns are not done every year. Major components are often carried over from one year’s vehicle to the next. The designs of vehicles and production systems for next year were already completed. How could such a reduction be achieved? Obviously, the individuals responsible for the edict were not thinking clearly about the constraints the nature of their business placed on performance. Of course, one “reason” for high warranty costs that regularly surfaced was that the dealers were cheating. So the edict to cut warranty cost by half may have been aimed at making the dealers behave.

Are we beginning to see a pattern here? Problems that are assigned to suppliers, direct labor, and dealers as sources of non-competitiveness appear to me to be manifestations of what Peter Senge called “The enemy is out there.” According to this view, some of the problems of non-competitiveness that are due to poor thinking and poor decision-making are ignored and the blame for all problems is assigned to some other group. If in no other way, we could all follow Michael Jackson in this regard and “start with the man in the mirror.” Reflection on one’s own role in one’s situation is difficult, but seems to be critically important to avoid repetition of the same mistakes.

I have not discussed what I saw in production at NUMMI in any detail because Toyota’s production system has been analyzed many times. One aspect of NUMMI that I thought was very important was management of the labor force. We learned that direct labor on the production line had secondary jobs that they were supposed to do if and when the production line stopped. They would do various equipment maintenance tasks and cleanup tasks. My understanding of Big Three direct labor is that production workers have no responsibility for maintenance; they have quotas for a shift’s production, and when they complete their quota they can go sit in the cafeteria or find a place to sleep. The management of NUMMI was able to negotiate an agreement with the UAW that enabled the assignment of auxiliary tasks to workers, but apparently the management of The Big Three were not.

As I understood it, there were work groups in production at NUMMI that rotated among different jobs in an area. There were levels of qualification that could be achieved by an individual worker for each job in the area. As a worker gained more training and experience, he or she was able to move up to the next level of qualification. The highest level of qualification was “teacher” or “instructor” or something similar. The work groups had improvement projects that they worked on. Their tasks involved improving the quality of the output of their area, or improving efficiency, or making the work easier to do, or all three. If they were able to demonstrate that their ideas for improvement were good, they would be implemented. As I saw it, these aspects of the organization of work helped to enable people to be engaged and to have a sense of contributing to their joint enterprise. At times, there may be too much focus on the technical aspects of the Toyota production system (lean, JIT, …) and not enough on the culture. The commitment that comes from personal pride in one’s work is a critical, but unmeasurable, aspect of any employee’s contribution to the enterprise.
The most remarkable insight I gained at NUMMI came as an answer to a question from a member of the touring group. The person asked what had been learned about the reasons that management/labor conflict had been reduced so much. The tour guide answered, “The answer we get from members of the labor force is that the Japanese do what they say they will do.” This was the same labor force that had held the record for most grievances filed per year in an assembly plant in the U.S. To me, this says a great deal about trust. There are circumstances in which you can trust a manager to be generous or kind or helpful; there are circumstances in which you can trust that manager to be harsh or intolerant of certain behaviors. In both cases, the manager who can be trusted to behave as you expect may be preferable to a manager who is unpredictable and cannot be relied on to provide the resources you need to do a good job. Some consultants imply that all managers need to do is to be nice to people and everything will be O.K. I doubt if that is sufficient.

Several months ago, I remarked to a person who deals with 401K investments in a very large financial management company that I didn’t think investments in American car companies would be a good idea. He remarked that I was wrong since they were coming out with some great new products that would be fuel efficient. I don’t think he knew very much about the nuts and bolts of building cars and trucks. The new products would at first only be a drop in a giant bucket. It takes years to develop and test new vehicles and to retool factories to produce them. The Big Three had equipped themselves to continue producing SUVs and other fuel guzzling products that were becoming more and more unattractive as gas prices shot up. As a friend remarked, redesigning a car is not the same thing as redesigning the label on a soup can. Equipping a production line to build a car is not the same thing as printing a different label. Of course, this may change in the future as more flexible factories are built. The point of my rambling here is that the press and Congress are talking about redesigning the automotive industry in the U.S. when I suspect very few of them are qualified to do that. I think it would be preferable to have members of the Toyoda family do it – wishful thinking, I’m sure.

After World War II ended, Toyota had, or created for themselves, the luxury of taking time to think, to experiment, and to learn with the conscious aim to improve their capabilities. If The Big Three were not in such a state of emergency, they could profit by asking questions aimed at sustainability and improvement, such as: What is important to our customers? (This requires actual research, not just speculation or the use of company mythology.) What kinds of changes do we expect in the future that might change what our customers need and value? What changes do we expect that will impact our ability to serve the needs of our customers? How can we improve our relationships with our suppliers and our customers? How can we make our work easier or simpler? How can we design the work so that it flows better? What products or processes need improvement? How can we improve the interactions that take place between departments? How can we more wisely use performance indicators and the information they provide? As it is, The Big Three seem not to have the luxury of careful thought.

The Big Three, and the entire international automotive industry, are in deep trouble at the moment. They are certainly not responsible for some of the trouble they are in. But The Big Three are responsible for managing their organizations wisely. I think that will take more than money. It will take a different culture and a different mind.

Overproduction: The waste you do on purpose

Claude Balie had made an interesting observation on the NWLEAN discussion group.

It [overproduction] is the only one [waste] that results from a decision. You don’t decide “no quality” or “useless transportation.” You just suffer from them as you try to improve.

Interesting point.

Profitable Value Streams

Lean Product and Process Development by the late Allan Ward is an interesting view into his extensive research into Toyota’s product development system. I am still reading it (along with Product Development for the Lean Enterprise
by Michael Kennedy. The books present the same basic model in different ways, though I should point out that it Kennedy is obviously a protégé of Dr. Ward.

One key point really jumped out at me, and challenges the traditional mindset of the design engineering community.

The output of product development is a profitable value stream.

Think about that for a minute. How does this mindset alter the focus of the design engineering subtask of product development?

Walking the Gemba

Duke left a great question as a comment to “A Morning Market.” He asked:

What’s the key differences between the [morning] market meeting and a gemba walk? Maybe I should ask what is the purpose of a gemba walk?

Good question.

I’ll start with one of my (other) favorite quotes from an old friend, Dave:

“It isn’t about shaking hands and kissing babies.”

That is to say, a lot of leaders think that heading out to the work area to “show the flag,” and do a meet-and-greet with the team members is “walking the gemba.” While they may be at the gemba, and they may actually be walking around, this isn’t it.

Walking the gemba is part of “Check” in Plan-Do-Check-Act. It is the process of carefully observing to see where things are not as they should be. Sometimes there is less walking involved, and more just standing and watching.

This, of course, begs the question: Watching for what? This, ultimately, is what makes it different than even just walking around looking.

Try this exercise. Go to some place where any activity is taking place. It really doesn’t matter what. If you aren’t in a factory, just go watch someone doing data entry or computer work. Watch the receptionist process walk-in customers and phone calls.

Note: Whatever you choose, please talk to people and tell them what you are doing, otherwise this is going to seem creepy to them if they aren’t used to it.

Get a feel for what is happening. More importantly, try to envision what is supposed to be happening. If this process were going perfectly, how would it look? Try hard to visualize in your mind a smooth, totally value-adding work flow.

Now, as you watch, become totally conscious of what is really happening. Why is this process other than how you visualized it? What disrupts the work? Where could mistakes be made? What keeps those mistakes from being made? Is it just vigilance? Or is there some mechanism to either prevent the mistake or either cue the person on the correct way, or alert them on the incorrect?

Is there any backtracking, rework, looping around? Are things where they are actually needed? Do people have to look around for things?

How do they know what they should be doing? What is their source of information? Do they have to hunt it down, or worse, guess at what should be done? Or is the “right thing” and the “right way” chrystal clear to even the casual observer (that would be you).

Is there a pace to the work? Even if it isn’t traditional takt-time work (especially if it isn’t), there is some kind of deadline. How does the person know whether things are on time or not? When do they learn they are behind?

If the person encounters some kind of problem, something unexpected, something needed but not there, what happens? Is there a support system to get this person back on-process? Or is he or she left to their own devices to just figure it out?

As you watch, keep your standard very high. If something is not obviously as it should be, then question whether it is. “Control” has the burden of proof here, not chaos.

When you see these things, focus in on one of them. Ask yourself “Why?” does this condition exist? Where does the problem originate? Go there. Study some more. How is it that this process fails to support its customer? Do they have a clear understanding of what is expected? (Probably not, most don’t, especially administrative processes.) How do they know they delivered (or didn’t) what their customer required? Did they think their output was defect free (according to their standards), but was really causing problems for their customer?

Often it helps to look at one person doing a single task, find a single issue, and follow the trap line upstream until you arrive at the origin of the problem. Often, again, you will have a fixable root cause right in front of you.

Now the fun begins. As a leader, it is not your job to fix the problem. That is not what you are looking for.

When you walk the gemba, you are assessing how well your organization is tuned to seeing these issues, clearing them, finding their causes, and solving them. If you see these opportunities, then your job now is to teach.

Grab whoever it is whose responsibility bounds both the effect and the origin of the problem. Guide him through the same things. If this issue was unaddressed, there are a couple of problems this leader must address.

First, there is someone downstream likely coping with an issue that he should be raising. (Or worse, there is no process for raising the issue, or worse still, no process to respond if he does.) If that isn’t happening, help this leader understand that this is the shortfall here, not the actual issue. It is now his turn to teach, in turn, either the Team Member, or whatever leader is between him and the Team Member.

Second, upstream, there is a process which either does not understand what “defect free” is, or does not have (or does not use) a positive way to verify it before sending it along. Same issue. This is a leader training process until the education reaches the level that should be doing the checks and the verifications.

The best way to learn how to do this is to walk your flow with someone who has the skill. It is simply a skill, and it can be taught. But learning also requires some humility, and the student must bring that to the “classroom.”

So, to recap in two short statements.

  • The gemba walk is a “Check” of Plan-Do-Check-Act.
  • You are checking the health of your leadership systems by looking at how they engage their people and processes.

Walking the gemba is a process of developing your people.

A3 – A Process, Not A Form

Kris Hallan is a frequent contributor on the LEI forum at lean.org.
In this post, he outlines some great experiences with trying to implement the “A3 process” in his organization. Lean Forums – A3.

One thing that really drove home what goes wrong most of the time with the A3 process, and frankly, with most well-intentioned efforts to bring good analysis into organizations, was his experience of an early effort to try to “require” it without having the behaviors to back it up:

One of the worst things you can do is require an A3 be written and then allow a poor A3 to get past you. This has a tendency to happen when you put an A3 mandate on something that you don’t necessarily have control over. For instance, we started by requiring all CAPEX [capital expenditure – ed] projects to be proposed using the A3 format (hoping that the A3 thought process would come with the format).

What we got was a lot of projects summarized on A3s and virtually no feedback to go back and improve anything. No one learned anything from the process, no hanei occured, and nemawashi was non-existent. It became a box that everyone had to check. This can have a very detrimental effect on people’s attitude toward A3. Since they don’t take it seriously, they can’t really learn anything from it. I would say that this actually moved us backwards in our understanding of problem solving.

I could not agree more. I have seen this in other companies. This is PLAN-DO without the CHECK and ACTion. Set an expectation, go through the motions of compliance, but don’t ever bother to see if it is actually working the way that is expected.

The good news, further into his post, is that Kris’s organization figured it out and found that doing it thoroughly is more important (and quicker!) than doing it fast.

A Morning Market

In past posts, I have referred to an organization that implemented a “morning market” as a way to manage their problem solving efforts.

Synchronicity being what it is:

Barb, the driving force in the organization in my original story, wrote to tell me that their morning market is going strong – and remains the centerpiece of their problem solving culture. In 2008, she reports, their morning market drove close to 2000 non-trivial problems to ground. That is about 10/day. How well do you do?

Edited to add in March 2015: I heard from Barb again. It is still a core part of the organization’s culture.

So – to organizations trying to implement “a problem solving culture” and anyone else who is interested, I am going to get into some of the nuts and bolts of what we did there way back in 2003. (I am telling you when so that it sinks in that this is a change that has lasted and fundamentally altered the culture there.)

What is “A Morning Market?”

The term comes from Masaaki Imai’s book Gemba Kaizen pages 114 – 118. It is a short section, and does not give a lot of detail. The idea is to review defects “first thing in the morning when they are fresh” – thus the analogy to the early morning fish and produce markets. (For those who like Japanese jargon, the term is asaichi, but in general, with an English speaking audience, I prefer to use English terms.)

The concept is to display the actual defects, classified by what is known about them.

  • ‘A’ problems: The cause is known. Countermeasures can be implemented immediately.
  • ‘B’ problems: The cause is known, countermeasures are not known.
  • ‘C’ problems: Cause is unknown.

Each morning the new defects are touched, felt, understood. (The actual objects). Then the team organizes to solve the problem. The plant manager should visit all of the morning markets so he can keep tabs on the kinds of problems they are seeing.

Simple, eh?

Putting It Into Practice

Fortunately we were not the pioneers within the company. That honor goes to another part of the company who was more than willing to share what they had learned, but their key lesson was “put two pieces of tape on a table, divide it into thirds, label them A, B and C and just try it.”

They were right – as always, it is impossible to design a perfect process, but it is possible to discover one. Some key points:

  • There is a meeting, and it is called “the morning market” but the meeting does not get the problems solved. The difference between the organizations that made this work and the ones that didn’t was clear: To make it work it is vital to carve out dedicated time for the problem solvers to work on solving problems. It can’t be a “when you get around to it” thing, it must be purposeful, organized work.
  • The meeting is not a place to work on solving problems. There is a huge temptation to discuss details, ask questions, try to describe problems, make and take suggestions about what it might be, or what might be tried. It took draconian facilitation to keep this from happening.
  • The purpose of the meeting is to quickly review the status of what is being worked on, quickly review new problems that have come up, and quickly manage who is working on what for the next 24 hours. That’s it.
  • The morning market must be an integral part of an escalation process. The purpose is to work on real problems that have actually happened. Work on them as they come up.

Just Getting Started

This was all done in the background of trying to implement a moving assembly line. There is a long back story there, but suffice it to say that the idea of a “line stop” was just coming into play. Everyone knew the principle of stopping the line for problems, but there was no real experience with it. As the line was being developed, there were lots of stops just to determine the work sequence and timing. But now it was in production.

The first point of confusion was the duration of a line stop. Some were under the impression that the line would remain stopped until the root cause of the problem was understood. “No, the line remains stopped until the problem can be contained,” meaning that safe operations that assure quality are in place.

The escalation process evolved, and for the first time in a long time, manufacturing engineers started getting involved in manufacturing.

The actual morning market meeting revolved around a whiteboard. At least at first. When they started, they filled the board with problems in a day or two. They called and said they wanted to start a computer database to track the problems. I told them “get another board.” In a few days that board, too, filled up. It really made sense now to start a computer database. Nope. “Get another board.” That board started to fill.

Then something interesting happened. They started clearing problems.

PDCA – Refining The Process

The tracking board evolved a little bit over time.

The first change was to add a discrete column that called out what immediate measures had been taken to contain the problem and allow safe, quality production to resume. This was important for two reasons.

First, it forced the team to distinguish between the temporary stop-gap measure that was put in immediately and the true root-cause / countermeasure that could, and would, come later. Previously the culture had been that once this initial action were taken, things were good. We deliberately called these “containments” and reserved the word “countermeasure” for the thing that actually addressed root cause. This was just to avoid confusion, there is no dogma about it.

Second, it reminded the team of what (probably wasteful) activity they should be able to remove from the process when / if the countermeasure actually works. This helped keep these temporary fixes from growing roots.

You can get an idea of what a typical problem board looked like here:

Morning Market White Board

The columns were:

  • Date (initial date the problem was encountered)
  • Owner
  • Model (the product)
  • Part Number (what part was involved)
  • Description (of the part)
  • Problem (description of the problem)
  • A/B/C (which of the above categories the problem was now. Note that it can change as more is learned.
  • Containment Method
  • Root Cause (filled in when learned)
  • Countermeasure (best known being tried right now)
  • Due Date (when next action is due / reported)
  • Verified (how was the countermeasure verified as effective?)

A key point is that last column: Verified. The problem stays on the board until there is a verified countermeasure in place. That means they actually tested the countermeasure to make sure it worked. This is, for a lot of organizations, a big, big change. All too many take some action and “call it good.” Fire and forget. This little thing started shifting the culture of the organization toward checking things to make sure they did what they were thought to do.

Refining The Meeting

While this particular shop floor was not excessively loud, it was too loud for an effective meeting of more than 3-4 people. Rather than moving the meeting to a conference room, the team spent $50 at Wally World and bought a karaoke machine. This provided a nice, inexpensive P.A. system. It added the benefit that the microphone became a “talking stick” – it forced people to pay attention to one person at a time.

Developing Capability

The other gap in the process that emerged pretty quickly was the capability of the organization to solve problems. While there had been a Six Sigma program in place for quite a while, most of skill revolved around the kinds of problems that would classify as “black belt projects.” The basic troubleshooting and physical investigation skills were lacking.

After exploring a lot of options, the organization’s countermeasure was to adopt a standard packaged training program, give it to the people involved in working the problems, then expecting that they immediately start using the method. This, again, was a big change over most organization’s approach to training as “interesting.” In this case, the method was not only taught, it was adopted as a standard. That was a big help. A key lesson learned was that, rather than debate which “method” was better, just pick one and go. In the end, they are all pretty much the same, only the vocabulary is different.

Spreading The Concept

In this organization, the two biggest “hitters” every day were supplier part quality and supplier part shortages. This was pretty much a final-assembly and test only operation, so they were pretty vulnerable to supplier issues. This process drove a systematic approach to understand why the received part was defective vs. just replacing it. Eventually they started taking some of their quality assurance tools upstream and teaching them to key suppliers. Questions were asked such as “How can we verify this is a good part before the supplier ships it?” They also started acknowledging design and supplier capability (vs. just price and capacity) issues.

On the materials side, the supply chain people started their own morning market to work on the causes of shortages. I have covered their story here.

As they implemented their kanban system, morning markets sprang up in the warehouse to address their process breakdowns. Another one addressed the pick-and-delivery process that got kits to the line. Lost cards were addressed. Rather than just update a pick cart, there was interest in why they got it wrong in the first place, which ended up addressing bill-of-material issues, which, in turn, made the record more robust.

Managing The Priorities

Of course, at some point, the number of problems encountered can overwhelm the problem solvers. The next evolution replaced the white board with “problem solving strips.” These were strips of paper, a few inches high, the width of the white board, with the same columns on them (plus a little additional administrative information). This format let the team move problems around on the wall, group them, categorize them, and manage them better. Related issues could be grouped together and worked together. Supplier and internal workmanship issues could be grouped on the wall, making a good visual indication of where the issues were.

"Problem Strips" at the meeting.
“Problem Strips” at the meeting.

But those were all side effects. The key was managing the workload.

Any organization has a limited capacity to work on stuff. The previous method of assignment had been that every problem was assigned to someone on the first day it was reviewed. It became clear pretty quickly that the half a dozen people actually doing the work were getting a little sick of being chided for not making any progress on problems 3, 4 and 5 because they were working on 1 and 2. In effect, the organization was leaving the prioritization to the problem solvers, and then second guessing their choices. This is not respectful of people.

The countermeasure – developed by the shop floor production manager, was to put the problems on the strips discussed above. The reason she did it was to be able to maintain an “unassigned” queue.

Any problem which was not being worked on was in the unassigned queue on the wall. All of the problems were captured, all were visible to everyone, but they recognized they couldn’t work on everything at once. As a technical person became available, he would pull the next problem from the queue.

There were two great things about this. First, the production manager could reshuffle the queue anytime she wanted. Thus the next one in line was always the one that she felt was the most important. This could be discussed, but ultimately it was her decision. Second is that the queue became a visual indicator that compared the rate of discovering problems (into the queue) with the rate of solving problems (out of the queue). This was a great “Check” on the capacity and capability of the organization vs. what they needed to do.

There were two, and only two, valid reasons for a problem to bypass this process.

  1. There was a safety issue.
  2. A defect had escaped the factory and resulted in a customer complaint.

In these cases, someone would be assigned to work on it right away. The problem that had been “theirs” was “parked.” This acknowledged the priority, rather than just giving him something else to do and expecting everything else to get done too. (This is respect for people.)

Incorporation of Other Tools

Later on, a quality inspection standard was adopted. Rather than making this something new, it was incorporated into the problem solving process itself. When a defect was found, the first step was to assess the process against the standard for the robustness of countermeasures. Not surprisingly, there was always a pretty significant gap between the level of countermeasures mandated by the standard and what was actually in place. The countermeasure was to bring the process up to the standard.

The standard itself classified a potential defect based on its possible consequences. For each of four levels, it specified how robust countermeasures should be for preventing error, detecting defects, checking the process, secondary checks and overall process review. Because it called out, not only technical countermeasures, but leadership standard work, this process began driving other thinking into the organization.

Effect On Designs

As you might imagine, there were a fair number of issues that traced back to the design itself. While it may have been necessary to live with some of these, there was an active product development cycle ongoing for new models. Some of the design issues managed to get addressed in subsequent designs, making them easier to “get right” in manufacturing.

What Was Left Out

The things that got onto the board generally required a technical professional to work them. These were not trivial problems. In fact, at first, they didn’t even bother with anything that stopped the line for less than 10 minutes (meaning they could rework / repair the problem and ship a good unit). But even though they turned this threshold down over time, there were hundreds of little things that didn’t get on the radar. And they shouldn’t… at least not onto this radar.

The morning market should address the things that are outside the scope of the shop floor work teams to address.

Another organization I know addressed these small problems really well with their organized and directed daily kaizen activity. Every day they captured everything that delayed the work. Five second stoppages were getting on to their radar. Time was dedicated every day at the end of the shift for the Team Members to work on the little things that tripped them up. They had support and resources – leadership that helped them, a work area to try out ideas, tools and materials to make all of the little gadgets that helped them make things better. They didn’t waste their time painting the floor, making things pretty, etc. unless that had been a source of confusion or other cause of delay. Although the engineers did work on problems as well, they did not have the work structure described above.

I would love to see the effect in an organization that does all of this at once.

No A3’s?

With the “A3” as all the rage today, I am sure someone is asking this question while reading this. No. We knew about A3’s, but the “problem solving strips” served about 75% of the purpose. Not everything, but they worked. Would a more formal A3 documentation have worked better? Not sure. This isn’t dogma. It is about applying sound, well thought out methodology, then checking to see if it is working as expected.

Summary

Is all of this stuff in place today? Honestly? I don’t know. [Update: As of the end of 2011, this process is still going strong and is strongly embedded as “the way we do things” in their culture.]  And it was far from as perfect as I have described it. BUT organized problem solving made a huge difference in their performance, both tangible and intangible. In spite of huge pressure to source to low-labor areas, they are still in business. When I read “Chasing The Rabbit” I have to say that, in this case, they were almost there.

And finally, an epilogue:

This organization had a sister organization just across an alley – literally a 3 minute walk away. The sister organization was a poster-child for a “management by measurement” culture. The leader manager person in charge sincerely believed that, if only he could incorporate the right measurements into his manager’s performance reviews, they would work together and do the right things. You can guess the result, but might not guess that this management team described themselves as “dysfunctional.” They tried to put in a “morning market” (as it was actually mandated to have one – something else that doesn’t work, by the way). There were some differences.

In the one that worked, top leaders showed up. They expected functional leaders to show up. The people solving the problems showed up. The meeting was facilitated by the assembly manager or the operations manager. After the meeting people stayed on the shop floor and worked on problems. Calendars were blocked out (which worked because this was a calendar driven culture) for shop floor problem solving. Over time the manufacturing engineers got to know the assemblers pretty well.

In the one that didn’t work, the meeting was facilitated conducted by a quality department staffer. The manufacturing engineers had other priorities because “they weren’t being measured on solving problems.” After the meeting, everyone went back to their desks and resumed what they had been doing.

There were a lot of other issues as well, but the bottom line is that “problem solving” took hold as “the way we do things” in one organization, and was regarded as yet another task in the other.

About 8 months into this, as they were trying, yet again, to get a kanban going, a group of supervisors came across the alley to see what their neighbors were doing. What they saw was not only the mechanics of moving cards and parts, but the process of managing problems. And the result of managing problems was that they saw problems as pointing them to where they needed to gain more understanding rather than problems as excuses. One of the supervisors later came to me, visibly shaken, with the quote “I now realize that these people work together in a fundamentally different way.” And that, in the end, was the result.

In the end? The organization in this story is still in business, still manufacturing things in a “high cost labor” market. The other one was closed down and outsourced in 2005.

Without Standards There Can Be No Kaizen

The meaning of this famous quote, attributed to Taiichi Ohno, becomes much more clear in the context of “Chasing the Rabbit” and previous published research by Steven Spear.

Spear’s research goes beyond Toyota’s process and delves into a more general question about how any organization playing in an otherwise level field can continuously out perform similar organizations in similar circumstances. This makes Toyota is a subset or an instance of a very fundamental principle, rather than a special, complex, unique case.

I think that is important. Some critics say Spear is making a soft version of the TPS. I think quite the opposite. He is explaining why it works.

And why it works comes right back to Ohno’s quote.

To better understand Ohno’s quote, let’s compare Ohno’s context with Spear’s.

All of us have been taught Ohno’s three elements of standard work:

  1. Takt time
  2. Work sequence
  3. Standard inventory

In “Decoding the DNA of the Toyota Production System” (a summary of his PhD dissertation), Spear describes the first rule-in-use he observed:

All activities are highly specified in terms of content, sequence, timing and outcome.

Further, Spear’s research concluded that the process steps themselves include frequent, nearly continuous, built-in checks that are designed to call attention to any departure from the specification. It is those built in checks which, on an assembly line, trigger an andon call and start the escalation process.

It is the escalation process which, in turn, results in problem solving and improvement.

It is any departure from the standard which calls the standard itself into question and results in investigation to understand more about the process.

The elements of takt, sequence and standard inventory define not only standard work, but they define elements of the built-in checks.

Takt time is the standard. Cycle time is the actual.
Actual cycle time is compared to the takt every time the process is carried out. If it takes longer than expected – problem, andon, escalation, problem solving.

The defined work sequence is the standard. It is (or should be) checked against the actual work sequence every time it is carried out. If something knocks the worker off the standard sequence – problem, andon, escalation, problem solving.

The standard inventory is the minimum amount of inventory required for the process to be successful at takt. Just as the work cycle is timed against the takt time, actual inventory can be compared with the standard. Too little? The process gets halted. That is a problem. Andon, escalation, problem solving. How do you check for too much inventory? Inside a process, specified inventory locations (5S, folks!). Inventory out of place? That is a problem. Andon, escalation, problem solving.

In regular takt-based work, these things in combination are a very effective set of cross checks of actual vs. specified work. BUT these are only tools that set up the system for kaizen.

It is the problem solving – the seeking to understand why the exception occurred that is true kaizen. This should must happen rapidly and every day. Not just during special “events,” every day.

It is part of the work, just like putting on protective equipment, just like maintaining the machines, just like cleaning up. Only this part of the work actually improves the operation.

So – without first specifying what is supposed to happen, there is no way to determine if what actually happened is routine or cause for investigation, learning and improvement. Then the exceptions become the routine because there is no expectation of otherwise. Look up the term “normalizing of deviance” and get an idea what the ultimate consequences can be.

That is why the first step in improving a process is often to attack ambiguity itself. This is especially true in administrative processes, and it is critical at the points where one process step turns over work to another.

If a defect-free outcome has not been specified, people are left with the leadership cop-out of “do the best you can” and that results in continuous erosion of morale, quality, delivery, cost. It is anti-kaizen. It is what is very much like kaizan – faking it.