Aan deze wiki wordt momenteel gewerkt. Het kan zijn dat tijdens deze werkzaamheden links niet werken of dat sommige views niet of onvolledig getoond worden.

Cocreatie:Denk mee met Thema Zaakgericht werken

Over dit discussiebord

Als u wil mee discussiëren, gebruik dan deze pagina. Kijk op de pagina forumfunctionaliteit, om te zien hoe de forumfunctionaliteit werkt. De discussie gaat over het onderwerp dat start bij de pagina: Zaakgericht Werken in GEMMA

Door op "Onderwerp toevoegen" te klikken gaat u akkoord met de gebruiksvoorwaarden van deze wiki.
Arjan Kloosterboer (Overlegbijdragen)

In enkele integratiepatronen wordt het zaaktype toegekend door anderen dan medewerkers die kennis hebben van het behandelen van zaken van dat zaaktype. Is dat doenlijk, ligt deze verantwoordelijkheid wel op de juiste plaats? Moet dat niet een medewerker zijn van de vakdiscipline die verantwoordelijk is voor de behandeling van zaken van dat type? Is een ander, die geen vakinhoudelijke kennis heeft, in staat om het juiste zaaktype te bepalen? Bijvoorbeeld, in het integratiepatroon 'Zaak starten via post' bepaalt de Medewerker 'inkomende post' het zaaktype a.d.h.v. het ontvangen document. Kan hij/zij dat goed beoordelen o.b.v. de aard en inhoud van het document? Evenzo bij het integratiepatroon 'Aanvullende informatie indienen op een zaak'. Die medewerker zou dan bovendien de zaak moeten bepalen waarop het document betrekking heeft. Dat vereist gedegen kennis en inzicht in allerlei zaken en zaaktypen. Verder, in het integratiepatroon 'Indienen productaanvraag via webformulier' bepaalt de servicebus het zaaktype. Dat gaat vast goed voor productaanvragen die altijd met hetzelfde zaaktype behandeld worden. Maar wat als dat afhankelijk is van de inhoud van de productaanvraag? Zou het niet zo zijn dat de vakdiscipline de eerst aangewezene is om het van toepassing zijnde zaaktype te bepalen? Zij zijn verantwoordelijk voor de afbakening van processen en zaaktypen. En zij beschikken over de vakinhoudelijke kennis om ontvangen documenten en aanvragen op waarde te kunnen schatten. In sommige gevallen zal het bij een ontvangen aanvraag of document klip en klaar zijn welk zaaktype van toepassing is. Ik kan me voorstellen dat daarover afspraken gemaakt worden met medewerkers inkomende post en servicebusbeheerders. Maar is dat niet het geval, dan hoort deze verantwoordelijkheid thuis bij de vakinhoudelijk verantwoordelijken.

Jgortmaker (Overlegbijdragen)

Iemand moet die post openen en er een zaaktype (en daarmee impliciet ook een behandelaar aan koppelen). Met een beetje training moet dat goed kunnen gaan. En gaat het een keer fout, dan kan dat hersteld worden door een specialist die ziet dat iets verkeerd geclassificeerd is.

Dit is ook erg afhankelijk van de inrichting van de organisatie. Komt alle post op één centraal punt binnen, of heeft iedere vakafdeling een eigen locatie en wellicht ook adres? In de patronen zijn we van het eerste uitgegaan. Dan kan een specialist de post niet openen, om de simpele reden dat niemand specialist burgerzaken, vergunningen, subsidies en uitkeringen zal zijn.

In het proces zoveel mogelijk maatregelen nemen, zodat antwoorden en aanvullende stukken voorzien zijn/worden van zaaknummer/QR-code/... vergemakkelijkt classificatie.

Als er verzoeken zijn waarvan het zaaktype afhangt van de inhoud van de productaanvraag, kun je dat ook prima in de servicebus configureren. Als bijvoorbeeld halverwege het aangifteformulier "verhuizing doorgeven" blijkt dat het een verhuizing naar het buitenland betreft, dan is die informatie onderdeel van de ingevulde gegevens en kan daar eenvoudig het juiste zaaktype aan worden gekoppeld.

Arjan Kloosterboer (Overlegbijdragen)

Op de pagina 'Relatie met zaakgericht werken' staat onder 'Architectuur en zaakgericht werken' een figuur met processen en corresponderende zaaktypen. Het voorbeeld procestype heet 'Behandelen aanvraag omgevingsvergunning' terwijl het corresponderende zaaktype 'Aanvraag omgevingsvergunning' genoemd is. Deze naamgeving van het zaaktype strookt niet met adviezen elders op deze site (over de Zaaktypecatalogus) aangaande de naamgeving van zaaktypen. Die zou moeten bestaan uit in ieder geval een werkwoord en een zelfstandig naamwoord. Hetgeen mij logisch voor komt. Een zaaktype betreft immers net zoals een procestype de beschrijving van handelingen. In de definitie van een zaaktype staat niet voor niets 'een hoeveelheid werk'. De naamgeving van dit zaaktype moet m.i. dan ook gelijkluidend zijn aan die van het corresponderende procestype. Evenzo moet in de instantie van zaaktype, de zaak, niet 'zaak' staan maar bijvoorbeeld 'Zaak 1234_ab-789'. Zaken hebben immers een "nummer".

Jgortmaker (Overlegbijdragen)

klopt. zet ik op de lijst om mee te nemen in een volgende update.

IvoHendriks (Overlegbijdragen)

Onder 'Categorie 2: Generieke Referentiecomponenten voor Zaakgericht Werken (Gemeente)' wordt naar de Generieke Zaakafhandelcomponent gerefereerd als ZAC. Een paar paragrafen later, onder 'Specifieke (domeingerichte) referentiecomponenten voor zaakgericht werken' wordt dat gZAC.

Ik stel voor de afkorting gZAC te hanteren, maar de alinea waarin die tweede referentie wordt gemaakt te verwijderen, aangezien dat subhoofdstuk over specifieke, dus juist niet-generieke functionaliteit gaat.

Jgortmaker (Overlegbijdragen)

ik heb het zoveel als mogelijk aangepast in gZAC.. je tweede opmerking kan ik niet terugvinden...

Bdendulk (Overlegbijdragen)

Voor mij is het volstrekt onduidelijk wat de toegevoegde waar is voor het onderscheid tussen een Generiek Zaakafhandelcomponent en een Specifiek Zaakafhandelcomponent. Er wordt gesproken over sub-componenten die domein specifiek kunnen zijn (zoals vergunningverlening versus burgerzaken). Ik begrijp dat er dus sprake is van specialisaties van zaakafhandelcomponent. Echter, in de beschrijving komen exact dezelfde functionaliteiten terug. Wat maakt ze dan specifiek? Waarschijnlijk de specifieke domein-KENNIS. Dit raakt een voor mij fundamentele discussie waar een aantal overheden (IND, NVWA, etc.) al flinke stappen in hebben gemaakt: het scheiden van de know en de flow. De flow gaat over de processen. De functionaliteiten die worden beschreven, ondersteunen met name de generieke functies die nodig zijn om processen de ondersteunen. Daarnaast is er specifieke kennis nodig om zaken af te handelen. De genoemde overheden doen dit door kennisregels (ook wel bedrijfsregels) expliciet te benoemen. Hierbij is er altijd de keuze om kennisregels te implementeren in systemen dan wel in werkinstructies, training, etc. Bij de NVWA is een zaaktype een bepaalde combinatie van een procestype en een producttype. De specifieke kennis wordt daarbij gekoppeld aan het product (en niet aan het proces). Hierdoor kan prima met een (generiek) zaakafhandelcomponent worden gewerkt. Daarnaast is er sprake van een een ander generiek referentie component die het mogelijk maakt om productspecifieke kennis vast te leggen: VTH product, subsidieproduct, Budget- en schuldhulpverlening product, GBA administratie product, MOR product. Dit zou prima het producten en dienstencatalogus component kunnen zijn. Zowel de IND als de NVWA maken bij het tonen van producten en diensten ook gebruik van intelligente formulieren voor het aanvragen. Hiervoor zijn dezelfde kennisregels nodig die ook bij het afhandelen van de zaken met betrekking tot deze producten nodig zijn. In mijn ogen maakt deze benadering de beschrijving van generieke en specifieke zaakafhandelcomponenten en overerving van functies (zie ook het plaatje "Procesondersteunende systemen en overerving van functies") veel eenvoudiger!

Bdendulk (Overlegbijdragen)

Toevoeging op bovenstaande reactie van mijn kant: De hierboven genoemde constatering voorkomt in mijn ogen ook een nodeloos ingewikkeld landschap van 'referentiecomponenten' die met elkaar moeten communiceren via een service bus.

Ik denk dat het heel erg zinvol is om een aantal patronen van referentiecomponenten naast elkaar te leggen en de voor- en nadelen goed af te wegen:

1. een landschap met best-of-breed systemen: apart formulieren systeem, documenten systeem, proces ondersteunend systeem, eventueel regelsysteem, klantcontacten systeem, etc.

2. een all-in-one landschap met een geïntegreerd systeem waarin zowel klantcontacten, formulieren, documenten, taakafhandeling, eventueel kennisregels worden ondersteund (de insteek bij NVWA)

3. een weloverwogen mix van (1) en (2) zoals bijvoorbeeld (2) per domein binnen de gemeente (de insteek bij IND voor wat betreft keuzes in bundeling van referentiecomponenten)

Jgortmaker (Overlegbijdragen)

klopt, maar met de GEMMA 2 zitten we met bestaande gemeentelijk applicatielandschappen, waarmee we de aansluiting niet mogen verliezen. o.a. met de softwarecatalogus. Bovendien zijn gemeenten nogal hererogene in de implementatie van de referentiecomponenten. Om hiermee om te kunnen gaan, hebben we de referentiecomponenten (en de abstracte referentiecomponenten) geïntroduceerd..

Voor één organisatie kunnen scherpere keuzes gemaakt worden.

Common Ground beoogt trouwens een radicale vernieuwing in het gemeentelijk applicatielandschap die hier erg op lijkt..

Uitreiken uniek documentnummer ontbreekt

2
Erik de Lepper (Overlegbijdragen)

Welke component is verantwoordelijk voor de uitgifte van unieke documentnummers? Voorstel: Documentregistratiecomponent (vergelijk zaakregistratiecomponent)

Jgortmaker (Overlegbijdragen)

waarschijnlijk wel. maar dat is geen functionaliteit die we hoeven opnemen. Het uitgeven van unieke zaaknummers is ook extern interessant, omdat je dat aan een klant wilt meegeven. voor een documentnr is dat niet het geval.

Koppelen met ketenpartners, inzet van referentiecomponenten

4
Mklerks (Overlegbijdragen)

Bij de beschrijving van het generieke zaakafhandelcomponent op https://www.gemmaonline.nl/index.php/ZGW_in_GEMMA_2 staat als één van de functies: "Uitwisselen van berichten met ketenpartners". De gegevens die de gemeente zal willen uitwisselen, zal meestal gaan om de gegevens (en documenten) die in de gedeelde ( ! ) generieke functionaliteit staat: de zaakregistratiecomponent en de documentregistratiecomponent. Waarom zou de gemeente hier nog de generieke zaakafhandelcomponent, die mogelijk geeneens alle zaken en documenten bevat, tussenin zetten?

Jgortmaker (Overlegbijdragen)

het uitwisselen van berichten gebeurt vanuit het proces en dus vanuit de zaakafhandelcomponent. In de zaak- of documentregistratiecomponent zitten enkel gegevens en geen proceslogica/functionaliteit

Mklerks (Overlegbijdragen)

De functie staat (uiteraard) ook bij het specifieke zaakafhandelcomponent (abstracte component). Daarbij geldt natuurlijk hetzelfde argument. Nu vraag ik mij wel af of het wenselijk is om berichten uit bijvoorbeeld de OLO eerst binnen te laten komen bij de zaak- en documentregistratiecomponenten om vanuit daar door te schieten naar de vergunningencomponent. Of willen we de OLO primair koppelen aan de vergunningencomponent en vanuit daar doorschieten naar de zaak- en documentregistratiecomponenten? Of sturen we vanuit de ESB de nodige berichten naar alle componenten (dus niet via-via)?

Een ander passend voorbeelden zijn de Landelijke Online Diensten, zoals het nieuwe verhuizingenformulier. Deze gaat straks StUF-EF-berichten aan gemeenten aanbieden. Hoe gaan we die door de componenten heen jagen?

Jgortmaker (Overlegbijdragen)

zie het integratiepatroon "indienen productaanvraag" De aanvraag gaat vanuit de e-formulierencomponent/LOD/OLO naar de zaakafhandelcomponent (bv. een verguningsysteem, burgerzakensysteem of een generiek zaaksysteem). Al dan niet na tussenkmost van een servciebus.

StUF EF bestaat niet meer. er komt een productaanvragen API voro in de plaats, te beginnen met de 2 LOD diensten.

Templates horen niet in het documentbeheercomponent?

2
Mklerks (Overlegbijdragen)

Op https://www.gemmaonline.nl/index.php/ZGW_in_GEMMA_2 staat bij de omschrijving van het documentbeheercomponent ook de functie "Maken en beheren templates". Deze functie hoort m.i. thuis in het documentcreatiecomponent.

Jgortmaker (Overlegbijdragen)

Goede vraag. Dit zit al even zo in GEMMA 2. Ik heb het op de lijst uit te zoeken punten gezet. Zoals het er nu staat zou ik het ook bij de documentcreatiecomponent zetten. Maar misschien zijn er wel meerdere soorten templates..

Communicatiekanalen wel of niet rood?

2
Mklerks (Overlegbijdragen)

Op https://www.gemmaonline.nl/index.php/ZGW_in_GEMMA_2 zijn de applicatiefuncties en referentiecomponenten die rechtstreeks te maken hebben met het zaakgericht werken rood gekleurd. Onder andere het CRM is rood gekleurd. Als ik hierop klik, dan heeft het nogal een hoog telefonie-gehalte. Ook de E-formulieren zijn rood gekleurd. Dat zijn dus twee kanalen? Waarom dan niet de scanning- en imagingcomponent?

En als je de E-formulieren rood kleurt, horen de onlinebetalingcomponent en de afsprakenbeheercomponent daar niet ook bij? En als je deze componenten aan de burgerkant (blauw blok) rood inkleurt, oor je ze dan ook niet aan de gemeentekant (groen blok) in te kleuren?

Waar ligt de grens?

Mijn advies is om 3 kleuren te hanteren: case-management, document management en digitale dienstverlening. Ik denk dat dat gemeenten helpt om ïntern te bespreken wat ze wel en wat niet wilen meenemen in hun ZGW-aanpak.

Jgortmaker (Overlegbijdragen)

dank. scanning- en imagingcomponent was ik vergeten.

de andere twee componenten hebben vele te maken met dienstverlening, maar niet met afhandelen van zaken. Komen ook niet in de patronen voor.

maar meer algemeen: niet teveel gewicht hangen aan de kleurtjes. het is vooral een overzicht van de componenten die verderop nog terugkomen.

Moet het PDC ook rood gekleurd?

3
Mklerks (Overlegbijdragen)

Op https://www.gemmaonline.nl/index.php/ZGW_in_GEMMA_2 zijn de applicatiefuncties en referntiecomponenten die rechtstreeks te maken hebben met het zaakgericht werken rood gekleurd. Het PDC is niet rood gekleurd.

In de ZTC 2.1 (https://www.gemmaonline.nl/index.php/GEMMA_Zaaktypecatalogus) wordt echter een nauwe relatie gelegd met het PDC. Zou het PDC dan toch rood gekleurd moeten zijn?

Jgortmaker (Overlegbijdragen)

het betreft de componenten die op deze pagina en/of in de patronen verder worden toegelicht..tekst is verduidelijkt.

Jgortmaker (Overlegbijdragen)

het betreft hier de componenten die te maken hebben met het afhandelen van zaken, maar vooral de componenten die verderop op de pagina of bij de integratiepatronen terugkomen.. tekst hierop verduidelijkt

Voorzet User Stories "Mijn Zaken" voor ZDS nieuwe stijl

2
Cathy Dingemanse (Overlegbijdragen)

Bij deze een requirement voorstel vanuit de gemeente Den Haag, bezien vanuit het perspectief van onze klanten. Brenda en ik zijn benieuwd wat jullie er van vinden!


Als persoon of vertegenwoordiger van een persoon met een of meer zaken bij de/ een overheid

Wil ik een overzicht van de zaken bij de/ een overheid waarbij ik betrokken ben (mijn zaken)

Zodat ik geen enkele zaak over het hoofd zie

En mijn zaken kan raadplegen

En kan zien welke zaken lopen en welke zaken zijn afgesloten.


Als persoon of vertegenwoordiger van een persoon met een of meer zaken bij de/ een overheid

Wil ik direct genotificeerd worden over iedere relevante ontwikkeling binnen mijn zaak

Zodat ik geen enkele ontwikkeling binnen een zaak over het hoofd zie

En kennis kan nemen van de laatste ontwikkeling(en) binnen mijn zaak

En tijdig de input kan leveren waar een behandelaar om vraagt

En tijdig kan reageren of een vraag kan stellen.


Als persoon of vertegenwoordiger van een persoon met een zaak bij de/ een overheid

Wil ik een zaak kunnen raadplegen

Zodat ik kan zien wie er in welke rol betrokken zijn bij mijn zaak

En kan zien wat de laatste status is

En kennis kan nemen van de beslistermijn van een zaak

En kan zien wie ik kan bellen als ik een vraag heb

En kan zien of de zaak binnen de afgesproken termijn is behandeld

En kan zien welke andere zaken een relatie hebben met mijn zaak.


Als persoon of vertegenwoordiger van een persoon met een zaak bij de/ een overheid

Wil ik de status van mijn zaak kunnen inzien

Zodat ik kennis kan nemen van de status van mijn zaak en bijbehorende documenten

En kan zien of er een of meer activiteiten van mijn kant worden verwacht

En een genomen besluit en bijbehorende documenten kan inzien

En klantcontacten kan raadplegen.


Als persoon of vertegenwoordiger van een persoon met een zaak bij de/ een overheid

Wil ik een klantcontact kunnen opvoeren

Zodat ik Documenten kan aanleveren waar een behandelaar bij deze status om vraagt

En kan reageren op een vraag of opmerking van een behandelaar

En een vraag of reactie kan plaatsen over de status van de zaak.


Als persoon of vertegenwoordiger van een persoon met een zaak bij de/ een overheid

Wil ik een klantcontact kunnen raadplegen

Zodat ik documenten kan inzien die ik heb aangeleverd

En mijn vragen en reacties kan teruglezen

En de vragen, reacties, documenten van en afspraken met de behandelaar kan teruglezen

En de antwoorden van en afspraken met een KCC medewerker kan teruglezen

En kan zien wanneer documenten, vragen, reacties en afspraken zijn geplaatst.

Michiel Verhoef (Overlegbijdragen)

Bedankt voor de user stories! In de geest van de CommonGround heb ik ze opgenomen als issues op de GitHub omgeving waarin we de zaakgerichte standaarden willen ontwikkelen: https://github.com/VNG-Realisatie/gemma-zaken/issues.

Ik stel voor dat iedereen die wil reageren of met een user story aan de slag wil dat in de GitHub omgeving doet. Ook nieuwe user stories kunnen gelijk als issue aangemaakt worden.

Voor toegang etc., neem contact met mij of een van de andere beheerders (Eelco Hotting, Arnaud Quanjer) op.

Er zijn geen oudere onderwerpen