Quality Digest

Tom,

I think that your defect definition approach can be quite effective.=20

However, what I was referencing is when defect definition becomes a requirement =
or policy for all projects within a Six Sigma implementation. When this occurs =
(e.g., typical practice within GE and Dupont) a Sigma Quality Level needs to be =
determined for each project.=20

When policy dictates the defining of a defect, you typically are required to =
determine an opportunity for failure for each project so that you will be able =
to calculate a defect per million opportunity (dpmo) rate for the project. This =
rate is what a sigma quality level could be determined from (which can be very =
different from what is seen by the customer). One concern from this practice is =
that everyone would not define a defect in a similar manner.=20

This practice can also lead to the creation of Cp and Cpk indices for =
transactional processes, which typically creates little added value.=20

In another situation this can often lead to changing continuous data to =
attribute before attempting to fit a distribution. For example, equating a 16 =
minute "late departure" time to a 2 hour late departure time for an airplane by =
just counting the frequency of not meeting a 15 minute specification.=20

Finally, in the real world when the resulting numbers are not at a desired =
level someone often decides to change the "specification", since the original =
specification was subjective anyway.

I am really concern that much resource can be wasted through playing games with =
the numbers when policy dictates that a defect be defined.=20

Forrest Breyfogle
512-996-8288
forrest@smartersolutions.com
www.smartersolutions.com

> Forrest,

> I've found the concept of defect useful in transactional environments. =
For
> example, you mentioned cycle time. One way to define a cycle time defect is
> to study the relationship between cycle time and customer satisfaction.
> There is usually a point where customer dissatisfaction takes a big
> dive--anything beyond that is a defects.

> While not absolutely necessary, I think that the discipline of defining a
> defect helps focus attention on why a thing is measured in the first place.
> I don't suggest that clients obsess on it, but I do ask that they give it
> the old college try. The exercise often produces unexpected opportunities
> and insights.

> Tom

> -----Original Message-----
> From: www-sixsigma-bounce@lists.insidequality.wego.net
> [mailto:www-sixsigma-bounce@lists.insidequality.wego.net]On Behalf Of
> forrest@smartersolutions.com
> Sent: Sunday, April 07, 2002 4:28 PM
> To: www-sixsigma@lists.insidequality.wego.net
> Subject: Re: Use statistical methods to improve company's processes

> Yes, like production and quality control areas statistical and Six Sigma
> methodologies can be very beneficial to design engineering, marketing,
> finance and engineering systems.

> Basically all the systems you have listed are processes. Six Sigma can be
> integrated with Lean techniques to reduce defects and improve cycle times
> for any process. Roadmaps help with the selection of the right tool for each
> situation.

> When examining a process we should determine the performance for Key Process
> Output Variables (KPOVs) of the process.

> To do this I suggest using an infrequent sampling plan. For example, select
> 1 random sample daily of all invoices processed, documenting the number of
> days it took for an invoice to be processed. This metric is then typically
> tracked on an XmR (individuals control chart).

> NOTE: This described infrequent sampling plan is different than the
> traditional school of thought of taking more samples within a subgroup but
> it has some great advantages for separating common cause variability from
> special cause variability. Note also from this sampling plan we are not
> trying to "fix" anything. We only want a simple approach to describe the
> output of the process from a customer point of view.

> >From this sampling the long-term process capability can then be determined.

> Collectively I call this view of the process the 30,000 Foot-Level.

> When we now step back and look at the numbers to see if there is a need for
> improvement and determine that there is, we would then take on this as a Six
> Sigma project using the Define-Measure-Analyze-Improve-Control roadmap.

> The above thought process is applicable for any process whether it is
> manufacturing or transactional.

> It is important to note that unlike others I believe that you do not need to
> require that there be a definition for a process defect (i.e., there is no
> need to determine "sigma quality level). This is important since with this
> approach it is much easier to blend Six Sigma into a transactional
> environment where processes often do not have a defect like manufacturing
> (e.g., a shorter cycle time is better but there is no crisp definition for a
> "defect").

> For more information about this 30,000 Foot-Level view and rolling out Six
> Sigma you might check out
> http://www.smartersolutions.com/html/bottomline.htm

> Forrest Breyfogle
> 512-996-8288
> forrest@smartersolutions.com
> www.smartersolutions.com

> You are subscribed to www-sixsigma. To unsubscribe go to:
> http://www.insidequality.wego.net/?ct=3Ddisc&ci=3D263
> If you have problems accessing the above link, visit the main site below.

> --
> This message is a service of InsideQuality
> http://www.insidequality.wego.net -- Powered by Wego