Omnichannel MijnZaken Bijlagen

Dit hoofdstuk omvat de bijlagen bij de referentiearchitectuur MijnZaken, waarin onder andere de casussen die zijn gebruikt om deze architectuur vorm te geven nader zijn beschreven.

Overzicht generieke MijnZaken-componenten[bewerken]

Onderstaande afbeelding toont de generieke componenten en API’s die betrokken (kunnen) zijn bij het ontstaan of tonen van MijnZaken-informatie. Het betreft hier een verzameling van de componenten die voor de verschillende casussen benodigd kunnen zijn.

ArchiMateNote Laag 4 - Proceslogica ApplicationComponent Processturingcompo- nent ArchiMateNote Laag 3 - Integratie Component voor het routeren, transformeren en eventueel orkestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent Een toegangspunt voor API's dat verzoekverwerking uitvoert op basis van gedefinieerd beleid inclusief authenticatie, autorisatie, toegangscontrole, SSL/TLS-offloading, routering en load-balancing. (ApplicationComponent) API Gatewaycomponent ArchiMateNote Laag 2 - Diensten De Verzoeken API standaardiseert het creëren, bijwerken, lezen en verwijderen van verzoekgegevens. (ApplicationInterface) Verzoeken API De Zaken API standaardiseert het creëren, bijwerken, lezen en verwijderen van zaakgegevens. (ApplicationInterface) Zaken API De Besluiten API standaardiseert het creëren, bijwerken, lezen en verwijderen van besluitgegevens. (ApplicationInterface) Besluiten API De Contactmomenten API standaardiseert het creëren, bijwerken, lezen en verwijderen van gegevens die een contactmoment beschrijven. (ApplicationInterface) Contactmomenten API API voor het loggen, opvragen, wijzigingen en verwijderen van verwerkingsacties (ApplicationInterface) Verwerkingenlogging API ApplicationInterface Toestemmingen API ApplicationInterface Afspraken API ApplicationInterface Gebruikersbeheer API ApplicationInterface Producten en Diensten API ApplicationInterface Catalogi API De Documenten API standaardiseert het creëren, bijwerken, lezen en verwijderen van informatieobjecten en bijbehorende metagegevens. (ApplicationInterface) Documenten API De Klanten API standaardiseert het creëren, bijwerken, lezen en verwijderen van klantgegevens. (ApplicationInterface) Klanten API ApplicationInterface Bevraging Ingeschreven Persoon API ApplicationInterface Objecttypen API ArchiMateNote Laag 1 - Gegevens Component voor de opslag en ontsluiting van identiteiten van gebruikers en de rechten die zij hebben. (ApplicationComponent) Gebruikersbeheerco- mponent Component voor uitvoering van de gemeentelijke taken rondom de registratie van persoonsgegevens. (ApplicationComponent) GBA- administratiecompon- ent ApplicationComponent Verzoekenregister Component voor opslag en ontsluiting van zaakgegevens. (ApplicationComponent) Zaakregistratiecomp- onent Component voor opslag en ontsluiting van besluitgegevens. (ApplicationComponent) Besluitregistratiecom- ponent Component voor het maken van afspraken tussen burgers, bedrijven en ambtenaren. (ApplicationComponent) Afsprakenbeheercom- ponent ApplicationComponent Contactmomentenre- gister Component voor het centraal vastleggen van gegevens over de activiteiten die gebruikers uitvoeren met vertrouwelijke gegevens. (ApplicationComponent) Verwerkingenloggin- gcomponent ApplicationComponent Toestemmingenregis- ter Component voor het onderhouden van gegevens over producten en diensten en het (interactief) presenteren daarvan aan burgers en bedrijven. (ApplicationComponent) Producten-en- dienstencatalogusco- mponent Component voor opslag en ontsluiting van zaaktypegegevens. (ApplicationComponent) Zaaktypecatalogusco- mponent Component voor opslag en ontsluiting van documenten en daarbij behorende metadata. (ApplicationComponent) Documentregistratie- component Component voor opslag en ontsluiting van klantgegevens. (ApplicationComponent) Klantregistratiecomp- onent Component voor ontvangen van notificaties van bronsystemen en het routeren daarvan naar geabonneerde afnemers. (ApplicationComponent) Notificatierouteringc- omponent ApplicationComponent Objecttypenregister ArchiMateNote Laag 3 - Landelijke integratie ApplicationComponent Landelijke integratiecomponent ArchiMateNote Laag 2 - Landelijke diensten Applicatieservice voor het authenticeren van burgers (ApplicationService) DigiD authenticatieservice ApplicationService DigiD Machtigen Landelijk systeem voor authenticatie van bedrijven inclusief bijbehorend machtigingen register. (ApplicationService) eHerkenning authenticatie en machtigingenservice ArchiMateNote Laag 5 - Interactie Component voor het ontwikkelen, publiceren, laten invullen, indienen en bevestigen van elektronische formulieren. (ApplicationComponent) E-formulieren publicatie-en- beheercomponent De interactiecomponent voor het tonen van statusinformatie wordt gebruikt om via een specifiek kanaal statusinformatie bij lopende aanvragen van producten of diensten aan een burger, (vertegenwoordiger van een) bedrijf of medeweker te tonen. De interactiecomponent voor het tonen van statusinformatie is een abstract component. Dat betekent dat verschillende concrete componenten (zoals een Mijngemeentecomponent) de functies die horen bij het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Interactiecomponent voor het tonen van statusinformatie (abstracte component) De kanaalspecifieke aanvraagcomponent ondersteunt het aanvragen van producten of diensten bij de gemeente via één of meerdere specifeke kanalen. De kanaalspecifieke aanvraagcomponent is een abstract component. Dat betekent dat verschillende concrete componenten (zoals een E-formulieren publicatie-en-beheercomponent) de functies die horen bij het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Kanaalspecifieke aanvraagcomponent (abstracte component) Component die via webtechnologie veilig toegang biedt tot persoonlijke informatie en gepersonaliseerde digitale dienstverlening. (ApplicationComponent) Mijngemeentecompo- nent ApplicationComponent Chatcomponent Component voor het ontvangen en versturen van berichten binnen sociale media waarbij met persoonlijke voorkeuren rekening wordt gehouden. (ApplicationComponent) Sociale mediacomponent Component voor het onderhouden van relaties met klanten of organisaties. (ApplicationComponent) Relatiebeheercompo- nent (CRM) ApplicationComponent Klantcontactcentrum- component ApplicationComponent E-mailcomponent Component voor het aanmaken van documenten waarbij vaste teksten/templates worden gecombineerd met gegevens. (ApplicationComponent) Documentcreatieco- mponent ApplicationComponent Specifiek procesafhandelcomp- onent Abstract verzamelcomponent voor procesondersteunende systemen die zaakgericht zijn ingericht. (ApplicationComponent) Zaakafhandelcompo- nent (abstract component) ArchiMateNote Laag 1 - Landelijke gegevens SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship Deze svg is op 29-05-2024 14:19:37 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 14:19:37 CEST
Figuur 18: Overzicht generieke componenten (open view in nieuw venster)

Om generieke interactiepatronen te kunnen vormgeven, toont bovenstaand model drie abstracte componenten, die hieronder nader worden toegelicht. Een nadere beschrijving van de meeste andere opgenomen componenten is te vinden in het overzicht van referentiecomponenten].

Component Beschrijving
Interactiecomponent voor het tonen van statusinformatie De interactiecomponent voor het tonen van statusinformatie wordt gebruikt om via een specifiek kanaal statusinformatie bij lopende aanvragen van producten of diensten aan een burger, (vertegenwoordiger van een) bedrijf of medewerker te tonen. De interactiecomponent voor het tonen van statusinformatie is een abstract component. Dat betekent dat verschillende concrete componenten (zoals een Mijngemeentecomponent) de functies die horen bij de interactiecomponent voor het tonen van statusinformatie kunnen vervullen.
Kanaalspecifieke aanvraagcomponent De kanaalspecifieke aanvraagcomponent ondersteunt het aanvragen van producten of diensten bij de gemeente via één of meerdere specifieke kanalen. De kanaalspecifieke aanvraagcomponent is een abstract component. Dat betekent dat verschillende concrete componenten (zoals een E-formulieren publicatie-en-beheercomponent) de functies die horen bij de Kanaalspecifieke aanvraagcomponent kunnen vervullen.
Procesondersteunende component Abstract verzamelcomponent voor procesondersteunende systemen die zaakgericht zijn ingericht.

Casussen[bewerken]

Casus MijnGemeente[bewerken]

Deze casus is beschreven voor gemeenten.

Burgers, bedrijven of instellingen die producten van de overheid afnemen, weten vaak niet (goed genoeg) wat de status van hun verzoek is of hoe lang het nog gaat duren voordat het product geleverd wordt. Het komt voor dat ze met meerdere organisaties contact moeten opnemen om dit te achterhalen – het bekende van het kastje naar de muur sturen. Met MijnZaken kunnen burgers en bedrijven de levering van producten en diensten volgen, ook als daarbij meerdere overheidsorganisaties betrokken zijn. Zij worden proactief en via een kanaal naar keuze geïnformeerd over die levering.

Een aantal gemeenten gaat een MijnGemeente-omgeving implementeren ter ondersteuning van de dienstverlening aan burgers en bedrijven. De basis hiervoor is het Integraal Klantbeeld, waarvan MijnZaken-informatie een onderdeel is. De scope van deze casus is groot genoeg om aan te kunnen tonen dat de uitgewerkte architectuur toegepast kan worden om burgers en ondernemers via een webportaal te informeren, en klein genoeg om de benodigde software en processen middels een beperkt aantal componenten in beperkte tijd te implementeren.

Casusbeschrijving[bewerken]

Een inwoner wil op een persoonlijke pagina van een gemeente (MijnGemeente portaal) een overzicht van relevante klantgegevens in samenhang zien. Hierbij worden alleen die gegevens getoond waartoe de inwoner geautoriseerd is. Het opvragen van de gegevens wordt vastgelegd ter verantwoording aan de inwoner. Wij denken op dit moment dat hiervoor onderstaande gegevens nodig zijn.

Relevante gegevens[bewerken]

  • Naam- en contactgegevens
  • Klantvoorkeuren
  • Aangevraagde en geleverde producten
    • Geleverde producten
    • Lopende aanvragen inclusief status
    • Bij aanvragen geleverde documenten
  • Zaken
    • Afgeronde zaken
    • Lopende zaken inclusief inzage in status en behandelaar
    • Documenten bij een zaak
    • Besluiten genomen bij een zaak
  • Contactmomenten
    • Gevoerde contacten
    • Toekomstige afspraken
  • Verwerkingenlogging-gegevens

Casus CRM[bewerken]

Deze casus is beschreven voor gemeenten.

Een goed geïnformeerde burger staat minder vaak aan de balie. En doordat overheidsorganisaties op een eenduidige manier informatie met elkaar delen, kunnen vragen worden beantwoord door een klantenservicemedewerker in plaats van de vakspecialist. Zij hebben daardoor meer tijd voor het leveren van goede dienstverlening en ondersteuning op maat. MijnZaken-informatie kan daarnaast worden gebruikt voor het bewaken van het verloop van (keten)processen en het bijsturen van de inrichting daarvan.

Een aantal organisaties gaat een CRM-platform implementeren. De basis hiervoor is het Integraal Klantbeeld, waarvan MijnZaken-informatie een onderdeel is. De scope van deze casus is groot genoeg om aan te kunnen tonen dat de uitgewerkte architectuur toegepast kan worden om KCC-medewerkers te ondersteunen bij het informeren van burgers en ondernemers, en klein genoeg om de benodigde software en processen middels een beperkt aantal componenten in beperkte tijd te implementeren.

Casusbeschrijving[bewerken]

Een medewerker van de gemeente wil inwoners goed voor kunnen lichten. Daarvoor is het nodig dat het CRM-platform een overzicht van relevante klantgegevens in samenhang toont. Hierbij worden alleen die gegevens getoond waartoe de medewerker geautoriseerd is. Het opvragen van de gegevens wordt vastgelegd ter verantwoording aan de inwoner. Wij denken op dit moment dat hiervoor onderstaande gegevens nodig zijn.

Relevante gegevens[bewerken]

  • Naam- en contactgegevens
  • Klantvoorkeuren
  • Aangevraagde en geleverde producten
    • Geleverde producten
    • Lopende aanvragen inclusief status
    • Bij aanvragen geleverde documenten
  • Zaken
    • Afgeronde zaken
    • Lopende zaken inclusief inzage in status en behandelaar
    • Documenten bij een zaak
    • Besluiten genomen bij een zaak
  • Contactmomenten
    • Gevoerde contacten
    • Toekomstige afspraken

Statusuitwisseling tussen organisaties[bewerken]

Behandelaars van zaken waarvan de behandeling (deels) is uitbesteed aan externe organisaties hebben inzicht nodig in de voortgang van die behandeling door die externe organisaties. Bovendien komt het voor dat burgers, bedrijven of instellingen met meerdere organisaties contact moeten opnemen om te achterhalen hoe het er met hun aanvraag van een product of dienst voorstaat – het bekende van het kastje naar de muur sturen. Met MijnZaken kunnen medewerkers van overheidsorganisaties, burgers en bedrijven de levering van producten en diensten volgen, ook als daarbij meerdere overheidsorganisaties betrokken zijn. Zij worden proactief en via een kanaal naar keuze geïnformeerd over die levering.

Een aantal organisaties gaat een beperkte omgeving implementeren. De basis hiervoor is het Integraal Klantbeeld, waarvan MijnZaken-informatie een onderdeel is. De scope van deze casus is groot genoeg om aan te kunnen tonen dat de uitgewerkte architectuur over meerdere organisaties heen toegepast kan worden, en klein genoeg om de benodigde software en processen middels een beperkt aantal componenten in beperkte tijd te implementeren.

Casusbeschrijving[bewerken]

Twee overheidsorganisaties zijn betrokken bij de levering van één product of dienst aan een burger of ondernemer. Bij de eerste organisatie (de leverancier) wordt door een burger een product aangevraagd waarvoor een deelproduct van een tweede organisatie (de onderaannemer) aan de leverancier geleverd wordt.

De leverancier bestelt dit deelproduct bij de tweede organisatie. De onderaannemer geeft een notificatie aan de eerste organisatie door als een behandelstatus voor het deelproduct is veranderd. Op basis daarvan kan de leverancier de status van de behandeling van het deelproduct bij de onderaannemer opvragen. Voor deze casus denken wij dat de tenminste onderstaande gegevens nodig zijn.

Relevante gegevens[bewerken]

  • Producten
    • Overzicht te leveren producten door organisaties aan elkaar
  • Aangevraagde en geleverde producten
    • Lopende aanvragen inclusief status
    • Bij aanvragen geleverde documenten
  • Zaken (gestart door de onderaannemer naar aanleiding van aanvraag door leverancier)
    • Lopende zaken inclusief inzage in status en behandelaar
    • Documenten bij een zaak
    • Besluiten genomen bij een zaak
Deze pagina is voor het laatst bewerkt op 5 jun 2024 om 02:00.