|
|
|
|
|
|
|
|
|
|
| 8D Problem Solving Report |
|
|
|
|
|
|
|
Issue Number |
|
(EX. 10-12-10-1600 =
YY-MM-DD-HH:MM)
This will be assigned by Oshkosh when loaded into sharepoint
0001 |
|
| D0 Problem Solving Summary Type |
|
| Select only one: |
Internal
|
0 |
Supplier |
0
|
|
|
|
|
|
|
|
|
|
|
|
| Header Information |
|
| Title of Defect: |
|
|
|
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
| Select a Summary Type - D0 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| D1 Problem Solving Team |
|
| Team Champion: |
We can learn of problems from many sources, including: internal metrics used to monitor the health of processes and the organization, feedback from customers and employees, and results of audits against standards and regulations. Use data, not emotions, to prioritize the order of problems to work on.
1) How was the problem identified?
2) Are “real” data available to confirm and diagnose the problem?
3) Is a team needed to tackle the problem or can one person handle the job working alone?
4) What is the level of urgency and impact of the problem?
The team champion should be an individual with sufficient authority and influence to:
1) Remove roadblocks for the team.
2) Drive progress and completion of the 8D.
3) Provide positive recognition to the team upon successful completion.
|
|
| Team Leader: |
The project team leader:
1) Takes ownership of the project.
2) Drives progress.
3) Manages team dynamics.
|
|
| Team: |
Who are the problem solving team members?
1) What is the role of each team member?
2) Have a Team Champion, Team Leader and SME (Subject Matter Expert) been identified?
3) Is the team cross-functional?
4) Are the appropriate stakeholders involved?
5) How are team activities documented and communicated?
|
|
| D2 Problem Description |
|
Describing the problem starts with a well-thought-out Problem Statement. The Problem Statement communicates the scope of the problem that the team is working on and gets the team focused. A complete Problem Statement also provides information relevant to the problem to help the team get started and clarify what is expected from the team. (Note: In actual use, the Second Discipline might precede the first. To be effective, the team must have the right mix of skills and relevant experience. Sometimes it is almost impossible to select and form an effective team until the scope of the problem is defined.) The IS-IS NOT tool is useful for developing accurate, useful Problem Descriptions.
1) Problem Description should include: What? Where? When? How many?
2) Has a Problem Statement been developed? Note: The Problem Statement communicates the nature of the problem to the team, focuses the team on the scope of the problem, provides data and information on what the problem is AND what it is not and lets the team know what they are expected to do.
3) Has the team identified what the problem is and what it is not? Knowing where the problem is not present is a critical piece of the problem description.
4) Do the expectations clarify the role the team should play (determine root causes and implement or recommend a solution), specify the deadline and include monetary limits for the team?
5) Does the Problem Statement communicate a problem to be studied or assign a task to be carried out?
A useful standard for problem descriptions is CREI:
1) Complaint - description of the problem.
2) Requirement - specific requirement that is being violated.
3) Evidence - objective evidence that the requirement is being violated.
4) Impact - significance of the problem based on cost, performance, etc.
|
|
|
|
|
|
| D3 Containment and Short Term Corrective Actions |
|
|
Containment means protecting the customer by ensuring that all suspect parts are identified and contained. Containment may include: sorting bad parts from good ones, quarantining parts, and setting up containment measures for parts in transit.
1) Have all areas of contamination been quarantined: Supplier Inventory, Supplier Work In Process, External Processing, In-Transit, Oshkosh Inventory, Oshkosh Work in Progress and at the Customer?
2) Are all suspect parts quarantined and clearly identified?
Containment Actions |
|
| List containment activities by area: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Additional Comments: |
|
|
|
| Completed By: |
|
Date: |
|
|
| Short term Corrective Action(s): |
|
Short term corrective action means that a “band-aid” is put in place to prevent the problem from impacting the customer or Oshkosh while a permanent solution is being developed and implemented. Short term corrective actions may include: sorting bad parts from good ones, adding operations or rework steps, using additional labor on the process, and additional inspection.
1) Has the short term corrective action been verified to work?
2) Has the impact of the short term corrective action been tested to ensure that additional problems are not created?
3) Are the actual additional costs of the short term corrective actions known and been verified that they are “worth” it?
For supplier issues, Containment Level 1 (CL1) is a very effective short term corrective action.
|
|
|
|
|
|
|
|
| Completed By: |
|
Date: |
|
|
| Pictures or Additional Documentation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| D4 Root Cause Analysis |
|
| Analysis method must be attached. Use of the HERCA worksheet is required if human error is the initial root cause identified. |
|
Defining the root causes is the core of the 8-D problem-solving process. This is normally the toughest aspect of the problem-solving process. Teams should make sure that they are not distracted by the problem symptoms, so that they can dig down to find the Process or Design Root Cause(s). The Process or Design Root Cause(s) is the cause that is a part of the process or design which led to the problem being investigated. Eliminating it will prevent recurrences of the same problem.
The team should always use a root cause analysis tool in this step (e.g.: The 5-Whys, Fishbone Analysis, HERCA, Fault Tree). The team should pick which tool(s) to use based on the problem they are trying to solve. For instance, on particularly confusing problems where the team does not even know where to start investigating the Fishbone Analysis tool can be extremely useful to help get the team started.
1) What techniques are used to discover the root causes? The completed method must be attached to the 8D. (e.g.: The 5-Whys, Fishbone Analysis, HERCA, Fault Tree)
2) Have you asked the Root Cause Question: “Do these causes explain all that is known about what the problem is, as well as all that is known about what the problem isn’t?” This is really a two part question: make sure the root causes found fit both the “is” and the “isn’t” sections of the question. If the causes being tested do not fit both, then they are probably not the root causes.
3) Have the root causes identified been verified? Verification may require a series of confirmation runs.
4) Is the root cause a process or design problem? Blaming human/operator error is not an acceptable or useful root cause. The root cause should indicate a problem with the design or process that can be addressed, not cast blame on a person or group.
5) If the team initially identifies human error as the root cause, use the Human Error Root Cause Analysis Worksheet (HERCA tab of this file). It will assist the team to dig deeper and identify the true Process/Design Root Cause.
If possible, the team should also identify the Systemic Root Cause(s) and the Detection Failure Cause(s). The Systemic Root Cause(s) is the underlying cause with the system that directly led to the Process or Design Root Cause(s). Eliminating it will prevent related failures.
The Detection Failure Cause(s) is the cause for why the problem was not detected. This is where the inspection process might be to blame.
|
|
|
|
|
|
|
| Completed By: |
|
Date: |
|
|
| D5 Long Term Corrective Actions |
|
The Long Term Corrective Actions should directly address the Process or Design Root Cause(s). When solutions are not obvious, often the root cause has not been found and the team should return to D4.
1) Does the solution directly address the root cause that has been identified?
2) Has the solution passed the tests of practicality, feasibility and cost-effectiveness?
3) Is the solution robust and capable of preventing a recurrence of the problem?
4) Does the ROI (return on investment) or the payback of the solution justify the cost of implementing the solution?
5) Can the solution be implemented within the required deadline?
The long term corrective action must:
1) Address the root cause.
2) Be specific and formally implemented (statements of intent are not acceptable).
3) Be auditable once complete.
|
|
|
|
|
|
|
A corrective action that includes error proofing (also called mistake proofing and poka-yoke) must change the process to prevent the problem from occurring again. Examples of error proofing:
1) Adding a feature to a weld or machining fixture so that the part cannot be placed in the fixture backwards.
2) Implementing barcode scanners to eliminate number entry errors.
3) Adding two-hand controls to a brake press so that the operators cannot accidentally place their hands in the press while it is operating.
4) Making a design change so that a part can only fit into its mating assembly in one orientation.
Do the Long Term Corrective Actions include error proofing? |
Yes |
No |
|
| Completed By: |
|
Date: |
|
|
| D6 Implementation and Verification of Long Term Corrective Actions |
|
Once the long term corrective action has been identified, objective evidence is required to prove that it has been implemented correctly and that it is effective.
Implementation:
The team needs to follow up on the corrective actions to ensure that they are implemented correctly:
1) Attach objective evidence of the corrective action to the 8D. This includes copies of updated documents, photos of fixed or updated fixtures, etc.
2) Go see! Review the updated process in action. Make sure that training has been performed where needed. If the corrective action involves the creation of new work instructions than make sure they are available and being used, if it involves the creation of a new fixture than make sure it is being used, etc.
3) Make sure that the implemented corrective action meets the team's expectations.
4) Review the new process for any unintended consequences.
5) Make sure that related documentation (control plan, DFMEA, PFMEA, etc.) is updated as well.
Verification:
It is critical that the team verifies that the long term corrective actions are effective at preventing re-occurrences of the problem. Objective evidence of effectiveness should be attached to the 8D. Verification can include activities such as:
1) Inspection of all parts for the defect for a length of time.
2) Testing the updated process against a number of operators who where not involved with the original problem.
3) Functional testing of units after implementing a design change.
|
|
|
|
|
|
| Have the FMEA and Control Plan been updated? |
Yes |
No |
|
| Completed By: |
|
Date: |
|
|
| D7 Preventive Actions |
|
The preventative actions section involves using the root causes or corrective actions from the 8D to prevent similar problems.
As a minimum, like parts and similar processes must be considered:
1) Are there similar parts that could have the same problem?
2) Do other processes have the same potential weakness?
3) Are there related designs that need to be reviewed?
To correct a problem with one part and not address all of the related parts that could have the same issue is unacceptable.
If possible, Systemic Corrective Actions should also be considered. The team should examine whether the Process or Design Root Cause(s) indicate that there is a significant Systemic Root Cause(s) that needs to be addressed. Examples could include:
1) Design errors that indicate the performance of inadequate design reviews.
2) Fixture problems that indicate inadequate control of fixtures.
3) Weld defects that indicate an under-qualified weld staff.
|
|
|
|
|
|
|
| Completed By: |
|
Date: |
|
|
| D8 Congratulate the Team and Wrap-up |
|
Once a team has completed implementing the solution and ensured that the solution works, all team members deserve to be congratulated. Team members need to know that their efforts are appreciated and that the organization knows about their accomplishments.
1) Has the team champion (or other leadership) recognized the team for their efforts in a timely manner?
2) Has the project team recognized those that have provided the team with support and assistance?
|
|
|
|
| Completed By: |
|
Date: |
|
|
| Additional Information or Comments |
|
|
|
|
|
|
|
|
|
| 8D Approved By: |
|
Date: |
|
|
Filetype Excel XLSX | Posted on 10 Aug 2022 | 3 years ago
