Gedachten over de implementatie van bedrijfssoftware en projectmanagementmethodologieën.

Elk project voor het beheren van een ERP-implementatie, ongeacht de gebruikte methodologie of hoe de fasen zijn gelabeld, is op dezelfde typische manier gestructureerd.

1. Projectinitiatie
2. Planning
3. Ontwerp
4. Ontwikkeling
5. Testen
6. Training en Verandermanagement
7. Voorbereiding op livegang
8. Livegang
9. Ondersteuning na livegang
10. Projectafsluiting

En dat is al minstens 30 jaar zo. Toen bedrijven 'Agile' gingen gebruiken voor projecten (en ik weet dat ik hier een omweg maak), veranderde dat niet echt de manier waarop dingen gedaan worden; 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. Gebruikersopleiding en verandermanagement
5. Voorbereiding op livegang
6. Go-Live en stabilisatie
7. Continue verbetering

Bovendien hadden weinig organisaties een idee hoe ze het concept 'continue verbetering' konden implementeren in hun organisatie, zeker niet wanneer het implementatieprojectteam werd opgeheven.

De structuur die gebruikt wordt om een ​​ERP-project te organiseren op de manier zoals beschreven in de inleiding, komt voort uit het juiste inzicht dat een softwareapplicatieplatform een ​​organisatie ondersteunt (of zou moeten ondersteunen): de strategische doelen en doelstellingen van de organisatie, de organisatiestructuur, de geografische voetafdruk, de afdelingen, de bedrijfsprocessen, de KPI's en alle eisen van de medewerkers met betrekking tot efficiënt en effectief werken. Dit betekent dat het project begint met een analyse van de business, hoe deze vandaag de dag functioneert, hoe deze georganiseerd is en wat de (strategische) eisen en doelstellingen zijn. Deze analyse richt zich op de businessvereisten, procesvereisten en de bedrijfsdoelen en -doelstellingen. In mindere mate richt de analyse zich op de eisen aan de informatietechnologie: het zijn de businessdoelen en -vereisten die de eisen aan de informatietechnologie (zouden moeten) sturen. Uitzonderingen hierop zijn eisen voor migratie en applicatie-integratie; hier komt de vraag voort uit de technologie zelf.

Kortom, de methodologie die tijdens ERP-projecten wordt gebruikt, is het analyseren van de vereisten en het ontwerpen van de voorgestelde organisatie, de (gewijzigde 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 het live gaan en ondersteunen van de organisatie en het oplossen van alle problemen die de organisatie in de eerste dagen, weken of maanden na de livegang tegenkomt.

De vraag is hoe succesvol en effectief de implementatiemethodologieën gebaseerd op bovenstaande principes werkelijk zijn. Veel ERP-projecten mislukken tegenwoordig of worden in ieder geval als minder succesvol beschouwd. Wat tegenwoordig als een succesvol project wordt beschouwd, is een project dat ten minste dezelfde functionaliteit biedt als het oude (vervangen) systeem, en het wordt als een overwinning beschouwd dat de technologie is geüpdatet naar de huidige standaarden.

En dat is vreemd, als het project als een succes wordt beschouwd, terwijl de 'enige' plus eigenlijk de nieuwe technologie is en de organisatie qua cultuur, processen en ondersteuning van doelen en doelstellingen er nauwelijks iets aan heeft gewonnen. De vraag is: waarom houden we dan nog steeds vast aan de methodologie?

De uitdagingen van hedendaagse ERP-implementaties kunnen het beste 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 frustratie tussen de implementatiepartner en de klant

Wanneer we proberen deze frustraties in kaart te brengen met betrekking tot de manier waarop het implementatieproject is georganiseerd of de gebruikte methodologie, kunnen we stellen dat de volgende gebieden de belangrijkste redenen zijn voor zogenaamde ERP-implementatiefalen:

1. Projectmanagement en governance: scope creep, problemen met de toewijzing en beschikbaarheid van middelen en natuurlijk het onvermogen van de projectmanager om het project te organiseren vanwege een gebrek aan ondersteuning of omdat de methodologie niet is geïmplementeerd in de organisatie en de organisatie/leiding de methodologie niet begrijpt.
2. Verandermanagement en gebruikerstraining: Medewerkers verzetten zich tegen veranderingen vanwege onbekendheid, angst voor baanverlies, of vanwege een gebrek aan adequate training en communicatie. De hoeveelheid en diepgang van de training die nodig is om gebruikers effectief te laten begrijpen waar het project over gaat, wordt vaak onderschat. Later in het project is de training in het gebruik van het nieuwe systeem en de nieuwe processen uiteraard te beperkt en inefficiënt.
3. Culturele en organisatorische impact: Afdelingen en stakeholders die geen gemeenschappelijk doel en/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 (en dus een dramatisch gebrek aan ondersteuning), wat een belangrijke factor is voor mislukking en frustratie. En verder over verandermanagement: de cultuuromslag die nodig is om zich aan te passen aan nieuwe processen en tools wordt eveneens onderschat of zelfs genegeerd, wat wederom reden geeft tot teleurstelling en frustratie. Twee andere belangrijke aandachtspunten: communicatie en flexibiliteit. Het management beseft pas te laat de druk die het project (de verandering) op de organisatie legt en veroorzaakt een paniekaanval waardoor de bereidheid om flexibel, creatief en open te staan ​​voor aanpassing aan het project afneemt. We merken ook dat hoe moeilijker het wordt, hoe meer de communicatie met de organisatie afneemt en wordt vergeten.
4. Procesre-engineering: Zoals eerder in dit artikel werd benadrukt, is het grondig begrijpen en documenteren van huidige processen vóór het ontwerpen van nieuwe processen of de overstap naar het nieuwe ERP-systeem veel complexer en tijdrovender dan verwacht of wat organisaties bereid zijn te accepteren (en waarin ze investeren). Het afstemmen van de gewenste bedrijfsprocessen op de standaardprocessen van het ERP-systeem zonder uitgebreide maatwerkoplossingen kan een uitdaging zijn en het projectteam frustreren of demotiveren.

Zijn dit de enige redenen voor frustratie en projectproblemen? Het is de moeite waard om op te merken dat datamigratie vaak wordt genoemd als een uitdaging voor het project. Maar hoewel het in sommige projecten vertraging en extra kosten met zich meebrengt, is datamigratie bijna nooit de reden voor teleurstelling of ontevredenheid over wat het project de organisatie heeft opgeleverd (de ervaren waarde). Ook kunnen problemen met de ontwikkeling van maatwerk en integraties extra tijd en kosten veroorzaken, of bijna veroorzaken. 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 willen stellen dat het tegenovergestelde het geval is: het enige wat echt gemeten en gecontroleerd wordt, is de softwarelevering. De functionaliteit van de applicatie, migratie, maatwerk, integraties, rapportages, enzovoort, zijn in principe de 'makkelijke dingen' om te beheren.

En als uit projectevaluaties blijkt dat testen of ondersteuning na implementatie uitdagingen zijn, zou ik zeggen dat dit meer 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 van mening dat de hierboven genoemde redenen ook de redenen zijn waarom projecten mislukken. Ze vereisen dat we opnieuw nadenken over de methodologie die we gebruiken en over de middelen en vaardigheden die we nodig hebben om een ​​ERP-project succesvol te beheren en uit te voeren.

Het is belangrijk om te vermelden dat een agile of alternatieve projectimplementatiemethodologie een grotere kans van slagen heeft dan de watervalbenadering, vanwege de flexibiliteit en aanpasbaarheid, gebruikersbetrokkenheid, risicobeperking en verbeterde communicatie.

Het is ook belangrijk om te vermelden dat ik geloof dat continue verbeterprojecten na een lastig initieel project om een ​​ERP-systeem te implementeren, een veel grotere kans van slagen hebben en organisaties veel meer waarde uit die projecten zullen halen, uiteraard alleen als die organisaties die projecten nog steeds toestaan ​​en 'appetijt voor verandering' tot een kernwaarde van de organisatie maken. In dit verband moet gezegd worden dat cloudsystemen het voordeel hebben dat ze de beste tool zijn voor continue verbetering.

Ik zou dit document graag zien 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 om:

1. De juiste methodologie vaststellen
2. Laat onze PM-functie organiseren
3. Huur de mensen in die we nodig hebben om volgens de methodologie uit te voeren
4. Train en blijf onze mensen continu trainen om succesvol te zijn in onze methodologie
5. Train en organiseer de verkoopafdeling om onze projecten te kunnen verkopen
6. Projecten succesvol opleveren

Ik hoor graag uw opmerkingen en meningen!

Geschreven door Amit Kumar

9 december 2024