Omnichannel MijnServices

Category:Omnichannel
== Inleiding ==
In aanvulling op de omnichannel-kanaalstrategie is in 2020 een referentiearchitectuur Omnichannel beschreven. In die referentiearchitectuur is een aantal perspectieven beschreven die invulling geven aan omnichannel. Eén van de aspecten is het kunnen tonen van een integraal of samengesteld klantbeeld. Daarvan is op GEMMA Online een beperkte uitwerking gemaakt. Veel gegevens die nodig zijn om een integraal of samengesteld klantbeeld te kunnen tonen, gaan over zaken die een burger of bedrijf bij een gemeente heeft lopen. De architectuur hiervan is te vinden in een apart beschreven referentiearchitectuur MijnZaken. Bij het gebruik van de MijnZaken service, blijkt dat dienstverlening met een burger of bedrijf verder gaat dan alleen het kunnen tonen en volgen van zaken en bijbehorende zaakgegevens. Een aanvulling op deze dienstverlening is de interactie die geboden wordt tussen burgers of bedrijven en de overheid. Hoe deze interactie kan worden vormgegeven, welke componenten, welke afspraken en welke (beoogde) standaarden daarbij nodig zijn, staat beschreven in deze referentiearchitectuur: de referentiearchitectuur MijnServices. Door de MijnServices in de dienstverlening toe te passen, wordt de dienstverlening vanuit een gemeente meer interactief, krijgt de burger of bedrijf meer mogelijkheden om digitaal te reageren, is de gemeente transparanter in de dienstverlening naar burgers of bedrijven en geeft het de burger of bedrijf meer controle op hoe de burger of bedrijf met de gemeente wil of kan interacteren.
MijnServices is een verzameling van digitale (gegevens) services die gebruikt worden in interactiepatronen tijdens de digitale communicatie tussen burgers of bedrijven en de overheid en tussen overheden onderling. Deze services worden als overheidsbreed toepasbare services ontwikkeld, waarbij (landelijke) standaardisatie het uitgangspunt is. Ze worden bewust platform-, kanaal-, product- en organisatieonafhankelijk ontwikkeld zodat een bredere toepassing binnen de gehele overheid mogelijk is. Omdat het uitgangspunt een (landelijke) standaardisatie van de services is, wordt in deze referentiearchitectuur al gesproken over de 'standaard'.
De MijnServices omvat een aantal services:
* MijnZaken service
* MijnTaken service
* MijnBerichten service
* MijnContactmomenten service
* MijnProfiel service
* Notificatie service
De services leveren een set gegevens op die gebruikt kunnen worden in interactiecomponenten zoals websites, apps, chatbots of applicaties voor medewerkers. Door informatiemodellen is onderlinge samenhang tussen de services geborgd en kunnen specifieke API’s ontwikkeld worden voor het bevragen van de gegevens uit de onderliggende registraties of voorzieningen.
Leveranciers van zowel dienstaanbiedende componenten (zoals registratie-componenten) als dienstafnemende componenten (zoals websites, persoonlijke internet pagina’s, chatbots, zaakafhandelcomponenten of zelfs landelijke overheidsportalen) kunnen softwareproducten ontwikkelen die voldoen aan deze standaard. Daarmee wordt bereikt dat gegevens kanaalonafhankelijk, organisatieonafhankelijk en productonafhankelijk aan burgers, bedrijven en medewerkers kunnen worden getoond om zo in een optimale dienstverlening te voorzien.
=== Doel en resultaat ===
Het doel van deze referentiearchitectuur is het beschrijven van de globale architectuur en de keuzen die daarin voor de MijnServices gemaakt zijn.
De referentiearchitectuur bevat de hoofdkeuzen voor te ontwikkelen oplossingen. Daarnaast zorgt de referentiearchitectuur dat oplossingen aansluiten op referentiearchitectuur van Omnichannel en MijnZaken en voldoet aan de gestelde kaders uit de NORA. Dit geheel zorgt ervoor dat de veranderopgave in samenhang met andere veranderingen wordt gerealiseerd en past binnen de gewenste toekomstvaste informatievoorziening van overheden in het algemeen en gemeenten in het bijzonder.
Deze referentiearchitectuur stelt organisaties in staat om een eigen, afgeleide doelarchitectuur op te stellen. Van daaruit voeren organisaties stapsgewijs veranderingen door tijdens de uitvoering van projecten. Het ontwerp van de verandering kan worden vastgelegd in een Project Start Architectuur (PSA). De PSA is gehouden aan de oplossingsrichting en de kaders die beschreven staan in de doelarchitectuur van de organisatie.
De NORA en dochter GEMMA zijn de overkoepelende kapstok met algemene kaders en richtlijnen waar elke referentiearchitectuur aan moet voldoen om een voorziening te realiseren dat werkt en op een eenduidige en samenhangende manier is opgezet.
=== Grondslagen ===
De principes uit zowel de NORA als de GEMMA zijn gebruikt om deze referentiearchitectuur op te stellen. Het gaat te ver om elk principe uitvoerig te beschrijven. Daarom wordt verwezen naar de locatie waar de principes staan.
* NORA: De Kernwaarden van dienstverlening, de Kwaliteitsdoelen, Principes en Implicaties
* GEMMA: Principes en GEMMA implicaties
* Wmebv: Wmebv
=== Uitgangspunten ===
Deze referentiearchitectuur gaat uit van onderstaande uitgangspunten.
==== Standaarden voor Zaakgericht Werken ====
Het belangrijkste uitgangspunt is dat de overheidsorganisatie zaakgericht werkt, zaakgericht registreert of in ieder geval informatie over lopende processen volgens de conventies van zaken beschikbaar stelt. Daarbij wordt gebruik gemaakt van de API-standaarden voor Zaakgericht Werken zoals deze gedefinieerd zijn door VNG. Meer informatie over deze manier van werken (of registreren) en de specificaties van de standaarden is te vinden op de website van VNG of op de Github pagina van VNG.
==== Standaarden voor Klantinteractie ====
Een aantal afspraken en specificaties voor de standaarden voor klantinteractie wordt samen met gemeenten, andere overheden en leveranciers ontworpen en ontwikkeld vanuit dit programma. Daarbij wordt gebruik gemaakt van ideeën en ontwikkelingen die VNG al op Github heeft uitgewerkt. Nieuwe ontwerpen, ontwikkelingen en toepassingen of aanpassingen aan bestaande uitwerkingen worden in samenwerking met VNG besproken en verwerkt in zowel deze referentiearchitectuur als de informatie op de Github pagina van de VNG.
==== NL Design System (NLDS) ====
Interactie vanuit de overheid met burgers, bedrijven of instellingen moet op een zo eenduidig mogelijke manier plaatsvinden. Zeker wanneer MijnOmgevingen in de vorm van portalen worden aangeboden. Als de look-and-feel van de portalen overal hetzelfde is, is het voor burgers direct herkenbaar dat ze te maken hebben met een overheidswebsite of -portaal. Het standaardiseren van de wijze van opbouw, manier van werking en hoeveelheid aan gegevens die getoond worden in een portaal helpt daarbij. Daarbij wordt gebruik gemaakt van bouwblokken van NL Design System van Gebruiker Centraal. Door de bouwblokken in elk portaal op te nemen, wordt eenzelfde uitstraling en werking mogelijk van de MijnOmgevingen. Deze referentiearchitectuur gaat er vanuit dat NLDS wordt toegepast bij het vormgeven van de portalen.
==Bedrijfsarchitectuur==
De MijnServices worden primair ontwikkeld vanuit de context van gemeenten. Bij het ontwerpen, ontwikkelingen, realiseren en implementeren wordt echter ook rekening gehouden met het toepassen van deze voorzieningen bij en door andere overheidsorganisaties. Op deze manier wordt overheidsbreed eenzelfde manier van interactie geborgd door gebruikte standaarden en interactiepatronen. Hierdoor overstijgen de Generieke Services de gemeentelijke context.
===Capabilities===
Capabilities geven aan wat een organisatie doet in het kader van de MijnServices. Het geeft aan welke vaardigheden een organisatie moet bezitten. Hoe een organisatie dat doet en hoe een organisatie de vaardigheden inzet, wordt gemodelleerd door diensten en processen.
=== Bedrijfsobjecten ===
Een bedrijfsobject is een concept dat binnen een bepaald domein wordt gebruikt en betekenis heeft. Onderstaande bedrijfsobjecten zijn relevant voor de MijnServices.
=== Actoren en rollen ===
Een klant kan zowel een burger als een bedrijf zijn. De klant is een dienstafnemer van een organisatie dat als dienverlener optreedt. De relaties tussen overheden (waarin een organisatie zowel de rol van dienstafnemer als dienstverlener kan aannemen) is in dit model niet meegenomen. Dit model is gericht op de interactie tussen een burger/bedrijf en een overheidsorganisatie.
=== Kanalen, diensten en processen ===
Een organisatie verleent globaal genomen via twee verschillende type kanalen haar (interactieve) dienstverlening: via een offline (of analoog) kanaal en via een online (of digitaal) kanaal. Voorbeelden van offline kanalen zijn een balie, post of telefonie. Onder een online kanaal worden bijvoorbeeld websites en apps geschaard.
De interactieve dienstverlening wordt gerealiseerd door een aantal interne processen. Dit zijn processen voor het verwerken en beschikbaar stellen van zaakgegevens, contactmomentgegevens, taakgegevens en berichten. Ook het proces van notificeren is een vorm van dienstverlening.
== Informatiearchitectuur ==
In de informatiearchitectuur worden de verschillende applicatieservices en applicatiecomponenten beschreven. De applicatieservices die gebruikt kunnen worden door de interactiecomponenten, worden beschreven evenals de applicatieservices die door de onderliggende registers worden geleverd.
=== Applicatieservices t.b.v. overheidsportalen ===
Ten behoeve van de interactie met burgers of bedrijven wordt een Interactieve dienstverleningscomponent ingezet. De component kan in verschillende verschijningsvormen voorkomen. In bovenstaande figuur zijn Mijngemeentecomponent en MijnOverheid.nl een specialisatie van dit component. Andere voorbeelden zijn een chatcomponent of een KCC-applicatie.
De Interactieve dienstverleningscomponent realiseert vijf generieke applicatieservices welke andere applicatieservices gebruiken. De opbouw en gebruik van de applicatieservices wordt in de volgende paragrafen beschreven.
Door het programma wordt een aantal applicatieservices ontworpen en ontwikkeld. Deze services kunnen zowel bedoeld zijn voor interactiecomponenten als services die bedoeld zijn voor registratiecomponenten. Daarnaast wordt een aantal al ontwikkelde services gebruikt. In de getoonde modellen in onderstaande paragrafen is een onderverdeling gemaakt in drie categorieën:
* nieuwe services die gerealiseerd worden door de interactiecomponenten (de dienstafnemers)
* nieuwe services die gerealiseerd worden door registratiecomponenten (de dienstaanbieders)
* bestaande services die eerder ontwikkeld zijn.
Het programma richt zich op de services die (nog) ontwikkeld worden: de nieuwe services.
==== MijnZaken service ====
Deze MijnZaken service is een verzameling van services die gebruikt worden in portalen of andere soorten interactiecomponenten. De MijnZaken service geeft een overzicht van lopende en afgeronde zaken, geeft details van de zaak en toont daarbij een overzicht van de contactmomenten die bij de zaak geregistreerd zijn.
De service die onder MijnZaken vallen zijn nieuwe services. Ze maken gebruik van services die gerealiseerd worden door registratiecomponenten die onderdeel uitmaken van de API-standaard voor Zaakgericht Werken. 
De service Overzicht lopende zaken geeft een lijst met zaken van één burger die de organisatie in behandeling heeft. Daarbij worden minimaal de volgende gegevens in de lijst getoond:
* Zaaknummer
* Zaakomschrijving
* Registratiedatum
* Status
* Organisatienaam (optioneel; indien afnemende organisatie anders is dan aanbiedende organisatie)
De service Overzicht afgeronde zaken geeft een lijst met zaken van één burger die door de organisatie afgerond zijn. Daarbij worden minimaal de volgende gegevens in de lijst getoond:
* Zaaknummer
* Zaakomschrijving
* Datum afgerond
* Resultaat
* Organisatienaam (optioneel; indien afnemende organisatie anders is dan aanbiedende organisatie)
De service Overzicht zaakgegevens toont alle relevante zaakgegevens van de zaak van één burger. Dit geldt voor zowel lopende zaken als afgeronde zaken. Hierbij worden ook contactmomenten via de MijnContactmomenten service opgehaald welke een relatie hebben met de geselecteerde zaak.
==== MijnTaken service ====
Deze service is een verzameling van services die gebruikt kunnen worden in portalen of andere soorten interactiecomponenten. De MijnTaken service geeft een overzicht van openstaande taken. Een openstaande taak kan door de service Afronden taak worden afgedaan. De afgeronde taak verdwijnt daarmee uit het overzicht. MijnTaken omvat ook een service voor het kunnen uploaden van een document dat hoort bij de zaak waarvoor de taak is uitgezet.
==== MijnBerichten service ====
Deze service is een verzameling van services die gebruikt kunnen worden in portalen of andere soorten interactiecomponenten. De MijnBerichten service geeft een overzicht van gelezen en ongelezen berichten en de inhoud van het bericht zelf die aan de klant zijn aangeboden.
==== MijnContactmomenten service ====
Deze service is een verzameling van services die gebruikt kunnen worden in portalen of andere soorten interactiecomponenten. De MijnContactmomenten service geeft een overzicht van contactmomenten die de klant met de overheidsorganisatie heeft gehad. Dit zijn zowel de contactmomenten geïnitieerd vanuit de overheidsorganisatie als vanuit de klant zelf. In het overzicht is minimaal het kanaal, datum en onderwerp van het contact zichtbaar. Het onderwerp staat altijd geschreven in de 'voltooid verleden tijd' aangezien de contactmomenten een gebeurtenis weergeven dat al heeft plaatsgevonden.
==== MijnProfiel service ====
Deze service is een verzameling van services die gebruikt kunnen worden in portalen of andere soorten interactiecomponenten. De MijnProfiel service geeft persoonsgegevens van de klant weer die nodig zijn voor de communicatie tussen de klant en de overheidsorganisatie. Dit zijn zowel de contactgegevens (zoals e-mailadres of mobiele telefoonnummer) als de kanaalvoorkeuren (zoals e-mail, SMS of post) waarover de communicatie tussen de klant en de overheidsorganisaties plaatsvindt.
==== Alle applicatieservices t.b.v. overheidsportalen ====
In onderstaand model zijn alle applicatieservices in samenhang getoond. De bovenste categorie services worden gerealiseerd door de Interactieve dienstverleningscomponent. De middelste categorie services hebben betrekking op nieuwe services die door de dienstaanbiedende componenten worden gerealiseerd. De onderste categorie services zijn bestaande services die door de dienstaanbiedende componenten worden gerealiseerd.
=== Applicatieservices t.b.v. interactie ===
Ten behoeve van de interactie met burgers of bedrijven worden notificaties naar burgers gestuurd om hen te attenderen dat er gedurende de dienstverlening een gebeurtenis bij de overheidsorganisatie heeft plaats gevonden. De ‘trigger’ hiervoor komt vanuit een registratiecomponent dat de gebeurtenis op een kanaal publiceert in het notificatierouteringscomponent. 
Een Outputmanagementcomponent dat een abonnement op het kanaal heeft, wordt geattendeerd op de gebeurtenis, haalt vervolgens enkele gegevens op uit het register waarin de gebeurtenis heeft plaats gevonden en gebruikt vervolgens de Klantnotificatie services om een notificatie naar de klant te sturen.
==== Klantnotificatie service ====
=== Applicatiecomponenten ===
Onderstaand model toont de referentiecomponenten die toegepast worden bij MijnServices. Omwille van de leesbaarheid zijn de relaties tussen de componenten weggelaten. Uiteraard bestaan er meerdere 'Serving-relationships' tussen de verschillende componenten.
De opbouw van het model volgt (grotendeels) de lagen van Common Ground. De bovenste laag bevat de interactiecomponenten en proceslogica voor zowel de burger als voor de medewerker. De laag eronder bevat componenten voor integratie tussen de interactiecomponenten en registratiecomponenten. De laag daaronder bevat de registratiecomponenten en de bijhorende API's. De drie componenten in de onderste laag zijn ondersteunende componenten.
In onderstaande view zijn de applicatiecomponenten getoond en de applicatieservices die door de applicatiecomponenten worden gerealiseerd.
Onderstaand model toont de gegevensuitwisseling tussen de verschillende componenten die nodig zijn bij de Generieke Services. In de tabel eronder wordt aangeven wat voor soort gegevens tussen welke componenten worden uitgewisseld.
=== Servicebus ===
De component ondersteunt het effectief en efficiënt uitwisselen van berichten tussen componenten binnen en buiten de organisatie. Het component speelt hierbij de rol van 'makelaar' die bemiddelt tussen de berichtleverancier en de berichtontvanger. Het 'bemiddelen' omvat minimaal het ontvangen en afleveren van het bericht maar kan ook allerlei aanvullende functies omvatten (bijv. tussentijds transformeren van berichten).
=== API Gateway ===
Een API Gateway wordt gebruikt voor (toegangs)beveiliging van API’s. Een API Gateway is vaak onderdeel van een product voor ‘full life cycle API Management’. Een API Gateway bevat ondersteuning voor het design, publiceren, documenteren, beveiligen en analyseren van API’s. Een API Gateway is een must have voor iedere gemeente die gevoelige API’s aan afnemers aanbiedt.
=== Federatieve Service Connectiviteit (FSC) ===
De FSC standaard stelt (overheids)organisaties in staat om FSC compliant gegevens uit te wisselen op een eenvoudige, veilige en toegankelijke manier gegevens uit te wisselen. Dit helpt overheden onder andere om aan de nieuwe privacywetgeving te voldoen en om burgers inzicht te geven in hun gegevens. FSC is onderdeel van Common Ground.