Een ERP-implementatie is pas geslaagd als medewerkers hun werk ermee kunnen uitvoeren, de gegevens kloppen en duidelijk is wie problemen oplost. Een overtuigende demo of afgeronde functielijst bewijst dat nog niet. De risico’s worden kleiner als de organisatie en de bouwer vooraf vastleggen wat wordt geleverd, hoe dat wordt getest en wanneer de overstap verantwoord is.
Onderstaande fouten zijn aandachtspunten voor je projectplan, geen voorspelling dat een traject zal mislukken. Gebruik ze om concrete afspraken te controleren. Gaat het nog om de productkeuze, begin dan bij het selecteren van een ERP-systeem.
1. Een productnaam als projectdoel gebruiken
“Een ERP implementeren” beschrijft de activiteit, niet het beoogde resultaat. Laat iedere betrokken afdeling de belangrijkste verandering benoemen. Leg vervolgens vast welk proces eerst wordt verbeterd, welke fout of vertraging nu speelt en hoe de nieuwe werkwijze wordt beoordeeld.
Maak daarnaast zichtbaar wat buiten het project valt. Als personeelsplanning niet wordt meegenomen, mag een nieuw dashboard niet de indruk wekken dat het capaciteitsprobleem daarmee al is opgelost.
2. Scope uitbreiden zonder gevolgen te bespreken
Een extra veld kan een extra controle, koppeling of rapportage betekenen. Houd daarom een wijzigingslijst bij. Beschrijf per verzoek het probleem, de impact en de beslissing: nu toevoegen, een onderdeel vervangen, later onderzoeken of niet doen.
Een eerste versie hoeft niet alle afdelingen te bedienen. Zij moet wel een afgesproken werkstroom betrouwbaar afmaken. Een halve keten die elke dag noodoplossingen vraagt, is niet automatisch een verstandige kleine start.
Volgende stap
Benieuwd wat dit voor jou kost?
Vertel wat je nodig hebt. We rekenen het door en sturen een offerte op maat.
3. Dagelijkse gebruikers alleen achteraf informeren
Medewerkers kennen uitzonderingen die niet in het formele proces staan. Betrek daarom mensen uit de uitvoering tijdens analyse en demonstraties. Geef hen tijd om te testen en laat zien wat met hun feedback gebeurt.
Maak één persoon verantwoordelijk voor de uiteindelijke proceskeuzes. Anders worden tegengestelde wensen allemaal ingebouwd, terwijl de onderliggende afspraak onduidelijk blijft. Betrokkenheid betekent niet dat iedereen elke beslissing apart moet goedkeuren.
4. Datamigratie als laatste technische klus behandelen
Oude gegevens bevatten vaak dubbele klanten, onduidelijke statussen en dossiers zonder eigenaar. Bepaal wat meegaat, wat moet worden hersteld en wat alleen raadpleegbaar hoeft te blijven. Plan een proefmigratie met controle op aantallen, relaties en representatieve dossiers.
Microsoft behandelt bron- en doelsystemen, volgorde, verantwoordelijkheden en controles rond de overstap als onderdelen van een migratiestrategie. Leg die onderwerpen ook voor jullie systeem vast. De gegevensverantwoordelijke moet de uitkomst kunnen beoordelen; een geslaagd importcommando is onvoldoende bewijs.
5. Alleen het makkelijke pad testen
Een correcte nieuwe opdracht is één scenario. Test ook een wijziging na akkoord, een gebruiker met beperkte rechten, een dubbele inzending en een uitgevallen koppeling. Controleer zowel wat moet gebeuren als wat nadrukkelijk niet mag gebeuren.
De Microsoft-handleiding voor testplannen adviseert scenario’s met verwachte uitkomsten en duidelijke verantwoordelijkheid. Gebruik een aparte testomgeving en leg de bevindingen vast. Een screenshot van een goed scherm bewijst niet dat de achterliggende gegevens correct zijn verwerkt.
Liever even bellen?
Laat je terugbellen
Eén telefoontje is vaak sneller dan drie mailtjes. Je hoort binnen een werkdag van ons.
6. Instructie verwarren met een eenmalige presentatie
Laat medewerkers hun eigen taken oefenen: een dossier starten, een fout corrigeren, een status overdragen en hulp vragen. Maak korte instructies per rol. Niet iedereen heeft een rondleiding door alle functies nodig.
Bespreek ook wat niet meer via oude lijstjes of mailboxen moet gebeuren. Wanneer de nieuwe werkwijze duidelijk is maar de oude route volledig blijft bestaan, kunnen opnieuw twee concurrerende administraties ontstaan.
7. Livegang zonder omslag- en terugvalplan
Spreek af wanneer wijzigingen in het oude systeem stoppen, welke laatste gegevens worden overgezet en wie beslist of het nieuwe systeem open mag. Controleer accounts, koppelingen en de eerste complete werkstroom vóór brede ingebruikname.
Een terugvalplan beschrijft niet alleen het terugzetten van software. Ook nieuwe gegevens en handelingen sinds de omslag moeten worden verantwoord. Voorkom dat orders of registraties bij terugschakelen verdwijnen. Laat kritieke onbekenden een reden zijn om de overstap uit te stellen.
8. Ondersteuning pas regelen na de eerste storing
Leg vóór livegang vast wie monitort, waar medewerkers incidenten melden en hoe urgente problemen worden beoordeeld. Maak onderscheid tussen een fout binnen de afgesproken scope en een nieuwe wens. Spreek af wie wijzigingen aan externe pakketten of API’s opvolgt.
Goed beheer en doorontwikkeling houden de oplossing bruikbaar wanneer het bedrijf verandert. Documentatie, accounts en kennisoverdracht moeten daarom niet alleen beschikbaar zijn bij de oorspronkelijke bouwer.
Een bruikbare eindcontrole
Vraag bij de laatste projectbespreking om bewijs: een afgetekende kernflow, opgeloste kritieke fouten, een gecontroleerde migratie en een overzicht van resterende punten met eigenaar. Controleer of gebruikers weten hoe zij hun taken en uitzonderingen afhandelen. Leg het besluit tot livegang en de voorwaarden expliciet vast.
De SiteJob-werkwijze begint met de kernflow en eindigt niet bij het opleveren van schermen. Voor een gesprek over een ERP-traject zijn bestaande procesvoorbeelden, een gegevensoverzicht en de belangrijkste onzekerheden een goede voorbereiding.
