Werkwijze
Hoe een traject eruitziet, van eerste gesprek tot overdracht. Niet omdat elk project hetzelfde loopt, maar omdat de volgorde van denken wel steeds dezelfde is.
Het begint met een vraag uit de business, niet met een systeem
Het eerste gesprek gaat niet over techniek. Het gaat over wat er misgaat: welke beslissing wordt te laat genomen, welk werk wordt drie keer gedaan, welk cijfer wordt niet geloofd. Daarna kijk ik pas naar de systemen die eronder liggen.
Die volgorde is niet cosmetisch. Als je begint bij het systeem, bouw je wat het systeem toevallig aanbiedt. Als je begint bij de vraag, weet je waar je mag stoppen — en dat scheelt meestal het meeste geld.
Eerst kijken wat er al staat
Voor er iets gebouwd wordt, breng ik in kaart wat er is: welke bronnen, welke koppelingen, welke Excels de facto systemen zijn geworden, en wie waar handmatig tussen zit. Die inventarisatie levert bijna altijd twee dingen op: een paar dingen die eenvoudiger blijken dan gedacht, en een paar dingen die niemand had opgeschreven.
Ik ga daarbij uit van wat er staat. Bestaande systemen worden niet vervangen omdat ze me niet bevallen; ze worden ontsloten. Vervangen komt pas in beeld als het aantoonbaar goedkoper is dan aansluiten, en dan zeg ik dat er ook bij.
De kleinste oplossing die het probleem echt wegneemt
Pragmatisch betekent hier iets concreets. Het betekent: geen platform bouwen als een koppeling volstaat. Geen vijf bronnen ontsluiten als het probleem in één bron zit. Geen nieuwe tool introduceren als de tool die je al hebt het kan — ook al zou ik zelf iets anders gekozen hebben.
Het betekent ook: in kleine stukken opleveren. Liever binnen enkele weken iets werkends in productie waar je iets aan hebt, dan een half jaar bouwen aan iets compleets dat bij oplevering al niet meer de goede vraag beantwoordt. Wat werkt, blijft staan en groeit door; wat niet blijkt te werken, heeft weinig gekost.
En het betekent dat "goed genoeg" een geldig eindpunt is. Niet alles hoeft realtime. Niet elk proces hoeft een eigen applicatie. Als een dagelijkse verversing volstaat, bouw ik geen streaming-architectuur.
Keuzes worden uitgelegd, niet opgelegd
Bij elke technische keuze die er echt toe doet, leg ik uit wat de opties zijn, wat ze kosten in tijd en beheer, en waar ze je aan vastleggen. In gewone taal — je hoeft geen data engineer te zijn om mee te beslissen over je eigen systemen.
Ik kies standaard voor techniek die breed gedragen is en waar meer mensen dan ik mee uit de voeten kunnen. Exotische keuzes maken een oplossing leuk om te bouwen en lastig om over te dragen.
Wat je er tijdens het traject van merkt
Één aanspreekpunt: degene die het bouwt is degene met wie je praat. Geen accountmanager tussen de vraag en het antwoord.
Korte lijnen en zichtbare voortgang. Je krijgt regelmatig iets te zien dat draait, niet alleen een statusupdate. Vragen aan jouw kant beperken zich zoveel mogelijk tot wat alleen jij kunt beantwoorden: hoe het werk in de praktijk loopt, en wat een begrip in jouw organisatie precies betekent. Die definitievragen zijn vervelend en essentieel — daar wordt het verschil gemaakt tussen een rapportage die vertrouwd wordt en een die dat niet wordt.
Als iets tegenvalt, hoor je dat op het moment dat ik het weet. Een probleem dat je aan het eind hoort, is twee problemen.
Opleveren en overdragen
Wat er wordt opgeleverd is meer dan het scherm dat je ziet:
- De werkende oplossing in jouw omgeving, op jouw infrastructuur of een omgeving naar keuze.
- De broncode, van jou, in een repository waar jij bij kunt.
- Documentatie van de koppelingen, het datamodel en de definities: wat er waar vandaan komt en hoe het berekend is.
- Monitoring en logging, zodat storingen zichtbaar zijn voordat een gebruiker belt.
- Een overdracht aan de mensen die ermee gaan werken, en desgewenst aan je eigen IT of huidige leverancier.
Het uitgangspunt is dat je niet aan mij vastzit. Je kunt het beheer bij mij laten omdat dat handig is, niet omdat het niet anders kan. Een oplossing die alleen door de bouwer te onderhouden is, is geen oplossing maar een abonnement.
Daarna
De meeste trajecten krijgen een vervolg, omdat er in gebruik altijd iets naar boven komt wat vooraf niet te bedenken was. Dat kan in beheer, in kleine uitbreidingen, of gewoon een keer meekijken als er iets nieuws speelt. Ook als er een tijd niets is geweest — de context is er dan nog.