Omnichannel Integraal Klantbeeld


Introductie[bewerken]

Om een optimale dienstverlening naar de burgers, bedrijven en instellingen te kunnen bieden, is een zo volledig mogelijk overzicht van klantgegevens die op dat moment in de dienstverlening nodig zijn van groot belang. Zo kan een medewerker op basis van die gegevens de klant bijvoorbeeld beter te woord staan en mogelijk al pro-actieve dienstverlening bieden. En de klant krijgt bijvoorbeeld meer inzicht in welke gegevens er bij de organisatie bekend zijn, wat er met zijn gegevens gebeurt en waarom en welke contacten er met de organisatie zijn geweest.

Een integraal klantbeeld omvat veel verschillende processen en softwarecomponenten die zich op de 5 lagen van de informatiekundige visie Common Ground bevinden. Deze moeten allemaal op elkaar aansluiten. De innovatiegroep referentiearchitectuur omnichannel heeft in de eerste helft van 2021 een eerste uitwerking gemaakt van het integraal klantbeeld. Op deze pagina wordt een toelichting gegeven op de architectuur.

Integraal klantbeeld[bewerken]

Een integraal klantbeeld kan vanuit twee perspectieven worden bekeken. Vanuit het perspectief van de klant en vanuit het perspectief van de medewerker. Uitgangspunt daarbij is dat beide perspectieven gebruikmaken van dezelfde gegevens. Om meer duiding te geven aan het begrip Integraal Klantbeeld, heeft de innovatiegroep de volgende toelichting geformuleerd.

"Een integraal klantbeeld bevat alle toegestane relevante klantgegevens die nodig zijn om een optimale dienstverlening te bieden."

Hoewel een gemeente beschikt over veel gegevens over een klant, mogen die gegevens niet zomaar integraal samengevoegd worden tot één klantbeeld. Om klantgegevens te mogen inzien, is een doelbinding nodig. Het uitgangspunt van doelbinding is, dat gegevens worden verwerkt en verzameld voor een welbepaald, uitdrukkelijk omschreven en gerechtvaardigde doel. Alleen die gegevens die gebruikt mogen worden voor een bepaald doel zijn daarom relevant en kunnen gebruikt worden voor een optimale dienstverlening.

Perspectief klant[bewerken]

Een integraal klantbeeld kan een burger, bedrijf of instelling inzicht bieden in welke gegevens er bekend zijn bij een gemeente. Er kan bijvoorbeeld inzage gegeven worden in welke dienstverlening in het verleden is geweest, welke contactmomenten er hebben plaatsgevonden, wat de status van een nieuwe aanvraag is en bij welke afdeling de aanvraag in behandeling is, et cetera. De klant krijgt hierdoor één overzicht van al zijn gegevens.

Perspectief medewerker[bewerken]

Het integraal klantbeeld ondersteunt ook medewerkers. Een medewerker van een klantcontactcentrum kan bijvoorbeeld in het overzicht zien wanneer en met welke medewerker een klant contact heeft gehad. Ook wordt inzicht gegeven in welke medewerker de aanvraag in behandeling heeft en wat de status van de aanvraag is. Daardoor kan direct antwoord worden gegeven op vragen van de klant en kan voorkomen worden dat de klant naar verkeerde medewerkers wordt doorverbonden. Daarnaast kan de medewerker van het klantcontactcentrum op basis van het integraal klantbeeld pro-actieve dienstverlening bieden, door klanten te attenderen op mogelijke diensten waarop de klant recht heeft.


Architectuur[bewerken]

Er is een eerste uitwerking gemaakt van de architectuur. Er wordt ingegaan op wat een organisatie moet kunnen (capabilities - het vermogen van een organisatie) om een integraal klantbeeld te kunnen tonen en er is een view gemodelleerd waarin een aantal GEMMA referentiecomponenten op de 5 lagen van Common Ground zijn gepositioneerd.

Capabilities[bewerken]

Een capability wordt omschreven als het vermogen van een organisatie om iets uit te kunnen voeren. Hierin wordt geen onderscheidt gemaakt tussen offline en online dienstverlening. Om een integraal klantbeeld te tonen, zijn vier capabilities onderkend.

Capabilities integraal klantbeeld (uit model: Omnichannel) - Toon SVG - Download als csv


  • Toegangscontrole: Het vermogen van een organisatie om klanten of medewerkers op zo een manier ondubbelzinnig te identificeren, authenticeren en autoriseren dat relevante klantinformatie kan worden opgevraagd uit de achterliggende systemen.
Toegangscontrole is van belang om vast te stellen of de persoon die toegang tot de gegevens wil, wel recht heeft op die toegang. Het controleren kan bijvoorbeeld aan de balie plaatsvinden doordat de klant een identiteitsbewijs toont of dat een medewerker in een informatiesysteem zijn inloggegevens invoert waarna een controle plaatsvindt. De toegangscontrole wordt dus gebruikt voor zowel de klant als de medewerker en is voor online en offline dienstverlening van belang. Om dit mogelijk te maken heeft de gemeente hiervoor voorzieningen beschikbaar.
  • Relevante klantinformatie: Het vermogen van een organisatie om in een specifieke context relevante klantinformatie te tonen waarbij rekening wordt gehouden met alle relevante juridische kaders.
Klantgegevens mogen alleen getoond worden als daarvoor de juiste doelbinding beschikbaar is. Een klant mag bijvoorbeeld wel zijn gegevens in één overzicht te zien krijgen, terwijl een medewerker in het sociaal domein alleen die gegevens te zien krijgt die nodig zijn voor de uitvoering van een specifieke taak in het sociaal domein. Een medewerker van het KCC zou in beperkte mate een overzicht van de klantgegevens kunnen inzien om de klant van goede dienstverlening te kunnen voorzien. Detailgegevens van de klant kunnen vanwege de privacy wet- en regelgeving afgeschermd zijn voor de KCC medewerker.
  • Koppelen relevante informatie aan klant: Het vermogen van een organisatie om relevante informatie van een klant op een privacy-correcte manier te koppelen aan die klant.
Gegevens over klanten worden in diverse informatiesystemen opgeslagen. Om een integraal klantbeeld te kunnen tonen, is het belangrijk de juiste gegevens uit die verschillende informatiesystemen met elkaar in relatie te brengen. Dit voorkomt dat een zoekactie uitgevoerd moet worden over alle gegevens in alle informatiesystemen heen en kunnen gericht gegevens worden opgevraagd of bewerkt.
  • Regie op eigen gegevens: Het vermogen van een organisatie om een klant regie te geven op de informatie die over de klant wordt opgeslagen. Deze regie behelst zowel inzicht in opgeslagen klantgegevens, toestemming om opgeslagen informatie te gebruiken en het verwijderen van informatie. Uiteraard binnen alle geldende juridische kaders.
Klanten moeten kunnen aangeven welke 'extra' gegevens door een gemeente gebruikt en gedeeld mogen worden. Ook het intrekken van deze toestemming moet mogelijk zijn. Als een klant constateert dat gegevens niet juist zijn, moet een klant dit aan een gemeente eenvoudig kunnen aangeven of in bepaalde gevallen zelf kunnen aanpassen.

Bedrijfsobjecten[bewerken]

Het integraal klantbeeld is opgebouwd uit verschillende gegevens. Onderstaande view toont een overzicht van de bedrijfsobjecten die kunnen bijdragen aan het klantbeeld. Het is een eerste uitwerking waarin de onderlinge relaties worden weergegeven. Het model wordt in een later stadium verder uitgewerkt.

Bedrijfsobjecten relevante klantgegevens (uit model: Omnichannel) - Toon SVG - Download als csv


Bovenstaande bedrijfsobjecten worden opgebouwd uit gegevens die zijn opgeslagen in informatiesystemen. In het overzicht van de te gebruiken applicatiecomponenten kan een afgeleide relatie gelegd worden tussen de bedrijfsobjecten en de applicatiecomponenten.

Relevante klantgegevens[bewerken]

Veel relevante klantgegevens zijn opgeslagen in verschillende softwaresystemen of componenten. Zo worden zaakgegevens opgeslagen en bewerkt in een zakenregistratiecomponent en worden persoonsgegevens bewaard in het BRP-systeem. Onderstaande view toont in samenhang de meest gebruikelijke referentiecomponenten waarin klantgegevens bewaard en bewerkt worden, gepositioneerd op de vijf lagen van Common Ground.

Het vermogen van een organisatie om in een specifieke context relevante klantinformatie te tonen waarbij rekening wordt gehouden met alle relevante juridische kaders (Capability) Relevante klantinformatie Grouping Laag 1 - Gegevens Component voor het faciliteren van de opslag van gegevens over verzoeken. (ApplicationComponent) Verzoekenregister Component voor uitvoering van de gemeentelijke taken rondom de registratie van persoonsgegevens. (ApplicationComponent) GBA-administratie component Component voor het beheren en publiceren van het register van verwerkingen (ApplicationComponent) Verwerkingenloggi- ngcomponent Component voor het faciliteren van de opslag van gegevens over zaken. (ApplicationComponent) Zakenregister Component voor het faciliteren van de opslag van gegevens over genomen besluiten. (ApplicationComponent) Besluitenregister ApplicationComponent Toestemmingenregi- ster Component voor het faciliteren van de opslag van gegevens over contactmomenten met klanten. (ApplicationComponent) Contactmomentenr- egister Component voor het maken van afspraken tussen burgers, bedrijven en ambtenaren. (ApplicationComponent) Afsprakenbeheerco- mponent Component voor de opslag en ontsluiting van identiteiten van gebruikers en de rechten die zij hebben. (ApplicationComponent) Gebruikersbeheerc- omponent Grouping Laag 2 - Diensten ApplicationInterface Verzoeken API ApplicationInterface Contactmomenten API ApplicationInterface Besluiten API ApplicationInterface BRP-Bevragen API ApplicationInterface Afspraken API ApplicationInterface Toestemmingen API ApplicationInterface Verwerkingenloggi- ng API ApplicationInterface Zaken API ApplicationInterface Gebruikersbeheer API Grouping Laag 3 - Integratie Component voor het routeren, transformeren en eventueel orchestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent Grouping Laag 4 - Proceslogica ApplicationComponent Processturingcomponent Grouping Laag 5 - Interactie Component die via webtechnologie veilig toegang biedt tot persoonlijke informatie en gepersonaliseerde digitale dienstverlening. (ApplicationComponent) Mijngemeentecom- ponent Component die wordt gebruikt door baliemedewerkers om eerstelijns ondersteuning te bieden. (ApplicationComponent) Klantcontact centrumcomponent Component voor het onderhouden van relaties met klanten of organisaties. (ApplicationComponent) Relatiebeheercomp- onent (CRM) Referentiecomponent als placeholder voor een willekeurige domein specifieke applicatie. https://www.gemmaonline.nl/index.php/GEMMA2/0.9/id-7a855337-fcbb-11e5-11ba-005056a85f9c (ApplicationComponent) Specifiek Procesafhandelcom- ponent Component voor het ontvangen en versturen van berichten binnen sociale media waarbij met persoonlijke voorkeuren rekening wordt gehouden. (ApplicationComponent) Sociale mediacomponent Component voor het opzetten en aannemen van chatgesprekken. (ApplicationComponent) Chatcomponent Grouping Laag 3 - Landelijke integratie ApplicationComponent Landelijke integratiecomponent Grouping Laag 2 - Landelijke diensten ApplicationService DigiD service ApplicationService Machtigingen service Grouping Laag 1 - Landelijke gegevens ApplicationComponent DigiD ApplicationComponent Machtigingenregist- er CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship RealizationRelationship RealizationRelationship Deze svg is op 07-04-2024 13:55:29 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 07-04-2024 13:55:29 CEST

Overzicht componenten relevante klantgegevens (uit model: Omnichannel) - Toon SVG - Download als csv


In bovenstaand model is een verdeling in 2 groepen te onderkennen: de onderste 2 lagen (Gegevens en Diensten) behoren tot de groep Dienstenaanbieders, de bovenste 2 lagen (Interactie en Proceslogica) behoren tot de groep Dienstenafnemers. De twee groepen worden door de middelste laag (Integratie) aan elkaar gekoppeld. Binnen een organisatie zou dit een Servicebuscomponent kunnen zijn, tussen organisaties wordt er gebruik gemaakt van een landelijke voorziening.

De onderste laag bevat de registers waarin de gegevens zoveel mogelijk eenmalig opgeslagen. De gegevens worden ontsloten via API's die zich in de laag erboven (Diensten) bevinden. De bovenste laag (Interactie) bevat (vaak) de gebruikersinterface die via de laag Proceslogica klantgegevens uit de lagen eronder kan ophalen. Afhankelijk van de autorisatie die een persoon (klant of medewerker) heeft, worden gegevens wel of niet opgehaald en getoond.

Deze pagina is het laatst bewerkt op 20 okt 2023 om 14:01.