🌎 All English Articles  |  🇯🇵 Japanese Version

Design Change Traceability Management: Keeping a Complete History of Engineering Changes

CAD Tools

The Cost of Incomplete Change Records

Every mechanical engineer has encountered this situation: a drawing has been revised four times, the current revision is D, and nobody can explain why revision B changed the wall thickness from 8 mm to 6 mm. The engineer who made that decision left the company. The email thread is buried in an archive. The change memo, if one was ever written, cannot be found. And now a field failure has emerged that may be directly related to that wall thickness reduction.

This scenario plays out in manufacturing companies of all sizes. The cost is not just the time spent reconstructing history — it is the inability to make informed decisions about future changes, the exposure to liability when designs are involved in safety incidents, and the erosion of institutional knowledge that engineering organizations spend decades building.

Design change traceability — a systematic, retrievable record of what changed, why it changed, who approved it, and when — prevents this problem. This article describes a practical traceability system suitable for engineering teams without dedicated PLM infrastructure.

What Traceability Requires

A complete change record for each engineering change includes:

  • What changed: specific drawing number, revision level, feature or dimension affected, and the before/after values
  • Why it changed: the technical or commercial reason — customer request, field failure, cost reduction, manufacturing feedback, design error correction
  • Who approved it: the engineer who made the change and the authority who approved its release
  • When it took effect: the release date and the serial number or lot from which the change applies
  • Related documents: links to the design calculation, test report, customer specification, or NCR that justified the change

Without all five elements, the record is incomplete and its value diminishes rapidly over time.

The Engineering Change Notice (ECN)

The Engineering Change Notice is the formal document that captures a design change. An ECN does not need to be complex — a well-designed one-page form captures all required information and takes less than ten minutes to complete for a routine change.

ECN Fields

  • ECN number (sequential, unique)
  • Date initiated and date released
  • Affected drawing numbers and revision levels (before and after)
  • Change description (what changed, stated precisely)
  • Reason for change (category + narrative)
  • Impact assessment (cost, lead time, inventory, related drawings)
  • Disposition of existing inventory (use as-is, rework, scrap)
  • Approvals with dates
  • Reference documents

The ECN number is entered in the drawing revision block, creating the link between the drawing and its change history. This link is the foundation of traceability.

Revision Blocks and Drawing Title Blocks

The revision block on a drawing is the visible history of the part. Each row records: revision letter, description of change, ECN reference number, date, and approver initials. The revision block must be maintained as a chronological record — never delete earlier rows, never overwrite previous entries.

Common errors in revision block management:

  • Describing the change as “per customer request” without stating what specifically changed
  • Referencing a verbal instruction or meeting without a document number
  • Leaving the ECN field blank and relying on institutional memory to connect the revision to its reason
  • Incrementing the revision letter without creating a formal ECN

Each of these shortcuts feels efficient in the moment and creates a traceability gap that may take hours or days to resolve years later.

Digital Traceability Tools

Dedicated Product Lifecycle Management (PLM) systems provide automated change management with approval workflows, version control, and cross-reference tracking. For organizations with the budget and scale to justify PLM, it is the right solution.

For smaller teams, a structured approach using accessible tools achieves most of the benefit:

Tool Use Case Advantage Limitation
Shared spreadsheet (ECN log) Tracking all ECNs with status Simple; universally accessible No workflow enforcement; manual linking
Folder-based archive with naming convention Storing ECN documents and supporting files Low cost; easy to understand No automated version control
PDM (Product Data Management) software Drawing version control with check-in/out Enforces revision history; locks files Requires training; per-seat licensing
Full PLM system Enterprise-wide change management Automated workflow; complete audit trail High cost; implementation complexity

Managing Related Drawing Updates

A single design change often affects more than one drawing. Changing a shaft diameter triggers updates to: the shaft drawing, the housing drawing, the assembly drawing, the BOM, and possibly a mating component drawing. Incomplete propagation — changing the shaft drawing but not the assembly drawing — creates the drawing inconsistency that causes incorrect builds.

The impact assessment section of the ECN is the mechanism for catching this. Before approving a change, the responsible engineer must list every document affected and verify that all changes are incorporated before the package is released. A cross-reference matrix — a table that maps components to the drawings that reference them — makes this step systematic rather than dependent on memory.

FAQ

Q: Our team uses verbal approvals and email for design changes. Is a formal ECN system necessary for a small team?
Verbal and email approvals feel efficient when the team is small and everyone shares context. They fail when people leave, when audits occur, when warranty claims arise, or when a design is reused in a new project. A minimal ECN system — even a simple numbered form with five fields — provides the traceability that email cannot. The investment is small; the protection is significant.

Q: How far back should we try to reconstruct change history for existing drawings?
Reconstructing full history for all drawings is usually impractical. Prioritize: safety-critical components, high-value assemblies that are still in production, and anything that has had field failures. For lower-priority drawings, document the current state thoroughly and commit to complete traceability on all changes going forward.

Q: What is the correct way to handle an urgent change that needs to go to production before the ECN is formally closed?
Assign the ECN number before release and mark it as “preliminary approved” — verbal or email authorization from the responsible engineer captured in the ECN record. Require formal sign-off within 24 hours. Never release a change without at least a number and a preliminary record; the gap between “we’ll document it later” and “it was never documented” is shorter than it appears.

コメント

タイトルとURLをコピーしました