SAP-stakeholdermanagement: voorkom conflicten voordat ze ontstaan

SAP-stakeholdermanagement bepaalt of een programma op tijd eindigt of zijn laatste kwartaal in discussie doorbrengt. Het komt neer op vier gewoonten. Breng in kaart wie ertoe doet en waar elke groep om geeft. Leg vast wie waarover mag beslissen. Hanteer een communicatiecadans die past bij de SAP Activate-fase. Leg elke belangrijke beslissing vast met de alternatieven. Deze gids is voor programmadirecteuren, PMO's en executive sponsors van S/4HANA-programma's. Gebruik de rollentabel en de cadans per fase hieronder om uw betrokkenheidsplan op te stellen vóór de eerste workshop.

Ik werkte ooit aan een SAP-uitrol waar IT strakke systeembeheersing wilde en Finance meer flexibiliteit nodig had. Toen wij erbij kwamen, praatten de twee teams niet meer met elkaar. Finance was gefrustreerd. IT stelde zich defensief op. De directie wilde weten waarom niemand communiceerde.

We bouwden een rollenkaart, hielden regelmatig afstemmingsoverleggen en maakten één bron van waarheid voor beslissingen. Was die basis aan het begin gelegd, dan hadden we maanden aan discussie bespaard.

Het patroon geldt ver buiten dat programma. De technologie faalt zelden uit zichzelf. Programma's falen als beslissingen niet worden genomen en verwachtingen nooit zijn gesteld. Ze falen als communicatie afhangt van persoonlijke relaties in plaats van een cadans, en als conflicten die op werkniveau thuishoorden de directie wekenlang te laat bereiken.

Niet iedereen in een SAP-programma heeft dezelfde zorgen of dezelfde invloed. Behandel ze als één doelgroep en u stuurt irrelevante updates en mist de echte risico's.

Rol	Waar ze om geven	Hoe u ze betrekt
Executive sponsor (CEO, COO, group CFO)	Rendement, bedrijfsrisico, geloofwaardigheid van het programma	Direct, regelmatig, kort
Stuurgroep (CIO, CFO, hoofden van business units)	Planning, budget, scope	Gestructureerde stuurgroepreviews met besluiten
Financieel management (CFO, controllers)	Omzeterkenning, integriteit van de rapportage, controles	Vroege betrokkenheid bij het ontwerp; akkoord op de FI/CO-scope
Operations en businessleads	Continuïteit van processen, training, gebruiksvriendelijkheid	Ontwerpworkshops; eigenaarschap van de gebruikersacceptatietest (UAT)
IT-management (CIO, hoofd architectuur)	Architectuur, beveiliging, integratie, ondersteuning	Akkoord op het technisch ontwerp
Proceseigenaren	Nauwkeurigheid van processen, uitzonderingen, randgevallen	Leiden de ontwerpworkshops; keuren de configuratie goed
Eindgebruikers	Leercurve, dagelijks werk, veranderingen in functies	Training en verandermanagement
Systeemintegrator (SI)	Reikwijdte van de oplevering, wijzigingsverzoeken, bezetting	Formele governance en scopedocumenten
HR en verandermanagement	Impact op mensen, rolwijzigingen, communicatie	Een parallelle workstream naast de oplevering

De macht-belangmatrix vertelt u waar u uw inspanning moet besteden. De CIO, CFO en sponsor scoren hoog op beide: zij keuren wijzigingen goed, stellen de go-live uit en wijzen mensen toe, en als zij zich terugtrekken, verliest het programma zijn dekking. Proceseigenaren, controllers en architecten hebben veel belang en minder formele macht, maar hun kennis van hoe het bedrijf werkelijk werkt maakt hen onmisbaar in het ontwerp. Bestuursleden en leidinggevenden buiten het programma hebben mijlpaalbriefings nodig, geen wekelijkse updates. Eindgebruikers hebben weinig invloed en de grootste blootstelling: hun draagvlak bij de go-live bepaalt of het systeem in de praktijk werkt.

Invloed op de uitkomstHoogGemiddeldLaag

• Bestuur, leidinggevenden buiten het programma

• Sponsor, CFO, CIO

• Proceseigenaren
• Controllers, architecten

• Eindgebruikers

LaagGemiddeldHoogHoezeer het programma hen raakt

De effectiefste betrokkenheid vindt plaats voordat iemand een klacht heeft. Leg bij de kick-off drie dingen vast.

Beslissingsrechten

Wie kan een scopewijziging goedkeuren? Wie tekent af op de UAT? Wie kan een uitstel van de go-live naar de stuurgroep brengen? Schrijf het op, laat het ondertekenen en neem het op in het projectcharter. Als een beslissing halverwege het project wordt betwist, is dat document waar u naar verwijst.

Zonder dat gaan betwiste beslissingen naar wie het hardst roept of het oor van de sponsor heeft. Geen van beide is governance en beide kweken wrok. Mijn gids over het schrijven van een SAP-projectcharter behandelt wat het onderdeel over beslissingsrechten moet bevatten.

Communicatiecadans

Bepaal bij de kick-off hoe vaak het programma communiceert, via welk kanaal en met welke inhoud. Stuurgroep om de twee weken. Workstreamleiders wekelijks. Eindgebruikers bij mijlpalen, met trainingsaankondigingen. Als mensen alleen van het programma horen wanneer er iets misgaat, nemen ze aan dat het altijd in de problemen zit.

Scopebaseline

Schrijf op wat binnen de scope valt en wat uitdrukkelijk niet. Uitsluitingen zijn even belangrijk als insluitingen, want elke ongedefinieerde grens is een toekomstig conflict. Neem een financieel lead die ervan uitgaat dat onkostenbeheer binnen de scope valt en in Realize ontdekt dat dat niet zo is. Die persoon zal voor de rest van het programma lastig zijn, niet omdat die van nature lastig is, maar omdat het programma een impliciete belofte heeft gebroken.

De behoeften aan betrokkenheid veranderen naarmate het programma de SAP Activate-fasen doorloopt. Wat in Explore werkt, werkt niet in Deploy. Gebruik dit als ruggengraat van uw betrokkenheidsplan:

Fase	Focus van de betrokkenheid	Cadans	Wie leidt
Discover en Prepare	Rollenkaart, governancestructuur, sponsorbriefings, eerste afstemmingssessies met Finance, Operations en IT	Sponsorbriefing bij de start; stuurgroep opgezet	Programmadirecteur
Explore	Fit-to-standard-workshops met businessleads en proceseigenaren; fit-gap-beslissingen beoordeeld vóór het akkoord	Wekelijkse werksessies; stuurgroep bij afsluiting van de fase	Oplossingsarchitect en proceseigenaren
Realize	UAT-voorbereiding; de tijd van businessleads voor testen beschermen; status van defecten en datamigratie	Stuurgroep tweewekelijks; workstreamleiders wekelijks	Programmamanager
Deploy	Gereedheid voor cutover, go/no-go-criteria afgesproken voordat de cutover begint	Dagelijkse cutover-stand-ups; go/no-go-briefing voor het management	Business operations lead, met IT en de SI in een ondersteunende rol
Run	Hypercare-communicatie, meldkanalen, stabilisatiereviews	Dagelijks gedurende twee weken, daarna wekelijks; reviews na 30, 60 en 90 dagen	Supportlead en proceseigenaren

Twee fasen veroorzaken de meeste problemen. In Explore betekenen de verkeerde mensen in de zaal dat beslissingen in Realize weer worden opengebroken, nadat de configuratie is begonnen. In Realize komen UAT-eigenaren die niet beschikbaar of onvoorbereid zijn vaak voor. Los dat op in het plan tijdens Explore, niet twee weken voordat het testen begint.

Het traditionele model had drie partijen: de klant, de SI en de sponsors. Onder RISE with SAP komt SAP erbij als deelnemer aan de oplevering. SAP beheert de infrastructuur en de technische operaties, en het customer-successteam volgt adoptie en waarde. Drie veranderingen in de governance volgen daaruit.

1. Een forum voor extensiereview. Elke gap vraagt een beslissing: configureren, uitbreiden via vrijgegeven API's (on-stack met ABAP Cloud of side-by-side op SAP BTP), of afwijzen. Op S/4HANA Cloud Public Edition is kernmodificatie niet mogelijk. Op Private Edition wel, maar elke modificatie voegt upgradewerk toe. Een klein forum onder de stuurgroep, met één architect die mag beslissen, voorkomt dat elk debat over maatwerk bij de stuurgroep belandt. Slaat u het over, dan komt de technische schuld aan het licht bij de eerste grote upgrade.
2. Een customer-successcadans met SAP. Het team van SAP houdt zich bezig met adoptie, BTP-gebruik en roadmap. Het loopt parallel aan de governance van de implementatie en gaat door na de go-live. Neem het op in uw governance in plaats van het apart te laten lopen.
3. Een escalatieroute naar SAP. Als er op platformniveau iets faalt, moet de CIO weten wie hij bij SAP moet bellen, niet alleen bij de partner. Bevestig de contactpersonen en de servicelevels voordat u tekent.

GROW with SAP-programma's op Public Edition hebben dezelfde drie nodig in een lichtere vorm: minder extensiebeslissingen omdat er minder ruimte is om uit te breiden, een meer gestandaardiseerde successcadans en een escalatie die meestal eerst via de partner loopt. On-premise-programma's houden het traditionele model, met SAP als leverancier in plaats van als deelnemer.

AI-tools helpen bij het papierwerk van betrokkenheid, niet bij de relaties.

Vergadersamenvattingen zijn de duidelijkste winst. Microsoft Copilot zet een opgenomen stuurgroepvergadering om in een concept van de notulen waarvoor een korte review volstaat in plaats van een lang uitwerkingswerk. De beslissingen die het vastlegt, zijn meestal juist, omdat het uitgaat van het transcript in plaats van het geheugen.

Beslissingenlogboeken komen op de tweede plaats. De AI-functies van Confluence, nu onder het Rovo-merk van Atlassian, kunnen vergadernotities omzetten in gestructureerde items voor het beslissingenlogboek zodra u een sjabloon hebt gebouwd.

Het opstellen van requirements helpt in Explore. SAP Cloud ALM kan requirements opstellen uit transcripten van fit-to-standard-workshops. Er is nog steeds iemand nodig die elke regel valideert.

Sentimentanalyse is grotendeels theater bij programma's van minder dan 100 mensen. Het signaal is zwak, valse positieven komen vaak voor en gezien worden terwijl u het sentiment monitort heeft een reële politieke prijs. Bij zeer grote programma's kan het terugtrekkende groepen vroeg opsporen. Voor de meeste programma's kunt u het AI-budget beter elders besteden.

Weerstand tegen SAP heeft bijna altijd een rationele grondslag. De persoon die tegenstribbelt, beschermt meestal iets: een workaround die een gat in het oude systeem dicht, een handmatige controle die het standaardproces niet toont, of zorg over de capaciteit van het eigen team om de verandering te verwerken. Zoek die grondslag voordat u reageert. Pak de onderliggende zorg aan en de weerstand verdwijnt meestal zonder confrontatie.

“We hebben dit maatwerk nodig”

Meestal beschermt dit een proces dat vandaag werkt en waarvan de persoon niet vertrouwt dat standaard SAP het aankan. Loop het standaardproces door en vraag precies waar het faalt. Vaak is de zorg een randgeval dat configuratie aankan. Soms is die terecht. U komt er alleen achter door het gesprek te voeren, en onder clean core staat er meer op het spel, omdat het antwoord bepaalt of u een extensie bouwt en onderhoudt.

“We zijn niet klaar voor de go-live”

Neem dit serieus. Als een businesslead zegt niet klaar te zijn, heeft die meestal een reden: datakwaliteit, onvolledige training, een ongetest proces. Zoek de specifieke zorg. Als die terecht is, moet de go-live worden uitgesteld. Als het angst is in plaats van bewijs, beantwoord die dan met gerichte voorbereiding, niet met een nieuwe datum.

De meest voorkomende variant: de UAT bracht problemen aan het licht die niet zijn opgelost. Doorduwen verplaatst het probleem van de UAT naar productie. Een uitstel van twee weken kost meestal veel minder dan een hypercareperiode die opgaat aan problemen die al vóór de go-live bekend waren.

“Niemand heeft ons over deze wijziging verteld”

Dit is een communicatiefout. De persoon stond op de verzendlijst maar zat niet in de ontwerpsessie, of de wijziging stond in een document dat die nooit las. Maak geen ruzie over wie wat heeft gecommuniceerd. Bied uw excuses aan, loop de wijziging met die persoon door, voeg die toe aan toekomstige ontwerpreviews op diens gebied en herstel het gat in het betrokkenheidsplan.

Als een conflict het werkniveau ontgroeit, gaat het om drie dingen.

Houd het binnen de governance. Een geschil tussen Finance en IT over systeemtoegang hoort bij de stuurgroep en wordt niet informeel beslecht door wie het vasthoudendst is. Informele afhandeling van structurele conflicten zorgt voor wrok en heropende beslissingen.

Formuleer het in zakelijke termen. Finance en IT die ruziën over toegangsbeheer is politiek. Finance en IT die het beveiligingsrisico afzetten tegen de operationele kosten is een zakelijke beslissing, en de stuurgroep kan die nemen. Het ene vertalen naar het andere is de taak van de programmamanager, of van de SI-lead, afhankelijk van het contract.

Leg elke belangrijke beslissing vast. Wat is besloten, door wie, wanneer en welke alternatieven zijn overwogen. Over zes maanden zegt iemand “daar hebben we nooit mee ingestemd”. Als de stuurgroep vraagt waarom een configuratie is gekozen, of een nieuwkomer een eerdere beslissing in twijfel trekt, hebt u het dossier nodig, niet een reconstructie uit het geheugen. Een gedeeld beslislogboek, wekelijks bijgewerkt en bij de stuurgroep besproken, kost bijna niets en bespaart veel.

Als de inbox van de programmamanager vol staat met dringende escalaties, werkt het plan niet. Gezonde programma's draaien op gestructureerde beslissingen, niet op dagelijks brandjes blussen.

Gezonde signalen: stuurgroepvergaderingen leveren besluiten op in plaats van uitstel; businessleads nemen aan workshops en UAT deel zonder dat ze achterna moeten worden gezeten; scopewijzigingen komen binnen via het wijzigingsproces; problemen na de go-live komen binnen via vastgelegde kanalen; het beslislogboek is actueel en wordt bij de stuurgroep aangehaald.

Waarschuwingssignalen: mensen benaderen de programmamanager buiten de governancestructuur om; businessleads keuren opleveringen goed zonder ze te lezen en betwisten ze later; de sponsor verdwijnt tussen stuurgroepsessies; mensen die het ontwerp hebben overgeslagen, betwisten de wijzigingsstop; hetzelfde conflict verschijnt op drie stuurgroepvergaderingen achter elkaar.

Als er waarschuwingssignalen verschijnen, moet u niet harder duwen op het bestaande plan. Bepaal welk element faalt (cadans, bevoegdheid, communicatie of documentatie) en herstel dat ene. Meer e-mails en meer vergaderingen maken het erger. Voor de stuurgroep zelf, zie mijn gids over het opzetten van een effectieve SAP-stuurgroep, en voor de menselijke kant van de go-live mijn notities over SAP-verandermanagement.

Wat is stakeholdermanagement bij een SAP-implementatie?

Het is het gestructureerde werk om te bepalen wie invloed heeft op of belang heeft bij het programma, hun zorgen te begrijpen, communicatie en besluitvorming op te zetten en hen betrokken te houden van de kick-off tot de hypercare.

SAP raakt Finance, HR, Inkoop, Operations en IT tegelijk, en elk heeft andere prioriteiten en invloed. Ze als één doelgroep beheren levert generieke updates op en mist de zorgen die weerstand voeden. SAP Activate bouwt dit in elke fase in: workshops in Explore, UAT-eigenaarschap in Realize en gereedheidsreviews in Deploy zijn allemaal afhankelijk van voorbereide businessdeelnemers.

Hoe bouwt u een rollenkaart voor een SAP-project?

Plaats elke persoon of groep op twee assen: invloed op de uitkomst en hoezeer het programma hen raakt. De sponsor, CFO en CIO scoren op beide hoog en hebben direct, regelmatig contact nodig. Controllers, proceseigenaren en architecten hebben veel belang en moeten bij het ontwerp zijn betrokken. Leidinggevenden buiten het programma hebben mijlpaalbriefings nodig. Eindgebruikers hebben gerichte communicatie nodig over wat er voor hen verandert, wanneer de training plaatsvindt en waar ze hulp kunnen krijgen.

Houd de kaart actueel. Mensen wisselen van rol, invloed verschuift naarmate het programma zichtbaar wordt en nieuwe deelnemers komen erbij naarmate de scope groeit.

Wat moet een SAP-betrokkenheidsplan bevatten?

Een rollenregister (naam, functie, invloed, belang, belangrijkste zorgen), een communicatieplan (kanaal, frequentie en inhoud per groep), beslissingsrechten voor scopewijzigingen, ontwerpbeslissingen en gereedheid voor de go-live, activiteiten voor elke Activate-fase, een escalatieroute voor betwiste beslissingen en een manier om zorgen formeel aan te kaarten.

Werk het bij elke fase-overgang bij. Documenteer het zo goed dat het team het kan uitvoeren zonder dat de programmamanager elke interactie persoonlijk afhandelt, want dat schaalt niet voorbij dertig benoemde deelnemers.

Hoe gaat u om met weerstand van businessleads tegen SAP?

Zoek eerst de bron. De gebruikelijke zijn zorg dat het nieuwe proces een belangrijk randgeval mist, angst voor productiviteitsverlies en het gevoel buiten beslissingen te worden gehouden. Procesbezwaren horen in een ontwerpsessie. Productiviteitsangst vraagt om realistische training en duidelijke hypercare-ondersteuning. Uitsluiting is een communicatiefout die u moet herstellen, niet over moet twisten.

Weerstand zonder rationele basis is moeilijker. De hefboom is meestal de sponsor, die duidelijk moet maken dat het programma de steun van de directie heeft. Doordrukken zonder de weerstand aan te pakken is de slechtste optie: de zorgen komen terug in de UAT.

Hoe gaat u om met conflicten tussen Finance en IT in een SAP-programma?

De meeste komen neer op een van drie spanningen: toegang versus functiescheiding, rapportageflexibiliteit versus datagovernance, of integratietempo versus beveiligingsreview.

Benoem de spanning precies. “Finance wil dat controllers leestoegang hebben tot productieorders voor rapportage, en IT vindt dat dit de functiescheiding doorbreekt” is op te lossen; “Finance wil flexibiliteit” niet. Breng het met de opties en hun risico's naar de stuurgroep. Leg daarna de beslissing en de alternatieven vast, want deze geschillen keren terug als mensen wisselen. Als de stuurgroep het niet kan oplossen, gaat het naar de sponsor. Dat is governance die werkt zoals bedoeld.

Hoe verandert RISE with SAP het stakeholdermanagement?

SAP wordt een deelnemer in plaats van alleen een leverancier. U hebt een forum voor extensiereview nodig om te beslissen hoe elke gap onder clean core wordt aangepakt, een plek in uw governance voor de customer-successcadans van SAP en een gedocumenteerde escalatieroute naar SAP voor platformproblemen die niet van de partner afhangt. Bevestig de escalatiecontacten en servicelevels voordat u tekent.