In this posting we will complete our Current Reality Tree for Dome and then talk about next steps. The Thinking Process Tools are quite dynamic and can be used to solve a variety of system problems. The problem in many organizations is that the symptoms that exist are often mistaken as the problem to be solved and we end up only treating these symptoms. In reality they are part of a chain of cause and effect relationships which terminate with a true root cause or core problem. Herein lies the real power of the CRT…..identifying the one or two core problems that create all or most of the negative symptoms (UDEs) that exist within our organization. Let’s continue on and complete our CRT, so you may want to keep our last posting handy for reference (i.e. Focus and Leverage Part 194).
At this point it could become possible that the next entity we are looking for might not be on our list, especially if we look at entity 10 and 60. Let’s look at both entities, 10 and 60, and see if there is a statement on our list that might be the effect of either one of these. It doesn’t appear as if there is a fit, at least for what we have listed. If that is the case, then ask the question: “What would be the effect of either one, or both of the entities?” How about a statement that reads: “Some customers are unhappy with Dome’s performance.” It wasn’t on the list but, it is probably an entity statement that does exist. So, now we will invoke the Entity Existence reservation from the CLR’s and determine if the some customers are really unhappy with Domes performance. As it turns out, this is a true statement. Why else would they want Dome to pay a late charge? It makes sense.
As you can see, by adding this statement to our tree it also adds clarity to reading the tree and adds the missing piece as to “why” on-time delivery might be affected.
1.Quality is becoming a problem.
2.New product design/ development seems slow.
Let’s look first at “Quality is becoming a problem.” There are two places to start. First, ask yourself, “what caused Quality to become a problem? The second question would be, “What effect happens because of the poor Quality?” The most probable answer to either of these questions is not on our remaining UDE list. Let’s work the quality statement and see if we can figure where it fits and why. This scenario is a great opportunity to look for any Predicted Effects (one of the CLR’s) that might come from poor Quality. As you ask the question(s) and look for predicted effects it is important to validate any affects you might discover. Even though an effect might be logical, it can only be valid if it exists in your reality. Let’s look for some predicted effects and see if they exist.
Let’s ask the question “What else might you expect to see if Quality was poor? We might expect to see that “many products have been returned.” We might also expect to see higher levels of “product rework” because of failed inspection. In the business case write-up, neither of these negative affects we listed. However, that doesn’t mean they don’t exist.
What we have discovered is two predicted effects that would/should exist if Quality really is becoming a problem. If you observe the system, or ask the questions, to find out if these entities exist then, you can validate the entities. If neither one of these entities exist then, it is doubtful that Quality is a real concern (maybe it happened once or twice, but does not occur on a regular basis). However, if one, or both, of them exist, then the Quality problem is validated. For the sake of discussion let’s assume that both of these entities were validated to exist at Dome. Let’s work these into the tree. It is possible that there is cause-effect-cause relationship between 120 and 130, i.e., many products being returned could cause higher levels of rework and repair. If there are higher levels of rework and, repairs and rework take additional production time then available production capacity is reduced doing repairs and rework. If production capacity is reduced doing rework and repairs then, it helps provide another causality as to “Why” on-time delivery is poor.
By adding this next segment to the CRT the causalities for poor on-time delivery begin to expand. Another question to ask at this point is “Why is Quality becoming a problem?” In other words, we see the effect but, what is that cause? If we search for the cause there could be several possible answers. One possible cause is that Production is trying to build too fast and is making mistakes. Another possible cause is that product inspection is not finding (or overlooking) the production flaws in order to keep up with the demand. (it can happen in many companies in order to keep pace with cash flow demands.)
There is no “and” statement here because each entity by itself could be sufficient cause to generate the effect. If one, or both, of these entities exist they could be causalities for the Quality problem. If neither entity exists then, the search continues for an applicable cause. For our discussion, let’s assume that both do exist. Let’s take it one step further for these entity effects and ask “Why do they exist?”
These two additional entities (160 and 150) would make sense to cause both 140 and 141. So far this CRT has expanded greatly and surfaced additional entities that were not part of the original UDE list. In all fairness the search for additional entities could continue, almost to an infinite level. But, at some point you need to decide “When is good enough – good enough?” These lower entities were not revealed in the original business case, not because they aren’t important, but because the people at Dome didn’t view them as problems. Their assumption is that efficiency is “important”, and if I push the products in they will come out. Let’s look at the entire CRT.
The general rule when analyzing a CRT for the root cause is to find the entity nearest the bottom that has the most arrows coming out of it. Or, to find the entity that causes at least 80% of the remaining entities. The 80% rules is most typical when you have a tree configuration that contains two distinct branches (or more) that seem to run parallel to the top. With each branch covering basically a different subject matter. Go as deep as you can, find the one with the most arrows coming out if it, or that causes at least 80% of the other entities and you’ve found (most likely) what you are looking for.
There was one additional UDE that has not been discussed yet. The UDE was “New Product Design/Development seems Slow.” If you think about this UDE it probably does exist but, it is outside the scope of this CRT. It is mostly un-to-itself. The design side would present a different subject matter than the production side. Right now we are interested in getting products delivered on time and not necessary designing them on time – at least not yet. With that said it would be possible to work the “New Product Design/Development seem Slow” UDE into this tree. However, it would add complexity and much more time to scrutinize and develop.
The real benefit of a CRT is being able to collect the UDE’s and realize that they are not individual problems that need to be solved in isolation but, rather there is a cause-effect-cause relationship between them. We could spend a lot of resources and time trying to solve these individually. The CRT allows, with some time and thinking, the ability to FOCUS on the problem that will provide the most LEVERAGE to improve the system.
With the CRT information now in your hip-pocket and the first part of the system analysis complete it is time to ask a question. Based on this tree – what do you think the root cause is for Dome's problems? In the next segment we will use the Conflict Resolution Diagram (CRD) to continue our analysis.