Root Cause Analysis Superfactory Excellence Program™ www. superfactory Root Cause Analysis Superfactory Excellence Program™ www.superfactory.com © 2004 Superfactory™. All Rights Reserved.

Disclaimer and Approved use The files in the Superfactory Excellence Program by Superfactory Ventures LLC (“Superfactory”) are intended for use in training individuals within an organization. The handouts, tools, and presentations may be customized for each application. THE FILES AND PRESENTATIONS ARE DISTRIBUTED ON AN "AS IS" BASIS WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED. Copyright All files in the Superfactory Excellence Program have been created by Superfactory and there are no known copyright issues. Please contact Superfactory immediately if copyright issues become apparent. Approved Use Each copy of the Superfactory Excellence Program can be used throughout a single Customer location, such as a manufacturing plant. Multiple copies may reside on computers within that location, or on the intranet for that location. Contact Superfactory for authorization to use the Superfactory Excellence Program at multiple locations. The presentations and files may be customized to satisfy the customer’s application. The presentations and files, or portions or modifications thereof, may not be re-sold or re-distributed without express written permission from Superfactory. Current contact information can be found at: www.superfactory.com © 2004 Superfactory™. All Rights Reserved.

Course Content Course Objectives What is Root Cause? Benefits The Problem Solving Process Examples and Exercises Here is an overview of the course content. We will review the definition of root cause, the benefits of performing root cause analysis, review a recommended problem solving process that contains the root cause analysis step, provide examples of problems addressed to root cause, things to keep in mind when performing this analysis, And finally a summary review of the course © 2004 Superfactory™. All Rights Reserved.

Course Objectives Upon completion of this course, participants should be able to: Understand the importance of performing root cause analysis Identify the root cause of a problem using the problem solving process Understand the application of basic quality tools in the problem solving process Upon completion of this course, participants will be able to: Understand the importance of performing root cause analysis Identify the root cause of a problem using the problem solving process Understand the application of basic quality tools in the problem solving process © 2004 Superfactory™. All Rights Reserved.

What is a root cause? ROOT CAUSE = The causal or contributing factors that, if corrected, would prevent recurrence of the identified problem The “factor” that caused a a problem or defect and should be permanently eliminated through process improvement The factor that sets in motion the cause and effect chain that creates a problem The “true” reason that contributed to the creation of a problem, defect or nonconformance Root cause definitions. Feel free to add your own © 2004 Superfactory™. All Rights Reserved.

What is root cause analysis? A standard process of: identifying a problem containing and analyzing the problem defining the root cause defining and implementing the actions required to eliminate the root cause validating that the corrective action prevented recurrence of problem Root cause analysis is part of a complete corrective action process. Getting to root cause is only half the battle. Preventing the root cause requires many more additional steps © 2004 Superfactory™. All Rights Reserved.

Less rework = Increased profits! Benefits By eliminating the root cause… You save time and money! Problems are not repeated Reduce rework, retest, re-inspect, poor quality costs, etc… Problems are prevented in other areas Communication improves between groups and Process cycle times improve (no rework loops) Secure long term company performance and profits Here are the benefits for why your company should take the time, on every problem, to analyze down to the root cause $$ $$ Less rework = Increased profits! © 2004 Superfactory™. All Rights Reserved.

Importance of the root cause Not knowing the root cause can lead to costly band aids. The Washington Monument was degrading Why? Use of harsh chemicals Why? To clean up after pigeons Why so many pigeons? They eat spiders and there are a lot of spiders at the monument Why so many spiders? They eat gnats and lots of gnats at the monument Why so many gnats? They are attracted to the light at dusk. Solution: Turn on the lights at a later time. © 2004 Superfactory™. All Rights Reserved.

When should root cause analysis be performed? When PROBLEMS occur !! Supplier Defects Out of Control Process Excess Inventory Computer issues Scrap Problems medical errors Human Error Audit Finding When should we perform root cause analysis? All the time! When you do not dig deep enough into the detail of these problems, you should expect them to continue to reoccur time and time again Missed Deliveries Safety Issues Machine Defects Overspending Budget Workmanship Defects © 2004 Superfactory™. All Rights Reserved.

How does it differ from what we do now? USUAL APPROACH Problem Identified Firefighting! Immediate Containment Action Implemented Problem reoccurs elsewhere! Find someone to blame! PREFERRED APPROACH Here is the usual versus preferred approach to problem solving. In most companies, when a problem surfaces, we firefight and try to put out the “fire” immediately. This involves some kind of quick fix or work around to keep the process moving. Just as we find an acceptable “band aid” fix that works, another “fire” starts somewhere else and we rush to fix it. We never take the time to revisit these “fires” to figure out why they happened in the first place. We keep dealing with the same problems over and over again. The preferred approach is similar. First, we develop a quick fix for the problem. However, instead of rushing to the next issue of the day, we take some extra time to do root cause analysis so that same problem is not tomorrow’s big “fire” We then implement the process change and check to see that is does not return, we institutionalize the solution so other areas and groups do not have the same problem as well. Which one of these approaches will take longer to complete? Obviously the preferred approach will take much longer, so why should we take the time? We must think in the long term. In six months or a year from now, do we want to be dealing with the same number of problems as we are today, or do we want to have more time available to work on improving the process and other value added activities. Immediate Containment Action Implemented Defined Root Cause Analysis Process Solutions validated with data Solutions are applied across company and never return! Problem Identified © 2004 Superfactory™. All Rights Reserved.

“Customer” can be Internal or External How does it work? Defect found at “Customer”… PROCESS A PROCESS B PROCESS C PROCESS D Here is a basic example of how to attack a problem with the problem solving process. These are television sets with a defective screen that escapes to the customer. Customer can be used as the internal customer (another process area) or the typical external customer (who pays for the product or service) CUSTOMER “Customer” can be Internal or External © 2004 Superfactory™. All Rights Reserved.

Nothing is allowed to further escape to the customer How does it work? Contain the problem… PROCESS A PROCESS B PROCESS C PROCESS D Contain the problem. Make certain that the group (customer in this case) that finds the problem does not see it again! CUSTOMER Nothing is allowed to further escape to the customer © 2004 Superfactory™. All Rights Reserved.

Nothing is allowed to further escape to the next process How does it work? Contain the root process… PROCESS A PROCESS B PROCESS C PROCESS D Once we better understand where the problem originates, we isolate our containment around that process, and allow the other processes to operate normally. These processes should not see the problem return. CUSTOMER Nothing is allowed to further escape to the next process © 2004 Superfactory™. All Rights Reserved.

Prevent the problem… How does it work? PROCESS A PROCESS B PROCESS C PROCESS D Finally, once root cause is determined and prevented through process changes, the containment efforts should be lifted and the new process should no longer create defects resulting from the same root cause. CUSTOMER Corrective action implemented so root cause of problem does not occur again! © 2004 Superfactory™. All Rights Reserved.

But who’s to blame? The “no blame” environment is critical Most human errors are due to a process error A sufficiently robust process can eliminate human errors Placing blame does not correct a root cause situation Is training appropriate and adequate? Is documentation available, correct, and clear? Are the right skillsets present? © 2004 Superfactory™. All Rights Reserved.

Corrective Actions 3 types of Corrective Action: Immediate action The action taken to quickly fix the impact of the problem so the “customer” is not further impacted Permanent root cause corrective action The action taken to eliminate the error on the affected process or product Preventive (Systemic) root cause corrective action The action taken to Prevent the error from recurring on any process or product There are three types of corrective actions. Immediate is the action done to “stop the bleeding” Permanent is typically done on a specific area or product to prevent the root cause from recurring. This is where most companies stop. Preventive is changing the process so that problem does not reoccur again in that area, or any other area in the future. This forces departments and groups to break down walls and communicate for the good of the company. © 2004 Superfactory™. All Rights Reserved.

Examples of Corrective Actions Immediate (step #3) All current batch of paperwork re-inspected by another worker for same type of problem Permanent (step #5) Form changed to mandate completion of certain fields Preventive (step #5) Here is an example of a transactional process, showing the three types of corrective action If there is a documentation error, the immediate action is the re-inspection of the paperwork for that specific error. This might also include reworking the document to get it back to an acceptable condition The permanent action is the changing of the form so that it cannot proceed without the correct information going to the document. The preventive action is the mistake proofing of all similar processes so that the error cannot be made again in the future Similar forms with same fields used all over in company are changed to “mandatory” If preventive not addressed, problem will return!! © 2004 Superfactory™. All Rights Reserved.

Examples of Corrective Actions Immediate (step #3) Part removed and replaced in product, retested Permanent (step #5) Product redesigned to account for part variability Preventive (step #5) Here is another example… Design process changed to require variation analysis testing on similar supplier parts If preventive not addressed, problem will return!! © 2004 Superfactory™. All Rights Reserved.

The Difference between Permanent vs. Preventive Corrective Actions Made training a requirement to new employees working in that area Changed design guidelines to not allow for use of part in full scale production All documents that are critical to project are identified with red folders Check for those software bugs added to checklist and performed prior to release of software Process developed to identify “at risk” patients for falls who require assistant Ethics training developed and provided to all employees Permanent Trained employee on proper machine use Changed product design to make parts easier to assemble manually Specific customer document critical to project is identified with red folder Update all customers with latest software revision to fix problem Fallen patient given full-time assistant to provide help moving around hospital Employee fired for ethical violation Here are some more examples of the difference between Permanent versus Preventive. Class attendees should start to see what we mean by root cause. Feel free to add your own company examples. © 2004 Superfactory™. All Rights Reserved.

Problem Solving Process 1 Validate Follow Up Plan Complete Plan Action Plan Root Cause Immediate Action Identify Team Identify Problem Problem Solving Process 8 2 3 7 A common, simple and highly recommended 8 step problem solving process. NOTE: This graphic is used on other slides, so if you customize this graphic, you will have to make changes to the other process steps, or remove those smaller graphics 6 4 5 © 2004 Superfactory™. All Rights Reserved.

Step #1 Very important! Identify the Problem Clearly state the problem the team is to solve Teams should refer back to problem statement to avoid getting off track Use 5W2H approach Who? What? Why? When? Where? How? How Many? Very important! The first, and one of the most important steps, is to identify the problem to address. Meetings can be drawn out and lose focus when the problem is unclear. It is very easy for teams to use the meetings as opportunities to address other issues at the same time. The 5 W’s and 2 H’s approach can help you get there. Simply answer the who, what, where, when, why, how, and how many to help better define the problem. © 2004 Superfactory™. All Rights Reserved.

Step #1 5W2H Who? Individuals/customers associated with problem What? The problem statement or definition When? Date and time problem was identified Where? Location of complaints (area, facilities, customers) Why? Any previously known explanations How? How did the problem happen (root cause) and how will the problem be corrected (corrective action)? How Many? Size and frequency of problem A description of the 5W2H questions © 2004 Superfactory™. All Rights Reserved.

Step #2 Identify Team When a problem cannot be solved quickly by an individual, use a team! Should consist of domain knowledge experts Small group of people (4-10) with process and product knowledge, available time and authority to correct the problem Must be empowered to “change the rules” Should have a designated Champion Membership in team is always changing! In most cases, a team of affected individuals should be brought together to discuss the issue. Problems can arise when the right people are not involved. Try and keep the team between 4-10 people. More than that can slow down the process It is recommended that the team assigns a “Champion” to oversee the problem until it is resolved. They may play an active role in the discussions, or simply make certain the teams are meeting and that progress is being made. May also be responsible for taking issues up to leadership As the problems become more defined and analysis starts to drive the team in one direction, it is normal for the team members to change. Initially, step 1 will have the most team members, and towards the end of this process, maybe only one or two people are still actively working the issue. During the root cause analysis step, new members may be asked to participate based on their expertise in a certain area. © 2004 Superfactory™. All Rights Reserved.

Key Ideas for Team Success Step #2 Key Ideas for Team Success Define roles and responsibilities Identify external customer needs Identify internal customer needs Appropriate levels of organization present Clearly defined objectives and outputs Solicit input from everyone! Good meeting location near work area for easy access to info quiet for concentration and avoiding distractions The following are keys to success for working in a group. The first one is defining roles and responsibilities. Each member must know what they are expected to “bring to the table”. This assures the team that all needed areas are adequately covered before beginning. The second note is to identify external customer needs. What outputs and results are expected from the customer, and how will they be communicated (at the end of the project, during, only when needed?) Identify internal needs. What processes and procedures need to be followed, and what systems are available or required. This may include a corrective action process. Without the appropriate levels of management supporting the effort, the team will have a hard time implementing any actions or activities that will result from the teams effort Clearly defined objectives and outputs are essential, otherwise the team may try to attack issues outside the scope of the analysis or get sidetracked by other problems that each group may want resolved. If all members are not involved in the discussions, there will be less buy-in to the resolution. Identify members who are not participating and ask for their opinions. Try to prevent certain individuals from dominating the discussion. Good meeting location may not make the team perform any better, but will prevent other distractions and issues that can really impact the teams success © 2004 Superfactory™. All Rights Reserved.

Roles and Responsibilities Step #2 Roles and Responsibilities Champion: Mentor, guide and direct teams, advocate to upper management Leader: day-to-day authority, calls meetings, facilitation of team, reports to Champion Record Keeper: Writes and publishes minutes Participants: Respect all ideas, keep an open mind, know their role within team The following is a list of roles and responsibilities © 2004 Superfactory™. All Rights Reserved.

Step #3 Immediate Action Must isolate effects of problem from customer Usually “Band-aid” fixes 100% sorting of parts Re-inspection before shipping Rework Recall parts/documents from customer or from storage Only temporary until corrective action is implemented (very costly, but necessary) Must also verify that immediate action is effective The third step is to address the immediate action needed to keep the problem from spreading any further. Often times, this involves some sort of band-aid, or containment effort, such as: sorting of parts or paperwork, re-inspection, rework, or recall Whatever immediate action is done, it should only be temporary, and not stay in place after the root cause has been corrected. A check should also be made to see that the containment and immediate action actually kept the problem from spreading any further © 2004 Superfactory™. All Rights Reserved.

Verify Immediate Action Step #3 Verify Immediate Action Immediate action = activity implemented to screen, detect and/or contain the problem Must verify that immediate action was effective Run Pilot Tests Make sure another problem does not arise from the temporary solutions Ensure effective screens and detections are in place to prevent further impact to customer until permanent solution is implemented. More info about immediate action © 2004 Superfactory™. All Rights Reserved.

Step #4 Root Cause Brainstorm possible causes of problem with team Organize causes with Cause and Effect Diagram “Pareto” the causes to identify those most likely or occurring most often Use 5 Why? method to further define the root cause of symptoms May involve additional research/analysis/investigation to get to each “Why?” Must identify the process that caused the problem if root cause is company-wide, elevate these process issues (outside of team control) to upper management to address Step 4 is defining the root cause. First of all, brainstorm the possible causes of the problem with the team. We recommend the use of the Cause and Effect diagram. After brainstorming, use the pareto principle to determine which causes to focus on. After selecting the most probable cause, there is still more analysis to perform. Use the 5 Why’s methodology until you get to the root cause. The root cause will be a process that initially caused the problem to occur. People, departments, groups or machines are not the root cause. Try to take the root cause one more step to make sure the team addresses the same problems at the company wide level, or outside of their own department or group. © 2004 Superfactory™. All Rights Reserved.

Step #4 Tools brainstorming flowcharting cause & effect diagrams pareto charts barrier analysis change analysis 5 Why failure mode, effect & criticality analysis fault tree analysis Step 4 is defining the root cause. First of all, brainstorm the possible causes of the problem with the team. We recommend the use of the Cause and Effect diagram. After brainstorming, use the pareto principle to determine which causes to focus on. After selecting the most probable cause, there is still more analysis to perform. Use the 5 Why’s methodology until you get to the root cause. The root cause will be a process that initially caused the problem to occur. People, departments, groups or machines are not the root cause. Try to take the root cause one more step to make sure the team addresses the same problems at the company wide level, or outside of their own department or group. © 2004 Superfactory™. All Rights Reserved.

Step #4 5 Why’s Ask “Why?” five times Stop when the corrective actions do not change Stop when the answers become less important Stop when the root cause condition is isolated Step 4 is defining the root cause. First of all, brainstorm the possible causes of the problem with the team. We recommend the use of the Cause and Effect diagram. After brainstorming, use the pareto principle to determine which causes to focus on. After selecting the most probable cause, there is still more analysis to perform. Use the 5 Why’s methodology until you get to the root cause. The root cause will be a process that initially caused the problem to occur. People, departments, groups or machines are not the root cause. Try to take the root cause one more step to make sure the team addresses the same problems at the company wide level, or outside of their own department or group. © 2004 Superfactory™. All Rights Reserved.

What is a Cause-Effect Diagram? A Cause-Effect (also called “Ishikawa” or “Fishbone”) Diagram is a Data Analysis/Process Management Tool used to: Organize and sort ideas about causes contributing to a particular problem or issue Gather and group ideas Encourage creativity Breakdown communication barriers Encourage “ownership” of ideas Overcome infighting © 2004 Superfactory™. All Rights Reserved.

Cause-Effect Diagram A Cause-Effect Diagram is typically generated in a group meeting It is a graphical method for presenting and sorting ideas about the causes of issues or problems © 2004 Superfactory™. All Rights Reserved.

Cause-Effect Diagram Effect Steps used to create a Cause-Effect Diagram: Define the issue or problem clearly Decide on the root causes of the observed issue or problem Brainstorm each of the cause categories Write ideas on the cause-effect diagram. A generic example is shown below: Environment Effect People Equipment Methods Materials NOTE: Causes are not limited to the 5 listed categories, but serve as a starting point © 2004 Superfactory™. All Rights Reserved.

Cause-Effect Diagram Shipping Problems Allow team members to specify where ideas fit into the diagram Clarify the meaning of each idea using the group to refine the ideas. For example: Materials Incorrect Quantity Incorrect BOL Wrong Destination Methods Late Dispatch Shipping Delay Spillage Environment Shipping Problems Traffic Delays Weather Equipment Wrong Equipment Dirty Equipment Breakdown People Driver Attitude Dispatcher Wrong Directions © 2004 Superfactory™. All Rights Reserved.

Cause-Effect Diagram After completing the Cause-Effect Diagram, take the following actions: Rank the ideas from the most likely to the least likely cause cause of the problem or issue Develop action plans for identifying the essential data, resources and tools © 2004 Superfactory™. All Rights Reserved.

Expected Outcome Individuals have become part of a problem solving team The sources of problems and other issues have been identified using a systematic process Team members see issues from a similar perspective Ideas and solutions are documented Communication is improved Team members assume ownership © 2004 Superfactory™. All Rights Reserved.

Corrective Action Plan Step #5 Corrective Action Plan Must verify the solution will eliminate the problem Verification before implementation whenever possible Define exactly… What actions will be taken to eliminate the problem? Who is responsible? When will it be completed? Make certain customer is happy with actions Define how the effectiveness of the corrective action will be measured. Verification involves testing of the proposed solution to make sure it will do what the team thinks it will prior to a full scale implementation. Often times, the solution can create additional problems. If the solution will not work, it is better to find out in a beta test environment, rather than under normal operating conditions. © 2004 Superfactory™. All Rights Reserved.

Verification vs. Validation Step #5 Verification vs. Validation (Before) (After) Verification Assures that at a point in time, the action taken will actually do what is intended without causing another problem Validation Provides measurable evidence over time that the action taken worked properly, and problem has not recurred Validation means that the corrective action not only worked, but it was effective long term (withstanding all possible process issues) © 2004 Superfactory™. All Rights Reserved.

Step #6 Complete Action Plan Make certain all actions that are defined are completed as planned If one task is still open, verification and validation is pushed back If the plan is compromised, most likely the solution will not be as effective Step 6 is simply making sure to complete the action plans defined in Step 5. You cannot verify or validate until all actions have been completed. If the actions are not fully completed, or only partially completed, the effectiveness of the solution will be jeopardized © 2004 Superfactory™. All Rights Reserved.

Step #7 Follow Up Plan What actions will be completed in the future to ensure that the root cause has been eliminated by this corrective action? Who will look at what data? How long after the action plan will this be done? What criteria in the data results will determine that the problem has not recurred? Step 7 involves preparing the team for action, once the data analysis of the solution is complete. Who should be collecting the data, and for how long? What type of data results will be deemed acceptable? © 2004 Superfactory™. All Rights Reserved.

Validate and Celebrate Step #8 Validate and Celebrate What were the results of the follow up? If problem did reoccur, go back to Step #4 and re-evaluate root cause, then re-evaluate corrective action in Step #5 If problem did not reoccur, celebrate team success! Document savings to publicize team effort, obtain customer satisfaction and continued management support of teams Finally, the team should review the data results to conclude whether the root cause was adequately defined, or that the corrective action put in place was effective. If the problem still exists. Go back to either Step #4 and redefine the root cause, or Step #5, to readdress the corrective actions put in place. If the problem went away, formally close the problem and celebrate success. It is extremely beneficial if a financial savings impact of resolving the problem is calculated. Many companies will redistribute a percentage of the cost savings back to the team members to further support the importance of solving problems © 2004 Superfactory™. All Rights Reserved.

What does a good RCA look like? The Root Cause is Internally Consistent , Thorough, and Credible © 2004 Superfactory™. All Rights Reserved.

What does a good RCA look like? The Complete Root Cause Analysis is inter-disciplinary, involving experts from the frontline services involving of those who are the most familiar with the situation continually digging deeper by asking why, why, why at each level of cause and effect. a process that identifies changes that need to be made to systems a process that is as impartial as possible © 2004 Superfactory™. All Rights Reserved.

What does a good RCA look like? To be thorough a Root Cause Analysis must include: determination of human & other factors determination of related processes and systems analysis of underlying cause and effect systems through a series of why questions identification of risks & their potential contributions determination of potential improvement in processes or systems © 2004 Superfactory™. All Rights Reserved.

What does a good RCA look like? To be Credible a Root Cause Analysis must: include participation by the leadership of the organization & those most closely involved in the processes & systems be internally consistent © 2004 Superfactory™. All Rights Reserved.

Hints about root causes One problem may have more than one root cause One root cause may be contributing to many problems When the root cause is not addressed, expect the problem to reoccur Prevention is the key! Here are a couple things to keep in mind when performing root cause analysis. Remember, just as one problem may have multiple root cause possibilities, one root cause may be causing multiple problems. When you do root cause analysis on a problem, you will have one root cause. However, if you look at all the “possible” ways in which it could go wrong, you will find multiple things that need to be improved. When you don’t get to root cause, the process that creates it continues to send more problems and the problem will eventually return. Many times a short period of time without reoccurrence does not mean the root cause has gone away When at all possible, brainstorm what possible root causes might be, so that you don’t have to wait for a problem to arise before it is fixed © 2004 Superfactory™. All Rights Reserved.

Review You learned: How to identify the root cause Why it is important The process for proper root cause analysis How basic quality tools can be applied to examples This is what the students should have learned in this course: How to identify the root cause, why it is so important for company success, the proper process for root cause analysis, and how you can apply basic quality tools to the problem solving process © 2004 Superfactory™. All Rights Reserved.

Root Cause Analysis Example #1 Manufacturing Root Cause Analysis Example #1 This is the first example. We will walk through this example using the quality tools and the problem solving process. The second example is a transactional process example. We highly encourage the use of your own company examples in addition to these. © 2004 Superfactory™. All Rights Reserved.

Part polarity reversed on circuit board Example #1 Identify Problem Part polarity reversed on circuit board We identify the problem as part polarity reversed on a printed circuit board. This may have been one incident, or a recurring problem identified from a pareto chart © 2004 Superfactory™. All Rights Reserved.

Determine Team Team members: Team Leader – Terry Inspector – Jane Worker – Tammy Worker - Joe Quality Eng – Rob Engineer – Sally © 2004 Superfactory™. All Rights Reserved.

Immediate Action Additional inspection added after this assembly process step to check for reversed part defects Last 10 lots of printed circuit boards were re-inspected to check for similar errors The immediate activity implemented after the team gets together… © 2004 Superfactory™. All Rights Reserved.

5 Why's Root Cause Why? Part reversed The problem is placed in the first box. We then ask the first why. Why was the part reversed? © 2004 Superfactory™. All Rights Reserved.

Worker not sure of correct part orientation Root Cause Part reversed Worker not sure of correct part orientation Why? The team determines that the factory worker was unsure of the correct part orientation when performing the task. Often times, teams will stop and assume that the problem is due to human error. This is NOT an acceptable root cause. Errors will always be made, so teams must dig deeper to find a way of making the process easier, or find a better way of catching the problem sooner. We again ask why. Why was the worked unsure of the correct orientation? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Part reversed Worker not sure of correct part orientation Part is not marked properly Why? Continue with the 5 Why’s process until they reach a defective process © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Part reversed Worker not sure of correct part orientation Part is not marked properly The 5 Why’s implies asking why five times, but it could be more than 5. Asking at least five times forces the team to dig beyond their own knowledge of the process and make certain they don’t stop short of the root cause Engineering ordered it that way from vendor Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Root Cause Part reversed Worker not sure of correct part orientation Part is not marked properly The team determines that the engineering process does not adequately account for manufacturing issues during the selection or specification process. Notice that they did not put the blame on the individual engineer. Engineering ordered it that way from vendor Root Cause Process didn’t account for possible manufacturing issues © 2004 Superfactory™. All Rights Reserved.

Corrective Action Permanent – Changed part to one that can only be placed in correct direction (Mistake proofed). Found other products with similar problem and made same changes. Preventive - Required that any new parts selected must have orientation marks on them. Here are the permanent and preventive actions. The permanent changes that part for that particular problem. The preventive truly addresses the larger issue of selecting the parts correctly the first time with orientation marks, instead of afterwards when the problem is found. © 2004 Superfactory™. All Rights Reserved.

Root Cause Analysis Example #2 © 2004 Superfactory™. All Rights Reserved.

Example #2 Identify Problem A manager walks past the assembly line and notices a puddle of water on the floor. Knowing that the water is a safety hazard, she asks the supervisor to have someone get a mop and clean up the puddle. The manager is proud of herself for “fixing” a potential safety problem. © 2004 Superfactory™. All Rights Reserved.

Example #2 But What is the Root Cause? The supervisor looks for a root cause by asking 'why?’ © 2004 Superfactory™. All Rights Reserved.

Immediate Action Knowing that the water is a safety hazard, the manager asks the supervisor to have someone get a mop and clean up the puddle. © 2004 Superfactory™. All Rights Reserved.

Puddle of water on the floor Root Cause 5 Why's Puddle of water on the floor Why? © 2004 Superfactory™. All Rights Reserved.

Puddle of water on the floor Root Cause Puddle of water on the floor Leak in overhead pipe Why? © 2004 Superfactory™. All Rights Reserved.

Puddle of water on the floor Water pressure is set too high Root Cause Puddle of water on the floor Leak in overhead pipe Water pressure is set too high Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Puddle of water on the floor Leak in overhead pipe Water pressure is set too high Water pressure valve is faulty Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Root Cause Puddle of water on the floor Leak in overhead pipe Water pressure is set too high Water pressure valve is faulty Root Cause Valve not in preventative maintenance program © 2004 Superfactory™. All Rights Reserved.

Corrective Action Permanent – Water pressure valves placed in preventative maintenance program. Preventive - Developed checklist form to ensure new equipment is reviewed for possible inclusion in preventative maintenance program. © 2004 Superfactory™. All Rights Reserved.

Root Cause Analysis Example #3 © 2004 Superfactory™. All Rights Reserved.

Example #3 Identify Problem Customers are unhappy because they are being shipped products that don't meet their specifications. © 2004 Superfactory™. All Rights Reserved.

Immediate Action Inspect all finished and in-process product to ensure it meets customer specifications. © 2004 Superfactory™. All Rights Reserved.

Product doesn’t meet specifications Root Cause 5 Why's Product doesn’t meet specifications Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Product doesn’t meet specifications Manufacturing specification is different from what customer and sales person agreed to Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Product doesn’t meet specifications Manufacturing specification is different from what customer and sales person agreed to Sales person tries to expedite work by calling head of manufacturing directly Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Product doesn’t meet specifications Manufacturing specification is different from what customer and sales person agreed to Sales person tries to expedite work by calling head of manufacturing directly Manufacturing schedule is not available for sales person to provide realistic delivery date Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Root Cause? Product doesn’t meet specifications Manufacturing specification is different from what customer and sales person agreed to Sales person tries to expedite work by calling head of manufacturing directly Manufacturing schedule is not available for sales person to provide realistic delivery date Root Cause? Confidence in manufacturing schedule is not high enough to release/link with order system © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Root Cause? NOT YET! Confidence in manufacturing schedule is not high enough to release/link with order system Why? © 2004 Superfactory™. All Rights Reserved.

Parts sometimes not available thereby creating schedule changes Root Cause Confidence in manufacturing schedule is not high enough to release/link with order system Parts sometimes not available thereby creating schedule changes Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Confidence in manufacturing schedule is not high enough to release/link with order system Parts sometimes not available thereby creating schedule changes Expediting and priority changes consume parts not planned for Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Confidence in manufacturing schedule is not high enough to release/link with order system Parts sometimes not available thereby creating schedule changes Expediting and priority changes consume parts not planned for Manufacturing schedule does not reflect realistic assembly and test time Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Root Cause Confidence in manufacturing schedule is not high enough to release/link with order system Parts sometimes not available thereby creating schedule changes Expediting and priority changes consume parts not planned for Manufacturing schedule does not reflect realistic assembly and test time Root Cause No ongoing review of manufacturing standards © 2004 Superfactory™. All Rights Reserved.

Corrective Action Permanent – Manufacturing standards reviewed and updated. Preventive - Regular ongoing review of actuals vs standards is implemented. © 2004 Superfactory™. All Rights Reserved.

Root Cause Analysis Example #4 Example #2 is geared towards transactional, or office related processes © 2004 Superfactory™. All Rights Reserved.

Department didn’t complete their project on time Example #4 Identify Problem Department didn’t complete their project on time © 2004 Superfactory™. All Rights Reserved.

Determine Team Team members: Boss – Jim Worker – Tom Worker - Karen Project Mgr – Bob Admin – Sally © 2004 Superfactory™. All Rights Reserved.

Immediate Action Additional resources applied to help get the project team back on schedule No new projects started until Root Cause Analysis completed The team applies additional resources to get the team back on schedule and no new projects were started until the root cause solutions of this project were completed. © 2004 Superfactory™. All Rights Reserved.

Didn’t complete project on time Root Cause 5 Why's Didn’t complete project on time Why? © 2004 Superfactory™. All Rights Reserved.

Cause and Effect Procedures Personnel Didn’t complete project on time Lack of worker knowledge Poor project plan Poor project mgmt skills Lack of resources Didn’t complete project on time The team uses the Cause and Effect Diagram to identify possible causes of the projects delay. Each cause is placed into the appropriate category Inadequate computer programs Poor documentation Inadequate computer system Materials Equipment © 2004 Superfactory™. All Rights Reserved.

Cause and Effect Procedures Personnel Didn’t complete project on time Lack of worker knowledge Poor project plan Poor project mgmt skills Lack of resources Didn’t complete project on time The team decides, based on experience and the available data, to focus on the “lack of resources” as the major reason for the delay. Inadequate computer programs Poor documentation Inadequate computer system Materials Equipment © 2004 Superfactory™. All Rights Reserved.

Didn’t complete project on time Resources unavailable when needed Root Cause Didn’t complete project on time Resources unavailable when needed Why? The team determines that the appropriate resources were not available when they were most needed to keep the project on schedule. © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Didn’t complete project on time Resources unavailable when needed Took too long to hire Project Manager Why? In this example, the Project Manager was not hired in time, which had a huge impact on the project’s schedule. © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Didn’t complete project on time Resources unavailable when needed Took too long to hire Project Manager The team keeps asking why, this time determining that the specifics for the Project Manager position were not clear and caused the Human Resources department to contact and interview some candidates who were not fully qualified Lack of specifics given to Human Resources Dept Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Root Cause Didn’t complete project on time Resources unavailable when needed Took too long to hire Project Manager Instead of stopping and blaming the HR department, the team brings a representative from HR into the team to dig further. After some discussion, the team determines that there are some problems with the internal job posting process, which allows the job specifics for the position to be overlooked or not clearly defined. Lack of specifics given to Human Resources Dept Root Cause No formal process for submitting job opening © 2004 Superfactory™. All Rights Reserved.

Corrective Action Permanent – Hired another worker to meet needs of next project team Preventive - Developed checklist form with HR for submitting job openings in the future The permanent action involves adding an additional full time support person to the project. The preventive action addresses the process issue so that the problem does not happen again! © 2004 Superfactory™. All Rights Reserved.

Root Cause Analysis Example #5 © 2004 Superfactory™. All Rights Reserved.

Example #5 Identify Problem High pyrogen count on finished medical catheter product using molded components. © 2004 Superfactory™. All Rights Reserved.

Immediate Action (and panic!) Quarantine all finished and in-process product (over $2 million worth!) Analyze location of pyrogen to find common denominator © 2004 Superfactory™. All Rights Reserved.

Panic-driven Immediate Reaction Panic-Driven Action Panic-driven Immediate Reaction (without root cause analysis) Pyrogen traced to molding cooling water leak Holy cow!… cooling water system hasn’t been cleaned in 15 years! Shut down 24/7 molding operation for 2 days to clean cooling water system Implement system for weekly analysis of cooling water for pyrogens Threaten to fire anyone who doesn’t report a cooling water leak © 2004 Superfactory™. All Rights Reserved.

Panic-Driven Action - Results Results of Panic-driven Immediate Reaction (without root cause analysis) Day 1 after cooling water system cleaning: water tests clean of pyrogens Day 2: cooling water is saturated with pyrogens. Uh oh. All operators and technicians reporting “possible water leaks” on all presses, all molds, all shifts… “just in case”. Molding operation shuts down. Operations manager nearly fired. “Help” flying in from corporate offices and other molding plants. Hourly conference calls to give status updates to executives. © 2004 Superfactory™. All Rights Reserved.

Logic Returns There must be a better way! How about trying something called “Root Cause Analysis”? © 2004 Superfactory™. All Rights Reserved.

Pyrogens on molded components Root Cause 5 Why's Pyrogens on molded components Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Pyrogens on molded components Parts released from molding even though they had been sprayed with leaking cooling water Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Pyrogens on molded components Parts released from molding even though they had been sprayed with leaking cooling water Disposition of contaminated parts procedure does not discuss water Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Why? Pyrogens on molded components Parts released from molding even though they had been sprayed with leaking cooling water Disposition of contaminated parts procedure does not discuss water Oil, grease, dust, human contact believed to be primary sources of contamination Why? © 2004 Superfactory™. All Rights Reserved.

Root Cause Root Cause Pyrogens on molded components Parts released from molding even though they had been sprayed with leaking cooling water Disposition of contaminated parts procedure does not discuss water Oil, grease, dust, human contact believed to be primary sources of contamination Root Cause No formal evaluation of contamination sources, types, severity, and disposition action. © 2004 Superfactory™. All Rights Reserved.

Corrective Action Permanent – Disposition of contaminated parts procedure re-written to include water. Preventive - Formal study of contamination sources, consequences, and disposition requirements. © 2004 Superfactory™. All Rights Reserved.