Audits en logs

Elke handeling van een agent levert een vastlegging op: wat hem in gang zette, welke regel paste, welke tools hij aanriep met welke gegevens, wat er terugkwam, en wat hij daarna besloot.

Die vastlegging heeft drie functies, en maar één ervan is foutzoeken.

De vraag achteraf beantwoorden

Vraagt een klant waarom er iets gebeurd is, dan is “dat deed het systeem” geen antwoord dat iemand accepteert, en steeds vaker ook geen antwoord dat een toezichthouder accepteert. Een volledig logboek maakt van die vraag een opzoekactie: dit kwam binnen, deze regel gold, deze handeling volgde.

Dat vermogen wil je hebben voordat je het nodig hebt. Een beslissing reconstrueren uit een onvolledig logboek, maanden later, kan voor geen prijs.

Leesbaar voor de mensen van het proces

Een logboek dat alleen een ontwikkelaar kan duiden, is een logboek dat één keer gelezen wordt, tijdens een incident, door de verkeerde persoon. De vastlegging is geschreven om gelezen te worden door wie het proces beheert: gewone beschrijvingen van wat er gebeurde in plaats van interne codes.

De bron om te verbeteren

In het logboek zie je welke uitzonderingen blijven terugkomen. Een geval dat één keer doorgezet wordt is ruis; hetzelfde geval dat veertig keer doorgezet wordt, is óf een regel die geschreven moet worden óf een proces dat gerepareerd moet worden.

Dat is een betere routekaart dan welke plansessie ook, want hij is opgebouwd uit wat er echt gebeurde en niet uit wat mensen zich herinneren dat er gebeurde.

Bewaartermijn

Hoe lang de vastlegging bewaard blijft, wordt per opdracht afgesproken en in de verwerkersovereenkomst gezet. Oneindig bewaren is geen standaard: een logboek van elke handeling die een agent op de gegevens van jouw klanten uitvoerde, is zelf ook data, en valt onder dezelfde regels als al het andere.