I have been searching to see if there have been any changes to the 8Ds. Recently a customer of ours asked us to add an "Escape Path" to the Root Cause and Corrective Action section when doing an 8D for them. Thats why we were wondering if the 8Ds have been modified to add this "Escape Path".
If they have been by who or what society?

Your help would be greatly appreciated.
Mystified in Massachusettes
(I couldn't think of anything to rhyme with Cambridge)

8-D was developed for Ford by a guy named Dean (I believe). We use 8-D extensively throughout the corp, and I'm not aware of any changes to the methodology. I have heard of an 8-D team determining root cause to a problem, and the corrective action reguired was not "to a degree appropriate to the magnitude of the problem." They closed out the 8-D without implementation, because the CA costs weren't commensurate with the risk. Maybe this is the 'escape' path that was mentioned?

Hi, I am new to this website. But to answer the question about Escape Point. I am the Quality Technician/8D Coordinator at our facility.

In 1998 Ford redesigned their current 8D system to Global 8D.

With this new Global 8D in D4 Root Cause now includes Escape Point. Escape Point is where in the process the defect should have been first detected but was not.

From personal experience, I do not include the Escape Point on the 8D. I do, however, include it on an action plan and correct the Escape Point through the action plan.

Only one customer requires that the Escape Point be listed on the 8D.

The Global 8D does not address corrective action for the Escape Point until you reach D6 Implemented Permanent Corrective Action and Escape Point.

If you have any other questions please contact me.

Brenda,

First, welcome to the Cove! Marc did a nice job in creating a place for Quality discussions and exchanges. Thanks also for your input here as it essential to the success of this site. See you around the Cove!

Regards,

Kevin

Visteon uses the "east/west" 8D format. This format includes Occurrence and Escape. Both require root cause, corrective action and prevention.
You can get more information from Visteon STA.

I got this tonight:

Subject: 8D's & "escape"
Date: Thu, 2 Dec 1999 21:58:12 EST
From: XXXXXXXX

"Escape" is an important part of the 8D problem solving tool. It is dealt with under Root cause........First you have Root cause for occurrence (Why did the problem occur) and Root cause for escape....(why did you not discover & contain the problem when it occurred ,and what caused it to "escape" to your customer.)

Hmmm. This has been dormant for quite sometime already but I would like to put my two cents of thought here. An 'escape point' is a point in the process where the problem or defect could be have been detected but was not. As one can deduce from the definition, the escape point is vital as it gives us an idea that our there was a lapse in our system as the defect escaped when it should have not. For example, we have a 100% third optical inspection after the die attach and wire bond processes (transistor production). A customer complained of a field failure and, upon verification, the root cause was a surface damage on the die. From this, we can easily suspect that the 3rd opt inspection was an escape point as the surface damage should have been detected during the inspection. For containment action, we may enhance the third opt inspection, i.e. if the inspection was done by human inspectors, we may enhance it to a vision system.

Regards,
Marloun

Does anybody have 8D documentation? Although I have used the process I do not have any current training materials or detailed process description. I am looking to see whether the 8D approach can be adapted to service processes in the software industry. If you happen to have 8D training material I would be mst greatful.

Regards,
Alex Hammer
www.nortelnetworks.com

Are you looking for Training Material for a group, or Material that you would like to use singly and possible adapt to a group situation at a later date. Depending on your requirements, I may be able to recommend or even supply you with some material.
Originally posted by AHammer:

Does anybody have 8D documentation? Although I have used the process I do not have any current training materials or detailed process description. I am looking to see whether the 8D approach can be adapted to service processes in the software industry. If you happen to have 8D training material I would be mst greatful.

Regards,
Alex Hammer

Yes - you can use the 8-D problem solving (prevent recurrence) methodology in a service company. It can be applied to any problem in any situation or industry.

Thanks for that 8D info. At my old company we had a customer that required us to use that format for all our CARs i never really understood it till now.

FYI - If you're an old Mil-Spec head, by chance, this is the same as the base requirements in the old Mil-Std-1520.

Anyone know where I might get a copy of the 8D with the "escape path" in it?

On 7/23/01 3:52 PM, XXXX wrote:

-> Marc,
->
-> We have a question. Perhaps you can help. what is the
-> difference between an escape path and an occur path in
-> Ford's 8-D program. Can you provide a simple overview so
-> I can explain it to folks who have not used 8-D before.

How did it occur? (What happened?)
Was this an operator error? Machine error? Documentation error?

How did it escape?

Where and how did it get to where it was identified?

For example, let's assume a customer receives a defective product. The product is a wagon. The defect is a wheel is missing. Initial escape point is the operation. It also got by the next operation. Etc. to final inspection/test and then to customer. You just map out the 'process' and look at inspection and test points. Was the quality planning process (system) at fault? What about the FMEA - why was this missed?

You do a root cause. You can use the East-West 'system', which - if you look - is simply an 8-D. East-West forms and explanation are part of my 8-D Guide.

Maybe some of the others here can take another stab at 'simplifying' the differences between occurance vs. escape.

Root Cause = What happened.
Escape Path = where it should have been caught.

The escape path should be part of the root cause of the corrective action and then lead to the revision of the control plan/FMEA.

Don't do it for the customer, do it for yourself!

It's been a while since this came up. Just wondering if anyone has come across this recently.

Root Cause = What happened.
Escape Path = where it should have been caught.

The escape path should be part of the root cause of the corrective action and then lead to the revision of the control plan/FMEA.

Don't do it for the customer, do it for yourself!
Sometimes people think of an escape path as a way out of a situation, that it might be positive. The escape path is just a term that should note when the first occurance of a failure prevention does not work as designed in a FMEA or similar document. If it happens, it proves that the possible failure mode was not investigated enough and that further investigation is required. This is not neccesarily bad, while determining mode in the proper manner all ideas are explored. There are times when nobody thinks of a possible mode and therefore a preventive action is not enacted.

The escape path serves to accentuate another possible mode and leads to various methodologies to improve that aspect of performance. Also don't be confused about escape paths being positive, think of the big picture, whether issued externally or internally, they are a shot across the bow that will stay in somebody's file for awhile.

Al...:)

On 7/23/01 3:52 PM, XXXX wrote:

You do a root cause. You can use the East-West 'system', which - if you look - is simply an 8-D. East-West forms and explanation are part of my 8-D Guide.
Marc, I never use a East-West system before, can you have a briefly explaination, or else, provide a sample "East-West" form, I am a bit interested in it.

Many thanks.

Here's a tracking sheet. I'll have to get back with you later with a description.

Marc,
Could you clear up a question? My registrar auditor had a problem with the "verify" in step 5 taking place before the "implement" in step 6. (How can you verify before you implement is what he said) So now, I am confused...
Thanks!

Well, I guess it's a matter of definitions. Before one would put in place any change for any reason one verifies that the change will, in fact, actually work. For examkple, take a data processing company. Before a software change is 'implemented' both systems are run concurrently for a time to ensure the outputs match and that the 'new' software in fact works as designed. Then, when outputs are matched (the software is validated), the changeover (implementation) occurs.

Same in manufacturing, really. In APQP it is that point where the processes and equipment have been run to ensure 'everything works' and then production is 'turned on'.

Only difference is in problem solving the changes are typically to ongoing processes. You still verify that what you propose workes before you actually 'go live' - even if its a running change.

NOTE: This is different than Verifying Effectiveness of the action. For example, the proposed change may work but it may not solve the original problem, may make the problem worse, and/or may induce a different problem.

mustang - the difference between verify and validate is an old 'controversy'...I've had teh same dilemmas wiht audtors before. typically, verify has the interpretation given by Marc.

The definition of verify = to establish the truth by comaprison, investigation or experimentation; with objective evidence.
The definition of validate = to declare (legally) valid or establish the soundness of.

You can verify that you have identified a root cause by turning it on and off... You can verify that your proposed corrective action will work before you implement it...you can verify that corrective actions have been implemented.

You validate that the corrective actions were effective by gathering data that shows that the process is better (or that teh Problem is significantly reduced/eliminated) than befroe teh implementation...this usually takes time (in the automotive world it can take months or years to get the statistically valid data...)

My corrective action processes always include the need to verify and then validate. While I use the terms verify and validate as above they are different than most QMS's (ISO, QS, etc.). I deal with this by being clear in the corrective action procedure by what is meant and the flow of usage and then explaiing to the auditor. For most auditors this is sufficient; but I've had avery few who wanted me to conform to the 'letter' of the word used in the standard - I have fought this with the registrar and won on those few occassions.

Thank-you Bev & Marc. What you both said is what I thought (when I had a chance to think about it), but of course, after two days of being stuck in a conference room with my registrar, my brain got fried and I could not for the life of me remember that.

Note to self: Need vocabulary manual...

Lucinda wrote: "My understanding of verification vs validation is different. Verification is verification that what you did is what you intended to do. Validation is the final objective evidence that what you did is what brings about the desired result."

This is true at the 10,000 foot general level. when applied to the speicfic actions in my post you should see that the specific examples comply completly with the general definition you have given.

Somewhere around form # 6 or 7 of the Ford 8D process is a Risk Analysis form. That form provides for a comparrison of several potential corrective actions for the SAME problem.

The inputs to this form include Needs (Defined by Management) and Wants (Defined as added perks by the focus team).

Using that format, you review, rate, select and in some cases verify and validate various corrections for their impact on solving the problem, and satisfying the Needs and Wants. A couple may be implemented as corrections.

Very few companies that I have had the "pleasure" of working with get past the IS/IS-Not Summary. That is where Who, What, When, Where, Why and How Many is addressed. The Japanese refer to these as the 5 W's and an H.

A True 8D is costly and not always necessary. It is a process for solving a problem where the Root Cause is not readily evident, and where more than one head is needed.

The 5-Why is an offshoot of Shingo. . . a good tool to approximate Root Cause. I belkieve that it has also been Americanized and made into more than it was intended to refer to. JMNSOHO

Good Afternoon everyone,

We have completed our TS audit with 2 minors and 6 OFI's. During one of our discussions the auditors mentioned something to the effect that we need to try to use a form that is "more" TS oriented, less QS9000 oriented. It was only a suggestion. Does anyone have any idea what she may have meant? I didn't develop the current form and that leaves me a bit confused. She did refer to "escape" (why shipped?) and "defect "(why made?) Can anyone help us?

:thanx: :confused:

TY