SAP stakeholder management: stop conflicts before they start

SAP stakeholder management decides whether a programme finishes on time or spends its last quarter in argument. It comes down to four habits. Map who matters and what each group cares about. Write down who has authority to decide what. Run a communication cadence that matches the SAP Activate phase. Record every significant decision with its alternatives. This guide is for programme directors, PMOs and executive sponsors on S/4HANA programmes. Use the role table and the phase-by-phase cadence below to build your engagement plan before the first workshop.

I once worked on an SAP rollout where IT wanted tight system controls and Finance needed more flexibility. By the time we came in, the two teams had stopped talking. Finance was frustrated. IT was defensive. Leadership wanted to know why nobody was communicating.

We built a role map, ran regular alignment meetings and created a single source of truth for decisions. Had that groundwork been laid at the start, we would have saved months of arguing.

The pattern holds well beyond that programme. The technology rarely fails on its own. Programmes fail when decisions are not made and expectations were never set. They fail when communication depends on personal relationships instead of a cadence, and when conflicts that belonged at working level reach leadership weeks too late.

Not everyone on an SAP programme has the same concerns or the same influence. Treat them as one audience and you send irrelevant updates and miss the real risks.

Role	What they care about	How to engage them
Executive sponsor (CEO, COO, group CFO)	Return, business risk, programme credibility	Direct, regular, short
Steering committee (CIO, CFO, business unit heads)	Timeline, budget, scope	Structured steering reviews with decisions
Finance leadership (CFO, controllers)	Revenue recognition, reporting integrity, controls	Early design involvement; sign-off on FI/CO scope
Operations and business leads	Process continuity, training, usability	Design workshops; ownership of user acceptance testing (UAT)
IT leadership (CIO, head of architecture)	Architecture, security, integration, support	Technical design sign-off
Business process owners	Process accuracy, exceptions, edge cases	Lead design workshops; sign off configuration
End users	Learning curve, daily work, job changes	Training and change management
System integrator (SI)	Delivery scope, change requests, resourcing	Formal governance and scope documents
HR and change management	People impact, role changes, communication	A parallel workstream to delivery

The power-interest grid tells you where to spend effort. The CIO, CFO and sponsor sit high on both: they approve changes, delay go-live and allocate people, and if they disengage the programme loses its cover. Process owners, controllers and architects have high interest and less formal power, but their knowledge of how the business really works makes them essential in design. Board members and executives outside the programme need milestone briefings, not weekly updates. End users have little influence and the highest exposure: their buy-in at go-live decides whether the system works in practice.

Influence over the outcomeHighMediumLow

• Board, outside executives

• Sponsor, CFO, CIO

• Process owners
• Controllers, architects

• End users

LowMediumHighHow much the programme affects them

The most effective engagement happens before anyone has a complaint. Lock in three things at kick-off.

Decision rights

Who can approve a scope change? Who signs off UAT? Who can take a go-live delay to the steering committee? Write it down, get it signed and put it in the project charter. When a decision is contested mid-project, that document is what you point to.

Without it, contested decisions go to whoever shouts loudest or has the sponsor's ear. Neither is governance, and both breed resentment. My guide to writing an SAP project charter covers what the decision-rights section should contain.

Communication cadence

Decide at kick-off how often the programme communicates, through which channel and with what content. Steering every two weeks. Workstream leads weekly. End users at milestones, with training call-outs. If people only hear from the programme when something is wrong, they will assume it is always in trouble.

Scope baseline

Write down what is in scope and what is explicitly out. Exclusions matter as much as inclusions, because every undefined boundary is a future conflict. Take a finance lead who assumes expense management is in scope and finds out in Realize that it is not. That person will be difficult for the rest of the programme, not because they are difficult by nature, but because the programme broke an implicit promise.

Engagement needs change as the programme moves through the SAP Activate phases. What works in Explore does not work in Deploy. Use this as the backbone of your engagement plan:

Phase	Engagement focus	Cadence	Who leads
Discover and Prepare	Role map, governance structure, sponsor briefings, first alignment sessions with Finance, Operations and IT	Sponsor brief at start; steering set up	Programme director
Explore	Fit-to-standard workshops with business leads and process owners; fit-gap decisions reviewed before sign-off	Weekly working sessions; steering at phase close	Solution architect and process owners
Realize	UAT preparation; protecting business leads' time for testing; defect and data migration status	Steering fortnightly; workstream leads weekly	Programme manager
Deploy	Cutover readiness, go/no-go criteria agreed before cutover starts	Daily cutover stand-ups; executive go/no-go brief	Business operations lead with IT and SI in support
Run	Hypercare communication, issue channels, stabilisation reviews	Daily for two weeks, then weekly; reviews at 30, 60 and 90 days	Support lead and process owners

Two phases cause most trouble. In Explore, the wrong people in the room means decisions get reopened in Realize, after configuration has started. In Realize, UAT owners who are unavailable or unprepared are a common pattern. Fix it in the plan during Explore, not two weeks before testing starts.

The traditional model had three parties: the client, the SI and the sponsors. Under RISE with SAP, SAP joins as a delivery participant. It runs infrastructure and technical operations, and its customer success team tracks adoption and value. Three governance changes follow.

1. An extension review forum. Every gap needs a decision: configure it, extend it through released APIs (on-stack with ABAP Cloud or side-by-side on SAP BTP), or reject it. On S/4HANA Cloud Public Edition, core modification is not possible. On Private Edition it is, but each modification adds upgrade work. A small forum below steering, with one architect authorised to decide, stops every customisation debate landing at steering. Skip it and the technical debt surfaces at the first major upgrade.
2. A customer success cadence with SAP. SAP's team engages on adoption, BTP usage and roadmap. It runs in parallel with implementation governance and continues after go-live. Fold it into your governance rather than run it separately.
3. An escalation path into SAP. When something fails at platform level, the CIO needs to know who to call at SAP, not just at the partner. Confirm the contacts and service levels before you sign.

GROW with SAP programmes on Public Edition need the same three at a lighter weight: fewer extension decisions because there is less room to extend, a more standardised success cadence, and escalation that usually runs through the partner first. On-premise programmes keep the traditional model, with SAP as a vendor rather than a participant.

AI tools help with the paperwork of engagement, not the relationships.

Meeting summaries are the clearest win. Microsoft Copilot turns a recorded steering meeting into draft minutes that need a short review instead of a long write-up. The decisions it captures are usually right, because it works from the transcript rather than memory.

Decision logs come second. Confluence's AI features, now under Atlassian's Rovo brand, can turn meeting notes into structured decision-log entries once you have built a template.

Requirements drafting helps in Explore. SAP Cloud ALM can draft requirements from fit-to-standard workshop transcripts. It still needs a person to validate every line.

Sentiment analysis is mostly theatre on programmes of fewer than 100 people. The signal is weak, false positives are common, and being seen to monitor sentiment carries a real political cost. On very large programmes it may spot disengaging groups early. For most programmes, spend the AI budget elsewhere.

Resistance to SAP almost always has a rational basis. The person pushing back is usually protecting something: a workaround that covers a gap in the old system, a manual check that the standard process does not show, or worry about their team's capacity to absorb the change. Find that basis before you react. Address the underlying concern and the resistance usually goes without a confrontation.

"We need this customisation"

Usually this protects a process that works today and that the person does not trust standard SAP to handle. Walk through the standard process and ask exactly where it fails. Often the concern is an edge case that configuration can handle. Sometimes it is legitimate. You only find out by having the conversation, and under clean core the stakes are higher, because the answer decides whether you build and maintain an extension.

"We are not ready to go live"

Take this seriously. When a business lead says they are not ready, they usually have a reason: data quality, incomplete training, an untested process. Find the specific concern. If it is valid, it should delay go-live. If it is anxiety rather than evidence, answer it with focused preparation, not a new date.

The most common version: UAT exposed problems that have not been fixed. Pushing on moves the problem from UAT into production. A two-week delay usually costs far less than a hypercare period spent on issues that were known before go-live.

"Nobody told us about this change"

This is a communication failure. The person was on the distribution list but not in the design session, or the change sat in a document they never read. Do not argue about who communicated what. Apologise, walk them through the change, add them to future design reviews in their area and fix the gap in the engagement plan.

When a conflict outgrows working level, three things matter.

Keep it inside governance. A dispute between Finance and IT over system access belongs at steering, not resolved informally by whoever is more persistent. Informal resolution of structural conflicts creates resentment and reopened decisions.

Frame it in business terms. Finance and IT arguing about access control is politics. Finance and IT presenting the security risk against the operational cost is a business decision, and steering can make it. Translating one into the other is the programme manager's job, or the SI lead's, depending on the contract.

Record every significant decision. What was decided, by whom, when and what alternatives were considered. In six months someone will say "we never agreed to that". When steering asks why a configuration was chosen, or a newcomer questions a past decision, you need the record, not a reconstruction from memory. A shared decision log, updated weekly and reviewed at steering, costs almost nothing and saves a great deal.

If the programme manager's inbox is full of urgent escalations, the plan is not working. Healthy programmes run on structured decisions, not daily firefighting.

Healthy signals: steering meetings produce decisions rather than deferrals; business leads attend workshops and UAT without chasing; scope changes arrive through the change process; post-go-live issues come through defined channels; the decision log is current and referenced at steering.

Warning signals: people contact the programme manager outside the governance structure; business leads approve deliverables without reading them and contest them later; the sponsor disappears between steering sessions; people who skipped design challenge the change freeze; the same conflict appears at three steering meetings in a row.

When warning signals appear, do not push harder on the existing plan. Work out which element is failing (cadence, authority, communication or documentation) and fix that one. More emails and more meetings make it worse. For the steering committee itself, see my guide to creating an effective SAP steering committee, and for the people side of go-live, my notes on SAP change management.

What is stakeholder management in an SAP implementation?

It is the structured work of identifying who has influence over or interest in the programme, understanding their concerns, setting up communication and decision-making, and keeping them engaged from kick-off to hypercare.

SAP touches Finance, HR, Procurement, Operations and IT at once, and each has different priorities and influence. Managing them as one audience produces generic updates and misses the concerns that drive resistance. SAP Activate builds this into every phase: workshops in Explore, UAT ownership in Realize and readiness reviews in Deploy all depend on prepared business participants.

How do you build a role map for an SAP project?

Plot each person or group on two axes: influence over the outcome and how much the programme affects them. The sponsor, CFO and CIO are high on both and need direct, regular contact. Controllers, process owners and architects have high interest and need to be in design. Executives outside the programme need milestone briefings. End users need targeted communication about what changes for them, when training happens and where to get help.

Keep the map current. People change roles, influence shifts as the programme becomes visible, and new participants join as scope grows.

What should an SAP engagement plan include?

A role register (name, function, influence, interest, main concerns), a communication plan (channel, frequency and content per group), decision rights for scope changes, design decisions and go-live readiness, activities for each Activate phase, an escalation path for contested decisions and a way to raise concerns formally.

Update it at each phase gate. Document it well enough that the team can run it without the programme manager handling every interaction personally, because that does not scale past thirty named participants.

How do you manage resistance to SAP from business leads?

Find the source first. The common ones are worry that the new process will miss an important edge case, fear of lost productivity, and feeling left out of decisions. Process concerns belong in a design session. Productivity fears need realistic training and clear hypercare support. Exclusion is a communication failure to fix, not argue about.

Resistance with no rational basis is harder. The lever is usually the sponsor, who needs to make clear the programme has leadership commitment. Pushing through without addressing resistance is the worst option: the concerns reappear in UAT.

How do you handle conflicts between Finance and IT in an SAP programme?

Most come down to one of three tensions: access versus segregation of duties, reporting flexibility versus data governance, or integration pace versus security review.

Name the tension precisely. "Finance wants controllers to have read access to production orders for reporting, and IT believes that breaks segregation of duties" can be resolved; "Finance wants flexibility" cannot. Take it to steering with the options and their risks. Then record the decision and the alternatives, because these disputes return when people change. If steering cannot resolve it, it goes to the sponsor. That is governance working as designed.

How does RISE with SAP change stakeholder management?

SAP becomes a participant rather than just a vendor. You need an extension review forum to decide how each gap is handled under clean core, a place in your governance for SAP's customer success cadence, and a documented escalation path into SAP for platform issues that does not depend on the partner. Confirm the escalation contacts and service levels before signing.