Een automatisering testen voor de livegang

De bouwer zegt dat het werkt, de demo liep goed, en toch wil niemand de eerste echte order erdoorheen sturen. Een demo bewijst dat het proces werkt op de gevallen die de bouwer heeft bedacht. Het gaat mis op de gevallen die hij niet heeft bedacht, en die zitten in uw administratie, niet in de zijne.

De vraag

Hoe weet u zeker dat een nieuwe automatisering klopt voordat hij live gaat?

Het antwoord

Zeker weten kan niet. Wat wel kan, is de kans op een verrassing zo klein maken dat de eerste verrassing geen schade doet. Dat gebeurt in vier delen, en het zwaartepunt ligt niet bij de bouwer maar bij u.

Het begint met uw eigen data. Niet vijf keurige testorders, maar een export van de laatste drie maanden, met alles wat u daar liever niet in had gezien: de klant die zijn bestelling in de onderwerpregel zet, de leverancier die twee facturen in één pdf stuurt, het bedrag met een komma waar een punt hoort. Een automatisering die alleen op schone voorbeelden is getest, is getest op een bedrijf dat u niet hebt. Wie deze randgevallen kent, is degene die het werk nu doet. Vraag die persoon een middag om alles op te zoeken wat de laatste tijd handwerk opleverde.

Daarna probeert u het kapot te maken, expres. Stuur een order twee keer. Stuur er een zonder klantnummer. Haal een verplicht veld leeg. De vraag is niet of het proces dan doorgaat, maar wat het doet als het niet doorgaat: stopt het netjes, meldt het iets, en is te zien waar het bleef steken? Een automatisering die bij een fout stilvalt zonder geluid is gevaarlijker dan een die helemaal niet werkt, want die tweede merkt u meteen. In de aanpak van Werkritme is dit stap 5: met uw data en uw randgevallen, met de uitdrukkelijke bedoeling het proces te breken voordat het in productie komt.

Het derde deel is het makkelijkst over te slaan: laat het nieuwe proces een tijd meedraaien naast het handwerk, zonder dat het iets beslist. Het handwerk blijft leidend, de automatisering doet hetzelfde werk in de schaduw, en elke dag legt iemand de twee uitkomsten naast elkaar. Het is de huiselijke variant van wat in softwareontwikkeling een parallel run met reconciliatie heet. Thoughtworks zette die techniek in de Technology Radar van oktober 2020 in de ring "Trial", de moeite van het proberen waard, juist voor het vervangen van iets dat al draait: dezelfde productiestroom door oud en nieuw, de oude uitkomst als antwoord, en de twee vergelijken. Voor een kleine administratie is dat eenvoudig: bijvoorbeeld twee weken lang een lijst van wat de automatisering had gedaan naast wat de collega heeft gedaan. Elke afwijking is een fout in de bouw of een regel die niemand ooit had opgeschreven. Allebei wilt u weten voordat er een factuur de deur uitgaat.

Pas dan gaat het live, en ook dan niet ineens. De eerste weken blijft er een controlestap staan; de veelgestelde vragen zeggen het zo: een extra controlestap die u zelf afbouwt zodra u het vertrouwt. In de eenvoudigste vorm zet de automatisering de order klaar en keurt een mens hem goed met één klik. Doet die goedkeuring dagenlang niets anders dan ja zeggen, dan kan de stap weg.

Wanneer dit niet genoeg is

Dit werkt bij werk dat vaak terugkomt en meestal op elkaar lijkt. Komt een geval maar een paar keer per jaar voor, dan zit het zelden in een export van drie maanden en zelden in twee weken meedraaien. Zulke gevallen moet u benoemen en buiten de automatisering houden, met een route naar een mens, want een test op historische data vindt ze niet vanzelf. En een proces dat naar buiten toe iets onomkeerbaars doet, zoals een betaling of een bericht aan een klant, verdient een controlestap die langer blijft staan dan een paar weken.

De test die het meeste oplevert is de saaiste: het handwerk nog even niet loslaten. Iedereen wil het snel afronden, de bouwer omdat het klaar is, u omdat u ervoor betaalt. Een paar weken dubbel werk is de prijs voor de zekerheid die een demo niet geeft.