© 2008 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Failure Modes &...
-
Upload
sofia-connolly -
Category
Documents
-
view
217 -
download
1
Transcript of © 2008 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Failure Modes &...
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 1
Failure Modes & Effects Analysis (FMEA)
A Great Tool to Improve Product and Process Reliability and Reduce Risks
Anthony Tarantino
PhD, Six Sigma Master Black Belt, CPIM, CPM,
Sr. Advisor to Cisco’s Six Sigma Center of Excellence
Adjunct Professor of Finance, Santa Clara University
May 23, 2011
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 2
A Leading Six Sigma Authority:
“To me Failure Modes and Effects Analysis (FMEA) is a versatile, powerful, process centered tool that belongs in every Process Owners’ and Six Sigma practitioners’ toolbox."
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 3
A Leading Operational Risk Authority:
“Catastrophic failures in operational risk management are rarely caused by a single and major point of failure. Rather they are the cumulative effect of smaller and inter-related failures. …FMEA is the tool of choice to address these complex operational risk failures at any level of an organization, whether tactical, strategic, or enterprise-wide. It works in every type of organization.”
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 4
Objectives
The objectives for this session include:
Understand what a FMEA is, why it is used, and when it can it be deployed
Understand the different components, definitions, and calculations used in a FMEA
Learn the steps to developing a FMEA
Use examples and Case Studies to showcase FMEA in action:
• Purchasing Process in Finance
• Sample High Tech Project to Reduce RMA Rates
• San Bruno Gas Pipeline Explosion
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 5
Reliability Defined
Product reliability is one of the qualities of a product. Quite simply, it is the quality which measures the probability that the product or device “will work.”
As a definition:
Product reliability is the ability of a unit to perform a required function under stated conditions for a stated period of time.
And, correspondingly, quantitative reliability, as a definition, is:
Quantitative reliability is the probability that a unit will perform a required function under stated conditions for a stated time.
Source: Fergenbaum, A. V. (1991). Total Quality Control. New York: McGraw-Hill, Inc.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 6
When Reliability is Lacking - Categories of Failure ModeSafety
Any failure mode that directly affects the ability of a product to meet Federal Safety Standards, or creates a potential product liability issue, or can result in death or extensive property damage.
Major (Hard)
Any failure mode that stops the operation of a product or system which requires immediate repair.
Evidenced by a catastrophic event, i.e, TEPCO Nuclear Plant Meltdown
Failure mechanism might be due to a “shock” to the system or an accumulation of shocks to the system
Minor (Soft)
Any failure mode that results in a product from meeting one of its intended functions, but does not preclude it from satisfying its most important functions.
Any failure mode which results in a gradual but not complete ability of the product to meet its intended function.
Degradation of performance over time, wear are examples of soft failures.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 7
FMEA Defined
What is a Failure Modes & Effects Analysis?
A FMEA is a systematic method to:
1. Recognize, evaluate, and prioritize (score) potential failures and their effects
2. Identify actions which could eliminate or reduce the chance of potential failure occurring
3. Document and share the process
FMEA generates a living document that can be used to anticipate and prevent failures from occurring.
In DMAIC and Design For Sigma Projects, FMEA’s can be used in various stages and revised as the project moves forward.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 8
Why Use a FMEA
Use of quality tools such as Statistical Process Control (SPC) encourage the use of FMEA(s) to help problem-solve quality problems
ISO/QS 9000 and product liability directives of the EC 1985 strongly encourage its use.
Helps select alternatives (in system, design, process, and service) with high reliability and high safety potential during the early phases (Blanchard 1986)
Ensures that all conceivable effects on operational success have been considered.
Many risk management regimens and standards, such as ISO 31000/31010 used in finance and operations are based on FMEA logic – probability vs. severity scoring and matrix.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 9
Why Use a FMEA - Continued
Improves the quality, reliability and safety of products and processes in a proactive manner.
Helps to increase customer satisfaction, by proactively addressing failures that keep us from meeting critical customer requirements in processes or products.
Reduces product development timing and cost
Reduces operational risk
Documents and tracks actions taken to reduce risk; Prioritize areas of focus
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 10
FMEA is a Team Process
Team Formation
Product Development
Design
Manufacturing
Quality
Sales/Marketing
Suppliers
Reliability and testing
Team Roles
Facilitator
Champion
Recorder/librarian
6-10 members is optimal
What are your experiences in FMEA Teams?
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 11
Why Use a Team for FMEATeam decision-making takes time. For a team to reach consensus:
100 percent active (express agreement/disagreement) participation.
Participants must be open to new ideas/to influence others.
100 percent agreement not the goal. Majority does not rule. Sometimes a single individual may be on the right track.
Need a formal system for voting.
Need effective facilitator (leader).
Team process check (how did we do?)
Difficult individuals
Facilitator must resolve such instances.
Effective meeting skills
Planning the meeting
Effective problem-solving skills
Soft Skills Are Critical
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 12
The Primary Driver for FMEA - What does 99.9% Quality Mean?
One hour of unsafe drinking water
291 incorrect pacemaker operations per year
12 babies given to the wrong parent each day
Two unsafe landings at O’Hare Airport per day
Your heart fails to beat 32,000 times per year
6,000 lost pieces of mail per hour
20,000 incorrect drug prescriptions per year
107 incorrect medical procedures performed
daily
14,208 defective personal computers shipped
each year
268,500 defective tires shipped per year
500 incorrect surgical operations
performed each week
Two million documents lost by the IRS
per year
880,000 credit card magnetic strips with
the wrong information
19,000 newborn babies dropped at
birth by doctors each year
22,000 checks deducted from the wrong
account each hour
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 13
Elements of a Successful FMEA
1. All problems are not the same. This is perhaps the most fundamental concept in the entire FMEA methodology. Unless a priority of problems (as a concept) is recognized, workers are likely to be contenders for chasing fires. They will respond to the loudest request and/or the problem of the moment. (In other words, they will manage by emergency.) - Does this sound like your organization?
2. The customer must be known. Acceptance criteria are defined by the customer, not the engineer.
3. The function must be known.
4. One must be prevention (proactively) oriented. Unless continual improvement is the force that drives the FMEA, the efforts of conducting FMEA will be static. The FMEA will be conducted only to satisfy customers and/or market requirements to the letter rather than the spirit of the requirements. Unfortunately, this is a common problem in implementation of an FMEA program.)
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 14
Process Step
Describe how the process step
could go wrong
Describe the impact
What could cause the failure?
Is there anything in place to detect or stop this from
happening?
What actions will you take?
Rankings (1-10)
Sample FMEA Form
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 15
Sample FMEA Process - Adding Milk to a Cake Mix
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 16
History of the FMEA
1940s - First developed by the US military in 1949 to determine the effect of system and equipment failures
1960s - Adopted and refined by NASA (used in the Apollo Space program)
1970s – Ford Motor Co. introduces FMEA after the Pinto affair. Soon adopted across automotive industry
Today – FMEA used in both manufacturing and service industries
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 17
Types of FMEAs
Design FMEA - examines the functions of a component, subsystem or main system.
• Potential Failures: incorrect material choice, inappropriate specifications.
• Example: Air Bag (excessive air bag inflator force).
Process FMEA - examines the processes used to make a component, subsystem, or main system.
• Potential Failures: operator assembling part incorrectly, excess variation in process resulting in out-spec products.
• Example: Air Bag Assembly Process (operator may not install air bag properly on assembly line such that it may not engage during impact).
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 18
Definitions
Failure Mode The way in which the product or process
could fail to perform its intended function.
Failure modes may be the result of upstream operations or inputs, or may cause downstream operations or outputs to fail.
Failure Effects The outcome of the occurrence of the failure
mode on the system, product, or process.
Failure effects define the impact on the customer.
Ranking is translated into “Severity” score
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 19
Definitions
Failure Causes Potential causes or reasons the failure
mode could occur
Likelihood of the cause creating the failure mode is translated into an “Occurrence” score
Current Controls Mechanisms currently in place that will
detect or prevent the failure mode from occurring
Ability to detect the failure before it reaches the customer is translated in “Delectability” score
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 20
Linking Causes to Effects One to One, One to Many, Many to One, or Many to Many
Cause 1
Cause 2
Effect 1
Effect 2
Cause 1
Effect 1
Effect 2
Cause 1
Cause 2
Effect 1
1:1
1:M
M:1
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 21
CalculationsRisk Priority Number
The Risk Priority Number (RPN) identifies the greatest areas of concern.
RPN is the product of:
(1) Severity rating
(2) Occurrence rating
(3) Detection rating
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 22
Calculations - FMEA Variables Severity
A rating corresponding to the seriousness of an effect of a potential failure mode. (scale: 1-10. 1: no effect on the customer, 10: hazardous effect)
Occurrence
A rating corresponding to the rate at which a first level cause and its resultant failure mode will occur over the design life of the system, over the design life of the product, or before any additional process controls are applied. (scale: 1-10. 1: failure unlikely, 10: failures certain)
Detection
A rating corresponding to the likelihood that the detection methods or current controls will detect the potential failure mode before the product is released for production for design, or for process before it leaves the production facility. (scale: 1-10. 1: will detect failure, 10: almost certain not to detect failures)
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 23
Calculations - Risk Priority Number (RPN)
Severity x Occurrence x Detectability =
Risk Priority Number (RPN)
For a given potential failure mode, how bad the outcome is multiplied by how likely it would actually happen multiplied by what things are in place today to prevent or notice it before it happens.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 24
FMEA ProcessStart with the process map
1 For each step, brainstorm potential failure modes and effects
2
Determine the potential causes to each failure mode
3
Evaluate current controls
4
Determine severity
Determine likelihood of occurrence
Determine detectability
Determine RPN
5
Identify actions
6
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 25
When is a FMEA Started? As early as possible; that is, as soon as some
information is known (usually through a QFD).
Practitioners should not wait for all the information. If they do, they will never perform a FMEA because they will never have all the data or information.
When new systems, designs, products, processes, or services are designed.
When existing systems, designs, products, processes, or services are about to change regardless of reason.
When new applications are found for the existing conditions of the systems, designs, products, processes, or services.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 26
When is a FMEA Completed? Only when the system, design, product, process, or service is
considered complete and/or discontinued.
A System FMEA may be considered finished when all the hardware has been defined and the design is declared frozen.
A Design FMEA may be considered finished when a release date for production has been set.
A Process FMEA may be considered finished when all operations have been identified and evaluated and all critical and significant characteristics have been addressed in the control plan.
A Service FMEA may be considered finished when the design of the system and individual tasks have been defined and evaluated, and all critical and significant characteristics have been addressed in the control plans.
As a general rule, the FMEA should be available for the entire product life. The FMEA is a working document.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 27
FMEA Tips No absolutes rules for what is a high RPN number.
Rather, FMEA often are viewed on relative scale (i.e., highest RPN addressed first)
It is a team effort
Motivate the team members
Ensure cross-functional representation on the team
Treat as a living document, reflect the latest changes
Develop prioritization with the process owners!
Assign an owner to the FMEA; ensure it is periodically reviewed and updated
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 28
FMEA & The DMAIC LifecycleQ: At what phase can/should the FMEA be used in a DMAIC project?
How it can be used:• Project
selection• Project
scope
How it can be used:•
Understand the process (w/ process mapping)
How it can be used:• Identify
process variables / root cause analysis
How it can be used:• Assist with
new process development / understand failures in design
A: A FMEA can be used in most phases of the DMAIC lifecycle for various purposes
How it can be used:• Manage
and control the process on an ongoing basis
FMEA can also be used in each stage of Design for Six Sigma - DMADV
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 29
FMEA Example
Purchasing Requisition to Purchase Order
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 30
ExamplePurchasing Dept.
cust
om
erF
ocu
s T
eam
Pu
rch
asin
gD
epa
rtm
ent
Su
pp
lier
CompletePurchase
Requisition (PR)
Send PR toPurchasing
Dept.
IncorrectPR
Returned
Correct andSend Back
ReceiveGoods
Receive PR
Form Correct
CompleteP.O.
Send P.O.To supplier
Confirm receipt of
P.O.
CompleteCommitProcess
YesNo
ShipGoods
Start
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 31
ExamplePurchasing Dept.
From the process map,
list the process steps
Brainstorm the various ways the
step could fail
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 32
ExamplePurchasing Dept.
Determine the potential effects
Determine the severity ranking using the scale
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 33
Severity Rankings
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 34
ExamplePurchasing Dept.
Determine how likely the failure would occur due
to this cause
Determine the potential causes
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 35
Occurrence Rankings
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 36
ExamplePurchasing Dept.
Determine how likely the controls in place will detect or prevent the failure mode from
occurring
Identify what controls or measures are currently in place
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 37
Detectability Rankings
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 38
ExampleCalculate the RPN
5 x 4 x 3 = 60
Severity Occurrence Detectability RPN
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 39
ExamplePurchasing Dept.
Brainstorm potential actions that will lower the
RPN
Assign specific owners
FMEA owner & team update the document as actions are
complete
Recalculate the RPN after
actions are complete
Occurrence Reduced from 4 to 3.
PRN cut in half.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 40
Case Study:
FMEA Logic in Scoring the Risk of Problems
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 41
Case Study: Using a FMEA Hybrid –Adding Project Prioritization Index (PPI) PPI can be used in combination with FMEA to score problem solving projects by balancing potential savings against project costs, and project effort/duration against project risks (chance of success).
PPI consists of four metrics:• Project Costs ($)• Project Benefits ($)• Project Probability of Success (Percent)• Project Duration (Years)
The PPI formula balances:
• Project Benefits versus Project Costs• Project Probability of Success versus Project Duration
The formula looks like this:
PPI = (Benefits/Costs) x (Probability of Success/Project Duration)
Source: Praveen Gupta, Total Quality Management, in Anthony Tarantino, Risk Management in Finance: Six Sigma and Other Next Generation Techniques (Wiley and Sons, 2010)
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 42
Case Study: Using a FMEA Hybrid - Adding Project Prioritization Index (PPI)
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 43
Case Study: Using FMEA+PPI To Score Potential Problem Solutions
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 44
Case Study:
San Bruno Gas Pipeline Explosion
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 45
Play the Youtube VOD from CBS News
http://www.youtube.com/watch?v=EZ6YbUrnxVM
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 46
San Bruno, CA - September 10, 2010 The ruptured natural gas pipeline created a crater approximately 72 feet long by 26 feet wide.
A pipe segment approximately 28 feet long was found about 100 feet away from the crater.
The released natural gas was ignited sometime after the rupture; the resulting fire destroyed 37 homes and damaged 18.
Eight people were killed, numerous individuals were injured, and many more were evacuated from the area.
Source: http://www.ntsb.gov/surface/pipeline/preliminary-reports/san-bruno-ca.html
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 47
Loss of Power at Control Terminal Just before the accident, PG&E was working on their uninterruptable power supply (UPS) system at Milpitas Terminal, which is located about 39.33 miles SE of the accident site.
During the course of this work, the power supply from the UPS system to the supervisory control and data acquisition (SCADA) system malfunctioned so that instead of supplying a predetermined output of 24 volts of direct current (VDC), the UPS system supplied approximately 7 VDC or less to the SCADA system.
Because of this anomaly, the electronic signal to the regulating valve for Line 132 was lost. The loss of the electrical signal resulted in the regulating valve moving from partially open to the full open position as designed.
The pressure then increased to 386 psig. The over-protection valve, which was pneumatically activated and did not require electronic input, maintained the pressure at 386 psig.
Source: http://www.ntsb.gov/surface/pipeline/preliminary-reports/san-bruno-ca.html
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 48
Case Study: San Bruno Gas Pipeline Explosion
There were longitudinal fractures in the first and second pup of the ruptured segment and a partial circumferential fracture at the girth weld between the first and second pup. There was a complete circumferential fracture at the girth weld between the fourth pup in the ruptured segment and the fifth pup in the north segment.
Source: http://www.ntsb.gov/surface/pipeline/preliminary-reports/san-bruno-ca.html
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 49
Case Study: San Bruno Gas Pipeline Explosion
The longitudinal fracture in the first pup continued south into the pipe ending in a circumferential fracture in the middle of the pipe.
Source: http://www.ntsb.gov/surface/pipeline/preliminary-reports/san-bruno-ca.html
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 50
Poor Document and Records Retention
SAN FRANCISCO (AP) March 5, 2011 – Facing a state Public Utilities Commission order to produce records on its pipelines by March 15. the utility has been shipping pallets loaded with boxes of documents to the Cow Palace in Daly City, where PG&E employees are pouring through the paper records.
“This effort is an example of the level of commitment the company is putting forward to make sure this process is thorough and complete,” PG&E spokesman Paul Moreno said. …it was part of a 24-hour search by more than 300 employees.
The document search comes after investigators found a seam with inferior welds that was believed to be the origin of the blast.
PG&E’s computer records had shown the pipeline did not have a seam, but PG&E officials have acknowledged problems when the old paper records were incorporated into the utility’s computer system.
PG&E President Chris Johns said last month the utility had been unable to find documents for 30 percent of its 1,000-plus miles of pipeline running under urban areas.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 51
DOT to Issue New Pipeline Regulations in August
SAN FRANCISCO (Dow Jones)--The U.S. Department of Transportation will issue new safety rules for the nation's oil and gas pipeline operators in August, the agency's top official said Thursday.
"We and the Obama administration will redouble our efforts on pipeline safety," Transportation Secretary Ray LaHood said, speaking at a press conference in San Francisco.
LaHood earlier visited the site in San Bruno, Calif., where a PG&E Corp. (PCG) gas pipeline exploded last September, killing eight people and destroying ...
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 52
Mode of Failure - Pipeline Rupture followed by Explosion
Potential Causes of Failure:
1. Faulty Weld – (1/2 thickness spec)
2. Pipe Corrosion (Over 50 Years Old)
3. Corrosion of Girth/Lateral Weld
4. Corrosion of Circumference Weld
5. Failure of Monitoring Station UPS
6. Lack of Automatic Shut Off Valves
7. Faulty Maintenance Documentation
8. Faulty Maintenance Procedures
9. Lack of Tone-at-the-Top Management
10.Weak Oversight by Calif. PUC
11. Weak Federal Regulations by DOT
Causes 1-5 • Tactical in Nature• Six Sigma Tool• Design of Experiments
Causes 6-11• Systemic in Nature• Enterprise-wide • Operational Risk Mgt.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 53
FMEA Advantages Over RCA and 5 Whys A robust FMEA will consider each
of the 5 tactical modes of failure and combination of modes of failure.
Design of Experiments (DOE) can be used to test the most likely combination of modes and causes.
A typical Root Cause Analysis (RCA) may focus on one or more of the failure modes and causees, but would not score their risk profiles.
A typical 5 Whys will focus on only one of the failure modes, and may not point to a solution.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 54
FMEA Suggested Tests
Design of Experiments (DOE)Potential Tests & Combination of Tests:
1. Faulty Weld
2. Corrosion of Pipe
3. Corrosion of Girth/Lateral Weld
4. Corrosion of Circumference Weld
5. Rise In Pressure
6. Faulty Weld (Remove Half Weld)
+ Accelerated Corrosion Test of
Pipe and Welds + Rise in
Pressure
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 55
Additional Information
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 56
FMEA & Other Risk Analysis Tools
FMEA Cause & Effect Diagram Fault Tree Analysis
• Bottoms-up approach to failure analysis
• Systematic method for identifying all the potential failure modes of a process or product
• Creates prioritized ranking of failure modes within a system
• Examines a certain failure mode or event and identifies all the possible causes
• Causes are grouped into several logical categories
• Top-down approach to failure analysis
• Starting point is a failure or “undesired state”
• Drill down into lower level events leading up to the undesired state
• Similar to the 5 Why’s method
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 57
Backup
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 58
For Further Information
Anthony Tarantino, PhD, MBB
Sr. Consulting Support
[email protected], 562-818-3275
Carl Ashcroft, MBB
Cisco’s Six Sigma Training and Education Programs
[email protected], 408-525-3929
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 59
Published FMEA Guidelines
J1739 - From the SAE for the automotive industry.
AIAG FMEA-3 - From the Automotive Industry Action Group for the automotive industry.
ARP5580 - From the SAE for non-automotive applications.
EIA/JEP131 – Provides guidelines for the electronics industry, from the JEDEC/EIA.
P-302-720 - provides guidelines for NASA GSFC spacecraft and instruments.
SEMATECH 92020963A-ENG - for the semiconductor equipment industry.
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 60
Rankings
© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 61