Risicoanalyse voor SAP-projecten: de praktische versie

Een risicoanalyse voor een SAP-project beschrijft wat het programma kan laten ontsporen en geeft elk risico een score voor kans en impact. Elk risico krijgt één benoemde eigenaar en een respons die is afgesproken voordat het zich voordoet, en de lijst wordt elke week beoordeeld. De risico's die SAP-programma's laten zinken, zijn zelden verrassingen: datamigratie, integratie, beschikbaarheid van mensen, scope die wegdrijft en adoptie. Deze gids is voor programmamanagers en sponsors die een risicoregister willen dat beslissingen verandert, in plaats van een register dat in een map ligt. U krijgt een gescoorde matrix, een sjabloon voor het register, drie publieke mislukkingen als uitgewerkte voorbeelden en de risico's die RISE with SAP en clean core toevoegen. Begin met het koppelen van een benoemde eigenaar aan elk risico dat u al heeft.

De meeste SAP-risicoanalyses worden opgesteld vóór de eerste stuurgroep, één keer beoordeeld en nooit meer aangeraakt. Dat is geen risicomanagement. Dat is een document.

Ik heb risico's zien negeren omdat ze te ongemakkelijk waren om vroeg aan te kaarten. Die stilte kost bijna altijd later meer. Wat begint als een klein integratieprobleem in Materials Management, blokkeert plotseling Finance. Een rapport dat in de test prima leek, breekt na een systeemupdate. Ik heb dat meer dan eens zien gebeuren.

De risico's waren geen verrassingen. Ze waren gedocumenteerd. Niemand deed er iets mee.

Scope. Het project begint met standaardmodules. Dan voegt iemand “nog één rapportje” toe, daarna een dashboard, daarna een paar uitbreidingen. Het gevaar zit in scopewijzigingen die informeel worden ingebracht in workshops, e-mails en gesprekken op de gang, en waar de projectmanager pas van hoort als de configuratie al klaar is. Mijn gids over scope creep voorkomen behandelt de beheersmaatregelen.

Resources. De architect wordt weggehaald voor een productieprobleem. Een belangrijke ontwikkelaar vertrekt. Gebruikers uit de business missen testcycli omdat hun dagelijkse werk niet stopt. Leg beschikbaarheid schriftelijk vast. Mondelinge toezeggingen verdampen onder druk op de bezetting.

Techniek. Veldmappings die nooit zijn gevalideerd tegen de doelstructuur. Interfaces die unittests doorstaan en breken bij echt transactievolume. Maatwerkcode die er goed uitziet tot de productiebelasting komt. Die risico's zijn voorspelbaar als u weet waar u moet kijken.

Planning. Een late blueprint perst de testfase in, maar de go-live-datum blijft vast. UAT, opleiding en datavoorbereiding worden gehaast. Hetzelfde patroon zie ik bij bijna elk programma dat een fasegate mist en het vervolgplan niet verschuift.

Adoptie. Mensen wijzen af wat ze niet begrijpen. Zwakke of late opleiding leidt tot omwegen, omwegen verslechteren de data en het systeem krijgt de schuld van falend verandermanagement.

Deze gevallen zijn openbaar en goed gedocumenteerd. De patronen herhalen zich op elke schaal.

Lidl: ongeveer €500 miljoen over zeven jaar

Lidl startte zijn eLWIS-project op SAP for Retail in 2011, ging live in enkele kleinere landen en stopte ermee in 2018 tegen gemelde kosten van ongeveer €500 miljoen. Eén veelgemelde oorzaak: Lidl waardeerde voorraad tegen inkoopprijzen, terwijl het standaardretailmodel van SAP verkoopprijzen gebruikt. Lidl paste de software aan in plaats van de werkwijze te veranderen, en het bedrijf zei dat de oorspronkelijke doelen niet met redelijke inspanning haalbaar waren.

Les: een mismatch tussen uw datamodel en de standaard van SAP is een risico uit week één, geen ontdekking in jaar vijf.

HP: ongeveer $400 miljoen aan gemiste omzet

In 2004 migreerde HP een deel van zijn serveractiviteiten naar een geconsolideerd, op SAP gebaseerd order- en supplychainsysteem. Orders vielen tussen het legacy-frontend en SAP uit en vergden handwerk, en de achterstand verdubbelde. De CEO van HP zei dat de problemen de server- en storagegroep ongeveer $400 miljoen aan omzet en $275 miljoen aan bedrijfswinst kostten, met een achterstand van $120 miljoen als gevolg. De CIO van HP zei later dat het team drie weken verstoring had ingepland en een buffer van vier tot zes weken had moeten hebben.

Les: dimensioneer de buffer voor een slechte cutover, niet voor een gemiddelde, en bouw voorraad- of kanaalbuffers op voordat u overschakelt.

Nike: meer dan $100 miljoen aan gemiste verkoop

In 2000 ging Nike live met de demand-planningsoftware van i2, vóór zijn SAP ERP-programma. De software was sterk aangepast om met de legacy-systemen van Nike te werken, draaide traag en crashte onder het productvolume. Het systeem bestelde te veel van sommige schoenen en te weinig van andere. Nike liep meer dan $100 miljoen aan verkoop mis en de beurskoers daalde met ongeveer 20%. Later verplaatste Nike de planning voor de korte en middellange termijn naar SAP.

Les: ga er nooit van uit dat een integratie werkt voordat die op productievolume met echte data heeft gedraaid.

Een analyse op basis van aannames is erger dan geen, omdat ze schijnzekerheid geeft. Zes inputs tellen:

1. Scopedocumentatie: charter, goedgekeurde scope en getekende requirements. Bestaan ze niet, dan is het scoperisico al hoog.
2. Toezeggingen voor resources: schriftelijke toezeggingen van afdelingshoofden, een skillsmatrix voor kritieke rollen en een benoemde back-up voor elke sleutelpositie.
3. Budget en planning: een goedgekeurd budget met reserve en een planning die is getoetst aan vergelijkbare programma's. Zes maanden en minimale financiering voor een volledige uitrol is een risico dat u nu moet benoemen.
4. Toezeggingen van leveranciers: contracten met serviceniveaus en boetes. Bij RISE de verantwoordelijkheden van SAP en de escalatieroute.
5. Technisch landschap: compatibiliteit met legacy, complexiteit van de datamigratie, deploymentmodel en een clean-core-plan voor al het maatwerk.
6. Logboeken van eerdere projecten: risicoregisters, issuelogs en evaluaties van eerdere SAP- of ERP-programma's. De meeste risico's zijn niet nieuw.

Geef elk risico een score voor kans en impact van 1 tot 5 en vermenigvuldig ze. Het voorbeeld hieronder is een typisch startpunt voor een S/4HANA-programma; uw scores zullen anders zijn.

Risico	Kans (1-5)	Impact (1-5)	Score	Prioriteit
Mislukte datamigratie	4	5	20	Hoog
Vertragingen bij integratie	4	4	16	Hoog
Beperkte resources	4	4	16	Hoog
Budgetoverschrijding	3	5	15	Gemiddeld
Maatwerkcode in de kern blokkeert upgrades	3	5	15	Gemiddeld
Scope creep	4	3	12	Gemiddeld
Hiaten in testdekking	3	4	12	Gemiddeld
Performance bij piekbelasting	3	4	12	Gemiddeld
Compliancehiaten	2	5	10	Gemiddeld
Geen escalatieroute naar SAP (RISE)	2	5	10	Gemiddeld
Lage gebruikersadoptie	3	3	9	Gemiddeld
Blootstelling aan abonnements- of licentiekosten	2	4	8	Gemiddeld
KPI's niet bijgehouden	3	2	6	Laag

Scores van 16 en hoger vragen nu om een benoemde eigenaar en actie. Scores van 8 tot 15 vragen om monitoring met een vastgelegde escalatietrigger. Onder 8 houdt u het risico op het register zonder er prioriteitstijd aan te besteden. Scores zijn een startpunt, geen vonnis: een compliancehiaat met score 10 kan in een gereguleerde sector 25 worden.

Een score alleen verandert niets. Elk risico heeft deze velden nodig, ingevuld.

Veld	Wat u opschrijft	Voorbeeld
Risico	De gebeurtenis, in één zin	Stamgegevens van leveranciers zijn niet opgeschoond vóór mock load 2
Eigenaar	Eén benoemd persoon	Lead crediteurenadministratie
Score	Kans × impact	4 × 5 = 20
Trigger	Het meetbare punt waarop u ingrijpt	Percentage duplicaten boven 5% in de extractie van mock 1
Respons	Vermijden, beperken, overdragen of accepteren, met de actie	Beperken: twee crediteurenanalisten drie weken aan opschoning
Volgende review	Datum	Risicoreview van komende maandag
Status	Open, in actie, gesloten	In actie

Zet de kosten waar mogelijk in reële termen. “Hoog risico” is vaag. “Een week vertraging bij UAT kost een bedrag van zes cijfers aan teamtijd en kan de go-live drie weken opschuiven” trekt de aandacht.

Maatwerkcode is een eigen risicocategorie. In S/4HANA Cloud Public Edition is maatwerkcode in de kern niet mogelijk. Uitbreidingen lopen via SAP BTP, vrijgegeven API's of key-usertools. In private cloud en on-premise kunt u de kern nog aanpassen, en partners die dat gewend zijn, zullen dat doen. Die technische schuld komt boven bij de eerste grote upgrade. Houd bij voor hoeveel van de geïdentificeerde aanpassingen een afgesproken clean-core-aanpak bestaat, controleer de BTP-uitbreidingservaring van de partner en richt uiterlijk aan het einde van Explore een reviewforum in.

RISE verandert wie de beschikbaarheid in handen heeft. SAP beheert de infrastructuur, dus het risico verschuift van “ons team is verantwoordelijk voor beschikbaarheid” naar “SAP is daarvoor verantwoordelijk en wij hebben een snelle route nodig als er iets uitvalt”. Leg de benoemde contactpersonen bij SAP vast, de escalatieroute en de serviceniveaus, en een incidentplan dat vóór go-live is afgesproken. Zonder die dingen blijven problemen die naar SAP moeten, te lang bij het projectteam liggen.

AI helpt bij het papierwerk, niet bij het oordeel. Op Joule gebaseerde assistenten in SAP Cloud ALM en tools zoals Microsoft Copilot kunnen registerregels en stuurgroeppakketten opstellen op basis van statusrapporten, defectlogs en notulen. Dat versnelt het onderhoud van het register bij programma's met schone brondata. Het vindt risico's die al zichtbaar zijn in de data. Het beslist niet welke risico's actie verdienen, krijgt eigenaren niet in beweging en escaleert niet de risico's die het management liever negeert.

1. Identificeer risico's in alle vijf categorieën. Houd workshops met IT, de business en leveranciers; elk ziet andere risico's. Neem bij RISE de contactpersonen van SAP in minstens één workshop mee. De risico's die teams meestal missen: IT en business die iets anders verwachten, slecht gedefinieerde externe integraties, UAT-eigenaren die niet beschikbaar zijn en informele scopewijzigingen.
2. Geef elk risico een score voor kans en impact, waar mogelijk met echte cijfers.
3. Wijs per risico één eigenaar aan. Een persoon, geen team. Geen eigenaar, geen opvolging, geen oplossing.
4. Bepaal de respons voordat het risico toeslaat. Vermijden, beperken, overdragen of accepteren. “Monitoren en reageren” is geen plan. Het is een uitgestelde beslissing.
5. Beoordeel wekelijks. Loop de open risico's na, voeg nieuwe toe, bepaal de score opnieuw waar de omstandigheden zijn veranderd en escaleer alles wat dicht bij de trigger komt. Breng de belangrijkste risico's naar de stuurgroep met een voorgesteld besluit in plaats van een kleur.

1. 01IdentificerenAlle vijf categorieën
2. 02ScorenKans × impact, 1 tot 5
3. 03Eigenaar aanwijzenEén persoon, geen team
4. 04Respons bepalenVermijden, beperken, overdragen of accepteren
5. 05Wekelijks beoordelenOpnieuw scoren, escaleren bij triggers

16 of hoger: deze week een benoemde eigenaar en actie

Wat is een risicoanalyse in een SAP-project?

Het is het proces van vaststellen wat er mis kan gaan, elk risico een score geven voor kans en impact, er een eigenaar aan koppelen en een respons afspreken voordat het zich voordoet. SAP-programma's draaien tegelijk meerdere modules, integraties, een datamigratie, een veranderprogramma en een vaste go-live, dus informeel risicomanagement houdt geen stand. Een korte lijst met echte risico's en eigenaren wint het van een lang document dat niemand leest.

Hoe bouwt u een risicomatrix voor een SAP-project?

Som risico's op over scope, resources, techniek, planning en adoptie, plus clean core en escalatie naar SAP bij RISE. Geef elk een score voor kans en impact van 1 tot 5 en vermenigvuldig. Beschouw 16 en hoger als hoog, 8 tot 15 als gemiddeld en onder 8 als laag. Geef elk gemiddeld en hoog risico een eigenaar en een meetbare trigger, zoals “als de UAT-voortgang in week 16 onder 80% ligt, wordt de go-live-datum opnieuw bekeken”. Bepaal de scores wekelijks opnieuw en bij elke fasegate.

Wat zijn de meest voorkomende risico's bij SAP-implementaties?

Mislukte datamigratie, omdat legacy-data bijna altijd rommeliger is dan geschat. Vertragingen bij integratie, vooral met ongedocumenteerde legacy-interfaces en externe leveranciers. Scope creep die testen en opleiding samenperst. Resourcebeperkingen, zoals sleutelfiguren die worden weggehaald of gebruikers die tijdens UAT door de maandafsluiting niet beschikbaar zijn. Lage adoptie door opleiding die schermen laat zien in plaats van het werk te simuleren. Voeg bij RISE maatwerkcode in de kern en het ontbreken van een escalatieroute naar SAP toe.

Wanneer moet u een risicoanalyse uitvoeren tijdens een SAP-project?

Voordat het project start, wanneer structurele risico's zoals mismatches in het datamodel of onrealistische planningen het goedkoopst zijn op te lossen. Vóór elke fasegate van SAP Activate, omdat elke fase het risicoprofiel verandert. Telkens wanneer scope, budget of resources veranderen. En wanneer een risico een probleem wordt, om te zien wat het nog meer raakt. Beoordeel er daartussen wekelijks.

Wie moet risico's beheren in een SAP-programma?

De persoon die er iets aan kan doen. De datalead is eigenaar van het risico rond datamigratie, de technisch architect van het integratierisico, de veranderlead van het adoptierisico en de oplossingsarchitect van het clean-core-risico. Bij RISE is de CIO of programmadirecteur eigenaar van de escalatieroute naar SAP. De programmamanager bewaakt de gezondheid van het register, maar is niet eigenaar van elk risico.

Wat gebeurt er als de risicoanalyse bij ERP wordt overgeslagen?

Op grote schaal krijgt u gevallen als Lidl, dat zijn SAP-retailproject in 2018 opgaf na ongeveer €500 miljoen. Of HP, waarvan de migratie van het SAP-ordersysteem in 2004 de servergroep ongeveer $400 miljoen aan omzet kostte. Op kleinere schaal is het mechanisme hetzelfde: mismatches in het datamodel die laat worden gevonden, integraties die bij productievolume falen en mislukte adoptie door zwakke opleiding. De risico's waren te herkennen voordat ze problemen werden.