FOD Financiën Programma Multi-kanaal Dienstverlening Conceptueel Object Model 3.0

FOD Financiën Programma Multi-kanaal Dienstverlening Conceptueel Object Model 3.0

Voorgelegd ter validatie aan het ICT-team, het kernteam en de stuurgroep van 16/06/2004 Voorstudie Programma MKDV

Inhoud 1.

2.

Blz. Inleiding .............................................................................................................................. 3 1.1. Objectief van het document 3 1.2. Werkwijze 3 Conceptueel Object Model.................................................................................................. 4 2.1.

2.2. 2.3.

3.

Uitleg van de gebruikte notatie 2.1.1. Package diagram

4 4

2.1.2. Klasse diagram Package Diagram

5 7

Object Modellen 2.3.1. Partij

8 8

2.3.2. 2.3.3.

Organisatie Interacties

10 12

2.3.4. 2.3.5.

Documenten Planning

14 15

2.3.6. Kwaliteit 17 Link met to be ‘data sources’ ............................................................................................ 18 3.1. 3.2.

Overzicht van de to be sources Uitleg van de tabel

18 18

3.3.

Tabel met de databronnen

19

Vertrouwelijk

© FOD Financiën

Conceptueel Object Model 3.0

2

Gevalideerd door stuurgroep van 16/06/2004

Dit document geeft een overzicht van het conceptueel object model ter ondersteuning van de toepassing voor het programma MKDV en de mapping tussen deze MKDV modellen en de (toekomstige) gegevensbronnen die nodig zijn. De modellen worden toegelicht aan de hand van UML Diagrammen (notatie wordt uitgelegd in hoofdstuk 2) waarin zowel de nodige objecten als de relaties die bestaan tussen de objecten wordt beschreven. Na het uitwerken van de modellen, worden de objecten die beschreven zijn, gelinkt met de (to be) informatiebronnen die te beschikking zullen zijn in de finale architectuur. Deze mapping gebeurt op niveau van de attributen van de objecten.

Het conceptueel object model is gebaseerd op de functionaliteiten zoals beschreven in het Use Case Boek V1.0. In deze use cases wordt er gebruikt gemaakt van een aantal concepten die overeenkomen met 1 of meerdere objecten. De definitie van de objecten en de relaties ertussen zijn gebaseerd op de ideëen, de vereisten en de noden die verwerkt zijn in de use case beschrijvingen.

Als aanzet tot het maken van de modellen, werden eerst de use cases uitgebreid beschreven en werd er uitgegaan van een draft van de functionele architectuure. Het resultaat zijn een aantal draft objectmodellen die eerst intern gevalideerd werden en dan werden voorgelegd aan ICT. Na de validatie door ICT worden de modellen voorgelegd aan het kernteam en aan de stuurgroep. De modellen, die gecopieerd zijn in dit document, zijn gemaakt in Rational Rose en worden in bijlage van dit document teruggevonden.

Vertrouwelijk

© FOD Financiën


3


!" #

# '(

%$" &

(

De notatie die wordt gebruikt voor het maken van de onderstaande modellen is de UML notatie. In dit document wordt enkel gebruik gemaakt van een package diagram en verschillende klasse diagrams. Deze worden summier uitgelegd in de volgende paragrafen.1

Packages worden gebruikt in UML om de elementen van een development process te structureren (van analyse tot implementatie). Een package kan het best vergeleken worden met een map (in een Windows omgeving) waarin documenten worden bewaard. Ook in packages worden de verschillende gelinkte elementen samen bewaard. Packages kunnen zelf terug packages bevatten, om zo de modellen verder te structureren. Packages worden in het algemeen als volgt voorgesteld:

Interacties

In ons diagram hebben we ze echter iconografisch voorgesteld (met een verschillende voorstelling voor het business analysis model (die de klasse diagramma bevatten) en voor het business use case model (die de use case diagramma bevatten):

Ondersteunende Use Case

Party

Packages kunnen worden gecombineerd in een package diagram, om zo de relaties tussen de verschillende packages te kunnen aangeven. Packages kunnen namelijk afhankelijk zijn van elkaar, wanneer een element van 1 package gebruik maakt of hulp nodig heeft van een element van een andere package. Package diagrammen zijn handig omdat ze de functionele en data afhankelijkheid tussen de verschillende packages duidelijk in beeld brengen. Daarnaast worden ze oa. ook gebruikt om het uiteindelijke systeem te partitioneren in deelsystemen.

1 Bij het lezen van de modellen worden een begrip van Object Orientatie en meer bepaald UML modellen verondersteld.

Vertrouwelijk

© FOD Financiën


4


De objecten die nodig zijn in de toepassing worden uitgedrukt dmv een klasse. Een klasse bevat typisch een omschrijving van de attributen (eigenschappen) en het gedrag van die objecten. Objecten zijn voorstellingen van mensen, materialen, informatie en gedrag. Een klasse wordt als volgt voorgesteld. Activiteit omschrijving : Stri ng id : String status : String vervaldag : Date activiteitType : String

Het klasse diagram is het belangrijkste artefact in het object modelerings proces. Het beschrijft de definitie van de elementen die essentieel zijn voor het juist werken van de te ontwikkelen toepassing. In een klasse diagram worden de klassen en de relaties tussen de klassen in kaart gebracht. Deze relaties kunnen van een verschillende aard zijn. We onderscheiden de associatie, de aggregatie en de overervingsrelatie. Een associatie is een relatie tussen twee klassen, wanneer deze elkaar nodig hebben. Een aggregatie is een compositie relatie (A bestaat uit 1 of meerdere B). Een overervingsrelatie is een ‘is-a’ relatie (A is een speciaal geval van B). Hun voorstelling wordt hieronder weergegeven.

)) Antwoord id : Integer omschrijving : String bronnen : String argumentatie : String gevalideerd[1] : Boolean 0..1

1

Vraag vraagT ype : String = {Specifiek, Algemeen} complexiteit : String = {Eenvoudig, Gemiddeld, Complex} prioritair : Boolean bevestigingOntvangst : Boolean activiteitT ype : String = vraag

Vertrouwelijk

© FOD Financiën


5


(( ( Catal ogus Planning beginDatum : Date eindDatum : Date

Werkregime begintijd[1] : Date eindtijd[1] : Date

ProductOmschrijving

Voor deze zijn er 2 vormen mogelijk: een compositie waar een deel geen reden van bestaan heeft op zich zelf (vb. Order bevat orderlijnen). Ook voorbeeld 2 van de aggregatie geeft hier een voorbeeld van. Het kan ook dat het deel wel kan bestaan (auto bevat een motor). Dit wordt ook afgebeeld in voorbeeld 1 van de aggregatie.

( Persoon (from Partij)

rijksregisterNummer : String naam : String v oornaam : String geboortedatum : Datum burgerlijkeStaat = {ongehuwd, gehuwd, gescheiden, ...} beroep : String

Medewerker (from Operationele use cases)

medewerkerIdentif icatie [1] : String taalrol : Taal

Wanneer een bepaalde klasse een subtype is van een andere klasse wordt de overervingsrelatie gebruikt. In deze relatie erft de overervende klasse alle attribute van de ‘parent’ klasse. In sommige gevallen is de ‘parent’ klasse bestaat de klasse enkel om attributen te verzamelen, maar bestaat niet op zich. In dat geval spreekt men van een ‘abstracte’ klasse. PartijRol

Vraagsteller

Betrokkene

(from Operationele use cases)


Bestemmeling (from Operationele use cases)

Vertrouwelijk

© FOD Financiën


6


!

(

(

Partij

Interacties

Documenten

Organisatie

Kwaliteit

Planning

Het bovenstaande package diagram bevat de volgende packages: • Partij: Deze package bevat alle klassen die te maken hebben met de modellering van personen en ondernemingen in het kader van de MKDV, samen met de rollen die gespeeld worden door de verschillende interagerende partijen. Deze gegevens komen typisch uit de verschillende rijksregisters, aangevuld met MKDV specifieke informatie • Organisatie: Hier wordt de interne organisatie (in het kader van MKDV) gemodelleerd. De klassen zijn gelinkt met de concepten medewerker en organisatie onderdeel. Deze gegevens zijn HR gerelateerde gegevens. • Interacties: Dit is de kern van de MKDV toepassing en bevat alle gegevens die te maken hebben met de interacties, de vragen en de antwoorden. • Documenten: Hier worden de klassen ondergebracht die de informatie bevatten die nodig is voor het beheren van de documenten die nodig zijn in de MKDV front-office processen. • Kwaliteit: De gegevens die worden bijgehouden voor het plannen van de kwaliteitsreviews, zijn ondergebracht in deze package • Planning: Als laatste worden de gegevens die bijgehouden worden die nodig zijn voor het plannen van de medewerkers van het contact center en het persoonlijk onthaal.

Vertrouwelijk

© FOD Financiën


7


*

&

''

PARTIJ AnoniemePartij

0..*

speelt

Taal

officiële taal Locatie

Een geïdentificeerde partij is altijd een Persoon of een Onderneming. Elke partij kan volgende rollen spelen: vraagsteller, bestemmeling, burger.

PartijRol

1

0..*

segment = {Particulier, Zelf standige/onderneming, Mandataris}

ty pe[1] = {land, stad, prov incie, staat} naam[1] : String identif icatie[0..1] : String 0..1 1..*

GeïdentificeerdePartij

0..*

Vraagsteller

Betrokkene



0..*

1

identif icatieNummer : String marketing : Boolean 1

1

Bestemmeling

contactadres

0..*

Adres beginDatum : Date eindDatum : Date

legaalAdres


is mandataris van

0..1

Mandaat

Fy sisch adres straatnaam : String huisnummer : String telef oonnummer[1..*] : String f axnummer[0..*] : String

beginDatum : Date eindDatum : Date reikwijdte : String 0..*

0..1

Persoon rijksregisterNummer : String naam : String v oornaam : String geboortedatum : Datum burgerlijkeStaat = {ongehuwd, gehuwd, gescheiden, ...} beroep : String mobielNummer[0..*] : String

Onderneming KBONummer : String naam : String

ContactVoorkeur v oorkeurDagen : String v oorkeurUren : String 0..n

geprefereerdKanaal legaleStructuur 0..1

OndernemingTy pe taal = {NL, FR, GE, EN} omschrijv ing : String

Vertrouwelijk

© FOD Financiën

Kanaal omschrijv ing : String


8


EmailAdres emailAdres : String

Webpagina url : String

Het partijmodel is gecentraliseerd rond het concept partij. Een partij kan anoniem zijn (een anonieme partij) wanneer de persoon die contact opneemt met de FOD Financiën niet kan of wil geïdentificeerd worden. In dat geval worden er enkel segment en taal van de partij bijgehouden in de informatie. De definitie van de segmenten wordt gedaan volgens de categorisatie van de klant van MKDV. De taal is een van de talen die werden gemodelleerd in de toepassing. Een anonieme partij kan in de toepassing enkel de rol van vraagsteller spelen. Wanneer het niet gaat om een anonieme partij, dan spreken we van een geïdentificeerde partij. Een geïdentificeerde partij is ofwel een persoon, ofwel een onderneming. Het identificatie nummer van de geïdentificeerde partij is het Rijksregisternummer (Rijksregister of Bisregister) voor de persoon en het KBO nummer voor de onderneming. Voor een onderneming wordt ook de legale structuur genoteerd. Bij een geïdentificeerde partij worden er meer gegevens geregistreerd dan voor een anonieme partij. De identificatie ven een partij gebeurd op basis van 1 of meerdere elementen die gekend zijn van de partij. Een partij kan verschillende adressen hebben. Een adres is de verzamelnaam voor een fysisch adres, een email adres of een webpagina. Wanneer het om een fysiek adres gaat, dan heeft het adres ook een locatie. Een locatie is een recursieve relatie: een locatie bestaat uit locaties, die weer uit locaties kunnen bestaan. Bij een geïdentificeerde partij kunnen er, bijvoorbeeld indien nodig in het kader van risicobeheer, nog bijkomende gegevens worden bijgehouden. Een geïdentificeerde partij kan naast de rol van vraagsteller ook de rol van bestemmeling (van een bepaalde correspondentie) of betrokkene spelen (de persoon over wie de vraag gesteld wordt). Al deze rollen zijn soorten partij rollen. Voor een geïdentificeerde partij kan er bijgehouden worden wanneer en over welk kanaal hij het liefst gecontacteerd wordt. Dit gebeurt door die gegevens bij te houden in de contact voorkeur klasse. Een laaste aspect dat wordt gemodelleerd voor de partijen is het concept van een mandaat. Een persoon is een mandataris van een of meerdere geïdentificeerde partijen (dus kan hij mandataris zijn van zowel een persoon (bijv. een advocaat) of van een onderneming (bijv. een bedrijfsjurist).

+ Voor de meeste van deze gegevens is het programma MKDV niet de authentieke bron. MKDV is enkel de authentieke bron voor: • de definitie van de partijrollen, • en voor het bijhouden van de geprefereerde contactwijze van de partij.

Vertrouwelijk

© FOD Financiën


9


ORGANISATIE STRUCTUUR

Persoon (from Partij)

rijksregisterNummer : String naam : String v oornaam : String geboortedatum : Datum burgerlijkeStaat = {ongehuwd, gehuwd, gescheiden, ...} beroep : String mobielNummer[0..*] : String

VaardigheidsNiv eau beginDatum : Date eindDatum : Date score : Integer

Adres (from Partij)

beginDatum : Date eindDatum : Date 0..* 0..1

OrganisatieOnderdeel

Vaardigheid omschrijv ing : String

1..*

Medewerker 0..*

maakt deel uit van

werkt voor 1

1..n 1..n

0..*

0..*

1..*

mogelijke kanalen

0..n

speelt

Medewerkersgroep naam : String eigenschap : String

ContactcenterMedewerker

0..*

beschikbaar : Boolean

(from Partij)

omschrijv ing : String

1


TaalVaardig heid

Kanaal

is verantwoordelijk voor 0..n


Prof iel

naam [1] : String niv eau = {n, n-1, ...} beschrijv ing : String telNummer : String f axNummer : String

0..1

MedewerkerRol

Toewijzing beginDatum : Date eindDatum : Date

1

Registrator

Behandelaar

Validator




Functie omschrijv ing : String

Vertrouwelijk

© FOD Financiën


10


Een tweede model omschrijft de klassen die te maken hebben met een organisatie. De basisklassen zijn een medewerker en een organisatie onderdeel. Een medewerker is een persoon en is daarom een subklasse van de klasse persoon die gedefinieerd werd in het model ‘partij’. Elke medewerker heeft een medewerkeridentificatie die wordt gebruikt om de medewerker te identificeren binnen de systemen van de FOD Financiën (en eventueel ook nog op een hoger niveau). Daarnaast heeft elke medewerker ook een taalrol. Een medewerker werkt voor een bepaald organisatie onderdeel. Dit kan zowel een organisatie onderdeel zijn van de front-office, back-office of van beiden. Om uit te drukken dat bepaalde personen verantwoordelijk zijn voor een bepaald organisatie onderdeel, is de relatie ‘is verantwoordelijk voor’ toegevoegd. Voor een organisatie onderdeel kan een adres worden toegevoegd (voor de definitie van adres zie model ‘partij’). Een medewerker die voor het contact center werkt is een contact center medewerker, waarvoor het extra attribuut beschikbaarheid wordt toegevoegd. Voor elke medewerker wordt zijn functie bijgehouden. In de toepassing speelt de medewerker een aantal rollen (zie ook het Use Case Boek). Deze rollen zijn registrator, behandelaar en validator. Elk van de medewerkers kan 1 van die rollen spelen in de behandeling van de vraag afhankelijk van waar in het algemeen proces de vraag zich bevindt. Voor elk van de medewerkers van de front-office wordt er bijgehouden voor welke kanalen hij kan werken en in welke periode (toewijzing) (zo kan een junior informatie ambtenaar enkel werken voor het kanaal correspondentie). In de planning wordt dan bepaald voor welk kanaal hij werkt op een bepaald moment (zie model ‘planning’). Een laatste aspect dat deel uitmaakt van het ‘organisatie’ model is het definiëren van de vaardigheden (in de context van MKDV) van de medewerker. Elke medewerker heeft een profiel. Een profiel bevat scores op een de vaardigheden die deel uitmaken van het bewuste profiel van de medewerker. Een score op een bepaalde vaardigheid (in een bepaalde periode) wordt omschreven in het vaardigheidsniveau.

+ Voor de meeste van deze gegevens is het programma MKDV niet de authentieke bron. MKDV is de authentieke bron voor • beschikbaarheid van de contact center medewerker, • de rollen die de medewerker speelt in de behandeling van de vraag, • de kanalen waarvoor een medewerker kan werken. De basisgegevens van dit model moeten komen uit de personeelsadministratie.

Vertrouwelijk

© FOD Financiën


11


INTERACTIES KanaalInformatie soort : String = {realtime, off-line} kostPerInteractie : Double kostPerMinuut : Double

Kanaal 1

1

T aal

0..n

gaatOver

1

1

geeft

1

1

0..1

0..*

0..*

id : integer status : String

0..*

1

bevat

0..*

1

2

0..* 0..*

Vraag

0..*

vraagT ype : String = {Specifiek, Algemeen} prioritair : Boolean bevestigingOntvangst : Boolean activiteitT ype : String = vraag

BetalingsWijze

1

omschrijving[] : String = {Overschrijving, Proton, Bankkaart}

Complexiteit

vanThema

beheerder : Medewerker id : Integer beginDatum : Date eindDatum : Date vraag/antwoord : String

1

0..1

datumEnUur : Date

0..*

0..*

FAQ

omschrijving : String 0..1

Afspraak

GeïdentificeerdePartij (from Partij)

Subproces

handeltOver 0..*

1..n

identificatieNummer : String marketing : Boolean

1

InteractieDossier 0..*

0..n

moet geleverd worden aan

1..*

Activiteit

0..1

begintijd : T ime eindtijd : T ime / duur : T ime

0..*

0..*

omschrijving : String id : String status : String vervaldag : Date activiteitT ype : String

id : Integer omschrijving : String bronnen : String argumentatie : String gevalideerd[1] : Boolean

0..*


Interactie

voertUit

0..*

Antwoord

bedrag : Double datumEnUur : Date

Betrokkene

0..1



0..*


werdGevraagdDoor

Behandelaar

wordt gegeven via

0..*

Vraagsteller

1

0..* 0..*

creatieDatumEnUur : Date afsluitDatumEnUur : Date

0..*

1

0..*

Contact

0..*

1

(from Partij)

Betaling


1

omschrijving : String

Betaler

Registrator

werdGeregistreerdDoor

(from Partij) 1

1

1..*

omschrijving : String = {eenvoudig, gemiddeld, complex}

0..*

voorFAQ

1

1 1..*

1..*

T hema omschrijving : String

1..*

1

StandaardAntwoordT ermijn geldigVanaf : Date geldigT ot : Date aantalWerkdagen : Integer bron : String

0..* 1..*

De manier waarop de FAQ zullen worden beheerd zal bepalen of er meer informatie nodig is.

isRelevantVoor

OrganisatieOnderdeel (from Organisatie)

naam [1] : String niveau = {n, n-1, ...} beschrijving : String telNummer : String faxNummer : String

2 2 Nota: Voor de specifieke vragen, kunnen extra object elementen bepaald worden rond de vraag en het antwoord die afhankelijk zijn van het type subproces en waarvoor de data verschillend kan zijn per pijler. Dit is meer uitgebreid gedocumenteer in het use case boek (eg. Operationeel specifieke use cases).

Vertrouwelijk

© FOD Financiën


12


De kern van de MKDV toepassing is het ‘interactie’ model, waar de basisklassen voor het registreren van een interactie en het behandelen van een vraag worden bijgehouden. Zodra er een contact is met de FOD Financiën wordt er een interactie opgemaakt. Een interactie maakt altijd deel uit van een interactiedossier. Wanneer de interactie aanleiding geeft tot (een) vra(a)g(en) en/of (een) activiteit(en) dan worden deze opgenomen in hetzelfde interactie dossier, waarbij een link wordt bewaard tussen de interactie en de resulterende vra(a)g(en). en/of activiteit(en). Al deze klassen hebben een aantal gezamelijke eigenschappen die zijn ondergebracht in de contact klasse. Het gaat hier over de creatie en afsluit datum en uur, de vraagsteller, de registrator (rol gespeeld door de medewerker die de interactie, interactie dossier, vraag of activiteit) registreerd. Ook de taal waarin het contact wordt gevoerd wordt altijd ingevuld. Indien de vraagsteller optreedt voor iemand anders, dan wordt ook de betrokkene van de vraag genoteerd op niveau van het contact Deze interactie houdt, naast gegevens die voor elk contact worden bijgehouden (interactie informatie) ook de exacte tijd en duur van de interactie bij. Voor elke interactie wordt genoteerd van welk type de interactie is . Voor een interactie dossier wordt de status en het identificatie nummer van het dossier bijgehouden. Voor vragen en activiteiten wordt er meer informatie bijgehouden. Vragen worden beschouwd als een soort activiteit. Daarnaast kunnen er ook activiteiten met vragen gelinkt worden. Alle soorten activiteiten hebben een omschrijving, een behandelaar, een datum voor de welke de activiteit verricht moet worden. Voor elk van de activiteiten wordt opgegeven wat het type van activiteit is (deze types worden op voorhand bepaald bij het configureren van de MKDV toepassing). Een activiteit heeft altijd een status van uitvoering. Een vraag is een speciaal geval van een activiteit. Volgende elementen worden extra gespecifieerd wanneer het om een vraag gaat. Zo wordt de vraag getypeerd, en wordt een idee gegeven van de complexiteit. Indien nodig kan bij een vraag ook worden bijgehouden of deze prioritair is of er een bevestiging van ontvangst is verstuurd. Een ander element van de vraag is de thematiek van de vraag: met elke vraag wordt een thema gelinkt (dat thema is verbonden met 1 of meerdere pijlers (organisatie onderdeel). Ook wordt er aangegeven, indien relevant, voor welke van de specifieke subprocessen de vraag wordt gesteld. Een standaard antwoordtermijn is bepaald op basis van de combinatie van het thema, het subproces en de complexiteit van de vraag. Een standaard antwoordtermijn is geldig voor een bepaalde periode en omvat een aantal werkdagen. De basis waarop een standaard antwoord termijn is gebaseerd kan bijgehouden worden in het attribuut bron. Wanneer de vraag behandeld is wordt er aan de vraag een antwoord gekoppeld door de behandelaar. Bij het antwoord worden de bronnen en de argumentatie die gebruikt zijn om het antwoord te geven opgegeven. Indien het antwoord het validatie proces heeft doorlopen, dan wordt dit ook aangegeven. Bij het antwoord wordt opgegeven aan welke partij(en) het antwoord geleverd moet worden, in welke taal en via welk kanaal (vooral belangrijk indien het om een verplicht kanaal gaat – bijv. voor het realiseren van de nodige authentificatie). Een antwoord kan het leveren van een item zijn tegen betaling. Indien dit het geval is dan moeten de betaler, het bedrag en de betalingswijze opgegeven worden. In het kader van de interacties wordt er bij het kanaal specifieke kanaalinformatie bijgehouden. De attributen worden enkel ter voorbeeld gegeven. Een laatste klasse representeert de FAQs: elke FAQ heeft een combinatie vraag/antwoord, een beheerder, een of meer gelinkte thema’s en de periode waarin de FAQ actief is.

+ Voor deze gegevens is het programma MKDV de authentieke bron.

Vertrouwelijk

© FOD Financiën


13


Catalogus

DOCUMENTEN

Thema 0..*

gerel ateerdSjabloon 1

SjabloonOmschrijving T ype : String = {Document, Email}

1

(from Interacties)

ProductOmschrij ving naamProduct : String taal : T aal locatie : String omschrij ving : String doel : String toegevoegdOp : Datum actiefVanaf : Datum teBetalen : Bool ean pri js : Double auteur : String sleutelwoorden[0..n] : String 0..*

omschrij ving : String 1 0..*

0..*

pijler

OrganisatieOnderdeel (from Organisatie) 0..1

naam [1] : String niveau = {n, n-1, ...} beschri jvi ng : Stri ng telNummer : String faxNummer : String

1

Bij lage

1

FysiekeDrager omschrijving : String = {Brochure, CD Rom, Video, PDF Document}

Het model van de documenten is een eenvoudig model dat vertrekt vanuit een catalogus. Een catalogus is een verzameling van productomschrijvingen die een bepaald product (op een bepaalde fysieke drager staat te omschrijven in de vorm van een catalogus zodat de medewerker het juiste product kan selecteren. Met een product, kan er ook een sjabloon worden geassocieerd, dat wordt voorgesteld als begeleidend schrijven wanneer een dergelijk product wordt afgeleverd aan een bestemmeling. Voor een product wordt de plaats waar het document terug gevonden kan worden ondergebracht in het attribuut locatie. Een sjabloonomschrijving is een speciaal soort product omschrijving, waar een fysiek document in een bijlage wordt gehangen.

+ Voor deze gegevens is het programma MKDV de authentieke bron, maar deze documenten kunnen komen vanuit een document management systeem.

Vertrouwelijk

© FOD Financiën


14


PLANNING

gebaseerd op 1

Kalender Dag

nietWerkDagen

datum : Date

0..*

0..*

1

startUur : Date eindUur : Date maxAantalWerkurenPerDag : Double maxAantalWerkurenPerWeek : Double

0..*

MedewerkersKalender

Planning beginDatum : Date eindDatum : Date Medewerker (from Operationele use cases) 0..*

0..1

Werkregime

0..*

1..n

begintijd[1] : Date eindtijd[1] : Date 0..*

Vaardigheid (from Organisatie)


1

is verantwoordelijk voor

0..* 0..*


gelinkt aan werkt voor 1

Kanaal (from Partij)


1

0..n

OrganisatieOnderdeel (from Organisatie)

naam [1] : String niv eau = {n, n-1, ...} beschrijv ing : String telNummer : String f axNummer : String

Om te kunnen werken in een front-office moet er een planning gemaakt worden van de medewerkers die zullen werken in de front-office. De eerste versie van de planning (lange termijn) bestaat enkel uit een aantal werkregimes waarvoor bepaalde vaardigheden vereist zijn. Een werkregime gaat over een bepaalde dag, begint op een bepaald uur en eindigt op een bepaald uur. Een werkregime is ook gelinkt aan een bepaald kanaal.

Vertrouwelijk

© FOD Financiën


15


Anderzijds heeft elke werknemer een persoonlijke medewerkerskalender die gebaseerd is op een standaard kalender (daarnaast is de medewerkerskalender ook een speciaal geval van een kalender). Wanneer de planning geconcretiseerd wordt, dan worden de medewerkers toegekend aan een werkregime op basis van hun kalender en op basis van hun profiel. Op dat moment wordt er een link gemaakt tussen een medewerker en werkregime.

+ Voor deze gegevens is het programma MKDV de authentieke bron, tenzij van de vakantie gegevens van een medewerker. Deze moeten komen uit de personeelsadministratie.

Vertrouwelijk

© FOD Financiën


16


Kwalitei tsDossier Kwalitei tsEval uatie

InteractieDossier gaatOver

0..*

(f rom Interacties) 1

0..*

evaluati e

0..* 0..*

gaatOver

id : i nteger status : String bevat1

0..1

0..*

Vraag

(f rom Interacties)

1..*

vraagType : String = {Specifiek, Algemeen} compl exitei t : String = {Eenvoudig, Gemiddeld, Complex} prioritai r : Boolean bevestigingOntvangst : Boolean activiteitType : Stri ng = vraag

Kwal iteitsCriterium datum : Date omschri jving : String categorie : String = {kwaliteit vh antwoord, kwal iteit communicatie, respecteren antw.} typeAntwoord : Stri ng = {score, boolean, ...} geldigVanaf : Date geldigTot : Date

wordtOpgesteldDoor

0..*

opgemaaktDoor 1

1

Medewerker (f rom Operationele use cases) medewerkerIdentif icatie [1] : String taalrol : Taal

Het laatste model bevat een aantal klassen die gebruikt kunnen worden voor het uitvoeren van de kwaliteitsreviews. Een kwaliteitsdossier wordt opgemaakt voor een bepaald interactiedossier en kan specifiek gelinkt zijn aan een bepaalde vraag. In een kwaliteitsdossier, zitten de resultaten van de kwaliteitsevaluatie van een aantal kwaliteitscriteria. Het dossier wordt opgesteld door een bepaalde medewerker, de criteria ook. Bij het bepalen van de criteria waar het dossier zal worden op getoetst, krijgt het criterium een bepaalde categorie. Deze categorieën worden bepaald als onderdeel van de configuratie van de front-office toepassing. Voor elk van de criteria wordt bepaald wanneer het geldig en in welke vorm een evaluatie van het criterium wordt verwacht.

+ Voor deze gegevens is het programma MKDV de authentieke bron. Vertrouwelijk

© FOD Financiën


17


*

,&

" "

$

- +" + . # /

*

)

.0

)

In een aparte tabel wordt er een overzicht gegeven van de databronnen die in de toekomst gebruikt worden ter ondersteuning van het programma MKDV. De informatie in deze tabel is gegeven op basis van de vandaag gekende informatie. Dit kan nog wijzigen in toekomst wanneer de volledige draagwijdte en specificaties van de andere programma’s, zoals Knowlegde Management of GIV gekend zijn.

*

# '(

KLASSE PARTIJ Anonieme Partij Locatie

' EXTERN Studie/ aan MKDV Project Y/N

ATTRIBUTEN Naam

Type

Segment type[1] naam[1] identificatie[1]

{Particulier, Zelfstandige/onderneming, Mandataris} {land,stad,provincie,staat} String String

No Yes

GIV

DATASOURCE

Basis gegeven : is nog niet gedefinieerd

De tabel is als volgt opgesteld: • De eerste kolom bevat de naam van de klasse zoals vernoemd in het bovenstaande conceptueel object model. • De tweede en 3de kolom bevat de attributen (met type) van de klassen in de eerste kolom. • Extern aan MKDV geeft aan of de authentieke bron die voor deze gegevens zorgt buiten het programma MKDV staat of niet. Indien dit zo is, dan wordt in een volgende kolom aangegeven in welke studie of welk project deze data behandeld zal worden. • In een laatste kolom wordt de bron toegelicht

Vertrouwelijk

© FOD Financiën

**

"

'

KLASSE PARTIJ Anonieme Partij Locatie Adres

GeïdentificeerdePartij Mandaat FysischAdres

EmailAdres Webpagina ContactVoorkeur Kanaal Onderneming OndernemingType Persoon

EXTERN Studie/ aan MKDV Project Y/N

ATTRIBUTEN Naam

Type

Segment type[1] naam[1] identificatie[1] beginDatum eindDatum

{Particulier, Zelfstandige/onderneming, Mandataris} {land,stad,provincie,staat} String String Date Date

No Yes

GIV

Basis gegeven : is nog niet gedefinieerd

Yes

GIV

mobielNummer identificatieNummer marketing beginDatum eindDatum reikwijdte straatnaam huisnummer telefoonnummer[1..*] faxnummer[0..*] emailAdres url voorkeurDagen voorkeurUren omschrijving KBOnummer naam taal omschrijving rijksregisterNummer naam voornaam geboortedatum burgerlijkeStaat beroep

String String Boolean Date Date String String String String String String String String String String String String {NL,FR,GE,EN} String String String String Date {ongehuwd, gehuwd, gescheiden,...} String

Yes Yes No Yes

GIV GIV

Indien mogelijk de periode waarin het adres geldig is. Het soort adres is opgegeven (legaal adres, contact adres,…) canaux de communication numéro d'identification unique

Taal PartijRol

Yes

Yes Yes No

DATASOURCE

GIV/FEDICT Mandataire (geldigheidsdatum en reikwijdte niet teruggevonden) GIV Adresse

GIV GIV

canaux de communication canaux de communication

No Yes

GIV

Personne morale

Yes

GIV

forme juridique ou type

Yes

GIV

Personne physique

Yes No

GIV

Langue

(1) Indien mogelijk worden hier to be bronnen vermeld - de meeste beschikbare gegevens waren echter as is bronnen

Vertrouwelijk

© FOD Financiën


19


ORGANISATIE OrganisatieOnderdeel

Medewerkersgroep Medewerker ContactcenterMedewerker Functie Toewijzing Vaardigheid

Vaardigheidsniveau Profiel MedewerkerRol

Vertrouwelijk

naam[1] niveau beschrijving telNummer faxNummer

String {n,n-1,…} String String String

Yes

naam eigenschap medewerkerIdentificatie[1] taalrol beschikbaar omschrijving

String String String taal Boolean String

No

beginDatum eindDatum omschrijving

Date Date String

beginDatum eindDatum score Profiel

Date Date Integer Profiel

© FOD Financiën

HR

Het niveau van een agent is gekend en het verschil met het management ook. Er bestaat echter geen hierarchie op niveau van de agentschappen. Het organigram van de agentschappen is nog te construeren en indien nodig kan hier een hierarchie aan toegevoegd worden.

Yes

HR

No Yes

Ook tel nummer en niveau zijn gekend

HR

Bestaat vandaag enkel voor de personen die vallen onder het copernicus programma

Yes

HR

Yes

HR

as - is : opleidingen van alle medewerkers, carriere examens, taalexamens zijn gekend in het systeem (evenals de examens die recht geven op krediet uren). Voor 50% van het personeel zijn de diploma gegevens up to date in het systeem. Indien nodig kan deze informatie verder worden aangevuld door de FOD. To be : In de nieuwe HR applicatie worden de competenties verder beheerd. Nieuwe HR applicatie

No

No No


20


INTERACTIES KanaalInformatie Betaling Antwoord

Betalingswijze Activiteit

InteractieDossier Vraag

FAQ

Thema Afspraak Complexiteit Subproces StandaardAntwoordTermijn

Contact Interactie InteractieType

Vertrouwelijk

soort kostPerInteractie kostPerMinuut bedrag datumEnUur id omschrijving bronnen argumentatie gevalideerd[1] omschrijving[] omschrijving id status vervaldag activiteitType id status vraagType prioritair bevestigingOntvangst activiteitType beheerder id beginDatum eindDatum Vraag/antwoord omschrijving datumEnUur omschrijving omschrijving geldigVanaf geldigTot aantalWerkdagen bron creatieDatumEnUur afsluitDatumEnUur begintijd eindtijd /duur omschrijving

String={realtime,off-line) Double Double Double Date Integer String String String Boolean string={Overschrijving, Proton, Bankkaart} String String String Date String Integer String String={specifiek, Algemeen} Boolean Boolean String=vraag medewerker Integer Date Date String String Date String={eenvoudig, gemiddeld, complex} String Date Date Integer String Date Date time time time string={e-mail, brief, fax, portaal, telef…}

© FOD Financiën

No No No

No No

No No

No

No No No No No

No No No


21


DOCUMENTEN ProductOmschrijving

SjabloonOmschrijving FysiekeDrager Catalogus Bijlage PLANNING Dag Planning Werkregime Kalender

MedewerkersKalender KWALITEIT Kwaliteitsdossier KwaliteitsEvaluatie KwaliteitsCriterium

naamProduct taal locatie omschrijving doel toegevoegdOp actiefVanaf teBetalen prijs auteur sleutelwoorden[0..n] Type omschrijving

String taal String String String Date Date Boolean Double String String String={Document, Email} String={Brochure, CD Rom, Video, PDF Document}

datum beginDatum eindDatum begintijd[1] eindtijd[1] startUur eindUur maxAantalWerkurenPerDag maxAantalWerkurenPerWeek

Date Date Date Date Date Date Date Double Double

evaluatie datum omschrijving categorie typeAntwoord geldigVanaf geldigTot

Vertrouwelijk

No

Omschrijvingen van de documenten kunnen komen uit de andere programmas zoals Patr Doc., Paperl. Douane, B&I

No No No No No No No No

No

Date String String={kwaliteit vh antwoord, kwaliteit communicatie, respecteren antw.} String={score, boolean,...} Date Date

© FOD Financiën

No No No


22


FOD Financiën Programma Multi-kanaal Dienstverlening Conceptueel Object Model 3.0

Recommend Documents