Waarom is ERP-implementatie zo moeilijk?
Waarom is een ERP-implementatie zo moeilijk? Ik lees en hoor het, maar al te vaak en afgaande op de reacties op het eerste deel van dit blog, is het een ‘hot topic’. In dit eerste blog heb ik 5 tips gegeven. Heb je ze nog niet gelezen, lees deze dan eerst. In dit vervolg ga ik verder in op wat er komt kijken bij een ERP-implementatie en help ik je met tips 6 t/m 10.
Het eerste deel nog niet gelezen? Waarom is een ERP-implementatie zo moeilijk?
6. Zorg voor een goed projectteam
In het eerste deel van dit artikel is duidelijk geworden dat succes start bij een goede voorbereiding. De voorbereiding is al een project op zich. Maar de voorbereiding kan nog zo goed zijn gegaan, het succes valt en staat met goed projectteam en goed projectmanagement. Een goed team en de juiste projectmanager zijn goud waard, zij zullen het project moeten maken. Zorg ervoor dat iedere discipline van het bedrijf is vertegenwoordigd in het projectteam.
Geweldige verhalen hebben een persoonlijkheid. Overweeg om een geweldig verhaal te vertellen dat persoonlijkheid geeft. Het schrijven van een verhaal met persoonlijkheid voor potentiële klanten helpt bij het maken van een relatie. Dit komt tot uiting in kleine eigenaardigheden zoals woordkeuzes of zinsdelen. Schrijf vanuit jouw standpunt, niet vanuit de ervaring van iemand anders.
Geweldige verhalen zijn voor iedereen, zelfs als ze, maar voor één persoon zijn geschreven. Als je probeert te schrijven met een breed, algemeen publiek in gedachten, zal je verhaal nep klinken en emotie missen. Niemand zal geïnteresseerd zijn. Schrijf voor één persoon. Als het echt is voor de ene, is het echt voor de rest.
En ik kan het niet vaak genoeg zeggen. Het implementeren van een ERP-systeem is een project. Dus zorg ervoor dat de geselecteerd mensen voor het project hiervoor (gedeeltelijk) vrij gemaakt worden. Een ERP-implementatie doe je er niet even bij. Wil je succesvol zijn, dan zullen de mensen hiervoor echt voldoende tijd moeten krijgen van het hoger management.
7. Gebruik scenario's
Zodra het projectteam is geformeerd, start met het maken van gebruik scenario’s. Een gebruiksscenario of scenario, in het kort, beschrijft een werkelijk voorbeeld van hoe één of meer mensen of organisaties echt werken met het systeem. Ze beschrijven de stappen, gebeurtenissen en/of acties die optreden tijdens het gebruik van het systeem. Gebruiksscenario's kunnen zeer gedetailleerd zijn en precies beschrijven hoe iemand werkt met de user interface (de schermen, knoppen, rapportages e.d.). Maar het kan ook meer een globaler beschrijving zijn van de kritische acties, maar er wordt dan niet aangegeven hoe deze exact worden uitgevoerd.
Maak voor ieder proces meerdere scenario’s die goed de huidige werkwijze beschrijven. Indien al duidelijk is dat een bepaalde werkwijze moet worden aangepast, is het zinvol om de gewenste werkwijze te beschrijven. Deze kun je gebruiken bij de pakketselectie. Leveranciers van de software kun je vragen om deze casus te demonstreren in hun ERP-systeem.
De scenario’s zijn niet alleen een goed hulpmiddel bij de pakketselectie, maar ze dienen verder in het traject ook voor het opzetten van test scenario’s.
8. Kies een projectmethodiek
Er zijn verschillende methoden om een project aan te pakken. Er is denk ik geen goede of slechte projectmethodiek, maar het hangt af van de organisatie en organisatiegrootte en de te verwachte complexiteit van het project, welke methodiek het beste geschikt is. In uiterste spreekt men van waterval gebaseerde methodes en Agile projectmethodes. Bij een watervalmethode wordt het project gefaseerd en worden de projectfases heel formeel en gestructureerd beschreven en overgedragen. Hierbij gaat men ervan uit dat bij de start van het project exact helder is wat er gemaakt moet worden. Wijzigingen onderweg zijn mogelijk, maar kostbaar.
Mijn voorkeur heeft een Agile-projectaanpak. Bij een Agile projectmethode is vooraf niet geheel duidelijk wat gemaakt moet worden. Het project doorloopt een meer evolutionair proces. Het project wordt opgedeeld in korte werkdelen (iteraties of sprints genoemd). Na iedere sprint wordt een deel opgeleverd, beoordeeld en op indien mogelijk, zelfs in bedrijf genomen. Omdat iedere sprint wordt opgeleverd aan de eindgebruiker ontstaat een betere samenwerking en heb je eerder feedback. Deze feedback wordt direct verwerkt in een opvolgende sprint.
Het nadeel van Agile is wel de snelheid waarin wordt gewerkt. Sprints volgen elkaar snel op en er moeten (zeer) snel beslissingen worden genomen. Al ben ik van mening dat een verkeerde beslissing vaak beter is dan geen beslissing. In de start-up fase is het dan ook belangrijk om te kijken naar de beschikbaarheid van het projectteam en hoe lang een sprint moet duren. En werk niet allen met sprints maar ook met ‘milestones’. Bijvoorbeeld naar sprint 3. Na deze milestone adviseer ik vaak een rustmoment en 1 sprint over te slaan. Het geeft iedereen de mogelijkheid om het geproduceerde nog eens goed te evalueren. Voorkom dat de kwaliteit ondersneeuwt door een te snelle opvolging van sprints.
9. Het aanpassen van het ERP-systeem
Een groot deel van de implementatie zit in het aanpassen van de standaardsoftware, zodat deze geschikt wordt gemaakt voor het doel. Er wordt geen functionaliteit toegevoegd, maar bestaande functionaliteit wordt aangepast. Denk hierbij aan schermen, workflows en rapportages. Het is mogelijk dat deze aanpassingen gedaan worden via de interface van de software. Aanpassingen worden dan opgeslagen in de database van het systeem. Als de software het via de interface toelaat, is het verleidelijk om ook velden toe te voegen aan de database en deze in de schermen op te nemen.
Mijn mening is dat je dat je deze aanpassingen via de interface zoveel mogelijk moet vermijden. Deze aanpassingen kun je beter vastleggen in software code en door het systeem laten uitvoeren. Door het vastleggen van alle aanpassingen in code is te allen tijde duidelijk gedocumenteerd wat is aangepast (en je kunt natuurlijk ook documenteren waarom). Ook voor toekomstige updates kun je deze code (automatisch) testen tegen de nieuwe versie.
Aanpassingen via de interface, zijn vaak sneller gemaakt en dat is ook het gevaar. Een scherm aanpassen hier en een extra veld daar. Niemand weet naderhand meer dat deze aanpassingen zijn gemaakt en iedereen denkt dat het standaard is. In code geschreven aanpassingen zijn in ieder geval geborgd.
10. Maatwerk software
Maatwerk software. Voor vele is het een afschrikkend woord en staat het voor problemen. Ik ben het daar niet mee eens. Maatwerk is een kans om je software perfect te maken. De eerste afweging die je moet maken is of het maatwerk een werkelijk toegevoegde waarde heeft. De benadering is niet kijken hoeveel het kost om het maatwerk te maken, maar eerst te berekenen wat het kost als je het maatwerk niet laat maken en gaat werken op de standaard manier. Weet je wat het je per jaar kost om niets te doen, dan weet je ook wat het maatwerk mag kosten (ga hierbij uit van een 7 à 8 jaar dat je met de software werkt).
Bedenk wel dat niet ieder ERP-systeem geschikt is voor maatwerk. Dus heb je maatwerk nodig, selecteer een pakket en een leverancier met een track record op het gebied van softwareontwikkeling. Het hoeft niet moeilijk te zijn, maar je moet wel de nodige ervaring hebben met het gebruikte ‘framework’ van het ERP-systeem en het ontwikkelen van software zelf. Dus vraag naar voorbeelden die de leverancier al heeft gemaakt en geleverd.
En om toekomstige compatibiliteit te borgen kun je afspraken maken met je leverancier. Je kunt bijvoorbeeld een onderhoudscontract afsluiten welke garantie geeft op migratie van de software naar toekomstige versies.
Succes zit in de voorbereiding en ik heb nu 10 punten met je gedeeld welke je een grotere kans geven op een succesvolle ERP-implementatie. Maar we zitten nog steeds in de voorbereiding. We moeten nog steeds een pakket uitkiezen en deze implementeren. Volg ons en we informeren je wanneer het vervolg blog er is.
Waarom is een ERP-implementatie zo moeilijk? - Deel 2