Forord. Versioner. APOS2 Bulk data import / export. APOS2 Security. APOS2 Installation, Operation and Monitoring. APOS2 Service Catalogue

Transkript

1 APOS2 Datamodel

2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne. Dokument oversigt: APOS2 Bulk data import / export APOS2 Security APOS2 Installation, Operation and Monitoring APOS2 Service Catalogue APOS2 Data Models APOS2 Administration Guide Alle dokumenterne kan findes på: Versioner Version Dato Beskrivelse /04/2012 Initial version /03/2013 Opdateret mht. roller og stedfortræder. Div. mindre fejl er også rettet /07/2014 Fjernet beskrivelse af primær markering, som ikke findes mere. Tabel 1: Dokuments historik 2

3 APOS2 er en implementation af Sag & Dokument standarderne for Organisation, Part og Klassifikation. Formålet med de nye Sags- og Dokumentstandarder er at understøtte et bedre samspil og en smidigere integration mellem fagsystemer og ESDH, og mellem forskellige ESDH-systemer. En standardiseret tilgang til data i ES- DH og fagsystemer vil muliggøre automatisering af arbejdsgange internt i organisationer, samt overdragelse af sager og dokumenter imellem organisationer og vil lette udviklingen af selvbetjeningsløsninger. Målet er endvidere at nedbringe omkostningerne til integrationer. Standarderne er udarbejdet af arbejdsgrupper nedsat under OIO-udvalget for sags- og dokumentområdet, og en lang række myndigheder og leverandører har deltaget i den konkrete udformning af standarderne. Der har været stort fokus på at understøtte den praktiske anvendelighed af standarderne i forhold til eksisterende og fremtidige ESDH- og fagsystemer. Dokumentation for Sag og Dokument findes her: Forudsætningerne for at kunne få udbytte af datamodellerne er en grundlægende indsigt i de nævnte standarder. 3

4 Indhold 1 Hvad er en datamodel? 5 2 Fortolkninger, mangler og udvidelser af standarden 5 3 Organisation mønstre Hieraki og enhedstype Lokation med adresser Engagement Leder niveau og ansvar Leder stedfortræder Roller Rolle stedfortræder Opgave klassifikationer IT Systemer og brugere Kontaktkanaler AM/MED organisation Fremtidige modeller 20 A Database schema 20 A.1 Egenskab A.2 Tilstand A.3 Relation A.4 Fler relation Indholdsfortegnelse 4

5 1 Hvad er en datamodel? En datamodel er den måde data er relateret. Dette kan betragtes på en logisk og et fysisk niveau. I beskrivelsen af hvordan APOS2 bruger Sag & Dokument standard objekterne til at løse foretningsdomæne behov, benyttes en logisk beskrivelse og illustrering. Dvs. egenskab værdier, tilstande og relationer benyttes som simple typer angivet ved deres værdi eller som en pil til et andet objekt. Den endelige implementation af disse i den fysiske model kræver flere database tabeller for at kunne understøtte de generelle egenskaber som f.eks. bitemporalitet. 2 Fortolkninger, mangler og udvidelser af standarden I Sag & Dokument standarden opereres der med objekterne inden for et pågældende område som f.eks. Klassifikation eller Organisation. Når et objekt refereres fra et område til et andet, betegnes et sådan objekt som et blåt objekt. Der er en del af disse blå som ikke findes men så er nødvendige for APOS2. F.eks. Adresse Myndighed Virksomhed... Af disse has APOS2 brug for at kunne referere adresse data, dvs. geografiske adresser og kontaktkanaler. Disse findes ikke som blå objekter, men der findes versioner af samme i høringsversionen for Part. Her er objekterne dog ikke rigtige objekter med UUID, egenskaber og de øvrige generelle egenskaber. Det er kun ud fra prosa i specifikationerne at man kan udlede at det blå objekt: Adresse må være en generaliseret type. APOS2 implementationen er vist i figur 1. 5

6 Figur 1: Adresse hieraki i APOS2. De manglende objekter som der er implementeret i APOS2 er derfor: GeografiskAdresse, KontaktKanal som angivet i Part og en langt mere fleksible klassifikation baseret Kontaktkanal. Alle disse objekter kan tilknyttes objekter som har relationer til super typen: Adresse. Geografisk adresse og Kontaktkanal følger OIO og informationsmodelen for Part. KlassifikationKontaktkanal har strukturen vist i figur 2 Figur 2: Klassifikationsbaseret kontaktkanal. Styrken ved et sådan kontaktkanal objekt er at det kan representere alle typer uden statisk arv begrænsninger. Koblingen imellem en organisatorisk enhed og dens geografiske pladcering(er) kan ikke modeleres i standarden da der mangler en kobling, som i APOS2 kaldes Lokation. Dette objekt holder kontaktkanaler, geografiske adresser, hvilke personer der arbejder på lokationen, p-nummer og åbningstider. Mange af disse er muligvis omfattet af specifikationen for ejendom, som i skrivende stund ikke er tilgængelig. 6

7 Pointen med Lokation er at en organisatiorisk enhed kan være spredt på flere lokationer som derved hver har et p-nummer, har muligvis deres egne s og telefon numre og vil måske have 1 eller flere geografiske adresser. Lokation vil blive vist i sammenhæng herunder. 3 Organisation mønstre Der vil kun blive beskrevet hvorledes den logiske datamodel er opbygget ifm. organisation komponenten. Dette skyldes at det er i denne komponent hvor der laves mange sammenstillinger af data, som ikke har af standarden navngivne relationer. Den måde disse forretningsmønstre bliver implementeret vha. organisation-funktioner vil variere fra leverandør til leverandør, selv om systemerne overholder standarden for organisation. Lignende implementationsvalg er også blevet foretaget i APOS2 ifm. håndtering af brugen af FORM 2.1 og de facetter dette klassifikationssystem indeholder. Varetagerne af Sag & Dokument standarderne bør påtage sig governance af hvordan standardene implementeres, konfigureres og bruges for at sikre at systemerne kan udveksle data. 3.1 Hieraki og enhedstype Organisation er hvor organisationenhederne er kædet sammen i en træstruktur. Den helt basale struktur er en Organisation som udpeger en rod organisationenhed. Der kan opbygges mangle organisationer: Politisk, AM/MED, Administrative, Løn, Økonomi,... 7

8 Figur 3: Del af administrative organisation. Måden hvorpå et hieraki er opbygget er at et Organisation objekt udpeger rod enheden for hierakiet. Organisationenheder kædes sammen ved brug af relationen: Overordnet. Det er muligt at angive en enhedstype som kan benyttes ifm. søgning, visning og måden hvorpå andre systemer integrere med APOS2. F.eks. kan et system angive at det ønsker enhedsændringer fra beskedfordeleren, men kun for enheder som er af typen SKOLE. 3.2 Lokation med adresser Ved at udvide modellen med Lokation data er det muligt at knytte geografisk adresse (postadresser) og kontaktinformationer (telefon, fax, ) på organisationsenheder. En organisationsenhed er et logisk begreb som beskriver hvordan kommunen varetager opgaver. En lokation beskriver hvor disse logiske enheder kan findes fysisk. En enhed kan benytte flere lokationer, som ikke nødvendigvis er arbejdspladser men f.eks. blot steder hvor enheden har udstyr som skal kunne serviceres. Personer som er tilknyttet til enhederne kan knyttes til de lokationer hvor de arbejder. Derved vil det være lettere at kontakte de relevante medarbejdere. Systemer og personer som administrerer installationer og PC ere kan benytte lokationerne ifm. de administrative systemer de bruger. En person kan også være tilknyttet flere lokationer f.eks. plejepersonale som arbejder på forskellige plejecentre. Ved at vedligeholde den information vil det være muligt at rette kommunikation mod de medarbejdere, som arbejder på specifikke geografiske adresser. Relationen Adresser benyttes til at udpeget både kontaktkanaler og geografiske adres- 8

9 ser. Figur 4: Angivelse af lokation og arbejdssted. Det er også muligt at angive en generel adresse direkte på en organisationsenhed. Denne er tiltænkt geografisk adresse, telefon, og EAN nummer. Den generelle adresse er en overordnet type, som kan være en kontaktkanal: Telefon nummer, , osv, eller en geografiskadresse. 3.3 Engagement Personer som er tilknyttet en organisationenhed, typisk ansatte, oprettes og vedligeholdes i Part systemet med objektet Person. Det er også i dette domæne at kommunikation og geografiske adresser håndteres. 9

10 Figur 5: Den administrative organisation med ansatte. I den simple udgave udpeges personerne som ansatte til en enhed. Dette beskriver dog ikke ansættelsesforholdet og hvad med de personer som blot er udlånt eller er vikarer? Denne ekstra beskrivelse af hvilken funktion en person udfører ift. enheden beskrives vha. en organisationfunktion. Figur 5 viser hvorledes en person har funktionen Engagement som udpeger klassifikationen for ansættelse eller tilknytningen til en enhed. Der bruges klassifikationer til at beskrive beskrive hvilken type funktion der er tale om og til at angive ensartede beskrivelser af hvad funktionen udtrykker. Alle enheder vil udpege egne versioner af disse funktioner. Dvs. når der oprettes en ny enhed skal de oprettes, samt andre organisationfunktioner som beskrevet i dette dokument. Ikke alle personer som arbejder for en enhed er ansatte. Nogle kan være udlånt af en anden afdeling og andre kan være eksterne konsulenter. Disse personer tilknyttes enheden vha. relationen: TilknyttedePersoner. Klassifikationer opbygges i Klassifikationssystemet og vedligeholdes her. Fordelen ved at benytte et klassifikationssystem fremfor f.eks. fritekst, er at der opnåes en konsistent opmærkning af data som kan benyttes ifm. distributionslister, rapporter, etc. 10

11 3.4 Leder niveau og ansvar Leder niveau og ansvar eksempel. Der er i KK opbygget 5 ledelsesniveauer. De forvaltningsneutrale betegnelser for disse er: Niveau Neutral niveau betegnelse Hjemmeplejen betegnelser 1 Direktion Direktion 2 Refererer til direktionen Lokalområdechef 3 Ledere Hjemmeplejeleder 4 Mellemledere Gruppeleder 5 Mellemledere - Tabel 2: Leder data med neutral og domæne specifik betegnelse Alt efter hvilken forvaltning de benyttes i, kaldes en leder på samme niveau noget forskelligt. Det har dog ikke noget med egentlig stillingsbetegnelse at gøre, og skal kun betragtes som en domænespecifik ledelsesbetegnelse. Et eksempel for hjemmeplejen er vist i tabellen herover. Det APOS2 datamodellen skal kunne udtrykke og holde af information er både niveauet s nummer, den neutrale betegnelse og den domænespecifikke angivelse afhængig af forvaltning. 11

12 Figur 6: Markering af ledere mht. deres ledelsesniveau og ansvar. Hvert niveau refererer ansvarsområder som kan variere per område og muligvis ned til afvigelser under den enkelte organisatoriske enhed. Figur 6 viser hvordan skoleleder angives via en organisationsfunktion. Der indgår to klassifikationer, en for angivelse af ledelsesniveauet. Disse klasser har niveau nummer som brugervendt nøgle og den neutrale ledelsesbetegnelse som klasse navn. Funktionstypen peger på niveau type klassen. Den område specifikke betegnelse er funktionsnavngivning. Funktionsnavnet for hjemmeplejen for en niveau 4 Mellemleder vil være: Hjemmeplejeleder. Det er funktionsnavnet som brugeren af organisation administrationen blvier præsenteret for. Ledergruppen arbejdsopgaver udpeges af funktionen i klassifikationen for Ansvar. Herved åbnes der for at der kan laves ledelsesfunktioner på niveau 4 og 5 som har forskellige ansvarsopgaver. Mulighederne for at opbygge distributionslister, rapporter osv. er mange da disse kan udtrækkes ved at filtrere på både lederansvar og lederniveau klassifikationerne. For 12

13 at lette opbygningen af nye enheder, findes der MOX agenter som automatiserer f.eks. hvilke leder funktioner som automatisk oprettes under nye enheder. Dette er baseret på templates som kan ændres efter behov. En leder funktions indflydelse gælder for underliggende enheder i hierakiet, indtil en anden leder funktion med samme ansvar overtager opgaven. APOS2 har kaskade visning af leder funktioners indflydelse i hierakiet, inklusiv angivelse af stedfortrædere. 3.5 Leder stedfortræder En leder person kan have én eller flere stedfortræder i en periode. Dette opnåes ved benytte en lederstedfortræder organisationfunktion. Denne funktion udpeger hvilke leder ansvar som personerne er stedfortrædere for for den angivne leder, samt hvilken type lederstedfortræder personen er. På figur 7 vises en stedfortræder, som kan udføre det samme som lederen og administratoren. Figur 7: Stedfortræder for personale ansvar. En lederstedfortræder organisationfunktion udpeger altid lederen, som den første person og den/de person(er), som er hendes stedfortræder derefter. Eksemplet i figur 7 viser at Anette er stedfortræder for Birte for ansvarsopgaven: Personale. Det er muligt at oprette flere lederstedfortrædere for samme person, på forskellige eller sammen ansvars- 13

14 områder. Dette bevirker at der skabes flere lederstedfortræder organisationfunktioner. Ledertedfortrædere indgår i kaskadeberegningerne for ledere. 3.6 Roller Ud over de navngivne roller: Leder og Engagement, har APOS2 også et generisk rolle begreb, som kan benyttes til en lang række modeleringer. F.eks. kan tilidsrepræsentanter, IT godkender og andre nøglepersoner registreres i APOS2 vha. roller. Som for leder er det en enhed som ejer den funktion som benyttes til at repræsentere rollen. En rolle oprettes med én klasse, som angiver hvilket ansvar eller opgave, personerne som er tilknyttet rollen, udfører. Rollen gælder for enheden som udpeger rollen og i dennes underenheder, indtil at der er en ny rolle længere nede i hierakiet som har samme ansvar/rolle. Figur 8: Angivelse af rolle. APOS2s kaskade visning virker også på de generelle roller. En person kan være stedfortræder for én eller flere ledere i en periode. Dette opnåes ved benytte en ledertype organisationfunktion som beskrevet herover. I stedet for at denne funktion udpeger et lederniveau benyttes lederniveau klassen Stedfortræder. 14

15 3.7 Rolle stedfortræder En person som har en rolle kan have én eller flere stedfortræder i en periode. Dette opnåes ved benytte en stedfortræder organisationfunktion. Denne funktion udpeger hvilken rolle som personen er stedfortræder for, samt hvilken type rollestedfortræder personen er. I det viste eksempel på figur 9 er stedfortræder, en person som kan udføre det samme som lederen og administrator, en person som kun kan forberede opgaver på vegne af personen som har rollen. Figur 9: Stedfortræder for person med rollen Tillidsrepræsentant. En rollestedfortræder organisationfunktion udpeger altid personen med rollen som den første person og den/de person(er) som er ehndes stedfortræder derefter. Eksemplet i figur 7 viser at Kurt er stedfortræder for Kaj for rolleopgaven: Tillidsrepræsentant. Det er muligt at oprette flere rollestedfortrædere for samme person, på forskellige eller sammen rolleopgave. Dette bevirker at der skabes flere rollestedfortræder organisationfunktioner. Rollestedfortrædere indgår i kaskadeberegningerne for roller. 15

16 3.8 Opgave klassifikationer Opgave klassifikationer Der hvor det virkelig giver merværdi er når arbejdsgrupper opbygges og klassificeres vha. Form og/eller KLE. Dette er vist på Figur 10. Arbejdsgrupper kan navngives og kan udpege et arbejdssted. SFO og normal folkeskole uddannelse enheder har samme FORM. Det er også muligt at sætte FORM klassifikation klasser på mange af organisation domænets objekter direkte. Det gøres ved at bruge relationen Opgaver. Der kan f.eks. angives alle de FORM-koder en skole varetager. Ved at vedligeholde disse data i APOS2 bliver de tilgængelige for alle systemer som integrerer med APOS2. I telefonbogen kan man se hvilke opgaver afdelingerne / personer løser. Det giver også nye muligheder for selvbetjening som ud fra nogle få nøgleord vil kunne fremfinde web-adresse, og telefon på de afdelinger de skal i kontakt med. Da opgaver også kan angives på IT systemer vil det også være muligt at dirigere brugerne til de rigtige selvbetjeningsløsninger. Figur 10: Angivelse af arbejdsgrupper med FORM kode. Der er med andre ord ikke noget nyt i at opmærke enhed, lokationer, arbejdsgrupper, it-systemer, projekter osv. med FORM-koder. Brugen af denne nye viden skal være kendt af de systemer og procedurer som drager nytte af APOS2. Således vil man kunne opbygge 16

17 adgangsgrupper i AD ud fra hvilke arbejdsopgaver en enhed eller personer varetager. Det vil være muligt for en medarbejderportal at give personer adgang til relevante data ud fra en FORM opgave de arbejder med. 3.9 IT Systemer og brugere Ved at vedligeholde de IT-Systemer som bruges i kommunen, opnåes et overblik over hvilke organisationer, enheder og arbejdsgrupper som benytter hvilke systemer. Ved at markere FORM koder på IT Systemerne åbnes der for mulighed for automatisering af f.eks. adgangskontrol. Der er direkte relationer fra f.eks. en organisationenhed eller organisationfunktion til de IT-Systemer som disse stiller til rådighed for de personer som er tilknyttet. Personer har ikke en direkte binding til et IT-System, men kobles via objektet Bruger. Figur 11: Bruger binder personer og IT-systemer sammen. evt. ift. enhed. Det er typisk op til et Identity Manager system eller AD at oprette de brugerobjekter samtidigt med at der gives adgang til det pågældende system. De brugere som skal bruge en PC får automatisk angivet et bruger-id og vil i denne forbindelse også få oprettet et bruger objekt i APOS2. Personer som har ledelsesansvar kan f.eks. få automatisk adgang til løn-systemet og mange andre Bruger -relationer kan automatisk oprettes ud fra de arbejdsopgaver som personen skal arbejde med. Selv alle de systemer 17

18 som ikke kan laves automatiske oprettelser vil være kandidat til at blive vedligeholdt i APOS2. Dette vil give et centralt sted hvor information om hvilke systemer en person benytter vedligeholdes. Derved vil det være let f.eks. at nedlægge adgange når en person skifter afdeling, arbejdsopgaver eller stopper ved kommunen Kontaktkanaler I APOS2 benyttes objektet: KlassifikationKontaktkanal til at holde s, fax, fastnet, mobil, web og andre kontaktkanaler. Figur 12 viser hvorledes kontaktkanaler refereres fra hhv. lokation og engagement. Figur 12: Kontaktkanaler benyttes til at holde telefon numre, , web adresser, etc. Modelen kan fyldes med kontakt informationer på andre steder hvor der er en adresse fler relation, så som f.eks. en enhed. Dette kunne benyttes til at angive fælles kontaktkanaler for selv den logiske organisationsenhed. Ikke alle af disse relationer kan admini- 18

19 streres fra administrator GUI en AM/MED organisation APOS2 understøtter en AM/MED organisations type, hvilket betyder at personers tilknytning til organisationes enheder en anderledes en for den administrative organisation. På figuren herunder er sammenhængen imellem personer, enheden og opgave klassifikationerne illustreret. Figur 13: Datamodellen for AM/MED organisation Selve udvalgsstrukturen opbygges med organisationsenheder som alle andre organisationer. Disse enheder tilhøre blot en ny organisation som har typen AM/MED. Med- 19

20 lemmerne af udvalgene defineres vha. en organisationsfunktion. En eller 2 personer kan tilknyttes, hvor den første er medlemmet og den anden, som er valgfri, er supplianten. Medlemmets positionstype, valgperiode og fagforbund angives ved klasser fra klassifikationssystemet: AM/MED. Der er en del frihedsgrader mht. hvordan facetterne organiseres, dog kræver dette at tilhørende konfigurationsfiler opdateres. Fagforbund klasserne angiver hvilket hovedeforbund de tilhører. 4 Fremtidige modeller Objekterne, har i følge specifikationerne, langt flere relationer end dem som APOS2 benytter i den installation brugerne aktuelt har adgang til. Alle disse relationer er implementeret i kernesystemerne, og kan benyttes via de rå service funktioner. Det vil dog altid være nødvendigt at opbygge en model for hvordan organisation funktioner benyttes, klasser angives, mappes og fortolkes. Styrken ved Sag & Dokument objekterne er deres fleksibilitet, hvilket giver mulighed for at understøtte nye foretningsbehov uden ændring i den fysiske datamodel eller kernekomponenter. En stærk governance og åben adgang til kernesystemerne vil sikre interoperabilitet og besked baseret integrationer. Appendiks A Database schema APOS2 indeholder implementation af alle aspekter af standarderne, og for alle støttesystemerne. Dvs. for Organisation, Klassifikation, Arkiv, Dokument, Sag og den forkastede høringsversion af Part. Alle bygger på de samme database strukturer som repræsentere: Objekt med UUID Et objekts registreringer med bruger og tidspunkt Et objekts egenskabobjekter med virkningsinterval og evt. aktør og note Et objekts tilstandsobjekter med virkningsinterval og evt. aktør og note Et objekts relationer med virkningsinterval og evt. aktør og note Herunder vises fire strukture som gentages for alle objekter. De dækker database skemaer for: Objekt, Registrering og Egenskaber Objekt, Registrering og Tilstande 20

21 Objekt, Registrering og Relation Objekt, Registrering og Fler Relation Der hvor specifikationerne angiver at objekterne eller relationerne bære flere attributter vil databasetabellerne være udvidet til at kunne rumme disse. A.1 Egenskab Figur 14: Database skema struktur for egenskabsobjekter. A.2 Tilstand Figur 15: Database skema struktur for tilstandsobjekter. 21

22 A.3 Relation Figur 16: Database skema struktur for relationsobjekter. A.4 Fler relation Figur 17: Database skema struktur for flerrelationsobjekter. 22