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

Het klinkt logisch: als de onderliggende systemen verouderd zijn, moet u die toch eerst op orde krijgen voor u er iets slims bovenop bouwt? In de praktijk is dat zelden waar. Een systeem hoeft niet nieuw te zijn om bruikbare data te bevatten.

“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 in een Kufu-traject gebouwd worden, lezen gegevens uit systemen die er al staan. Bijvoorbeeld een export uit een boekhoudpakket, een koppeling met een CRM via een bestaande API (de technische ingang waarmee twee systemen gegevens uitwisselen), of een reeks Excel-bestanden die u nu al bijhoudt. Het hulpmiddel wordt daaromheen 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? Een hulpmiddel kan daar gewoon gegevens uit lezen of exporteren, zonder dat het pakket zelf moet 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, geen regel, en dat wordt tijdens de eerste dag van een traject snel duidelijk. De conclusie is dan meestal niet ingrijpend: één specifieke koppeling, of één extra stap om de data alsnog bereikbaar te maken.

Grote IT-vernieuwingen hebben hun eigen redenen om ooit te gebeuren: veiligheid, aflopende ondersteuning, groei die het huidige systeem niet meer aankan. Die beslissing hoeft echter niet vooraf te gaan aan een eerste AI-hulpmiddel.

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 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.

Dat wordt, waar mogelijk, al tijdens de eerste dag van een traject ingericht, in overleg met wie bij u de systemen beheert of met uw 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 niet weggegooid te worden zodra dat systeem ooit vervangen wordt. De koppeling verandert dan mee. Maar de kern van wat het hulpmiddel doet, blijft grotendeels hetzelfde: data samenbrengen, iets automatisch invullen, een rapport opstellen. Vroeg beginnen is dus geen keuze tegen een latere vernieuwing. Het is een manier om nu al iets terug te verdienen, in plaats van jaren te wachten.

Wat betekent dit voor de omvang van een eerste stap?

Precies dit uitgangspunt is waarom Twee dagen of 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”. Meestal is het al opgelost binnen de eerste dag van een traject, zonder dat u er vooraf apart voor moet plannen.

Waarom dit de instapdrempel verlaagt

Het gevolg is dat “we zijn er nog niet klaar voor” zelden klopt. De meeste kmo’s die twijfelen om te beginnen, hebben al genoeg staan om ergens mee te starten.

De eerste dag van een traject is er net om dat samen na te gaan. U hoeft dat niet vooraf zelf uit te zoeken.