Waarom “eerst onze IT vernieuwen” zo’n gangbare gedachte is

Het klinkt logisch: als de onderliggende systemen verouderd zijn, moet je die toch eerst op orde krijgen voor je er iets slims bovenop bouwt? In de praktijk is dat zelden waar. Een systeem hoeft niet nieuw te zijn om bruikbare data te bevatten, en “eerst vernieuwen” is vaak een project van maanden tot jaren dat het eigenlijke probleem alleen maar uitstelt.

Hoe een traject werkt met wat er al staat

De meeste AI-hulpmiddelen die bij een Kufu-traject gebouwd worden, lezen gegevens uit systemen die er al staan: een export uit een boekhoudpakket, een koppeling met een CRM via een bestaande API, of gewoon een reeks Excel-bestanden die vandaag al worden bijgehouden. Het hulpmiddel wordt eromheen gebouwd, niet in de plaats ervan.

Dat betekent dat een verouderd systeem geen showstopper is, zolang er data uit te halen valt. Werkt u vandaag met een oud boekhoudpakket dat u niet meteen wilt vervangen, dan kan een hulpmiddel daar prima gegevens uit exporteren of lezen zonder dat het pakket zelf hoeft te veranderen.

Wanneer is IT-vernieuwing wél nodig, en wanneer niet?

Er zijn situaties waarin een systeem echt een blokkade vormt — bijvoorbeeld wanneer het geen enkele vorm van export of koppeling toelaat, en data dus letterlijk vastzit. Dat is de uitzondering, niet de regel, en dat wordt tijdens de eerste dag van een traject snel duidelijk. In dat geval is de conclusie niet “vernieuw eerst alles”, maar meestal iets veel kleiners: één specifieke koppeling of één extra stap om de data alsnog bereikbaar te maken.

Grote IT-vernieuwingen hebben op zich hun eigen redenen om ooit te gebeuren — veiligheid, ondersteuning die afloopt, groei die het huidige systeem niet meer aankan. Maar die beslissing hoeft niet vooraf te gaan aan een eerste AI-hulpmiddel, en allebei tegelijk aanpakken maakt een traject alleen maar groter en trager dan nodig.

Wat met beveiliging en toegang tot bestaande systemen?

Werken met bestaande systemen betekent niet dat er zomaar overal toegang nodig is. Meestal volstaat een beperkte, aparte login voor het specifieke stuk data dat relevant is — geen volledige toegang tot het hele systeem. Waar dat kan, wordt dat zo ingericht tijdens de eerste dag van een traject, in overleg met wie bij u de systemen beheert of met uw bestaande IT-partner, zodat er geen onnodige risico’s bijkomen.

Wat als er straks toch een grotere IT-vernieuwing komt?

Een hulpmiddel dat vandaag op een bestaand systeem gebouwd wordt, hoeft daarmee niet weggegooid te worden zodra dat systeem ooit vervangen wordt. De koppeling verandert dan mee, maar de kern van wat het hulpmiddel doet — data samenbrengen, iets automatisch invullen, een rapport opstellen — blijft grotendeels hetzelfde. Vroeg beginnen is dus geen keuze tegen een latere vernieuwing, eerder een manier om vandaag al iets terug te verdienen in plaats van jarenlang te wachten.

Wat betekent dit voor de omvang van een eerste stap?

Precies dit uitgangspunt is waarom een AI-scan van twee dagen of een Kickstart van vijf dagen realistisch is: het traject begint bij wat er vandaag al staat, niet bij een systeem dat nog gebouwd moet worden. Twijfelt u of uw eigen systemen daar geschikt voor zijn, dan is is onze data klaar voor AI? een goed vertrekpunt om dat zelf na te gaan.

Een eerlijke kanttekening

Dit betekent niet dat elk systeem zomaar bruikbaar is zonder enige aanpassing. Soms is een kleine ingreep nodig — een export activeren, een extra veld toevoegen, een login aanmaken voor een koppeling. Dat is iets anders dan “eerst de hele IT vernieuwen”, en meestal iets dat binnen de eerste dag van een traject zelf al opgelost geraakt, niet iets waar u vooraf apart voor moet plannen.

Waarom dit de instapdrempel verlaagt

Het gevolg is dat “we zijn er nog niet klaar voor” zelden een juiste conclusie is. De meeste kmo’s die twijfelen om te beginnen, hebben al genoeg staan om ergens mee te starten — en de eerste dag van een traject is er net om dat samen na te gaan, in plaats van dat vooraf te moeten uitzoeken.