INSTRUKTION TIL TILBUDSGIVER

Bilag 2.1 – Kravspecifikation

FLIS Genudbud

INSTRUKTION TIL TILBUDSGIVER

Nærværende bilag udgør Kravspecifikationen. Tilbudsgiver skal ikke udfylde nærværende bilag, men besvare bilaget ved at udfylde underbilag 2.2.A (Løsningsbeskrivelse) og underbilag 2.2.B (Krav- skema).

I nærværende bilag anvendes betegnelsen Leverandøren i stedet for Tilbudsgiver, uanset om der er tale om oplysninger eller krav, der skal opfyldes ved afgivelsen af tilbuddet.

Om underbilag til bilag 2

Bilag 2 (Leverancebeskrivelse) har følgende underbilag:

• Bilag 2.1 Kravspecifikation (inklusive potentielle videreudviklingsopgaver)

• Bilag 2.2 Forklæde til Løsningsbeskrivelse

o Bilag 2.2.A Løsningsbeskrivelse

o Bilag 2.2.B Kravskema

• Bilag 2.3 Eksisterende dokumentation

Om nærværende bilag (Kravspecifikationen)

Nærværende bilag med tilhørende Underbilag udgør Kravspecifikationen. Kravspecifikationen er inddelt i flere sektioner og indeholder Minimumskrav, Krav og Optioner efter følgende systematik:

Krav kategori	Beskrivelse
Minimumskrav (MK)	Minimumskrav er et Krav (se nedenfor), der uforbeholdent skal opfyldes af Leverandøren. Opfyldes et Minimumskrav ikke, vil tilbuddet blive anset som ukonditionsmæssigt, og tilbuddet vil ikke blive taget i betragtning. Minimumskrav er forbeholdt de egenskaber i Systemet, som er fundamen- talt afgørende for, om Systemet kan anvendes.
Krav (K)	Kategorien Krav, er KOMBITs krav til Systemet, som Leverandøren kan, men ikke skal, opfylde.
Option (O)	Kravspecifikationen indeholder en række Optioner. Alle Optioner er angi- vet som et Krav i Kravspecifikationen. Alle Optionerne er Minimumsoptio- ner. Det betyder, at Leverandørens tilbud ikke vil være konditionsmæs- sigt, hvis ikke alle Optioner tilbydes. KOMBIT kan vælge at indfri Optionerne, men er ikke forpligtiget hertil.

Uanset om udtrykket "skal" er brugt i beskrivelsen af et Krav, skal det ikke opfattes som et Minimums- krav. Det er således kun manglende opfyldelse af Krav anført som minimumskrav, der medfører ukon- ditionsmæssighed.

Krav og kravkategorier i Kravspecifikationen

Alle krav er i Kravspecifikationen angivet ved et unikt fortløbende nummer:

Krav # # Navn (unikt nummer samt et navn for kravet)
Kategori:	Kategori er en angi- velse af, om kravet er: • Minimumskrav, for- kortet ”MK” (opfyl- des et minimums- krav ikke, er tilbud- det ikke konditions- mæssigt) • Krav, forkortet ”K” • Option, forkortet ”O”	Type:	Type er en inddeling af kravet i følgende områ- der: • Funktionelt krav (forretningskrav). • Ikke funktionelle krav (løsningsorienterede krav).
Beskrivelse:	Beskrivelse indeholder en tekstuel beskrivelse af kravet.

Der henvises i øvrigt til udbudsbetingelserne.

Besvarelse af Kravspecifikationen

Leverandørens besvarelse af Kravspecifikationen skal ske gennem udfyldelsen af Løsningsbeskrivel- sen i Bilag 2.1.A og Kravskemaet i bilag 2.1.B.

Vejledning til udfyldelse af Kravskemaet findes nedenfor, mens vejledningen til udfyldelse af Løsning- beskrivelsen fremgår af Bilag 2.1.A - Løsningsbeskrivelse.

Besvarelse af Kravskemaet

Kravskemaet er de samlede Minimumskrav, Krav og Optioner fra Kravspecifikationen. Leverandøren skal i Kravskemaet markere Systemets opfyldelse af ovenstående. Dette gør Leverandøren ved for hver kravkategori i Kravskemaet svarende til nedenstående tabel 1, at angive, i hvilket omfang det er opfyldt.

Kravnummer	Titel	Kravkategori	Helt opfyldt	Delvist opfyldt	Xxxx opfyldt	Kommentar	Leveran- dørens reference til Løs- ningsbe- skrivel- sen
1	Titel	K
2	Titel	O
3	Titel	MK

Tabel 1: Kravskema

Følgende retningslinjer gælder ved udfyldelse af Kravskemaet:

1. Kan Leverandøren og dennes Løsningsbeskrivelse imødekomme den pågældende kravkategori (Krav eller Option), angives ”Helt opfyldt”.

2. Kan Leverandøren og dennes Løsningsbeskrivelse delvis imødekomme den pågældende kravkate- gori, angives ”Delvist opfyldt”. Angives ”Delvist opfyldt”, skal Leverandøren i kommentarfeltet specifi- cere, hvorfor kravkategoriens opfyldelse kun er delvis.

3. Kan Leverandøren ikke imødekomme den pågældende kravkategori, angives ”Ikke opfyldt”. Angives ”Ikke opfyldt”, er kommentarer ikke nødvendige.

4. Hvis Leverandøren i en kommentar foretager konkrete referencer til andre bilag, skal referencen være konkret og nem at finde.

5. Det er ikke muligt at angive eller kommentere Minimumskrav, og manglende opfyldelse af disse vil medføre, at tilbuddet ikke er konditionsmæssigt jf. ovenfor og Udbudsbetingelserne. Minimumskrav er derfor også markeret gråt og kan ikke udfyldes.

6. Leverandøren må ikke ændre eller udfylde de med gråt markerede celler.

Vejledning til Løsningsbeskrivelserne

Løsningsbeskrivelsen er Leverandørens beskrivelse af den tilbudte Løsning og en beskrivelse af, hvor- dan KOMBITs Kravspecifikation vil blive opfyldt. Løsningsbeskrivelsen skal foretages i Bilag 2.1.A - Løsningsbeskrivelse. I Løsningsbeskrivelsen beskriver Leverandøren, hvordan Leverandøren imøde- kommer de specifikke Forretningsbehov og Krav, KOMBIT har angivet i Kravspecifikationen.

Ønsker Leverandøren at vedlægge dokumenter til Løsningsbeskrivelsen, bør disse angives som under- bilag med fortløbende nummerering, og der skal i Løsningsbeskrivelsen refereres til relevante underbi- lag. Referencen skal være konkret, afgrænset og nem at finde med sidetal og afsnitsnummer/overskrift. Er den ikke det, ignoreres referencen i tilbudsvurderingen.

Særligt om Optioner

Kravspecifikationen indeholder en række Optioner. Alle Optionerne er minimumsoptioner. Det betyder, at Leverandørens tilbud ikke vil være konditionsmæssigt, hvis ikke alle Optioner tilbydes. Dertil kommer, at selve opfyldelsen af Optionerne vil indgå som konkurrenceparametre i forhold til tilbudsvurderingen og i forhold til relevante underkriterier til tildelingskriteriet ”det økonomisk mest fordelagtige tilbud”, jf. Udbudsbetingelserne.

Leverandøren behøver i henhold til ovenstående ikke at opfylde alle beskrevne elementer i en Option, for at Tilbudsgivers tilbud er konditionsmæssigt, da de vil indgå i tilbudsvurderingen.

For Optioner gælder, at Leverandøren særskilt skal prisfastsætte hver enkel Option, der afgives tilbud på. Prisen skal omfatte omkostninger til alle elementer, der er nødvendige for pågældende Options anvendelighed for KOMBIT. Priserne skal fremgå af Bilag 5 (Priser og Betalingsplan) og Bilag 7.2.B (Priser og Betalingsplan).

INDHOLDSFORTEGNELSE

1 Indledning 7

1.1 Kravspecifikationens indhold 7

1.2 Underbilag 7

2 Baggrund, succeskriterier og forretningsbehov 8

2.1 Baggrund og formål 8

2.1.1 Baggrund og formål med Systemet 8

2.1. Nye målsætninger og indsatser 9

2.1.2 Indsatsområder 9

2.2 Brugere af Systemet 12

2.2.1 Brugerinvolvering 12

3 Aktører og kontekst 14

3.1 Kontekstdiagram 14

3.2 Brugeraktører 14

3.3 Systemaktører 17

4 System 22

4.1 Eksisterende system 22

4.1.1 Teknisk infrastruktur. 22

4.1.2 Arkitektur 23

4.1.3 Integrationer 25

4.1.4 Fysisk datamodel 28

4.1.5 Logisk datamodel 28

4.1.6 Regler/forretningslogik 29

4.1.7 Brugergrænseflade 29

4.1.8 Sikkerhed 29

4.1.9 Lovmæssige krav 33

4.1.10 Logning 35

4.1.11 Dokumentation 39

4.2 Udfasede krav 39

4.2.1 Teknisk infrastruktur. 39

4.2.2 Arkitektur 39

4.2.3 Integrationer 39

4.2.4 Regler/forretningslogik 40

4.2.5 Brugergrænseflade 40

4.2.6 Sikkerhed 41

4.2.7 Metadata management 41

4.3 Nye krav 42

4.3.1 Teknisk infrastruktur. 42

4.3.2 Arkitektur 48

4.3.3 Integrationer 48

4.3.4 Fysisk datamodel 58

4.3.5 Logisk datamodel 58

4.3.6 Regler / forretningslogik 58

4.3.7 Brugergrænseflade 58

4.3.8 Sikkerhed 59

4.3.9 Lovmæssige krav 60

4.3.10 Logning 60

4.3.11 Dokumentation 60

4.3.12 Driftsafvikling. 60

5 Forventninger til leveranceforløbet og roadmap 62

5.1 Det overordnede leveranceforløb 62

5.2 KOMBITs forventninger til leveranceforløb 63

1 Indledning

Dette bilag er Bilag 2.1 - Kravspecifikation, som med tilhørende underbilag er KOMBITs Kravspecifika- tion af Systemet, og udgør i sammenhæng med Bilag 2.2.A (Løsningsbeskrivelse) og Bilag 2.1.B (Krav- skema), den samlede Leverancebeskrivelse.

Leverandøren skal ikke udfylde dette bilag, men besvare bilaget gennem udfyldelse af Bilag 2.2.A (Løs- ningsbeskrivelse) og Bilag 2.1.B (Kravskema).

1.1 Kravspecifikationens indhold

Kravspecifikationen indeholder en detaljeret beskrivelse af, hvordan de bilaget opstillede krav til Syste- met skal forstås.

• Kapitel 1 er en kort beskrivelse af indholdet i Bilag 2.1 (Kravspecifikation) og tilhørende bilag.

• Kapitel 2 beskriver baggrunden for Systemet samt vision og mål for Systemet. Kapitlet skal betragtes som baggrundsviden.

• Kapitel 3 beskriver aktører og kontekst.

• Kapitel 4 beskriver krav fra det eksisterende System, der indgår i genudbuddet af Systemet, udfa- sede krav samt nye krav som danner baggrund for genudbud af Systemet.

• Kapitel 5 beskriver KOMBITs forventninger til leveranceforløbet.

Kravspecifikationen er udformet med vekslende tekstuel beskrivelse af de relevante behov og krav.

1.2 Underbilag

I bilaget henvises blandt andet til materiale i form af kilder og underbilag. I Bilag 2.1.C (Nuværende dokumentation) er alle underbilag listet.

2 Baggrund, succeskriterier og forretningsbehov

Dette afsnit giver et indblik i Systemet, herunder baggrunden samt videre strategi for Systemet. Til sidst introduceres succeskriterier og forretningsbehov.

Formålet med afsnittet er at give Leverandøren en overordnet forståelse af, hvad KOMBIT ønsker at opnå med Systemet.

2.1 Baggrund og formål

2.1.1 Baggrund og formål med Systemet

Systemet er tænkt som en benchmarking- og ledelsesinformationsløsning, der stilles til rådighed for kommunerne. I dag anvender kommunerne Systemets nøgletal og rapporter til benchmarking og som ledelsesinformation, eller de anvender data fra Systemet i deres egne ledelsesinformationssystemer. Herudover anvender KL nøgletal fra Systemet til at foretage en sammenligning af kommunerne i forbin- delse med deres interessevaretagelse.

Det, der gør Systemet unikt i forhold til andre offentlige databaser med nøgletal, er, at kommunerne i Systemet har mulighed for at verificere samt analysere datagrundlaget bag de frembragte nøgletal, idet de kan nedbrydes til individ/transaktionsniveau.

Systemet blev påbegyndt i 2011, i hovedkontrakten for Systemet fremgik det, at der som det første skulle udstilles data fra 7 dataområder:

Tværgående områder:

- Borger

- Økonomi

- Personale/Fravær

Fagområder:

- Skole

- Ældre

- Voksenhandicappede

- Udsatte Børn og Unge

Hovedkontrakten blev opfyldt ultimo 2014, hvor data fra alle 7 områder var integreret i Systemet. For disse dataområder er der udarbejdet ca. 1.100 nøgletal og 60 standardrapporter, herudover er der ud- arbejdet Dataanalyse- og Kontrolrapporter (DAK-rapporter) på hvert dataområde, der hjælper kommu- nen med at foretage datavalidering i forhold til deres fagsystemer.

For at understøtte kommunernes forskellige behov for både at kunne tilgå rådata og forarbejdede data består Systemet af tre elementer – en datainfrastruktur, et datawarehouse og en portal.

Kommunerne anvender fortrinsvis Systemet på følgende to måder:

1. Kommuner, der har et lokalt ledelsesinformationssystem, henter data - rådata og nøgletalsdata fra Systemet –– som overføres til kommunens lokale ledelsesinformationssystemer eller GIS løsninger, men det kan også være andre præsentationsværktøjer og apps.

2. Kommuner, der ikke har et lokalt ledelsesinformationssystem, anvender Systemets præsentationslag, hvori der kan udføres benchmarking, dataanalyser samt trækkes og udvikles rapporter.

Efter at hovedkontrakten for Systemet var opfyldt ultimo 2014, besluttede KL og KOMBIT i 2015, bl.a. initieret af dialog med flere kommuner, at iværksætte et strategiarbejde, der skulle udstikke rammerne for en strategisk videreudvikling af Systemet og dets fortsatte drift.

Systemet bevæger sig nu ind i en ny fase, hvor der er nye behov der skal understøttes. Dette falder naturligt sammen med at Systemet skal i genudbud. Ved genudbuddet, vil det være muligt at adressere de krav der er til en videreudvikling af systemet i forhold til de nye målsætninger for Systemet.

2.1. Nye målsætninger og indsatser

Strategien ”Nye målsætninger og indsatser i FLIS” baserer sig på de krav og ønsker, der er fremkommet hos kommunerne, KL og KOMBIT i løbet af Systemets første år og beskriver en række indsatsområder.

2.1.2 Indsatsområder

De tekniske indsatsområderne fra strategien beskrives i det følgende.

2.1.2.1 Nye dataområder i Systemet

Systemet skal udvides med fire nye dataområder. Det forventes, at de kommende dataområder bliver Sundhed og Beskæftigelse, mens de efterfølgende to områder endnu ikke er besluttet.

Ved integration af et nyt dataområde i Systemet, etableres der snitflader til de relevante fagsystemer og registre, der er identificeret at indeholde data til understøttelse af relevante nøgletal til benchmarking samt rådata til dataudlæsning til kommunens øvrige formål. Data danner baggrund for en ny Datamart, som både skal levere de nødvendige elementer til dannelse af nøgletal, og til at give den ønskede sporbarhed fra nøgletal til kommunens detaljerede fagdata.

2.1.2.2 Udfasning af præsentationslaget

Oprindeligt blev præsentationslaget til Systemet etableret som en tilvalgsmulighed, fordi der ikke var tilstrækkelig udbredelse og markedsunderstøttelse af sådanne værktøjer. Siden er der sket en rivende udvikling inden for forskelligartede portalløsninger. Der ønskes derfor en højere grad af valgfrihed i forhold til portalløsninger, og en del kommuner har allerede udskiftet FLIS-portalen med en anden por- talløsning.

Mange kommuner har fortsat stor nytte af FLIS-portalen, men kommunernes differentierede udviklings- ønsker tydeliggør udfordringerne ved at lave én fælles portalløsning, der kan tilfredsstille alles behov. Der er således risiko for at præsentationslaget er for avanceret, således at mange kommuner betaler for mere end de ønsker, eller at det bliver for simpelt og dermed kun dækker få kommuners behov.

Det er derfor ultimo 2015 besluttet, at FLIS-portalen udfases fra og med 1. januar 2018. Udfasningspe- rioden på 24 måneder er fastsat, så det er muligt for kommunerne at finde en anden løsning i forhold til præsentation af data fra Systemet. Portalen er kommunernes ejendom og vil kunne overdrages, hvis en eller flere kommuner i fællesskab ønsker at videreføre den.

Dele af funktionaliteten fra FLIS-portalen videreføres som en administrationsportal med dokumentation, databestillinger, samt en begrænset rapporteringsfunktionalitet, der underunderstøtter Dataanalyse og Kontrolrapporter til datavalidering.

2.1.2.3 Koblede data

Der findes allerede et stort datagrundlag i Systemet og med introduktionen af nye dataområder udvides dette. Det giver mulighed for at konstruere nye koblede nøgletal på tværs af serviceområder, der øger kommunernes mulighed for at analysere sammenhænge og effekter. De koblede nøgletal vil oftest blive

konstrueret ud fra det eksisterende datagrundlag i Systemet, men det kan også komme på tale at kon- struere koblede nøgletal på bagrund af data fra eksterne datakilder og registre, fx vedr. kriminalitet, indkomst, skat mv.

Der er mulighed for mange interessante datakoblinger i Systemet, der yderligere skal identificeres og analyseres. Nedenfor ses en principskitse over de muligheder, der fx er for dataområdet Udsatte Børn og Unge.

Figur 1: Eksempel på koblede nøgletal

Der er pt. fremsat konkret ønske om, at der udarbejdes koblede nøgletal på Skole- samt Udsatte Børn og Unge-området.

2.1.2.4 Styrkelse af datainfrastruktur

Siden Systemet blev etableret er der flere kommuner der aktivt er begyndt at arbejde med ledelsesin- formation til løbende monitorering. For at kommunerne kan spare penge på datakøb og ressourcer på dataintegration, er det tænkt at Systemet skal agere som central dataleverandør for de områder der er integreret i Systemet. Det kræver, at de etablerede Snitflader i Systemet understøtter kommunernes behov for data på områderne, samt at data kan leveres med den hyppighed samt forarbejdning som kommunerne efterspørger.

2.1.2.4.1 Udvidelse af eksisterende snitflader og introduktion af nye snitflader

På Borger-, Økonomi-, Personale- og Skoleområderne er der allerede identificeret ønsker omkring flere data. I nogle tilfælde er der tale om begrænsede feltudvidelser af en eksisterende snitflade, mens der for andre er tale om helt nye snitflader, fx på Skoleområdet. På Ældre og Voksenhandicap-området er der en forventning om at udskifte den nuværende snitflade, der stilles til rådighed af Danmarks Statistik med snitflader direkte fra kommunernes fagsystemer, hvorved datagrundlaget øges. Samtidig sker der konstant en udvikling på markedet, hvor der skal åbnes snitflader til nye og tilpassede kommunale systemer.

2.1.2.4.2 Performanceopdatering

Infrastrukturen i Systemet skal styrkes gennem en række initiativer, der giver hurtigere og hyppigere adgang til de datatyper, som kommunerne efterspørger.

Det tilsigtes at nøgletalsdata indlæses og bliver tilgængelige tidligere på måneden. Systemet skal end- videre imødekomme kommunernes individuelle behov for data, hvor nogle kommuner har behov for daglig eller ugentlig rådata andre har behov for forarbejdede data fra DM- samt EDW-laget, til integra- tion i eget ledelsesinformationssystem.

2.1.2.4.3 Vision, Forretningsbehov og Succeskriterier for Systemet

Med disse indsatser som omdrejningspunkt for den videre udvikling er det visionen med Systemet at stille data, der kan styrke kommunernes beslutningsdygtighed og KL’s interessevaretagelse, til rådighed.

For at kunne realisere denne vision er der tre centrale forretningsbehov, som skal være på plads.

BREDDE: Systemet skal indeholde de data inden for de valgte dataområder, som under- støtter kommunernes behov

TILLID: Systemet skal med gennemsigtighed og kvalitet give brugerne tillid til de data, Systemet indeholder.

TILGÆNGELIGHED: Systemet skal stille data til rådighed i en form og på et tidspunkt, som svarer til brugernes behov.

For at operationalisere disse behov har projektet formuleret følgende succeskriterier for Systemet. Le- verandøren forventes aktivt at støtte KOMBIT i indfrielsen af succeskriterierne, dog således at KOMBIT alene har det formelle ansvar for at sikre indfrielsen.

Vision	Forret- ningsbehov	Succeskriterier
At stille data til rådighed der kan styrke kommunernes beslutnings- dygtighed og KLs interessevaretagelse.	BREDDE	S1	Kommunerne understøttes med relevante data, der understøtter relevante politiske dagsordener
		S2	Kommunerne kan anvende data i egne løsninger og sparer penge på datakøb og ressourcer på dataintegration i egne løs- ninger, idet der kun er én central leverandør af de data der er in- tegreret i Systemet
		S3	Kommunerne sparer ressourcer ved ikke selv at skulle indberette til øvrige myndigheder
		S4	Kommunerne får stillet nøgletal til rådighed
	TILLID	S5	Kommunerne har i data og dokumentation mulighed for at ned- bryde strategiske nøgletal til operationelle detaildata
		S6	Kommunerne har tillid til at data afspejler data i kildesystemerne
		S7	Systemet er veldokumenteret, velkonsolideret og sikkert
		S8	Kommunerne bliver opmærksomme på forskellig registrerings- praksis
	TILGÆNGELIGHED	S9	Kommunerne kan integrere data fra Systemet i deres egne løs- ninger
		S10	Kommunerne kan modtage data fra Datamarter samt udarbej- dede nøgletal for en måned senest d.15. i den efterfølgende må- ned
		S11	Kommunerne får leveret rådata dagligt eller ugentligt hvis de ef- terspørger det.
		S12	Systemet kan håndtere skift i det omgivende systemlandskab uden udfald

2.2 Brugere af Systemet

Systemet vil primært anvendes af den del af den kommunale forvaltning, der understøtter beslutnings- tagerne med relevant information. Den typiske bruger sidder centralt og tæt på beslutningstagerne, oftest i en økonomisk stabsenhed, og disse brugere vil almindeligvis anvende rapportering samt bench- marking data. I nogle kommuner er der allerede veludbyggede LIS systemer, og her vil brugerne pri- mært være databehandlere/LIS-medarbejdere, der tilgår rådata/DM data for en integration i eget LIS system eller i GIS-portal.

Brugerne af Systemet forventes at være følgende, som beskrevet i kapitel 3 (Aktører og kontekst):

• Controller / Analytiker / GIS- medarbejdere

• LIS-medarbejder

• Topleder/Beslutningstagere

2.2.1 Brugerinvolvering

Systemet skal understøtte kommunernes behov for ledelsesinformation. For at Systemet kan lykkes med dette er det nødvendigt, at kommunerne involveres i udviklingen af Systemet. Derfor lægges der betydelig vægt på den løbende involvering af kommunerne (slutbrugere) i udviklingen af Systemet. For

at sikre forankring og input til specificering og udvikling af Systemet er der oprettet tre kommunegrup- per:

XXXX Xxxxxxxxxxx: Består af økonomichefer og direktører samt kommunaldirektører fra 6 kommuner, KL og KOMBIT. Styregruppen har til formål at rådgive og beslutte, i hvilken retning Systemet skal udvikle sig i med fokus på de forretningsmæssige behov. Gruppen mødes 3-4 gange årligt.

FLIS Følgegruppe: Består af 10 kommunale medarbejdere fra udvalgte kommuner. Følgegruppen har til formål at deltage i tekniske afklaringer og foretage en prioritering af de ind- meldte ændringsanmodninger til Systemet samt overordnet at sikre, at Systemet tilpasses de kommunale behov. Følgegruppen mødes 2 gange årligt.

FLIS Faggruppe: Består af udvalgte kommunale medarbejdere, der bistår med at fastsætte hvilke dataområder der skal integreres i Systemet. Faggruppen har endvidere til formål at bistå med at definere nøgletal samt forretningsregler og begreber inden for det valgte dataområde. Faggruppen vil ligeledes have kompetence til at vurdere, om en forskelligartet praksis for registrering i kommunerne vil have betydning for mu- ligheden for benchmarking. Faggruppen har en midlertidig karakter og nedlægges, når det pågældende fagområde er færdigudviklet og valideret. Gruppen mødes efter behov.

Grupperne har til formål at hjælpe med at definere indhold og udvikling af Systemet, ligesom grupperne kan anvendes i forbindelse design, validering og test af løsningen.

Det forventes, at Leverandøren aktivt støtter anvendelsen af grupperne, herunder i væsentligt omfang planlægger dem anvendt i arbejdet med at udvikle Systemet.

3 Aktører og kontekst

Systemet indgår i et samspil med en række forskellige brugeraktører og systemaktører. De enkelte aktører er beskrevet i dette kapitel.

Aktørerne i løsningen er opdelt i:

• Brugeraktører, dvs. Xxxxxxx, der som personindivider interagerer med Systemet.

• Systemaktører/eksterne systemer, dvs. andre it-systemer, som interagerer med Systemet.

3.1 Kontekstdiagram

De forskellige Bruger- og Systemaktører er vist i nedenstående kontekstdiagrammer.

Figur 2: Overordnet kontekstdiagram for Bruger- og Systemaktører

3.2 Brugeraktører

Brugeraktørerne agerer med Systemet via FLIS-portalen, hvor brugerne anvender FLIS-portalen til ud- arbejde relevant ledelsesinformation til beslutningstagen, benchmarking, administrere brugerrettighe- der, bestille datapakker samt validere data. Når FLIS-portalen udfases 1. januar 2018, og overgår til at være en administrationsportal, jf. afsnit 2.1.2.2, vil brugerne alene anvende portalen til at tilgå relevant dokumentation, bestille datapakker samt tilgå Dataanalyse og Kontrolrapporter til datavalidering. Fra 1. januar 2018 og frem vil størstedelen af de nuværende brugeraktører derfor ikke længere skulle suppor- teres.

Figur 3: Brugeraktører

Navn	FLIS Brugere
Rolle	Kommunale medarbejdere der enten fremskaffer relevant ledelsesinformation til beslutningstagen eller som anvender Systemet til at understøtte beslut- ningstagen. Anvender oftest de faste rapporter med nøgletal eller integrerer data i GIS-kort til lokal benchmarking internt i kommunen. En kommunal FLIS brugere har kun adgang til sin egen kommunes portal.
Ansvar	• Fremskaffelse af tal til beslutningsstøtte • Anvendelse af data fra Systemet til beslutningsstøtte • Kan udarbejde egne dashboard og rapporter i kommunens egen portal • Udarbejder GIS-kort med data fra systemet til lokal benchmarking i kommu- nen. • Tilbagemelding til KOMBIT omkring nuværende og fremtidig anvendelse af Systemet • Deltagelse i brugerundersøgelser
Antal/kapacitet	Min. 1 pr. kommune

Navn	Lokaladministrator
Rolle	En kommunal medarbejder der varetager den tekniske opsætning af Systemet i kommunen. Lokaladministratoren arbejder oftest med ledelsesinformation. Lokaladministratoren har rettighed til alle funktioner, herunder administration og alle dataområder i kommunens egen portal.
Ansvar	• Kontaktperson i kommunen • Oprettelse af lokale kommunale brugere • Koordinering af kommunens ændringsønsker til Systemet • Superbruger på Systemet • Bestiller dataleverancer til kommunen, i det omfang kommunen ønsker det • Kan distribuere rapporter via e-mail • Dashboard og rapportudvikler • Sikrer indlæsning af eventuelle bemærkninger til kommunens nøgletal
Antal/kapacitet	Min. 1 i hver kommune

Navn	Dataadministrator
Rolle	Rollen tildeles til de kommuner, der ikke har tilkøbt portalen, men som allige- vel har behov for at kunne tilgå datakvalitetsrapporterne samt bestille datapak- ker. En dataadministrator har adgang til at se data fra alle områder for at kunne køre datakvalitetsrapporterne.
Ansvar	• Bestiller dataleverancer til kommunen i det omfang, kommunen ønsker det • Tilgår datakvalitetsrapporterne • Udvikler egne datakvalitetsrapporter
Antal/kapacitet	1-5 i hver kommune

Navn	Benchmarking/rapportdistributør
Rolle	Rollen ’Benchmarking – Rapportdistributør’ kan kun sende rapporter markeret som benchmarkingrapport.
Ansvar	Distribuerer rapporter markeret som benchmarking rapport via e-mail
Antal/kapacitet	Varierende

Navn	Supportbrugere
Rolle	Denne rolle varetages af KOMBIT og KL. Brugeren har status af lokaladmini- strator og har således fulde rettigheder til kommuneportalen. En supportbruger kan tilgå alle kommuners portaler. Supportbrugere kan tilgå vejledningssitet, men kan kun læse og ikke redigere indholdet her.
Ansvar	• Dashboard og rapportudvikler • Validerer data • Kontrollerer at data er valide samt forretningsregler er overholdt
Antal/kapacitet	3-5

Navn	Administrationsbrugere
Rolle	Denne rolle varetages af KOMBIT og KL. Administrationsbrugere har adgang til Administrationsportalen, med hvad det indebærer af muligheder for bl.a. rapport- og meddelelsesudrulning, kursusoprettelse m.v. Administrationsbru- gere har ydermere fulde rettigheder til at redigere vejledningssitet, og kan så- ledes oprette/slette/redigere sider, menuer og dokumenter her.
Ansvar	• Opdatere vejledning • Meddelelser til brugerne mv. på Administrationsportalen
Antal/kapacitet	3-5

Navn	KL - brugere
Rolle	Anvender nøgletal i den politiske dialog med regeringen. Har et overblik over de styringsmæssige behov i kommunerne. KL har deres egen portal, hvor de kan udføre benchmarking mellem kommunerne, men de kan ikke nedbryde data.
Ansvar	• Input til den faglige udvikling af områderne i Systemet • Forretningsmæssig vedligeholdelse af nøgletal og kontoplaner, for den poli- tiske interessevaretagelse samt medvirken i implementeringsaktiviteter • Uddannelse af brugere i FLIS-portalen
Antal/kapacitet	10-20

3.3 Systemaktører

Systemet har behov for at integrere til en række eksterne systemer for at kunne hente samt udstille data. Eksterne systemer, som kommunikerer med Systemet via Snitflader, betegnes som systemaktø- rer. Endvidere vil Systemet selv fungere som systemaktør i forbindelse med udstilling af Snitflader til eksterne systemer. Systemet vil i takt med introduktion af nye Dataområder få flere systemaktører, og Systemet vil levere data til andre aktører.

Figur 4: Systemaktører

Navn	KMD
Rolle	Leverandør der stiller Snitflader til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Løn- og Personale, Fravær, Økonomi, Elever samt Børn og Voksne.
Xxxxx/Kapacitet	7
Bemærkning	Beskrivelse af Snitflader forefindes i indeværende bilag afsnit 4.1.3

Navn	IBM
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Udsatte Børn og Unge.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	IBM
Rolle	Leverandør der får stillet Snitflade til rådighed for Systemet.
Ansvar	Systemet udstiller oplysninger om Økonomi
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	IST
Rolle	Leverandør der stiller Snitflader til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Elever.
Xxxxx/Kapacitet	2
Bemærkning	Beskrivelse af Snitflader forefindes i indeværende bilag afsnit 4.1.3

Navn	STAR
Rolle	Leverandør der får stillet Snitflade til rådighed fra Systemet.
Ansvar	Systemet udstiller oplysninger om Voksenhandicappede.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	Kommunerne
Rolle	Modtager af data fra Systemet.
Ansvar	Systemet udstiller rå-, DSA-, samt DM-data til rådighed.
Antal/Kapacitet	Min 100
Bemærkning	Kommunerne kan bestille datapakker indeholdende rådata, DSA eller DM data.

Navn	DST
Rolle	Leverandør der stiller Snitflader til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Omsorg, samt Voksenhandicappede.
Xxxxx/Kapacitet	2
Bemærkning	Beskrivelse af Snitflader forefindes i indeværende bilag afsnit 4.1.3

Navn	EG
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Økonomi.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	Fujitsu
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Økonomi.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	SBSYS
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Udsatte Børn og Unge.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	SilkeborgData
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Løn- og Personale samt Fravær
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	KOMBIT
Rolle	Leverandør der stiller referencedata til rådighed for Systemet.
Ansvar	Udstiller på flere områder, herunder Skole, Alder, Kommune, Fravær
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	Københavns Kommune
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Økonomi, Udsatte Børn og Unge samt Visitationer.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	CGI
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om Udsatte Børn og Unge samt Voksenhandicappede.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af Snitflade forefindes i indeværende bilag afsnit 4.1.3

Navn	CPR (via Samarbejdsplatformen)
Rolle	Leverandør der stiller Snitflade til rådighed for Systemet.
Ansvar	Udstiller oplysninger om CPR.
Antal/Kapacitet	1
Bemærkning	Beskrivelse af snitflade forefindes i indeværende bilag afsnit 4.1.3

4 System

Følgende kapitel 4 er inddelt i tre afsnit, i afsnit 4.1 foretages der en gennemgang af de væsentligste komponenter der skal genskabes ved en transition af Systemet til en ny platform. Afsnit 4.2 vil gen- nemgå de komponenter af det eksisterende system der udfases og i afsnit 4.2 er der fremsat nye krav til systemet.

4.1 Eksisterende system

Leverandøren skal genskabe funktionaliteten i det eksisterende system, hvilket vil sige, at der skal være en 1:1 overflytning af funktionaliteten fra det eksisterende system til det nye System. Leverandøren kan ved en transition af Systemet vælge en anden teknisk infrastruktur eller arkitektur af Systemet, men Systemet skal genskabes med den eksisterende funktionalitet.

1:1 overflytning af funktionalitet
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Systemet skal genskabes med samme funktionalitet som i det eksisterende sy- stem, eksklusiv udfasede krav jf. afsnit 4.2 samt inklusiv nye krav jf. afsnit 4.3.
Bemærkning:

Som hjælp til Tilbudsgiver er de vigtigste elementer af den eksisterende system kravstillet i det neden- stående.

4.1.1 Teknisk infrastruktur

I Bilag 7.3.C – Beskrivelse af Driftsmiljøet, er det beskrevet hvilke miljøer Leverandøren skal etablere systemet med, dette afviger fra det eksisterende driftsmiljø. Hvor det eksisterende System er etableret på fire logiske miljøer der håndterer:

• PROD - Produktion

• DEMO - Demonstration (udfaset)

• TEST – Test

• UDV – Udvikling

Jf. Bilag 7.3.C – Beskrivelse af Driftsmiljøet, erstattes disse miljøer af et nyt driftssetup for systemet.

Det eksisterende system er opbygget med standard komponenter, der kan skaleres op og ned efter behov, hvis der ønskes at regulere på Systemets kapacitet.

Platformen består af følgende services:

• Sikker filoverførsel sikker afsendelse og modtagelse af dataleverancer

• ETL dataintegration, integrationsprocesser

• Metadata management til understøttelse af Metadata management

• Relationel database til understøttelse af store mængder relationelle data, herunder Systemets data og repository databaser for software-værktøjer

• OLAP-database til opbevaring af OLAP forespørgsler

• OLAP-processering til processering af Datamarter til OLAP

• OLAP-forespørgsel til behandling af OLAP-forespørgsler

• OLAP-præsentation til præsentation af OLAP-data, herunder drilldown

• Rapport-præsentation til præsentation af Rapporter

• Dashboard-præsentation til aggregeret præsentation af OLAP og rapporter

I Underbilag 2.1.A.1 D0120 - Teknisk Infrastruktur Design findes en beskrivelse af Systemets tekniske infrastruktur. Systemet skal konfigureres med tilsvarende services, som der er beskrevet i bilaget. Hvis der er services der udgår vil det være beskrevet i indeværende bilag afsnit 4.2 vedr. udfasede krav. Leverandøren kan vælge at etablere de ønskede services på anden teknologi.

Teknisk Infrastruktur
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal etablere Systemet med tilsvarende logiske services, der er listet i Underbilag 2.1.A.1 D0120 - Teknisk Infrastruktur Design, øverst afsnit 2. Hvis der er nogle af de logiske services, der udgår, vil det være beskrevet i af- snittet vedr. udfasede krav.
Bemærkning:	Der henvises til indeværende bilag afsnit 4.2.1 vedr. udfasede krav.

Logiske miljøer
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal etablere Systemet på logiske miljøer svarende til driftssetup skitseret i Bilag 7.3.C – Beskrivelse af Driftsmiljøet.
Bemærkning:

Intern testmiljø
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Intern testmiljøet skal som minimum indeholde tidstro data fra 1 kommune.
Bemærkning:

Ekstern testmiljø
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Ekstern testmiljøet skal som minimum indeholde tidstro data fra 8 kommuner.
Bemærkning:

4.1.2 Arkitektur

Systemet etableres med en veldefineret og veldokumenteret arkitektur, hvor der er udstukket klare ret- ningslinjer og formål for den etablerede lagdeling.

I Bilag 2.1.A.4 D0150 - Softwarearkitektur findes en beskrivelse af den eksisterende datawarehouse arkitektur for Systemet.

Datawarehouse i Systemet består af fem lag:

• DSAHIST

• DSA (udfaset i Release 3.0)

• EDW

• Datamart

• Nøgletalsdatamart

Herunder er datawarehouse og dets lag illustreret i kontekst af kilderne og portalløsningen i Systemet.

Figur 5: Datawarehouse arkitektur for Systemet

De forskellige lag i datawarehouse har hvert sit formål og særlige funktionalitet, som er beskrevet i Underbilag 2.1.A.4 D0150 - Softwarearkitektur.

Hvis der er lag i den eksisterende arkitektur, der udgår, vil det være beskrevet i indeværende bilag afsnit 4.2.2 vedr. udfasede krav.

Arkitektur
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal etablere Systemet som en lagdelt datawarehouse arkitektur. Der skal være udstukket klare retningslinjer og formål for den etablerede lagde- ling. Arkitekturen skal være veldefineret og veldokumenteret. Systemets eksi- sterende datawarehouse arkitektur er beskrevet i Underbilag 2.1.A.4 D0150 - Softwarearkitektur, afsnit 4.1 og afsnit 4.2.
Bemærkning:	Der henvises til indeværende bilag afsnit 4.2.2 vedr. udfasede krav.

4.1.3 Integrationer

Det centrale element i Systemet er data. Systemet genererer ikke selv data, men samler og ensretter data. Systemet integrerer med et flere eksterne leverandører, hvorfra der modtages data.

Nedenstående tegning viser hvilke systemintegrationer, der er til Systemet. Hver kasse repræsenterer en dataleverandør. Flere af dataleverandørerne leverer data fra flere af deres systemer. De systemer, som dataleverandørerne leverer data fra, er listet under leverandørnavnet.

CGI

AS2007

IST

TEA

DST

Omsorg Ældre Voksne og Handicappede

Kbh's

Kommune

KØR

SilkeborgD

ata

SilkeborgLøn

CPR

CPR‐registeret

EG

ØS Indsigt

IBM

DUBU

Fujitsu

PRISME

KMD

KMD ØS

OPUS‐Økonomi KMD KLP

KMD ÅK Fravær KMD‐Elev

KMD Børn og voksne

OPUS‐Løn‐ og personale

Systemet

SBSYS

SBSYS

KOMBIT

Kommuner Nøgletal Nøgletalskommen tarer Aldersgruppering Fravær

Personale Skole

Udsatte børn og unge

IM's kontoplan Landekoder PLRegulering KL‐

Ressourceluppen KRL‐

Nomenklaturen Tid

Ældre Domænebegreber VoksneHandicapp ede

Dataområde Kommune Vurdering

Figur 6: Integrationer

Snitfladerne er defineret af KOMBIT i samarbejde med leverandøren af data. I nogle tilfælde er der blevet udviklet unikke Snitflader. I andre tilfælde har leverandøren en eksisterende Snitflade, som le- veres til Systemet. I de tilfælde leveres der ofte flere data, som ikke nødvendigvis skal anvendes i Systemet. De vil dog blive gemt i Systemet, og kommunerne vil kunne hente data via datapakker.

Der er dog det krav, at Snitfladen skal gøre det muligt at beregne de ønskede nøgletal.

Nogle Snitflader anvender en ren systemintegration og dermed leveres data direkte på KOMBITs FTP server. Data fra KOMBIT leveres manuelt; hvilket vil sige, at de uploades via det system, Leverandøren har stillet til rådighed for KOMBIT/KL til manuel oplæsning af data. Disse data er referencedata og ikke løbende dataoverførsler.

Langt de fleste data overføres af 3. parts Leverandører til Systemet via en sikker FTP-forbindelse. En dataleverance kan bestå af flere filer og kan afsluttes derfor med en kontrolfil, der angiver, at data er overført. Andre data hentes af Systemet fra en sikker FTP-forbindelse ved leverandøren, og her er det Systemet, der skal kontrollere, at data hentes korrekt.

4.1.3.1 Snitflader

Systemet indeholder pt data fra 7 områder: Borger, Økonomi, Personale/Fravær, Skole, Ældre, Vok- senhandicappede og Udsatte Børn og Unge.

Der er i dag etableret 18 Snitflader til fagsystemer, der er hostet af 11 forskellige leverandører. Snitfla- derne er beskrevet i Underbilag 2.1.A.5 til Underbilag 2.1.A.74. Herudover foretages der månedligt en manuel indlæsning af referencedata, der opdateres af KOMBIT, hvor data bl.a. stammer fra KL, Inden- rigsministeriet og KRL.

Snitflader
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal etablere adgang til 18 Snitflader. I Underbilag 2.1.A.5 til Un- derbilag 2.1.A.74 er Snitfladerne beskrevet.
Bemærkning:	Der henvises til indeværende bilag afsnit 4.2.3 vedr. udfasede krav.

Xxxxxx opdatering af referencedata
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal foretage en opdatering af referencedata fra KL, KOMBIT, KRL m.fl. I det nuværende system opdateres referencedata manuelt af KOM- BIT. I Underbilag 2.1.A.75 til Underbilag 2.1.A.88 forefindes en beskrivelse af de nuværende referencedata.
Bemærkning:

4.1.3.2 Eksterne snitflader til myndigheder/leverandører

Systemet udstiller et antal Sniflader til brug for eksterne systemer. De udstillede Snitflader giver andre fagsystemer og eksterne systemer mulighed for at hente information fra Systemet.

Styrelsen for Arbejdsmarked og Rekruttering (STAR)
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal udstille en snitflade, hvor det er muligt for Styrelsen for Ar- bejdsmarked og Rekruttering at modtage Voksenhandicappede data. Se nær- mere detaljer samt specifikation i Underbilag 2.1.A.89 til Underbilag 2.1.A.90.
Bemærkning:

IBM
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal udstille en snitflade, hvor det er muligt for IBM at modtage Økonomidata.
Bemærkning:

DUBU
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal udstille en snitflade, hvor det er muligt for DUBU Systemet at modtage XXX data.
Bemærkning:

4.1.3.3 Eksterne Snitflader til kommunerne

Den lokale administrator i en kommune kan bestille datapakker fra Systemet. Herefter udvikles der et job, der scheduleres til at udtrække de ønskede data. Kommunerne tilgår deres data via FTP server.

Der kan bestilles tre typer datapakker fra enten rådata (benævnt legacy), DSAHIST- eller Datamartla- get. Kommunerne kan bestille datapakker løbende for en eller flere fremtidige kørsler, eller rådata og DSA leverancer fra tidligere kørsler.

Datapakker til kommunerne
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal udarbejde Snitflader til kommunerne, så de kan tilgå data for egen kommune fra rådata, DSAHIST- og Datamartlaget.
Bemærkning:

4.1.4 Fysisk datamodel

Den fysiske datamodel er dokumentation af de konkrete valg, der er foretaget for en strukturering af data i Systemet. Den fysiske datamodel er afgørende for Systemets funktionalitet.

Hvis der udarbejdes en ny logisk datamodel, skal den fysiske datamodel afspejle dette. Derfor skal Leverandøren udarbejde en fysisk datamodel for Systemet. Den fysiske datamodel for den nuværende version af Systemet er dokumenteret i Underbilag 2.1.A.91 til 2.1.A.131

Specifikation af den fysiske datamodel
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal opbygge den fysiske datamodel for Systemet efter den fysi- ske datamodel i det nuværende system. En beskrivelse af den fysiske datamo- del for Systemet findes i Underbilag 2.1.A.91 til 2.1.A.131
Bemærkning:

4.1.5 Logisk datamodel

Den logiske datamodel beskriver attributter og relationer for de objekter, der skal indgå i Systemet. Den logiske datamodel skal afspejle de tværgående sammenhænge, idet det øger muligheden for datagen- brug og sammenstilling af data.

I Underbilag 2.1.A.132 D0130 Logisk Datamodel, findes en oversigt over dokumentation vedr. den lo- giske datamodel i Systemet.

I Underbilag 2.1.A.133 D0130 Logisk Datamodel - Portal, findes en beskrivelse af datamodellen, der ligger til grund for rapportering i Systemet.

I Underbilag 2.1.A.135 D0130 Logisk Datamodel - Rapporteringsgrundlag, findes en beskrivelse af da- tagrundlaget for rapporteringen i FLIS-Portalen.

Specifikation af den logiske datamodel
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal genskabe den logiske datamodel, så det sikres, at den logi- ske datamodel systemunderstøtter forretningens rapporteringsbehov. Den logi- ske datamodel for Systemet findes i Underbilag 2.1.A.132 D0130 Logisk Data- model, Underbilag 2.1.A.133 D0130 Logisk Datamodel - Portal og Underbilag 2.1.A.135 D0130 Logisk Datamodel - Rapporteringsgrundlag
Bemærkning:

4.1.6 Regler/forretningslogik

I Systemet er der inden for hvert dataområde implementeret forretningsregler. De implementerede for- retningsregler regler er beskrevet i Underbilag 2.1.A.136 til Underbilag 2.1.A.149.

Implementering af forretningsregler
Kategori:	(MK)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal implementere de beskrevne forretningsregler, som fremgår af Underbilag 2.1.A.135 D0130 Logisk Datamodel - Rapporteringsgrundlag. Le- verandøren skal, i dialog med KOMBIT, fastlægge de endelige regler i forhold til eventuelle ændringer.
Bemærkning:

4.1.7 Brugergrænseflade

Dette afsnit indeholder krav til brugergrænsefladen. Fra 1. januar 2018 udfases FLIS-portalens præ- sentationslag, og FLIS-portalen videreføres som en administrationsportal, hvor brugerne har mulighed for at foretage databestillinger samt tilgå dokumentation og Dataanalyse og Kontrolrapporter til datava- lidering, jf. afsnit 2.1.2.2.

Leverandøren skal videreføre den nuværende brugergrænseflade til 1. januar 2018.

Præsentationslag
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal videreføre og drifte den nuværende brugergrænseflade frem til 1. januar 2018. I Underbilag 2.1.A.150 til Underbilag 2.1.A.180 findes en be- skrivelse af rapporter samt nøgletal.
Bemærkning:	Der henvises til indeværende bilag afsnit 4.2.5 vedr. udfasede krav.

4.1.8 Sikkerhed

Dette afsnit beskriver den overordnede model for sikkerhed og brugerstyring i Systemet. Sikkerheden i Systemet karakteriseres ved:

• Primært at skulle administrere adgang for interne medarbejdere i Kommunerne

• At integrere til et større antal fag-systemer

• At anvendere kun får adgang til det data, de har rettigheder til

Da Systemet indeholder personoplysninger, skal mekanismer til beskyttelse af data prioriteres meget højt, således at Systemet til enhver tid indeholder de korrekte data, og at disse er tilgængelige for de autoriserede Brugere og kun disse.

Alle, der har adgang til Systemet, skal autentificere og være autoriseret. Der skal derfor etableres tiltag for at:

• Bevidst eller ubevidst misbrug eller korrumpering af information ikke kan finde sted

• Systemet er tilgængeligt og kan levere de forespurgte data korrekt

• Der forefindes funktionalitet, der sikrer en registrering af sikkerhedshændelser og muligheden for ef- terfølgende at få adgang til og administrere disse

• Uvedkommende Brugere eller Brugere med manglende rettigheder ikke får adgang til Systemet.

4.1.8.1 Opbevaring og sikring af data

Opbevaring af data
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Data skal opbevares på en måde, der sikrer personfølsomme data om borgerne. Dvs. at Leverandøren skal sikre: • At data ikke opbevares under forhold, hvor dansk lovgivning ikke kan hånd- hæves.
Bemærkning:

Sikring af data
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal sikre integritet af data, blandt andet ved at: • sikre mod uautoriserede ændringer af data (fra Brugere, fra andre dele af Systemet og fra eksterne parter) • data ikke overskrives ved en fejl (eksempelvis ved at skrivebeskytte data, der ikke skal opdateres) • indarbejde kontrolprocedurer (fx at afstemme data fra forskellige kilder) • automatisk tjekke og opdage uautoriserede eller ukorrekte ændringer, som kan detekteres maskinelt ud fra kendte værdisæt, regler mv.
Bemærkning:

4.1.8.2 Rollebaseret adgangsstyring

Leverandøren skal udarbejde en rollebaseret adgangsstyring til Systemet. I det nuværende system opbevares alle brugerkonti (både portalbrugere, servicekonti og SFTP brugere) opbevares i AD.

Tabellen nedenfor viser et samlet billede af, hvilke systemroller der anvender systemet.

	Se analyseoversigter og rapporter	Se DAK rapporter	Se vejledning	Gemme analyseover- sigter og rapporter	Distribuere rapporter	Bestille datapakker	Hente datapakker fra FTP server	Foretage brugeradmi- nistration
Benchmarking - Rapportdistributør			X		*
Lokaladministrator	X	X	X	X	X	X	X	X
Dataadministrator		X				X	X
FLIS Bruger (per dataområde):
Fuld læseadgang	X	X	X
Begrænset læseadgang	**		X
Rapportdistributør	X	X	X		X
Skriveadgang	X	X	X	X
Dataadgang			X				X

* Kun distribution af rapporter markeret som benchmarking rapporter

** Kan ikke se CPR-oplysninger

Tabel 2: Rettighedsmatrix

Rollebaseret adgangsstyring
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal udarbejde en rollebaseret adgangsstyring til Systemet. Det skal være muligt at anvende rolle/rettighed begrænsninger på følgende konceptuelle dele af Systemet: • Adgang til data – en Bruger med en given rolle skal kun kunne ”se” det data, vedkommende har adgang til inklusive adgang til følsomme data • Adgang til services / intern funktionalitet – en Bruger skal kun kunne anvende de services, som denne har adgang til.
Bemærkning:

Lokaladministrator rettighed
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Det skal være muligt for en Lokaladministrator at foretage brugeradministration. Lokaladministrator rollen udfases ved overgang til administrationsportalen fra 1. januar 2018, jf. afsnit 4.2.6.
Bemærkning:

Prædefinerede dataafgrænsninger
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Dataadgange, styret via brugerroller, skal minimum kunne afgrænses på: • Kommuner • Dataleverandør • Personer • Virksomhed
Bemærkning:

Kontrol af korrekt brugeropsætning
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Systemet skal sikre, at adgang til funktionalitet og data er korrekt afstemt med brugerroller og rettighedsmatrix.
Bemærkning:

Navngivning af systembrugere
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Brugerne af Systemet skal tildeles brugernavne med navnestandard baseret på kommune/dataleverandør ID, således at man er sikker på at opnå unikke bru- gernavne på tværs af kommuner og dataleverandører. Til inspiration kan den nuværende tildeling af For kommunale brugere skal alle brugernavne ende på ”.” efterfulgt af det offi- cielle kommune-nummer (for at sikre unikke brugernavne på en fast måde, hvor brugernavne ikke risikerer at ramme grænsen i AD på 20 karakterer). For dataleverandører starter brugernavnet altid med ”DAT.” efterfulgt af en si- gende forkortelse og afsluttet med det interne ID for leverandøren (f.eks. ”DAT.D001.KMD”). For brugere med adgang til den globale administrationsportal skal brugernavnet have formen ”[type].[valgfritnavn].FLIS”, fx ”NC.ingo.FLIS”, ”Kombit.nico- lai.FLIS”. Typen skal være en af følgende: NC, KOMBIT, KL, DAT. Alle sikkerhedsgrupper skal have prefix ”sec_”, så de er lette at genkende i oversigter. Sikkerhedsgrupper navngives derefter ud fra den kontekst, de står i, således at det er let at se, om det er en kommune, leverandør eller servicemæssige sik- kerhedsgruppe.
Bemærkning:

4.1.8.3 Generelle sikkerhedskrav

Sikring mod indtrængning og angreb
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal sikre, at alle integrationer og brugergrænseflader, som ud- stilles af Systemet over offentlige eller private netværk, skal være sikrede mod indtrængen og angreb, som almindelig god IT-skik tilsiger.
Bemærkning:

URL sikring
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal sikre, at afgang til Systemet ikke kan manipuleres gennem manuel retning i URL.
Bemærkning:

Logout
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal sikre, at der på brugergrænsefladen er implementeret en vi- suel komponent til ”Logout” (via en knap eller et link), som giver brugeren mu- lighed for at logge af Systemet.
Bemærkning:

Velkontrollerede forbindelser
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal sikre, at forbindelser mod Systemet foregår på en vel- kontrolleret måde blandt andet ved: • kun at give adgang til specifikke services via godkendte IP adresser
Bemærkning:

4.1.9 Lovmæssige krav

De lovkrav, som Leverandøren er forpligtet til at overholde, fremgår af dette afsnit.

4.1.9.1 B 103

Hvis der er væsentlige grunde til ikke at overholde de relevante obligatoriske, åbne standarder, skal der ved kontraktunderskrivelse udarbejdes rapportering med begrundelse for anvendelse af undtagel- sesbestemmelserne.

Begrundelsen for at afvige fra standarderne skal indberettes til Digitaliseringsstyrelsen med henblik på offentliggørelse.

Overholdelse af B 103
Kategori:	(K)	Type:	Lov og politik
Beskrivelse:	Leverandøren skal sikre, at Systemet efterlever bestemmelserne i folketingsbe- slutning B 103 om anvendelse af åbne standarder, som udmøntet i Digitalise- ringsstyrelsens vejledninger om åbne standarder.
Bemærkning:	Hvis der er væsentlige grunde til ikke at overholde de relevante obligatoriske, åbne standarder, skal der ved kontraktunderskrivelse udarbejdes rapportering med begrundelse for anvendelse af undtagelsesbestemmelserne. Begrundelsen for at afvige fra standarderne skal indberettes til Digitaliserings- styrelsen med henblik på offentliggørelse.

4.1.9.2 ISO 27.001

Staten har besluttet at overgå til ISO 27.001, og KL anbefaler kommunerne at gøre det samme. ISO

27.001 er en del af ISO/IEC 2700 serien og består af en række standarder med indbyrdes relationer.

Overholdelse af ISO 27.001
Kategori:	(K)	Type:	Lov og politik
Beskrivelse:	Leverandøren skal sikre, at Systemet overholder ISO 27.001 eller tilsvarende
Bemærkning:

4.1.9.3 Persondataloven

I Systemet indgår personoplysninger

I den offentlige og private sektor skal persondataloven overholdes, når der foretages databehandling. Dvs. at loven gælder, når personoplysninger behandles ved hjælp af computerteknik. Loven indeholder en række regler om, hvornår man må indsamle, registrere og videregive personoplysninger osv. Hvilke regler, der skal følges i den enkelte situation, afhænger af oplysningernes karakter og formålet med databehandlingen.

Persondataloven opdeler personoplysninger i tre typer: Følsomme oplysninger, oplysninger om andre rent private forhold og almindelige ikke-følsomme oplysninger. Opdelingen findes, fordi der gælder for- skellige betingelser og procedurer for behandling af personoplysninger - afhængig af oplysningernes følsomhed.

Som udgangspunkt skal enhver behandling af personoplysninger, der foretages for en offentlig myndig- hed, anmeldes til Datatilsynet. Der gøres opmærksom på, at KOMBIT skal foretage anmeldelse til Da- tatilsynet i relation til Systemet, og at Leverandøren skal medvirke i relevant og nødvendigt omfang til denne anmeldelse.

Leverandøren skal medvirke til, at oplysninger ikke kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med persondataloven.

Overholdelse af persondataloven
Kategori:	(K)	Type:	Lov og politik
Beskrivelse:	Leverandøren skal sikre, at Systemet behandler persondata i overensstem- melse med persondataloven: • Lov om behandling af personoplysninger (Persondataloven) Lov nr. 429 af 31.5.2000 med ændringer, herunder ved lov nr. 280 af 25.4.2001 (Justitsmi- nisteriet/Datatilsynet), og Lov nr. 639 af 12.6.2013 (Justitsministeriet). • Bekendtgørelse nr. 528 af 15. juni 2000 som ændret ved Bekendtgørelse nr. 201 af 22. marts 2001 om sikkerhedsforanstaltninger til beskyttelse af per- sonoplysninger, som behandles for den offentlige forvaltning (Sikkerhedsbe- kendtgørelsen). Datatilsynets praksis omkring behandling af personoplysninger skal følges, og data skal behandles i overensstemmelse med god databehandlingsskik.
Bemærkning:	Kravet indebærer bl.a., at Leverandøren skal medvirke til, at oplysninger ikke kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med persondataloven.

Sletning efter persondataloven
Kategori:	(K)	Type:	Lov og politik
Beskrivelse:	Leverandøren skal sikre, at det er muligt at slette alle data i Systemet, der - som konsekvens af persondataloven - skal slettes, når der efter en fastlagt periode ikke længere er forvaltningsmæssigt behov for disse oplysninger.
Bemærkning:

Usynlig adresse ved adressebeskyttelse
Kategori:	(K)	Type:	Lov og politik
Beskrivelse:	Leverandøren skal sikre, at adresseoplysninger ikke gøres tilgængelige for bru- geren for de borgere, der er omfattet af adressebeskyttelse i CPR
Bemærkning:

4.1.10 Logning

Systemet anvendes til behandling af personfølsomme oplysninger og skal leve op til en række lovmæs- sige krav, som kravsat i afsnit ”4.1.9 Lovmæssige krav”. Samtidig er det væsentligt, at der kan følges op på, om der er foretaget søgninger eller opslag i Systemet, som ikke er forvaltningsmæssige rele- vante.

KOMBITs generelle principper for logning fremgår af Bilag 2.1.F Logningsprincipper.

Til disse formål skal Systemet danne følgende logspor, der er detaljeret beskrevet i Bilag 2.1.F Log- ningsprincipper.

Log Type	Beskrivelse
Systemlog	Denne typer af logs har bl.a. til formål at bistå ved fejlfinding af systemet. Det er fagsystemet, som selv sørger for at oprette, vedligeholde og udfylde de re- levante systemlogs.
Revisionslog	Formålet med denne log er at opsamle, hvordan Systemet er blevet anvendt på et givent tidspunkt, herunder opsamling af hvilke informationer, der tilgås af hvilke Brugere eller eksterne systemer. Krav hertil er direkte udledt af Person- dataloven og tilsvarende krav om revisionsspor og sikring mod uretmæssig til- gang til personhenførbare oplysninger.
Verifikationslog	Logning af events i forbindelse med udrulning og ændringer i de fysiske mil- jøer. Muliggør verifikation af, om ændringer er udrullet korrekt.
Driftslog	Logning fra de fysiske miljøer inkl. operativsystem, netværksudstyr med vi- dere, som kan danne grundlag for fejlsøgning.

Under afklaringsfasen afgøres det, hvilke af Systemets logninger, der er indeholdt i hver enkelt log type. Det aftales også i afklaringsfasen hvilke felter, der skal være indeholdt i de enkelte log typer.

Leverandøren skal sikre, at indholdet af det samlede datagrundlag for logning er komplet, uanset om logningen foretages centralt eller decentralt.

Principper for logning
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal foretage logning efter de generelle principper for logning, der er defineret i Bilag 2.1.F Logningsprincipper.
Bemærkning:

Implementering af logs
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal implementere følgende logs, som beskrevet i Bilag 2.1.F Logningsprincipper. • Systemlog • Revisionslog • Verifikationslog • Driftslog
Bemærkning:

Adgang til logs
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal gøre det muligt for KOMBIT og en administrator via en bru- gergrænseflade at søge, specificere filtre og få vist logdata i de anførte logspor, samt at udtrække logdata i gængse udvekslingsformater til bearbejdning i andre systemer. Driftsleverandøren skal kunne anvende Logning som input til brug for driftsrap- portering.
Bemærkning:

Administration og opbevaring af logs
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal sikre, at det er muligt at administrere logs, herunder at logs kan gemmes og slettes når logs overstiger den fastsatte alder, jf. Bilag 2.1.F Logningsprincipper. Logs skal opbevares i 5 år med mindre andet er aftalt mellem KOMBIT og Leve- randøren – personfølsomme logdata må dog højst opbevares 6 måneder, jf. per- sondataloven.
Bemærkning:

Opsamling og lagring af logdata i systemet
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal foretage en automatisk opsamling af logdata, og gemme disse på maskinlæsbar form.
Bemærkning:

Ensartet struktur og format for logning af data i Systemet
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal sikre, at det er muligt at eksportere logdata i et standardfor- mat, som anført i Bilag 2.1.F Logningsprincipper. Den ensartede struktur og for- mat skal sikre muligheden for at sammenstille logs på tværs af systemer.
Bemærkning:

Anvendelse af fælles logningskomponent
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal sikre, at det er muligt at aflevere log data til en central log løsning implementeret eller udpeget af KOMBIT. Indholdet af logs skal være som anført i Bilag 2.1.F Logningsprincipper. Dette sikrer muligheden for at sammenstille logs på tværs af systemer. Log data skal kunne afleveres inde- holdt i en fil og skal kunne afleveres til en filtransportløsning.
Bemærkning:

Generering og brug af et unikt transaktions ID
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal genere og benytte sig af unikke transaktions ID i logs, som anført i Bilag 2.1.F Logningsprincipper. Transaktions ID skal sikre muligheden for at sammenstille logs på tværs af systemer.
Bemærkning:

Logning af tid i brugergrænseflade
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal foretage logning af anvendelse af brugergrænsefladen, her- under svartider. Logningen er nærmere beskrevet i Bilag 7.2.A Ydelser og Servicemål, punkt 13.3.
Bemærkning:

Logning af kald til Snitflader
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal sikre, at der foretages logning ved levering og/eller modta- gelse af data via en Snitflade. Logningen er nærmere beskrevet i Bilag 7.2.A Ydelser og Servicemål, punkt 13.4. Informationer om anvendte Snitflader der skal logges: • Dato og tid • Det eksterne system, der tilgås • Svartid på forespørgsel • Datamængde
Bemærkning:

Logning af fejl ved kald til Snitflader
Kategori:	K	Type:	Ikke funktionelt
Beskrivelse:	Leverandøren skal sikre, at fejl ved levering og/eller modtagelse af data via en Snitflade logges.
Bemærkning:

4.1.11 Dokumentation

Krav om dokumentation
Kategori:	(MK)	Type:	Ikke-Funktionelt
Beskrivelse:	Leverandøren skal implementere KOMBITS krav til Dokumentation i henhold til Bilag 4 - Dokumentation og programmel. Kravet er ligeledes gældende for æn- dringer foretaget inden for rammerne af kontrakten, men efter overdragelse af hovedleverancen, med mindre andet eksplicit er nævnt i løsningsbeskrivelsen til den enkelte ændring.
Bemærkning

4.2 Udfasede krav

Følgende afsnit indeholder en beskrivelse af de dele af Systemet der kan udfases. Der udfasede dele af Systemet er oftest beskrevet i en tilhørende ændringsanmodning.

4.2.1 Teknisk infrastruktur

Systemet blev oprindeligt etableret med fire logiske miljøer, der håndterer:

• PROD - Produktion

• DEMO (udfaset)

• TEST - Test

• UDV – Udvikling

Udfasning af Demo miljø
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren kan vælge at undlade at etablere Systemet med et DEMO miljø. I den nuværende version af Systemet er DEMO miljøet udfaset.
Bemærkning:

4.2.2 Arkitektur

Med ønsket om en performanceoptimering besluttede man i Release 3.0 (Ændringsanmodning 190) at udfase DSA laget i Systemet. DSA laget replicerede næsten udelukkende data i DSAHIST. Det var derfor en mulighed at læse data direkte fra DSAHIST til EDW, og derved opnå en performanceforbed- ring.

Udfasning af DSA Lag
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal etablere Systemet som en lagdelt datawarehouse arkitektur. Leverandøren kan vælge at undlade at etablere Systemet med et DSA niveau, jf. Ændringsanmodning 190.
Bemærkning:

4.2.3 Integrationer

Ved dialog med Københavns Kommune blev det i første omgang identificeret, at der skulle etableres Snitflader til Københavns Kommunes Udsatte Børn og Unge system (BUS) samt Visitationssystem (VI),

disse to Snitflader er aldrig taget i brug. Herudover blev der i første omgang truffet aftale med Danmarks Statistik om adgang til Snitflader indeholdende data om Udsatte Børn og Unge (De nationale dokumen- tationsprojekter del 4) samt Sundhedsdata (De nationale dokumentationsprojekter del 2), disse to Snit- flader er pt. ikke taget i brug.

Snitflader der ikke er taget i brug
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren behøver ikke at foretage integration til følgende fire Snitflader, idet Snitfladerne pt. ikke er taget i brug: - Københavns Kommunes Udsatte Børn og Unge system (BUS) - Københavns Kommunes Visitationssystem (VI) - Danmarks Statistik Udsatte Børn og Unge data (De nationale dokumen- tationsprojekter del 4) - Danmarks Statistik Sundhedsdata (De nationale dokumentationsprojek- ter del 2)
Bemærkning:

4.2.4 Regler/forretningslogik

Til Systemet er der udarbejdet 1.100 nøgletal, efter udvikling af nogle af nøgletallene har de mistet deres relevans. De nøgletal, der ikke bliver anvendt eller har mistet deres relevans, kan undlades fra Systemet.

Udfasning af nøgletal
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren kan undlade at beregne de nøgletal, der er markeret med status- kode ’6’ og ’9’ i Underbilag 2.1.A.XX. Nøgletallene er ikke taget i brug, og be- høver derfor ikke at blive beregnet.
Bemærkning:

4.2.5 Brugergrænseflade

Fra 1. januar 2018 udfases FLIS-portalens præsentationslag, og FLIS-portalen videreføres som en ad- ministrationsportal, hvor brugerne har mulighed for at foretage databestillinger samt tilgå dokumentation og Dataanalyse og Kontrolrapporter til datavalidering, jf. afsnit 2.1.2.2.

Leverandøren skal videreføre den eksisterende brugergrænseflade frem til 1. januar 2018.

Udfasning af portalfunktionalitet
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal fra 2018 videreføre en begrænset portalfunktionalitet. Porta- lens formål bliver dermed at understøtte bestilling af datapakker og udtræk af DAK-rapporter, samt indeholde dokumentation og brugervejledninger.
Bemærkning:

4.2.6 Sikkerhed

Ved udfasning af FLIS-portalen fra 1. januar 2018, vil hovedparten af de nuværende brugere ikke læn- gere skulle supporteres.

Support af brugere
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Leverandøren skal fra 1. januar 2018 ikke længere supportere FLIS-brugerne, lokaladministratorerne samt Benchmarking- Rapportdistributør jf. Tabel 2 Ret- tighedsmatrix i afsnit 4.1.8.2.
Bemærkning:

4.2.7 Metadata management

I den nuværende løsning er valgt Informatica Powercenter, som ETL værktøj og Informatica Metadata- Manager & Business Gloassary for bl.a. at sikre sporbarhed mellem dataleverancer og rapporterings- niveauet ved at udstille datafelters kilde og anvendelse (data lineage) for brugerne. I praksis har det vist sig, at denne funktionalitet ikke matcher behovet for sporbarhed. Der er i højere grad anvendt skriftlig dokumentation, hvor data lineage præsenteres sammen med forretningsregler i prosa. Kravet om et integreret værktøj til at præsentere metadata online for brugerne kan således bortfalde. Øvrige funktionelle krav, som i det eksisterende system understøttes af Informatica Metadata Manager og In- formatica Powercenter er fortsat gældende, hvor intet andet er nævnt.

I Bilag 4 – Dokumentation og Programmel fremgår gældende krav om dokumentation til Systemet.

Udfasning af spor
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Systemet kan, men behøver ikke, at understøtte online webbaseret adgang til at se datalineage og forretningsregler.
Bemærkning:

4.3 Nye krav

Følgende afsnit indeholder krav, der ligger ud over beskrivelsen af den eksisterende løsning eller skær- per kravene ud over den baseline, som er beskrevet i XXXX. Det skal bemærkes, at de herunder be- skrevne krav retter sig mod udvikling af ny funktionalitet eller udvikling, der understøtter opfyldelse af krav til performance og driftsafvikling. For flere krav og optioner gælder, at der er korresponderende krav og optioner under beskrivelsen af driftsdelen i Bilag 7, som relaterer sig til ændringer i den løbende driftsafvikling.

4.3.1 Teknisk infrastruktur

Der stilles en lang række nye krav til performance i systemet, som ikke var kravsat eller var kravsat anderledes i det eksisterende System.

4.3.1.1 Parallel håndtering af datapakker

Systemet er på nuværende tidspunkt konfigureret til at køre serielt. Det er således ikke muligt at fore- tage ind- og udlæsning af datapakker samtidig med, at der gennemføres ETL op til Datamarter og kubeprocessering. For at understøtte løbende videreformidling af rådata og DSA-data bliver der stillet krav om, at Systemet skal kunne fortsætte udlæsning af datapakker parallelt med, at der foretages andre processer i løsningen. De parallelle processer vil skulle trække på nogle af de samme ressourcer og data. Der skal således tages skridt til at modvirke konflikter ved samtidig tilgang til data, og der skal være en klar statushåndtering af hvilke data, der er klar til at blive udlæst.

Parallel håndtering af datapakker
Kategori:	(K)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne foretage indlæsning af rådata, validering og oplæsning til DSA og udlæsning af datapakker parallelt med ETL-processer og kubeproces- sering.
Bemærkning:

4.3.1.2 Skalérbar indlæsningstid i månedlig kørsel

Systemet er i sin nuværende form designet og bestykket ud fra behov, der tidligere var til løsningen, den teknologi og de priser, som var gældende ved det tidligere udbud. I den mellemliggende periode har behovene ændret sig, og nye muligheder åbnet sig. Det forventes derfor, at Systemet kan gennem- føre de løbende kørsler hurtigere end på nuværende tidspunkt.

4.3.1.2.1 Indlæsning til datamarter

Der er særligt fokus på de processer, herefter benævnt Den kritiske vej, som påbegyndes, når den sidste månedlige dataleverance er afleveret, og indtil Datapakker fra Datamartlaget kan udlæses.

Figur 7

I nedenstående angives en række Optioner, som stiller forskellige krav til procestiden for ”Den kritiske vej”. Målet for disse krav opgøres som den maksimale tid brugt på at gennemgå de beskrevne processer under en række angivne forudsætninger.

Optionerne herunder dækker videreudviklingsopgaver, der skal iværksættes for at opnå den ønskede procestid. Ændring af procestider udløser samtidig et tillæg for ”hurtigere procestid”, som angivet i bilag 7.2.B.

Processerne er, som angivet i diagrammet ovenfor, alle processer involveret i dannelse af Datamarter fra sidste dataleverance er modtaget, og indtil Datamarterne er klar til at blive udlæst.

Sidste dataleverance udgør i denne sammenhæng OPUS Økonomi og OPUS Løn og Personale - se

4.1.3. Datamængder i disse leverancer forudsættes at udgøre XXXX. Datamængder i løsningen i øvrigt forudsættes at svare til XXXX.

Det forudsættes, at der ikke er behov for manuelle indgreb i processen, dvs. at alle automatiske vali- deringer gennemløbes, men at manuelle valideringer kan negligeres.

Udlæsning af datapakker indgår ikke direkte i den kritiske vej, idet de forudsættes at foregå i en parallel proces jf. Krav# 2.1-52. For så vidt, at disse processer trækker på nogle af de samme ressourcer, skal det forudsættes, at der skal udlæses datapakker svarende til de nuværende bestillinger jf. XXXX.

Indlæsning af data - udvikling
Kategori:	(K)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal være konfigureret således at procestiden for Den kritiske vej er skalerbar. Leverandøren skal uden at måtte ændre på funktionelle krav, kunne iværksætte en ændring af procestiden helt ned til 6 timer for de beskrevne pro- cesser. Baseline, der skal overholdes som udgangspunkt, er 60 timer.
Bemærkning:

Herefter følger fem optioner, som trin for trin stiller skrappere krav til indlæsningstiden. Det forudsættes, at en evt. tilbagerulning til mindre skrappe krav sker uden afregning eller kompensation til Leverandøren på udviklingssiden, mens der kan ske ændring begge veje på driftssiden.

Indlæsning af data på 48 timer - udvikling
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne gennemføre ETL processen fra sidste leverance er mod- taget til Datamarterne er opdateret (”Den kritiske vej”) på højst 48 timer.
Bemærkning:

Indlæsning af data på 36 timer - udvikling
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne gennemføre ETL processen fra sidste leverance er mod- taget til Datamarterne er opdateret (”Den kritiske vej”) på højst 36 timer. Det forudsættes, at Krav# 2.1-54 først er aktiveret.
Bemærkning:

Indlæsning af data på 24 timer - udvikling
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne gennemføre ETL processen fra sidste leverance er mod- taget til Datamarterne er opdateret (”Den kritiske vej”) på højst 24 timer. Det forudsættes, at Krav# 2.1-55 først er aktiveret.
Bemærkning:

Indlæsning af data på 12 timer - udvikling
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne gennemføre ETL processen fra sidste leverance er mod- taget til Datamarterne er opdateret (”Den kritiske vej”) på højst 12 timer. Det forudsættes, at Krav# 2.1-56 først er aktiveret.
Bemærkning:

Indlæsning af data på 6 timer - udvikling
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne gennemføre ETL processen fra sidste leverance er mod- taget til Datamarterne er opdateret (”Den kritiske vej”) på højst 6 timer. Det for- udsættes, at Krav# 2.1-57 først er aktiveret.
Bemærkning:

4.3.1.3 Indlæsningstid ved Fuld indlæsning

Systemet forventes at skulle følge videreudvikles med to årlige Minor eller Major versioner. I forbindelse med disse versioner forventes alle data at blive genindlæst, således at evt. ændringer i forretningsregler kan slå igennem på alle data. Denne Fulde indlæsning skal kunne gennemføres uden at påvirke de løbende Månedsindlæsninger. Den Fulde indlæsning skal altså kunne gennemføres i perioden fra en Månedsindlæsning er færdig og klarmeldt, den nye version bliver rullet på og indtil næste Månedsind- læsning skal påbegyndes. Det forudsættes her, at Krav# 2.1-52 er opfyldt således at indlæsning data og udlæsning af rådata og DSA-datapakker foregår parallelt og upåvirket af dette.

Indlæsningstid ved Fuld indlæsning
Kategori:	(K)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne gennemføre en Fuld indlæsning af alle data i Systemet i forbindelse med nye Minor og Major versioner således, at Månedsindlæsninger fortsat kan foretages på samme tid hver måned.
Bemærkning:

4.3.1.3.1 Processering af kuber

Med udfasningen af den primære rapporteringsdel på FLIS-portalen mister de kuber, som processeres oven på datamarterne noget af deres betydning. De skærpede performance krav til de øvrige dele af løsningen vil derfor ikke umiddelbart gælde denne proces. Hvis Krav# 2.1-70 tilvælges, vil det imidlertid alligevel være relevant. Følgende tidskrav til processeringen forudsætter en fuld gendannelse af alle kuber, uafhængigt af Krav# 2.1-64 om delvis opdatering af datamarter og kuber.

Processering af kuber
Kategori:	(K)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne processere kuber, til rapportering for alle kommuner på højst 48 timer.
Bemærkning:

Processering af kuber – skærpet krav
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet skal kunne processere kuber, til rapportering for alle kommuner på højst 24 timer.
Bemærkning:

4.3.1.4 Optimering af driftsforløb

Fejl og genkørsler er uundgåelige i et komplekst system med mange datakilder. Systemet skal derfor indeholde faciliteter til test af data, restore og genkørsel.

Nøgletal er de mest forædlede data i Systemet, og test på dette niveau vil derfor naturligt fange en lang række fejl i de underliggende lag og datagrundlag. Til gengæld vil fejl, der ses efter nøgletallene er beregnet, kun kunne rettes ved en genkørsel tilbage fra det niveau, hvor fejlen lå.

For at få det optimale udbytte af tests er det afgørende, at de ligger så tidligt som muligt efter den proces, som de skal teste. Samtidig kan eventuelle genkørsler optimeres ved at placere udtagning af backup, så det er muligt at nøjes med at foretage genkørsel af særligt kritiske dele af processen, eller efter særligt tidskrævende dele.

Optimering af proces for driftsforløb
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Systemet skal i sit flow af transformationer, tests og backups understøtte en fleksibel adgang til at genkøre hele eller dele af processen til opdatering af da- tamarterne. Tilbudsgiver bedes beskrive hvorledes man påtænker at sikre en optimal pro- ces for kørsel, test og evt. genkørsel.
Bemærkning:

Er det nødvendigt at foretage en genkørsel, er det afgørende, at data i Systemet er organiseret og opmærket, således at en genkørsel kan isoleres til færrest mulige data.

Fleksibel delvis opdatering
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Systemet skal kunne indlæse og erstatte data fra en eller flere leverancer (en kommunes data på en enkelt snitflade) uden samtidig at skulle genindlæse og/eller erstatte øvrige data. Dette skal være gældende fra den leverede rådatafil og op til kuberne.
Bemærkning:

Som en yderligere mulighed for at optimere kørselstiderne stilles der krav om at kunne foretage delvis opdatering af datamart og kuber. På nuværende tidspunkt gendannes datamarter og kuber helt ved hver månedsindlæsning.

Delvis opdatering af datamart og kuber
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Systemet skal kunne foretage en delvis opdatering af datamarter og kuber. Opdateringen vil skulle kunne afgrænses på: • Tidsdimensionen således at fx kun sidste, indeværende og fremtidige år opdateres. • Dataområder, således at fx et dataområde (ekskl. nøgletal) opdateres færdigt før resten. Ændringer af hvilket omfang, der skal opdateres, skal dette kunne håndteres som en ukompliceret ændring af kørselsparametre således, at det kan ske fra måned til måned og er omfattet af krav XXX om månedlige driftsafvikling.
Bemærkning:

4.3.1.5 Testmiljø

Systemet anvender mange forskellige kilder og dækker data fra mange omskiftelige faglige miljøer. Ydermere er der bindinger på tværs af dataområder, således at en nøgletalsberegning fordrer samtidige data fra flere forskellige kilder. Nogle regler er tidsafhængige og kræver derfor tidsserier på flere år og nogle gange op til nyeste data. For at kunne foretage test af integrationer og nøgletalsberegninger er det derfor nødvendigt at have adgang til testdata fra mange forskellige kombinationer af tid og kilder.

Det bedste datagrundlag ville således være adgang til alle produktionsdata i test og udviklingsmiljøet. Hindringer for dette er hovedsagligt, at det giver fleksibilitet i udviklings- og testprocessen, hvis man kan gennemføre testgennemløb af hele ETL-forløbet i løbet af en enkelt nat eller weekend. Afhængig af regnekraften i test og udviklingsmiljøet sætter det en grænse for hvor mange data, man kan nå at behandle. Endvidere er der krav (XXX) til, at data, som behandles i test og udviklingsmiljøet, er anony- miserede. Data, som skal indgå i test-miljøet, skal derfor først gennemgå en sløring.

Der er derfor behov for let at kunne opdatere data i testmiljøet og ændre sammensætning af data alt efter aktuelle behov for test.

Fleksibelt testmiljø
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Data i testmiljøet skal give adgang til at teste på de til enhver tid relevante kom- binationer af fagsystemer og tidsserier.
Bemærkning:

4.3.1.6 Udfasning af SFTP-service

Udfasning af egen SFTP-service
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Ved en fuld ibrugtagning af Serviceplatformens SFTP service for både ind og udgående filleverancer, kan Systemets integrerede SFTP løsning lukkes ned
Bemærkning:

4.3.2 Arkitektur

Der er ingen nye krav relateret til dette afsnit ud over det, der fremgår af øvrige bilag.

4.3.3 Integrationer

4.3.3.1 Fleksibel indlæsning af data

I den nuværende løsning foretages der en gang dagligt validering af dataleverancer på de eksterne snitflader. Det giver unødvendig liggetid for data, før de videreformidles.

Løbende validering af dataleverancer
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Validering af data og efterfølgende generering af datapakker igangsættes på baggrund af en trigger eller tilsvarende service, der igangsætter levering af da- tapakker, så snart de nødvendige data er tilgængelige. Herunder mulighed for at bestille udtræk af de aktive datamarter.
Bemærkning:

Behandling af indkomne leverancer på en enkelt snitflade er på nuværende tidspunkt organiseret på tværs af kommuner. Det vil sige, at behandling af data fra en kommune på en snitflade ikke kan påbe- gyndes, før end alle kommuner, der er opsat til at anvende denne snitflade, har leveret eller er blevet annulleret.

Indlæsning af enkelte kommuners data på snitflader med adskilte leverancer
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Validering og indlæsning af data skal kunne foretages for enkelte kommuners data, selvom der er flere kommuner, der afleverer data på den samme snit- flade.
Bemærkning:

4.3.3.2 Nye typer af eksterne integrationer fra Systemet

Der kan udlæses data fra det nuværende system på rådata, DSA og Datamart-niveau. For at give den størst mulige fleksibilitet ønskes Option på nye leverancer fra EDW og på kuber.

Udlæsning af datapakker fra EDW
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Kommunerne skal kunne udlæse egne data fra EDW-laget på samme måde, som der nu kan udlæses rådata, DSA og Datamart-data.
Bemærkning:

Udlæsning af kuber som datapakker
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Kommunerne skal kunne udlæse filer, der indeholder OLAP-kuber (.cub), sva- rende til dem, som anvendes i rapporteringslaget på samme måde, som der nu kan udlæses rådata, DSA og Datamart-data.
Bemærkning:

Direkte adgang til data som supplement til sftp
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Som alternativ til sftp skal kommunerne kunne trække data, som stilles til rådig- hed ved hjælp af direkte adgang til en database. Databasen skal anvende et standard forespørgselssprog og adgangen skal leve op til samme sikkerhedsni- veau, som den ftp-adgangen giver.
Bemærkning:

4.3.3.3 Højere frekvens af datapakker

På nuværende tidspunkt indlæses hver snitflade én gang om måneden. Enten når alle forventede data er modtaget fra alle kommuner, eller når Systemets månedskørsel går i gang. Det er på dette tidspunkt, at der kan leveres datapakker på DSA og rådata-niveau. Det skal være muligt at processere og videre- distribuere snitflader flere gange om måneden.

Der ønskes en løsning, hvor kommunerne kan vælge at få daglige, ugentlige eller månedlige leveringer af datapakker fra Systemet på rådata og DSA-data i det omfang, at det er stillet til rådighed af leveran- døren. Denne løsning skal fungere som et tilvalg for nogle kommuner, og skal ikke være tilgængelig for alle.

Bestilling af data skal udvides til daglige eller ugentlige data. Der er opstillet særskilte SLA-krav for leverancer på uge- og dagsniveau, som kan stille skærpede krav til performance ift. standardløsningen. Se bilag XXXX.

Bemærk, at dette er option på udvikling af ny funktionalitet ifm at tilbyde daglige og ugentlige leverancer. Derudover kan der afregnes månedlige tillæg for ydelsen på driftssiden se bilag 7.2.B.

Levering af rådata dagligt eller ugentligt
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Kommunerne skal kunne få leveret rådata og DSA-data dagligt eller ugentligt i det omfang, at data leveres med denne hyppighed fra Dataleverandøren. Ad- gang til at bestille data til leverance dagligt eller ugentligt skal kun gives til en- kelte kommuner for enkelte snitflader på baggrund af aftale med KOMBIT. Le- verance af ugentlige og daglige data er underlagt særskilte SLA-krav jf. bilag 7. XXXX
Bemærkning:

4.3.3.4 Udtræk af datapakker

På samme måde, som det er vigtigt, at data skal kunne beregnes på en begrænset tid, skal datapakker også kunne leveres på en fast afgrænset tid. Efterspørgslen efter datapakker er uforudsigelig, og kra- vene til datapakkeleverancer stilles derfor som et krav til hastighed, snarere end som et krav til samlet leveringstid.

Kravene dækker udtræk og overførsel af datapakker fra driftsmiljøet og ned på det medie, hvor kom- munerne kan hente dem (i udgangspunktet Systemets SFTP-server).

Der stilles krav til hvilken performance der forventes som baseline i Bilag 7XXX, mens der er Optioner om udviklingsomkostningen ifm. bedre performance i dette bilag og i Bilag 7.2.B vedrørende eventuelle merudgifter til drift.

Udtræk af datapakker (rådata)
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Der ønskes performance på udtræk og overførsel af datapakker fra driftsmiljøet og ned på det medie, hvor kommunerne kan hente dem (i udgangspunktet Sy- stemets SFTP-server) med en hastighed på 1000 Mbyte/ Minut.
Bemærkning:

Udtræk af datapakker (DSA)
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Der ønskes performance på udtræk og overførsel af datapakker fra driftsmiljøet og ned på det medie, hvor kommunerne kan hente dem (i udgangspunktet Sy- stemets SFTP-server) med en hastighed på 200 Mbyte/ Minut.
Bemærkning:

Udtræk af datapakker (EDW)
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Der ønskes performance på udtræk og overførsel af datapakker fra driftsmiljøet og ned på det medie, hvor kommunerne kan hente dem (i udgangspunktet Sy- stemets SFTP-server) med en hastighed på 250 Mbyte/ Minut. Det skal bemær- kes at udlæsning fra EDW er en Option (Krav# 2.1-69).
Bemærkning:

Udtræk af datapakker (Datamart)
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Der ønskes performance på udtræk og overførsel af datapakker fra driftsmiljøet og ned på det medie, hvor kommunerne kan hente dem (i udgangspunktet Sy- stemets SFTP-server) med en hastighed på 250 Mbyte/ Minut.
Bemærkning:

Udtræk af datapakker (Kuber)
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Der ønskes performance på udtræk og overførsel af datapakker fra driftsmiljøet og ned på det medie, hvor kommunerne kan hente dem (i udgangspunktet Sy- stemets SFTP-server) med en hastighed på 1000 Mbyte/ Minut. Det skal be- mærkes at udlæsning af kuber er en Option (Krav# 2.1-70).
Bemærkning:

Udtræk af datapakker (Udvikling)

Option	Krav	Option	Reference fra nuvæ- rende løsning/	Målsætning
	Mbyte/Minut	Mbyte/Minut	Mbyte/Minut
Rådata leverance	200	1000	198 (477 Mb/2,4 Min)
DSA leverance	20	200	18 (500 Mb/28min) 16(218 Mb/13 min) 21(274 Mb/13 min)
EDW leverance	25	250	--
Datamart leverance	25	250	26 (1099 Mb/42 min)	Alle kommuner på 12 timer (98 kom. x 1,5Gb/ 12t.)=209 Mb/Min
Kuber leverance	500	1000	--	Alle kommuner på et døgn (98 kom. x 9Gb/ 24t.) = 627 Mb/Min

4.3.3.5 Automatiseret indlæsning af referencedata

Systemet anvender på flere områder eksterne referencedata til at kategorisere data fra de forskellige kommunale kildesystemer. Disse data downloades, formateres og behandles i dag manuelt for at over- holde snitfladen til Systemet. Dette er tidskrævende og ufleksibelt, samt medfører risici for driftssikker- hed og datakvalitet. Ved etablering af automatiserede integration til disse kilder vil Systemet blive mere robust.

Register	Frekvens Kilde	Frekvens System	Format	Forædling
Indenrigsministeri- ets(IM) kontoplan (xxxx://xxx- xxxx.xxx.xx/)	Ad hoc 2-3 gange årligt	Ved hver opdatering	Standard formateret pdf	Standardisering af input Opdatering af eksisterende liste
KRL’s liste over løn- klasser (xxxx://xxx.xxx.xx/xxx- dukter/lkl/)	2 gange år- ligt (jan/apr)	Ved hver opdatering	Excel-fil til download	Opdatering af eksisterende liste med nye værdier
STIL’s institutionsre- gister (xxxx://xxxxxxx.xxx- x.xx/XxxxXxxXxxxxxx/)	Løbende	Månedligt	Excel-fil til download	Opdatering af eksisterende liste Opbygning af historik
CVR’s virksomheds- register (xxxxx://xx- xxxxx.xxxx.xx/xxxx/xxx)	Løbende	Månedligt	Excel-fil til download	Ubearbejdet

Implementering af en automatisering kan enten ske ved en fuld automatisering eller ved manuel down- load og automatiseret formatering og behandling. Det skal bemærkes, at der er delvist overlap mellem denne option og integration med Støttesystemet Klassifikation se Krav# 2.1-87.

Optionen dækker udelukkede evt. udviklingsomkostninger ifm implementering af hel-/semi automatise- redet integration. Driftsdelen indgår af bilag 7. Bemærk, at integration og mapning af disse data allerede foretages af Systemet og er beskrevet (se Krav# 2.1-8), Optionen dækker kun, at tilvejebringe data og bringe det på den form, som Systemets integration er forberedt på.

Automatisereret indlæsning af referencedata – udvikling
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal kunne hente og integrere data fra de ovennævnte kilder, som ikke er tilgængelige som system-til-system integrationer, men hvor der kan ud- vikles en højere grad af automatisering.
Bemærkning:

4.3.3.6 Nye data i Systemet

Der er oprindelig aftalt 11 dataområder i Systemet. Der vil derfor, som minimum skulle udvikles 4 yder- ligere områder. Et dataområde i Systemet kan dog variere meget i omfang. De eksisterende dataområ- der dækker hvert et udsnit af data fra et kommunalt serviceområde med 1-5 Integrationer med 29-2900 felter hver, i alt 100 Kb-10Gb pr. måned og dannelse af 100-300 nøgletal.

Parametre i eksisterende dataområder

Dataområde	Integrationer	Felter i rådata	Gb rådata pr. md.	Felter i EDW	Felter i Datamart	Nøgletal	Nøgletalstyper
Tværgående	X	X	X	172	185
Borger	1	924	<1	311	69	14	3
Økonomi	5	3.885	Ca.10	410	649	311	17
Personale/Fravær	3	1.649	Ca.10	143	100	188	10
Skole	2	124	<1	232	143	128	24
Ældre	1	49	Ca.5	89	143	90	12
Voksenhandicappede	1	29	<1	117	153	106	15
Udsatte Børn og Unge	4	5.226	Ca.10	134	142	165	28
Total	17	12.479	Ca. 30	1608	1584	1002	109

Integrationer: Antallet af eksterne integrationer fra ét eller flere produktionssystemer, der anven- der samme datamodel til aflevering af data.

Felter i rådata: Xxxxxx xxxxx felter med særskilt definition i datamodellen.

Gb rådata pr. md.: Omtrentlig datamængde afleveret i løbet af en løbende måned.

Felter i EDW: Felter ekskl. systemfelter (_SYS) i samtlige tabeller i EDW-laget

Felter i Datamart: Felter ekskl. systemfelter (_SYS) i samtlige tabeller i datamart-laget

Nøgletal: Aktive nøgletal, som vises i portalen.

Nøgletalstyper: Xxxxx nøgletalsskabeloner. Hver skabelon kan anvendes til en række nøgletal blot ved udskiftning af 1-2 filtre eller variable.

Eftersom de kommende dataområder endnu ikke er afgrænsede, ønskes Optioner på en række gene- riske dataområder med forskellige konstellationer af parametre. Som kan bruges til at overskue omfan- get af faktiske kommende dataområder.

Kravene til nye dataområder deles i tre dele:

• Ny integration, som dækker alle relationer mod dataleverandør og regler for indlæsning op til DSAHIST. Her stilles et generelt Krav om at der skal kunne integreres, hvorpå der i Bilag 5 beskrives en matrix optioner, der dækker kombinationer af loadtype og antal felter, der skal indlæses. Disse optioner er udtømmende og kan dermed dække alle fremtidige integrationer.

• Ny mapning, dækker over mapning af data, som allerede er persisteret i DSAHIST op til en eksiste- rende datamodel i EDW. Her opsættes kun to generiske optioner, som ikke skal være dækkende, men kun skal give et indtryk af det forventede udviklingsbehov i to forskellige scenarier.

• Nyt dataområde, dækker over dannelse af en datamodel og et rapporteringsgrundlag for et nyt data- område, under forudsætning af et specificeret antal felter i Datamart-laget og et antal nøgletal på et

PORTAL

KUBER

DM

EDW

DSAHIST

Rådata

Kildesystemer

Nyt dataområde

Ny mapning

angivet antal nøgletalstyper. Her er angivet tre generiske optioner, der dækker tre scenarier af forskel- lige dataområder, som skal give indtryk af det forventede udviklingsbehov.

Ny Integration

4.3.3.6.1 Opdeling af krav ifm nye data i Systemet

Ny integration
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Systemet skal kunne integrere data fra nye Snitflader, som skal modtages fra dataleverandører og lagres i DSAHIST.
Bemærkning:

4.3.3.6.2 Ny mapning

Når rådata er lagret i DSAHIST, kan dele af datafangsten mappes ind i Systemets datamodel. Det er således ikke sikkert, at alle rådata skal medtages i de følgende datalag. Dele af data overføres direkte, andre oplæses ved brug af regler. Der ønskes Option på to forskellige generiske mapninger med hhv. 100 og 300 felter.

Ny mapning til eksisterende datamodel - lille
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal kunne mappe data fra en ny Snitflade, der er lagret i DSAHIST, til den eksisterende datamodel på det pågældende dataområde i EDW, som har en datamodel med 100 felter.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

Ny mapning til eksisterende datamodel - stor
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal kunne mappe data fra en ny Snitflade, der er lagret i DSAHIST, til den eksisterende datamodel på det pågældende dataområde i EDW, som har en datamodel med 300 felter.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

4.3.3.6.3 Nyt dataområde

Det er opstilles tre generiske scenarier for nye dataområder, som ønskes estimeret. Scenarierne er løseligt baseret på de eksisterende dataområder. Optionerne vil danne udgangspunkt for fastsættelsen af de konkrete fremtidige dataområder.

	Felter i Datamart	Nøgletals-typer	Nøgletal
Scenarie 1 – lille	50	5	15
Scenarie 2 – mellem	150	20	75
Scenarie 3 - stort	500	20	150

Nyt dataområde – scenarie 1
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal udvides med et nyt dataområde, som vil indbefatte opbygning af en ny datamodel i EDW, ny Datamart og kube, samt indbefatte beregning af en række nøgletal, som kan stilles til rådighed i nøgletalsdatamarten. Der forudsættes, at datamodellen i Datamarten vil have 50 felter, at der skal udvikles 5 nye typer nøgletal, og at der i alt skal beregnes 15 nøgletal.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

Nyt dataområde – scenarie 2
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal udvides med et nyt dataområde, som vil indbefatte opbygning af en ny datamodel i EDW, ny Datamart og kube, samt indbefatte beregning af en række nøgletal, som kan stilles til rådighed i nøgletalsdatamarten. Der forudsættes, at datamodellen i Datamarten vil have 150 felter, at der skal udvikles 20 nye typer nøgletal, og at der i alt skal beregnes 75 nøgletal.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

Nyt dataområde – scenarie 3
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal udvides med et nyt dataområde, som vil indbefatte opbygning af en ny datamodel i EDW, ny Datamart og kube, samt indbefatte beregning af en række nøgletal, som kan stilles til rådighed i nøgletalsdatamarten. Der forudsættes, at datamodellen i Datamarten vil have 500 felter, at der skal udvikles 20 nye typer nøgletal, og at der i alt skal beregnes 150 nøgletal.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

4.3.3.7 Fleksibel håndtering af Eksterne systemgrænseflader

FLIS har en strategi om at kunne dække kommunernes databehov på de dataområder, som er en del af FLIS. Disse dataområder er i stadig bevægelse, både hvad angår tilgængelige data og kommunernes behov. Det betyder, at FLIS skal være fleksibel ift. ændringer i de tilstødende systemgrænseflader.

Når leverandører tilføjer felter i en tabel, som indgår i en leverance til FLIS, skal dette kunne håndteres med et minimalt indgreb i løsningen. Sådanne ændringer vil som udgangspunkt ske med 3 måneders varsel, men kan også være akut. Det kan ikke forudsættes at ske i forbindelse med en release af FLIS. Det er derfor nødvendigt, at sådanne tilpasninger kan integreres i FLIS’ datagrundlag mellem releases og med et minimalt indgreb i løsningen

Ændringer i eksterne systemgrænseflader
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Ændringer i eksterne systemgrænseflader, som ikke påvirker Datamartlaget skal kunne integreres i FLIS mellem releases og med et minimalt indgreb i løs- ningen.
Bemærkning:

For at give et indblik i omfanget af ændringer i de eksterne systemgrænseflader, ønskes her option på en generisk sag, som den kunne se ud.

Ændring af ekstern systemgrænseflade
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Der ønskes en ændring i en ekstern systemgrænseflade, som ikke påvirker Da- tamartlaget. Ændringen er varslet med 3 måneder og testdata foreligger 1 må- ned før idriftsætning. Selve ændringen indbefatter udvidelse med 20 felter, som ikke skal indgå i mapninger videre til EDW.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

4.3.3.8 Kobling til støttesystemerne

Systemet skal være forberedt på integration med støttesystemerne, når der åbnes op for generel ad- gang til disse.

Kobling til støttesystemerne, Klassifikation og Organisation
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal kunne koble til støttesystemerne Klassifikation og Organisation, og integrere data fra disse som f.eks. den autoriserede kontoplan som referen- cedata.
Bemærkning:

Kobling til støttesystemerne, Adgangsstyring
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Kommunerne skal kunne anvende støttesystemet Adgangsstyring til at admini- strere adgang til data i Systemet.
Bemærkning:

4.3.3.9 Kobling til Serviceplatformen

Systemet anvender nu sine egen SFTP servere til transport og lagring af indgående rådata og udgående datapakker.

Siden Systemet oprindeligt blev specificeret, er der blevet etableret services under Serviceplatformen, som håndterer transporten af filer (se xxx.xxxxxxxxxxxxxxxxx.xx). At anvende disse services under- støtter en solid fælleskommunal rammearkitektur, og giver Systemet mulighed for at fokusere på ker- neopgaven.

Overgang til Serviceplatformens SFTP-service kan ske gradvist, således at Systemet i en periode skal understøtte begge løsninger på tværs af leverandører og aftagere. Der er således behov for adskilte optioner på ind og udfasning af de respektive platforme.

Anvendelse af Serviceplatformens SFTP-service
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Systemet opsættes til at kunne hente rådata fra, og levere datapakker til, Ser- viceplatformens SFTP service. Systemet vil således skulle anvende en ftp-kli- ent i stedet for selv at hoste
Bemærkning:

4.3.4 Fysisk datamodel

Der er ingen nye krav relateret til dette afsnit, udover hvad der fremgår af øvrige bilag.

4.3.5 Logisk datamodel

Der er ingen nye krav relateret til dette afsnit, udover hvad der fremgår af øvrige bilag.

4.3.6 Regler / forretningslogik

4.3.6.1 Nye nøgletal

I forbindelse med den løbende vedligeholdelse af et dataområde ønskes ofte udviklet nye nøgletal på et eksisterende dataområde. Det kan både være i form af nye nøgletalstyper og som udvidelse med nye nøgletal, som anvender samme beregning, men med ændrede parametre.

Ny nøgletalstype
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal udvides en ny Nøgletalstype, dvs. at der på baggrund af eksiste- rende data i datamarten skal beregnes en tæller og en nævner, der kan indgå i en nøgletalsbrøk, som tilføjes til løsningens samling af nøgletal. Processen kan involvere dannelse af nye variable i de involverede datamarter, hvorfra data trækkes.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

Nyt nøgletal af eksisterende type
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemet skal udvides med et nyt nøgletal af en allerede eksisterende type, hvor kun 1-2 filtre eller variable skal udskiftes, men hvor der ikke skal dannes nye variable eller opstilles nye beregninger.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

4.3.7 Brugergrænseflade

Et stort antal af de nøgletal, som findes i Systemet og som løbende udvikles, er identiske med eksiste- rende nøgletal på nær ændring af enkelte filtre eller variable.

Eks.1 Der findes et stort antal nøgletal til sygefravær, som er identiske på nær afgrænsningen af hvilke konti, som personalet henføres til. Afgrænsningen foretages på funktionsniveau i Inden- rigsministeriets autoriserede kontoplan.

Eks 2. Der findes nøgletal på Økonomiområdet, som opgør forbrug på en enkelt funktion i kontopla- nen. Ved udskiftning af variablen ”Forbrug” med ”Oprindeligt budget” dannes ganske simpelt et andet nøgletal.

Der ønskes mulighed for funktionalitet, hvor KOMBIT kan danne sådanne simple tilrettede nøgletal, eller tilrette eksisterende, uden leverandørens direkte involvering på samme måde som visse metadata vedr. nøgletal kan tilrettes nu.

Tilretning og nyudvikling af simple nøgletal
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Der ønskes adgang for KOMBIT til direkte at danne nye og tilrette eksisterende nøgletal, hvor dette udelukkende involverer erstatning af eksisterende variable og filterværdier uden yderligere involvering af leverandøren. De udviklede nøg- letal lægges på eksternt testmiljø, hvorfra der er adgang til at teste beregnin- gerne og med mulighed for at introducere dem til PROD i forbindelse med med senere release. Der er behov for procedurer og vinduer for, hvornår nøgletal kan udvikles og forventes lagt på produktionsmiljøet.
Bemærkning:

4.3.8 Sikkerhed

4.3.8.1 Brugeradgang til systemet

I den nuværende løsning kan der ikke gives delvis adgang at hente datapakker. Brugere med adgang til en kommunes ftp-mappe har fuld læse- og skriveadgang til alle filer. Sikkerhedsmodellen for adgang til datafiler ønskes udvidet, således at datapakker fra et givent dataområde kan begrænses til enkelte brugere.

Modellen kan basere sig på afgrænsning til enkelte brugere ved bestilling af dataadministratorrollen eller en udvidet rollemodel, hvor brugere får adgang datapakker fra enkelte (eller alle) dataområder. Hovedsagen er, at sikkerheden styres på serveren, ikke i filen, og at automatiseret afhentning og ud- pakning ikke hindres.

Bruger- og sikkerhedsmodel
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Der ønskes en udvidelse af sikkerhedsmodellen, som understøtter en begræns- ning af adgang til datapakker, således at Dataadministratoren kan begrænse enkelte brugeres eller brugerrollers adgang til at hente datapakker på dataom- råder eller bestillingsniveau.
Bemærkning:

4.3.8.2 KOMBITs adgang til systemet

KOMBIT inddrages (jf. bilag XXX) i support på systemet, samt indgår i tæt dialog med leverandøren om den løbende udvikling og vedligeholdelse af Systemet. Til brug for dette har KOMBIT brug for læsead- gang til alle dataniveauer i test og produktionsmiljøet. Adgangen gives med VPN tunnel eller lignende til brug på KOMBITs egne udpegede lokationer.

KOMBIT skal have adgang til alle miljøer
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	KOMBIT skal have læseadgang til alle dataniveauer i test- og produktionsmil- jøet (rådata, DSA, EDW, DM og kuber)
Bemærkning:

4.3.9 Lovmæssige krav

Der er ingen nye krav relateret til dette afsnit ud over det, der fremgår af øvrige bilag.

4.3.10 Logning

Der er ingen nye krav relateret til dette afsnit ud over det, der fremgår af øvrige bilag.

4.3.11 Dokumentation

Eksport af OLAP-projekt mm.
Kategori:	(K)	Type:	Funktionelt
Beskrivelse:	Kommunerne skal have stillet de definitioner til rådighed, som gør det muligt at danne de kuber, som anvendes til rapportering i Systemet ved hjælp af et stan- dardværktøj. Det kan f.eks. være views til tilgang af udlæste datamart-filer samt et SSAS-olap projekt. Disse filer skal stilles til rådighed efter hver idriftsat æn- dring, typisk ved releases.
Bemærkning:

4.3.12 Driftsafvikling

4.3.12.1 Serviceydelse – Tilpasning af testmiljø

Tilpasning af testmiljø
Kategori:	(O)	Type:	Ikke-Funktionelt
Beskrivelse:	Der ønskes en ændring i datagrundlaget for testmiljøet, således at der fra alle kilder anvendes data, der er et år nyere. Hvis f.eks. data fra en datakilde tidli- gere indeholdt data fra maj 2011 til april 2014, skal det fremover være maj 2012 til april 2015.
Bemærkning:	Denne Option er generisk og skal danne baggrund for den samlede prissæt- ning.

4.3.12.2 Serviceydelse – Driftsstatus

Systemet har interessenter, hvis interesser varierer meget. Det kan være:

• Personalemedarbejderen, der kun vil vide, hvis data fra ét bestemt system i egen kommune er berørt

• Analysemedarbejderen, der arbejder med benchmarking af et dataområde i et nøgletalssamarbejde over et helt dataområde på tværs af en gruppe kommuner

• LIS-leverandøren, som ønsker viden om alle ændringer hos sine kunder

Der er derfor behov for detaljeret opmærkning af driftsstatus, som så til gengæld kan være dannet maskinelt ud fra emneopdelte skabeloner.

Driftsstatus med abonnement
Kategori:	(O)	Type:	Funktionelt
Beskrivelse:	Systemets hjemmeside skal indeholde en driftsstatus (jf. bilag 7.2). Denne sta- tus skal understøtte abonnementsordning til mail og rtl-feed el. lign. systemlæ- seligt format. Alle beskeder opmærkes med metadata om berørte kommuner, systemer, dataområder og berørt periode af data, samt startdato og forventet ophørsdato. Abonnementer skal kunne baseres på disse metadata.
Bemærkning:

5 Forventninger til leveranceforløbet og roadmap

I dette kapitel beskrives KOMBITs forventninger til Systemets leveranceforløb, herunder KOMBITs for- ventninger til indhold og tidsafgrænsning af de enkelte faser i projektet.

5.1 Det overordnede leveranceforløb

Det overordnede leveranceforløb består jf. Kontrakten af to faser, der hver er opdelt i tre etaper, hvor den sidste fase fortsætter iterativt.

Første fase er en Transitionsfase, der er opdelt i tre etaper:

Etape I: Afklaringsfase Formålet med Afklaringsfasen er bl.a. at sikre, at Projektet bliver

mobiliseret, herunder at Leverandøren og KOMBIT får fastlagt rammerne for det konkrete samarbejde og at sikre, at Leverandø- ren opnår yderligere forståelse for og indsigt i KOMBITs krav og behov. Umiddelbart efter kontraktunderskrift og efter dialog med Leverandøren meddeler KOMBIT dato for påbegyndelse af Afkla- ringsfasen. KOMBIT vil være parat til at kunne starte tidligst to (2) Arbejdsdage fra kontraktunderskrift, og Afklaringsfasen skal være påbegyndt senest XX dage efter kontraktunderskrift.

Samtidigt med at Etape I gennemføres, skal der udarbejdes en detaljeret tidsplan for Etape II, der skal godkendes seneste 15 dage, før Etape II påbegyndes.

Etape II: Transitionsetape Fasen omfatter migrering af det nuværende System til Leveran-

dørens eget driftsmiljø.

Etape III: Test og Godkendelse Endelig systemprøve, overtagelsesprøve og godkendelsesprøve

samt Transitionsfasen godkendes.

Anden fase samt de efterfølgende faser er Releasefaser, der er opdelt i tre etaper:

Etape I: Analyse og design Scope af ny release samt analyse og design af løsningen. Etape II: Udvikling Ny release udvikles

Etape III: Test og Godkendelse Den nye release testes og godkendes

Figur 8

5.2 KOMBITs forventninger til leveranceforløb

KOMBIT forventer, at Leverandøren har forståelse for, at faserne skal køres parallelt, hvor den første Releasefase skal påbegyndes samtidigt med, at Transitionsfasen gennemføres. Herefter vil der køre Releasefaser parallelt, der dog er forskudt i forhold til Etaperne, hvormed Leverandøren eksempelvis er i Etape III for en release og i Etape I for en anden release.

KOMBIT forventer, at Transitionsfasen er afsluttet og godkendt i produktionsmiljøet inden for 6 måne- der. Det vil dog være muligt for Leverandøren at tilkøbe sig ekstra driftsmåneder ud over de 6 mdr. ved den nuværende Leverandør.

KOMBIT forventer, at den første Releasefase, der vil indeholde integration af to nye dataområder, er afsluttet og godkendt i produktionsmiljøet inden udgangen af 2017.