Zaakgericht werken is een concept dat veel wordt gebruikt in gemeenten. Het kent ook vele vormen en implementatievarianten. In de GEMMA is hier de laatste jaren meer richting aan gegeven met het katern Zaakgericht Werken, Zaakgericht Werken in de praktijk en recentelijk de vertaling van Zaakgericht Werken in de GEMMA (informatiearchitectuur). Met de beweging “Common Ground” Common Ground beogen gemeenten de realisatie van een radicaal nieuw informatie- en applicatielandschap, een “Gegevenslandschap”. Hierin worden gegevens gescheiden van businesslogica en eindgebruikersfunctionaliteit en dus uit de traditionele procesapplicaties gehaald en zijn in plaats daarvan via gestandaardiseerde API’s beschikbaar bij de bron.
In GEMMA 2 en met name de uitwerking van het ZGW-deel is al voor een deel rekening gehouden met de beweging naar een “Gegevenslandschap”. Zaken API (ZRC) en Zaakafhandelcomponent (ZAC), Documenten API (DRC) en Documentbeheerocmponent (DBC) (zie functies en referentiecomponenten voor uitgebreide beschrijvingen van de componenten en een toelichting hierop) zijn afzonderlijke referentiecomponenten voor registratie respectievelijk proces/interactie.
Toch vraagt de architectuur van het Gegevenslandschap om een aanpassing van hoe we tegen de informatiearchitectuur ten dienste van het ZGW aan kijken. Het is ook niet uit te sluiten dat het concept Zaakgericht Werken zelf enige bijstelling behoeft als gevolg van de transitie naar een Gegevenslandschap.
Dit stuk onderzoekt deze aanpassingen en schetst enkele oplossingsrichtingen. Het is urgent om op een aantal van deze punten minstens op korte termijn de richting bepaald te hebben. Op dit moment worden immers de nieuwe zaakgerichte standaarden (ZGW API’s) ontwikkeld. Omdat de architectuur van het Gegevenslandschap/Common Ground door de Taskforce Samen Organiseren als uitgangspunt voor de toekomstige (collectieve) informatievoorziening van gemeenten is benoemd, is het belangrijk dat deze API’s in een gegevenslandschap het ZGW kunnen ondersteunen.
Uitgangspunt voor de zaakgerichte standaarden (ZGW API’s) is GEMMA 2 en daar waar GEMMA 2 nog niet Gegevenslandschap proof is, gaan we uit van Gegevenslandschap. Openstaande vraag is backwards compatibility: lukt het om de Zaakgerichte API’s zo te ontwikkelen dat deze zowel binnen een GEMMA 2 landschap (huidige systemen/leveranciers) als een Gegevenslandschap gebruikt kan worden? Ook om deze vraag te kunnen beantwoorden is er eerst meer inzicht nodig in hoe (de informatiearchitectuur voor) ZGW in een Gegevenslandschap vorm krijgt.
In GEMMA 2 worden processen zaakgericht uitgevoerd, ondersteund door informatiesystemen die invulling geven aan de generieke of specifieke Zaakafhandelcomponenten. De primaire verandering agv het gegevenslandschap zit in deze componenten. We signaleren drie grote veranderingen:
In GEMMA 2 en bijgevolg in ZGW in GEMMA 2 zijn de taakspecifieke processystemen als “Specifieke Zaakafhandelcomponenten” neergezet. Processen die zaakgericht worden uitgevoerd, worden afgehandeld met een Zaakafhandelcomponent (ZAC, generiek of specifiek). De generieke ZAC slaat haar gegevens op in de Zaken API (ZRC). Daarentegen slaat de specifieke ZAC alle gegevens zelf op: over de zaak en het proces, het verloop daarvan en veelal ook de registratie van de objecten waarop dat proces betrekking heeft. Vanuit deze component wordt een zaak geregistreerd (gekopieerd) in de ZRC en wordt deze zaak bij wijzigingen (ook) daarin bijgewerkt. Volgens het Gegevenslandschap moeten deze gegevens gescheiden worden van de procesapplicatie en in een of meerdere registraties worden ondergebracht en via gestandaardiseerde API’s ontsloten. Voor de Generieke Zaakafhandelcomponent is hierin al voorzien: deze gebruikt enkel generieke zaakgegevens. Deze gegevensset beperkt zich dus tot de gegevensset zoals wordt bijgehouden in de Zaken API (ZRC). Voor een specifieke ZAC waarin veel domein- of processpecifieke gegevens worden bijgehouden heeft dit (vergaande) consequenties.
Common Ground gaat uit van het beschikbaar stellen en bevragen van gegevens bij de bron. Kopiëren en distribueren van gegevens (gegevensmagazijnen, gegevensdistributie,..) bestaan in een gegevenslandschap niet meer. ‘Beschikbaar stellen bij de bron’ moet evenwel niet altijd letterlijk genomen worden. Anders zouden er precies evenveel registraties als procesapplicaties ontstaan (elke procesapplicatie als zelfstandige bron voor de gegevens ontstaan in die applicatie), wat een nogal gefragmenteerde gemeentelijke informatiehuishouding zou opleveren. Hierbij zouden dan telkens al deze bronregistraties bevraagd moeten worden om een overzicht te krijgen van de gegevens behorende bij alle lopende zaken. “Soortgelijke gegevens opslaan bij soortgelijke gegevens” is hiervoor een goed uitgangspunt. Zo ontstaan diverse “(kern)registraties”: coherente en integere registraties met meervoudig gebruikte soortgelijke gegevens die vanuit verschillende procesapplicaties worden bijgehouden. Bijvoorbeeld één gemeentelijke kernregistratie medewerkers en niet een (deel-)registratie per afdeling/proces. Voor het Zaakgericht werken heeft dit als gevolg dat veel objecten die nu in een Zakenmagazijn of procesapplicatie worden bijgehouden (behandelend medewerker, betreffend object, aanvrager (klant),..) vervangen moeten worden door een verwijzing naar de desbetreffende kernregistratie.
In de huidige gemeentelijke informatievoorziening vindt de interactie tussen processen plaats door middel van gegevensuitwisselingsberichten tussen desbetreffende applicaties (cq. referentiecomponenten). De ontvangen informatie wordt veelal ook weer opgeslagen door en in de ontvangende procesapplicatie. Een voorbeeld zijn mutaties van het verblijfsadres van een burger (a.g.v. een verhuizing) die door de GBA- (cq. BRP-)beheerapplicatie verstrekt worden aan bijvoorbeeld een vergunningenapplicatie, belastingenapplicatie en sociaal domeinapplicatie. In een gegevenslandschap is er van een dergelijke gegevensdistributie geen sprake meer. Hooguit wordt een proces genotificeerd over een gebeurtenis (zoals een verhuizing). De daarbij betrokken gegevens kunnen vervolgens, indien gewenst, door de ontvangende applicatie opgevraagd worden bij de desbetreffende registratie (en niet opnieuw vastgelegd worden) om daarmee de voor het proces relevante afhandeling te kunnen doen. Het versturen van berichten met inhoud tussen verschillende referentiecomponenten wordt dus zoveel mogelijk beperkt en vervangen door het sturen van notificaties en het opvragen van de bijbehorende gegevens uit een registratie. Specifieke aandacht verdienen aanvragen, meldingen e.d. die ‘op een website’ (of vanuit een App) ingediend worden. Het indienen wordt ondersteund door de referentiecomponent voor het aanvragen van producten en diensten (“e-Formulierencomponent” in GEMMA 2). In GEMMA 2 wordt een dergelijke aanvraag gerouteerd (in een bericht) naar de van toepassing zijnde generieke of specifieke ZAC. In een Gegevenslandschap kan hiervan geen sprake meer zijn. Voor de hand liggend is dat de e-Formulierencomponent die aanvraag opslaat, bijvoorbeeld in een : (kern)registratie Verzoeken”, een notificatie stuurt naar de desbetreffende ZAC die naar aanleiding daarvan de behandeling start (en daartoe onder meer de zojuist genoemde Registratiecomponent bevraagt).
Op basis van de hierboven geschetste veranderingen agv het gegevenlandschap en Common Ground zijn we toe aan een nieuwe fase in de zaakgerichte informatievoorziening. Dit past goed op de ontwikkelrichting zie ZGW al doorlopen heeft: van een zakenmagazijn naast backoffice-silo’s die ongeschikt waren voor klantgerichte (online-) dienstverlening, via alles-in-een zaaksystemen, naar zaakgericht registreren en generieke en specifieke zaakafhandelcomponenten naar een volgende stap in het vormgeven van de informatie-architectuur onder het zaakgericht werken. Hieronder gaan we uit van een, op basis van het Gegevenslandschap, radicaal anders opgezet applicatielandschap. Daarin zijn veel uitdagingen die aanleiding hebben gegeven tot het zaakgericht werken veel integraler in de applicaties en registraties verwerkt. Voorbeelden van dergelijke uitdagingen zijn het verbeteren van de dienstverlening, een beter inzicht in proces- en voortgang uit back-office applicaties en digitaal uniform archiveren etc. Zaakinformatie zit als gevolg hiervan niet meer op één centrale plaats, maar gedistribueerd over meerdere registraties. Grof geschetst bewegen we van een situatie zoals in figuur 1 naar een situatie zoals in figuur 2.
In figuur 1 staat een schets van de huidige situatie zoals min of meer beschreven door GEMMA 2.
Figuur 1 - ZGW in de huidige situatie (~GEMMA 2)
In het Gegevenslandschap komt bovenstaand plaatje er, door het scheiden van proces en data, eenmalige opslag en bevraging ‘bij de bron’ en het verminderen van informatiestromen anders uit te zien (zie figuur 2):
Figuur 2 - ZGW in een Gegevenslandschap
Bovenstaande plaat schetst het concept ZGW in een Gegevenslandschap al heel behoorlijk. Toch zijn er nog enkele openstaande vragen te beantwoorden. Voor een deel is dit al af te leiden uit de stippellijnen in bovenstaande plaat:
In bovenstaande figuur is de relatie tussen Melding/Aanvraag (Verzoek) en Zaak als een stippellijn getekend (Merk op dat er ook zaakgericht gewerkt kan worden in processen die niet naar aanleiding van een verzoek van de klant worden opgestart, marabv. n.a.v. een binnengekomen gebeurtenis.In dat geval is er ook geen Verzoek.. Dit omdat Verzoek niet in het RGBZ voorkomt (zat wel in GFO Zaken) en we dus niet weten hoe Verzoek en Zaak zich tot elkaar verhouden. Essentie van de relatie lijkt te zijn dat een verzoek of melding een op zichzelf staand ‘iets’ is en behandeld wordt als zaak. Één verzoek kan leiden tot meerdere zaken. Meerdere Verzoeken kunnen ook leiden tot één Zaak. Bv. meerdere meldingen die als één zaak worden afgehandeld. Verzoek heeft juridisch ook een eigen betekenis, bijvoorbeeld in het kader van archivering en het bepalen van de afhandeltermijn (ontvangstdatum Verzoek). Een verzoek kan bv. een subsidieaanvraag of een melding zijn.
Figuur 3 -Verzoeken
We kiezen ervoor om Verzoeken als aparte registratie te onderkennen en op te nemen in het RGBZ (als apart Informatiemodel Verzoeken met relatie met Zaak). Zo wordt het eerder aangehaalde nadeel dat gestructureerde gegevens die in een formulier zijn ingevuld “verloren” dreigen te gaan voorkomen. Een e-formulierencomponent (of ander systeem waarin een burger of bedrijf een aanvraag kan doen) registreert het verzoek in de Verzoekenregistratie. De gegevens van de aanvrager (in figuur 3 een burger) in de klantenregistratie (als deze niet al bestond) en de documenten bij de aanvraag in de documentenregistratie. Meldingspecifieke gegevens in de domeinspecifieke registratie voor meldingen. Denk aan aard van de melding, omschrijving van de klacht etc. De relatie tussen verzoek en alle informatie die bij de aanvraag aanwezig was, of eventueel later is aangevuld, wordt vastgelegd en mag niet meer gewijzigd worden. Zo is te allen tijde duidelijk welke gegevens er bij de aanvraag zaten.
Figuur 4- Van Verzoek naar Zaak
NU het verzoek is geregistreerd, moet het in behandeling worden genomen. Dit gebeurt door een medewerker die in de regel met een taakapplicatie zal werken. Deze wordt ofwel genotificeerd over een nieuw binnengekomen verzoek, of deze applicatie controleert periodiek, bv. ieder uur, of er nog nieuwe verzoeken van een bepaald type binnen zijn gekomen. Als het verzoek in behandeling wordt genomen, wordt vanuit de desbetreffende taakapplicatie via de Zaken API een Zaak aangemaakt. Het Verzoek wordt gerelateerd aan deze zaak (relatie nog in informatiemodel te formaliseren). Objecten die aan Verzoek waren gerelateerd (groen gekleurd in figuur 4: Klant, Bijlagen, Meldingspecifieke gegevens), worden ook rechtstreeks aan Zaak gerelateerd. Tijdens de behandeling in de Zaakafhandelcomponent ontstaat bijkomende informatie in de Documentenregistratie en de Meldingenregistratie. De relatie tussen Verzoek en Zaak wordt nog verder uitgewerkt. Zie #390
Een andere vraag is waar we in een gegevenslandschap “Procesinformatie” willen opslaan. Procesdefinitiegegevens beschrijven het te volgen proces in de afhandelapplicatie. Uit welke stappen bestaat dat proces, welke keuzes kunnen hierin gemaakt worden, welke beslisregels worden gehanteerd, etc. Vergelijkbaar met een Zaaktype voor zaken. Procesgegevens beschrijven hoe dit proces voor één bepaald geval is doorlopen: welke behandelaar heeft welke stap uitgevoerd wanneer. Welke keuzes zijn gemaakt obv de bekende gegevens etc. In figuur 2 is dit – samen met Procesdefinitiegegevens - gepositioneerd in de Zaakafhandelcomponent (net als nu in de diverse Taaksystemen). Dit lijkt (mogelijk) in strijd met het uitgangspunt van het Gegevenslandschap dat functionaliteit en gegevens van elkaar gescheiden moeten zijn. Procesgegevens zijn immers ook gegevens. Het is echter moeilijk om proces- en procesdefinitiegegevens uit de afhandelende systemen te halen. In veel gevallen is de procesdefinitie zelfs impliciet (hard gecodeerde flow tussen schermen); dat valt dan niet eens los te knippen. Toewerken naar een situatie waarbij procesgegevens onafhankelijk van de afhandelende applicatie in een leveranciersonafhankelijke “procesregistratie” komen te staan lijkt ons niet haalbaar. Het meest generieke formaat wat we over alle processen konden afspreken hebben we al, nl. Zaken en Zaaktypen. Dat is voor het sturen en registreren van de afhandeling niet toereikend. Een ander alternatief is van alle taakapplicaties te eisen dat ze op basis van in BPMN gedefinieerde processen gaan werken en één centrale processenrepository gaan gebruiken. Ook dat lijkt ons te ingrijpend in de huidige leveranciersmarkt. Ook is het de vraag of er dan voldoende interessante markt voor afhandelapplicaties overblijft. Er is één maar. Het kunnen ontsluiten van procesinformatie is nodig om het handelen als overheid te verantwoorden: het moet dus gearchiveerd worden. Wie heeft op welke datum welke stap gezet? Welke procesflow (en keuzes) is er doorlopen? Welke informatie was wanneer beschikbaar? Hoe luidde de (deel)berekening die heeft geleid tot een bepaald resultaat? Dit is informatie die niet in één van de andere registraties past en voor het grootste deel niet in de ZRC wordt vastgelegd (die kent meestal maar één behandelaar en vooral enkel het proces op hoofdlijnen: de Statussen). Conclusie: proces- en procesdefinitiegegevens blijven in de afhandelapplicaties. Idealiter maken deze een scheiding tussen schermen (interactie) en afhandeling (proces), en stellen ze hun procesgegevens in een open formaat (via een API) beschikbaar. Alternatief is een “log” van hun procesverloop als document (PDF) als document aan de zaak toe te voegen.
In de figuur staat ook een stippellijn getekend tussen Zaak en Procesgegevens. Proces staat niet gedefinieerd in het informatiemodel RGBZ, en dus ligt de relatie zaak – proces ook niet eenduidig vast. In GFO zaken was dit min of meer wel het geval met “stap”. Hieruit, en vooral uit de prominente rol van ‘status’ in het RGBZ, blijkt al dat het moeilijk is om alle soorten processen op een eenduidige manier te registreren. Uiteindelijk kom je dan bij een informatiemodel met de rijkheid van BPMN uit (en voor de meer adaptieve processen iets dat lijkt op CMMN). Wat uiteraard niet de bedoeling is. Maar indachtig de vorige vraag: “waar registreren we procesinformatie”, is het noodzakelijk dat de relatie zaak-proces goed is gedefinieerd, zodat we als we nadere procesinformatie willen weten van een zaak, deze bij een zaaknummer kunnen opvragen (indien beschikbaar). Er is een issue om deze vraag te beantwoorden.
Objecten worden in het RGBZ aan een zaak gerelateerd dmv. “Zaakobject”: “een Object waarop de zaak betrekking heeft”. In theorie kun je hier veel kanten mee op. In de praktijk is het gebruik hiervan beperkt tot voornamelijk basisregistratieobjecten. In een gegevenslandschap moeten veel meer soorten objecten aan een zaak gerelateerd kunnen worden. De zaak vormt immers de sleutel om deze bij elkaar te kunnen houden. Denk bijvoorbeeld aan verleende subsidies, uitgegeven marktplaatsen, grafrechten, etc. Vroeger werden deze objectenregistraties bijgehouden in het processysteem en lag daar impliciet de relatie tussen de zaak en deze objecten. Het Gegevenslandschap vraagt om een andere, meer integrale benadering. Het is daarom de vraag of de relatie zaak – object zoals gedefinieerd in het RGBZ (zaak heeft betrekking op object) hiervoor voldoende is genoeg is. Zeker omdat de domeingegevens voor de complexere processen uit meerdere objecten zullen bestaan. Relateer je dan al die objecten aan een zaak? Discussie en verdere verdieping op dit issue.
In de uitwerking hierboven hebben gezien dat er aparte registraties “bakjes” ontstaan voor verschillende aan zaak gerelateerde objecten die nu nog in de ZRC worden bijgehouden. Voor deze registraties moeten er aparte, aan zaak (RGBZ) gekoppelde informatiemodellen komen. De objecten worden via aparte API’s ontsloten. Rondom het zaakgericht werken onderkennen we de volgende registraties:
Zaakgericht werken kent al een lange geschiedenis. Het stamt uit de tijd dat dienstverleningsambities hoger werden en backoffice-applicaties dit niet of nauwelijks aankonden. Daarna was er de gedachte dat een “alles-in-1 zaaksysteem” voor veel processen voldoende zou zijn. Inmiddels draait de slinger een beetje terug en zien we taakspecifieke systemen moderner en opener worden. In een Gegevenslandschap is dit helemaal het geval. In de loop der jaren zijn er diverse doelen voor zaakgericht werken ontstaan: dienstverlening verbeteren, als basis voor het archiveren, het bieden van managementinformatie,.. waarvan het de vraag is of je ze in een modern applicatielandschap nog met zaakgericht werken wilt oplossen. In het geval van een gemeente die met één dominant generiek zaaksysteem werkt ligt de oplossingsrichting voor de hand. In een Gegevenslandschap veel minder. Bovendien zien we op vele vlakken een terugtrekkende beweging op het “gemeentebrede” dienstverleningsconcept, meer richting domeinspecifieke apps en portalen. Een meer domeingerichte dienstverlening en informatievoorziening (ipv generiek obv zaken) ligt daar dan meer voor de hand. Enkele voorbeelden:
In een gegevenslandschap willen we geen zaken (of andere informatie) meer “rondsturen”. Vraag is wel hoe een behandelaar met een taakapplicatie te weten komt dat er een melding voor hem beschikbaar is die behandeld moet worden. Er zijn nog andere scenario’s te bedenken, waarin het nuttig is dat een partij actief wordt genotificeerd over een zaak(status). Bijvoorbeeld bij meerdere behandelaars die met meerdere systemen werken (of moeten we dat niet willen?), of wanneer er een nieuw document aan een zaak is toegevoegd door een KCC-medewerker. Het is nuttig om enkele van deze scenario’s uit te werken binnen de context van een gegevenslandschap en hiervoor een generieke oplossing voor te stellen. Een verdere uitwerking van notificeren over zaken binnen een gegevenslandschap. Nog verder uit te werken in issue #397