The need for PIM has grown rapidly. Customers expect richer product data and the complexity of the catalogs increases frequently. Implementing PIM will save company time and money on product data management, especially for large catalogs. As PIM has a clear overlap with ERP, finding a balanced approach is critical for both your daily operations and consumer communication.
There are two main approaches for this: one in which ERP is leading, and the second in which PIM is leading. We’ll cover the advantages and disadvantages for each approach for management, responsibility and New Product Introduction (NPI), and we’ll sketch out typical use cases.
1. ERP Leading
In this approach, the initial product record is created in ERP. The information is shared with PIM where it is further enriched and used for omnichannel publishing purposes.
Clearly defined data flows from ERP to PIM, bringing a distinct core process ownership. The system interface is only a minor process extension and has a minimal TCO. The complete product lifecycle is steered by ERP. Typical ERP related data, such as logistic, Bill of Materials (BoM) and trading data starts and stays in your ERP system. Any enriched data in PIM is 100% added on top of the ERP item master data.
The downsides to ERP leading are several. It mixes up data maintenance workflows in both systems. So, for example, technical attributes required in ERP may differ from channel relevant attributes. To maintain different product content in different systems, users must switch between their systems UI. And if PIM data is required for ERP processes, like language specific data for shipping notes, then the ERP data model must be enlarged. And when purchased parts are a nameable part of master assortment, you’ll have two options. Either the ERP-lead scenario will have to replenished by PIM-lead scenario (“process duplication“), or the ERP data model must be expanded to guide through PIM related content.
Typical use cases
Applications where ERP is in the lead, and the New Product Introduction (NPI) is done in sequence:
- Industry related scenario for self-constructed product assortments
- If there is an established PLM workflow, with common understanding for lifecycle milestones and quality gates
- Purchased parts are not a nameable part and do not affect product assortment
- Units of organization for data maintenance are implemented in sequence
- PLM and/or MDM maintenance user roles are mainly separated from user roles responsible for channel specific product content
- NPI by ERP often based on (already established) product lifecycle processes (for example, product creation, product launch with distinct milestones and quality gates)
2. PIM Leading
In this second approach, the initial product record is created in the PIM system. The information is shared with ERP where a product ID is returned to PIM.
When the suppliers are responsible for actively preprocessing the data maintenance, this reduces process costs. Without immediate ERP representation, mass (supplier) data can be imported, further reducing ERP costs. Multi-supplier data stages are now possible, as well as staged and active category management on the expanded content base. Additionally, putting PIM in the lead gives access to extended supplier data pools for maverick buying purposes. It also offers a basic setup of a PIM related multi-supplier product MDM Scenario. This is the “Golden Record Principle“: one master item for several supplier items.
Of course, there are also downsides of putting PIM in the lead. Firstly, the data flow and data processing become more complex. That means more complex processes and data interfaces to implement and operate. Secondly, data maintenance users must often cover data authoring processes across systems. This scenario also requires a pass through for ERP related supplier data. Either by splitting PIM from ERP related data before PIM import (“data switch point “), or by enhancing the PIM data model with ERP product data model (like logistical data, purchasing prices). The product lifecycle is now split between PIM and ERP responsibility, resulting in more complex data governance. For example, the responsibility for assortment is shared over two systems.
Typical use cases
Applications where PIM is in the lead, and the New Product Introduction (NPI) is done synchronous:
- For typical multi-supplier onboarding scenario for (international) wholesale and retail
- Perfect scenario for long tail strategy
- Mass data handling and process automation
- When channel specific assortment definition is established within PIM
- Units of organization for data maintenance are implemented along End2End product information lifecycle
- Category management starting from strategic purchasing and ends at channel-specific content enhancement and assortment definition
ERP or PIM?
There can be only one initial point where product records are created. This means that you’ll need to choose one of the two options to function as the main PIM architecture base. If you can answer the following questions, then you can make the right decision:
- Is there currently a central point where all product records are initially created?
- Is there a PLM process in place and is it connected to the main ERP?
- Is the ERP providing unique IDs for products that are used elsewhere in the product data process?
- Will everybody involved in product creation have access to the ERP and PIM system?
Have you answered yes to all these questions? Then ERP leading is the best approach. But as in every situation, there are dependencies and company specific requirements were the other option might be more suitable. The key question is therefore: is your current product creation process closely embedded in the ERP environment or not? The last thing you‘ll want to do is to change multiple business processes to accommodate the new PIM system. Aim for minimal changes within your current environment and business processes. And focus on a single point of storage for product information. There is generally no preferred approach, only the approach that fits your situation best.