Archiveren procesgegegevens (tracking, tracing, logging, auditing)

Hallo Breed-volgers,

Op 1 december ben ik een discussie gestart over een onderwerp waarmee, vroeg of laat, DIV-afdelingen te maken krijgen.

Of het toen niet het juiste moment was, andere discussies op Breed interessanter waren, of dat het om een niet alledaagse vraag ging, feit is dat niemand gereageerd heeft. Ik doe dus een nieuwe poging. Ik ben benieuwd naar jullie reacties en, ook als je het antwoord niet weet wil ik vragen te reageren.  

Het volgende vraagstuk doet zich in onze organisatie voor: in digitale werkprocessen worden gegevens van processtappen gelogd en opgeslagen. Aan DIV is de vraag voorgelegd welke van die gegevens, tot op welke detailniveau, hoe lang bewaard moeten worden. 

Onze insteek is dat bewaring of vernietiging natuurlijk bepaald wordt door het werkproces waarvoor die gegevens zijn vastgelegd en dat de proceseigenaar verder bepaalt welke gegevens van belang kunnen zijn voor verantwoording, bewijs en reconstructie. 

Onze gedachte is verder, dat procesgegevens die van belang zijn, in de vorm van een auditrapportage middels een pdf worden opgeslagen. 

Ongetwijfeld zullen een aantal proceseigenaren daar een heldere kijk op hebben maar zij die daar minder bedreven in zijn zullen DIV om raad/advies vragen. Zij willen van DIV weten welke gegevens dan minimaal bewaard zouden moeten worden. 

Ik ben benieuwd wie van jullie al ervaring heeft met dit vraagstuk en misschien zelfs al algemene uitgangspunten heeft geformuleerd over het, al dan niet in detail, bewaren van gegevens.  

Voorbeeld: medewerkers van de gemeente Tilburg kunnen digitaal reiskosten declareren. Zij loggen in met userid en wachtwoord, stellen de declaratie op en verzenden die. Volgens een gedefinieerde workflow komt die declaratie ter goedkeuring bij de leidinggevende terecht die, ingelog met userid/wachtwoord de declaratie goedkeurt. Vervolgens komt die goedgekeurde declaratie terecht op de financiële afdeling  die zorgt voor verdere afhandeling. Iedere handeling/activiteit wordt gelogd en die gegevens worden opgeslagen. Achter iedere handeling zitten onder water subprocesjes waarvan gegevens ook worden gelogd. Wij denken dat het volstaat om de goedkeuring (logging) van de hoofdprocesstappen te bewaren maar niet de gegevens van de achterliggende  subprocessen. 

Weergaven: 443

Hierop reageren

Berichten in deze discussie

De aanhouder wint... :-D

 

Die subprocesjes zullen volledig geautomatiseerd zijn. Als je eenmaal hebt beschreven hoe die subprocessen werken, dan kun je afhankelijk van de voorliggende trigger altijd reconstrueren wat er is gebeurd. Wat lastiger is te voorspellen en dus te reconstrueren, is het menselijk handelen. Ik zou daarom alleen loggen wanneer een mens iets doet (op een knop drukken ofzo).

 

Om het helemaal netjes te doen, in je DSP kun je per proces vastleggen welke applicaties / systemen er gebruikt worden. Bij iedere applicatie / systeem kun je een beschrijving opnemen van de werking. In deze beschrijving kun je onder meer de beschrijvig van de subprocessen opnemen.

 

Aan de hand van de per zaak gelogde handelingen én de generieke subproces-beschrijvingen kun je iedere zaak tot op het kleinste detail reconstrueren. De vraag is uiteraard wel of je dat nu zo nodig vindt.

Het eerste wat me opviel is de neiging om de gegevens op te slaan als .pdf. Dat heeft voor mij hetzelfde gevoel als het uitprinten en weer inscannen van een email.
Kijk ik naar de gemeentelijke selectielijst dan heb ik het idee dat het hier gaat om:
" Gegevens, noodzakelijk voor het bepalen van de  authenticiteit, de volledigheid, de context alsmede voor het beheer van op termijn te vernietigen archiefbescheiden (metadata) "
Dat betekent volgens mij dat je eerst zelf kunt bepalen welke van de procesgegevens hier inderdaad onder vallen. Het lijkt mij dat hier geen hele algemene richtlijnen voor aan te geven zijn, dit kan in het uiterste geval per proces verschillen. En het kan natuurlijk ook andersom zijn: wellicht heb je nu systemen waarin dit soort gegevens juist niet vastgelegd/ uit geexporteerd worden, terwijl je dit vanuit het oogpunt van authenticiteit/volledigheid/context wel zou willen.  
 En hoe ga je die uiteindelijk bewaren: het mooiste lijkt mij dat het systeem zelf de mogelijkheid biedt dit soort gegevens te beheren en uiteindelijk uit te verwijderen. In het andere geval kom je waarschijnlijk tot de oplossing waarbij je er een pdf van maakt die daarmee beter beheerbaar wordt.

Een soortgelijke vraag valt overigens ook te stellen rondom zaakgericht werken: wat van de zaak wil je nu eigenlijk voor kortere of langere tijd bewaren? Dat het de documenten die bij een zaak horen, is gezien de documentgerichte selectielijst logisch.  Je ontkomt er vervolgens ook niet aan om de zaakgegevens zelf te archiveren, ze vormen tenslotte de context van je documenten. De manier waarop je dat doet  kan echter alweer verschillend zijn. Ga je een 'zaakdocument' maken waarin alle relevante zaakgegevens en behandelgegevens worden opgenomen? (ik kan me herinneren dat ik dit een aantal jaar terug heb gezien in een OZO zaakoplossing, maar dat is ruim 4 jaar geleden). Wanneer je dat niet doet ligt het voor de hand dat het zaaksysteem zelf dit soort gegevens in samenhang moet kunnen archiveren. Maar betekent het ook dat je de eventueel doorlopen statussen en de in het zaaksysteem ingevulde checklists net zo lang wilt gaan bewaren als de documenten van de zaak, of ga je daar toch nog een onderscheid in maken? En wanneer je een los DMS hebt wat gekoppeld is aan een zaaksysteem/zakenmagazijn lijkt het mij ook een uitdaging om het geheel van de zaak in samenhang digitaal te archiveren.

Dag Mart,

De selectielijst zegt over metadata onder cat. 2.11 alleen maar iets over het gecreëerde document en niet over de weg daar naartoe. Ook de Archiefregeling benoemd onder hoofdstuk 3 en met name artikel 17 metadata die alleen raken aan het moment van, en omstandigheden waaronder documenten worden gecreëerd. In dat verband kan ik mij wel vinden in de opmerking van Marco dat wanneer je “elke druk op de knop” logt, je de procesgang (workflow) kan reconstrueren. Kwestie is dus om vast te stellen of deze subprocessen hier ook aan beantwoorden, of dat het meer generieke instructieprocessen betreft.

 

Denk dat de meerwaarde van DIV bij dergelijke vragen vooral ligt in de diplomatieke en meedenkende manier waarop je de verantwoording tav de reconstructie van de procesgang / workflow bij de procesgebruiker zelf terugbrengt.. Zij moeten immers aangeven welke metadata zij zelf nodig denken te hebben om hun procestappen te verantwoorden. Als DIV medewerken kan je ze hier op wijzen zodat zij hier zelf bewuster van worden. Het is feitelijk gezien geen archivistisch vraagstuk, maar een workflow vraagstuk. Adviseer in termen van

opties, maar laat de proceseigenaar de beslissing nemen. Let wel, alleen wanneer het over procesmetadata gaat die niet raken aan de archivistische authenticiteit. Daarom ben ik er altijd voorstander van geweest (en nog) om in dit soort discussies onderscheid te maken in metadata die betrekking hebben op de procesgang zelf en die betrekking hebben op de archivistische aspecten hiervan. Niet om je ergens achter te verschuilen of je ergens makkelijk van af te maken, en ook geen ontkenning dat procesgang en de activistische neerslag in elkaar grijpen tot een integraal systeem. Maar het gaat om de wijze waarop je als DIV, eventueel als regisseur, samen met de proceseigenaar en ICT de verantwoordelijkheden mobiliseert. Je bent als DIV (kennisveld) namelijk niet verantwoordelijk voor de keuze waarop de procesgang wordt ingericht, maar wel voor de archtivistische gevolgen. Ook een kwestie van ordening.

 

Antwoorden op discussie

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden