Xfmea Risk Discovery Analysis Example: Difference between revisions
Lisa Hacker (talk | contribs) m (moved XFMEA Risk Discovery Analysis Example to Xfmea Risk Discovery Analysis Example: Standard naming conventions for "Xfmea.") |
Lisa Hacker (talk | contribs) No edit summary |
||
| Line 6: | Line 6: | ||
Let’s examine the new Risk Discovery analysis feature in Xfmea through a fictional example. Suppose that a technology company is developing a new complex product. It is a multi-function printer that prints, copies, scans and has several other features, such as scan to e-mail, document management, etc. | Let’s examine the new Risk Discovery analysis feature in Xfmea through a fictional example. Suppose that a technology company is developing a new complex product. It is a multi-function printer that prints, copies, scans and has several other features, such as scan to e-mail, document management, etc. | ||
The figure below shows the system hierarchy, with some subsystems fully expanded down to the component level and others collapsed at the subsystem level. | |||
[[Image:Printer System for FMEA Example.png | [[Image:Printer System for FMEA Example.png|center|400px|]] | ||
As a best practice, the team first conducts an FMEA at the top (system) level in order to address any potential problems related to interactions and interfaces. Starting the analysis at lower levels has been proven to be a practice that can lead to omission of interactions between subsystems. In most complex systems, interactions will account for more than 50% of the total failure modes that the system will experience. In such cases, it is essential to start with a top-down approach. | As a best practice, the team first conducts an FMEA at the top (system) level in order to address any potential problems related to interactions and interfaces. Starting the analysis at lower levels has been proven to be a practice that can lead to omission of interactions between subsystems. In most complex systems, interactions will account for more than 50% of the total failure modes that the system will experience. In such cases, it is essential to start with a top-down approach. | ||
Revision as of 03:42, 16 August 2012
 |
Let’s examine the new Risk Discovery analysis feature in Xfmea through a fictional example. Suppose that a technology company is developing a new complex product. It is a multi-function printer that prints, copies, scans and has several other features, such as scan to e-mail, document management, etc.
The figure below shows the system hierarchy, with some subsystems fully expanded down to the component level and others collapsed at the subsystem level.
As a best practice, the team first conducts an FMEA at the top (system) level in order to address any potential problems related to interactions and interfaces. Starting the analysis at lower levels has been proven to be a practice that can lead to omission of interactions between subsystems. In most complex systems, interactions will account for more than 50% of the total failure modes that the system will experience. In such cases, it is essential to start with a top-down approach.
Once the top (system) level FMEA has been completed, the next question that the FMEA team faces is which subsystems and components to focus on. This is where the Risk Discovery feature in Xfmea is used.
The team adds a Risk Discovery analysis for each of the main subsystems of the product: the printing system, the copying system, the scanning system and the document management system. Xfmea supports two configurable methods for this type of analysis: a set of yes/no questions (where a yes answer indicates that the assembly/component poses a risk that warrants more detailed analysis) or a set of predefined rating scales (which can be used to calculate an overall rating for each assembly/component). For this example, we will assume that the organization has selected to use the Questions tab with the sample questions that are shipped by default with the software. These questions address the issues that would typically be considered with a change point analysis approach (new technology, new application, historical problems, supplier capability), together with other relevant issues (safety, regulatory requirements and mission criticality).
If the rating scales method is used, for each factor, a risk rating scale is assigned to it, as shown in the figure below.
