Welk documenttype kies je voor een bijlage bij een agenda van een vergadering (vergaderstuk)?
Een vraag die vast al eerder gesteld is, maar ik stel deze toch nog maar eens.
In ons zaaksysteem registreren wij bij een document het documenttype. Daarvoor volgen wij zoveel mogelijk de NEN2084.
Maar is dat ook nodig voor vergaderstukken bij een agenda? Of zou je dan kunnen volstaan met het te introduceren (want niet in NEN2084) type Bijlage? En wat is het argument om dat niet te doen en elk vergaderstuk het documenttype te geven wat daarop van toepassing is? De duurzame toegankelijkheid?
Bedankt voor jullie reactie.
Samenvatting: Voor advies aan een gemeente over archivering van videotulen is het heel fijn als er regels zijn voor de metadata: wat moet er in elk geval in? Mijn vraag: zijn er eerder zulke lijsten gemaakt? Het lijkt me handig om (deels) metadateerlijsten voor videotulen op elkaar te baseren.
Het metadatamodel van het e-Depot van het NA, het hiervan afgeleide XML formaat ToPX en de specificati...
Vanaf vandaag staat alle informatie over DUTO en de DUTO-eisen op www.nationaalarchief.nl/archivere...
Reacties
Hoi Eelco,
Persoonlijk vind ik documenttypen een beetje een achtrehaald concept omdat de overige metadata vaak al duidelijk laat zien wat voor een soort document het betreft. In mijn ervaring kiezen de meeste gebruikers voor de makkelijkste optie en dat is vaak het eerste item wat in de lijst met documenttypen staat of een documentype die ze al vaker hebben gebruikt. Het is soms ook enorm lastig om een documenttype vast te stellen omdat de inhoud van een document heel goed zou kunnen verwijzen naar meer dan 1 goede match uit de lijst met documenttypen en wat kies je dan.
Als we kijken naar vergaderstukken in het algemeen dan mag het duidelijk zijn dat er vegaderstukken zijn (agendapunten) waarbij rapporten kunnen worden ingestuurd ter verduidelijking van het vergaderstuk. Dan is er een agenda, de acties, stemmingen, notulen en mogelijk vervolgacties. Ook kunnen vergaderstukken en agendapunten worden doorgeschiven naar een ander vergadering wanneer men er niet aan toegekomen is.
Voor de meeste documenten rondom vergadering is het vrij duidelijk wat het documenttype is maar ik denk dat de eerlijkheid geboed te zeggen dat naar alle waarschijnlijk heid naamvoering wordt gebruikt zoals "agenda vergadering 1 augustus 2023 commissie Informatiebeheer", "notulen vergadering 1 augustus 2023 commissie Informatiebeheer", "Actiepunt 1, vergadering 1 augustus 2023 commissie Informatiebeheer - documentypen bepalen", enz. Zoals je ziet is het dan al vrij duidelijk wat het documentype is en is, mijns inziens, en apart metadataveld om het documenttype te kiezen vrijwel overbodig omdat dezelfde informtie twee keer moet worden ingevuld. Zo ook voor bijlagen bij vergaderstukken. Stel dat ik een vergaderstuk heb ingediend om te beslissen wat we gaan gebruiken inzake documentypen dan is het niet ondekbaar dat ik de volgende bijlagen meestuur met mijn vergaderstuk, "kopie NEN2084", "faktuur kopie NEN2084" "advies gebruik documentypen bij vergaderstukken", "huidige situatie en werkwijze rondom vergaderstukken", enz. Daaruit blijkt al wat voor documentype het in dit geval is. Uiteraard zou je dat kunnen aanvulen met waarden uit de NEN2084 en dan zou je moeten kiezen voor de NEN kopie iets van "afdruk, afschrift, authentiek afschrift of kopie", voor de faktuur een waarde als "rekening, declaratie, factuur, inkoopfactuur of nota", voor het advies iets van "aanbeveling, advies of voorstel" en voor de huidige werkwijze bijvoorbeeld "procesomschrijving of beschrijving". Het wordt de gebruiker niet gemakkelijk gemaakt want in principe is alles wat ik hierboven heb beschreven correct. Sterker nog, in mijn bestandsnamen of titles stonden deselfde termen al vermeld dus heb ik als gebruiker nu twee keer hetzefde ingevuld en heeft het mij waarschijnlijk minimaal tweemaal de tijd gekost.
Er zijn overigens ook mooie software oplossingen rondom het beheer van vergaderingen waarbij dit hele proces een heel stuk vereenvoudigd kan worden. Dit soort software registreerd alle ingekomen vergarderstukken waarbij ze worden voorzien van de noodzakelijk metadata. Daarna kan een agenda volledig automatisch worden gegenereerd en verstuurd naar alle betrokken leden van de vergadering (inclusief alle ingezonden stukken en bijlagen), notulen, stemmingen en actiepunten kunnen tijdens de vergadering worden aangemaakt. Na afloop van de vergadering kunnen de notulene dynamisch worden gegegereerd (wederom voorzien van alle stukken en bijlagen), actielijsten worden gegenereerd en alles kan worden verstuurd naar iedereen die bij de vergadering aanwezig was. Doorgeschoven agendapunten komen automatisch op de volgende agende, enz.
Ik hoop dat dit helpt (misschien een beetje controversieel maar wel iets om misschien bij stil te staan).
In de opzet van de NEN 2084 was het de bedoeling dat van de primaire rol van documenten werd uitgegaan. De primaire rol van een bijlage is informerend en dan kom je uit bij de kolom "berichtgeving" met zaken als "voordracht", "voorstel", "mededeling" en "notitie".
@gphaar
Dag G-P Haar,
Dank je wel voor je uitvoerige reactie.
Ik ben het met je eens dat dubbele registratie niet nodig hoeft te zijn. Het zal de gebruiker in ieder geval niet uitnodigen, vermoed ik. Dus een scherpe keuze in wat je waar noteert.
Ik neem het mee in mijn overweging.
Vr. groet,
Eelco
@dickbunskoeke
Dag Dick,
Dank je wel voor je reactie.
Je uitleg is voor mij een nieuwe invalshoek om naar de primaire rol van een bijlage te kijken. Ik zat op de lijn die rol te zien als wat de oorspronkelijke rol van het stuk was, dus niet als zijnde een bijlage. En dan kunnen het dus veel meer (alle) documenttypen van de NEN zijn. Maar zoals jij het schetst wordt de rol van de bijlage dus teruggebracht tot het informeren. Dat beperkt de keuze.
Vind ik interessant. Ga ik mee aan de slag.
Bedankt.
Groet,
Eelco
Even reagerend op de reactie van G-P Haar:
Persoonlijk vind ik documenttypen een beetje een achterhaald concept omdat de overige metadata vaak al duidelijk laat zien wat voor een soort document het betreft.
Het is me niet helemaal duidelijk of de opmerking alleen betrekking heeft op bijlagen bij vergaderstukken of op alle informatie die in een zaaksysteem geregistreerd wordt. Ik ga even uit van het laatste (alhoewel het op zich niet uitmaakt voor mijn reactie).
Documenttypen als metadata zijn niet alleen bedoeld voor interpretatie, maar zeker ook voor het zoeken & vinden, het uitwisselen van informatie en om te bepalen wat voor type beheer er aan vast zit.
De combinatie met kenmerken als status en vorm van het document (zie bijlage A van de NEN2084) geven grote meerwaarde aan het interpreteren en beheren van de informatie, maar ook het filteren bij een zoekopdracht.
Als er een agenda rondgaat, waar een vergaderverslag als bijlage is toegevoegd, dan maakt het uit of het verslag de status concept heeft of niet. Dat kan interessant zijn voor vernietigingsvraagstukken.
En bij bouwvergunningen is het van belang om te weten welk documenttype bij een stuk hoort: zo mogen bouwtekeningen niet zomaar online gepubliceerd worden (Auteurswet) en dan is het van waarde dat het documenttype Bestek is toegevoegd, of aan het documenttype Beschikking (de bouwvergunning) de term tekening als vormkenmerk is toegevoegd. Dan is automatisch duidelijk welk deel van de vergunning niet automatisch gepubliceerd kan worden. Zeker bij overbrenging naar een e-depot is dat interessant.
Voor de lange termijn toegankelijkheid kunnen deze metadata dus van groot belang zijn. Het mag dan wel niet meteen allemaal in de bedrijfsvoering gebruikt worden, maar secundaire gebruikers kunnen er veel baat bij hebben. En bij digitaal materiaal begint het garanderen van duurzame toegankelijkheid feitelijk al bij de creatie.
Overigens kan documenttype wel degelijk interessant zijn voor de bedrijfsvoering zelf. De zoekvraag “doe mij alle overeenkomsten die de status definitief hebben, maar niet de status gepubliceerd” kan heel nuttig zijn in het kader van de WOO, bijvoorbeeld. Daarbij: het documenttype overeenkomst komt in de naamvoering door de jaren heen in verschillende vormen voor: contract, convenant, akkoord, verbintenis, deal, regeling, schikking enz. Dus op basis van de naamvoering kan je waarschijnlijk wel interpreteren wat het is (alhoewel bijv. regeling al voor meerdere uitleg vatbaar is) als je de registratie eenmaal voor je ziet, maar er op zoeken is een stuk lastiger.
Documenttype wegzetten als ‘achterhaald concept’ vind ik veel te kort door de bocht. In tegendeel: door de vorming van digitaal archief en zaken als de WOO wordt het steeds belangrijker.
Hoi Chido,
Bedankt voor je reactie, het was niet bedoeld als kort door de bocht want ik begrijp ook dat een metadataveld voor Document Type waarde kan hebben. Waar ik op doelde is dat ik in de praktijg erg vaak tegen kom dat het Document Type ook al wordt vermeld in de titel van een document. Ook kom ik met grote regelmaat tegen dat gebruikers bij extra metadatavelden simpelweg de eerste de beste optie kiezen en daarmee dus mogelijk de waarde van het metadata veld verminderen.
Het lastige, in mij ervaring, is om een goede balans te vinden tussen hetgeen avveptabel is voor gebruikers om in te vullen en het belang van de metedata gegevens die voor ons als beheerders van de informatie en de acties die wij erop uit moeten voeren. Wanneer documenten middels geaotomatiseerde processen woden opgeslagen in een EDRMS is het meestal wat makkelijker omdat je dan de regels instelt om te zorgen dat de metadata autmatisch gegenereerd wordt.
Je meld onder andere "De zoekvraag “doe mij alle overeenkomsten die de status definitief hebben, maar niet de status gepubliceerd” kan heel nuttig zijn", misschien dat het aan mij ligt maar de status van een document is noet hetzelfde als een Document Type. Ik ben het wel met je eens dat dit een heel belangrijk gegeven is maar dat is in een ander veld opgeslagen denk ik. Ook zeg je "Daarbij: het documenttype overeenkomst komt in de naamvoering door de jaren heen in verschillende vormen voor: contract, convenant, akkoord, verbintenis, deal, regeling, schikking", en dat is ook waar ik het over had en maakt het zeker lastiger. Hier zijn echter zoek algoritmes voor die synoniemen gebruiken en "feilloos" alle variaties in een zoekodracht laten zien.
Ik vind je uitleg met het schema zeker heel handig en overzichtelijk. Wel een leuke discussie en nogmaals bedank voor jou reactie.
@gphaar
Beste G-P Haar,
Dank voor je antwoord. De status is inderdaad niet hetzelfde als het document type, maar is wel onderdeel van het geheel van NEN2084. Het gaat me er om dat de combinatie een behoorlijke meerwaarde kan opleveren.
Verder ben ik groot voorstander van de inzet van zelflerende algoritmes voor de zoekfunctie, maar tot dusver zie ik die niet in overtuigende vorm verschijnen in zaak- en andere registratiesystemen. Daarnaast vraag ik me af of dat altijd goed werkt, als je de waarde/status van een document wil bepalen. Zoals ik al als voorbeeld noemde: de term regeling is door de jaren heen voor meerdere uitleg vatbaar, wat lastig is als je alleen de documenten wil hebben die over een overeenkomst gaan. Hetzelfde zou je kunnen zeggen voor de termen akkoord en deal.
Maar laten we niet verzanden in details. Mijn uitgangspunt is dat we de oude schoenen niet moeten weggooien, voordat we nieuwe hebben, die ook goed passen.
En inderdaad, leuke discussie :-)