A business team reviews a TOGAF stakeholder matrix during an SAP S/4HANA rollout meeting.
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
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:
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?
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.
For this example, we define two major concerns.
Global standardization of business processes using a common Global Template.
Modernization and simplification of the IT architecture by reducing legacy systems, interfaces, and unnecessary custom development.
We identify five key stakeholders:
| 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.
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 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.
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.
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.
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.
The same Stakeholder Concern Matrix can be used differently by a Project Manager and an Enterprise Architect.
A Project Manager typically uses stakeholder analysis to support:
For example, High Power / High Interest stakeholders may need to participate in a Steering Committee and be engaged at key decision points.
An Enterprise Architect typically focuses on:
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.
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.
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.
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.
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.
Every TOGAF ADM phase, from Preliminary through Requirements Management, translated into an input/task/output/outcome checklist you…
BTEP (Business Transformation Enablement Program) provides important foundations for understanding TOGAF Business Transformation Readiness Assessment.…
Learn how TOGAF Architecture Principles can be applied to global SAP implementation and rollout programs.…
TOGAF's Architecture Partitioning is defined in the Preliminary Phase and revisited when triggered from Phase…
A practical breakdown of the official TOGAF-SABSA Integration white paper — covering SABSA's background, purpose,…
Struggling to decide which work package to tackle first in a global SAP S/4HANA rollout?…