Waarom KMO’s vastlopen met IT-partners (en wat wél werkt)

Je start met de beste intenties. Een nieuw CRM om verkoop beter op te volgen. Een ERP om eindelijk orde te scheppen in voorraad, facturatie of productie. Een planningstool zodat alles minder ad hoc wordt.

De demo zag er goed uit. De IT-partner klonk overtuigend. Er was een planning, een offerte en een “go-live”-datum.

En toch herken je misschien dit verloop:

• Na enkele weken zijn er vooral meetings, workshops en open vragen.

• Na enkele maanden is er wel een systeem, maar het past niet bij hoe jullie écht werken.

• Medewerkers haken af: “Dit kost ons meer tijd dan het oplevert.”

• Scope en budget verschuiven gaandeweg, en niemand voelt nog controle.

• De relatie met de IT-partner verzuurt: “Ze luisteren niet” vs. “Jullie beslissen niet.”

Op dat punt is het verleidelijk om te zeggen: “Het ligt aan de IT-partner.” Soms is dat ook zo. Maar in veel KMO’s zit de kern ergens anders: het ontbreekt aan regie en eigenaarschap aan klantzijde.

En precies daar zit de hefboom om het anders te doen.

Waarom dit zelden puur “de schuld van de IT-partner” is

Een IT-partner levert doorgaans één (of meerdere) van deze rollen:

• implementatie (configuratie, integraties, migraties),

• expertise (best practices, technische keuzes),

• projectbegeleiding (planning, opvolging),

• support (nazorg, incidenten, verbeteringen).

Wat een IT-partner zelden kan leveren, tenminste niet op een betrouwbare manier, is eigenaarschap over jouw bedrijfsdoelen, interne keuzes en veranderingsproces.

In grote organisaties is dat verdeeld over functies: CIO/IT-manager, procesverantwoordelijken, change management, governance, procurement. In KMO’s belandt het vaak “tussen de plooien”, omdat de zaakvoerder al tien rollen heeft en sleutelmedewerkers hun operationele werk niet kunnen laten vallen.

Het gevolg is voorspelbaar: de IT-partner bouwt, maar de business stuurt onvoldoende. En dan krijg je een oplossing die technisch “af” is, maar operationeel niet landt.

Geen vendor-bashing dus. Dit gaat vooral over een mismatch in verwachtingen en rolverdeling.

Waarom KMO’s vastlopen: 6 oorzaken (met voorbeelden en wat er eigenlijk nodig is)

1) Geen duidelijke doelen of prioriteiten

De situatie

“Digitaliseren” is geen doel. “Efficiënter” is geen scope. Zonder scherpe doelen is het onmogelijk om goede keuzes te maken wanneer er discussies ontstaan over functionaliteiten, timing of budget.

Concreet voorbeeld

Een CRM-implementatie start met “we willen beter verkoop opvolgen”. In workshops komt al snel alles op tafel: offertes, service, projectopvolging, facturatie, marketing automation, dashboards… De IT-partner probeert iedereen tevreden te stellen en bouwt een compromis. Resultaat: veel complexiteit, weinig adoptie.

Wat er nodig was

• Een heldere top 3 aan doelen (bijvoorbeeld: “doorlooptijd offerte -20%”, “één klantbeeld”, “pipeline voorspelbaarheid”).

• Duidelijke prioriteiten: wat is fase 1, wat is fase 2?

• Eén beslissingskader: als iets niet bijdraagt aan het doel, gaat het niet in fase 1.

2) Te weinig interne voorbereiding (processen, data, beslissingen)

De situatie

Veel IT-projecten stranden op basics: rommelige data, onduidelijke processen, impliciete uitzonderingen, of ontbrekende beslissingslijnen. Niet omdat mensen onbekwaam zijn, maar omdat de realiteit van een KMO vaak organisch gegroeid is.

Concreet voorbeeld

Bij een ERP-implementatie blijkt tijdens migratie dat artikelcodes niet consistent zijn, klantgegevens dubbel staan en kortingen “op gevoel” worden ingegeven. Het project loopt vertraging op en het budget stijgt, terwijl niemand zich herkent in de oorzaak.

Wat er nodig was

• Een korte “as-is” analyse: hoe werken we vandaag echt?

• Een datacheck vóór migratie: wat is bruikbaar, wat moet opgeschoond?

• Een beslissingsstructuur: wie hakt knopen door bij uitzonderingen?

3) De verwachting dat de IT-partner “alles wel zal bedenken”

De situatie

KMO’s hopen soms dat een partner niet alleen een tool levert, maar ook het proces hertekent, interne weerstand oplost en het project “laat slagen”. Alleen: de partner kan jouw organisatie niet besturen.

Concreet voorbeeld

Een planningstool wordt geconfigureerd, maar “hoe we plannen” blijkt per planner anders. De tool krijgt daardoor tien uitzonderingen en workarounds. Na livegang voelt iedereen zich beperkt en zoekt men snel manieren om buiten het systeem te werken.

Wat er nodig was

• Interne proceskeuzes: één werkwijze als standaard (met beperkte uitzonderingen).

• Eigenaarschap: iemand aan klantzijde die keuzes durft maken, ook als niet iedereen akkoord is.

• Het besef dat IT de processen volgt; het creëert ze niet.

4) Geen interne eigenaar van het project

De situatie

Als niemand echt verantwoordelijk is, blijft alles “naast het gewone werk” gebeuren. Beslissingen blijven hangen, requirements veranderen telkens, en escalaties komen te laat.

Concreet voorbeeld

Bij een CRM of ERP is er wel een projectmeeting, maar niemand heeft mandaat. Sales wil A, finance wil B, operations wil C. De IT-partner vraagt richting, maar krijgt discussies in plaats van keuzes. De planning schuift, irritatie stijgt, en uiteindelijk wordt “het systeem” de schuldige.

Wat er nodig was

• Eén interne projectowner (product owner/project lead) met mandaat.

• Tijd en ruimte: niet “erbij”, maar gepland.

• Duidelijke governance: wie beslist wat, wanneer?

5) Te veel focus op de tool, te weinig op processen en mensen (adoptie)

De situatie

Een IT-project is zelden puur technisch. De grootste risico’s zitten in adoptie: nieuwe werkafspraken, opleiding, discipline, communicatie en begeleiding.

Concreet voorbeeld

Een service- of ticketsysteem wordt uitgerold. De tool is oké, maar er is geen afspraak over prioriteiten, respons- en oplostijden, of “wat is klaar”. Een deel blijft werken via e-mail en telefoons. Het resultaat: chaos met een nieuw label.

Wat er nodig was

• Procesdesign: afspraken, rollen, definities, uitzonderingen.

• Training en begeleiding: niet één demo, maar herhaling en coaching.

• Verandermanagement: duidelijke verwachtingen en opvolging na livegang.

6) Scope en budget die onderweg ontsporen (scope creep)

De situatie

Tijdens implementatie ontdekt men nieuwe noden. Logisch. Maar als elke nieuwe wens “erbij” komt zonder herprioritering, ontspoort het project. Dit creëert frustratie langs beide kanten: de KMO voelt zich “gefactureerd”, de IT-partner voelt “oneindige scope”.

Concreet voorbeeld

Een CRM start voor sales. Dan komt: “kan dat ook met facturatie?”, “en een klantenportaal?”, “en rapportering per segment?”, “en integratie met e-commerce?” Alles waardevol, maar niet allemaal tegelijk binnen hetzelfde budget.

Wat er nodig was

• Fase 1 met strikte scope: waarde snel realiseren.

• Change control: elke wijziging krijgt een impactinschatting (tijd, geld, risico).

• Roadmap: wat schuift naar fase 2/3?

Het alternatief: IT-regie aan klantzijde met een onafhankelijke parttime CIO

Als je de oorzaken hierboven samenneemt, zie je één rode draad: KMO’s hebben nood aan regie aan klantzijde.

Niet als extra bureaucratie, maar als praktische stuurkracht:

• doelen scherp,

• keuzes gemaakt,

• interne voorbereiding op orde,

• partners selecteren op fit,

• scope en adoptie bewaken.

In veel KMO’s is een voltijdse CIO overkill. Maar een onafhankelijke parttime CIO (of onafhankelijke IT-adviseur in CIO-rol) is vaak precies schaalbaar genoeg: enkele dagen per maand, afhankelijk van fase en complexiteit.

Wat doet zo’n onafhankelijke regisseur concreet?

1) Doelen en businesscase scherpstellen

• Wat moet beter en waarom?

• Welke KPI’s tonen succes?

• Wat is “goed genoeg” voor fase 1?

2) Interne voorbereiding organiseren

• Processen in kaart brengen (incl. uitzonderingen).

• Datakwaliteit en integraties inschatten.

• Requirements vertalen naar duidelijke verwachtingen.

3) De juiste IT-partners selecteren (zonder vendor-lock-in)

• Longlist/shortlist op basis van context, sector en maturiteit.

• Kritische vragen stellen over aanpak, governance, referenties en nazorg.

• Offertes vergelijken op scope en aannames (niet alleen op dagtarief).

4) Vertaler tussen business en IT

• Business spreekt in doelen, fricties, risico’s.

• IT spreekt in modules, integraties, migratie, constraints.

• De regisseur zorgt dat beide partijen elkaar begrijpen en dat afspraken expliciet zijn.

5) Scope, budget, planning en impact bewaken

• Strak change-proces.

• Transparant beslissingenlogboek.

• Nazorg en adoptieplan, niet enkel “go-live”.

Waarom dit de relatie met je IT-partner juist verbetert

Een sterke IT-partner werkt beter met een klant die:

• duidelijk beslist,

• voorbereid is,

• realistische verwachtingen heeft,

• snel knopen doorhakt,

• en impact op mensen meeneemt.

De parttime CIO is dus geen “controleur”, maar een versterker in de samenwerking. Minder ruis, minder rework, minder escalaties met meer resultaat.

Praktische checklist: 7 dingen om te doen vóór je een nieuw IT-traject start

Gebruik dit als voorbereiding voor je een nieuwe ERP-implementatie, CRM-implementatie, migratie of digitaliseringsproject start.

1) Formuleer je doelen op één pagina

• Wat moet beter worden?

• Hoe meten we succes?

• Wat is het primaire doel (top 1)?

2) Kies één interne eigenaar met mandaat

• Wie beslist bij discussie?

• Wie bewaakt prioriteiten?

• Is er tijd voorzien in de agenda?

3) Breng processen en uitzonderingen in kaart

• Hoe loopt het vandaag echt?

• Waar zitten knelpunten en dubbel werk?

• Welke uitzonderingen zijn “structureel” en welke moeten verdwijnen?

4) Check je data vóór je migreert

• Welke bronnen en “waarheden” bestaan er?

• Hoeveel duplicaten, ontbrekende velden, onlogische codes?

• Wie doet opschoning, tegen wanneer?

5) Definieer fase 1 met strikte scope

• Wat levert binnen 8–12 weken al waarde?

• Wat parkeren we bewust voor fase 2?

• Welke integraties zijn echt noodzakelijk?

6) Leg change control vast

• Hoe vragen we wijzigingen aan?

• Wie keurt goed?

• Welke impact op budget en timing accepteren we wel/niet?

7) Maak adoptie een deliverable, geen bijzaak

• Opleiding per rol (niet “voor iedereen hetzelfde”).

• Interne communicatie en verwachtingen.

• Hypercare na livegang (2–6 weken) met duidelijke opvolging.

Als je al teleurstellende IT-trajecten hebt meegemaakt, is sceptisch zijn logisch. Alleen is de conclusie “IT werkt niet” meestal te kort door de bocht. Wat vaak niet werkte, was de rolverdeling.

• De IT-partner is het sterkst als uitvoerder en specialist.

• De KMO moet eigenaar blijven van doelen, processen, keuzes en adoptie.

• En iemand moet de regie aan klantzijde organiseren, dit kan intern of via een onafhankelijke parttime CIO.

Wil je eens objectief analyseren waarom jullie vorige IT-project vastliep (zonder vingerwijzen), en welke aanpak de kans op succes bij een volgend traject drastisch verhoogt? Dan loont een kort gesprek vaak al: niet om meteen “een project te starten”, maar om opnieuw controle en richting te krijgen.