Commercial change control for manufacturing

A customer asks for a different voltage after the controls panel has entered production. Engineering finds that the change also affects the transformer, motor starters, cable schedule, test procedure and site power study. Procurement has placed two non-cancellable orders. The project manager still needs to know whether the promised ship date can hold. Finance needs a price. Production needs to know which work can continue today.

A weak process forwards the email to engineering, opens a change request and waits for departments to reply. Work continues against the old baseline while the OEM debates scope, cost and responsibility. The eventual change quote recovers the obvious new parts and misses the stopped work, supplier cancellation, retest, schedule compression and warranty exposure.

A sound process answers six questions in order: what changed, which accepted commitment it changes, what work the request touches, what the full effect will cost, who can authorize it and which records must change after approval. The change is not finished when the customer signs. It is finished when every affected team works from the revised commitment.

Start from the accepted order

No team can measure a change without a baseline. The baseline should include the accepted proposal, customer purchase order, contract, negotiated exceptions, governing drawings and specifications, product configuration, delivery plan, payment milestones and every qualification that supported the price. A link to the sales order alone rarely supplies enough context.

Record the baseline by revision and effective date. If the customer asks to move a factory acceptance test forward, compare the request with the accepted milestone. If a new specification arrives, compare it with the specification named in the order. If an engineer discovers that the quoted design cannot meet the requirement, preserve the original basis and classify the issue as an internal correction or possible defective customer input. The source and cause affect price, claim rights and customer language.

ASME Y14.35 defines methods to identify and record revisions to engineering product definition and related documents. Commercial control needs the same discipline around the whole order: identify the accepted state, preserve later states and show which work used each one.

Register the request before people act on it

Create the change record when anyone receives a direction that could alter scope, configuration, method, cost or time. Do not wait for a formal customer form. Site meeting notes, marked-up drawings, an engineer-to-engineer call and an email from the buyer can all start the review. The team can reject or reclassify the request later.

Capture the exact words, source, date, requested completion and person who gave the direction. Identify the customer role and whether the contract grants that person authority to change the work. If authority is unclear, the record should say so. A technically reasonable instruction from a site engineer may still lack commercial authority.

The US Federal Acquisition Regulation offers a useful, concrete model even for private industrial work. FAR 52.243-4 covers changes to specifications, methods, furnished inputs and acceleration. It also requires written notice of the date, circumstances and source when an instruction acts like a change. Your contract governs your rights, but the operating lesson travels well: document the direction while the facts remain fresh.

Classify the change before routing it

Different causes need different decisions. A customer enhancement, an internal design correction and a supplier obsolescence can touch the same BOM but create different price, responsibility and approval paths. Give the request one primary cause and record contributing causes separately.

Do not label every customer question a change. A clarification that confirms the accepted baseline may need an answer but no commercial action. The moment the answer changes scope, performance, sequence, responsibility or time, route it through change control. This protects both parties from discovering later that a casual reply changed the deal.

Protect the affected work while analysis runs

A change review needs a containment decision within hours, not after the full estimate. Identify the drawings, work orders, purchase orders and site tasks that could become wrong. Pause only the affected work unless safety or configuration uncertainty reaches farther. Record who issued the hold, its scope and the condition for release.

The team should also decide what can continue. Mechanical fabrication may proceed while electrical engineering stops. Standard parts may remain valid while a custom transformer order waits. A blanket project hold can cost as much as the change. No hold can turn every hour of continued work into avoidable scrap.

Oracle documents this distinction for one-time configure-to-order items. Its change flow can update an untouched work order, put a transacted order on hold for factory review or create new supply when the factory must start again. The correct path depends on the requested configuration and the work already completed.

Build the technical impact from dependencies

Engineering should assess the request against function, interfaces, product configuration, calculations, drawings, software, verification and customer deliverables. A voltage change does not end at one BOM line. It can alter protection settings, heat load, cable sizes, panel certification, test equipment, manuals and spares.

Start with the requested item, then follow explicit dependencies. Ask which requirements allocated to it, which assemblies contain it, which interfaces connect to it and which tests prove it. List each affected object and its current release state. Avoid a narrative such as “engineering impact expected.” It does not tell costing, planning or production what changed.

PLM products specialize in this product-side work. Aras change management connects affected items, impact analysis, approvals and released product data. Siemens describes a similar chain from change request through impact analysis, approval and release in Teamcenter X. Commercial change control should use that product evidence without pretending the PLM record also owns customer price or contract authority.

Trace the effect through supply and production

The estimate must use the current state of each commitment. Ask suppliers whether they can amend the order, which work they have completed, what cancellation charge applies and how the change affects lead time. Preserve the supplier response. A verbal “should be fine” is not a cost or schedule basis.

Inside the factory, list completed labor, open operations, WIP, reserved inventory, cut material, tooling and test work. Decide what the OEM can reuse. A new part may add $20,000 while the stranded custom item adds $70,000. If the team prices only the new BOM, it loses money before the revised work starts.

Show the schedule effect as a dated plan

Do not answer a schedule question with “two-week impact” unless the team can show the path. Start from the accepted milestone plan. Add customer decision time, engineering release, supplier response, material lead time, rework, test and document approval. Identify which task controls the promised date.

Offer choices where they exist. The customer may accept the original ship date with a later retrofit, pay for expediting, approve a temporary configuration or move the delivery. Each choice needs a price, risk and decision deadline. This turns schedule analysis into a commercial decision.

Price the whole change

Build a change estimate with the same discipline as the original bid. Include engineering, material, supplier, production, quality, documentation, logistics, site work and project management. Add the cost of stopping, reworking, scrapping and restarting. Include schedule recovery only when the execution plan names the labor, freight or supplier action behind it.

Separate cost, customer price and contractual entitlement. Cost answers what the change does to the OEM. Price adds margin, risk and commercial strategy. Entitlement answers what the contract allows the OEM to recover. Mixing them hides a conscious concession inside the estimate.

For a clear example of this separation, FAR 52.243-4 links a change in work to cost or time adjustment and written contract modification. Private OEM contracts differ, but a change record should still show the cost effect, requested price effect and final negotiated adjustment separately.

Approve the business decision, not a total

Approvers need to see the request, cause, baseline, technical effect, cost, schedule, contract basis, proposed price and unresolved risks together. A finance approver cannot judge a margin percentage without knowing that the team has excluded $82,000 of stranded supplier work. An engineering approver cannot accept the new configuration without seeing the customer deadline and release plan.

Route by exposure. A small drawing correction that changes no price or date may need engineering and project approval. A concession below target margin needs commercial authority. A change that alters performance guarantees, safety, warranty or liability needs the relevant technical and legal owner even if the price is small.

IFS Contract Change Management tells teams to assess cost, revenue, risk, resources and schedule before they submit a change externally. That is the right shape for approval: one decision package, with the evidence behind each effect.

Send the customer a decision-ready change proposal

The customer document should state the requested change, revised scope, exclusions, price, tax, payment, schedule, validity, assumptions and required authorization. Attach or cite the changed technical baseline. State what work remains on hold and the date when delay or expediting assumptions will change.

Give alternatives when they lead to materially different outcomes. Option A can provide the full new requirement at a later date. Option B can preserve the date with a defined expedite charge. Option C can defer part of the change to site. The options must be executable configurations, not negotiating fog.

Control work before final agreement

Urgent projects sometimes need work before the parties agree the final price. Define a separate authorization-to-proceed path. It should state the maximum spend or hours, allowed activities, interim schedule, commercial reservation and customer authority. Do not treat an email saying “please proceed” as permission for unlimited redesign and supplier commitment.

If the OEM chooses to work at risk, record who approved the exposure and its limit. The project forecast should show that cost even while revenue remains unagreed. Otherwise the job appears healthy until the negotiation ends.

IFS supports this practical distinction. Its contract change process moves a request through registration, analysis, internal and external approval, implementation and closure. The change record can exist before the final contract update, but the status must tell the team what it may do.

Turn approval into revised execution records

Customer approval does not update a drawing, sales order, supplier purchase order or work instruction. Create a downstream action for every affected record, name its owner and confirm completion. The revised customer commitment and product release should share an effective date or clear transition rule.

ERP should receive the revised order lines, price, billing, delivery and supply actions. PLM should receive the approved requirement, configuration and engineering change. Project controls should receive the schedule and forecast. Procurement should amend or cancel supplier commitments. Quality should update inspections, tests and certificates. CRM should retain the customer communication and commercial status.

Use effectivity to prevent mixed configurations

A revision number says that something changed. Effectivity says where the new state applies. Record the serial number, lot, unit, date, operation or installation event that separates old and new configurations. This matters when one unit has entered assembly, another waits for material and a third has not started.

For each affected object, identify the last valid old state and first valid new state. Check WIP, replacement parts, manuals and software against that boundary. If the customer accepts a temporary configuration, record its expiry and the retrofit obligation. Do not leave production or service to infer the answer from email timing.

Update the forecast before the negotiation ends

The project forecast should include probable change cost when the work becomes likely, even if the customer has not agreed the revenue. Show approved, submitted and unagreed change values separately. Hiding the cost until signature overstates margin. Booking all requested revenue before agreement overstates recovery.

IFS EAC Workbench brings contract change orders into estimate-at-completion forecasts and distinguishes their status. The useful management view is a bridge: original forecast, approved changes, probable unapproved cost, requested revenue, agreed revenue and current margin.

Worked example: a $9.6 million packaging line

An OEM is building a $9.6 million packaging line for a food producer. Six weeks after order release, the customer requests 600 V power instead of 480 V, washdown upgrades around two machines and a factory acceptance test three weeks earlier. Mechanical design is 70% complete. Panel production has started. The OEM has ordered drives, custom stainless enclosures and the main transformer.

The change owner links the request to the accepted proposal, electrical specification Rev B, configuration C07 and contract milestones. Controls engineering stops the affected panel work. Mechanical fabrication outside the two washdown zones continues. Procurement asks each supplier for amendment, cancellation and lead-time options.

Engineering finds 37 affected documents, 11 BOM changes, four software settings and six tests that must repeat. The current transformer cannot support 600 V and carries a 35% cancellation charge. Two enclosures can be modified; one must be replaced. Accelerating FAT requires parallel software checkout, Saturday panel labor and air freight for one drive package.

The full incremental cost is $287,000: $96,000 of new material, $41,000 of stranded commitments, $58,000 of engineering and rework, $52,000 of acceleration, $24,000 of repeat testing and documentation, and $16,000 of project and site work. The approved customer price is $365,000. The proposal offers the original FAT date for $311,000 or the accelerated date for $365,000. The customer selects the accelerated option and signs by the supplier decision deadline.

Approval opens 24 downstream actions. ERP receives the revised order value, billing milestone and work orders. PLM releases configuration C08 with serial effectivity. Procurement amends three orders. Quality updates the FAT procedure. Service receives the 600 V installed configuration and revised spares list. The change closes only after finance confirms billing and every downstream action has finished.

Measure recovery, speed and execution quality

Count money and time together. A fast response that omits stranded cost is not good performance. A complete estimate that reaches the customer after the supplier deadline also fails. Compare similar changes by cause, product family and execution state.

Review closed changes against actual cost and schedule. The variance should improve the next estimate. Also inspect rejected and withdrawn changes. They still consume engineering and project time, and they often reveal unclear contracts or products that invite late customization.

Choose software by the broken part of the process

PLM is the right center when engineering product change is the main problem. ERP or project software is the right center when the company needs contract, cost, supply, manufacturing and forecast control inside one established suite. A contract lifecycle product can own legal amendment and signature. None of those choices automatically assembles the customer request, accepted commercial baseline, product impact, supplier evidence and approval decision across the existing stack.

Bourne fits when the systems exist but employees still assemble the change through email, spreadsheets and meetings. It reads the request and baseline, creates the impact case, asks each system and owner for the facts it needs, drafts the customer response and writes the approved result back. ERP, PLM and CRM continue to own their records.

How Bourne runs commercial change control

Bourne starts with the customer request and the approved order package behind it. It identifies the affected commitment, preserves the sources and builds a change case across engineering, suppliers, WIP, cost, schedule, contract terms and forecast. Each person sees the evidence needed for a specific decision.

The application can draft supplier questions, technical impact tasks, a price bridge and the customer change proposal. Your team approves judgments, commercial positions and release decisions. After customer authorization, Bourne updates or creates the approved records in CRM, ERP, PLM, project, procurement and quality systems, then tracks every action to closure.

This matters most when no one system owns the full change. The buyer’s request starts in email. The contract sits in a document repository. Product impact belongs in PLM. Commitments and cost sit in ERP. The forecast sits in project controls. Bourne turns those records into one decision and returns the result to each owner.

Pilot the process on closed and live changes

Start with five closed changes whose actual cost and outcome are known. Include a customer enhancement, an internal correction, a supplier-driven change, an acceleration request and a rejected change. Rebuild each case from its original sources. Compare the proposed system result with what the company actually recovered and spent.

Then run two live requests in parallel with the current process. Require the pilot to find the accepted baseline, issue a containment decision, identify affected records, build a supported cost and schedule response, route the right approvals and create downstream actions. Measure the human hours needed to prepare the case as well as elapsed time.

The pilot passes when a reviewer can trace every material cost, date and scope statement to a source; production can tell what it may build; the customer can make a clear decision; and the approved change reaches every affected system without a second manual reconstruction.

Buğra Gündüz

Buğra Gündüz is the co-founder and CEO of Bourne and co-founder of HockeyStack. He built HockeyStack into an eight-figure AI business. At Bourne, he works with entrepreneurs and established companies to create AI products and services.