Een ERP-project stap voor stap: van afbakening tot doorontwikkeling

Een ERP-project is geen softwareaankoop, maar een bedrijfsverandering met software als hulpmiddel. Wie een ERP-project goed wil laten verlopen, moet de stappen kennen vóór de eerste offerte binnenkomt. Deze gids beschrijft de stappen van een ERP-implementatie, de mise en place van een ERP-systeem in uw organisatie, van de eerste afbakening tot de doorontwikkeling na de ingebruikname. Per stap leest u het doel, de opleveringen en de valkuilen.

De volgorde is een raamwerk, geen dwangbuis. Bij een kleinere onderneming vallen sommige stappen samen; bij een groep met meerdere entiteiten worden ze herhaald per land of per vestiging. De logica blijft gelijk: eerst begrijpen wat u nodig hebt, dan kiezen, dan inrichten, dan bewijzen dat het werkt, en pas daarna overschakelen.

Het ERP-project in één overzicht

De tabel hieronder vat de negen stappen samen. De secties daarna werken elke stap uit.

Stap één: afbakening van het ERP-project

Doel. Vaststellen waarom u een ERP-systeem wilt en wat het project wel en niet omvat. Zonder dit fundament wordt elke latere keuze een discussie.

Begin bij het probleem, niet bij het pakket. Gaan de maandafsluitingen te traag? Mist u zicht op voorraad en marge? Vragen klanten om elektronische facturen? Is het huidige pakket niet meer te onderhouden? Noteer de pijnpunten en koppel ze aan meetbare doelen, in uw eigen cijfers en niet in de cijfers van een leverancier.

Opleveringen

• een projectkader met doelen, scope, afhankelijkheden en randvoorwaarden;
• een opdrachtgever uit de directie en een projectleider aan uw kant;
• een eerste inschatting van kosten en baten, zonder valse precisie;
• een beschrijving van de huidige systeemlandschap en de belangrijkste koppelingen.

Valkuilen

• Een project dat uitsluitend door IT wordt getrokken. ERP raakt financiën, inkoop, verkoop en productie of dienstverlening; dan moeten die afdelingen mee beslissen.
• Een scope die tijdens het project blijft groeien. Leg vast wat in de eerste fase hoort en wat naar een latere fase gaat.
• Geen aandacht voor de organisatie. Wie niet bepaalt welke mensen tijd krijgen voor het project, krijgt vertraging.

Voor het kostenplaatje is de gids over ERP-kosten een goed vertrekpunt. Is uw organisatie klein, lees dan ook ERP voor het mkb.

Stap twee: selectie van pakket en integrator

Doel. Een pakket en een implementatiepartner kiezen die bij uw processen, uw omvang en uw groeiplannen passen.

Selectie begint met een programma van eisen. Splits eisen in noodzakelijk, wenselijk en overbodig, en beschrijf ze als bedrijfsprocessen in plaats van als lijstje functies. Het gaat om vragen als: hoe loopt een order van aanvraag tot betaling, welke goedkeuringen zijn nodig, hoe verloopt de voorraadwaardering.

Het aanbod op de Nederlandse markt is breed. Odoo, Exact Online, Microsoft Dynamics 365 Business Central, AFAS, SAP Business One en Oracle NetSuite verschillen in doelgroep, opbouw en manier van uitbreiden. Een neutrale vergelijking vindt u bij ERP-software en in de pagina's over Odoo en Business Central. Hoe u kiest, staat in de gids ERP kiezen.

De integrator is minstens zo bepalend als het pakket. Dezelfde software kan in handen van een ervaren partner soepel verlopen en bij een ongeschikte partner stroef. Let op ervaring in uw sector, op de bezetting van het projectteam en op de manier van werken. De gids ERP-integrator kiezen geeft criteria en vragen voor de gesprekken.

Opleveringen

• een gewogen programma van eisen;
• een shortlist van pakketten en partners, met gestructureerde demonstraties op basis van uw eigen scenario's;
• een keuzedossier waarin de afweging is vastgelegd;
• een contract met duidelijke afspraken over scope, rollen, wijzigingsbeheer en oplevering.

Valkuilen

• Kiezen op basis van een aansprekende demonstratie met standaardgegevens. Vraag om uw eigen scenario's.
• Alleen naar de licentieprijs kijken. De totale kosten bestaan uit licenties, implementatie, koppelingen, training en beheer.
• Een contract dat te veel openlaat. Onduidelijke scopeafspraken leiden tot discussies over meerwerk.

Stap drie: ontwerp van de processen

Doel. Uw werkwijze vertalen naar het gedrag van het systeem, en tegelijk beslissen waar u uw werkwijze aanpast aan de standaard.

In de ontwerpfase, soms analyse- of fit-gapfase genoemd, bespreken consultants en key users elk proces: wat gebeurt er, wie doet het, welke gegevens zijn nodig, welke uitzonderingen komen voor. Per proces wordt bepaald of de standaardfunctie volstaat, of een instelling nodig is, of dat maatwerk of een aanvullende oplossing nodig is.

De hoofdregel: volg waar mogelijk de standaard. Elk maatwerk kost bij de bouw, bij de test en bij elke toekomstige update opnieuw tijd. Maatwerk is gerechtvaardigd als het een echt concurrentievoordeel ondersteunt of een wettelijke eis invult, niet als het een gewoonte van één medewerker bewaart.

Opleveringen

• een functioneel ontwerp per proces, met de gekozen oplossing en de reden;
• een lijst met afwijkingen van de standaard en een besluit per afwijking;
• een ontwerp van de koppelingen met andere systemen, zoals webshop, bank, vervoerders of een productieplanner;
• een inrichting van de organisatiestructuur: bedrijven, vestigingen, magazijnen, grootboekschema en dimensies.

Valkuilen

• Het huidige systeem één op één nabouwen. Dat bewaart ook de zwakke plekken van vroeger.
• Beslissingen die niemand durft te nemen. Spreek een escalatiepad af en laat de opdrachtgever knopen doorhakken.
• Wettelijke eisen vergeten, zoals e-facturatie, btw-aangiften of bewaarplichten. Lees daarvoor de gids over e-facturatie in ERP.

Stap vier: configuratie en koppelingen

Doel. Het ontwerp omzetten in een werkende omgeving waarop u kunt testen.

De integrator richt het systeem in: stamgegevens, rechten, werkstromen, rapportages en documentlay-outs. Koppelingen worden gebouwd en getest, en eventuele maatwerkonderdelen ontwikkeld. Een goede aanpak werkt in korte rondes, met tussentijdse demonstraties aan de key users, zodat misverstanden vroeg zichtbaar worden.

De keuze tussen cloud-ERP of on-premise bepaalt mede hoe deze stap verloopt: bij een cloudoplossing richt u omgevingen in via de aanbieder, bij on-premise zorgt u zelf voor servers, back-ups en beveiliging. Dat verschil moet vóór deze stap duidelijk zijn.

Opleveringen

• een ingerichte testomgeving die de ontworpen processen kan uitvoeren;
• werkende koppelingen met de belangrijkste omringende systemen;
• een rechten- en rollenmodel, afgestemd op functiescheiding;
• een overzicht van rapporten en dashboards.

Valkuilen

• Key users die pas bij de test voor het eerst het systeem zien. Laat ze tussentijds meekijken.
• Koppelingen die als bijzaak worden behandeld. In de praktijk vragen ze vaak meer aandacht dan het pakket zelf.
• Rechten te ruim inrichten omdat het sneller gaat. Dat levert later auditproblemen op.

Stap vijf: datamigratie

Doel. Betrouwbare, opgeschoonde gegevens in het nieuwe systeem krijgen, in een vorm die het systeem kan gebruiken.

Datamigratie is de stap die het vaakst wordt onderschat. Relaties, artikelen, stuklijsten, openstaande posten, voorraadstanden en historie staan zelden in een vorm die zonder meer past. Bepaal eerst wat u meeneemt: stamgegevens en openstaande posten bijna altijd, volledige transactiehistorie niet altijd. Oude historie kunt u vaak beter raadpleegbaar houden in een archief.

Werk in proefmigraties. Elke ronde laadt een volledige dataset in de testomgeving, waarna de key users de uitkomst controleren. Fouten uit de eerste ronde zijn normaal; ze verdwijnen pas door herhaling. Het slotmoment, de definitieve migratie, wordt als een draaiboek voorbereid.

Opleveringen

• een migratieplan met scope, bronnen, verantwoordelijken en regels voor opschoning;
• herhaalbare migratiescripts of -sjablonen;
• een afstemming tussen oud en nieuw: saldi, voorraad, openstaande posten;
• een getekend akkoord van de dataverantwoordelijken.

Valkuilen

• Slechte data blindelings overnemen. Het nieuwe systeem maakt ontdubbeling en opschoning juist noodzakelijk.
• Geen eigenaar voor de datakwaliteit. De integrator kent uw klanten en artikelen niet; uw eigen mensen wel.
• Te laat beginnen. Datamigratie loopt parallel aan ontwerp en configuratie, niet erna.

Gaat het om de overstap van een bestaand ERP-systeem, dan helpt de gids over ERP-migratie bij de specifieke risico's.

Stap zes: acceptatietest

Doel. Aantonen dat het systeem uw dagelijkse processen aankan, met uw gegevens en door uw mensen.

Er zijn meerdere testlagen. De integrator test technisch en functioneel; daarna volgt de acceptatietest door uw key users aan de hand van scenario's die het volledige proces dekken, van offerte tot betaling, van inkoop tot voorraad, van productieorder tot kostprijs. Test ook uitzonderingen: retouren, creditnota's, correcties, meerdere valuta's als u die gebruikt, en periodesluitingen.

Doe daarnaast een integratietest van de koppelingen en een prestatietest met realistische volumes. Een proces dat met tien records werkt, moet ook werken met de volumes van een drukke maandafsluiting.

Opleveringen

• testscenario's gebaseerd op echte bedrijfssituaties;
• een lijst met bevindingen, ingedeeld naar ernst en met een besluit per punt;
• een getekend testrapport waarin de opdrachtgever de overstap goedkeurt of uitstelt;
• een go/no-go-criterialijst, vooraf overeengekomen.

Valkuilen

• Testen met te weinig mensen of op te weinig tijd, omdat de dagelijkse drukte voorgaat.
• Alleen het gewone verloop testen. Bijna alle problemen na livegang komen uit uitzonderingen.
• Bevindingen die blijven liggen. Spreek af welke punten vóór livegang opgelost moeten zijn en welke daarna mogen.

Stap zeven: training en veranderbegeleiding

Doel. Zorgen dat gebruikers het systeem begrijpen, vertrouwen en juist gebruiken.

Training wordt vaak als laatste ingepland en als eerste geschrapt. Dat is een kostbare fout. Het beste werkt een opbouw in twee lagen: de integrator traint de key users, en de key users trainen daarna hun collega's op basis van uw eigen processen en gegevens. Zo bouwt u interne kennis op die na het project blijft.

Naast training hoort communicatie. Leg uit waarom het project nodig is, wat er verandert in het dagelijks werk en wie waarmee kan helpen. Weerstand is meestal een teken dat mensen zich niet gehoord voelen, niet dat ze tegen vooruitgang zijn.

Opleveringen

• een trainingsplan per rol, met handleidingen in de taal van uw medewerkers;
• opgeleide key users die als eerste aanspreekpunt dienen;
• een communicatieplan richting alle betrokkenen;
• een afspraak over ondersteuning in de eerste weken na livegang.

Valkuilen

• Algemene training met demogegevens. Mensen onthouden wat ze met hun eigen werk kunnen doen.
• Key users die er het project naast bij moeten doen zonder ruimte in hun agenda.
• Het systeem presenteren als een controlemiddel. Benadruk wat het werk makkelijker maakt.

Stap acht: livegang

Doel. Van het oude naar het nieuwe systeem overschakelen met zo min mogelijk verstoring van uw bedrijfsvoering.

Livegang is een afgesproken moment waarop alles samenkomt: definitieve datamigratie, afsluiten van het oude systeem, openen van het nieuwe. Een draaiboek beschrijft wie wat doet, in welke volgorde en wat de terugvalmogelijkheid is. Kies het moment bewust. Veel bedrijven kiezen een rustige periode of de start van een boekjaar of boekperiode, zodat de financiële afsluiting schoon verloopt.

Er zijn twee hoofdstrategieën. Bij een overstap in één keer gaat het hele bedrijf tegelijk over. Bij een gefaseerde overstap gaat u per module, per vestiging of per land live. Gefaseerd verlaagt het risico en vraagt meer coördinatie; één keer is eenvoudiger te organiseren en scherper in de uitvoering. De juiste keuze hangt af van de omvang en de complexiteit van uw organisatie.

Opleveringen

• een draaiboek met taken, verantwoordelijken, tijdstippen en terugvalplan;
• een formele go/no-go-beslissing op basis van de afgesproken criteria;
• extra ondersteuning op de werkvloer in de eerste dagen;
• een lijst van openstaande punten met een duidelijke planning.

Valkuilen

• Livegang in een drukke periode, zonder terugvalplan.
• Het oude systeem te snel uitschakelen, voordat de eerste afsluiting is gelukt.
• Te weinig ondersteuning in de eerste weken, waardoor mensen terugvallen op spreadsheets.

Stap negen: nazorg en doorontwikkeling

Doel. Het systeem stabiliseren en daarna blijven laten meegroeien met uw bedrijf.

Na livegang volgt een stabilisatieperiode waarin de integrator fouten oplost en gebruikers ondersteunt. Daarna begint het eigenlijke rendement: rapportages verfijnen, handmatige stappen automatiseren, modules toevoegen en koppelingen uitbreiden. Plan regelmatige evaluaties met de key users en leg vast welke verbeteringen de meeste waarde opleveren.

Maak ook beheerafspraken. Wie beheert rechten en stamgegevens? Hoe gaat u om met updates van de leverancier? Wie beslist over wijzigingsverzoeken? Een ERP-systeem zonder eigenaar veroudert snel, ook als de software zelf actueel blijft.

Opleveringen

• een evaluatie van het project ten opzichte van de doelen uit de afbakening;
• een beheerorganisatie met rollen, serviceafspraken en een wijzigingsproces;
• een verbeterplan met prioriteiten;
• een plan voor het omgaan met updates en nieuwe versies.

Valkuilen

• Het project als afgerond beschouwen op de dag van livegang.
• Geen budget of tijd voor verbetering reserveren.
• Gebruikers die oplossingen buiten het systeem blijven zoeken omdat verzoeken niet worden opgepakt.

Rollen en tijdsinvestering

Een ERP-project vraagt veel van uw eigen organisatie. De integrator levert kennis van het pakket; u levert kennis van uw bedrijf. Plan deze rollen vooraf.

Wat de doorlooptijd en de kosten bepaalt, is geen vast aantal maanden, maar een combinatie van factoren: het aantal processen en modules, het aantal gebruikers, het aantal entiteiten en landen, de datakwaliteit, de omvang van maatwerk en de beschikbaarheid van uw eigen mensen. Een serieuze integrator noemt geen vaste einddatum vóór de ontwerpfase. Wie dat wel doet, geeft een gok.

Vooraf te stellen controlevragen

Gebruik de volgende vragen als toets voordat u een stap afsluit:

• Zijn de doelen van het project meetbaar en door de directie bevestigd?
• Weet u wat er wel en niet in de scope valt, en wie over wijzigingen beslist?
• Is elk afwijkend maatwerk onderbouwd en goedgekeurd?
• Heeft elk gegevenstype een eigenaar die de kwaliteit bewaakt?
• Zijn de testscenario's gebaseerd op echte situaties, inclusief uitzonderingen?
• Is er een terugvalplan voor de dag van livegang?
• Wie beheert het systeem na het project?

Veelgemaakte fouten in het kort

Veel ERP-projecten lopen op dezelfde plekken vast. De volledige analyse staat in de gids over fouten in ERP-projecten. De kern: een onduidelijke scope, een afwezige opdrachtgever, te veel maatwerk, onderschatte datamigratie en te weinig training. Wie deze vijf punten beheerst, haalt het grootste deel van het risico weg.

Hoe wij u op weg helpen

ERP Integrator is een gratis dienst die uw project koppelt aan een gecertificeerde integrator die past bij uw situatie. Wij voeren zelf geen implementaties uit en zijn niet verbonden aan een softwareleverancier; de integrator doet het project, wij zorgen voor de juiste kennismaking. Hoe dat in zijn werk gaat, leest u bij hoe het werkt. Wilt u eerst oriënteren, begin dan met wat een ERP-systeem is of kijk op de startpagina.

De genoemde softwarenamen zijn handelsmerken van hun respectievelijke eigenaren en worden uitsluitend ter informatie vermeld. Deze site is onafhankelijk en niet verbonden aan een softwareleverancier.