Waarom is een ERP implementatie zo moeilijk?

Deel 2

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.

#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.
 

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 globalere beschrijving zijn van de kritische acties, maar er wordt dan niet aangegeven hoe deze exact worden uitgevoerd.


Maak voor ieder proces meerdere scenario’s welke 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 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 waterval methode 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 startup 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 Aanpassen van de standaard software

Een groot deel van de implementatie zit in het aanpassen van de standaard software, 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 garant voor problemen. Ik ben het daar niet mee eens. Maatwerk is een kans om je software perfect te maken. De eerste afweging welke 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 a 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 software ontwikkeling. 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 welke de leverancier al heeft gemaakt en geleverd. 

En om toekomstige compatibiliteit te borgen kan 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.
Tips of opmerkingen? Ik hoor ze graag.


Waarom is ERP Implementatie zo moeilijk

17 TIPS OM WEL SUCCESVOL TE ZIJN!

ik wil je graag mijn 17 tips aan je geven, welke zeker gaan bijdragen aan het succesvol in gebruik nemen van jouw nieuwe ERP systeem.


Klik op de knop "Download Gratis". Je hoeft alleen je naam en e-mail adres in te vullen.

Je gegevens zijn veilig. Wij hebben net zo'n hekel aan spam als jij :)

Start je Gratis proefperiode

Wil je Odoo gratis proberen?

Klik op de knop "Ja, dat wil ik wel", je hoeft alleen je naam en e-mail adres in te vullen en je ontvangt van ons direct een mail met een link naar de probeerversie van Odoo.

Schrijf een reactie

U moet zijn ingelogd om een reactie te plaatsen.