Steve C

Prediction interval is used for expressing a range of possible outcomes for a single event, based on observed process variation. Confidence interval is used for expressing a range of possible outcomes averaged over time. Because a prediction interval contains a single data point, it will always be greater than a confidence interval for a given variable of interest. A practical example would be an estimate of how long it takes me to commute to my office on a daily basis (average, therefore confidence interval) versus an estimate of how long it might take to commute on a given day when I have an important appointment that I can't be late to.

Interesting question. My initial reaction is that when I was taught Six Sigma 20+ years ago by MBBs with a Motorola>Allied Signal or GE pedigree, they were very insistent that DPMO and RTY were the only acceptable ways to measure process performance with attribute data. I did not completely agree, and still don't. I would use yield data for simple products of moderate to low value, since you don't want the burden of your defect tracking system to be a large percentage of the product cost. You do capture data that can be turned into DPMO in your lower level cause categorization for defectives, i.e. a Pareto analysis. I would use DPMO or DPU for more complex products, since yield would tend to summarize performance to a level that would be difficult to take action on. For a service process, I would use DPMO, since a defect in this case is an unsatisfied (not returning) customer, so you would want to measure multiple points to satisfy or dissatisfy that same customer throughout the interaction to pinpoint areas that need attention. Regardless of which method you use, identifying opportunities for improvement needs to be the primary focus, with comparing like processes important but not the most important

1. A Z score is useful for normalizing how well the process performs relative to expectations for different types of data and measurement systems. It can compare attribute (Yield, DPU, DPMO) and variable data, so it provides the ability to compare different processes so that appropriate business case and investment decisions can be made 2. Secondly, a Z score is a single metric that provides a lot of information about the process, i.e. the process variation, the requirements and the comparison of the two, so it is a useful shorthand that quickly indicates the relative process health

I can think of at least four ways that a Process FMEA can be used in a DMAIC project. The first is as a source of a project itself. When working through a PFMEA, a team might identify a process step that needs to be improved. The required improvement may require the use of the DMAIC tool set to accomplish it. The second is straightforward in that PFMEA is a standard tool used in the Analyze phase to identify likely cause and effect relationships that need to be tested for validity. The third way is I could see a PFMEA used in the measurement phase to ensure a capable measurement system. The key point here is to remember that measurement is a process in itself, subject to the same improvement tools used to improve a larger process. Finally, I have seen PFMEA used in the improve phase as a tool to help bring structure to a team's brainstorming activities. It can also help to prioritize improvement actions based on impact and likelihood of success.

I find it helpful to think different types of causes as root causes and contributing causes. Both types can be either actionable (i.e. subject to change), or not actionable (at least by people in the system under consideration). Actionable causes are almost always effects of not actionable causes. When looking for root causes and contributing causes, keep asking "why" until you reach a cause that does not seem actionable, e.g. the rock fell due to the force of gravity, then the effect of that cause will likely be an actionable cause. The difference for me between root causes and contributing causes is that the root cause(s) lead to the undesirable condition, whereas the contributing causes can increase the impact of the undesirable condition once it exists. Thirdly, interactions between both types of causes are important. Sometimes two causes must be present to create an effect (AND) and sometimes one or more causes can create the effect by themselves (OR). I find it important to capture this logic when doing cause and effect diagrams to ensure logical consistency and clarity those reviewing the logic. Finally, it is usually helpful to review causes determined to ask if there are additional expected effects that were not documented in the original logic. This helps with clarity, logically consistency and sufficient detail when doing cause and effect analysis.

Difference is between statistical significance and practical significance. If changing x, therefore y, does not have an impact that is important to the leaders of the business, then the efforts are better directed somewhere else.

1. To insure that we have an accurate perception of customer desires and expectations 2. To align expectations between suppliers and customers 3. To identify improvements needed for acceptance standards

Some thoughts I have: 1) knowing what the process is likely to deliver within an expected range allows us to better assess risk or opportunity to improve upon performance, or to distinguish ourselves from our competitors. I'm thinking specifically about the advantages due to predictable lead times and the ability to deliver products quickly, and consistently meet customer expectations. 2) second, knowing what the process mean is relative to the desired nominal provides insight into improvement actions, whether adjusting the process performance to reduce the gap between the mean and a desired target, or reducing the process variation. Different approaches may apply to the different desired improvement targets.