Het requirementsdocument zei dat een aanvraag één goedkeuringsstap had.
Het Excelbestand vertelde een ander verhaal. Gele cellen betekenden “nog even navragen”, rood was “niet leveren”, drie verborgen tabbladen bevatten uitzonderingen en in de opmerkingen stond wie er gebeld moest worden als een klant haast had.
Dat bestand was niet netjes. Het was wel eerlijk.
Het officiële proces bestaat vooral op papier
Wanneer bedrijven software willen laten bouwen, ontstaat al snel een lijst met functies. Gebruikers moeten kunnen inloggen, aanvragen invoeren, documenten uploaden, goedkeuren en rapporteren.
Dat is nuttig, maar het beschrijft vooral wat de nieuwe software zichtbaar moet kunnen. Het vertelt nog niet hoe het werk werkelijk verloopt.
In de praktijk zit cruciale informatie vaak ergens anders:
- een persoonlijk Excelbestand;
- een map met e-mails die als takenlijst wordt gebruikt;
- een whiteboard met magneten;
- een papieren formulier met handgeschreven codes;
- een WhatsApp-groep waarin de echte planning wordt gecorrigeerd;
- of één ervaren medewerker die alle uitzonderingen uit zijn hoofd kent.
Het officiële proces staat in een document. Het werkelijke proces zit in de omwegen.
De workaround is niet automatisch het probleem
Workarounds hebben een slechte naam. Ze zouden bewijzen dat medewerkers niet volgens het proces werken. Dus worden ze tijdens een nieuw softwareproject soms weggepoetst: in het nieuwe systeem doen we het voortaan zoals het hoort.
Maar een workaround kan twee dingen betekenen.
Hij kan onnodige rommel zijn die ooit ontstond en nooit is opgeruimd. Of hij kan een slimme reactie zijn op een uitzondering die het officiële proces niet aankan.
Stel dat een planner iedere ochtend een Excel-export maakt en drie klanten geel markeert. Dat lijkt dubbel werk. Tot blijkt dat deze klanten alleen geleverd mogen krijgen als een specifieke laadplaats beschikbaar is, terwijl die informatie niet in het huidige plansysteem staat.
Automatiseer je het officiële proces zonder die kennis, dan verdwijnt het gele vlak maar niet het bedrijfsrisico.
Vraag om een rondleiding, geen presentatie
Bij Byte Me horen we graag wat een organisatie wil bereiken. Daarna willen we het werk zien.
Niet alleen een gepolijste presentatie van het proces, maar een gewone dinsdagmiddag. Welke schermen staan tegelijk open? Welke gegevens worden overgetypt? Wanneer loopt iemand naar een collega? Welke stap wordt altijd gecontroleerd, ook al zegt het systeem dat alles klopt?
We vragen mensen om de laatste echte aanvraag te laten zien. Niet hoe het gemiddeld gaat, maar wat er gisteren gebeurde. Concrete voorbeelden maken abstracte woorden scherp.
“De manager keurt goed” wordt dan: de teamleider beoordeelt bedragen tot €10.000, behalve bij nieuwe leveranciers; dan kijkt finance altijd mee. Dat is softwarelogica waar je iets mee kunt.
Bouw niet iedere omweg na
Het doel van onderzoek is niet om alle bestaande gewoontes in code te vereeuwigen. Dan krijg je een nieuw systeem dat precies dezelfde rommel sneller uitvoert.
Iedere gevonden uitzondering vraagt om een keuze:
- bestaat de reden nog?
- hoe vaak komt dit voor?
- wat gebeurt er als we hem niet ondersteunen?
- kunnen we het proces eenvoudiger maken?
- moet de software dit oplossen of moet de organisatie een afspraak veranderen?
Soms bouwen we automatisering. Soms maken we een bewuste handmatige stap. En soms adviseren we eerst het proces op te ruimen voordat er software komt.
Maatwerk is geen kopieermachine voor bestaande werkwijzen. Het is een kans om scherper te kiezen.
Een wensenlijst mist de waarom
“We willen een exportknop” is een requirement. Waarom die export nodig is, bepaalt de oplossing.
Misschien stuurt iemand het bestand wekelijks naar finance. Dan is automatische rapportage logischer. Misschien controleert een klant één specifiek veld. Dan kan een klantportaal beter passen. Misschien wordt de export gebruikt als persoonlijke back-up omdat het systeem niet wordt vertrouwd. Dan moeten we eerst dát probleem oplossen.
Als we alleen bouwen wat wordt gevraagd, leveren we mogelijk precies de verkeerde oplossing keurig op tijd.
Wat we vóór de eerste regel code willen zien
Neem bij een eerste gesprek gerust je plannen, doelen en wensen mee. Maar breng ook de rommel mee. Het spreadsheet waar niemand aan mag komen. Het formulier met correcties. De mailboxmap met uitzonderingen. De medewerker van wie iedereen zegt dat hij “precies weet hoe het zit”.
Daar zit geen schaamte in. Daar zit de kennis waarmee goede software wordt gebouwd.
Laat je requirementsdocument dus vooral niet echt thuis. Maar leg dat Excelbestand ernaast.
De verschillen tussen die twee zijn waarschijnlijk het interessantste deel van het project.