AyMINE

Modules

Task, project & quality management
Contacts and directories module (CRM)
Web management and automation
Human resources
Products, assets and sales
Finance management
Metrics and Measurements

Technical Modules

Sabre plugin module
Enterprise Architect connector

System Modules

The AyMINE Framework Module
System Management

Let us know what you're looking for

Do you prefer to ask us directly?

Call us +420 605 203 938 (the Czech Republic)

or use this contacts

FMEA Analysis - Process

The FMEA process is standardized, and AyMINE fully supports its latest version according to the AIAG & VDA FMEA Handbook.

A complete description of FMEA is available on a separate page here.

FMEA Process

The sections do not describe the entire process but its implementation within AyMINE. For a more comprehensive understanding of FMEA, we recommend our training courses, and details of the process are also described directly within the FMEA itself. The purpose of this page is to provide a global overview of the process, which may not be sufficiently clear from individual tasks.

Step 1 - Planning and Preparation

The preparation of FMEA is guided by the standard FMEA process. The process can be initiated by the project leader or the product owner. It should be linked to the analyzed product or process. This connection can be established either to a product already recorded in the product database or to elements of the analysis, such as a production process.

A key part of Step 1 is defining the team responsible for conducting the FMEA analysis. The leader nominates team members for the analysis task, not for the preparation task, which remains their responsibility.

The timeline and size of the team determine the planning of subsequent steps:

  • Responsibility for reviewing and, if necessary, supplementing the analysis of the subject. The responsible team member is assigned the task FMEA - Step 2.
  • Responsibility for preparing the functional analysis - FMEA - Step 3.
  • Scheduling meetings with experts for failure and risk analysis. These experts should be given time to familiarize themselves with the analysis beforehand, so there should be sufficient time between completing Steps 2 and 3 and starting Step 4 (depending on whether independent experts unfamiliar with the subject are involved).

The second crucial part is planning analytical meetings, during which Steps 4 and 6 will be carried out.

Good planning and preparation may seem partly obvious, partly unnecessary. However, quality preparation determines whether the analysis will be effective.

  • It is essential to clearly define the scope of the analysis, i.e., where exactly the boundaries of the analyzed subject (process, product) lie.
  • Identify who truly understands the topic and assemble a competent team.
  • Plan the preparation, especially the preparation of materials, as well as all subsequent steps.

Step 2 - Structural Analysis

The output is the structure of the subject, either in the form of parts (for a product) or process steps and the equipment used (for a process).

If structural analysis is applied to a product, the results can be visualized using Enterprise Architect. (This requires a connection to the EA model via the eacon connector).

When using a documented component database, it is possible to build on an existing previous FMEA analysis. Therefore, it is advisable to use already recorded parts whenever possible and avoid creating duplicates in the structural analysis.

Step 3 - Functional Analysis

The output includes descriptions of properties, operational modes, and states at the detail level of individual components. At the parts level, properties of parts relevant to the FMEA should be described. Descriptions are directly linked to elements, so functional analysis can logically only be conducted after structural analysis.

The primary tool for controlling functional analysis is meeting the functional specification of the product or process using properties (a general term encompassing):

  • General properties
  • Functionality
  • Operational modes.

If a repeated FMEA analysis is conducted for a part for a different purpose, documentation from the previous analysis can be utilized, or a new analysis can be created for the same element. For this reason, it is possible to specify which analysis each property belongs to. (If not specified, it is included in all.)

Step 4 - Failure Analysis

Possible failures are recorded for each property. Failures can be entered collectively for each property, but it is better to detail them individually as failure cases (a tab in the detail view).

The possible failure cases become part of the documentation for the property and, by extension, for the part (or process step). These will be further used in Step 5.

Each part and each property are recorded separately, so it is not a problem to split the FMEA analysis into multiple groups if this makes sense given the differing properties.

Note on rights: Only those who are active collaborators in the area or project where the analysis is being conducted can work on the analysis. Additionally, they must have pright to access analyses. This ensures proper control over who contributes to the analysis.

Quality of documentation: We recommend that everyone involved in the analysis be members of the team for this task. The composition of the team is part of the analysis documentation, based on the list of participants. Organize meetings where FMEA is the sole agenda item. This prevents discussions from drifting away from the FMEA focus.

Step 5 - Risk Analysis

The risk analysis builds on the failure analysis - adding data to the failures that were recorded in step 5 of the FMEA process. In principle, no new lines should be added to the FMEA at this stage – these correspond to possible failures, but those have been identified.

Step 6 - Optimization

Like Step 5, Step 6 builds on the preparation from Steps 2 and 3. For each failure and risk analysis, the system calculates an action priority for risk minimization. (The system also calculates the older RPN index, as many teams are still accustomed to using it.)

A key part of optimization is proposing changes to reduce the likelihood of occurrence. For each failure, the system can distinguish between existing mitigation measures and newly proposed ones. The analysis documents new measures and records their anticipated effectiveness – the analysis output thus includes both the current state and the state after implementing all measures.

Tasks and Requirements for Resolution

Measures from the analysis are translated into change requests or tasks to address the problem. Both can be created directly in the detail of the failure case or the property detail. The request or task is linked to the possible failure, making it clear why it was created and allowing tracking of its resolution.