Soms moet je eerst de bron bouwen

Op zowat elke website van een BI-bureau staat dezelfde belofte. Wij halen inzicht uit de data die u al heeft.

Dat klinkt geruststellend en het is meestal waar. Maar niet altijd. Bij een aannemer waar ik vorig jaar binnenkwam, was het gewoon niet waar. Niet omdat de data rommelig was of verspreid zat. Ze bestond niet.

Wat er wel was

Een facturatiepakket dat hun facturen keurig maakte en verder niets prijsgaf. Geen bruikbare koppeling, geen export die je kon inplannen. Ik heb hun softwareleverancier moeten aanschrijven met de vraag of er überhaupt een manier was om er gestructureerd data uit te krijgen, in eender welke vorm: een API, een UBL-bestand, een CSV op een server. Dat is het niveau waarop het gesprek begon.

Een boekhouder die in een ander pakket werkte, zoals dat gaat.

En daarnaast: niets. Geen voorraadregistratie. Geen vastlegging van wat er op een werf gebeurde. Geen planning die ergens anders stond dan in het hoofd van de zaakvoerder en op een bord aan de muur.

Dat is geen uitzonderlijke situatie. Dat is hoe het er bij heel veel kmo's uitziet zodra je voorbij de facturatie kijkt.

De verkeerde reflex

Op zo'n moment is de reflex om een groter systeem voor te stellen. Een ERP dat alles vangt. Dan heb je binnen een jaar wel data.

Dat is meestal een slecht idee, en niet om de reden die je denkt. Het is niet te duur. Het is dat je een pakket koopt om een vraag te beantwoorden die je nog niet gesteld hebt. Je weet op dat moment niet welke cijfers je gaat gebruiken, dus je weet ook niet wat er vastgelegd moet worden. Wat je krijgt is een systeem dat alles registreert en niets verklaart, en personeel dat velden invult zonder te weten waarom.

De andere reflex is even verkeerd: wachten. Eerst orde op zaken, dan pas data. Dat wachten duurt altijd langer dan gepland en er komt zelden iets van.

Wat we in plaats daarvan gedaan hebben

We hebben drie kleine dingen gebouwd, elk rond één vraag waar de zaakvoerder echt mee zat.

Een app om voorraad te tellen. Als een materiaal onder zijn ijzeren voorraad zakt, rolt er een bestellijst uit als PDF. Niemand hoeft iets te interpreteren, je krijgt een lijst die je doorstuurt.

Een app voor werfopname. Vier verkopers documenteren een werf ter plaatse met foto's, metingen en notities. Eruit komt een werffiche als PDF, en tegelijk gaat alles naar een database.

Een planbord. Vier ploegen van drie mensen, werven die je per dag versleept. Het kantoor en de zaakvoerder werken erin.

Elk daarvan lost op zich een praktisch probleem op. Dat is waarom ze gebruikt worden. Maar het echte effect zit ergens anders.

Het neveneffect is de data

Elke telling in die voorraad-app is een meetpunt. Elke werfopname is een gedateerd dossier met foto's en metingen erbij. Elke geplande dag is een registratie van wie waar was en hoe lang.

Na een paar maanden heb je iets dat er voordien niet was: een reeks. En met een reeks kan je gaan vergelijken. Welke werven lopen structureel uit. Welke materialen raken telkens op. Welke ploeg heeft welk soort werk het snelst rond.

Dat is geen bijproduct dat je achteraf ontdekt. Het is een ontwerpkeuze. Elk van die apps schrijft naar dezelfde database, met dezelfde sleutels, zodat de drie later aan elkaar hangen. Dat kost tijdens het bouwen bijna niets extra, en achteraf is het het verschil tussen drie losse hulpmiddelen en een model van hoe die zaak draait.

Waarom dit sneller gaat dan vroeger

Eerlijk zijn: tien jaar geleden had ik dit niet voorgesteld. Drie apps laten bouwen was een project van maanden en een budget waar een aannemer met vier ploegen niet aan begint.

Dat is veranderd. Een werkende app met een database erachter, gehost en bereikbaar op een gsm, is nu een kwestie van dagen. Niet omdat ik sneller typ, maar omdat het gereedschap anders is. De hosting is een druk op de knop, de database staat er in minuten, en het schrijfwerk gaat een veelvoud sneller dan vroeger.

Dat verandert de rekensom volledig. Zelf een bron bouwen was vroeger een laatste redmiddel. Nu is het vaak gewoon de kortste weg.

Waar het niet werkt

Als je wel data hebt en ze is alleen rommelig, dan is dit niet je oplossing. Dan ga je gewoon opruimen en koppelen, en dat is sneller.

En als het proces op de werkvloer niet klopt, lost een app dat niet op. Een telling die niemand doet, levert geen voorraadcijfer. De vraag "gaan mensen dit echt gebruiken" komt voor de vraag "wat gaan we bouwen", niet erna.

De stelling

Werken met de data die je hebt, is een goede regel tot ze geen data hebben. Dan is de eerlijke vraag niet hoe je meer uit het bestaande haalt, maar wat je vandaag kan laten ontstaan zodat je het over een half jaar wel weet.