Softwareimplementatie:
wat komt er op je af nadat je getekend hebt?

Bekijk het webinar

De opname van 10 september 2026. Duur: 53 minuten.

In dit webinar nemen Ines Vanlangendonck en Rutger Meekers je mee door wat er op je afkomt zodra het contract getekend is. Samen begeleidden ze tientallen implementaties, eerst aan de kant van softwareleveranciers, nu aan die van organisaties in non-profit en social profit. Bekijk de video, of lees het uitgebreide dossier hieronder rustig op je eigen tempo.

De slides kan je hier terugvinden.

Zes meest voorkomende vragen beantwoord

De vragen die we het meeste horen tijdens, of in de aanloop naar, softwaretrajecten behandelen we één voor één.

Hieronder het korte antwoord, wil je meer lezen, scroll dan verder of klik gewoon op de vraag waar je meer over wil weten.

Scrol verder om per vraag het uitgebreide antwoord te ontdekken.
Wil je er liever meteen mee aan de slag, spring dan naar de acht vragen voor je volgende intern overleg.

Om te beginnen: waar het écht misloopt

Deze zes uitspraken doen bij ons een alarmbel afgaan. Ze klinken onschuldig, en ze komen allemaal voort uit een aanname die niemand hardop toetst. Organisaties vrezen bugs, een leverancier die niet levert, een systeem dat minder kan dan verwacht, data die slecht gemigreerd wordt. Allemaal legitiem, en geen van alle de reden waarom trajecten ontsporen. 

Wat er wel gebeurt:

De rode draad? Alle vier gaan ze over je eigen organisatie. Dat is confronterend, maar ook een troost, want het betekent dat je het volledig zelf in de hand hebt. 

1. Waar begin je?

Begin niet bij requirements, of gebruikersbevragingen, of gesprekken met mogelijke leveranciers omdat je toevallig hun reclame voorbij hebt zien komen (ik heb het over jou, odoo!).

Begin bij je doel: waarom willen jullie dit digitale traject? Schrijf je doel in drie tot vier zinnen, kort genoeg om aan de muur te hangen. Een voorbeeld? Uit een traject rond stagebeheer: het platform brengt alle communicatie over stages tussen studenten, docenten en begeleiders samen, zodat het sneller en zonder fouten gebeurt over faculteiten heen. 

En zet daarna het denkwerk eronder: waarom doen we dit, voor wie verandert het werk, wat hoort er uitdrukkelijk niet in.

Een visie geeft natuurlijk richting, maar het dient vooral om nee te kunnen zeggen. Zonder expliciet doel is elke vraag van elke afdeling even legitiem, en vult iemand anders het in: je leverancier met zijn bril, of een collega of bestuurder met een sterke stem halverwege het project. 

Maak succes ook toetsbaar. Beschrijf je definition of done in tien tot vijftien kritieke werkhandelingen per gebruikersprofiel. Niet "het systeem staat live", wel "kan de hulpverlener zijn dossier afwerken?" Zonder die lijst wordt klaar een gevoel, en dan wint wie het hardst roept.

Neem hier genoeg tijd voor, want het levert je de grootste winst op. Doe deze oefening met mensen die daarna in de stuurgroep komen en laat het geheel valideren door je management. Zo is de richting en eindbestemming voor iedereen duidelijk.

2. Wie beslist wat, en wie doet het werk? (governance)

"Dat beslist de directeur wel" klinkt als duidelijkheid, maar het betekent dat het mandaat niet verdeeld is. De directie wordt de bottleneck. Mandaat krijg je van iemand die het kan doorgeven, en het is niet omdat je de aanbesteding trok dat je mag beslissen tijdens de bouw. Dus zorg dat diegene die de effectieve verantwoordelijkheid opneemt, ook het juiste mandaat krijgt.

Mandaat geven aan een ander betekent ook loslaten. Vergelijk het met een appartement dat je verhuurt: zodra er een huurder in zit, val je er niet meer binnen met je eigen sleutel. Wie delegeert, springt voor zijn mensen in de bres, ook bij een beslissing waar hij zelf niet gelukkig mee is.

Niemand beslist alleen, zorg dat er een logische governance structuur wordt opgezet. Elke laag volgt een ander ritme en is voor andere dingen verantwoordelijk:

Strategisch bewaakt de kaders, operationeel hakt knopen door. Een stuurgroep fluit het kernteam alleen terug wanneer een beslissing buiten de visie valt, en dus niet op technische gronden. Die stuurgroep hoeft niet groot te zijn: twee directieleden plus de projectleiding volstaat bij een kleinere organisatie.

Leg per orgaan vier zinnen vast: 

• mag autonoom beslissen over, 
• beslist in overleg over, 
• moet escaleren bij, 
• en verleend door wie en wanneer. 

Dat is een klein document, maar met grote impact. Want goeie afspraken maken goeie vrienden (of collega's).

Nog even over mandaat: wat een teruggedraaide beslissing kost. 

In datzelfde stageplatform was beslist dat alle docenten konden communiceren met alle stagebegeleiders. Halverwege drong de consequentie door: iedereen zag dan ook alle contactgegevens van alle bedrijven. Het bestuur wilde terugkomen op die keuze. Dat kost je twee keer: 

• de software is al rond die logica gebouwd (sunk cost)
• en je toont je kernteam dat zijn mandaat altijd teruggeroepen kan worden (vertrouwen)

Je bestuur is trouwens je snelheidslimiet: één beslissing die daar passeert kost in het slechtste geval tien weken. Spreek vooraf af wat er niet langs moet en plan de andere beslissingsmomenten ruim op voorhand.

Wat is de juiste schaal voor mijn organisatiegrootte?

"Dit is veel te zwaar voor ons." We horen het vaak, en meestal heeft wie het zegt gelijk. Governance moet passen bij je project: te zwaar verstikt een klein team, te licht laat een groot traject ontsporen. Een implementatie van 200.000 euro vraagt nu eenmaal andere afspraken dan een van een miljoen, en die weer andere dan een van tien miljoen.

Wij werken daarom met drie maten. Zoek waar jouw project zit en gebruik die kolom als vertrekpunt:

Hoe bepaal je jouw maat? Kalibreer op vier factoren:

• de omvang van het project: budget, doorlooptijd en het aantal processen dat je raakt
• de impact en het risico voor je dagelijkse werking
• het aantal leveranciers dat meespeelt
• je interne ervaring met projectmatig werken

Twee regels bij het lezen van die tabel:

• Bij een gemengd beeld rond je naar boven af, zeker wanneer impact en risico hoog zijn.
• Weinig interne ervaring verlaagt je categorie niet. Het is net een reden om mandaten expliciet te maken en zware rollen tijdelijk extern te beleggen.

Loopt dit project samen met andere projecten die data, systemen of dezelfde mensen delen? Dan is het geen project meer maar een programma, en zit je in L.

Twijfel je tussen klein en groot beginnen, begin dan klein en breid uit wanneer het nodig is. Dat werkt beter dan een structuur optuigen die niemand volhoudt. Eén ding is wel het minimum, hoe klein je ook bent: een stuurgroep heb je altijd nodig. Bij een kleinere organisatie mogen dat twee directieleden zijn, met je projectleiding erbij, want die moet mee kunnen beslissen.

Wie doet het werk (rollen binnen projectteam)

Vraag drie leveranciers een offerte en je krijgt drie woordenlijsten: sponsor, projecteigenaar, key user, proceseigenaar, product owner, scrum master. Meestal bedoelen ze hetzelfde. Teken zelf je projectteam uit, want de standaardindeling die een leverancier gebruikt, past meestal niet op non-profits.

Je projectteam bestaat uit verschillende rollen, en een rol is geen persoon: één iemand kan meerdere rollen opnemen, zolang die, en de rest van de organisatie, weet dat het meerdere petten zijn. 

Lijst op wie welke rol opneemt en in welk orgaan zit. Dankzij deze oefening zie je meteen ook of er te veel (werkdruk of verantwoordelijkheid) bij één persoon terecht komt en of er ergens een belangenconflict opduikt. Wees op dit moment ook realistisch. Je kan als organisatie van alles willen, maar als je niet de mensen hebt om het tot een goed einde te brengen, dan schaal je beter terug. Liever stapsgewijs behapbare projecten, dan alles tegelijk in gang trappen en hopen op het beste.

En moet je alles zelf doen? Projectmanagement kan je gerust uitbesteden, een product owner niet: die beslist continu over dingen die de organisatie raken, en een externe werkt zich daar op korte termijn niet in. Veel organisatiekennis met weinig ervaring als product owner werkt beter dan omgekeerd. Intern blijven ook je sponsor, je proceseigenaars, je key users en je ambassadeurs. Tijdelijk extern kan: projectleiding, PMO, change, testcoördinatie en datamigratie. En wie het systeem straks beheert, loopt best mee vanaf dag één.

Hoeveel tijd moet je ongeveer rekenen per rol?

Scenario A: één kernsysteem voor 80 gebruikers

Samen ongeveer 2 VTE intern, verdeeld over 8 tot 12 mensen, een jaar lang.

"Tijdens piek" is niet "het hele traject". Niemand doet dit voltijds, en precies daarom wordt het vaak onderschat: het is nergens één beslissing om iemand vrij te maken, het zijn twaalf kleine beslissingen die niemand optelt. De cijfers zijn indicaties van wat wij zouden voorstellen, gebaseerd op onze ervaring in tientallen implementatietrajecten.

Scenario B: meerdere systemen, meerdere vestigingen

Reken op 5 tot 8 VTE. Maar de optelsom is je probleem niet.

Kijk naar de kolom "aantal". In elke rij komen dezelfde drie of vier namen terug: de weinige mensen die je organisatie echt kennen en tegelijk een project aankunnen. Dat is je capaciteitsgrens, niet je budget. Bescherm die mensen, prioriteer bewust en spreid je projecten. Twee projecten na elkaar duren vaak korter dan twee tegelijk.

3. Hoe hou je timing en budget strak?

Ongeveer 60% van je bestek wordt gebouwd zoals bedoeld. Dat klinkt als slecht nieuws en het is er geen. Veel procesontwerp gebeurt pas tijdens de implementatie: over de grote lijnen bestaat overeenstemming, over de honderden kleine dingen niet. Wie mag een dossier heropenen? Wanneer is een aanvraag afgesloten? Een mens vult die gaten zelf in, een systeem doet dat niet.

Daarom valt een uitgebreide analyse vooraf tegen. Je steekt er maanden in, kiest een leverancier, en het eerste wat die zegt is: we starten met de analysefase. Het eindresultaat halen we wel, maar niet op de manier die jij geschetst hebt. Doe vooraf dus net genoeg analyse om je offertevraag high-level en vooral functioneel te schrijven, intern te begroten en vooral zelf helemaal te begrijpen wat je nodig hebt.

Je verliest je grip niet, je verplaatst ze: van "alles wat we opschreven komt er" naar "we leveren op datum en binnen budget het meest waardevolle dat we kunnen". Vraag niet of iets volledig is, vraag of het beter is dan wat je had, en laat je leverancier voor elke scopewijziging de impact op tijd, kost en risico berekenen.

De perfectieval. Een nieuw systeem maakt 95% van je processen efficiënter, en dan is er dat ene proces dat het minder goed ondersteunt. De aandacht verschuift razendsnel naar die uitzondering. Je vergelijkt dan met een geïdealiseerde versie van je oude systeem en het wordt het focuspunt van de frustratie die vaak omwille van andere redenen in het project is geslopen. Start daarom op tijd met change management (daarover later meer) en verdedig je nieuwe systeem. Het heeft even tijd nodig voor mensen er aan gewend zijn.

Standaardpakket dat toch maatwerk wordt?

In de regel raden wij aan om maximaal te kiezen voor standaard softwarepakketten. Jouw organisatie is uniek, maar de manier waarop je processen lopen vaak niet. Dat betekent dat je met een pakket dat je zo off the shelf kan kopen al heel ver komt voor de best mogelijke prijs. 

Maar sluit zo'n standaardpakket perfect aan? Nee. Het systeem dekt bijvoorbeeld 70% van wat jij wil en nodig hebt, maar wat doe je dan met die overige 30%?

Optie 1: We houden vast aan de manier waarop we dingen vroeger deden. Dan moet de software volledig aansluiten op je oude processen. Leveranciers werken daaraan mee, want ook zij willen aan je verwachtingen voldoen en factureren onderweg met plezier voor al dat maatwerk. Of je er over vijf jaar nog mee verder kan, weegt bij hen minder zwaar.

Optie 2: Je stelt je processen in vraag en probeert voor die overgebleven 30% maximaal aan te sluiten op de logica van het nieuwe pakket. Je zal soms eens langs rechts moeten gaan in plaats van langs links, maar blijft daarmee wel bij een pakket dat standaard ondersteund wordt en automatisch wordt ge-update. (lijkt me duidelijk waar onze voorkeur naar uitgaat?)

Maatwerk is niet verboden, het moet alleen getoetst worden aan je doel uit blok 1. 

4. Is dit eigenlijk wel de juiste richting?

Bij een verbouwing weet iedereen hoe het werkt. Jij bent de bouwheer. Je gaat eerst naar een architect, die samen met jou het ontwerp maakt en de samenhang bewaakt, en pas daarna kies je de aannemer die past bij je project.

In de digitale wereld sla je die digitale architect bijna altijd over. Een goede aannemer is goud waard en bouwt vakkundig wat je vraagt, maar de vraag die een architect stelt, stelt hij niet: heb je dit echt nodig, en hoe past het in je grotere geheel? Vraag je om vijf slaapkamers terwijl je er drie nodig hebt, dan bouwt hij er (met plezier) vijf.

Waarom het net in digitaal misgaat: je ziet niet wat er gebouwd wordt en code kent geen fysieke rem, dus het voelt alsof je kan blijven sleutelen. Bij een huis zou niemand, als het dak erop ligt, nog de fundering laten wijzigen. Bouw je zo, dan krijg je Vlaamse koterij 7.0. Het is niet toevallig dat een architect in de bouw wettelijk verplicht is, en evenmin dat hij niet in opdracht van de aannemer mag werken.

Ook die rol van digitaal architect kan je intern beleggen. Waar het om gaat is dat iemand het ontwerp en jouw belang op lange termijn bewaakt, en dat die iemand niet zelf bouwt. Reken er niet op dat je integrator dat doet: hij meet zich af aan "voldoet aan de verwachting", niet aan "is dit over vijf jaar nog een goed idee".

5. Hoe hou je het tempo erin?

Er bestaat geen algemene optimale snelheid, wel een optimale snelheid per project. Te snel komen we zelden tegen, te traag is de standaardfout. Niet omdat iemand dat plant, maar omdat beslissingen niet genomen raken of omdat mensen die een rol moeten opnemen daar geen tijd voor hebben.

En die traagheid betaal je twee keer: je resultaat komt later, en iedereen moet zich telkens opnieuw inwerken, aan jouw kant en aan die van je leverancier. Die contextswitching zit in je factuur.

Wanneer piekt wie. De uren uit blok 2 vallen niet gelijkmatig. Ontwerpworkshops trekken je proceseigenaars en key users, prioriteren en aanvaarden is je product owner, testen zijn de key users, datamigratie piekt bij de cut-over, en opleiding en overdracht vragen je key users en je toekomstige beheerder. Change loopt dan weer over het hele project, van begin tot einde. Dat is meteen je argument richting je leidinggevenden: je vraagt geen mensen voor een jaar, je vraagt specifieke mensen op specifieke momenten en dat is planbaar.

Drie dingen houden het tempo vast:

• Een escalatiepad met termijnen. "Het kernteam beslist binnen vijf werkdagen, anders escaleert het vanzelf." Zonder termijn escaleert er pas iets als iemand kwaad wordt of blijft de beslissing uit.

• Een beslissingslogboek. Je schrijft het voor over achttien maanden, wanneer niemand zich nog herinnert waarom je hier nee op zei. Wat moet er in staan?

  • Datum en orgaan
  • Beslissing
  • Waarom
  • Gevolg
• Korte iteraties en één plek. Elke twee weken iets dat je kan zien en testen. Hou backlog en beslissingen op één plek met een eigenaar. Liefst in een tool die daarvoor ontworpen is, Excel en SharePoint zijn namelijk geen projecttools

Onderschat de tijd die je moet investeren in je data niet. Opkuisen, ontdubbelen, mappen, migreren, valideren. Dit is de post die het vaakst ontspoort en die in geen enkele offerte realistisch begroot staat, want niemand buiten je organisatie weet wat er in het veld "status2" staat. Probeer dit dus op voorhand, voordat je selecteert en implementeert, al aan te pakken.

6. Hoe krijg je je mensen mee?

Change is voor ongeveer 80% communicatie en voor 20% opleiding: vertellen wat er gebeurt, aan wie het aangaat, op tijd. De klassieke fout is erover beginnen als het systeem klaar is, maar dan is het eigenlijk al te laat. Je mensen zijn niet dom, ze weten ook dat er iets gaande is, hoe meer onzekerheid je toelaat, hoe meer weerstand dat oproept.

Change begint op het moment dat de nood ontstaat, wordt concreet bij de gunning, piekt rond go-live en zakt daarna logischerwijs wat terug.

Wat je vooral niet wilt, is een geruchtenmolen waarin iedereen voelt dat er iets groots verandert en niemand weet wat. Veel organisaties zwijgen uit voorzichtigheid, maar zwijgen richt meestal meer schade aan dan open communiceren.

• Hou de deur van je projectruimte open. Projecten die zich afsluiten uit schrik voor kritiek, zwengelen de onrust net aan.
• Werk met een pilot of gefaseerde uitrol. Wie het al gezien heeft, overtuigt collega's beter dan een directiemail.
• Ambassadeurs zijn intern, je change manager mag extern. Een externe is soms net béter, wanneer interne politiek de boodschap vertroebelt.
• Train-de-trainer. Laat je key users hun eigen mensen opleiden. Dat is meteen je kennisborging.
• Zet een war room op. Eén ruimte waar leverancier en kernteam samenzitten, met het projectplan aan de muur. Collega's die binnenlopen, zien in één keer hoeveel werk erin zit.

Drie dingen die niemand je vertelt. 

• De dip in animo na go-live is normaal: kondig die fase aan, anders leest ze als bewijs dat het project mislukt is. 
• Weerstand zit vaak hoger dan de werkvloer, want het middenkader ziet zijn overzicht en soms zijn informele macht veranderen. 
• En je projectteam krijgt weinig applaus, want bij software staat er op een dag gewoon een scherm. Het is aan de directie om die mensen te beschermen en hun werk te erkennen.

Ten slotte: wanneer ben je eigenlijk klaar?

Een leverancier ziet go-live als eindpunt, want daar stopt zijn mandaat. Voor jou begint het dan pas. Succes heeft drie stappen, en alleen de derde telt: het is technisch live, het is bruikbaar, en het is in gebruik. Je medewerkers werken er elke dag mee, en graag.

Toets dat aan de kritieke werkhandelingen uit blok 1. Niet volledig, niet perfect, maar bruikbaar en gebruikt. En hou er rekening mee dat change een lange staart heeft: een systeem zonder budget na oplevering is binnen drie jaar achterhaald. Deel je vijfjarenbudget door vijf en geef het elk jaar uit.

En als het toch misloopt: durf op de pauzeknop te duwen

Soms loopt een project uit de hand en dondert het gewoon verder. Het eerste wat je dan doet is op de pauzeknop duwen. Elk lid van je kernteam moet weten dat het dat mandaat heeft, want in IT-projecten is de trein vaak vertrokken en durft niemand te zeggen dat hij twijfelt.

Je hebt niet alle feiten nodig, genoeg indicaties volstaan. Ga samenzitten en keer terug naar je doel: waar staan we, waar gaan we naartoe, wat klopt er niet? Stilstaan kost timing, verder denderen kost meer, en iets weggooien is soms goedkoper dan het eindeloos bijschaven. Eén ding om niet te doen: er wagonnetjes aan hangen. Dat andere project dat ook vastloopt, loopt niet vast om technische redenen, en die reden verhuist mee.

Acht vragen voor je volgende overleg