Een geplande taak is pas automatisering als fouten zichtbaar zijn

Een webshop laat iedere nacht openstaande orders controleren. Op maandagochtend blijkt dat die controle drie nachten niet heeft gedraaid. De planning werkte op papier, maar niemand had een melding ingericht. Een taak op een tijdstip zetten is nog geen betrouwbare automatisering.

Neon kondigt aan dat Neon Functions op een schema kunnen draaien. Dat is nuttig voor terugkerend werk dicht bij je database. Mijn stelling: bouw niet eerst de planning en bedenk daarna hoe je fouten opvangt. Ontwerp de taak vanaf het begin alsof ze een keer niet draait, halverwege stopt of dubbel wordt gestart. Bron: https://neon.com/blog/your-neon-functions-can-now-run-on-a-schedule.

Het schema is het makkelijke deel

Denk aan een installatiebedrijf dat iedere ochtend werkbonnen van de vorige dag klaarzet voor controle. Of een accountantskantoor dat aan het einde van de maand dossiers markeert waarin nog stukken ontbreken. Zulke taken hebben een duidelijk ritme en gegevens uit de eigen administratie nodig.

Toch zit het risico niet in de vraag of een taak om 06.00 uur kan starten. Het zit in wat er gebeurt wanneer de database tijdelijk onbereikbaar is, een record onverwachte gegevens bevat of de taak na twintig van de vijftig werkbonnen stopt. Als de medewerker alleen het eindresultaat ziet, ontdekt die het probleem vaak pas wanneer iemand belt.

Schrijf daarom vóór de bouw één zin op: hoe ziet een geslaagde uitvoering eruit? Voor de werkbonnen kan dat zijn: alle bonnen van gisteren hebben vóór 08.00 uur een controle-status, of staan met reden op een foutenlijst. ‘De taak heeft gedraaid’ is geen goed antwoord. Een proces kan technisch klaar zijn en zakelijk toch onvolledig.

Kies eerst de grens van de taak

Een geplande functie is aantrekkelijk omdat ze werk kan uitvoeren zonder dat iemand op een knop drukt. Juist daarom moet je klein beginnen. Laat een taak bijvoorbeeld ontbrekende factuurgegevens signaleren, niet meteen facturen versturen, klanten mailen en dossiers afsluiten.

Dat verschil is praktisch. Een foutieve signalering kan een medewerker controleren. Een foutief verstuurde factuur vraagt herstel buiten je systeem. Hoe moeilijker een handeling terug te draaien is, hoe minder je aan één geplande taak moet overlaten.

Mijn voorkeursvolgorde voor een eerste versie is simpel: selecteer de relevante records, leg per record vast wat er moet gebeuren en toon uitzonderingen aan een verantwoordelijke. Voeg automatische vervolgstappen pas toe wanneer je weet hoeveel uitzonderingen er in de praktijk zijn. Zo leer je van echte gegevens zonder meteen een heel bedrijfsproces onzichtbaar te maken.

Drie fouten die je vooraf kunt ontwerpen

De eerste is een gemiste uitvoering. Als de ochtendtaak niet draait, moet iemand dat merken vóór de werkdag erop gebouwd wordt. Bewaar daarom per uitvoering een starttijd, eindtijd, status en aantal verwerkte records. Spreek ook af wie een melding krijgt als er om 08.00 uur geen geslaagde uitvoering zichtbaar is.

De tweede is een gedeeltelijke uitvoering. Stel dat vijftig dossiers gecontroleerd moeten worden en de taak na dossier twintig stopt. Eén algemene status ‘mislukt’ vertelt te weinig. Leg per dossier vast of het is verwerkt, overgeslagen of vastgelopen, met een korte foutreden. Dan kan iemand gericht herstellen in plaats van alles opnieuw te doen.

De derde is een dubbele uitvoering. Een medewerker start de taak handmatig opnieuw, terwijl de geplande uitvoering alsnog begint. Zonder bescherming ontstaan dubbele meldingen of wijzigingen. Geef elke verwerking daarom een herkenbare sleutel, bijvoorbeeld taaktype plus dossiernummer plus periode. Controleer vóór een wijziging of die combinatie al succesvol is afgehandeld. Dat heet idempotent werken: opnieuw proberen mag, dubbel effect niet.

Die drie controles zijn geen technische luxe. Ze bepalen of je bij een storing binnen tien minuten weet wat er misging, of een halve dag records met de hand moet vergelijken. De exacte inrichting hangt af van je eigen systeem; de aankondiging van een schema neemt dit ontwerpwerk niet van je over.

Een voorbeeld: de maandelijkse dossiercontrole

Neem een kantoor met 400 actieve dossiers. Op de eerste werkdag van de maand wil het weten welke dossiers een ontbrekend document hebben. Een geplande taak leest de dossierstatus, maakt een overzicht en zet uitzonderingen klaar voor de dossierbehandelaar. Dat is een afgebakende toepassing: de taak neemt geen inhoudelijk besluit over de klant.

Stel dat 37 dossiers aandacht vragen. Dan is ‘37 gevonden’ een bruikbaar controlegetal. Bij de volgende uitvoering kun je zien of het aantal sterk afwijkt en of alle 400 dossiers zijn beoordeeld. Als er slechts 250 zijn verwerkt, hoort het overzicht niet als compleet te verschijnen.

Laat de taak ook vastleggen welke peildatum ze gebruikt. Een controle op de eerste werkdag kan gegevens van de voorafgaande maand nodig hebben. Als je alleen ‘nu’ opslaat, wordt een latere herstart lastig: dezelfde taak kan dan ongemerkt een andere selectie maken. Een expliciete periode maakt het resultaat reproduceerbaar.

Voor dit soort werk is de winst niet dat een computer 400 dossiers kan lezen. De winst is dat een medewerker elke maand dezelfde controle op dezelfde manier krijgt, inclusief de gevallen die aandacht vragen. Reken tijdwinst dus pas mee nadat je ook herstelwerk, uitzonderingen en controle hebt gemeten.

Wanneer je dit juist niet moet plannen

Niet ieder proces wordt beter van een vaste tijd. Een voorraadwijziging die direct invloed heeft op wat een klant kan bestellen, vraagt mogelijk een reactie op de gebeurtenis zelf. Een taak die maar één keer per kwartaal voorkomt en telkens menselijk oordeel vraagt, is vaak beter als controlelijst dan als automatische functie.

Let ook op toegang tot gegevens. Een taak die ‘voor het gemak’ alle klantrecords mag wijzigen, heeft meer rechten dan nodig voor een maandelijkse controle. Beperk de toegang tot de gegevens en handelingen die voor die ene taak nodig zijn. Bewaar in het logboek bij voorkeur recordnummers en foutcodes, niet onnodig volledige klantgegevens.

En maak de planning begrijpelijk voor de mensen die ermee werken. ‘Elke dag om 06.00 uur’ lijkt helder, totdat zomertijd, feestdagen of een vertraagde aanlevering meespelen. Leg vast welke tijdzone, welke peildatum en welke uiterste oplevertijd gelden. Dat zijn bedrijfsafspraken, geen details die een ontwikkelaar in zijn eentje moet raden.

Wat je maandag kunt doen

Kies één terugkerende controle die nu handmatig gebeurt en waarvan een gemiste uitvoering vervelend, maar herstelbaar is. Teken de route op één pagina: welke records gaan erin, welk resultaat moet eruit komen, wie ziet de uitzonderingen en wanneer is het resultaat te laat? Pas daarna beslis je waar de geplande taak draait.

Bouw vervolgens een proef waarin je bewust drie situaties veroorzaakt: één record met ongeldige gegevens, een onderbroken uitvoering en een tweede start van dezelfde periode. Als je team voor elk geval kan aanwijzen wat wel en niet is verwerkt, heb je een basis voor productie. Lukt dat niet, dan is de planning nog niet het probleem dat je moet oplossen.

Neon Functions op een schema maken terugkerend databasewerk interessanter. Maar de waarde voor een MKB-bedrijf ontstaat niet bij de klok. Die ontstaat wanneer een gemiste, gedeeltelijke of dubbele uitvoering zichtbaar blijft en zonder giswerk te herstellen is. Automatiseer niet alleen het werk, automatiseer ook het bewijs dat het werk goed ging.