Checklist aanschaf informatiesystemen: archiveren by design begint bij de aanschaf

Kijk, daar is Claude-AI nu een handig hulpmiddel voor :)

Bedankt Layla

Claude-Ai is traag. Dit heb ik gemaakt met DesignerGPT. Echt een aanrader😉

Hallo Layla,

Wat ontzettend aardig dat je dit soort hulpmiddelen met ons vakgenoten deelt. Dit help mij in ieder geval om goed beslagen ten ijs te komen bij de collega's die informatiesystemen aan gaan schaffen. Blijf dat vooral doen.

Groet,

Jeroen Arkesteijn
Gemeente Mook en Middelaar

Heel lief van je, @jeroenarkesteijn75! Het is echt geen moeite voor mij en ik ben blij als ik iemand anders hiermee kan helpen😊. Fijn om te horen dat je er wat aan hebt. Hoe meer geluiden, ervaringen en inzichten we vanuit de praktijk ophalen, hoe beter. Met de huidige technologieën is het ontwikkelen van nieuwe tools en oplossingen steeds minder het probleem. De uitdaging zit vooral in hoe we die ontwikkelingen slim en gezamenlijk inzetten. Juist daarom vind ik het belangrijk dat we elkaar als community op weg helpen, kennis delen en van elkaars ervaringen leren. Zo voorkomen we dat iedereen afzonderlijk het wiel opnieuw uitvindt én dat er onnodige wildgroei ontstaat.

Fantastisch weer dat je dit deelt @laylahassan, gelijk ook alweer positieve reacties 👍. Ik heb nog wat extra trefwoorden toegevoegd aan deze bijdrage zodat deze checklist ook langere tijd zichtbaar blijft in relevante hoofdthemagroepen in het lijstje kennisproducten.

Hoi Layla,

Wat een ontzettend goed document hebben jullie opgesteld. Dit kan je uitstekend onderdeel laten uitmaken van je PvE. Een heel belangrijk punt dat ik niet kan terugvinden in de checklist is dat de structuur van de opbouw van het dossier gehandhaafd blijft bij de export. Bijna alle leveranciers exporteren platte data die dan weer gereconstrueerd moet worden door de archiefvormer zien wij vaak. Dit is een punt van echt bij de leverancier hoort te liggen en niet bij de gebruiker. Wellicht kan dit punt nog worden toegevoegd aan de checklist omdat dit de archiefvormer veel tijd scheelt bij overbrenging of migratie naar een nieuw systeem.

Hoi @marvinhughes

Dank je wel, wat fijn om te horen! En dank voor dit scherpe punt. Je hebt helemaal gelijk: platte data exporteren en de archiefvormer laten puzzelen is een bekend probleem. Die verantwoordelijkheid hoort bij de leverancier.

Dit punt zit in de checklist, maar niet in één eis. Het is verspreid over meerdere eisen die samen zorgen dat de dossierstructuur bij export intact blijft:

• R6: het systeem slaat informatie op op individueel niveau en op aggregatieniveau (dossier, zaak), met een unieke identificatiecode op beide niveaus.
• R7: het systeem legt relaties tussen archiefstukken op beide niveaus en koppelt die aan de bedrijfscontext.
• O4: bij export gaan documenten, metagegevens, logging en systeemberichten mee.
• O9: bij migratie of exit is alle informatie volledig exporteerbaar, met metagegevens, relaties en logging, inclusief een controle op volledigheid.
• C2: bij einde contract levert de leverancier alle informatie aan in een open formaat, met documentatie van het datamodel.

Mijn tip: beoordeel deze eisen in samenhang. Vraag de leverancier in een demo om een dossier te exporteren en laat zien dat de opbouw van dossier, zaak en document daarna nog klopt. Dan zie je meteen of de structuur echt behouden blijft, of dat je platte data terugkrijgt.

Dank je wel voor het meedenken. Precies hierom deel ik dit graag breed!

Hartelijke groet,
Layla

Hoi Layla,

Wat fijn dat je dit deelt! 😊

Wij gebruiken al een checklist bij de aanschaf van informatiesystemen. Toch vonden we de vertaling van het DUTO-raamwerk naar concrete eisen en vragen voor een leverancier nog best technisch.

Jij hebt dit samen met DesignerGPT een stuk eenvoudiger gemaakt. We gaan de checklist zeker gebruiken en in de praktijk testen hoe goed deze werkt. 👍

Zonnige groet vanuit Zevenaar!

Hoi @ariannezwaan, fijn om te horen dat dit eenvoudig en toepasbaar oogt. Ik hoor graag wat je ervaringen zijn als je het hebt getest. Tips zijn natuurlijk altijd van harte welkom :-)!

Hoi Layla,

Mooi werk weer. Ik heb het meteen bij mijn collega's voorgelegd om dit te gaan gebruiken. Ik was zelf al aan het worstelen om alle eisen 'ergens' in de aanbestedingsstukken te krijgen. Dit helpt enorm, dank je wel!

Fijn en graag gedaan @danielboongerrits :-)!

Mooi lijst met eisen. Ik gebruik een dergelijke lijst al enkele jaren, ook gebaseerd op het DUTO raamwerk, en ervaar dat het selecteren van relevante eisen voor elk PvE weer maatwerk is en betrokkenheid van informatiebeheer vereist. In die zin denk ik te zien dat de lijst te weinig rekening houdt met differentiatie in projecten, waardoor de beoordeling M/S/C niet altijd klopt. Ter illustratie: voor een applicatie met alleen kort te bewaren informatie is het niet nodig dat er een signalering op naderen van de overbrengingstermijn in zit. Ik heb niet gecontroleerd wat er gebeurd met de opbouw van de Excel als je niet relevante eisen eruit haalt.

Al typende denk ik dat de lijst alleen bedoeld is voor applicaties waar permanent te bewaren informatie in zit, klopt dat?

En ik zou overbrengen en migratie niet op 1 hoop gooien, overbrenging kan een migratie zijn, maar hoeft niet.

Je blijft maar gaan @laylahassan!

Hoi @lindaklaase

Dank je wel voor je reactie en voor het delen van je ervaring. Je raakt precies de kern: een lijst met eisen is een startpunt, geen kant-en-klaar PvE. Het selecteren van de relevante eisen is maatwerk en vraagt betrokkenheid van informatiebeheer. Dat staat ook in de checklist zelf: eis A1 vraagt om betrokkenheid van de archivaris en informatiebeheer vanaf de start. In de leeswijzer staat dat je de MoSCoW-weging aanpast op de risicobeoordeling van je eigen organisatie. Maar je hebt gelijk dat de lijst die differentiatie nog niet zichtbaar maakt.

Op je vraag: nee, de lijst is niet alleen bedoeld voor applicaties met blijvend te bewaren informatie. De eisen voor registreren, vernietigen, bewaren en ter beschikking stellen gelden voor vrijwel elke applicatie. De eisen over overbrenging, zoals de B-lijst, de signalering van de overbrengingstermijn en de openbaarheidsbeperkingen, zijn alleen relevant als er blijvend te bewaren informatie in zit. Jouw voorbeeld klopt dus: bij een applicatie met alleen kort te bewaren informatie is die signalering overbodig, en dan hoort die eis ook geen M te zijn.

Over de Excel: je kunt eisen verwijderen zonder dat het dashboard breekt, want de telling past zich aan. Mooier is het om eisen niet te verwijderen, maar per eis te kunnen aangeven of die van toepassing is. Dan maak je de keuze zichtbaar en rekent het dashboard alleen met de relevante eisen.

En overbrengen en migreren: terecht punt. Overbrenging is het overdragen van de zorg voor blijvend te bewaren informatie aan de archiefbewaarplaats. Dat kan gepaard gaan met een migratie, maar hoeft niet. Migratie is een eigen DUTO-proces dat ook los van overbrenging speelt, bijvoorbeeld bij een systeemwissel. Die twee verdienen een eigen plek.

Ik neem beide punten mee in een volgende versie: een kolom "Van toepassing" en een aparte indeling voor overbrengen en migreren. Dank je wel voor het meedenken, hier wordt de lijst echt beter van!

Hartelijke groet,
Layla

Er schoten me nog een paar punten binnen: we gaan er steeds meer vanuit dat applicaties op zichzelf kunnen bewaren en vernietigen, maar de realiteit in gemeenteland is nog heel vaak dat applicatie daarvoor gekoppeld worden aan een zaaksysteem. Dat vergt weer andere eisen omtrent het meenemen van metadata over de koppeling en het terugsturen van een signaal dat leidt tot vernietiging in de bronapplicatie (wat wel onmogelijk lijkt in de markt, maar niet gevraagd is altijd nee).

Wat betreft api's: ik vind dat we veel strenger moeten zijn op de informatie die via een api uitgewisseld kan worden, ik heb te vaak meegemaakt dat de coole api een uitgeklede kloppeling bleek. Ik zou in de lijst een opmerking voor de opsteller van het PvE toevoegen dat dit per project uitgewerkt moet worden.

Ik zie een aantal keer het woord archiefstukken terugkomen, die zou ik vervangen door informatie. Dat wordt veel breder geïnterpreteerd, men denkt anders al gauw alleen aan bestanden (erger nog, alleen aan PDF's), maar een inverted index hoort er ook bij.

Ook informatiewetgeving die vaak vergeten wordt in PvE's: WEP en WOO, vooral de publicatievereisten. Specifieke eisen hiervoor zijn sterk afhankelijk van het informatielandschap van de organisatie, maar er zijn eisen te bedenken voor verschillende situaties.

Hoi @lindaklaase

Dank je wel, wat fijn dat je zo grondig meedenkt :-)! Een paar punten neem ik graag over, op een paar andere geef ik je graag tegengas ;).

Koppeling met het zaaksysteem
De lijst gaat er niet van uit dat applicaties zelfstandig bewaren en vernietigen. De eisen uit Bijlage V zijn juist gebouwd op het gemeentelijke scenario met een zaaksysteem: de V-lijst en de B-lijst gaan naar het zaaksysteem (V1 en O1). Eis V4 vraagt dat vernietiging plaatsvindt op alle opslaglocaties, dus ook in de bronapplicatie. Wat wel ontbreekt, is de expliciete eis dat metadata over de koppeling wordt meegenomen, en dat een vernietigingssignaal vanuit het zaaksysteem terugkomt in de bron. En je hebt helemaal gelijk: niet gevraagd is altijd nee. Dat neem ik mee.

API's
Eens dat een API te vaak een uitgeklede koppeling blijkt. Maar strengere eisen in een generieke lijst lossen dat niet op, want wat een API moet uitwisselen verschilt per project. Daarom vraagt eis T4 om een gedocumenteerde API. De tip in de checklist is om het in een demo te laten zien, niet te laten beloven. Jouw voorstel voor een opmerking aan de opsteller van het PvE is een goede aanvulling. Die voeg ik toe.

Archiefstukken of informatie
In de meeste eisen staat al "informatie" of "informatieobjecten". "Archiefstukken" komt alleen terug waar de eis letterlijk uit Bijlage V en NEN-ISO 16175-1 komt, om herleidbaar te blijven naar de bron. Je punt dat mensen dan alleen aan pdf's denken is terecht, dus ik trek het gelijk. Bij de inverted index plaats ik wel een kanttekening. Een zoekindex is afgeleide informatie. Die hoort mee in de vernietiging, anders blijft er informatie achter die weg had gemoeten, en dat dekt V4. Maar die hoeft niet bewaard of overgebracht te worden. "Informatie" breed opvatten betekent dus niet dat alles dezelfde eisen krijgt.

WEP en Woo
Terecht dat die vaak vergeten worden. De checklist raakt de Woo nu alleen aan via publicatie en lakken (T3 en T4), en de WEP ontbreekt. Je zegt het zelf al: specifieke eisen hangen sterk af van het informatielandschap. Dat pleit voor een aanvulling per situatie, bijvoorbeeld met of zonder eigen publicatievoorziening, en niet voor vaste eisen voor iedereen.

Ik neem deze punten mee in de volgende versie. Dank je wel, hier wordt de lijst echt sterker van!

Hartelijke groet,
Layla