AI Design Change Management — Fixing BOM Silos and Missed ECNs

The drawing on file has been replaced with the latest revision, yet parts machined to the superseded version are still stacking up on the shelves out on the floor. In manufacturing plants across Thailand, things rarely go wrong in the design change itself. They go wrong somewhere along the route the change travels on its way downstream. AI design change management is the idea that machines should support that route — the stretch between the moment a change arises and the moment it has actually landed everywhere it needs to. This article walks through the three stages of engineering change control, from ECR to ECO to ECN, shows where information tends to break at each one, and draws a clear line between what AI can take over and what people have to keep holding.

What AI design change management actually means

AI design change management is a collective term for using AI to support the path a design change travels after it is raised, until it has propagated correctly into the bill of materials, into every affected department, and into the drawings that are physically in use on the shop floor. It is not AI that draws for you, and it is not a machine that approves changes on your behalf. The scope is narrow and specific — the interval from the moment a change occurs to the moment it is fully reflected in every downstream document and function.

That interval is the least visible part of most factories. Inside the engineering department, the change is complete. The drawing is revised, the revision letter has moved up, the approval has been signed. But the list of people and documents that need to know about it lives only in somebody’s head, the notification goes out through personal email and chat, and there is no way to confirm how far the receiving side has actually taken it. The result is a plant where the design is right and the product is wrong.

The focus is not finding or calculating, it is delivering

We have covered neighbouring topics on the TOMAS TECH blog before, and they are easy to confuse with this one, so it is worth setting the boundaries first.

The three-layer problem of locating, identifying and interpreting legacy drawings is covered in detail in AI drawing search. AI design change management picks up the story after that drawing has been revised.

What happens when a change fails to reach the BOM correctly, meanwhile, is quantified in MRP system BOM accuracy. Even with 98% master data accuracy at the item level, a product built from 35 parts has only about a 49% probability that every item on it is correct. One missed handover looks trivial in isolation, but the moment the product is assembled it becomes a coin flip. It helps to think of AI design change management as the discipline that stops that 98% from decaying over time.

Production styles also differ in how well they absorb change. The point at which specifications freeze is different for make-to-stock, assemble-to-order, make-to-order and engineer-to-order, and we worked through that in make-to-order production management. The closer a plant sits to engineer-to-order, the more design change stops being exception handling and becomes ordinary daily work.

Which plants need AI design change management

Where several of the following conditions apply together, the handover of design changes tends to break down structurally rather than occasionally.

• High-mix low-volume or engineer-to-order work, where the same nominal product branches into customer-specific drawings
• Engineering in the Japanese head office and manufacturing at the Thai site, so design and production are separated geographically and organisationally
• The engineering BOM and the manufacturing BOM held in separate files and separate systems
• Change notification carried out by email and chat, with no record that anyone acknowledged receipt
• No written rule for withdrawing superseded drawings, so paper accumulates on the floor

The inverse also holds. A single-product volume plant with a handful of design changes a year, where engineering and production sit in the same building, runs perfectly well on memory and word of mouth. A system becomes necessary at the point where the frequency of change and the number of handover routes together exceed what people can reliably hold in their heads.

From ECR to ECO to ECN, and where the thread breaks

Engineering change control is generally described in three stages. The explanation published by Things Inc. sets them out as ECR (Engineering Change Request) for the proposal, ECO (Engineering Change Order) for the decision, and ECN (Engineering Change Notice) for the notification, and it identifies four leading causes of design change failure, namely missed communication, overlooked impact, insufficient traceability, and ambiguous cutover timing.

Cross the three stages with the four causes and it becomes clear which handover is most likely to break at which point.

Each of these deserves a closer look from a practical standpoint.

Where ECR breaks, nobody can see the whole impact scope

An ECR is simply a request. It can originate from a customer specification change, a component going end-of-life, a countermeasure to a defect, a cost reduction, or a regulatory requirement. What trips people up at this stage is that the person raising the request cannot possibly know everything the change will affect.

Component obsolescence is the classic case. When an electronic part goes end-of-life, what it affects is not simply the products that use it. There is the board it is mounted on, the products that board goes into, the operating manuals and service parts lists for those products, and the parts breakdowns already submitted to customers. The Things Inc. explanation gives the example of using reverse BOM explosion to establish, in one pass, that an obsolete part appears in three board types and seven product models. That figure is an illustration of how the mechanism works rather than an industry statistic, but it makes the point well. Whether or not you have reverse explosion available decisively changes how much you can see at the moment the request is raised.

Without it, here is what happens instead. The originator writes up only their own area of responsibility. At the review meeting somebody says “wasn’t that used on the other product too?” from memory. If the person who happens to know is in the room, the item gets picked up. If not, it is missed. And the missed impact will not be caught at ECO or ECN either, because anything not enumerated at the start is never enumerated at all.

This is where putting AI to work pays back the most. We will come back to it below, but change impact analysis is structurally the kind of task AI is good at, and it can generate candidates far more exhaustively than human recall.

Where ECO breaks, the reasoning behind the decision is not kept

ECO is the stage where the organisation decides to go ahead. Who approved it, which alternatives were considered and rejected, how the cost and lead time impact was estimated. The information created here actually outlives the change itself, and it gets pulled up years later when the same component causes trouble again.

In practice, though, this is the stage whose records scatter most easily. Approval ends as a verbal agreement in a meeting, and the minutes carry a single line saying “approved”. The evaluation of alternatives lives in a spreadsheet on somebody’s local PC, and disappears when that person transfers. The revised drawing preserves the fact that the revision letter moved, but not why it moved. That is insufficient traceability.

The damage from poor traceability does not show up immediately after the change. It shows up two or three years later. A customer asks when a dimension changed and why, and nobody can answer. The same component fails again, nobody can tell how far the previous countermeasure went, and the investigation starts from zero. A quality audit asks for evidence of change control, and somebody prints out email search results. At Thai sites this is also one of the items most likely to draw a finding in a customer or head office audit.

The minimum an ECO needs to retain is the before and after state, who decided, the date of the decision, the reason for the decision, and the list of affected items. If those five things are held in one place, tied to a change number, traceability holds. As long as they are scattered across systems, no amount of careful record keeping will let anyone trace the change afterwards.

Where ECN breaks, nobody knows whether it landed

ECN is the stage where a confirmed change is communicated to everyone affected. Two things break here — missed communication and ambiguous cutover timing.

Missed communication is a problem of addressees. When the distribution list lives in somebody’s head, the routine recipients get included — manufacturing, quality, purchasing — and the infrequent ones drop out. The tooling maker, the outside processing vendor, the service department, whoever translates the technical documentation, the customer’s incoming inspection group. Nobody notices the omission until a problem surfaces at the omitted destination. And even where the sent folder proves the message went out, nothing proves the recipient acted on it. There is a wide gap between “sent” and “reflected”.

Ambiguous cutover timing is a problem of the time axis. If the effective date of the change is not explicit, the shop floor is forced to decide. Build to the new drawing starting today, or run out the old parts on hand first, or switch from a specific lot number, or apply it early for one customer only. Send a notice without settling this and each area interprets it differently, so old and new coexist inside the same product. That coexistence is discovered after shipment, and combined with poor traceability it produces the worst possible outcome — nobody can tell which lots are new and which are old.

An ECN therefore needs to state more than the content of the change. It needs the basis for effectivity (a date, a lot, or exhaustion of stock), the handling of the superseded version (scrap, run out, or return), and the method of acknowledging receipt. A change notice missing those three is best treated as incomplete.

Why BOM data silos form in the first place

Running underneath all three stages is the problem of BOM data silos — bills of materials whose real state is trapped in separate files and in individual heads. The root cause of broken design change handover is less about weak notification mechanics and more about the fact that nobody can give a single unambiguous answer to the question of where the master record that should carry the change actually lives.

The split between engineering BOM and manufacturing BOM

In manufacturing, the BOM built by engineering (the engineering BOM, or E-BOM) and the BOM used by production (the manufacturing BOM, or M-BOM) are not the same object. The engineering BOM is organised around the functional structure of the product. The manufacturing BOM is organised around process sequence and the units actually procured. There will always be differences, such as a screw counted as a part on the engineering BOM but rolled into process consumables on the manufacturing BOM.

The problem is that the conversion rules between the two are undocumented in most plants. Daiko Group’s commentary on person-dependent work in manufacturing raises exactly this split as one of its examples. The conversion is usually carried out by one or two specific people in production engineering, who decide from experience, every single time, which process a given part belongs to and which sub-assemblies get collapsed.

Given that structure, consider what happens when a design change lands. The engineering BOM updates automatically. But nothing reaches the manufacturing BOM until that individual receives the notice, applies the conversion rules from memory, and rewrites the data by hand. If they are on leave, it stops. If they were left off the distribution list, it never happens at all. If they misread the intent, it is reflected incorrectly.

Silos form on three separate layers

Treating the problem as nothing more than “only one person understands it” leads to the wrong countermeasures. What is locked into individuals actually splits across three layers.

Each layer needs a different remedy. The location layer is solved by tidying the file server and consolidating on a single master. The conversion layer is solved by writing the rules down and putting them into a system. The judgement layer, however, is territory that properly belongs to people, and forcing automation onto it is a mistake. Any effort to reduce dependency on individuals that skips this distinction and aims to automate everything will break somewhere.

Conditions specific to Thai sites

For Japanese manufacturers in Thailand, further conditions stack on top of that structure.

First, the division of labour — engineering in Japan and manufacturing in Thailand. The primary record of a design change is issued in Japanese and then rendered into English or Thai at the Thai site. Where that translation step depends on an individual, nuance falls away. This is exactly how accidents happen. A proviso such as “existing parts may continue to be used for now” goes untranslated, only the notice itself is passed on, and the shop floor switches the entire stock over.

Second, the difference in time zones and working calendars. Confirmation of change notices stalls during periods when Thailand is running through a Japanese holiday week, or around the operational adjustments made for Songkran and Loy Krathong.

Third, staff mobility on the local side. When the production engineering member who held the BOM conversion rules in their head leaves for another company, the rules leave with them. On the Japanese side, the assumption that “we can just ask them” can sit unchallenged for years, long after nobody actually knows any more.

These are less technical problems than problems of how information handover is designed. That is precisely why the unglamorous work of consolidating notification routes and master records pays off more at a Thai site than it does domestically in Japan.

Where engineering chain DX stands today — what AI-equipped PLM can now do

The tools that support design change management have moved substantially over the past few years. Genuinely usable AI features are now appearing in the space usually discussed under the heading of engineering chain DX.

The four areas where AI is being used in BOM management

AI Souken’s analysis reports that AI adoption in manufacturing BOM management is progressing across four areas, namely BOM creation, duplicate part detection, change impact analysis, and natural language search. The same article notes that capabilities from the major PLM vendors came together during 2026, citing Siemens Teamcenter Copilot, PTC Windchill AI Parts Rationalization, and the Aras Variant BOM Agent.

Those four areas map onto the break points described above. Change impact analysis addresses overlooked impact at ECR. Duplicate part detection addresses the conversion layer of BOM data silos. Natural language search provides a way to dig out past decisions that poor traceability has buried. The direction the tooling is taking is not accidental; it is heading straight for the places that hurt most in practice.

Connecting drawings and BOMs

Japanese vendors are moving too. Zuken Presight’s PLM product Visual BOM is reported to have added, in v6.2 released on 26 June 2026, a capability for AI to analyse the features of a 2D drawing and retrieve similar drawings, along with a capability to structure knowledge out of technical information.

What is notable is that this joins drawing search and BOM management inside a single product. Traditionally drawings sat in a drawing management system while BOMs sat in a PLM or ERP, in separate boxes. One of the main reasons design change handover breaks is the seam between those boxes. Products evolving so that drawing-side revisions and BOM-side revisions share the same ground is consistent with what practitioners feel on the floor.

Market size and adoption outlook, read the numbers as ranges

For the engineering change management software market, Introspective Market Research forecasts growth from USD 3.2 billion in 2023 to USD 10.63 billion in 2032, a compound annual growth rate of 14.27%. Forecasts in this space vary widely between research firms, however, and some other houses put the CAGR in the 11 to 12% band. Rather than the absolute values, the practical reading is that this is an area attracting enough investment for multiple research houses to expect double-digit growth.

On the outlook for embedded AI, a Gartner forecast stating that 50% of PLM vendor solutions will incorporate generative AI capabilities by 2026, up from 5% in 2023, is quoted across several PLM industry publications. That figure circulates through secondary sources and we have not verified it against the primary report, so it should not be treated as settled. That said, it is directionally consistent with what the vendors listed above have actually shipped.

The engineering-to-ERP integration question

There is one more development that matters practically — integration between engineering information and ERP. A commentary drawing on the KPMG global tech report positions the reduction of duplicate work such as BOM re-entry and revision reconciliation, achieved through this integration, as the foundation on which manufacturing AI is built.

That sounds unglamorous but it is fundamental. It is not unusual to find a plant where a design change is notified, reflected in the manufacturing BOM, and then keyed in again by hand into the ERP item master. Enter the same information three times and you create three opportunities for error. Before investing in sophisticated AI-driven impact analysis, reducing that re-entry from three passes to one is often the better return.

What AI can take over and what people must keep

This boundary is the single most important thing to settle before evaluating AI design change management. Leave it vague at deployment and the project either disappoints or, worse, builds dangerous automation.

Three areas where AI is structurally strong

First, change impact analysis. Reverse BOM explosion is inherently a computing task. Tracing from an item up to its parent, then up again to the parent above that, is a search that human memory will always leak on and a machine can complete exhaustively. With AI in the loop, products are now surfacing candidates beyond the structural parent-child relationships, including parts previously substituted as equivalents and different part numbers with similar geometry or specification, relationships that do not appear in the structured data at all.

Second, retrieval of similar drawings and similar parts. Has a comparable change been made before, is a part with similar geometry already registered. Searching for this manually takes time and the result depends on the experience of the person searching. Retrieving similarity from drawing features removes a large part of that dependency on individuals. This area is covered in detail in AI drawing search.

Third, natural language querying. A question such as “which products that use this part have had a change since last year” gets an answer without anyone having to learn the search screen. Records accumulated for traceability are worthless if they cannot be pulled back out. Natural language search lowers the wall between accumulating information and using it.

Two areas people must keep

There are, on the other hand, decisions that must not be handed to AI.

First, final approval of a change. Technical validity, quality impact, regulatory compliance, consistency with contractual commitments to the customer. The judgement that a change may proceed, taking all of that into account, belongs to someone who can carry the responsibility. AI can assemble the evidence, point out omissions and present comparable past cases, but it cannot be the approving party. Quality management system requirements for change control likewise call for records that identify the result of the review and the person who authorised the change.

Second, the decision on cutover timing. This is the one most often overlooked. Cutover timing is not determined by the technically optimal answer. It is determined by the value of stock on hand, the customer’s incoming inspection arrangements, production plans on other lines, the lead time on imported components, and the fiscal year-end stocktake. AI can supply inputs such as how many units remain and how many weeks they will take to consume, but information such as the state of the customer relationship and the room available to negotiate is simply not in the system. Try to automate this and you will produce a rule the shop floor refuses to follow.

Limits worth agreeing on before you start

AI output is a set of candidates, not a guarantee of completeness. Three points in particular are worth putting on the table before deployment.

• If the source data is inaccurate, the AI output will be inaccurate. A part that was never registered in the BOM will not appear in a reverse explosion. You cannot skip master data cleanup and bolt AI on top.
• Implicit rules that are not on the drawing, such as a jig that must always be used at a given process or a special inspection applied only for one customer, are invisible to AI. Writing that knowledge down remains human work.
• Where change history has not yet accumulated, similar-case retrieval will not be accurate. In the early phase it is realistic to lower expectations and treat the period as one for building up records.

How to design ECN automation in five steps

From here the discussion turns to implementation. ECN automation is not something that finishes when the tool is installed. The order matters.

Step 1, take stock of the change flow you actually have

Start by selecting somewhere between 10 and 20 design changes from the past year and tracing how each of them really flowed. Who raised it, who approved it, who was notified, where it stopped, how many days it took. Write down what actually happened, not the idealised flow diagram.

What invariably surfaces are routes that do not exist in the official flow. “The people involved spoke on the phone and started work before the formal notice went out.” “The notice was issued, but the real instruction came through chat.” These informal routes are not necessarily bad. More often than not they are the floor adapting to an official flow that is too slow. When designing automation, the aim is not to eliminate this reality but to make the official flow fast enough to match it.

Step 2, pick one master BOM

Next, decide where the master BOM lives. The engineering BOM and the manufacturing BOM do not need to be merged into one. What is needed is that, for each of them, everyone can point to the same answer when asked which one is the master.

Realistically, abandoning an established spreadsheet practice outright is often not feasible. Even so, fix the master in one place and reposition the spreadsheet as an artefact generated from it. As long as people continue to edit the derived artefact directly, any notification automation you build will be neutralised.

Step 3, define notification triggers and addressees

Who gets told what, and on what event. Fix this in a table. Half the work of reducing dependency on individuals is done the moment that table exists.

When defining addressees, work through not only internal departments but also outside processing vendors, tooling makers, the service department, whoever handles translation, and the counterpart on the customer side. Explicitly listing the parties who do not need to be notified is also worth doing, because it stops the judgement drifting later.

For triggers, the default is to fire on completion of ECO approval. Broadcasting to everyone at the ECR stage produces so much traffic that the notices stop being read, and that is the most common failure pattern in practice. That said, sending an advance “under consideration” heads-up to departments inside the impact scope at the ECR stage can work well.

Step 4, put AI on impact analysis

Only now does AI enter the picture, and it matters that the order has not been inverted. Deploying AI before the master is settled and the addressees are defined simply produces inaccurate candidates from inaccurate inputs.

The most effective place to apply it is immediately after an ECR is raised. Run a reverse explosion from the items targeted by the request, and present the higher-level assemblies, related drawings and related documents that may be affected as candidates. The originator reviews the list, removes what is out of scope, and confirms it. What was a task of recalling becomes a task of confirming. Omissions that stem from memory drop away with that substitution.

Step 5, monitor the operation with KPIs

Notification automation degrades after it is built. You need numbers to see whether the practice has become hollow. OpenBOM’s commentary lists monitoring metrics for BOM management such as BOM synchronisation lag by plant and the share of engineering changes reflected without manual intervention. Made concrete for your own operation, these become something like the following.

Reviewing these monthly is enough. What matters is designing them so that, when a number deteriorates, the metric itself tells you which layer is jammed.

Practical cautions for rolling this out in Thailand

Finally, some points to keep in mind when actually taking this forward at a Thai site.

Solve multilingual notices with structure, not translation

Where change notices have to be issued in Japanese, English and Thai, translating the full text is a practice that will not survive. The volume is too high and notices are delayed waiting for translation.

The realistic answer is to structure the notice. Split the target part number, the before and after state, the basis for effectivity and the handling of superseded stock into fixed fields, and fix the field labels in all three languages. Restrict free text to a supplementary notes box. Translation is then required only for that box, while the body can simply be displayed in whichever language the reader needs. Accidents caused by mistranslation also stop occurring in the structured portion.

Stage the connection to head office systems

Where the Japanese head office runs a PLM, connecting the Thai site into it is the ideal. In practice, though, it usually requires modification on the head office side, and approval and budget take time.

The practical route is to complete master consolidation and notification definitions inside the Thai site first, and narrow the intake from head office down to a single point. Whatever format information arrives in from Japan, if there is one entry point on the Thai side, you can receive it there and load it into the site’s own master. Direct integration with the head office system can be considered afterwards without losing anything.

Scope the small start by product line

The established approach is to start with one product line rather than rolling out company-wide at once. Choose a line with a high rate of change, a reasonable part count, and a cooperative owner. Pick a line with few changes and it takes so long for any effect to appear that interest is lost along the way.

What to aim for in the first three months is not dramatic efficiency gains but two concrete outcomes — that impact candidates now appear automatically, and that the notification addressees are now fixed. Those two alone address two of the four leading causes, namely missed communication and overlooked impact.

Build training and handover into the mechanism

If you take local staff mobility as a given, operating rules belong in the system rather than in people. Writing conversion rules into a document is not enough on its own, because the habit of reading that document is not what gets handed over. Instead, make the rules appear inside the flow of work, as options on an input screen or as checklist items. The essence of reducing dependency on individuals is not transferring knowledge; it is creating a state in which the correct steps can be followed without that knowledge.

Frequently asked questions

What is AI design change management?

It is a collective term for using AI to support the path a design change travels, after it is raised, until the information has propagated correctly into the bill of materials, the affected departments and the drawings in use on the floor. Concretely it refers to capabilities such as automatically enumerating the impact of a change from reverse BOM explosion and similarity relationships, retrieving and presenting comparable past changes, and answering natural language queries. It does not generate drawings, and it does not have a machine approve changes on your behalf. Final approval and the decision on cutover timing remain areas that people own and are accountable for.

Why do BOM data silos form?

The main cause is that the conversion rules between the engineering BOM and the manufacturing BOM are undocumented and rest on the experience of specific individuals. Silos form on three layers — the location layer covering where the current BOM lives, the conversion layer covering how the engineering BOM is restructured, and the judgement layer covering when and how widely a change is applied. The location layer is resolved by consolidating on a single master, and the conversion layer by writing the rules down and systematising them. The judgement layer properly belongs to people, and forcing automation onto it is counterproductive. At Thai sites, multilingual working and staff mobility compound the problem, which makes resolving it more urgent than it would be in Japan.

Where should we start with ECN automation?

Start by taking stock of the current flow, not by selecting a tool. Trace 10 to 20 design changes from the past year and record how each actually moved. Then settle on a single master BOM, and after that fix notification triggers and addressees in a table. Applying AI to impact analysis comes only once those three are done. Deploy AI before the master and the addressees are settled and all you get is inaccurate candidates from inaccurate inputs.

Do we need a PLM before we can use AI design change management?

It is not a prerequisite. Impact extraction and notification automation work perfectly well starting from an existing ERP, a production management system, or even a BOM held on a file server. What matters is not the category of tool but that the master BOM is settled as one, and that change history accumulates in a structured form. That said, the value of similar-case retrieval rises the longer change history accumulates, so designing on the assumption of an eventual move to something PLM-equivalent will save rework in the medium term.

Summary

Most of the trouble caused by design changes comes not from errors in the design itself but from the route the change takes on its way downstream. At ECR the impact scope is overlooked. At ECO the reasoning behind the decision is not retained. At ECN addressees are missed and the cutover timing reaches the floor unresolved. Underneath all four of those breaks sits a common structure — BOM data silos.

AI design change management takes on the parts of that route machines handle well, namely exhaustive extraction of the impact scope, retrieval of similar drawings and similar changes, and natural language querying against accumulated records. Final approval and the cutover decision remain with people. Once that line is drawn, working through the steps in order — stock-take of the current flow, master consolidation, notification definitions, AI deployment, KPI monitoring — is the surest route, even though it looks like the long way round.

Engineering chain DX does not have to begin with a wholesale system replacement. Pick one product line and finish just the first two moves — the stock-take of the current flow and the consolidation of the master record. Get that far and the notification definitions and the AI deployment that follow become a matter of repeating the same steps across the rest of the business.

TOMAS TECH is based in Bangkok and works on factory IT challenges for manufacturers in Thailand, including the PEGASUS production and energy management system. If design change handover or BOM data silos are on your mind, it is perfectly fine to be at the stage of still working out what the problem is. We are happy to start by taking stock of your current flow together. You can reach us through our contact page.

References

• Things Inc. (mono-prism.jp), commentary on engineering change management with ECR, ECO, ECN and the bill of materials, mono-prism.jp
• AI Souken, the four areas of AI use in manufacturing BOM management and the state of the major PLM vendors, ai-souken.com
• CAD JAPAN, topic page on the new capabilities in Zuken Presight Visual BOM v6.2, cadjapan.com
• getleo.ai, guide to the difference between PLM and PDM, including the quoted Gartner forecast, getleo.ai
• Introspective Market Research, forecast of the engineering change management software market size, introspectivemarketresearch.com
• QBuild Software, commentary positioning engineering-to-ERP integration as the foundation of manufacturing AI, qbuildsoftware.com
• OpenBOM, commentary on BOM review mistakes and the KPIs worth monitoring, openbom.com
• Daiko Group (daiko-plus), on person-dependent work in manufacturing and the split between engineering and manufacturing BOMs, daiko-xtech.co.jp