Eightd

8D Problem Solving Skill

CRITICAL REQUIREMENT: Complete All Phases

When generating an 8D report, you MUST include ALL nine phases (D0 through D8) in every response. Never truncate or omit phases. If the response would be long, still complete all phases — use concise language but include every discipline. A partial 8D report is invalid.

Mandatory phases checklist for every 8D report output:

• D0: Emergency Response Actions
• D1: Team Formation
• D2: Problem Description (with IS/IS NOT)
• D3: Interim Containment Actions + Escape Point
• D4: Root Cause Analysis (occurrence AND detection)
• D5: Permanent Corrective Actions
• D6: Implementation and Verification
• D7: Systemic Prevention
• D8: Team Recognition and Closure

CONDENSED FORMAT RULE: When generating an 8D report, write each phase in 3-6 bullet points maximum. Do NOT use elaborate multi-column tables — use simple prose or brief bullets. This keeps total length manageable so ALL phases D0–D8 are always included in a single response. Never stop writing before D8 is complete. If you are generating a long response and feel you are running out of space, shorten earlier phases to make room — but D8 MUST always be the final section written, fully completed. An 8D report that ends before D8 is a critical failure.

NO PLACEHOLDERS RULE: Every field must be populated with real, specific content derived from the user's input. Never output brackets like [PART NUMBER] or [TBD] — if information is missing, make a reasonable inference and note the assumption clearly (e.g., "Assumed: thread spec M12×1.75 based on typical application"). A template with empty fields is not an 8D report. The IS/IS NOT analysis in D2 must contain actual specific values for What, Where, When, and Extent — never leave cells empty, never use ⚠️ markers or "unknown" labels, never ask the user to fill in the data later. If a dimension or quantity is not stated, derive a plausible specific value from context and label it as assumed. A D2 section that withholds values pending more information is a failing response.

NEVER REQUEST INFORMATION BEFORE GENERATING RULE: When a user describes a problem or asks for an 8D report, you MUST immediately generate the full D0–D8 report using whatever information is provided. Do NOT ask clarifying questions first. Do NOT present a list of questions requesting the user to supply data before you begin. Use assumed/inferred values for any missing details and label them as assumptions. A response that asks "please provide the following information" instead of generating the 8D report is a critical failure. If the user provides even a brief problem description, that is sufficient to generate a complete 8D report.

D6–D8 TRUNCATION PREVENTION: These three phases are the most commonly truncated. As you write D5, actively monitor response length. If D5 is growing long, cut it short — D6, D7, and D8 are non-negotiable. After completing D5, you must write D6, then D7, then D8 in sequence. Do not stop. Do not summarise with "phases D6–D8 follow the standard template." Write each phase fully. The response is invalid if it ends before D8 closure text is written.

Overview

The 8D (Eight Disciplines) methodology is a team-based problem-solving process for identifying, correcting, and eliminating recurring problems. Originally developed by Ford Motor Company, it is now the automotive industry standard for customer complaint resolution and internal quality problem solving.

Skill Integration

8D Phase Overview

---

D0: Prepare for the 8D Process

Emergency Response Actions (ERA)

Before formal 8D begins, immediate actions to protect:

1. Customer Protection

• Identify all potentially affected product
• Stop shipment of suspect product
• Notify customer of situation
• Provide replacement/rework timeline

2. Symptom Assessment

• What is the symptom?
• When was it first detected?
• How much product is affected?
• Is this a safety/regulatory issue?

3. **8D Trigger Criteria

D0 Outputs

• Decision to proceed with 8D
• Initial ERA documented
• Urgency level assigned (24h / 72h / Standard)

---

D1: Establish the Team

Team Composition

Team Size

• Ideal: 4-7 members
• Minimum: 3 members
• Maximum: 10 members (larger teams slow progress)

D1 Outputs

• Team roster with roles and contact information
• Meeting schedule established
• Resources allocated
• Communication plan

---

D2: Describe the Problem

Problem Description Techniques

5W2H Analysis:

IS / IS NOT Analysis:

Problem Statement Format

Good problem statement:

"Outer diameter of part #12345 measures 25.08-25.12mm (spec: 25.00 ±0.05mm) on 147 parts from production lot 2026-01-15, discovered at customer receiving inspection."

Bad problem statement:

"Parts are out of spec" (too vague)

D2 Outputs

• Clear, quantified problem statement
• IS/IS NOT analysis completed
• All affected product identified and quantified
• Timeline of events established

---

D3: Interim Containment Actions (ICA)

Containment Scope

Containment Actions

1. Sort - 100% inspection to separate good/bad 2. Hold - Quarantine suspect product 3. Replace - Provide conforming product 4. Enhanced inspection - Temporary additional checks 5. Process change - Temporary parameter adjustment

Containment Verification

Before releasing containment:

• Verify containment is effective
• Track containment metrics (PPM before/after)
• Document all contained material
• Customer acceptance of containment

Escape Point Analysis

Critical Question: Where should this have been caught?

D3 Outputs

• All suspect material identified and quarantined
• Containment actions verified effective
• Customer notified of containment
• Escape point identified

---

D4: Root Cause Analysis

Root Cause Categories

Occurrence Root Cause: Why did the defect occur?

• Process, machine, material, method, environment

Detection Root Cause (Escape Point): Why wasn't it caught?

• Inspection method, frequency, capability, training

Root Cause Analysis Tools

5-Why Guidelines

Root Cause Verification

Verification Methods:

Root cause is verified when:

• Can reproduce defect by introducing cause
• Can eliminate defect by removing cause
• Explains all data (IS/IS NOT)
• Team consensus on verification

D4 Outputs

• Verified occurrence root cause(s)
• Verified detection root cause(s) (escape point)
• Root cause analysis documentation
• Evidence supporting root cause

---

D5: Develop Corrective Actions

⚠ WORD BUDGET: D5 content MUST NOT exceed 80 words total. Stop writing D5 immediately when you approach 80 words. D6, D7, and D8 MUST be written after D5 — they are more important than a complete D5. After writing D5, your very next characters must be "## D6".

Corrective Action Types

Corrective Action Hierarchy

Prefer higher-order controls:

Corrective Action Criteria

Each corrective action must be:

• Specific - Clear what will be done
• Measurable - Can verify implementation
• Assignable - Single owner responsible
• Realistic - Can be implemented
• Time-bound - Due date defined

Risk Assessment

Before implementing corrective actions:

• Will action introduce new risks?
• Update PFMEA with new information
• Validate action doesn't create new problems

D5 Outputs: Corrective actions with owners/dates, risk assessed, PFMEA and Control Plan updates identified.

---

⚠ MANDATORY CONTINUATION: You MUST now write D6, D7, and D8. Do not stop. Do not summarise. Write "## D6" as your next line.

---

D6: Implement and Verify Corrective Actions

⚠ MANDATORY SECTION — must appear in every 8D report output. Do not skip.

• Implement each PCA per owner and due date; confirm completion in writing
• Verify implementation (did we do it correctly?) then validate effectiveness (did it work?)
• Collect before/after data — control charts, PPM, Cpk — over 1–3 months
• Update WI, Control Plan, FMEA to reflect changes; retain records

D6 Outputs: Actions implemented, effectiveness data collected, documents updated.

---

D7: Prevent Recurrence

⚠ MANDATORY SECTION — must appear in every 8D report output. Do not skip.

• Update PFMEA: add new failure mode, revise S/O/D ratings, add new controls
• Update Control Plan: add/modify inspection steps and reaction plan
• Revise Work Instructions: embed process changes permanently
• Retrain operators and quality staff on changes
• Document Lessons Learned; deploy horizontally to similar parts/processes/suppliers

D7 Outputs: PFMEA updated, Control Plan updated, WI revised, training done, lessons learned filed, horizontal deployment complete.

---

D8: Recognise Team and Close

⚠ MANDATORY FINAL SECTION — the 8D report is NOT complete until D8 is written. If you have written D0 through D7, you MUST now write D8. Do not end the response before this section is fully written.

• Confirm all closure criteria met: root cause verified, PCAs implemented and effective, documents updated, training complete, customer satisfied
• Obtain customer acceptance of 8D closure (if customer complaint)
• Formally recognise team contribution — acknowledge individuals, share success with organisation
• Archive completed 8D report in quality records (minimum 3 years per IATF 16949)
• Close 8D number in tracking system

D8 Outputs: 8D report approved and archived, customer acceptance received, team recognised, report closed.

---

COMPLETION CHECK: If you have reached this line, you have completed all nine phases (D0–D8). The 8D report is now complete. Do not truncate any earlier phase to reach this point — shorten prose if needed but all nine phase headers must appear.

---

Templates

• templates/8d-report.md - Full 8D report template

Reference Materials

• reference/root-cause-tools.md - 5-Why, Fishbone, IS/IS NOT
• reference/verification-methods.md - How to verify root cause and effectiveness

MNMUK-Specific Guidelines

Response Timeframes

8D Numbering

Format: 8D-[YYYY]-[SEQ] Example: 8D-2026-001

Approval Authority

---

Quick Reference

# Generate 8D for customer complaint
"Create 8D for customer complaint: [describe problem]"

# Root cause analysis assistance
"Help me do 5-Why analysis for [problem]"
"Generate fishbone diagram for [defect type]"

# Corrective action development
"Recommend corrective actions for [root cause]"

# 8D review
"Review this 8D for completeness"

---

Workflow Routing

---

Examples

Example 1 — Full 8D for customer complaint:

"Create an 8D for customer complaint: supplier received 50 damper assemblies with incorrect gas charge pressure — 85 bar actual vs 110 bar spec. Customer is Multimatic, complaint received 2026-03-20."

Kai generates a complete D0–D8 report with ERA, team, IS/IS NOT analysis, containment actions, 5-Why root cause, corrective actions, and closure criteria — all in a single condensed response.

Example 2 — Root cause analysis only:

"Help me do a 5-Why analysis: CNC lathe produced 30 parts with OD oversize by 0.08mm — tool offset not applied after tool change."

Kai builds a 5-Why chain from the symptom down to the procedural/training root cause, then identifies both occurrence and detection root causes.

Example 3 — Corrective action development:

"Our 8D root cause is: no documented procedure requires the operator to verify tool offset after an unplanned tool change. Recommend corrective actions."

Kai provides a ranked corrective action hierarchy (eliminate → poka-yoke → procedure → training), with SMART criteria, owners, and FMEA/Control Plan update requirements.

8D Problem Solving - Extended Guidance

Deep-dive content for comprehensive 8D execution and facilitation.

---

Table of Contents

1. 8D Facilitation 2. Problem Description Excellence 3. Containment Best Practices 4. Root Cause Analysis Deep Dive 5. Corrective Action Development 6. Verification and Validation 7. Common 8D Failures 8. Customer-Specific Requirements

---

8D Facilitation

Team Dynamics

Effective 8D teams:

• Meet regularly (daily during containment, weekly during RCA)
• Have clear roles and accountability
• Document decisions and actions
• Escalate blockers promptly
• Stay focused on root cause, not blame

Team Leader Responsibilities:

• Schedule and facilitate meetings
• Track action items to closure
• Report status to management
• Maintain 8D documentation
• Ensure timeline compliance

Meeting Structure

D3 Containment Meeting (Daily until contained):

• Status of containment actions
• Quantity sorted/contained
• Customer communication
• Next 24-hour actions

D4/D5 Analysis Meeting (2-3x weekly):

• Review data and evidence
• Brainstorm and narrow causes
• Assign verification tasks
• Update timeline

Management Review (Weekly):

• Status summary
• Blockers requiring escalation
• Resource needs
• Customer status

Escalation Triggers

---

Problem Description Excellence

Common Problem Statement Failures

Quantification Requirements

Every problem statement must include:

• What: Specific defect/deviation
• How much: Measurement vs specification
• How many: Quantity affected
• Where found: Detection point
• When: Date/lot/shift

Data Collection for D2

Timeline Construction

Build a detailed timeline: 1. When was material produced? 2. When did process change (if any)? 3. When was defect first produced? 4. When was defect first detected? 5. When was customer notified? 6. When did we detect in-house?

Gap between 3 and 4/5 indicates escape point.

---

Containment Best Practices

Containment Planning

Containment Verification

Before releasing containment:

1. Verify sort effectiveness:

• Re-inspect sample of "good" product
• Track PPM through containment period
• Customer feedback on contained lots

2. Verify no new defects:

• Enhanced inspection catching nothing
• Process stable on control charts
• Customer reports no new issues

3. Transition criteria:

• Permanent corrective action implemented
• Effectiveness verified for [X] lots/days
• Customer approval (if required)

Customer Notification

---

Root Cause Analysis Deep Dive

Cause Categories (6M)

5-Why Discipline

Rules for effective 5-Why:

1. Stay factual - Each "because" must be verifiable 2. Stay in control - Focus on factors you can influence 3. Don't jump - Don't skip logical steps 4. Branch when needed - Multiple causes are OK 5. Stop at actionable - Root cause suggests a fix

Example (Good):

Problem: OD out of spec (25.08mm vs 25.00 ±0.03mm)
Why? → Dimension drifted during production run
Why? → Tool wear not compensated
Why? → Operator didn't check wear offset
Why? → No procedure requires checking wear offset
Why? → Procedure never updated after new tooling installed
Root Cause: Procedure gap for tool wear monitoring

Example (Bad - Jumping):

Problem: OD out of spec
Why? → Operator error
(Stops too early, blames without evidence)

Verification Techniques

When Root Cause Is Elusive

If root cause not found after reasonable effort:

1. Review IS/IS NOT - Did we miss a distinction? 2. Gather more data - More samples, longer timeframe 3. Bring in expertise - Supplier, equipment OEM, metallurgist 4. Consider intermittent causes - Environmental, batch-to-batch 5. Accept multiple causes - May be combination

Document if root cause is "most probable" rather than "verified."

---

Corrective Action Development

Action Selection Matrix

Avoiding Weak Corrective Actions

FMEA/Control Plan Updates

Every 8D should update:

1. PFMEA:

• Add failure mode if new
• Update Occurrence based on actual frequency
• Update Detection based on escape analysis
• Add new controls

2. Control Plan:

• Add inspection if detection gap
• Update frequency if needed
• Update reaction plan

3. Work Instructions:

• Incorporate process changes
• Add visual aids
• Update training materials

---

Verification and Validation

Implementation Verification

Effectiveness Validation

Short-term (1-4 weeks):

• No recurrence of defect
• Process in control
• Customer accepts initial lots

Medium-term (1-3 months):

• Sustained zero defects
• Capability improved (if applicable)
• No customer complaints

Long-term (3-12 months):

• No recurrence over extended period
• Validated through audit
• Lessons applied to similar processes

Validation Metrics

---

Common 8D Failures

Why 8Ds Fail

8D Quality Audit

Review completed 8Ds for:

Red Flags in 8D Review

• Root cause found in one day (probably not verified)
• Only corrective action is "training" or "inspection"
• No FMEA/Control Plan updates
• Closed before effectiveness period complete
• Different defect code used to avoid tracking

---

Customer-Specific Requirements

Common Customer Formats

Customer Portal Submissions

• Meet timeline requirements
• Use customer terminology
• Attach evidence
• Respond to questions promptly
• Close only when customer approves

Regulatory Complaints

For safety/regulatory issues:

• Expedited timeline (24-hour containment)
• Engineering sign-off required
• May require field action
• Retain all evidence
• Involve legal if needed

---

8D Metrics and Tracking

KPIs for 8D Programme

8D Trend Analysis

Review 8D database for:

• Common failure modes
• Repeat issues by part family
• Process areas with most issues
• Supplier-related issues
• Effectiveness of corrective actions

---

Training Requirements

8D Team Members

• 8D methodology training
• Root cause analysis tools
• Problem-solving techniques
• Customer format requirements

Quality Engineers

All above plus:

• Advanced statistical analysis
• FMEA/Control Plan linkage
• Customer portal systems
• Audit and review techniques

Recommended Training Time

Root Cause Analysis Tools Reference

Overview

Root cause analysis requires structured approaches to move from symptoms to true causes. This reference covers the primary tools used in 8D problem solving.

---

5-Why Analysis

Purpose

Drill down from symptom to root cause by repeatedly asking "why" until the fundamental cause is reached.

When to Use

• Simple, linear cause-effect chains
• Single failure modes
• Quick initial analysis
• When cause relationships are clear

How to Conduct

1. State the problem clearly 2. Ask "Why did this happen?" 3. Answer with a verifiable fact 4. Repeat until root cause is reached (typically 3-7 levels) 5. Verify each level

5-Why Guidelines

Example: Dimension Out of Spec

Problem: Shaft OD measures 25.08mm (spec: 25.00 ±0.03mm)

Why 1: Why is the OD oversize?
→ Because the tool cut undersize, leaving extra material

Why 2: Why did the tool cut undersize?
→ Because tool wear offset wasn't updated

Why 3: Why wasn't the offset updated?
→ Because the operator didn't check wear during the run

Why 4: Why didn't the operator check wear?
→ Because the work instruction doesn't specify when to check

Why 5: Why doesn't the WI specify this?
→ Because it was never updated after tooling change last month

ROOT CAUSE: Work instruction gap - no defined wear check interval

Common 5-Why Mistakes

---

Fishbone Diagram (Ishikawa / Cause-and-Effect)

Purpose

Brainstorm all potential causes in a structured format before narrowing down.

When to Use

• Complex problems with multiple potential causes
• Team brainstorming sessions
• When root cause is unclear
• To ensure all categories are considered

Structure (6M Categories)

                                    ┌─────────────────┐
                                    │    PROBLEM      │
                                    │   STATEMENT     │
                                    └────────┬────────┘
                                             │
        ┌────────────────┬───────────────────┼───────────────────┬────────────────┐
        │                │                   │                   │                │
   ┌────┴────┐      ┌────┴────┐         ┌────┴────┐         ┌────┴────┐      ┌────┴────┐
   │   MAN   │      │ MACHINE │         │MATERIAL │         │ METHOD  │      │MEASURE │
   └─────────┘      └─────────┘         └─────────┘         └─────────┘      └─────────┘
        │                │                   │                   │                │
   - Training      - Maintenance       - Specification      - Procedure     - Calibration
   - Experience    - Capability        - Lot variation      - Sequence      - Resolution
   - Fatigue       - Settings          - Storage            - Setup         - Method
   - Attention     - Wear              - Contamination      - Handling      - Repeatability

                                    ┌─────────────────┐
                                    │   ENVIRONMENT   │
                                    │ (Mother Nature) │
                                    └─────────────────┘
                                             │
                                   - Temperature
                                   - Humidity
                                   - Vibration
                                   - Cleanliness

6M Categories Explained

Fishbone Construction Steps

1. Write problem statement at fish head (right) 2. Draw main spine and category branches 3. Brainstorm causes under each category 4. Add sub-causes branching from main causes 5. Circle likely causes for investigation 6. Verify circled causes with data

Example: Surface Finish Defect

                                    ┌─────────────────┐
                                    │ Surface finish  │
                                    │ Ra >3.2 μm      │
                                    └────────┬────────┘
                                             │
   MAN                MACHINE            MATERIAL            METHOD
   - New operator     - Spindle wear     - Material hardness - Feed rate too high
   - Training gap     - Vibration        - Bar stock finish  - Wrong insert
   - Fatigue          - Coolant flow     - Heat treat var.   - Depth of cut
                      - Insert wear ●    - Contamination     - Speed setting ●

   MEASUREMENT         ENVIRONMENT
   - Ra gage error     - Temperature
   - Surface std       - Coolant temp
   - Inspection freq   - Chips buildup ●

   ● = Likely causes to investigate

---

IS / IS NOT Analysis

Purpose

Define problem boundaries precisely by comparing what the problem IS versus what it IS NOT (but could be).

When to Use

• Complex problems with unclear scope
• When similar items are not affected
• To narrow down potential causes
• D2 problem definition

IS / IS NOT Template

Example: Thread Damage

Distinctions point to: Handling at customer, assembly process, intermittent occurrence

---

Comparative Analysis

Purpose

Identify differences between good and bad items or conditions.

When to Use

• When identical parts have different results
• When problem is intermittent
• When process seems unchanged
• To isolate variables

Comparison Factors

Example

Conclusion: Material lot change correlates with defect

---

Fault Tree Analysis (FTA)

Purpose

Systematic top-down analysis of all failure paths for complex systems.

When to Use

• Complex failure modes
• Safety-critical analysis
• Multiple potential failure paths
• System-level problems

Symbols

Example: Machine Stop

                    ┌─────────────────┐
                    │  Machine Stop   │
                    │    (TOP)        │
                    └────────┬────────┘
                             │
                          ┌──┴──┐
                          │ OR  │
                          └──┬──┘
              ┌──────────────┼──────────────┐
              │              │              │
       ┌──────┴──────┐ ┌─────┴─────┐ ┌──────┴──────┐
       │ Power Loss  │ │  Alarm    │ │ Mechanical  │
       └──────┬──────┘ └─────┬─────┘ └──────┬──────┘
              │              │              │
           ┌──┴──┐        ┌──┴──┐        ┌──┴──┐
           │ OR  │        │ OR  │        │ OR  │
           └──┬──┘        └──┬──┘        └──┬──┘
              │              │              │
        ┌─────┼─────┐   ┌────┼────┐   ┌────┼────┐
        │     │     │   │    │    │   │    │    │
        ○     ○     ○   ○    ○    ○   ○    ○    ○
      Mains Breaker UPS Tool Temp Part Way  Ball Lube
      fail  trip  fail  wear alarm jam  screw fail
                                      wear

---

Timeline Analysis

Purpose

Map sequence of events to identify when problem started and what changed.

When to Use

• Process-related problems
• When "something changed"
• To correlate events with defect onset
• Investigation of complex sequences

Timeline Format

Date/Time    Event                                    Significance
─────────────────────────────────────────────────────────────────────
Jan 10       Last known good production               Baseline
Jan 11       New material lot received                Potential change
Jan 12 AM    Maintenance replaced spindle bearing    Potential change
Jan 12 PM    First defect detected                   Problem start
Jan 13       Defect continues at 5% rate             Confirms pattern
Jan 14       Containment initiated                   Response

Questions for Timeline

1. When was last known good? 2. What changed between good and bad? 3. When was defect first produced (not detected)? 4. Is there a pattern (shift, day, batch)? 5. Did anything else change at that time?

---

Tool Selection Guide

---

Combining Tools

Typical analysis flow:

1. Timeline - Establish sequence of events 2. IS/IS NOT - Define problem boundaries 3. Fishbone - Brainstorm all potential causes 4. Comparative - Compare good vs bad 5. 5-Why - Drill down on likely causes 6. Verify - Reproduce or eliminate to confirm

---

Verification Summary

Always prefer reproduction or elimination verification when possible.

Verification Methods Reference

Overview

Verification is critical in 8D problem solving. This reference covers methods for verifying root cause and validating corrective action effectiveness.

---

Root Cause Verification

Why Verify Root Cause?

Verification Hierarchy

---

Reproduction Verification

Principle

If the identified cause truly creates the defect, deliberately applying that cause should reproduce the defect.

Steps

1. Control the test environment - Same equipment, material, conditions 2. Apply the suspected cause - Deliberately introduce the condition 3. Observe the result - Does the same defect occur? 4. Repeat - Confirm reproducibility (3+ times)

Example

Problem: Dimension out of spec (25.08mm vs 25.00 ±0.03mm)

Suspected cause: Operator bypassed wear offset update

Reproduction test: 1. Set machine to known good condition 2. Run 50 parts with proper offset updates → All good 3. Deliberately skip offset update for 20 parts → 8 parts out of spec 4. Defect matches original (oversize OD)

Conclusion: Root cause verified by reproduction

When Reproduction Is Not Possible

---

Elimination Verification

Principle

If the identified cause is removed or corrected, the defect should stop occurring.

Steps

1. Implement temporary fix - Address only the suspected cause 2. Monitor results - Track defect occurrence 3. Compare before/after - Statistical comparison 4. Confirm no other changes - Isolate the variable

Example

Problem: Surface finish out of spec (Ra 4.2 vs max 3.2)

Suspected cause: Coolant concentration too low (2% vs spec 5%)

Elimination test: 1. Day 1-3: Continue at 2% coolant → 15% defect rate 2. Day 4: Adjust coolant to 5% 3. Day 5-7: Monitor at 5% → 0% defect rate 4. No other changes made

Conclusion: Root cause verified by elimination

Confirmation Period

---

Statistical Correlation

Principle

Data analysis shows statistically significant relationship between cause and effect.

Methods

Example: Correlation Analysis

Problem: Intermittent dimensional variation

Data collected: 200 parts with material hardness and dimension

Analysis:

• Correlation coefficient: r = 0.87
• P-value: <0.001
• Relationship: Higher hardness → larger dimension

Conclusion: Statistically significant relationship supports material hardness as contributing factor

Caution

Correlation ≠ Causation

Always combine statistical analysis with physical understanding of the mechanism.

---

Physical Evidence Verification

Principle

Forensic analysis of failed parts confirms the failure mechanism matches the suspected cause.

Analysis Types

Example

Problem: Shaft fracture in service

Suspected cause: Fatigue from stress concentration at fillet

Physical evidence: 1. Beach marks visible on fracture surface (fatigue indicator) 2. Fracture origin at fillet radius 3. Fillet radius measured 0.2mm vs spec 0.5mm minimum 4. Stress analysis confirms fillet is highest stress location

Conclusion: Physical evidence confirms fatigue failure initiated at undersized fillet

---

Verification Documentation

Required Elements

Verification Record Template

ROOT CAUSE VERIFICATION RECORD

8D Number: ____________
Root Cause: ____________________________________________

Verification Method: [ ] Reproduction [ ] Elimination [ ] Correlation [ ] Physical

Test Description:
__________________________________________________________________
__________________________________________________________________

Test Conditions:
__________________________________________________________________

Results:
__________________________________________________________________
__________________________________________________________________

Conclusion: [ ] Verified [ ] Not Verified [ ] Partially Verified

If partially verified, additional investigation needed:
__________________________________________________________________

Verified by: _____________ Date: _____________
Approved by: _____________ Date: _____________

---

Corrective Action Effectiveness Validation

Verification vs Validation

---

Implementation Verification

What to Verify

Verification Checklist

• [ ] Change documented in appropriate system
• [ ] Affected personnel trained
• [ ] Change implemented per plan
• [ ] Settings/configurations confirmed
• [ ] Visual confirmation (photos if applicable)
• [ ] First article/trial run acceptable

---

Effectiveness Validation

Validation Criteria

Validation Timeline

Validation Methods

---

Validation Data Collection

Sample Size Guidelines

Statistical Comparison

For before/after defect rate comparison:

1. Collect baseline data (before corrective action) 2. Collect validation data (after corrective action) 3. Statistical test - Chi-square or proportion test 4. Confirm significance - P-value <0.05

Example Validation

Problem: Defect rate 2.5%

Corrective action: Process parameter change

Validation:

Statistical test: Chi-square p-value < 0.001

Conclusion: Statistically significant improvement validates effectiveness

---

Closure Criteria

Standard Closure Criteria

• [ ] Root cause verified by reproduction or elimination
• [ ] All corrective actions implemented
• [ ] Implementation verified
• [ ] Effectiveness validated for minimum period
• [ ] No defect recurrence during validation period
• [ ] FMEA/Control Plan updated
• [ ] Customer accepts closure (if applicable)

Validation Period by Severity

---

Failed Validation

If Validation Fails

1. Don't close the 8D - Return to analysis 2. Review root cause - Was it correct? 3. Review corrective actions - Were they adequate? 4. Check implementation - Properly executed? 5. Investigate new factors - What changed?

Escalation

If repeated validation failures:

• Escalate to management
• Consider external expertise
• Review fundamental approach
• Increase team resources

---

Documentation Requirements

Validation Record

CORRECTIVE ACTION EFFECTIVENESS VALIDATION

8D Number: ____________
Corrective Action: ________________________________________

Validation Method: _________________________________________

Validation Period: From ____________ to ____________

Metrics:
| Metric | Before | After | Target | Result |
|--------|--------|-------|--------|--------|
|        |        |       |        |        |
|        |        |       |        |        |

Statistical Analysis (if applicable):
__________________________________________________________________

Conclusion: [ ] Effective [ ] Not Effective

If not effective, next steps:
__________________________________________________________________

Validated by: _____________ Date: _____________
Approved by: _____________ Date: _____________

Retention

Keep verification and validation records:

• Attached to 8D report
• Minimum 3 years
• Per customer requirements
• Accessible for audits

8D Problem Solving Report

Report Information

---

Customer Information

---

D0: Prepare / Emergency Response

Problem Summary

Emergency Response Actions (ERA)

8D Required?

• [ ] Yes - Proceed to D1
• [ ] No - Reason: ____________________

---

D1: Establish Team

Team Roster

Meeting Schedule

---

D2: Describe the Problem

5W2H Analysis

IS / IS NOT Analysis

Problem Statement

[Write clear, quantified problem statement here]

Supporting Data

• [ ] Photos attached
• [ ] Measurement data attached
• [ ] Process data attached
• [ ] Customer feedback attached

---

D3: Interim Containment Actions (ICA)

Suspect Product Identification

Containment Actions

Containment Verification

Escape Point Analysis

Where should this defect have been detected?

Escape Point Conclusion:

---

D4: Root Cause Analysis

Potential Causes (Brainstorm)

Man: -

Machine: -

Material: -

Method: -

Measurement: -

Mother Nature (Environment): -

5-Why Analysis (Occurrence)

Problem:

Occurrence Root Cause:

5-Why Analysis (Escape/Detection)

Problem: Why wasn't the defect detected?

Detection Root Cause:

Root Cause Verification

Verification Evidence:

---

D5: Permanent Corrective Actions (PCA)

Occurrence Corrective Actions

Detection Corrective Actions

Risk Assessment

---

D6: Implement and Verify

Implementation Status

Documentation Updates

Effectiveness Validation

Validation Period: From __________ to __________

Validation Result: [ ] Effective [ ] Not Effective (return to D4)

---

D7: Prevent Recurrence

Systemic Actions

Horizontal Deployment

---

D8: Congratulate Team and Close

Closure Checklist

• [ ] Root cause verified
• [ ] All corrective actions implemented
• [ ] Effectiveness validated (no recurrence for _____ days/lots)
• [ ] PFMEA updated
• [ ] Control Plan updated
• [ ] Work instructions updated
• [ ] Training completed
• [ ] Customer accepts closure (if applicable)
• [ ] Lessons learned documented
• [ ] Horizontal deployment completed

Team Recognition

Team contributions acknowledged: [ ] Yes [ ] No

Lessons Learned

---

Approvals

---

Attachments

• [ ] Photos/Images
• [ ] Measurement data
• [ ] Process data
• [ ] Fishbone diagram
• [ ] Updated PFMEA
• [ ] Updated Control Plan
• [ ] Training records
• [ ] Customer correspondence

---

Revision History