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?
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:
Post a Comment