Root Cause Analysis - Treat the problem, not the symptom! | Automation.com

Root Cause Analysis - Treat the problem, not the symptom!

April 102012
Root Cause Analysis - Treat the problem, not the symptom!
April 2012
 
By Bill Lydon
 
While working with an experienced engineer early in my career, I remember being frustrated when I thought I found the “cause” of a control system problem, but he just kept digging deeper, finding more issues and looking for the “root cause.” The root cause is the problem that ultimately created the undesired outcome, and if eliminated or modified, would have prevented the undesired outcome, thus fixing the problem. In a nutshell the fundamental principal of root cause analysis is to use symptoms as clues to find the source of a problem. This method requires analysis and/or testing to determine if something is a symptom or problem. Treating the symptoms can temporarily mask a problem or even make the problem worse. Broadly defined, Root Cause Analysis is any structured approach to identifying the factors of a harmful outcome (consequence) to identify what behaviors, actions, or conditions need to be changed to prevent recurrence of similar harmful outcomes and to identify the lessons to be learned to promote the achievement of better consequences.
 
Root cause analysis is used in a range of industries including aerospace, transportation, nuclear power, health care, chemical processing, pollution control, information technology and manufacturing. Root cause analysis is used in a number of improvement methods including quality, Kaizen, lean manufacturing, Six Sigma and Kepner-Tregoe.
 
5 Whys
 
The “5 Whys” technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. It is a critical component of problem-solving training, delivered as part of the induction into the Toyota Production System. The architect of the Toyota Production System, Taiichi Ohno, described the 5 Whys method as the basis of Toyota's scientific approach by repeating “Why” five times to understand the nature of the problem as well as its solution. The tool has seen widespread use beyond Toyota, and is now used within Kaizen, lean manufacturing, and Six Sigma.
 
By repeatedly asking the question “Why” you can peel away the layers of symptoms which can lead to the root cause of a problem. Very often the reason for a symptom will lead to another question. Although this technique is called “5 Whys,” less or more questions may be required to identify root cause. Here’s the methodology:
 
1.       Write down the specific problem including issues and describe everything completely. A clear and complete problem statement helps focus on the problem and if a team is involved, this gets everyone pointed in the right direction.
2.       Ask “Why” the problem happens and write the answer down below the problem.
3.       If the answer doesn’t identify the root cause of the problem, ask “Why?” again and write that answer down.
4.       Loop back to step 3 until there is agreement that the problem’s root cause is identified.
 
5 Whys Examples
 
Example 1: This is a simple example of using the 5 Whys to analyze the root cause of getting a speeding ticket while driving to work.
 
I was late for work, so I was driving fast. Why?
I got up too late. Why?
The alarm clock didn’t work. Why?
The batteries in the alarm clock were dead. Why?
I forgot to replace them. This is the root cause.
Solutions: Get an alarm clock that plugs into power outlet or add reminder in computer or mobile device to replace the batteries occasionally.
 
This is a simple example where the solution is quickly obvious. But when working with more complex problems, it is important to remember that there is a common tendency to stop at a symptom and treat it as the root cause problem rather than going on to determine if there are lower level root causes.
 
Data Collection
 
Data collection is important throughout the problem solving process and is done through observation and measurement of what is happening? Without complete information and an understanding of the problem, the causal factors and root causes associated with the problem cannot be identified. One engineer I worked with always carried around a pack of 3x5 inch index cards to note symptoms, data, and troubleshooting steps. While there are higher technology methods, I found this to be easy and effective. A mobile device with electronic notes would work well also.
 
Timeline
 
While dealing with more complex systems, it is valuable to create a chronological timelines of event, changes, alarms, and data related to a problem. Both PLC and DCS systems usually have alarm and data logs available that can be used for this information. Another tool is setting up trend logs and special alarms to help analyze what is occurring.
 
Ishikawa (Fishbone) Diagram
 
Another tool, created by Kaoru Ishikawa in 1968, for more complex problems are the Ishikawa diagrams (aka fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or Fishikawa) are causal diagrams that show the causes of a specific event. Each cause or reason for imperfection is a source of variation.  The “5 Whys” can be used individually or with the Ishikawa diagrams. This method helps you explore all potential or real causes that result in a single defect or failure. Once all inputs are established on the fishbone, you can use the “5 Whys” technique to drill down to the root causes. Causes are usually grouped into major categories to identify these sources of variation. The categories typically include:
 
  • People: Anyone involved with the process
  • Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws
  • Machines: Any equipment, computers, tools etc. required to accomplish the job
  • Automation & Control Systems: Any controllers, interfaces, sensors, etc.
  • Materials: Raw materials, parts, pens, paper, etc. used to produce the final product
  • Measurements: Data generated from the process that are used to evaluate its quality
  • Environment: The conditions, such as location, time, temperature, and culture in which the process operates
 
To construct a fishbone, start by stating the problem in the form of a question, such as “Why is process creating poor quality product?”  Framing it as a “why” question will help in brainstorming, as each root cause idea should answer the question. The team should agree on the statement of the problem and then place this question in a box at the “head” of the fishbone.
 
The rest of the fishbone then consists of one main line drawn horizontally across the page (creating the spine), attached to the problem statement, and several lines or “bones” coming out vertically from the main line. These bones represent categories of any factors contributing to the problem. For example, “Machines” could be one category (bone) with possible factors being speed and blade wear.
 
Problem Solving
 
The time to identify and solve problems can be lowered using better analysis and methods.
Did you Enjoy this Article?

Check out our free e-newsletters
to read more great articles.

Subscribe Now

MORE ARTICLES

VIEW ALL

RELATED