Bilag 3A Behovsopgørelse

Bilag 3A Behovsopgørelse Version 0.8 26-06-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... 17 4.4 ØVRIGE ELEMENTER I FORRETNINGSUDBUDSARKITEKTUREN... 17 5 KOMPONENTMODEL... 18 Bilag 3A Behovsopgørelse Side 1 af 80 1

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

5.5.9 KOMMUNAL MELLEMFINANSIERING... 29 6 FORRETNINGSPROCESSER... 31 6.1 SAMLET PROCESKATALOG... 32 6.2 KERNEPROCESSER... 33 6.2.1 KERNEPROCES HÅNDTER INDBERETNING 1.2.1... 33 6.2.1.1 LF Boligstøtte Håndter indberetning 1.2.1.1... 34 6.2.1.2 LF Boligstøtte Håndter automatisk genererede oplysninger 1.2.1.2... 34 6.2.2 KERNEPROCES - TRÆF AFGØRELSE 2.2.1... 35 6.2.2.1 LF Boligstøtte Træf afgørelse 2.2.1.1... 35 6.2.3 KERNEPROCES HÅNDTER DRIFT 2.2.2... 36 6.2.3.1 LF Boligstøtte - Dan udbetalingsgrundlag 2.2.2.1... 36 6.2.3.2 LF Boligstøtte Udfør årlig efterregulering og årsomregning 2.2.2.2... 37 6.2.4 KERNEPROCES HÅNDTER UDBETALING 3.2.1... 37 6.2.4.1 LF Boligstøtte Effektuer udbetaling 3.2.1.1.... 37 6.2.5 KERNEPROCES HÅNDTER OPKRÆVNING 3.2.2... 37 6.2.5.1 LF Boligstøtte Dan krav 3.2.2.1... 38 6.2.6 TVÆRGÅENDE PROCES HÅNDTER POST... 38 6.2.7 TVÆRGÅENDE PROCES HÅNDTER TELEFONISK KONTAKT... 38 6.2.8 TVÆRGÅENDE PROCES HÅNDTER DATALEVERANCE... 38 6.2.9 TVÆRGÅENDE PROCES HÅNDTER WEBADGANG... 39 6.2.10 TVÆRGÅENDE PROCES HÅNDTER WEBSERVICE... 39 7 INFORMATIONSARKITEKTUR... 40 7.1 OVERORDNET BEGREBSMODEL FOR UDBETALING DANMARK... 40 7.2 BEGREBS- OG INFORMATIONSMODELLER FOR FORRETNINGSLØSNINGEN... 41 7.2.1 DOKUMENTATION TIL LEVERANDØR... 41 7.2.2 INFORMATIONSMODEL SAG... 42 7.2.2.1 Udbetaling Danmark definition af Sag... 42 7.2.2.2 Sag - Nøgler og Egenskaber... 43 Bilag 3A Behovsopgørelse Side 3 af 80 3

7.2.2.3 Sagens relationer... 45 7.2.2.4 Sagens oprettelse og livsforløb... 46 7.2.3 PART... 46 7.2.4 SAGSDOKUMENTATION... 47 7.2.5 INFORMATIONSMODEL BOLIGSTØTTE... 47 7.2.6 BOLIGSTØTTESAG... 47 7.2.7 BOLIGSTØTTEGRUNDOPLYSNING PERSON & BOLIG... 47 7.2.8 BOLIGSTØTTEYDELSE... 47 7.2.9 BOLIGSTØTTEYDELSESTYPE... 48 7.2.10 BOLIGSTØTTETILSLUTNINGSREGISTER... 48 7.2.11 BOLIGSTØTTEUDBETALING... 49 7.2.12 BOLIGSTØTTESYSTEMADMINISTRATION... 49 8 IT ARKITEKTUR... 50 8.1 IT-UDBUDSARKITEKTUREN... 50 8.2 SYSTEMKONTEKST OG INTEGRATIONER... 52 8.2.1 INTEGRATIONER... 53 9 NON-FUNKTIONELLE KRAV TIL SYSTEMET... 56 9.1 ARKITEKTUR... 56 9.1.1 RAMMER FOR ARKITEKTUREN... 56 9.1.2 BELASTNING OG SKALERING... 56 9.1.2.1 Udbetalingskørsler... 56 9.1.2.2 Satsregulering... 57 9.1.2.3 Årlig efterregulering... 57 9.1.2.4 Journaliser post på sagen... 57 9.1.2.5 Dataudtræk og øvrig rapportering... 57 9.2 DESIGN OG APPLIKATIONSSTRUKTUR... 57 9.3 LOGNING... 57 9.4 SYSTEMFLEKSIBILITET... 58 Bilag 3A Behovsopgørelse Side 4 af 80 4

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

10.2.6 ETABLERING AF PROCESSER OG VÆRKTØJER TIL VEDLIGEHOLDELSE AF SYSTEMET... 72 10.3 VEDLIGEHOLDELSE OG VIDEREUDVIKLING AF SYSTEMET... 72 10.3.1 VEDLIGEHOLDELSE AF SYSTEMET... 72 10.3.2 VIDEREUDVIKLING AF SYSTEMET... 74 10.4 LØBENDE DRIFT... 75 10.4.1 LOKALITETER... 75 10.4.2 INFRASTRUKTUR OG MASKINEL... 75 10.4.3 PROGRAMMEL... 75 10.4.4 TEKNOLOGISK RÅDGIVNING, RAPPORTERING OG SUPPORT... 75 10.4.5 DOKUMENTATION OG KONFIGURATIONSSTYRING... 76 10.4.6 SIKKERHED OG BEREDSKAB... 76 10.4.7 OVERVÅGNING... 76 10.4.8 OPHØRSBISTAND... 76 10.4.9 SERVICE OPERATION... 76 10.4.9.1 Supportløsningen... 76 10.4.10 INCIDENT MANAGEMENT... 77 10.4.11 PROBLEM MANAGEMENT... 77 10.4.12 CHANGE MANAGEMENT... 77 10.4.13 RELEASE MANAGEMENT... 78 10.4.14 EVENT MANAGEMENT - OVERVÅGNING... 78 10.4.15 CONFIGURATION MANAGEMENT... 78 10.4.16 CAPACITY MANAGEMENT... 78 10.4.17 FREMTIDIGE TILPASNINGER TIL SYSTEMET... 79 10.5 INTEGRATION TIL FRITAGELSE AF DIGITAL POST... 79 10.6 INTEGRATION TIL SKAT... 79 10.7 INTEGRATION TIL SAPA... 79 10.7.1 FORUDSÆTNINGSSYSTEMER FOR INTEGRATIONEN TIL SAPA... 79 10.8 INTEGRATION TIL GRUNDDATAFORDELER... 80 Bilag 3A Behovsopgørelse Side 6 af 80 6

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

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) Bilag 3A.9 (Beregningsark) 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 boligstøtte. Bilaget indeholder de aktivitetsbeskrivelser, der indgår i de løsningsflows og forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af boligstøtte. Bilaget indeholder UML modeller af de væsentligste forretningsmæssige begreber og de informationer, som vedrører indberetning, administration og udbetaling af boligstøtte. Bilaget indeholder standardiserede modeller af de regler af lovgivningsmæssig og anden karakter forbundet med indberetning, administration og udbetaling af boligstøtte. 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 Forretningsroller Informationsbehandling_gui Bilaget indeholder vejledning til beregning af boligstøtte. Tabel 2 Behovsopgørelsen og tilhørende underbilag Bilag 3A Behovsopgørelse Side 8 af 80 8

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 80 9

3 Den samlede forretningsmæssige løsning Beskrivelsen af den forretningsmæssige løsning for boligstøtte tager udgangspunkt i brugerne af Systemet; borgere, kunderådgivere, 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 behov for at forstå ansøgnings-, ændrings- 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 boligstøtte, ændre i egne oplysninger, vedhæfte dokumentation og svare på diverse henvendelser, som agterskrivelser. Angive oplysninger i en kørende sag, fx ændringer i husstandssammensætning eller svar på partshøring. Bilag 3A Behovsopgørelse Side 10 af 80 1

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å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 oplysninger 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å 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 3A Behovsopgørelse Side 11 af 80 1

Bilag 2 (Situationsbeskrivelse), punkt 7, 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, 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 minimerer 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 (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. Bilag 3A Behovsopgørelse Side 12 af 80 1

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æsentligt, 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. 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. Bilag 3A Behovsopgørelse Side 13 af 80 1

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 boligstøtteområ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 80 1

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 og registre i den forretningsmæssige løsning og dels den ønskede forretningsmæssige funktionalitet. Ved hjælp af farver er det angivet hvilken type af funktionalitet, der er tale om, fx hvorvidt det er fællesoffentlig eller fælleskommunal funktionalitet. Modellen og den efterfølgende forklarende tekst tjener som introduktion til Boligstøtteløsningen på et konceptuelt plan. Figuren nedenfor viser de væsentligste elementer i forretningsudbudsarkitekturen. Figur 2: Forretningsudbudsarkitektur for boligstøtte Bilag 3A Behovsopgørelse Side 15 af 80 1

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 boligstøtte, 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 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 Det er i denne del af Systemet, at man finder it-understøttelsen til administration af boligstøttesagerne. De blå kasser repræsenterer forretningskomponenter, der beskrives i punkt 5. Systemet er at betragte som en hel løsning, hvor både automatisering samt manuel funktionalitet er placeret. Kunderådgiverne arbejder primært i Systemet, og her løser de stort set alle Opgaver herunder efterregulering og årsomregning. 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 landeveje (jf. Bilag 2A). Systemet indeholder den funktionalitet og sikrer adgang til de data, der er behov for, i forhold til at behandle en i given Opgave 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 en modtaget ansøgning om boligstøtte. 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. Hos kunderådgiverne foretages der en række manuelle kontroller, hvorefter sagen så vidt muligt kan komme tilbage på det automatiserede spor. I overensstemmelse med ombudsmandens notat: Forvaltningsretlige krav til det offentliges IT-løsninger, så skal Systemet understøtte, at der kan sendes en Besked til borgeren i umiddelbar forlængelse af, at afgørelsen træffes. Hvorvidt disse Bilag 3A Behovsopgørelse Side 16 af 80 1

Beskeder skal gives i alle tilfælde og i hvor høj grad kan processerne automatiseres, skal dog først afklares endeligt i afklaringsfasen. 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. Denne skal give borgerne adgang til at søge om boligstøtte, indberette ændringer, se oplysninger på Min Side og modtage generel vejledning om boligstøtte. Udbetaling Danmark har etableret en kviklinje for kommunerne, som er en direkte telefonlinje til Udbetaling Danmark. Den skal sikre hurtige svar og afklaringer om en borgers sag mellem kommunen og Udbetaling Danmark. Derudover illustrerer 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. Se punkt 8 for en fuldstændig liste over Integrationer. Bilag 3A Behovsopgørelse Side 17 af 80 1

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 også for funktionalitet til håndtering af hændelser, beslutning om hvorvidt sager skal til manuel kontrol, beregning af ydelser og modregningsregler. Derfor skal Komponenternes funktionalitet kunne ændres gennem en brugergrænseflade bestående af flere skærmbilleder, hvor ATP s forretningsadministratorer kan konfigurere regler og parametre til regler. Bilag 3A Behovsopgørelse Side 18 af 80 1

Figuren nedenfor viser komponentmodellen for boligstøtte. 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). Bilag 3A Behovsopgørelse Side 19 af 80 1

5.1 Manuelt Denne gruppe af Komponenter understøtter dels kunderådgivernes 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ådgiver betjener, så sker det via nedenstående Komponenter: Opgaveindbakke, Sagshåndtering, Tværgående overblik og Manuelle breve 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: Systemadministration Regeladministration 5.1.1 Opgaveindbakke Udgangspunktet for det daglige arbejde for en kunderådgiver vil være Opgaveindbakken. Via Opgaveindbakken udsøger kunderådgiver 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ådgiver vælger en opgave, hvorefter den aktuelle sag låses for redigering af andre. Hvor det er muligt skal komponenten igangsætte det automatiserede flow igen, når opgaven afsluttes. Bilag 3A Behovsopgørelse Side 20 af 80 2

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 generere 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 boligstøttedata 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ådgiverens indgangsvinkel til Systemet, særligt ved telefonbetjening, men også i forbindelse med øvrig sagsbehandling. Formålet er at give kunderådgiveren mulighed for, ved ét enkelt opslag, hurtigt at få et overblik over borgerens situation. 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 punkt 8.2 Systemkontekst). 5.1.5 Systemadministration Systemet indeholder en brugergrænseflade (flere skærmbilleder), hvor en forretningsadministrator kan konfigurere information, som udstilles i brugergrænseflader, samt håndtere forskellige opsætninger ift. brevskabeloner, arbejdspakker, tekster, hjælpeinformation, kontoplan, mapning mellem system- og forretningsroller, genvejstaster mv. Bilag 3A Behovsopgørelse Side 21 af 80 2

Brugergrænsefladen skal være rettet mod en forretningsadministrator, der har kendskab til de forskellige områder. Der må ikke forudsættes særlige IT-tekniske kompetencer. 5.1.6 Regeladministration Det er vigtigt, at Systemet er fleksibelt og robust for indførsel af nye forretningsprocesser og ændret lovgivning. Vi må forvente, at der sker en løbende tilpasning af reglerne for boligstøtte, der kan få betydning for, hvad der kan håndteres automatisk, og hvad der kan behandles manuelt. Det er væsentligt, at denne optimering af vores arbejdsprocesser kan tilpasses smidigt og uden store implementeringsomkostninger. Komponenten Regeladministration indeholder de nødvendige og tilstrækkelige beregningsparametre til at træffe afgørelser om boligstøtte og ydelsesberegninger, samt typer af regler, der er nødvendige for at gennemføre korrekt sagsbehandling. Komponenten indeholder tillige de parametre, der enten indgår i de enkelte regler eller selvstændigt styrer en given proces som eksempelvis tidspunktet for udsendelse af Beskeder omkring tidsbestemte hændelser. Komponenten leverer en brugergrænseflade til at vedligeholde regler og parametre, der anvendes til at udføre validering, kontrol, afgørelse og beregning af ydelse. Når rettelsen af de relevante parametre har fundet sted, så skal det være muligt, at teste resultatet i et præ-produktionsmiljø inden ændringerne lægges i produktion. Brugergrænsefladen skal være rettet mod en forretningsadministrator, der har kendskab til de forskellige områder. Der må ikke forudsættes særlige IT- tekniske kompetencer. I Regeladministration vedligeholdes også regler for hvilke processer, der skal igangsættes, når de enkelte 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 80 2

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 modtages enten fra eksterne eller interne registre eller opstår som følge af en validering/kontrol i Systemet eller fra tidsfrister i Systemet. I visse tilfælde vil Hændelser bliver til en Opgave. Når en hændelse modtages, så igangsættes der en proces, der er designet ud fra de regler, der knytter sig til håndteringen af den pågældende Hændelse. Hvis Hændelsen skal håndteres automatisk, så kræver det, at data til brug for de relevante valideringer og kontroller kan hentes og ligeledes bruges i en automatisk proces. Hvis dette ikke er muligt, så må hændelsen håndteres manuelt. 5.2.2 Validering Denne komponent har ansvaret for at validere alle inputdata. Det gælder både ansøgninger og ændringer, som modtages af 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. Dette sker ud fra et sæt af beslutningsregler, der er implementeret i komponenten Regeladministration. Validering udstiller services til Selvbetjening jf. bilag 3A. (Kravliste). 5.2.3 Kontrol Denne komponent har ansvaret for at behandle ansøgninger og ændringer efter Validering succesfuldt har valideret inputdata. Komponenten udfører kontrol af an- Bilag 3A Behovsopgørelse Side 23 af 80 2

søgningen eller ændringen for at sikre, at ansøger retsmæssigt er berettiget til at modtage boligstøtte. Kontrollen sker ud fra et sæt af beslutningsregler, som er defineret i Regeladministration og som vedligeholdes af en forretningsadministrator. Kontrollerne sker kun på de data, der er til rådighed i Systemet fra autoritative kilder og borgeren selv. Et eksempel på en kontrol kunne være, om husstanden består af andre end dem, som ansøger har oplyst. Hvis en eller flere af disse kontrolbetingelser er opfyldt, så adviseres en kunderådgiver via en opgave i Opgaveindbakken. 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.4 Beregning af Ydelser Beregning af Ydelser indeholder beregningsfunktionaliteten for alle typer af sagsforløb og for alle varianterne af boligsikring og boligydelse. Komponenten træffer en afgørelse på baggrund af relevante oplysninger og beregner ydelsen. Herefter oprettes en økonomisk effektueringsplan, som afspejler den ydelse, som borgeren er tilkendt. Hvis ændringer i beregningsgrundlaget (eindkomst) resulterer i, at borgeren i en periode har fået for meget eller for lidt udbetalt i boligstøtte, så sørger Komponenten for at justere den eller de kommende boligstøtteudbetalinger. Hvis Komponentens beregning i øvrigt resulterer i, at der skal rettes et krav mod borgeren, så sender Komponenten automatisk en opkrævning til Opkrævningssystemet. 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 Denne Komponent har ansvaret for at samle og overføre udbetalinger til udbetalingssystemet. Den registrerer udbetalingsdata og genererer udbetalingsfiler. Boligstøtte udbetales til borgere, boligorganisationer og kommuner. Denne Komponent skal således være i stand til at samle udbetalingerne til de borgere, der bor i en almen bolig og udbetale disse på én gang til boligorganisationernes NemKonto. Bilag 3A Behovsopgørelse Side 24 af 80 2

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 fra Debitor til borgeren eller ved modregning i kommende boligstøtteudbetalinger i Systemet. I forbindelse med lånesager (ejer- og andelsboliger), så skal der ved hver udbetaling fra Systemet foretages en overførsel af gælden til Debitor. Dermed har Debitor hele tiden et overblik over boligstøttemodtagerens gæld og kan dermed også - eksempelvis foretage en rentetilskrivning på lånet. 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. 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 effektuerer modregninger i boligstøtte for krav, der indmeldes fra opkrævningssystemet og fra eksterne systemer. For boligstøttes vedkommende skal der eksempelvis udveksles oplysninger med et eksternt opkrævningssystem via modregningsfordeleren på serviceplatformen i forbindelse med modregning af beboerindskudslån. Komponenten har ansvaret for, at der dannes udbetalingsposter til fordringshavere for de modregninger, som komponenten foretager. 5.3 Støttekomponenter Denne gruppe af Komponenter varetager informationer om borgere og boliger fra autoritative registre samt sager og dokumenter: Persondata Boligdata Sager og dokumenter 5.3.1 Persondata Denne komponent har ansvaret for at hente og gemme persondata fra Beriget Grunddata. Persondata udstiller disse informationer for de øvrige Komponenter i Systemet. Bilag 3A Behovsopgørelse Side 25 af 80 2

Komponenten skal vedligeholde de ydelsesspecifikke persondata, som ikke vedligeholdes i det tværgående støttesystem, Beriget Grunddata. Dette drejer sig fx om samlivsstatus, telefonnummer, relationer (fx anbragt barn, solidarisk hæfter mv.) og undtagelse for obligatorisk selvbetjening, som enten modtages automatisk via Serviceplatformen, eller som kunderådgiveren opdaterer igennem Systemet. 5.3.2 Boligdata Denne komponent har ansvaret for at hente data vedrørende relevante boliger fra Beriget Grunddata. Det drejer sig om data fra BBR og fra ESR. 5.3.3 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. Den består af følgende Komponenter: Selvbetjening 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 boligstøtte, 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. Selvbetjening udstiller, validerer og modtager indtastede data og sender disse til Systemet for validering, kontrol og beregning. Selvbetjening stiller også en løsning til rådighed for boligorganisationer, således, at disse har mulighed for at kunne der her igennem har mulighed for at afvise udbetalinger til enkelte af deres lejere, hvis de alligevel ikke skal have boligstøtte. Bilag 3A Behovsopgørelse Side 26 af 80 2

Udbetaling Danmarks bestyrelse ønsker at bringe Udbetaling Danmarks serviceniveau på niveau med andre offentlige myndigheder. ATP er derfor sammen med den nuværende leverandør (KMD) i gang med at udvikle en tidssvarende selvbetjeningsløsning (frontend) til Boligstøtte på den eksisterende fagløsning, som man forventer, kan gå i luften allerede fra starten af 2016. Udviklingen af selvbetjeningsløsningen sker i tæt samarbejde med Konkurrenceudsættelsesprogrammet, så den kan stilles til rådighed for den kommende leverandør af den nye samlede Boligstøttesystem. 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 Tilslutningsregister Kommunal Medfinansiering. 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 27 af 80 2

Systemet skal tilsvarende levere sags- og ydelsesinformationer for boligstøttesager til de samme indeks, 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ådgiverne har et overblik over sager i både Udbetaling Danmark og i kommunerne og på denne baggrund bl.a. kan foretage helhedsorienteret vejledning af borgeren på tværs af Udbetaling Danmarks og kommunernes opgavesplit. 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, vedligeholde 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 Bilag 3A Behovsopgørelse Side 28 af 80 2

stemme overens med de kontonumre, som anvendes i ERP, så sum-posteringer mv. 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. Desuden skal en forretningsadministrator kunne vedligeholde kontobro til bogføringsdata. 5.5.7 Arkivering Komponenten har ansvaret for at 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åndtere denne aflevering af data. 5.5.8 Tilslutningsregister Tilslutningsregisteret anvendes i forbindelse med udbetaling af boligstøtte direkte til boligorganisationer. Registret indeholder samtlige boligorganisationer i Danmark, hvor oversigten over boligorganisationer vedligeholdes af Beriget Grunddata. Ved hjælp af en brugergrænseflade skal det være muligt at styre, hvorvidt en boligorganisation har indgået en aftale med Udbetaling Danmark vedrørende udbetaling, eller om boligorganisationens beboere skal have boligstøtten udbetalt til deres egen NemKonto. Det skal være muligt at koble boligorganisationerne sammen, hvis de eksempelvis benytter en administrator. Det skal også være muligt at vedligeholde diverse kontaktoplysninger til boligorganisationen. 5.5.9 Kommunal Mellemfinansiering Denne komponent skal sikre, at kommunernes andel i finansieringen af boligstøtte kan håndteres. Komponenten skal understøtte, at der automatisk kan beregnes, hvor meget hver kommune skal have trukket via en udbetalingsanmodning i Nem- Konto eller udbetalt af kommunal medfinansiering (KMF). Beregningen skal ske pr. måned og skal tage højde for alle bevægelser af boligstøtten, herunder udbetaling, tilbagesøgning af for meget udbetalt, samt afskrivning af krav vedrørende for meget udbetalt boligstøtte. I de tilfælde hvor der har været for meget i boligstøtte, og der derfor er opkrævet for meget kommunal medfinansiering fra en kommune, skal der ske refusion af Bilag 3A Behovsopgørelse Side 29 af 80 2

KMF. Denne refusion skal medtages i beregningen af KMF i den måned, hvor kravet identificeres, og ikke først efter at borgeren har tilbagebetalt kravet til Udbetaling Danmark. NemKonto anvendes til at gennemføre udbetalingen for kommunerne for betaling af medfinansieringen. Systemet skal automatisk sende bogføringsposter til hver af de kommuner, hvor der er et træk eller en udbetaling af KMF. Bogføringsposterne skal sendes via en Integration til de fælleskommunale ØiR-snitflader. Systemet skal endvidere sende en rapporteringsfil pr. kommune til fordelingskomponenten, som herefter fordeler rapporterne til de respektive kommuner. Kommunerne kan vælge at modtage rapporterne som Digital Post, hvor selve rapporten er vedhæftet, eller kommunen kan vælge at lade et system modtage rapporten, så den eventuelt kan behandles automatisk. Bilag 3A Behovsopgørelse Side 30 af 80 3

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). Bilag 3A Behovsopgørelse Side 31 af 80 3

6.1 Samlet proceskatalog Processerne markeret i den grønne ramme i proceskataloget angiver de forretningsmæssige kerneprocesser, der benyttes i administrationen af boligstøtte. Figur 4 Samlet procesoverblik Bilag 3A Behovsopgørelse Side 32 af 80 3

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.2.1 LF Boligstøtte Håndter indberetning 1.2.1.1 LF Boligstøtte Håndter automatisk genererede oplysninger 1.2.1.2 Administration Træf afgørelse 2.2.1 LF Boligstøtte Træf afgørelse 2.2.1.1 Håndter drift 2.2.2 LF Boligstøtte Dan udbetalingsgrundlag 2.2.2.1 LF Boligstøtte Udfør årlig efterregulering og årsomregning 2.2.2.2 Udbetaling Håndter udbetaling 3.2.1 LF Boligstøtte Effektuer udbetaling 3.2.1.1 Håndter opkrævning 3.2.2 LF Boligstøtte Dan krav 3.2.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 boligstøtteområdet. Kerneprocesserne er nedbrudt i Løsningsflows (LF), som er yderligere beskrevet i punkterne nedenfor. 6.2.1 Kerneproces Håndter indberetning 1.2.1 Processen håndterer simulering af boligstøtteberegninger, samt ansøgning om boligstøtte og modtagelse af ændringer til eksisterende boligstøttesager. Processen henter oplysninger fra en lang række autoritative registre og stiller disse til rådighed for en ny ansøger eller en eksisterende modtager af boligstøtte. Processen håndterer ligeledes logon fra øvrige husstandsmedlemmer. Den sidste del af denne kerneproces sikrer, at der oprettes abonnementer til autoritative registre og at der automatisk hentes oplysninger fra disse. Ændringer, der Bilag 3A Behovsopgørelse Side 33 af 80 3

opstår som følge af valideringer i fagsystemet mv., bliver ligeledes registreret og sendt til behandling i de efterfølgende processer. Kerneprocessen Håndter Indberetning består af følgende løsningsflows: LF Boligstøtte - Håndter indberetning 1.2.1.1 LF Boligstøtte Håndter automatisk genererede oplysninger 1.2.1.2 6.2.1.1 LF Boligstøtte Håndter indberetning 1.2.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 boligstøtte eller angive ændringer til en eksisterende sag. I dette løsningsflow har personer også mulighed for at foretage en simulering af en boligstøtteberegning (uden at logge på Borger.dk). Blanketansøgninger modtages ligeledes i dette løsningsflow. 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 benytte simulering/beregning af ydelser. Hvis der logges på selvbetjeningsløsningen henter Systemet de oplysninger, der er til rådighed om personen, dennes husstand og nuværende bolig. Herefter har vedkommende mulighed for at søge om boligstøtte eller angive ændringer til eksisterende sager. Undervejs i ansøgningen eller i forbindelse med indberetningen af en ændring, så henter Systemet selv de oplysninger, der er tilgængelige via de autoritative registre. Det drejer sig om oplysninger via Beriget Grunddata, SKAT, KMD Indkomst og Huslejeregisteret. Når en person søger om boligstøtte eller indberetter en ændring, er der mulighed for 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 Digital Post. Hvis et husstandsmedlem ikke har logget på, så bliver der sendt en Besked afsted til ansøger. 6.2.1.2 LF Boligstøtte Håndter automatisk genererede oplysninger 1.2.1.2 Formålet med dette løsningsflow er oprettelse af nye abonnementer til de autoritative registre og modtagelse og registrering af data fra interne og eksterne registre. Hver gang en borger indsender en ansøgning om boligstøtte via Borger.dk, så bliver der automatisk opsat et abonnement til de autoritative registre såsom Beriget Bilag 3A Behovsopgørelse Side 34 af 80 3

Grunddata, SKAT, KMD Indkomst og Huslejeregisteret. Ligeledes bliver der oprettet abonnementer, når en kunderådgiver har indberettet en ansøgning modtaget via blanket. Når data er modtaget, bliver sagen opdateret i Systemet, og sagen fortsætter videre til Træf afgørelse. Denne proces viser også de ændringer, som løbende modtages i Systemet. Disse ændringer bliver afleveret til Systemet, der herefter foretager en ny beregning, der kan have betydning for berettigelsen til boligstøtte. 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.2.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. Træf afgørelse anvendes både i forbindelse med ansøgninger og ændringer. Kerneprocessen Træf afgørelse består af løsningsflowet: LF Boligstøtte Træf afgørelse 2.2.1.1. 6.2.2.1 LF Boligstøtte Træf afgørelse 2.2.1.1 Formålet med processen er at træffe afgørelse om, hvorvidt en person er berettiget til boligstøtte. 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. Processen anvendes også i forbindelse med beregning af eventuelle ændringer til en eksisterende sag, genberegning af oplysninger fra eindkomst. Når hele processen er gennemført i relation til disse ændringer, så afgøres sagen, og der sendes Besked til personen via brev og selvbetjening. Hvis der skal udbetales, fortsættes i Dan udbetalingsgrundlag. Det samme gør sig gældende, hvis beregningen viser, at borgeren har modtaget for meget i boligstøtte. Bilag 3A Behovsopgørelse Side 35 af 80 3

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. I denne proces er der også mulighed for, at borger kontakter boligstøttes kunderådgivere enten via telefon eller via fysisk/digital post. 6.2.3 Kerneproces Håndter drift 2.2.2 Processen håndterer overordnet set klargøring af udbetalingerne. Herudover håndteres modregning af gæld fra udbetaling Danmarks Debitorsystem og fra kommunerne i forbindelse med beboerindskudslån. Kerneprocessen består af løsningsflowet: LF Boligstøtte Dan udbetalingsgrundlag 2.2.2.1 LF Boligstøtte Udfør årlig efterregulering og årsomregning 2.2.2.2 6.2.3.1 LF Boligstøtte - Dan udbetalingsgrundlag 2.2.2.1 Formålet med processen er at bestemme og danne det endelige udbetalingsgrundlag. 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 den endelige udbetaling, bliver evt. modregningsaftaler gennemgået, og gældsposter fratrukket en udbetaling. Gæld opstået i selve Systemet som følge af genberegning af eindkomst bliver også fratrukket en udbetaling. I processen håndteres en eventuel dækningsrækkefølge for disse forskellige typer af gæld. 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 krav og udbetalingsposter. Boligorganisationerne skal midt i måneden have en liste over de udbetalinger, som de kan forvente sidst på måneden. Processen bundtler udbetalingerne og danner en liste til brug for deres videre behandling. Bilag 3A Behovsopgørelse Side 36 af 80 3

6.2.3.2 LF Boligstøtte Udfør årlig efterregulering og årsomregning 2.2.2.2 Formålet med processen er at gennemføre en årlig efterregulering og årsomregning. Efterreguleringen gennemføres i forlængelse af, at SKAT har de nye årsopgørelser klar. Årsopgørelserne hentes ind i processen, og boligstøtten bliver beregnet på ny på baggrund af indkomstoplysninger i årsopgørelserne. Der foretages herefter en sammenligning med de udbetalinger, der er foretaget for det pågældende indkomstår, og resultatet kan enten være en opkrævning (hvis borger har fået for meget), en efterbetaling (hvis borger har fået for lidt). I begge tilfælde skal borger orienteres om resultatet. Hvis efterreguleringen viser, at borger har fået det korrekte udbetalt, så skal borger også have et brev, der bekræfter dette. Årsomregningen gennemføres i slutningen af året, når de nye satser er modtaget fra ministeriet. Resultatet af denne årsomregning er, at borgerens boligstøtte for det kommende år er beregnet. Borgeren bliver orienteret i denne forbindelse. 6.2.4 Kerneproces Håndter udbetaling 3.2.1 Processen håndterer overordnet set udbetaling af boligstøtte. Kerneprocessen Håndter udbetaling består af løsningsflowet: LF Boligstøtte Effektuer udbetaling 3.2.1.1. 6.2.4.1 LF Boligstøtte Effektuer udbetaling 3.2.1.1. Formålet med processen er, at effektuere udbetalingerne af boligstøtte, samt danne relevante posteringer til regnskabet og afstemning. Processen starter, når det er tid til udbetaling, og der findes et udbetalingsgrundlag til enten borger, boligselskab eller kommune. 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ådgiver. 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 Nem- Konto. Henvendelserne behandles manuelt af kunderådgiverne. 6.2.5 Kerneproces Håndter opkrævning 3.2.2 Processen understøtter overordnet, hvordan betalingskrav videreformidles til Debitor. Kerneprocessen Håndter opkrævning består af løsningsflowet: Bilag 3A Behovsopgørelse Side 37 af 80 3

LF Boligstøtte Dan krav 3.2.2.1. 6.2.5.1 LF Boligstøtte Dan krav 3.2.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. 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 Disse flows beskriver overordnet, hvordan post modtages og afsendes i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Boligstøttesystemet 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 Disse flows beskriver overordnet, hvordan telefonopkald modtages og foretages i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Boligstøttesystemet skal kunne modtage og foretage telefonopkald via denne proces. 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 Bilag 3A Behovsopgørelse Side 38 af 80 3

Disse flows beskriver overordnet, hvordan dataleverancer modtages og afsendes i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Boligstøttesystemet skal kunne modtage og afsende dataleverancer 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 Disse flows 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. Boligstøttesystemet skal kunne modtage henvendelse via www og modtage 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 Disse flows beskriver overordnet, hvordan webservicekald besvares og foretages i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark. Boligstøttesystemet skal kunne foretage webservicekald via denne proces. Bilag 3A Behovsopgørelse Side 39 af 80 3

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 abstraktionsniveau 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 en underliggende 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 Fejl! Henvisningskilde ikke fundet.5. Udbetaling Danmark administrerer og udbetaler økonomiske ydelser til personer eller virksomheder. Ydelserne kan være af typen pension, barseldagpenge, 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 40 af 80 4

Figur 5 Overordner 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: Boligstøtte 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 41 af 80 4

der, begreber og attributter er beskrevet med definition, kildehenvisning og relevante kommentarer. Systemet er beskrevet i: Informationsmodel Boligstøtte 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 Udbetaling Danmark definition af Sag Udbetaling Danmark definerer en sag på samme måde som OIO Specifikation for SAG Version 1.2. 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 eller myndighed har én sag i et ydelsesområde, som dækker hele forløbet for vedkommende. I Boligstøtte oprettes der således én sag pr. afgørelse. Hver sag har en primær part, dvs. person som ansøger om boligstøtte på vegne af husstanden og er modtager ydelsen. Hver sag vil få et primært KLE-nummer. Bilag 3A Behovsopgørelse Side 42 af 80 4

Figur 6 Eksempel på Boligstøttesag Vi samler dokumenter, data og information om 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. I Boligstøtte samles dokumenter på boligstøttesagen, som vedrører den konkrete sag. 7.2.2.2 Sag - Nøgler og Egenskaber Udbetaling Danmarks generelle 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 UUID ja Sag ID Brugervendt identifikation, der er unik inden for myndigheden. 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 4: Nøgler for "Sag" Bilag 3A Behovsopgørelse Side 43 af 80 4

Sagen har også en række generelle attributter: Beskrivelse Værdisæt Obl. Betegnelse Henvisning til hjemmel fx lov og for sagens behandling. Angives, hvis der er truffet beslutning om undtagelse fra offentligheden. Værdisættet består af de to følgende elementer. 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. Tekst Nej Hjemmel OffentlighedUndtaget Nej OffentlighedUndtaget Anvendes ikke i UDK Tekst Nej AlternativTitel Anvendes ikke i UDK Tekst Nej Hjemmel Anvendes ikke i UDK Nej/Ja Nej Principiel Tekst Ja Kassationskode Er afleveret til Statens Arkiver/ 7 arkiv. Nej/Ja Nej Afleveret Sagens forretningsmæssige fremdrift i Opstået Ja Sagstilstand forhold til behandling. Oplyst Afgjort Afsluttet Tabel 5: Generelle egenskaber for "Sag" Sager i ydelsesområderne arver de generelle attributter og nøgler. De kan derudover have flere sagsattributter, som er specifikke for den enkelte sagstype eller for Udbetaling Danmark. Bilag 3A Behovsopgørelse Side 44 af 80 4

7.2.2.3 Sagens relationer Figur 7 Sag og relationer fra OIO Sag 1.2 En sag har Attributter og Sagstilstand, som beskrevet under attributter. En Udbetaling Danmark sag har følgende relationer: Relation til Klassifikation, her findes KLE-nummer Relation til Sagsaktør, hvor identifikation af aktør findes Relation til Sagspart, som for Udbetaling Danmark kan være af typen Person, Virksom eller Myndighed. Relation til andre sager, her kan bygges sagshieraki og relationer til andre sagstyper, som fx klagesager Relation til Journalpost, her er relation til dokumenter og journalnotater Det er vurderet, at Sagsgenstand ikke er nødvendig. Bilag 3A Behovsopgørelse Side 45 af 80 4

7.2.2.4 Sagens oprettelse og livsforløb En boligstøttesag oprettes ved modtagelse af en digital ansøgning ved modtagelse af en blanket ansøgning. Sagen afsluttes, når ydelsesmodtageren ikke længere er berettiget til boligstøtte eller ønsker at stoppe sin sag. Boligstøttesagen afsluttes på baggrund af regler, der er defineret i kassationskoden, som kan være forskellige alt efter sagstype. Sagen afsluttes, når ydelsesmodtageren ikke længere er berettiget eller ønsker at stoppe sin sag. Sagen ændrer tilstand i løbet af sin levetid: Beskrivelse Værdisæt Obl. Betegnelse Sagens forretningsmæssige fremdrift i forhold til behandling 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 Fremdrift Tabel 6: Tilstande for "Sag " Sagens tilstand kan skifte frem og tilbage mellem de forskellige værdisæt i løbet af levetiden. 7.2.3 Part I boligstøtte har en sag en primær part, den der er berettiget til ydelsen og husstandsmedlem som sekundær part. Et husstandsmedlem er ikke Part i sagen, men hæfter solidarisk. Der kan knyttes flere solidariske hæftere til en sag. Hvis der opstår et tilbagebetalingskrav for den periode, hvor den solidariske hæfter har opholdt sig på adressen, og den solidariske hæfter bliver gjort bekendt med dette tilbagebetalingskrav, så optræder den solidariske hæfter som Part i sagen for denne periode. En Part har ret til aktindsigt i sin egen sag. Bilag 3A Behovsopgørelse Side 46 af 80 4

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 BSYDI1 Udstil oplysninger i Ydelsesindeks og BSSDI1 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 Boligstøtte Informationsmodellen for boligstøtte indeholder boligstøttebegreber og deres relationer. Begreberne er grupperet i kasser, hvor de vigtigste er BoligstøtteSag, BoligstøtteGrundoplysninger - Person, BoligstøtteGrundoplysninger Bolig, BoligstøtteYdelse og BoligstøtteYdelsesType, BoligstøtteTilslutningsregister, BoligstøtteUdbetaling og BoligstøtteSystemadministration. Disse beskrives kort nedenfor. 7.2.6 BoligstøtteSag En boligstøttesag indeholder oplysninger om et sagsforløb for en sagspart, der kan være en person og som skal have boligstøtte. Den enkelte sag kan udelukkende indeholde en afgørelse. Andre personer end sagspart kan optræde på sagen som husstandsmedlemmer. Disse husstandsmedlemmer kan have forskellige relationer til sagsparten. En boligstøttesag arver alle de generelle attributter fra Sag. 7.2.7 BoligstøtteGrundoplysning Person & Bolig Grundoplysninger er oplysninger til brug for afgørelser og beregninger på boligstøttesag. Oplysningerne fås fra andre myndigheder, offentlige registre, indtastes af kunderådgiver eller via ansøgers selvbetjening. 7.2.8 BoligstøtteYdelse 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 BSYDI1 Udstil oplysninger i Ydelsesindeks). Bilag 3A Behovsopgørelse Side 47 af 80 4

7.2.9 BoligstøtteYdelsestype Systemets ydelsestyper er opdelt i to områder: Boligsikring Boligstøtte der ydes til personer, der ikke er pensionister, betegnes som boligsikring. Jf. boligstøtteloven består gruppen af følgende: Personer der ikke er folkepensionister eller førtidspensionister Personer der er tilkendt førtidspension 1. januar 2003 eller senere eller personer for hvem en sag om førtidspension er påbegyndt efter 1. januar 2003. Boligsikring ydes først og fremmest som et tilskud til lejere. Hvis man bor i en ejer- eller andelsbolig vil boligsikringen dog være et lån, der skal betales tilbage. Boligsikring i form af et lån kan dog kun ydes til ejere eller andelshavere, der er førtidspensionister eller ejere og andelshavere, der er bevægelseshæmmet eller døgnhjælpsmodtagere. Boligydelse Boligstøtte der ydes til personer der er pensionister betegnes som boligydelse. Såfremt der bor flere personer i en husstand, kan boligydelse tildeles, hvis blot ét af husstandsmedlemmerne er pensionist. Jf. boligstøtteloven består gruppen af pensionister af følgende: Folkepensionister Modtager af udenlandsk alderspension Personer der er tilkendt førtidspension inden 1. januar 2003 eller for hvem der er påbegyndt en sag om førtidspension inden den 1. januar 2003. Boligydelse ydes først og fremmest som et tilskud til lejere. Hvis man bor i en ejer- eller andelsbolig vil boligydelsen dog være et lån, der skal betales tilbage. Boligydelse i form af et lån kan dog kun ydes til ejere eller andelshavere, der modtager dansk folkepension, førtidspension eller pension efter EFforordninger. 7.2.10 BoligstøtteTilslutningsregister Tilslutningsregister indeholder boligorganisation- og administrationsoplysninger om almene boligorganisationer til brug for sagsbehandling og udbetaling af boligstøtte via boligorganisationer. Bilag 3A Behovsopgørelse Side 48 af 80 4

7.2.11 BoligstøtteUdbetaling Udbetalingspakken indeholder informationer for hver udbetaling og opkrævning samt modregningskrav. 7.2.12 Boligstøttesystemadministration Begreber som anvendes i forbindelse med planlægning af kunderådgivernes opgaver og til rapportering til den daglige driftsledelse. Bilag 3A Behovsopgørelse Side 49 af 80 4

8 IT arkitektur Dette punkt 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 Boligstøttesystemet, samt de eksterne services, som Systemet skal etablere og udstille. 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 Boligstøttesystemet, således at det fulde omfang af Snitflader klarlægges. I modsætning til forretningsarkitekturen beskriver IT-arkitekturen ikke den interne opbygning af Boligstøttesystemet. 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 50 af 80 5

Figur 8 IT-udbudsarkitekturen for den samlede Forretningsløsning for administration af Boligstøtte Udbetaling Danmark systemer Boligstøttesystemet 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 enkelte 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 af de øvrige ydelsesområder, og som kun indgår i administrationen af boligstøtteordningen. Systemerne er afbildet på IT-målarkitekturen i bilag 3 (Leverancebeskrivelse), og præsenteres kort her. Bilag 3A Behovsopgørelse Side 51 af 80 5

Systemet leverer informationer til en række andre parter: Til brug for statistik m.m. leveres data til hhv. Danmarks Statistik, Ministeriet for By, Bolig- og Landdistrikter samt Ministeriet for Børn, Ligestilling, Integration og Sociale Forhold. 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 punkt 8.2.1 Integrationer. På systemkontekst diagrammet er hver Integration tildelt et ID ud fra mønsteret IntegrationsID = <ydelsesområdeforkortelse BS ><3-bogstavs systemforkortelse><fortløbende nr.>. Fra aktivitetsbeskrivelser og fra krav er der refereret til integrationsid et. Systemkonteksten er illustreret i Figur 9. Bilag 3A Behovsopgørelse Side 52 af 80 5

Figur 9 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 Alle integrationerne er listet i nedenstående tabel 7. Integrationspart IntegrationsID Integrationsnavn ATP-systemer ATP ERP BSERP1 Posteringer til ERP ATP Afstemning BSAAF1 Afstemningsdata til ATP ATP Datawarehouse BSDWH1 Data til datawarehouse ATP idm & idp BSIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM BSIDP1 Login via ATP s IdP Interne tværgående støttesystemer & Eksterne services Posthåndterings-leverandør BSPHL1 Modtag indgående post (PHL) BSPHL2 Send post til genjournalisering Fjernprint BSFPR1 Send besked Bilag 3A Behovsopgørelse Side 53 af 80 5

Integrationspart IntegrationsID Integrationsnavn Beriget Grunddata BSBGD1 Hent data fra Beriget Grunddata Eksterne kanaler Borger.dk BSBOR1 Visuel Integration i Borger.dk Fælleskommunale systemer Sags- og dokumentindeks BSSDI1 Udstil oplysninger i Sags- og dokumentindeks BSSDI2 Hent oplysninger fra Sags- og dokumentindeks Ydelsesindeks BSYDI1 Udstil oplysninger i Ydelsesindeks BSYDI2 Hent oplysninger fra Ydelsesindeks Modregningsfordeler BSMRF1 Send data til modregningsfordeler BSMRF2 Modtag data fra modregningsfordeler Fælles systemer & registre NemKonto BSNKS1 Send udbetalingsanmodninger NemLogin BSNLO1 Login til selvbetjening via NemLogin SKAT eindkomst BSKE1 Hent indkomstoplysninger SKAT Forskud BSSFO1 Hent Forskudsopgørelse SKAT Årsopgørelse BSSAO1 Hent Årsopgørelse Danmarks Statistik BSDST1 Levering af oplysninger til Danmarks Statistik Ydelsesområde-specifikke systemer og registre Ministeriet for Børn, Ligestilling, BSMBS1 Levering af oplysninger til Ministeriet Integration og Sociale forhold Fagsystemer Pensionsfagsystem BSPFS1 Send oplysninger til Pension BSPFS2 Hent oplysninger fra Pension Debitorfagsystem BSOFS1 Send krav BSOFS2 BSOFS3 BSOFS4 Modtag kravstatus Modtag modregning Send modregningsstatus Tabel 7 Systemets integrationer En detaljeret beskrivelse af hver Integration kan findes 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 Snit- Bilag 3A Behovsopgørelse Side 54 af 80 5

flader jf. tabel 7. 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 55 af 80 5

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 underpunkter. 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.. Dertil kommer daglige udbetalingskørsler. Kørslerne er afhængige af, at der forinden er blevet dannet et endeligt udbetalingsgrundlag, hvor modregningsaftaler fra Debitor og kommunerne 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 56 af 80 5

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 en lang række satser inden for boligstøtte udføres årligt og bevirker, at et stort antal aktive sager skal genberegnes. 9.1.2.3 Årlig efterregulering To gange om året gennemføres en efterregulering af boligstøtte. Det sker i maj og oktober, når SKAT frigiver årsopgørelsen for henholdsvis lønmodtagere og selvstændige. Efterreguleringen medfører at Systemet skal genberegne de sager, hvor husstandsindkomsten har været forskellig fra den oplyste. Hvis forskellen er tilstrækkelig stor, så skal der enten foretages en opkrævning eller efterbetaling. 9.1.2.4 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.5 Dataudtræk og øvrig rapportering Systemet skal kunne håndtere levering af 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. 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. Bilag 3A Behovsopgørelse Side 57 af 80 5

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 punkt 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 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 10). Der er primært fokus på opsætningen af diverse abonnementer (Beriget Grunddata, SKAT Snitflader mv.). Selve datakonverteringen vil foregå ved en samlet idriftsættelse, således at alle relevante data udtrækkes fra KMD, og forventes indfaset i en enkelt fase i Systemet. Alle data fra Eksisterende Løsning, som indeholder information om boligstøtteområdet, vil blive trukket ud og placeret på en FTP server. Den fysiske datamodel m.v. fremgår af bilag 2B (Eksisterende data). Dertil vil Ny Leverandør have adgang til detaljeret dokumentation af data, samt design dokumentation af dataudtræk. ATP er ansvarlig for, at der foreligger et eller flere 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 beho- Bilag 3A Behovsopgørelse Side 58 af 80 5

vet for manuelle/maskinelle korrektioner, inden data endeligt konverteres til Systemet. 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 10. Figur 10 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 boligstøttesag. Dataudtrækket fra Eksisterende Løsning gennemføres af KMD og er aftalt i aftalen om udfasningsassistance. Aftalen om 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 til 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. Bilag 3A Behovsopgørelse Side 59 af 80 5