Brontekst bekijken van Omnichannel Integraal Klantbeeld

== Architectuur ==
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 ===
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.

{{ToonViewGEMMA
|viewid=c007a040-f502-447d-bbd2-8f247d07f273
|modelid=3c0f6ff7-0d6b-4f84-adcc-93cb3153cecd
|label=Capabilities integraal klantbeeld}}

* '''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 ===
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.

{{ToonViewGEMMA
|viewid=0d3bd5d9-b12d-4863-8a14-79353d5eea49
|modelid=3c0f6ff7-0d6b-4f84-adcc-93cb3153cecd
|label=Bedrijfsobjecten relevante klantgegevens}}

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 ===
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.

{{ToonViewGEMMA
|viewid=cae0f1bc-4c3c-4d4e-8db8-55b80a4645b1
|modelid=3c0f6ff7-0d6b-4f84-adcc-93cb3153cecd
|label=Overzicht componenten relevante klantgegevens}}
<br />
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.