Kunt u aantonen wat het systeem deed?

Dinsdag, kwart over tien. Een klant van een groothandel belt: op de factuur van vorige week staan twaalf dozen, hij had twaalf stuks besteld. De medewerker die opneemt heeft de order niet zelf ingevoerd. Dat deed sinds maart een koppeling die inkooporders uit de mailbox leest en in het ERP zet. De vraag aan de telefoon is simpel. De vraag erachter is dat niet: wie of wat heeft van twaalf stuks twaalf dozen gemaakt, en hoe bewijst u dat?

Wat volgt is een typisch geval, geen klant van ons. Het laat zien wat een logboek moet bevatten om zo'n vraag te beantwoorden, en waarom een logboek dat alleen storingen bijhoudt dat niet kan.

Van achter naar voren

Een storing zoekt u van voren naar achteren, een verkeerde uitkomst van achteren naar voren. U begint bij wat de klant in handen heeft: de factuur. Elke stap terug moet één vraag beantwoorden: waar kwam dit vandaan?

De factuur staat in het boekhoudpakket, met een ordernummer. Het ERP kent dat ordernummer en laat zien dat de orderregel "12 DS" is aangemaakt op 19 augustus, 08:14, door de gebruiker koppeling-orders. Dat is het eerste dat een logboek moet kunnen: de handeling toeschrijven aan een proces, niet aan wie toevallig was ingelogd. Hier houdt het ERP op. Het weet wat er is ingevoerd, niet waarom.

Voor het waarom moet u naar het logboek van de koppeling zelf. Daar staat per verwerkte order een reeks regels. Voor deze order, ingekort:

`` 19-08 08:14:02 order 24-3187 ERP-boeking regel 3: art 40118, 12 DS ok 19-08 08:13:58 order 24-3187 eenheid "12" zonder eenheid -> DS (regel: standaardeenheid art 40118) 19-08 08:13:57 order 24-3187 uitlezen model X, PDF a91f3c…, regel 3: aantal 12, eenheid leeg, zekerheid 0,97 19-08 08:13:55 order 24-3187 ontvangst mail van inkoop@[klant], bijlage order-3187.pdf (a91f3c…) ``

Vier regels, en de oorzaak staat erin. De PDF van de klant vermeldde een aantal zonder eenheid. Het model las dat correct: twaalf, eenheid leeg, met hoge zekerheid. Daarna paste een vaste regel de standaardeenheid van het artikel toe, en die staat in het ERP op "doos". Niet het model heeft gemist, de regel heeft ingevuld wat niemand had opgeschreven. De klant bestelt dit artikel meestal per doos, vandaar de standaard, en deze ene keer niet.

Wat het logboek moest bevatten om dit te kunnen

Het antwoord zat in wat er naast de uitkomst was vastgelegd. De invoer zelf, of een verwijzing die ernaartoe leidt: het PDF-bestand met een controlegetal, zodat u zeker weet dat u naar hetzelfde document kijkt als het proces toen. Daarnaast de tussenstap: niet alleen "regel 3: 12 DS", maar wat er werd uitgelezen vóórdat er een regel overheen ging. Zonder die tussenregel had het eruitgezien alsof het model "DS" had verzonnen. En bij elke stap het mechanisme dat hem nam: een model met een zekerheidsscore, of een vaste regel met een naam. Dat is precies wat wij bedoelen als we op de vragenpagina schrijven dat elke verwerking terug te zien is in het logboek: welk model, welke invoer, welke uitkomst.

Een logboek dat alleen fouten registreert, had hier niets gemeld. Er ging technisch niets mis. De order is foutloos verwerkt naar een verkeerde uitkomst, en juist die gevallen komen niet via een foutmelding binnen maar via een klant.

De verantwoording erachter

Twee verplichtingen maken dit meer dan een handigheid. De AVG legt in artikel 5 lid 2 de verantwoordingsplicht bij u: de verwerkingsverantwoordelijke moet kunnen aantonen dat de beginselen worden nageleefd. In deze order zitten persoonsgegevens, al is het maar de naam en het mailadres van de inkoper. Wordt de PDF door een extern taalmodel gelezen, dan is een logboek dat per verwerking vastlegt welk model dat was en waar de verwerking plaatsvond een concrete manier om het aan te tonen; een logboek zonder die kolom laat de vraag open.

De tweede is ouder. De Belastingdienst verplicht u de administratie zeven jaar te bewaren, en de in- en verkoopadministratie hoort tot de basisgegevens die altijd onder die termijn vallen. De factuur bewaart u dus zeven jaar, en de inkooporder waaruit die factuur voortkwam hoort bij diezelfde in- en verkoopadministratie. Wordt het logboek van de koppeling na dertig dagen geleegd, dan bewaart u over zes jaar wel de factuur en de order, maar niet meer de schakel die uitlegt hoe het één uit het ander is ontstaan. Of het logboek zelf onder de bewaarplicht valt, hangt af van wat erin staat.

Waar het niet werkt

Dit werkt niet als het logboek de invoer niet bewaart en de klant zijn PDF inmiddels heeft overschreven. Het werkt niet als het proces zonder logboek stilvalt en de order handmatig is nagetikt; dan staat de collega weer in het ERP en is de vraag terug bij af. En het werkt niet als de koppeling meerdere stappen in één regel samenvat: "order verwerkt" zegt niets.

Wilt u weten hoe uw eigen situatie ervoor staat, neem dan één order of factuur van vorige maand die door een geautomatiseerde stap is gegaan en probeer hem terug te lezen tot de binnengekomen mail. Neem er een kwartier voor. Bij welke stap het terugkijken ophoudt, daar zit het gat, en dat weet u dan eerder dan een klant. Wat wij daarover hebben afgesproken met onszelf, staat onder "alles wordt gelogd" op de pagina over techniek en eigendom.