Ik schrijf dit stuk omdat ik het zelf vaak genoeg fout heb gedaan.
De afgelopen twee jaar heb ik van alles gebouwd voor klanten. Sommige dingen werkten. Andere dingen hadden nooit gebouwd mogen worden, ook al kon het technisch wel.
Het patroon is steeds hetzelfde. Iemand ziet een mogelijkheid om te automatiseren, ik ga aan de slag, en drie weken later hebben we iets dat niemand gebruikt. Of erger: iets dat het werk lastiger maakt dan het was.
Hier zijn de vijf tests die ik nu hanteer voordat ik begin. Als een taak op drie of meer scoort, begin ik er niet aan.
Eén: hoe vaak komt het terug
Een taak die je één keer per kwartaal doet, is bijna nooit de moeite waard om te bouwen. De investering in tijd en onderhoud is hoger dan de winst.
Een taak die je dagelijks doet, is bijna altijd de moeite waard. Ook als het maar vijf minuten per keer is.
Vuistregel: als de taak minder dan vier keer per maand voorkomt, zoek ik eerst uit hoeveel uur het in een jaar kost. Meestal is dat een middag. Dan is bouwen duurder dan doen.
Twee: hoe foutgevoelig is het handwerk
Sommige taken zijn irritant omdat ze vaak terugkomen. Andere zijn irritant omdat er altijd wel iets misgaat.
Die tweede categorie is een veel betere kandidaat. Niet de frequente taak zonder fouten. Wel de foutgevoelige taak, ook als die maar één keer per week voorkomt.
Een machine maakt geen typefouten. Een machine vergeet geen stap. Een machine wordt niet moe op vrijdagmiddag. Dat is precies wat je wilt bij werk waar de gevolgen van een fout groot zijn.
Drie: is het patroon stabiel
Automatisering werkt alleen als de input en de output voorspelbaar zijn.
Als elke keer dezelfde gegevens uit hetzelfde systeem komen, in dezelfde volgorde, dan is dat een patroon. Dan kun je bouwen.
Als elke keer iemand anders bedenkt welke kolommen erin moeten, of welke berekeningen, of welke uitzonderingen, dan is het geen patroon. Dan is het maatwerk. En maatwerk automatiseren is het duurste wat er is.
Ik vraag altijd: kan iemand die het werk niet kent, in twee minuten uitleggen wat er moet gebeuren. Zo nee, dan wachten we tot het patroon stabiel is.
Vier: wie is de eigenaar van het probleem
Dit is de vraag die ik het vaakst verkeerd beantwoord heb.
Als niemand eigenaar is van het probleem, dan is er ook niemand die het opgelost wil hebben. Dan krijg je een script dat niemand gebruikt.
Ik weiger tegenwoordig te bouwen voor een commissie, een afdeling, of een vaag idee van "we zouden eigenlijk." Er moet één persoon zijn die zegt: dit is mijn probleem, dit is hoe het beter moet, en ik gebruik het resultaat elke week.
Zonder die persoon blijft het script een mooi speeltje in een map die niemand opent.
Vijf: kan ik het over twee jaar nog onderhouden
Sommige dingen die ik bouw, zijn helder en simpel. Een lijntje code dat elke ochtend data ophaalt en in een sheet zet. Dat begrijp ik over twee jaar nog.
Andere dingen zijn slimme constructies. API-koppelingen met meerdere tussenstappen. Conditionele logica die het in drie gevallen zus doet en in vier gevallen zo. Dat begrijp ik over twee maanden al niet meer.
Als ik het niet in een halve pagina kan uitleggen aan iemand zonder technische achtergrond, dan is het te ingewikkeld. Dan komt er een dag dat er iets stuk gaat, en dan zit je vast aan de bouwer.
Ik bouw alleen dingen die ik in een gesprek van tien minuten kan overdragen aan de klant. Geen vendor lock-in.
Wat ik er zelf mee doe
Deze tests klinken misschien streng. Dat is ook de bedoeling.
Ik heb liever dat ik drie dingen per jaar bouw die werken en blijven werken, dan tien dingen die binnen een jaar vergeten worden. De eerste drie betalen zichzelf terug, geven de klant vertrouwen, en zorgen voor de volgende klant. De andere tien kosten tijd, leveren weinig op, en bezorgen me slapeloze nachten als er iets misgaat.
De volgende keer dat iemand je vertelt dat iets "echt makkelijk te automatiseren" is, vraag dan door. Hoe vaak. Hoe foutgevoelig. Hoe stabiel. Wie gaat het gebruiken. Wat als jij er niet meer bent.
Als je het niet in twee zinnen kunt beantwoorden, is het geen automatisering. Het is een project. En een project is iets anders.