PLM to ERP: getting the engineering definition into the system that buys and builds

The engineering structure and the production structure are different objects

A design structure groups components as the product is conceived, by function and assembly relationship. A production structure reflects how the plant actually builds: subassemblies that exist because of a work sequence rather than a design intent, consumables and adhesives that no designer listed, parts supplied in different units, packaging, and items sourced as kits. Attempting to force one to serve both leaves either engineering carrying manufacturing detail it should not own, or production maintaining a structure engineering keeps overwriting. Accepting two related structures, with a defined transformation between them, is usually the less painful arrangement.

Who creates the item downstream, and when

Create production items automatically on engineering release and the production system fills with parts lacking the attributes planning needs. Create them manually and the transfer waits on a person, so a released change sits unbuilt while purchasing works from the old definition. The workable pattern is automatic creation of the record with a status that blocks planning until a data owner has supplied procurement type, planner responsibility, lot rules and lead time. That makes the missing information visible as a queue rather than as a silent gap discovered when an order fails to plan.

Effectivity is where the storeroom finds out

A change takes effect on a date, from a serial number, or on a specific order, and the choice has physical consequences. Date effectivity is simple and takes no account of stock already made to the previous version. Order or serial effectivity is precise and demands that both systems track which units were built when. Behind either lies the question nobody enjoys: what happens to the components already on the shelf and on order for the superseded version. Deciding that at release, rather than after the parts are found, is the difference between a planned run-out and a write-off.

A release that half-transfers is worse than one that fails

The scenario to design against is a change where the parent structure updated and one child did not, leaving the production system holding a combination that never existed as a released design. Nothing alerts anyone, and the error surfaces when a build is short of a component or when an obsolete part is issued. Transfers should be treated as a single unit of work that either completes or reverses, with a clear report of what moved and a check that the resulting structure matches the source. Silent partial success is the most damaging failure mode this interface has.

Attributes engineering does not care about and production cannot work without

Unit of measure, whether an item is bought or made, the responsible planner, order sizing rules, storage conditions, inspection requirement, standard cost, shelf life. None of these belongs in a design definition, all are needed before a part can be planned or purchased, and each represents a decision by somebody in operations. The practical approach is to define the minimum set required for a part to be usable, capture it as part of the release process rather than afterwards, and give the request a route with a service expectation, so engineering does not experience data governance as an obstacle to launching a product.

Frequently asked questions

Should the transfer be automatic or reviewed by a person?

Automatic movement of the structure with a review step for the attributes production must supply gives most of the benefit of both. Full automation without review means unusable records appear downstream and planning fails in ways that take time to diagnose. Full manual entry duplicates work and guarantees the two definitions drift apart. Whichever route is chosen, the audit question stays the same: can you show which engineering revision the production structure corresponds to on any given date.

How do we handle parts that exist only in production?

Packaging, consumables, tooling and phantom levels created for a work sequence have no design owner and should not be pushed back into engineering. Give them a numbering range or an attribute that marks them as production-owned, and configure the transfer never to overwrite or delete them when a structure updates. Without that protection, an engineering release can strip out items the plant added, and the loss is usually noticed when a build lacks the label or the adhesive nobody thought to record.

What breaks most often in this interface?

Units of measure and quantity conversions, closely followed by revision handling. A component specified by length in design and purchased in whole lengths, or a liquid designed by volume and bought by mass, will produce quantities that look plausible and are wrong. Revision problems show up as production planning against a superseded structure because a release completed in engineering was never confirmed downstream. Both are worth explicit test cases using real awkward parts rather than clean examples.