Can engineering data simply be held in the business system?

For a stable product maintained by a small team, often yes. What the business system does not usually provide is relationship-aware file management, a formal change workflow with impact assessment, and a revision history that explains why something changed. Whether you need those depends on how frequently designs move, how many people touch them, and whether anyone will ever ask you to demonstrate control over the design process. Where changes are rare and one person owns them, the additional system may add more administration than value.

Which system should own the part number?

Whichever one you designate, applied consistently, with the other referencing it. Problems arise from having two numbering schemes with an informal mapping between them, so a part is known by different identifiers in engineering and in purchasing. Decide where numbers are created, who may create them, and how the identifier flows to the other system. The choice matters less than the discipline; what causes lasting damage is allowing both systems to mint identifiers independently and reconciling them by memory.

How do I know the engineering side has become the constraint?

Look for specific symptoms rather than general frustration. Parts built to a superseded revision. Time spent locating the current drawing. Changes made without anyone assessing their effect on stock, tooling or service. Two engineers with different versions of the same file. Suppliers asking which revision applies. When those appear regularly, the definition itself is out of control, and improving transactional systems will not touch the cause because the wrong information is entering them correctly.

PLM or ERP: where the product definition lives before it becomes an order

One system holds what the product is meant to be — models, drawings, revisions, approvals, the reasoning behind a change. The other holds what the business does with it — items, costs, purchase orders, works orders, stock. Both contain something called a bill of materials, and they are not the same list. Whether to invest in the engineering side or the transactional side depends on which of those two records is currently causing you to build the wrong thing.

Comparison criteria

Criteria are stated explicitly and neither option is declared a winner: which one fits depends on the constraint that binds hardest in your operation.

Criterion	PLM: the engineering definition and its change control	ERP: the manufacturing item master and its transactions
Which product structure it owns	The engineering structure: how the product is designed, organised by function and assembly, carrying revisions and the documents attached to them.	The manufacturing structure: how it is actually built and bought, organised by operation and stocking level, carrying costs and lead times.
How a change is handled	As a controlled process — a request, an assessment of impact, an approval, an effectivity decision and a released revision with a recorded reason.	As an update to master data, effective from the moment it is saved unless someone has built a discipline around versioning and effectivity.
Document and model management	Native. Models, drawings, specifications and test reports are held with their relationships and revision history intact.	Peripheral. Documents can usually be attached to an item, but relationships between files, and between a file and a revision, are not maintained.
Who works in it every day	Designers, engineers and quality staff, who need to see why something is the way it is and what else a change would affect.	Planners, buyers, stores, production and finance, who need quantities, dates, costs and availability.
Evidence it produces for a regulated product	A traceable history of design decisions, verification and approvals — the record you must produce when asked to show a product was developed under control.	A traceable history of what was purchased, made and shipped, tied to lots and orders, which is the production half of the same story.
The failure it prevents	Building to a superseded revision, or two people changing the same design in different directions without either knowing.	Items that cannot be planned, priced or purchased because they exist only in an engineering file that operations never received.
Sharing definitions outside the business	Designed for it. Suppliers can be issued a controlled revision and notified when it supersedes, with a record of who holds what.	Awkward. Drawings tend to be emailed alongside purchase orders, and nobody can say afterwards which revision a supplier is working to.
Integration burden	Requires a defined transfer of released structures and documents downstream, plus rules for how engineering items become manufacturing items.	Requires nothing extra if the engineering definition is maintained inside it, at the cost of the change control and document handling described above.

Choose PLM: the engineering definition and its change control when

Revisions circulate as files and somebody has already built to an outdated one
You must be able to show an auditable design history for the product you sell
Several engineers work on the same design and their changes have to be reconciled
You release designs to more than one plant or supplier and must control which revision they hold

Choose ERP: the manufacturing item master and its transactions when

The item master and standard costs are unreliable enough that planning cannot be trusted
Your product is stable and design changes are genuinely infrequent
Purchasing and production cannot see requirements without someone assembling them by hand
A small engineering team already keeps a workable file and revision convention

The two bills of materials must be reconciled by design

An engineering structure describes the product as designed; a manufacturing structure describes it as built and bought, with stocking levels, phantom assemblies, consumables and packaging that engineering has no reason to model. The transform between them is real work and needs an owner. Where it is done manually and repeatedly, errors accumulate exactly where they are least visible: a component substituted in one structure and not the other, a level added for planning and never reflected upstream. Whether the transform is automated or performed by a person, write down the rules, decide who approves the result, and check periodically that the two lists still describe the same object.

Change control is where the money is either saved or lost

A design change is cheap on the day it is approved and expensive on the day it takes effect. Somebody has to decide when it applies, what happens to stock built to the previous revision, what is already on order, whether service parts remain interchangeable, and who needs telling. Doing this in an unmanaged way produces the familiar outcomes: obsolete inventory discovered at year end, a supplier still shipping the old part, a service department holding spares that no longer fit. The value of formal change control is not the paperwork but the impact assessment that happens before anyone commits to a date.

Suppliers need controlled revisions, not attachments

Most manufacturers issue drawings to suppliers by attaching them to purchase orders or emailing them to a contact. That works until a revision changes, at which point nobody can say with certainty which version each supplier holds, and the first evidence of the gap is a delivery of parts made correctly to an obsolete drawing. The remedies are unglamorous: a register of which revision each supplier is working to, a notification process when a revision supersedes, and a requirement that a supplier quotes the revision on its documentation. These cost little and prevent a category of failure that is otherwise almost undetectable in advance.

Frequently asked questions

Can engineering data simply be held in the business system?: For a stable product maintained by a small team, often yes. What the business system does not usually provide is relationship-aware file management, a formal change workflow with impact assessment, and a revision history that explains why something changed. Whether you need those depends on how frequently designs move, how many people touch them, and whether anyone will ever ask you to demonstrate control over the design process. Where changes are rare and one person owns them, the additional system may add more administration than value.
Which system should own the part number?: Whichever one you designate, applied consistently, with the other referencing it. Problems arise from having two numbering schemes with an informal mapping between them, so a part is known by different identifiers in engineering and in purchasing. Decide where numbers are created, who may create them, and how the identifier flows to the other system. The choice matters less than the discipline; what causes lasting damage is allowing both systems to mint identifiers independently and reconciling them by memory.
How do I know the engineering side has become the constraint?: Look for specific symptoms rather than general frustration. Parts built to a superseded revision. Time spent locating the current drawing. Changes made without anyone assessing their effect on stock, tooling or service. Two engineers with different versions of the same file. Suppliers asking which revision applies. When those appear regularly, the definition itself is out of control, and improving transactional systems will not touch the cause because the wrong information is entering them correctly.

Data limitations

Manufacturing figures are operator-supplied inputs, not market data. GeoBusinessIQ holds no factory costs, production volumes, yields, cycle times, tooling prices or capacity data and does not estimate them — every result reflects only the figures you enter.
No manufacturer, supplier, vendor or factory is recommended, rated or ranked anywhere in this cluster, and no directory of them is published. Selection material describes how to run your own assessment; the assessment itself remains yours.

Explore the graph

Logistics & supply chain

Across GeoBusinessIQ

Sources

National Institute of Standards and Technology — NIST (accessed 2026-08-30)
Covers: Measurement science, manufacturing technology research, cybersecurity frameworks, and industrial standards support.
Does not cover: Certification of products, endorsement of vendors, or costs for any specific implementation.
Why it matters: A United States federal research institute whose public material covers measurement, manufacturing technology and control-system security.
Review cadence: annual
United Nations Industrial Development Organization — UNIDO (accessed 2026-08-30)
Covers: Industrial development analysis, industrial statistics methodology, and manufacturing capability programmes across member states.
Does not cover: Company-level data, factory costs, supplier information, or real-time production statistics.
Why it matters: The United Nations agency for industrial development; used for structural framing of how manufacturing sectors develop, never for point figures.
Review cadence: annual
International Organization for Standardization — ISO (accessed 2026-08-30)
Covers: International standards for quality management, environmental management, occupational health and safety, and industrial processes.
Does not cover: The content of any standard, conformity decisions, or certification status of any organisation.
Why it matters: Cited so a reader can reach the issuing body's own public description of a standard. Standard text is never reproduced here.
Review cadence: annual

Educational and operational information only — not legal, engineering, safety, customs, tax, or financial advice. Requirements vary by jurisdiction, product, process, and contract; confirm with the relevant authority or a qualified professional before acting.

Last updated: 2026-08-30