PIM vs ERP vs CMS in a manufacturing company: What to implement first – and what to do if you already got it wrong

When comparing PIM vs ERP vs CMS, deciding which system to implement first requires an assessment of where key data originates, who is responsible for it, and which processes currently generate the greatest costs or risks. In some cases, the first step will be to organize product data in PIM. In others, it will be to develop the ERP system, while certain circumstances may justify launching a B2B portal earlier. Existing implementations can also be reorganized in stages, without rebuilding the entire environment from scratch.

Why company structure affects the order of PIM, ERP, and CMS implementation

Responsibility for an ERP implementation usually lies with the finance, operations, or IT department. In our projects, the department funding the implementation of a CMS or B2B portal often wants to quickly demonstrate a working catalog, customer portal, configurator, or new sales channel to management. Preparing data in PIM, meanwhile, involves collaboration between marketing, sales, and e-commerce teams, product managers, and employees responsible for technical documentation.

A department with an approved budget may be able to start its own project earlier. Developing a shared data model and integrations then requires agreement with the other teams on funding and the scope of work.

If the portal is launched before the integrations are ready, the team may populate it with data copied from ERP, spreadsheets, and network folders. Marketing then maintains its own product descriptions, while the technical department updates documentation in its own environment. Updating product data therefore requires the same changes to be made in several places.

When discussing the project with management, it is worth presenting the cost of manually updating and reconciling the same data across different systems and channels.

We discuss the ERP vs PIM distinction in more detail in our article on why ERP cannot replace a PIM system.

Launching an online store as the first stage can also make business sense, particularly when a company needs to start selling and generating revenue quickly. In this scenario, the project scope should include a plan from the outset for organizing the data and subsequently integrating the store with PIM, together with the budget, timeline, and person responsible for this stage.

One of our clients planned to launch a Magento store and implement the Akeneo PIM system. The business priority was to start selling quickly, so Magento was launched first and the full PIM implementation was postponed to a later stage. Ultimately, the budget for that stage was not approved. Akeneo was launched with a limited scope, containing basic product information that the team also maintained in Magento. Magento 2 remained the main product database, while Akeneo contained hundreds of products and operated without integration with the store. A solution that had been planned as temporary remained in place for several years. This case illustrates the risk of postponing part of a project to a later stage without securing the budget and implementation timeline.

PIM vs ERP vs CMS: What is the difference, and where does PLM fit?

For each group of data, a system of record should be defined, meaning the system that holds the version of the data considered authoritative within the company. Other systems retrieve this data according to established synchronization rules.

In a manufacturing company, a CMS may be part of a portal for distributors, sales representatives, or business customers. The portal uses data from several systems: ERP can provide prices and availability information, while PIM supplies product descriptions and documentation. The CMS is responsible for content management, while ordering or product configuration functions are handled by the relevant portal modules.

We discuss this approach to B2B channels in more detail in our article on B2B platforms designed as operational tools.

In our project for Fox Fittings, Pimcore provides the foundation for an extensive product catalog and a DXP (Digital Experience Platform) solution integrated with ERP. The system organizes the structure of categories, groups, product types, and attributes, and links products to technical documentation and certificates.

Who should be responsible for specific data?

For each group of data, the company should also identify the person or department responsible for its accuracy and updates. The matrix below shows an example division of responsibilities:

A company may store the source document in its quality management system, keep its metadata in PIM, and make the approved version available through the B2B portal.

When manual data exchange between ERP, PIM, and CMS becomes too expensive

The need to implement PIM should be assessed based on several factors: catalog size, the number of channels and markets, the frequency of changes, the number of language versions, the complexity of product relationships, and the amount of documentation involved.

For example, two manufacturers with catalogs containing 10,000 SKUs each may have completely different needs. The first sells products in a single market and updates its offering several times a year. The second works with multiple distributors, prepares information in several languages, assigns certificates to product variants, and regularly updates technical data.

The amount of work involved can be estimated using the number of manual updates and the average time required for each task:

monthly manual data update time = number of tasks per month × average time per task in hours

The calculation should be performed separately for tasks that take different amounts of time, such as correcting a description, assigning a document, or preparing a file for a distributor. For each group of tasks, multiply the number of hours by the hourly labor cost of the people performing them, and then add the costs together. Documented costs resulting from errors and delays can also be added, excluding any labor costs already included in the calculation.

Two different types of projects illustrate the scale of the problem. In the implementation for ZARYS, the catalog included 10,000 items, and the company exported products to more than 60 countries. In the Emotivo project, carried out in a different industry, data for several thousand items was supplied to PIM by hundreds of vendors. The data was then used on Prezentmarzen.pl and distributed to several or even more than a dozen sales channels, including marketplaces. With manual data management, the workload increases with the number of sources, channels, and updates.

How to fix an existing PIM, ERP, and CMS setup without starting over

An existing CMS and PIM can often be retained by changing how responsibility for data is divided and how the systems synchronize that data. The scope of remediation is determined by the quality of the existing data, the integration architecture, and the number of processes tied to the current systems.

1. Map the actual data flow

For each critical attribute, identify:

• the system in which it originates,
• the business owner,
• the system authorized to update it,
• the direction of synchronization,
• the systems or users that consume the data,
• the frequency of changes.

This type of map quickly reveals fields that are being maintained simultaneously in ERP, spreadsheets, PIM, and CMS.

2. Define the system of record for each attribute

For fields that are updated simultaneously in several places, define a system of record from which the other systems should retrieve the approved data. If product descriptions and attributes are currently maintained in the CMS, this stage may involve migrating product data from CMS to PIM and leaving the CMS responsible for content publishing.

3. Organize integrations and update rules

The next stage covers validation, mapping, error handling, and synchronization rules. The company can introduce these changes gradually, starting with the most costly or risky data flows.

4. Stop maintaining the same data in multiple systems

Once the new synchronization process has been confirmed to work correctly, set a date for ending the existing manual updates. The person responsible for this stage should verify that users have adopted the new way of working. Modernization may involve changing the responsibilities of individual systems and the way they are integrated while retaining the components that continue to perform their functions effectively. We used this approach in the project for ZARYS.

In the ZARYS project, some product information had previously been stored in the ERP system. As part of the Pimcore implementation, we divided responsibility for different groups of data: SAP continued to handle operational data, while product information intended for further enrichment and publication was moved to Pimcore. We took over the project from a previous provider, completed the Pimcore configuration, and finalized its integration with SAP. As a result, SAP and Pimcore now have clearly defined responsibilities and exchange the data required by downstream processes.

We also discuss common sources of problems in projects like these in our article on PIM implementation pitfalls.

What to do when the new ERP Is delayed but PIM is needed earlier 

When the implementation of a new ERP system is delayed, PIM can initially work with data from the existing system, files, or other agreed sources. For this interim solution, the company should define:

• the person responsible for the interim solution,
• the format and scope of the data,
• validation rules,
• how errors will be monitored,
• the target integration method with the new ERP,
• a specific condition for ending the interim solution,
• a review date.

The switch to the target integration should take place after confirming data completeness, correct mapping, and proper operation of the update process. The plan should identify the person responsible for approving the switch, the date when the temporary import will be discontinued, and the rollback procedure in case of an error.

An MVP lets the company launch a limited but useful first version and expand it in later stages. We describe an example of a phased PIM implementation and integration in our article on a quick start to PIM and B2B e-commerce in the medical industry.

How the type of manufacturing affects implementation priorities

The type of manufacturing, sales model, and customer needs help determine which groups of data should be organized during the first stage of an ERP, PIM, and CMS implementation. The role of the customer also matters: an engineer, distributor, and end user perform different tasks and need information prepared accordingly. We explore this distinction further in our article on five customer segments every manufacturing company should know.

Machinery and equipment manufacturer

A sales representative who receives an equipment number needs a list of parts that fit the specific version and configuration of the machine. The analysis should examine how the serial number is linked to documentation and the service parts list, how replacement parts are approved, and which systems provide information about part prices and availability.

If selecting a part requires consulting an engineer each time, the project scope should include recording approved relationships between products and making them available to the sales team. PIM can store information intended for the parts catalog, while the B2B portal can enable searches by model or equipment number. Compatibility rules should be approved by the technical department.

Suggested metric for the first stage: the time from receiving the equipment number to preparing a quote for the correct part. The measurement should also include the number of cases requiring the involvement of an engineer or service team.

Industrial component manufacturer

A component buyer needs data that makes it possible to compare variants and verify their specifications. Dimensions, material, units of measurement, technical requirements, and documents should be clearly assigned to the correct catalog item.

In some industries, product descriptions are standardized using ETIM, a classification model for technical products. It defines product classes, features, values, and units. The identifiers for these elements are language-independent, which helps maintain consistent technical descriptions across different language versions.

The analysis can begin with a file the company provides to a distributor. Check how much data needs to be entered manually, how parameter names are matched, and who resolves discrepancies between the specification and the catalog. If each customer requires a separate spreadsheet, the first stage can include developing a shared attribute model and automatically generating files in the agreed formats.

Suggested metrics: the time required to prepare a complete data set for a new distributor and the number of corrections requested after the data has been delivered.

Process manufacturing, such as chemicals

In process manufacturing, the analysis should begin by examining the relationship between the product, its batch, documentation, and the information used to fulfill the delivery. ERP can manage batch records and data related to product expiration dates.

The project should separately define the sources of batch data, quality control results, and documents made available to customers. Safety data sheets, certificates of analysis, and product specifications should have their own rules for assignment to products, versions, or deliveries. The quality department determines the appropriate scope of publication, while the integration transfers approved information to the portal.

The first stage can establish how to find documents related to a specific delivery and make them available to authorized recipients. Expanding marketing descriptions can be planned as a separate stage.

Suggested metrics: the time required to collect documentation for a specific batch or delivery and the number of inquiries to the quality department that require individual handling.

CAD, DTR, BOMs, and spare parts: What data should be organized?

The table below shows which data and relationships should be reviewed before implementation. The final division of responsibilities between ERP, PLM, PIM, and the document repository should be based on the capabilities of the systems in use and the agreed way of working.

Pimcore provides, among other features, relationships between objects and files, additional data describing those relationships, localized fields, and structures for product classification. With an appropriate data model, these capabilities can be used to represent some of the relationships described above.

When defining a “replacement part” relationship, it is useful to specify the part being replaced, its replacement, the scope of compatibility, and the date from which the replacement can be used. A recommended accessory can be linked to a product through a separate relationship. This distinction makes it possible to define precise rules for product presentation and search in the portal.

The data owner should also define how document changes are handled. A new version of technical documentation may apply to a subsequent version of the equipment. The system storing the documentation should retain files assigned to previously delivered units, together with their relationships to the relevant product versions. The integration should transfer these relationships so that the recipient receives the correct document.

How product data flows between PLM, ERP, PIM, and the B2B portal

PLM, or product lifecycle management, may manage engineering documentation, product structures, and successive design revisions. The CAD environment is used to create models and drawings.

When designing the data flow, it is also important to distinguish between the engineering bill of materials (eBOM) and the manufacturing bill of materials (mBOM). Reconciling them involves engineering changes, variants, and plant requirements. PLM or ERP may be responsible for a given type of BOM, depending on the implementation.

An example data flow:

PLM/CAD → ERP → PIM → CMS and B2B portal

Depending on the architecture, some data may also flow directly between systems:

PLM/CAD → PIM: approved technical parameters, links to drawings, and files intended for external users.

ERP → B2B portal: customer-specific prices, availability, order statuses, and other transactional information.

PIM → CMS and B2B portal: descriptions, translations, classifications, documentation, and approved relationships between products.

The choice of connections should take into account data freshness requirements, system load, and available interfaces. Pricing can be handled by ERP, a separate pricing engine, or a portal module, depending on the chosen architecture.

Which system should own technical product data?

The engineering team should approve changes to geometry, dimensions, and compatibility rules in the system where product documentation is maintained. PIM can retrieve the approved values, combine them with commercial descriptions, and prepare them for publication. Marketing is then responsible for descriptions and translations within the agreed scope, while permissions to modify engineering parameters remain assigned to the technical team.

When validating the integration, it is worth testing a data update for a single product. An engineer approves a new drawing revision. The team then checks which product versions the change applies to, what data is transferred to ERP and PIM, and what the recipient sees in the portal. The test should also cover access to documentation for the previous version.

How to decide what to implement first and measure the result

For the first stage, define the process to be improved, the data required, the scope of system changes, and the person responsible for the result.

The table below can help IT, sales, marketing, and operations teams agree on the first stage of work:

The budget for each stage should cover data preparation, integration, testing, and the time spent by employees responsible for approving the information. Before work begins, the person responsible for the business outcome should define how it will be measured and what result is expected. IT defines the technical dependencies, while the teams responsible for the data ensure that the necessary people are involved and set a deadline for completing any missing data.

If the B2B portal and ERP transformation are being carried out in parallel, the first shared stage can cover a single product family and a selected group of distributors. It should include preparing and publishing the data and verifying whether distributors can complete the planned tasks in the portal. Management then receives results that can be used to make a decision about funding the next stages of work.

Where to start the discussion about ERP, PIM, and CMS in your company

For the first meeting, it is useful to prepare data for one representative product, its documentation, the spreadsheet provided to a distributor, and a description of the most recent data change. When evaluating an existing implementation, a list of integrations, error reports, and a description of the manual tasks involved in updating the catalog will also be useful.

Tandemite provides PIM implementation services, including needs analysis, data model design, integrations, and configuration of product information management processes.

During a consultation with Tandemite, we will review how product data currently flows through your systems and define a practical first stage, whether that means organizing product information, fixing an integration, or developing selected B2B portal functionality.