Gedachten over de implementatie van bedrijfssoftware en projectmanagementmethodologieën.

Elk project dat een ERP-implementatie beheert, ongeacht de gebruikte methodologie of de benaming van de fasen, is doorgaans op dezelfde manier gestructureerd.

1. Projectinitiatie
2. Planning
3. Ontwerp
4. Ontwikkeling
5. Testen
6. Training en verandermanagement
7. Voorbereiding op de livegang
8. Go-Live
9. Ondersteuning na de implementatie
10. Projectafsluiting

En dat is al minstens 30 jaar zo. Toen bedrijven 'Agile' voor projecten begonnen te gebruiken (en ik weet dat ik hier een beetje de zaken kort door de bocht afsnijd), veranderde dat niet echt de manier waarop dingen gedaan werden; het betekende vaak alleen dat het (gedetailleerde ontwerp en) de ontwikkeling en het testen iteratieve cycli werden.

1. Initiatie en planning
2. Ontdekking en ontwerp
3. Iteratieve ontwikkeling en testen
4. Gebruikerstraining en verandermanagement
5. Voorbereiding op de livegang
6. Ingebruikname en stabilisatie
7. Continue verbetering

Toen het concept 'continue verbetering' werd geïntroduceerd, hadden maar weinig organisaties een idee hoe dit in hun organisatie kon worden ingebed, vooral niet wanneer het implementatieteam werd ontbonden.

De structuur die wordt gebruikt om een ​​ERP-project te organiseren zoals beschreven in de inleiding, is gebaseerd op het juiste inzicht dat een softwareplatform een ​​organisatie ondersteunt (of zou moeten ondersteunen): de strategische doelen en doelstellingen van de organisatie, de organisatiestructuur, de geografische spreiding, de afdelingen, de bedrijfsprocessen, de KPI's en alle behoeften van de medewerkers met betrekking tot efficiënt en effectief werken. Dit betekent dat het project begint met een analyse van de organisatie, hoe deze momenteel functioneert, hoe deze is georganiseerd en wat de (strategische) behoeften en doelstellingen zijn. Deze analyse richt zich op de bedrijfsbehoeften, procesbehoeften en de bedrijfsdoelen en -doelstellingen. In mindere mate richt de analyse zich op de IT-behoeften: het zijn de bedrijfsdoelen en -behoeften die (zouden moeten) bepalend zijn voor de IT-behoeften. Uitzonderingen hierop zijn migratie- en applicatie-integratiebehoeften; in dit geval komt de vraag vanuit de technologie zelf.

Kort gezegd bestaat de methodologie die bij ERP-projecten wordt gebruikt uit het analyseren van de vereisten en het ontwerpen van de voorgestelde organisatie, de (aangepaste en nieuwe) processen en applicaties, het bouwen van het applicatieplatform op basis van het ontwerp en het trainen en testen van de nieuwe processen en tools. De laatste stap is de implementatie en ondersteuning van de organisatie, en het oplossen van alle problemen die de organisatie in de eerste dagen, weken of maanden na de implementatie ondervindt.

De vraag is hoe succesvol en effectief de implementatiemethoden op basis van bovenstaande principes werkelijk zijn. Veel ERP-projecten mislukken tegenwoordig, of worden op zijn minst als minder succesvol beschouwd. Wat tegenwoordig als een succesvol project wordt gezien, is een project dat minstens dezelfde functionaliteit biedt als het oude (vervangen) systeem, en het wordt als een overwinning beschouwd dat de technologie is bijgewerkt naar de huidige standaarden.

En dat is vreemd, als het project als een succes wordt beschouwd terwijl het 'enige' pluspunt eigenlijk de nieuwe technologie is en de organisatie – qua cultuur, processen, ondersteuning van doelen en doelstellingen – er nauwelijks of helemaal niets mee heeft gewonnen. De vraag is: waarom blijven we dan vasthouden aan deze methodologie?

De uitdagingen van de huidige ERP-implementaties kunnen het best als volgt worden samengevat:

1. De organisatie is teleurgesteld over de resultaten
2. Het project duurt langer dan verwacht
3. Het project kost meer dan begroot
4. Er is sprake van frustratie tussen de implementatiepartner en de klant

Als we die frustraties proberen te koppelen aan de manier waarop het implementatieproject is georganiseerd of de gebruikte methodologie, kunnen we stellen dat de volgende gebieden de belangrijkste oorzaken zijn van zogenaamde ERP-implementatiefalen:

1. Projectmanagement en -governance: scope creep, problemen met resourceallocatie en -beschikbaarheid, en natuurlijk het onvermogen van de projectmanager om het project te organiseren vanwege een gebrek aan ondersteuning of omdat de methodologie niet binnen de organisatie is geïmplementeerd en de organisatie/leiding de methodologie niet begrijpt.
2. Veranderingsmanagement en gebruikerstraining: Werknemers verzetten zich tegen veranderingen vanwege onbekendheid met de nieuwe situatie, angst voor baanverlies of een gebrek aan adequate training en communicatie. De hoeveelheid en diepgang van de training die nodig is om gebruikers te laten begrijpen waar het project over gaat, wordt vaak onderschat. Natuurlijk is de training in het gebruik van het nieuwe systeem en de nieuwe processen later in het project vaak ontoereikend en inefficiënt.
3. Culturele en organisatorische impact: Het feit dat afdelingen en stakeholders geen gemeenschappelijk doel of visie delen, is een veelvoorkomend probleem bij veel projecten. Bovendien sluit het project niet aan bij de strategische doelen van het bedrijf en is het management niet bereid het belang van het project op dit gebied te erkennen (wat leidt tot een dramatisch gebrek aan steun), wat een belangrijke factor is voor mislukking en frustratie. Verder is er het probleem van verandermanagement: de cultuurverandering die nodig is om zich aan te passen aan nieuwe processen en tools wordt eveneens onderschat of zelfs genegeerd, wat wederom aanleiding geeft tot teleurstelling en frustratie. Twee andere belangrijke aandachtspunten zijn communicatie en flexibiliteit. Het management beseft de druk van het project (de verandering) op de organisatie pas te laat, wat leidt tot paniek en een verminderde bereidheid tot flexibiliteit, creativiteit en aanpassingsvermogen. We zien ook dat hoe complexer de situatie wordt, hoe meer de communicatie met de organisatie afneemt en zelfs vergeten wordt.
4. Procesherontwerp: Zoals eerder in dit artikel is benadrukt, is het grondig begrijpen en documenteren van de huidige processen vóór het ontwerpen van nieuwe processen of de overstap naar het nieuwe ERP-systeem veel complexer en tijdrovender dan verwacht of dan organisaties bereid zijn te accepteren (en te investeren). Het afstemmen van de gewenste bedrijfsprocessen op de standaardprocessen van het ERP-systeem zonder ingrijpende aanpassingen kan een uitdaging zijn en kan het projectteam frustreren of demotiveren.

Zijn dit de enige redenen voor frustratie en projectproblemen? Het is opvallend dat datamigratie vaak wordt genoemd als een uitdaging voor het project. Maar hoewel het in sommige projecten vertragingen en extra kosten met zich meebrengt, is datamigratie vrijwel nooit de reden voor teleurstelling of ontevredenheid over wat het project de organisatie heeft opgeleverd (de ervaren waarde). Ook moeilijkheden met de ontwikkeling van maatwerkoplossingen en integraties kunnen, of zullen vrijwel zeker, extra tijd en kosten met zich meebrengen. Maar dit is nooit de reden dat mensen na de livegang het gevoel hebben dat niet alles wat gewenst of vereist was, is geleverd. Ik zou zelfs durven beweren dat het tegendeel waar is: de enige zaken die echt gemeten en gecontroleerd worden, zijn de softwareleveringen. De applicatiefunctionaliteit, migratie, maatwerkoplossingen, integraties, rapportages enzovoort zijn in principe de 'makkelijke dingen' om te beheren.

En wanneer uit projectevaluaties blijkt dat testen of ondersteuning na de implementatie uitdagingen opleveren, zou ik zeggen dat dit eerder te maken heeft met slecht projectmanagement en/of de motivatie van de organisatie om de juiste (hoeveelheid) mensen in te zetten en het belang en de impact van het project te erkennen, zoals eerder vermeld.

Ik ben ervan overtuigd dat de hierboven genoemde redenen de oorzaak zijn van het mislukken van projecten en dat we onze methodologie moeten herzien en moeten nadenken over de middelen en vaardigheden die we nodig hebben om een ​​ERP-project succesvol te beheren en uit te voeren.

Het is belangrijk te vermelden dat een agile of alternatieve projectimplementatiemethodologie een grotere kans op succes heeft dan de watervalmethode, vanwege de flexibiliteit en aanpasbaarheid, de betrokkenheid van gebruikers, risicobeperking en verbeterde communicatie.

Het is ook belangrijk te vermelden dat ik geloof dat na een aanvankelijk lastig project voor de implementatie van een ERP-systeem, projecten voor continue verbetering een veel grotere kans van slagen hebben en dat organisaties veel meer waarde uit die projecten zullen halen. Dit geldt natuurlijk alleen als die organisaties dergelijke projecten blijven toestaan ​​en 'bereidheid tot verandering' tot een kernwaarde van de organisatie maken. In dit verband moet worden opgemerkt dat cloudsystemen het voordeel hebben dat ze het beste instrument zijn voor continue verbetering.

Ik zie dit document graag als een discussiestuk en het begin van een discussie binnen p2-i en tussen partners en klanten, om ons te helpen onze eigen organisatie en onze dienstverlening te verbeteren, met als doel:

1. Bepaal de juiste methodologie
2. Zorg dat onze projectmanagementfunctie goed georganiseerd is
3. Neem de mensen in dienst die we nodig hebben om de methodologie uit te voeren
4. Train en blijf onze mensen continu trainen om succesvol te zijn in onze methodologie
5. Train en organiseer het verkoopteam zodat zij onze projecten kunnen verkopen
6. Projecten succesvol opleveren

Ik hoor graag jullie reacties en meningen!

Geschreven door Amit Kumar 

9 december 2024