Wat is de echte werkstroom, en waarom weet niemand het precies?
Ieder bedrijf heeft een beschreven proces en een werkelijk proces. Die twee lopen uiteen, soms een beetje, soms fors. Het beschreven proces staat in een handleiding of een oud functioneel ontwerp. Het werkelijke proces zit in de hoofden van de mensen die al jaren met het systeem werken. Zij weten welke velden ze negeren, welke workarounds ze toepassen en welke stappen ze in een andere volgorde uitvoeren dan het systeem verwacht. Als je begint met herontwikkelen zonder dat eerst boven tafel te krijgen, bouw je de inefficiëntie gewoon opnieuw in. Netter dan voorheen, maar even vastgeroest.
Hoe ziet een geblokkeerde flow er in de praktijk uit?
Een veelvoorkomend patroon: de flow stokt niet bij de complexe stappen, maar bij de simpele overgangen. Een order staat klaar, maar de volgende afdeling weet het niet omdat de melding in een mailbox terechtkomt die twee keer per dag wordt gelezen. Of een document is geaccordeerd, maar het systeem toont het nog als 'in behandeling' omdat de statusupdate handmatig moet. Die micro-blokkades klinken onbeduidend, maar bij honderd orders per dag tellen ze op. Wanneer je het systeem opnieuw bouwt, heb je de kans om die overgangen te automatiseren en de status altijd zichtbaar te maken. Maar alleen als je ze eerst hebt herkend als blokkade, niet als normaal.
Wanneer loont herontwikkelen software echt?
Herontwikkelen loont als het bestaande systeem de werkstroom stuurt in plaats van ondersteunt. Dat klinkt abstract, maar is concreet te herkennen: mensen passen hun manier van werken aan het systeem aan, in plaats van andersom. Ze exporteren data naar Excel om er iets mee te kunnen doen. Ze houden een schaduwadministratie bij omdat het systeem de informatie niet op de juiste plek toont. Ze wachten op rapporten die te laat komen. In die situaties biedt een nieuw, op maat gebouwd systeem directe operationele winst, omdat het de daadwerkelijke flow volgt. Een standaardpakket biedt die ruimte zelden, omdat het ontworpen is voor een gemiddeld bedrijf, niet voor jouw specifieke stroom.
Wat leer je in de eerste weken van een herontwikkelproject?
De eerste weken van een herontwikkelproject zijn altijd onthullend. Je inventariseert de huidige staat, en dat proces levert bijna altijd verrassingen op. Systemen die aan elkaar hangen met koppelingen die niemand meer begrijpt. Velden die worden ingevuld met codes die ergens in iemands hoofd zitten. Koppelingen naar externe partijen die op geen enkel diagram staan. Dit zijn geen problemen van het nieuwe systeem, het zijn problemen van de huidige operatie die zichtbaar worden zodra je ze kaart. Het leermoment: de herontwikkeling begint niet bij de code, maar bij het in kaart brengen van wat er werkelijk stroomt, waar het ophoudt en waarom. Daarna pas schrijf je het eerste module-ontwerp.
Wat betekent dit voor hoe je het aanpakt?
De praktische conclusie is deze: plan bij herontwikkelen altijd een ontdekfase in voordat je iets bouwt. Niet een weekje, maar lang genoeg om de mensen te spreken die het systeem dagelijks gebruiken, niet alleen de managers die het beschrijven. Laat de daadwerkelijke handelingen zien, scherm voor scherm, stap voor stap. Vraag niet wat er fout gaat, maar vraag wat mensen doen als het systeem ze niet geeft wat ze nodig hebben. Het antwoord op die vraag tekent de flow nauwkeuriger dan elk processchema. Bonsai hanteert milestones met go/no-go momenten: na de ontdekfase toets je samen of het beeld klopt en of bouwen de juiste volgende stap is. De klant blijft eigenaar, van de data, de code en de beslissing.