Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Version 0.85 23-02-2015

Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 7 2 INDLEDNING... 8 2.1 UNDERBILAG... 8 2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER... 10 3 DEN SAMLEDE FORRETNINGSMÆSSIGE LØSNING... 11 3.1 BRUGERNE AF SYSTEMET... 11 3.2 BORGERNE... 11 3.3 KUNDERÅDGIVERNE... 12 3.4 FORRETNINGSADMINISTRATORER... 13 3.5 ROLLER OG RETTIGHEDER... 13 3.6 RISIKOVURDERING... 14 3.7 PERSONDATALOVEN... 14 3.8 FUNKTIONSADSKILLELSE... 14 3.9 DOKUMENTATION... 14 3.10 PRIVILEGEREDE ROLLER... 15 3.11 FORRETNINGSROLLER... 15 4 FORRETNINGSUDBUDSARKITEKTUREN... 16 4.1 FORRETNINGSUDBUDSARKITEKTUREN... 16 4.2 AUTOMATISERET OG MANUEL SAGSBEHANDLING... 17 4.3 KANALER OG KOMMUNIKATION... 17 4.4 ØVRIGE ELEMENTER I FORRETNINGSUDBUDSARKITEKTUREN... 18 5 KOMPONENTMODEL... 19 Bilag 3A Behovsopgørelse Side 1 af 78

5.1 MANUELT... 20 5.1.1 OPGAVEINDBAKKE... 21 5.1.2 MANUELLE BREVE... 21 5.1.3 SAGSHÅNDTERING... 21 5.1.4 TVÆRGÅENDE OVERBLIK... 22 5.1.5 SYSTEMADMINISTRATION... 22 5.1.6 REGELADMINISTRATION... 22 5.2 AUTOMATISK... 23 5.2.1 HÆNDELSER... 23 5.2.2 VALIDERING... 23 5.2.3 BESKEDHÅNDTERING... 23 5.2.4 DAN UDBETALING... 24 5.2.5 MODREGNING... 24 5.2.6 DAN OPKRÆVNING... 24 5.2.7 KONTROL... 24 5.2.8 BEREGNING AF YDELSER... 24 5.3 STØTTEKOMPONENTER... 25 5.3.1 PERSONDATA... 25 5.3.2 SAGER OG DOKUMENTER... 25 5.4 KANALER... 25 5.4.1 MODTAGELSE AF POST... 26 5.4.2 SELVBETJENING... 26 5.5 ØVRIGE KOMPONENTER... 26 5.5.1 SIKKERHED... 26 5.5.2 RAPPORTER... 26 5.5.3 JOBAFVIKLING... 27 5.5.4 ØKONOMI... 27 5.5.5 AFSTEMNING... 27 5.5.6 INDEKSSYNKRONISERING... 27 5.5.7 ARKIVERING... 28 6 FORRETNINGSPROCESSER... 29 Bilag 3A Behovsopgørelse Side 2 af 78

6.1 SAMLET PROCESKATALOG... 29 6.2 KERNEPROCESSER... 30 6.2.1 KERNEPROCES HÅNDTER INDBERETNING 1.4.1... 30 6.2.1.1 LF Familieydelser Håndter indberetning 1.4.1.1... 31 6.2.1.2 LF Familieydelser Håndter automatisk genererede oplysninger 1.4.1.2... 31 6.2.2 KERNEPROCES - TRÆF AFGØRELSE 2.4.1... 32 6.2.2.1 LF Familieydelser Træf afgørelse 2.4.1.1... 32 6.2.3 KERNEPROCES HÅNDTER DRIFT 2.4.2... 32 6.2.3.1 LF Pension - Dan udbetalingsgrundlag 2.4.2.1... 32 6.2.3.2 LF Familieydelser Udsend påmindelse om enlig-erklæring 2.4.2.2... 33 6.2.4 KERNEPROCES HÅNDTER UDBETALING 3.4.1... 33 6.2.4.1 LF Familieydelser Effektuer udbetaling 3.4.1.1.... 33 6.2.5 KERNEPROCES HÅNDTER OPKRÆVNING 3.4.2... 34 6.2.5.1 LF Familieydelser Dan krav 3.4.2.1... 34 6.2.6 TVÆRGÅENDE PROCES HÅNDTER POST 20.X.1... 34 6.2.7 TVÆRGÅENDE PROCES HÅNDTER TELEFONISK KONTAKT 20.X.2... 34 6.2.8 TVÆRGÅENDE PROCES HÅNDTER DATALEVERANCE 20.X.3... 35 6.2.9 TVÆRGÅENDE PROCES HÅNDTER WEBADGANG 20.X.4... 35 6.2.10 TVÆRGÅENDE PROCES HÅNDTER WEBSERVICE 20.X.5... 35 7 INFORMATIONSARKITEKTUR... 36 7.1 OVERORDNET BEGREBSMODEL FOR UDBETALING DANMARK... 36 7.2 BEGREBS- OG INFORMATIONSMODELLER FOR FORRETNINGSLØSNINGEN... 37 7.2.1 DOKUMENTATION TIL LEVERANDØR... 37 7.2.2 INFORMATIONSMODEL SAG... 38 7.2.2.1 Sag... 38 7.2.2.2 Sag - Nøgler og Egenskaber... 39 7.2.2.3 Sagens oprettelse og livsforløb... 40 7.2.2.4 Forskelle til sagsbegreb i Eksisterende Løsning... 42 7.2.3 PART... 43 7.2.4 SAGSDOKUMENTATION... 43 Bilag 3A Behovsopgørelse Side 3 af 78

7.2.5 INFORMATIONSMODEL FAMILIEYDELSER... 43 7.2.6 FAMILIEYDELSESAG... 43 7.2.6.1 Samlesag... 43 7.2.6.2 Delsag... 44 7.2.7 FAMILIEYDELSERGRUNDOPLYSNING... 44 7.2.8 FAMILIEYDELSESTYPE... 44 7.2.9 FAMILIEYDELSESYDELSE... 46 7.2.10 UDBETALING... 46 7.2.11 FAMILIEYDELSESYSTEMADMINISTRATION... 46 8 IT ARKITEKTUR... 47 8.1 IT-UDBUDSARKITEKTUREN... 47 8.2 SYSTEMKONTEKST OG INTEGRATIONER... 49 8.2.1 INTEGRATIONER OG INFRASTRUKTUR... 50 9 NON-FUNKTIONELLE KRAV TIL SYSTEMET... 53 9.1 ARKITEKTUR... 53 9.1.1 RAMMER FOR ARKITEKTUREN... 53 9.1.2 BELASTNING OG SKALERING... 53 9.1.2.1 Udbetalingskørsler... 53 9.1.2.2 Satsregulering... 54 9.1.2.3 Udsendelse af årlig påmindelse om enlig erklæring... 54 9.1.2.4 Årlig efterregulering... 54 9.1.2.5 Journaliser post på sagen... 54 9.1.2.6 Dataudtræk og øvrig rapportering... 54 9.2 DESIGN OG APPLIKATIONSSTRUKTUR... 54 9.3 LOGNING... 55 9.4 SYSTEMFLEKSIBILITET... 55 9.5 TILGÆNGELIGHED... 55 9.6 DATAKONVERTERING... 55 Bilag 3A Behovsopgørelse Side 4 af 78

9.6.1 KONVERTERINGSKONCEPTET GENERELT... 55 9.6.2 UDTRÆK AF DATA... 57 9.6.3 TRANSFORMERING AF DATA... 58 9.6.4 INDLÆSNING OG VIDEREFORDELING AF DATA... 59 9.6.4.1 Indlæsning af data i Systemet... 59 9.6.4.2 Viderefordeling af data og synkronisering med støttesystemer... 60 9.6.5 AFSTEMNING OG DATAVALIDERING... 61 9.6.6 GENNEMFØRSEL AF KONVERTERINGEN... 62 9.6.7 HÅNDTERING AF PRØVEUDTRÆK... 63 9.7 BRUGERVENLIGHED... 63 9.8 LOVGIVNING... 63 9.9 SIKKERHED... 63 9.10 MILJØER... 64 9.11 PROJEKTLEDELSE... 64 9.12 UDDANNELSE... 64 9.13 DOKUMENTATION... 64 9.14 IDRIFTSÆTTELSE... 65 9.15 HYPERCARE... 65 9.16 SAMARBEJDE OG RAPPORTERING... 65 9.17 TEST... 66 10 KRAV TIL DRIFT, VEDLIGEHOLDELSE, SUPPORT OG VIDEREUDVIKLING (YDELSERNE) 67 10.1 OVERORDNEDE KRAV... 67 10.2 ETABLERINGSYDELSEN... 68 10.2.1 ETABLERING AF LOKALITETER... 68 10.2.2 ETABLERING AF KOMMUNIKATIONSINFRASTRUKTUR... 68 10.2.3 ETABLERING AF PROGRAMMEL... 68 10.2.4 ETABLERING AF PROCESSER FOR DRIFTSAFVIKLING OG SUPPORT... 68 10.2.5 ETABLERING AF PROCESSER OG VÆRKTØJER TIL VEDLIGEHOLDELSE AF SYSTEMET... 68 10.3 VEDLIGEHOLDELSE OG VIDEREUDVIKLING AF SYSTEMET... 69 10.3.1 VEDLIGEHOLDELSE AF SYSTEMET... 69 Bilag 3A Behovsopgørelse Side 5 af 78

10.3.2 VIDEREUDVIKLING AF SYSTEMET... 71 10.4 LØBENDE DRIFT... 72 10.4.1 LOKALITETER... 72 10.4.2 INFRASTRUKTUR OG MASKINEL... 72 10.4.3 PROGRAMMEL... 72 10.4.4 TEKNOLOGISK RÅDGIVNING, RAPPORTERING OG SUPPORT... 72 10.4.5 DOKUMENTATION OG KONFIGURATIONSSTYRING... 73 10.4.6 SIKKERHED OG BEREDSKAB... 73 10.4.7 OVERVÅGNING... 73 10.4.8 OPHØRSBISTAND... 73 10.4.9 SERVICE OPERATION... 73 10.4.9.1 Supportløsningen... 73 10.4.10 INCIDENT MANAGEMENT... 74 10.4.11 PROBLEM MANAGEMENT... 74 10.4.12 CHANGE MANAGEMENT... 74 10.4.13 RELEASE MANAGEMENT... 75 10.4.14 EVENT MANAGEMENT - OVERVÅGNING... 75 10.4.15 CONFIGURATION MANAGEMENT... 75 10.4.16 CAPACITY MANAGEMENT... 75 11 FREMTIDIGE TILPASNINGER TIL SYSTEMET... 76 11.1 INTEGRATION TIL FRITAGELSE AF DIGITAL POST... 76 11.2 INTEGRATION TIL SKAT... 76 11.3 INTEGRATION TIL SAPA... 76 11.3.1 FORUDSÆTNINGSSYSTEMER FOR INTEGRATIONEN TIL SAPA... 76 11.4 INTEGRATION TIL GRUNDDATAFORDELER... 77 12 OPTIONER... 78 12.1 OPTION PÅ ORDINÆR FORLÆNGELSE... 78 12.2 OPTION PÅ UDSKYDELSESADGANG... 78 Bilag 3A Behovsopgørelse Side 6 af 78

1 Vejledning til Tilbudsgiver Bilaget skal ikke ændres af Tilbudsgiver. Tabel 1 Vejledning til Tilbudsgiver Bilag 3A Behovsopgørelse Side 7 af 78

2 Indledning Dette bilag indeholder en overordnet beskrivelse af ATP s krav til det nye System samt de øvrige krav til Leverandøren. Bilaget udgør sammen med tilhørende underbilag ATP s behovsopgørelse for Systemet. 2.1 Underbilag Bilaget har følgende underbilag: Bilag Bilag 3A.1 (Kravliste) Bilag 3A.2 (Løsningsflows) Bilag 3A.3 (Aktivitetsbeskrivelser) Bilag 3A.4 (Informationsmodeller) Bilag 3A.5 (Regel- og beslutningsmodeller) Bilag 3A.6 (Integrationer) Bilag 3A.7 (Brugergrænseflader) Bilag 3A.8 (Oversigter) Indhold Bilaget indeholder en liste over ATP s krav til Leverancen, hvor Leverandøren skal angive opfyldelsesgrad mv. i overensstemmelse med vejledningen til bilaget. Bilaget skal for en del krav læses i sammenhæng med de øvrige underbilag. Bilaget indeholder de løsningsflows, der indgår i de forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af familieydelser. Bilaget indeholder de aktivitetsbeskrivelser, der indgår i de løsningsflows og forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af familieydelser. Bilaget indeholder UML modeller af de væsentligste forretningsmæssige begreber og de informationer, som vedrører indberetning, administration og udbetaling af familieydelser. Bilaget indeholder standardiserede modeller af de regler af lovgivningsmæssig og anden karakter forbundet med indberetning, administration og udbetaling af familieydelser. Bilaget indeholder uddybende information om de integrationer, som Leverandøren skal etablere fra Systemet. Bilaget indeholder rammesættende wireframes for brugergrænseflader, der har til formål at give Leverandøren inspiration til design af brugergrænsefladerne i Systemet Bilaget indeholder følgende oversigter: Brevoversigt Hændelses- og ydelsesoversigt Akt LF - DM Regeloversigt Forretningsroller Informationsbehandling_gui Tabel 1 Behovsopgørelsen og tilhørende underbilag Bilag 3A Behovsopgørelse Side 8 af 78

Bilag 3A Behovsopgørelse Side 9 af 78

2.2 Farveanvendelse på arkitekturdiagrammer Der optræder en række arkitekturdiagrammer i bilagsmaterialet. Der er på tværs af alle disse figurer anvendt en farvekodning, som siger noget om, hvem der ejer eller anskaffer et system/komponent. Betydningen af farverne fremgår af Figur 1. Figur 1: Farveanvendelse på arkitekturdiagrammer. Bilag 3A Behovsopgørelse Side 10 af 78

3 Den samlede forretningsmæssige løsning Beskrivelsen af den forretningsmæssige løsning for familieydelser tager udgangspunkt i brugerne af Systemet; borgere, kunderådgivere, forretningsadministratorer og deres behov. Brugernes behov er i det efterfølgende skildret gennem: 3 Brugerne af Systemet hvornår og hvordan møder brugerne Systemet 4 Forretningsudbudsarkitekturen systemer, parter og sammenhænge 5 Komponentmodellen hvad Systemet skal understøtte 6 Forretningsprocesser tekniske understøttelse af de forretningsmæssige behov 7 Informationsarkitekturen beskrivelse og gruppering af forretningsmæssige begreber 3.1 Brugerne af Systemet Udgangspunktet for brugergrupperne af Systemet er forskelligt og de tre typer af brugere har forskellige behov. De forskellige brugeres anvendelse af Systemet er beskrevet i de følgende afsnit. 3.2 Borgerne Borgerne har grundlæggende behov for at kende og forstå de familieydelser, der er relevante i deres livssituation. De har behov for at forstå ansøgnings- og afgørelsesprocessen, samt kunne se deres udbetalinger, både historiske og fremtidige. Disse grundlæggende behov er afspejlet i de krav, der stilles til Systemet. Obligatorisk selvbetjening (element af den offentlige Digitaliseringsstrategi) stiller samtidig krav om, at der er selvbetjeningsløsninger, der imødekommer borgernes behov for at forstå og overskue processen. Selvbetjeningsløsningerne skal for at understøtte borgernes behov kunne: Indhente og udstille oplysninger om borgeren fra relevante autoritative systemer og registre, så borgeren ikke skal genindtaste oplysninger Give borgeren mulighed for at ændre i egne oplysninger og på den baggrund ansøge om familieydelser Angiv oplysninger i en kørende sag, fx ændringer i enlig status eller svar på partshøring/høring Bilag 3A Behovsopgørelse Side 11 af 78

Vedhæfte dokumentation Det skal foregå på en måde, hvor borgeren føler sig betrygget. Dette sikres primært ved gennemsigtighed i de oplysninger, der ligger til grund for beregningen og Borgeren skal desuden via selvbetjeningsløsningen kunne danne sig et overblik og indblik i egen sag, og skal derfor til enhver tid kunne se status og en oversigt over udbetalinger. Der henvises i øvrigt til: Bilag 2 (Situationsbeskrivelse), afsnit 4.1.6, der beskriver tankerne om borgerne på Borger.dk. Kravene til borgernes brugergrænseflader er beskrevet med udgangspunkt i disse Bilag 3A.1 (Kravliste), der indeholder de konkrete krav til selvbetjeningsløsningen Bilag 3A. 7 (Brugergrænseflader), der indeholder User experience guidelines (UX-guidelines) og inspirationsgivende wireframes som rammesætter ATP`s tanker om et brugervenligt og effektivt System. Bilag 7 (Servicemål), der indeholder de konkrete krav til svartider og tilgængelighed på selvbetjeningsløsningen (borgernes brugergrænseflader). 3.3 Kunderådgiverne For kunderådgiverne er et tværgående overblik med alle relevante oplysninger og mulighed for at foretage sagshåndtering, mens borgeren er i telefonen, altafgørende. Relevante oplysningerne er primært oplysninger om borgeren, sager, dokumenter, ydelser og journaler. Overblikket skal til enhver tid kunne tilpasses, så den enkelte kunderådgiver oplever et overblik, som er tilpasset den konkrete arbejdsopgave. En opgaveindbakke hvor alle opgaver er prioriteret og med sorterings- og udsøgningskriterier for kunderådgiverne er særdeles vigtig. Når en opgave åbnes skal alle relevante oplysninger og muligheden for at foretage sagshåndtering være til stede straks (efter samme princip som telefonisk henvendelse). En intuitiv og tilgængelig brugergrænseflade påvirker kunderådgiverens effektivitet i høj grad, hvorfor der både er fokus på brugervenlighed og svartider. Det handler om flow i opgaveløsningen og rådgivningssituationen, så mængden af klik, fejl og tid reduceres. Bilag 3A Behovsopgørelse Side 12 af 78

Der henvises i øvrigt til: Bilag 2 (Situationsbeskrivelse), Kapitel 6, der beskriver arbejdet med manuelle processer. Kravene til kunderådgivernes brugergrænseflader er beskrevet med udgangspunkt i disse. Bilag 3A.1 (Kravliste), der indeholder de konkrete krav til kunderådgivernes brugergrænseflade Bilag 3A.7 (Brugergrænseflader), der indeholder inspirationsgivende wireframes og UX-guidelines som rammesætter ATP`s tanker om et brugervenligt og effektivt System. Bilag 7 (Servicemål), der indeholder de konkrete krav til svartider og tilgængelighed på kunderådgivernes brugergrænseflader. 3.4 Forretningsadministratorer Systemet skal understøtte, at en forretningsadministrator kan rette og slette i regler, beslutninger, skabeloner og tekster, der styrer en automatiseret funktionalitet i Systemet. Et eksempel herpå kan være, at man retter en parameter til igangsættelse af en automatisk kørsel fra 14 til 10 dage eller opretter en ny manuel brevskabelon. Brugergrænsefladen skal være udformet, så den giver en logisk tilgang til dette arbejde og minimere risikoen for fejl. Der henvises i øvrigt til: Bilag 3A.1 (Kravliste), der indeholder de konkrete krav til forretningsadministratorernes brugergrænseflade. Bilag 3A.7 (Brugergrænseflader), der indeholder UX-guidelines som rammesætter ATP`s tanker om et brugervenligt og effektivt System. 3.5 Roller og rettigheder Det er et grundlæggende arkitekturkrav, at der anvendes roller til at styre adgang til data og funktioner. Adgangstildelingen skal være baseret på en risikovurdering og foregå i overensstemmelse med informationssikkerheds- og kontrolpolitikken i ATP. Det er ATP som tildeler brugerne (inklusiv Leverandørens medarbejdere og systembrugere) adgange og adgangene skal kunne styres via TIM (IBM Tivoli Identity management). I det følgende gennemgås grundprincipperne for opbygningen af rollerne, hvor risikovurdering, persondataloven, funktionsadskillelse, doku- Bilag 3A Behovsopgørelse Side 13 af 78

mentation og kontroller er vigtige elementer. Til sidst nævnes de forretningsroller som der på nuværende tidpunkt er identificeret behov for. 3.6 Risikovurdering Risikovurderingen skal foretages i forhold til de konkrete processer, som den pågældende rolle giver adgang til. Generelt vurderes det, at følgende risici skal overvejes ved opbygningen og vedligeholdelse af roller: fejl i transaktionsdata, fejl i stamdata, fejl i beregningsparametre, fejl i kørsler, overtrædelse af persondatalovens regler og besvigelser. Rolleopbygningen er (sammen med adgangstildelingen) en effektiv kontrol, når en risiko kan afdækkes ved funktionsadskillelse eller ved at begrænse adgang til transaktioner og data. 3.7 Persondataloven Persondataloven stiller krav til behandling af data. Ved behandling af data forstås adgang til at se, registrere, slette eller arkivere data. Ved design og vedligeholdelse af roller skal det sikres, at der kun tildeles adgange til personfølsomme oplysninger, hvis der er et kontinuerligt arbejdsrelateret behov. 3.8 Funktionsadskillelse ATP s informationssikkerhedspolitik stiller krav om, at der skal være grundlæggende funktionsadskillelse mellem a) udvikling og vedligeholdelse af systemer, b) drift og c) ATP s forretningsaktiviteter og brugerfunktioner. Dette betyder blandt andet at der ikke må tildeles IT roller til forretningen eller omvendt. Ved design af roller er det således væsentlig, at forretningsopgaver ikke lægges i IT-roller og IT-opgaver ikke lægges i forretningens roller. Inden for ATP s forretningsaktiviteter, skal der ligeledes etableres funktionsadskillelse, der sikrer, at samme person ikke alene kan initiere, udføre og godkende transaktioner. 3.9 Dokumentation Rollerne og de tilhørende rettigheder skal dokumenteres i en rolle/rettighedsmatrice. I rolle/rettighedsmatricen skal rollerne stå nævnt vandret og de tilhørende rettigheder lodret. Det skal for hver rettighed være angivet om der er tale om oprette-, læse-, opdatere- og/eller sletterettigheder. Matricerne skal til enhver tid holdes opdaterede, så de altid afspejler virkeligheden. Rettighedstabellerne kan ændres ved konstruktion af nye funktioner/transaktioner, ændrede funktioner eller nye forretningsmæssige behov. Der vil uvilkårligt ske ændringer, både som følge af udvikling af ny funktionalitet og som følge af forretningens ønsker om tilpasning af roller og arbejdsfunktioner. Bilag 3A Behovsopgørelse Side 14 af 78

Roller bør ikke anskues enkeltstående og derfor bør kombinationen af roller vurderes. Det er vigtigt, at der ikke tildeles roller, som er konfliktende. Konfliktende roller skal derfor identificeres og dokumenteres. 3.10 Privilegerede roller Leverandøren skal levere en beskrivelse af, hvilke privilegerede roller de ønsker til deres egne medarbejdere. Beskrivelsen skal samtidig indeholde de funktioner, som kan udføres af den enkelte rolle. Rollerne skal godkendes af ATP, men ansvaret for opdatering ligger hos leverandøren. Der skal være en revisionsmæssig gennemgang (intern audit) af hvilke medarbejdere, der har hvilke roller 2 gange årligt. ATPs sikkerhed er en revisionspåtegning i leverandørens regnskab. 3.11 Forretningsroller ATP har defineret et antal forretningsroller. Rollerne er ordnet i en matrix, der angiver hvilke pakker af informationer fra familieydelsesområdets informationsmodel, den enkelte rolle skal have adgang til. Der skelnes mellem at: oprette (C), læse (R), opdatere og slette (CRUD), jf. bilag 3A.8 (Oversigter), fane Forretningsroller. Det er ikke alle informationer i en pakke, som de enkelte roller skal have adgang til. I Etape II, jf. bilag 1 (Tidsplan) skal leverandøren, som en del af Delleverancerne, i samarbejde med ATP specificere forretningsrollernes adgang til informationer på klasse- og attributniveau og mappe dem til systemroller. Bilag 3A Behovsopgørelse Side 15 af 78

4 Forretningsudbudsarkitekturen I dette afsnit beskrives forretningsudbudsarkitekturen, som den ser ud ved implementering af det nye System. Herefter beskrives Systemet via en komponentmodel. 4.1 Forretningsudbudsarkitekturen Forretningsudbudsarkitekturen beskriver dels sammenhænge mellem de forskellige systemer, registre og parter i den forretningsmæssige løsning og dels den ønskede forretningsmæssige funktionalitet. Modellen og den efterfølgende forklarende tekst tjener som introduktion til Familieydelsesløsningen på et konceptuelt plan. Figuren nedenfor viser de væsentligste elementer i forretningsudbudsarkitekturen. Figur 2: Forretningsudbudsarkitektur for familieydelser Den samlede forretningsmæssige løsning består af selve fagsystemet, illustreret ved udvalgte forretningskomponenter med blå farve. Denne del er specifik for Systemet til administration af familieydelser, mens de øvrige dele af figuren viser samspillet med omkringliggende systemer. For at bevare overblikket er kun udvalgte systemer illustreret i forretningsudbudsarkitekturen. I nogle tilfælde er systemer Bilag 3A Behovsopgørelse Side 16 af 78

slået sammen og repræsenteret ved én kasse, og konkrete systemnavne er navngivet ved den primære funktionalitet, de leverer frem for konkrete systemnavne. Vi henviser til bilag 3A.6 (Integrationer) for en komplet oversigt over de eksterne systemer, som Systemet skal integrere til. 4.2 Automatiseret og manuel sagsbehandling Denne del er selve Systemet, hvor man finder it-understøttelse til administration af familieydelsessagerne. De blå kasser repræsenterer forretningskomponenter, der beskrives i afsnit 5. Systemet er at betragte som en hel løsning, hvor både automatiseret og manuel funktionalitet er placeret. Dette betyder, at kunderådgiverne arbejder i Systemet som deres primære systemunderstøttelse og her løses stort set alle deres opgaver. En forudsætning, for at ATP kan realisere det effektiviseringspotentiale, der fremgår af ATP s businesscase, er, at sagsbehandlingen automatiseres i vid udstrækning. Dette er særdeles vigtigt for de løsningsflows i bilag 3A.2 (Løsningsflows), der er kategoriseret som motorveje eller landevej, jf. bilag 2A (Sådan forretningsmodellerer vi i ATP). Systemet indeholder den funktionalitet og sikrer adgang til de data, der er behov for i forhold til at behandle en i given arbejdspakke eller sag. Dokumenter, journalnotater og digital post er endvidere placeret på sager og er journaliseret i Systemet. Systemet skal understøtte ønsket om at gennemføre STP ( straight through processing ) i videst muligt omfang, uden at det går ud over kvaliteten af sagsbehandlingen. Princippet er, at sagerne så vidt muligt fødes automatisk på baggrund af besked fra Beriget Grunddata om ny fødsel. Herefter vil ændringer til sagen komme fra autoritative registre og i selvbetjeningsløsningen og behandles så automatisk som muligt i Systemet. I de tilfælde, hvor der er behov for manuel sagsbehandling, sendes en opgave videre til kunderådgivernes opgaveindbakke i Systemet. 4.3 Kanaler og Kommunikation Her vises de kanaler, der bruges til borgerrettet kommunikation og koordinering af sager med borgerens kommune og/eller udenlandske myndigheder. En vigtig del af løsningen er selvbetjeningsløsningen på borger.dk, som skal give borgere nem adgang til ansøgning om ydelser, indberetning af oplysninger og mulighed for at se oplysninger og generel vejledning. Derudover illustrerer forretningsarkitekturen også, at vi modtager fysisk og Digital Post gennem hhv. Scanning Fysisk Post og Digital Post. Bilag 3A Behovsopgørelse Side 17 af 78

Afsendelse af post vil ske til Fjernprint, der videresender beskeder til Digital Post eller printer, kuverterer og afsender fysisk post, hvis modtager er undtaget fra Digital Post. 4.4 Øvrige elementer i forretningsudbudsarkitekturen De øvrige dele af forretningsudbudsarkitekturen er tværgående (indenfor Udbetaling Danmark) støttesystemer, komponenter eller registre, som Systemet skal have grænseflader til. De tværgående dele understøtter interne behov for rapportering, forpligtelser i forhold til ekstern rapportering og udbetaling. Bemærk at en fuldstændig liste over integrationer findes i afsnit 8 IT arkitektur. Bilag 3A Behovsopgørelse Side 18 af 78

5 Komponentmodel Den funktionalitet, som Systemet skal besidde, beskrives i form af en Komponentmodel. Til forskel fra forretningsudbudsarkitekturen, så omhandler Komponentmodellen kun den fagspecifikke løsning. Komponentmodellen illustrerer, hvordan Systemet er tænkt opdelt i forretningsmæssige logiske komponenter, der leverer beslægtet funktionalitet. Komponentmodellen og de efterfølgende komponentbeskrivelser har to formål: at give et overblik over den funktionalitet, Systemet skal indeholde. at gøre os i stand til at italesætte og kategorisere Systemets funktionalitet fra et forretningsmæssigt perspektiv. Leverandøren må gerne byde ind med forslag til en anden opdeling end den viste, hvis det er mere fordelagtigt set ud fra Leverandørens systemopbygning. Det er blot vigtigt, at Leverandøren tydeliggør, hvordan løsningen samlet leverer den beskrevne funktionalitet i forhold til komponentmodellen. Generelt skal de komponenter, som indeholder funktionalitet, der ændres hyppigt, fx ved lov- og regelændringer, kunne ændres smidigt. Dette gælder desuden også for funktionalitet til håndtering af hændelser, beslutning om sager skal til manuel kontrol, beregning af ydelser og modregningsregler. Derfor skal komponenternes funktionalitet kunne ændres igennem skærmbilleder, hvor ATP s forretningsadministratorer kan konfigurere regler og parametre til regler. Bilag 3A Behovsopgørelse Side 19 af 78

Figuren nedenfor viser komponentmodellen for familieydelser. Figur 3: Komponentmodel Komponentmodellen er inddelt i fem hovedområder: Manuelt Automatisk Støttekomponenter Kanal Øvrige komponenter De følgende afsnit gennemgår komponenterne i modellen enkeltvis og præsenterer overordnet den funktionalitet, som komponenterne leverer. De detaljerede krav til komponenterne er listet i bilag 3A.1 (Kravlisten). 5.1 Manuelt Denne gruppe af komponenter understøtter kunderådgivernes daglige manuelle sagsbehandling (jf. afsnit 3.3): Opgaveindbakke, Sagshåndtering, Tværgående overblik og Manuelle breve Bilag 3A Behovsopgørelse Side 20 af 78

Disse fire komponenter udgør tilsammen kunderådgivernes primære arbejdsredskab. De er her beskrevet i separate komponenter, men skal ikke betragtes som enkeltstående skærmbilleder. Deres funktionalitet kan med fordel integreres i samme skærmbillede, så kunderådgiverne herved får mulighed for at udføre deres arbejde på en effektiv måde. Den samlede funktionalitet, der er beskrevet her og i bilag 3A.1 (Kravliste), skal være til stede i Systemet. Komponenterne, som understøtter forretningsadministratorerne i deres arbejde er beskrevet i nedenstående komponenter (jf. afsnit 3.4): Systemadministration Regeladministration 5.1.1 Opgaveindbakke Udgangspunktet for det daglige arbejde for en kunderådgiver er Opgaveindbakken. Opgaveindbakken indeholder opgaver, som er struktureret i arbejdspakker. En opgave kan bestå af behandling af indscannede blanketter eller hændelser, som Systemet ikke har kunnet eller kan håndtere automatisk, jf. bilag 3A.5 (Regel og beslutningsmodeller). En kunderådgiver skal kunne reservere og arbejde med en opgave. 5.1.2 Manuelle Breve Denne komponent har ansvaret for at administrere og vedligeholde brevskabeloner til udsendelse af manuelt udarbejdede breve. Disse breve sendes ad samme kanal til Fjernprint som de automatisk genererede breve. Fjernprint styrer om brevet til borgeren og/eller myndigheden skal sendes som fysisk post eller digital besked. Kunderådgiveren skal kunne genere et brev med udgangspunkt i prædefinerede brevskabeloner, og forretningsadministratoren skal kunne oprette nye skabeloner samt rette i eksisterende. 5.1.3 Sagshåndtering Denne komponent leverer en brugergrænseflade, hvorfra kunderådgiveren udfører manuel sagsbehandling, og hvor familieydelsesdata kan vises og redigeres. Bilag 3A Behovsopgørelse Side 21 af 78

5.1.4 Tværgående Overblik Systemet skal kunne præsentere et Tværgående Overblik, der samler alle relevante informationer om den enkelte borger. Det Tværgående Overblik er kunderådgiverens indgangsvinkel til Systemet ved telefonrådgivning. Formålet er at give kunderådgiveren mulighed for, ved ét enkelt opslag, hurtigt at få et overblik over borgerens personlige forhold. Fra det Tværgående Overblik skal kunderådgiveren have mulighed for at få præsenteret yderligere detaljer om en sag og personen. Det Tværgående Overblik viser data fra både Systemet og fra Sags- og Dokumentindeks og fra Ydelsesindeks (se afsnit 8.2 Systemkontekst). 5.1.5 Systemadministration Systemadministration er en brugergrænseflade, hvor man kan ændre forskellige systemopsætninger som brevskabeloner, arbejdspakker, tekster, hjælpeinformation og genvejstaster. I denne komponent oprettes og ændres også de familieydelsestyper, som kan bevilges i Systemet. 5.1.6 Regeladministration For ATP er det væsentligt, at systemet er fleksibelt og robust for indførsel af nye forretningsprocesser og ændret lovgivning. Vi forventer, at der sker en løbende tilpasning af regler for, hvad der håndteres automatisk, og hvad der skal behandles manuelt. Det er væsentligt for optimeringen af arbejdsprocesserne, at disse tilpasninger kan ske smidigt og uden store implementeringsomkostninger. Komponenten Regeladministration indeholder de nødvendige og tilstrækkelige beregningsparametre til at træffe afgørelser om familieydelser og ydelsesberegninger. Komponenten leverer en brugergrænseflade til at vedligeholde de regler, parametre og grænseværdier, der anvendes til at udføre validering, kontrol, afgørelse (beslutning), beregning af ydelse og skatteberegning. Under skatteberegning også beregning af ATP-bidrag og bidrag til Supplerende Arbejdsmarkedspension. I Regeladministration vedligeholdes også regler for hvilke processer, der skal igangsættes når hændelser indtræffer. De konkrete krav til parameterstyring og konfiguration af Systemet fremgår af bilag 3A.1 (Kravliste). Bilag 3A Behovsopgørelse Side 22 af 78

5.2 Automatisk Denne gruppe af komponenter understøtter den automatiske sagsbehandling af primært motorvejene og består af følgende komponenter: Hændelser Validering Beskedhåndtering Dan udbetaling Modregning Dan opkrævning Kontrol Skatteberegning Beregning af ydelser 5.2.1 Hændelser Hændelser har ansvaret for at styre et automatiseret flow i fagsystemet efter en given ændring i interne eller eksterne registre. Komponenten igangsætter den proces, der følger efter en given ændring i eksterne eller interne registre. Det sker på baggrund af de regler, der er gældende for den aktuelle proces. 5.2.2 Validering Denne komponent har ansvaret for at validere inputdata såsom ansøgninger og ændringer til Systemet. Valideringen skal sikre konsistens i Systemets data, således, at beløb f.eks. ikke indtastes i datofelter. Validering kan både ske på feltniveau (enkelt attribut validering) og ved at vurdere sammenhænge mellem flere forskellige informationer. Det sker ud fra et sæt af beslutningsregler, der er implementeret i komponenten Regeladministration. Validering udstiller services til Selvbetjening jf. bilag 3A. (Kravliste), komponenten Validering ). 5.2.3 Beskedhåndtering Beskedhåndtering initierer udsendelse af beskeder til Fjernprint, som afgør om beskeden sendes som Digital Post eller fysisk brev til borgeren. Komponenten indsamler informationer og genererer automatisk beskeden/brevet. På baggrund af retursvaret fra Fjernprint registreres den anvendte afsendelseskanal. Bilag 3A Behovsopgørelse Side 23 af 78

Beskedhåndtering indeholder desuden en brugergrænseflade til konfiguration af beskeder/breve. Komponenten muliggør oprettelse og vedligehold af besked- /brevskabeloner med tilpasning og for udfyldelse af tekstblokke. 5.2.4 Dan Udbetaling Komponenten skal samle og overføre udbetalinger til udbetalingssystemet. Den registrerer udbetalingsdata og danner udbetalingsfiler. 5.2.5 Modregning Komponenten Modregning effektuerer modregninger i familieydelser for krav, der indmeldes fra Debitor. Komponenten har ansvar for at danne udbetalingsposter til fordringshavere for de modregninger den foretager. 5.2.6 Dan Opkrævning Dan opkrævning skal kunne danne krav, der sendes til Debitor. 5.2.7 Kontrol Kontrol behandler ansøgninger, indberetninger og ændringer efter, at Validering succesfuldt har valideret inputdata. Komponenten udfører kontroller ved inddragelse af yderligere data end de, der direkte danner grundlag for berettigelse til ydelser. Et eksempel på en kontrol kunne være om en enlig mor får barn med samme far som hun har andre børn med. Kontrollerne sker kun på de data, der er til rådighed i Systemet fra autoritative kilder og borgeren selv. Komponenten henter således ikke data fra andre systemer. Kontrollerne skal konfigureres ud fra et sæt af beslutningsregler, som er defineret i Regeladministration. Hvis en eller flere af kontrolbetingelserne er opfyldt adviseres en kunderådgiver herom for videre inspektion af sagens oplysninger og yderligere kontroller. Komponenten har også ansvar for at levere udtræk af data, vedrørende manuelle handlinger i systemet til brug for kontrol af svig i ATP s Kvalitetscenter. 5.2.8 Beregning af Ydelser Beregning af Ydelser indeholder beregningsfunktionaliteten for alle typer familieydelser. Komponenten træffer en afgørelse om berettigelse til familieydelser på baggrund af relevante oplysninger, så som børn, adresse, civilstand, indkomst mm. Herefter oprettes en økonomisk effektueringsplan som afspejler de ydelser borgeren er tilkendt. Bilag 3A Behovsopgørelse Side 24 af 78

Hvis ændringer i beregningsgrundlaget resulterer i, at der skal rettes et krav mod borgeren, hvilket fx kan ske efter den årlige efterregulering af Børne- og ungeydelsen, sender komponenten automatisk en opkrævning til Debitor, hvorfra beløbet opkræves. Opkrævningen kan enten ske ved udsendelse af et girokort til borgeren eller ved modregning i kommende familieydelsesudbetalinger i Systemet. Beregningen baserer sig på de beslutningsregler og beslutningsparametre, der er defineret for tilkendelse og ydelsesberegning i komponenten Regeladministration, jf. bilag 3A.5 (Regel- og beslutningsmodeller). 5.3 Støttekomponenter Denne gruppe af komponenter varetager informationer om borgere fra autoritative registre samt sager og dokumenter: Persondata Sager og dokumenter 5.3.1 Persondata Denne komponent har ansvaret for at hente og gemme persondata fra Beriget Grunddata. Komponenten udstiller disse informationer for de øvrige komponenter i Systemet. Komponenten skal vedligeholde de ydelsesspecifikke persondata som ikke vedligeholdes i det tværgående støttesystem, Beriget Grunddata. Dette drejer sig f.eks.om samlivsstatus og undtagelse for obligatorisk selvbetjening, som kunderådgiveren kan opdatere igennem Systemet. 5.3.2 Sager og dokumenter I Systemet bliver alle sags- og ydelsesinformationer gemt i Sager & Dokumenter. Denne komponent er en database, som vedligeholder metadata for sager og dokumenter og holder referencer mellem sager og dokumenter. Til gruppen af dokumenter hører blandt andet blanketter, beskeder fra Digital Post, breve, post, og andet bilagsmateriale som ATP modtager eller selv udsender. 5.4 Kanaler Denne gruppe af komponenter angiver hvordan Systemet skal fungere sammen med ATP s postmodtagelse og Systemets selvbetjeningsløsning: Modtagelse af post Selvbetjening Bilag 3A Behovsopgørelse Side 25 af 78

5.4.1 Modtagelse af post Systemet skal kunne modtage digital og fysisk post fra borgere og myndigheder. Den digitale post hentes af en posthåndteringsleverandør, inden den overleveres til Systemet igennem en snitflade. Samme posthåndteringsleverandør modtager fysisk post, som overleveres til Systemet ad samme snitflade. 5.4.2 Selvbetjening Selvbetjening leverer en webbaseret løsning, som udstilles på Borger.dk. Selvbetjeningsløsningen anvendes af borgere til ansøgning om familieydelser, indberetning af oplysninger samt til at udstille informationer om borgerens sag og vejledning. Derudover kan borgerne foretage en simulering af hvor meget, den enkelte forventes at få udbetalt (jf. afsnit 3.2) Selvbetjening udstiller og modtager indtastede data og sender disse til Systemet for validering og eventuel registrering. 5.5 Øvrige Komponenter Denne gruppe indeholder Systemets øvrige komponenter: Sikkerhed Rapporter Jobafvikling Økonomi Afstemning Indekssynkronisering Arkivering 5.5.1 Sikkerhed Sikkerhed har ansvaret for konfiguration og administration af sikkerhed, herunder rolle og rettighedsstyring i forhold til de brugerrettede dele af systemet. Sikkerhed har desuden ansvaret for håndtering af log on på Systemet og Selvbetjeningsløsningen. 5.5.2 Rapporter Rapporter har ansvaret for, at der kan dannes dataudtræk til interne ATP-systemer og eksterne rapporter til forskellige samarbejdsparter primært offentlige instanser. Bilag 3A Behovsopgørelse Side 26 af 78

Ud over informationer på familieydelsessagerne leverer komponenten også informationer om interne processer i Systemet, f.eks. hvor mange opgaver, der er oprettet på baggrund af en bestemt regel. Disse informationer anvendes til løbende driftsoptimering i ATP. Komponenten har en brugergrænseflade, som muliggør at forretningsadministratorer selv kan definere rapporter i Systemet. 5.5.3 Jobafvikling Komponenten har ansvaret for at håndtere driftflows for interne hændelser i fagsystemet, hvilket typisk drejer sig om batchkørsler. Komponenten vedligeholder regler for kørselstidspunkter og flowregler for afvikling af de automatiske kørsler. 5.5.4 Økonomi Systemet overfører posteringer til ATP`s ERP system i forbindelse med udbetalinger, dannelse af opkrævninger, ændringer til udbetalinger etc. Systemets kontonumre skal stemme overens med de kontonumre som anvendes i ERP, så sumposteringer etc. placeres korrekt i forbindelse med en overførsel. Samlet set sikrer denne dataudveksling, at regler til understøttelse af regnskabslovgivning samt gældende revisionskrav kan overholdes. 5.5.5 Afstemning Afstemning leverer afstemningsdata fra fagsystemet til videre behandling. Afstemning har ansvaret for at udtrække og samle afstemningsdata fra fagsystemet, for at sikre retvisende regnskab. Komponenten har ansvar for at levere logning på data, som udsendes til andre systemer, sådan at der kan foretages afstemninger på grænseflader. Komponenten har ligeledes ansvar for at foretage afstemning af interne dataflyt i Systemet. 5.5.6 Indekssynkronisering Systemet henter sags- og ydelsesinformationer fra de fælleskommunale støttesystemer Sags- og dokumentindeks og Ydelsesindeks. Systemet skal tilsvarende levere sags- og ydelsesinformationer for familieydelsessager til de samme indekser, dels for at stille informationerne til rådighed for kommunerne, men også for at kunne etablere et opdateret overblik i KMD Sag jf. for- Bilag 3A Behovsopgørelse Side 27 af 78

retningsudbudsarkitektur i afsnit 3.1, i den overgangsperiode hvor nogle af ydelsesområdernes systemunderstøttes der. Samlet sikrer denne dataudveksling, at kunderådgiverne har et overblik over sager i både Udbetaling Danmark og i kommunerne. 5.5.7 Arkivering Komponenten har ansvaret for sikre korrekt og lovmedholdelig arkivering af sager. Dvs. sikre at Udbetaling Danmark overholder opbevaringspligten, og at lukkede sager markeres til kassation på det rette tidspunkt. Efter udløb af opbevaringspligten skal Systemet automatisk gennemløbe sagerne og slette sager der ikke længere skal opbevares. I det omfang der træffes beslutning om at der skal afleveres til Statens Arkiver skal komponenten håndterer denne afleveringen af data. Bilag 3A Behovsopgørelse Side 28 af 78

6 Forretningsprocesser Forretningsprocesserne beskriver en mulig understøttelse af de forretningsmæssige behov. For en detaljeret visning af forretningsprocesserne henvises til bilag 3A.2 (Løsningsflow) og for en detaljeret beskrivelse af de enkelte aktiviteter henvises til bilag 3A.3 (Aktivitetsbeskrivelser). Desuden henvises til den klikbare version af processerne. Den metodemæssige tilgang til forretningsmodellering i ATP er beskrevet i bilag 2A (Sådan forretningsmodellerer vi i ATP). 6.1 Samlet proceskatalog Processerne markeret i den grønne ramme i proceskataloget angiver de forretningsmæssige kerneprocesser, der benyttes i administrationen af familieydelser. Figur 4 Samlet procesoverblik Bilag 3A Behovsopgørelse Side 29 af 78

Nederst i figuren vises de kommunikations-, styrings-, drifts- og støtteprocesser som er tværgående for hele Udbetaling Danmark. I de efterfølgende afsnit vil kerneprocesserne samt de tværgående kommunikationsprocesser blive beskrevet. De øvrige processer beskrives ikke yderligere i udbudsmaterialet. Niveau 1 - Procesområde Niveau 2 Niveau 3 Løsningsflow Indberetning Håndter indberetning 1.4.1 LF Familieydelser Håndter indberetning 1.4.1.1 LF Familieydelser Håndter automatisk genererede oplysninger 1.4.1.2 Administration Træf afgørelse 2.4.1 LF Familieydelser Træf afgørelse 2.4.1.1 Håndter drift 2.4.2 LF Familieydelser Dan udbetalingsgrundlag 2.4.2.1 LF Familieydelser Udsend påmindelse om enlig-erklæring 2.4.2.2 Udbetaling Håndter udbetaling 3.4.1 LF Familieydelser Effektuer udbetaling 3.4.1.1 Håndter opkrævning 3.4.2 LF Familieydelser Dan krav 3.4.2.1 Kommunikation Håndter post 20.x.1 LSF Modtag post LSF Afsend post Håndter telefonisk kontakt 20.x.2 LSF Modtag telefonopkald LSF Foretag telefonopkald Håndter dataleverance 20.x.3 LSF Modtag dataleverance LSF Afsend dataleverance Håndter webadgang 20.x.4 LSF Modtag henvendelse via www LSF Modtag log-in oplysninger Håndter webservice 20.x.5 LSF Besvar webservicekald LSF Foretag webservicekald Tabel 2: Oversigt over procesområder og løsningsflows 6.2 Kerneprocesser Kerneprocesserne beskriver hvordan Udbetaling Danmark indberetter, administrerer og danner udbetalinger for familieydelsesområdet. Kerneprocesserne er nedbrudt i Løsningsflows (LF), som er yderligere beskrevet i afsnittene nedenfor. 6.2.1 Kerneproces Håndter indberetning 1.4.1 Processen håndterer opstart og indberetning af oplysninger fra en person eller myndighed, samt modtagelse og håndtering af automatisk generede oplysninger fra registre. Kerneprocessen Håndter Indberetning består af følgende løsningsflow: LF Familieydelser - Håndter indberetning 1.4.1.1 LF Familieydelser Håndter automatisk genererede oplysninger 1.4.1.2 Bilag 3A Behovsopgørelse Side 30 af 78

6.2.1.1 LF Familieydelser Håndter indberetning 1.4.1.1 Det centrale i dette løsningsflow er selvbetjeningsløsningen, som giver personer mulighed for dels at orientere sig på området og se aktuelle oplysninger om egen sag, og dels at søge om Familieydelser eller angive oplysninger til en verserende sag. Desuden modtages indberetninger fra personer og myndigheder via brev eller telefon. Disse behandles af en kunderådgiver i Systemets brugergrænseflade. Processen starter når en person anvender selvbetjeningsløsningen på Borger.dk. Hvis der ikke logges på med NemID er løsningen begrænset til muligheden for at se og læse generelle oplysninger om området, samt benytte simulering/beregning af ydelser. Hvis der logges på selvbetjeningsløsningen henter Systemet de oplysninger, der er til rådighed om personen, og herefter har vedkommende mulighed for at søge om familieydelser eller angive oplysninger til aktuelle sager, fx en erklæring som enlig eller svar på en partshøring. Når en person har søgt om en ny ydelse eller angivet oplysninger, er det muligt at vedhæfte dokumentation til Udbetaling Danmark. Afslutningsvis vælger personen at indsende ansøgningen/oplysningerne eller at gemme som kladde. Når en ansøgning eller oplysninger er sendt til Udbetaling Danmark, viser Systemet en kvittering på selvbetjeningsløsningen, og desuden sendes besked til eboks. Hvis sagen kan afgøres straks (sker i flowet Træf afgørelse) vil afgørelsen blive udstillet sammen med kvitteringen. 6.2.1.2 LF Familieydelser Håndter automatisk genererede oplysninger 1.4.1.2 Formålet med dette løsningsflow er oprettelsen af nye sager og modtagelse og registrering af data fra interne og eksterne registrer. Hver gang et barn bliver født eller bliver tildelt et CPR nummer (fx ved indrejse i Danmark) modtager Beriget Grunddata besked. Der opsættes herefter automatisk et abonnement til Familieydelser i Beriget Grunddata, og oplysningen om det nye barn samt øvrige stamoplysninger sendes til Systemet. Ved modtagelse af data fra Beriget Grunddata opretter og opdaterer Systemet en sag og tilhørende delsager, hvorefter sagen sendes videre til Træf afgørelse. Det hele sker automatisk uden inddragelse af kunderådgiver eller person. Langt de fleste af sagerne i Familieydelser oprettes i dette flow. Denne proces viser også de ændringer som løbende modtages i Systemet. Dels abonneres på oplysninger om ydelsesmodtagere, der kan have betydning for be- Bilag 3A Behovsopgørelse Side 31 af 78

rettigelsen til familieydelser, og dels indrapporteres nogle oplysninger fra kommunerne eller udenlandske myndigheder. Når nye oplysninger modtages bestemmes det om de har betydning for en sag, og i givet fald sendes sagen til Træf afgørelse for en genvurdering af berettigelsen. 6.2.2 Kerneproces - Træf afgørelse 2.4.1 Processen håndterer overordnet set validering af informationer og kontrolbehov, beregning af ydelsen samt selve afgørelsen, der kan være en bevilling eller et afslag. Kerneprocessen Træf afgørelse består af løsningsflowet: LF Familieydelser Træf afgørelse 2.4.1.1. 6.2.2.1 LF Familieydelser Træf afgørelse 2.4.1.1 Formålet med processen er at træffe afgørelse om en persons berettigelse til en given familieydelse. Processen er startet i Håndter indberetning eller Håndter automatisk genererede oplysninger. Systemet starter med at fremskaffe nødvendige data om ansøger. Data valideres og på baggrund heraf og ud fra gældende regler bestemmes behovet for kontrol og/eller kontakt til personer, der er relevante for sagen. Systemet bestemmer ligeledes om personen er berettiget og beregner en eventuel ydelse. Når hele processen er gennemført afgøres sagen, og der sendes besked til personen via brev og selvbetjening. Hvis der skal udbetales, fortsætter processen i Dan udbetalingsgrundlag. Er der undervejs et behov for manuel kontrol, så danner Systemet en opgave, som lægges i en arbejdspakke. En kunderådgiver vil så via Opgaveindbakken behandle opgaven og evt. indhente yderligere information. Herefter lægges sagen tilbage til det automatiske flow. 6.2.3 Kerneproces Håndter drift 2.4.2 Processen håndterer overordnet set klargøring af udbetalingerne og den årlige kontrol af enlig status. Kerneprocessen består af løsningsflowene: LF Familieydelser Dan udbetalingsgrundlag 2.4.2.1 LF Familieydelser Udsend påmindelse om enlig-erklæring 2.4.2.2 6.2.3.1 LF Pension - Dan udbetalingsgrundlag 2.4.2.1 Formålet med processen er at bestemme og danne det endelige udbetalingsgrundlag. Bilag 3A Behovsopgørelse Side 32 af 78

Processen starter, når det er tid til at udbetale eller når et krav, som skal sendes til Debitor, opstår. Før Systemet kan beregne det endelige udbetalingsgrundlag modtages dels informationer om indbetalinger (for bidragssager) og dels informationer om eventuelle modregningsposter. Når udbetalingsgrundlaget er dannet bestemmes det videre forløb, som kan være at sagen skal vurderes manuelt af en kunderådgiver, at der skal sendes besked til en person, at sagen skal lukkes, at der gives besked til opkrævning om modregning og/eller at der udbetales eller opkræves (Håndter udbetaling/håndter opkrævning). Bemærk at processen både bruges til at opgøre opkrævningsposter og udbetalingsposter. 6.2.3.2 LF Familieydelser Udsend påmindelse om enlig-erklæring 2.4.2.2 Formålet med denne proces er at udsende en årlig påmindelse om erklæringen som enlig. Det gælder for alle de personer hvis status (enlig/ikke enlig) berettiger til enlig-ydelser (ordinært og ekstra børnetilskud), at der en gang årligt skal bekræftes at de fortsat er enlige. Processen starter med at udsøge alle relevante personer, hvorefter der sendes besked om erklæringen. Hvis der ikke er modtaget svar indenfor et givet tidsrum, så udsendes en rykker. Hvis der fortsat ikke modtages svar indenfor tidsfristen, så fortsætter processen i Træf afgørelse, da det manglende svar opfattes som en erklæring som ikke-enlig. Svarene på enlig-erklæringen modtages via selvbetjeningsløsningen(håndter indberetning). 6.2.4 Kerneproces Håndter udbetaling 3.4.1 Processen håndterer overordnet set udbetaling af familieydelser og indberetning af udbetalinger til e-indkomst. Kerneprocessen Håndter udbetaling består af løsningsflowet: LF Familieydelser Effektuer udbetaling 3.4.1.1. 6.2.4.1 LF Familieydelser Effektuer udbetaling 3.4.1.1. Formålet med processen er at effektuerer udbetalingerne af familieydelser, samt danne relevante posteringer til regnskab og afstemning. Processen starter, når det er tid til udbetaling og der findes et udbetalingsgrundlag. Systemet danner poster til regnskab og afstemning, og sender selve udbetalingen til NemKonto. Efterfølgende modtager Systemet besked om gennemførte og afviste udbetalinger fra NemKonto. Når der udbetales Børne- og ungeydelser gives Bilag 3A Behovsopgørelse Side 33 af 78

desuden besked til EFI, som derved kan modregne daginstitutionsrestancer via NemKonto. I forbindelse med udbetalingerne modtages ind i mellem besked fra personer om fejl i udbetalingerne. Henvendelserne behandles manuelt af kunderådgiverne. 6.2.5 Kerneproces Håndter opkrævning 3.4.2 Processen understøtter overordnet hvordan betalingskrav videreformidles til Debitor. Kerneprocessen Håndter opkrævning består af løsningsflowet: LF Familieydelser Dan krav 3.4.2.1. 6.2.5.1 LF Familieydelser Dan krav 3.4.2.1 Formålet er at sikre, at krav videreformidles til opkrævningssystemet, samt at der kan dannes regnskabs- og afstemningsposter, som sendes til ERP. Processen starter når Dan udbetalingsgrundlag har resulteret i et krav. Det forekommer i bidragsager og i forbindelse med tilbagebetaling. Systemet danner poster til afstemning, regnskabet og selve kravet. Når Debitor har opkrævet kravet og modtaget en indbetaling, modtager Systemet besked herom, og processen fortsætter på Dan udbetalingsgrundlag. 6.2.6 Tværgående proces Håndter post 20.x.1 Den tværgående proces Håndter post, består af to løsningssubflows: LSF Modtag post LSF Afsend post Flowsene beskriver overordnet hvordan post modtages og afsendes i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Familieydelsessystemet skal kunne modtage og afsende post via denne proces. 6.2.7 Tværgående proces Håndter telefonisk kontakt 20.x.2 Den tværgående proces Håndter telefonisk kontakt, består af to løsningssubflows: LSF Modtag telefonopkald LSF Foretag telefonopkald Flowsene beskriver overordnet hvordan telefonopkald modtages og foretages i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Bilag 3A Behovsopgørelse Side 34 af 78

6.2.8 Tværgående proces Håndter dataleverance 20.x.3 Den tværgående proces Håndter dataleverance, består af to løsningssubflows: LSF Modtag dataleverance LSF Afsend dataleverance Flowsene beskriver overordnet hvordan dataleverancer modtages og afsendes i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Familieydelsessystemet skal kunne modtage og afsende dataleverance via denne proces. 6.2.9 Tværgående proces Håndter webadgang 20.x.4 Den tværgående proces Håndter webadgang, består af to løsningssubflows: LSF Modtag henvendelse via www LSF Modtag log-in oplysninger Flowsene beskriver overordnet hvordan personers henvendelser via www og log-in oplysninger modtages i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Familieydelsessystemet skal kunne modtage henvendelser via www og log-in oplysninger via denne proces. 6.2.10 Tværgående proces Håndter webservice 20.x.5 Den tværgående proces Håndter webservice, består af to løsningssubflows: LSF Besvar webservicekald LSF Foretag webservicekald Flowsene beskriver overordnet hvordan webservicekald besvares og foretages i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Familieydelsessystemet skal kunne foretage webservicekald via denne proces. Bilag 3A Behovsopgørelse Side 35 af 78

7 Informationsarkitektur Informationsarkitekturen fastlægger de forretningsmæssige begreber, som forretningen anvender og som Systemet skal indeholde i form af data. Begreber og sammenhænge vises i UML Diagrammer, og begreberne defineres og kommenteres i tekst i de medfølgende bilag med kildehenvisning til begrebernes definition. Udbetaling Danmark har modelleret de forretningsmæssige begreber i et hierarki af begrebs- og informationsmodeller. Den Overordnede Begrebsmodel har det højeste abstraktions niveau og viser begreber fra hele Udbetaling Danmarks forretning. Niveauet under den overordnede begrebsmodel er begrebsmodeller for hver af de sagstyper, vi håndterer, en generisk begrebsmodel for det generelle Sagsbegreb samt en begrebsmodel for de grunddata vi registrerer for parter/aktører/ interessenter i sager. Hver begrebsmodel har under sig en informationsmodel som detaljerer og beriger begrebsmodellen. Informationsmodellerne giver information til og er grundlaget for leverandørens logiske og fysiske datamodeller. 7.1 Overordnet begrebsmodel for Udbetaling Danmark Udbetaling Danmark behandler forskellige typer af sager, som kan aflæses i den overordnede begrebsmodel, se Figur 6. Udbetaling Danmark administrerer og udbetaler økonomiske ydelser til personer eller virksomheder. Ydelserne kan være af typen pension, barselsdagpenge, refusion til virksomhed, boligstøtte og familieydelse. Derudover opkræver vi børnepenge og foretager helhedsorienteret kontrol af ydelser. Sagsbehandlingen kan være automatisk eller manuel. Bilag 3A Behovsopgørelse Side 36 af 78

Figur 6: Overordnet begrebsmodel for Udbetaling Danmark 7.2 Begrebs- og informationsmodeller for Forretningsløsningen Begrebs- og Informationsmodeller er forretningens modeller over de væsentligste begreber, som Systemet skal kunne oprette, læse, ændre og slette. Modellerne er på et konceptuelt niveau. Begrebsmodellerne giver det overordnede overblik og informationsmodellerne giver detaljering og berigelse af begrebsmodellerne. Informationsmodellerne indeholder de begreber og attributter, som aktivitetsbeskrivelser, beslutningsmodeller og eksterne systemer har behov for i forbindelse med beskrivelsen af et sammenhængende system. Modellerne er metodemæssigt afstemt med KOMBIT. Der indgår følgende begrebs- og informationsmodeller i Systemet: Familieydelser Sag Beriget Grunddata Begrebsmodellerne indgår ikke i udbudsmaterialet, da informationsmodellerne giver den tilstrækkelige information til leverandøren. 7.2.1 Dokumentation til leverandør Informationsmodellerne er detaljeret beskrevet i bilag 3A.4 (Informationsmodeller), både i diagramform og i rapportform hvor diagrammer, logiske samhørende enhe- Bilag 3A Behovsopgørelse Side 37 af 78

der, begreber og attributter er beskrevet med definition, kildehenvisning og relevante kommentarer. Systemet er beskrevet i: Informationsmodel Familieydelser Informationsmodel Sag Informationsmodel Beriget Grunddata Derudover er informationsmodellen for Beriget Grunddata vedlagt, idet den viser hvilke informationer, der er til rådighed i Systemet for Person og Myndighed. Den metodemæssige tilgang til begrebs- og informationsmodellering i ATP er beskrevet i bilag 2A (Sådan forretningsmodellerer vi i ATP). 7.2.2 Informationsmodel Sag Informationsmodellen for Sag indeholder de generelle sagsbegreber og deres relationer. Begreberne er grupperet i logiske samhørende enheder, hvor de vigtigste er Sag, Sagsdokumentation og Part. Disse beskrives kort nedenfor. 7.2.2.1 Sag Sag er defineret i den fællesoffentlige OIO standard Specifikation af serviceinterface for sag http://digitaliser.dk/resource/1567587 sådan: Sag forstås som en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces, typisk til administrative formål, herunder til at træffe afgørelser. En sag består af et antal dokumenter, der vedrører det samme begivenhedsforløb. Et dokument kan indgå i flere sager, dvs. have relation til flere begivenhedsforløb Udbetaling Danmark har valgt at definere en sag sådan: En sag er en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces, typisk til administrative formål, herunder til at træffe afgørelser Udbetaling Danmarks sagsbegreb betyder at en person/virksomhed/myndighed har én sag i et ydelsesområde, som dækker hele forløbet for vedkommende. Bilag 3A Behovsopgørelse Side 38 af 78

Undtagelsen fra denne regel er klagesager, hvis en part klager over sin sag oprettes der en klagesag med relation til den oprindelige sag, så en sag kan godt have relateret en eller flere klagesager i et ydelsesområde. Vi samler dokumenter, data, information om en afgrænset arbejdsproces i en Sag. Sagen er således en digital hængemappe for dokumentation og en sag kan fremsøges ved hjælp af forskellige nøgler, som identificerer denne. 7.2.2.2 Sag - Nøgler og Egenskaber Udbetaling Danmarks sag er modelleret efter OIO Specifikation for Sag version 1.2 og har dermed følgende nøgler: Beskrivelse Værdisæt Obl. Betegnelse Primær nøgle, en teknisk nøgle som er unik Brugervendt identifikation, der er unik inden for myndigheden. UUID Ja Sag ID Tekst Ja BrugervendtNøgle Frit sagsnummer Tekst Ja Sagsnummer Officiel sagstitel, der kan anvendes i forbindelse med åbne dagsordenspunkter. Dette er også dokumentets objektnavn, jf. Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet. Tekst Ja Titel Sagsbeskrivelse i fri tekst. Evt. supplerende beskrivelse af indhold og formål. Tekst Ja Beskrivelse Tabel 3: Nøgler for "Sag" Sagen har også en række generelle egenskaber: Beskrivelse Værdisæt Obl. Betegnelse Henvisning til hjemmel fx lov og for sagens behandling. Tekst Nej Hjemmel Bilag 3A Behovsopgørelse Side 39 af 78

Beskrivelse Værdisæt Obl. Betegnelse Angives, hvis der er truffet beslutning om undtagelse fra offentligheden. Værdisættet består af de to følgende elementer. OffentlighedUndtaget Nej OffentlighedUndtaget Anvendes ikke i Udbetaling Danmark Alternativ sagstitel der kan anvendes i forbindelse med lukkede dagsordenspunkter, som skal vises på åbne dagsordener samt i forbindelse med postlister. Tekstuel henvisning til lovhjemmel, der anvendes som grundlag for beslutning om undtagelse fra offentligheden. Indikator for om sagen er udnævnt som principsag. Kassationskode, der styrer varighed før kassation. Er afleveret til Statens Arkiver/ 7 arkiv. Tekst Nej AlternativTitel Anvendes ikke i Udbetaling Danmark Tekst Nej Hjemmel Anvendes ikke i Udbetaling Danmark Nej/Ja Nej Principiel Tekst Ja Kassationskode Nej/Ja Nej Afleveret Tabel 4: Generelle egenskaber for "Sag" De generelle attributter, som dækker alle sagstyper, nedarves, og hver sagstype har yderligere attributter, som er specifikke for typen. 7.2.2.3 Sagens oprettelse og livsforløb En familieydelsessag består af minimum to instantieringer af begrebet Sag. Der er en samlesag, som er hægtet op på barnet, og en til flere delsager alt efter hvor mange personer/myndighed der har bevillinger relateret til barnet i samlesagen. En delsag har altid en relation til en samlesag og en delsag kan også godt have relationer til andre delsager. Fx en mor, som har en familieydelsessag (delsag), har en relation til barnets far, som har en familieydelses (delsag) med en bevilling på Bilag 3A Behovsopgørelse Side 40 af 78

betaling af børnebidrag, og en relation til sit barn, som har en samlesag. Disse relationer ligger i sagsrelationer. Figur 4: Eksempel på Sagsrelationer Det der binder sagerne sammen er referencer mellem sagerne. Det betyder, at ved en søgning på et givent CPR nr., vil der dukke et antal sager frem i søgeresultatet. På det tidspunkt hvor en kunderådgiver vælger en af disse sager i Systemet, vil kunderådgiveren kunne danne sig et overblik over de tilhørende sager til den valgte delsag. I tilfældet i Figur 4 vil kunderådgiveren kunne se, at den valgte delsag, de har søgt på, er relateret til en anden delsag samt en samlesag. Derfor er referencernes synlighed mellem sagerne i kunderådgiverens brugergrænseflade både i Systemet. På den måde kan et overblik over et sagskompleks skabes hurtigt f.eks. i forbindelse med en telefonsamtale mellem Udbetaling Danmark og en borger. En familieydelsessag med samlesag på barn og delsag på ydelsesmodtager oprettes enten o o o Ved besked fra Beriget Grunddata om nyt barn i CPR, dette gælder både fødsler og indrejser Ved anmodning om Børne- Ungeydelse fra EØS borgere. Ved ansøgning om ægtefællebidrag (kan være uden barn på samlesag) Sagen sluttes først, når barnet er fyldt 18 eller alle bidrag er betalt/udbetalt på sagen. Det betyder, at sager, hos os, kan være meget langvarige. En familieydelsessag løber over barnets hele berettigelsesperiode typisk 18 år. Sagen ændrer tilstand i løbet af sin levetid: Bilag 3A Behovsopgørelse Side 41 af 78

Beskrivelse Værdisæt Obl. Betegnelse Sagens forretningsmæssige fremdrift i forhold til behandling Fremdrift Noget kræver myndighedens ageren. Sagen er i proces med en oplysning Der er truffet afgørelse på sagen, fx bevilling eller afslag Sagsbehandling er fuldført Opstået Under Oplysning Afgjort Afsluttet Tabel 4: Tilstande for "Sag " Sagens tilstand kan skifte frem og tilbage mellem de forskellige værdisæt i løbet af levetiden. 7.2.2.4 Forskelle til sagsbegreb i Eksisterende Løsning Familieydelser nuværende løsning Sagsbegreb i KMD Børneydelse: o For hver tilskudsmodtager findes én sag som både kan rumme børne- og ungeydelse samt børnetilskud. o Parter kan være barn, mor, far, ægtefælle og samlever. Sagsbegreb i KMD Underholdsbidrag: o For hver bidragsmodtager findes én sag som kan rumme et antal bevillinger, der hver især kan rumme et antal ydelser. o Parter kan være bidragsmodtager, bidragsbetaler og barn. Familieydelser, ny løsning I Familieydelsessystemet vil barnet få én samlesag og hver ydelsesmodtager og bidragsbetaler få én delsag. Hver person har kun en delsag selv om vedkommende har mere end en hovedydelse. Hver person kan dog godt have flere delsager, da man har en delsag pr. barn man modtager ydelser for eller betaler bidrag til. Det nye sagsbegreb vil forøge antallet af sager på børneydelser til antallet af børn i Danmark, mens bidragssagerne vil indgå i børneydelsessagerne. Samlet vil antallet af sager stige en smule. Bilag 3A Behovsopgørelse Side 42 af 78

7.2.3 Part Hver sag i Udbetaling Danmark har én part tilknyttet og vi har derfor ikke behov for begreberne primær og sekundær part. En part er en person i en familieydelsessag. En part har ret til aktindsigt i sin egen sag. 7.2.4 Sagsdokumentation Systemerne for de enkelte ydelsesområder har ansvaret for sagen gennem hele sagens levetid fra oprettelsen, over ændringer på sagen, til sagen sluttes. Det er det enkelte Systems ansvar at sørge for at vedligeholde Rammearkitekturens Sags- og dokumentindeks og Ydelsesindeks (se snitfladerne PYDI1 Udstil oplysninger i Ydelsesindeks og PSDI1 Udstil oplysninger i Sags- og dokumentindeks) samt rettidig synkronisering, således at indeksene til en hver tid afspejler fagsystemet. Det er ligeledes Systemets ansvar at vedligeholde data alt hvad der vedrører sagen, journalnotater, beskeder, digitale henvendelser, scannende dokumenter samt journalisering af henvendelser. 7.2.5 Informationsmodel Familieydelser Informationsmodellen for familieydelser indeholder familieydelsesbegreber og deres relationer. Begreberne er grupperet i logiske enheder, hvor de vigtigste er Familieydelsesag, FamilieydelseGrundoplysninger, Familieydelsestype, FamilieydelseYdelse, Udbetaling og FamilieydelseSystemadministration. Disse beskrives kort nedenfor. 7.2.6 Familieydelsesag En familieydelsessag vil altid være af typen Samlesag eller Delsag. 7.2.6.1 Samlesag En samlesag for de person-delsager, som vedrører samme barn. Samlesagen har relation til alle de delsager (mor/far/myndighed), der er knyttet til barnets sag. Der oprettes én samlesag per født/indrejst barn. Samlesagen oprettes for at holde relationen mellem delsagerne. Samlesagen har kun én betydende attribut, nemlig personident på det barn, som samler delsagerne. Samlesag har dermed ikke behov for alle de attributter, der ligger på Sag, og de kan undværes her. Bilag 3A Behovsopgørelse Side 43 af 78

7.2.6.2 Delsag En delsag er en instantiering af en sag. Delsagen indeholder oplysninger om et sagsforløb for en sagspart, der kan være en person eller en myndighed, som skal have en økonomisk ydelse/bidrag. En delsag under familieydelsessag giver mulighed for at opdele familieydelsessagen i delsager, så sagsparternes dataindsigt begrænses til de data, som ligger på delsagen, så parterne ikke kan se hinandens delsager. Andre personer end mor og far kan indtræde i retten til ydelser. Det kan fx være en mormor der har barnet boende. Bevillingen vil dog forsat være afhængig af den forælder med forældremyndighed og bevillingen, og dermed skal denne forælder fortsat opfylde berettigelse. En delsag arver alle de generelle attributter fra Sag. En myndighed kan indtræde i retten til bidrag ved anbringelse af barnet. 7.2.7 FamilieydelserGrundoplysning Grundoplysninger er oplysninger til brug for afgørelser og beregninger på familieydelsessagen. Oplysningerne fås fra andre myndigheder, offentlige registre, indtastes af kunderådgiver eller via ansøgers selvbetjening. 7.2.8 FamilieydelsesType Systemets ydelsestyper er opdelt i tre områder: BørneUngeYdelse Børne- og ungeydelse udbetales automatisk, hvis personen opfylder en række betingelser. Børneydelse er til børn i alderen 0-14 år og udbetales en gang i kvartalet. Ungeydelse er til børn i alderen 15-17 år og udbetales en gang i måneden. Der findes en række satser for ydelsen alt efter hvor gammel barnet er. Børnetilskud Børnetilskud består af børnetilskud til enlige forsørgere samt en række mindre børnetilskud. Der er forskellige betingelser for at opfylde kravene til de forskellige børnetilskud, men også nogle generelle betingelser. OrdinærtBørnetilskud Bilag 3A Behovsopgørelse Side 44 af 78

Enlige forsørgere kan søge om et ordinært børnetilskud. Det er en betingelse, at borgeren er reelt enlig. Det ordinære børnetilskud udbetales pr. barn. EkstraBørnetilskud Det ekstra børnetilskud udbetales en gang i kvartalet pr. familie. Personen søger om ordinært og ekstra børnetilskud på samme ansøgning. BørnetilskudTilForældreUnderUddannelse Særligt børnetilskud til forældre under uddannelse kan udbetales, når en forælder er i lære eller i gang med en uddannelse, hvor man kan få SU eller blive optaget i en a-kasse. Tilskuddet er indkomstbestemt. SupplerendeBørnetilskud Supplerende børnetilskud kan udbetales til forældre under uddannelse, der er i en praktik- eller skoleperiode med løn eller skolepraktikydelse. Tilskuddet er indkomstbestemt. Adoptionstilskud En person kan søge om adoptionstilskud, hvis han eller hun har adopteret et udenlandsk barn gennem en godkendt adoptionsorganisation. Adoptionstilskuddet er et engangsbeløb. OrdinærtBørnetilskudtilpensionist Folkepensionister kan have ret til børnetilskuddet. Førtidspensionister på de gamle regler kan også få tilskuddet. Børnetilskuddet udbetales automatisk. Der modtages besked fra Pensionssystemet om nye pensionister med børn. SærligtBørnetilskudtilpensionist Hvis kun en af forældrene er pensionist, vil pensionisten modtage særligt børnetilskud til pensionister, men ikke det ordinære børnetilskud til pensionister. Hvis begge forældre er pensionister, vil de både modtage det ordinære og det særlige børnetilskud samt et ekstra tillæg i hvert kvartal. Børnetilskuddet er indkomstbestemt og udbetales automatisk. Børnetilskudtilbidragsbetalendepensionist Folkepensionister eller førtidspensionister efter gamle regler, der betaler bidrag kan søge et tilskud til dækning af normalbidragets grundbeløb. Det særlige børnetilskud til bidragsbetalende pensionister kan enten udbetales ved at tilskuddet bliver modregnet i Personens bidragsopkrævning eller hele tilskuddet udbetales til Personens Nemkonto. SærligtBørnetilskud Der kan gives et særligt børnetilskud, når der kun er én eller ingen forældre. Tilskuddet gives: Bilag 3A Behovsopgørelse Side 45 af 78

- Når den ene forælder er død - Når begge forældre er døde (her gives der to tilskud) - Når der ikke er fastslået faderskab - Mens der er en igangværende faderskabssag i Statsforvaltningen - Når barnet er kommet til ved kunstig befrugtning - Når barnet er adopteret af en enlig adoptant Nogle af tilskuddene skal der søges om, mens andre skal startes automatisk. Børnetilskudvedflerbørnsfødsel Ved en flerbørnsfødsel kan der gives et tilskud for hvert barn ud over det første. Tilskuddet udbetales automatisk og stopper når børnene fylder 7 år. Underholdsbidrag Underholdsbidrag er et økonomisk bidrag til en person, som man har pligt til at forsørge. Det kan være et barn eller en ægtefælle. Underholdsbidrag betales fra den ene part til den anden part ud fra en afgørelse fra Statsforvaltningen eller privat aftale. Udbetaling Danmark opkræver og udbetaler bidraget, hvis parterne ikke kan ordne bidraget indbyrdes. Bidraget er delt i børnebidrag, ægtefællebidrag og særbidrag. Bidrag kan udbetales forskudsvist, mens andre kun kan udbetales ej forskudsvist. Bidragsafgørelse Bidragsafgørelsen er dokumentation for en persons ret til bidraget, beløbets størrelse samt udbetalingsfrist. 7.2.9 FamilieydelsesYdelse Samling af de effektueringsbegreber, der skal til for at danne en udbetaling/opkrævning, og som skal danne grundlag for dataafsendelse til Rammearkitekturens YdelsesIndeks (se snitfladen PYDI1 Udstil oplysninger i Ydelsesindeks). 7.2.10 Udbetaling Udbetalingspakken indeholder informationer for hver udbetaling og opkrævning samt modregningskrav. 7.2.11 Familieydelsesystemadministration Begreber som anvendes i forbindelse med planlægning af kunderådgivernes opgaver og til rapportering til den daglige drift-ledelse. Bilag 3A Behovsopgørelse Side 46 af 78

8 IT arkitektur Dette kapitel præsenterer: 1. IT-udbudsarkitekturen. Her præsenteres hvilke it-systemer, der skal indgå i den samlede forretningsløsning, som skal være etableret på Overtagelsesdagen 2. System kontekst. Her præsenteres integrationerne, der skal etableres fra Familieydelsessystemet samt de eksterne services som Systemet skal etablere og udstille. 3. Integrations-infrastrukturen. Her beskrives overordnet den tekniske infrastruktur omkring integrationerne. 8.1 IT-udbudsarkitekturen I det følgende præsenteres hvilke it-systemer, der skal indgå i den samlede Forretningsløsning, som skal være etableret på Overtagelsesdagen. IT-arkitekturen understøtter forretningsarkitekturen ved at udmønte de forretningsmæssige behov i et konkret systemlandskab. IT-arkitekturen bygger videre på og konkretiserer forretningsarkitekturen i forhold til hvilke systemer og registre, der indgår i løsningen. Endvidere angives de eksterne systemer og parter, som skal modtage-/levere data fra Familieydelsessystemet, således at det fulde omfang af snitflader klarlægges. I modsætning til forretningsarkitekturen beskriver IT-arkitekturen ikke den interne opbygning af Familieydelsessystemet. Den interne IT-arkitektur for Systemet skal beskrives af Tilbudsgiver i bilag 3B (Løsningsbeskrivelse). IT-udbudsarkitekturen vil være en del af en transitionsplan mod målarkitekturen beskrevet i bilag 3 (Leverancebeskrivelse). Det udmønter sig dels ved, at ikke alle de indgående systemer vil blive benyttet i deres endelige form. IT-udbudsarkitekturen fremgår af Figur 7 og forskellene i forhold til ITmålarkitekturen beskrives kort i det følgende. Bilag 3A Behovsopgørelse Side 47 af 78

Figur 7: IT-udbudsarkitekturen for den samlede Forretningsløsning for administration af Familieydelser. Udbetaling Danmark systemer Familieydelsessystemet er afbildet på figur 7 som det centrale system i ITudbudsarkitekturen og er med i den tredje runde af it-systemer, der bliver konkurrenceudsat af ATP. Ydelsesområdet Boligstøtte jf. figur 7 vil fortsat benytte KMD systemer, på det tidspunkt hvor Systemet bliver idriftsat. Interne tværgående støttesystemer Til levering af person- og myndighedsoplysninger skal benyttes et register - Beriget Grunddata, som etableres i Udbetaling Danmark. Dette system skal bl.a. sikre, at berigelser af persondata fra de autoritative registre kan deles på tværs af Udbetaling Danmarks ydelsesområder. Ydelsesområde-specifikke systemer og registre De ydelsesområde-specifikke systemer og registre er de systemer, som ikke skal anvendes på de øvrige ydelsesområder, og som kun indgår i administrationen af Bilag 3A Behovsopgørelse Side 48 af 78

familieydelsesordningen. Systemerne er afbildet på IT-målarkitekturen i bilag 3 (Leverancebeskrivelse), og præsenteres kort her. Systemet leverer informationer til en lang række andre parter: Til brug for statistik m.m. leveres data til hhv. Danmarks Statistik, SU Styrelsen og Ministeriet for Børn, Ligestilling, Integration og Sociale forhold (BLIS). Derudover leveres forskellige oplysninger til SKAT, hvor der leveres oplysninger til Skattefrie Beløb, Grøn Check, EFI og Enlige Forsørgere. Alle øvrige områder af IT-udbudsarkitekturen er som beskrevet i IT-målarkitekturen i bilag 3 (Leverancebeskrivelse). 8.2 Systemkontekst og integrationer Nedenfor præsenteres systemkonteksten for Systemet. Hvor IT-udbudsarkitekturdiagrammet siger noget om hvilke systemer, der samlet set indgår i Systemet, men ikke noget om hvordan de er forbundet, illustrerer systemkonteksten hvilke systemer, der skal integreres til fra Systemet. Systemkonteksten holdes på logisk niveau, og infrastrukturkomponenter er ikke medtaget her. Disse infrastrukturkomponenter beskrives i stedet i afsnit 8.2.1 Integrationer og infrastruktur. På systemkontekst diagrammet er hver integration tildelt et ID ud fra mønsteret IntegrationsID = <ydelsesområdeforkortelse F ><3-bogstavs systemforkortelse><fortløbende nr.>. Fra aktivitetsbeskrivelser og fra krav er der refereret til integrationsid et. Systemkonteksten er illustreret på Figur 8. Bilag 3A Behovsopgørelse Side 49 af 78

Figur 8: Systemkonteksten for Systemet. Diagrammet viser alle de systemer, som Systemet skal integrere til. Figuren viser ikke infrastruktur-komponenter men udelukkende applikationer på logisk niveau. 8.2.1 Integrationer og infrastruktur Alle integrationerne er listet i nedenstående tabel 5. Integrationspart IntegrationsID Integrationsnavn ATP-systemer ATP ERP FERP1 Posteringer til ERP ATP Afstemning FAAF1 Afstemningsdata til ATP ATP Datawarehouse FDWH1 Data til datawarehouse FIDP1 Interne tværgående støttesystemer & Eksterne services ATP idm & idp FIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM Login via ATP s IdP Posthåndterings-leverandør (PHL) FPHL1 Modtag indgående post FPHL2 Fjernprint FFPR1 Send besked Send post til genjournalisering Sikker Post FSIP1 Send sikker post. Bilag 3A Behovsopgørelse Side 50 af 78

Integrationspart IntegrationsID Integrationsnavn Beriget Grunddata FBGD1 Hent data fra Beriget Grunddata Eksterne kanaler Borger.dk FBOR1 Visuel integration i Borger.dk Fælleskommunale systemer Sags- og dokumentindeks FSDI1 Udstil oplysninger i Sags- og dokumentindeks FSDI2 Hent oplysninger fra Sags- og dokumentindeks Ydelsesindeks FYDI1 Udstil oplysninger i Ydelsesindeks FYDI2 Hent oplysninger fra Ydelsesindeks Fælles systemer & registre NemKonto FNKS1 Send udbetalingsanmodninger NemLogin FNLO1 Login til selvbetjening via NemLog-in Digital Fuldmagt FDIF1 Hent digital fuldmagt SKAT eindkomst FSKE1 Hent indkomstoplysninger SKAT Forskud FSKF1 Hent topskattegrundlag FSKF2 Hent skattepligtskode SKAT Årsopgørelse FSKS1 Hent topskattegrundlag Danmarks Statistik FDST1 Levering af oplysninger til Danmarks Statistik Statens arkiver FSTA1 Indberet til statens arkiver Ydelsesområde-specifikke systemer og registre SKAT (CSC) FSKA1 Indberet skattefrie beløb SKAT Enlige forsørgere FSEF1 Indberet ekstra børnetilskud SKAT Grøn Check FSGR1 Indberet antal børn FSGR2 Indberet udbetalt børne- og ungeydelse på antallet af børn SKAT EFI FEFI1 Indberet til SKAT EFI Bilag 3A Behovsopgørelse Side 51 af 78

Integrationspart IntegrationsID Integrationsnavn Ministeriet for Børn, Ligestilling, Integration og Sociale forhold FBLI1 Levering af oplysninger til BLIS (BLIS) SU Styrelsen FSUS1 Levering af oplysninger til SU Styrelsen Feriepenge.dk FFEP1 Modtagelse af oplysninger fra feriepenge.dk Fagsystemer Pensionsfagsystem FPFS1 Hent oplysninger fra pension Debitorfagsystem FOFS1 Send krav FOFS2 Modtag kravstatus FOFS3 Modtag modregning FOFS4 Send modregningsstatus Tabel 5 Systemets integrationer En detaljeret beskrivelse af hver integration er at finde i bilag 3A.6 (Integrationer). Da systemintegrationerne kan ændre sig over tid, er det vigtigt, at der er løs kobling og klare grænseflader til systemerne. Ved løs kobling forstås, at en given komponent ikke er afhængig af den konkrete implementering af en anden komponent, men kun af systemgrænsefladen (data), som udstilles via ovenstående snitflader jf. tabel 5. De konkrete krav til integrationer fremgår af bilag 03A.1 (Kravliste). Alle integrationer fra Systemet til andre systemer er som udgangspunkt punkt-tilpunkt. Det er Leverandørens ansvar at etablere de enkelte integrationer fra Systemet til den anden part i integrationen, samt at levere den nødvendige infrastruktur. Leverandøren skal benytte den integrationsmetodik og -platform, som serviceudbyderen stiller til rådighed. Bilag 3A Behovsopgørelse Side 52 af 78

9 Non-funktionelle krav til Systemet Ud over de funktionelle krav til Systemet i bilag 3A.1 (Kravliste) har ATP en række non-funktionelle krav til Systemet. Disse non-funktionelle krav er inddelt i en række kravgrupper, som gennemgås i de følgende underafsnit. Kravgrupperingen anvendt i dette bilag anvendes også i bilag 3A.1 (Kravliste) og i bilag 3B (Løsningsbeskrivelse), således at strukturen fremstår ensartet i de tre bilag. 9.1 Arkitektur ATP har en række krav til de overordnede rammer for Systemet. Disse krav fremgår af bilag 3A.1 (Kravliste), og kravene angiver ligeledes de arkitektoniske afgrænsninger, som Systemet skal efterleve. 9.1.1 Rammer for arkitekturen Leverandøren skal sikre at Systemet er fleksibelt opbygget, således at Systemet kan modificeres og videreudvikles i hele Systemets levetid uden unødige omkostninger eller unødige risici. Som en dokumentation for Systemets fleksibilitet skal Leverandøren i bilag 3B (Løsningsbeskrivelse) indsætte en besvarelse på udvalgte cases, der omhandler fiktive, men dog realistiske, ændringer til Systemet. 9.1.2 Belastning og skalering Systemet skal designes med skalerbarhed for øje, så det til en hver tid kan skaleres til at håndtere et stigende/faldende antal brugere/hændelser, dokumenter og journalnotater. Med bruger forstås såvel antallet af kunderådgivere som borgere. Hændelser er de automatisk genererede ændringer som bevirker at Systemet udfører en foruddefineret handling, en beregning, en udbetaling eller ved at servicere en af snitfladerne jf. Systemkonteksten. 9.1.2.1 Udbetalingskørsler De største udbetalingskørsler er månedlige og kvartalsvise. Dertil kommer daglige udbetalingskørsler af bidrag. Kørslerne er afhængige af, at der forinden er blevet dannet et endeligt udbetalingsgrundlag, hvor indbetalinger og modregningsaftaler fra Debitor tages med i beregningen af hvor meget der skal udbetales. Kørslen er omdrejningspunktet for hele Systemet, og det er derfor væsentligt, at Systemet er gearet til at håndtere alle udbetalinger, såvel som de bagvedliggende processer, der direkte eller indirekte indgår i udbetalingsprocessen. Bilag 3A Behovsopgørelse Side 53 af 78

Kunderådgiverne modtager i dagene op til og efter udbetalingen, et stigende antal henvendelser fra borgerne vedrørende selve udbetalingen. Dette bevirker at kunderådgiverne skal hente forskellige informationer fra Systemet, for at kunne servicere borgere. 9.1.2.2 Satsregulering Satsregulering af stort set alle familieydelser udføres årligt og bevirker at et stort antal aktive sager skal genberegnes. 9.1.2.3 Udsendelse af årlig påmindelse om enlig erklæring Der udsendes årligt en påmindelse til alle de personer hvis status (enlig/ikke enlig) berettiger til enlig-ydelser (ordinært og ekstra børnetilskud). I alt ca. 135.000 breve. 9.1.2.4 Årlig efterregulering To gange om året gennemføres en efterregulering for Børne- og ungeydelsen og for Supplerende børnetilskud til forældre i praktik. Det sker i maj og juli, når SKAT frigiver årsopgørelsen for henholdsvis lønmodtagere og selvstændige. Det medfører at Systemet skal genberegne de sager, hvor årsindtægten har været større end grænsen og forskellig fra det forskudsindberettede. 9.1.2.5 Journaliser post på sagen Al post digitaliseres og hentes via systemintegrationen til Posthåndtering. Posten placeres på sagen ud fra de medfølgende metadata, som Posthåndteringsleverandøren har løftet ud af forsendelsen. 9.1.2.6 Dataudtræk og øvrig rapportering Systemet skal være gearet til at levere de dataudtræk og rapporter, som er beskrevet i bilag 3A.1 (Kravliste), uden at det har betydning for kunderådgivernes og selvbetjeningsbrugernes systemoplevelse, det vil sige at svartiderne jf. bilag 7 (Servicemål) er gældende, såfremt kørslen forekommer indenfor kritisk forretningstid. At Systemet eller en bruger danner/henter en rapport, anses som værende en almindelig arbejdsrutine som foretages indenfor Kritisk forretningstid. 9.2 Design og applikationsstruktur ATP har ligeledes en række krav til afgrænsningerne omkring designet af løsningen, som løsningen skal efterleve. Kravene fremgår af bilag 3A.1 (Kravliste), og er rettet imod specifikke applikationsstrukturer, herunder integrationsmønstre, og angiver hvordan disse skal opbygges. Bilag 3A Behovsopgørelse Side 54 af 78

9.3 Logning I forhold til omfanget og karakteren af logning i Systemet, har ATP en række krav. Kravene definerer hvilke informationer Systemet skal logge, og skal føre til, at der etableres sporbarhed og at den gældende lovgivning efterleves, eksempelvis ved kontrol af adgang til personfølsomme data. Logningskravene skal desuden sikre, at Leverandøren kan dokumentere hvordan servicemål efterleves, ligesom de skal afhjælpe fejlsøgning og generel overvågning af Systemet. 9.4 Systemfleksibilitet ATP ønsker et System som er fleksibelt og modulært opbygget, så fremtidige tilpasning kan gennemføres ved konfiguration af processer, nye ydelsestyper, regler, kontroller og øvrige systemparametre ATP anser systemfleksibilitet som en væsentlig kilde, til at minimere vedligeholdelse omkostningerne for Systemet. 9.5 Tilgængelighed ATP ønsker et driftsstabilt System med høj grad af tilgængelighed og lave svartider. Kravene i bilag 3A.1 (Kravliste) fastsætter sammen med servicemålene i bilag 7 (Servicemål), kravene til Systemets tilgængelighed. 9.6 Datakonvertering Dette afsnit fastsætter de overordnede vilkår for konvertering af data fra den Eksisterende Løsning til Systemet. ATP s overordnede mål for konverteringen er at sikre, at der sker behørig konvertering og afstemning af relevante data og en sikker overgang til Systemet. 9.6.1 Konverteringskonceptet generelt ATP er ansvarlig for at der foreligger et prøveudtræk, så det er muligt for Leverandøren, at igangsætte prøvekonverteringen tidligt i forløbet. Dette sker for at få erfaring med både kompleksiteten og datakvaliteten. Endvidere afdækkes behovet for manuelle/maskinelle korrektioner inden data konverteres til Systemet. Baseret på erfaringerne fra prøvekonverteringerne skal der etableres en drejebog for konverteringen. Drejebogen skal indeholde de aktiviteter, som Leverandøren skal sikre i forbindelse med overgangen til Systemet (jf. figur 9). Der er primært fokus på opsætningen af diverse abonnementer (Beriget Grunddata, SKAT snitflader mv.) samt integrationen til Debitor, da det danner grundlaget for korrekt udbetaling. Bilag 3A Behovsopgørelse Side 55 af 78

Dernæst på de øvrige leverancer til dels ATP og til de øvrige offentlige myndigheder samt halv offentlige instanser, såsom Danmarks Statistik m.v. Konverteringen vil ske systemopdelt, hvor først data vedrørende børne- og ungeydelse samt børnetilskud konverteres over i Systemet, og så efter en månedsudbetaling konverteres data vedrørende underholdsbidrag. Ved hver konverteringsbølge skal data behandles ud fra et fast specificeret regelsæt. Alle data fra Eksisterende Løsning og øvrige KMD systemer, som indeholder information om familieydelsesområdet, vil blive trukket ud og placeret på en FTP server. Dataudtrækket, den logiske datamodel m.v. vil fremgå af bilag 2B (Eksisterende data). Den endelige konvertering skal koordineres mellem KMD, ATP og Leverandøren. Det overordnede dataflow under konverteringen samt ansvarsfordelingen mellem KMD og Leverandøren er illustreret i figur 9. Figur 9 Ansvarsfordeling og dataflow for konvertering af data fra Eksisterende Løsning til Systemet. Udtræk af data: Den Eksisterende Løsning består af flere systemer, og støttesystemer. Der er således flere systemer, som indeholder data, der er relateret til en familieydelsessag. Bilag 3A Behovsopgørelse Side 56 af 78

Dataudtrækket fra Eksisterende Løsning gennemføres af KMD og er aftalt i udfasningsassistancen. Udfasningsassistancen forefindes på ATP Udbudsportal (http://www.atp.dk/udbudsportal/udfasningsassistance). Mapning og transformering: Leverandøren skal gennemføre mapning og transformering af data udtrukket fra Eksisterende løsning, således at data ensrettes Systemets informationsmodel, samt stille de fornødne værktøjer til rådighed herfor. Indlæsning og validering af data: Leverandøren skal indlæse, validere og afstemme data i Systemet. Leverandøren er endvidere ansvarlig for at videredistribuere de fornødne data til øvrige støttesystemer, hvori der skal loades eller konverteres data. Aktiviteterne under Udtræk, Transformering, Indlæsning og validering uddybes nærmere i de følgende afsnit. Leverandørens metode for transformering, indlæsning og validering vil fremgå af Leverandørens konverteringsstrategi. 9.6.2 Udtræk af data KMD leverer fuldt udtræk af alle de data fra KMD-systemer, som kan tænkes at skulle bruges i den nye løsning. Data udtrækkes som filer og placeres på en FTPserver. Udtræk af data fra Eksisterende Løsning omfatter: Systemdata fra KMD Børneydelse og KMD Underholdsbidrag. For disse vil data omfatte både afsluttede og igangværende sager, samt eventuelt tilknyttede opgaver. Generelle sagsdata fra KMD Sag vedrørende familieydelsessager. Dette inkluderer journalnotater og dokument metadata for tilknyttede dokumenter. Dokumenter fra KMD Sag EDH og KMD doc2archive. Detaljeret beskrivelse af data og udtræksformat findes i bilag 2B (Eksisterende data). KMDs ydelser i forhold til dataudtrækket fra Eksisterende Løsning er overordnet følgende: Leverer detaljeret design og dokumentation af udtrækket Bidrager til forståelse af eksisterende data via dataforståelsesworkshops Bilag 3A Behovsopgørelse Side 57 af 78

Levere data fra systemerne i det format, der er overordnet beskrevet i bilag 2B (Eksisterende data). Data leveres i samme kvalitet, som de i dag har i systemerne. Bidrager til den tværgående test af konverteringen, herunder at levere et prøveudtræk af produktionsdata. Bidrager til idriftsættelsesplan (ansvarlig for de aktiviteter, der skal foregå på KMDs side) Leverancerne er yderligere beskrevet i udfasningsassistance kravspecifikation og kravbesvarelse, som kan findes på ATP udbudsportal under Udfasningsassistance (http://www.atp.dk/udbudsportal/udfasningsassistance). ATP vil fungere som kontaktpunkt mellem KMD og Leverandøren. Leverandøren skal hente prøveudtræk og endeligt dataudtræk fra KMDs FTPserver. FTP-serveren er yderligere beskrevet i udfasningsassistancens underbilag, og er vedlagt i bilag 3A.6a Produkt og snitfladebeskrivelser\bilag_x_kmd_udfasningsassistance_ftp_infrastruktur.pdf. Leverandøren skal sørge for, at dataudtræk bliver slettet fra FTP-serveren efter afhentning. Leverandøren skal verificere, at dataudtrækket fra KMD matcher den leverede dokumentation af udtrækket, samt at dataudtrækket overholder kravene fra udfasningsassistance-kravspecifikationen. Dette skal ske på tidspunktet for modtagelse af prøveudtræk fra KMD og skal ske ved indlæsning af de modtagne data. Herigennem kan det verificeres, om der er referentiel integritet mellem tabeller, og om data har det beskrevne format. Ved mangler i leverancen fra KMD håndteres dette af ATP. 9.6.3 Transformering af data Leverandøren skal bortfiltrere eventuelt unødvendige data og transformere de data, som skal indlæses i Systemet i forbindelse med overgangen. Det vil bl.a. sige, at data ensrettes med Systemets informationsmodel. Leverandøren skal indledningsvist, gennem deltagelse i workshops med KMD, opbygge den dataforståelse som er nødvendig, for at gennemføre den efterfølgende konvertering. Leverandøren er ansvarlig for, at data migrationen fra den Eksisterende Løsning til Systemet sker korrekt ud fra de af KMD og ATP leverede databeskrivelser. ATP bidrager med forretningskendskab til data. Leverandøren skal i den forbindelse facilitere de workshops, som er nødvendige, for i samarbejde med ATP, at kunne Bilag 3A Behovsopgørelse Side 58 af 78

mappe data fra den Eksisterende Løsning til Systemet. Leverandøren skal levere en beskrivelse af transformationen på informationsmodel-niveau, som skal godkendes af ATP. Transformeringen skal kunne håndtere data, som de er leveret af KMD, og som det vil fremgå af den detaljerede dokumentation, der leveres af KMD. Datakvaliteten forventes overordnet at være god, ATP har ansvaret i tilfælde af, at der skal rettes op på data i Eksisterende Løsning. Leverandøren skal gennemføre en dataanalyse for at fastlægge behovet for datavask. ATP skal bistå med forretningsviden. Leverandøren skal sikre, at der etableres fuldt transaktionsspor på datatransformeringen og den efterfølgende indlæsning af data i Systemet. Nødvendigt værktøj og programmel til transformering af data udvikles/stilles til rådighed af Leverandøren. 9.6.4 Indlæsning og viderefordeling af data Leverandøren er ansvarlig for, at alle data konverteres korrekt ind i Systemet, og at sagerne oprettes i den rette tilstand. Endvidere skal Leverandøren sørge for, at der foretages den fornødne viderefordeling af data og synkronisering med støttesystemer. Det skal sikre at data er konsistente på tværs af Systemet og støttesystemer. 9.6.4.1 Indlæsning af data i Systemet Leverandøren skal indlæse fyldestgørende data til at sagsbehandlingen kan videreføres i Systemet med al den funktionalitet, der er i Systemet (såfremt der er de tilstrækkelige data til rådighed i dataudtrækket fra KMD). Herunder gælder særligt at: Aktive sager fra Eksisterende Løsning skal videreføres i Systemet, og sagsbehandlingen og/eller udbetalingerne skal forsætte i Systemet. Som minimum skal historik, svarende til indeværende år + 3 år for børne-og ungeydelsesager samt børnetilskudssager og indeværende år + 10 år for underholdsbidragssager, konverteres ind i Systemet. Afsluttede sager fra Eksisterende Løsning skal kunne genberegnes i forhold til de på det tidspunkt gældende regler. Der skal være adgang til dokumenter og journalnotater på sagerne. Kassations- og arkiveringsprocesserne skal virke for alle indlæste data. Bilag 3A Behovsopgørelse Side 59 af 78

Bemærk at konfigurationsdata fra KMD Sag ikke skal indlæses i Systemet, selvom de fremgår af databeskrivelsen i bilag 2B (Eksisterende data). Leverandøren skal i Afklaringsetapen i samarbejde med ATP afklare, om der er data, der kan/skal håndteres manuelt. Anbefalingen godkendes af ATP som en del af den opdaterede konverteringsstrategi. 9.6.4.2 Viderefordeling af data og synkronisering med støttesystemer Leverandøren skal udveksle data med følgende systemer: Beriget Grunddata Personer med administrative cpr-nr. etableres i Beriget Grunddata. Der skal opsættes abonnement for personkredsen, og persons- /myndighedsdata skal modtages fra Beriget Grunddata i den daglige replikering. SKAT Der skal oprettes abonnementer på og hentes indkomstoplysninger for alle i personkredsen. Sags- og dokumentindeks Alle aktive sager skal oprettes i sags- og dokumentindeks med tilknyttede dokumenter og journalnotater. Dataene vil herfra automatisk blive synkroniseret over i KMD Sag via den sædvanlige mekanisme til synkronisering mellem indekses og KMD Sag. Ydelsesindeks Bevillinger og ydelser skal oprettes i ydelsesindeks. ATP Datawarehouse Datawarehouse skal modtage et dataudtræk, når konverteringen er tilendebragt og alle data er konverteret ind. Data skal leveres i samme format som i de daglige dataleverancer se integrationsbeskrivelse FDWH1 i bilag 3A.6 (Integrationer). KMD Sag Når alle data er indlæst i Sags- og dokumentindeks og Ydelsesindeks, og alle sager derved er blevet synkroniseret til KMD Sag, skal de gamle sager i KMD Bilag 3A Behovsopgørelse Side 60 af 78

Sag logisk slettes og herved også de gamle sager i Sags- og dokumentindeks. Sletningen i KMD Sag foretages af KMD ud fra en liste over de sager og dokumenter, der skal slettes. Leverandøren er ansvarlig for at levere denne sletteliste. Leverandøren skal sikre, at der etableres fuldt transaktionsspor på viderefordelingen af data. 9.6.5 Afstemning og datavalidering Leverandøren skal udvikle automatiseringsrutiner til afstemning af data. Kriterier for datavalidering og efterfølgende godkendelse, opsættes i samarbejde mellem ATP og Leverandøren i forbindelse med migrationen af data fra Eksisterende Løsning til Systemet. Leverandøren skal som minimum gennemføre: Afstemning efter flytning af KMD dataudtræk til Systemets informationsmodel, som bevis for at alle relevante data er indlæst korrekt. Afstemning efter henholdsvis transformation og indlæsning af data, som bevis for at alle relevante data fra KMD dataudtrækket er indlæst korrekt og fuldstændigt i Systemet. Afstemning efter ajourføring af sager i Sags- og dokumentindeks og Ydelsesindeks som bevis for at der er overensstemmelse mellem sager i Systemet og i indekses, samt at sagerne er synkroniseret korrekt til KMD Sag. Verifikationen af KMD Sag synkronisering sker i samarbejde med KMD. Afstemmes op mod afstemningsdata leveret fra KMD. Beløbsafstemning på laveste niveau. Ad-hoc afstemning og kontroller, som skal gøres tilgængelige for ATP Bestandsafstemning og sumkontroller. Validering af transformeringen som sikrer at der ikke sker data tab eller forvanskning af data ved overgangen til Systemet. Alle felter med parametre eller kodeværdier (f.eks. 01 = myndighed, 02 = person m.m.) skal dokumenteres konverteret korrekt. Alle numeriske felter skal dokumenteres konverteret korrekt. Alle felter, der forandrer udseende (evt. sammenlægning af adresse oplysninger), skal dokumenteres konverteret korrekt. Leverandøren skal i forbindelse med gennemførsel af konverteringen levere en afstemningsrapport som dokumentation for afstemning af data inklusiv dokumentati- Bilag 3A Behovsopgørelse Side 61 af 78

on/forklaring af evt. afvigelser, samt redegørelse for påkrævede handlinger for håndtering af afvigelser. Afstemningsrapporten skal godkendes af ATP. 9.6.6 Gennemførsel af konverteringen Leverandøren skal udarbejde en strategi for konvertering og beskrive denne overordnet i bilag 3B (Løsningsbeskrivelse), så ATP kan evaluere og betrygges i at Leverandøren har prøvet dette før. Leverandøren skal med input fra ATP og KMD, tilrettelægge og gennemføre konverteringen, så overgangen fra Eksisterende Løsning til Systemet foregår på en sikker og forsvarlig måde, med særlig fokus på driftsstabilitet så forstyrrelser af den daglig drift, påvirkes mindst muligt. Leverandøren er ansvarlig for udarbejdelsen af en drejebog. ATP bidrager med overgangsinstrukser til Kunderådgiver samt øvrige forretningsmæssige afklaringer. Drejebogen skal som minimum indeholde nedenstående punkter: a) Forretningsmæssig nedlukning/opstart ved overgangen til ny Familieydelsesløsning. b) Jobafvikling, udbetalinger, data udtræk. c) Koordinering med ATP ERP, Afstemning, DWH. d) Overgangsinstrukser til Kunderådgiver. e) Integration til eksterne parter jf. systemkonteksten i bilag 3A (Behovsopgørelse), som skal nedlukkes og opstartes igen (databehandleraftaler og snitfladeaftaler). Leverandøren er ansvarlig for at konverteringen kan gennemføres indenfor den fastsatte tidsramme for konverteringen. De enkelte lukkevinduer til brug for den trinvise konvertering skal være så lille som muligt og skal være placeret uden for kritisk forretningstid, jf. bilag 7 (Servicemål). ATP skal godkende hvis Leverandøren ønsker at fravige dette. Selvbetjeningsløsningen skal i så vid mulig udstrækning være tilgængelig i et lukkevindue, således at borgere kan afgive deres ansøgning. Det er dog acceptabelt at opsamle disse informationer separat således at de efter et lukkevindue kan indlæses i Systemet. Hvis der er aktiviteter, der gennemføres indenfor kritisk forretningstid, skal der så vidt muligt fortsat være læseadgang til data, for sager der tidligere er konverteret ind i Systemet. Bilag 3A Behovsopgørelse Side 62 af 78

9.6.7 Håndtering af prøveudtræk Til brug for afprøvning af konverteringsprogrammellet vil der fra KMD blive leveret et prøveudtræk fra den Eksisterende Løsning. Der vil være tale om et fuldt udtræk af umaskerede produktionsdata; Indeholdende alt data for hele bestanden, dog kun med repræsentativ data fra udvalgte støttesystemer. Hvis der er behov for yderligere prøveudtræk (f.eks. af en delbestand), skal dette aftales med ATP. Leverandøren skal ved anvendelse af udtræk fra den Eksisterende Løsning sikre at de non-funktionelle krav i bilag 3A.1 (Kravliste) vedrørende test og datasikkerhed overholdes. 9.7 Brugervenlighed Dette emneområde angiver krav til, hvor nemt det skal være at benytte og tilgå Systemet. Brugervenlighed drejer sig primært om kvaliteten af brugergrænsefladen, hvilket eksempelvis drejer sig ergonomi, den visuelle oplevelse, skærmbillede opbygning, hvordan der navigeres rundt i Systemet og de hjælpemidler der stilles til rådighed for handikappede. 9.8 Lovgivning ATP ønsker sikkerhed for at Leverandøren i sit arbejde overholder gældende lovgivning, ligesom Systemet skal være konstrueret på en sådan måde, at ATP kan varetage de forretningsmæssige opgaver Systemet understøtter, således at almen og ATP-specifik lovgivning til en hver tid overholdes. Kravene fremgår af bilag 3A.1 (Kravliste). Det påhviler ATP at identificere og foretage de nødvendige fortolkninger af relevante dele af UDK-specifik lovgivning (fx Børne- og ungeydelsesloven, Børnetilskudsloven, Forvaltningsloven og Udbetaling Danmark Loven) samt omsætte disse til krav til Systemet. Leverandøren skal på ATP s anmodning deltage i dette arbejde. 9.9 Sikkerhed IT sikkerhed handler om at sikre konfidentialitet, integritet og tilgængelighed af information imod forskellige sikkerhedsrisici. Dette behov skal sikres ved at indarbejde tekniske og systemspecifikke kontroller både i infrastrukturen og i designet af Systemet samt i de underliggende forretningsprocesser. Kravene til sikkerhed fremgår af bilag 3A.1 (Kravliste). Bilag 3A Behovsopgørelse Side 63 af 78

9.10 Miljøer Leverandøren skal tilvejebringe et driftsmiljø samt en række interne såvel som eksterne miljøer til brug for udvikling, test og uddannelse. Til brug for afprøvningerne, beskrevet i bilag 6 (Afprøvninger), vil der være behov for et internt testmiljø, et eksternt testmiljø, et præproduktionsmiljø og så selve produktionsmiljøet. Kravene til de forskellige miljøer vil fremgå af bilag 3A.1 (Kravliste). 9.11 Projektledelse Leverandøren har det overordnede projektledelsesansvar og ansvarlig for projektledelsen i perioden fra kontraktindgåelsen og til Overtagelsesdagen. Projektledelsen skal ske i overensstemmelse med en formaliseret projektledelsesmetode og Leverandøren er ansvarlig for gennemførelsen af projektledelsesaktiviteter som fx planlægning og udarbejdelsen af tidsplaner jf. bilag 1 (Tidsplan) og kravene i bilag 3A.1 (Kravliste). 9.12 Uddannelse Leverandøren skal levere følgende uddannelse med tilhørende uddannelsesmateriale ATP s projektteam skal uddannes indenfor leverandør-, løsnings- og metodespecifikke områder, således at ATP s projektteam bliver i stand til at deltage effektivt i projektet omkring design, udvikling og ibrugtagning af Systemet. ATP s forretningsadministratorer skal uddannes i konfigurering og tilpasning af Systemet. ATP s undervisere skal uddannes, således at de er i stand til at uddanne øvrige brugere af Systemet ( train-the-trainer -princippet). De konkrete krav til uddannelse fremgår af bilag 3A.1 (Kravliste). 9.13 Dokumentation Leverandøren skal levere fyldestgørende og til en hver tid fuldt opdateret dokumentation af Systemet, herunder den efterfølgende drift og vedligeholdelse af dokumentationen. Leverandøren skal sikre, at ATP til enhver tid har adgang til opdateret og detaljeret dokumentation, der gør ATP i stand til at få fuld indsigt i Systemet. Samtidig skal dokumentationen være i en sådan stand, at en anden it-leverandør, uden unødigt besvær, vil kunne sætte sig ind i Systemet og eventuelt overtage drift, vedligeholdelse og videreudvikling heraf. Bilag 3A Behovsopgørelse Side 64 af 78

Den del af dokumentationen, der falder uden for Leverandørens ansvarsområde, jf. bilag 4 (Dokumentation) og programmel, skal som hovedregel udarbejdes og vedligeholdes af ATP. Leverandøren er dog ansvarlig for at assistere ATP med udarbejdelsen, kvalitetssikringen og vedligeholdelsen af denne dokumentation. De konkrete krav til Leverandøren i forhold til dokumentation fremgår af bilag 3A.1 (Kravliste) og bilag 4 (Dokumentation). 9.14 Idriftsættelse Leverandøren er ansvarlig for planlægningen og gennemførelsen af idriftsættelsen af Systemet. Idriftsættelsen af Systemet skal ske på en sådan måde, at påvirkningen af ATP s forretning minimeres, fx ved en minimering af nedetid. Leverandøren skal have et særligt fokus i forbindelsen med den trinvise idriftsættelse og første gangs afvikling af de enkelte jobs (batch kørsler, udbetalingskørsler m.v.). Leverandøren skal samarbejde med ATP for at sikre, at dette forløber succesfuldt, hvilket kan kræve øget bemanding og/eller øget kontrol/overvågning. Leverandøren skal sikre, at der foreligger en af ATP godkendt fallback-plan for enhver idriftsættelse. KMD har udarbejdet en beskrivelse for fallback til Eksisterende Løsning, vinduet for denne er limiteret til perioden fra udkonverteringen og er muligt så længe Systemet endnu ikke har kørt en udbetalingskørsel. De konkrete krav til Leverandøren i forhold til idriftsættelsen fremgår af bilag 3A.1 (Kravliste). 9.15 Hypercare I forbindelse med idriftsættelsen af Systemet ønsker ATP at Leverandøren leverer hypercare-ydelser, hvilket bl.a. inkluderer et øget beredskab hos Leverandøren og fysisk tilstedeværelse af Leverandørens nøglepersoner på ATP s lokalitet i Hillerød. Hypercare-ydelserne skal give ATP s undervisere og andre nøgleperson hos ATP øget adgang til bistand fra Leverandøren med henblik på at sikre en succesfuld implementering og ibrugtagning af Systemet. De konkrete krav til Leverandøren i forhold til hypercare fremgår af bilag 3A.1 (Kravliste). 9.16 Samarbejde og rapportering ATP ønsker et konstruktivt samarbejde med en professionel it-leverandør. Systemet er afgørende for Udbetaling Danmarks forretning, og er tæt integreret med en lang række af ATP s øvrige systemer. Det medfører at Leverandøren skal indgå i Bilag 3A Behovsopgørelse Side 65 af 78

regelmæssige og ad hoc møder med både ATP og ATP s Øvrige Leverandører, da dette vurderes som værende essentielt for opretholdelsen af driftsstabilitet og den tværgående koordinering. Leverandøren skal deltage i samarbejdsorganisationen og levere rapportering jf. kravene i bilag 8 (Samarbejdsorganisation og rapportering). 9.17 Test ATP ønsker et funktionelt, driftsstabilt og brugervenligt System, der lever op til arkitekturprincipperne jf. bilag 3A.1 (Kravliste). ATP anser Afprøvninger for at være en væsentlig kilde til at opnå dette, Afprøvninger prioriteres derfor meget højt. En forudsætning for en succesfuld proces i forhold til Afprøvninger er, at både ATP og Leverandøren indgår i processen på den mest hensigtsmæssige vis. Afprøvning af Leverancen, skal gennemføres for at sikre, at Leverancen opfylder de specificerede krav, og at Leverancen kan anvendes i henhold til det aftalte. En beskrivelse af de forskellige Afprøvninger, rækkefølgen for Afprøvningerne set i forhold til udviklingsmodellen, testværktøjer, testdokumentation, samt review af processen indgår ligeledes. For hver Afprøvning angives formålet, processen for gennemførelsen samt de Godkendelseskriterier, Leverancen skal opfylde for, at en Afprøvning kan betragtes som godkendt. Leverandøren er ansvarlig for planlægningen og udførelsen af alle Afprøvninger, og har dermed det fulde ansvar for alle Afprøvninger. De konkrete beskrivelser i forhold til Afprøvninger fremgår af bilag 6 (Afprøvninger). Bilag 3A Behovsopgørelse Side 66 af 78

10 Krav til Drift, vedligeholdelse, support og videreudvikling (Ydelserne) Som en del af udbuddet indgår Ydelserne fra Overtagelsesdagen og frem til bilag 7 s (Vilkår for Drift, Vedligeholdelse, Support og Videreudvikling) ophør. Dette afsnit og bilag 3A.1 (Kravliste) indeholder kravene til Leverandørens Ydelser. Et overblik over Ydelserne fremgår af nedenstående figur: Kundens opgaver Leverandørens ydelser Enterprise-arkitektur Kontraktstyring Brugersupport Etablering Vedligehold Videreudvikling Drift Rådgivning Dokumentation Sikkerhed Overvågning Optioner Figur 5 Kundens opgaver og Leverandørens ydelser. 10.1 Overordnede krav Leverandøren skal sikre tilstedeværelsen af de overordnede organisatoriske og tekniske rammer, der kan sikre, at de aftalte Ydelser leveres til ATP. Herunder hører rapportering, samarbejdsorganisation, kvalitetssikring, ressourcer og kapacitet og overholdelse af lovgivning og politikker. Bilag 3A Behovsopgørelse Side 67 af 78

10.2 Etableringsydelsen Leverandøren skal etablere grundlaget for varetagelse af Ydelserne, herunder Drift, vedligeholdelse, support og videreudvikling af Systemet. Etape III i Kontrakten afsluttes med en række prøver, som beskrevet i Kontraktens bilag 1 (Tidsplan) og bilag 6 (Afprøvninger). Leverandøren har det fulde ansvar for at etablere den samlede tekniske platform, herunder alle relevante miljøer og kommunikationsinfrastruktur, samt hertil hørende Programmel og maskinel, som specificeret i Kontrakten. I det efterfølgende gennemgås de overordnede Ydelser i etableringsperioden. 10.2.1 Etablering af lokaliteter Leverandøren skal etablere og forberede de Ydelseslokaliteter, hvorfra maskinellet, der stilles til rådighed for ATP, skal drives. 10.2.2 Etablering af kommunikationsinfrastruktur Leverandøren skal anskaffe og etablere kommunikationsinfrastruktur og maskinel på de Ydelseslokaliteter, Leverandøren vil benytte sig af i forbindelse med leveringen af Ydelserne. Leverandøren etablerer endvidere kommunikationsinfrastruktur mellem Leverandørens egne lokaliteter, mellem Leverandøren og ATP samt mellem Leverandøren og ATP s Øvrige Leverandører. 10.2.3 Etablering af Programmel Leverandøren skal tilvejebringe det Progammel, der er nødvendigt for at levere Ydelserne samt opfylde Kontrakten i øvrigt. Desuden er Leverandøren ansvarlig for at etablere de applikationer, der indgår i Systemet i sit eget miljø eller i at understøtte ATP i at installere disse på ATP s miljøer, i det omfang det er nødvendigt. 10.2.4 Etablering af processer for driftsafvikling og support Leverandøren forbereder og etablerer samtlige Servicedesk-procedurer, herunder IT Service Management værktøjer til understøttelse for supportprocesserne og integration mellem ATP s og andre relevante leverandørers IT Service Management værktøjer. Integrationen skal omfatte integration til alle discipliner i Service management, herunder Problem-, Incident-, Configuration-, Event- og Change management. 10.2.5 Etablering af processer og værktøjer til vedligeholdelse af Systemet Leverandøren skal etablere processer til vedligehold af Systemet, herunder processer til fejlfinding, rettelse af fejl og samarbejde med ATP. Desuden skal Leve- Bilag 3A Behovsopgørelse Side 68 af 78

randøren etablere de værktøjer, der er nødvendige for at understøtte processerne til vedligehold af Systemet. 10.3 Vedligeholdelse og videreudvikling af Systemet 10.3.1 Vedligeholdelse af Systemet Leverandøren varetager håndteringen af Fejl og Mangler ved Systemet, herunder vedligehold. På baggrund på vedligeholdelsen, skal Leverandøren løbende ajourføre Dokumentationen for Systemet. Leverandøren skal løbende fejlfinde og -afhjælpe konstaterede Fejl i Systemet i henhold til Kontrakten. Vedligehold dækker over løsning af alle Fejl og Mangler, som Leverandøren eller ATP måtte opdage samt forebyggende vedligehold og support. Forhold vedrørende rapportering af Incidents, fejlkategorier mv. sker på samme måde som den øvrige del af Driftsmiljøet. Der henvises også til bilag 7 (Servicemål) og bilag 8 (Samarbejdsorganisation og rapportering). Bilag 3A Behovsopgørelse Side 69 af 78

Definition: Vedligeholdelse og support Vedligehold omfatter foranstaltninger til forebyggende og afhjælpende vedligehold, der er nødvendige for at holde leverancen i god og driftssikker stand, herunder løbende at opretholde servicemål (jf. bilag 7): 1. Fejlsøgning, fejlrettelse, og implementering af fejlrettelser. 2. Omgåelse af fejl. 3. Forebyggelse af fejl herunder som eksempel stikprøve afprøvning af ITsystemerne i forbindelse med opdatering af basisprogrammel. 4. Små tilpasninger (timeforbrug < 3 timer). 5. Planlægning og opfølgning på forretningskritiske produktioner (kørsler/batchafvikling). 6. Medvirke i forbindelse med inspektion og revision herunder besvarelse af interne revisionsanmodninger. 7. Periodisk tilbagevendende ændringer til systemer, hvor alene IT-personer kan udføre de opgaver, der er nødvendige for at sikre en fortsat korrekt produktion. Aktiviteterne omfatter ikke tilpasninger eller udvikling, men inkluderer rettelse af evt. hard coded values og fremskaffelse af testdata. 8. Leverandøren skal - i overensstemmelse med god leverandørskik inden for ITbranchen - udføre alle de foranstaltninger til forebyggende og afhjælpende vedligeholdelse, der er nødvendige for at holde de omfattede applikationer i god og driftssikker stand. 9. Dokumentation til understøttelse af pkt. 1-8. Support omfatter følgende ydelser: 1. Besvarelse af spørgsmål fra Kundens udpegede kontakter (fagcoaches /superbrugere/proces- og løsningsansvarlige/fagspecialister og ATP Servicedesk) vedrørende anvendelsen af det omfattede Programmel 2. Besvarelse af spørgsmål fra Kundens leverandører, vedrørende anvendelsen af det omfattede Programmel, der ikke udspringer af fejl hos leverandøren (og kan udføres på under 15 minutter). 3. Simpel problemdiagnosticering (kan udføres på under 3 timer). 4. Generel vejledning vedrørende det pågældende Programmel, herunder vurdering af, om et konstateret forhold forudsætter indrapportering som fejl, behov for tilpasning eller udvikling. 5. Videregivelse af fejl til 3. part og sikre den efterfølgende opfølgning på samme. 6. Standardiserede dataudtræk, dvs. eksisterende udtræk eller som kan udarbejdes. under 3 timer. 7. Estimering med time-grænse under 3 timer. I bilag 7 (Servicemål), kap. 4.3.2 er Vedligeholdelse og Support benævnt ændringskategori C. Tabel 6 Definition af vedligeholdelse og support. Bilag 3A Behovsopgørelse Side 70 af 78

10.3.2 Videreudvikling af Systemet Leverandøren forestår, i samråd med ATP, den løbende videreudvikling af Systemet, således at dens funktionalitet bliver udvidet i overensstemmelse med udviklingen i ATP s behov. Leverandøren forestår den løbende vedligeholdelse af Systemet, herunder opdateringer, patches mv., der sikrer, at Systemet opretholder dens funktionalitet og følger den teknologiske udvikling i øvrige dele af Driftsmiljøet samt integrerer til andre af ATP s Øvrige Leverandørers og relevante tredjeparters systemer som ønsket. På baggrund af den videreudvikling der sker, skal Leverandøren løbende ajourføre Dokumentationen for Systemet. ATP har i dette punkt defineret krav til videreudviklingsydelsen, som Leverandøren skal opfylde i Kontraktens løbetid. Leverandørens ansvar for videreudvikling omfatter hele Systemet. Leverandøren er ansvarlig for videreudvikling af Systemet, eksempelvis som følge af: ændret administrativ praksis (instrukser) og nye forretningsgange ændringer i love og bekendtgørelser teknologisk udvikling, som kan ændre valget af elektronisk kommunikation mellem ATP og virksomheder brugerkrav i forbindelse med optimering af processer og funktioner tilpasning af grænseflader i forbindelse med nye og/eller ændrede omgivende systemer. Tilpasning, udvikling og projekter indgår i timepulje-aftale. Definition: Videreudvikling omfatter tilpasninger og udviklingsprojekter I forbindelse med presale/tilbudsgivning til Kunden, bidrager Leverandøren med bistand til rådgivning og frembringelse af løsningsforslag og priser (håndteres normalvis som ændringsanmodninger). Leverandøren udarbejder efter aftale sådanne løsningsforslag og prisestimater under budgetpuljen for tilpasninger og udvikling ved estimeringsopgaver > 3 timer. Tilpasning omfatter: funktionelle ændringer eller udvidelser til eksisterende omfattede applikationer og integrationer med et forventet forbrug indtil 2 mio. kr. pr. opgave. Bemærk: ATP kan vælge at ATP s projektmodel skal anvendes, hvis der f.eks. er integrationsopgaver involveret Bilag 3A Behovsopgørelse Side 71 af 78

I bilag 7 (Servicemål), kap. 4.3.2 er Tilpasning benævnt ændringskategori B Udviklingsprojekter omfatter: udvikling, integration og implementering af større funktionelle ændringer eller udvidelser til eksisterende omfattede applikationer med en forventet økonomi på over 2 mio. kr. pr. opgave. Bemærk: ATP s projektmodel skal anvendes, ligesom der er særlige KPIs (jf. bilag 7 og 8) I bilag 7 (Servicemål), kap. 4.3.2 er Udviklingsprojekter benævnt ændringskategori A Tabel 7 Definition af videreudvikling. 10.4 Løbende Drift 10.4.1 Lokaliteter Leverandøren varetager den løbende vedligeholdelse af Ydelseslokaliteter, herunder eksempelvis nødstrømsanlæg, brandslukning og køling mv. Endvidere foretager Leverandøren overvågning 24/7 af driftscenterlokaliteterne for at sikre overholdelsen af Servicemål og opretholdelse af sikkerhedsprocedurer. Leverandøren har det fulde ansvar for den samlede Drift af Systemet i overensstemmelse med det i det efterfølgende specificerede og Kontraktens krav i øvrigt. 10.4.2 Infrastruktur og maskinel Leverandøren varetager vedligeholdelsen af den kapacitet, som Leverandøren er forpligtet til at levere. Vedligeholdelsen af infrastruktur og maskinel skal sikre overholdelsen af Servicemål og opretholdelse af det krævede sikkerhedsniveau. Vedligeholdelse af desktop-maskinel varetages af ATP. 10.4.3 Programmel Vedligeholdelse af Programmel varetages af Leverandøren, der ligeledes løbende idriftsætter opgraderinger, patches mv. Leverandøren skal ligeledes løbende orientere ATP om eventuelle optimeringsmuligheder jf. Kontraktens bestemmelser om rådgivningspligt. 10.4.4 Teknologisk rådgivning, rapportering og support Leverandøren er ansvarlig for teknologisk rådgivning i forhold til Ydelserne. Det er endvidere Leverandørens opgave at foretage løbende rapportering, jf. bilag 8 (Samarbejdsorganisation og Rapportering), i forhold til fx driftsstatus, incidents og overholdelse af Servicemål. Alle brugerrelaterede Servicedesk henvendelser håndteres af ATP som 1. level support. Alle tekniske alarmer/incidents genereret på om- Bilag 3A Behovsopgørelse Side 72 af 78

råder, som Leverandøren har ansvaret for, håndteres af Leverandøren som 1. level support. 10.4.5 Dokumentation og konfigurationsstyring Leverandøren er ansvarlig for Dokumentation jf. bilag 4 (Dokumentation) og konfigurationsstyring og skal bl.a. vedligeholde en configuration management database (CMDB). I CMDB skal alle konfigurationselementer være sporbare, således at det bliver muligt at følge historikken på et specifikt konfigurationselement. Gennem configuration management skal der etableres Dokumentation af konfigurationer, miljøer, maskinel m.v. for at støtte service management processerne. Konfigurationsstyring skal ske i overensstemmelse med ITIL s anbefalinger til best practice. Krav til Dokumentation er endvidere beskrevet i bilag 4 (Dokumentation). 10.4.6 Sikkerhed og beredskab Leverandøren, dennes medarbejdere, Underleverandører og disses medarbejdere skal overholde de sikkerhedspolitikker, der til enhver tid er gældende i ATP s organisation, herunder krav om backup og vedligeholdelse af beredskabsplaner, jf. også Kontrakten samt bilag 13 (Sikkerhed). Leverandøren skal ligeledes løbende vedligeholde sikkerhedsprocedurer, herunder eksempelvis i forhold til fysiske og logiske adgange, elektronisk kommunikation, beskyttelse af personoplysninger mv. Endelig sikrer Leverandøren backup, genetablering og systemberedskabet i forhold til det omfattede maskinel og infrastruktur. 10.4.7 Overvågning Leverandøren varetager overvågning 24/7 af Ydelserne. 10.4.8 Ophørsbistand Leverandøren skal i forbindelse med ophør af Kontrakten, uanset årsagerne dertil levere Ophørsbistand som beskrevet i Kontrakten kapitel XIII og bilag 20 (Ophørsbistand). 10.4.9 Service Operation 10.4.9.1 Supportløsningen Alle brugerrelaterede Servicedesk henvendelser håndteres af ATP som 1. level support. Alle tekniske alarmer/ incidents genereret inden for Leverandørens an- Bilag 3A Behovsopgørelse Side 73 af 78

svarsområder, håndteres af Leverandøren som 1. level support. Leverandøren varetager ligeledes 2. level support. For en nærmere beskrivelse af samarbejdsorganisationen henvises til bilag 8 (Samarbejdsorganisation og Rapportering). 10.4.10 Incident management Incident management omfatter ATP s krav til Leverandørens processer inden for incident management. Incident management skal sikre, at hændelser, der ikke er en del af den normale Drift håndteres, således at Driften kan varetages optimalt og som minimum i overensstemmelse de definerede Servicemål, jf. bilag 7 (Servicemål). Incident management skal følge ITIL s anbefalinger til best practice. Forebyggelse baseret på incidents. Efter løsning af incidents, skal Leverandøren i relevant omfang, eventuelt i samarbejde med ATP s øvrige leverandører, foretage en opfølgning på processen for at sikre erfaringsopsamling, der kan forbedre fremtidige processer (proaktiv incident management). 10.4.11 Problem management Problem management omfatter ATP s krav til Leverandørens processer inden for problem management. Problem management skal medvirke til at minimere og forebygge de driftsmæssige konsekvenser af Incidents og Problems. Problem management processen har både reaktive og proaktive aspekter. Det reaktive aspekt vedrører løsning af problemer som reaktion på en eller flere incidents. Proaktiv problem management vedrører identifikation og løsning af problemer og kendte fejl (known errors) før en incident indtræffer. Leverandøren skal proaktivt konstatere og forebygge problemer, eksempelvis ved at reducere eller helt forebygge incidents, i forbindelse med løbende trendanalyser, som udføres i forbindelse med ydelsen. Trendanalysen kan eksempelvis håndteres ved gennemgang af alle Incidents (både løste og uløste) for gentagne fejlmønstre og root causes. 10.4.12 Change management Changes opstår på flere måder, fx som resultat af incidents, problemer, fra proaktiv søgning af forretningsfordele, eller på initiativ fra ATP. Bilag 3A Behovsopgørelse Side 74 af 78

Change management processerne skal sikre, at standardiserede metoder og procedurer anvendes for effektiv og hurtig håndtering af alle ændringer under kontrakten. En change er en hvilken som helst ændring af ATP s It-miljø. Samtlige ændringer skal følge change management processen med undtagelse af eventuelle standardændringer, som godkendes af ATP, og som dokumenteres i den af Leverandøren udarbejdede Driftsaftalehåndbog. 10.4.13 Release management Leverandøren skal sikre en struktureret og sikker udrulning af Programmel og maskinel i ATP s It-miljø, herunder skabe enighed om det faktiske indhold i releases gennem dialog med Change- og Releasegruppen, jf. bilag 8 (Samarbejdsorganisation og Rapportering). 10.4.14 Event management - Overvågning Leverandøren varetager løbende overvågning af samtlige hovedydelser omfattet af aftalen. Leverandøren tilbyder ligeledes, efter ATP s anmodning, opsætning af udvidet overvågning, fx af applikationsprogrammel. 10.4.15 Configuration management Gennem configuration management skal der etableres Dokumentation af konfigurationer, miljøer, maskinel mv. for at støtte service management processerne. Konfigurationsstyring skal ske i overensstemmelse med ITIL s anbefalinger til best practice. Krav til Dokumentation er endvidere beskrevet i bilag 4 (Dokumentation). 10.4.16 Capacity management Leverandøren skal sikre, at der er tilstrækkelig kapacitet i miljøerne til at kunne levere servicen i henhold til de aftalte servicemål samt Kontraktens øvrige krav. Leverandøren skal overvåge kapacitetsforbruget på alle relevante områder jf. bilag 8 (Samarbejdsorganisation og Rapportering) afsnit 9.1.1. Målingerne af kapacitetsforbruget skal være så hyppige eller af en sådan karakter, at det vil være muligt for Leverandøren rettidigt at spore selv mindre ændringer i forbrug, der kan fordre en skalering af kapacitetsydelserne og deraf følgende vederlagsregulering. Leverandøren skal registrere og opbevare de historiske målinger af kapacitetsforbruget. Bilag 3A Behovsopgørelse Side 75 af 78

11 Fremtidige tilpasninger til Systemet Der forventes at skulle ske en række fremtidige tilpasninger til Systemet, som skal ske løbende efter Overtagelsesdagen for Systemet. Nogle af disse tilpasninger skyldes ønsker om funktionelle udvidelser af Systemet, og nogle skyldes at der skal ske en transition fra IT-udbudsarkitekturen til IT-målarkitekturen. Tilpasningerne til Systemet er ikke prissat i forbindelse med kontraktindgåelsen, og de forventede tilpasninger til Systemet er derfor blot præsenteret overordnet i det følgende. Det er ikke sikkert, at alle de beskrevne tilpasninger vil blive gennemført. 11.1 Integration til fritagelse af Digital Post Det er muligt at hente en liste over personer, der er fritaget fra Digital Post fra e- Boks (leverandør af Digital Post). Det er muligt at Systemet ved en fremtidig ændring skal kunne hente disse fritagelser fra e-boks. Digital Post er ved at blive udbudssat, og vi kan derfor ikke vide hvem leverandøren bliver. Det er også muligt at informationen om fritagelse fra Digital Post bliver hentet ned i Beriget Grunddata og at Systemet får den via replikering fra Beriget Grunddata. 11.2 Integration til SKAT I udbudsarkitekturen er det beskrevet at Systemet kobler direkte op mod SKAT for at tilgå årsopgørelse og forskudsopgørelse. Denne løsning er dog en interimsløsning, indtil at SKAT kan udstille en standardiseret snitflade til hent af årsopgørelse og forskudsopgørelse. 11.3 Integration til SAPA SAPA er et brugervendt system, der giver sagsbehandleren et overblik over en person/virksomhed og dennes sager og dokumenter på tværs af alle fagsystemer ved at trække på eksterne oplysninger via Serviceplatformen. SAPA bliver udbudt af KOMBIT og Udbetaling Danmark vil anvende SAPA personoverblik, når det er driftsmodent, dog ikke SAPA advis. Udbetaling Danmark vil vurdere hvornår brugen af SAPA vil være til gavn for forretningen og derefter påbegynde implementering. 11.3.1 Forudsætningssystemer for integrationen til SAPA I forbindelse med integration til SAPA vil der være forudsætningssystemer som skal benyttes. Dette er f.eks. klassifikation og organisation. Organisation er et register der indeholder en myndighedsorganisation og skal understøtte at organisationen kun vedligeholdes i et system. Andre systemer som måtte have behov for at kende myndighedens organisation, kan trække på støttesystemet. Klassifikation er Bilag 3A Behovsopgørelse Side 76 af 78

et register der indeholder klassifikationer (KLE, FORM m.fl.). Registeret understøtter at en given klassifikation vedligeholdes i ét eksternt system. Udbetaling Danmark skal integrere til disse støttesystemer for at kunne benytte SAPA. 11.4 Integration til Grunddatafordeler Som erstatning for Beriget Grunddata vil Systemet skulle integrere op mod den fællesoffentlige grunddatafordeler, der i fremtiden vil stå for at fordele en række oplysninger. Disse data vil bl.a. være persondata, boligdata osv. Bilag 3A Behovsopgørelse Side 77 af 78

12 Optioner Kontrakten omfatter to optioner relateret til selve Kontrakten som er beskrevet i det efterfølgende. Optionerne er prissat i bilag 5 (Priser og betalingsplan), hvor Leverandøren også har anført fristen for ATP s bestilling af optionerne, hvis de skal leveres som en del af Udviklingsprojektet. 12.1 Option på Ordinær Forlængelse ATP ønsker tilbud på Option på Ordinær Forlængelse, som beskrevet i Kontraktens kapitel XVI. 12.2 Option på Udskydelsesadgang ATP ønsker tilbud på Option på udskydelsesadgang, som beskrevet i Kontraktens kapitel III. Bilag 3A Behovsopgørelse Side 78 af 78