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

Transcriptie

1 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 6/06/2004 Voorstudie Programma MKDV

2 Inhoud Blz.. Inleiding Objectief van het document 3.2. Werkwijze 3 2. Conceptueel Object Model Uitleg van de gebruikte notatie Package diagram Klasse diagram Package Diagram Object Modellen Partij Organisatie Interacties Documenten Planning Kwaliteit 7 3. Link met to be data sources Overzicht van de to be sources Uitleg van de tabel Tabel met de databronnen 9 Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

3 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 V.0. In deze use cases wordt er gebruikt gemaakt van een aantal concepten die overeenkomen met 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

4 !"# $% " & #'( ( 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. 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): Party Ondersteunende Use Case 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 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. Bij het lezen van de modellen worden een begrip van Object Orientatie en meer bepaald UML modellen verondersteld. Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

5 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 : id : status : vervaldag : activiteittype : 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 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 : bronnen : argumentatie : gevalideerd[] : Boolean 0.. Vraag vraagtype : = {Specifiek, Algemeen} complexiteit : = {Eenvoudig, Gemiddeld, Complex} prioritair : Boolean bevestigingontvangst : Boolean activiteittype : = vraag Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

6 ((( Planning begindatum : einddatum : Catalogus Werkregime begintijd[] : eindtijd[] : 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 van de aggregatie. ( Persoon (from Partij) rijksregisternummer : naam : v oornaam : geboortedatum : Datum burgerlijkestaat = {ongehuwd, gehuwd, gescheiden,...} beroep : Medewerker medewerkeridentif icatie [] : 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 Bestemmeling Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

7 !( ( Partij Interacties Organisatie Documenten 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

8 * &' PARTIJ speelt AnoniemePartij segment = {Particulier, Zelf standige/onderneming, Mandataris} officiële taal Taal PartijRol Een geïdentificeerde partij is altijd een Persoon of een Onderneming. Elke partij kan volgende rollen spelen: vraagsteller, bestemmeling, burger. Locatie ty pe[] = {land, stad, provincie, staat} naam[] : identif icatie[0..] : 0.. Vraagsteller Betrokkene GeïdentificeerdePartij identificatienummer : marketing : Boolean contactadres..* Adres begindatum : einddatum : Mandaat begindatum : einddatum : reikwijdte : Bestemmeling is mandataris van legaaladres 0.. Fysisch adres straatnaam : huisnummer : telef oonnummer[..*] : f axnummer[] : Adres adres : Webpagina url : Persoon rijksregisternummer : naam : voornaam : geboortedatum : Datum burgerlijkestaat = {ongehuwd, gehuwd, gescheiden,...} beroep : mobielnummer[] : Onderneming KBONummer : naam : legalestructuur OndernemingTy pe taal = {NL, FR, GE, EN} omschrijv ing : 0.. ContactVoorkeur voorkeurdagen : voorkeururen : 0..n geprefereerdkanaal 0.. Kanaal omschrijving : Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

9 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 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 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

10 ORGANISATIE STRUCTUUR VaardigheidsNiv eau begindatum : einddatum : score : Integer Persoon (from Partij) rijksregisternummer : naam : v oornaam : geboortedatum : Datum burgerlijkestaat = {ongehuwd, gehuwd, gescheiden,...} beroep : mobielnummer[] : Adres (from Partij) begindatum : einddatum : Vaardigheid omschrijv ing : TaalVaardig heid Kanaal (from Partij) omschrijv ing :..* maakt deel uit van Prof iel mogelijke kanalen Toewijzing begindatum : einddatum : Medewerker medewerkeridentif icatie [] : taalrol : Taal..* ContactcenterMedewerker beschikbaar : Boolean speelt is verantwoordelijk voor 0..n werkt voor..n..n 0.. MedewerkerRol 0..n 0.. OrganisatieOnderdeel naam [] : niv eau = {n, n-,...} beschrijv ing : telnummer : f axnummer : Medewerkersgroep naam : eigenschap : Registrator Behandelaar Validator Functie omschrijv ing : Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

11 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 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 Conceptueel Object Model 3.0 Gevalideerd door stuurgroep van 6/06/2004

12 INTERACTIES KanaalInformatie soort : = {realtime, off-line} kostperinteractie : Double kostperminuut : Double Betaler Betaling bedrag : Double datumenuur : 0.. Kanaal (from Partij) omschrijving : Taal (from Partij) wordt gegeven via Antwoord id : Integer omschrijving : bronnen : argumentatie : gevalideerd[] : Boolean Behandelaar geeft 0.. voertuit Activiteit omschrijving : id : status : vervaldag : activiteittype : bevat Contact creatiedatumenuur : afsluitdatumenuur : InteractieDossier id : integer status : 0..n..* werdgeregistreerddoor werdgevraagddoor gaatover Interactie begintijd : Time eindtijd : Time / duur : Time 0.. Registrator Vraagsteller Betrokkene BetalingsWijze GeïdentificeerdePartij (from Partij) identificatienummer : marketing : Boolean omschrijving[] : = {Overschrijving, Proton, Bankkaart} 0..n moet geleverd worden aan..n FAQ beheerder : Medewerker id : Integer begindatum : einddatum : vraag/antwoord : Vraag vraagtype : = {Specifiek, Algemeen} prioritair : Boolean bevestigingontvangst : Boolean activiteittype : = vraag voorfaq vanthema..* Thema omschrijving : Afspraak datumenuur : Complexiteit handeltover omschrijving : = {eenvoudig, gemiddeld, complex} 0....* Subproces omschrijving : 0....* 2..* StandaardAntwoordTermijn geldigvanaf : geldigtot : aantalwerkdagen : Integer bron : De manier waarop de FAQ zullen worden beheerd zal bepalen of er meer informatie nodig is...* isrelevantvoor OrganisatieOnderdeel (from Organisatie) naam [] : niveau = {n, n-,...} beschrijving : telnummer : faxnummer : 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

13 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 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

14 DOCUMENTEN Catalogus gerelateerdsjabloon SjabloonOmschrijving Type : = {Document, } ProductOmschrijving naamproduct : taal : Taal locatie : omschrijving : doel : toegevoegdop : Datum actiefvanaf : Datum tebetalen : Boolean prijs : Double auteur : sleutelwoorden[0..n] : pijler 0.. Thema (from Interacties) omschrijving : OrganisatieOnderdeel (from Organisatie) naam [] : niveau = {n, n-,...} beschrijving : telnummer : faxnummer : Bijlage FysiekeDrager omschrijving : = {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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

15 PLANNING Dag datum : nietwerkdagen Kalender startuur : einduur : maxaantalwerkurenperdag : Double maxaantalwerkurenperweek : Double gebaseerd op MedewerkersKalender Planning begindatum : einddatum : Werkregime begintijd[] : eindtijd[] : 0.. Medewerker medewerkeridentificatie [] : taalrol : Taal..n is verantwoordelijk voor gelinkt aan werkt voor Vaardigheid (from Organisatie) omschrijv ing : Kanaal (from Partij) omschrijv ing : 0..n OrganisatieOnderdeel (from Organisatie) naam [] : niv eau = {n, n-,...} beschrijv ing : telnummer : f axnummer : 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

16 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

17 KwaliteitsEval uatie evaluatie KwaliteitsCriterium..* datum : omschrijving : categorie : = {kwaliteit vh antwoord, kwaliteit communicatie, respecteren antw.} typeantwoord : = {score, boolean,...} geldigvanaf : geldigtot : KwaliteitsDossier gaatover gaatover 0.. InteractieDossier (from Interacties) id : integer status : bevat Vraag (from Interacties) vraagtype : = {Specifiek, Algemeen} complexiteit : = {Eenvoudig, Gemiddeld, Complex} prioritair : Boolean bevestigingontvangst : Boolean activiteittype : = vraag opgemaaktdoor wordtopgestelddoor Medewerker (f rom Operationele use cases) medewerkeridentif icatie [] : 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 Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

18 *, &" " $ -+"+.#/.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 ATTRIBUTEN EXTERN aan MKDV Studie/ Project Naam Type Y/N PARTIJ Anonieme Partij Segment {Particulier, Zelfstandige/onderneming, Mandataris} No Locatie type[] {land,stad,provincie,staat} Yes GIV naam[] identificatie[] De tabel is als volgt opgesteld: DATASOURCE Basis gegeven : is nog niet gedefinieerd 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

19 ** "' KLASSE ATTRIBUTEN EXTERN aan MKDV Studie/ Project Naam Type Y/N PARTIJ Anonieme Partij Segment {Particulier, Zelfstandige/onderneming, Mandataris} No Locatie type[] {land,stad,provincie,staat} Yes GIV naam[] identificatie[] Adres begindatum Yes GIV einddatum DATASOURCE GeïdentificeerdePartij mobielnummer Yes GIV canaux de communication identificatienummer Yes GIV numéro d'identification unique marketing Boolean No Mandaat begindatum Yes GIV/FEDICT Mandataire (geldigheidsdatum einddatum en reikwijdte niet reikwijdte teruggevonden) FysischAdres straatnaam Yes GIV Adresse huisnummer telefoonnummer[..*] faxnummer[] Adres adres Yes GIV canaux de communication Webpagina url Yes GIV canaux de communication ContactVoorkeur voorkeurdagen No voorkeururen Kanaal omschrijving No Onderneming KBOnummer Yes GIV Personne morale naam OndernemingType taal {NL,FR,GE,EN} Yes GIV forme juridique ou type omschrijving Persoon rijksregisternummer Yes GIV Personne physique naam voornaam geboortedatum burgerlijkestaat {ongehuwd, gehuwd, gescheiden,...} beroep Taal Yes GIV Langue PartijRol No () Indien mogelijk worden hier to be bronnen vermeld - de meeste beschikbare gegevens waren echter as is bronnen Basis gegeven : is nog niet gedefinieerd Indien mogelijk de periode waarin het adres geldig is. Het soort adres is opgegeven (legaal adres, contact adres, ) Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

20 ORGANISATIE OrganisatieOnderdeel naam[] Yes HR niveau {n,n-, } beschrijving telnummer faxnummer 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. Medewerkersgroep naam No eigenschap Medewerker medewerkeridentificatie[] Yes HR Ook tel nummer en niveau zijn taalrol taal gekend ContactcenterMedewerker beschikbaar Boolean No Functie omschrijving Yes HR Bestaat vandaag enkel voor de personen die vallen onder het copernicus programma Toewijzing begindatum No einddatum Vaardigheid omschrijving 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. Vaardigheidsniveau begindatum Yes HR Nieuwe HR applicatie einddatum score Integer Profiel Profiel Profiel No MedewerkerRol No Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

21 INTERACTIES KanaalInformatie soort ={realtime,off-line) No kostperinteractie Double kostperminuut Double Betaling bedrag Double No datumenuur Antwoord id Integer No omschrijving bronnen argumentatie gevalideerd[] Boolean Betalingswijze omschrijving[] string={overschrijving, Proton, Bankkaart} No Activiteit omschrijving No id status vervaldag activiteittype InteractieDossier id Integer No status Vraag vraagtype ={specifiek, Algemeen} No prioritair Boolean bevestigingontvangst Boolean activiteittype =vraag FAQ beheerder medewerker No id Integer begindatum einddatum Vraag/antwoord Thema omschrijving No Afspraak datumenuur No Complexiteit omschrijving ={eenvoudig, gemiddeld, complex} No Subproces omschrijving No StandaardAntwoordTermijn geldigvanaf No geldigtot aantalwerkdagen Integer bron Contact creatiedatumenuur No afsluitdatumenuur Interactie begintijd time No eindtijd time /duur time InteractieType omschrijving string={ , brief, fax, portaal, telef } No Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004

22 DOCUMENTEN ProductOmschrijving naamproduct No taal taal locatie omschrijving doel toegevoegdop actiefvanaf tebetalen Boolean prijs Double auteur sleutelwoorden[0..n] SjabloonOmschrijving Type ={Document, } No FysiekeDrager omschrijving ={Brochure, CD Rom, Video, PDF Document} No Catalogus No Bijlage No PLANNING Dag datum No Planning begindatum No einddatum Werkregime begintijd[] No eindtijd[] Kalender startuur No einduur maxaantalwerkurenperdag Double maxaantalwerkurenperweek Double MedewerkersKalender No KWALITEIT Kwaliteitsdossier No KwaliteitsEvaluatie evaluatie No KwaliteitsCriterium datum No omschrijving categorie ={kwaliteit vh antwoord, kwaliteit communicatie, respecteren antw.} typeantwoord ={score, boolean,...} geldigvanaf geldigtot Omschrijvingen van de documenten kunnen komen uit de andere programmas zoals Patr Doc., Paperl. Douane, B&I Vertrouwelijk FOD Financiën Conceptueel Object Model Gevalideerd door stuurgroep van 6/06/2004