Enterprise Architecture

TOGAF® Agile × Product Management: Shifting Manufacturing from Projects to Continuous Value Creation

Applying TOGAF® Agile Product Management in Manufacturing: A Practical Approach to Continuous Business Value


1. Why the Shift from “Project” to “Product” Matters Now

Traditionally, system implementation in manufacturing has been approached as a project—something designed to be completed once and then considered finished.

However, TOGAF’s agile approach requires a fundamental shift in thinking. Instead of treating a system as a one-time delivery, it should be managed as a product that continuously evolves.

This is not merely a difference in development methodology. It is a change in the design philosophy of the management foundation itself—one that enables the enterprise to keep creating value over time.

In this article, we break down “5. Using Agile Product Management Techniques” from the TOGAF® guidance and explain it through concrete manufacturing examples. The goal is to translate the concept into a level that can be directly applied in practice.

oduct Management: Shifting Manufacturing from Projects to Continuous Value Creation


2. Moving to a Product-Centric Model: What Changes in Manufacturing?

In the traditional project-based approach, an SAP implementation, for example, typically proceeds as follows:

  • Define requirements
  • Design and build the system
  • Go live and close the project

In this model, post-go-live improvements are often treated as part of a separate future project. As a result, organizations struggle to respond quickly to changes in the business and on the shop floor.

By contrast, agile product management views something like a target costing platform as a single product.

Under this model:

  • Improvement continues after go-live
  • Functions are added according to business value
  • Priorities are adjusted based on feedback from the field

For example, in the target costing domain of an automotive parts manufacturer, the difference becomes clear:

  • Traditional approach: Implement a cost management system and stop there
  • Agile approach: Continuously enhance functionality to improve cost achievement rates

This shift is what transforms IT from a mere implementation exercise into a mechanism for delivering business outcomes.


3. Defining the Problem: Capturing the Real Issue Through Design Thinking

In agile, the process does not begin with trying to define perfect requirements from the outset. It begins by identifying the true nature of the problem.

Case: Cost deterioration caused by design changes

In many manufacturing companies, the following issues occur:

  • Design changes are made just before mass production or even after production has started
  • Costs increase
  • Inventory scrapping and rework occur

The important point here is not to define the surface-level problem, but the underlying problem.

Reframing the issue through design thinking

For example:

  • Surface-level problem: There are too many design changes
  • Underlying problem: The cost impact is not visible during the design phase

This reframing changes the direction of the solution.

Instead of aiming simply to reduce design changes, the focus becomes:

Build a mechanism that enables decision-making during the design stage.

Practical activities in the field

To identify the real issue, activities may include:

  • Interviewing designers to understand when and how decisions are made
  • Visualizing the customer journey from planning to design to mass production
  • Observing actual operations, including Excel-based and manual work
  • Formulating hypotheses, such as fragmented cost information across functions

These activities help reveal the real business challenge that architecture and product management need to address.


4. Designing the MVP: Delivering Value in the Smallest Possible Unit

Once the problem is clear, the next step is not to pursue full optimization from day one. Instead, the focus should be on defining an MVP (Minimum Viable Product)—the smallest scope that can still deliver meaningful value.

Manufacturing example: Target costing

For the theme of making costs visible during the design stage, implementation can proceed in stages such as:

Sprint 1

  • Visualize cost at the component level
    (for example, by using SAP PLC)

Sprint 2

  • Link BOM data with cost information
    (PLM → SAP integration)

Sprint 3

  • Simulate cost impact when design changes occur

Key points

What matters is:

  • Do not build everything at once
  • Do not aim for perfection at the start
  • Create a usable state as early as possible

TOGAF® also emphasizes the importance of just-enough architecture.


5. From Epics to User Stories: Shifting to a Business-Value Perspective

In agile, requirements are not translated directly into system specifications. They are first broken down into epics and user stories.

Epic

Enable cost control during the design stage

User stories

  • As a designer, I want to immediately understand the cost impact when I change a component
  • As a procurement professional, I want to check quoted cost in real time
  • As a manager, I want visibility into cost achievement status

Practical points

  • Describe work in terms of business actions, not IT functions
  • Clarify who wants to do what
  • Make prioritization easier

This is how development shifts from being system-centered to being driven by operational value.


6. Breaking Down the Work into Segments and Capabilities

Large-scale manufacturing systems cannot be developed in an agile way unless they are first broken down into manageable units.

TOGAF® addresses this by decomposing the landscape into segments and capabilities.

Segments (business domains)

  • Target costing
  • Design change management
  • Procurement
  • Production management

Capabilities

  • Cost simulation
  • BOM integration
  • Change impact analysis
  • Cost tracking

Why this matters in practice

This decomposition makes it possible to:

  • Develop in smaller increments
  • Assign priorities more effectively
  • Scale more easily across global operations

7. Product Backlog: Prioritizing by Business Value

A backlog is not simply a list of tasks. It is an ordered sequence of business value.

Priority criteria in manufacturing

Typical prioritization criteria include:

  • Impact on cost
  • Impact on mass production
  • Importance of customer requirements
  • Difficulty of implementation

Common failure patterns

  • IT decides priorities alone
  • Everything is pursued at the same time
  • The voice of the field is ignored

Success factors

  • The product owner makes the decisions
  • Priorities are linked to management indicators
  • The backlog is reviewed sprint by sprint

8. Governance and OKRs: Building a Mechanism to Measure Value

In agile, governance is not a separate process outside delivery. It is built into the sprint cycle itself.

Example OKR in manufacturing

Objective
Improve the accuracy of target costing

Key Results

  • Reduce cost variance by 20%
  • Shorten design change lead time by 30%
  • Improve quotation accuracy

Practical points

  • Measure change, not just static KPI values
  • Review continuously
  • Use metrics that connect management and the field

Conclusion

Agile product management is not simply a development methodology. In manufacturing, it is a mechanism for executing management itself.

By applying TOGAF’s way of thinking, organizations can make several fundamental shifts:

  • From project orientation to product orientation
  • From requirements definition to value creation
  • From one-time implementation to phased evolution

As a result, ERP evolves from being just an operational system into infrastructure that continuously generates business outcomes.

Please refer to this article for topics related to Enterprise Architecture (EA).
Enterprise Architecture – Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy


Reference Links


Disclaimer

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.


Back to Top

REI

Recent Posts

Why SAP Programs Need TOGAF® from a PM Perspective

A global SAP template will not remain sustainable by agile delivery alone. This article explains…

8 hours ago

How to Design the MRP4 View in SAP S/4HANA Private Edition for Manufacturing and MRP by Location

The MRP4 view in SAP S/4HANA Private Edition is the fine‑tuning dial for manufacturing logic…

1 day ago

The True Power of Enterprise Architecture in Driving Successful SAP Implementations

A deep dive into how Enterprise Architecture (EA) empowers SAP success through TOGAF’s four key…

3 days ago

A Must‑Read for Digital Transformation Practitioners: What Is DPBoK and How Does It Differ from TOGAF® Enterprise Architecture?

The Digital Practitioner Body of Knowledge (DPBoK) is a practical standard for planning, building, operating,…

4 days ago

TOGAF® Agile Architecture in Practice: Understanding Landscape and the Three-Layer Model (Strategy, Segment, Capability)

A practical guide to TOGAF Agile Architecture using the three-layer model. Learn how to connect…

5 days ago

Developing Architecture in an Agile Way with TOGAF®: Practical Application and Key Insights

A practical guide to applying TOGAF’s “Developing Architecture in an Agile Way.” Learn how enterprises…

6 days ago