Editor | On 02, Jan 2006

By: Larry Ball

Hierarchical TRIZ Algorithms is a how-to TRIZ book. It is designed to
assist both beginning and advanced users. Each month, the TRIZ-Journal will publish
another chapter of the book. Next month’s installation will cover the seventh process step:
G. What Causes the Problem
Next month’s installation will cover the eighth process step:
H. Turn Object Knobs (Properties) to Fix the Problem
In all, there will be 12 installments. Should you decide to purchase the most current
edition of the complete book contact the publisher at:
http://www.3mpub.com/TRIZ/

Introduction

The previous chapter helped us to define the main problem that we are trying to solve or the improvement that the system requires. We called this the big Y or the dependent variable that we would like to improve.
Y

Let us go back to the example of the acid container in the previous chapter. Recall that we identified the dependent variable as “Cost of Replacement”
Y= Cost of Replacement

A common misstep in problem solving is to identify what you would like to improve and then start brainstorming solutions. For instance, we could easily jump to the conclusion that we need to change the material of the container to one that is not affected by the acids or to one that is less inexpensive. When we do this, we are taking a lot for granted. In effect, we may be attacking the symptoms of the disease while ignoring the disease itself. A good inventor or problem solver will always try to understand what is causing the problem.

In its simplest form, cause-effect analysis is the identification of the object knobs (object parameters, properties or attributes) that control the independent variable that we are trying to improve. We can write these attributes as the independent variables in the function which gives us Y.

Y = f ( X1 X2 X3 X4 X5 . . . )

This equation can be read, Y is a function of, or is controlled by X1, X2 ….
We could state the acid corrosion problem in equation form.

Let’s assume, for the moment, that this function was created during a brainstorming session. When we stand back and look at what we have created, we may notice that the independent variables of the equation are not independent of each other. For instance, the cost of the container is related to the cost of the material. This relationship is not yet evident in the stated function.

We can write the function in a new form that takes into account the interdependencies. The act of doing this causes us to recognize new independent variables.

In effect, we have formed a cause-effect chain of dependencies which relate back to the original problem. A further refinement of our understanding comes when we include the knob settings for each of the variables.

A further refinement comes when we recognize that many of the knob settings change over time and are controlled by something . Any time a knob setting changes over time, a function is involved. If we include these functions, and apply other tools that allow us look for more knobs involved with these functions we gain a yet deeper understanding of what is causing our problem.

These concepts are the beginnings of what will be described in this chapter as a cause-effect chart which takes the form shown below.

Each box in the chart represents a knob and setting or a function which leads to the problem that we are trying to solve. The functions are connected to each other by object attributes.

While setting up a cause-effect diagram, we will ultimately come to knobs which are not caused by anything else, but are design parameters such as the length of something. Here we learn a valuable lesson, requirements are not causes. The reason that such knobs have the settings that they do is because if they do not, something else will get worse. In effect, a contradiction is formed. In addition, an alternate problem path is created. We can solve the original problem by solving the alternative problem. This alternative problem path is illustrated in the next drawing by the added boxes.

This line of reason is very useful when we later look for solutions. First, we have observed the problem from all sides and have forced ourselves to discover all of the interrelationships that cause the problem. Secondly, many contradictions are already evident. Resolving any of these contradictions will fix at least two problems. One of which was not as evident.

The more one knows about the problem, the more useful this technique becomes. This becomes more evident when working with legacy problems that have languished for years. Usually, there is someone around that is a subject matter expert. All of the pieces to the problem are individually floating in the brain of this expert. Organizing this cranial information is an important step to solving the problem. It is common that such subject matter experts are also incapable of solving the problem. They are well aware of the conflicts and feel helpless to resolve them. Later steps in the solution process help us across this hurdle

If the problem is not well understood, finding the cause and effect relationships can be very time consuming. In effect, when we first start, we are usually putting down our theories. A cause-effect diagram is an effective way to document our theories. It also serves as a good thought process map to help us focus our energies on the most important tests to run, etc. A cause-effect diagram can be especially useful when working with teams of people.

It is important to add graphics to the diagram so that others can participate and follow it easily. Without such graphics, these diagrams can become chloroform in print. The reader will usually fall asleep before you can finish the story. The author has found that people untrained in the use of these cause-effect diagrams can come up to speed very quickly and make important contributions.
A problem may be extremely vexing because it is hard to tell what is causing it. A special section is included on what to do if the cause is hard to detect. If you belong to a large organization with lots of resources, you should likely perform screening tests on prototypes in which only one variable is changed at a time. These tests will help you to understand the relative importance of each knob.

An additional benefit of this step is that sometimes we discover knobs that can be easily turned to solve the problem. Steps are given to find as many knobs as possible. These methods are referred to as “relative to” and the Table of Knobs which includes most of Altshullers “Standard Solutions”.

Some disciplines refer to this step as “Root Cause Analysis”. The name “Root Cause” implies that if we keeping asking why we will eventually come to the root cause. For those who are six-sigma minded, remember that there is a difference between problems which are special-cause and those with common-cause. Special cause implies that the output of a process is outside of the control limits and is therefore highly unlikely. For these problems, we can often find a single or a couple of root causes. However, for variation within the control limits there is a chain of causes. It is advisable to avoid the use of the term “Root Cause Analysis” when we are trying to understand a problem which is not special cause.

The output of this step is the knobs and settings and the key functions that cause the main problem. This output can be in the form of a cause-effect diagram.