Waarom gaat de ERP installatie vaak mis?

Hoewel hierover veel geschreven is, is volgens Herb Krasner (2000) het grootste probleem dat de projecten veelal te groot en complex opgezet zijn. Hierdoor is het vaak onduidelijk of men bezig is met implementatie van software of het herinrichten van het bedrijfsproces. Terwijl volgens Krasner de meeste studies indertijd waren gericht op managementproblemen (denk aan o.a. beperkte integratie van de planning, slechte communicatie tussen mensen, een gebrek aan een formeel besluitsprocedure, een gebrek aan goede testcriteria en het negeren van eerder geleerde lessen uit eerdere implementaties) is het de vraag hoe deze management problemen voorkomen konden. Voor de hand liggende oplossingen zijn focus, teamwork, heldere scope, duidelijke business case, goede planning van training & support, waar mogelijk bestaande software slim aan te passen, een goede architectuur, doordacht projectmanagement, effectieve communicatie van verwachtingen en een betrokken hoger management. Maar volgens Krasner wordt er te weinig gesproken over een functioneel plan voor de techniek die het uiteindelijk mogelijk moet maken.

Babain, Lucas & Topi (2006) herinneren ons aan het belang van gebruiksvriendelijkheid. Al in 2003 deed Forrester een evaluatie van diverse grote ERP partijen (waaronder SAP, PeopleSoft, Oracle, JD Edwards, Microsoft and Lawson) en concludeerde dat een niet intuïtieve interface leidt tot een verlaagde productiviteit en daarmee dus hogere kosten voor bedrijven die deze gebruiken.

Een mogelijke verbetering in het uitrollen van een ERP systeem is door Participatory Design. Dit is iets dat Xavier Thavapragasam uitdiepte. Hij keek hierbij zowel gekeken naar meer user-centered design als Joint Application Development/design (JAD). Bij JAD wordt echter vooral gekeken naar functionele eisen, in tegenstelling tot de sociale. UCD legt continue de focus op de gebruiker die een gebruiksvriendelijk eindproduct dient te krijgen, met als gevolg een grotere tevredenheid over de gebruiksvriendelijkheid.

Maar, hoewel gebruiksvriendelijkheid een belangrijke factor speelt bij de acceptatie van een ERP systeem, is dat niet het enige. Zo speelt volgens Judy Scott (2008), naast ervaren gebruiksvriendelijkheid, ook de waargenomen nuttigheid een belangrijke rol. Deze ervaren nuttigheid heeft een belangrijke invloed op hoe de gebruiksvriendelijkheid ervaren wordt (meest eenvoudige voorbeeld: een magische rode knop is misschien wel heel gebruiksvriendelijk, maar als die het niet doet schiet niemand er iets mee op). Daarnaast is het belangrijk om rekening te houden met de “technological self-efficacy” van de gebruikers, de mate waarin iemand het idee heeft dat hij of zij een taak technisch kan doorlopen. Een gebruiker zal, afhankelijk van zijn of haar vertrouwen in kunnen en gemak van de applicatie zelf, meer of minder moeite steken in het voltooien van een taak middels het ERP als het veel waarde oplevert (of op lijkt te leveren).

Een suggestie die Babain, Lucas & Topi (2006) doen is om veel meer uit te gaan van de samenwerkingstheorie. In plaats van wat ze noemen een master-slave model, waarbij de gebruiker computer opdrachten geeft, naar een situatie waarin het systeem samenwerking faciliteert. Hierbij kun je letten op de mate waarin de gebruikers mee doen aan het proces (“Commitment to the Joint Activity”), het aanpassingsvermogen dat gebruikers tonen teneinde de samenwerking tot een succes te maken (“mutual responsiveness”), de mate waarin gebruikers elkaar ondersteunen (“mutual support”) en de mogelijkheid waartoe een complexere taak onder te verdelen is in subtaken (“meshing subplans”).

Hoewel ERP systemen vaak processen ondersteunen die te complex zijn om volledig te overzien of te managen zijn door een enkele gebruiker, draagt inzicht in de implicaties van het ingevoerde wel bij aan een beter begrip. Gesuggereerd wordt dat dat leidt tot een verbeterde samenwerking en dus efficienter gebruik van het systeem door de gehele “enterprise”.

Op de hoogte blijven?

Maandelijks maak ik een selectie artikelen en zorg ik voor wat extra context bij de meer technische stukken. Schrijf je hieronder in:

Mailfrequentie = 1x per maand. Je privacy wordt serieus genomen: de mailinglijst bestaat alleen op onze servers.