ERP draait niet om software die je plooit naar oude gewoonten, maar om processen die je slimmer inricht. Implementaties mislukken wanneer het softwarehuis of de implementatiepartner enkel uitvoert wat gevraagd wordt, in plaats van de vraag achter de vraag te doorgronden en te challengen.
De valkuil: digitaliseer wat er al is
Veel bedrijven starten een ERP-project met de (logische) wens om “te krijgen wat we nu doen, maar dan digitaal”. Het resultaat?
-
Overbodig maatwerk om het verleden te reproduceren
-
Complexiteit en hogere kosten bij upgrades
-
Inconsistenties tussen afdelingen (elke uitzondering wordt een feature)
-
Lage gebruikersacceptatie omdat het nieuwe systeem oud gedrag faciliteert in een nieuw jasje
De harde realiteit: wie het ERP dwingt om het verleden te imiteren, koopt vooral meer van hetzelfde, met extra licentiekosten.
De omslag: van requirements naar doelstellingen
In plaats van een lijstje met “moeten kunnen” functionaliteiten, begin je beter met heldere businessdoelen. Denk aan:
-
Verkorten van doorlooptijd van offerte tot factuur
-
Minder handwerk en minder fouten in de keten
-
Betere traceerbaarheid en rapportage
-
Snellere onboarding van nieuwe collega’s
Vraag achter de vraag: “Wat willen we verbeteren en hoe meten we dat?”
Pas daarna hoort de vraag: “Welke standaard ERP-flows ondersteunen dit het beste?”
Wat een goede implementatiepartner doet (en wij dus ook)
Bij Teamservices geloven we dat implementeren iets anders is dan enkel configureren. Onze aanpak:
-
Procesworkshops vóór configuratie
We visualiseren de huidige en gewenste flow (Order-to-Cash, Procure-to-Pay, Project-to-Invoice…). We zoeken bottlenecks en overlap. -
Standaard eerst, maatwerk bewust
We kiezen de standaardfunctionaliteit tenzij er een heldere businesscase is voor maatwerk (competitief voordeel, wetgeving, integratie). -
Challengen met respect
Als je zegt “zo doen we het al 20 jaar”, vragen wij “waarom?” en testen we alternatieven. Niet om lastig te doen, maar om te winnen op eenvoud. -
Onboarding-succes en change
Trainingen per rol, duidelijke werkinstructies, en een feedbacklus na go-live. Technologie zonder gebruikersacceptatie is een halve oplossing.
Praktijkvoorbeeld – Van legacy-eis naar juiste oplossing: budget vs. reserveringen
Een klant wilde per se éénzelfde budgetregel aan meerdere aankoopdossiers koppelen, omdat hun vorige software zo werkte. Na analyse bleek: het oude systeem was lineair opgebouwd (1 dossier → 1 prijsaanvraag → 1 contract), terwijl het nieuwe juist meerdere stappen per dossier ondersteunt. De “multi-koppeling” maskeerde eigenlijk een andere behoefte: budgetcontrole en traceerbaarheid.
De oplossing was níet voor elke stap een aankoopdossier te maken, maar het proces bundelen: start één aankoopdossier en voer daar alle vervolgstappen in uit. Resultaat: één duidelijk budgetspoor, geen dubbeltellingen.
Conclusie
ERP faalt zelden door de software zelf. Het faalt wanneer je een oude manier van werken in een nieuw systeem probeert te gieten. Kies daarom voor een partner die meedenkt, tegendenkt en durft te challengen — zodat je morgen niet hetzelfde doet als gisteren, maar beter.
