Een ERP-project bij een KMO loopt bijna nooit spaak door de software zelf. Het loopt spaak omdat men snel wil gaan, omdat men de nodige keuzes onderschat, of omdat men denkt dat een integrator een gebrek aan interne besluitvorming zal compenseren. De veelvoorkomende fouten bij een ERP-project in een KMO zijn zelden spectaculair. Ze zijn vaak banaal, en juist dat maakt ze kostbaar.
In een kleine of middelgrote onderneming raakt een ERP snel aan alles - verkoop, aankoop, voorraad, productie, financiën, klantenservice, eCommerce. Wanneer het project goed is afgebakend, creëert het overzicht en vermindert het onnodige taken. Wanneer het slecht van start gaat, bevriest het bestaande problemen onder een complexere softwarelaag. Het verschil wordt heel vroeg gemaakt.
Waarom veelvoorkomende fouten bij een ERP-project in een KMO zo vaak terugkomen
Een KMO heeft niet de luxe van een project dat los staat van de dagelijkse activiteit. Dezelfde mensen die processen moeten definiëren, blijven ondertussen klanten, leveranciers, kasproblemen en operationele onvoorziene omstandigheden beheren. Daar begint het risico.
De klassieke val bestaat erin het ERP te behandelen als een IT-aankoop, terwijl het in werkelijkheid om een organisatieproject gaat. De bedrijfsleider wil beter overzicht, financiën wil betrouwbaardere cijfers, het operationele team wil minder herinvoer, en iedereen denkt dat zijn prioriteiten vanzelfsprekend begrepen zullen worden. Zonder expliciete keuzes stapelt het project tegenstrijdige verwachtingen op.
1. Alles in één keer willen oplossen
Veel KMO's starten een ERP-project met een buitensporige ambitie. Ze willen tegelijk de Excel-bestanden vervangen, de aankoopflows herwerken, de CRM structureren, het voorraadbeheer herzien, de rapportering verbeteren, de eCommerce-site koppelen en de facturatie automatiseren. Op papier is dat coherent. In de praktijk is het vaak te veel.
Een ERP geeft betere resultaten wanneer men prioriteiten stelt. Men moet onderscheid maken tussen wat kritiek is voor de exploitatie en wat gewoon nuttig zou zijn. Een gefaseerde start is geen gebrek aan ambitie. Het is vaak de beste manier om sneller resultaten te boeken, met minder wrijving.
2. De tool kiezen vóór de processen zijn verduidelijkt
Dit is een zeer veelvoorkomende fout. De directie ziet een overtuigende demonstratie, hoort spreken over automatisering en dashboards, en beslist dan om te starten. Het probleem is eenvoudig: als uw beheerregels niet duidelijk zijn, zal het ERP ze niet voor u uitvinden.
Voordat men over modules praat, moet men zeer concrete vragen beantwoorden. Hoe wordt een bestelling een factuur? Wie valideert een aankoop? Wat is de regel bij een voorraadbreuk? Wanneer start de productie? Waar bevindt zich de betrouwbare referentiedata? Zolang deze antwoorden verschillen naargelang de persoon, rust het project op drijfzand.
3. De datakwaliteit onderschatten
Data wordt vaak als een secundair onderwerp behandeld, terwijl het de geloofwaardigheid van het toekomstige systeem bepaalt. Dubbele artikelen, onvolledige nomenclaturen, slecht gekwalificeerde klanten, inconsistente eenheden, niet-betrouwbare tarieven, verkeerd uitgelijnde boekhoudrekeningen: bij de start komen deze gebreken allemaal tegelijk naar boven.
Het belangrijkste punt is niet enkel de data te migreren. Men moet beslissen welke data het waard is om over te nemen, te corrigeren of te laten vallen. De volledige historiek overnemen is niet altijd een goed idee. Dat hangt af van de bedrijfsbehoefte, de traceerbaarheidsverplichtingen en de reële opschoningscapaciteit. Een lichte maar propere datamigratie is vaak beter dan een massale en twijfelachtige overname.
4. Nuttige personalisatie verwarren met onnodige ontwikkeling
In veel ERP-projecten bij KMO's duikt de verleiding tot maatwerk zeer vroeg op. Een team wil exact zijn oude schermen terugvinden. Een verantwoordelijke vraagt een specifieke logica voor een zeldzaam geval. Een bedrijfsleider wenst een ultra-gepersonaliseerde workflow omdat het bedrijf dat altijd zo heeft gedaan.
Specifieke ontwikkeling is op zich geen probleem. Het wordt een probleem wanneer het dient om een herziening van de werkwijzen te vermijden. Elke personalisatie voegt kosten, doorlooptijd, testwerk en toekomstig onderhoud toe. Sommige zijn perfect gerechtvaardigd, vooral wanneer ze een reëel operationeel voordeel ondersteunen. Andere reproduceren enkel gewoontes die geen waarde meer opleveren.
De juiste reflex is de vraag te stellen: onderscheidt deze behoefte ons echt, of zoekt men gewoon geruststelling voor de organisatie?
5. Geen echte verantwoordelijke aan klantzijde aanduiden
Een ERP-project zonder duidelijke interne piloot loopt snel vast. In een KMO ziet men vaak een impliciete verdeling van verantwoordelijkheden tussen directie, financiën, operaties en IT. Iedereen is betrokken, dus niemand beslist echt.
Er is een businessverantwoordelijke voor het project nodig, met voldoende legitimiteit om te arbitreren, prioriteiten te valideren en beslissingen vooruit te helpen. Die rol bestaat niet uit het volgen van vergaderingen. Ze bestaat erin het project te dragen in de realiteit van het bedrijf. Zonder deze duidelijke verantwoordelijkheid moet de integrator een governance-leegte compenseren, en dat kost uiteindelijk altijd meer.
6. De teams te laat betrekken
Een KMO kan snel beslissen. Dat is een voordeel. Maar die snelheid wordt een nadeel wanneer het project wordt uitgedacht tussen directie en leverancier, en pas daarna aan de teams wordt voorgesteld als een systeem om over te nemen. In dat stadium duiken weerstanden vaak op onder de vorm van praktische details: ontbrekende velden, te omslachtige stappen, slecht begrepen schermen, regels die als onrealistisch worden ervaren.
Adoptie wint men niet met een opleiding op het laatste moment. Ze wordt opgebouwd wanneer de sleutelgebruikers vroeg genoeg betrokken worden om aan te geven wat het werk op het terrein echt blokkeert. Het gaat er niet om elke medewerker in een projectleider te veranderen. Het gaat erom de reële beperkingen op te vangen voordat ze na de livegang incidenten worden.
7. Het budget en de timing slecht afbakenen
Het budget van een ERP beperkt zich nooit tot de licentie of de implementatie. Men moet rekening houden met interne tijd, datamigratie, testen, change management, eventuele ontwikkelingen, interfaces en begeleiding na de start. Veel teleurstellingen komen voort uit een theoretisch budget dat slechts een deel van het echte traject dekt.
Dezelfde logica geldt voor de timing. Een te optimistische planning wordt vaak aanvaard omdat ze geruststelt. Maar een geloofwaardige kalender moet de validatietijd aan klantzijde bevatten. En het zijn juist in een KMO vaak deze validaties die uitlopen, niet uit nalatigheid, maar omdat de activiteit gewoon doorgaat. Beter een sobere planning met duidelijke mijlpalen dan een snelle belofte die onmogelijk te houden is.
8. De interfaces met de rest van het systeem verwaarlozen
Een ERP staat bijna nooit alleen. Het moet vaak communiceren met een eCommerce-site, een PIM, een betaaloplossing, een vervoerder, een BI-tool, een kassasysteem of specifieke vaksoftware. Veel projecten worden ingewikkelder omdat deze afhankelijkheden te laat worden geïdentificeerd.
Het onderwerp is niet alleen technisch. Het is ook operationeel. Als de voorraadsynchronisatie niet betrouwbaar is, lijdt de klantenservice eronder. Als betalingen slecht doorkomen, verliest de boekhouding tijd. Als productdata inconsistent zijn tussen systemen, werken verkoop en operaties met twee verschillende waarheden.
Een goede ERP-afbakening kijkt daarom heel vroeg naar de volledige stromenkaart, ook al zijn sommige interfaces pas voor een latere fase gepland.
9. De livegang als een formaliteit behandelen
De go-live wordt vaak behandeld als een datum die men moet halen. In werkelijkheid is het een risicomoment. Als de testscenario's oppervlakkig waren, als de sleutelgebruikers niet klaar zijn, als de noodprocedures niet zijn bepaald, verandert de start in crisisbeheer.
Men moet testen wat er echt gebeurt in het bedrijf, niet alleen wat werkt bij een demonstratie. Een dringende bestelling, een klantenretour, een leveranciersbreuk, een gedeeltelijke creditnota, een voorraadverschil, een betaling die over meerdere facturen wordt verrekend - dat zijn de gevallen die de maturiteit van de parametrisering blootleggen.
Hoe deze risico's te verminderen zonder het project te verzwaren
De juiste aanpak bestaat er niet in te overdocumenteren of vergaderingen te vermenigvuldigen. Een KMO heeft nood aan een afgebakend, maar ook uitvoerbaar project. Dat gaat via enkele eenvoudige keuzes: beperkte businessprioriteiten bepalen, een écht beschikbare sponsor aanduiden, de kritieke processen laten valideren vóór de ontwikkelingen, en data als een volwaardig werkterrein behandelen.
Men moet ook aanvaarden dat een goed ERP-project op compromissen rust. Niet alles zal perfect zijn op dag één. Bepaalde automatiseringen kunnen wachten als ze de operationele basis in gevaar brengen. Omgekeerd zijn bepaalde technische investeringen de moeite waard als ze permanente omwegen of dure herinvoer vermijden.
Daar toont zich vaak de waarde van een partner. Niet in zijn vermogen om overal ja op te zeggen, maar in zijn vermogen om nee te zeggen wanneer een vraag het project verzwakt, en om een realistisch traject voor te stellen. Bij Agitech is dat doorgaans het vertrekpunt van een gezond project: verkopen wat nuttig is, niet wat de scope onnodig doet opzwellen.
Wat een KMO zou moeten eisen vóór de start
Vóór de ondertekening zou een bedrijf in eenvoudige bewoordingen moeten kunnen uitleggen waarom het van ERP verandert of waarom het zijn activiteiten eindelijk rond een ERP structureert. Als het antwoord vaag blijft - beter werken, digitaliseren, centraliseren - is het project nog te abstract.
De juiste vragen zijn directer. Welke dure problemen wil men elimineren? Welke indicatoren wil men betrouwbaar maken? Welke stromen moeten functioneren zonder afhankelijk te zijn van één sleutelmedewerker? Welk niveau van standaardisatie is aanvaardbaar? En vooral, wie neemt de beslissingen wanneer men moet kiezen tussen gewoontecomfort en procesdiscipline?
Een goed uitgevoerd ERP maakt een bedrijf niet enkel beter uitgerust. Het maakt het leesbaarder, beter stuurbaar en minder kwetsbaar. Voor een KMO is het vaak minder een technologievraag dan een vraag van beheersduidelijkheid. Daarom zijn de meest voorkomende fouten ook niet technisch: ze komen voort uit een gebrek aan afbakening, prioriteit of moed in de te maken keuzes.