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
- TOGAF® Standard 10
https://www.opengroup.org/togaf - TOGAF® Standard 10 Download
https://www.opengroup.org/library/c231 - TOGAF® Agile Architecture
https://www.opengroup.org/library/g186 - TOGAF® ADM Overview (Visual Paradigm)
https://www.visual-paradigm.com/guide/togaf/what-is-togaf-adm/ - TOGAF® Content Framework
https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html - TOGAF® Business Architecture (Phase B)
https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap09.html - TOGAF® Technology Architecture / Capability
https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap11.html - Agile Product Management
https://www.scaledagileframework.com/product-management/
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.
Leave a Reply