Een rapport is het antwoord op een vraag die iemand drie maanden geleden stelde.
Iemand wilde weten hoeveel offertes er per maand vertrekken, dus bouwde iemand een rapport. Dat rapport bestaat nog. De vraag van vandaag is een andere: welke offertes van boven de vijfduizend euro kregen in september geen antwoord? Daar is geen rapport voor. Dus maakt iemand een export, plakt die in Excel, filtert, en stuurt het resultaat twee dagen later door.
Dat is het werk dat verdwijnt als je je data in gewone taal kan bevragen. Niet het rapport. Het wachten op het rapport.
Wat bevragen wel en niet is
Je data bevragen is geen dashboard met een chatvenster ernaast. En het is ook niet je Excel-bestand in ChatGPT plakken en hopen dat het rekent.
Zie het als de collega die al twintig jaar in het archief zit. Je hoeft niet te weten in welke kast het dossier ligt of hoe het mapje heet. Je stelt je vraag, hij weet waar het staat, en hij komt terug met het stuk zelf, niet met zijn herinnering eraan.
Technisch komt het hierop neer: je eigen systeem hangt rechtstreeks aan een AI-assistent zoals Claude. Die mag er vragen aan stellen, op dezelfde manier als jij een filter instelt in het programma zelf. Het systeem zoekt en telt; de assistent zet je vraag om en brengt het antwoord in leesbare zinnen terug. Je hoeft dus niet van applicatie te wisselen om iets op te zoeken.
Dat onderscheid is belangrijker dan het lijkt. Een model dat zelf een kolom optelt, kan zich vergissen. Een model dat je systeem vraagt om die kolom op te tellen, geeft je het getal dat er echt staat.
Hoe dat er in de praktijk uitziet
Thools heeft een eigen backoffice waarin het team de sprints van hun productontwikkeling opvolgt en de antwoorden uit hun surveys bewaart. Die backoffice hangt aan Claude. Wat in de ene sprint is blijven liggen, of wat testers over een bepaalde functie zeiden, is daardoor een vraag en geen zoekopdracht.
De backoffice is gebouwd rond hun eigen manier van werken. Dat is meteen waarom het werkt: de vragen die ze stellen, gaan over hun eigen begrippen, in hun eigen systeem.
Welke vragen lenen zich daarvoor bij een KMO? Vragen die je nu stelt aan de enige persoon die de export kan maken:
- Welke klanten hebben dit jaar nog niets besteld, terwijl ze vorig jaar wel kochten?
- Welke dossiers staan langer dan drie weken op dezelfde status?
- Wat zeiden klanten in de laatste vijftig enquêtes over de levertijd?
- Welke openstaande facturen horen bij klanten die ook een lopende offerte hebben?
Geen van die vragen is moeilijk. Ze worden alleen nooit gesteld, omdat het antwoord een halve dag werk kost.
Wat het niet kan
Dat klinkt als iets wat je elk pakket vandaag kan laten doen. Dat kan soms, en sommige pakketten hebben zo'n koppeling al ingebouwd. Maar een slimme vraag op slordige data levert een snel en overtuigend fout antwoord op.
Drie dingen moeten eerst kloppen.
Je begrippen moeten vastliggen. Wat is een actieve klant? Iemand die dit jaar kocht, of iemand met een lopend contract? Als twee collega's daar een ander antwoord op geven, geeft de assistent er ook twee. Hij kiest gewoon zonder het te zeggen.
Je data moet op één plek staan, of op plekken die met elkaar praten. Zitten je klanten in het CRM en je facturen in een apart boekhoudpakket zonder gemeenschappelijk klantnummer, dan kan geen enkele assistent die twee betrouwbaar naast elkaar leggen.
Je moet kunnen nagaan waar een antwoord vandaan komt. Een goed opgezette koppeling toont bij elk antwoord welke records ze gebruikte. Zonder die bron is het een bewering, geen antwoord.
Wat ik nog niet weet: hoe betrouwbaar het blijft bij vragen over tienduizenden rijen met tien filters tegelijk. Bij de vragen die een zaakvoerder in de praktijk stelt, werkt het. Bij een volledige financiële analyse zou ik het resultaat voorlopig altijd naast een klassiek rapport leggen.
Welke data je beter niet openzet
Hier zit de echte beslissing, en ze is niet technisch.
De surveyantwoorden in een backoffice hangen vaak vast aan een naam, een e-mailadres en een telefoonnummer. Dat de assistent kan zeggen wat testers over een functie vinden, is nuttig. Dat hij op verzoek een lijst met telefoonnummers afdrukt, is iets anders.
Drie vuistregels:
- Begin met lezen, niet met schrijven. De assistent mag vragen stellen aan je systeem, geen records aanpassen of verwijderen. Schrijfrechten komen later, per handeling.
- Wie iets niet mag zien in het programma, mag het ook niet via de assistent vragen. De koppeling erft de rechten van de gebruiker, nooit meer.
- Laat personeelsdossiers, lonen en alles onder beroepsgeheim buiten de eerste versie. Niet omdat het technisch niet kan, maar omdat de winst van één snelle vraag niet opweegt tegen één verkeerd gedeeld antwoord.
Dat is ook waar een applicatie op maat het verschil maakt met een algemene koppeling: jij bepaalt welke vragen er mogen, niet de leverancier van het pakket.
Wat je maandag zelf kan doen
Schrijf de vijf vragen op die je deze maand stelde en waarvoor iemand een export moest maken. Zet er drie dingen achter: in welk systeem het antwoord staat, hoe lang het duurde voor je het had, en wie het eigenlijk niet mag zien.
Staat het antwoord bij de meeste vragen in één systeem, dan is dat systeem je beste kandidaat om te ontsluiten. Staat het verspreid over drie, dan is het eerste werk niet de assistent, maar die drie aan elkaar knopen. Hoe zo'n traject loopt, van zo'n lijstje tot een werkende koppeling, lees je op onze pagina over hoe we werken.
Breng die vijf vragen mee naar een gratis strategiegesprek. Na dertig minuten weet je welke ervan morgen een vraag kunnen zijn, en welke eerst een opruimbeurt vragen.