A detailed framework outlining key stages and roles in SAP PLM investment decisions
For Tier 1 automotive suppliers, one of the hardest decisions in SAP and PLM programs is deciding which platform to fund first, and how to phase the rollout. TOGAF® ADM Phase F, Migration Planning, provides a practical way to turn that decision into an executable migration plan based on dependencies, value, risk, and resource constraints.
TOGAF® Phase F is not a phase for simply comparing SAP against PLM in isolation. Its purpose is to finalize the Architecture Roadmap and complete a detailed Implementation and Migration Plan that reflects project priority, dependencies, costs and benefits, resources, and risk.
In other words, Phase F answers a more important question than “Which should come first?” It asks, “What sequence is most likely to succeed as an integrated change program?”
Phase F does not end when every project has gone live. It ends when the migration scope has been organized into a coherent plan, with priorities, dependencies, timing, delivery responsibility, and required resources clearly defined.
That means it is normal for Project A to start first, while Project B and Project C are refined later as the program learns more. The key is that later work is not unmanaged; it is already positioned within the overall roadmap, with clear conditions for moving forward.
In a Tier 1 manufacturer, SAP governs core operations such as finance, procurement, inventory, production, and sales, while PLM governs product-centered information such as engineering BOMs, specifications, design changes, cost planning, and the handoff to mass production.
Because the two systems play different roles, improving only one side does not necessarily optimize the whole enterprise. Phase F is where these interdependencies must be translated into project sequencing.
This is especially important in automotive parts manufacturing, where EBOM-to-MBOM conversion, design change propagation, and synchronization of item, process, and procurement information during launch are critical. If PLM is not defined clearly enough, SAP may end up with repeated item registration and rework; if SAP control rules are immature, PLM-first deployment can create instability in cost and inventory control after ramp-up.
The most basic rule is to invest first in the prerequisite that enables later work. If BOM standardization, design attributes, or change control in PLM are not stable, SAP material master and procurement data will be difficult to operate consistently.
In that case, PLM standardization and master data preparation become the enabling investment for SAP rollout. On the other hand, if product data is already reasonably standardized and the main issues are accounting control, inventory visibility, and cost tracking, then advancing SAP core processes first is reasonable.
TOGAF® Phase F requires each work package to be assessed in terms of business value and risk, not just urgency or intuition.
For example, if repeated handoff problems between design and mass production are causing rework, strengthening PLM-based change management may deliver high value. If the business is under pressure to improve audit readiness, month-end closing, or inventory reduction, SAP finance and inventory visibility may deserve priority.
Even a correct plan fails if engineering, SCM, IT, and external vendors cannot all participate at the same time. TOGAF® explicitly expects Phase F to estimate resources, timing, and delivery responsibility.
Tier 1 suppliers also face practical constraints such as launch periods, customer audits, and peak engineering workload. For that reason, the sequence must reflect business events, factory calendars, and fiscal timing, not only theoretical optimization.
If the business has a high share of new products, frequent design changes, and confusion during the handoff from EBOM to production preparation, PLM standardization should usually come first.
In this case, the program should first stabilize design attributes, BOM structures, change management, and approval rules, then expand SAP item, procurement, and production integration. Phase F is complete when these projects are sequenced with clear dependency logic and transition conditions, even if SAP is not yet fully deployed.
If inventory valuation, cost visibility, and procurement control differ significantly by site, and management needs a common performance-control foundation first, then SAP FI/CO, MM, and inventory management should be prioritized.
PLM can then be positioned as the next investment for design sophistication, while the ERP layer establishes common master data and control rules. Even in this case, Phase F requires that future integration points, data standards, and organizational changes be reflected in the roadmap.
The most realistic approach is often not to choose one system completely before the other, but to combine them in waves. For example: wave 1 for engineering change control and item standardization, wave 2 for SAP finance and procurement control, and wave 3 for production, costing, and PLM integration enhancement.
This approach reduces risk by splitting investment into smaller steps while still creating early value. TOGAF® describes Phase F as the phase that supports staged migration using transition architectures, not just a single big-bang schedule.
| Decision axis | PLM first fits when | SAP first fits when | Phased rollout fits when |
| Main problem | Design change instability, BOM confusion, weak mass-production handoff | Weak accounting control, poor inventory visibility, weak cost tracking | Problems are mixed and cannot be solved at once |
| What to stabilize first | Product data, attributes, change management, EBOM foundation | Common master data, accounting control, purchasing and inventory rules | Milestones and dependencies by wave |
| Main risk | ERP control is delayed | Poor design data flows into ERP | The plan becomes half-finished if governance is weak |
| PM focus | Define PLM outputs as SAP-ready deliverables | Prevent future PLM integration from being blocked | Make each wave’s completion criteria explicit |
A PM should not only decide whether a project can start. The more important task is to define the conditions that allow the next step to begin.
For example, once standard PLM attributes are fixed, the program can move to SAP material design. Once common costing elements are defined, the project can proceed to CO deployment. Once the pilot plant has operated stably for three months, the rollout can move to overseas sites.
Without these conditions, the investment order becomes a wish list, and every priority discussion starts over again. The value of Phase F is not in listing projects, but in creating a shared basis for management, business, and IT to judge sequencing consistently.
There is no single correct sequence for SAP and PLM investment. However, TOGAF® ADM Phase F helps move the discussion away from intuition and toward a structured migration plan based on dependency, value, risk, and resource realism.
For Tier 1 automotive suppliers, where engineering, procurement, production, costing, and quality are tightly connected, SAP and PLM sequencing should be decided through enterprise design, not isolated optimization. Phase F is the stage that converts that enterprise design into an investment roadmap that executives can approve and the organization can execute.
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.
The Environments and Locations Diagram is a formal TOGAF Phase D artifact that answers which…
The most common failure in early Enterprise Architecture work is misreading the business strategy. This…
Manufacturing integration must balance the rapid harmonization of management reporting with the safe migration of…
A TOGAF-based framework for identifying, evaluating, and mitigating SAP implementation risks in Tier 1 automotive…
Learn how Enterprise Architects can apply TOGAF Initial Risk Assessment, mitigation, and Residual Risk Assessment…
Learn how Outputs, Deliverables, Artifacts, and Outcomes differ in Enterprise Architecture through a practical automotive…