Spear’s “Rules-in-Use” – Rule 3: Simplifying System Flow

Spear’s “Rules-in-Use” – Rule 3: Simplifying System Flow

In my previous two posts, I covered Rule-in-Use 1 and Rule-in-Use 2 as outlined in Steven Spear’s 1999 Ph.D. dissertation on the Toyota Production System.

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.

Rule 2: guides the design and operation of connections between activities.

Rule 2 states: design and operate the connection between every person who or every machine that supplies a good, service or information and the customer who receives the specific item so that the connection is direct, ‘binary”, and self-diagnostic.

We now move on to his third of five rules.

Rule 3: guides the design and operation of flow paths (systems of connected activities) over which goods, services or information take form within or among organizations.

Rule 3 states: Each good, service and piece of information must have a pre-specified, simple, self-diagnostic flow path over which it will travel as it takes form.

According to Spear:

“For flow-paths to be pre-specified, every good, service, or information must have one and only one flow-path over which it is expected to travel as it takes form. This means each of the activities that will contribute to the production and delivery of the good, service, or information must be assigned uniquely to a single person or machine.  This requires that what will be done, by which supplier, in what order, must be defined.”

And:

“To be simple, a flow-path must not have loops or intertwined branches.”

And:

“To be self-diagnostic, a flow-path must immediately generate a binary (yes/no) signal if a good, service, or information travels over a flow-path other than the expected one.  The signal must be interpretable as “a problem has occurred in the production and delivery of a specific good, service, or information over a specific flow-path, either because a supplier expected to perform an activity did not, or a supplier not expected to perform a specific activity, actually did.” (i.e., a person not assigned the responsibility for providing a specific good, service, or information, to a specific customer, actually did.)”

While Rule-1 guides the design and performance of individual activities and Rule-2 guides the design and operation of the connections between activities, Rule-3 guides the design and operation of the flow paths between this system of connected activities.

So with these three rules we have gone from managing individual activities and connections within the system to managing the entire system flow. And in a “production system” (a system that creates value, whether as a physical product or a service) that means we have three guiding principles that cover everything from procurement of raw materials to the transformation of these raw materials into value added entities to how these transformed products are transferred through the system to the final customer. I don’t know about you, but I’m impressed.

But that’s not all!

Remember, the thesis behind this thread series is that TPS, as developed and practiced by Toyota, reduces the complexity and simplifies the operation and management of “complex adaptive systems”. We’ve previously shown how Rule-1 and Rule-2 helps us achieve that end. Now we will see Rule-3 takes us even further.

For an in-depth discussion of “complex adaptive systems”, please go back to my 5 part series on “Simplifying the Complex” (see Table of Contents). But for your easy reference, I will again layout the 4 key attributes and general system dynamics 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:

  1. Requires diversity in the types of agents. If they are diverse, they will respond differently to various inputs, producing more varied results.
  2. Requires connectedness. …The agents must have a way to contact one another.
  3. Requires interdependence, which means that the agents influence one another.
  4. Requires adaptation. In complex systems, adaptation means more than change; rather it refers specifically to learning.

To understand how a complex system operates, it is necessary to think about the strength of each of these four elements. …At a setting of one, the system is uninteresting. It may have the elements of complexity, but nothing much is going on. Diversity is low, connectedness and interdependence are weak and the result is almost no adaptation or learning taking place. At a setting of ten, the system is chaotic. Agents receive too much information from too many sources and are stymied in their decision making by conflicting and overwhelming signals. Where complexity is most intriguing is…. the “interesting in-between”. This means the dials are set somewhere between three and seven, with each dial different from the others. This allows a good flow of information, interaction and learning among diverse agents, but not so much that the system becomes chaotic. This is the heart of complexity – a system that continuously produces surprising results without breaking down.

Remember, complexity is not necessarily measured by the quantity of each of these four 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.

And as we learned in earlier posts, complex systems tend to add complexity over time to tackle more and more problems. That requires exponentially more of that magic energy. In order to avoid eventual collapse, we have only two options: 1) get more of that human effort, money and time, or 2) simplify the system.

And if properly understood and applied, Spear’s Rules-in-Use should help us reach that “interesting in-between” mentioned above by actually simplifying our production system.

With respect to the four attributes, we have already demonstrated that Rule-1 is primarily focused on attribute 1: diversity in individual activities (i.e., decisions they make and actions they take) and how the results of these activities can vary from individual to individual. Rule-1 guides the management of that diversity by designing in a structure behind each activity to standardize and simplify decision making and thus reduce variation. And we want to encourage diversity by seeking innovative solutions to any problems we encounter while carrying out those activities.

And we found that Rule-2 is primarily focused on attribute 2: connectedness of individuals/machines with each other. Rule-2 designs these connections in such a manner that they are always predictable and simple.

You want to guess which complexity attribute Ruel-3 addresses? Bingo! Interdependence. In fact, Spear hints at this when he says:

“Rule-3 guides the design and operation of the flow-paths – constructed from connected activities — over which final goods, services, and information are created.  Rule-3 plays an important part in reducing the number of interactions in the system, thus making cause and effect more obvious, reducing cognitive burdens, and decreasing the difficulty of system operation and improvement.  In reducing the number of interactions, Rule-3 contributes directly towards creating a nested, modular organizational structure.”

By reducing the number of interactions, you, by definition, reduce the level of interdependence that exists within the system. And by reducing the number of interactions necessary to run the system, you also reduce the level of energy required to manage that system. Why “fire fight” if you don’t have to!

We saw this reduction of interdependence/interactions when we discussed the role of Kanban buried in Rule-2. By using Kanban, we bypass the need to go through a centralized intermediary, e.g., Production Control. While the Kanban connection between two activities is covered by Rule-2, the bypassing of the centralized intermediary is really covered by Rule-3: the systemic flow path of material and information.

Still interested? I hope so.

So let’s jump into the details of how Rule-3 actually works. To recap:

Rule 3: guides the design and operation of flow paths (systems of connected activities) over which goods, services or information take form within or among organizations.

Rule 3 states: Each good, service and piece of information must have a pre-specified, simple, self-diagnostic flow path over which it will travel as it takes form.

Let’s take each of those three qualifiers one at a time.

Pre-specified

Spear (and by default -Toyota) states:

“For flow-paths to be pre-specified, every good, service, or information must have one and only one flow-path over which it is expected to travel as it takes form”.

OK. That’s pretty straightforward. Don’t we all do that already? If we make a WIDGET, we know what process steps to go through to end up with a finished WIDGET. What’s the big deal?

But Spear then says:

“This means each of the activities that will contribute to the production and delivery of the good, service, or information must be assigned uniquely to a single person or machine.  This requires that what will be done, by which supplier, in what order, must be defined.”

Oh! Yea….but…. I think we do that, but….

Let’s look at this a little more closely. Here is a simple process flow diagram for two products, A and B.

Figure 1

In this case both products go through Process I and Process II. But Process II has two identical machines, M1 and M2. Products A and B can go through either machine depending on which machine is available at the time. That makes sense. That’s what efficiency is all about! Right?

But Spear (and Toyota) say “No”. This process flow path is not pre-specified. A pre-specified flow path will look like this.

Figure 2

In this example the pre-specified process flow path for Product A would be Process I followed by Process II, machine M1. The pre-specified process flow path for Product B would be Process I followed by Process II, machine M2. OK. But that’s not efficient! What if we have a Product A coming off Process I and M1 is down but M2 is available? Why wouldn’t we just send Product A to M2? That’s efficient!

But is that effective?

If we go back to a previous post of mine, we discussed the difference between “efficiency” and “effectiveness”. According to Russell Ackoff:

Efficiency is a matter of doing things right; effectiveness is a matter of doing the right things.”

And Peter Drucker elaborated on Ackoff’s thinking:

“One might better be doing the right things wrong than doing the wrong things right.”

So why is the pre-specified flow path effective rather than efficient? Why is it the “right thing”?

There are several reasons why the pre-specified flow path is the “right thing”.

First, if M1 is down, we shouldn’t say “Oh well” and just send Product A to M2. We should say “Oh hell!” and ask, “Why is M1 down when we have Product A to produce?”. We can send Product A to M2, but we need that to be a warning flag that something is wrong and we need to address the problem. (That is the self-diagnostic qualifier in Rule-3).

Second, if we use the pre-specified flow path and we have a quality problem with Product A downstream, we only need to look at Process I and Process II, machine M1 to try to find the root cause. We know that the product went through these two steps and these two steps only. But with the non- pre-specified flow path we need to look at Process I and both M1 and M2 of Process II to try to find the root cause. And our chances of finding that root cause are much less probable since we probably don’t know what flow path was used. And this problem is only exacerbated if we have a long flow path with many process steps. Thus, a pre-specified flow path simplifies problem solving and learning. That is illustrated very well in these two figures:

Non-pre-specified Flow Path

Pre-specified Flow Path

Figure 3

Which flow path would you want to deal with if the processes are not perfect?  And they never are!

Third, the very fact that the system flow path is pre-specified is a key reason that Rule-2 concerning the design and operation of connections works so well. With a pre-specified flow path, a visual system of binary signals, DO/DON’T DO and DONE/NOT DONE, such as Kanbans, is feasible which clarifies system information and simplifies decision making. The supplier knows what, where and when to send product and the customer knows what, from where and when they will receive product. How many times have you experienced the following scenario?

Figure 4

A lot of that time and money energy thing is used up just in making a decision as to what to do.

But with a pre-specified system flow path, this decision making conundrum becomes a rare occurrence. And with the binary signal/trigger system, such as Kanban, in place the connection flow and decision making is simplified.

Figure 5

Which world would you rather live in? Which world encourages innovation, adaptation and learning? (More on that in a later post).

Fourth, just remember that Rule-3 doesn’t just apply to material and information (production) flow. Almost every function in the system should be governed by this rule. That includes job training and assistance, maintenance, problem solving, engineering, etc. A specific supplier and flow path should be assigned to each of these functions as well.

I covered Toyota’s pre-specified flow path for worker assistance in my discussion of Rule-1. But they have these built-in flow paths for all major support functions.

In Part 3 of my five part series on “Simplifying the Complex”, I discussed the almost miraculous advances achieved when I transformed a traditional manufacturing organization into a “Value Stream” organizational structure. All functional silos were folded into the individual value streams. I discovered that “interesting in-between” that was described in the “4 key attributes and general system dynamics of a complex adaptive system” I outlined above. All the attribute dials were brought into that magic middle range.

But if you look at the organization charts of Toyota, you see those functional silos sitting there staring you in the face. I always wondered why they did not organize around “value streams”. But after discovering these “Rules-in-Use” from Spear, I realized that Toyota, while having formal departments for Maintenance, Engineering, etc., the individuals within those departments were tied to individual value streams, on a person by person basis, via these pre-specified flow paths. Makes a lot of sense.

There are more “right things” we could cover here but I think these will suffice for now.

Just as Rule-1 requires a pre-determined structure for every activity and is the basis for “Standard Work”, Rule-3 establishes a basis for “Standard Work” for system flow.

A little clarification before we move to the next step. While Rule-3 states that every product (and service and information) must have a pre-specified flow path, the inverse is not true.

1 Flow per product ≠ 1 product per flow

A given flow path may be used for multiple products and is in fact encouraged. Mixed model production would not be possible without it.

Also, the flow path is not restricted to single machines in the case where product is moving from a higher capacity process to a lower capacity process where multiple machines/people are required to keep the flow moving. A strict sequencing protocol should be established to keep the flow path well defined.

OK, the next qualifier.

Simple

Spear states:

“To be simple, a flow-path must not have loops or intertwined branches.”

Stop! I sort of know what a loop is, but what the heck is an intertwined branch?

Yep, that was my reaction when I first read Spear’s dissertation. But lucky for you we’ve already covered that thing. I just didn’t call it that. See Figure 3: just label the top flow as “Intertwined Branches” and the bottom flow as “Simple Flows, no branches”. Done. And we have covered the key points as to why we want to avoid intertwined branches.

Spear covers some other, more detailed, cases to illustrate the problems with these branches. Here is an example of what looks like a perfect flow path.

Figure 6

But when you dig a little deeper, you find the actual flow path looks like this:

Figure 7

Before a product reached shipping, it could have traveled as many as 108 possible flow paths. And since this cell produced 7 different products, as many as 756 different flow paths could have been involved. This is obviously not the best situation to confront for after-the-fact problem solving. Cause and effect becomes very hard to discern.

And intertwined branches automatically increase the complexity of the system. The branches increase the number of activities with which each activity must interact. Interdependence can go off the chart.

This cell needs to be cleaned up, probably by forming 2 or 3 stand-alone cells for possible distinct product families.

Now let’s look at loops.

Taiichi Ohno, when talking about his “River System” in a 1990 interview said:

The river system is supposed to flow only forward, not loop backward.

He was specifically referring to “re-work” in this case but Ohno and company were averse to any loops that show up in process flow paths. Here is a simple example:

Figure 8

The primary reason for this aversion is the same as for their aversion to branches: loops make it more difficult to identify cause and effect relationships. In the above example, if you have a problem at P-II, the cause could not only lie in P-I or P-II itself, but also P-III and P-IV. Interdependencies abound. Not good for problem solving.

My favorite example of a deleterious loop is evident in almost every non-TPS manufacturing plant world-wide. That is the infamous central planning loop known as “Production Control”. I covered this topic on at least two other occasions when I was discussing MRP versus Kanban and also in my last post covering Rule-2.

In the typical non-TPS plant, Production Control sends production plan information to each separate work center every morning. The work centers then send information on what they produced back to Production Control at the end of the day. Production Control then digests that information and sends out new production plan information to each work center the next day. Rinse and repeat.

This daily (or more frequent) planning proccess is just one big series of information loops within the production system itself. Unfortunately, material and product does not flow unless allowed to do so by this planning loop information sub-system. Production Control communicates to every work center and vice versa. But the work centers do not communicate with each other. That is the source of the chaos illustrated in Figure 4.

But Rule-2 and Rule-3 allow a TPS structured plant to eliminate this gigantic loop sub-system. Production Control only issues a production plan to a single downstream work center as close to the customer as possible. Production information then flows upstream from work center to work center via Kanban along a pre-specified flow path. Material and product then flow downstream from work center to work center along a pre-specified flow path and to the customer.

Yes, let’s get rid of those loops. Reduce complexity through simplification.

Self-diagnostic

As you may have noticed, every Rule-in-Use we have covered emphasizes that every activity, connection and flow must have a self-diagnostic check of some kind embedded in that process every time that process is performed. I am convinced that this embedded feature is a key reason why TPS works so effectively and most generic Lean efforts do not come close.

Since my next post will cover Rule-4 and Rule-5 covering continuous improvement methodologies within the Toyota Production System, I will leave any further discussion of self-diagnostic tools until then.

But before I leave, I would like to leave you with a quote from a 1973 TPS Manual that was discovered and translated by Mark Warren. (I believe you need to be a Linkedin member to connect through the provided link).

TPS Manual – Chapter 1, 1973

It should not be overlooked that people, materials, and equipment on site are not independent from each other but rather intermingled in a complex manner.

For example, this is the vicious cycle: there are too many people → too many products (accumulate stock) → more people needed for clean ups, loading and unloading, storage or rework is required → even more people.

In this way, increasing one thing increases other things accordingly. In the workplace, complexity is in direct proportion.

The challenge to conquer complexity was embedded in Toyota long before Spear or myself ever tried to write about it. But better late than never.

 

Note: All graphics in this post are pulled directly from the Spear dissertation.


Leave a Reply

Your email address will not be published. Required fields are marked *