A product definition typically lives in three or four places before it reaches the person building it. CAD holds the design. A PLM or document system holds the released version. ERP holds the planning and costing view. The floor holds work instructions. Each handover is an opportunity for the versions to diverge, and given enough time they reliably do.
How Drift Happens
Rarely through negligence. A designer updates a model and the release to PLM happens a week later. Someone corrects a part number in ERP directly because a purchase order was urgent, and the correction never travels back. Work instructions are updated for one line and not the other. Each step is reasonable in isolation.
The compounding problem is that nobody can tell which version is authoritative. Ask which system holds the current BOM and you’ll often get different answers from different departments, all delivered with confidence.
Establish Direction of Authority
The single most useful decision is declaring, per field, which system is the master and which are copies. Design geometry and structure originate in CAD. Release status and revision control belong in PLM or your document system. Purchasing data, costing, and planning parameters belong in ERP. Manufacturing-specific content — consumables, packaging, routing — belongs in the manufacturing system.
Then enforce it. A field mastered elsewhere should be read-only where it’s copied. This feels restrictive to the person who wants to make a quick fix, and it’s exactly the restriction that prevents drift.
Transfer Structure, Not Just a List
A common integration failure is flattening. The CAD assembly structure carries information — what belongs to what, at which level — and a transfer that reduces it to a flat parts list loses it. Someone then rebuilds the hierarchy manually in ERP, and now you have two structures maintained separately.
Transfer the structure, and preserve the mapping so a change at one level can be traced to everywhere it appears.
Reconcile On a Schedule
Even good integration drifts, because manual corrections happen. Run an automated comparison periodically — weekly for active products — that reports structural differences between systems. Not to block anything, just to surface discrepancies while they’re small and someone still remembers why.
Most manufacturers who run this for the first time find more differences than expected, and most of them are old.
Watch the Part Numbering
Sync problems often trace back to identifier mismatches: a part number with a suffix in one system and without in another, a supplier part number used where an internal one should be, or the same physical component entered twice under different codes by two people.
Duplicate part numbers are particularly corrosive, because they split stock, split demand, and make every downstream calculation quietly wrong. Deduplicating the item master is unglamorous work with an unusually good return.
Prevention is cheaper than cleanup. A single owner for item creation, with a search-before-create step, stops most duplication at source. It slows down the person creating the part by a minute and saves years of downstream confusion.
ticktick.ai reads BOM structure from existing systems with defined field ownership, and reports structural divergence rather than silently overwriting.
