Sunday, April 7, 2013

Focus and Leverage Part 198

Building the Conflict Resolution Diagram (CRD)

In a previous posting (Focus and Leverage Part 195) we presented the completed Current Reality Tree (CRT) for the Dome company business case.  With the CRT we identified the probable root cause as: “The internal measure is for efficiency (push).”   Supported with the “and” statement: “The production schedule is not synchronized to production capacity.”  The efficiency measure, based on the CRT guideline of finding the entity lowest in the tree that has the most arrows coming out of it, supports at least 80% of the UDE’s, would certainly be probable.

With the CRT we have surfaced a possible core problem which will help answer the question: “What do we change, or what to change?”  In other words, it helps us focus the thinking on the entity where the real problem might be.  If the CRT logic is solid, then we have identified a probable causality for the Undesirable Effects (UDE’s) being experienced in reality.  By using the CRD we can now help build the bridge from “What do I change – the core problem” to, “what do I change to – the proposed solution.”  The CRD is the thinking tool that allows the transition for this important step.  So, with a potential core problem(s) identified the next question becomes: “What do I change to?”  The point being, that if the core problem no longer existed in the reality, then the negative effects that come from it will no longer exist as well.  Because many people have had problems constructing the CRD, we are going to create one slowly by taking a step-by-step approach….so those of you who understand how to do this, please bear with us.

Conflict Resolution Diagram (CRD)
This thinking tool originally started as the “Evaporating Cloud” in the early days of TOC.  There was also a period of time when it was referred to as the “Conflict Diagram.”  From that title it has evolved into to what we prefer to call it, the “Conflict Resolution Diagram (CRD).”  Even though this tool has many names and no matter what you decide to call this tool, the structure and intent of the tool has remained the same.

The CRD is necessity based in the logic and is read “In order to have entity A…(tip of the arrow) I must have entity B… (base of the arrow)”  The CRD structure is simple and requires the presence of an Objective, two requirements and two prerequisites.  In a typical full thinking processes analysis the objective for the CRD would be the opposite of the root cause from the CRT (which is usually a negative entity).  In other words, the negative effect (root cause) from the CRT is converted to a positive statement to define the CRD Objective.  In essence, we want to remove the causality for the undesirable effects (UDE’s) that come from the root cause.  In the Dome business case we defined the root cause as “The internal measure is for efficiency (push).”  So, in defining the CRD objective we might express the objective as: “Production scheduled at the most effective level.”  This CRD objective helps us overcome the UDE that the schedule is not synchronized and the measure for efficiency.  Referencing the CLR’s (Focus and Leverage Part 192 and 192B) will apply to the scrutiny of the CRD for ALL entities.  For example, you could employ the clarity clause on the entity statement.  Does it succinctly define what the objective really needs to be? 
Is this what you want to have happen?  Is this the objective you want to accomplish?  Remember: the wording is very precise.  We didn’t define scheduling at the most “efficient” level; we defined it at the most “effective” level.
Finding the Requirements
The next step is to look for two requirements that support the objective.  When doing a CRD you might have trouble trying to determine what the requirements should be.  A helpful suggestion would be to look at the branches on your tree, if in fact any exist.  The reason for this is because it might be possible to help define the requirements based on a “theme” associated with branches in your tree.  As an example, one branch might be associated with a scheduling theme.  While another branch might be associated are with measurement, or procurement, or something else.  The branch themes may help point you in the right direction for coming up with the necessary requirements.

When you look for CR requirements, using necessity logic, you are looking for those things (entity statements) that must exist just before the objective can be achieved.  In other words, “In order to have the objective (A), I must have the Requirement (B).  Write the statements to follow completion of the sentence using “In order to have “A”, I must have “B”.  When you write your statement using this method the statements now implies that entity “B” MUST be there.  Entity “B” can’t be there sometimes or most of the time, or even maybe.  It implies it MUST be there. Read the statement with those words and write the entity to fit the phrase.  It you follow this pattern the reading and flow will be much better

The two requirement entities (B and C) will be the requirements necessary to achieve the production scheduled at the most effective level.  Ask the question:  “In order to have production scheduled at the most effective level, I must have….What?  What you are looking for is a necessary condition that “must” exist to support the objective.  One of the most common requirements is for a company to be efficient in its use of resources.  This thinking can be stated in policy, or procedure, or assumed in the tribal knowledge of the company.  Most companies make efficiency a policy, not because they believe it’s the right thing to do but rather, because everyone else is doing it or, cost accounting mandates it.  So, “In order to have Production scheduled at the most effective level…I must have Production scheduled to utilize available capacity.”  The second requirement (entity C) is surfaced using the same questions: What must happen just before Production is at the most effective level? What you are looking for are two necessary conditions that must exist in order to achieve the stated objective of the CRD.  What two things would be necessary to do that?  The system would need to generate the maximum number of products to be considered effective.  So, the second requirement is to have “Production generate the maximum number of products.” Generating the maximum number of products in the system would certainly make the system appear to be effective.

When we add the second requirement to the CRD we now have two requirements necessary to achieve the objective.  In the first requirement we talk about using the available capacity and in the second requirement we talk about getting the maximum number of products through the system.  Both capacity utilization and getting products through faster could be considered requirements before production scheduling is considered to be at its most effective level.

In our next posting, we’ll discuss how we surface the Prerequisites for each requirement and then we'll continue on with the next steps.  Remember, we will be using multiple posts to demonstrate how to create the CRD.

Bob Sproull

No comments: