APOS2 Implementations Guide

APOS2 Implementations Guide

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å: http://axapoint.com/ Dokumentet har til formål at beskrive, hvordan en projektstart kan forløbe samt hvilke data, der skal klargøres til dette. 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 - samt mellem forskellige ESDH-systemer. En standardiseret tilgang, til data i ESDH og fagsystemer, vil muliggøre automatisering af arbejdsgange internt i organisationer. Denne overdragelse af sager og dokumenter imellem organisationer vil lette udviklingen af selvbetjeningsløsninger. Målet er desuden, 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 et stort fokus på, at kunne understøtte den praktiske anvendelighed af standarderne i forhold til eksisterende og fremtidige ESDH- og fagsystemer. Dokumentation for Sag og Dokument findes her: http://digitaliser.dk/group/56264 Ud over disse primære mål, har Axapoint gennem sit arbejde med implementeringen i kommunerne identificeret, at et af de vigtiste områder for ethvert APOS2 projekt er integration med Identity Management (IDM). Frem for at lave fortløbende proprietære integrationer til licenstunge IDM systemer, har Axapoint valgt at opbygge en rammearkitekturbaseret IDM-løsning, baseret på en udvidelse af Apache Syncope (et open source IDM-system), så det passer ind i rammearkitekturen. 2

Scopet for hvilke data APOS2 indeholder, hvordan disse data vedligeholdes samt hvilke integrationer der skal understøttes varierer meget fra kommune til kommune. Der kan både være store organisationer, som har fokus på få data, og f.eks. mindre kommuner med et meget detaljeret fokus på data samt mange integrationer. Det er altid muligt at ændre scope, og APOS2 udvikles løbende med endnu flere muligheder, som løbende stilles til rådighed for alle kunder. Versioner Version Dato Beskrivelse 1.0.0 23/04/2013 Initial version 1.0.1 28/04/2013 Gennemrettet 1.0.2 01/05/2013 Opdatereret og rettet mht. IDM Tabel 1: Dokuments historik 3

Indhold 1 Hvad indeholder et APOS2 projekt? 5 2 Tidsplan? 8 3 Server setup, internt eller som hostet løsning? 8 4 Hvilke data skal benyttes? 9 5 Hvordan vedligeholdes data? 10 6 Hvilke systemer skal/kan integreres? 11 7 Hvordan benyttes data i forhold til sikkerhed? 11 A Data om Organisationen 13 B Data om Personer 14 C Data om Medarbejdere 14 D Data om Ledere 14 E Data om IT-Systemer og Brugere 15 F Data om lokationer 15 G Data om Adresser 16 Indholdsfortegnelse 4

1 Hvad indeholder et APOS2 projekt? Hovedformålet med et APOS2 projekt er, at få styr på stamdata, og gøre disse autoritative og tilgængelige. Helt grundlæggende er der således en opstartsfase, hvor data indsamles og indlæses i APOS2. Samtidig udarbejdes en listning af de integrationer, som skal virke, for at data kan gøre gavn i aftagersystemerne. Organisationen skal tilrettelægge de processer, som er nødvendige for, at data i APOS2 bliver vedligeholdt. Det er vigtigt, at APOS2 forankres som mere end blot endnu et IT projekt, da det skal indeholde autoritative organisations- og klassifikationsdata, som de øvrige IT systemer bør benytte. Der skal besluttes hvordan APOS2-softwaren skal benyttes. Skal det evt. være i form af en hostet løsning, hvor en tredjepart står for drift og applikationsovervågning, eller ønsker kunden selv at varetage dette internt. APOS2 kan leveres som begge løsninger. Det er altid muligt at flytte APOS2 driften fra sit driftsmiljø. Det er derfor muligt at komme hurtigt igang, ved at benytte en hostet løsning, som kan leveres af Axapoint - og derefter overgå til et andet setup senere. Opstarten af et APOS2 projekt sker ofte ved, at der laves et forprojekt. Forprojektet sikrer, via et par workshops, at der indhentes data og udarbejdes en oversigt over de integrationer, der skal være på plads ved idriftsætning. Data kan fra kundens side leveres som udtræk fra eksisterende systemer: Løn, AD,... eller som regneark med informationer, der allerede vedligeholdes i organisationen eller oprettes i forbindelse med APOS2 projektet. Forprojektet vil således kunne afdække behovet og placeringen af ansvaret for APOS2 - samt fastlægge de processer, der enten skal forbedres eller opbygges. Erfaringen har vist, at afviklingen af workshops er en god arbejdsmetode frem mod en hurtig og effektiv afprøvning af APOS2. Der etableres en opbygning af viden om produktet i kundens organisation, der skal underbygge beslutninger og aflive antagelser om funktionalitet. Samtidigt sker der en modning af kvaliteten af de data som APOS2 skal vedligeholde. Flowet af data i et typisk APOS2 setup er vist på figur 2 (a) initialisering og (b) vedligeholdelse af data. 5

Figur 1: (a) Initial dataload. (b) Dataflow under drift. APOS2 bygger på en komplet implementation af rammearkitekturens specifikation af organisation og klassifikation. Disse er så fleksible og omfangsrige, at de kan understøtte mange datamodeller. APOS2 definerer de datamodeller, som benyttes af alle kunderne idag, lige fra en mindre kommune som Gribskov og op til Københavns Kommune. I forbindelse med implementeringen af APOS2, kan der startes med en delmængde af data, da mulighederne for senere at registrere flere data kan tilføjes i takt med, at disse bliver besluttet og gjort tilgængelige. Som udgangspunkt skal der ikke bruges ressourcer på at vedligeholde data som ikke benyttes. De store offentlige klassifikationsystemer: KLE og FORM kommer med APOS2 og kan benyttes til at opmærke organisationsenhederne med. Som udgangspunkt skal data om personer og deres ansættelsesforhold loades samt de kontaktinformationer, der kendes for ansættelser og enheder. Der kan dannes andre organisationer, f.eks. via Silkeborg Data s SD Løn organisation, hvor der eksisterer nogle dybe integrationer til, samt AM/MED organisation og afledte organisationer på baggrund af roller. Efter at data er loadet i APOS2, skal det vedligeholdes. Normalt er der 2 områder, som varetages af seperate roller. Den ene rolle varetager ændringer af organisationerne og de data som tilhører disse, dvs. hierakierne og hvilke lederroller og andre roller, der benyttes i organisationen. Den samme administrationsgruppe vil også typisk varetage klassifikationer, som f.eks. ledertyper, ansvar, jobfunktioner, opgaver og hvordan opgaver mapper mod f.eks. KLE. Det data som vedligeholdes af denne gruppe ændres ikke så ofte, og det er med tidsstyringen (bitemporalitet) i APOS2 muligt, at kundens medarbejdere kan lave disse ændringerne frem i tiden. Dermed kan organisationsændringer planlægges og implementeres i god tid, så ændringerne kører automatiseret, når de skal aktiveres. Antallet af personer, som skal varetage disse ændringer, vil således være få, så ressourcer 6

kan frigøres til andet. Den anden type af administratorer skal varetage personers engagementer (ansættelser), hvilke teams personerne er tilknyttet, hvilke lokationer engagementerne tilhører, og hvordan engagementerne er relateret til IT-Systemer i form af brugerobjekter. Der er en række af muligheder for, hvordan disse administratorer kan udføre deres opgaver. Dette kan ske både direkte i APOS2 administrations brugerfladen / GUI en - eller som en integreret del af eksisterende processer. En stor del af et APOS2 projekt er forandringsbaseret og sigter mod procesoptimering. Hvilke eksisterende processer skal APOS2 indgå i? Hvordan kan eksisterende processer forbedres? Hvem har ansvar for data - og hvilke - i forhold til organisationen? Ved at data bliver samlet og udstillet ved hjælp af standarderne, giver dette mulighed for, at lave automatiske opdateringer af systemer, som er aftager af organisations- og klassifikationsdata - systemer som i dag forventer, at disse data måske leveres af AD et eller vedligeholdes manuelt i selve systemet. En af de klare fordele, der kan opnås efter et succefuld APOS2 projekt, er den løbende udførelse af projekter, som automatiser datavedligehold i en lang række af øvrige systemer og afdelinger, der i dag selv bruger ressourcer på at vedligeholde disse data i lokalt udviklede systemer. En stor del af værdien i Business casen for et APOS2 projekt er således summen af alle de efterfølgende optimeringer, som det er muligt at gennemføre i kommunen, ved at der er styr på grunddata: Fælles billede af organisationen og terminologier: mindre koordinering og færre misforståelser. Oversigt over ledere og deres ansvar: erfaringsmæssigt kan antallet af ledere ofte mindskes. Korrekte data til medarbejderinformationer på intranettet: viser hvem der arbejder med de samme opgaver?, hvem er lederen? hvem har rollen? Korrekte adresse- og kontaktinformationer: effektiviserer og forbedrer kommunikationen. Korrekte data til IDM, som derved ud fra regler kan opbygge: fællesdrev, mailinglister og adgangsgrupper til de forskellige systemer. Integrationer til systemer: skaber automatiserede flows og sparer manuelle processer. Udvikling af MOX agenter til process optimeringer: uafhængige af proprietære systemer/fremtidssikre En APOS2 kunde udtrykte dette om udarbejdelsen af business casen for projektet: Businesscasen er så stor, at ingen leder reelt ønsker at kende den, da det udstiller ineffektiviteten og omkostningerne forbundet med håndteringen af den nuværende organisations vedligehold. 7

2 Tidsplan? Et APOS2 projekt er et konsoliderings og forandringsprojekt, der skaber procesoptimeringer. Data som vedligeholdes forskellige steder, eller mangler et autoritativt hjem, konsolideres i APOS2. Procedurerne omkring data vedligeholdelse og brug i andre systemer optimeres og ensrettes. Automatiske integrationer udvikles og implementeres til de systemer, hvor det vurderes at være essentielt. Figur 2: Illustration over faserne i et projekt. En af styrkerne ved APOS2 er hastigheden hvormed data kan indlæses og vises til projektet. Derfor er det også en god forudsætning, at der inden den første workshop laves et load af de data, som er let tilgængelige i organisationen. Dette giver et konkret udgangspunkt for arbejdet og en demo-platform for projektet, som kan benyttes til at illustrere værdi og fremdrift over for en styregruppe. Efter at APOS2 er sat i drift, vil det løbende være muligt at lave flere systemintegrationer, oprette nye datamønstre - i form af roller, organisationer og klassifikationer samt udnytter disse grunddata i IDM-sammenhæng. 3 Server setup, internt eller som hostet løsning? Der er to modeller for etableringen af et APOS2 server setup. Den ene er, at kunden selv leverer server fra deres egen driftleverandør. Den anden, at Axapoint leverer en hostet løsning fra sin driftleverandør. Når Axapoint står for driftansvaret, kan dette dække både support til platformen, forbindelser og setup, samt overvågning af APOS2 applikationerne. Hvis kunden vælger et setup med egen driftleverandør, så varetager denne normalt kun supporten af server og netværkstjenester. Overvågningen af APOS2 bliver enten ikke udført - eller kan alternativt varetages af Axapoint. Det er muligt at komme hurtigt igang, ved at lade Axapoint levere en server med APOS2 applikationer klar til brug. Det vil således i løbet af 1-2 dage være muligt at benytte APOS2 i forbindelse med f.eks. afholdelsen af workshops. Dette hostede setup kan så senere overføres til den endelige model - alt efter kundeønske. 8

Det anbefaldede setup til APOS2 består af 3 servermiljøer. Produktion Versionen som skal benyttes til drift. Trial Versionen som skal benyttes til undervisning. Test Versionen som svarer til den nyeste version af APOS2. Axapoint kan tilbyde yderligere servermiljøer som f.eks.: Udviklingsmiljø, hvis der er mange integrationsprojekter, som kræver et særskilt miljø, der ikke følger den nyeste version af systemet - og et Stagingmiljø, i forbindelse med planlægning af f.eks. en større organisationsændring. Ressource Minimum Anbefalet CPU 2 kerner 3GHz 4 Kerner 3GHz Memory 8 GBytes 8GBytes Disk 500GB 500GBytes Tabel 2: Server specifikationer Axapoint kan understøtte både Linux og Windows som Operativsystem. APOS2 er et turnkey system, som kommer med database og applikationer samlet. Der skal således ikke udføres andet af kunden, end evt. at levere servere. Installation og opsætning, inkl. backup foretages af Axapoint. Det kræves, at Axapoint har VPN adgang til serveren og en domæne PC til testformål. Der skal benyttes 2 servere til at understøtte de 3 standardmiljøer: Produktion, Trial og Test. Den ene server vil kun køre Produktion, og den anden vil køre både Trial og Test. Generelt for APOS2 er, at det er tilstandløst. Dette bevirker, at det er let at skalere og at alle services i systemet altid er bagudkompatible. Undtaget er dog, hvis der er ændringer i standardens specifikationer, hvilket endnu ikke har være tilfældet i systemets levetid. Ved ændringer og udvidelser i standarden, vil der kunne forekomme migreringsarbejde og omkostninger i forbindelse med en eventuel opgradering af systemet. 4 Hvilke data skal benyttes? Der kan være store forskelle på, hvor meget data en kommune ønsker at starte med at registrere. Som minimum bør data om den administrative organisation, personers tilknytning som medarbejdere og ledere i denne organisation registreres. For hver enhed i organisationen, skal der angives én eller flere lokationer, hvor det er muligt at administrere adresser og kontaktkanaler. For medarbejdere er det også muligt at vedligeholde kontaktinformationer ift. telefon, email, etc. Når disse data er på plads kan udnyttelsen af APOS2 kontinuerligt udvides. APOS2 bliver løbende videreudviklet i samarbejde med 9

kunderne, og nye features stilles til rådighed for alle kunder, i takt med disses indførelse i versionerne. Der er i øjeblikket følgende ekstra muligheder i APOS2, som ikke antages udnyttet initielt: AM/MED organisation med udvalgsadministration Roller: Tillidsrepræsentant, IT-Godkender,... Opgave markering ift. KLE, FORM, Indrigsministeriets kontoplan SD Løn organisations data SD Løn medarbejder data ESDH organisation ud fra den administrative Økonomisystemets organisation ud fra den administrative Projektorganisationer For kommuner som har SD Løn, vil det være naturligt, at inkludere dette systems synrkoniseringer i de initielle integrationer. 5 Hvordan vedligeholdes data? Der er 3 hovedeområder af data, som skal vedligeholdes: 1. Vedligeholdelse af klassifikationer. Dvs. engagement typer, stillinger/job ansvar, leder betegnelser og ansvar, opgaver og mapninger af opgaverne til KLE, FORM... 2. Vedligeholdelse af organisationen. Dvs. hierakiet, enhedernes lokations data, som f.eks. kontaktkanaler og adresser samt leder grupper for enhederne. 3. Vedligeholdelse af medarbejderne. Dvs. ansættelser, fratrædelser, flytninger og hvem som er ledere. Hyppigheden hvormed data forandres stiger fra 1 til 3. Ændringer i klassifikationer er få og sjældne. Ændringerne i organisationen er moderate og planlægges i små, mellem og store organisationsomlægninger. Der vil løbende være små ændringer ifm. at enheder ændrer navn, nye enheder som f.eks. skoler, der opretter underenheder for SFO, klubber, ændringer til kontaktkanaler og hvilke opgaver, der udføres hvor i organisationen. Ændringerne ift. medarbejderne er mange og udføres ofte. Ud over ansættelse, fratrædelser og flytninger, så er det også vedligeholdelse af kontaktinformationer. Det vil typisk være personer med en lederfunktion, som står for medarbejderregistreringer for deres egen del af organisationen. Medarbejderens egne kontaktkanaler er det muligt for den enkelte medarbejder selv at holde opdateret. 10

Kommuner, som har SD Løn, kan drage fordel af integrationen imellem dette system og APOS2. Vedligeholdelse af medarbejdere udføres så igennem SD Løn s brugerflader og oprettes automatisk i APOS2. Der er stadig ekstra data som kun vedligeholdes i APOS2, og som så efterfølgende skal opdateres - f.eks. kontaktkanaler og leder tilknytninger. Ved hjælp af sikkerhedsroller kan APOS2 administrationsbrugerfladen konfigureres således, at de nævnte administratoropdelinger afgrænses, så man kun kan vedligeholde de data, som man er ansvarlig for. 6 Hvilke systemer skal/kan integreres? De typiske integrationer som indgår i et APOS2 implementeringsprojekt er: Integration med Løn/Bruger administrationen Integration med eksisterende e-telefonbog Integration med intranettet Integration med kantine system Integration direkte med AD eller via et IDM system Integration til datawarehouse Der eksisterer web services og synkroniseringsfunktionalitet til de dominerende systemer på disse områder. For det meste er disse implementeret eller relativt lette at få oprettet. Modtagende systemer har adgang til en omfattende liste af services ud over alle standard OIO services. 7 Hvordan benyttes data i forhold til sikkerhed? Sikkerhed er enten blevet varetaget i hvert enkelt system eller via AD, som så også er blevet vedligeholdt manuelt. Sikkerhed er på samme måde som i alle andre støttesystemer: der er en opgave som det udfører, der kræver kendskab til organisationen og klassifikationer. En del IDM systemer er solgt på ideen om, at de er autoritative for disse data, og derfor skal være kilden for andre systemer for disse. Desværre har fundamentet for disse systemer sjældent kunnet leve op til ambitionen på grund af 2 ting: Systemerne har være lukkede og derfor krævet dyr konsulentbistand til at udvikle propritære services Fokus har været på det databehov som IDM har ift. access management - dvs. på Identiteten - hvilket betyder, at systemerne ikke kan modelere den måde organisatorisk grunddata naturligt hænger sammen. 11

Axapoint har tidligt erfaret, at rammearkitekturens data skal stilles til rådighed for system tilgangskontrol (access management), og gennem arbejdet med flere langvarige og komplekse integrationer med IDM leverandører, har dette kunnet vurderes op mod en simpel direkte integration til Active Directory (AD) - som er udført med et meget værdiskabende resultat for kunderne. Figur 3: En IDM som taler rammearkitekturens sprog. Eksempel på IDM setup. Målet for Axapoint s IDM-tilgang er blevet, at skabe en nær integration imellem data i rammearkitekturen og et IDM system, som har mange gode access management funktionaliteter. Dette udvikles oven på Apache Syncope. En af fordelene ved at benytte et eksisterende open source, og ikke licensbærende produkt er, at det åbner muligheden for manuelt at kunne administrere de undtagelser, som altid forekommer. Løsningen kan desuden bidrage yderligere til APOS2 med nye workflow-muligheder. Der er typisk alt for mange applikationsintegrationer, som fortolker adgangskontrol i forhold til data. Dette er ikke formålstjenligt, og har ikke noget med sikkerhed at gøre. Det er desuden ofte dyrt at få ændret hver gang foretningsbehovet skifter. APOS2 har en sikkerhedsmodel som udelukkende bygger på grupper i Active directory. At disse grupper så kun er opbygget på baggrund af data i APOS2 p.t. kan evt. ændres på et senere tidspunkt på baggrund af et ændret workflow. Dette illustrerer, hvorfor det er en dårlig ide, at basere sikkerhed på fortolkning af applikationsdata, da disse fortolkninger skifter. Ud fra data fra APOS2 er det muligt at skabe mange værdifulde data i et IDM. Så som: Fællesdrev for personer med samme arbejdestyper, opgaver, organisatorisk placering, eller lokation... Mailingslister for personer med samme arbejdestyper, opgaver, organisatorisk pla- 12

cering, eller lokation... Aktivering af workflows til automatisk at oprette bruger id er til AD, Uni-C, KMD,... Populere AD med kontaktinformationer og adresser, som giver let og korrekt adgang til disse via outlook. Mindske licensomkostninger til AD ved at forhindre nødvendigheden af, at holde fiktive identer i AD for personer, som ikke er rigtige IT-Brugere, f.eks. hvis de kun skal kunne have adgang til kommunens Intranet via NemID login. Det er IDM, som vha. AD, KMD, Uni-C, etc. er autoritativt for de bruger-identer, som disse systemer udsteder, og ved at kunne repræsentere objekterne: IT-System og Bruger fra rammearkitekturen kan disse formidles og bruges i en lang række nye muligheder. Måden dette nye IDM-støttesystem minimeres på, er ved at basere sig på organisationsgrunddata, og ved at kunne forstå det fælles sprog via standarden. Dette vil kunne danne præcedens, og vise vejen frem, for alle de andre systemer, som heller ikke er autoritative for: organisationsdata, klassifikationsdata, eller fortolkning af data som sikkerhed. Bilag Her følger en række eksempler på hvilke data, der skal indhentes til indlæsning i APOS2. Det vil være muligt at vedligeholde mange flere typer af data, men disse eksempler giver et afvejet billede af et typisk brugsscenario. Som det vil fremgå af tabellerne, så kan det være meget forskelligt, hvordan data er tilgængelige, og hvordan disse kan sammenstilles. Der er ikke én rigtig vej, men mange forskellige muligheder. Det er derfor også nødvendigt at løse dette ved hjælp af iterative processer. Målet er, at opnå sammenhængende grunddata, hvorfra overblik og fremadrettede muligheder kan realiseres. A Data om Organisationen De data som skal registreres for organisation, er navnet på enhederne, hvorledes hierakiet er opbygget, enhedernes type og evt. hvilke opgaver, der udføres af de enkelte enheder. I APOS2 er det muligt at opbygge flere organisationer. Det som er i fokus initielt, er at få opbygget den politisk bestemte administrative organisation. 13

Værdi Navn Overordnet Type Opgaver Beskrivelse Navnet på enheden Id eller navnet på den enhed, som ligger over denne Hvilken type enhed er det: Kommune, magistrat, afdeling, skole, team Hvilke opgaver (KLE, Kontoplan) udføres i denne hierakiske enhed B Data om Personer De data som skal registreres for personer er navn, CPR, og privatadresse. Værdi CPR Navn Adresse Beskrivelse Personens CPR nummer Personens navn - som fornavn, mellemnavn, efternavn og adreseringsnavn Personens privatadresse APOS2 har DPR integration, så personer automatisk kan indlæses ud fra et CPRopslag. C Data om Medarbejdere Medarbejdere er koblingen imellem en person og den/de enheder i organisationen som personen udfører funktioner for. Værdi Beskrivelse CPR Hvilke personer er medarbejdere Enhed Hvilken enhed er personen medarbejder i Stilling/funktion Hvilken titel/stilling eller jobfunktion varetager personen Type Er personen ansat, ekstern, frivillig,... Kontaktkanaler Hvilke emails, telefonnumre, EAN, osv. har personen som medarbejder D Data om Ledere I APOS2 er det at være leder, at udføre en lederfunktion ift. en organisatorisk enhed. Det er muligt, at opbygge disse lederfunktioner med forskellige navne, alt efter hvor i 14

hierakiet lederen udfører sin funktion. Der ligger således et arbejde i, at indhente data om leder og hvilke begreber, som benyttes i de forskellige domæner. Værdi Beskrivelse Navn Hvad kaldes ledertypen: Inspektør, Direktør, Daglig leder, Center chef, Faglig leder,... Betegnelse Det domæne-neutrale navn: Chef, Leder, Afdelings chef,... Ansvar Hvilket ansvar har lederen. Økonomi, Faglig, Personale. Det er muligt, at angive disse efter behov og mappe dem til FORM. Ved at gøre dem detaljerede forøges IDM s mulighed for, automatisk at oprette sikkerhedsgrupper og mailinglister. E Data om IT-Systemer og Brugere Data om IT-Systemer og hvilke Brugere der er tilknyttet kan beskrives i rammearkitekturen. Vedligeholdelsen af Brugerobjekterne sker i et tæt samspil med et IDM system, som er autoritativt for bruger credentials. Det er typisk IDM systemet, som definerer reglerne for f.eks. brugernavnene for de enkelte systemer, og evt. email adresser, initialer, hvilke IT-Systemer personen skal have adgang til og hvilke grupper brugerne indplaceres i. Til initialisering kan følgende data indlæses. Værdi Brugernavn IT-System Engagement ID Beskrivelse Bruger navnet ift. IT-Systemet Navn/ID for IT-Systemet ID for det engagement som Brugerobjektet tilhører F Data om lokationer En lokation er data, som forbinder en hierakisk enhed med de lokationer, hvor medarbejderne arbejder i den fysiske verden. Det er også lokationen, som har kontaktinformationerne, adresser, p-nummer,... Værdi Beskrivelse Navn Lokationens navn. Benyttes normalt kun når det er en bygning som alle kender navnet på: Rådhuset, Det gamle posthus,... P-nummer Produktionsnummeret for denne adresse ift. enheden. Kontaktkanaler Telefonnummer, email, www, intern post,... Personer Hvis en enhed har flere lokationer, så er det muligt at registrere hvilke personer, som normalt arbejder på hvilke lokationer. 15

G Data om Adresser I APOS2 er adresser BBR data, som kan synkroniseres automatisk. Det kræver at disse data stilles til rådighed, ellers kan Axapoint hente dem fra KOMBIT s BBR services. 16