In this posting we will continue building our Conflict Resolution Diagram by discussing how to surface the Prerequisites for each requirement and then begin surfacing the assumptions and injections for each entity. As we said in our last posting, we intend to present this material in a slow, methodical manner so the readers who aren’t familiar with the TOC Thinking Processes can better understand how these techniques work.Surfacing the Prerequisites
The prerequisites are the necessary conditions that support the requirements. This is also the step that will surface the most likely conflict between achieving the requirements in the CRD. The prerequisites are commonly referred to as entities D and E.
If we look at the requirement (entity B) in the CRD we are looking for the prerequisite (necessary condition) that must exist just prior to “Production scheduled to utilize available capacity.” What must exist just prior to this requirement to make it possible? You can also read from entity B to try and establish the prerequisite. In other words, “In order to have production scheduled to utilize available capacity… I must have what?” When you think about utilizing the available capacity most people immediately think about “keeping everyone busy - all the time!” On the surface, that seems like the best and most effective way to utilize the capacity. The best way to achieve that would be to schedule production based on a “push” system. The constant release of products into the system would maximize the probability of keeping everyone busy and utilizing the maximum capacity! Let’s plug it in and see what happens.
“In order to have Production scheduled to utilize available capacity, I must have Production scheduled based on the push system.” Seems to make sense and it seems to fit.
The second prerequisite is surface in the same manner. It will be a necessary condition to support the second requirement (Entity C). Again, ask the question: “What must exist just prior to, “Production generates the maximum number of products.” This can also be read, “In order to have Production generate the maximum number of products, I must have what? If we think about this prerequisite it immediately implies a system of smooth flow, low work-in-process (WIP) and short production lead-times, to get product through the system fast. This thinking would imply a “pull” system. In other words, release only when necessary instead of releasing all the time.
With the second prerequisite now added to the CRD the conflict now becomes obvious. In order to meet one requirement (entity B) I must use the “push” system. In order to meet the second requirement (entity C) is must use the “pull’ system. Both systems cannot exist at the same time! It is not possible to “push” and “pull” with the same schedule. With the conflict now surfaced, the second part of the CRD analysis is focused on breaking the conflict and determining the best solution to implement.
NOTE: When building a CRD it is a common mistake for people to actually verbalize the conflict in the requirements (B & C). When you determine the requirements make sure they are requirements that are needed to support achieving the objective. If the requirements actually read more like two opposing thoughts then, slide them out to D & E and look for new requirements to fill in B & C.
Surfacing the Assumptions and Injections
With the conflict surfaced we now extend the CRD to look for a solution to the conflict. The way to accomplish this is to surface, and evaluates, the assumptions that go with each arrow between the entities, either your assumptions or someone else’s. The assumptions are the reason “why” the stated necessary condition is important. In the CRD, each arrow between the entities is a solid black line because they are supported by assumptions. Assumptions can basically be in two categories – valid and invalid. Some assumptions, even though they are highly preached and believed, can be invalid! Challenging these assumption(s) is a way for logic to provide a pathway to override the emotions of belief that support some invalid assumptions.
There are five (5) arrows in the CRD on which assumptions can be surfaced. The next step is to surface the assumptions on the arrows between the entity statements. The purpose is to verbalize what those assumptions are and see if any (minimum one) can be invalidated with an injection (new Idea) that overcomes the assumption. An injection, once found, should be powerful enough to overcome the existing assumption and invalidate it. Once this happens the conflict can be broken and the “new” injection (idea) can replace the old assumption and dissolve the conflict.
We surface the assumptions by asking the question -”Because?” In order to have “A”, I much have “B”… because? The answers to the “because” question becomes the “assumptions” that appears to make the statement valid. When surfacing assumptions be BOLD. Don’t reject an assumption because you don’t believe it. The truth is, someone else might believe.
Let’s start by surfacing assumption on the A à B arrow.
“In order to have Production scheduled at the most effective level, I must have Production scheduled to utilize available capacity, because…?”
1, Capacity really is limited. There is only so much you can do with what you have.
2. Production is measured on system efficiency. I there any other way to measure a system besides efficiency?
3.Operators need to be busy all the time. If they aren’t busy ALL the time we should send them home, or lay them off!
4. Operators are measured based on machine utilization. There has to be a way to measure the individual contributions to the system. Individual efficiency is a way to do that.
Transfer these assumptions to the CRD.
1. Capacity is scheduled correctly. If capacity is limited, which it is, then, scheduling it correctly will provide benefit.
2. Production is measured on system throughput. Measuring system throughput will eliminate the need to measure efficiency.
3. Operators are busy only when they need to be busy. Synchronizing the production schedule based on Drum-Buffer-Rope (DBR) will eliminate the need to be busy all the time and be busy only when they need to be busy.
4. Operators are measured based on system throughput. A radical change in measures from efficiency to throughput. Measure the system and not each individual operator.
Once the assumptions and injections for A à B line have been surfaced, we can move to the B à D line. The same thinking process will be employed for ALL of the arrows. In our next posting we will continue to develop the CRD.
Once again I want to thank my good friend Bruce Nelson for writing this valuable series of post. In closing I want to let my reader base know that a group of “TOC Experts,” who shall remain nameless, have deemed Bruce and my methods as being incorrect and not in line with how Dr. Goldratt intended the Thinking Processes to be used. I can only tell you that our method has worked quite well for us over the years and that we will continue using it. It’s your choice as to whether you follow our method or some other method. Our purpose in this blog posting is simply to demonstrate the power of the TP’s. In a previous blog posting I wrote about the difference between being and optimizer and a satisficer……we choose to be satisficers.