iSixSigma

about 8D problem solving methodology

Six Sigma – iSixSigma Forums Old Forums General about 8D problem solving methodology

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #42803

    Abdelhamid
    Participant

    Hi,
    I am in the process of preparing an internal  training on 8D methodology for problem solving. This method was developped in 1987 by Ford Corporate.  I have checked out various resources on internet and did found few articles but book dedicated to the subject. I will appreciate your feed-back. Is the 8D method protected by an IP or  rights from Ford ???
    All views & suggestions are welcome.
    Best Regards,
    Abdelhamid.

    0
    #135329

    Chicagoan
    Participant

    Abdelhamid,
    Ford’s 8D (Eight Disciplines) problem solving methodology works great. 8D steps and template format may be protected under IP. However I’ve seen other formats like 6-step problem solving templates which skipped thanking team (D8) and combined “Chosen Permanent Corrective Actions (D5) and Implemented Corrective Actions (D6)” as one step.
    Bottom line, although 8D provides a structured approach, as long as you cover all the steps in the training, IMO, 8D template format doesn’t matter. Be sure to cover the “Occurence” and “Escape” aspects of the issue you are trying to solve.
    -C

    0
    #135332

    Ivan
    Participant

    Can you explain “occurance” & “escape” aspects in G8D ?
    Thanks.
    Ivan.

    0
    #135352

    equinox
    Participant

    8D is only successful when carried out with the ‘Is-Is Not’ – Test Matrix – Prevention Worksheet -Decision Making Calculations and risk assessment …
    The 8D process has watered down since 1987 and it is rare to see a well executed 8D these days .. Good Luck
    Equinox.

    0
    #135396

    Chicagoan
    Participant

    Ivan,
    For most process related issues, root cause analysis should focus on two aspects i.e occurence and escape. In a G8D, process for (D4) Root Cuase analysis, find out the reasons that caused the issue to happen in first place. This addresses occurence aspect.
    For escape: Figure out the reasons why the issue was not detected after it happened, why/how it escaped the system.
    For example, a potential occurence issue might be tool wear causing chatter. Escape might be a by-passed surface finish verification sensor.
    Hope this helps.
    -C

    0
Viewing 5 posts - 1 through 5 (of 5 total)

The forum ‘General’ is closed to new topics and replies.