BREED - over de grenzen van informatie
NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Verbijzondering van documenttypen en bijlagen
Berichten in deze discussie
-
Permalink Antwoord van Danielle Hag op
-
Olivier,
wij kijken juist naar de documentttypen van het RGBZ, zoals gedefinieerd in de domeintabellen (https://www.surfgroepen.nl/sites/stuf/Shared%20Documents/Informatie...).
Dit zijn er veel minder dan in het DSP volgens mij. (Moet wel even erbij vermelden: we zitten nog in een testfase met een aantal processen, dus wij weten ook nog niet of wij nog problemen gaan tegen komen.)
Waarom zou je het gaan verbijzonderen? Is dat om duidelijker te maken bij welke zaak het document hoort? In dat geval vind ik het juist prettig dat niet meer informatie is opgenomen in de naam van het documenttype. Want door de combinatie documenttype en zaaktype heb je precies dezelfde informatie, maar is het makkelijker te onderhouden en te gebruiken in zoekvragen.
Als je het wilt gaan verbijzonderen omdat er allemaal andere sjablonen/formulieren achterhangen, is dat wat anders. Je moet je wel afvragen, heb je wel allemaal andere formulieren nodig? Kun je dit niet generieker maken?
Waarom wil je een verbijzondering?
-
Permalink Antwoord van Oliver Labatzki op
-
Bedankt voor je reactie Danielle,
De verbijzondering zou met name moeten leiden tot een betere ontsluiting/terugvindbaarheid van documenten.
Zo vormt bijvoorbeeld de ontsluiting van bouwtekeningen een probleem. Met de huidige beperkte metadering is het voor medewerkers/raadplegers lastig de juiste bouwtekening snel terug te vinden.
Tevens is het denkbaar dat een bepaald, al te generiek geformuleerd, documenttype binnen één werkproces, bij meerdere processtappen voorkomt. Hoe ga je daarmee om zonder verbijzondering?
Verder leert de praktijk dat ook de 'registratie' van Wabo-bijlagen een bijzondere benadering behoeft. Wabo-medewerkers kunnen op dit moment maar moeilijk uit de voeten met de beperkte set van Tilburgse documenttypen.
-
Permalink Antwoord van Rudy Kaptein op
-
Dag Olivier,Op basis van je bericht heb ik nog niet volledig scherp waar je tegen een probleem aanloopt, maar daar komen we in de discussie vanzelf achter.Je start met de vraag naar de mogelijkheid tot verfijning van de documenttypen in het DSP. Later noem je de term documentsoorten. Om even de begripsverwarring te voorkomen voor iedereen die dit leest: documenttypen zijn binnen de i-Navigator de typering van documenten die specifiek bij een bepaald zaaktype horen (bijv. 'aanvraag evenementenvergunning'). Metadata die je bij een type vastlegt gelden dus ook alleen voor dat betreffende type. Documentsoorten zijn binnen de i-Navigator de lijst documenttyperingen die niet aan een een zaaktypen gekoppeld zijn (bijv. 'aanvraag'). metadata die over een documentsoort gekoppeld worden gelden daarmee voor alle onderliggende types (bijv. voor zowel de 'aanvraag zorgverlof', 'aanvraag wwb' en aanvraag evenementenvergunning') Uit de voorgaande zin blijkt daarmee ook dat er een relatie is tussen documenttypen en documentsoorten. De grote lijst documenttypen (10.000+) zijn allemaal een verbijzondering van een beperkt aantal documentsoorten (+/- 50).Bij het gaan werken met documenttyperingen zie je dat organisaties in grote lijnen (mengvormen zijn ook mogelijk) een keuze maken tussen het werken met een van beide opties: documentsoorten of documenttypen.Werken met documenttypen: in dit geval kiest de organisatie ervoor om gebruikers per zaaktype een specifieke lijst met documenttyperingen aan te bieden. Bij het ene zaaktype kunnen dit er drie zijn, bij het andere zaaktype twintig. Beheersmatig vraagt deze keuze een grotere inspanning, omdat het aantal te beheren documenttypen erg groot kan worden en in het meest extreme geval elk beheerde stuk metadata individueel per documenttype ingeregeld kan worden. Zo ver gaat het vaak niet, juist metadatabeheertools als de i-Navigator kunnen er aan bijdragen dat bepaalde metadata van de verschillende typen alsnog groepsgewijs beheerd worden. Een goed voorbeeld van dit laatste is de benaming van de documenten. Ondanks dat er sprake is van een groot aantal documenttypen kan er gekozen worden om deze documenttypen een naam te geven uit een lijst van van bijvoorbeeld 80 verschillende benamingen. De domeintabel documenttypen van het RGBZ zou hiervoor als referentie kunnen dienen, maar het kan natuurlijk ook een zelfopgestelde lijst zijn. Metadata die vaak wel individueel bepaald worden zijn bijbehorend aanvraagformulier (voor de verschillende typen aanvragen specifiek) of documentsjablonen (er zijn bijvoorbeeld 100 documenttypen met de naam vergunning, maar aan elk documenttype hangt een ander documentsjabloon, afhankelijk van het soort vergunning).Werken met documentsoorten: in dit geval kiest de organisatie ervoor om gebruikers bij elk zaaktype een algemene lijst met documenttyperingen aan te bieden. Bij elk zaaktype wordt bijvoorbeeld een lijst van 50 mogelijke typeringen getoond. Beheersmatig is dit natuurlijk eenvoudiger bij te houden, omdat het aantal te beheren documentsoorten overzichtelijk zal zijn. Nadelen zijn er echter ook: het is met een dergelijke lijst niet mogelijk om metadata die gelden voor een specifiek documenttype van een bepaald werkproces een bepaald gegeven vast te leggen, omdat de vastgelegde metadata gelden voor alle documenttypen van een bepaalde soort. Ook het gebruiksgemak is kleiner: gebruikers wordt een totaallijst getoond, waar mogelijk een groot aantal voor het betreffende zaaktype niet relevante documentsoorten tussen staan.Binnen de i-Navigator worden feitelijk beide vormen ondersteund. Wanneer gewerkt wordt met documentsoorten kan daarbij het Horsman / Van Heijst model van documentsoorten gebruikt worden, voor het werken met documenttypen zijn de documenttypen beschikbaar. Een eventuele mengvorm (bepaalde metadata op soortniveau vastleggen en beheren), bepaalde metadata op typeniveau vastleggen en beheren) wordt ook ondersteund, omdat van elk documenttype is bepaald bij welk documentsoort het hoort.Je noemt tenslotte een tweetal beperkende factoren:- het niet kunnen koppelen van een eigen metadataveld aan een specifiek documenttype- het niet kunnen aanpassen / uitbreiden van de documentsoorten in het Horsman / Van Heijst modelVoor beide gevallen geldt dat deze vanaf de komst van de i-Navigator 3.0 (eind dit jaar) mogelijk worden. Het wordt mogelijk om aan specifieke objecten, zoals een bepaald documenttype, een kenmerken toe te voegen. Ook de opzet van het Horsman / Van Heijst model gaat aangepast worden, waarbij het mogelijk wordt om zelf documentsoorten toe te voegen. In combinatie met de bestaande mogelijkheden voor het aanpassen, toevoegen en verwijderen van documenttypen en hun metadata zou dit alle mogelijkheden moeten bieden om aan de slag te gaan met de verfijning van de documenttypen. Binnen de huidige situatie zijn er waarschijnlijk ook al mogelijkheden om aan de slag te gaan, maar dan heb ik meer informatie nodig over jullie exacte plannen en dingen waar jullie nu tegenaan lopen.
-
-
Hallo Rudy,
Hartelijk dank voor je zeer uitvoerige antwoord. Ik ben daar zeer blij mee omdat je beschrijving me helpt bij de communicatie met de ontwikkelaars van de Tilburgse datamart en het op- en vaststellen van een gemeentebreed metadatamodel. In grote lijnen was me het verschil tussen documentsoorten en -typen wel duidelijk, maar ik vroeg me af hoe de door jou genoemde mengvorm van documenttypen en -soorten gestalte zou kunnen krijgen en in de i-Navigator beheerd kan worden. Deze mengvorm zou wellicht een oplossing kunnen bieden voor de door ons gezochte verfijning of verbijzondering.
Met spanning wacht ik dan ook op de komst van de i-Navigator 3.0, al komt de release daarvan, gezien de eigen interne ontwikkelingen, voor ons waarschijnlijk net iets te laat...
-
-
Hoi Olivier,
Wellicht valt er in jullie huidige plannen/ interne ontwikkelingen al rekening te houden met de komst van de i-Navigator 3.0, zodat wat nu door jullie vastgelegd wordt straks makkelijk overgezet kan worden. Daarover kun je eventueel rechtstreeks contact met mij opnemen. Het kan natuurlijk ook via dit forum, maar mogelijk wordt het daarvoor te specifiek.
-
Permalink Antwoord van Yvonne Welings op
-
@Rudy en Oliver,
Er zijn meerdere organisaties die met de I-navigator werken. Als er generieke ontwikkelingen zijn, horen meer mensen dat graag (op BREED).
Met vr. groet
Yvonne Welings
-
-
@Rudy en Yvonne,
Kennisdeling is inderdaad het toverwoord, Yvonne, en anticiperen op nieuwe ontwikkelingen een 'must'. Staan er met het oog op de aanstaande release van i-Navigator 3.0 nog informatiebijeenkomsten op de nabije VHIC-agenda, Rudy? Soortgelijke bijeenkomsten, zoals de bijeenkomst die voorafging aan de introductie van i-Navigator 2.5 heb ik als zeer nuttig ervaren. Voor de specifiek inhoudelijke vraagstukken nemen we uiteraard graag rechtstreeks met jou contact op.
-
-
Er staan inderdaad voor dit najaar weer gebruikersbijeenkomsten gepland:
Dinsdag 25 oktober, Maarssen
Maandag 31 oktober, Meppel
Maandag 14 november, Sint-Oedenrode
Dinsdag 22 november, SpijkenisseOnderwerp is dan onder andere de i-Navigator 3.0.
Inschrijven is vanaf hier mogelijk:
-
Permalink Antwoord van Hans Meijer op
-
Ja, dit is een zeer herkenbaar vraagstuk. Ben je ervan op de hoogte dat ons Normalisatieinstituut NEN bezig is met een norm hiervoor: NEN 2084? Zie Nen.nl.
Er is een Nederlandse norm in de maak voor de aanduidingen van documenten; een taxonomie. Je kunt zeggen ‘dagafschrift’, ‘kassabon’, ‘kwitantie’ of ‘betalingsbewijs’. Dit is een voorbeeld van meerdere gehanteerde namen voor wat in principe hetzelfde document is. Maar om dit soort wildgroei van documentnamen tegen te gaan, bevat de norm 2084 een standaardoverzicht van aanduidingen van documenttypen die van belang zijn voor de reconstructie van processen. Omdat informatiesystemen steeds meer worden gekoppeld, wordt het van belang dat die documenten eensluidend worden. In het bovenstaande voorbeeld kiest norm 2084 dus voor ‘betalingsbewijs’
Ik ga ervan uit dat de NEN-norm veel (praktische) houvast gaat bieden. Een lijst van 80 documenttypen zou hier de basis vormen. Per proces zou je kunnen verbijzonderen, op basis van wensen eindgebruikers. Verzint eer ge begint! Immers, anders blijf je "doorontwikkelen". Een inlichtingenstaat is een inlichtingenstaat, uit de context m.n. het proces zou moeten blijken of dit bij inburgering of financiële administratie van toepassing is.
Overigens blijkt dit type document niet in de tabel RGBZ te staan. Toch onderdeel van onze gemeentelijke (informatie-) architectuur. Een omissie of teken aan de wand ...
Niettemin dank aan Daniëlle Hag voor de verwijzing naar dit document.
-
-
Daar gaan we weer :) Mijns inziens eerder een teken aan de wand, Hans.
Deze gedachtenuitwisseling gaat meer en meer lijken op de eerder op dit forum gevoerde discussie 'Relatie ZTC, PDC en UPL'. Steeds meer 'standaardlijsten' die als paddestoelen uit de grond schieten (in casu Horsman van Heijst, documenttypen RGBZ en binnenkort NEN 2084), maar geen landelijk geaccepteerde single point truth. Waarom blijkt het toch zo moeilijk om landelijk geldende standaarden te definiëren, die vervolgens in heel gemeenteland omarmd worden en de lokale overheid de zo dringend benodigde houvast biedt?
Toch bedankt voor de waardevolle tip, Hans. Ik moet bekennen dat ik niet van deze NEN-norm voor de aanduiding van documenten op de hoogte was.
-
Permalink Antwoord van H. Oosting op
-
Een mooie discussie. Ik sluit me aan bij Danielle en Hans. Naar mijn idee is een combinatie van Zaaktype en Documenttype (de RGBZ-term) genoeg. Laat deze twee dan vooral landelijk omarmde standaardlijsten zijn die ook centraal beheerd worden (de link die Danielle poste doet vermoeden dat dit nu niet gebeurt).
Is er dan iets op tegen om voor de medewerkers Vergunningen (en alle andere eindgebruikers die hier behoefte aan hebben) een 'vrij veld' beschikbaar te stellen waarin ze kunnen aangeven dat dit documenttype Tekening (cfr RGBZ), een tekening van het ventilatiesysteem op de derde verdieping betreft?
-
-
Zijn er overigens ontwikkelingen mbt de nen2084? Ik weet dat er sinds 2009 aan gewerkt wordt, maar heb er al een hele tijd niets meer van gehoord.Het grootste probleem met de verschillende 'standaardlijsten' is dat de uitgangspunten op basis waarvan deze samengesteld worden niet uniform zijn, niet bekend zijn (ik kan ze niet vinden van het RGBZ) en soms niet aanwezig. Je kunt bijvoorbeeld prima een lijst samenstellen van de 60 binnen de gemeentelijke context meest voorkomende documenttypen, maar dan hou je bijvoorbeeld nog 30% van de documenttypen over waar je geen oplossing voor hebt. Of bijvoorbeeld de keuze: neem je in je lijst het documenttype 'besluit' op, kies je voor 'beschikking', of voor 'vergunning' en 'weigering'. Afhankelijk van je toepassingsdoel zal je komen tot een andere keuze. Het is daarmee denk ik onvermijdelijk dat er meerdere van dit soort lijsten blijven bestaan die afhankelijk van de toepassing gebruikt worden. En in een heel aantal gevallen valt tussen de verschillende lijsten wel een relatie aan te brengen, maar in bovenstaand voorbeeld rond besluit / beschikking / vergunning is dat niet altijd even makkelijk om te doen.
- ‹ Vorige
- 1
- 2
- Volgende ›
Partner(s)
Sponsor(s)
Direct naar...
© 2024 Gemaakt door Marco Klerks.
Verzorgd door
