Zeven consultancyframeworks voor SAP- en AI-programma's

Als een SAP- of AI-programma vastloopt, is de oorzaak meestal structureel, en zeven eenvoudige frameworks sporen die op. Breng de huidige situatie in kaart. Spreek met een RACI af wie waarover beslist. Koppel het werk aan business capabilities. Vind grondoorzaken met vijf keer waarom. Rangschik requirements met MoSCoW. Rangschik risico's op wat het programma echt kan stoppen. Houd na elke fase een echte post-mortem. Deze gids is bedoeld voor programmamanagers, consultants en sponsors bij SAP- en AI-programma's. Begin bij de tabel hieronder: zoek uw symptoom op en gebruik eerst het bijpassende framework.

Een middelgroot mediabedrijf in Qatar voerde SAP in over meerdere regio's. Financiën en inkoop gingen in fase één live. Het wilde ook AI-voorspelmodellen in zijn rapportage.

In week zes kroop er vertraging in. Gebruikers uit de business zeiden dat ze requirements hadden afgetekend, maar nog steeds niet wisten wat ze zouden krijgen. Er waren AI-use cases voorgesteld en niemand kon zeggen wie eigenaar van de data was of hoe de uitkomst zou worden gebruikt. Mensen kwamen te laat op vergaderingen, of helemaal niet.

Het was die tussenfase. Te vroeg om het een mislukking te noemen. Te laat om te doen alsof het vanzelf goed zou komen.

We pasten de frameworks stap voor stap toe. Niet alles werd in het begin met open armen ontvangen. Sommige sessies waren stil. Andere dwaalden af. Maar de structuur maakte het werk makkelijker: het team hield op met rondjes draaien, de backlog werd beheersbaar en de AI-use cases kregen echte eigenaren. Het project ging acht weken later live dan gepland. Niet perfect. Maar het kwam er, en fase twee begon op steviger grond, met minder onbekenden.

Ik heb varianten van alle zeven gebruikt in 23 jaar uitvoering van SAP-, Oracle- en AI-programma's in de Golfregio, Europa en daarbuiten. Geen enkele is exotisch. Ze werken allemaal als u ze met discipline toepast en niet als documentatieoefening.

Koppel het symptoom aan het framework:

Symptoom dat u ziet	Framework	Wat het oplevert	Typische inspanning
Gebruikers hebben requirements afgetekend maar zijn nog steeds in verwarring	1. Huidige situatie in kaart brengen	Een gedeelde kaart van hoe het werk vandaag echt verloopt	3 tot 5 dagen workshops
Besluiten blijven heen en weer stuiteren tussen vergaderingen	2. RACI voor kritieke besluiten	Benoemde besluiteigenaren voor de 20 tot 30 sleutelbeslissingen	Eén workshop, daarna handhaving
Sponsors hebben zich losgekoppeld van “het IT-project”	3. Capability mapping	Voortgang gerapporteerd als business capabilities	Ingebouwd in fit-to-standard
Hetzelfde type defect blijft terugkomen	4. Vijf keer waarom	Een grondoorzaak die u kunt veranderen	Eén begeleide sessie per probleem
Alles is als hoge prioriteit aangemerkt	5. MoSCoW	Een gerangschikte scope met een realistische lijst Must haves	Eén gezamenlijke sessie van business en IT
Het risicolog ziet er goed uit, maar het team voelt spanning	6. Risico's rangschikken	Aparte lijsten met risico's die het programma kunnen stoppen en risico's die alleen hinderlijk zijn	Wekelijkse review van 30 minuten
Dezelfde fouten herhalen zich fase na fase	7. Post-mortem	Drie tot vijf wijzigingen met eigenaren	Een halve dag na elke fase

De meest gemaakte fout aan het begin van een programma is meteen naar de oplossing springen voordat u vastlegt wat er bestaat. Procesdocumentatie is meestal verouderd. Mensen beschrijven hoe dingen zouden moeten werken, niet hoe ze werken. In het gat tussen die twee zitten de implementatieproblemen.

Een bruikbare kaart van de huidige situatie vraagt drie tot vijf dagen workshops met de mensen die het werk doen, niet met de mensen die hen aansturen. Ze omvat de processtappen op volgorde, de systemen die bij elke stap worden gebruikt, handmatige ingrepen en workarounds, en dataflows tussen afdelingen.

Zoek naar de handmatige stappen die niemand noemt omdat ze onzichtbaar zijn geworden, de workarounds die zo lang meegaan dat ze inmiddels als standaardproces gelden, en de datakwaliteitsproblemen die iedereen kent en niemand heeft opgelost.

In Qatar kwam de kaart van de huidige situatie voort uit workshops met gebruikers, niet uit documentatie. Daar begon de verwarring over de afgetekende requirements af te nemen.

Goed uitgevoerd kost zo'n kaart dagen. Als documentverzamelingsoefening kost ze maanden en levert ze iets op dat niemand vertrouwt.

Besluitrechten zijn het structurele element dat het vaakst ontbreekt in SAP- en AI-projecten. Iedereen heeft een mening. Niemand weet wie het laatste woord heeft. Besluiten gaan naar de volgende vergadering, die ze doorschuift naar de stuurgroep, die ze terugstuurt naar de werkgroep.

Een RACI-matrix (Responsible, Accountable, Consulted, Informed) geeft elk besluit en elk opleverproduct een eigenaar. Eén persoon is Accountable en kan ook Responsible zijn of dat delegeren. Geconsulteerden geven input. Geïnformeerden horen de uitkomst.

De praktische versie: maak een lijst van de twintig tot dertig meest kritieke besluiten in de huidige fase en houd een RACI-workshop waarbij de besluitvormers aanwezig zijn. Als een toewijzing wordt betwist, hebt u iets geleerd: óf de governance is onduidelijk, óf er speelt een politieke strijd om gezag. Breng het in beide gevallen in week twee boven tafel, niet in week veertien.

RACI zonder handhaving is decoratie. De namen moeten overeenkomen met de mensen met echt gezag. Eindverantwoordelijkheid toewijzen aan een functietitel in plaats van aan een persoon met naam is een manier om het gesprek over wie het risico draagt uit de weg te gaan.

SAP- en AI-programma's leveren veel technische activiteit op die de business niet kan zien. Het verband tussen wat er wordt gebouwd en het resultaat dat het moet opleveren wordt abstract. Sponsors haken af en “het IT-project” krijgt de schuld van vertragingen die in feite besluiten van de business zijn.

Capability mapping verbindt systeemfunctionaliteit met business capability: wat de organisatie moet kunnen. In plaats van te volgen of de workflow voor inkooporders is geconfigureerd, volgt u of de organisatie leveranciersfacturen binnen drie dagen na ontvangst kan verwerken. Configuratie is het middel. De capability is de uitkomst.

In SAP Activate sluit dit aan op de fit-to-standard-workshops in Explore. Elk proces binnen de scope is een capability en elk gat tussen de SAP-standaard en de vereiste capability is een besluit: de standaard accepteren, een variant configureren of uitbreiden. Door het gesprek op capability-niveau te houden, blijft de aandacht van de business tijdens de bouw vast, en het brengt capabilities aan het licht waarvan iedereen aannam dat ze binnen de scope vielen maar die niemand had bevestigd.

Als hetzelfde soort probleem in sprint na sprint of fase na fase opduikt, helpt het niet om elk geval apart te patchen. De oorzaak zit stroomopwaarts.

Vijf keer waarom is het eenvoudigste instrument voor grondoorzaakanalyse. Vraag waarom het probleem is ontstaan, dan waarom dát is gebeurd, tot u iets bereikt wat u kunt veranderen. Vijf rondes komen meestal bij de echte oorzaak uit. Twee rondes blijven meestal steken bij het symptoom.

Een voorbeeld uit datamigratie. De proefmigratie bevat datakwaliteitsfouten: dat is het symptoom. Waarom? De bronextractie had verkeerde veldmappings. Waarom? De mappingspecificatie is nooit beoordeeld door de data-eigenaar van de business. Waarom? De data-eigenaar is pas aangewezen nadat de mapping klaar was. Waarom? Het plan maakte de betrokkenheid van de data-eigenaar niet tot een afhankelijkheid voor de mapping. Dat is de grondoorzaak, en de oplossing is een governancebesluit, geen datacorrectie. In mijn artikel over waarom SAP-datamigratie mislukt ziet u hoe vaak precies deze keten voorkomt.

1. 01Fouten bij proefmigratieHet symptoom
2. 02Verkeerde veldmappingsWaarom mislukte de migratie?
3. 03Spec nooit beoordeeldWaarom waren de mappings fout?
4. 04Eigenaar te laat benoemdWaarom is de spec niet beoordeeld?
5. 05Plan miste de afhankelijkheidWaarom kwam de eigenaar te laat?

De grondoorzaak is een governancebesluit, geen datacorrectie

Grondoorzaakanalyse in een ruimte zonder schuldvraag levert eerlijke antwoorden op. In een ruimte waar schuld wordt toegewezen levert ze defensief gedrag op. De taak van de facilitator is het gesprek bij het proces te houden, niet bij personen. In mijn gids over gestructureerd denken en probleemoplossing leest u hoe u een rommelig probleem ontleedt voordat u begint met waarom vragen.

Elke scopediscussie bij SAP en AI kent een consensusval. Niemand wil afwegingen maken, dus alles wordt hoge prioriteit. Als alles hoge prioriteit heeft, heeft niets die, en probeert het bouwteam alles te doen.

MoSCoW (Must have, Should have, Could have, Won't have this time) dwingt tot keuzes. Must have is het minimum dat nodig is voor de go-live. Should have is belangrijk maar geen blokkade. Could have is wenselijk als tijd en budget het toelaten. Won't have wordt uitdrukkelijk uitgesteld.

De discipline zit in de grens voor Must have. In de eerste ronde van een MoSCoW-oefening belandt meestal veel te veel in Must have. De DSDM-richtlijnen van het Agile Business Consortium, waar MoSCoW vandaan komt, stellen een plafond van 60% van de inspanning voor Must haves en waarschuwen dat een hoger percentage de oplevering in gevaar brengt. Het verschil tussen de eerste ronde en een realistische lijst bestaat vooral uit niet-geteste aannames.

Doe MoSCoW met business en techniek in dezelfde ruimte. Afzonderlijk blijken de Must have-lijst van IT en die van de business onverenigbaar, en niemand brengt ze op één lijn voordat de configuratie al is begonnen.

De meeste risicoregisters zijn lange lijsten, gescoord op kans en impact, maandelijks beoordeeld, met RAG-statussen die zelden veranderen. Ze leggen risico vast zonder tot actie te leiden.

Scheid risico's die het programma kunnen stoppen van risico's die het alleen moeilijker maken. De eerste groep heeft eigenaren, responsplannen en wekelijkse zichtbaarheid nodig. De tweede groep heeft monitoring nodig.

In Qatar zag het risicolog er op papier goed uit, maar iedereen voelde spanning. Een snelle risico-impactmatrix, wekelijks in plaats van maandelijks beoordeeld, bracht de echte zorgen naar boven.

Een register dat er goed uitziet terwijl het team spanning voelt, verbergt bijna altijd iets. Het register is niet de waarheid; de gesprekken eromheen zijn dat wel. Een wekelijkse review die vraagt “wat hield u gisteravond uit uw slaap?” levert meer op dan “wat is de status van punt 14?”. Mijn risicobeoordelingsmatrix voor SAP geeft een sjabloon voor de scoring en het eigenaarschap.

Post-mortems na een fase of go-live voorkomen dat dezelfde fouten in de volgende fase terugkeren. Ze zijn ook het eerste wat sneuvelt als de planning onder druk staat.

Een nuttige post-mortem stelt vier vragen. Wat wilden we bereiken en wat hebben we bereikt? Wat ging goed en moet worden herhaald? Wat ging slecht en wat was de oorzaak? Wat zouden we anders doen? Ze moet eindigen met drie tot vijf concrete acties met eigenaren, niet met een document dat samenvat wat er is gebeurd.

De veelvoorkomende valkuil is een rechtvaardigingsoefening waarin teams besluiten verdedigen in plaats van ze te onderzoeken. Blijf vooruitkijken. De vraag is niet wie de vertragingen in week zes veroorzaakte. De vraag is welke structurele verandering ze in de volgende fase voorkomt.

In Qatar vond de post-mortem direct na de go-live plaats en draaide die om actie, niet om schuld. Dat is een groot deel van de reden waarom fase twee op steviger grond begon.

De frameworks zijn niet veranderd. Hoe ze worden toegepast wel, op drie punten.

Het opstellen van concepten gaat sneller; het luisteren niet. AI-tools zetten workshoptranscripten en procesdocumenten nu binnen enkele minuten om in een eerste versie van de kaart, en SAP Cloud ALM kan requirements opstellen op basis van transcripten van fit-to-standard-sessies. De workshops zelf duren net zo lang als altijd, want het luisteren is het punt. De tijd die u bij het opstellen wint, moet naar het bevragen van de kaart met mensen.

RACI-concepten zijn direct klaar, en het moeilijke deel blijft. Een algemene AI-assistent maakt in een minuut een RACI op basis van een charter en een lijst met werkpakketten. De discipline verschuift naar onderhandelen: elke cel vraagt om een echt gesprek over gezag en escalatie. De tijd die u bespaart bij het opstellen van het concept, moet naar die lastige gesprekken.

MoSCoW wordt moeilijker met AI in de ruimte. Een rangschikking van requirements door AI is aannemelijk, gepolijst en vaak fout over lokale politiek. Consultants die haar zonder tegenspraak overnemen, maken slechtere prioriteitenlijsten dan consultants die met een blanco blad beginnen. Behandel het AI-concept als startpunt, nooit als antwoord.

Het oordeelsvermogen bovenop deze frameworks is nu meer waard, niet minder. Bouwt u deze vaardigheden op als consultant, dan laten de loopbaanpaden van SAPopedia zien welke vaardigheden in elke fase van een SAP-loopbaan het meest tellen.

Wat zijn consultancyframeworks en waarom gebruiken SAP-projecten ze?

Het zijn gestructureerde werkwijzen voor analyse, besluitvorming en probleemoplossing. Bij SAP- en AI-programma's geven ze business leads, architecten, projectmanagers, integratoren en sponsors een gedeelde methode.

Zonder methode valt elke groep terug op haar eigen denkmodel: procesresultaten, architectuur, of planning en resources. Frameworks zoals het in kaart brengen van de huidige situatie, RACI en MoSCoW maken meningsverschillen expliciet en oplosbaar. SAP Activate is zelf een framework voor fasen, gates en op te leveren producten; deze zeven werken daarbinnen en pakken de structurele en menselijke kwesties aan die methodologie alleen niet oplost.

Hoe werkt het in kaart brengen van de huidige situatie bij een SAP-implementatie?

Het legt vast hoe processen echt werken voordat de configuratie begint, in plaats van hoe bestaande documentatie zegt dat ze zouden moeten werken. Bouw het op in workshops met de mensen die de processen uitvoeren: stappen, systemen, overdrachten, handmatige ingrepen en workarounds.

Het voedt de fit-to-standard-workshops in de Explore-fase van SAP Activate, waar de huidige situatie de basislijn wordt die wordt vergeleken met de standaardprocessen van SAP. Rond het af voordat die workshops beginnen, anders berust uw gap-analyse op aannames.

Wat is MoSCoW-prioritering en wanneer wordt die gebruikt in SAP-programma's?

MoSCoW sorteert requirements in Must have, Should have, Could have en Won't have this time. Must haves zijn het minimum voor de go-live; Won't haves worden uitdrukkelijk uitgesloten, zodat ze niet ongemerkt terugsluipen.

Het is het nuttigst in Explore, wanneer fit-gap-bevindingen besluiten over uitbreidingen sturen, en in Realize, wanneer defects en enhancements om bouwtijd concurreren. Het gebruikelijke probleem is te veel Must haves in de eerste ronde. DSDM adviseert niet meer dan 60% van de inspanning aan Must haves te besteden; een facilitator die elke Must have ter discussie stelt, met business en IT in dezelfde sessie, brengt u daar.

Hoe houdt u een effectieve risicoreview bij een SAP-project?

Als een gesprek, niet als statusupdate. Begin met open vragen zoals “Wat is uw grootste zorg deze week die niet in het register staat?” voordat u het register doorloopt.

Vraag bij elk risico met hoge prioriteit wat er is veranderd, welke actie is ondernomen, of de trend verbetert en of het responsplan nog past. Risico's die wekenlang zonder actie op dezelfde score staan, worden vaak onderschat. Beoordeel wekelijks in actieve fasen en toon de stuurgroep de top vijf met status en volgende actie, niet het volledige register.

Wat maakt een post-mortem na een SAP-go-live nuttig?

Concrete, uitvoerbare wijzigingen voor de volgende fase. Een samenvatting van wat er is gebeurd is een verslag, geen post-mortem.

Behandel wat u wilde bereiken, wat u bereikte, wat werkte en wat niet. Graaf door onder oppervlakkige verklaringen zoals “we hadden te weinig capaciteit”: klopte het resourceplan niet, klopte de scope niet, of was het escalatiepad stuk? Sluit af met drie tot vijf wijzigingen, elk met een eigenaar en een datum.

Hoe helpen consultancyframeworks bij AI-implementatie in SAP-omgevingen?

AI-projecten mislukken om dezelfde structurele redenen als SAP-projecten, plus een paar eigen: data zonder eigenaar, ongedefinieerde succesmaatstaven en geen afgesproken proces om op de uitkomst te handelen.

Het in kaart brengen van de huidige situatie laat zien wie de data bezit die een model nodig heeft en hoe goed die is. RACI beantwoordt wie de uitkomst valideert, wie besluit erop te handelen en wie eindverantwoordelijk is als ze fout is. MoSCoW scheidt essentiële use cases van interessante. Begin met twee of drie essentiële use cases met duidelijke eigenaren en succesmaatstaven, niet met vijftien tegelijk.