This infographic compares how PLM and ERP divide manufacturing responsibilities across five connected business processes.
Manufacturers rolling out PLM alongside an ERP such as SAP S/4HANA, whether together or in phases, always run into the same question: which system owns what? Both offer BOM and change management capabilities, so deciding by feature comparison alone often leads to disconnected BOMs and engineering changes that never reach the shop floor.
This article is written for PMs, CIOs, and especially PLM leaders at automotive suppliers and other manufacturers evaluating PLM and ERP. It sets out a clear ownership principle and applies it to four practical themes.
The deciding factor is not who uses the data, but why the data exists.
This aligns with the view that “PLM should normally own the engineering product definition and engineering change process,” while “ERP should normally own transactional and operational data such as inventory, purchasing, supplier transactions, standard and actual cost, production orders, financial records, and material planning” (Nora PLM).
SAP has its own BOM and change management functions. SAP still offers integration with external PLM systems, because discrete manufacturers running SAP as their ERP often run a separate engineering PLM for CAD and change management (Demystifying PLM).
The goal is not to collapse everything into one system. It is to assign a single system of record for each data domain, and let the other system consume that data.
SAP’s own guidance states that data exchanged between systems “should be reduced to a minimum,” so that “any data and logics which is needed only in one system should not affect the other system at all” (SAP Help). The principle is to pass only what is needed, under controlled change, rather than synchronizing everything.
| Domain | PLM (System of Record) | ERP / SAP S/4HANA (System of Record) |
| Market needs and requirements | Capture, evaluate, and link requirements to parts | Provide sales and order data as decision input |
| EBOM, CAD, documents | Owner | Reference only |
| MBOM and routings | Process planning and MBOM authoring | Executable MBOM, production versions, routings, MRP |
| Engineering change | ECR/ECO/ECN, impact analysis, approval | Change master with effectivity, execution |
| Quality corrective action | Nonconformance to CAPA to engineering change | Inspection and production records (with MES) |
| Cost | Target cost, should-cost, what-if scenarios | Standard and actual cost |
Some sources treat MBOM as owned by ERP, while others recommend PLM as “the master for approved parts, specifications, EBOM/MBOM, and routings” (Koala Feedback). A balanced view is that “MBOM ownership can sit in PLM, ERP, or a connected manufacturing layer depending on where manufacturing engineering actually authors and controls the production definition” (Nora PLM).
In practice, it helps to separate authoring the MBOM (process planning, bill of process) from holding the executable MBOM.
Market and customer needs should be captured as requirements in PLM, evaluated, prioritized, and linked to products and projects. A useful approach is to “centralize ideas, requirements, and market inputs, then connect them to products and projects” (Koala Feedback).
SAP’s standard integration also covers new product development and introduction (NPDI), which includes early-phase steps “such as developing high-level product structures, requirements” (SAP Help). ERP should not be the system of record at this stage; it supplies supporting data such as sales history and cost.
When improving an existing product or adding features, updating the EBOM is only the start. You also need to confirm which MBOMs, operations, plants, and production plans are affected, and release the change downstream at the right time.
Impact analysis and approval belong in PLM; release to ERP should be governed by change numbers and effectivity dates. In the SAP–Teamcenter integration, the Teamcenter Change Notice is brought into SAP as a Change Master, and “the BOM update is done with proper change management, so dates for effectivity are brought across and kept” (SAP Community).
Field service requests and failure reports work best as a two-way flow: they enter through ERP, and design decisions are made in PLM. In one SAP–Teamcenter scenario, “a problem report is created in SAP S/4HANA (as change record), and the affected item is sent as reference to Siemens Teamcenter,” where a change request and change notice are then derived (SAP Community).
The weak point is often the step from change request to change order: accept, offer an alternative, or defer to the next model. Building that decision into a PLM workflow, and recording rejections and deferrals as well, turns service feedback into a reusable asset for the next product generation.
Closed-loop quality brings test, inspection, and field-failure data back to design and manufacturing. Siemens describes analyzing production data captured by MES and “closing the loop to product and manufacturing engineering departments for continuous improvements” (Siemens).
Target cost and should-cost belong in PLM; standard and actual cost belong in ERP. Feeding actual manufacturing costs back to engineering improves design-to-cost accuracy (SymplProcess). Teamcenter’s costing capability, for example, supports “technical and business what-if scenarios” (Siemens Teamcenter Product Costing).
Divide PLM and ERP responsibilities by the purpose of the data, not by feature availability. PLM owns product definition and change; ERP owns transactions and execution. Then put two flows at the center of your design:
With both flows in place, manufacturers can speed up new product development, make engineering changes reliable, and improve quality while reducing cost. PLM leaders should treat the ERP boundary and the feedback flows as core design topics from the very start of the program.
Note that this article does not directly address automotive-specific requirements such as IATF 16949 or APQP/PPAP. These should be assessed separately against each company’s quality management system.
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
ERP implementation in global manufacturing requires critical decisions about ERP scope, surrounding applications, global standardization,…
Measure SAP S/4HANA ROI over just three years and you will mostly see cost. This…
Explore how SAP Digital Manufacturing supports FPC production, including quality management, traceability, S/4HANA integration, implementation…
What does AI need to rate stakeholder power and interest as High, Middle, or Low…
How can AI streamline TOGAF stakeholder management? This guide outlines a practical six-step process, from…
Do Tier 1 and Tier 2 automotive suppliers really need MRP? Discover when SAP S/4HANA…