In de Zaak- en Documentservices standaard (t/m de laatste versie 1.2) staat in paragraaf 5.3 beschreven welke gegevens in het DMS vastgelegd moeten worden. Daar gaat deze discussie over, wat betreft de omschrijving van het zaakdossier en de mapping vanuit de zaakomschrijving.
De omschrijving van het zaakdossier wordt niet concreet vastgelegd in het DMS. Hoewel er een aantal beschrijvende attributen zijn, zoals de zaaktypeomschrijving (in het bovenliggende zaaktypedossier) en de initiatorgegevens (in het zaakdossier zelf), is het toch voor de medewerkers van onze klanten niet altijd even makkelijk om zaakdossiers in het DMS terug te vinden. Dit komt doordat de gegevens verspreid zijn over verschillende dossiers (zaaktype- en zaakdossiers). Bovendien beschikken de gebruikers vaak niet over de unieke identificaties van de zaakdossiers, doordat ze werken met inkomende informatiestukken waar die informatie niet op staat, zoals een brief van een burger. In een aantal gevallen is het ook nodig om in het DMS digitale dossiers op te zoeken (met de zoekfunctie) op basis van sleutelwoorden.
De vraag is dus hoe jullie het zien om de zaakomschrijving uit het StUF-ZKN 3.10 (ZS-DMS) bericht te mappen op een CMIS property die het zaakdossier beschrijft, als onderwerp/titel/omschrijving van het zaakdossier (de term verschilt per DMS). Dit is namelijk niet in de Zaak- en Documentservices standaard gedefinieerd, ook al bestaat er wel een standaard StUF-ZKN 3.10 (ZS-DMS) element voor de zaakomschrijving, zodat dit ook weer niet zo snel als maatwerk te beschouwen is (wat wel met extraElementen het geval zou zijn).
Anders gezegd: Wat is erop tegen om deze functionaliteit alsnog toe te voegen, ondanks dat dit niet gespecificeerd is? Ik hoor graag wat jullie ervan vinden.
Het lastige van dit voorstel is dat de zaakomschrijving een vrije tekst is en nog steeds geen garantie dat de waarde van het veld uniek is. De enige unieke sleutel is de zaakidentificatie, daarom wordt die ook gebruikt om het zaakdossier te identificeren.
Daarnaast is het niet correct om aan te nemen dat het niet terug kunnen vinden van een dossier omdat deze gegroepeerd zijn per zaaktype. Sterker nog, dat zou het juist makkelijker moeten maken. Alle zaakdossiers mbt. het aanvragen van een parkeervergunning zullen gegroepeerd zijn onder het zaaktype "aanvraag parkeervergunning". Wanneer een dergelijk gegeven al problemen gaat geven met het terugvinden van een dossier wordt dat zeker niet opgelost door een zaakomschrijving op te nemen.
Waar dit probleem uit voort lijkt te komen is dat , als ik het goed begrijp, de gebruiker niet via een zaaksysteem (ZS) documenten opvraagt maar rechtstreeks in het DMS gaat zoeken. Wanneer de gebruiker via het ZS het dossier opvraagt moet dit geen probleem geven. Zoals de zaak- documentservices nu opgezet zijn (dit staat ook zo beschreven) is het ZS het portaal voor ontsluiting van zaakdocumenten.
Interessante discussie die toevallig ook in Nijmegen actueel is. De opmerking van Michiel is de kern: "Zoals de zaak-documentservices nu opgezet zijn (dit staat ook zo beschreven) is het ZS het portaal voor ontsluiting van zaakdocumenten." Maar zoals ik ook bij Laurens lees wordt om goede redenen ook het DMS gebruikt als portaal voor ontsluiting van zaakdocumenten. En ja, dan wil je uiteraard over alle benodigde metadata beschikken.
Ik ben nooit een fan geweest van het in een DMS anders metadateren en opslaan (bijv. clusteren via zaaktype) van documenten die toevallig aan een zaak gerelateerd zijn. Omdat er bij de start niet is gekozen voor autonome zaak- en autonome documentservices kun je problemen zoals door Laurens beschreven in mijn ogen niet echt oplossen binnen de standaard (metadata in vrije velden gaan stoppen beschouw ik als niet echt oplossen).
Mede door de ervaringen in een lopende pilot-eDepot zie ik wat ik tot nu toe als een knelpunt beschouwde nu als een breekpunt.
Ad, zou je willen aangeven welke problemen ontstaan in de pilot richting e-Depot?
In Haarlem zijn we er niet voor een aanpassing in de standaard te doen. Wanneer je in het DMS wilt zoeken op basis van zaakgegevens anders dan identificatienr dan zou dat kunnen door vanuit het DMS eerst de services van het zaakregistratiecomponent aan te roepen om identificatienummers te verkrijgen. De architectuur moet bewegen richting minder redundante gegevensopslag, in plaats van meer.
Mbt aanleveren aan een eDepot verwacht ik dat het sowieso een flinke uitdaging wordt om metadata en documenten goed aan te gaan leveren (lees: inhoudelijk conform TMLO goed gevuld en qua formaat in ToPX sidecar-structuur of ToPX-RIP). Metadata verschillend/verspreid en via een andere applicatiecomponent dan waar documenten zijn opgeslagen vastleggen maakt het in praktijk lastig(er) verwacht ik.
Maar daarover kun je uiteraard van mening verschillen, waarbij zoals zo vaak gemeentespecifieke omstandigheden ook een rol spelen. Ik pleit dan ook niet voor aanpassing van de standaard maar denk dat je moet onderkennen dat hij niet bedoeld/geschikt is om aan alle archiveringsbehoeften tegemoet te komen en je hem op verschillende manieren kunt toepassen.
Dat de huidige zaak- documentservices niet toereikend zijn voor aansluiting op een e-Depot/TMLO is al enige tijd bekend. Dat is dan ook een onderwerp van de doorontwikkeling van de standaard zoals besproken tijdens de laatste bijeenkomst van de werkgroep.
Het ontbrekende deel zit hem niet zozeer in de ZDS standaard maar in de ondergelegen standaard RGBZ1. Lang niet alle noodzakelijke gegevens om een TMLO bericht correct te vullen zijn aanwezig in het RGBZ 1 en daarmee ook niet in StUF ZKN en Zaak- Documentservices. Daarom wordt momenteel gekeken naar de (voor gemeenten) beste mogelijke manier(en) om deze gegevens wel mee te kunnen nemen in de Zaak- Documentservices.
Met dank voor de (voor mij) nieuwe info Michiel. Best een uitdaging om te bepalen wat wel en wat niet thuishoort binnen de standaard. Ik ben benieuwd wat er uit komt.