Het gesprek voordat we beginnen te bouwen

Regelmatig begint een gesprek niet met een probleem, maar met een antwoord. “We willen een app voor onze monteurs.” “We willen een dashboard waar iedereen inzicht heeft.” “Kun je dit systeem koppelen aan dat systeem.” De oplossing zit er al in voordat we ook maar weten wat er misgaat. Dat is het beginpunt van bijna elk project bij ons, en het is precies het punt waar we niet beginnen met bouwen, maar met vragen stellen.

De oplossing komt eerder dan het probleem

Iemand die belt heeft er meestal al over nagedacht. Hij heeft gezien hoe een ander bedrijf iets deed, of een collega heeft ergens een demo gevolgd, of hij heeft zelf een tijdje gezocht naar wat andere bedrijven gebruiken. Tegen de tijd dat hij ons belt, heeft hij al een naam voor wat hij wil: een app, een portaal, een koppeling. Dat is niet gek. Wie een probleem ervaart, gaat op zoek naar iets wat het oplost, en het eerste wat je vindt is meestal het concreetste: een stuk software met een naam erop.

Het punt is dat die oplossing bedacht is zonder dat iemand precies heeft uitgezocht waar het echt misgaat. Een app voor monteurs lost niets op als het probleem is dat niemand weet welke informatie op kantoor terecht moet komen. Een dashboard heeft geen zin als de cijfers die erin moeten er nog niet betrouwbaar zijn. Een koppeling tussen twee systemen werkt niet als in beide systemen andere definities van dezelfde klant rondlopen.

Waarom dat zo vaak gebeurt

Dit komt niet doordat ondernemers slecht nadenken. Het komt doordat je binnen je eigen bedrijf te dicht op het probleem staat om te zien waar het precies vandaan komt. Een proces is jaren geleden ontstaan als praktische oplossing voor iets kleins: een Excel-bestand om orders bij te houden, een mailtje als goedkeuring, een telefoontje als iets snel moest. Dat werkte, tot het bedrijf groeide en er meer mensen, meer klanten en meer uitzonderingen bij kwamen. Op een gegeven moment merk je alleen nog de symptomen: dubbel werk, fouten, een collega die alles in haar hoofd heeft zitten. De oorzaak zit dieper, en die zie je pas als iemand van buiten meekijkt.

Het gesprek dat we voeren

Voordat we iets bouwen, zitten we eerst een uur met de ondernemer om het huidige proces in kaart te brengen. Niet de wensen, het proces zoals het nu daadwerkelijk loopt. Wie doet wat, in welke volgorde, met welk bestand of welk systeem, en wat gebeurt er als iemand ziek is of een klant iets ongebruikelijks vraagt. We vragen naar de momenten waarop het misgaat: waar ontstaan de fouten, wie merkt ze als eerste, en hoeveel tijd kost het om ze te herstellen.

Uit dat gesprek komt geregeld een ander antwoord dan waarmee iemand belde. Soms blijkt dat er helemaal geen nieuwe applicatie nodig is en dat het bestaande Excel-bestand vervangen door een goed opgezette structuur al genoeg oplevert. Soms blijkt dat de vraag juist te klein was: niet één koppeling, maar een compleet klantportaal waarin klanten zelf hun status kunnen zien, scheelt uiteindelijk meer telefoontjes dan de ene koppeling die gevraagd werd. En soms is de conclusie dat er nog niets gebouwd moet worden, omdat eerst iemand intern verantwoordelijk moet worden voor de data die erin komt. Die conclusie leveren we net zo makkelijk als een voorstel om te starten.

Wat dat oplevert, en waar het ophoudt

Het resultaat van dat eerste gesprek is een scherpere vraag. Niet “bouw een app”, maar bijvoorbeeld “zorg dat een monteur op locatie kan zien welke onderdelen op voorraad zijn, en dat die voorraad automatisch bijwerkt”. Dat is een vraag waar je een goede prijs en een goede planning op kunt maken, en waarvan je vooraf weet of hij het probleem daadwerkelijk raakt. Zonder dat gesprek bouw je iets dat op papier klopt met de wens, maar dat na oplevering het onderliggende probleem gewoon laat bestaan.

Er is ook een grens aan wat dit gesprek oplost. Software lost een proces op, geen organisatie. Als niemand de verantwoordelijkheid wil dragen om gegevens actueel te houden, of als twee afdelingen het structureel oneens zijn over wie de klant “bezit”, dan verandert een nieuw systeem daar niets aan. Dat merken we soms pas na een paar vragen door, en dan zeggen we dat ook. Onze aanpak begint daarom altijd met dat gesprek, niet met een offerte.

Het is misschien het minst spannende deel van een project: een uur praten voordat er iets gebouwd wordt. Maar het scheelt achteraf het meeste tijd, en het voorkomt dat je betaalt voor iets wat je probleem niet raakt.