Op dit moment lopen wij tegen een situatie aan die lijkt af te wijken van de standaard implementatie van ZKN-DMS.
Om organisatorische redenen wilt onze klant gebruik blijven maken van een vakapplicatie om vergunningen te behandelen. Dit betekent dat men feitelijk de volgende flow wenst:
Basisgegevens:
Vakapplicatie is ingericht met de rol Consumer
Zaaksysteem is ingericht met de rol Zaaksysteem
Gewenste workflow van klant
1. Registratie van een nieuwe aanvraag vindt plaats in het zaaksysteem (rol zaaksysteem)
1.1 Binnen het zaaksysteem wordt een zaak aangemaakt (rol zaaksysteem)
Nu is het mogelijk om binnen het zaaksysteem het volledige behandel en afhandelproces uit te voeren, echter dient er binnen de visie van onze klant nu een overdracht (op basis van ZKN-DMS) plaats te vinden naar de vakapplicatie die zich beperkt tot de rol van consumer.
2. De geregistreerde zaak dient overgedragen te worden naar de vakapplicatie (rol consumer - hybride?)
2.1 De vakapplicatie registreert een (zaak??) aanvraag (rol zaaksysteem - hybride?)
Dit is het knelpunt waar wij tegen aanlopen, alleen de rol van consumer kan een creeerZaak aanmaken bij een andere applicatie die ingericht is met de rol Zaaksysteem. Ziet iemand hierin een mogelijkheid om op basis van de standaard een omgekeerde werking te realiseren, dwz dat de rol Zaaksysteem een CreeerZaak naar de rol Consumer doet?
3. De behandeling / afhandeling geschiedt in de vakapplicatie (rol consumer)
4. De vakapplicatie doet een UpdateZaak naar het zaaksysteem (rol consumer)
5. Het zaaksysteem ontvangt het UpdateZaak bericht (rol zaaksysteem)
6. Zaaksysteem publiceert het besluit op de Persoonlijke informatie pagina van de aanvrager
Vraag
Kent iemand een mogelijkheid om bovenstaand scenario te laten werken?
Zo ja, welke mogelijkheden zien jullie?
Wij kennen de volgende mogelijke oplossingen:
1. Haal de vakapplicatie uit het scenario en werk alleen in het Zaaksysteem - Kan niet ivm wens klant
2. Ontwikkel een specifiek-koppelprofiel - Nadeel is dat we dan niet obv een standaard uitwisselen
3. Vakapplicatie levert zelf webformulieren en doet na afhandeling alleen een overdracht naar het Zaaksysteem - Extra kosten klant
Dag Niek,
Strikt genomen wordt dit scenario niet door de Zaak- en Documentservices ondersteund. Om het in de praktijk toch te laten werken zijn er wel mogelijkheden. Bij gemeenten ben ik de volgende scenario's tegen gekomen. Uiteraard hangt dit af van de functionaliteit die de vergunningapplicatie biedt.
Zaakregistratie in vakapplicatie
1.1 Registratie van nieuwe zaak vindt plaats in de vakapplicatie
1.2 De vakapplicatie registreert een nieuwe zaak in het zaaksysteem
1.2 De vakapplicatie registreert de bijbehorende documenten in het zaaksysteem
2.0/2.1 vervalt
Voordeel: Gebruikers gebruiken hun eigen vakapplicatie. Door de koppeling met het zaaksysteem vindt er toch centrale zaakregistratie plaats.
Zaaksysteem informeert vakapplicatie
1.2 Het zaaksysteem verstuurt een StUF zkn0310 zakLk01-bericht naar de vakapplicatie (vergunningapplicatie)
1.3 Bijlagen worden optioneel via een edcLk01-bericht aangeboden aan de vakapplicatie
2.0 De vakapplicatie maakt een nieuw dossier/registratie aan op basis van de ontvangen zaak
2.1 Deze stap vervalt, er wordt alleen een nieuw dossier aangemaakt binnen de eigen applicatie op basis van het zakLk01-bericht
Voordeel: Je kunt de gewenste workflow aanhouden
Gebruiker koppelt zaak in vakapplicatie
2.0 De gebruiker koppelt het zaaknummer (zaakIdentificatie) handmatig in de vakapplicatie
2.1 De gebruiker klikt op de knop overhalen zaakgegevens.
2.2 Vakapplicatie bevraagt het zaaksysteem op basis van geefZaakdetails en vult de zaakgegevens in de vakapplicatie
Voordeel: Wanneer de technische mogelijkheden tekort schieten, en er niet afgeweken wenst te worden van de werkwijze kun je op deze wijze toch koppelen/kloppelen.
Gebruik een Gemeentelijke ServiceBus (GSB)
Naast deze twee scenario's kun je ook oplossingen bedenken waarbij je een gemeentelijke servicebus inzet om een koppeling mogelijk te maken, al dan niet als intermediair tussen de webform-module, de vakapplicatie en het zaaksysteem.
Zaak overdragen
De term zaak overdragen vind ik persoonlijk wat ongelukkig gekozen. De zaakregistratie blijft gewoon plaatsvinden in het zaaksysteem. De inhoudelijke afhandeling vindt echter plaats in een vakapplicatie. Het is dus aan de vakapplicatie om de koppeling met het zaaksysteem te maken. Van overdracht is er naar mijn mening geen sprake, hoogstens notificatie over een nieuw gestarte zaak.
Kun je hiermee uit de voeten?
Hartelijke groet,
Jarich Ypma
Jarich,
Dank voor de uitgebreide post. Nog een kleine aanvulling: De eerste optie (Zaakregistratie in vakapplicatie) is de workflow die als uitgangspunt is gebruikt voor de Zaak- en Documentservices. Deze optie heeft duidelijk de voorkeur omdat deze het beste aansluit bij de beschikbare services waardoor geen aanvullende maatwerk services nodig zijn ( voor notificeren van consumer vanuit zaaksysteem) of het handmatig koppelen van zaakidentificaties in de vakapplicatie.
Groet,
Jan
Ik ben het eerlijk gezegd niet helemaal eens met Jan, als ik het tenminste goed begrijp. Ook wij komen de situatie tegen dat een zaak in in het zaaksysteem start, bijvoorbeeld via het post-kanaal of E-formulier. Vervolgens moet de zaak worden doorgezet naar de TSA. Dit hebben we ook gerealiseerd tussen Squit XO (een TSA voor vergunningverlening) en diverse zaaksystemen. En nu mijn punt: de werkgroep ZS-DMS heeft de wensleijkheid hiervan ook onderkend en is bezig een oplossing hiervoor te ontwerpen voor ZS-DMS 1.2. UIt het verslag van afgelopen 9 december:
"Toevoegen notificatie services
Op dit moment kent de zaak- documentservices nog geen notificaties. In de praktijk worden al wel notificaties verstuurd in de vorm van zakLk01 en edcLk01 berichten. De aanwezige leveranciers geven aan dat deze manier van notificeren in de praktijk goed werkt en is uitgegroeid tot defacto standaard. Daarom kiest de werkgroep ervoor om deze manier van notificeren te formaliseren in de standaard. Leveranciers leveren input (voorbeeldberichten) aan Michiel om deze notificaties verder uit te werken (actie leden/KING)."
Binnen de Zaak-Regieservices zijn ook al notificatieberichten gemaakt.
@Johannes: Vanuit de standaard geredeneerd heeft het de voorkeur om een zaak te starten in vakapplicatie omdat er dan geen notificatieservices nodig zijn.
In de praktijk zijn inderdaad ook veel situaties waarin de zaak niet gestart wordt vanuit de vakapplicatie. In dat geval zou de vakapplicatie, volgens de huidige versie van de standaard, bij het zaaksysteem moeten ‘pollen’ om te zien of er een voor hem relevante zaken zijn. Dit is niet handig en daarom is voor versie 1.2 van de standaard een RFC ingediend om een notificatie service toe te voegen waarmee vakapplicaties op de hoogte kunnen worden gebracht van relevante zaken of wijzigingen op zaken.
@Lidwien: het klopt dat in de Regie- en Zaakservices ook functionaliteit is gespecificeerd om vakapplicaties te notificeren (via overdragenZaak service). We hebben in de werkgroep voorgesteld om de functionaliteit over te nemen in de Zaak- en Documentservices. Echter, hebben leveranciers in de werkgroep (waaronder Centric) aangegeven dat ze op dit moment al berichten en services geïmplementeerd hebben om vakapplicaties te notificeren van een zaak, dat deze berichten naar wens functioneren en dat deze berichten door veel leveranciers reeds ondersteund worden en daarmee een defacto standaard zijn. Dit was voor ons reden om, in ieder geval voor versie 1.2, niet te kiezen voor een compleet andere manier van notificeren waardoor leveranciers en daarmee gemeenten, investeringen moeten doen voor functionaliteit die op dit moment op veel plekken al bestaat en goed werkt.
Het bericht creeërZaak uit de Zaak- Documentservices wordt door de consumer aangeboden aan de provider. De rol van provider wordt ingevuld door het centrale zakenmagazijn, in de rol van Zaaksysteem. In dit centrale zakenmagazijn worden alle Zaakgegevens opgeslagen. Dat vervolgens een zaak overgedragen kan worden aan een vakapllicatie/TSA doet hier niets aan af, de zaak blijft geregistreerd in het centrale zakenmagazijn. Naast het centrale zakenmagazijn kunnen er meer, andere gegevensmagazijnen bestaan. Het centrale zakenmagazijn is echter de bron voor alle zaakgegevens. Vakapplicaties/TSA's dienen alle zaakgegevens (ook) op te slaan in het centrale zakenemagazijn.
Met andere woorden: Wanneer een zaak in behandeling overgedragen wordt aan een vakapplicatie/TSA blijft het centrale zakenmagazijn de plaats waar de zaakgegevens opgeslagen worden. Voor de afhandeling kan een vakapplicatie/TSA een eigen gegevensmagazijn hanteren maar de voor de zaak noodzakelijke gegevens dienen (ook) in het centrale zakenmagazijn opgeslagen te worden. Dit kan middels het updateZaak bericht van de Zaak- Documentservices.
Het afhandelen van een zaak bepaalt niet of een applicatie consumer of provider is van bepaalde services. Het feit dat een vakapplicatie/TSA een zaak verder in behandeling neemt betekent niet dat de vakapplicatie/TSA rol van Zaaksysteem (provider van de Zaak- Documentservices) gaat krijgen, dat is en blijft het centrale zakenmagazijn. De vakapplicatie/TSA blijft consumer van de Zaak- Documentservices.
Het in behandeling overdragen van een zaak van een centraal Zaaksysteem aan een vakapplicatie/TSA betekent ook niet dat een nieuwe zaak aangemaakt wordt, de zaak bestaat immers al en wordt ter verdere afhandeling overgedragen. De vakaplicatie/TSA is dan ook geen Zaaksysteem. Zoals Johannes en Jarich aangeven wordt het overdragen momenteel vaak gerealiseerd met een zakLk01 en eventueel edcLk01 berichten (voor het overdragen van bij de zaak behorende documenten). Deze de facto werkwijze is besproken in de werkgroep Zaak- Documentservices en zal verder uitgewerkt worden voor de komende 1.2 release van de Zaak- Documentservices.
Bijgevoegd de diagrammen uit de specificatie van de Zaak- Documentservices met daarbij de applicaties (webformulieren, vergunningenapplicatie, zaaksysteem) in hun rol van consumer of provider.
Bijlage
Een deel van het probleem dat hier geschetst wordt heeft volgens mij te maken met onvoldoende duidelijke definiëring van betrokken componenten. Binnen GEMMA2 wordt beter gedefinieerd welke functionaliteiten worden onderscheiden en door welke referentiecomponenten ('applicaties') die worden geleverd. Hieronder een poging om te schetsen hoe dat er uitziet en waarom dat behulpzaam is om tot betere afstemming te komen. Dit alles: volgens mij.
In de GEMMA2 IA-architectuurplaat (https://gemmaonline.nl/index.php/GEMMA_2_Informatiearchitectuur) wordt een expliciet onderscheid gemaakt in specifieke functionaliteit ('Opslaan en ontsluiten zaken en documenten') en domeinfunctionaliteit (bijv. gemeentelijk 'Beheren zaken' maar ook 'Bijwerken zaakinformatie' / 'Bijwerken lopende zaken' voor partner en burgers). De in gebruik zijnde aanduiding "zaaksysteem" werkt verwarrend (zie bijv. bovenstaande discussie) omdat daarbij platform- en specifieke functionaliteit in praktijk gemixt worden. Bij een concept-uitwerking van GEMMA2 worden om die reden de termen 'Zakenbeheersysteem' (specifiek) en 'Zakenregistratiesysteem' (platform) gebruikt om 2 verschillende referentiecomponenten (let wel: niet 'applicaties'*) aan te duiden. Dit onderscheid leidt in mijn ogen tot helderder discussies over wat je van welke component verwacht en hoe je de uitwisseling daartussen optimaliseert.
In de zaak-documentservices is dit onderscheid feitelijk al gemaakt door 'consumers' en 'providers' te onderscheiden. "Zaaksysteem" vervult daarbij de rol van wat ik hierboven "Zakenregistratiesysteem" noem. Een zaakserviceconsumer kan een "zakenbeheersysteem" zijn, maar ook bijv. een taakspecifieke applicatie (maar ook bijv. een portaalapplicatie waar een burger zaakinformatie kan actualiseren).
Door een beter onderscheid in platform- en specifieke functionaliteit is er geen discussie meer nodig over de volgorde van gebeurtenissen rondom creatie van een zaak. Een zaak (zoals nu binnen GEMMA gedefinieerd) wordt gecreëerd door het 'zakenregistratiesysteem' als een consumer daartoe verzoekt. Afhandeling van een zaak gebeurt via consumers; dat kan een zakenbeheersysteem zijn, maar ook een TSA, een partnerapplicatie of een burgerportaal. Waarbij we uitkomen bij iets dat we eigenlijk als sinds de eerste versie van NORA weten: we werken binnen een service-georiënteerde architectuur waarin verschillende componenten conform afspraak de services leveren die ze moeten leveren.
ad *) In de huidige praktijk worden platform- en specifieke functionaliteit (voor afhandeling van zaken door een gemeente) vrijwel altijd via 1 applicatie geleverd. Een helderder onderscheid helpt om meer zaakafhandel-flexibiliteit te bieden, iets dat al via het ontwerp van 'de basisgemeente' werd beoogd en oa via de ZaakDocument services wordt bevorderd.