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 (open view in nieuw venster)
  • 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.

De voorkeur die een klant heeft met betrekking tot de dienstverlening. Dit kan bijvoorbeeld gaan over het gewenste communicatiekanaal of een taalinstelling. (BusinessObject) klantvoorkeur De toestemming die een klant gegeven heeft aan een gemeente om klantgegevens in te zien of te verwerken. (BusinessObject) toestemming BusinessObject mijnzaken-informatie De machtiging die een klant aan een ander natuurlijk persoon heeft verstrekt. (BusinessObject) machtiging Een gepland klantcontact tussen een klant en de gemeente. (BusinessObject) afspraak Een samenhangende hoeveelheid werk met gedefinieerde aanleiding en een gedefinieerd eindresultaat waarvan kwaliteit en doorlooptijd bewaakt moeten worden (BusinessObject) zaak Een natuurlijk persoon of niet-natuurlijk persoon waar een product/dienst wordt geleverd (BusinessObject) klant een mens (BusinessObject) natuurlijk persoon een rechtspersoon of een samenwerkingsverband (BusinessObject) niet-natuurlijk persoon De vastlegging van een verwerking in een logregistratie om de verwerking van objectgegevens te kunnen duiden. (BusinessObject) verwerkingenlog een tastbaar goed of verzameling activiteiten die door de gemeente geleverd kunnen worden (BusinessObject) product/dienst Een contactmoment met een klant dat relevant is voor de dienstverlening (BusinessObject) klantcontact Een clustering van medewerkers binnen de lijnorganisatie met een duidelijk gedefinieerde specifieke taakstelling (BusinessObject) organisatie-eenheid Een informatieobject met als generieke aanduiding 'document' kan van alles zijn, ongeacht aard en vorm: een tekstverwerkingsdocument, een papieren brief, een webpagina, een landkaart, een foto, een geluidsopname, een dataset, een blog, etc. (BusinessObject) document een beslissing over het wel of niet toekennen van [product/dienst] (BusinessObject) besluit een [natuurlijk persoon] met een tijdelijk of vaste [dienstbetrekking] of met een inhuurcontract met de gemeente (BusinessObject) medewerker Een vraag, melding of aanvraag voor een product/dienst door een klant (BusinessObject) verzoek AggregationRelationship AggregationRelationship AggregationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AggregationRelationship AggregationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AggregationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship Deze svg is op 29-05-2024 12:37:39 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 12:37:39 CEST
Bedrijfsobjecten relevante klantgegevens (open view in nieuw venster)

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 ArchiMateNote Laag 5 - Interactie Component die via webtechnologie veilig toegang biedt tot persoonlijke informatie en gepersonaliseerde digitale dienstverlening. (ApplicationComponent) Mijngemeentecom- ponent ApplicationComponent Klantcontactcentru- mcomponent Component voor het onderhouden van relaties met klanten of organisaties. (ApplicationComponent) Relatiebeheercomp- onent (CRM) ApplicationComponent Chatcomponent Component voor het ontvangen en versturen van berichten binnen sociale media waarbij met persoonlijke voorkeuren rekening wordt gehouden. (ApplicationComponent) Sociale mediacomponent ApplicationComponent Specifiek procesafhandelcom- ponent ArchiMateNote Laag 4 - Proceslogica ApplicationComponent Processturingcomponent ArchiMateNote Laag 3 - Integratie Component voor het routeren, transformeren en eventueel orkestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent 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) Verwerkingenloggi- ng API ApplicationInterface Toestemmingen API ApplicationInterface Afspraken API ApplicationInterface BRP-Bevragen API ApplicationInterface Gebruikersbeheer API ArchiMateNote Laag 1 - Gegevens Component voor de opslag en ontsluiting van identiteiten van gebruikers en de rechten die zij hebben. (ApplicationComponent) Gebruikersbeheerc- omponent Component voor uitvoering van de gemeentelijke taken rondom de registratie van persoonsgegevens. (ApplicationComponent) GBA- administratiecomp- onent ApplicationComponent Verzoekenregister Component voor opslag en ontsluiting van zaakgegevens. (ApplicationComponent) Zaakregistratiecom- ponent Component voor opslag en ontsluiting van besluitgegevens. (ApplicationComponent) Besluitregistratieco- mponent Component voor het maken van afspraken tussen burgers, bedrijven en ambtenaren. (ApplicationComponent) Afsprakenbeheerco- mponent ApplicationComponent Contactmomentenr- egister Component voor het centraal vastleggen van gegevens over de activiteiten die gebruikers uitvoeren met vertrouwelijke gegevens. (ApplicationComponent) Verwerkingenloggi- ngcomponent ApplicationComponent Toestemmingenregi- ster ArchiMateNote Laag 3 - Landelijke integratie ApplicationComponent Landelijke integratiecomponent ArchiMateNote Laag 2 - Landelijke diensten Applicatieservice voor het authenticeren van burgers (ApplicationService) DigiD authenticatieservice Landelijk systeem voor authenticatie van bedrijven inclusief bijbehorend machtigingen register. (ApplicationService) eHerkenning authenticatie en machtigingenservice ArchiMateNote Laag 1 - Landelijke gegevens Landelijk systeem voor authenticatie van burgers. (ApplicationComponent) DigiD ApplicationComponent Machtigingenregist- er-org ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship CompositionRelationship Verplicht CompositionRelationship ServingRelationship ServingRelationship ServingRelationship RealizationRelationship RealizationRelationship Deze svg is op 29-05-2024 12:55:38 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 12:55:38 CEST
Overzicht componenten relevante klantgegevens (open view in nieuw venster)


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 voor het laatst bewerkt op 21 mei 2024 om 15:32.