Tag: Root Cause Analysis

Desk Jockey “Leaders”

English: A desk in an office.
English: A desk in an office. (Photo credit: Wikipedia)

Behind The Desk

For some people, being bound to a desk is an inherent and perhaps unfortunate part of the work they do. But, the last place I would expect to find a lean leader is sitting behind their desk.

I recognize the need for an office and understand that managing a business does require some desk time. However, it’s amazing how some “leaders” think that that’s what it takes to run a business. If you started and run your own business, you know otherwise.

To be in touch with your business is to spend time on the front lines, with your customers,  walking the floor, and simply being with your team – not just when you think they need you. Personally, I like to see and understand what is happening directly at the source. This is not to suggest that we interfere with the normal flow of operations or bypass the hierarchy of people who are running the operation. Rather, it is an opportunity to learn what is going on first hand so we can have a meaningful discussion to make improvements or to resolve any concerns as they arise.

The Desk Jockey

Desk Jockeys, on the other hand, rely on the steady stream of paper flowing through their office, looking for discrepancies or anomalies that don’t align with their expectations. Upon discovery, desk jockeys call the responsible person or persons to their office and proceed to explain the problem and offer solutions to them without really knowing what happened.

Desk Setup June 2009
Desk Setup June 2009 (Photo credit: Trevor Manternach)

If there isn’t enough paper already, desk jockey leaders have a niche for creating more. Attempts to justify their reasons for doing so further exposes their lack of knowledge on what it means to really manage and lead their teams.

We can’t assume the system is working simply because the paperwork is correctly completed. If the system is working, does that mean the physical process is working correctly too? Furthermore, could it be that the system itself is fundamentally flawed to begin with?

No Accident

Of course, desk jockey “leaders” didn’t get their titles by accident. They have a wealth of experience – at least that’s what they tell me – that brought them to their current level of success. It’s interesting to note that I hear this more from “first time” leaders who, sooner or later, learn why it may also be their “last time” leading.

A desk Jockey may also be a “know it all” or “know about”, leaving their teams to suffer and sweat through the issues so they can fend and “learn for themselves”. Almost as though rising to the challenge will make them stronger in the long run. I can picture the analogy well – the baby chick breaking out of its shell to discover the world because to help the chick is to make it weaker than those that did it for themselves.

It’s Just NOT Lean

Desk jockey “leaders” are not fully engaged with the reality that exists within their business. If you’re wondering why morale is low and your team is not engaged, it’s very likely that you’re not engaged with them. Strangely, desk jockeys share the same frustrations as their teams. They just don’t know it.

If you’re an expert, share your knowledge and skills. If you’re not, then you have all the more reason to get out from behind the desk and learn. Having the right answers isn’t going to solve all of your problems but asking the right questions will certainly help to bring you closer.

If our mission is “To deliver the highest quality product or service at the lowest possible cost in the shortest amount of time”, then writing reports for quality deficiencies, cost overruns, or missed deliveries is a strong indication that a problem exists – not behind the desk, but in the operation itself. Meetings and reports are best replaced by real hands on root cause analysis and problem solving that is only effective at the source.

Cell phones, tablets, laptops and other technologies make it possible to conduct business from wherever you are. Run your business from the place that matters most, not your desk. As for me, if I spend 10% of my time in the office, I’ve been there far too long.

Your feedback matters

If you have any questions, comments, or topics you would like us to address, please feel free to contact us by using the comment space below or email us at LeanExecution@Gmail.com. We look forward to hearing from you.

Until Next Time – STAY lean

[twitter-follow screen_name=’Versalytics’ show_count=’yes’]

Vergence Analytics

Foundations of Failure

The problem with many of the problems we find ourselves having to contend with at any given time is that we learn of their existence after the fact (when the damage is done) or after discovering that the results we were looking for simply didn’t materialize.  As we learned from Michael A. Roberto’s book, “Know What You Don’t Know“, there are a number of reasons why problems don’t surface until after the fact.  I highly recommend reading “Know What You Don’t Know” as well Steven J. Spear’s “Chasing the Rabbit” as both books present numerous examples and extensive research that span across a wide variety manufacturing and service industries.

In many cases, the pathology of a given problem reveals that much of the information surrounding a given failure, or series of failures, is “common” knowledge.  In isolation, many of the contributing factors appear to be insignificant or irrelevant.  However, when we review all of the “insignificant” bits and pieces of evidence as part of the whole, we discover that it is these “pieces” that make the puzzle complete.  This was certainly the case with 9-11, Three Mile Island, The Challenger, and perhaps even the most recent economic collapse.

The expression, “If it ain’t broke, don’t fix it”, comes to mind as I think of problem solving in the general sense.  Even today, we find this philosophy is embedded deep within the culture of many corporations.  In some cases, the designs are so fragile, that any deviation from normal or intended use may result in failure.  Broken plates and glasses remind us that they are not intended to be dropped – either intentionally or by accident.  We are also painfully aware that the absence of past failures does not automatically exclude or make the process or product immune from future failure.  There are too many examples of failure where past successes are suddenly shattered by a catastrophic failure.

Of course, many products are subject to numerous hours of testing in varying degrees of severity and exposure limits.  Yet somehow, these tests still do not capture all of the possible failure modes that are observed in practice.  Too many product recalls are evidence of our inability to anticipate the vast array of problems that continue to haunt manufacturer’s around the globe.  Just maybe the the “If it ain’t broke” expression needs a little rework itself.  If it ain’t broke please break it – or at least try!  Computer hackers around the world having been giving Microsoft and other major corporations their fair share of problems as they continually find and develop “new” ways to break into very sophisticated and high tech systems.

Our Foundations of Failure model is based on the premise that every failure has a known and identifiable root cause.  The challenge for today’s companies is to learn how to identify problems before the product makes it to market or the process is released to manufacturing for production.  The objective is to instill an innate ability to constructively critique your concepts and designs to identify and anticipate the “What if …” scenarios that your product or service may be subject to.

Perhaps an even greater skill to be learned is to identify and anticipate how the product or process may be used or abused – with or without intent or malice.  From this perspective, lean manufacturing principles and standardized work can certainly help us to map our road to success.  Technically, if the ideal process and it’s inherent steps are performed as specified, then any deviations from the prescribed process or design are subject to a system breakdown or product failure.  As discussed in “Chasing the Rabbit“, this was (and is) certainly the case for the US Nuclear Submarines.

Are your system, process, and product specifications documented to the extent that deviations from their intended purpose or function can be, or are, readily identified?  Is it even possible to forecast or anticipate every possible failure mode?  Is it fair to suggest that prescribing a solution to a problem suggests that the original scope of the problem was or is fully understood?

As we have learned from the numerous failures in our financial markets and the collapse of many high profile businesses and companies around the globe, common symptoms and effects of failure may be the result of radically different root causes:  ignorance, negligence, willful misconduct, and even fraud.  We need to implement systems and processes that are robust and assure our future successes are built on solid fundamental business practices.  When the foundation is faulty, the entire business enterprise is at risk.

In summary, the first step is the most critical step.  The first few steps of any new initiative, process, product, or service, form the foundation of all decisions that follow.  Just as a building requires a solid foundation, so do our future successes.  I recall a little sign that was posted in a retail store that read as follows:

Lovely to look at,
Lovely to Hold,
But if you drop it …
Consider it Sold!

Until Next Time – STAY lean!

Using TRIZ for Problem Solving – Resources

In our first post on this topic, “Using Triz for Problem Solving – Introduction“, we provided a very basic introduction to TRIZ.  In the spirit of TRIZ, it is not our intent to rewrite or redefine the TRIZ process when excellent information is already available.  Our intent is to identify the few of the many excellent and exceptional resources that we have found.

What is TRIZ?

To learn more about TRIZ and it’s applications we suggest visiting the following web sites that present a tremendous amount of information on the development and application of TRIZ.

TRIZ Principles

40 Inventive Principles with Examples:

Examples for each of the 40 Inventive Principles can be found at the following link:  http://www.triz-journal.com/archives/1997/07/b/index.html

TRIZ Resources

The Contradiction matrix:

As you will have learned from reading the “What is TRIZ?” page from the link above, one of the tools of TRIZ is the Contradiction Matrix that consists of 40 elements.  The TRIZ Contradiction Matrix is available as an Excel Spreadsheet through the following link:

http://www.triz-journal.com/archives/1997/07/matrix.xls

The TRIZ Journal ARTICLES:

The Triz Journal presents many informative articles.  One very intriguing article, “TRIZ / Systematic Innovation Enhances Hoshin Kanri“, by Darrell Mann and Ellen Domb, demonstrates the principles of TRIZ in a unique application.

An excellent article, “Create a High Performance Culture with Hoshin Kanri”, by Frank Deno can be found at the following link http://www.realinnovation.com/content/c080623a.asp

WEB Sites:

TRIZ Books:

A number of books are available on the topic of TRIZ.  Click here to preview the selections currently available.

TRIZ Challenges:

TRIZ is not without its challenges.  Although TRIZ has evolved over many years, it still remains relatively unknown and few companies seem to be ready to adopt this problem solving method.

An excellent article, “Enhancing TRIZ with Dr. Deming’s Philosophy“, by Ellen Domb and Bill Bellows, presents some interesting insights to this challenge.

We typically tend to avoid “labels” for the method we are using to solve a specific problem.  Unlike a surgeon “requesting specific tools (scalpel)” while performing an operation, our strategy tends to be a blended “hybrid” approach to problem solving; TRIZ happens to be one of the more effective methods that we have learned to use over the past few years.

The acceptance of TRIZ may be attributed to the current struggles many companies experience simply attempting to complete an 8D or 5-Why.  Of course, that would only be true of companies who are void of the Lean principles and methods – right?  TRIZ also has a perceived complexity that does not lend itself to ready adaptation as a company-wide problem solving tool.

We would recommend reviewing the many available books on the topic of TRIZ.  Integrating a tool such as TRIZ will require someone to become the leading expert.  Click here to see the various book selections that are available.

Unfortunately, for many companies, the discipline or the structure is simply not there to support effective problem solving efforts.  Perhaps if more time was spent solving the real problems, they would have more time to solve problems not yet realized.

Remember to get your TRIZ – Click Here!

Until Next Time – STAY Lean!

Using TRIZ for Problem Solving – Introduction

Using TRIZ for Problem Solving – Introduction

A famous quote from Albert Einstein, “The problems that exist in the world today cannot be solved by the level of thinking that created them.“, applies to the discussion of problem solving and more so to the topic of TRIZ, The Theory of Inventive Problem Solving, developed by Genrich S. Altshuller.

TRIZ – Theory of Inventive Problem Solving

Genrich S. Altshuller developed TRIZ based on his search for a standard method to solve problems.  At the very basic level, once a problem is identified the objective is to determine whether a similar problem has already existed elsewhere.  If so, study the solution and determine whether it can be incorporated into the current solution being sought.  Taken one step further, consider the possibility that a different perspective of the problem may also present a unique inventive solution.

It does not seem too far fetched that the problem to be solved has occurred elsewhere in a completely different context.  The solution that is found may also be out of the context but the concept may lead to an innovative solution for the current problem at hand where one never before existed.

The application of TRIZ requires an open mind.  We often bring our “tool box” of experience to the table and draw on those tools and our wealth of knowledge to create a solution.  TRIZ is a tool that can be used to create completely new and unique solutions to a given problem.  This doesn’t mean that we need to abandon our current technology and know-how; it simply means that there may be other options where the current know-how and / or technology may not apply or it may be applied in a manner that is quite different than it is today.

Identify the Real Problem to be Solved

Any problem solving method can only be successful if the true root cause is identified.  Once found, a clear and concise problem statement must be formulated to assure that the solution developed and implemented indeed addresses the true root cause.

Searching for Solutions:

Once a problem has been identified, the next question is, “How do we solve it?”  There are a number of techniques that can be used such as brain storming and idea mapping, however, one seldomly used technique is TRIZ:  Theory of Inventive Problem Solving.

Every day we are challenged with a diverse range of problems from machine malfunctions to defective parts.  The very nature of any company’s operations requires an immediate fix to restore operations to “normal”.  Recognizing that a problem exists is not the same as understanding what the problem is and effectively solving the problem requires that we have identified the true root cause and not just the symptoms.

Many tools are readily available to even help us address these concerns or identify where opportunities exist to make improvements.  Unfortunately, these tools seldom provide the solution to the problem.  Too often we are trapped inside the box of current thinking, technologies, standards, methodologies, present knowledge, and even company policy.  Our own levels of thinking and plausible solutions are influenced and limited by our current understanding and knowledge of the problem as well as our own experiences.

The Basis for Using TRIZ to Solve Problems:

Technology

In some cases, product or part designs themselves may be constrained as engineers and designers work to generate a design tailored to a specific, known, technology.  Quality Function Deployment is one strategy that provides a platform to explore alternative design and process approaches before committing to a specific technology or process.

It is worth noting that, although product design is critical, processes and technologies used to manufacture the product itself are often overlooked and seldom are the process constraints and their affects ever considered.  There are many examples where numerous hours are wasted attempting to develop tools using traditional technologies to produce parts that conform to the wishes of engineers and designers.

How do we actually go about solving problems where the technology or the design present constraints that prevent success?  This is the basis for TRIZ:  We have clearly identified the problem to be solved, now we need a solution to resolve it.

Problem Classifications

Although problems may have varying degrees of difficulty, the solutions for them can only fall into one of two overly simplified categories:  Known or Unknown.  While this classification may appear simple on the surface, consider the unknown solution.  Is it truly unknown or is it only unknown to you.
  1. Known:  Surrogate process already proven and only requires adaptation for the current situtation.  The “problem solver” has an awareness or experience related to the solution.
  2. Unknown:  Typically, solutions are often limited by the scope of experience of the person or person(s) attempting to solve the problem.
    1. The problem solver is not aware of the solution’s existence (Personal)
    2. The solution is outside the problem solver’s scope of experience, training, or field of expertise, but may exist within the company (Company)
    3. The solution is not known within the company but is known within the industry (Industry)
    4. A solution can be realized although it does not presently exist (Outside Industry).
    5. Requires an inventive solution that goes beyond improving the existing condition and is not known to exist anywhere.
  3. Although a solution may be found or developed internally, it may not necessarily be ideal.  We recommend continual review of trade journals, going to trade shows, and networking not only with industry peers but outside your areas of expertise as well.

We will pursue the TRIZ methodology as both a learning and problem solving method.  Often times the solution to a problem requires a different perspective to achieve an effective resolution.

Applying TRIZ in the real world:

TRIZ can be used to develop solutions in a wide range of applications.  As Contingency Plans are developed, you may determine that a solution is required to address a problem or crisis that company has not yet experienced.  As we have discussed, the information or solution to the pending “crisis” may already exist elsewhere.  Similarly, improvements to Overall Equipment Efficiency may require solutions to be developed to address problems or opportunities that are inhibiting continued improvement. 

We will continue to pursue the application of TRIZ in the real world and present a more detailed case study.  

Note:  We would also recommend and encourage you to visit http://www.mazur.net/triz/ for an indepth presentation and detailed discussion of TRIZ.  This site provides greater detail and background that is presently beyond the application or scope of this series.

Until Next Time – STAY Lean!

 

 

How to Solve Problems with Idea Maps

FreeMind 0.9.0 RC4 - Mind Map with User Icons
Image via Wikipedia

Problem solving is a problem in itself for many companies and at times can be one of the most daunting tasks to undertake during the course of an otherwise regular work day.

For some, problems seldom occur while for others this may, unfortunately, be a daily activity.  Since problem solving is not usually part of the typical daily agenda of “routine” activities, our ability to find the time and solve them efficiently and effectively is compromised.

For many, just finding time seems to be one of the greatest challenges and perhaps a problem to be solved in itself.  Sweeping problems under the rug may be efficient but it is certainly not effective.  (So … broom is not the solution we’re proposing).

Using IDEA Mapping Techniques can help you solve problems effectively and efficiently.  IDEA Maps, Process Maps, and Mind Maps are variations on a theme.  We may use the terms interchangeably in the discussion that follows.

Background:

While there are several different approaches and “forms” that can be used to manage the overall problem solving process, the two most critical steps that will determine the effectiveness of the solution are:

  1. Define a Clear and Concise Problem Description / Statement
  2. Determine the Root Cause(s) of the problem defined by the Problem Statement.

While the first step seems relatively simple, the second step requires a little more effort.  There are at least two (2) root causes for most problems that stem from two simple questions:

  • Why Made?
  • Why Shipped?

These questions imply that defective product was made for a reason (process) and it was shipped to the customer undetected (system).  In other words, the customer is not protected from receipt of defective product.

The root cause analysis process forms the basis for all subsequent problem solving activities, including verification, interim and long term corrective actions.  A lot of time can be wasted simply because the real root causes were never identified.

Problem Solving Tools for Root Cause Analysis:

Many different tools can be deployed during the Root Cause Analysis process including Ishikawa Diagrams (Fishbone Diagrams), 5 Why (discussed in a previous post), Fault Tree Analysis, Q&A (Question Board), and Brain Storming to name just a few.

Mind Mapping or Process Mapping is a technique that provides an unconstrained approach to the thinking process for multiple input and contribution streams.  Maps can also be used to identify interactions or relationships to other elements.

Mind Mapping (Process Mapping)

The center of the map contains the problem statement.  We then surround the problem statement with potential inputs or contributors to the problem.  These statements in turn become the “center” of additional levels of inputs and contributors.  In some respects, the process map can be very similar to a Bloom Diagram and certainly supports the logic found with fishbone diagrams.

The   The draw back to “Mapping” is that most are usually developed on Whiteboards and not easily or readily translated into a software solution.

Software Solutions and Templates

While there are many spreadsheet based solutions, few provide an effective interface to support the use of mapping techniques.  Even most fishbone diagrams developed in Excel are quirky and awkward at best.

While we typically do not endorse specific software solutions, however, FREEMIND is one software that we consider to be among the best of available solutions and can be downloaded free of charge.  The download and installation process only requires a few minutes.

The developers of FREEMIND provide a clean, intuitive solution for creating and maintaining process or mind maps.  While other commercial packages are available, FreeMind is more than capable of handling most problem solving challenges and quite simply is time and money well saved.

The FreeMind homepage provides a better description of the software and it’s capabilities than we could provide here.  Our goal was to introduce “Mapping” as an effective and efficient tool that can be used in the problem solving process.

After spending some time with the software, you will quickly discover that there are many other opportunities where this software can serve you.  We have a mind map that we use to manage weekly and daily reports, another for key metrics, and yet another for our business structure.  The ability to use hyperlinks makes it an easy process to access external reports and resources .

The FreeMind main page provides an excellent overview and provides examples of their software in action.  This is definitely worth looking into and may just save some time for real problem solving.

We are presently using FreeMind version 0.9.0 RC 6.

Home: http://freemind.sourceforge.net/

Copyright 2000-2009 Joerg Mueller, Daniel Polansky, Christian Foltin, Dimitry Polivaev, and others.

Click here to see a sample process map to achieve delivery of 100% on time – in full:  Mapping with FreeMind.  We have also uploaded two documents (one of the original map and a word document showing a pictorial of the mind maps we created) into our Free Downloads box.  See the ORANGE box on the sidebar to get your copy.

If you have a copy of FreeMind, simply change the extension on our Delivery file from “.txt” to “.mm”  Of course, don’t type the quotes.  This is just a sample for example purposes only.  Feel free to edit or modify these files  in any manner you choose.

If you would like to learn more about IDEA Mapping we would encourage you to also read Idea Mapping – How to Access Your Hidden Brain Power, Learn Faster, Remember More, and Achieve Success in Business by author Jamie Nast (twitter:  @JamieNast) or you can visit the website at:  http://www.ideamappingsuccess.com/.

Click here to review or purchase your copy of Idea Mapping: How to Access Your Hidden Brain Power, Learn Faster, Remember More, and Achieve Success in Business

Until Next Time – STAY lean!

IDEA Mapping, Published by John Wiley & Sons, Inc, Hoboken, New Jersey, Published simultaneously in Canada (ISBN-13:  978-0-471-78862-1, ISBN-10:  0-471-78862-7), 268 pages.  The book includes a companion CD-ROM featuring a 21 day trial for Mindjet MindManager 6.

How to use the 5 WHY approach

Schema of the Process of problem solving. Base...
Image via Wikipedia

The 5 WHY technique, developed by Sakichi Toyoda, is one of the core problem solving tools used by Toyota Motor Corporation and has been adopted and embraced by numerous companies all over the globe.  This technique is unconstrained, providing the team with a high degree of freedom in their thinking process.

As we suggested in our “How to Improve OEE” post, the 5 WHY system is simple in principle.  This simplicity may also be the downfall of this technique unless you take the time to understand and apply the process correctly.  Other problem solving tools, such as Cause and Effect diagrams, allow for the development of multiple solution threads, in turn creating the potential for multiple solutions.

Some root-cause analysis experts have correctly identified some of the short comings presented by the 5-WHY technique including:

  1. The approach is not repeatable – One problem, different teams, different solutions.
  2. The scope of the investigation is constrained by the experience of the team.
  3. The process is self directing based on the evolution of the “WHY + Answer” series.
  4. The TRUE Root Cause may never be identified – Symptoms may be confused for Root Causes.
  5. The inference that a root cause can be determined by a 5 tier “Why + Answer” series.
  6. The Problem Statement defines the Point of Entry. It is imperative to define where the real problem begins.

We would argue that any problem solving or root-cause analysis tool is subject to some short falls in one form or another.  Perhaps even in problem solving there is no definitive solution.  Different problems require different tools and perhaps even different approaches.  In the automotive industry, each customer has a different variation on the problem solving approach to be used and prescribe various tools to be used in the problem solving process.

For this reason, most companies do not rely on one single technique to approach their problem solving challenges.  We would also argue that most companies are typically well versed in their processes (equipment and machines), products, and applications.  As a result, having the right people on the team will minimize the experience concerns.  There is no reason not to include outside expertise in or outside of your current industry.

One concern that can be dismissed from the above list of short comings is the inference that the solution can be found by a 5 tier “Why + Answer” series.  There is no rule as to how many times the “Why + Answer” series should be executed.  Although five times is typical and recommended, some problems may require even deeper levels.  We recommend that you keep going until you have identified a root cause for the problem that when acted upon will prevent its recurrence.

The TRICK:

The technique that we propose in this post will at least provide a method to validate the logic used to arrive at the root cause.  Most 5-WHY posts, web sites, articles, or extracts on the topic seem to focus on a top-down or deductive “Why + Answer” logic sequence.  The challenge then is to have some way to check the “answer” to see if it actually fits.

A simple way to validate the top down logic is to read the analysis in reverse order, from the bottom up, substituting the question WHY with the words “Because” or “Therefore.”  To demonstrate the technique we’ll use an example based on a problem sequence presented in Wikipedia:

I am late for work (the problem):

  1. Why? – My car will not start. (The Real Problem)
  2. Why? – The battery is dead.
  3. Why? – The alternator is not working.
  4. Why? – The alternator belt is broken.
  5. Why? – The alternator belt was well beyond its useful service life and was never replaced.
  6. Why? – The car was not maintained according to the recommended service schedule. (Root Cause)

You probably noticed that we used a 6 “Why + Answer” series instead of 5.  We did this deliberately to demonstrate that 5 WHY is a guideline and not a rule.  Keep asking WHY until you find a definitive root cause to the problem.  We could keep going to determine why the car was not maintained and so on to eventually uncover some childhood fear of commitment but that is beyond the scope of our example.

The CROSS CHECK – Root Cause Analysis Validation

Root Cause: The car was not maintained according to the recommended service schedule.

  1. Therefore, the alternator belt was well beyond its useful service life and was never replaced.
  2. Therefore, the alternator belt is broken.
  3. Therefore, the alternator is not working.
  4. Therefore, the battery is dead.
  5. Therefore, the car will not start. (The Real Problem)
  6. Therefore, I will be late for work.

Does the reverse logic make sense to you?  It seems to fit.  Does it sound like the owner of the car needed to be a mechanic or at least know one?  When it comes to car trouble, we don’t seem too concerned about going to the outside experts (the mechanic) to get it fixed.  Why do some companies fail to recognize that experts also exist outside of their business as well?  In some cases, proprietary or intellectual knowledge would preclude calling in outside resources.  Barring that, some outside expertise can certainly bring a different perspective to the problem at hand.

Caution!  Stick to the Problem – Don’t Assign Blame

The original Wikipedia example identified the root cause as, “I have not been maintaining my car according to the recommended service schedule.”  It would be too easy for someone to say, “Aha, it’s entirely your fault.  If you only took better care of your things you wouldn’t have been in this predicament.”  For this reason, we presented the case based on the facts.  It’s not WHO it’s WHAT.  This approach also tempers emotions and keeps the team focused on the problem and the solution.

Where do we start? Problem Entry Points

You have likely noted that the problem statement is the key to establishing a starting point for the 5 WHY process.  A problem may have different entry points depending on what stage you become involved:

Entry Point Problem Statement
You Late For Work
Service Manager The car will not start
Mechanic The battery is dead
Belt Supplier The alternator belt is broken

Product Recalls and Warranty Returns are typical examples of where you may find multi-level 5 WHYs.  Ultimately the suppliers of most products, like the Belt Supplier in our example, will also complete a 5 WHY.  This is typically the case for most Tier I automotive suppliers.

WHY MAPS / TREES.

The one drawback or downfall of the 5 Why process as presented above and also used by most companies is the suggestion that a single “WHY + Answer” series will evolve into a neat single root cause.  Our experience suggests that this is far from reality.  We typically present the single series as part of the final solution, however, we can assure you that multiple root cause / solution threads were developed before arriving at the final result.

We use the WHY MAP (WHY TREE) as a tool that allows us to pursue multiple thought threads simultaneously.  Pursuing multiple threads also stimulates new ideas and potential causes.  In some cases the root cause analysis threads lead to the same or common root cause.  Then it is a matter of selecting the most likely root cause.

Tip:

Problem solving TREES come under many different names including Why-Tree, Cause Tree, Root Cause Tree, Causal Factor Tree, Why Staircase Tree, and Cause Map to name a few of them.  As you can see from the names, they all serve to create, stimulate, and propagate ideas.

Regardless of the tool you use, finding the true root cause and ultimately the solution to resolve it is the key to your problem solving success.

We trust this post will provide you with some insight to using the 5-WHY approach for problem solving and will serve as a useful tool to improve your OEE.

More on this series to follow in our next post.

Until Next Time – STAY lean!


How to Improve OEE – Any Questions?

Ask any Quality or Engineering manager and they will tell you that measurement systems are valuable tools to identify problems and opportunities.  The measurement system itself is not the answer – it is the data source, the EVIDENCE that drives the questions.  It is a part of the discovery and validation process to confirm the opportunity or problem and the effectiveness of the solutions to resolve it.

A well integrated OEE system should provide the data to answer the questions on everyone’s mind, “What do we need to do to improve?” or “Why aren’t we improving?”  The simple answer is, “We need to fix it.”  Of course the real question may not be, “What do we need to fix?” but, “Why did it break?”

Yes, we will likely have to replace the part(s) that failed to get the line back up and running, but what really caused the failure to occur?  What was the real root cause?  This introductory post to problem solving and root cause analysis will kick start some of the techniques used to solve problems effectively.

The Problem Statement:

The key to effective problem solving starts with identifying the problem to be solved.  This is typically a brief statement describing the problem.  For external concerns, the problem is usually stated in customer terms.

This post presents some simple examples of problems to be solved.  You will quickly discover that defining the problem may not be as simple as it looks.  We will discuss this in more depth in our future posts.

Root Cause Analysis

Identifying the real root cause(s) for the failure is the secret to successful problem solving.  The method you use to arrive at the root cause should allow you to confirm and validate your solution before taking action.  Here is an important point to remember:

Do not confuse symptoms with root causes.  

For example, you are driving down the road and suddenly find yourself struggling to maintain control of your vehicle.  Your expert driving skills allow you to pull over and stop on the side of the road.  You get out of the car and walk around to discover that you have a flat tire.  The flat tire is a symptom – not the root cause.

As luck would have it, a police officer who just happened to be following you in an unmarked car, notices your sudden erratic driving behavior and charges you with recklessness and careless driving.  Since none of the tires on the police car are flat, the officer presumes the condition of your vehicle is the direct result of your poor driving skills and bad habits after many years on the road.  Another point to remember:

Do not jump to conclusions

You, like many people, would argue that your many years of driving provided you with the experience necessary to avert danger.  The officer quickly recognizes that your many years of experience have caused you to lose perspective of the potential hazards of driving.  The officer advises that your driving record shows no record of any tickets or accidents and clearly suggests that you have had very few “experiences” with the law and minimal exposure to poor road conditions.

The officer proceeds to charge you, the operator, because you simply weren’t paying attention to the conditions and potential hazards of the road.  You are given a ticket to serve as a reminder to pay more attention to the road and to be mindful of your driving habits in the future.  Then to add insult to injury, the officer advises you to fix your tire and drive carefully. 

Unforgiving of the circumstances and since quota’s have to be met, the charges stand and you find yourself on your way to court.  As you sit in your vehicle, stunned that you just got a ticket for getting a flat tire, you are conflicted and fuming because the officer blamed you, your poor driving skills, and your bad habits for driving recklessly down the road!  The following tip will help you remember:

Operator Error is not a Root Cause

Many times, management is too quick to attribute the root cause to operator error.

5 WHY Analysis

One of the best methods for identifying the real root cause is the 5-Why approach.  The concept of asking the question “WHY?” five times is quite simple.  In practice though, you will find it may not be that easy.  Why?  Because the wrong answer will lead you through a continuing series of wrong answers that ultimately lead to the wrong conclusion.

There is always more than one answer – Which one is correct?

Referring back to our example of the flat tire, you now need an argument to absolve yourself of any blame for the incident on the highway.  In court, the judge asks, “How you plead to the charges before you?”  You answer, “Not Guilty your honor.”

  1. Why?  While I was driving down the road, I got a flat tire.
  2. Why?  Because all the air ran out of my tire.
  3. Why?  Because there was a hole in it.
  4. Why?  Because the tire didn’t have anti-puncture technology.
  5. Why?  Because the manufacturer didn’t design it properly.

Were it not for my expert driving skills, this situation could have been much worse.  As it was, using my superior driving skills, I successfully managed to maneuver my vehicle, without incident, to the side of the road, averting what could have been a disastrous crash.  Therefore, I request to be completely absolved of any and all wrongful doing and I am filing a class action suit against the tire manufacturer to cover court costs, lost wages, and damages as well as my emotional stress.

Clearly not satisfied, the judge requests you to take a 10 minute break to rethink your case.  On your return to the courtroom, you are prepared to present the following argument:

  1. Why?  While I was driving down the road, I got a flat tire.
  2. Why?  Because all the air ran out of my tire.
  3. Why?  Because there was a hole in it.
  4. Why?  Because there was a nail on the road.
  5. Why?  Because the government refuses to keep the highways clean.

Were it not for my expert driving skills, this situation could have been much worse.  As it was, using my superior driving skills, I successfully managed to maneuver my vehicle, without incident, to the side of the road, averting what could have been a disastrous crash.  Therefore, I am filing a class action suit against the government to cover for court costs, lost wages, and damages as well as my emotional stress.  To resolve this matter quickly, I request that all charges be dropped and I in turn will drop my counter-claim.

The purpose of the above example was to demonstrate how the answer to the question – WHY? – can lead to completely different conclusions.  On one hand we’re ready to sue the tire manufacturer and on the other, we’re ready to take on the government.  If there was indeed a nail on the road, how did it get there?

Don’t Assign Blame

Solving problems and getting to the root cause is not about assigning blame to someone or something.  You can’t blame the government or the tire company for the fact that there was a nail on the road.  It is to easy to assign blame and it happens everywhere, everyday.  Perhaps the nail manufacturer should be sued as well for failing to provide adequate protections should the nail become lost or misplaced.

The question that wasn’t asked is, “Why was the nail on the road?”  The answer may be that it likely fell out of a board or from a truck or trailer that may have been carrying construction materials.  Again, being careful with the answer, we don’t want to come to the conclusion that nails should be banned completely.

On the other hand, it may be worthwhile to advise that all companies and contractors must make a reasonable effort and take appropriate precautions and measures to ensure that all loads are secure and free from loose raw materials.  Any nails must be placed in a sealed container and secured to the vehicle for the purpose of transport.  A maximum fine of $2,000.00 may be imposed and made payable to the “Operator Error Trust Fund.”

Leading the Witness:  The solution BIAS

STOP! – if you think you already know the answer – Stop!  We know that the right question doesn’t always lead to the right answer as we attempted to show in our example.  Another major pitfall is thinking we already have the answer and we just need to frame the questions and answers to support that conclusion.  This isn’t problem solving, this is creative story telling.  Don’t lead your team into following what “appears” to be a logical conclusion – be prepared to prove it.

Don’t Assume Anything – Follow the EVIDENCE

At a minimum, follow the evidence.  What is the data telling you?  It’s time to start thinking like a crime scene investigator (CSI) or good lawyer.  Asking questions and continuing to probe for answers is the secret to uncovering the less obvious and, more than likely, real solution.

Many OEE equipment / software integrators provide the ability to record and track downtime events in real time.  This data is extremely valuable for trouble shooting and problem solving; however, they are not necessarily root causes.  The integrators provide the capability to readily identify what part of the process failed or what is broken.  While this may be the cause of the line down condition, it is not the root cause of the problem.

Do not confuse the Point of Failure (Source) with the Root Cause

Don’t fall into this trap:

  • Supervisor:  “The OEE system report showed that we lost two hours on the paint line last night.”
  • Maintenance:  “Yeah, I saw the report too.  This OEE system tracks everything!”
  • Supervisor:  “Why did the line go down?”
  • Maintenance:  “The A-Tank feed pump overheated.  The OEE system told us exactly which pump failed.  It saved us a ton of time.”
  • Supervisor:  “What did you do?”
  • Maintenance:  “Oh, we replaced it.  The line is running fine now.”
  • Supervisor:  “OK, that’s good.  Thanks.”

End of conversation.

So, WHY did the pump overheat?  Some questions just never get asked, but I’m sure the OEE will be just fine on the next shift.  We recognize that most effective TPM managers are sharper than this.  Our point is that not everyone is looking at the data from the same perspective.

We’ll discuss “How to Improve OEE” in more detail in our next post:  “How to use the 5 Why Approach.”

Until Next Time – STAY lean!