Introduction
Engineering change orders (ECOs) are a normal part of product development and manufacturing. No design survives contact with production and field use without modification. But there is a meaningful difference between an engineering team that manages changes reactively — issuing ECOs as problems surface without understanding why they keep surfacing — and one that applies root cause analysis to understand why changes are needed, and addresses those causes to prevent the same pattern of changes from recurring.
This article covers how to apply root cause analysis (RCA) discipline — particularly the 5-Why method — to engineering change management, turning the change process from a reactive fire-fighting activity into a source of genuine organizational learning.
Why Engineering Changes Keep Recurring
Most manufacturing organizations can look at their ECO history and identify product families or design teams with consistently high change rates. The changes look different on the surface — a dimensional error here, an interface mismatch there, a tolerance that proved too tight in production — but they often trace back to a small number of root causes:
- Requirements were not completely or clearly defined before design began
- Design validation (analysis or testing) was insufficient to detect the problem before release
- Design reviews didn’t surface the issue, or issues raised weren’t effectively resolved
- The manufacturing or supplier process was not well understood at design time
- Lessons from previous programs weren’t captured or weren’t visible to the current design team
Engineering changes are symptoms. The root causes are in the design process — and fixing symptoms without addressing causes produces more symptoms.
The 5-Why Method Applied to Design Changes
The 5-Why method is a root cause analysis technique developed in manufacturing quality management. It works by asking “why” iteratively until the root cause is reached — typically in three to five steps. The method is deceptively simple; the skill is asking the right question at each step and being willing to follow the chain to an uncomfortable conclusion (usually: the process failed, not just the person).
Example: A tolerance-related ECO
The change: a machined bore diameter was specified with a tolerance of H7, but the bearing selected requires an H6 fit for reliable operation under the actual load cycle. This was discovered after first production run when early failures appeared.
- Why 1: Why was the wrong bore tolerance specified? — The designer used H7 as the default fit without checking the specific bearing’s requirements for this load case.
- Why 2: Why did the designer use a default without checking? — The bearing manufacturer’s technical data was not referenced during design; the designer relied on general knowledge.
- Why 3: Why wasn’t the bearing manufacturer’s technical data referenced? — There is no design standard or checklist requiring consultation of manufacturer data for bearing fit selection.
- Why 4: Why is there no such standard or checklist? — The team has not formalized bearing selection rules despite this type of error occurring previously.
- Why 5: Why hasn’t this been formalized despite recurring occurrences? — No formal mechanism exists to capture lessons from ECOs and translate them into process changes.
The root cause is not “the designer made an error” — it’s that the organization lacks a process for translating repeated failure patterns into preventive design standards. Fixing the bore diameter (the symptom) prevents this one failure. Creating the process prevents the pattern.
Building a Change Management Framework with RCA Integration
Effective change management combines two elements: a change execution process (the ECO mechanics) and a learning process (RCA integrated into the ECO workflow). Most organizations have the first; fewer have the second.
The ECO workflow with RCA integration
- Change identification: Document the problem clearly — what failed, when, and under what conditions. This seems obvious but is often done poorly; vague problem statements produce vague root causes.
- Immediate containment: Identify and quarantine affected inventory, stop production of the affected revision if necessary, and determine whether already-shipped product needs a field action.
- Root cause analysis: Apply 5-Why (or, for complex multi-cause problems, a fishbone/Ishikawa diagram) to identify the systemic root cause. This step is often skipped in the urgency of execution — resist the skip.
- Corrective action — immediate: The design change itself: the ECO that fixes the specific problem.
- Corrective action — systemic: The process change that prevents the class of problem from recurring. This might be a new design checklist item, a new design standard, a change to the design review agenda, or additional training.
- Verification: Confirm that the corrective action resolved the problem (verify the changed design performs as required) and that the systemic action was implemented.
- Lessons learned capture: Document the problem, root cause, and both corrective actions in a searchable lessons-learned system.
Categorizing ECO Root Causes for Pattern Analysis
To identify systemic issues, categorize the root causes of ECOs over time. Standard categories:
| Root Cause Category | Example | Systemic Fix Target |
|---|---|---|
| Requirements incomplete/unclear | Customer operating condition not specified | Requirements review process, elicitation checklist |
| Design analysis insufficient | Fatigue life not analyzed for actual load spectrum | Analysis requirements for design reviews |
| Design review miss | Known issue raised but not resolved before release | Action item closure verification process |
| Manufacturing process not understood | Tolerance achievable in prototype, not in production | Earlier manufacturing input in design process |
| Drawing error | Wrong dimension after model update | Drawing review checklist, change control for drawings |
| Supplier capability gap | Tolerance held in single-source prototype shop, not production supplier | Supplier qualification process for critical features |
Tracking the frequency of each root cause category over time reveals where process improvement effort will have the highest impact. A team with 40% of ECOs in the “requirements” category has a different improvement priority than one with 40% in “drawing errors.”
Common Mistakes in Engineering Change Root Cause Analysis
- Stopping at the immediate cause: “The dimension was wrong” is not a root cause — it’s a description of the problem. Keep asking why until the process failure is identified.
- Blaming individuals rather than processes: “Engineer X made an error” is not a root cause in a healthy engineering organization. What process condition allowed the error to occur and reach production? That’s the root cause.
- Generating corrective actions that don’t match the root cause: If the root cause is “no design standard for bearing fits,” the corrective action is “create a bearing fit standard” — not “engineer X will be more careful.”
- Skipping RCA under schedule pressure: The urgency of production recovery creates pressure to execute the change quickly without taking time for analysis. This feels efficient but guarantees that the class of problem recurs.
FAQ
Q: How do I apply 5-Why when there are multiple contributing causes rather than a single root cause?
A: Real failures often have multiple contributing causes. The 5-Why method works best when there’s a clear primary causal chain. For multi-cause problems, use a fishbone (Ishikawa) diagram to map the contributing factors first — then apply 5-Why down each branch that identifies a significant contributor. Address the two or three highest-contribution root causes. Trying to address every contributing cause simultaneously disperses effort and often results in nothing being fully addressed.
Q: Who should lead the root cause analysis for a design change?
A: The design engineer who owns the affected drawing should be involved, but RCA is most effective when it’s a multidisciplinary activity. Involve manufacturing (who saw the production problem), quality (who has inspection data), and the design reviewer (who can speak to what was checked). The “why” questions often cross discipline boundaries — a manufacturing process issue may trace back to a design decision, which traces back to a requirements gap. A single-discipline RCA misses these cross-disciplinary chains.
Q: How long should a root cause analysis take? Is there a risk of over-analyzing a simple change?
A: Scale the analysis to the risk. A cosmetic drawing correction (wrong note text) warrants a five-minute root cause check (was the drawing review process adequate?) and a quick fix. A field failure in a safety-critical application warrants a thorough structured analysis. The rule of thumb: spend more time on RCA when the cost of the problem recurring exceeds the cost of the analysis. For engineering changes that are costing money, causing customer dissatisfaction, or creating safety risk, thorough RCA is almost always justified.
コメント