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

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.

Figuur 18: Overzicht generieke componenten (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv

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

Casus MijnGemeente

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

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

• 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

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

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

• 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

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

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

• 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

Sjabloonoplossing voor de architectuur van een bepaald domein.

De fundamentele concepten of eigenschappen van een systeem in zijn omgeving belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.

Afkorting van 'application programming interface': een manier om twee of meer computerprogramma's met elkaar te laten communiceren. Het is een soort software-interface die een dienst aanbiedt aan andere stukjes software.

Betekenisvolle gegevens.

Communicatiekanaal dat bij de dienstverlening wordt gebruikt. Elk kanaal kent verschillende vormen waarin informatie kan worden gedeeld.

Een samenhangende set Diensten, Bedrijfsobjecten en/of Representaties die onder in een Overeenkomst beschreven voorwaarden kan worden afgenomen.

Alle belanghebbenden van overheidsdienstverlening in de ruimste zin van het woord.

Een overzicht van de voorkeuren en behoeften van de klant op basis van geagregeerde klancontactinformatie

Een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden.

Een afgebakende prestatie van een persoon of organisatie (de dienstverlener), die voorziet in een behoefte van haar omgeving (de dienstafnemer(s)).

De door een aanbieder aan afnemers verstrekte gegevens over binnen zijn domein plaatsgevonden gebeurtenissen