A Practical TOGAF® Approach for Project Managers and Enterprise Architects
Large-scale SAP S/4HANA implementation and global rollout programs face a challenge that can be even more difficult than designing the system itself: understanding the different concerns of stakeholders and building alignment across the organization.
A CEO, CFO, CIO, Business Unit Head, and Plant Manager may all have very different expectations of an SAP transformation.
This is where the TOGAF® approach to Stakeholder Management becomes particularly useful.
This article explains how Project Managers and Enterprise Architects can apply a Stakeholder Concern Matrix to an SAP S/4HANA transformation using the following flow:
Stakeholder → Concern → Power / Interest → Requirement → Engagement → Viewpoint / View
1. Why Stakeholder Management Matters in an SAP Transformation
Suppose a global manufacturing company is planning a transformation from its legacy ERP environment to a global SAP S/4HANA platform.
The objective is not simply to replace an old ERP system.
The transformation may include objectives such as:
- Global business process standardization
- Simplification of the IT landscape
- Data standardization
- Improved management visibility
- Reduction of IT costs
- Advanced supply chain capabilities
However, not every stakeholder will place the same priority on these objectives.
The CFO may focus on financial transparency and TCO.
The CIO may focus on the application landscape and integration complexity.
A Plant Manager may be less interested in the architecture itself and much more concerned about whether the SAP implementation could disrupt production.
Therefore, simply creating a list of stakeholders is not enough.
We need to understand:
Who are the stakeholders, and what are their concerns?
2. What Is a Stakeholder Concern Matrix?
A Stakeholder Concern Matrix helps identify and analyze:
Who has an interest in the transformation, what their concerns are, how much power and interest they have regarding those concerns, and what they require from the architecture.
A useful structure is:
Stakeholder × Concern × Power × Interest × Requirement
The key element here is the Concern.
A stakeholder’s Power and Interest may vary depending on the specific concern being addressed.
For example, a CFO may have:
High Power / High Interest
when the concern is the Business Case or investment decision.
However, the same CFO may have:
Medium Power / Low Interest
when the concern is the detailed SAP Integration Architecture.
This means that stakeholders should not always be classified using one fixed Power/Interest rating. Their position should be considered in the context of a specific concern.
3. Example: Global SAP S/4HANA Transformation
For this example, we define two major concerns.
Concern 1: Business Standardization
Global standardization of business processes using a common Global Template.
Concern 2: IT Architecture Modernization
Modernization and simplification of the IT architecture by reducing legacy systems, interfaces, and unnecessary custom development.
We identify five key stakeholders:
- CEO
- CFO
- CIO
- Business Unit Head
- Plant Manager
4. Example Stakeholder Concern Matrix
| Stakeholder | Concern 1 | Power | Interest | Requirement |
| CEO | Business Standardization | High | High | Global operating model and faster decision-making |
| CFO | Business Standardization | High | High | Cost reduction and financial transparency |
| CIO | Business Standardization | High | High | Global process and system standardization |
| Business Unit Head | Business Standardization | High | High | Preserve necessary business differentiation |
| Plant Manager | Business Standardization | Low | High | Minimize disruption to plant operations |
The assessment may change when the concern is IT Architecture Modernization.
| Stakeholder | Concern 2 | Power | Interest | Requirement |
| CEO | IT Architecture Modernization | High | Low | IT must support business growth |
| CFO | IT Architecture Modernization | Medium | Low | Reduce IT TCO |
| CIO | IT Architecture Modernization | High | High | Simple and scalable architecture |
| Business Unit Head | IT Architecture Modernization | Medium | Medium | Architecture must support business requirements |
| Plant Manager | IT Architecture Modernization | Low | Medium | Stable and usable plant systems |
This illustrates an important principle:
A stakeholder’s Power and Interest can change depending on the concern.
5. Understanding Power, Interest, and Requirement
Power
Power represents the stakeholder’s ability to influence architecture or transformation decisions.
For example, if the CIO can approve the global ERP strategy and architecture principles, the CIO has High Power.
Interest
Interest represents how strongly the stakeholder is interested in or affected by a particular concern.
A Plant Manager may have relatively low interest in technical architecture but extremely high interest in production continuity.
Requirement
A Requirement represents a specific need or expectation that the stakeholder expects the architecture or transformation to address.
Instead of documenting a CFO requirement simply as:
IT Cost Reduction
it is more useful to define it as:
Reduce IT operating costs by 20% within three years.
This makes it easier to connect the stakeholder requirement to architecture requirements, KPIs, and transformation outcomes.
6. From Power and Interest to an Engagement Strategy
The purpose of stakeholder analysis is not to create a table.
The analysis should drive the Stakeholder Engagement Strategy.
| Power | Interest | Engagement Strategy |
| High | High | Manage Closely |
| High | Low | Keep Satisfied |
| Low | High | Keep Informed |
| Low | Low | Monitor |
For High Power / High Interest stakeholders, continuous engagement may be required around the Architecture Vision, Target Architecture, and Transformation Roadmap.
For High Power / Low Interest stakeholders, detailed technical architecture presentations may not be effective.
Communication should instead focus on Business Outcomes, Investment, Risk, and KPIs.
7. Connecting theStakeholder Concern Matrix to Architecture Views
For Enterprise Architects, one of the most important steps is connecting the Stakeholder Concern Matrix to Architecture Views and Viewpoints.
Consider the CFO.
Stakeholder
CFO
↓
Concern
Investment / Cost / Business Value
↓
Requirement
Reduce IT TCO by 20% within three years
↓
Viewpoint
Financial / Business / Transformation Roadmap Viewpoint
↓
View
5-Year TCO, Current vs. Target Cost, Business Benefits, ROI, Transformation Roadmap
For the CIO, the chain may look different:
Concern: IT Complexity
Requirement: Reduce legacy applications and point-to-point interfaces
View: Application Landscape, Integration Architecture, Transition Architecture
The architecture communication should therefore be adapted to the stakeholder’s concerns.
8. Different Perspectives for Project Managers and Enterprise Architects
The same Stakeholder Concern Matrix can be used differently by a Project Manager and an Enterprise Architect.
Project Manager
A Project Manager typically uses stakeholder analysis to support:
- Governance
- Decision-making
- Communication
- Escalation
- Change Management
- Project Risk Management
For example, High Power / High Interest stakeholders may need to participate in a Steering Committee and be engaged at key decision points.
Enterprise Architect
An Enterprise Architect typically focuses on:
- Architecture Concerns
- Architecture Requirements
- Architecture Principles
- Views and Viewpoints
- Target Architecture
- Transition Architecture
In simple terms, the Project Manager asks:
Who needs to be engaged, when, and how?
The Enterprise Architect asks:
How should the architecture address this stakeholder’s concerns?
Combining these two perspectives creates a much stronger approach to stakeholder management.
9. Applying the Stakeholder Concern Matrix to SAP Global Template Rollouts
The Stakeholder Concern Matrix is particularly valuable in SAP Global Template rollout programs.
Headquarters may prioritize:
Global Standardization
while local organizations and plants may prioritize:
Local Requirements and Business Continuity
Rather than treating this simply as a conflict between headquarters and local organizations, the Enterprise Architect can make the different concerns explicit.
For example:
Global Process Owner
Concern: Global Standardization
Local Business Head
Concern: Local Competitiveness
Plant Manager
Concern: Production Continuity
CIO
Concern: IT Complexity
This provides a better foundation for Fit-to-Standard, localization, exception management, and Architecture Governance discussions.
10. A Stakeholder Concern Matrix Is Not a One-Time Deliverable
An SAP transformation may continue for several years.
Stakeholder Power, Interest, and Concerns can change significantly as the program progresses.
For example:
Architecture Vision → Global Template Design → Build → Pilot → Rollout
As the program moves toward Pilot and Rollout, the Interest of Plant Managers and local business organizations may increase significantly.
The Stakeholder Concern Matrix should therefore be reviewed and updated at major phases and decision points rather than created once at the beginning of the program.
Conclusion
A Stakeholder Concern Matrix in an SAP implementation or rollout project is much more than a list of people involved in the program.
The key flow is:
Stakeholder → Concern → Power / Interest → Requirement → Engagement → Viewpoint / View
Project Managers can use this information to improve Governance, Communication, and Decision-Making.
Enterprise Architects can translate stakeholder concerns into Architecture Requirements and connect them to appropriate Viewpoints, Views, Target Architectures, and Transformation Roadmaps.
Large SAP transformations cannot succeed through technical architecture alone.
The critical capability is to understand who cares about what, and then ensure that both the architecture and the transformation approach respond to those concerns.
That is where TOGAF® Stakeholder Management becomes highly practical for real-world SAP implementation and global rollout programs.
Reference Links
TOGAF / Enterprise Architecture
- The Open Group – TOGAF Standard
Official information about the TOGAF Standard and the overall framework for Enterprise Architecture. - The Open Group – TOGAF Library
Official library for TOGAF publications and supporting guidance.
SAP Transformation / SAP Activate
- SAP Learning – Discovering SAP Activate
Official SAP learning content covering SAP Activate, SAP Best Practices, and the Fit-to-Standard approach. (SAP Learning) - SAP Learning – Explaining the Fit-to-Standard Detailed Process in SAP Activate
SAP learning content explaining the Fit-to-Standard process, key roles, and accountability framework. (SAP Learning) - SAP Help Portal – Explore: Define the Target Architecture
Particularly relevant to the blog because it connects global process templates, Fit-to-Standard workshops, target processes, target architecture, and transformation planning. (SAP Help Portal)
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