Focus and Leverage Part 206

Build the PRT

When building a PRT start at the top of the tree with the injection you want to accomplish. The injection becomes the objective of the PRT.  The Objective and IO’s are in square cornered boxes and the obstacles are in round cornered boxes.  This is strictly a symbol to separate the two thoughts when looking at the tree in addition to the box titles.

As a beginning point, look at your list of IO’s and determine if you can find two of them that are connected.  In other words, is there one IO that must exist before another IO can exist?  When you look at the IO’s ask yourself, “What must happen just before this IO can exist?”  If the answer is an IO on the list then, we can make the connection with a necessity arrow.  If a plausible IO does not exist then, determine what the new IO would be and write it down.  Let’s make a connection from the Dome Company list.

 

 

It is not necessary to connect to the objective first.  It is possible that the first connection could come from two independent IO’s.  So, if we read this out loud; “In order to have Production synchronized to maximize throughput, I must have scheduling changed to a “pull” system, because Current scheduling is a push system.”

With this connection you’ll notice that IO-1 is connected to OBS-1 by the necessity arrow.  All of the IO’s will always be paired with the corresponding obstacle.  At this point you can ask, “Is there anything else required to be in place just before the objective?”  Or, we could also ask, “What entity must exist just before IO-1 can be achieved?”  Is there another IO on our list that must happen before we can change scheduling to a “Pull” system? Let’s keep building and make the connections some additional connections.

In our next posting we will complete our Prerequisite Tree (PRT) before moving on to our next TOC Thinking Process tool.

Bob Sproull

 

 

 

Focus and Leverage Part 205

Prerequisite Tree (PRT)

 

In a previous posting we presented the Future Reality Tree (FRT).  The FRT is the final step in determining a possible answer to the question; “What to change to.” The FRT was used to test possible injection(s) to help solve the problem.  Once an answer has been isolated that appears to create the Desired Effects for the future we must determine how best to implement the idea.  The PRT allows for the logical links, and thinking, to determine what steps will be necessary to implement the idea (injection) and make it a reality.  The PRT becomes the transition tool to move the thinking from “What to change to” to “How to cause the change to happen.

Prerequisite Tree (PRT)

The PRT is necessity based with its logic.  In other words, when reading the PRT we revert back to “In order to have entity A…. I must have entity B.” With the PRT we are trying to surface, and overcome, the obstacles (reasons) about “WHY” we can’t implement our injection (idea) right now.  What stands in the way of making our good idea a reality?  What things must be overcome to implement the new idea? With the PRT we will surface the obstacles that could/will stop us from implementing the injection and develop the Intermediate Objectives (IO) that will allow us to overcome the obstacles.  The IO’s will be the entities that must exist to overcome and remove the obstacles.

The PRT provides a structure that defines the intrinsic order of the tasks that need to be completed to implement the idea.  Using the previous thinking tools we have already surfaced a root cause with the CRT; determined, and solved, a conflict with the CRD by surfacing a plausible injection; and tested the selected injection using the FRT to make sure we get the desired effects we are looking for.  Now we will use the PRT to determine the required tasks that will be part of the implementation plan.  In our case, the PRT will be constructed as a continuation of a full systems thinking process analysis for the Dome Company.

Building the PRT

When you look at the selected injection from the FRT you might be thinking to yourself, “It’s a great idea but, how do I make that happen?”  The PRT will allow us to systematically divide this major task into a set of interdependent smaller tasks.  We will use the PRT to sequence the task completions based on the time dependencies.  In other words, which task do I do first? Which one is second?  Which one is third? etc.  The output of the PRT is a structured plan that defines the tasks and determines the intrinsic order for completion.

The PRT has three elements.

1.  Objective.  The objective is what we want to ultimately achieve with this process.  It’s the reason we are doing a PRT.  In our case, the objective would be the selected injection from the FRT that we want to implement.

2.  Intermediate Objectives (IO).  The IO’s are the ideas that will help us overcome and remove the obstacles that exist.  It is possible that a single IO can overcome more than one obstacle.

3.  Obstacles.  An entity that does, will or can block the achievement of the PRT objective.  Something that currently exists that could/will prevent you from achieving the injection.

First Step-PRT

The first step to develop a PRT is to list as many obstacles as you can think of that will/could block you from achieving the PRT objective.  In the case of the Dome Company our objective is: “Production is synchronized to maximize throughput.”

Once you have identified the list of obstacles it’s time to identify the Intermediate Objectives to counter the effects of the obstacles.  Remember: an IO is an entity that if it existed then, the obstacle would no longer be a problem.

The IO list now gives us the task list for those entities that must be completed to overcome the obstacles.  This list is not intended to be a complete list but, rather a starting point.  It is highly likely that additional obstacles and IO’s will be surfaced when you build the PRT.  In our next posting we will continue building our PRT.

Bob Sproull

Focus and Leverage Part 204

In this posting we will discuss negative effects and then complete the creation of our Future Reality Tree.  Before we do, let's look at our last graphic from Focus and Leverage Part 203.



 

Negative Effects

Let’s pursue a possible negative effect branch from DE-6.  Just from the shear nature of the entity it would appear that negative effects could come from this entity. Let’s build and see what happens.

 

 

From DE-6 to DE-25 is a desired effect and is the default of a DBR (synchronized) system that releases jobs based on the drum signal from the constraint. NE-10 and NE-20 start to become negative entities that if they exist in our future could cause our good idea to become a train wreck.  What we need now is an injection to overcome the possibility, or eliminate the entity of “The efficiency measure starts to go down.” 

If we insert a suitable injection we should be able to overcome the negative effects that will result if we don’t insert one.  By inserting a suitable injection we should be able to determine some desirable effects rather than negative effects and re-write the negative entities to become more desirable.

In this case we applied two additional injections to reverse the negative effect (Inj-2 and Inj-3).  Both of these injections came from the original CRD injection list and seemed to work well in the FRT.  The CRD injections are always a good place to look for any additional injections you might need.  However, it is also possible that the injection you seek is not listed.  In that case, ask yourself; “What must exist in order for the negative effect NOT to exist?”  Whatever the answer to that question is can become a possible injection.

Loop

The final diagram also contains a loop (the red line on the left side).  This loop signifies the repeatable action of the entities that can happen over and over again.  In this case the loop states the if, “Production flow will improve” then, “The internal measure changes from “push” to “pull”.”  In other words, if INJ-1 exists and the other entities logically linked to it exist then, the production flow will improve.

Now, we have a plausible FRT if, ALL of these entities and injections can be made to exist in reality. If they do exist it will allow us to overcome the undesirable effects (entities from the CRT) by implementing the injection (idea) that will allow us to turn things around and get Dome heading in the right direction.

Next – The Prerequisite Tree (PRT)

In the next step we will determine “WHY” we can’t have “Production is synchronized to maximize throughput.”  In other words, what obstacles exist that stand in the way of making Inj-1 a reality?  If this injection is really the answer we need then, why can’t we have it today?  What’s stopping us from doing this righ now?  We can only assume that if it were an easy idea to implement, it would have already taken place – but it hasn’t!  The transition from the Future Reality Tree (FRT) to the Prerequisite Tree (PRT) will introduce how to move from “What to change to” to “How to cause the change to happen.”

I want to thank Bruce Nelson for this series of posts on the TOC Thinking Process analysis.  As you're seeing a complete TP Analysis takes time, but the results are worth the effort.

 Bob Sproull

 

Focus and Leverage Part 203

In this posting we will begin the actual construction of our Future Reality Tree and as I explained in the last several postings, we are going to take our time so that folks new to the TOC Thinking Processes can see the step-by-step process for building our FRT.

When you are building the FRT start at the bottom with the injection you are testing and build the tree upwards.  Remember: what we are trying to figure out is if the proposed injection becomes part of the reality will you achieve the desired effect you hope to achieve?

Let’s begin our construction of the FRT.  Use the selected injection from the CRD place it at the bottom and build upwards.  Remember: injections are in squared cornered boxes versus round cornered boxes.  This is strictly a symbolism to separate the two entities.  Ask the question “if the injection, then what?”  What would happen if the injection existed?  Write the injection in the present tense as if they already existed.  Using the CLR’s you can look for any additional cause(s) required, such as, a current desired effect, or an entity that would be needed to support the outcome of the desired effect.

We can keep building the FRT up from this point looking for additional desired effects that will happen with this injection.  Is this injection sufficient to cause anything else?  Are there any additional cause(s) to support the next entity?

 

At this point several desired effects are starting to fall into place – good things could/will happen if all of these entities happen.  However, we still haven’t identified a negative branch for those entities that we don’t want to happen.  Let’s look at the tree and see if a negative branch does exist.  In this tree for learning purposes we will identify the Negative Effects as “NE”.  This will help you distinguish which entities are negative effects when building the tree.  In our next posting we will look into the negative effects and continue building our Future Reality Tree.

Bob Sproull

 

Focus and Leverage Part 202

Future Reality Tree (FRT)

In a previous posting we presented the Conflict Resolution Diagram (CRD).  The CRD was used to generate and surface the assumptions between the arrows and several possible injections to overcome the identified conflict.  The CRT and the CRD were the tools we used to help answer the question: “What to change to.”  The Future Reality Tree will be used to continue the analysis to determine what to change to.

Future Reality Tree (FRT)

The FRT is sufficiency based with its logic.  In other words, when reading an FRT we revert back to the “If entity A…. then, entity B.  With the FRT we are still trying to isolate the answer “what to change to.”  The FRT is the thinking tool that provides a platform to test ideas and look for the merits and also the possible negative effects that might be created in the future.

Many times people will have a seemingly good idea to solve a problem.  The FRT allows a person to test the merits of the idea before taking any action to implement it. The FRT is a logical way to construct a solution that yields a high degree of assurance that the existing core problem and undesirable effects from the CRT can/will be eliminated without creating any new undesirable effects.  The FRT also provides a means to look for any negative effects that might appear if, and when, the new idea is implemented.  The FRT permits the structure of a plan to verbalize and communicate a future vision of reality.  The FRT can also be used as a standalone thinking tool to test the virtues of an idea.  In our case, the FRT will be constructed as a continuation of a full systems thinking process analysis for the Dome company.

Constructing the Future Reality Tree (FRT)

The FRT has five (5) primary components in its structure.  Each component provides a different piece of the puzzle.  These components are:

1.  Injection

2.  Desired Effect

3.  Positive Branch

4.  Negative Branch

5.  Loop

Injection: an entity that does not exist yet, but when it does it will provide a desirable effect in the future.

Desired Effect (DE):  It is the reason for implementing an idea.  The DE’s can be the opposite, or replacements for the UDE’s defined in the CRT

Positive Branch: those entities that describe only the positive desirable outcome of an idea.

Negative Branch: The entities or portion of an FRT that describe the potential undesirable effects that could come from an idea.  Injections are added to overcome the negative effects.  The negative branch is a good way to see (and understand) when and where a good idea might go bad.

Loop:  The ability to connect an entity higher in the tree with an entity lower in the tree.  The self-reinforcing loop shows the cyclical nature of why things keep happening the way they do.

The square cornered boxes in an FRT represent the injections.  Injections are those entities that don’t exist yet but, if they did would lead to desired effects.  The round cornered boxes represent entities that could exist (desired effects) in the new reality.  The “effects” represent entities, both desired and undesired, that don’t exist yet but, could/will exist in the future as the inevitable results of the entities pointing to them.

In our case we will test the injection(s) from the CRD in the Dome business case.  You might remember we developed four (4) possible injections to break the conflict at B à D. Those injections were:

1.  Production synchronized to maximize throughput.

2.  Company policy changed to a throughput/profit measure.

3.  Bonuses are determined based on throughput.

4.  Change the cost measure to throughput.

With the injections surfaced in the CRD (on all the arrows) they should all be sufficient to break the conflict.  However, not all injections are equal.  Each injection could present a different path to success and each could/will vary in the amount of time it takes or, the amount of money needing to be invested, or the number of resources required or, the number and possible severity of the negative branches encountered.

Desired Effects

Once you have picked an injection to test the merits of the idea then, write down the Desired Effects that you would expect to see coming from the idea.  In our case, we picked the first injection, “Production is synchronized to maximize throughput.”  It is possible to develop the Desired Effects list using the Undesirable Effects (UDE’s) from the CRT and verbalizing the opposite effect.  In others words, a desirable or desired effect  If the UDE’s are the entities that currently exist, and you don’t want them to exist then, what entities do you want to exist?

Desired Effects

1.  On-time delivery improves

2.  Production orders are entered into the system correctly

3.  Product quality improves

4.  Production change orders are minimal

5.  Production rework time is reduced

When you are building the FRT start at the bottom with the injection you are testing and build the tree upwards.  Remember: what we are trying to figure out is if the proposed injection becomes part of the reality will you achieve the desired effect you hope to achieve?

In our next posting we will begin developing and building our Future Reality Tree looking at possible negative effects and other parts of the FRT.

Bob Sproull

Focus and Leverage Part 201

In this very short posting we will look at how to select and break a conflict articulated one of the conflicts in the Conflict Resolution Diagram.  For reference, let’s first refer back to the completed Conflict Resolution Diagram presented in our last posting. In looking at the completed CRD there appears to be an advantage to breaking the conflict on the B to D arrow.  By breaking this arrow we would hope to achieve the objective, maintain both requirements, and implement a production schedule based on the “pull’ system.  If we could break this conflict, breaking the D to E conflict becomes much easier.

 

This conflict selection process is something as simple as:

 

BREAK THE CONFLICT AT THE B to D ARROW - PICK ONE!

 

1.  Production synchronized to maximize throughput.

 

2.  Company policy changed to a throughput/profit measure.

 

3.  Bonuses are determined based on throughput.

 

4.  Change the cost measure to throughput.

We have surfaced several injections, each with the probability of resolving the conflict by breaking any of the arrows.  By choosing to break the conflict at B à D we have 4 reasonable injections on this arrow, and each appears sufficient to break the arrow and resolve the conflict.  The choice now becomes which injection do we want to use?  Having this choice is an enormous benefit of the CRD.  In the original conflict it appeared as if there was no way out of the conflict!  Now, we have four (4) possible answers to choose from.  Each injection is not equal.  Each could cost money and/or time to implement with no guarantee that the results will reap the benefits that are desired.  What we need is a way to test the injection(s) and make sure it provides the end result that we want.  That is the purpose of the Future Reality Tree (FRT).  The FRT can be used to test injections and make sure the desired results are achieved and to help ensure that the negative side effects that might arise are identified in advance and taken care of.  In the next segment we will discuss how to create the FRT and what it will do for us.

 

Bob Sproull

 

Focus and Leverage Part 200

In this posting we will continue building our Conflict Resolution Diagram (CRD) by surfacing our assumptions and injections for our remaining entities (i.e. B to D, and A to C) and then we’ll begin looking at the conflict that exists between D and E.

We start once again by using our necessity based logic syntax, “In order to have Production scheduled to utilize available capacity (Box B), I must have Production scheduled based on the “push” system (Box D), because…?”

1.  Production needs to be busy ALL the time.  If they aren’t are efficiency metrics will drop outside of an acceptable range.

2.  Company policy mandates the efficiency measure.  Following company policy is important.  If it wasn’t important we would not have to follow any policies.

3.  Production management bonuses are tied to efficiency.  If we didn’t use efficiency as a bonus measure management would not be motivated to get better.

4.  Higher efficiency generates higher ROI.  The Returned On Investment must there.  Otherwise is was a poor investment.

Transfer these assumptions to the CRD

 

 

 

These assumptions are the reasons why the arrow between B and D seems valid.  Either why you, or someone else, thinks the necessary condition “must” be there.   Now look for the possible injections, ask yourself “What must exist in current reality for the assumption to no longer exist, or to go away?” 

Possible injections:

1.  Production Maximized to synchronize throughput.  If efficiency is eliminated and the system is synchronized for throughput then, system benefits will be achieved.

2.  Company policy changed to a throughput/profit measure.  Companies create policies and they can also change them.

3.  Bonuses are determined based on throughput.  Just like polices and procedures the company measures can also be changed.  Measure the right thing to get the right results!

4.  Change from cost measure to throughput.  A radical change in measures from Cost Accounting to Throughput accounting.  Eliminate efficiency and measure system throughput.

Transfer these assumptions to the CRD

 

Again, these assumptions are the reasons why the arrow between A à C seems valid.  Either why you, or someone else, thinks the necessary condition “must” be there.  Now look for the possible injections, ask yourself “What must exist in current reality for the assumption to no longer exist, or to go away?” 

Possible injections:

1.  The right product mix equal maximum profit. Scheduling the right products at the right time will enhance profitability.

2.  Maximize throughput to increase profits.  Maximizing throughput will generate the most profit in the least amount of time

3.  Measure management on throughput.  Measuring system throughput will still give management a measurement, it just focuses on the right measure.

Transfer these injections to the CRD

 

 



We will continue this process and surface assumptions for C à E.  This will be the last two entities on the second leg (bottom) of the CRD.

Now we will continue this process and surface assumptions for C à E.  This will be the last two entities on the second leg (bottom) of the CRD.  Following our necessity based logic we say, “In order to have Production generate the maximum number of products (entity C), I must have Production scheduled based on the “pull” system (entity E), because…?”

1.  Because a “pull” system decrease the production lead-time.  The more synchronized the flow is the faster is will move through the system.

2.  Pulling slows the release.  Synchronized pull system

3.  WIP will go down.  Synchronizing the pull system to the DBR will cause WIP to be reduced..

Transfer these assumptions to the CRD

 



 

 

Again, these assumptions are the reasons why the arrow between C à E seems valid.  Either why you, or someone else, thinks the necessary condition “must” be there.  Now look for the possible injections, ask yourself “What must exist in current reality for the assumption to no longer exist, or to go away?” 

Possible injections:

1.  No injection required. This is probably a valid assumption that does not need to be broken with a suitable injection.

2.  Implement a Drum-Buffer-Rope (DBR system.  DBR provides an excellent pull system scenario to control the release of work based on the system drum beat.

3.  WIP will go down.  A natural output from a DBR system is the reduction in system WIP

 

Transfer these injections to the CRD.

 

This completes the Assumptions and Injections and in our next posting we will look at the conflict that exists between entities D and E and surface ways to break this conflict.

Bob Sproull

 



Focus and Leverage Part 199

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.

 

These assumptions are the reasons why the arrow between A and B seems valid.  Either why you, or someone else, thinks the necessary condition “must” be there. With each assumption surfaced you also want to identify a corresponding injection.  When you look for an injection, ask yourself “What must exist in current reality for the assumption to no longer exist, or to go away?”  The answer to this question becomes the injection.  The injection (idea), if it existed, would invalidate the assumption and essentially break the arrow.

Possible injections:

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.

Bob Sproull