IATF16949 Practical Application (3) | AIAG-VDA Seven-Step Method: Building and Judging the Structure Tree, Function Network, and Failure Chain

A new project in an automotive parts company has entered the process approval stage. The customer's SQE reviewed the process FMEA and asked only three questions: To which process step does this failure mode belong? Which function has not been realized? Which control measure in the downstream control plan corresponds to the cause of this failure?

The table was filled out in great detail, with the severity (S), occurrence (O), and detection (D) columns all filled with numbers, and the action priority column marked as "medium." However, the engineer could only answer one of the questions on the spot. Further investigation revealed that this FMEA was created by one person at the end of the project, based on the table from the previous generation of the product: the structure column only listed the process names, without the process work elements layer; the function column contained vague statements like "ensure welding quality"; the failure effects were directly copied from the final inspection items; and the cause column was filled with general terms like "improper operation."

This is not a matter of careless scoring, but rather a compression of the seven-step method into a single step: "just fill out the table." The three layers of analysis—structure, function, and failure—were not properly built, making each row in the table unverifiable and thus unusable in the field. This article provides step-by-step examples, criteria, and a list of deliverables for the AIAG-VDA seven-step method that can be directly applied.

1. Clarify: The First Four Steps Are Analysis, the Last Three Are Documentation

The seven-step method is often treated as seven parallel "tables to fill out," but it actually consists of two segments: the first four steps are for building the structure, and the last three steps are for risk prioritization and action closure. To determine whether an FMEA is "analysis" or "filling out the table," check if it has the first three networks (structure tree, function network, and failure chain), rather than the number of rows.

Common symptoms of skipping steps are easily recognizable, and each will be questioned during audits or by the client:

2. Step 1: Planning and Preparation—Define the Scope in a Verifiable Sentence

The output of this step is not a plan document but four short inputs. It is recommended to organize them according to the "5T" method, with each item having a verifiable standard:

The scope definition should be fixed with a verifiable sentence: "The scope of this DFMEA analysis: from the X assembly to the Y subsystem interface, excluding the Z part provided by the customer; the boundary-affected interfaces are A and B." If this sentence is not clearly written, the top level of the structure tree will have multiple candidates, and the team will repeatedly debate the same issue at each meeting.

3. Step 2: Structure Analysis—How to Build the Three-Level Structure Tree

The task of structure analysis is to break down the analysis object into a "level + element" relationship, providing a归属位置 for the subsequent failure chain. The three-level structure has different names in DFMEA and PFMEA, but the logic is consistent:

There are four rules for building the structure tree:

1. Draw the boundary diagram or process flowchart first, then fill out the structure tree. For DFMEA, use the boundary diagram to determine the interfaces; for PFMEA, use the process flowchart to determine the sequence of process steps. The numbers in these diagrams should correspond one-to-one with the structure tree. Doing it the other way around will inevitably result in missing steps.
2. Process work elements must be specific objects. Writing "equipment" is not acceptable; instead, write specific elements like "spot welding electrode," "fixture locating pin," "cleaning solution concentration." Writing "human" is not acceptable; instead, write observable elements like "torque gun holding method of the assembly operator."
3. Each element should appear only once. Repeated appearances indicate unclear level definitions, usually due to mixing "system" and "component."
4. Assign a responsible person to each element. The responsible person's role is to confirm that the element's description matches the actual process, not to be responsible for scoring.

For example, in a welding process, the structure tree can be written in three segments:

After the structure tree is built, the team will have a clear number of analyzable elements (in the example, 3 process steps and 9 process work elements). This number is the first step in self-checking: if the number of rows and elements do not match, it indicates that the analysis has not kept up.

4. Step 3: Function Analysis—Function Network and "Measurable" Criteria

Function analysis connects the elements in the structure tree into a network: the overall function of the upper level is achieved by the functions of the lower-level elements. To judge whether a function is correctly written, look at one criterion: is it measurable?

When filling out, two boundary scenarios may be encountered, and the handling guidelines are as follows:

• An element performs multiple functions: Write them in separate rows, not in the same cell. The number of functions written in separate rows directly determines the number of rows for failure modes, and combining them will inevitably lead to missing failure modes.
• Functions defined by parameter windows: Break down the parameter windows into "function + requirements" columns. Write the intent in the "function" column (e.g., "form a qualified nugget") and the numerical values and measurement methods in the "requirements" column. If the requirements column lacks a measurement method, it is considered incomplete.

The hallmark of a correctly built function network is: from any function at the focus level, it can be traced upward to which upper-level function it serves and downward to which lower-level elements support it. This bidirectional traceability is the prerequisite for the subsequent failure chain to be derivable.

5. Step 4: Failure Analysis—Three-Level Derivation Rules for the Failure Chain

Failure analysis is the step in the seven-step method that is most prone to deviation. The correct approach is: for each function, ask three questions—what the upper level will see (failure effect), what the current level has not achieved (failure mode), and why the lower level is like this (failure cause). These three form the failure chain.

The derivation rule is simple but must be strictly enforced:

The failure effect at the lower level is the failure mode at the upper level; the failure effect seen at the upper level has its root in the failure mode at the current level, and the failure mode at the current level originates from the failure of the lower-level elements.

For example, this chain can be illustrated in the three-level structure:

Three common high-frequency errors and their corrections:

After the failure chain is built, the FMEA changes from a "flat table" to a "network": any row can be traced upward to the effect and downward to the cause. At this point, revisiting the self-check logic in the first part can help verify the credibility of the scores—severity is determined by the failure effect, occurrence by the preventive control corresponding to the cause, and detection by the detection control for the mode or cause. Each has its own basis and will not compromise the others.

6. Step 5: Risk Analysis—Three Scoring Criteria and Action Priority

The volume of scoring itself is not large, but the criteria must be clearly defined from the start, otherwise, "the same type of issue will be scored differently in different projects." Three rules for scoring criteria:

The key point of replacing RPN with action priority (AP) is not just a change in letters, but a change in the ranking logic: RPN multiplies the three dimensions, which can easily result in a distortion where "high severity + high detection" is calculated as low risk. AP directly ranks high, medium, and low based on the combination of "severity—occurrence—detection," ensuring that high severity is not overshadowed by low detection.

The judgment logic can be summarized in three points to help unify the team's criteria (specific values should be based on the action priority table in the manual):

1. High severity and non-negligible occurrence, always high. At this point, it cannot be resolved by tightening inspections; measures must be taken to eliminate or reduce the cause at the design or process level.
2. High severity but the cause is fully suppressed by preventive controls, usually medium. The focus should be on continuously verifying the effectiveness of preventive controls, not adding more inspections.
3. Low severity scenarios are handled at the lower limit. Even with high occurrence, they should not occupy the team's main improvement resources.

Examples of the three scenarios (for internal criteria practice, actual scoring should be based on the manual table):

7. Steps 6-7: Optimization and Documentation—Actions Must Have Evidence of Effectiveness

The completion marker for the optimization step is not "actions have been implemented," but "the risk level has changed, and there is evidence." The minimum field set for the actions column is five items: action content, responsible position, completion date, method of effectiveness verification, and S/O/D after verification.

The results of documentation should not only produce the FMEA report itself but also a linkage matrix. This matrix is the only interface between the seven-step method and the field. Without it, the FMEA will degrade into an archived document:

8. Seven-Step Method Deliverables and Completion Criteria Checklist

Consolidate the first seven parts into a printable self-checklist, and check each item when completing an FMEA:

9. Checklist for Table-Filling FMEA: Ten Judgment Criteria

If you need to quickly determine whether an FMEA is an analysis or just filling out the table before an audit, judge each of the following ten criteria. If any one is "no," there is a risk:

If items 1, 2, and 5 are "no," it is recommended not to patch up the original table but to rebuild from the structure tree. These three items are the foundation, and cannot be corrected by merely changing the text.

10. Key Points for Implementation and Common Errors

1. Start with the structure tree, not the table. The implementation order is boundary diagram or flowchart, structure tree, function network, failure chain, scoring, and actions. At each weekly meeting, confirm the upper level first, then discuss the lower level.
2. An FMEA done by one person will inevitably degrade to just filling out the table. The minimum role configuration is: someone who understands the design intent, someone who understands the actual process actions, and someone who understands the detection method capabilities. Missing any of these roles will result in scoring inaccuracies.
3. Functions that are not measurable are equivalent to having no function. Make "measurability" the acceptance action for the function column, confirmed by the reviewer for each item, to avoid repeated rework later.
4. If failure modes and causes are unclear, refer to the structure tree. Elements that can be traced to process work elements are causes, those that fall on process steps are modes, and those that fall on process items or customer ends are effects.
5. Do not discuss scoring in the field. Field scoring will be influenced by "project progress" and "customer pressure"; lock the scoring basis (effect column, control column) first, and scoring is just a table lookup result.
6. Adding inspections is the most common shortcut. Tightening inspections can only change detection, not effective for high-severity risks. During review, directly ask: "Does this action reduce occurrence or detection?"
7. The linkage matrix must be updated with changes. The version relationship between drawings, FMEA, control plans, and work instructions should be made into a matrix table. Any change should first update the matrix, then the documents, which is the most common breakpoint during audits.
8. Family FMEAs must have independent structure trees. Baseline reuse can save time, but before reuse, confirm if the process steps and work elements are consistent. Inconsistent parts must be rebuilt.

The output of the seven-step method is not a thicker table, but three networks that can be derived from each other. Only when "any row can be traced upward to the effect, downward to the cause, and outward to the corresponding field control" can the FMEA withstand audit scrutiny and truly prevent problems.

The structure tree, function network, and failure chain are the foundation of FMEA.

Knowledge code: 15.1.1

Version: v20261009

Author: QTank QTank is dedicated to providing quality management professionals with systematic knowledge, methodologies, and practical tools to continuously enhance the quality capabilities of enterprises.