Who should own the item number in a project-oriented business?

When working with PLM and ERP, the question of item numbers almost always comes up sooner or later. Many take it for granted that ERP should own the item number, since that is where purchasing, production, inventory and finance are managed. In businesses with series production and catalogue products, this is generally entirely appropriate. Products have long lifecycles, are ordered repeatedly and require tight control from a logistics and financial perspective.

In project-oriented, engineering-driven ETO companies, however, day-to-day operations often look different. Here, products and components generally exist because a particular project needs them. They are designed as part of the delivery, manufactured once – perhaps a few times – and closed out with the project. Although some designs may be reused later, this rarely happens without a fresh technical assessment and often involves modifications. In these environments, it is less obvious that the item number should necessarily be created by ERP.

The difference between catalogue logic and project logic

Much of the system architecture around PLM and ERP has been shaped by catalogue-based and series production. In that context, it makes sense for the item number to be stable, independent of projects, and primarily governed by logistics and finance. In project-oriented businesses, this picture shifts.

Typical characteristics we see in project-driven environments include:

• items and components are created in response to specific projects
• reuse occurs, but often informally and following a fresh assessment
• engineering drives the decision about what should exist

When businesses try to apply the same numbering scheme as in catalogue-based production, friction often arises. They end up with multiple numbers for what is effectively seen as the same part, and have to make ERP-related decisions early in the design phase, often before either the design or the requirements are clearly defined. Over time, this can make the systems cumbersome to work with, particularly for engineering and project delivery.

Where it often makes sense for the identity to originate in PLM

In many engineering-led ETO companies, it is the design process that effectively determines that a component exists. Not because it is intended to become a standard stock item, but because the project requires it. In such cases, it is often both natural and practical to create the item number in PLM alongside the design.

When the part later needs to be purchased or manufactured, the same number is replicated in ERP. This does not mean ERP loses control; rather, it avoids having to establish a new identity for something that is already clearly defined. CAD files retain their own CAD numbers, and serial numbers are managed separately at instance level, but the business identity itself remains clear and recognisable across disciplines.

In practice, this often means:

• fewer numbers to keep track of in projects
• less translation between engineering and logistics
• better understanding between PLM, ERP and production

Change management and maturity over time

A common concern is that this model weakens control. Experience often shows the opposite. When PLM owns the item number, PLM must also own the decision about which definition is valid at any given time. Revisions, changes and release must be clearly controlled, so that there is never any uncertainty in ERP about what should actually be manufactured or purchased. The difference lies primarily in where the identity originates, not in how tightly it is managed.

Nor does every item have to be treated the same way forever. Many project-based companies successfully distinguish between project items and more standardised items. Project items are created and managed in PLM and replicated in ERP. If a component later proves suitable for reuse, it can be promoted to a more standardised context with stricter rules and clearer ERP ownership.

Summary

There is no universal answer to item number ownership. In businesses with volume production, ERP remains the natural place for this role. In project-oriented, engineering-driven ETO environments, however, we often see that a PLM-driven approach provides a smoother workflow, fewer misunderstandings and a numbering structure that better reflects how people actually work.

Architecture should support the business – not the other way around. If you recognise the challenges described here, it may be useful to step back and take a holistic look at how numbering, ownership and the interaction between PLM and ERP actually work in your organisation today. Often, it only takes small changes for the systems to start supporting your way of working more effectively. Feel free to contact us for a no-obligation discussion about how this can be addressed in practice – ideally based on your own projects and the way you work.