De afgelopen tijd is er verschillende malen discussie ontstaan over mislukte erp-projecten. Voorlopig hoogtepunt zijn de recent gedane uitspraken van SAP Nederland-directeur Angelique de Vries die klanten verantwoordelijk houdt voor het mislukken van SAP-implementaties. Voor Jeroen Philippi, marketingmanager bij Unit 4 Agresso, reden om eens te kijken waarom erp-implementaties slagen of mislukken. Het codewoord hierbij is verandering.
De vraag lijkt zo oud als het bestaan van erp zelf: wat bepaalt of een implementatie slaagt of mislukt? Om de zoveel tijd laait de discussie weer op, meestal gevoed door nieuws over mislukte erp-projecten. Het vreemde is dat in deze discussies altijd een essentieel onderdeel buiten beschouwing blijft. Eén van de belangrijkste redenen van het wel of niet slagen van een erp-implementatie is of de koper rekening houdt met toekomstige veranderingen in de organisatie en de mogelijkheden om het pakket daaraan aan te passen.
Dat bleek ook onlangs weer, in de commotie die ontstond over de uitspraken van Angelique de Vries, directeur van SAP Nederland. In een interview met Computable zei ze dat klanten vaak zelf verantwoordelijk zijn voor het mislukken van SAP-implementaties. Daarna brandde de discussie los. Die concentreerde zich vooral op de schuldvraag van leverancier en klant en de professionaliteit van de implementatiepartner en consultants. Discussiëren over wie schuld heeft, is echter zinloos. Bij een project dat zo intensief en complex is, zijn er twee partijen nodig om tot een succes te komen. Organisaties hebben een weloverwogen besluit genomen, na waarschijnlijk een lang en intensief keuzeproces. 'It takes two to tango' en dat geldt zeker voor business-software.
Waar het eigenlijk om zou moeten gaan, is of de keuze voor een erp-pakket wel op basis van de juiste of afdoende argumenten wordt genomen. Het is een bekend fenomeen dat RFI's veel op elkaar lijken. Ze concentreren zich op de bekende vragen rondom functionaliteit, positie van de softwareleverancier, technologie, prijs en de condities. Deze veelgebruikte criteria zijn niet onbelangrijk, maar niet genoeg om een goede keuze op te baseren. Een essentieel onderdeel van een erp-implementatie ontbreekt hier namelijk en dat is de toekomstige verandering van een organisatie.
De globalisatie van de wereld, de beschikbaarheid van online informatie en de verkorting van levenscycli bieden een speelveld van continue veranderingen. Veranderingen waarop bedrijven willen anticiperen om een goede concurrentiepositie te behouden. Vreemd dat keuzeprocessen dan vooral uitgaan van een status quo; een niet veranderende omgeving. Je denkt goed na over hoe de wereld voor je organisatie er nu uitziet en beslist op basis daarvan voor de beste match. Vragen of overwegingen die vooral gaan over het makkelijk doorvoeren van veranderingen, de totale kosten van gebruik en verandering en de impact die de implementatie op de organisatie heeft worden niet tot nauwelijks gesteld. Jammer, want daar zit toch een heel groot deel van het blijvende succes van business-software voor de organisatie.
‘Klassieke' erp-applicaties zijn veelal ontstaan in productieomgevingen. Dit zijn complexe processen waar op voorhand goed over nagedacht wordt, waarna de automatisering er omheen gegoten wordt. Het primaire proces en de automatisering zijn daarmee voor een langere periode vastgesteld. De architectuur van dit soort applicaties is ook op deze filosofie gestoeld. Rijk aan functionaliteit, veel complexe inrichtingsmogelijkheden die op voorhand gemaakt moeten worden, maar als het eenmaal staat, is het zeer rigide en zal het beton moeilijk gaan meebewegen.
Deze erp-applicaties hebben met hun succes ook andere markten ontgonnen zoals de zakelijke en publieke dienstverlening en handel, echter komen ze met hun architectuur bij deze vaak bewegelijke organisaties in de knoop. Zo ontstaan er tijdens of na de implementatie fricties. De structuur en filosofie van het erp-pakket laten gewoon weinig snelle flexibiliteit toe, alle initiatieven van templates ten spijt.
Het is dus goed als organisaties die een keuze voor een nieuw pakket willen maken, zich ook afvragen hoe flexibel het erp-systeem na de implementatie nog is. Wat kost een update qua investering, maar ook in tijd voor de eigen organisatie? Hoe snel kan een update uitgerold worden en wat is de doorlooptijd? Met andere woorden: wat kost een verandering voor mijn organisatie en hoe snel kan dit plaatsvinden? In hoeverre sta ik als ondernemer zelf aan het roer?
Daarnaast is het verstandig dat een eindgebruiker zich op voorhand goed laat informeren over wat de implementatie aan tijd van de eigen organisatie gaat verlangen en of dit wel past bij de organisatie en ict-afdeling: kun je het wel verteren en is het na de implementatie door de organisatie nog wel te herkauwen? Kijk verder dan het opgegeven aantal implementatiedagen voor het initiële project.
Functioneel kunnen we allemaal de noot kraken. Het gaat vaak om de zachtere criteria die het verschil maken in succes of teleurstelling.
Jeroen Philippi, marketing manager Unit 4 Agresso
Volkomen juist, dat heet projectplanning.
De opmerking “it takes two to tango” is niet helemaal waar, de schoen wringt waar implementatoren overdreven verwachtingen wekken bij de klant en bij implementatoren die onvoldoende kennis van zaken hebben over organisaties waar ze het pakket neerzetten.
In dergelijke gevallen is de klant de dupe.
De titel is hoopgevender dan de essentie van het artikel. Het is inderdaad belangrijk dat de architectuur aansluit bij de verandering cq. dynamiek van de organisatie. Dit is zeker een van de factoren die het succes op lange termijn bepalen. In referentie tot eerdere discussies over het wel of niet slagen van ERP (of CRM) implementaties is dit echter niet de essentie.
In het artikel wordt gesteld dat een pakket op basis van de juiste argumenten gekozen moet worden. Hierbij zal dus naast functionaliteit, technologie, prijs en condities ook rekening gehouden moeten worden dat de architectuur voldoende flexibel is om toekomstige veranderingen te ondersteunen. Hoewel ik het hier volledig mee eens ben, is dit niet de oplossing voor de geschetste problemen.
Vanuit de visie en de organisatiedoelstellingen wordt de keuze gemaakt voor een ERP pakket dat een ontwikkeling in de juiste richting mogelijk maakt. Hiermee zal de implementatie direct de enabler van verandering worden. Dit betekent ook direct dat in het project de vertaalslag gemaakt moet worden van de veranderde processen (en soms structuur) naar de ondersteuning door de software. Dit moet volledig in lijn zijn met de strategie, cultuur en de gewenste managementstijl.
Projecten waarbij software (en implementatie) partners alleen functionaliteit opleveren en organisaties niet gechallenged worden op de betrokkenheid bij het project en de aansluiting bij de organisatiedoelstellingen lopen naar alle waarschijnlijkheid de mist in. In dit geval mag je al blij zijn als de performance van voor de implementatie wordt bereikt.
In deze dynamische wereld is flexibiliteit zeker belangrijk, maar zonder doel is het natuurlijk altijd moeilijk scoren. Ik geloof zeker dat Unit4Agresso een sterke propositie heeft op flexibiliteit. Nog steeds wordt de echte verandering niet geadresseerd. De Provincie NH en de FreeRecordShop zouden ook met deze flexibiliteit dezelfde problemen hebben gehad. Als de organisatie de vertaalslag van organisatiedoelstellingen niet kan maken en zich niet consistent verbindt aan de verandering die hier voor nodig is, maakt deze flexibiliteit het alleen nog maar complexer.
Een andere vraag is natuurlijk wat de verschillende spelers in dit soort projecten toe willen voegen. Het opleveren van een werkend systeem, ongeacht hoe flexibel, met prima werkende functionaliteit kan natuurlijk nooit het doel zijn. Opdrachtgevers (klanten) mogen verwachten dat ze experts binnenhalen die inderdaad niet overdreven verwachtingen creeren, maar verdomd goed snappen wat de opdrachtgever wil bereiken en wat de impact van de verandering is. Dit betekent ook dat beide partijen bereid moeten zijn de confrontatie aan te gaan.
Ramon Zanders, Perfect for People
Citaat: “Het opleveren van een werkend systeem, ongeacht hoe flexibel, met prima werkende functionaliteit kan natuurlijk nooit het doel zijn.”
Wat dan? Is dat niet wat de klant wil? Vreemde jongens, die ICT’ers, om met Obelix te spreken.
Gebruikers willen geen werkend, maar een werkbaar systeem. En daarbij moet de leiding van zo’n gebruikersorganisatie zich afvragen of hun organisatie wel standaard genoeg is. Mocht dat niet zo zijn, is het verstandig om die organisatie eerst standaard te maken.
Let daarbij op cultuurverschillen. Een pakket met Duitse discipline past vast prima bij het Ministerie van Defensie, maar waarschijnlijk niet zo goed op een een HRM-afdeling van een provincie of waterschap.
Bedrijven kopen in het algemeen een ERP pakket om geen maatwerk applicaties te hoeven bouwen. De consequentie van deze keuze is dat de standaard (meestal op Best-Practise gebaseerde) bedrijfsprocessen gebruikt moeten worden. Organisatie verandering is een belangrijk aspect bij een ERP implementatie. Als de organisatie niet veranderd zal je ERP implementatie nooit succesvol worden. Benader dit soort projecten niet vanuit een technisch oogpunt en zorg ervoor dat je in je project altijd een change manager of business architect hebt. Hij/zij kan de organisatie bij de hand nemen om te zorgen dat je ERP implementatie een succes wordt en dat er weinig maatwerk gebouwd hoeft te worden. Hiermee voorkom je, soms onnodig, hoge kosten bij het doorvoeren van patches en upgrades.
Twee elementen spelen een essenti�le rol:
1. Kies de juiste ERP software
2. Zorg voor betrokkenheid
Kies de juiste ERP software
Stop ERP in de organisatie in plaats van andersom! Maak van de klant een profit center en automatiseer niet alleen de bestaande processen. Kies voor gebruiksvriendelijke en flexibele software en accepteer de best practices in deze software. Selecteer een betrouwbare leverancier die support en implementatie zelf verzorgt.
Zorg voor betrokkenheid
Zet actief in op betrokken medewerkers. Zijn externen noodzakelijk? Laat ze de bestaande werkzaamheden overnemen. Eigen medewerkers dienen met de verandering bezig te zijn. Een kleine groep hoofdgebruikers is een groot gedeelte van hun tijd bezig met deze verandering, niet vice versa. Zorg voor een sterke rol van de CFO als sponsor van de verandering. Toon lef en maak keuzes om de gewenste verandering te forceren.
Een ERP implementatie heeft een grotere kans van slagen met de juiste mensen. Deze mensen moeten voldoende gemotiveerd zijn, de juiste plek en rol in het projectteam hebben en realistisch (dus niet binnen 4 ? 6 maanden zijn wij makkelijk life) en pragmatisch zijn. Verder moeten ze de mentaliteit hebben van ?niet lullen maar poetsen? of de Feijnoord slogan ?geen woorden maar daden? hoog in het vaandel hebben. De mensen in het projectteam moeten zich realiseren dat ze verantwoordelijk zijn voor het succes van de implementatie. Verder dient er een realistische projectplanning te zijn en die begint al bij de pakketselektie (deze dien je niet erdoor te ?jassen?). Een ERP implementatie is een veranderingstraject wat door mensen gedaan moet worden en geef ze daar ook de tijd voor.
Twee keer een beeldspraak over ERP:
1. ERP keuze is als boodschappen doen voor het avondeten. Je maakt een boodschappenlijstje (scope). Laat je bij het boodschappen doen niet afleiden door andere leuke en lekkere producten, waardoor je uiteindelijk veel meer geld uitgeeft en ook nog te laat thuis komt.
2. ERP implementatieproject is als rijden in een formule 1 auto. Ook al kan je autorijden (projecten doen), een formule 1 rijden vergt goede instructie en begeleiding. Zorg dat je het circuit goed kent (planning) en de kracht van de auto (functionaliteit) en zorg voor een goede pits crew (implementatie partner). Het ongeschonden halen van de finish is het doel. Nummer 1 worden het streven.
Alle opmerkingen van de andere experts zijn overigens ook waar.
De introductie van ERP-systemen zou gericht moeten zijn op stroomlijning, harmonisatie of zelfs standaardisatie van bedrijfsprocessen. Het slagen hiervan staat of valt met een configuratie die het proces volgt, een implementatie die conform specificaties is en een voldoende acceptatiegraad bij gebruikers. Een klassiek probleem in IT is de discrepantie tussen documentatie, implementatie en executie. Tussen ontwerp en realisatie ontstaan al snel interpretatieverschillen. De uitdaging ligt in het synchroon houden van deze werelden. Een eerste succesfactor is een procesgedreven ERP-implementatie. Bedrijfsprocessen zouden leidend moeten zijn, niet functionaliteiten. Een tweede succesfactor is een modelgedreven aanpak, waarbij de business zijn wensen en eisen tot uitdrukking brengt in procesmodellen in plaats van ongestructureerde documenten en de modellen overdraagt aan IT voor de technische inrichting van het ERP-systeem. Zo kan men telkens teruggrijpen op de keuzes die ten grondslag liggen aan de inrichting, ook bij veranderingen. Bovendien spreken business en IT dan een gemeenschappelijke taal.
De kop boven het artikel is verwarrend. Waar verwacht wordt dat er geschreven wordt over de veranderbereidheid van organisaties, volgt een verhandeling over de flexibiliteit en aanpasbaarheid van software aan toekomstige veranderingen (van processen) in organisaties. Een kritische succesfactor voor het slagen van een ERP implementatie is niet zozeer de flexibiliteit van de software, maar veel meer de bereidheid van de organisatie (de klant) om anders te gaan werken. Wie kiest voor een standaard ERP zal zich ervan bewust moeten zijn dat dit een andere manier van werken met zich mee brengt. Is de organisatie hier aan toe, of zijn de medewerkers verandermoe? En ja, natuurlijk is het belangrijk dat systemen flexibel genoeg zijn om mee te kunnen veranderen met een organisatie. Gelukkig wordt dat door SAP onderkent en goed opgepakt. Nu dat andere nog, de wil om te veranderen. Het vereist naast de nodige kennis en kunde een bepaalde attitude van alle betrokkenen om grootschalige ERP implementaties succesvol te laten verlopen. Een bekende spreuk is: Attitude is everything, so pick a good one!