Omnichannel ProductDienstStatus Bedrijfsarchitectuur
Hoofdstuk:
- Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende "".
Deze pagina is een onderdeel van compleet: Hele document bekijken - Exporteren - [[|Definitie]] - [[Media:Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende "".|PDF versie]] (, "<span class="smw-highlighter" data-type="4" data-state="inline" data-title="Waarschuwing" title="Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende ""."><span class="smwtticon warning"></span><span class="smwttcontent">Ergens in uw zoekopdracht was "" niet afgesloten door een bijbehorende "".</span></span>" is geen geldige titel)
Dit hoofdstuk beschrijft de actoren, bedrijfsobjecten en -processen en -diensten die bij het verstrekken en ontvangen van ProductDienstStatus (PDS)-informatie een rol spelen.
Actoren en rollen
Bij het verstrekken en ontvangen van PDS-informatie kunnen drie actoren betrokken zijn.
- Burger: Iedere natuurlijke persoon die ingezetene is in Nederland (zoals opgenomen in de BRP), of is opgenomen in het Register Niet-Ingezetenen RNI.
- Private partij: een organisatie met of zonder winstoogmerk die tot doel heeft goederen en/of diensten te produceren en/of die te leveren aan andere organisaties of individuen.
- Overheidsorganisatie: een organisatie van de overheid die overheidstaken uitvoert of in opdracht van de overheid een wettelijke taak vervult (zoals zelfstandige bestuursorganen).
Bovengenoemde actoren kunnen drie rollen vervullen:
- Afnemer van PDS-informatie: degene die PDS-informatie gebruikt om inzicht te krijgen in de status van levering van een product of dienst. Dit kan zowel de indiener van een productaanvraag zijn, als een medewerker van een overheidsorganisatie
- Aanbieder van PDS-informatie: degene die handelingen uitvoert die ervoor zorgen dat de status van levering van een product of dienst verandert.
Figuur 1: Actoren en rollen betrokken bij het verstrekken en ontvangen van PDS-informatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
De relaties in Figuur 1 hierboven laten zien dat een burger alleen kan optreden als afnemer van PDS-informatie. Private partijen en overheidsorganisaties kunnen zowel de rol van afnemer als de rol van aanbieder daarvan vervullen.
Bedrijfsobjecten
Bij het verstrekken van PDS-informatie is een aantal bedrijfsobjecten betrokken. Deze kunnen verdeeld worden in drie categorieën:
- Bedrijfsobjecten die informatie omvatten waaruit PDS-informatie is opgebouwd. Dit geldt voor ‘productaanvraag’, ‘product/dienst’ en ‘zaak’. In Figuur 2 is deze relatie geïllustreerd door een aggregatierelatie tussen deze objecten en ‘PDS-informatie’. Dit betekent dat PDS-informatie geen nieuwe informatie is, maar informatie die al binnen de overheidsorganisatie beschikbaar is, zoals aanvraag- en zaakstatussen, en statusbeschrijvingen en servicetermijnen die in een producten- en dienstencatalogus of zaaktypecatalogus beschreven zijn.
- Bedrijfsobjecten die informatie omvatten die bepaalt of, en zo ja hoe PDS-informatie geleverd wordt. Het gaat dan bijvoorbeeld om klantvoorkeuren die bepalen welk kanaal voor levering van PDS-informatie wordt gebruikt, en toestemming die bepaalt of, en zo ja in welke mate een medewerker die daarvoor geen andere grondslag heeft toegang heeft tot statusinformatie bij aanvragen van een inwoner of bedrijf. Deze objecten zijn Figuur 2 donkergeel gekleurd.
- Bedrijfsobjecten die een rol spelen tijds het proces van aanvragen en leveren van producten en diensten, de referentiearchitectuur Omnichannel, en/of onderdeel uitmaken van een integraal klantbeeld, maar die bij het verstrekken van PDS-informatie een secundaire, of überhaupt geen rol spelen. Deze objecten zijn in Figuur 2 lichtgeel gekleurd.
Figuur 2: Bedrijfsobjecten betrokken bij het verstrekken en ontvangen van PDS-informatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
In de tabel hieronder zijn de definities voor de geïllustreerde bedrijfsobjecten opgenomen. Deze zijn voor zover daarin beschreven overgenomen uit de referentiearchitectuur Omnichannel of GEMMA-referentiearchitectuur.
Bedrijfsobject | GEMMA-definitie |
---|---|
klantvoorkeur | De voorkeur die een klant heeft met betrekking tot de dienstverlening. Dit kan bijvoorbeeld gaan over het gewenste communicatiekanaal of een taalinstelling. |
toestemming | De toestemming die een klant gegeven heeft aan een gemeente om klantgegevens in te zien of te verwerken. |
machtiging | De machtiging die een klant aan een ander natuurlijk persoon heeft verstrekt. |
klant | Een natuurlijk persoon of niet-natuurlijk persoon waar een product/dienst wordt geleverd. |
natuurlijk persoon | Een mens. |
niet-natuurlijk persoon | Een rechtspersoon of een samenwerkingsverband. |
productaanvraag | Een vraag of aanvraag voor een product/dienst door een klant. |
product/dienst | Een tastbaar goed of verzameling activiteiten die door de gemeente geleverd kunnen worden. |
contactmoment | Een aaneengesloten interactie tussen inwoner of (vertegenwoordiger van) een onderneming en de gemeente via een synchroon kanaal (telefoon, gesprek aan de balie) of een informatieverstrekking door de inwoner of (vertegenwoordiger van) een onderneming aan de gemeente of vice versa via een asynchroon kanaal (e-mail, contactformulier, chatbot) waarvan de inhoud relevant is voor de dienstverlening of verantwoording door de gemeente. |
afspraak | Een gepland klantcontact tussen een klant en de gemeente. |
medewerker | Een [natuurlijk persoon] met een tijdelijk of vaste [dienstbetrekking] of met een inhuurcontract met de gemeente. |
organisatie-eenheid | Een clustering van medewerkers binnen de lijnorganisatie met een duidelijk gedefinieerde specifieke taakstelling. |
zaak | Een samenhangende hoeveelheid werk met gedefinieerde aanleiding en een gedefinieerd eindresultaat waarvan kwaliteit en doorlooptijd bewaakt moeten worden. |
pds-informatie | Informatie die inzicht geeft in het proces voor levering van een product of dienst, de huidige status van een specifieke productaanvraag binnen dat proces en een indicatie van de verwachtte resterende levertijd. |
document | 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. |
besluit | Een beslissing over het wel of niet toekennen van [product/dienst]. |
verwerkingenlog | De vastlegging van een verwerking in een logregistratie om de verwerking van objectgegevens te kunnen duiden. |
Bedrijfsprocessen en -diensten
Figuur 3 laat zien hoe PDS-informatie wordt verstrekt. De basis hiervoor is het bedrijfsproces ‘Verstrekken van producten en diensten’ dat de overheidsorganisatie naar aanleiding van een aanvraag voor een product of dienst door een burger of bedrijf of instelling is gestart. Deze aanvraag wordt zaakgericht behandeld. Tijdens de behandeling doorloopt de zaak verschillende fases. Hierbij ontstaan statuswijzigingen. Deze statuswijzigingen vormen de basis voor PDS-informatie.
Het leveren van PDS-informatie kent een eigen bedrijfsproces: ‘Verstrekken PDS-informatie’. Tijdens het doorlopen van dit proces worden een aantal bedrijfsobjecten gelezen: ‘klantvoorkeur’ om PDS-informatie te kunnen leveren via het voorkeurskanaal van de klant, en ‘machtigingen’ en ‘toestemmingen’ om te bepalen of de afnemer wel recht heeft op inzage in de te verstrekken gegevens. Daarnaast de uit ‘productaanvraag’-, ‘zaak’- en ‘product/dienst’-informatie samengestelde PDS-informatie die aan de aanvrager verstrekt wordt. Het verstrekken van deze informatie wordt bovendien vastgelegd in een verwerkingenlog.
Interactie tussen de PDS-afnemer en aanbieder vindt plaats via de dienst ‘ProductDienstStatus’ die de PDS-aanbieder levert. Deze dienst kan worden aangeroepen via een daartoe door de PDS-aanbieder ingericht 'Interactiekanaal’. Dit kanaal ondersteunt zowel het opvragen van statusinformatie door een PDS-afnemer (pull-scenario, zie ook Figuur 5) als het ontvangen van statusinformatie op initiatief van de aanbieder verstrekte PDS-informatie (push-scenario, zie ook Figuur 4).
Figuur 3: Generieke illustratie van bedrijfsprocessen en -diensten die een rol spelen bij de verstrekking van
PDS-informatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
Scenario’s voor levering van PDS-informatie
PDS-informatie kan op verschillende manieren aan afnemers geleverd worden. factoren die de wijze van leveren beïnvloeden zijn:
- De aanleiding voor het leveren van PDS-informatie. Een aanbieder van PDS-informatie kan een statusupdate naar een afnemer ‘pushen’ naar aanleiding van een veranderde status bij een aanvraag of zaak (Figuur 4), maar een (eind)afnemer kan ook het zelf het initiatief nemen tot het opvragen (‘pullen’) van de laatste statusinformatie (Figuur 5).
- Het kanaal dat wordt gebruikt voor het opvragen van statusinformatie. Een (eind)afnemer kan inzicht in statusinformatie krijgen via geautomatiseerde, digitale kanalen (Figuur 4, Figuur 5 en Figuur 7), of door te bellen naar het klantcontactcentrum van de overheidsorganisatie die de aanvraag behandelt (Figuur 6). In het laatste geval kan niet alleen de Burger, maar ook de KCC-medewerker van de Overheidsorganisatie waarmee contact wordt gelegd gezien worden als afnemer van PDS-informatie
- De betrokkenheid van meerdere organisaties. Als meerdere organisaties betrokken zijn bij de levering van een product of dienst aan een (eind)afnemer, dan geldt de overheidsorganisatie bij de wie de oorspronkelijke productaanvraag is ingediend niet alleen als aanbieder (aan de burger die geldt als (eind)afnemer)) van PDS-informatie, maar ook als afnemer van door de ketenpartner aangeleverde PDS-informatie (Figuur 7).
In onderstaande diagrammen treedt steeds een burger op als (eind)afnemer. Maar deze rol zou ook kunnen worden vervuld door een private partij of een (tweede) overheidsorganisatie.
De diagrammen sluiten aan bij de in hoofdstuk 8 beschreven casussen. Figuur 5 bij ‘MijnGemeente’, Figuur 6 bij ‘CRM’ en Figuur 7 bij ‘Statusuitwisseling tussen organisaties’.
Figuur 4: levering naar aanleiding van veranderde status (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
Figuur 5: levering op aanvraag van burger (of andere (eind)afnemer) (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
Figuur 6: levering op initiatief van burger (of andere (eind)afnemer) via Klantcontactcentrum van overheidsorganisatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv
Figuur 7: levering naar aanleiding van veranderde status bij ketenpartner via tweede overheidsorganisatie aan
(eind)afnemer (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv