| Trend charts are also known as Run charts, and are used to show trends in data over time. All processes vary, so single point measurements can be misleading. Displaying data over time increases understanding of the real performance of a process, particularly with regard to an established target or goal. Following is an example of a trend chart of order fill rate performance: | ||||||||||||||||||
|
| ||||||||||||||||||
| Major Elements: | ||||||||||||||||||
| A good trend chart has the following characteristics: | ||||||||||||||||||
| ||||||||||||||||||
| Two common errors in chart construction are shown below: | ||||||||||||||||||
| ||||||||||||||||||
| ||||||||||||||||||
| ||||||||||||||||||
| ||||||||||||||||||
| ||||||||||||||||||
Sunday, April 29, 2007
Trend Chart - Run Chart
Failure Mode and Effect Analysis - FMEA
| Failure Mode and Effects Analysis (FMEA) is a model used to prioritize potential defects based on their severity, expected frequency, and likelihood of detection. An FMEA can be performed on a design or a process, and is used to prompt actions to improve design or process robustness. The FMEA highlights weaknesses in the current design or process in terms of the customer, and is an excellent vehicle to prioritize and organize continuous improvement efforts on areas which offer the greatest return. |
| The process is very straightforward, and begins by identifying all of the probable failure modes. This analysis is based on experience, review, and brainstorming, and should use actual data if possible. New designs or processes may not have actual historical data to draw from, but "proxy" data may be available from similar designs or processes. |
| The next step is to assign a value on a 1-10 scale for the severity, probability of occurrence, and probability of detection for each of the potential failure modes. After assigning a value, the three numbers for each failure mode are multiplied together to yield a Risk Priority Number (RPN). |
| The RPN becomes a priority value to rank the failure modes, with the highest number demanding the most urgent improvement activity. Error-proofing, or poka-yoke actions are often an effective response to high RPN's. |
| Following is an example of a simplified FMEA for a seat belt installation process at an automobile assembly plant. |
| As you can see, three potential failure modes have been identified. Failure mode number two has an RPN of 144, and is therefore the highest priority for process improvement. |
| FMEA's are often completed as part of a new product launch process. RPN minimum targets may be established to ensure a given level of process capability before shipping product to customers. In that event, it is wise to establish guidelines for assessing the values for Severity, Occurrence, and Detection to make the RPN as objective as possible. |
Flow Chart
| The Process Flow chart provides a visual representation of the steps in a process. Flow charts are also referred to as Process Mapping or Flow Diagrams. Constructing a flow chart is often one of the first activities of a process improvement effort, because of the following benefits: | ||||||||
| ||||||||
| There are many symbols used to construct a flow chart; the more common symbols are shown below: | ||||||||
| | ||||||||
| If you have Microsoft Word or Excel, you can access a gallery or symbols in the Autoshapes function, together with a description of their use. The next step is to identify the process steps and link them together with direction arrows. | ||||||||
| Following is an example of a very simple flow chart for the process of getting out of bed in the morning: | ||||||||
| You can make a flowchart more useful by adding information beside the boxes. This flowchart gives a better description of the process when you know that the snooze bar gets hit three times, postponing the inevitable by five minutes each time. |
Pareto Chart
The theory behind the Pareto Chart originated in 1897 when an Italian economist named Vilfredo Pareto created a formula representing the uneven distribution of wealth - what later came to be known as the 80-20 rule. You have probably heard a version of it like: "20% of the people cause 80% of the problems", or a derivative. Dr. J. M. Juran started applying this principal to defect analysis - separating the "vital few" from the "trivial many", and called it the "Pareto Chart". In fact, many (most) defect distributions follow a similar pattern, with a relatively small number of issues accounting for an overwhelming share of the defects. The Pareto Chart shows the relative frequency of defects in rank-order, and thus provides a prioritization tool so that process improvement activities can be organized to "get the most bang for the buck", or "pick the low-hanging fruit". Following is an example of paint defects from an automotive assembly plant: |
| After reviewing the chart above, there is no question which defect to work on first. However, this pareto chart is constructed from one dimension only - defect frequency. If you learned that it costs $10 to fix a Dirt defect, while Sag defects cost $100 to correct, Sags would probably be the highest priority. Likewise, if one category represents a constraint on the whole process, its priority would be elevated. You may wish to consult the Project Priority Calculator for a template to prioritize along multiple dimensions. |
C-chart - Application of Control Charts
Attribute Charts in General, c Charts in Particular
Attribute control charts arise when items are compared with some standard and then are classified as to whether they meet the standard or not. The control chart is used to determine if the rate of nonconforming product is stable and detect when a deviation from stability has occurred. The argument can be made that a LCL should not exist, since rates of nonconforming product outside the LCL is in fact a good thing; we WANT low rates of nonconforming product. However, if we treat these LCL violations as simply another search for an assignable cause, we may learn for the drop in nonconformities rate and be able to permanently improve the process.
The c Chart measures the number of nonconformities per "unit" and is denoted by c. This "unit" is commonly referred to as an inspection unit and may be "per day" or "per square foot" of some other predetermined sensible rate.
Steps in Constructing a c Chart
- Determine cbar.
There are k inspection units and c(i) is the number of nonconformities in the ith sample.
- Since the mean and variance of the underlying Poisson distribution are equal,
Thus,and the UCL and LCL are:
- Plot the centerline cbar, the LCL and UCL, and the process measurements c(i).
- Interpret the control chart.
Example:
Farnum Example:
data is from Farnum (1994):
Modern Statistical Quality Control and Improvement, p. 248
Non-conforming
Day Errors/1000 lines
1 6
2 7
3 7
4 6
5 8
6 6
7 5
8 8
9 1
10 6
11 2
12 5
13 5
14 4
15 3
16 3
17 2
18 0
19 0
20 1
21 2
22 5
23 1
24 7
25 7
26 1
27 5
28 5
29 8
30 8
Calculations:
CBAR = 4.4667
UCL = cbar + 3*sqrt(cbar) = 10.80701366
LCL = cbar - 3*sqrt(cbar) = -1.873680327 = 0
(when LCL < 0, set LCL = 0)
Day CL UCL LCL NonConforming
1 4.4667 10.80701366 0 6
2 4.4667 10.80701366 0 7
3 4.4667 10.80701366 0 7
4 4.4667 10.80701366 0 6
5 4.4667 10.80701366 0 8
6 4.4667 10.80701366 0 6
7 4.4667 10.80701366 0 5
8 4.4667 10.80701366 0 8
9 4.4667 10.80701366 0 1
10 4.4667 10.80701366 0 6
11 4.4667 10.80701366 0 2
12 4.4667 10.80701366 0 5
13 4.4667 10.80701366 0 5
14 4.4667 10.80701366 0 4
15 4.4667 10.80701366 0 3
16 4.4667 10.80701366 0 3
17 4.4667 10.80701366 0 2
18 4.4667 10.80701366 0 0
19 4.4667 10.80701366 0 0
20 4.4667 10.80701366 0 1
21 4.4667 10.80701366 0 2
22 4.4667 10.80701366 0 5
23 4.4667 10.80701366 0 1
24 4.4667 10.80701366 0 7
25 4.4667 10.80701366 0 7
26 4.4667 10.80701366 0 1
27 4.4667 10.80701366 0 5
28 4.4667 10.80701366 0 5
29 4.4667 10.80701366 0 8
30 4.4667 10.80701366 0 8
c - Chart:
Friday, April 27, 2007
The Cause and Effect Diagram (a.k.a. Fishbone)
By Kerri Simon
When utilizing a team approach to problem solving, there are often many opinions as to the problem's root cause. One way to capture these different ideas and stimulate the team's brainstorming on root causes is the cause and effect diagram, commonly called a fishbone. The fishbone will help to visually display the many potential causes for a specific problem or effect. It is particularly useful in a group setting and for situations in which little quantitative data is available for analysis.
The fishbone has an ancillary benefit as well. Because people by nature often like to get right to determining what to do about a problem, this can help bring out a more thorough exploration of the issues behind the problem - which will lead to a more robust solution.
To construct a fishbone, start with stating the problem in the form of a question, such as 'Why is the help desk's abandon rate so high?' Framing it as a 'why' question will help in brainstorming, as each root cause idea should answer the question. The team should agree on the statement of the problem and then place this question in a box at the 'head' of the fishbone.
The rest of the fishbone then consists of one line drawn across the page, attached to the problem statement, and several lines, or 'bones,' coming out vertically from the main line. These branches are labeled with different categories. The categories you use are up to you to decide. There are a few standard choices:
| |||||||||||
You should feel free to modify the categories for your project and subject matter.
Once you have the branches labeled, begin brainstorming possible causes and attach them to the appropriate branches. For each cause identified, continue to ask 'why does that happen?' and attach that information as another bone of the category branch. This will help get you to the true drivers of a problem.
Once you have the fishbone completed, you are well on your way to understanding the root causes of your problem. It would be advisable to have your team prioritize in some manner the key causes identified on the fishbone. If necessary, you may also want to validate these prioritized few causes with a larger audience.
Tuesday, April 24, 2007
Analytical Hierarchy Process (AHP)
. T. L. Saaty, The Analytic Hierarchy Process:Planning, Priority Setting, Resource Allocation,
Suppose that the value function has the form
If wi = 0, the corresponding outcome yi can be deleted from consideration. Thus, we shall assume that wi > 0, i = 1, 2, . . . , q.
Define the weight ratio by
Note that, for any i, j, k indexes
Define the matrix of weight ratios as W = [wij]q×q:
A matrixW is called consistent if its components satisfy the equalities
wij = wikwkj for any i, j and k.
Observe that:
- . Since each row of W is a multiple of the first row, the rank of W is one, and thus there is onlu one nonzero eigenvalue which is q.
- . We can easily chack that
Ww = qw
therefore w must be the eigenvector of W corresponding to the maximum eigenvalue q.
As a living system, human perception and judgment are subject to change when the information inputs or psychological states of the decsion maker change.
A fixed weight vector is difficult to find. Saaty proposed the following to overcome this difficulty:
Estimate or elicit the weight ratio wij by aij and let A = [aij]q×q be the matrix of components {aij}.
Note that as each wij > 0, we expect and shall assume that all aij > 0.
Furthermore, as
, Saaty suggested that in practice, only aij, j > I need to be assessed.
Since A is found as an approximate for W, when the consistency conditions are almost satisfied for A, one would expect that the normalized eigenvector corresponding to the maximum eigenvector of A, denoted by λmax, will also be close to w.
Theorem 1. The maximum eigenvalue, λmax,of A is a positive real number.
Let ˆ w be the normalized eigenvector corresponding to λmax of A. Then ˆ wi > 0 for all 1 ≤ i ≤ q.
Theorem 2. The maximum eigenvalue of A satisfies the inequality
λmax ≥ q.
Assume we have q objectives and we want to construct a scale, rating these objectives as to their importance with respect to the decision, as seen by the analyst.
We ask the decision maker to compare the objectives in paired comparisons.
If we are comparing objective i with objective j, we assign the values aij and aji as follows:
. If objective i is more important than objective j then aij gets assigned a number as follows:
Note that the above observation is valid for any matrix which is consistent.
| Intensity of relative importance | Definition |
| 1 | equal importance |
| 3 | weak importance (of one over the other) |
| 5 | strong importance |
| 7 | demonstrated importance over the other |
| 9 | absolute importance |
| 2, 4, 6, 8 | intermediate values between |
Saaty’s scale of relative importances.
Example 1. Let us consider the following matrix
To find λmax we solve
det[A . λI] = 0
that is,
= (1 . λ)3 . 3(1 . λ) + 9/35 + 35/9 = 0
The maximum solution is
λmax = 3.21.
After normalization we get
ˆ w1 = 0.77, ˆ w2 = 0.05, ˆ w3 = 0.17.
We illustrate Saaty’s method on a job selection problem (3 alternatives compared on 6 criteria)
Choice of job.
The question asked was, which of a given pair of criteria is seen as contributing more to overall satisfaction with a job and what is the intensity or strength of the difference?
Pairwise comparison matrix of criteria.
The relative weights of criteria (priorities) can be computed as normalized geometric means of the rows (which are very close to the eigenvector corresponding to the largest eigenvalue of the matrix)
The geometric means are computed as
m1 = (1 × 1 × 1 × 4 × 1 × ½)1/6
m2 = (1 × 1 × 2 × 4 × 1 × ½)1/6
m3 = (1 × 1/2 × 1 × 5 × 3 × ½)1/6
m4 = (1/4 × 1/4 × 1/5 × 1 × 1/3 × 1/3) 1/6
m5 = (1 × 1 × 1/3 × 3 × 1 × 1) 1/6
m6 = (2 × 2 × 2 × 3 × 1 × 1) 1/6
So, the relative weight (priority) of the criterion research is obtained as
p1 = m1 / (m1 + m2 + m3 + m4 + m5 + m6)
Then we compare the alternatives on each of the
We obtain
So job A should be selected as the best alternative.
Failure Mode and Effect Analysis (FMEA)
Although the purpose, terminology and other details can vary according to type (e.g. Process FMEA, Design FMEA, etc.), the basic methodology is similar for all. This document presents a brief general overview of FMEA / FMECA analysis techniques and requirements.
FMEA / FMECA Overview
In general, Failure Modes, Effects and Criticality Analysis (FMEA / FMECA) requires the identification of the following basic information:
- Item(s)
- Function(s)
- Failure(s)
- Effect(s) of Failure
- Cause(s) of Failure
- Current Control(s)
- Recommended Action(s)
- Plus other relevant details
Most analyses of this type also include some method to assess the risk associated with the issues identified during the analysis and to prioritize corrective actions. Two common methods include:
- Risk Priority Numbers (RPNs)
- Criticality Analysis (FMEA with Criticality Analysis = FMECA)
Published Standards and Guidelines
There are a number of published guidelines and standards for the requirements and recommended reporting format of failure mode and effects analyses. Some of the main published standards for this type of analysis include SAE J1739, AIAG FMEA-3 and MIL-STD-1629A. In addition, many industries and companies have developed their own procedures to meet the specific requirements of their products/processes. Figure 1 shows a sample Process FMEA in the Automotive Industry Action Group (AIAG) FMEA-3 format. Click to enlarge the image.
| Figure 1 [Enlarge] |
Basic Analysis Procedure for FMEA or FMECA
The basic steps for performing an Failure Mode and Effects Analysis (FMEA) or Failure Modes, Effects and Criticality Analysis (FMECA) include:
- Assemble the team.
- Establish the ground rules.
- Gather and review relevant information.
- Identify the item(s) or process(es) to be analyzed.
- Identify the function(s), failure(s), effect(s), cause(s) and control(s) for each item or process to be analyzed.
- Evaluate the risk associated with the issues identified by the analysis.
- Prioritize and assign corrective actions.
- Perform corrective actions and re-evaluate risk.
- Distribute, review and update the analysis, as appropriate.
The process for conducting an FMEA is straightforward. The basic steps are outlined below.
- Describe the product/process and its function. An understanding of the product or process under consideration is important to have clearly articulated. This understanding simplifies the process of analysis by helping the engineer identify those product/process uses that fall within the intended function and which ones fall outside. It is important to consider both intentional and unintentional uses since product failure often ends in litigation, which can be costly and time consuming.
- Create a Block Diagram of the product or process. A block diagram of the product/process should be developed. This diagram shows major components or process steps as blocks connected together by lines that indicate how the components or steps are related. The diagram shows the logical relationships of components and establishes a structure around which the FMEA can be developed. Establish a Coding System to identify system elements. The block diagram should always be included with the FMEA form.
- Complete the header on the FMEA Form worksheet: Product/System, Subsys./Assy., Component, Design Lead, Prepared By, Date, Revision (letter or number), and Revision Date. Modify these headings as needed.
Failure Modes and Effects Analysis (FMEA) Example 2 - Use the diagram prepared above to begin listing items or functions. If items are components, list them in a logical manner under their subsystem/assembly based on the block diagram.
- Identify Failure Modes. A failure mode is defined as the manner in which a component, subsystem, system, process, etc. could potentially fail to meet the design intent. Examples of potential failure modes include:
- Corrosion
- Hydrogen embrittlement
- Electrical Short or Open
- Torque Fatigue
- Deformation
- Cracking
- A failure mode in one component can serve as the cause of a failure mode in another component. Each failure should be listed in technical terms. Failure modes should be listed for functions of each component or process step. At this point the failure mode should be identified whether or not the failure is likely to occur. Looking at similar products or processes and the failures that have been documented for them is an excellent starting point.
- Describe the effects of those failure modes. For each failure mode identified the engineer should determine what the ultimate effect will be. A failure effect is defined as the result of a failure mode on the function of the product/process as perceived by the customer. They should be described in terms of what the customer might see or experience should the identified failure mode occur. Keep in mind the internal as well as the external customer. Examples of failure effects include:
- Injury to the user
- Inoperability of the product or process
- Improper appearance of the product or process
- Odors
- Degraded performance
- Noise
Establish a numerical ranking for the severity of the effect. A common industry standard scale uses 1 to represent no effect and 10 to indicate very severe with failure affecting system operation and safety without warning. The intent of the ranking is to help the analyst determine whether a failure would be a minor nuisance or a catastrophic occurrence to the customer. This enables the engineer to prioritize the failures and address the real big issues first.
- Identify the causes for each failure mode. A failure cause is defined as a design weakness that may result in a failure. The potential causes for each failure mode should be identified and documented. The causes should be listed in technical terms and not in terms of symptoms. Examples of potential causes include:
- Improper torque applied
- Improper operating conditions
- Contamination
- Erroneous algorithms
- Improper alignment
- Excessive loading
- Excessive voltage
- Enter the Probability factor. A numerical weight should be assigned to each cause that indicates how likely that cause is (probability of the cause occuring). A common industry standard scale uses 1 to represent not likely and 10 to indicate inevitable.
- Identify Current Controls (design or process). Current Controls (design or process) are the mechanisms that prevent the cause of the failure mode from occurring or which detect the failure before it reaches the Customer. The engineer should now identify testing, analysis, monitoring, and other techniques that can or have been used on the same or similar products/processes to detect failures. Each of these controls should be assessed to determine how well it is expected to identify or detect failure modes. After a new product or process has been in use previously undetected or unidentified failure modes may appear. The FMEA should then be updated and plans made to address those failures to eliminate them from the product/process.
- Determine the likelihood of Detection. Detection is an assessment of the likelihood that the Current Controls (design and process) will detect the Cause of the Failure Mode or the Failure Mode itself, thus preventing it from reaching the Customer. Based on the Current Controls, consider the likelihood of Detection using the following table for guidance.
- Review Risk Priority Numbers (RPN). The Risk Priority Number is a mathematical product of the numerical Severity, Probability, and Detection ratings:
RPN = (Severity) x (Probability) x (Detection)
The RPN is used to prioritize items than require additional quality planning or action. - Determine Recommended Action(s) to address potential failures that have a high RPN. These actions could include specific inspection, testing or quality procedures; selection of different components or materials; de-rating; limiting environmental stresses or operating range; redesign of the item to avoid the failure mode; monitoring mechanisms; performing preventative maintenance; and inclusion of back-up systems or redundancy.
- Assign Responsibility and a Target Completion Date for these actions. This makes responsibility clear-cut and facilitates tracking.
- Indicate Actions Taken. After these actions have been taken, re-assess the severity, probability and detection and review the revised RPN's. Are any further actions required?
- Update the FMEA as the design or process changes, the assessment changes or new information becomes known.
Risk Evaluation Methods
A typical failure modes and effects analysis incorporates some method to evaluate the risk associated with the potential problems identified through the analysis. The two most common methods, Risk Priority Numbers and Criticality Analysis, are described next.
Risk Priority Numbers
To use the Risk Priority Number (RPN) method to assess risk, the analysis team must:
- Rate the severity of each effect of failure.
- Rate the likelihood of occurrence for each cause of failure.
- Rate the likelihood of prior detection for each cause of failure (i.e. the likelihood of detecting the problem before it reaches the end user or customer).
Severity
| Hazardous without warning | Very high severity ranking when a potential failure mode effects safe system operation without warning | 10 |
| Hazardous with warning | Very high severity ranking when a potential failure mode affects safe system operation with warning | 9 |
| Very High | System inoperable with destructive failure without compromising safety | 8 |
| High | System inoperable with equipment damage | 7 |
| Moderate | System inoperable with minor damage | 6 |
| Low | System inoperable without damage | 5 |
| Very Low | System operable with significant degradation of performance | 4 |
| Minor | System operable with some degradation of performance | 3 |
| Very Minor | System operable with minimal interference | 2 |
| None | No effect | 1 |
Probability
| PROBABILITY of Failure | Failure Prob | Ranking |
| Very High: Failure is almost inevitable | >1 in 2 | 10 |
| | 1 in 3 | 9 |
| High: Repeated failures | 1 in 8 | 8 |
| | 1 in 20 | 7 |
| Moderate: Occasional failures | 1 in 80 | 6 |
| | 1 in 400 | 5 |
| | 1 in 2,000 | 4 |
| Low: Relatively few failures | 1 in 15,000 | 3 |
| | 1 in 150,000 | 2 |
| Remote: Failure is unlikely | <1> | 1 |
Detectability
| Detection | Likelihood of DETECTION by Design Control | Ranking |
| Absolute Uncertainty | Design control cannot detect potential cause/mechanism and subsequent failure mode | 10 |
| Very Remote | Very remote chance the design control will detect potential cause/mechanism and subsequent failure mode | 9 |
| Remote | Remote chance the design control will detect potential cause/mechanism and subsequent failure mode | 8 |
| Very Low | Very low chance the design control will detect potential cause/mechanism and subsequent failure mode | 7 |
| Low | Low chance the design control will detect potential cause/mechanism and subsequent failure mode | 6 |
| Moderate | Moderate chance the design control will detect potential cause/mechanism and subsequent failure mode | 5 |
| Moderately High | Moderately High chance the design control will detect potential cause/mechanism and subsequent failure mode | 4 |
| High | High chance the design control will detect potential cause/mechanism and subsequent failure mode | 3 |
| Very High | Very high chance the design control will detect potential cause/mechanism and subsequent failure mode | 2 |
| Almost Certain | Design control will detect potential cause/mechanism and subsequent failure mode | 1 |
Source : http://www.isixsigma.com
- Calculate the RPN by obtaining the product of the three ratings:
RPN = Severity x Occurrence x Detection
The RPN can then be used to compare issues within the analysis and to prioritize problems for corrective action. This risk assessment method is commonly associated with Failure Mode and Effects Analysis (FMEA).
Criticality Analysis
The MIL-STD-1629A document describes two types of criticality analysis: quantitative and qualitative. To use the quantitative criticality analysis method, the analysis team must:
- Define the reliability/unreliability for each item, at a given operating time.
- Identify the portion of the item’s unreliability that can be attributed to each potential failure mode.
- Rate the probability of loss (or severity) that will result from each failure mode that may occur.
- Calculate the criticality for each potential failure mode by obtaining the product of the three factors:
Mode Criticality = Item Unreliability x Mode Ratio of Unreliability x Probability of Loss
- Calculate the criticality for each item by obtaining the sum of the criticalities for each failure mode that has been identified for the item.
Item Criticality = SUM of Mode Criticalities
To use the qualitative criticality analysis method to evaluate risk and prioritize corrective actions, the analysis team must:
- Rate the severity of the potential effects of failure.
- Rate the likelihood of occurrence for each potential failure mode.
- Compare failure modes via a Criticality Matrix, which identifies severity on the horizontal axis and occurrence on the vertical axis.
These risk assessment methods are commonly associated with Failure Modes, Effects and Criticality Analysis (FMECA).
Applications and Benefits
The Failure Modes, Effects and Criticality Analysis (FMEA / FMECA) procedure is a tool that has been adapted in many different ways for many different purposes. It can contribute to improved designs for products and processes, resulting in higher reliability, better quality, increased safety, enhanced customer satisfaction and reduced costs. The tool can also be used to establish and optimize maintenance plans for repairable systems and/or contribute to control plans and other quality assurance procedures. It provides a knowledge base of failure mode and corrective action information that can be used as a resource in future troubleshooting efforts and as a training tool for new engineers. In addition, an FMEA or FMECA is often required to comply with safety and quality requirements, such as ISO 9001, QS 9000, ISO/TS 16949, Six Sigma, FDA Good Manufacturing Practices (GMPs), Process Safety Management Act (PSM), etc.













