Besturing acceptatieproces in ERP implementaties

Bij het afsluiten van een project wordt het resultaat overgedragen aan de operationele organisatie, die hiermee dit resultaat formeel accepteertHet is belangrijk deze formele acceptatie goed te regelen, anders eindigt het project nooitHet beste resultaat is te boeken als degene die moeten accepteren worden meegenomen van begin van het project tot einde. Doordat bij alle projectactiviteiten meegekeken wordt vanuit acceptatieperspectief wordt de kwaliteit van het resultaat (het ingerichte ERP-systeem) hoger. De uiteindelijke acceptatie zal makkelijker gaan, omdat het projectresultaat geen verrassing is voor de acceptanten. 
 

Wat is ERP?

ERP-systemen zijn softwarepakketten die meerdere bedrijfsbrede processen automatiseren en integreren. Ze hebben als doel de productiviteit van organisaties te maximaliseren, de kosten te beheersen en om optimaal te voldoen aan klantwensen. Het afgeleide doel van een ERP-project is dat het op te leveren systeem de organisatie helpt de hierboven genoemde doelen te realiseren conform de functionele- en kwaliteitseisen die bepaald zijn door de accepterende organisatie aan het begin van het project. Aan het einde van het project bepalen de acceptanten of het pakket aan deze eisen voldoet.

In de implementatie zijn verschillende fasen te onderscheiden.

  • Projectinitiatie: de opstart van het project, waarin alle initiële zaken geregeld worden die nodig zijn voor de start van de activiteiten.
  • Ontwerp van de oplossing: het eindproduct dat door het project opgeleverd zal worden (het ingerichte ERP-systeem, volgens de specificaties van de gebruikersorganisatie).
  • Realisatie: van het eindproduct, inclusief de gewijzigde governance, de interfaces, de gemigreerde data, de eventuele maatwerkaanpassingen, het testen van de oplossing, het opstellen van trainingsmateriaal en de draaiboeken om het ERP-systeem live te brengen. Ook wordt de benodigde technische infrastructuur ingericht en de beheersorganisatie voorbereid.
  • Implementatie van de oplossing: betreft het testen van de oplossing, het trainen van de eindgebruikers en de go-live.
  • Post-implementatie support: de nazorg na go-live van het systeem en de uiteindelijke acceptatie.

Projectgovernance

Iedere fase uit het ERP-implementatiemodel heeft andere activiteiten. Hierdoor kan de samenstelling van het projectteam per fase verschillen. Rollen worden ingevuld door zowel individuele personen als door groepen (actoren). Wij gebruiken hier bewust rollen en geen functies, omdat rollen door meerdere actoren kunnen worden vervuld, een functie is persoonsgebonden. Projectleden vervullen een rol in het ERP-project maar hebben daarnaast vaak een operationele functie: de rollen die wij hier beschrijven zijn projectrollen.

De eerste stap is het bepalen van de projectgovernance (besturing), dit vindt plaats in de initiatiefase. De projectgovernance wordt vastgesteld door de stuurgroep, vaak op voordracht van de projectmanager. Deze governance kan dynamisch worden bijgestuurd (na goedkeuring door de stuurgroep) afhankelijk van ontwikkelingen in het project. In de governance spelen de actoren opdrachtgever, stuurgroep, projectmanager, projectmanagementteam, procesteams, technische teams, klankbordgroep en de kwaliteitsfunctionarissen een cruciale rol in de besturing van het acceptatieproces en de bij behorende activiteiten. Zij bepalen gezamenlijk de kwaliteit van de eindoplossing. Daarom is het belangrijk om deze actoren goed in positie te brengen en te houden gedurende de uitvoering van het project. Elke rol bekijkt/benadert de acceptatie vanuit een andere invalshoek. Zo zijn er rollen met een beleidsbepalende invalshoek, zij focussen op het inrichten van het acceptatieproces. Daarnaast zijn er rollen die met een uitvoerende invalshoek, zij voeren de acceptatie-activiteiten uit en als laatste is er de controlerende invalshoek, dit zijn de experts die hun vakkennis inbrengen en op die manier bijdragen aan de kwaliteit van de eindoplossing. Uiteindelijk vindt de acceptatie vanuit alle invalshoeken plaats. Wij bespreken de diverse actoren en hun rollen op basis van deze drie invalshoeken met als eerste de beleidsbepalende.

Beleidsbepalende actoren

De opdrachtgever is eindverantwoordelijk voor de realisatie van de voorziene opbrengsten (‘benefits’) van het programma en leidt als eindverantwoordelijke de organisatie naar het bedrijfsresultaat. Zij/hij is dus degene die het meeste belang heeft bij een succesvolle en gedragen implementatie en is de belangrijkste acceptant van het systeem. Immers, als het projectresultaat niet voldoet is er een groot risico dat de benefits niet worden gehaald. Deze persoon zal bij acceptatie door de overige actoren bevestigd moeten krijgen dat de opgeleverde oplossing in het ERP voldoende werkt.

In de praktijk zien wij dat de opdrachtgever zich niet bewust is van de belangrijke rol die hij zij vervult in het accepteren van de eindoplossing. Het is als projectmanager belangrijk om de opdrachtgever te begeleiden in zijn/haar rol in het acceptatieproces. Besteed hier in de initiatiefase voldoende tijd en hier aandacht aan. Begeleid de opdrachtgever om antwoorden te geven op de volgende vragen: Welke eisen en criteria stelt de opdrachtgever? Wie zou volgens de opdrachtgever de oplossing moet accepteren? Wat verwacht de opdrachtgever in jouw rol in het acceptatieproces? Wie vertrouwt de opdrachtgever informeel het meest?

Bespreek met de opdrachtgever het acceptatieproces goed door: onze ervaring is dat veel opdrachtgevers het fijn vinden als je hun begeleidt in hun rol in het acceptatieproces, zeker als deze rol nieuw voor ze is. Doe dit vooral in 1 op 1 gesprekken die je als projectmanager toch al op regelmatige basis (bijvoorbeeld wekelijks) hebt.

De stuurgroep, waarvan de opdrachtgever de voorzitter is, neemt op basis van de uitkomsten van het acceptatieproces het uiteindelijke besluit om live te gaan. Zij is verantwoordelijk voor de acceptatie van de oplossing en moet zekerstellen dat oplossing ook echt werkt. Zij raadpleegt hiervoor de functionele procesteams en de klankbordgroep, maar kan ook andere medewerkers of experts inschakelen als extra validatie. De samenstelling van de stuurgroep is van invloed op de acceptatie. Is de samenstelling breed, vanuit veel organisatieonderdelen, dan zal dit positief bijdragen aan een brede acceptatie en eigenaarschap van de oplossing. Zijn of voelen een aantal organisatieonderdelen zich niet betrokken dan is dit een potentieel risico dat zij de oplossing niet zullen accepteren. De kans bestaat dat dit vlak voor of net na de go-live naar boven komt. Het nadeel van een brede vertegenwoordiging is dat de besluitvorming complexer kan worden: dat vergt dan strakke aansturing van de voorzitter, ondersteunt door de projectmanager, van de stuurgroep. Mocht de stuurgroep te groot worden dan is er ook de optie om het projectmanagementteam uit te breiden. Wij hebben positieve ervaringen met een kleine stuurgroep en een breder projectmanagementteam.

In de praktijk zien wij dat het implementeren van een ERP-systeem voor de meeste stuurgroepleden nieuw is. Ons advies is om bij de start van het ERP-traject (initiatiefase) met de stuurgroep de diverse acceptatiestappen en hun rol hierin door te lopen. Bespreek met de stuurgroep wat zij belangrijk vinden bij de acceptatie, vertel hun wat hun belangrijke rol is en wat specifiek gevraagd wordt bijv. bij de ontwerpfase of aan het einde van de nazorgfase. Leg aan de stuurgroep uit wat de gevolgen kunnen zijn bij een niet goed uitgevoerd acceptatieproces. Bepaal samen met de stuurgroep wie hun een advies gaat geven over de acceptatie en in welke fase. Een methode die je hiervoor kunt gebruiken is het houden van een workshop specifiek gericht op het acceptatieproces. Leg gedurende deze workshop diverse acceptatie casussen voor en laat de stuurgroep bespreken hoe ze hier mee om willen gaan. Een andere mogelijkheid is de stuurgroep doormiddel van een spel mee te nemen in het acceptatieproces, waarbij ze het doorleven op een leuke leerzame manier.

Het is te adviseren om de samenstelling van de stuurgroep consistent te houden gedurende de uitvoering van het project. Bij elke wisseling dient het acceptatieproces opnieuw uitgelegd te worden zodat de nieuwkomer de vastgelegde informatie niet mist.

Uitvoerende actoren

De projectmanager is samen met de opdrachtgever/stuurgroep in de initiatiefase verantwoordelijk voor de governance nodig voor de acceptatie. Daarnaast is hij/zij in deze fase verantwoordelijk voor het inrichten van het acceptatieproces. Hij/zij zorgt in de diverse fases voor het opstellen van de acceptatiecriteria, het ontwerpen van de nieuwe processen en de realisatie in de software, het zorgen voor draagvlak, maar ook voor het afstemmen met de bredere organisatie. Hij/zij zorgt ook voor de formele aftekening van de acceptatie en legt resultaten ter besluitvorming voor aan de stuurgroep aan het einde van de nazorgfase. Naast het inrichten van het acceptatieproces heeft de projectmanager een belangrijke rol in het begeleiden van de diverse actoren in hun rol, hier gericht op de acceptatie. Hij vervult de rol van coach of faciliterend leider. De mate van begeleiding hangt af van de volwassenheid en ervaring die de organisatie heeft op het gebied van het uitvoeren van ERP-projecten, en in dit specifieke geval de acceptatie van de oplossing.

Het projectmanagementteam (PMT) ondersteunt de projectmanager bij het uitvoeren van zijn of haar taken. Het PMT richt samen met de projectmanager het acceptatieproces in, bewaakt de voortgang van het acceptatieproces en stuurt bij. Net als bij de stuurgroep is het belangrijk om de juiste actoren in het PMT te hebben, dit vergroot de draagkracht van de uitkomsten van het acceptatieproces. Meestal zijn dit de leiders van de diverse projectteams, mogelijk aangevuld met een aantal specialisten, bijvoorbeeld op gebied van kwaliteit of projectcontrolling. Zorg dat er in het PMT-actoren zitten die onafhankelijk zijn en vanuit hun proces en technische expert rol de kwaliteit van de oplossing bewaken: juist hun betrokkenheid verhoogt de kwaliteit van de acceptatiecriteria en het bewaken van de integraliteit.

Voor veel gebruikersorganisaties is het implementeren van een ERP nieuw en is er, door losstaande, onafhankelijke afdelingen, soms minder oog voor een integraal werkende oplossing. Daarnaast hebben eindgebruikers niet altijd een beeld wat er letterlijk achter de schermen van het pakket gebeurt. Door aanvullende kennis van experts, eventueel extern, kan er aanvullend bepaald worden of er niets wordt vergeten tijdens de acceptatie, met name ook in de ontwerp-, realisatie- en implementatiefase.

Het opstellen van de functionele vereisten, businessprocessen en acceptatiecriteria gebeurt veelal door de functionele en technische teams binnen een project. Omdat het vaak meerdere teams betreft is er een rol weggelegd voor de teamleiders in het PMT dat afstemming tussen de relevante teams plaats vindt.

De functionele procesteams3 zijn verantwoordelijk voor het opstellen van de acceptatiecriteria en het ontwerpen van de nieuwe processen. Zij zullen toetsen of deze nieuwe processen in lijn zijn met deze acceptatiecriteria. Functionele procesteams bestaan vaak uit de kerngebruikers en de applicatiespecialisten van de leverancier. De kerngebruikers zijn verantwoordelijk voor het definiëren van de functionele vereisten, businessprocessen en acceptatiecriteria. De applicatiespecialisten zullen aan de hand van de businessprocessen het systeem inrichten. Voor het realiseren van eventueel aanvullend maatwerk wordt gebruik gemaakt van technische teams. Na het inrichten van het ERP-systeem gaan de kerngebruikers het ERP-systeem toetsen en bepalen ze voor de eerste keer of het voldoet aan de acceptatiecriteria. Zij bespreekt de resultaten met PMT-leden of de projectmanager. Onze ervaring is dat de meeste eindgebruikers het lastig vinden om businessprocessen en acceptatiecriteria te beschrijven: voor de meesten is het de eerste keer. Bepaal als projectmanager wat het kennis- en ervaringsniveau is op dit gebied en organiseer begeleiding of training, ook in de nieuwe software. Neem de tijd om de kerngebruikers dit te leren, deze investering betaalt zich terug.
De samenstelling van de functionele procesteams kan gedurende de verschillende projectfases verschillen, afhankelijk van de omvang van de implementatie en de kenmerken van de organisatie. Bij het implementeren op een enkele locatie zal de samenstelling misschien weinig wisselen, bij roll-outs waar meerdere sites live gaan worden functionele procesteams soms opgesplitst om locatie specifieke teams te vormen. Ook kunnen, afhankelijk van de hoeveelheid werk, teamleden worden toegevoegd of worden bepaald dat zij niet meer nodig zijn. In de ontwerp en de realisatiefase komt het regelmatig voor dat er tijdelijke (sub)teams worden geformeerd om een specifiek onderwerp op te pakken. In dit soort gevallen is specifieke aandacht nodig om de (relatie met de) acceptatiecriteria te borgen, zeker als het tijdelijke teams betreft.

De technische teams zijn, in overleg met de functionele teams, verantwoordelijk voor het opstellen van de technische acceptatiecriteria voor hun werkzaamheden, ook voor die acceptatiecriteria die los staan van de functionele acceptatiecriteria, zoals de performance van het systeem. De functionele vereisten, business processen en acceptatiecriteria zijn de basis voor de realisatie van hun onderdelen.

De verdere werkzaamheden van technische team(s) omvatten het in overeenstemming met het ontwerp realiseren van; de standaard softwareconfiguratie, het maken van aanvullend maatwerk, datamigratie, interfaces, BI en rapporten, formulieren, infrastructuur, de voorbereidingen en technische uitvoering van de go-live en het uiteindelijk in beheer nemen. Zij werken nauw samen met de functionele procesteams. De technische teams leveren op aan deze functionele teams, die de oplossing functioneel accepteren.

Afhankelijke van de activiteiten per fase kunnen ook de technische teams wisselen van samenstelling: teamleden worden toegevoegd of er wordt bepaald dat zij niet meer nodig zijn.

Controlerende actoren

De klankbordgroep heeft in het acceptatieproces een ondersteunende en adviserende rol. Deze groep bestaat uit een aantal experts en is ondersteunend aan de functionele procesteams op het gebied van het opstellen van de functionele eisen, business processen en de acceptatiecriteria, maar ook de technische teams. Deze groep zou al vanaf aanvang van het project en in iedere fase actief moeten zijn, maar in ieder geval vanaf de ontwerpfase: in het begin mogelijk alleen voor raadpleging van mogelijke ontwerpvragen of issues, later voor het reviewen van de ontwerpen en het verder uitdragen van (nieuws over) de oplossing in de organisatie. Ook is het voor de uiteindelijke acceptatie van belang dat er over de afzonderlijke bedrijfsprocessen heen de samenhang tussen de processen geborgd wordt: hier speelt de klankbordgroep een rol en is het van belang goed naar de samenstelling van deze groep te kijken (zowel qua projectproces als qua inhoud).

Deze groep dient representatief te zijn, zowel qua processcope als qua organisatieonderdelen, en heeft uiteindelijk een adviserende (en misschien wel beslissende) rol over het accepteren van de oplossing naar de stuurgroep. Zij kan ook gevraagd en ongevraagd een audit uitvoeren en de uitkomsten voorleggen aan de stuurgroep. Afhankelijk van de fase kan de klankbordgroep worden aangepast.

De kwaliteitsfunctionarissen spelen een onafhankelijk controlerende/adviserende rol in het project. Dit is een verzamelnaam van actoren die de organisatie nodig heeft om te zorgen dat er wordt voldaan aan de wettelijke verplichtingen of eisen van toezichthouders, zoals SoX of financiële verantwoordingen. Zij hebben vaak een onafhankelijke positie en rapporteren meestal rechtstreeks aan de directie of raad van bestuur. In het accepteren van de oplossing hebben zij een belangrijke rol, ze kunnen het live gaan van een systeem tegenhouden als niet aan de criteria wordt voldaan.

Als projectmanager is het belangrijk aan het begin van je project te achterhalen welke kwaliteitsfunctionarissen de eindoplossing moeten beoordelen, betrekt deze functionarissen dan vanaf het begin bij je project en vraag ze proactief mee te denken. Vraag ze ook tussentijdse adviezen te geven, dit geeft ruimte om de eventuele bevindingen te verwerken. Uiteindelijk zullen zij over de eindoplossing een onafhankelijk advies geven aan de benodigde organisatie entiteiten, dit hoeft niet alleen de stuurgroep te zijn. Bij voorkeur worden de kwaliteitsfunctionarissen niet gewisseld tijdens het project.

Inrichten besturing voor afwijkingen en besluitvorming

Bovenstaande paragrafen beschrijven vooral de werkzaamheden van de actoren als de activiteiten en resultaten volgens plan verlopen. In ieder project zullen met zekerheid ook afwijkingen en geschillen voorkomen, bijvoorbeeld als de nieuwe processen niet aansluiten bij de gestelde requirements. Om in zo’n situatie zo weinig mogelijk tijd te verliezen en tot snelle besluiten te komen is het noodzakelijk om bij projectinitiatie binnen de gedefinieerde governance ook de rollen en processen bij escalatie te beschrijven. Zo kunnen functionele teams afwijkingen voorleggen aan de klankbordgroep voor inhoudelijke toetsing en neemt de stuurgroep een besluit, ook over de eventuele budgettaire impact.

Vraag die nog naar voren komt is hoe je de besluitvorming inricht: zo hoog of laag mogelijk, in zelforganiserende teams of sterk sturend vanuit projectmanagement? Het antwoord op deze vragen is erg afhankelijk van de organisatie waarin het project wordt uitgevoerd. Wij leggen de uitvoerende acceptatieactiviteiten en verantwoordelijk hierover graag zo laag mogelijk in de organisatie: dit draagt bij aan eigenaarschap over de nieuwe processen en het nemen van verantwoordelijkheid voor het opstellen hiervan, waardoor de acceptatie van de processen op de werkvloer wordt vergroot. De uiteindelijke besluitvorming voor de ingebruikname van het systeem wordt nog steeds door een zo hoog niveau in de organisatie genomen Dit om de risico’s van de besluiten bewuster te nemen, leiderschap te tonen, betrokkenheid van management te maximaliseren en verantwoordelijkheid te laten nemen.

Afsluiting

In dit artikel hebben wij ons beperkt tot het inrichten van de governance voor de acceptatie en dan met name over de betrokken actoren en hun rol. De rol van de projectmanager is om de actoren te coachen en faciliteren in het accepteren van de oplossing, zowel tussen als eindoplossing. Naast de inrichting van de projectgovernance is het acceptatieproces van belang, waarmee de actoren moeten werken. In het volgende en laatste artikel uit deze reeks zal dit aan de orde komen.

Blogdetails

23-04-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