A bill of material looks like a simple list until an engineering change arrives. Then it becomes a question of who may change a product structure, when the change takes effect, and which open quotes, orders, work, and inventory records it touches. This article argues a bounded thesis: a manufacturer should settle ownership, decision rights, and operating controls for product structure and engineering change before adding or rewiring technology. The evidence below shows how enterprise systems treat these controls, and it is explicit about where the judgment is ours.
At a glance
- Thesis: a manufacturer should settle ownership, decision rights, and operating controls for product structure and engineering change before adding or rewiring technology. This is professional judgment, not a measured finding.
- Evidence: vendor documentation shows enterprise systems that already encode distinct product structures, validity and effectivity, release keys, revision levels, and role-based change actions.
- Competing consideration: more governance means more steps, roles, and waiting, and tool support for effectivity models varies, so the right level of control depends on your own risk.
The thesis: ownership and controls come before tooling
The broader shift is that disconnected product, order, inventory, work, and quality records are increasingly treated as an operating-model problem, not only a software problem. Our thesis follows from that: define who owns each record and each decision first, then choose the smallest technical response. This is professional judgment, not a measured finding. What the documentation does show is that mature systems already encode ownership and control concepts that a manufacturer must decide how to use.
What the evidence shows about product structures and change control
Product structures are not one thing. Oracle's documentation for JD Edwards describes several types of bills of material, including planning, batch, percent, and manufacturing bills, each used for a different purpose. Oracle also says a properly structured bill of material reflects material flow and how the product is built, and that an inaccurate one might result in problems such as material shortages, inaccurate product costing, and delayed shipments. In Oracle's Engineering flows, items, bills, and routings can be transferred or copied from engineering to production using an engineering change order, which shows engineering and manufacturing structures can be distinct objects.
Change control is where ownership becomes concrete. SAP's learning material explains that a material change can affect related objects such as bills of material, routings, documents, and classifications, and that Engineering Change Management groups affected objects into a coordinated, traceable process. It describes a validity definition so that changes become effective only at the defined point in time, and a release key that makes changes effective in areas such as sales orders, material requirements planning, and shop floor control. SAP also describes revision levels as unique and linked to a specific change number, and notes that for materials and BOMs, assigning a revision level is a deliberate and controlled action performed explicitly.
SAP's S/4HANA material guidance adds that a change number lets a manufacturer understand at any time who made a change to a bill of materials and why, and lists distinct roles: a production engineer who creates change masters and a BOM engineer who applies them. Oracle's command center similarly lets users track manufacturing and engineering bills with all revisions and effectivity dates and analyze pending change orders grouped by stages.
The records themselves also carry lineage. A NIST report on a manufacturing implementation describes a material ledger as the book of records of characteristics, chain of custody, and transformation, built so transformed material could be traced back to its origin. That is a different domain from engineering change, but it illustrates the same principle: traceability must be designed into the record.
Competing considerations
Control has a cost. SAP's own materials describe change records as a container for organizing and controlling the process, with the actual object changes carried out separately, and with workflows assigning tasks to users. More governance means more steps, more roles, and more waiting. Oracle states that its Bills of Material Command Center currently supports date effective bills and that unit effective bills are not supported. Check whether any tool you consider supports the effectivity model your own products require. SAP's course also notes that most changes have been carried out with immediate (day-to-day) validation in its scenario, before planned master data changes were defined in advance. Whether a lighter approach is a legitimate starting point depends on your own risk, and the sources do not settle that question.
Unnecessary control is a cost too, and each added role or step deserves a reason. Which level of governance fits depends on product complexity, regulatory exposure, and how costly a wrong revision is on the floor. The documentation does not quantify that balance, and we do not claim it does.
What this implies for the flow from PLM into ERP, planning, production, and quality
The documentation supports a few bounded implications, framed here as our recommendations rather than sourced facts.
- Treat engineering, manufacturing, and planning structures as separate records with named owners, since the systems above treat them as distinct objects that can be transferred between stages.
- Decide who has authority to approve and release a change, and who may assign a revision, because the systems model these as explicit, role-based actions.
- Define effectivity deliberately. A change that takes effect at a date, or by another rule your tool may or may not support, determines what open orders and work see.
- Name an owner for exceptions: what happens when PLM and ERP disagree, and who contains the impact on open quotes, orders, work, inventory, and quality records.
These are decisions about the operating model. Technology can carry them out, but it cannot make them.
Applying this before your next change
Before choosing a tool or integration, ask your own team these questions and write down the answers:
- Which system holds the authoritative engineering structure, and which holds the manufacturing structure? Who stewards each?
- Who can approve a change, who can release it, and who assigns the revision?
- How is effectivity set, and which downstream records read it: quotes, orders, planning, work, inventory, quality?
- When a record in one system disagrees with another, who is accountable for reconciling it and containing the impact?
- Which controls are essential for your risk, and which add friction without protecting anything?
If the answers are unclear, that is the work to do first. If they are clear, the smallest sound technical response may be a targeted integration, a configuration change, or no new technology at all.