Engineering Change Management Across Company Boundaries

Coordinating product delivery across applications and company boundaries

Every day brings another example of software being built with AI. People are creating new applications, adding AI capabilities to familiar tools, and rebuilding existing workflows around their own needs. For anyone looking to become more productive, the question is increasingly practical: what could I automate, improve, or build myself?

Engineering and product development offer many opportunities for this kind of improvement. An engineer can automate a repetitive task, prepare a report, create a tool for a specific calculation, automate CAD or simulation work. These improvements matter. They can remove friction from work people do every day.

As engineering change management work moves between engineering, purchasing, suppliers, and manufacturing, the coordination problems become especially painful. A faster engineering task can leave the team waiting for a supplier’s clarification, an approval, or confirmation that the manufacturing partner is working from the applicable revision. Each person can improve their own process while the product still waits between them.

I came across the article “The Next Engineering Giant Might Sell Parts,” by Mark Burhop. He points to a practical opportunity for engineering software. Here is the passage that caught my attention: “For a product manager, the practical opportunity is the work between applications. Consider a customer approving a change to a housing. Someone must identify affected manufacturing instructions, make sure the correct revision reaches suppliers, and determine which inspection evidence needs updating. A faster model edit helps. Carrying the change through those steps could solve a larger problem.” 

The large problem is the one that makes total sense to me – Mark describes a customer approving a housing change and the work that follows: identifying affected manufacturing instructions, getting the applicable revision to suppliers, and determining which inspection evidence needs updating.

I found it important because it connects directly to the problem we see with our customers every day. Engineering, planning, procurement, supply chain, contractors – the communication and alignment is hard. At OpenBOM, we are exploring the same problem in our OpenBOM Launch Master. 

We see applications and people often belong to different companies. Following a change through production means coordinating people whose responsibilities, systems, and commitments extend beyond your own organization.

A change becomes consequential when someone else has to act on it. The supplier needs to understand what to manufacture. The contract manufacturer needs to prepare the assembly process. Quality needs to establish which evidence supports acceptance. The person responsible for the build needs to know whether their combined answers still support the required quantity and date.

A change travels through several companies

Consider an illustrative example. A manufacturer is preparing a build of 50 assemblies. Each requires one housing at revision D, available at the contract manufacturer by November 30. Engineering has revised a connector opening and approved the updated definition.

The housing supplier previously committed to November 26. But that commitment covered revision C. Revision D requires a programming update and a review of the fixture. The supplier has received the new package, but has not yet confirmed its effect on delivery. Meanwhile, purchasing still has the original date in its records.

The contract manufacturer has its own preparation work. Someone must determine whether the change affects assembly instructions or tooling. The quality team must review which inspection requirements changed and whether existing evidence remains applicable. Any housings already made to revision C need an explicit disposition for this build.

Engineering has completed its approval. The supplier has acknowledged the files. The purchasing record contains a delivery date. Yet the build owner still lacks a confirmed answer about 50 revision D housings at the assembly location by November 30.

The same pattern applies to a material change, component substitution, revised quantity, or new customer requirement. It also runs in the other direction. A supplier can report a shortage or a longer lead time that requires engineering to evaluate an alternative. Each change can affect an agreement made elsewhere.

Communication needs a clear product reference

“We are on schedule” is useful information when everyone understands what that schedule covers. In the housing example, the statement needs a part identity, applicable revision, quantity, and a date whose meaning is clear. Arrival at the assembly location and dispatch from the supplier describe different events.

Company boundaries make this harder. The supplier may use its own part number. Its quotation can reference a particular drawing, while the purchase order refers to an internal Item. Connecting these references allows people to see whether they are discussing the same requirement.

The response itself also has stages. Acknowledging receipt establishes that a package arrived. Technical acceptance establishes agreement on what is required. A delivery confirmation establishes a commitment under stated conditions. Each stage answers a different question about the work.

Launch Master could help make those questions specific. For example: Does your November 26 commitment cover 50 housings at revision D, available at our contract manufacturer? If it depends on a fixture decision, who must make that decision, and by when?

Supplier collaboration needs shared product context

This coordination needs a common reference that participants can return to as their work changes. In Who Is Holding Your Product Launch Together?, I described a launch commitment through its configuration, quantity, milestone, and date. That commitment gives the surrounding information a practical purpose: determining what supports the build and what requires attention.

OpenBOM already provides a foundation for this work by connecting Items, BOMs, files, revisions, and sourcing information. Our approach to supplier collaboration supports sharing selected product information across companies, with permissions and views appropriate to the participants. Companies can also use familiar Excel, PDF, and ZIP exchanges as part of their process.

A supplier can continue using its own manufacturing systems while sharing the evidence relevant to an agreed handoff. The OEM can retain control of the engineering definition. The contract manufacturer can contribute its requirements and responses. The information owner determines what is shared, and missing information remains an explicit question for the responsible participant.

The Product Context Graph connects that product information with the work around it: questions, findings, decisions, and dated commitments. For the housing, the useful connection is between the required revision, the supplier’s response, the affected build, and the conditions behind its promised date.

How Launch Master could coordinate the work

Launch Master remains a proposed application direction. Our initial focus is engineering and sourcing alignment and material readiness for a defined build. Manufacturing preparation and inspection coordination describe a broader direction we want to explore as the supporting information and checks become available.

For the housing example, I would want Launch Master to help the build owner work through the following steps:

1. Define the commitment. Identify the applicable configuration, required revision, quantity, and material need date at the assembly location.
2. Connect the evidence. Bring together the approved definition, supplier quotation or response, purchase reference, and any supplied preparation requirements. Confirm identities and relationships when they are ambiguous.
3. Expose the unresolved dependency. Show that the recorded supplier date covers revision C while the build requires revision D. Keep the revision D commitment unconfirmed until the supplier provides an applicable answer.
4. Prepare the next action. Help the buyer ask for a revised commitment and identify any engineering decision the supplier needs. Assign responsibility and a due date for the follow-up.
5. Reassess the build. When a reviewed response arrives, compare its quantity and usable arrival date with the requirement. Keep other open dependencies visible.
6. Verify closure. Recheck the condition using current evidence. A completed task records progress; closing the finding requires evidence that its specific condition has been resolved.

Software can perform explicit comparisons and quantity calculations. AI can help interpret supplied information, investigate a finding, explain its implications, and prepare a focused question. Engineers approve technical changes, suppliers confirm their commitments, and the build owner makes the delivery decision.

Agreements need to be preserved for the next change

Suppose the supplier confirms that revision D housings can reach the assembly location on December 3. The response resolves one uncertainty and exposes a date conflict. The build owner now has a specific issue to discuss with engineering, purchasing, and the contract manufacturer.

The team might investigate expediting the work, changing the build sequence, or approving a limited use of existing revision C housings. Each option needs its own evidence and authorization. An exception accepted for this build needs a clear scope so that a later program does not inherit it accidentally.

This is also where Product Memory becomes useful. Preserving the supplier’s response, the engineering disposition, and the reason for a decision helps the next person understand the plan. If the quantity increases or the required revision changes again, Launch Master could identify which earlier confirmations need review.

The coordination continues after an update is distributed. A new response changes what is known. A missed decision date changes the available options. The shared picture needs to reflect those developments so the build owner can act while there is still time.

Measure the work completed between companies

Mark’s article asks how much of the customer’s work engineering software could carry through dependably. For Launch Master, I would measure progress through the time needed to obtain an applicable supplier confirmation, the unresolved dependencies found before a material deadline, and the effort people spend reconstructing the current situation.

A practical place to begin is one build, one engineering change, and one supplier handoff. Establish the requirement, connect the available evidence, and see whether the team can reach a clear answer with less chasing and fewer assumptions. Our build readiness direction starts with this kind of defined job.

At OpenBOM, we are exploring how Launch Master can help the people responsible for these commitments coordinate the work across applications and companies. If you manage engineering changes, supplier relationships, or product builds, I would like to hear where that coordination becomes difficult for your team.

When engineering approves a change, who confirms that the commitments across your suppliers and manufacturing partners still hold?

At OpenBOM we help companies to coordinate their work across multiple disciplines, departments, organizations, suppliers and contractors. 

REGISTER FOR FREE and explore how OpenBOM can help you. 

Best, Oleg