When introducing AI impact assessment for a manufacturing process change, the first decision is how to make every affected item visible to an authorized reviewer. Starting from a change request, the team must identify the product revisions, BOMs, routings, inspection specifications, equipment settings, work in process (WIP), work instructions, and training records that need checking. This practical guide helps quality assurance, production engineering, production planning, and IT teams at Thai factories design AI-assisted candidate discovery, an RFP, acceptance testing, and operating controls.
The problem AI impact assessment addresses
A seemingly small material substitution can affect product revisions, substitute approval, line setup, inspection fixtures, customer submissions, released production orders, old material in stores, and WIP in transit. Even with a change register, evidence may be scattered among PLM, ERP, MES, QMS, spreadsheets, and paper instructions. The result is an impact review that depends on individual memory.
AI can extract part numbers, operations, equipment, and customers from a free-text request and suggest related records and documents. Effective dates, customer approval conditions, safety interlocks, and first-article acceptance must be decided using master data, explicit rules, measured results, and authorized people. A document-search answer must never be written directly to production settings.
Microsoft’s engineering change management documentation separates change requests from change orders and describes assessment, approval, and effects on existing transactions. That controlled process remains the foundation when AI is added. Editing a product revision, BOM, or route in one system does not automatically fix a shop-floor instruction or define the WIP cutover.
How this differs from 4M change control and model drift monitoring
4M change management records and approves changes to Man, Machine, Material, and Method. For its core design and costs, see our guide to 4M change management systems. Here the focus is the evidence needed to find affected revisions and shop-floor items before a request reaches final approval.
Our guide to AI visual-inspection model drift concerns a particular inspection model losing performance as conditions change. In this article, that model is one possible affected item among BOMs, processes, inventory, work instructions, and customer notifications. The overall change assessment and the validation of one subsystem need separate checks.
Define scope by change event and affected item
“Every factory change” is too broad for a first proof of concept (PoC): rules, permissions, and exceptions vary too much. Select one frequent or consequential change type, such as an alternative material, fixture change, routing change, inspection-frequency change, or equipment-software revision. Customer-specification and safety changes require stronger human review because contracts, regulations, and specialist judgment may apply.
Record at least the change ID, requester, reason, product and part numbers with revisions, old and new conditions, proposed effective date, plant and line, attachments, and expected effects. A difference described only in prose is hard for both people and AI to verify. Structure old and new BOM lines, routing steps, settings, and inspection points where possible; preserve the source record IDs and revisions.
A baseline impact list should cover nine areas: (1) products, BOMs, and substitutes; (2) routes, operations, and equipment; (3) work instructions and training; (4) inspection specifications, fixtures, and gauges; (5) WIP, finished goods, and inventory; (6) purchasing and suppliers; (7) customer approval and submissions; (8) safety, environment, and maintenance; and (9) integration among ERP, MES, QMS, and PLM. Add industry-specific areas. When excluding one, record the reason and approver. Silence from AI is not a reason to exclude it.
Connecting the assessment inputs
Typical sources are PLM change requests/orders and product revisions; ERP BOMs, stock, and production orders; MES operations, equipment, and lot histories; QMS inspection rules, nonconformities, and corrective actions; and controlled work instructions. NIST’s Digital Thread for Smart Manufacturing examines how lifecycle information can be managed, connected, and reused. A useful factory implementation needs linking keys, including part number, revision, lot, equipment ID, and effective date, not just a list of systems.
Inventory the fields available from each source and label them “available,” “unavailable,” or “entered by a person.” Check before the PoC whether old instructions exist only as PDFs, WIP lots lack product revisions, or setting histories remain only inside a PLC. AI must not invent missing data. Show “unverified,” “data missing,” or “awaiting owner review” on screen and route the gap to a person.
The connection inventory should name the system of record for each field. PLM may own the design BOM while only ERP records whether a substitute is permitted in the purchasing BOM. QMS may hold the latest inspection standard while a night-shift terminal still displays an older PDF. Refreshing AI’s index cannot make that shop-floor document current. Record the index refresh rate, distribution time to terminals, and evidence that obsolete copies were withdrawn. If handoffs cross departments, fix the handoff instead of treating each discrepancy as an operator’s oversight.
Document titles and folder names alone can also cause false matches, especially with identically named equipment across plants or common parts supplied to several customers. A document without a direct linking ID should be flagged as a related candidate, not required approval evidence. A correct ID on a revision outside its effective period is not current evidence either. Check ID, revision, effective date, plant, and customer together.
Limit AI’s role to extraction, linking, and explanation
First, extract possible change subjects from the request and attachments. “Replace resin A with resin B” should lead to candidate part numbers for A and B, products, customers, and molding operations. Attach the original text location, record ID, and revision to each extraction. If an abbreviation refers to several parts, ask the user to choose instead of resolving it silently.
Second, trace relationships from confirmed part numbers and revisions. Use structured links to find parent assemblies in BOMs, route operations, their inspection points, open production orders, and inventory lots. Retrieved instructions and customer specifications are supporting evidence. If candidates receive scores, show relationship type separately from evidence age. A direct BOM reference is stronger evidence than similar wording.
Third, draft an explanation a reviewer can inspect. For example: “The changed part appears in product X, BOM revision 3, and four unfinished orders on line 2. Inspection specification Q-17 explicitly names the old material and needs review.” Separate facts from recommended actions. An acceptance criterion should require every cited source to open at the exact revision. Correct links and differences matter more than fluent prose.
The NIST AI Risk Management Framework Core organizes work under Govern, Map, Measure, and Manage. Here, testable risks include missed candidates, incorrect part matching, obsolete documents, and unauthorized access to confidential records. Using the framework alone does not discharge a company’s quality obligations; translate it into the site’s change rules.
Design the impact map and approval gates
Each impact-map row should identify item type, item ID, revision, relation to the change, evidence URL or record ID, effective date, owner, and assessment state. Use distinct states such as “affected,” “not affected with reason,” “review required,” and “data missing.” Direct BOM or route relationships may be enumerated automatically. Product safety, customer agreement, regulation, and training needs require authorized judgment.
Keep AI suggestions apart from workflow gates. A high model score cannot release a change to production. Assign reviews to quality assurance, production engineering, planning, maintenance, and, where needed, sales or the customer interface. Record evidence whenever a reviewer marks “not affected.” Define a delegate’s authority and an escalation path so an absent approver does not leave a request open indefinitely.
Use at least four release gates: G1 verifies subjects and evidence; G2 records cross-functional approvals; G3 disposes of old-revision WIP and inventory and trains operators; G4 checks the first article or trial lot and authorizes production. Add customer approval or process-capability evidence for high-risk changes. AIAG’s APQP and Control Plan FAQ describes a Change Management section and checklist in the newer APQP materials. Check the customer-specific requirements and audit standard that apply to your site.
Specify the cutover between old and new revisions
“New revision from the end of October” is insufficient for night shifts, orders already running, and pick instructions already issued. Define the cutover using a combination of product, plant, line, order or lot, time, and customer. Decide whether old material can be consumed, how WIP is handled, whether old labels are destroyed or quarantined, and how mixed production is identified. Do not assume ERP, MES, and paper records switch revisions simultaneously.
Microsoft’s FAQ on product-revision transactions explains that tracking revision in transactions changes treatment of stock, planning, and traceability. Check the revision dimensions in your ERP/MES and the effect on existing transactions. If source lots do not carry a revision, an AI claim that “no affected lots exist” has no evidential basis.
Test the cutover and rollback as an operating scenario
Consider one plant switching to new material at 06:00 on October 20. An order started the previous night may continue past 06:00 while WIP already contains old material. Put the change approval time, ERP BOM effective time, MES order start, actual material issue, and inspection-standard publication on one timeline. Decide in advance which lots are old, new, or mixed. Hold any lot that cannot be classified by date alone until the physical goods and issue record are checked.
The day before cutover, reconcile purchased parts and remaining old material, issued pick instructions, unfinished orders, instructions in use, and fixture calibration. AI may list candidates, but stores and the line must verify quantities against physical stock. On cutover day, the line leader distributes the new instruction and records when old copies are withdrawn. Produce a uniquely identifiable first-article lot. Do not release volume production until quality approves its dimensions and function. The person, time, and lots released must agree between MES and the change record.
If the first article fails, rollback requires more than canceling an AI recommendation. Quarantine lots made with new material, restore equipment settings, reconfirm the availability and quantity of old material, and restore effective BOM, routing, and inspection revisions where needed. Check customer notices and issued inspection reports. Quality and production engineering must inspect physical goods and records before authorizing production under the previous conditions. Retain the change ID and record the failure reason, affected lots, and conditions for a new request.
Use this scenario in SAT to expose integration gaps. If a new ERP BOM takes effect at 06:00 but an offline night-shift terminal still shows the old instruction, can AI report “document distribution unverified”? When the first article fails, can the system distinguish tested lots from those awaiting inspection? Can it prevent AI from issuing permission to revert material on its own? Testing interruption and recovery checks operating accountability better than testing candidate extraction only. Before scaling to another plant, test local time, part codes, and customer rules at that site.
Worked example: assess an alternative-material change
The following figures are assumptions for planning, not measured results or industry averages. Suppose one Thai factory requests a switch from resin A to a candidate approved resin B. Assume three affected products, five BOM revisions, two lines, 12 unfinished production orders, eight related WIP lots, and 1,500 kg of old material in stock. There are four inspection-specification documents, three work instructions, and 24 affected people across two shifts.
For manual initial discovery, suppose 40 target records take an average of 15 minutes each to find across systems. Search alone takes 600 minutes, or 10 hours. Suppose AI search and a relationship graph produce candidates in 20 minutes. That does not mean those candidates are verified. If quality, production, and shop-floor reviewers check 40 records at five minutes each, verification takes 200 minutes, or about 3 hours 20 minutes. Approval coordination and trial inspection take additional time. The potential gain concerns discovery time, not a reduction of the entire change process from 10 hours to 20 minutes.
The key comparison is omission, not display speed. Suppose a later human review identifies 43 truly affected records. AI proposed 40 candidates, of which 38 really are affected. Recall is 38 ÷ 43 ≈ 88.4%; precision is 38 ÷ 40 = 95.0%. The five missed records may include old-revision WIP or a paper standard. A percentage alone cannot authorize release. Weight safety, customer approval, and shipment hold items; set zero critical omissions as a separate acceptance condition.
In this illustration, 40 AI candidates at five minutes each require 200 minutes of review. Add 20 minutes for AI extraction: 220 minutes. The difference from 600 minutes of manual search is 380 minutes, about 6 hours 20 minutes. For a like-for-like comparison, both sides exclude approval and inspection work. The simple calculation also excludes integration, data cleanup, and training costs. An RFP should estimate 12-month total cost and benefit using annual change volume, critical-change share, recheck rate, and operating costs.
KPIs that show whether the system helps
Measure time from request to first impact candidates, time to finish human review, critical omissions, obsolete-revision references, percentage of working evidence links, return-for-correction rate, and repeat changes after first-article inspection separately. One “AI accuracy” figure is insufficient. Also track the proportion of “not affected” decisions with reasons, completion of old-WIP disposition, and nonconformities during the 30 days after change. Report customer-specific requirements separately.
A 90-day PoC, from data preparation to shop-floor acceptance
In days 1–30, set scope and a reference standard. Select past changes that include successful cases and returned requests, omissions, or old-revision mix-ups. Quality and production engineering should reconstruct the correct affected-item list for each case. Keep at least the change ID, old and new conditions, record revision, discovery time, and actual disposition. Separate evaluation cases from training or retrieval data. A document revised later must not be presented as evidence that existed at the time.
In days 31–60, run the PoC read-only beside the normal review process. Do not write AI candidates to live shop-floor settings. Test missing records, duplicate part names, obsolete documents, multilingual variants, shift boundaries, and approved changes not yet effective. If a reviewer cannot see why an item was proposed, a high hit rate alone is insufficient for acceptance.
In days 61–90, try a limited production workflow with fixed product families, lines, and change types. Attach candidate lists to the approval workflow; quality retains final disposition and cutover authority. Each week classify false positives, misses, and missing data, then log changes to thresholds and connectors. At close, state scope, unresolved critical risks, operating owner, manual fallback, and rollback conditions. A 90-day average score should not automatically authorize rollout to every plant.
Boundary cases for acceptance tests
Include old and new revisions of the same part, specifications split by two customers, WIP lots, purchased items not yet received, temporary dispositions, obsolete paper forms, and a missing equipment ID. When AI says “unrelated,” require it to show what data it examined. Confirm that a direct BOM relationship is found even when text similarity is low; also confirm that similar descriptions from another plant are not merged.
For permissions, check whether one customer’s confidential specification appears in another customer’s search results or summary, whether a requester can impersonate an approver, and whether a user who cannot open a document can still see its contents in an AI response. Logs can contain personal data or pricing; define retention, access, audit logs, and transmission to external AI services in the contract. If the connected PLM is down, the system must report “unverified” and stop the request, not say “no impact.”
RFP requirements and vendor comparison
An RFP needs more than “AI impact analysis.” Specify (1) change types, (2) connected systems and readable fields, (3) part, revision, lot, and effective-date keys, (4) evidence for every candidate, (5) departmental approvals, (6) old-WIP disposition, (7) access controls, (8) audit trails, (9) stop behavior on failure, and (10) evaluation data for factory and site acceptance tests (FAT/SAT). Define how missing data appears and require a reason when a person confirms “not affected.”
Compare how each proposal connects to the authoritative systems, not merely its model name. A solution that reads PLM structures but cannot read MES WIP should be evaluated as a clearly limited use case. If it copies master data, assess synchronization delay, effective dates, and revision conflicts. If it can write back to change requests, initially restrict it to human-approved comments.
Compare total costs beyond licensing: connectors and cleanup, document revision control, reference scenarios, permissions, evaluation datasets, training, monitoring, model updates, and audit support. For charges per change, search, or attachment capacity, request monthly volume assumptions and overage rates. Test multilingual document processing using actual Japanese, Thai, and English samples.
What FAT and SAT should test separately
Use anonymized representative changes in FAT to test candidate extraction, direct-relationship detection, evidence links, critical misses, permission separation, and failure messages. Do not accept only vendor-selected demos. In SAT, use real plant data and workflows to test night shifts, old WIP, paper standards, multiple languages, and PLM/ERP/MES synchronization delays. Even excellent FAT metrics do not establish operational acceptance when SAT reviewers cannot follow the evidence.
Attach concrete pass evidence to the request for quotation. For a change request, the solution should export to CSV or screen the target part and revision, affected parent products and orders, related inspection rules, and work instructions. Each row needs a source-system record ID and retrieval time; its link must open the same revision. Where old WIP remains, the effective-date gate must stay closed until a person decides whether to use, hold, or rework it. If a connector fails, show missing data prominently and never summarize an empty candidate list as “no impact.” Only authorized users should see customer-specific documents. These are testable specifications, not marketing descriptions.
Include preparation of evaluation data in the contract. Agree how many past-change answer lists will be supplied, how many critical cases they contain, whether parent–child part relationships survive anonymization, and how revised answer lists are versioned. Historical omissions matter even if rare. Score difficult cases separately so many easy examples cannot inflate the average into a pass.
The Siemens Teamcenter Change Management fact sheet describes rule-based change management and impact analysis. If your PLM already supplies direct-relationship analysis, use that capability and consider AI for document and exception candidates. Avoid duplicating existing functions, which makes acceptance criteria and accountability harder to define.
Operating responsibilities and update rules
The authoritative change record is the approved PLM or QMS record. Save the AI candidate list with its creation time, source revisions searched, model or rule version, and reviewer. Show differences when candidates change; do not silently rewrite earlier approvals. Manage the timing of AI-index refresh separately from the effective time of source-system changes.
Product developments in 2026 can inform procurement questions. Siemens’ Teamcenter 2606 introduction describes a direction in which real BOM data, rules, and lifecycle context support impact analysis and change execution. This is not a product endorsement; ask vendors what structured data grounds their AI. Autodesk’s October 2026 change-management guide lays out evaluation, approval, implementation, and tracking of changes to products, BOMs, documents, and manufacturing information. New AI features do not remove responsibility for the effective change and old-revision disposition.
Rejected AI suggestions are valuable feedback, but classify reasons such as “different plant,” “obsolete evidence,” “customer specification prevails,” or “operators already trained”; do not learn from click history alone. Human rejections can also be wrong, so require quality to recheck rejected critical effects. A weekly review should compare acceptance rates, later-discovered misses, and false candidates by change type, then decide which connector or rule to improve.
Quality assurance decides release and first-article acceptance. Production engineering owns operations, tooling, and machine settings. Production planning owns orders, WIP, and cutover dates. IT owns connectors, permissions, and logs. Sales or quality checks customer contracts for approval duties. The AI vendor is accountable for candidate-display quality and service operation, not final product-quality approval. Record these duties in a RACI or approval matrix, including delegated-approval conditions.
After go-live, run regression tests whenever part numbering, BOM structure, lines, document locations, or the AI model change. On finding a critical omission, recheck past changes during the affected period and follow the procedure for holding affected WIP and products. Reassess on connector schema changes and customer-specification updates, rather than relying on an annual review alone. These controls are how PoC results can be sustained in operation.
Frequently asked questions
Does AI impact assessment replace a 4M change management system?
No. A 4M system remains the basis for requests, approvals, and records. AI helps present possible affected items and evidence. If PLM or QMS already manages approval, attach AI suggestions there. Moving permissions, history, and effective dates into AI alone obscures responsibility.
Can people skip review if AI says “no impact”?
Not in an initial implementation. Missing data, obsolete documents, and customer-specific exceptions mean a non-detection is not proof of no impact. After validation, a site might adjust the review scope for low-risk routine changes. Authorized people retain gates involving safety, shipment, and customer approval.
What determines the cost of AI impact assessment?
Major factors are the number and quality of PLM/ERP/MES/QMS connections, consistency of part-revision-lot keys, change types, multilingual documents, audit trails, and approval workflow. Compare 12-month connection maintenance, evaluation, and training costs, not only PoC price. Share your change volume and data gaps with vendors so estimates use comparable assumptions.
Which change type should a Thai plant test first?
Choose a recurring change type whose existing request, BOM, routing, and inspection records share IDs. Alternative materials and inspection fixtures are candidates. Customer-approval or safety-related changes need not be absent from evaluation data; they need strict human review. If records exist only on paper, establish revisions and identifiers first.
Conclusion
AI impact assessment for manufacturing process changes should collect evidence about product revisions, operations, inspection, WIP, and instructions for authorized reviewers. Success depends on tracing each change ID to source records, showing missing data honestly, defining the old-to-new cutover, and catching critical misses in acceptance tests. Build a reference dataset for one change type and start with a read-only PoC.
If you are mapping the systems and documents needed for change assessment at a Thai plant, contact TOMAS TECH even before writing your RFP. We can help define a feasible scope and acceptance criteria around the PLM, ERP, MES, and QMS connections you actually have.
References
- NIST, Digital Thread for Smart Manufacturing — Primary source on linking and reusing lifecycle information.
- NIST, AI RMF Core — Govern, Map, Measure, and Manage in AI risk management.
- Microsoft Learn, Engineering change management overview — Product revisions and change management features.
- Microsoft Learn, Manage changes to engineering products — Requests, orders, impact, and approval.
- Microsoft Learn, Engineering change management FAQ — Implications of tracking product revisions in transactions.
- AIAG, APQP 3rd Edition and Control Plan 1st Edition FAQs — Change Management section and checklist.
- Siemens, Teamcenter Change Management Fact Sheet — Change and impact analysis functions.
- Siemens, Introducing Teamcenter 2606 — Official 2026 introduction of AI-assisted change management.
- Autodesk, Engineering Change Management Guide — Practical guide published October 15, 2026.
*All time and quantity calculations here are hypothetical planning examples, not observed performance or general industry effects. Sources were publicly available on October 19, 2026.*
