A Model is Fixed, but Others are Still at Risk? —— The Five-Step Method for Effective Cross-Model Implementation
A certain automotive parts company supplies two models of a chassis assembly to two OEMs on the same platform, using almost identical welding processes, raw materials, and suppliers. In the first half of the year, the A model's bracket experienced weld point failure at the client site. The team worked through the night to identify the root cause, which was found to be welding current fluctuations exceeding the process window. They immediately adjusted the parameters and increased post-weld sampling inspection. The 8D report was approved and closed by the client, and everyone breathed a sigh of relief.
Three months later, the same weld point failure occurred on the B model, causing the client's production line to halt for 6 hours. Quality Manager Zhang immediately reviewed the 8D report for the A model and discovered that the corrective actions were only implemented in the work instructions for the A production line. Both models shared the same supplier and the same welding parameter baseline document—no changes were made to the supplier's general process document, meaning the B model "inherited" the same隐患. What made Zhang even more embarrassed was the client's SQE's question: "I approved the 8D for the A model. Where is your evidence for cross-model implementation?"
Zhang searched through the archived documents and only found the phrase "已横向展开" (cross-model implementation completed) in the D8 section of the 8D report, with no records of the investigation, no difference analysis, and no verification data.
This scenario is not uncommon in manufacturing. During client audits, "cross-model implementation" is almost always a key question: Have similar issues been investigated in other products, production lines, and suppliers? Most companies' answers do not hold up to scrutiny. If cross-model implementation is not done well, preventive measures only address one point, and the problem can re-emerge in different models, production lines, or suppliers. This article explains the five-step method for effective cross-model implementation: what to implement, how to define the scope, how to prioritize, how to address, and how to close, ensuring that every 8D corrective action can "fly" to all the necessary places.
1. Cross-Model Implementation: The "Second Foot" of Preventive Measures
Preventive measures need to answer two questions: Will the same issue reoccur at the same location? Will similar issues occur elsewhere? The former relies on vertical implementation, while the latter depends on cross-model implementation.
Vertical implementation involves solidifying measures over time—revising standard work instructions, updating control plans, supplementing FMEAs, and installing poka-yoke devices—to ensure that the same failure mode does not recur at the same location. This is what most companies do after completing an 8D.
Cross-model implementation (also known as horizontal implementation) involves projecting corrective actions across all similar objects—other models, other production lines, other shifts, other suppliers, and other equipment families—investigating and addressing each one. To put it another way: vertical implementation is like sealing the hole where the mole pops up, while cross-model implementation is like checking the entire ground to see if there are other unexposed holes.
Why is cross-model implementation essential? Because issues are never isolated events but rather local manifestations of systemic vulnerabilities. The same design platform, the same process document, the same supplier, and the same equipment family determine that defects are "contagious": if Model A exposes a defect, Model B is likely to have the same hidden issue, just waiting for the right conditions to trigger it. The 8D addresses the "exposed point," while cross-model implementation addresses the "unexposed points."
In the 8D process, cross-model implementation is a core action in the preventive measures phase and a frequent point of inquiry in system audits like IATF 16949. Well-performing companies have checklists, records, and verification for cross-model implementation, allowing auditors to easily produce evidence. Poorly performing companies only have a vague "已横向展开" (cross-model implementation completed) in their 8D reports.
2. The Five-Step Method for Cross-Model Implementation
Step 1: Define Implementation Dimensions, Avoid Relying on Intuition
The first challenge in cross-model implementation is "where to implement." If the scope is too narrow, potential issues will be missed; if the scope is too broad, it can lead to a halt in production and cost overruns. In practice, it is recommended to review each of the five dimensions:
| Implementation Dimension | Investigation Object | Typical Example |
|---|---|---|
| Same Model, Different Batches | Work-in-progress, in-transit, client inventory | Whether subsequent batches of the same model have the same deviations |
| Different Models on the Same Platform | Other models sharing design/drawing characteristics | Whether Models B and C on the same platform share the same weld point design |
| Different Lines/Shifts with the Same Process | Shared process documents, parameters, tooling | Whether the night shift and Line 3 are still using the old parameters after changes in the day shift |
| Different Materials from the Same Supplier | Materials, molds, processes supplied by the same supplier | Whether other brackets supplied by the same supplier have the same source |
| Different Products from the Same Equipment Family | Products processed by the same equipment, tools, and programs | Whether other parts processed by the same welding machine |
Create a checklist for these five dimensions, listing the "investigation object, responsible person, and completion deadline" for each. During meetings, check off each item. Zhang's mistake was that he only investigated "same model, different batches," missing the "different models on the same platform" and "different materials from the same supplier" dimensions—both of which were relevant to Model B.
Step 2: Translate Root Causes into "Search Features"
Cross-model implementation is not about mass-distributing the 8D report and asking everyone to "self-check." Instead, it involves translating the conclusions of the 8D into searchable and comparable "feature words." Without this, different people may interpret the issue differently, leading to superficial investigations. Three types of features need to be translated:
- Failure Mode Features: Weld point failure, incomplete welding, porosity, shrinkage, missing parts... Clearly describe the typical manifestations and judgment criteria of the defect.
- Root Cause Mechanism Features: Welding current fluctuations, material batch anomalies, lubricant residue, torque decay... This is the most critical basis for cross-model implementation—mechanisms that are the same must be investigated, regardless of the distance; mechanisms that are different can be cleared.
- Applicability Conditions of Measures: Parameter windows, inspection methods, poka-yoke devices, training requirements... Clearly state the conditions under which the corrective actions are applicable, preparing for subsequent difference analysis.
For the A model case, the features can be translated as follows: Failure mode "weld point failure (0.8% incomplete welding rate)"; root cause mechanism "welding current exceeding the process window ±5%, combined with electrode wear"; measures "re-verify current parameters to the midpoint of the window, reduce electrode replacement cycle from 2,000 to 1,500 cycles, and add 100% visual inspection after welding." With this set of features, investigators can quickly compare any product using the checklist, rather than relying on impressions to say "it should be fine."
Step 3: Risk Assessment and Prioritization, Three-Tiered Disposition
There may be many investigation objects, and efforts should not be evenly distributed. Score each object using three factors: severity (S, how serious the failure consequences are), occurrence (O, the probability of the mechanism recurring in the object, with higher scores for higher similarity), and exposure range (E, the number of batches/units involved). The total score can be divided into three tiers:
- High Priority (high S×O×E): Immediate implementation, complete investigation and disposition within one week, such as objects with the same platform, supplier, and parameters as Model B.
- Medium Priority: Planned implementation, included in the monthly improvement plan, with clear responsible persons and timelines.
- Low Priority: Registered for observation, recorded for review during the next change evaluation or annual audit.
Zhang's team scored and prioritized six investigation objects: Model B scored 72 points (immediate implementation), Model C on the same platform scored 54 points (immediate implementation), another bracket from the same supplier scored 36 points (planned implementation), and three other products with significantly different structures scored 18 points or less (registered for observation). Once the priorities were set, the scope became clear: only two models required immediate attention, while the rest could be handled systematically.
Step 4: Difference Analysis Determines Disposition Method
For each investigation object, a simple "yes/no" answer is insufficient. A difference analysis should be conducted: compare the design, materials, process, equipment, and environment of the object with the product that experienced the issue, and provide one of three conclusions:
| Disposition Conclusion | Judgment Criteria | Required Evidence |
|---|---|---|
| Applicable, Direct Rectification | High structural and mechanism consistency, measures can be directly applied | Rectification records, verification data of measures |
| Differences, Rectification After Evaluation | Differences exist but do not block the failure mechanism | Difference analysis table + rectification records |
| Not Applicable, Record Basis | Differences sufficient to block the failure mechanism (e.g., completely different materials or structures) | Difference analysis table + reasons for non-applicability |
The most common mistake is to assume that "differences mean no action is needed." Differences must be proven to "block the mechanism" to be valid, not just "look different." The difference analysis for Model B is a good example: compared to Model A, Model B had an additional reinforcing rib at the weld point, leading some to argue that "the structures are different, so there won't be an issue." However, after a detailed comparison, it was found that the reinforcing rib did not affect the current path, and the failure mechanism still applied—differences did not block the mechanism, so rectification was necessary. This judgment was later proven correct: the weld failure on Model B occurred at the same weld point.
Step 5: Verification and Closure, Embedding Experience into the System
The closure of cross-model implementation should not be marked by "measures have been issued" but must be supported by three pieces of solid evidence: first, the investigation checklist is fully completed, with a disposition conclusion for each object; second, the corrective actions have verification data, such as the incomplete welding rate dropping from 0.8% to below 0.05% after rectification; third, no similar issues recur during the observation period (usually 3 to 6 months).
At the same time, the experience should be embedded into the system to prevent a reset when a different person or project is involved: supplement the FMEA with the failure mode and measures, update the control plan with inspection frequencies and poka-yoke requirements, revise the standard work instructions, update the supplier's general process document, and store the entire set of feature words and disposition records in the lessons learned database.
This time, Zhang completed the full set: the supplier's general process document was revised and re-approved, the parameters for Models B and C were re-verified, and no weld failures occurred in the two models during the three-month observation period. When the client's SQE reviewed the case, they saw the complete investigation checklist and difference analysis table, and signed off on the cross-model implementation section.
3. Five Common Misconceptions
- Misconception 1: Turning cross-model implementation into a "company-wide cleanup." Without setting boundaries, investigating all products and production lines leads to cost overruns and complaints. The correct approach is to define the scope according to the five dimensions and prioritize based on risk scores, focusing efforts on the most similar and most dangerous objects.
- Misconception 2: Investigating only the same model and missing the same process and supplier. Even if the models are different, the same process document and supplier can still spread the隐患. This was Zhang's critical mistake.
- Misconception 3: Investigating based on memory, not creating a checklist. Asking a round of "does anyone think there's a problem?" during meetings and considering the investigation complete if no one speaks up. Without a written checklist and item-by-item conclusions, there is no evidence to present during audits, rendering the investigation ineffective.
- Misconception 4: "Differences mean no action is needed." Difference analysis is superficial and does not verify whether differences block the mechanism. Remember: differences are the basis for evaluation, not an excuse for inaction.
- Misconception 5: Writing only "已横向展开" (cross-model implementation completed) without an evidence chain. The five words in the 8D report do not earn the client's trust or prevent nonconformities in the next audit—investigation records, difference analysis tables, and verification data are all essential.
4. One-Sentence Summary
Cross-model implementation is the "second foot" of preventive measures: define dimensions, translate features, prioritize risks, conduct difference analysis, and verify closure. Completing these five steps ensures that similar issues are truly eliminated.
Solid cross-model implementation prevents similar issues from recurring.
Knowledge code: 5.2.1
Version: v20260828
Author: Quality Think Tank Quality Think Tank is dedicated to providing systematic knowledge, methodologies, and practical tools for quality management professionals, helping companies continuously improve their quality capabilities.