Nieuw systeem selecteren | Checklist voor keuze & integraties

Een nieuw systeem selecteren: waar je op moet letten om écht vooruit te gaan

Een nieuw systeem selecteren lijkt soms vooral een keuze tussen leveranciers, features en prijzen. In de praktijk is het iets anders: je kiest een systeem dat je dagelijkse werk gaat sturen. En als je hier verkeerd kiest, betaal je dat later terug in omwegen, frustratie, extra werk en ontwikkelkosten.

Als je vooruit wil, moet je selectie niet draaien om “wat klinkt goed”, maar om: wat werkt in jullie processen en past bij jullie groei.

1) Begin bij je huidige landschap: integraties zijn geen detail

De meeste organisaties draaien niet op één systeem. Er zijn koppelingen met ERP, CRM, boekhouding, WMS/TMS, planningstools, BI-rapportages, portals, Excel-bestanden die “even tijdelijk” bleven bestaan — noem maar op.

Daarom is de eerste stap niet een longlist met leveranciers, maar een overzicht van:

  • welke systemen nu betrokken zijn in het proces
  • welke data waar “de waarheid” is (masterdata)
  • welke integraties kritisch zijn voor de dagelijkse operatie
  • welke koppelingen nu problemen geven (handwerk, foutgevoelig, timing)

Een nieuw systeem dat op papier perfect is, maar slecht integreert met je bestaande landschap, zorgt uiteindelijk voor méér handwerk. En dat is precies wat je wilde voorkomen.

2) Maak een wensenlijst, maar durf te schrappen

Een goede wensenlijst is geen boodschappenlijst. Het is een hulpmiddel om keuzes te maken.

Werk met drie categorieën:

  • Must-haves: zonder dit werkt het proces niet
  • Should-haves: belangrijk, maar tijdelijk op te vangen
  • Nice-to-haves: pas relevant als de basis staat

Belangrijk: leg elk punt naast twee dingen:

  1. Pijnpunt: welk probleem lossen we hiermee op?
  2. Bestaande functionaliteit: doen we dit nu al (desnoods omslachtig) in huidige systemen?

Als een wens al grotendeels wordt afgedekt door bestaande tooling of een simpele procesafspraak, zet ’m lager of haal ’m weg. Zo voorkom je dat je je selectie laat sturen door features die vooral “lekker voelen”, maar weinig opleveren.

3) Kies op pijnpunten, niet op glimmende extra’s

De grootste fout bij systeemselectie is kiezen op basis van “mooie mogelijkheden”, in plaats van de redenen waarom je nu vastloopt.

Dus: maak de pijnpunten expliciet. Bijvoorbeeld:

  • veel handmatig overtypen tussen systemen
  • onbetrouwbare data of dubbele registraties
  • slechte traceerbaarheid of onvoldoende status-inzicht
  • te veel uitzonderingen die niet passen in de workflow
  • rapportages die achteraf kloppen, maar niet helpen bij sturen

Een systeem moet je selecteren op wat je nu niet kunt of alleen met veel omwegen kunt. Nice-to-haves komen later pas.

4) Peil ambitie: je leverancier moet kartrekker willen zijn

Dit is er eentje waar veel organisaties te laat achter komen: je koopt niet alleen een systeem, je kiest ook een partij die de komende jaren meeontwikkelt.

Je wil voorkomen dat je binnenkort weer tegen de muur aan loopt, of dat je voor elke nieuwe feature een maatwerkfactuur krijgt. Daarom moet je toetsen of een partij:

  • een duidelijke productvisie en roadmap heeft
  • aantoonbaar doorontwikkelt (regelmatig releases, transparantie)
  • klanten actief betrekt bij verbeteringen
  • bereid is verantwoordelijkheid te nemen als kartrekker

Praktisch: vraag in gesprekken niet alleen “kan het?”, maar:

  • Wat hebben jullie de afgelopen 12 maanden aan productontwikkeling opgeleverd?
  • Welke features staan er de komende 6–12 maanden op de roadmap?
  • Hoe worden klantwensen geprioriteerd?
  • Wat is standaard en wat wordt maatwerk?

Ambitie is geen marketingzin. Ambitie zie je terug in structuur, ritme en bewijs.

5) Plan demo’s slim: niet consumeren, maar testen

Een demo is geen show. Het is een test. Plan daarom niet één demo met één partij, maar:

  • maak een shortlist (bijv. 3–5 partijen)
  • geef elk dezelfde cases en scenario’s
  • laat ze het proces doorlopen zoals jullie het echt doen
  • stel kritische vragen over uitzonderingen

Nog beter: vraag een demo-omgeving aan en ga er zelf doorheen. Scroll, klik, probeer, en let vooral op:

  • hoe logisch voelt de workflow?
  • wat kost handmatig werk?
  • hoe worden uitzonderingen afgehandeld?
  • hoe makkelijk is het om fouten te herstellen?

Wat er in een demo soepel uitziet, kan in het dagelijks gebruik alsnog zwaar zijn. Zelf testen haalt dat snel boven water.

6) Trap niet in AI als verkooppraatje

AI wordt momenteel vaak gebruikt als etiket: het klinkt modern, maar zegt weinig. “AI in het systeem” is geen reden om te kiezen — zeker niet als het je kernproblemen niet oplost.

Goede vuistregel:

  • Als de basisprocessen niet strak zijn, maakt AI het niet beter — alleen ingewikkelder.

Vraag daarom door:

  • wat doet die AI concreet?
  • welke inputdata heeft het nodig?
  • hoe betrouwbaar is het resultaat?
  • wie is verantwoordelijk bij fouten?
  • wat levert het op in tijd, fouten of doorlooptijd?

Als het antwoord vaag blijft, is het meestal vooral verkooptaal.

7) Laat iemand meekijken als je niet alles van de werkprocessen weet

Systeemselectie faalt vaak omdat beslissers het proces kennen op hoofdlijnen, maar niet in detail. En juist die details bepalen of een systeem werkt.

Als je te weinig zicht hebt op de huidige werkprocessen:

  • betrek key users van de werkvloer
  • loop processen mee (korte observaties werken beter dan aannames)
  • laat een onafhankelijke partij de processen en pijnpunten objectiveren

Je kiest een systeem niet voor hoe je denkt dat je werkt, maar voor hoe het werk daadwerkelijk gebeurt.

Chapter22-signatuur

Een nieuw systeem selecteren is geen feature-wedstrijd. Het is een keuze die je proces, je integraties en je groeiruimte bepaalt. Als je vooruit wil, selecteer je op pijnpunten, bewijs van doorontwikkeling en de mate waarin een leverancier verantwoordelijkheid durft te nemen.

Bij Chapter22 beginnen we daarom niet bij tools, maar bij het werk: processen, data en integraties. Daarna pas kiezen we een systeem dat niet alleen vandaag past, maar ook voorkomt dat je over twee jaar opnieuw moet vervangen of duur moet bijbouwen.

date_range

Geschreven op:

March 5, 2026

person

Geschreven door: Stan de Leeuw

0
1
2
3
4
5
6
7
8
9
0
0
1
2
3
4
5
6
7
8
9
0
0
1
2
3
4
5
6
7
8
9
0
%