Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Version 1.0 27-04-2015

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

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

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

7.3.3 SAGSDOKUMENTATION... 42 7.3.4 INFORMATIONSMODEL FAMILIEYDELSER... 42 7.3.5 FAMILIEYDELSESSAG... 42 7.3.6 FAMILIEYDELSERGRUNDOPLYSNING... 43 7.3.7 FAMILIEYDELSESTYPE... 43 7.3.8 FAMILIEYDELSESYDELSE... 45 7.3.9 UDBETALING... 45 7.3.10 FAMILIEYDELSESYSTEMADMINISTRATION... 45 8 IT ARKITEKTUR... 46 8.1 IT-UDBUDSARKITEKTUREN... 46 8.2 SYSTEMKONTEKST OG INTEGRATIONER... 48 8.2.1 INTEGRATIONER... 49 9 NON-FUNKTIONELLE KRAV TIL SYSTEMET... 52 9.1 ARKITEKTUR... 52 9.1.1 RAMMER FOR ARKITEKTUREN... 52 9.1.2 BELASTNING OG SKALERING... 52 9.1.2.1 Udbetalingskørsler... 52 9.1.2.2 Satsregulering... 53 9.1.2.3 Udsendelse af årlig påmindelse om enlig erklæring... 53 9.1.2.4 Årlig efterregulering... 53 9.1.2.5 Journaliser post på sagen... 53 9.1.2.6 Dataudtræk og øvrig rapportering... 53 9.2 DESIGN OG APPLIKATIONSSTRUKTUR... 53 9.3 LOGNING... 54 9.4 SYSTEMFLEKSIBILITET... 54 9.5 TILGÆNGELIGHED... 54 9.6 DATAKONVERTERING... 54 9.6.1 KONVERTERINGSKONCEPTET GENERELT... 54 Bilag 3A Behovsopgørelse Side 4 af 78

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... 59 9.6.5 AFSTEMNING OG DATAVALIDERING... 60 9.6.6 GENNEMFØRSEL AF KONVERTERINGEN... 61 9.6.7 HÅNDTERING AF PRØVEUDTRÆK... 62 9.7 BRUGERVENLIGHED... 63 9.8 LOVGIVNING... 63 9.9 SIKKERHED... 63 9.10 MILJØER... 63 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 OG VÆRKTØJER FOR DRIFTSAFVIKLING OG SUPPORT... 68 10.2.5 ETABLERING AF PROCESSER FOR TVÆRGÅENDE LEVERANDØR SAMARBEJDE... 69 10.2.6 ETABLERING AF PROCESSER OG VÆRKTØJER TIL VEDLIGEHOLDELSE AF SYSTEMET... 69 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... 74 10.4.9.1 Supportløsningen... 74 10.4.10 INCIDENT MANAGEMENT... 74 10.4.11 PROBLEM MANAGEMENT... 74 10.4.12 CHANGE MANAGEMENT... 75 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 10.5 INTEGRATION TIL FRITAGELSE AF DIGITAL POST... 77 10.6 INTEGRATION TIL SKAT... 77 10.7 INTEGRATION TIL SAPA... 77 10.7.1 FORUDSÆTNINGSSYSTEMER FOR INTEGRATIONEN TIL SAPA... 77 10.8 INTEGRATION TIL GRUNDDATAFORDELER... 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 BM LF Regeloversigt Forretningsroller Informationsbehandling_gui Bilag 3A Behovsopgørelse Side 8 af 78

Tabel 2 Behovsopgørelsen og tilhørende underbilag 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 9 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ådgivergivere, forretningsadministratorer og deres behov. Brugernes behov er i det efterfølgende skildret gennem: Brugerne af Systemet hvornår og hvordan møder brugerne Systemet Forretningsudbudsarkitekturen systemer, parter og sammenhænge Komponentmodellen hvad Systemet skal understøtte Forretningsprocesser tekniske understøttelse af de forretningsmæssige behov Informationsarkitekturen beskrivelse og gruppering af forretningsmæssige begreber 3.1 Brugerne af Systemet Helt overordnet er der tre typer af brugere af Systemet. Udgangspunktet for brugergrupperne er forskellige og de har forskellige behov. De forskellige brugeres anvendelse af Systemet er beskrevet i de følgende punkter. 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 digital selvbetjening, der er et element af den offentlige Digitaliseringsstrategi, stiller samtidig krav om, at der er selvbetjeningsløsninger, der imødekommer borgernes behov. 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 ansøge om familieydelser, ændre i egne oplysninger og vedhæfte dokumentation Bilag 3A Behovsopgørelse Side 10 af 78

Angiv oplysninger i en kørende sag, fx ændringer i enlig status eller svar på partshøring/høring 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), punkt 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ådgivergiverne 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ådgivergiver oplever et overblik, som er tilpasset den konkrete arbejdsopgave. En opgaveindbakke hvor alle opgaver er prioriteret og med sorterings- og udsøgningskriterier for kunderådgivergiverne 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). Bilag 3A Behovsopgørelse Side 11 af 78

En intuitiv og tilgængelig brugergrænseflade påvirker kunderådgivergiverens effektivitet i høj grad, hvorfor der både er fokus på overblik, brugervenlighed og svartider. Det handler om flow i opgaveløsningen og rådgivningssituationen, så mængden af klik, fejl og tid reduceres. Der henvises i øvrigt til: Bilag 2 (Situationsbeskrivelse), punkt 7, der beskriver arbejdet med manuelle processer. Kravene til kunderådgivergivernes brugergrænseflader er beskrevet med udgangspunkt i disse. Bilag 3A.1 (Kravliste), der indeholder de konkrete krav til kunderådgivergivernes 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ådgivergivernes brugergrænseflader. 3.4 Forretningsadministratorer Systemet skal understøtte, at en forretningsadministrator kan rette og slette i regler, parametre, 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 Bilag 3A Behovsopgørelse Side 12 af 78

foregå i overensstemmelse med informationssikkerheds- og kontrolpolitikken i ATP. Det er ATP som tildeler brugerne (inklusive 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, dokumentation 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 Bilag 3A Behovsopgørelse Side 13 af 78

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. 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 to (2) gange årligt. ATP s 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 14 af 78

4 Forretningsudbudsarkitekturen I dette punkt 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 Bilag 3A Behovsopgørelse Side 15 af 78

udvalgte systemer illustreret i forretningsudbudsarkitekturen. I nogle tilfælde er systemer 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 punkt 5. Systemet er at betragte som en hel løsning, hvor både automatiseret og manuel funktionalitet er placeret. Dette betyder, at kunderådgivergiverne 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. 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ådgivergivernes 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 Bilag 3A Behovsopgørelse Side 16 af 78

forretningsarkitekturen også, at vi modtager fysisk og Digital Post gennem hhv. Scanning Fysisk Post og Digital Post. 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 punkt 8 IT arkitektur. Bilag 3A Behovsopgørelse Side 17 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 18 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 punkter 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 dels kunderådgivergivernes daglige manuelle sagsbehandling (jf. punkt 3.3), og dels understøttes forretningsadministratorernes (jf. punkt 3.4). Kunderådgiverens behandling af sager tager enten udgangspunkt i behandling af opgaver fra Opgaveindbakken eller i telefonbetjening. Uanset hvilken kanal en kunderådgivergiver betjener, så sker det via nedenstående komponenter: Bilag 3A Behovsopgørelse Side 19 af 78

Opgaveindbakke, Sagshåndtering, Tværgående overblik og Manuelle breve Disse fire komponenter udgør tilsammen kunderådgivergivernes 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ådgivergiverne 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: Systemadministration Regeladministration 5.1.1 Opgaveindbakke Udgangspunktet for det daglige arbejde for en kunderådgivergiver vil være Opgaveindbakken. Via Opgaveindbakken udsøger kunderådgivergiver den arbejdspakke, som der skal arbejdes med. Arbejdspakken indeholder opgaver, som bliver vist via Opgaveindbakken. En opgave kan fx bestå af behandling af modtaget post, indscannede blanketter eller af hændelser, som Systemet ikke har kunnet eller kan håndtere automatisk. En kunderådgivergiver vælger en opgave, hvorefter den aktuelle sag låses for redigering af andre. 5.1.2 Manuelle Breve Denne komponent har ansvaret for at administrere, vedligeholde og anvende brevskabeloner til udsendelse af manuelt udarbejdede breve. Brevene 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. Bilag 3A Behovsopgørelse Side 20 af 78

5.1.3 Sagshåndtering Denne komponent leverer en brugergrænseflade, hvorfra kunderådgivergiveren udfører manuel sagsbehandling, og hvor familieydelsesdata kan vises og redigeres. 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ådgivergiverens indgangsvinkel til Systemet, særligt ved telefonbetjening, men også i forbindelse med øvrig sagsbehandling. Formålet er at give kunderådgivergiveren mulighed for, ved ét enkelt opslag, hurtigt at få et overblik over borgerens personlige forhold. Fra det Tværgående Overblik skal kunderådgivergiveren 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 punkt 8.2 Systemkontekst). 5.1.5 Systemadministration Systemadministration er en brugergrænseflade (flere skærmbilleder), 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ørelser og beregning af ydelser. Bilag 3A Behovsopgørelse Side 21 af 78

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). 5.2 Automatisk Denne gruppe af komponenter understøtter den automatiske sagsbehandling og består af følgende komponenter: Hændelser Validering Kontrol Beregning af ydelser Dan udbetaling Dan opkrævning Beskedhåndtering Modregning 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 modtager hændelser, som kan være fra interne eller eksterne registre, fra selvbetjeningsløsningen eller fra tidsfrister i Systemet. Herefter igangsættes den videre proces på baggrund af de regler, der er gældende for den aktuelle proces. 5.2.2 Validering Denne komponent har ansvaret for at validere alle inputdata. Det gælder både ansøgninger og ændringer til Systemet fra selvbetjeningsløsningen, indtastninger fra Kunderådgiver og modtagelse af data fra andre systemer (interne i ATP såvel som eksterne). Valideringen skal sikre konsistens i Systemets data, således, at beløb fx 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). Bilag 3A Behovsopgørelse Side 22 af 78

5.2.3 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. 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 ikke er opfyldt, skal der dannes en opgave, som efterfølgende vil blive behandlet manuelt af en kunderådgivergiver. 5.2.4 Beregning af Ydelser Beregning af Ydelser træffer ud fra regler afgørelser om en sag og indeholder beregningsfunktionaliteten for alle typer familieydelser. Komponenten træffer en afgørelse om berettigelse til familieydelser på baggrund af relevante oplysninger samt regler. Herefter beregnes ydelsen. Hvis ændringer i beregningsgrundlaget resulterer i, at der skal rettes et krav mod borgeren, sender komponenten kravet videre til Dan opkrævning. 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.2.5 Dan Udbetaling Komponenten skal samle og overføre udbetalinger til NemKonto. Den registrerer udbetalingsdata og danner udbetalingsfiler. 5.2.6 Dan Opkrævning Dan opkrævning skal kunne danne krav, der sendes til Debitor. Opkrævningen kan enten ske ved udsendelse af et girokort til borgeren eller ved modregning i kommende familieydelsesudbetalinger i Systemet. 5.2.7 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.8 Modregning Komponenten Modregning effektuerer modregninger i familieydelser for krav, der indmeldes fra Debitor. Komponenten har ansvaret for at modtage modregningsordninger fra Debitor og hvis muligt at foretage modregningen i udbetalinger. Efterfølgende sendes besked til Debitor om den foretagne modregning. 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 modtage og gemme data 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 fx om samlivsstatus og telefonnummer, som kunderådgivergiveren 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: Selvbetjening Bilag 3A Behovsopgørelse Side 24 af 78

Modtagelse af post 5.4.1 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 for udvalgte ydelser foretage en simulering af, hvor meget den enkelte forventes at få udbetalt. Selvbetjening udstiller, valider og modtager indtastede data og sender disse til Systemet for validering og eventuel registrering. 5.4.2 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.5 Øvrige Komponenter Denne gruppe indeholder Systemets øvrige komponenter: Sikkerhed Indekssynkronisering Rapporter Afstemning Jobafvikling Økonomi 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 Indekssynkronisering Systemet henter sags- og ydelsesinformationer fra de fælleskommunale støttesystemer Sags- og dokumentindeks og Ydelsesindeks. Bilag 3A Behovsopgørelse Side 25 af 78

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. forretningsudbudsarkitektur i punkt 4.1, i den overgangsperiode hvor nogle af ydelsesområdernes systemunderstøttes der. Samlet sikrer denne dataudveksling, at kunderådgivergiverne har et overblik over sager i både Udbetaling Danmark og i kommunerne. 5.5.3 Rapporter Rapporter har ansvaret for, at der kan dannes dataudtræk til interne ATP-systemer og eksterne samarbejdspartere. Desuden skal der kunne opsættes enkle rapporter til driftlederrapportering. Komponenten har en brugergrænseflade, som muliggør at forretningsadministratorer kan definere, vedligeholdes og danne driftlederrapporter samt dataudtræk til interne og eksterne modtagere. 5.5.4 Afstemning Afstemning leverer afstemningsdata fra Systemet til videre behandling. Afstemning har ansvaret for at udtrække og samle afstemningsdata fra Systemet, 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.5 Jobafvikling Komponenten har ansvaret for at håndtere driftflows for interne hændelser i Systemet, hvilket typisk drejer sig om batchkørsler. Komponenten vedligeholder regler for kørselstidspunkter og flowregler for afvikling af de automatiske kørsler. 5.5.6 Økonomi Systemet overfører posteringer til ATP`s ERP system i forbindelse med udbetalinger, dannelse af krav, ændringer til udbetalinger mv. Systemets kontonumre skal stemme overens med de kontonumre, som anvendes i ERP, så sum-posteringer mv. placeres korrekt i forbindelse med en overførsel. Bilag 3A Behovsopgørelse Side 26 af 78

Samlet set sikrer denne dataudveksling, at regler til understøttelse af regnskabslovgivning samt gældende revisionskrav kan overholdes. 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 27 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). 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. Bilag 3A Behovsopgørelse Side 28 af 78

Figur 4 Samlet procesoverblik Nederst i figuren vises de kommunikations-, styrings-, drifts- og støtteprocesser som er tværgående for hele Udbetaling Danmark. I de efterfølgende punkter 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 3: 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 punkterne 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 29 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ådgivergiver 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. 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. 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 registre. 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, hvorefter sagen sendes videre til Træf afgørelse. Det hele sker automatisk uden inddragelse af kunderådgivergiver 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. I forbindelsen med modtagelse af ansøgninger eller registrering af nye børn og ydelsesmodtagere opsættes abonnementer i relevante registrer. Efterfølgende Bilag 3A Behovsopgørelse Side 30 af 78

modtages løbende oplysninger om ydelsesmodtagere, der kan have betydning for berettigelsen til familieydelser. 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 validere data, der er til rådighed 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ådgivergiver 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 Familieydelser - Dan udbetalingsgrundlag 2.4.2.1 Formålet med processen er at bestemme og danne det endelige udbetalingsgrundlag. Bilag 3A Behovsopgørelse Side 31 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 informationer om indbetalinger (for bidragssager) og 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ådgivergiver, 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 krav 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, der modtager 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. 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 effektuere udbetalingerne af familieydelser, samt danne relevante posteringer til regnskabet 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. Ved afviste udbetalinger sendes automatisk brev til modtager, eller der dannes en opgave til en kunderådgivergiver. Bilag 3A Behovsopgørelse Side 32 af 78

Når der udbetales Børne- og ungeydelser gives 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, fx når en udbetaling ikke er modtaget pga. manglende NemKonto. Henvendelserne behandles manuelt af kunderådgivergiverne. 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. 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 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 Den tværgående proces Håndter telefonisk kontakt, består af to løsningssubflows: LSF Modtag telefonopkald LSF Foretag telefonopkald Bilag 3A Behovsopgørelse Side 33 af 78

Flowsene beskriver overordnet hvordan telefonopkald modtages og foretages i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. 6.2.8 Tværgående proces Håndter dataleverance 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 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 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 34 af 78