In the previous post, I introduced Stephen Spear’s 1999 Ph.D. dissertation on the Toyota Production System. In that paper, Spear outlined 5 “Rules-in-Use” which he saw as the fundamental principles driving the inner workings of the production system that Toyota developed over many decades. These are not written down anywhere within Toyota but were developed over those decades through a rigorous devotion to mastering the art of learning and teaching others how to learn. Sounds a little spooky at first but starts to make a lot of sense as you read through Spear’s 511-page dissertation. It does not cover a lot of theory, but actual practices carried out on a daily basis within the organization. And he spent three and a half years inside Toyota – not in the offices, but at the gemba – observing their day-to-day behavior.
I then contrasted these 5 “Rules-in-Use” with the 4 primary attributes that describe complex adaptive systems. And what did we find? The 5 Rules-in-Use and the 4 attributes complement each other very well. The Rules-in-Use appear to be a useful set of tools to manage a complex adaptive system. TPS is a complex adaptive system and these Rules-in-Use have allowed Toyota to manage that system very, very successfully over decades. And it has accomplished that through rigorous system simplification!
[Note: If you have not read any of the previous posts in this series, some of what I just said may not make much sense to you. If you want to catch up, I recommend you hop over to my Table of Contents and start reading somewhere near the beginning of the 5-part series on “Simplifying the Complex”. But if you want to keep reading, no problem. Much of what I will be discussing will stand on its own.]
OK, where were we? Oh yes, I said I would finally begin to outline how these Rules-in-Use generated many of the so-called “tools” that we see in Today’s Lean lexicon. We will begin to see how these Rules-in-Use simplify the various complex production systems that has caused so many headaches for so many people for so many years. Hopefully we will better understand “Why Lean works” (the subtitle of this blog) and why, all too often, it doesn’t.
For your easy reference, I will again list the key attributes of a complex adaptive system:
Complex systems begin with individual components called autonomous agents, which make decisions and produce results in the system. To be complex, a system:
- Requires diversity in the types of agents. If they are diverse, they will respond differently to various inputs, producing more varied results.
- Requires connectedness. …The agents must have a way to contact one another.
- Requires interdependence, which means that the agents influence one another.
- Requires adaptation. In complex systems, adaptation means more than change; rather it refers specifically to learning.
Remember, complexity is not necessarily measured by the quantity of each of these attributes that exist in a given system, but by how much total energy must be expended to make the system work (or not work) with the actual attributes contained within the system. And what is this energy I am referring too? That would be the human effort, money and time required to operate and manage that system. (For a general overview of system thinking, see my previous post “Who does the thinking around here anyway?”).
I outlined a summary of the “Rules-in-Use” in my last post, but I will now cover each of them in more detail. I will also try to illustrate how each of these rules assist in managing the various attributes of a complex adaptive system. (For a general overview of Spear’s “Rules-in-Use”, see pages 32 – 39 in his dissertation – the PDF page numbers not the actual paper).
Rule 1: guides the design and performance of all individual activities.
Rule 1 states: design and perform every activity so that it is structured and self-diagnostic.
According to Spear:
“To be structured, an activity must be designed and performed with a prespecified sequence of steps, an expected time per step, and an expected outcome”.
“To be self-diagnostic, an activity must be designed so a built-in test immediately generates a binary (yes/no) signal if:
(a) the activity is actually performed in a way different from its design or
(b) the result is different than the predicted (defect-free) outcome.
The signal must be interpretable as ‘a problem has occurred in the performance of a specific activity’”.
“A structured, self-diagnostic activity is a hypothesis-testing experiment. A problem signal refutes one of two hypotheses: that the supplier is capable of performing the activity as it is designed, or that the activity is capable of producing a defect-free outcome if it is performed as it is designed”.
Rule 1 focuses on an activity by an individual (or a machine, if that is appropriate). It does not focus on groups of people (or machines) – the other rules cover those situations. And the rule applies every time that activity is performed. The rule outlines a series of questions that must be answered every time that activity is performed:
- Was the prespecified sequence of steps able to be performed?
- Were the prespecified sequence of steps able to be performed in the time allotted?
- Was the expected outcome achieved?
And the answer to each of these questions must have a binary answer – “Yes” or “No”. “Close enough” or “almost” or “I’ll get it next time” doesn’t count. If “Yes”, then the JIT Pillar is working. If “No” then the Jidoka Pillar kicks in.
As I outlined in the post linked above:
“The two pillars of the TPS House, Just-In-Time (JIT) and Jidoka, are must “hows”. They are true pillars and without these, TPS cannot achieve the “Goal” outlined in the roof. JIT establishes flow and Jidoka makes visible any interruption of flow and/or visibly stops flow when the quality of that flow is jeopardized. Together they make flow (or lack thereof) visible. Together they establish lead time and make time visible. Together they make quality (or lack thereof) visible. Together they make cost visible. JIT creates the flow; and Jidoka interrupts the flow to make the waste that is preventing continuous flow visible.”
Or as Spear concisely expresses it:
“Rule-1 guides the design and performance of work activities done by people and machines that transform material, energy, and information. Rule-1 plays a critical role in creating opportunities for problem-solving and learning, and it reflects the theme that each use of an activity is a chance to verify the assumptions implicit in the design of the activity. Therefore, every performance of an activity is an experiment which serves as an opportunity to learn about the process and the person doing the process.”
As you may have guessed, Rule-1 establishes, among other things, the foundation for the “Lean tool” we all call “Standard Work”. But unfortunately, most descriptions of that “tool” imply it is a stand-alone entity that tells workers what they must do in performing their day-to-day activities. Very rarely do discussions of “Standard Work” outline how that tool fits in with the other “Lean tools” to create a system – a complex adaptive production system – that facilitates learning above all else. “Standard Work” is not a “check list”, it is one critical piece of a total problem-solving system.
“Standard Work” is the pre-specified sequence of steps, the time per step and the expected outcome. But the significance of Standard Work is not in the doing, but in the success of the resulting outcome. Were you able to perform the steps in the time allotted and with the expected outcome? If you get “yes” answers you repeat – that is “Just-in-Time”. If you get a “no” answer, you stop – that is “Jidoka”. And Jidoka initiates “Kaizen”. After Kaizen, Standard Work is revised, and you start all over again.
If you get a “No” answer, then you must ask “Why”. And you must ask “Why” in real-time and repeat the “Why” question until you can understand the problem, determine the root cause(s), implement appropriate counter measures and start getting “Yes” answers again.
Standard Work is just the first step in a learning cycle. Does this sound familiar to another “Lean tool” called PDCA? (Hint: the answer is “yes”).
I think it is appropriate to quote Shigeo Shingo again here:
“We have to grasp not only the Know-How but also ‘Know Why’, if we want to master the Toyota Production System.”
Ok, this all sounds good. But what is this built-in “binary (yes/no) signal” thing that’s supposed to tell me if a problem has occurred? Am I supposed to stand around and ask myself a bunch of questions after every activity is completed? Is that built -in to my prespecified sequence of steps? Do I have time allotted to talk to myself? Well, no. This is where “visual control” or “visual management” comes in. This is where many of those “Lean tools” originated.
Spear also calls this signal a “binary signal switch” (opened with a request, closed with a response). And this self-diagnostic signal switch applies to all the Rules-in-Use. These visible “switches” are as varied as the multitude of processes that can be found in any given system.
Spear talks about his realization that much of the work he was doing at various Toyota plants encompassed designing and installing devices and processes that had the same “binary, self-diagnostic, switch-like qualities”. He went on to say:
“Then, as I visited other plants, I saw that individual customers and suppliers were linked consistently by similarly constructed ‘switches’ even though the physical form of the particular signaling tool might be different. For example, Kanban cards, andon lights, music, andon boards, empty containers, full containers, empty locations, full locations, deviations from standardized work, two people talking, an idle machine, an idle person, an active person were all used in different circumstances – as a binary, signaling switch.”
The type of signal to be used for a given process will vary depending on the information needed, the nature of the processes being used and the type of inputs and outputs the system requires. But the signal must be easy to use, and it must be visual. The signal types are only limited by your imagination. The existence of these binary yes/no signals tend to become a habit over time in a TPS environment. We all need to learn that habit. Spear also worked in a Big 3 auto plant while he was studying Toyota (see below). He makes continued references to the fact that the Big 3 never learned that habit. And as a result, they were never able to successfully compete against true TPS. (I’ll illustrate a one-to-one comparison between Toyota and the Big 3 in a minute).
Here is an example of how the “tools” and “signal switches” are used by Toyota to continuously validate the performance of a particular activity using Rule-1.
“Standard work” is the means for specifying what the prespecified steps should entail. “Takt time”, also included in “Standard Work”, is a tool to specify the response time to a given request. Spear provides an example where these two tools are used in the installations of seats in a moving automobile assembly line. The floor at the workstation is marked in time intervals. The worker knows at what time intervals each of his prespecified steps must be completed. This is the “expected outcome”. A quick visual check by the worker or his Team Leader will tell them if the work is being performed as specified. If “yes”, the work proceeds as planned. If “no”, the proverbial “Andon cord” is pulled and the magical “Andon light” appears. The Team Leader arrives and problem solving is begun immediately. (The Andon system is a signal switch in itself. Pulling the cord is a signal request for assistance and the arrival of the Team Leader is the response).
The prespecified steps are defined by the “Standard Work”, the time per step is defined by the “takt time” and the expected outcome is measured by the visual markings on the floor, a binary (yes/no) signal switch. And this “hypothesis-testing experiment” is performed every time the activity is attempted – every time.
Other well-known examples of self-diagnostic signals/switches are covered in the extensive discussions of “poka-yoke” made popular in the West by Shigeo Shingo. Spear also covers a myriad of real world examples of Rule-1 being applied (and not applied) in chapter 7.1 of his dissertation. In fact Chapter 7 and its sub-chapters take up half of Spear’s total dissertation and describe his hands-on experiences at the gemba for each of his 5 Rules-in-Use.
So how does Rule-1 help me manage my complex adaptive system? How does it simplify my life in that complex world? Well, Rule-1 attacks the first attribute of complex systems (see above), the diversity of independent agents, which states: If they are diverse, they will respond differently to various inputs, producing more varied results. As I stated in my last post:
“Attribute 1 deals with the diverse performance of activities by individuals (i.e., decisions they make and actions they take) and how the results of these activities can vary from individual to individual. Spear’s Rule-1 guides the performance of all activities by designing in a structure behind each activity to standardize and simplify decision making and thus reduce variation.”
Spear describes his experience installing front seats in a Big 3 auto plant versus his experience doing the exact same job in a Toyota plant. At the Big 3 plant, the worker was instructed to install four bolts at a certain torque. And although he knew how much total time he had to do the job (the time until the auto body left his work area), he was not instructed as to the order of bolt installation or the time each step should take (time varied depending on whether you were installing front bolts or rear bolts). Spear saw that different workers did the job differently. But there was no effort made to determine the “best” way to do the job.
At Toyota, on the other hand, the exact sequence of bolt installation was specified and the time for each step was quantified.
At the Big 3, if the worker had problems, and Spear did have frequent problems, each worker had to work around the problem and try to finish the job in the allotted time. If he was not able to complete the job correctly or on time, the worker would enter a code into the computer that indicated that the job was not completed successfully. And the auto moved on and the problem would be addressed in a later rework step by someone else. Although the procedure called for workers to “notify” if problems were found, Spear said he never clearly knew “who” he was supposed to notify.
At Toyota, if a problem with bolt installation was encountered (and that problem would be identified immediately due to the time sequence protocol) and he did not have an immediate solution, the Andon cord must be pulled (or via some other notification method) and the Team Leader would respond immediately – and I mean “immediately”. If they couldn’t solve the problem in the allotted time, the line would be stopped until the problem was addressed. No known defects were to be passed down the line for any reason. And not just any Team Leader would respond. There was only one Team Leader who was responsible for that process step. If for some reason that Team Leader could not respond immediately, there was a very simple Andon Board in place that would notify a single assigned Group Leader who would respond in his place. This was structured to go up 4 levels if necessary. (The Andon system is really a subset of Rule-2, but I have included it here to illustrate how seriously the self-diagnostic aspect of Rule-1 is adhered to. How problem solving would be carried out is covered in Rule-4).
So, Rule-1 simplifies the diversity problem by assuring that individual activities within the system are less diverse in response to varying inputs and thus minimizes the variation in activity results. Remember, Rule 1 states: “design and perform every activity so that it is structured and self-diagnostic”. Inputs are structured and outputs are self-diagnostic. Decision making is simplified and resulting variation is reduced.
With TPS Rule-1, you are finding and addressing problems in real-time using a few right people. Root causes are relatively easy to identify and countermeasures can be evaluated quickly. At the Big 3, however, problems are sent around the system to be patched, not fixed, by many wrong people. Root causes are hidden and countermeasures cannot be applied. Time plays a major role at Toyota and is used wisely. Time plays virtually no role at the Big 3 and is simply wasted.
Which system is easier to manage? Which is simpler?
In my next post I will tackle Rule-in-Use 2.