Your SlideShare is downloading. ×
0
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
How to solve problems (or at least try) with 8D
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

How to solve problems (or at least try) with 8D

14,501

Published on

8D could be also an excellent method for risk mitigation. The course was developed in 2012.

8D could be also an excellent method for risk mitigation. The course was developed in 2012.

Published in: Technology, Business
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
14,501
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
786
Comments
0
Likes
12
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 8D-Problem solving method Dr.ing. Ștefan KOVACS
  • 2. Contents • Goal of this course • Historic of 8D • Glossary • What is 8D ? • Global 8D • 8D-X factory procedure • The main steps of 8D
  • 3. GOAL OF THIS COURSE • The students should be able to use 8D in their current activity, based on the guidelines of the X factory procedure or independently if needed. • The students should retain some operative methods like 5W, 5W2H, Fishbone, etc.
  • 4. History of 8D • The development of a Team Oriented Problem Solving strategy, based on the use of statistical methods of data analysis, was done at Ford Motor Company. The executives of the Powertrain Organization (transmissions, chassis, engines) wanted a methodology where teams (design engineering, manufacturing engineering, and production) could work on recurring problems. In 1986, the assignment was given to develop a manual and a subsequent course that would achieve a new approach to solving tough engineering design and manufacturing problems.
  • 5. History of 8D • The manual for this methodology was documented and defined in "Team Oriented Problem Solving"(TOPS), first published in 1987. The manual and subsequent course material was piloted at World Headquarters in Dearborn, Michigan. Many changes and revisions were made based on feedback from the pilot sessions. This has been Ford's approach to problem solving ever since. It was never based on any military standard or other existing problem solving methodology. The material is extensive and the 8D titles are merely the chapter headings for each step in the process. Ford also refers to their current variant as G8D (Global 8D)
  • 6. History of 8D-Military usage • The US Government first standardized a process during the Second World War as Military Standard 1520 'Corrective Action and Disposition System for Nonconforming Material' . This military standard focused on nonconforming material and the disposition of the material. • The 8D Problem Solving Process is used to identify, correct and eliminate recurring problems. The methodology is useful in product and process improvement. It establishes a permanent corrective action based on statistical analysis of the problem. It focuses on the origin of the problem by determining Root Causes. • This 'Determine a Root Cause' step is a part of the military usage of the 8D's but was not a reference in the development of the 8D problem solving methodology and is not referenced or included in the TOPS manual or course.
  • 7. Glossary • Action plan-This is a formal record of assignments, responsibilities and timing. • Advanced product quality planning-A cross functional approach that enables communication and feedback to flow throughout the organization for improved quality and productivity. APQP focuses on linking ‘Prevent Recurrence’ with: • Defined product development process (event, timing, quality of event) • G-Y-R (Green, Yellow, Red) program control process (macro view of critical path). • Design Quality Review (DQR) or micro view of working documents. • Engineering change management (Verification and Validation) • Analytical Tools
  • 8. Glossary • Common cause-Process inputs and conditions that regularly contribute to the variability of process outputs. Because Common Causes are ‘regular’ contributors, the ‘Process’ or ‘System’ Variability is defined in terms of them. • Containment action-Verified action that immediately stops the Symptom from reaching the customer. • Corrective action-Action that permanently eliminates the Root Cause of a problem. Selected in D5 and implemented in D6.
  • 9. Glossary • Champion-Someone who has authority but does not participate directly in the team’s problem solving activities. A supporter and persuader of the team’s actions. • Common cause- Process inputs and conditions that regularly contribute to the variability of process outputs. Because Common Causes are ‘regular’ contributors, the ‘Process’ or ‘System’ Variability is defined in terms of them
  • 10. Glossary • Decision making-Process used to select the best Corrective Action. Assess impact and risks. • Design Quality Reviews-A process that measures the Product Development Process. Examines information across the cross- functional Product Development Team in terms of: • The ability of the design to meet customer needs and wants. • Comparison with Best-In-Class (BIC) • Ability to meet Affordable Targets (AFT) • Level of robustness of both the process and the product. • Things-Gone-Wrong / Things-Gone-Right in process (including Team functioning). • Defining ‘Quality of the Event” for the engineering process. • Design Verification Plan & Report
  • 11. Glossary • Empowerement-A proactive process, to delegate, authorize, or enable the Team members to have Ownership and to be responsible for changing the rules. • Escape- Primary question in problem solving which explains how the problem reached the customer.
  • 12. Glossary • Information database-A tool for Root Cause Analysis that organizes all known data about a problem into four categories: • What, Where, When and How Big by using Is / Is Not comparisons in D2. The database is analyzed for Differences and Changes leading to Root Cause in D4. Corrective actions are evaluated using Decision Making and Verification in d%. Actions are implemented in D6
  • 13. Glossary • Management review-Jointly agreed to by Management and Team for periodic review of progress to objectives. This is the team’s opportunity to obtain management assistance where required. • Management decision making-The technique chosen by Ford to achieve structural changes to meet customer satisfaction. This approach consists of theory, methods and philosophy for extracting information from data, converting data into information that enables us to improve the quality of managerial decisions.
  • 14. Glossary • Pareto chart-Type of bar chart used in problem description to quantify concerns / defects in descending order of importance. It works on the principle that 20% of the problems are responsible for 80% of the occurrences. • Paynter chart-Chart that identifies multiple problem descriptions and provides validation of containment and corrective actions over time. The chart consists of two-dimensional tracking of a specific number of problems along the Y axis and occurrences of failures in weeks or months along the X axis.
  • 15. Glossary • Poka-Yoke-Error Proofing - Techniques use simple and inexpensive devices to prevent errors about to occur or detect errors and defects that have occurred. • Policy deployment-System focus providing direction and alignment focusing on process What’s and How’s to develop different measures at different organizational levels to achieve common policy and/or goal
  • 16. Glossary • Problem Description Analysis-Process to organize and gather appropriate information about the Symptom into a Problem Description through the use of Repeated WHY's and the Information database. • Problem Improvement Methodology-Structured approach to ensure that our processes better met customer needs and wants over time, in an efficient manner, with a minimum of waste and error. The stages are: • Identify the opportunity • Define the scope • Analyze the current process • Envision future processes • Pilot and Verify the proposed changes • Implement changes • Continually improve
  • 17. Glossary • Process measurables- Indicators identified and monitored on an ongoing basis that result in consistent product quality and greater customer satisfaction. • Product development process-A group of events and processes that includes: • System design specification • Quality function deployment • Technology reviews • Risk assessment • Quality road map • Serviceability • Design and process verification plan and report • Design and process FMEA (Failure Modes Effects Analysis0 • Critical, safety and significant characteristics • Control plans and flow charts • Process capability • Initial sample review • Process review
  • 18. Glossary • Quality Function Deployment- A planning tool used by multi-disciplinary teams for translating customer needs and expectations into appropriate system and component requirements. The output of QFD process is the identification of system and component significant characteristics as well as key process and production characteristics.
  • 19. Glossary • Quality Operating System-Manufacturing plant - A data driven management process designed by Ford to get to the Root Cause of problems by employing the Prevent Recurrence methodology. A system format which includes and Executive Summary of key plant measurables, a Preventive Focus on performance of products during product development, a Customer focus group of measurables reflecting Voice of the Customer, and in internal Focus of process measurables.
  • 20. Glossary • Recognize gaps-Process of finding the distance between what should be happening and what is actually happening. Examples of gaps are Best-In-Class versus current performance, Customer Expectations versus what customer receives, Plan versus actual. • Repeated WHYs-Method for improved Problem Description that moves from the problem Symptom to the Problem Description by asking WHY to obtain better definition of object, concern and quantification. This question is asked repeatedly until a level is reached which can be acted upon.
  • 21. Glossary • Special cause-Process inputs and conditions which SPORADICALLY contribute to the variability of process outputs. The variability due to one or more Special Causes can be identified by the use of control charts. The ‘process’ or ‘system’ variability is defined without them. • System design specification-A tool which utilizes QFD methodology to identify the need to add or revise engineering and test specifications to correspond to all specific customer requirements. The output of SDS is revised system and component engineering requirements and testing specifications (DVP&R).
  • 22. Glossary • V-Loop- Process of Verifying Containment and Corrective Actions before implementation and Validating the actions over time after implementation. This process is performed by using the same indicator that demonstrated the problem. • Validate-Proof developed AFTER implementation and over time. The action taken must do what is intended by providing before and after data comparison, and must not introduce a new problem. Proof must be developed by using the same indicator that demonstrated the problem and should be tracked on the Paynter chart.
  • 23. What is 8 D ? • 8D is a problem-solving methodology for product and process improvement. It is structured into eight disciplines, emphasizing team synergy. The team as whole is better and smarter than the quality sum of the individuals. Each discipline is supported by a checklist of assessment questions, such as "what is wrong with what", "what, when, where, how much".
  • 24. What is 8D ? General schema
  • 25. What is 8D ? • It could be used to identify, correct and eliminate the recurrence of quality problems. • Actually, we could speak about 8(9) steps, described in detail in this course.
  • 26. 8D and typical operation flowchart
  • 27. Global 8D • In the late 1990s, Ford developed a revised version of the 8D process, that they call "Global 8D" (G8D) which is the current global standard for Ford and many other companies in the automotive supply chain. The major revisions to the process are as follows:
  • 28. Global 8D • Addition of a 0D (D-Zero) step as a gateway to the process. At D0, the team documents the symptoms that initiated the effort along with any Emergency Response Actions (ERAs) that were taken before formal initiation of the G8D. D0 also incorporates standard assessing questions meant to determine whether a full G8D is required. The assessing questions are meant to ensure that in a world of limited problem-solving resources, the efforts required for a full team-based problem- solving effort are limited to those problems that warrant these resources.
  • 29. Global 8D • Addition of Escape Point to D4 through D6. The idea here is to consider not only the Root cause of a problem, but equally importantly, what went wrong with the control system in allowing this problem to escape. Global 8D requires the team to identify and verify this Escape Point (defined as the earliest control point in the control system following the Root Cause that should have detected the problem but failed to do so) at D4. Then, through D5 and D6, the process requires the team to choose, verify, implement, and validate Permanent Corrective Actions to address the Escape Point.
  • 30. When is an 8D recquired ? • Often, a 8-D is a customer response at a problem. Feedback from the customer shows concern with a product or service. • Ideally, a measurable will indicate when a 8-D should start. When an undesirable trend in a process develops ,corrective action can be taken to reduce the cause of the variation before a symptom occurs in the process and escapes to the customer. • A decision must be made regarding if the symptom could be fixed or requires further analysis. If so, a 8-D team must assembled.
  • 31. Case study • Should a customer ask for solving of the problem ? Perhaps it is a minor problem (which could became serious) and he is not thinking to report it. • Should the enterprise applying 8D be avare of every problem, no matter how small it is ? • Please, give some examples of major, medium and minor problems in your opinion.
  • 32. 8D-X factory procedure • 1.1 This procedure establishes the process used at X factory Romania for the analysis of existing or potential problems in order to identify their root causes, to establish and implement the corrections and corrective / preventive actions, verification and review the effectiveness of the implemented actions. Also this procedure describes the way to record in SAP system the identified causes, the corrections and the corrective/preventive actions initiated to eliminate nonconformities and their causes.
  • 33. 8D-X factory procedure • 1.2 The procedure applies to X factory Romania’s Business Units and Departments for the nonconformities detected at internal audits (according to CRP-822), at the control of nonconforming products (according to CRP- 83), at solutioning of customers claims / FPRs, at suppliers performance evaluation, or for potential nonconformities
  • 34. 8D-X factory procedure • References: – - X factory Romania’s Quality Manual, code: CR-MQ; – - ISO 9000, Quality Management Systems. Basic principles and terminology; – - ISO 9001, Quality Management Systems. • Requirements; – - DP-001014, Corrective/Preventive Actions; – - DP-006001, Suppliers performance measurements; – - CRP-822, Internal audits; – - CRP-83, Control of nonconforming product;
  • 35. 8D-X factory procedure • 3.1 Corrective action (ISO 9000) – action to eliminate the cause of a nonconformity, defect or other undesirable situation. • Note 1: There can be more than one cause for nonconformity. • Note 2: Corrective action is taken to prevent recurrence whereas preventive action is taken to prevent occurrence. • Note 3: There is a distinction between correction and corrective action.
  • 36. 8D-X factory procedure • 3.2 Preventive action (ISO 9000) – action to eliminate the cause of a potential nonconformity or other undesirable potential situation. • Note 1: There can be more than one cause for a potential nonconformity. • Note 2: Preventive action is taken to prevent occurrence whereas corrective action is taken to prevent recurrence.
  • 37. 8D-X factory procedure • 3.4 Root Cause – Cause of a problem/nonconformity that goes beyond the obvious, visible aspect of the problem/ nonconformity and seeks to identify the base reason for the problem/nonconformity. This is the cause or causes, which if eliminated, will prevent the problem/nonconformity from reoccurring in the future.
  • 38. 8D-X factory procedure • 5.1 Identification and recording of the nonconformities and their causes – 5.1.1 The nonconformities can be detected on: • - receiving, manufacturing flow, and final inspection; • - internal and external quality audits; • - feedback from customers (complaints, suggestions, etc.); • - projects for improvement; • - current reviews performed in Production Centers/ Departments; • - evaluation of suppliers performance; • - audits performed by suppliers.
  • 39. 8D-X factory procedure • 5.2 Internal corrective and preventive actions – To establish and implement the corrective and preventive actions, the 8D principles described below shall be used.
  • 40. 8D-X factory procedure • D0 – CPAR initiation: • When a problem is identified, the Quality/Quality Assurance Engineer analyses the opportunity for corrective/ preventive actions. When it is determined that formal corrective/preventative action is warranted, a CPAR is initiated in SAP R/3 (in accordance with Annex 6.1). – CPAR shall be issued in the following situations: • - Nonconformities found in internal/external audits (customers / ISO / API); • - Repeatable nonconformities (more than 3 times in a month); • - Repair and rework with values more than 5.000 USD; • - Intracompany (FPR / NCR) or direct customers complaints; • - Nonconformities which leads to late delivery (more than 15 days); • - Scrap whose root cause is "operator error".
  • 41. 8D-X factory procedure • D1 – Building the team for 8D analysis of the problem • The assigned Manager has the responsibility to initiate the 8D process and in this respect,he shall establish and organize an 8D team.
  • 42. 8D-X factory procedure • D1 – Building the team for 8D analysis of the problem • The 8D team members can be (as applicable) the following persons: Process Engineers,Production Supervisors, Quality Engineer/Supervisor, Quality Assurance Engineer,Design Engineer, Programmers, Welding Engineer, Purchasing Referent, Planner, Operators. The 8D team leader is the assigned Manager.
  • 43. 8D-X factory procedure • D1 – Building the team for 8D analysis of the problem • This team has the following tasks: – - 8D process preparing (information, data,documents, product samples, etc). – - attending the cause analysis meetings when necessary. – - analyzing and identification of the root causes. – - establishing and proposing of corrective/preventive actions and implementing due dates. – - applying of the proposed solutions.
  • 44. 8D-Cameron procedure • D2 – Precise definition of the problem • The 8D team makes an initial analysis of the problem, and if it is necessary, reformulates the nonconformity description (in CPAR too). • The method 5W2H shall be used (Who?;What?; Why?; Where?; When?; How much?;How often?)
  • 45. 8D-X factory procedure • D3 – Establishing of immediate measures (corrections, etc.) to eliminate the problem / nonconformity or to eliminate /minimize the effects. • The 8D team analyses the necessity of immediate actions, i.e. hold on anufacturing,nonconform products isolation, other customers’ notification, etc.
  • 46. 8D-X factory procedure • D4 – The problem / nonconformity analysis to identify the root cause The 8D team analyses the problem /nonconformity to identify the rootcause/causes. • Specific methods like Analysis 5 Why? Or Fish bone - Ishikawa diagram (cause –effect diagram)shall be used. • The 8D team leader fills the „TASK – 001 –Root Cause Analysis” in CPAR and this task shall be closed.
  • 47. 8D-X factory procedure • D5 – Establishing of corrective /preventive actions and their implementation to eliminate the cause/ causes
  • 48. 8D-X factory procedure • D5 – Establishing of corrective /preventive actions and their implementation to eliminate the cause/ causes • - The 8D team 8D, after identification of causes, establishes the actions to eliminate them. A responsible person and a due date shall be assigned to each action. • - The preventive actions are established in order to avoid potential nonconformities,accidents or damages, or to improve the processes or products.
  • 49. 8D-X factory procedure • D5 – Establishing of corrective /preventive actions and their implementation to eliminate the cause/ causes • -The sources of nonconformities (Nonconformity reports for products, Reports for complaints, etc) are also recorded in the corrective/ preventive actions reports to ensure identification of the documents which were the basis for initiating those actions.
  • 50. 8D-X factory procedure • D5 – Establishing of corrective /preventive actions and their implementation to eliminate the cause/ causes • Some example of types of corrective or preventive actions (without limiting thereto) can be: – - modify the manufacturing specification or the manufacturing process; – - prepare new technologies or instructions for non- documented sub-processes; – - modify/supplement the procedures or instructions to clarify specific aspects;
  • 51. 8D-X factory procedure • D5 – Establishing of corrective /preventive actions and their implementation to eliminate the cause/ causes • Some example of types of corrective or preventive actions (without limiting thereto) can be: – - train the personnel in charge (also after preparing a new procedure or instruction or after modifying the existing ones); – - endowment with new technologies or tools/devices/ measuring instruments, etc.
  • 52. 8D-X factory procedure • D6 – Verification of implementation and effectiveness of corrective/preventive actions • The status, implementation results and effectiveness of the taken actions are recorded in the Corrective/ Preventive Actions Report by the initiating person.
  • 53. 8D-X factory procedure • D7 – Preventive actions. • Identify if is the case to extend the corrective actions also to other similar products/processes or if are necessary also other long term actions (modify procedures, processes,etc.)
  • 54. 8D-X factory procedure • D8 –CPAR closing up (according to • Annex 6.5). • If all actions have been implemented at the due date and this action have been considered effective, the appointed person for the task „005 – Follow Up” shall close the CPAR.
  • 55. 0D • What is done ?Prepare for the 8D • Collect the Symptoms • Symptoms Checklist • Emergency Response Action
  • 56. 0D • Identify the problem. • Is there a singular problem or a repeating problem ? Would it be above or belov ALARP ? • It deserves to be studied ? • It could lead towards problems that would manifest in loss, incidents and accidents ?
  • 57. 0D-Case study • Any problem, here ?
  • 58. 0D-Case study • Any problem, here ?
  • 59. 0D-Case study • Any problem, here ?
  • 60. 0D-Case study • Any problem, here ?
  • 61. 0D-Case study • Any problem, here ?
  • 62. 0D-Case study • Any problem, here ?
  • 63. 0D-Case study • Any problem, here ?
  • 64. 0D-Case study • Any problem, here ?
  • 65. 0D-Case study • Any problem, here ?
  • 66. 0D-Case study • Any problem, here ?
  • 67. 0D-Case study • Any problem, here ?
  • 68. 0D-Case study • Any problem, here ?
  • 69. 0D-Case study • Any problem, here ?
  • 70. 0D-Case study • Any problem, here ?
  • 71. 0D-Case study • Any problem, here ?
  • 72. 1D • Use Team Approach • Establish a small group of people with the knowledge, time, authority and skill to solve the problem and implement corrective actions. The group must select a team leader.
  • 73. 1D • When a problem cannot be solved quickly by an individual, it is necessary to form a Team. The team will engage in the investigation and resolution of the problem. Many factors are critical to establish a group and to ensure that the group can work effectively together. Using a team approach is not just a step in the problem solving process, but an overriding framework for decision making. • It is necessary to reevaluate team membership continually. • Model for Effective Teamwork: • Structure • Goals • Roles • Procedures • Interpersonal Relationships
  • 74. 1D
  • 75. 1D • Common causes are the myriad of ever-present factors (e.g., process inputs or conditions) that contribute in varying degrees to relatively small, apparently random shifts in outcomes day after day, week after week, month after month. The collective effect of all common causes is often referred to as system variation because it defines the amount of variation inherent in the system. • Special causes are factors that sporadically induce variation over and above that inherent in the system. Frequently, special cause variation appears as an extreme point or some specific, identifiable pattern in data. Special causes are often referred to as assignable causes because the variation they produce can be tracked down and assigned to an identifiable source. (In contrast, it is usually difficult, if not impossible, to link common cause variation to any particular source.) Special Cause variation results from events which are occurring outside the process. For example, a relatively major change in temperature or humidity could cause significant variation (points outside control limits) in the process.
  • 76. 1D • Brainstorming- how to: • The following rules are important to brainstorming successfully: • A leader should take control of the session, initially defining the problem to be solved with any criteria that must be met, and then keeping the session on course. He or she should encourage an enthusiastic, uncritical attitude among brainstormers and encourage participation by all members of the team. The session should be announced as lasting a fixed length of time, and the leader should ensure that no train of thought is followed for too long. The leader should try to keep the brainstorming on subject, and should try to steer it towards the development of some practical solutions. • Participants in the brainstorming process should come from as wide a range of disciplines with as broad a range of experience as possible. This brings many more creative ideas to the session.
  • 77. 1D • Brainstorming-how to: • Brainstormers should be encouraged to have fun brainstorming, coming up with as many ideas as possible, from solidly practical ones to wildly impractical ones in an environment where creativity is welcomed. • Ideas must not be criticised or evaluated during the brainstorming session. Criticism introduces an element of risk for a group member in putting forward an idea. This stifles creativity and cripples the free running nature of a good brainstorming session. • Brainstormers should not only come up with new ideas in a brainstorming session, but should also 'spark off' from associations with other people's ideas and develop other peoples ideas. • A record should be kept of the session either as notes or a tape recording. This should be studied subsequently for evaluation. It can also be helpful to jot down ideas on a board which can be seen by all brainstormers.
  • 78. 1D • Individual vs. Group Brainstorming • Brainstorming can either be carried out by individuals or groups: • Individual brainstorming tends to produce a wider range of ideas than group brainstorming, but tends not to develop the ideas as effectively, perhaps as individuals on their own run up against problems they cannot solve. Individuals are free to explore ideas in their own time without any fear of criticism, and without being dominated by other group members. • Group brainstorming develops ideas more deeply and effectively, as when difficulties in the development of an idea by one person are reached, another person's creativity and experience can be used to break them down. Group brainstorming tends to produce fewer ideas (as time is spent developing ideas in depth) and can lead to the suppression of creative but quiet people by loud and uncreative ones. • Individual and group brainstorming can be mixed, perhaps by defining a problem, and then letting team members initially come up with a wide range of possibly shallow solutions. These solutions could then be enhanced and developed by group brainstorming.
  • 79. 1D • Define Scope Of Team – Select team members and functions – Define roles and responsibilities – Identify external customer needs, expectations and requirements – Identify internal customer needs, expectations and requirements – Complete preliminary studies – Identify costs, timing and constraints – Identify documentation process and method – Develop investigation plan
  • 80. 1D • Team Organization – Cross-functional • Design Engineering (Typically the leader) • Quality Assurance • Purchasing • Manufacturing Engineering • Material Control • Sales/Marketing • Etc. – Participation appropriate for phase being conducted – Resources - Team defines ”Needs” • *Should* involve customer or subcontractor participation (not always feasible)
  • 81. 1D • Roles In A Team – Several roles need to be established for the team. These roles are: Leader, Champion, Record Keeper (Recorder), Participants and (if needed) Facilitator. • Leader-Group member who ensures the group performs its duties and responsibilities. Spokesperson, calls meetings, establishes meeting time/duration and sets/directs agenda. Day-to-day authority, responsible for overall coordination and assists the team in setting goals and objectives. • Record Keeper-Writes and publishes minutes. • Participants: – Respect each others ideas. – Keep an open mind. – Be receptive to consensus decision making. – Understand assignments and accept them willingly. • Champion-Guide, direct, motivate, train, coach, advocate to upper management.
  • 82. 1D • Inputs To Team – Field service reports – Problems and issues reported from Internal customers – Internal evaluations using surrogate customers – Road trips (e.g.: Struts) – Management comments and/or direction – Government requirements and/or regulations – Contract review – Input from higher system level or past QFD projects – Media commentary and analysis – Customer letters and suggestions – Things gone Right/Wrong reports – Dealer comments – Fleet operator comments
  • 83. 1D • Basic Team Rules – Team must develop their own ground rules • Once developed, everyone must live by them • Ground Rules are an aid to ”self-management” • Team can modify or enhance the rules as they continue to meet – Determine if there should be a meeting – Decide who should attend – Provide advance notices – Maintain meeting minutes or records – Establish ground rules – Provide and Follow an agenda – Evaluate meetings – Allow NO interruptions
  • 84. 1D • What s important ? – Form a Team – Core Team Structure – Team Preparation
  • 85. 1D-Case study • What criteria would you choose in selecting a team that should solve the problema of a tank that was produced in X factory, tested in X factory but when arrived at the beneficiary, it was looking like in the figure ?
  • 86. 1D-Case Study • Who should be the leader of the team ? Is this man a good leader ?
  • 87. 2D • Describe the Problem • Describe the problem in measurable terms. Specify the internal or external customer problem by describing it in specific terms. • Specify the internal / external customer problem by identifying in quantifiable terms the Who, What, When, Where, Why, How, How Many (5W2H) for the problem.
  • 88. 2D • Describe the Problem – Problem definition is the basis of problem solving. The definition is used during brainstorming sessions to identify root causes in step 2 and main (potential) causes in step 4. Potential causes are those most likely causes that appear on the surface to be the source of the problem. A potential cause may be the root cause but must be supported by evidence.
  • 89. 2D • Describe the Problem • Part of the problem solving process is to identify the root cause of the problem and understand why it existed in the first place. Only then can a permanent solution be chosen and implemented. to make certain the problem will never surface again. The root cause is the reason the problem exists. When it is corrected or removed from the system, the problem will disappear. It is important to improve our understanding of today's technology to make possible the planning required to achieve quality and productivity breakthroughs for tomorrow and into the future.
  • 90. 2D • Customer Complaints • Many problems arise from customer complaints. An internal customer complaint could involve one department complaining that they cannot use the output of another department. An external customer complaint could involve a customer complaining to a dealer that a transmission ”shifts funny”. • Frequently the wrong problem is solved and the customer complaint is not addressed. It is very important that the customer complaint be clearly understood. The only method to ensure this is to have direct customer contact.
  • 91. 2D • Customer Complaints • For internal customers, it is advisable to have representatives from the complaining organization as part of the problem solving team. In many cases this approach is the only way a problem can truly be solved. • External customer complaints typically require direct interviews to understand why the customer is not satisfied. It is not unusual for a customer complaint to be misrepresented by a company reporting system that classifies problems in prearranged standard categories.
  • 92. 2D • Operational Definition of the Problem • It is important that the problem be described in terms that have the same meaning to everyone. This is best achieved through an operational definition. • An operational definition consists of verifiable criteria that have the same meaning to the production workers, manager, customer, engineer, buyer, technician, team members, etc., and are used for past, present and future comparisons and analysis. • Sometimes problems are mistakenly described in terms of symptoms: – Machine is down due to electrical problem. No backup machine or alternative available. – The scrap rate has increased from from 3% to 22%. – Customer warranty claims on engine component is 12%. – Failure of durability tests of a transmission component at 50,000 miles will delay launch.
  • 93. 2D • Symptoms vs. Causes • It is not uncommon for problems to be reported as symptoms. More examples are: noise, won t work, no power, machine down, broken tool, head froze up, contaminated, rough surface, porosity, shortage of parts, rattles, quality problem, worn out, line stopped, not to specification, labour problem, management problem, too much variation, etc. • The problem solving team must use a systematic approach to define the real problem in as much detail as possible. A definition of the problem can best be developed using approaches that organize the facts to get a comparative analysis. These approaches do this by asking what is against what is not. Then they draw distinctions from this comparison, testing these against the problem definition and forming a statement or description of the problem which must be resolved.
  • 94. 2D • Problem Solving – Systematic approaches to problem solving: • Business as a System (Business as a Process) • Analytical problem solving • Process flow – Problem analysis methodologies: • 5W2H • Stratification • Comparative analysis • Similarity analysis
  • 95. 2D-5W2H Analysis • It is sometimes difficult to define the problem and sort out real differences. The first, most important step, however, it to determine that the customer complaint is fully understood. • 5W2H : – Who? Identity customers complaining – What? Identity the problem adequately and accurately – When? Timing - When did the problem start? – Where? Location - Where is it occurring? – Why? Identify known explanations – How? In what mode or situation did the problem occur? – How Many? Magnitude - Quantify the problem • To reduce the risk of making wrong decisions, consideration and analysis of potential problems in advance will provide contingency actions to maintain control and protect the customer.
  • 96. 2D-5W-2H Analysis – Who? - Identity individuals associated with the problem. Characterize customers who are complaining. Which operators are having difficulty? – What? - Describe the problem adequately. Does the severity of the problem vary? Are operational definitions clear (e.g. defects)? Is the measurement system repeatable and accurate? – When? - Identify the time the problem started and its prevalence in earlier time periods. Do all production shifts experience the same frequency of the problem? What time of year does the problem occur? – Where? - If a defect occurs on a part, where is the defect located? A location check sheet may help. What is the geographic distribution of customer complaints? – Why? - Any known explanation(s) contributing to the problem should be stated. – How? - In what mode or situation did the problem occur? What procedures were used? – How Many? - What is the extent of the problem? Is the process in statistical control?
  • 97. 2D-Stratification analysis • Stratification Analysis determines the extent of the problem for relevant factors. – Is the problem the same for all shifts? – Do all machines, spindles, fixtures have the same problem? – Do customers in various age groups or parts of the country have similar problems? • The important stratification factors will vary with each problem, but most problems will have several factors. Check sheets can be used to collect data.
  • 98. 2D-Stratification analysis • Stratification Analysis determines the extent of the problem for relevant factors. • Essentially this analysis seeks to develop a Pareto diagram for the important factors. The hope is that the extent of the problem will not be the same across all factors. The differences can then lead to identifying root cause. • When the 5W2H and Stratification Analysis are performed, it is important to consider a number of indicators. For example, a customer problem identified by warranty claims may also be reflected by various in-plant indicators. Sometimes, customer surveys may be able to define the problem more clearly. In some cases analysis of the problem can be expedited by correlating different problem indicators to identify the problem clearly.
  • 99. 2D-Describe the problem • It has been said that there are no new problems, only different manifestations of old problems. In problem definition, it is often useful to quantify the problem in similar situations. The criteria to match similar situations will vary with the type of problem. Identifying effective matches and evaluating the presence of the problem provides useful information to generate potential causes and possible problem solutions. If the similarity analysis identifies a comparable situation where the problem does not exist, the analysis can focus on the differences in where the problem is occurring and where it is not occurring. • Once the 3 types of analysis have been completed, it is sometimes possible to divide the problem into separate problems. It is easier to address these smaller problems because fewer root causes are involved. In the ideal case, a single root cause would be responsible for each problem. If the problem is separated, different teams may be required to address each problem. • All three elements of the problem definition are not used for every problem. However, collectively the different analyses provide a comprehensible description. You are developing a ”specification” of the problem.
  • 100. 2D-IS/Is not questions IS IS not What ? What is the object you have problems with ? What could be happening but is not ? Where ? Where is the problem in the product or service ? When ? At what step of the process you first saw the problem ? How big ? How much of the service or product is affected by the deffect ? How many products could have the defect but did not
  • 101. 2D-Describe the problem Questions • What Type of Problem Is It? – Field complaint – Quality improvement – Manufacturing improvement – Component design – Labour / Personnel – Supplier / Vendor – Cost improvement – Solution implementation – Cross functional – Research – Safety • Describe the Problem Questions • Other Questions – Can you list all of the resources and documents which might help you specify the problem more exactly? – Do you have more than 1 problem? Can this situation be separated into smaller parts? – Is / Is Not – Is there any evidence this problem surfaced before?
  • 102. 2D-Describe the problem in terms of 5W • Who, What, When, Where, Why, How, How Many – What is the extent of the problem? – Has the problem been increasing, decreasing or remaining constant? – Is the process stable? – What indicators are available to quantify the problem? – Can you determine the severity of the problem? Can you determine the various costs of the problem? Can you express the cost in percentages, dollars, pieces, etc.? – Do we have the physical evidence on the problem in hand? – Have all sources of problem indicators been identified and are they being utilized? – Have failed parts been analyzed in detail?
  • 103. 2D • What is important ? • Describe the Problem • 5 Why • Problem Statement • Affinity Diagram • Is / Is Not • Problem Description
  • 104. 2D-Case Study • A storage tank, designed for working at 2 bar input pressure, is modified by adding a nozzle in the input pipe, in order to make an uniform filling of the tank. After the change, the operation manager decided to speed up a little the process, groving the input pressure at 4 bar. Please define the event that may happen(0D) and its root causes.
  • 105. D2-5Why • 5 Why is a problem solving technique pioneered by Toyota Motor Corporation. The 5 Why concept is simple. If problem solvers ask the question “Why?” five times successively, the root cause will present itself by the 4th or 5th Why. Often, the 5th Why points directly at the management systems and practices allowing the problem to exist. • 5 Why is not a deductive brainstorming technique. The 5 Why process for RCA (Root Cause Analysis) requires that each Why be supported by data or facts. The process is a team activity, requiring members to work at each level with discipline to obtain supporting data. The known or collected facts from each Why lead to the next Why as the process continues, concluding when the root cause is found.
  • 106. D2-5Why • The Three-legged 5 Why is a technique used to follow three related paths. The purpose of the Three-legged 5 Why is to arrive at the root cause level, where energy has been expended incorrectly resulting in a failure chain. The failure chain ends at the symptom or effect experienced by the customer. The Three-legged 5 Why begins with a problem symptom and ends with three separate conclusions for improvement.
  • 107. D2-5Why • The Three Legs are: • Root Cause (Energy Misappropriation) • Barrier or Control (Quality Control) • Systemic Cause (Management)
  • 108. 2D-5Why • Findings from each leg can crossover between paths. The development of subsequent legs result in a more detailed explanation of where, when and how the problem occurred. Prevention of future problems are addressed in all three legs, with the following: • Avoidance of the specific root cause through SPC (Statistical Process Control and Process Capability) or Error / Mistake Proofing (Poka Yoke) • Poka Yoke of the process responsible for the problem • Establishment of Standard Work Practices to maintain consistency
  • 109. 2D-Case Study • Please give a Poka Yoke example taking into account a command pannel that could trigger a very unpleasant reaction if someone is coming inside and thinking just to ”play with the buttons”
  • 110. 3D • Implement and Verify Short-Term Corrective Actions • Define and implement those intermediate actions that will protect the customer from the problem until permanent corrective action is implemented. Verify with data the effectiveness of these actions.
  • 111. 3D • Implement and Verify - Interim (Containment) Actions – Define and Implement containment actions to isolate the effect of the problem from any internal / external customer until corrective action is implemented. – Verify the effectiveness of the containment action.
  • 112. 3D • Containment-Action objective – Define and Implement containment actions to isolate the effect of the problem from internal and external customers until corrective action is implemented. – Verify the effectiveness of the containment action(s).
  • 113. 3D • Containment actions-1 • The main objective of this part of the problem solving process is to isolate the effects of the problem by implementing containment actions. A problem may be poor quality, marginal product design, or a process or system that is unpredictable. A containment action may be stopping production of a known source of a problem, or not shipping any parts or assemblies until the source of the problem is identified.
  • 114. 3D • Containment actions-1 • Once a problem has been described, immediate actions are to be taken to isolate the problem from the customer. In many cases the customer must be notified of the problem. These actions are typically local fixes. • Common containment actions include: – 100% sorting of components – Cars inspected before shipment – Parts purchased from a supplier rather than manufactured in-house – Tooling changed more frequently – Single source
  • 115. 3D • Containment actions- 2 – Unfortunately, most containment actions will add significant cost ($) to the product. However, it is important to protect the customer from the problem until permanent corrective actions can be verified and implemented.Most interim actions are temporary short term actions taken until a permanent corrective action is defined, implemented and verified. The danger of many interim corrective actions is that they are considered to be a permanent solution to the problem. It must be remembered that they are typically ”band-aids”. It is a mistake to view containment actions as a solution to the problem. Containment actions typically address the effect. They should be considered ”immediate first-aid” to be reviewed and removed as quickly as possible.
  • 116. 3D • Containment actions-3 • Containment actions can and often should proceed in parallel with the root cause determination investigation. During the period in which containment actions are taking place, many useful things must be pursued as a first step in finding the root cause. These things include: – Establishing an investigative plan – Obtaining baseline data – Initiating an on-going control system – Developing a follow-up and communications system – Correcting products already produced – Start systematic investigations – Conduct special studies and statistical experiments – Understand the problem Review experiences and data with current trends – Forecast the future
  • 117. 3D-Case Study • A tank containing sulphuric acid was corroded and a spill is the result. The spill is small so the operation manager decided to weld a metal sheet over the spill hole. • Would this be an immediate corrective action ? Why ? What are the steps that must be followed before making the welding ? What are the immediate control steps ?
  • 118. 3D • Interim Containment Action • Verification of Effectiveness
  • 119. 4D • Define PRIMARY CAUSES THROUGH ROOT CAUSES ANALYSIS • Identify all potential causes which could explain why the problem occurred. Test each potential cause against the problem description and data. Identify alternative corrective actions to eliminate root cause.
  • 120. 4D • Identify all potential causes which could explain why the problem occurred. • Isolate and verify the root cause by testing each potential cause against the problem description and test data. Identify alternate corrective actions to eliminate root cause.
  • 121. 4D-Root cause of a failure
  • 122. 4D • Two Root Causes • Root Cause of Event (Occur or Occurrence) • What system allowed for the event to occur? • Root Cause of Escape • What system allowed for the event to escape without detection?
  • 123. 4D • Define and Verify Root Cause(s)-1 • An investigation into all identified potential causes is necessary for effective problem solving. A cause and effects diagram can be used to brainstorm all potential causes of the described problem. The team should decide on what C&E diagram(s) is to be used: 5M, Process Flow and/or stratification. The more detailed the C&E diagram, the higher the chances the root cause will be included on the C&E diagram. An effective C&E diagram will include input from all team members and will be discussed in detail.
  • 124. 4D • Define and Verify Root Cause(s)-1 • Any existing data should be reviewed for clues to potential causes. Further data collection may be required to investigate additional causes. • If the problem has not previously been seen, a timeline analysis should provide significant data. The timeline will identify events occurring about the time the problem developed. If enough documentation is available, potential causes can be further identified. For example, if a new operator was put on a process or if a new supplier began supplying parts. Investigation into the events occurring at the same time the problem was discovered could lead to several important potential causes. • ”What Changed?” ”When?” are important questions.
  • 125. 4D • Define and Verify Root Cause(s)-2 • A technique used extensively in analytical problem solving is a comparison analysis. This analysis looks at what is and what is not in the problem description. • Potential causes can be discovered by conducting a survey. By surveying the customer who has witnessed the problem, more potential causes can be highlighted. • Asking ”Why”repeatedly is effective in driving the process toward root cause and generating more complete understanding of the cause and effect.
  • 126. 4D • Define and Verify Root Cause(s)-3 • Once the problem has been described and the potential causes identified, the team should be evaluated. Are the right members on the team to investigate the potential causes? Are technical advisors required to assist in any special studies? Do new team members need to be added? Is the authority to pursue the analysis of the potential causes well defined? All these questions must be answered to ensure the team will be successful in investigating the potential causes and determining the root cause.
  • 127. 4D • Define and Verify Root Cause(s)-3 • The cause and effect diagram is used to identify the potential causes to be investigated. What is the probability that a potential cause could be responsible for the problem? Identify all potential causes that could have been present and may have caused the problem. • Once all potential causes have been agreed upon, choose several potential causes to investigate. If only one potential cause is investigated, a lot of time may be lost if that potential cause proves not to be the culprit. To expedite a solution, investigate several potential causes at the same time (Parallel actions on several potential causes).
  • 128. 4D • Define and Verify Root Cause(s)-4 • If the problem is a manufacturing process, begin to establish a stable process. Once the process is stable, definition of the potential cause will be clarified. • If design causes are identified, screening experiments may help identify the key variables which are affected by subsequent processes. Design changes may be appropriate. • Four or five potential causes should be identified to investigate. Identifying several potential causes forces the team to address multiple possibilities rather than searching endlessly for a single cause. An implicit part of problem analysis is investigating potential causes in parallel rather that in series.
  • 129. 4D • Six Steps Of Investigation – State how the potential cause could have resulted in the described problem. – Establish what type of data can most easily prove or disprove the potential cause. Develop a plan on how the study will be conducted. Identify the actions on an action plan. – Prepare the required materials to conduct the study. Training may also be required. – Collect the required data. – Analyze the data. Use simple statistical tools emphasizing graphical illustrations of the data. – State conclusions. Outline conclusions from the study. Does the data establish the potential cause as being the reason for the problem?
  • 130. 4D • Identify Alternate Solutions – Generate a Cause & Effects diagram. – Survey the customer. – Identify similar problem(s) previously solved. – Avoid implementing the interim actions for permanent actions /solutions. – Consider new and current technology for the solution. – Incorporate the solution into future products.
  • 131. 4D • Identify Potential Causes – Define the effects for cause and effect diagram(s). – Prepare a 5M, Process or Stratification cause & effects diagram for each effect (you may want to use a combination). – Team members should each assume their activity causes the problem and ask themselves :How could what I do possibly generate the problem? – Prepare a time line analysis if the problem was not always present. Identify what changed when. – Perform a comparison analysis to determine if the same or a similar problem existed in related products or processes. Identify past solutions and root causes which may be appropriate for the current problem. – Identify the top few potential causes. Develop a plan for investigating each cause and update the action plan. – Evaluate a potential cause against the problem description. Does a mechanism exist so that the potential cause could result in the problem?
  • 132. 4D • Analyze Potential Causes- Identify Root Cause • Analyze Potential Causes • Use the iterative process to analyze each potential cause. – Hypothesis generation: How does the potential cause result in the problem? – Design: What type of data can most easily prove/disprove the hypothesis? – Preparation: Obtain materials and prepare a check list. – Data Collection: Collect the data. – Analysis: Use simple, graphical methods to display data. – Interpretation: Is the hypothesis true? • Investigate several potential causes independently. • Use an action plan to manage the analysis process for each potential cause being studied. • Validate Root Causes • Clearly state root cause(s) and identify data which suggests a conclusion. • Verify root cause factors are present in the product and/or process. • Conduct with / without study to verify root cause. Can you generate the problem? • Analyze Potential Causes - Validate Root Cause
  • 133. 4D • Defining the five elements of production: – Objects of Production: Materials: Raw, Finished, Semi-finished, In-process – Agents of Production: People, Machines, Tools, Jigs, Machine Tools, Incidental Devices, Inspection Equipment, The Environment, etc. – Methods: Processing System, Load & Capacity Balance, Processing Conditions – Space: Left to Right, Front to Back, Top to Bottom – Time: Process Time, Production Time, Task Time
  • 134. 4D-4 process Phenomena
  • 135. 4D • Poka Yoke Devices, Systems & Inspection – Poka Yoke Systems • Control Systems • Halt the operations, and require feedback and action before process can resume. – Warning Systems • Uses signals to warn the operator that the operations needs feedback and action – SQC systems have fairly long periods of time between check stages and feedback execution
  • 136. 4D • Poka Yoke Devices – Are Built within the Process – In General Have Low Cost – Have the Capacity for 100% Inspection – Remember SQC is performed outside the process which adds cost and allows defects to escape the system.
  • 137. 4D-Systems for 0 defects ?
  • 138. 4D-Case Study • Please describe- in your opinion- a system with 0 defects.
  • 139. 4D • What is important ? • RCA (Root Cause Analysis) and Escape Point • Differences and Changes • Root Cause Theories • Verification • Process Flow Diagram • Escape Point
  • 140. 4D-RCA • RCA (Root Cause Analysis) is not a method or process itself, but a class of problem solving methods aimed at identifying the root cause of problems or events. RCA is any structured approach that identifies factors resulting in the problem outcome including symptoms, effects or consequences. • The practice of RCA is based in the belief that problems are permanently solved by addressing the root cause, rather than addressing obvious symptoms. Counter measures directed at the root cause are more likely to prevent problem reoccurrence.
  • 141. 4D-RCA • There may be several effective measures that address the root causes of a problem. Due to this fact, RCA is often performed iteratively and is frequently used as a continuous improvement tool. RCA is reactive, identifying events or causes, revealing problems and solving them. Analysis is done after a problem has occurred. FMEA (Failure Mode and Effects Analysis) is the usage of RCA to forecast or predict probability of events before they occur. RCA and FMEA are related and similar but separated by their place in the Product or Process life cycle. FMEA is used prior to product or process launch whereas RCA is used after.
  • 142. D4-RCA • The root cause of any problem is found at the point of creation. The root cause is never an operator error or a broken tool. The specifics of a root cause occur at the conversion of a product or service from one state to a new desired state. This conversion must be measurable and typically require proper energy usage. Examples of energy include, but are not limited to force, temperature or motion. The incorrect application of energy is the point at which the root cause can be found. The root cause can only be known if it can be turned on and off at will.
  • 143. D4-RCA • The RCA process is selected depending upon many factors such as culture and knowledge of problem solving tools. Quality-One has decades of experience in determining the proper tools and techniques for problem solving suited to your specific needs. Q-1 is the leader in Training and Facilitating the most effective RCA techniques available. We specialize in 8D (Eight Disciplines of Problem Solving), 5 Why and Six Sigma.
  • 144. 4D-RCA • User / Operator Safety-based RCA • Accident Analysis • Occupational Safety and Health • Production-based RCA • Quality Control • Manufacturing
  • 145. 4D-RCA • Process-based RCA • Business Processes • Failure-based RCA • Failure Analysis in Engineering and Maintenance • Systems-based RCA • Change Management • Risk Management • Systems Analysis
  • 146. 4D-Risk Based Inspection • Risk Based Inspection could establish through complex quantitative analysis the principal causes of the nonconformity. • RIB is an American based inspection method developed by API (American Petroleum Industry)
  • 147. 4D-Risk Based Inspection • An inspection strategy based on risk avoids the inadequacies of the traditional approach. The concept of risk takes into account, not only the probability of failure, but also the consequences of failure. These may encompass consequences in terms of lost profits, repair and re-justification costs, human casualties and environmental clean up costs. Such a strategy ensures that inspection effort is targeted appropriately to optimize costs and benefits, and provides an auditable demonstration that this has been done with due diligence.
  • 148. 4D-Risk Based Inspection • In some cases, initial turnaround inspection planning is based on qualitative risk ranking (QRR). Whereas, quantitative risk assessment attempts to perform a precise numerical evaluation of the risk exposure represented by equipment, qualitative risk-based inspection (RBI) planning provides a means of making a risk categorization. Therefore, qualitative RBI planning provides a useful methodology for correctly targeting inspection expenditure to components of the plant where it will be most effective in maximizing the safety of plant personnel and minimizing the cost exposure to failure.
  • 149. 4D-Risk Based Inspection • A qualitative RBI methodology presents, to an expert study team, each of the factors influencing the likelihood of equipment failure and each of the factors influencing the consequences of that failure in the event it were to occur. Based on the study team’s combined expertise, judgments are then made as to the magnitude of each factor, for each item, according to a pre-determined scheme. The result of such an assessment is an evaluation of risk category (or ranking) for each item, the severity of which then dictates the appropriate required effectiveness of the inspection response. • In cases where the assessment procedure for determining the magnitude of any of the factors influencing either likelihood or consequences of failure, replace expert judgment by numerical rules, the approach is termed ‘semi-quantitative’.
  • 150. 4D-Risk Based Inspection • Risk Based Inspection: – is a consequent development of traditional maintenance strategies that minimizes maintenance expenses, – belongs to the knowledge based methodologies focussing on safety and plant availability on demand by increasing on-stream time due to less turn-around time and a consequent reduction of unexpected failures, – is a systematic tool that helps users to make informed business decisions regarding inspection and maintenance expenses,
  • 151. 4D-Risk Based Inspection • Risk Based Inspection: – identifies “Weak Points” and “Bad Actors”, – enables evolution from a “Bandage Approach” to a sustaining reliability culture, – is a recognized way towards “Best In Class Performance” and “Operational Excellence”, – means fostering replacement strategy, – is measuring risk as a key performance indicator, – implies prioritization in maintenance efforts, – extends inspection intervals where local authorities recognize Risk Based Inspection (RBI), and – allows determination of external alternative inspection methods to avoid internal entry
  • 152. 4D-Risk Based Inspection • Obtainable effects: – Identification of Weak Points – Asset Policies – Replacement Strategy – Less internal inspections: – Increased Inspection Intervals – Alternative Inspection Methods – Up-front On-Line Inspections
  • 153. 4D-Risk Based Inspection
  • 154. 4D-Risk Based Inspection • Short description of methodology • Step 1:Define probability of failure • Failure probability rules have been developed such that data requirements are minimized as much as possible. Generally, data required can be obtained from P&ID and PFD drawings, piping and valve specifications, process mass balance data etc., with only minimal requirement to reference design drawings, piping isometrics etc. The principle is that such detailed data should only need to be reviewed for more detailed analysis if deemed appropriate following risk ranking using the standard easily applied rules. Major features include:
  • 155. 4D-Risk Based Inspection • Short description of methodology • Step 1:Define probability of failure – Two probabilities of failure are derived for pressure vessels and pipework, probabilities of failure due to internal damage and due to external damage. – Where appropriate failure probabilities are defined in terms of remaining life where the life is calculated according to an assessed or measured degradation rate, a life in service, and a degradation tolerance. – For damage mechanisms for which a remaining life is not appropriate, such as Stress Corrosion Cracking, a failure probability score is derived according to how the actual process conditions compare with permissible process conditions for the materials in question. – Failure probability rules address a wide variety of degradation mechanisms grouped under the following: • Wall thinning mechanisms e.g. Corrosion • Cracking mechanisms e.g. Stress Corrosion Cracking • Mechanical damage e.g. Fatigue • Metallurgical Damage e.g. Embrittlement
  • 156. 4D-Risk Based Inspection • Short description of methodology • Step 2:Define consequence of failure • Three categories of failure consequence are assessed. • Safety: toxic, fire, explosion, pressure and temperature hazards • Environment: pollution hazard to surrounding population or landscape • Business: instant and longer term effects on production
  • 157. 4D-Risk Based Inspection • Short description of methodology • Step 3:Define maintenance/inspection effectiveness • RBI/RBM rules allow for inspection effectiveness in apportioning confidence grades to each equipment item. In the first instance these grades are taken to be the same as the plant’s existing inspection grades. In effect the grading represents confidence in the current and future condition of an item, confidence is lowest if there is no inspection evidence and highest if there is lots of appropriate inspection evidence or well behaved degradation. Major features include: – For any given risk ranking, items graded high will be allocated longer inspection intervals than items graded low confidence. – Probabilities of detection are not used in the standard methodology but can be taken account of in Inspection Value Analyses.
  • 158. 4D-Risk Based Inspection • Short description of methodology • Step 4:Risk mitigation methodology • Inspection alone is not sufficient to mitigate risk, action arising out of inspection is also required. • Through use of Confidence Grading and remaining wall thickness measurements etc., allows for information on known condition of items and this is then used to influence ‘perceived’ risk. For example, a wall thickness measurement can be used to refine judgments on historical corrosion, this is refinement of perceived risk.
  • 159. 4D-Risk Based Inspection • Short description of methodology • Step 5:Fitness for purpose and remaining life evaluation • Within ESR Technology’s RBI/RBM methodology ‘fitness for purpose’ is represented by either remaining life or failure susceptibility. Remaining lives in the first instance are calculated according to assessed or measured corrosion rates, design corrosion allowances, time in service, and presence and condition of any protective coatings. In almost all instances such a basic remaining life can be extended through use of improved determination of corrosion allowance e.g. through more detailed application of design codes, finite element analysis etc, or through more in depth corrosion assessment, or through better corrosion rate trending from wall thickness measurements.
  • 160. 4D-Risk Based Inspection • Short description of methodology • Step 6:Inspection strategy • Inspection activities are assigned in terms of damage needing to be checked for as follows: – Wall thinning inspection. – Cracking inspection. – Mechanical damage inspection. – Metallurgical damage inspection. – Internal visual inspection (an activity intended to check for more than one type of damage category and assigned in instances of either low confidence and/or high risk).
  • 161. 4D-Risk Based Inspection • Short description of methodology • Inspection frequencies are assigned for each of the above activities as the soonest of two calculated dates as follows: – A frequency obtained from a lookup table according to risk rank and confidence grade (where the risk is defined by the overall failure consequences and the failure likelihood rank for the type of damage). – A percentage of the remaining life calculated for the type of damage, where the percentage is obtained from a look up table according to the derived overall failure consequence ranking.
  • 162. 4D-Risk Based Inspection • Short description of methodology • Cost and benefit analysis • Field experience reports that good quality and thorough RBI/RBM will result in more efficient inspection scheduling through which high risk items can be concentrated on using better inspection whilst inspection requirements are relaxed on lower risk items. ESR Technology has experience of calculating the impact of RBI/RBM programmes, the results can be dramatic. In practice the success of any cost benefit analysis depends very much on the data that can be obtained from the plant.
  • 163. 4D-Risk Based Inspection • Short description of methodology- PROBABILITY- CONSEQUENCE MATRIX
  • 164. 4D-Risk Based Inspection • Short description of methodology-Inspection schedule
  • 165. 4D-Risk Based Inspection • Short description of methodology- API RBI matrix
  • 166. 5D • Verify Corrective Actions • Confirm that the selected corrective actions will resolve the problem for the customer and will not cause undesirable side effects. Define other actions, if necessary, based on potential severity of problem.
  • 167. 5D • Choose, Verify and Implement CA objective: • Through pre-production test programs quantitatively confirm that the selected corrective actions will resolve the problem for the customer, and will not cause any undesirable side effects. • Define contingency actions, if necessary, based upon Risk Assessment.
  • 168. 5D • Choose, Implement & Verify Corrective Actions-1 – By far the most critical step in the problem-solving process is to verify that the solution will in fact eliminate the problem. In addition, it is often the most difficult step. The most common method to evaluate a problem solution is to wait for implementation of the solution, then see if the problem goes away. However, too much time may be lost before conclusive information is available. Verification, where ever possible, should come before implementation. – Several approaches to verification are available. In engineering, design verification and production validation testing provides significant information. In the short term, a bench/lab test can be used to verify. In some cases dynamometer testing can provide verification. Long term one can monitor fleet response. For manufacturing, verification is by in-plant indicators. SPC can verify the elimination of the problem. Sometimes scrap rate reports and conformance audits provide information. Sometimes a designed experiment is part of verification.
  • 169. 5D • Choose, Implement and Verify Corrective Actions-2 – Whatever verifications you choose, a detailed verification / action plan is required to outline who will be taking what actions by when. The action plan should show what data or statistics will be collected and analyzed, who is responsible and must track actual progress and scheduled completion. The action plan is the detailed Dynamic record of all phases of the problem solving process. – Good problem solution verifies the customer is satisfied with the solution. If possible, involve the customer in choosing solutions. – All verification of the problem solution will require decision analysis. Decision analysis is part of the cost and timing consideration of the solution. Decisions affecting cost must include effects on quality, future problem recurrence and complete elimination of the problem. In addition, management and operating procedures may be involved when choosing the solution. Evaluation of any adverse effects caused by the solution are important. The FMEA will most surely be affected.
  • 170. 5D • Choose, Verify and Implement Corrective Actions-3 – Run Pilot Tests – Artificially simulate the solution to allow actual process or field variation. – Field test the solution using pilot customer groups. – Verify carefully that another problem is not generated by the solution. – Monitor Results – Quantify changes in key indicators. – Stress the customer / user evaluation.
  • 171. 5D-Case Study • -Please define a Pilot Test in order to verify the reparation of a fractured distilation collumn or other equipment. The fracture was due to the fatigue of the material .
  • 172. 5D • What is important ? • Permanent Corrective Action • Acceptance Criteria • Risk Assessment / FMEA (Failure Mode and Effects Analysis) • Balanced Choice • Control Point Improvement • Verification of Effectiveness
  • 173. 5D-FMEA • FMEA (Failure Mode and Effects Analysis) is an analytical methodology used to ensure that potential problems have been considered and addressed throughout the product and process development cycle. Examples of common development cycles are APQP (Advanced Product Quality Planning), CPPD (Collaborative Product Process Design) and NPI (New Product Introduction). • A DFMEA (Design FMEA) is performed prior to the completion of the design of the product. A PFMEA (Process FMEA) is performed prior to the release of the design for the process. It is critical that a FMEA be performed with sufficient time to take counter measures against the risk and still capture the changes within the design before its release.
  • 174. 5D-FMEA • The primary reason for doing a FMEA is taking action to prevent a failure, improve design control through testing or evaluation, or process control through inspection. In a FMEA, risk is the substitute for failure. This risk is treated as if the failure had already occurred and corrective action is required. The reversal of this principle is the 8D (Eight Disciplines of Problem Solving). A FMEA is an 8D before an 8D is necessary.
  • 175. 5D-FMEA • The RPN (Risk Priority Number) is the product of Severity, Occurrence and Detection (RPN = S∗O∗D), and is often used to determine the relative risk of a FMEA line item. In the past, RPN has been used to determine when to take action. RPN should not be used this way. Actions are determined by Criticality. Criticality is the combination of Severity and Occurrence as displayed in the Criticality Matrix shown in the next slide.
  • 176. 5D-FMEA
  • 177. 5D-FMEA • How is a FMEA done ? • FMEA Development Methodology follows a Three Path Model. With the combination of pre-work documentation, evolving team structure and action closure, a FMEA becomes the road map for improvement in the design of products or processes. Severity for each Effect of Failure is defined in Path 1 by a core team; Occurrence is selected in Path 2 by an expanded team of SMEs (Subject Matter Experts); and Detection is chosen in Path 3 with testing or inspection personnel.
  • 178. D5-FMEA
  • 179. D5-FMEA
  • 180. 6D • Implement Permanent Corrective Actions(PCA) • Define and implement the permanent corrective actions needed. Choose on-going controls to insure the root cause is eliminated. Once in production, monitor the long-term effects and implement additional controls as necessary.
  • 181. 6D • IMPLEMENT PERMANENT CA OBJECTIVE – Define and implement the best permanent corrective actions. Choose on-going controls to ensure the root cause is eliminated. Once in production, monitor the long-term effects and implement contingency actions, if necessary. – Identify Alternative Solutions – Evaluate how other groups solved similar problems.
  • 182. 6D • IMPLEMENT PERMANENT CA OBJECTIVE – Use brainstorming to generate Alternate Solution C&E diagram. – Consider redesign of the part or process to eliminate the problem. – Anticipate failure of the solution. Develop contingency action(s). – Implement Solution – Use an action plan approach to implement the solution. – Test and verify contingency actions, if possible
  • 183. 6D • Implement PCA-1 • Define and implement the ”appropriate” corrective action(s). • Choose on-going controls to ensure the root cause is eliminated. • Once in production, monitor the long term effects and implement contingency actions (if necessary).
  • 184. 6D • Implement PCA-2 – Once the root cause(s) have been identified, the team establishes an action plan on the permanent actions to be taken. Again, the action plan includes who will do what by when. The permanent actions are implemented to solve the problem. The question ”Why did this occur?” must be answered. – Establish ongoing controls on the process to ensure the process remains in control. Once the permanent corrective actions are in place, the ongoing controls will verify the effects of the actions.
  • 185. 6D • Implement PCA-2 – To forecast reduction of the problem, indicators such as scrap reports, etc., can be used. A statistical plan will verify the effectiveness of the actions. A systematic approach involves a plan to establish the facts using data or evidence as a requirement for making decisions. Data is obtained by investigations and experiments to test assumptions. These assumptions are identified by translating the customer concerns into understandable definitions of what the problem is and relating these definitions of the problem to product and processes. These definitions and data are used to verify solutions.
  • 186. 6D • Implement PCA-3 – Once permanent solutions are in place, document the changes. In addition, all customers need to be informed about what actions were taken. In most cases, some type of training is required to institute permanent corrective actions. Training may be required to implement a product design or process change. In addition, implementation of the permanent actions may need to include the effect on design or process issues. In manufacturing, maintenance personnel often need to be informed of the changes.
  • 187. 6D • Implement PCA-3 – Another important part is to correct the obvious. This includes correcting defective parts already produced, changing product design, changing tooling, reworking defective machines and/or equipment, revising ineffective operating systems or working with and/or replacing suppliers. – Contingency actions should be identified if for some reason the permanent actions cannot be implemented. For example, in manufacturing a recommendation to single source a part may be recommended. But, if one vendor is unable to meet the increased productivity alternate action is necessary. Contingency actions based upon risk assessment are essential to the success of permanent corrective actions for customer protection and problem solution.
  • 188. 6D • CA Questions • Do the actions represent the best possible long- term solution from the customers viewpoint? • Do the actions make sense in relation to the cycle plan for the products? • Has an action plan been defined? – Have responsibilities been assigned? – Has timing been established? – Has required support been defined? – What indicators will be used to verify the outcome of the actions, both short-term and long-term?
  • 189. 6D-Case Study • Please describe the permanent corrective action you ll take if there are systemic errors on the products which were lathed. You should take into connsideration the eventual problems with the machine and the operator.
  • 190. 6D • What is important ? • Implement and Validate • Project Plan • Validation of Improvements
  • 191. 7D • Prevent Recurrence • Modify specifications, update training, review work flow, improve practices and procedures to prevent recurrence of this and all similar problems.
  • 192. 7D • Prevent Recurrence Objective • Modify those management systems, operating systems, practices and procedures to prevent recurrence of this problem and all similar problems. • Prepare a process flow diagram of the management / operating system that should have prevented the problem and all similar problems. • Make needed changes to the system. Address system follow-up responsibilities. • Standardize practices. • Use action plan to coordinate required actions.
  • 193. 7D • Prevent Recurrence-1 • Modify the management systems, operating systems, practices, and procedures to prevent recurrence of this and all similar problems.
  • 194. 7D • Prevent Recurrence-2 – This next step in the Problem-Solving Process is the seventh step. It is important to understand what in the process allowed the problem to occur. A cause-and-effect diagram can be used to outline the reasons the problem occurred. By asking ”Because?” the C&E diagram can be constructed. – Another effective tool is a process flow diagram. The process flow of the manufacturing or engineering process can be effective in identifying where in the process the problem could have been prevented. To prevent recurrence of the problem, most of the time a change to the management system will be required. Managers must understand why their system allowed a problem develop. The same system will allow future problems to occur.
  • 195. 7D • Prevent Recurrence-3 – Management systems, practices and procedures need to be fully understood to be effective. Most of them are carry-overs from previous model years and organized structures. Some are outdated and need to be revised. Understanding the elements of a management system can be achieved by maintaining an up-to-date flow diagram of the system and process. Also, there should be easy to follow instructions for those who are part of the system.
  • 196. 7D • Prevent Recurrence-3 – Management systems, practices and procedures should provide management support for ”Never ending improvement” in all areas and activities. The system should encourage individuals to participate freely in the problem solving process. It should help to understand more about their job and how each individuals effort affects the outcome of the final product on customer satisfaction. The system should encourage everyone to learn something new. And it should recognize individual and team effort when these new skills are applied.
  • 197. 7D • Prevent Recurrence-4 – Changes in the management system can require documenting new standard procedures, streamlining to remove obsolete procedures and revising previous standards. Changes in the management system need to be communicated clearly to all customers. – To prevent recurrence additional training is often required. Training may be needed in statistical techniques and methodologies, new engineering or manufacturing technologies or disciplines, better process and/or project management. – If concerns develop regarding changes to the system, these issues will be addressed. A new team may need to be assigned with the authority to address the management system.
  • 198. 7D • What is important ? • Prevention • Similar Products and Process Prevention • Systems Prevention • Standard Work or Practice • Procedures / Policy Updates
  • 199. 8D • Congratulate Your Team • Recognize the collective efforts of your team. Publicize your achievement. Share your knowledge and learning.
  • 200. 8D • The final step in a team oriented problem solving effort is to recognize the team s collective efforts in solving the problem and show gratitude by applauding individual contributions. Management will need to determine the best way to recognize the team s contribution to the origination. In addition, individual effort and talents need to be highlighted and rewarded. • Team oriented problem solving involves risk taking, some conflict, hard work and participation by everyone. It includes a free exchange of ideas,, individual talent, skill, experience and leadership. The team approach, when led effectively, produces a driving force of individuals motivated and committed to solving a specific problem.
  • 201. 8D • Closure and Team Celebration • Archive Documents • Team Lessons Learned • Before and After Comparison • Celebrate Successful Completion
  • 202. 8D and the Is/Is Not Approach • 8D is a counterintuitive approach to problem solving. As a problem is encountered, it is intuitive to try solutions to uncover what the root cause Is. 8D takes the opposite approach by removing possible causes that are not contributors. The Is Not approach limits the number of trial and error attempts at fixing the problem. 8D achieves this by defining the problem with increasing detail based on facts as they are available. • The problem description is the result of a scientific study of; what, where, when and how much. The method develops theories with collected facts after removing possible causes not agreeing with the problem description. These root cause theories are compared to the problem description prior to physical verification. Trial and error is not permitted in 8D.
  • 203. 8D and FMEA • FMEA is a tool used in the planning of product or process design. The Failure Modes in a FMEA are equivalent to the problem statement or description in an 8D. Causes in a FMEA are equivalent to potential causes in an 8D. Effects of failure in a FMEA are problem symptoms in an 8D. The relationships between 8D and FMEA are outlined below: • The problem statements and descriptions can be linked between both documents. An 8D can be completed faster by utilizing easy to locate, pre- brainstormed information from a FMEA to solve problems. • Possible causes in a FMEA can immediately be used to jump start 8D Fishbone or Ishikawa diagrams. Brainstorming information that is already known is not a good use of time or resources. • Data and brainstorming collected during an 8D can be placed into a FMEA for future planning of new product or process quality. This allows a FMEA to consider actual failures, occurring as failure modes and causes, becoming more effective and complete. • The design or process controls in a FMEA can be used in verifying the root cause and Permanent Corrective Action in an 8D
  • 204. 8D Final Flowchart

×