SAP-projectherstel: een programma redden dat uit koers is

SAP-projectherstel betekent een migratie of implementatie die uit koers is stilzetten, uitzoeken wat er werkelijk waar is, en vanuit die waarheid opnieuw plannen. De eerste week beslist of het werkt: beoordeel de programmastatus, review het ontwerp en beoordeel wat er werkelijk in het systeem is uitgerold.

Kort antwoord: als die drie controles met elkaar en met het plan overeenkomen, heeft het programma een duwtje nodig, geen redding. Komen ze niet overeen, dan lost geen enkele extra inspanning op het huidige plan het op, en hebt u een formeel herstel met een nieuwe baseline nodig.

Dit artikel gaat over die diagnose en wat erop volgt. Het is een onderdeel van mijn gids over de migratie van ECC naar S/4HANA, die routes, doorlooptijden en deadlines behandelt. Hier is de vraag smaller: uw programma zit in de problemen, wat nu?

De meeste programma's die achterlopen, hoeven niet gered te worden. Ze hebben snellere beslissingen nodig, een key user die wordt vrijgemaakt of een leverancier die aan een datum wordt gehouden. Dat is een duwtje.

Een redding is iets anders. De signalen komen uit dezelfde drie controles die ik in week één uitvoer, en het signaal is eenvoudig: de status, het ontwerp en wat er is uitgerold, komen niet overeen met elkaar of met het plan.

Een paar patronen die ik als signaal voor een redding zou behandelen:

1. De status is groen, het systeem niet. Rapporten zeggen dat het grootste deel van de bouw klaar is, maar het testsysteem kan geen basale order-to-cash draaien.
2. Het ontwerp is getekend, de bouw negeert het. De configuratie is gedaan op basis van workshopaantekeningen, niet op basis van het goedgekeurde ontwerp.
3. Het plan heeft een go-livedatum, niemand kan de weg ernaartoe uitleggen. Testen, dataloads en cutover-generales hebben geen realistisch tijdslot.
4. De scope groeit alleen maar. De WRICEF-lijst (rapporten, interfaces, conversies, uitbreidingen, formulieren en workflows) stijgt nog steeds, lang na de Explore-fase.

Elk van deze kan met een duwtje worden opgelost. Twee of meer tegelijk meestal niet.

Week één is om uit te zoeken wat waar is. Niet om te repareren, niet om schuldigen aan te wijzen en niet om een nieuw plan te schrijven. Ik beoordeel drie dingen, in deze volgorde: de status, het ontwerp en wat er werkelijk is uitgerold.

Dit is wat elke controle dekt en wat een gebrek aan overeenstemming u vertelt:

Controle	Waar ik naar kijk	De vraag die ze beantwoordt	Als ze niet overeenkomt met de andere
Programmastatus	Plan, statusrapporten, RAID-log, openstaande wijzigingsverzoeken, uitgaven tegenover budget	Wat gelooft het programma over zichzelf?	De rapportage is te optimistisch of los van de levering
Ontwerp	Ontwerp van bedrijfsprocessen, uitkomsten van fit-to-standard, WRICEF-lijst, openstaande ontwerpbeslissingen	Wat is de business beloofd?	De bouw is afgedreven van wat is afgesproken, of het ontwerp is nooit afgemaakt
Wat is uitgerold	De ontwikkel- en testsystemen, configuratie, transporten, maatwerkcode, dataloads tot nu toe	Wat bestaat er vandaag werkelijk?	Er is voortgang gerapporteerd op werk dat niet in het systeem zit

De derde controle is de controle die de meeste reviews overslaan. Ze betekent achter het systeem gaan zitten en processen draaien, niet documenten over het systeem lezen.

Statusrapporten en ontwerpdocumenten zijn beweringen. Het systeem is bewijs.

Wie de controles hoort uit te voeren

De mensen die de statusrapporten schreven, horen niet de mensen te zijn die ze verifiëren. Dat is geen beschuldiging. Het is dezelfde reden waarom auditors hun eigen werk niet controleren.

Ik zou iemand die onafhankelijk is van de implementatiepartner verantwoordelijk maken voor week één, met volledige toegang tot de systemen en het recht om met iedereen in het programma te praten. Is dat niet mogelijk, laat de partner u dan minstens het uitgerolde systeem live laten zien in plaats van op slides.

In 2018 werkte ik aan het herstel van een luchtvaartprogramma. De modules waren uitgerold, maar niets was geconfigureerd op basis van de eisen van de business.

Dat is precies de situatie die de drie controles in week één moeten blootleggen. Uitgerolde modules zijn niet hetzelfde als een werkend ontwerp, en alleen in het systeem kijken laat het verschil zien.

Luchtvaartmaatschappijen verbinden onderhoud, inkoop en finance nauw met elkaar, dus een gat in één gebied reist mee. Hoe SAP bij die branche past, behandel ik op mijn pagina over SAP voor de luchtvaart.

In de 21 SAP-programma's die ik heb geleid of gered, is de grootste fout die ik zie dat er aan het begin van de implementatie niet goed wordt gepland. Een redding is vaak die ontbrekende planning, laat en onder druk gedaan.

Twee andere oorzaken komen steeds terug:

1. De leverancier beheert de scope. Als de systeemintegrator de scope schrijft, beschrijft die wat de integrator van plan is te leveren. De gaten komen later binnen als wijzigingsverzoeken, geprijsd door dezelfde leverancier.
2. Maatwerkcode loopt uit. In mijn ervaring is maatwerkcode de migratiefase die het vaakst uitloopt, en ook de verborgen kostenpost die het vaakst wordt vergeten.

De budgetkant hiervan, inclusief waarom de kosten juist in de Explore-fase omhoogschieten, behandel ik in mijn artikel over waarom SAP-projecten over budget gaan. Ik herhaal het hier niet.

Zwakke beheersing is de andere rode draad. Had het programma nooit een wekelijks ritme van volgen, escaleren en wijzigingsbeheer, dan moet de redding er een invoeren. Mijn gids over planning en beheersing van SAP-projecten beschrijft dat ritme, met eigenaren.

Zodra u weet wat waar is, heeft het herstel een duidelijke volgorde. Een stap overslaan betekent meestal dat u de redding twee keer doet.

Volgorde van het herstel van een SAP-programma

1. 01

   Diagnosticeren

   Status, ontwerp en wat is uitgerold, tegen elkaar gecontroleerd.

2. 02

   Scope terugnemen

   Scope in eigendom van de klant, bevroren, met elke wijziging geprijsd.

3. 03

   Nieuwe baseline

   Eén nieuw plan gebouwd op bewijs, met onvoorzien aan uw kant.

4. 04

   Fasen afsluiten met poorten

   Een kwaliteitspoort aan het eind van elke resterende fase.

5. 05

   Repeteren en cutover

   Volledige generales voordat een go-livedatum wordt bevestigd.

1. Neem het eigenaarschap van de scope terug

Beslis wie eigenaar is van de scope voordat iemand opnieuw plant. Is het antwoord nog steeds de leverancier, dan faalt het nieuwe plan op dezelfde manier als het oude.

Schrijf de scope aan de kant van de klant, vergelijk die met wat is uitgerold en bevries hem. Vanaf dat moment is elke wijziging een geprijsde beslissing met een eigenaar.

2. Stel één keer een nieuwe baseline vast, op basis van bewijs

Een herstel krijgt één nieuwe baseline, geen reeks kleine verschuivingen. Bouw die op basis van wat het systeem laat zien, niet op basis van wat het oude plan hoopte.

Schat eerst de maatwerkcode opnieuw in, want daar komen overschrijdingen het vaakst vandaan. Daarna data, want datamigratie is 30 tot 40 procent van de inspanning en loopt in een programma met problemen meestal achter.

Houd 10 tot 20 procent onvoorzien aan uw kant, en geef het alleen vrij tegen benoemde risico's. Mijn zusterartikel over de kosten van een S/4HANA-migratie legt uit wat de getallen bepaalt.

3. Zet een kwaliteitspoort aan het eind van elke fase

Programma's met problemen zijn meestal van fase naar fase gegaan op basis van data in de agenda in plaats van bewijs. Zet dat recht.

In SAP Activate draait de Explore-fase fit-to-standard-workshops, en goedgekeurde delta-eisen gaan naar de product backlog voor Realize. Heeft het programma Explore verlaten zonder afgerond ontwerp, ga dan terug en maak het af. SAP Cloud ALM ondersteunt kwaliteitspoorten als controlepunten met checklists, zichtbaar in het projectoverzicht, dus de poort hoeft niet in een spreadsheet te leven.

4. Repeteer voordat u zich aan een datum vastlegt

Bij een brownfield-conversie plan ik drie proefconversies vóór de cutover. Programma's met problemen schrappen vaak generales om tijd te winnen, en dat verplaatst het risico naar het go-liveweekend.

De cutover-downtime die ik heb gezien, varieert van een weekend tot een week. Een gered programma hoort zijn getal te kennen uit een generale, niet uit een schatting.

5. Controleer de deadline waar u werkelijk naartoe werkt

Voor SAP ERP 6.0 op enhancement packages 6 tot en met 8 eindigt het mainstream-onderhoud op 31 december 2027, met optioneel verlengd onderhoud tot eind 2030 tegen een opslag van twee procentpunten (SAP News). Een herstel dat een ECC-migratie voorbij 2027 duwt, hoort openlijk verlengd onderhoud te budgetteren.

Laat de datum van 2027 geen go-live afdwingen die de generales niet onderbouwen. Een late go-live kost onderhoudsvergoedingen. Een mislukte kost veel meer.

Een redding roept vaak de vraag op of u de huidige systeemintegrator houdt. Soms is de partner vervangen de juiste keuze. Vaak is het grotere probleem hoe het programma is opgezet, en een nieuwe partner erft dat.

Dit zijn de vragen die ik zou stellen voordat ik beslis:

1. Kunt u ons het uitgerolde systeem live laten zien, tegenover het getekende ontwerp? Geen demo-omgeving en geen slides.
2. Welke WRICEF-objecten zijn gebouwd, getest en getransporteerd, en welke worden alleen als klaar gerapporteerd?
3. Wat is uw high-level design om af te ronden, en welke referenties kunnen we bellen waar u een programma zoals het onze hebt hersteld? Referenties en het high-level design zijn de twee dingen waar ik elke partner om vraag voordat er getekend wordt.
4. Wat hebt u van ons nodig dat u niet krijgt? Ontbrekende beslissingen en parttime key users zijn vaak de helft van het verhaal.
5. Voor klanten van RISE with SAP: welke problemen liggen bij SAP in plaats van bij de partner, en wie escaleert ze?

De rode vlag is dezelfde als die waarbij ik bij de selectie van een partner wegloop: algemene antwoorden. Kan het herstelplan op elk bedrijf van toepassing zijn, dan is het niet voor het uwe geschreven. Mijn gids over het kiezen van een S/4HANA-migratiepartner behandelt de selectiekant.

Heeft het programma nooit een goede beoordeling van het bronsysteem gehad, voer die dan nu uit. De SAP Readiness Check analyseert uw bestaande systeem, en SAP raadt aan hem in productie te draaien voor een nauwkeurig beeld van het echte gebruik. Mijn artikel over de SAP Readiness Check en migratiebeoordeling legt uit wat hij mist, te beginnen met maatwerkobjecten.

Plan een halve dag met uw programmadirecteur en uw SAP-lead, en vraag hun drie dingen naast elkaar te laten zien: het laatste statusrapport, het getekende ontwerp en het testsysteem dat één volledig bedrijfsproces draait. Vertellen die drie hetzelfde verhaal, geef dan een duwtje. Doen ze dat niet, start dan een formeel herstel vóór de volgende stuurgroep.

Wilt u een onafhankelijke blik op een programma dat uit koers is, dan help ik organisaties met precies dit soort diagnose. U kunt een gesprek met mij plannen.

Wat is SAP-projectherstel?

SAP-projectherstel is het werk om een SAP-implementatie of -migratie die uit koers is, weer onder controle te brengen. Het begint met een diagnose van de programmastatus, het ontwerp en wat er werkelijk is uitgerold, neemt daarna het eigenaarschap van de scope terug, stelt één nieuwe baseline vast en voegt kwaliteitspoorten toe aan de resterende fasen.

Hoe weet ik of mijn SAP-project een redding nodig heeft?

Vergelijk drie dingen: wat de statusrapporten zeggen, wat het getekende ontwerp zegt en wat er werkelijk in het systeem is uitgerold. Komen ze met elkaar en met het plan overeen, dan heeft het programma een duwtje nodig. Komen ze niet overeen, dan lost meer inspanning op het huidige plan het niet op en hebt u een formeel herstel nodig.

Wat moet er gebeuren in de eerste week van het herstel van een SAP-implementatie?

Alleen diagnose. Beoordeel de programmastatus, review het ontwerp en beoordeel wat er werkelijk is uitgerold, bij voorkeur geleid door iemand die onafhankelijk is van de implementatiepartner. Schrijf het nieuwe plan pas als die drie controles zijn gedaan.

Moeten we onze SAP-implementatiepartner vervangen tijdens een herstel?

Niet automatisch. Vraag de partner het uitgerolde systeem te laten zien tegenover het getekende ontwerp, en u een high-level design te geven om af te ronden, met referenties van vergelijkbare herstelprojecten.

Zijn de antwoorden algemeen, dan is dat een sterk signaal om te wisselen. Ligt het echte probleem bij het eigenaarschap van de scope of bij ontbrekende beslissingen aan uw kant, dan erft een nieuwe partner dat.

Waarom raken SAP S/4HANA-migraties uit koers?

De meest voorkomende hoofdoorzaak die ik zie, is dat er aan het begin van de implementatie niet goed wordt gepland. De leverancier de scope laten beheren is een andere, en maatwerkcode is de fase die het vaakst uitloopt. Datamigratie, met 30 tot 40 procent van de inspanning, loopt meestal ook achter.

Duwt een herstel onze ECC-migratie voorbij de deadline van 2027?

Dat kan. Het mainstream-onderhoud voor SAP ERP 6.0 op enhancement packages 6 tot en met 8 eindigt op 31 december 2027, en optioneel verlengd onderhoud loopt tot eind 2030 tegen een opslag van twee punten. Budgetteer verlengd onderhoud in plaats van een go-live af te dwingen die uw generales niet onderbouwen.