Hoe is het acceptatieproces van ERP implementaties te optimaliseren?

Drie artikelen beschrijven twee cruciale succesfactoren bij het implementeren van Enterprise Resource Planning (ERP)-systemen. De eerste succesfactor is de juiste projectmedewerkers uit de organisatie betrekken. Dit is beschreven in het eerste artikel geplaatst in editie 11 van dit Vakblad. De tweede succesfactor is het accepteren van het nieuwe ERP-systeem. In het tweede artikel ligt de focus op de actoren in het acceptatieproces. Het laatste artikel (te lezen in editie 13) gaat in op activiteiten in het acceptatieproces zelf.
 

Een opgeleverd ERP wordt gemakkelijker geaccepteerd als de actoren die moeten accepteren (de acceptanten) gedurende het hele project betrokken worden. De projectactoren opdrachtgever, stuurgroep, projectmanager, project managementteam, procesteams, technisch team, klankbordgroep, kwaliteitsfunctionarissen spelen een belangrijke rol (zie het tweede artikel). Deze actoren voeren en doorlopen met elkaar een proces om te komen tot de acceptatie van het nieuwe ERP-systeem, het acceptatieproces. Dit proces bestaat uit een aantal activiteiten. Deze activiteiten zijn verdeeld over de verschillende projectfases (zie figuur 1). Uitgangspunt is dat er gedurende alle projectfases acceptatie gerelateerde activiteiten worden verricht, waardoor de ingerichte processen beter aansluiten bij de gewenste situatie en de kwaliteit van het resultaat (het ingerichte ERP-systeem) hoger wordt. Wij bespreken hieronder de benodigde activiteiten voor besluitvorming, escalatie en acceptatie per projectfase.

Projectfase Projectinitiatie

In de projectinitiatie wordt de besturing voor acceptatie van de ERP-oplossing ingericht, zoals beschreven in het tweede artikel. Deze governance van het acceptatieproces bestaat uit het invullen van de taken, verantwoordelijkheden en bevoegdheden van de diverse actoren en de bijbehorende personele bezetting, inclusief het vastleggen van de mandaten, escalatiepaden en besluitvorming.

Belangrijke processtap in deze fase is het opstellen van de functionele en non-functionele acceptatiecriteria door de functionele en technische teams, met betrokkenheid van de klankbordgroep en kwaliteitsfunctionarissen en in lijn met de eventueel aanwezige projectstrategie. De bedrijfsprocessen in scope zijn de basis voor de functionele en non-functionele acceptatiecriteria. Door deze criteria nu al vast te leggen kan er tijdens de overige fases aan worden gerefereerd en kunnen ze worden getoetst. Daarnaast draagt het werkproces voor het opstellen van de acceptatiecriteria bij aan de kwaliteit van de eindoplossing en ontstaat er een gedeeld beeld over wat gerealiseerd moet worden. Zorg ervoor dat de acceptatiecriteria in een log worden vastgelegd (incl. het bijhouden van de wijzigingen) en dat dit voor iedere projectactor te raadplegen is.

Na het vaststellen van de functionele en non-functionele acceptatiecriteria is het belangrijk om deze te valideren met de stuurgroep als finale acceptant. De volgende vraag staat hierbij centraal: ‘Als deze acceptatiecriteria gerealiseerd zijn, wordt het systeem dan geaccepteerd?’ Uiteraard kan het, door voortschrijdende inzichten in latere fases, lastig zijn om in de initiatie fase de finale criteria te bepalen. Enige flexibiliteit en bijsturing moet mogelijk zijn gedurende de opvolgende fases, zorg wel voor een goed veranderproces en documentatie (log). Wees er als projectmanager dus alert op dat er wijzigingen plaats kunnen vinden en wees ontvankelijk voor deze wijzigingen, mits volgens een proces in het project geformaliseerd: als je dit niet doet kan dit terug komen tijdens de eindgebruikerstesten of erger na go-live.

De acceptatiecriteria zijn ook een basis voor het opstellen van de test- en trainingsaanpak. De testaanpak zal moeten verifiëren en valideren of de eindoplossing voldoet aan de gestelde functionele en non-functionele criteria. Bedrijfsprocessen en gekoppelde functionele acceptatiecriteria zijn input voor het opstellen van trainingen en het opstellen van toetsen. Bovendien is een getrainde gebruikersorganisatie zelf ook een criterium voordat het systeem live kan worden gebracht.

Bepaal in deze fase ook het proces van goedkeuring en de personen en partijen die het eindproduct moeten accepteren. Dit kan in de vorm van een acceptatiestrategie, goedgekeurd door de stuurgroep van het project. Het proces van accepteren wordt in de overige projectfases beschreven, samengevat als wie accepteert wat en op welke wijze.

Hierbij het van belang om te bepalen voor welke onderdelen van het acceptatieproces je handtekeningen wilt vragen of nodig hebt. Onze ervaring is dat mensen een andere lading geven aan een acceptatie als zij een handtekening moeten zetten en zorgvuldiger naar de kwaliteit van de opgeleverde resultaten zullen kijken. Het zetten van handtekeningen voor de acceptatie van nieuwe functionaliteiten of volledige ERP-systemen is in sommige branches verplicht, bijvoorbeeld bij productietechnologie voor levensmiddelen of medicijnen, dit is dan een formele acceptatiestap. Zonder handtekening mag niet worden gestart met de volgende activiteit.

Het gehele bovenstaande proces van acceptatie wordt beschreven in het Project Initiatie Document (PID, in Prince2 termen) dat goedgekeurd wordt door de stuurgroep en het ‘contract’ vormt voor alle projectuitvoerenden.

Onze ervaring is dat het houden van informatiesessies of het geven van een training over het acceptatieproces en acceptatie gerelateerde elementen uit het PID inzicht in en informatie geeft over wat van de acceptanten wordt verwacht in het acceptatieproces.

Projectfase Ontwerp van de oplossing

Bij het procesontwerp van het toekomstig gewenste business proces wordt rekening gehouden met de acceptatiecriteria en wordt er bijgehouden welke criteria wel of niet worden gerealiseerd. Als criteria niet worden gerealiseerd of criteria worden gemist dan wordt dit met reden teruggekoppeld aan de acceptanten, met eventuele alternatieve oplossingen. In geval van knelpunten kunnen acceptanten betrokken worden bij de escalatie en besluitvorming en bij het opstellen van eventuele alternatieven. Dit geldt ook voor het ontwerp van maatwerk, interfaces, datamigratie, rapporten, testscripts, trainingsplannen en concept trainingsmaterialen.

De nieuwe processen (blauwdruk), de testscripts, de concept trainingsmaterialen en het actuele overzicht van de realisatie van de acceptatiecriteria worden op reguliere basis aan (een deel) van de acceptanten (in deze fase vooral de klankbordgroep en de kwaliteitsexperts) teruggekoppeld. Bij afronding van de fase (en de blauwdruk) worden ze als geheel voorgelegd voor een eerste review en akkoord. Dit akkoord zal voorlopig zijn (‘op basis van de dan beschikbare kennis’) en is de basis om naar de volgende projectfase door te gaan.

Projectfase Realisatie van de oplossing

Tijdens en na de realisatie (bouw software en hardwarecomponenten, inrichting van de standaard software) worden de opgeleverde onderdelen getest. Bij het uitvoeren van de testen worden de nieuwe processen, maatwerk, interfaces en waar mogelijk de infrastructuur getest op werking volgens het ontwerp en of ze voldoen aan de acceptatiecriteria. In praktijk is regelmatig aanpassing of bijsturing nodig, bijv. omdat een ontworpen proces tijdens het testen niet goed de praktijk afdekt, of te complex is. In deze gevallen moet het ontwerp worden aangepast, wat in overleg met (een deel van) de acceptanten (met name de klankbordgroep en de kwaliteitsexperts) moet gebeuren. Niet alleen het ontwerp/de documentatie moet worden aangepast, dit geldt mogelijk ook voor de acceptatiecriteria.

In praktijk is het realiseren en testen een iteratief proces en vindt regelmatig aanpassing of bijsturing plaats. Onze ervaring is om in korte iteraties, bijvoorbeeld maximaal twee weken, te realiseren en/of te testen. Dit kan sequentieel of dit kan gelijk in een iteratie. Onze voorkeur gaat uit alles in een iteratie, zowel realisatie als het testen van de gerealiseerde onderdelen. Maak realisatie van de onderdelen zo klein mogelijk: hoe sneller feedback of iets werkt en voldoet aan de criteria hoe sneller je kunt inspelen op afwijkingen. Na de testen op onderdelen zullen ook de testen voor de oplossing als geheel in samenhang moeten worden doorlopen, inclusief de eventuele integratie met andere systemen ([proces]interfaces. Voor de uiteindelijke gebruikersacceptatietesten is het noodzakelijk dat de gebruikers getraind zijn in het nieuwe systeem; deze laatste testen vinden daarom plaats in de implementatiefase.

Organiseer in deze fase ook live demo’s of show and tell sessies aan de brede groep van acceptanten, inclusief de stuurgroep, en overige geïnteresseerden om inzicht te geven in het nieuwe systeem. Doorloop tijdens je demo’s representatieve cases en ga in op belangrijke details, zoals prijs- en kortingsstructuren of de voorraadsystematiek, vooral op die gebieden waar de grootste verandering met de grootste impact plaatsvindt. Het is belangrijk om de feedback te verwerken en waar nodig acceptatiecriteria aan te passen, aan te vullen of te verwijderen: dit verhoogt de kwaliteit en acceptatie van het systeem.

Laat in deze fase het trainingsmateriaal toetsen: door de trainingsmaterialen te laten reviewen door de functionele procesteams en voor te leggen aan de klankbordgroep en de kwaliteitsfunctionarissen krijgen deze actoren meer inzicht in het systeem en geeft dit de mogelijkheid hun rol beter te vervullen. Uiteindelijk draagt dit bij aan het verhogen van de kwaliteit van het trainingsmateriaal en daardoor aan de acceptatie van de oplossing door de eindgebruikers. Betrek een expert op het gebied van opstellen en geven van trainingen, dit is een vak apart.

In deze fase wordt ook het cutoverplan/-draaiboek voor de ingebruikname van het nieuwe systeem (‘go-live’) opgesteld. Tijdens deze cutover, welke wordt uitgevoerd in de implementatiefase, worden diverse go-live acceptatiestappen doorlopen. Het cutoverplan/-draaiboek moet alle cutover- en acceptatiestappen bevatten. Wordt er een go-live acceptatiecriterium tijdens de cutover niet gehaald dan kan dit betekenen dat de go-live niet door kan gaan. Stel het cutoverplan/-draaiboek op in samenspraak met de proces- en technische teams en de kwaliteitsexperts: deze teams hebben veelal een rol tijdens de cut-over, door ze mee te laten opstellen doorleven zij het plan en verhoogt dit de kwaliteit van de cut-over. Voer ter acceptatie van dit document en als voorbereiding van de cutover een aantal simulaties (dry-runs) uit.

Naast bovenstaande hebben we positieve ervaringen met het regelmatig houden evaluaties met de bij het acceptatieproces betrokken actoren: het geeft de mogelijkheid om bij te sturen en eventuele knelpunten voor acceptatie vroegtijdig te evalueren. Het gaat hier niet zozeer over de inhoud maar over het proces om het eindresultaat te bereiken. Je kunt tijdens zo’n sessie ingaan op hoe er wordt samengewerkt, hoe het proces wordt uitgevoerd, of de juiste actoren betrokken zijn en of er op tijd wordt bijgestuurd,.

Projectfase Implementatie

Na het trainen van de eindgebruikers in deze implementatiefase vinden de gebruikersacceptatietesten plaats, waarmee de operationele gebruikers het systeem beoordelen. Niet alleen worden de functionele (proces)aspecten van het systeem getest, maar ook de integratie met andere systemen, of de data van het te vervangen systeem goed wordt overgenomen en ook of de niet-functionele aspecten, zoals de performance van het systeem (bijv. scherm- en verwerkingsresponstijden) naar verwachting presteren.

De gebruikersacceptatietesten zijn een belangrijk onderdeel van deze acceptatie, maar passen in het grotere geheel van alle acceptatiecriteria die aan het begin van het project zijn vastgelegd: is het systeem voldoende gedocumenteerd, zijn de gebruikers voldoende opgeleid, is de organisatie gereed voor eventuele andere werkstructuren / autorisaties, is er voldaan aan de SOX- en security voorwaarden, is het cutoverplan gereed, inclusief een eventuele fallback als de cutover niet volgens plan verloopt.

Als de gebruikersacceptatietesten en de trainingen succesvol zijn doorlopen, kan de cutover gaan beginnen volgens het cutoverdraaiboek. Voordat dit gaat starten zullen alle acceptanten op basis van de acceptatiecriteria een formele goedkeuring voor start moeten geven. In praktijk is het vaak de stuurgroep die deze goedkeuring geeft, gebaseerd op input van de andere acceptanten als informant.

Deze fase sluit af met het uitvoeren van het cutoverdraaiboek. In het draaiboek behoren diverse acceptatiemomenten te zitten, waaraan de goedkeuring voor volgende stap is gekoppeld. Gezien het belang van de systeemovergang van de organisatie en de impact als het niet goed loopt, moet de acceptatie neergelegd worden bij het hoogste niveau betrokken bij de scope van het systeem, vertegenwoordigd in de stuurgroep:

  • Voor de start dient er een goedkeuring te komen van de stuurgroep voor het afsluiten van het oude systeem en het overzetten naar en het opstarten van het nieuwe systeem. Feitelijk is dit de acceptatie van de voorliggende activiteiten, zoals testen, trainen en het afronden van de acceptatiecriteria. De stuurgroep zal zich baseren op eigen waarnemingen en de informatie aangeleverd door andere acceptanten.
  • Na afronden van het omzetten van het systeem, waarbij de datamigratie aantoonbaar succesvol is afgerond en de infrastructuur en de interfaces aangezet en getest zijn, volgt een goedkeuring door de stuurgroep voor de eerste operationele testen (bijvoorbeeld doorlopen aantal scenario’s van live orders, inclusief interfaces) door een kleine groep gebruikers.
  • Als deze live testen succesvol zijn doorlopen zal het systeem door de stuurgroep worden vrijgegeven en open worden gezet voor de gehele gebruikersgroep.

Projectfase Post Implementatie

Onderdeel van acceptatie is het overdragen van het project aan de operationele organisatie: als voldaan wordt aan de in de initiatiefase opgestelde criteria kan het project worden overgedragen. Daarbij gelden als voorwaarden (exitciteria) dat het systeem zich in praktijk een aantal weken operationeel heeft bewezen, alle kritische processen succesvol zijn doorlopen en de eventuele problemen in voldoende mate zijn opgelost. Verantwoordelijk operationeel (lijn)management dient het systeem dan finaal te accepteren, waarna eventuele verstoringen opgelost worden door de operationele IT-organisatie en niet meer door de projectorganisatie. Hierbij is het gebruikelijk dat al vóór go-live door IT- operations een intake wordt gedaan: onze ervaring is om al tijdens de initiatiefase de criteria voor deze intake met de operationele IT-organisatie op te stellen en de operationele organisatie te zien als een van de belangrijke actoren. Als je dit niet doet dan loop je het risico dat je het project niet kan afronden, omdat je volgens de operationele organisatie niet voldoet aan de criteria.

Na deze overdracht kan het project worden gestopt en het projectteam worden opgeheven.

Als onderdeel van het afsluiten van het project is het goed om met de actoren een eindevaluatie te houden. Bespreek met elkaar de acceptatiecriteria, het acceptatieproces en de governance: wat ging goed en wat kan beter? Leg als projectmanager de bevindingen vast in een eindevaluatie en maak dit onderdeel van je decharge bij de stuurgroep. Dit is het moment waarop je vraagt om ontheven te worden van je taak.

Formele acceptatie en informele acceptatie

Een vraag die vaak naar voren komt is hoe formeel je het acceptatieproces moet maken door bijvoorbeeld de acceptanten handtekeningen te laten zetten. Los van het feit dat het soms vanuit branche specifieke externe criteria (bijvoorbeeld SoX) verplicht is om iedere systeemwijziging traceerbaar goed te laten keuren door bevoegde personen, confronteert een formeel acceptatieproces de acceptanten met extra verantwoordelijkheid. Onze ervaring is dat zodra je acceptanten vraagt een handtekening te zetten er dan nog eens kritisch wordt gekeken of de oplossing echt wel voldoet aan de acceptatiecriteria. Voor de volgende stappen is een formele acceptatie, in ieder geval vastgelegd in notulen van bijvoorbeeld de stuurgroep, aan te bevelen:

  • Het aftekenen van het ontwerp in procesbeschrijvingen, rollen en verantwoordelijkheden en doorlooptijden, met review door de klankbordgroep,
  • Verslaglegging van de show and tell sessie aan alle belanghebbenden van alle relevante organisatieonderdelen,
  • Het opleveren van testverslagen van het testen van de oplossing door de proces- en technische teams, waarin aangetoond wordt dat de testuitkomsten voldoen aan de gestelde acceptatiecriteria,
  • Het opleveren van testverslagen van het testen van de oplossing door de eindgebruikers in de gebruikers acceptatietest, waarin aangetoond wordt dat de testuitkomsten voldoen aan de gestelde acceptatiecriteria,
  • Het aftekenen van de cutover stappen dat ze goed zijn uitgevoerd en dat het resultaat voldoet aan de gestelde acceptatiecriteria. Dit aftekenen dient te gebeuren door de stuurgroep en de opdrachtgever (formele handtekening onder documenten, zeker indien vanuit SoX verplicht) van de cutover en go-live besluiten,

Ons advies is om in de diverse groepen een besluitenregister bij te houden waarin formeel wordt vastgelegd dat het besluit goed is geformuleerd.

Naast de harde kant van het accepteren is er ook de zachte kant. Het nieuwe systeem kan prima voldoen aan alle vastgestelde functionele en non-functionele acceptatiecriteria en toch niet worden geaccepteerd door de gebruikers. De redenen hiervoor zijn vaak ongrijpbaar maar wel belangrijk. Onze meest succesvolle implementaties waren die waar wij naast de formeel gedefinieerde en goedgekeurde acceptatiecriteria veel aandacht hadden voor de informele menselijke acceptatie. Implementeren is en blijft mensenwerk.

Afsluiting

Het acceptatieproces verdient aandacht vanaf het begin van het project. Zorg dat de juiste actoren betrokken worden. Leg een goede basis in de besturing en het proces en doorleef deze met alle actoren. Neem voldoende tijd en ruimte om de functionele en non-functionele acceptatiecriteria te beschrijven en te begrijpen. Zorg voor een weloverwogen acceptatie door het laten zetten van handtekeningen. Leg besluiten vast in een besluitenlijst. Geef ook aandacht aan de zachte kant van het acceptatieproces en spreek regelmatig informeel met de diverse actoren en gebruikers, en laat op basis van deze gesprekken je intuïtie spreken. Met de toepassing van deze elementen zal de kwaliteit van uw implementatie en de acceptatie worden vergroot.

Blogdetails

04-06-2021
Publicaties
  • Erik van Daalen

    Senior Project Manager

    Pragmatische zelfstartende traditioneel / agile projectmanager die zich kenmerkt door zijn drive, besluitvaardigheid en duidelijkheid. Analyseert vraagstukken snel, scherp en gestructureerd. Neemt ownership, heeft oog voor ieders belangen, en zorgt voor verbinding binnen en buiten zijn projectorganisatie.

    Meer over Erik van Daalen

  • Erik van Daalen

Wil je meer weten?

We vertellen je graag meer over onze aanpak van het succesvol managen van projecten en programma’s.

Bel ons op 088 266 28 70 Stuur ons een bericht