De reis naar M365 van de gemeente Tilburg
Samenvatting: De gemeente Tilburg is druk bezig om de laatste hand te leggen aan de overgang van het werken op netwerkschijven naar het werken in M365.
PDC-component in ZGW-architectuur
- dec 2023
- Wouter Verdaas
- ·
- Aangepast 27 jun
- 16
- 211
Samenvatting
In mijn gemeente bestaat sterk te behoefte aan een centrale producten- en diensten component binnen het zaakgericht werken spectrum.
Ons idee is dat deze component opgebouwd wordt vergelijkbaar met de ztc. Dit betekent dat er product- en diensttypen ontstaan 'waaronder' producten en diensten kunnen worden aangemaakt. Een goede basis hiervoor zou de Uniforme ProductnamenLijst (UPL) kunnen zijn die iedere organisatie verder zou kunnen aanvullen. Deze producten of diensten maak je aan wanneer je een zaak start/behandeld.
Voordeel hiervan is dat de structuur van zgw in onze ogen eenvoudiger/logischer wordt, want je hebt een kapstok om zaken die over het zelfde product gaan aan op te hangen. Hierdoor heb je geen string van zaken die aan elkaar gerelateerd zijn d.m.v. een relatie (die in veel gevallen niets doet, want vaak wordt 'gerelateerd aan' gebruikt)
Als voorbeeld: er wordt een overeenkomst afgesloten. Hiervoor is een zaak 'Overeenkomst aangaan' gestart met een bewaartermijn van 10 jaar na vervallen van belang. Het product wat hieruit voortvloeit is de overeenkomst. Die heeft een bepaalde looptijd. Wellicht wordt de overeenkomst in de tussentijd aangepast. Hiervoor is een zaak 'Overeenkomst aanpassen' gestart. Deze zaak koppel je aan de overeenkomst (het product) en heeft ook een bewaartermijn van 10 jaar na vervallen van belang. Na verloop van tijd wordt er besloten om de overeenkomst op te zeggen. Er wordt een zaak 'Overeenkomst beëindigen' aangemaakt en ook gekoppeld aan het product. Deze zaak heeft een bewaartermijn van 10 jaar na afhandeling.
De einddatum van de overeenkomst wordt vastgelegd bij de overeenkomst. De einddatum zal automatisch doorgegeven moeten worden aan de aan de overeenkomst gerelateerde zaken.
We merken toch dat veel mensen binnen de organisatie nog steeds in dossiers denken i.p.v. in zaken. We hopen dat hiermee dat het voor de gemiddelde medewerker logischer wordt om zaken aan te maken voor de verschillende handelingen omdat het inzichtelijker wordt wat het effect is.
Nog een ander voordeel is dat deze component het mogelijk maakt om met generieke(re) zaaktypen te gaan werken zoals dat nu ook al gebeurt in de ZTC-OW. (ztc Omgevingswet), zoals beschikking behandelen. Hierdoor zal de beheerlast van de ztc afnemen omdat er minder zaaktypen nodig zijn.
Ook zien we mogelijkheden voor deze component om een grote (centrale) rol te spelen in het integraal vernietigen van gegevens in een common ground landschap. Immers worden er in veel vakapplicaties ook gebruik gemaakt van producten en diensten.
Hoe het e.e.a. technisch in het vat moet worden gegoten zijn nog niet helemaal uit, maar we gaan graag samen met andere gemeenten deze uitdaging aan.
Zijn er meerdere gemeenten die hier behoefte aan hebben of dit een goed idee vinden en met ons mee willen doen om dit te ontwikkelen en hopelijk tot standaard te laten verheffen?
Verken
Aanmelding bijeenkomsten Duurzaam informatiebeheer
Wat? Zeven bijeenkomsten georganiseerd door het Kennisnetwerk Informatie en Archief over duurzaam inf...
Week van Grip op Informatie
Van maandag 11 tot en met vrijdag 15 mei organiseert VNG Realisatie samen met een groot aantal gemeent...
Reacties
Wouter, wil je de structuur van ZGW werkelijk vereenvoudigen en logischer maken, dan zou je eens kunnen kijken naar wat de NORA daarvoor biedt in de vorm van het Basisconcept van Dienstverlening: dat behandelt namelijk de architectuur van die dienstverlening, terwijl ZGW een praktische toepassing is die o.b.v. die architectuur kan worden ingericht/verbeterd.
Het Basisconcept levert bijvoorbeeld een universele definitie van een dienst, waarmee je jouw gewenste structurele verbetering/vereenvoudiging kunt bewerkstelligen. Die dienst-structuur kun je 1-op-1 in je dienstenovereenkomst hanteren, waarna je ook je dienstenrapportage 1-op-1 in dezelfde structuur inricht. Je kunt je vast wel voorstellen welke impact zoiets op je besturingscyclus en je continue verbetering gaat hebben...
Alle zaakvoorbeelden die jij noemt bij het object [overeenkomst] zijn praktische variaties van een kernproces 'wijzigen van een beheerde component'. Als je dat kernproces (zie de NORA) inricht, hoef je alleen de toepassing op de verschillende situaties in te richten. Daarvoor biedt de NORA templates die je voor nog veel meer praktische variaties ('zaken') kunt toepassen. Zie je al welke synergievoordelen je nu met alle zaaktypen uit ZGW in beeld krijgt?
Het streven om meer logica in ZGW te krijgen laat zich vanzelfsprekend het best realiseren door vanuit het ontwerp te redeneren (de architectuur) i.p.v. vanuit de steeds veranderende praktijk. Ik kan je dan ook aanraden om voor jouw doel eerst te kijken naar die NORA-architectuur, en dan je verbeteracties tegen het daglicht te houden: dan blijkt al snel dat je herhaaldelijk hetzelfde probeert te doen, vanuit de praktijk. Beginnen bij het begin levert in deze situaties altijd veel duurzamere resultaten op.
Mocht je meer willen weten over deze benadering, dan ben je van harte welkom in de NORA Expertgroep Zaakgericht Werken. Neem daarvoor contact op met Ellen van der Steen van gemeente Apeldoorn.
Verduidelijkingsvragen:
Is het de bedoeling dat een product uit een Producten en Diensten Catalogus een te kiezen attribuut bij een zaaktype wordt in dit voorstel?
Welke aanvulling, wijziging op de al bestaande componenten uit de componenten catalogus Common Ground stellen jullie hiermee voor of zijn jullie opzoek naar iets totaal anders?
@bartelvanstrien
Hoi Bartel,
dit lijkt me zo op het eerste gezicht wel logisch. Maar de specifieke inrichting laat ik graag over aan onze it-architect(en).
Zover ik weet voorziet geen enkele bestaande component hier nog in. De archiefbeheercomponent zal in ieder geval hierop aangepast moeten worden.
@janvanbon
Hoi Jan,
dank voor je reactie. De architecten van mijn gemeente werken zover ik weet met de Nora en Gemma-principes en kwamen tot de conclusie dat dit element (vooralsnog) ontbrak. Ik zal je uitnodiging doorzetten naar deze collega's zodat zij (evt.) kunnen aanhaken bij deze expertgroep.
Dank je wel.
@janvanbon
Heel goed, we zien ze graag komen! Het gaat in dit geval trouwens niet over de NORA- en GEMMA-principes, maar over de architectuurspecificaties die mét deze principes zijn opgesteld. Dus één nivootje hoger :-)
Dag Wouter,
In hoeverre heb je hierover ook contact met Jinze van Nuenen en Rick Balvers? Zij hebben product in het kader van VTH inhoudelijk ook echt voorzien van een structuur en ook de toestemming daarin een hele prominente rol gegeven. Het is immers van belang om het product juridisch en procedureel te borgen. Dat is dus niet een beschikking of getekende overeenkomst, maar de gestructureerde content van het product (bijv. activiteit en bijbehorende object).
Ik ben in die zin van mening dat product als object binnen ZGW onvoldoende toegevoegde waarde heeft als het beperkt blijft tot alleen een object. De waarde is dan alleen een selectielabel voor archivering (zeer zeker heel nuttig en absoluut doen!), terwijl je er juist inhoudelijk veel meer mee wilt doen.
Dit brengt me ook meteen bij het probleem van de UPL. Dat kan dan een onuitputtelijke lijst worden van productnamen, terwijl je juist wilt naar uniformiteit. Die kun je pas verankeren in een product, wanneer het product inhoud heeft en niet alleen een naam. Jinze en Rick hebben hier een prachtige plaat van gemaakt. Een uitwerking daarvan zou ook meteen de basis kunnen vormen voor de input van een eerste aanzet tot het FDS. Iets wat vervolgens weer aanzet tot anonimiseren bij de bron; en dit heeft weer grote voordelen bij de actieve openbaarmaking volgens de Woo.
Grt,
Bastiaan Ligt
Adviseur Inrichting
Provincie Overijssel
Hoi Bastiaan,
Dank voor je reactie.
Ik heb een zeer kort lijntje met Jinze en Rick en trek ook samen met hun op in dit vraagstuk. Het vervelende is dat zij niet veel gehoor krijgen buiten onze eigen organisatie en hun vakgebied en daar loop ik in mijn vakgebied ook tegenaan. Daarom mijn oproep hier om wellicht wat mensen te inspireren en een zaadje te planten.
Ik heb me in mijn vraag op dit platform alleen gericht op het informatie- en archiefbeheer (iab) gedeelte, maar ben het met je eens dat er nog een hele wereld achter product zit en dat we breder moeten kijken dan alleen iab.
De UPL is m.i. ook nog geen gelukkige uitwerking. Het bevreemd me ook dat men nu aan een pdc werkt/gaat werken ihkv dienstverlening zonder dat er m.i. een goede inhoudelijke basis voor producten en diensten staat binnen het zgw-spectrum.
Gr. Wouter
Bastiaan, Wouter,
hebben jullie inmiddels gezien wat er in de NORA al aan structuur voor dit vraagstuk beschikbaar is? De NORA-pagina https://www.noraonline.nl/wiki/Het_procesmodel_en_de_werkstromen_van_de_overheidsorganisatie behandelt in detail een architectuur waar alle diensten in kunnen worden ondergebracht. De voorbeelden uit de oorspronkelijke post van Wouter zijn hier eenvoudig één op één in te herkennen, en je hebt niet veel fantasie nodig om alle andere zaaktypen uit de ztc ook met gemak hun plaats te geven in deze architectuur.
Binnen de NORA is de Expertgroep Dienstverlening ingesteld (https://www.noraonline.nl/wiki/Expertgroep_Dienstverlening) waar we graag nog meer vertegenwoordigers uit gemeenten bij zien aanschuiven.
@wouterverdaas1
Dag Wouter,
Ik kon me al niet aan de indruk onttrekken :). Vorig jaar hebben Jinze, Rick en ik de schematische opzet van Zaak en Product, die zij hebben gemaakt, nog iets nadrukkelijker verankerd aan de toestemming. Daardoor is actief gebruik van domeindata binnen het ZGW mogelijk en kan ZGW straks ook echt een rol gaan spelen in bijv. de aanlevering van domeindata aan de FDS. Als we dat kunnen bewerkstelligen komt de toepassing van het gebruik van domeindata in de dienstverlening (bijv. het DSO) een stuk dichterbij.
Momenteel ben ik bij de provincie Overijssel druk bezig om de bovengenoemde plaat in te brengen en breder gedragen te krijgen. Tilburg staan dus zeker niet alleen, maar we moeten wel kijken hoe we het z.s.m. kunnen aantonen in een specifiek domein. Wellicht aardig om een keer kennis te maken.
Grt,
Bastiaan
06 38 20 40 10
@janvanbon
Dag Jan,
Het abstractieniveau van het procesmodel maakt dat ik het lastig vind te plaatsen op Wouters voorstel. Wellicht ontbreekt het mij aan fantasie ;)
Ik lees dat het in het procesmodel heel erg gaat om de overheidsdienst en de wijze waarop aanpassingen kunnen worden gedaan. Ik lees zelf in Wouters initiële blog iets anders...
ZGW houdt van begin af aan al geen rekening met de content (domeindata). De vele discussies die ik met de werkgroep RGBZ en haar voorzitter heb gevoerd over de tekortkoming daarvan, hebben helaas nooit geleid tot een aanpassing. Dat had indertijd vooral te maken met de beperkingen in het berichtenverkeer (StUF-Zaken en later StUF ZSDMS). De enige wijze om domeindata in een zaak te laten landen, is door ExtraElements te gebruiken en daarvoor is overeenstemming nodig over het metadatamodel/objectenmodel van het bewuste domein.
Doordat er meer en meer bewustwording komt op de noodzaak van uniformiteit in domeindata (FDS) en de huidige benadering van het zaakresultaat te beperkt is om te kunnen voldoen aan een adequate archivering, is het noodzakelijk om Product als object in Zaak te introduceren. Dat heeft echter alleen nut wanneer het product domeindata vertegenwoordigt. We behandelen een zaak immers niet omwille van het proces, maar omwille van het resultaat.
Het zou geweldig zijn wanneer elk domein nadenkt over de vormgeving van Product, zoals Tilburg dat heeft gedaan voor VTH (en ik hoop dat meer BG's naar hun plaat gaan kijken). Hoogstwaarschijnlijk verschilt het per domein en zullen er meerdere producttypen ontstaan met hun eigen metadatamodel. Alleen zo kunnen we als BG's ook echt de FDS met kwalitatieve data gaan voeden.
(Toegevoegd) Archivering vind nu altijd plaats o.b.v. een selectielijst die vaak uitgaat van enkelvoudige domeindata (lees: activiteit Milieu, Bouw of Natura2000), terwijl de Omgevingswet meervoudige activiteiten ondersteunt. Men bewaart nu o.b.v. de langst te bewaren activiteit. Maar dat gaat in de FDS niet meer op. Dan moeten gegevens worden vernietigd per domein. Daarin voorziet de huidige methodiek van ZGW niet. Door de archiefnominatie te leggen op de domeindata, dus op Product, wordt het bewaren en schonen veel eenvoudiger en eenduidiger.
Grt,
Bastiaan
@janvanbon
Bastiaan - het ging in de post volgens mij om een structuur voor diensten, en zoiets pak je (hopelijk) aan met een architectuur. Dat betekent concreet dat je niet vanuit de zaken (praktijken) denkt, maar vanuit een ontwerpstructuur voor die zaken. Dat is precies wat het NORA Basisconcept van Dienstverlening je biedt: een eenvoudige en universeel toepasbare structuur/architectuur voor niet alleen diensten maar ook voor het managen van die diensten, in één geïntegreerde systematische aanpak.
Het kost vaak wat denkkracht om anders (vanuit een architectuur) te leren kijken naar hetzelfde onderwerp, maar je bereikt er veel duurzamere resultaten mee. Zaakgericht werken zou dus heel veel eenvoudiger (en goedkoper) kunnen worden als gemeenten vanuit die management-architectuur naar hetzelfde leren kijken.
@wouterverdaas1
Dag Bastiaan,
lijkt me goed om eens kennis te maken. Ik zal je even een mail sturen.
Gr. Wouter
@janvanbon
Dag Jan,
ik moet zeggen dat ik met Bastiaan meega en dat, hoewel je procesmodel an sich wel duidelijk is, ik nog niet zo 1,2,3 zie hoe ik dat op producten kan toepassen, maar dat zal ongetwijfeld aan mijn beperkte architectuurkennis liggen.
Heeft de Expertgroep ook contact met VNG Realisatie over het toepassen van jullie model in het zgw-spectrum? Dat lijkt me het gepaste gremium om het e.e.a. samen te voegen.
Gr. Wouter
@janvanbon
Wouter,
het gaat niet alleen om het procesmodel maar eerder om de structuurdefinitie van een dienst. Lees bv https://usm-portal.com/what-is-a-service/. En de Expertgroep Dienstverlening en Expertgroep Zaakgericht Werken zijn met elkaar verbonden. De VNG heeft een sterke focus op praktijkdenken, en mist daarmee de architectuur van de dienst. De zaaktypencatalogus is daar een fraaie exponent van, en ook de benadering met Service Blueprinting voor het documenten van klantreizen onderstreept die benadering. Met zo'n praktijkbenadering ga je voorbij aan de onderliggende architectuur: die praktijk zou immers het resultaat van de ontwikkeling moeten zijn en niet het begin... Zolang we blijven proberen om de verbetering te realiseren door aan de buitenkant te poetsen gaan we voorbij aan de duurzame oplossing die aan de binnenkant zit. Als je ziek bent en naar de dokter gaat, dan hoop je ook dat die zich niet alleen met de symptomen bezig houdt, maar de oorzaak van de ziekte weg wil nemen.
Dit is geen fijne boodschap voor iedereen die zich al jaren met Lean e.d. heeft bezig gehouden, maar symptoombehandeling is nou eenmaal minder duurzaam dan het behandelen van de oorzaak...
@janvanbon
Dag Jan,
Ik begrijp de nut en noodzaak van een goede architectuur, al heb ik er persoonlijk onvoldoende inzicht in om echt goed te doorgronden waar ik naar zit te kijken. Maar ik moet ook zeggen dat ik nog nooit een architect heb gesproken die mij duidelijk kan uitleggen hoe de domeindata zich in de architectuur verhoudt tot generieke data in het kader van ZGW. Het is goed mogelijk dat het wel in het procesmodel staat, maar ik kan het er niet uithalen. Wellicht ligt daar dan ook meteen het probleem van de architect: te weinig mensen in de organisatie begrijpen waar diegene mee bezig is. Het is te abstract, of beter nog, er zit onbegrijpelijke toelichting bij.
Maar goed, hand in eigen boezem, net zo goed als dat een architect beter moet uitleggen hoe e.e.a. zich verhoudt, moet een niet-architect als ik soms het operationele iets meer loslaten. Het gaat de laatste tijd vaak over datakwaliteit, datastrategie en datamanagement in onze organisatie. Wij hebben Product momenteel gepositioneerd als label in ZGW. Er hangt geen domeindata aan.
Ik sta hier zeker niet negatief in en wil heel graag de relatie tussen het procesmodel en Wouters vraag begrijpen, want ik denk dat we dan veel anderen ook weer kunnen helpen om structureel genezende antwoorden vanuit de architectuur te geven i.p.v. dat we per domein pleisters plakken. Is het mogelijk om een keer een Teams-sessie te houden waarin je ons die relatie toelicht?
Ik hoor graag van je.
Grt,
Bastiaan
@janvanbon
Bastiaan,
het lijkt erop dat ik de indruk heb gewekt dat mijn reactie betrekking heeft op data-architectuur. Dat is echter niet zo: de structuur van een product/dienst/service is gepositioneerd op laag 2 van het NORA-Vijflaagsmodel; de organisatie, en niet op laag 3-4-5, de technologische informatie/data-applicatie-netwerk laag. Het gaat er daarbij dat je eerst een management-architectuur inricht vóórdat je met een technologie-architectuur aankomt. Die technologie zou immers de realisatie moeten onderbouwen van de diensten die je wil gaan managen. Dat is de blinde vlek van de meeste IT'ers: ze kijken vooral naar de techniek, en hun redenering om de wereld te verbeteren begint ook aan die kant. Daarmee begin je echter bij het eind en niet bij het begin. Dat klinkt niet erg logisch, wel? Gelukkig is er een eenvoudige manier om dat te repareren. Het Basisconcept van Dienstverlening van de NORA legt uit hoe dat kan. Ik licht dat graag een keer toe in een Teams-sessie. Je mag ook eerst aanschuiven bij een algemene introductie van de methodische denkwijze daarachter, op 29 februari of 5 april (https://usm-portal.com/online-usm-workshop/).