Bilag 3A Behovsopgørelse

Transkript

1 Bilag 3A Behovsopgørelse Version

2 Indhold 1 VEJLEDNING TIL TILBUDSGIVER INDLEDNING UNDERBILAG FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER DEN SAMLEDE FORRETNINGSMÆSSIGE LØSNING BRUGERNE AF SYSTEMET BORGERNE KUNDERÅDGIVERNE FORRETNINGSADMINISTRATORER ROLLER OG RETTIGHEDER RISIKOVURDERING PERSONDATALOVEN FUNKTIONSADSKILLELSE DOKUMENTATION PRIVILEGEREDE ROLLER FORRETNINGSROLLER FORRETNINGSUDBUDSARKITEKTUREN FORRETNINGSUDBUDSARKITEKTUREN AUTOMATISERET OG MANUEL SAGSBEHANDLING KANALER OG KOMMUNIKATION ØVRIGE ELEMENTER I FORRETNINGSUDBUDSARKITEKTUREN KOMPONENTMODEL Bilag 3A Behovsopgørelse Side 1 af 78

3 5.1 MANUELT OPGAVEINDBAKKE MANUELLE BREVE SAGSHÅNDTERING TVÆRGÅENDE OVERBLIK SYSTEMADMINISTRATION REGELADMINISTRATION AUTOMATISK HÆNDELSER VALIDERING KONTROL BEREGNING AF YDELSER DAN UDBETALING DAN OPKRÆVNING BESKEDHÅNDTERING MODREGNING STØTTEKOMPONENTER PERSONDATA SAGER OG DOKUMENTER KANALER SELVBETJENING MODTAGELSE AF POST ØVRIGE KOMPONENTER SIKKERHED INDEKSSYNKRONISERING RAPPORTER AFSTEMNING JOBAFVIKLING ØKONOMI ARKIVERING FORRETNINGSPROCESSER Bilag 3A Behovsopgørelse Side 2 af 78

4 6.1 SAMLET PROCESKATALOG KERNEPROCESSER KERNEPROCES HÅNDTER INDBERETNING LF Familieydelser Håndter indberetning LF Familieydelser Håndter automatisk genererede oplysninger KERNEPROCES - TRÆF AFGØRELSE LF Familieydelser Træf afgørelse KERNEPROCES HÅNDTER DRIFT LF Familieydelser - Dan udbetalingsgrundlag LF Familieydelser Udsend påmindelse om enlig-erklæring KERNEPROCES HÅNDTER UDBETALING LF Familieydelser Effektuer udbetaling KERNEPROCES HÅNDTER OPKRÆVNING LF Familieydelser Dan krav TVÆRGÅENDE PROCES HÅNDTER POST TVÆRGÅENDE PROCES HÅNDTER TELEFONISK KONTAKT TVÆRGÅENDE PROCES HÅNDTER DATALEVERANCE TVÆRGÅENDE PROCES HÅNDTER WEBADGANG TVÆRGÅENDE PROCES HÅNDTER WEBSERVICE INFORMATIONSARKITEKTUR OVERORDNET BEGREBSMODEL FOR UDBETALING DANMARK BEGREBS- OG INFORMATIONSMODELLER FOR FORRETNINGSLØSNINGEN DOKUMENTATION TIL LEVERANDØR INFORMATIONSMODEL SAG Sag UDBETALING DANMARK DEFINITION AF SAG Sag - Nøgler og Egenskaber Sagens relationer Sagens oprettelse og livsforløb PART Bilag 3A Behovsopgørelse Side 3 af 78

5 7.3.3 SAGSDOKUMENTATION INFORMATIONSMODEL FAMILIEYDELSER FAMILIEYDELSESSAG FAMILIEYDELSERGRUNDOPLYSNING FAMILIEYDELSESTYPE FAMILIEYDELSESYDELSE UDBETALING FAMILIEYDELSESYSTEMADMINISTRATION IT ARKITEKTUR IT-UDBUDSARKITEKTUREN SYSTEMKONTEKST OG INTEGRATIONER INTEGRATIONER NON-FUNKTIONELLE KRAV TIL SYSTEMET ARKITEKTUR RAMMER FOR ARKITEKTUREN BELASTNING OG SKALERING Udbetalingskørsler Satsregulering Udsendelse af årlig påmindelse om enlig erklæring Årlig efterregulering Journaliser post på sagen Dataudtræk og øvrig rapportering DESIGN OG APPLIKATIONSSTRUKTUR LOGNING SYSTEMFLEKSIBILITET TILGÆNGELIGHED DATAKONVERTERING KONVERTERINGSKONCEPTET GENERELT Bilag 3A Behovsopgørelse Side 4 af 78

6 9.6.2 UDTRÆK AF DATA TRANSFORMERING AF DATA INDLÆSNING OG VIDEREFORDELING AF DATA Indlæsning af data i Systemet Viderefordeling af data og synkronisering med støttesystemer AFSTEMNING OG DATAVALIDERING GENNEMFØRSEL AF KONVERTERINGEN HÅNDTERING AF PRØVEUDTRÆK BRUGERVENLIGHED LOVGIVNING SIKKERHED MILJØER PROJEKTLEDELSE UDDANNELSE DOKUMENTATION IDRIFTSÆTTELSE HYPERCARE SAMARBEJDE OG RAPPORTERING TEST KRAV TIL DRIFT, VEDLIGEHOLDELSE, SUPPORT OG VIDEREUDVIKLING (YDELSERNE) OVERORDNEDE KRAV ETABLERINGSYDELSEN ETABLERING AF LOKALITETER ETABLERING AF KOMMUNIKATIONSINFRASTRUKTUR ETABLERING AF PROGRAMMEL ETABLERING AF PROCESSER OG VÆRKTØJER FOR DRIFTSAFVIKLING OG SUPPORT ETABLERING AF PROCESSER FOR TVÆRGÅENDE LEVERANDØR SAMARBEJDE ETABLERING AF PROCESSER OG VÆRKTØJER TIL VEDLIGEHOLDELSE AF SYSTEMET VEDLIGEHOLDELSE OG VIDEREUDVIKLING AF SYSTEMET VEDLIGEHOLDELSE AF SYSTEMET Bilag 3A Behovsopgørelse Side 5 af 78

7 VIDEREUDVIKLING AF SYSTEMET LØBENDE DRIFT LOKALITETER INFRASTRUKTUR OG MASKINEL PROGRAMMEL TEKNOLOGISK RÅDGIVNING, RAPPORTERING OG SUPPORT DOKUMENTATION OG KONFIGURATIONSSTYRING SIKKERHED OG BEREDSKAB OVERVÅGNING OPHØRSBISTAND SERVICE OPERATION Supportløsningen INCIDENT MANAGEMENT PROBLEM MANAGEMENT CHANGE MANAGEMENT RELEASE MANAGEMENT EVENT MANAGEMENT - OVERVÅGNING CONFIGURATION MANAGEMENT CAPACITY MANAGEMENT INTEGRATION TIL FRITAGELSE AF DIGITAL POST INTEGRATION TIL SKAT INTEGRATION TIL SAPA FORUDSÆTNINGSSYSTEMER FOR INTEGRATIONEN TIL SAPA INTEGRATION TIL GRUNDDATAFORDELER Bilag 3A Behovsopgørelse Side 6 af 78

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

9 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

10 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

11 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

12 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

13 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

14 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

15 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 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 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

16 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

17 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

18 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

19 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

20 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

21 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 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 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

22 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 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) 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 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

23 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 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 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

24 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 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) Dan Udbetaling Komponenten skal samle og overføre udbetalinger til NemKonto. Den registrerer udbetalingsdata og danner udbetalingsfiler 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 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

25 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 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 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 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

26 Modtagelse af post 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 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 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 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

27 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 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 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 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 Ø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

28 Samlet set sikrer denne dataudveksling, at regler til understøttelse af regnskabslovgivning samt gældende revisionskrav kan overholdes 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

29 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

30 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 LF Familieydelser Håndter indberetning LF Familieydelser Håndter automatisk genererede oplysninger Administration Træf afgørelse LF Familieydelser Træf afgørelse Håndter drift LF Familieydelser Dan udbetalingsgrundlag LF Familieydelser Udsend påmindelse om enlig-erklæring Udbetaling Håndter udbetaling LF Familieydelser Effektuer udbetaling Håndter opkrævning LF Familieydelser Dan krav 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 Kerneproces Håndter indberetning 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 LF Familieydelser Håndter automatisk genererede oplysninger Bilag 3A Behovsopgørelse Side 29 af 78

31 LF Familieydelser Håndter indberetning 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 LF Familieydelser Håndter automatisk genererede oplysninger 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

32 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 Kerneproces - Træf afgørelse 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 LF Familieydelser Træf afgørelse 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 Kerneproces Håndter drift 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 LF Familieydelser Udsend påmindelse om enlig-erklæring LF Familieydelser - Dan udbetalingsgrundlag Formålet med processen er at bestemme og danne det endelige udbetalingsgrundlag. Bilag 3A Behovsopgørelse Side 31 af 78

33 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 LF Familieydelser Udsend påmindelse om enlig-erklæring 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) Kerneproces Håndter udbetaling Processen håndterer overordnet set udbetaling af familieydelser. Kerneprocessen Håndter udbetaling består af løsningsflowet: LF Familieydelser Effektuer udbetaling LF Familieydelser Effektuer udbetaling 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

34 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 Kerneproces Håndter opkrævning Processen understøtter overordnet, hvordan betalingskrav videreformidles til Debitor. Kerneprocessen Håndter opkrævning består af løsningsflowet: LF Familieydelser Dan krav LF Familieydelser Dan krav 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 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 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

35 Flowsene beskriver overordnet hvordan telefonopkald modtages og foretages i Udbetaling Danmark. Processen er den samme for alle ydelsesområderne i Udbetaling Danmark 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 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 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

36 7 Informationsarkitektur Informationsarkitekturen fastlægger de forretningsmæssige begreber, som forretningen anvender og som Systemet skal indeholde i form af data. Begreber og sammenhænge vises i UML Diagrammer, og begreberne defineres og kommenteres i tekst i de medfølgende bilag med kildehenvisning til begrebernes definition. Udbetaling Danmark har modelleret de forretningsmæssige begreber i et hierarki af begrebs- og informationsmodeller. Den Overordnede Begrebsmodel har det højeste abstraktions niveau og viser begreber fra hele Udbetaling Danmarks forretning. Niveauet under den overordnede begrebsmodel er begrebsmodeller for hver af de sagstyper, vi håndterer, en generisk begrebsmodel for det generelle Sagsbegreb samt en begrebsmodel for de grunddata vi registrerer for parter/aktører/ interessenter i sager. Hver begrebsmodel har under sig en informationsmodel som detaljerer og beriger begrebsmodellen. Informationsmodellerne giver information til og er grundlaget for Leverandørens logiske og fysiske datamodeller. 7.1 Overordnet begrebsmodel for Udbetaling Danmark Udbetaling Danmark behandler forskellige typer af sager, som kan aflæses i den overordnede begrebsmodel, se Figur 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 35 af 78

37 Figur 5: Overordnet begrebsmodel for Udbetaling Danmark 7.2 Begrebs- og informationsmodeller for Forretningsløsningen Begrebs- og Informationsmodeller er forretningens modeller over de væsentligste begreber, som Systemet skal kunne oprette, læse, ændre og slette. Modellerne er på et konceptuelt niveau. Begrebsmodellerne giver det overordnede overblik og informationsmodellerne giver detaljering og berigelse af begrebsmodellerne. Informationsmodellerne indeholder de begreber og attributter, som aktivitetsbeskrivelser, beslutningsmodeller og eksterne systemer har behov for i forbindelse med beskrivelsen af et sammenhængende system. Modellerne er metodemæssigt afstemt med KOMBIT. Der indgår følgende begrebs- og informationsmodeller i Systemet: Familieydelser Sag Beriget Grunddata Begrebsmodellerne indgår ikke i udbudsmaterialet, da informationsmodellerne giver den tilstrækkelige information til Leverandøren 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 Bilag 3A Behovsopgørelse Side 36 af 78

38 enheder, begreber og attributter er beskrevet med definition, kildehenvisning og relevante kommentarer. Systemet er beskrevet i: Informationsmodel Familieydelser Informationsmodel Sag Informationsmodel Beriget Grunddata Derudover er informationsmodellen for Beriget Grunddata vedlagt, idet den viser hvilke informationer, der er til rådighed i Systemet for Person og Myndighed. Den metodemæssige tilgang til begrebs- og informationsmodellering i ATP er beskrevet i bilag 2A (Sådan forretningsmodellerer vi i ATP) 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 Sag 7.3 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 Vi overholder enkeltsagsprincippet ved at oprette en sag for hver afgørelse af berettigelse til en ydelse. En person får mange sager i et fagsystem, en sag for hver ydelsesafgørelse, hver sag vil få et primært KLE-nummer. Der kan være flere parter relateret til en afgørelsessag. Bilag 3A Behovsopgørelse Side 37 af 78

39 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 Tekst Ja BrugervendtNøgle myndigheden. Frit sagsnummer Tekst Ja Sagsnummer Officiel sagstitel, der kan anvendes i forbindelse med Tekst Ja Titel åbne dagsordenspunkter. Dette er også dokumentets objektnavn, jf. Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet. Sagsbeskrivelse i fri tekst. Evt. supplerende beskrivelse af indhold og formål. Tekst Ja Beskrivelse Tabel 4: Nøgler for "Sag" Sagen har også en række generelle attributter: Beskrivelse Værdisæt Obl. Betegnelse Henvisning til hjemmel fx lov og for Tekst Nej Hjemmel sagens behandling. Angives, hvis der er truffet beslutning om undtagelse fra offentligheden. Værdisættet OffentlighedUndtaget Nej OffentlighedUndtaget Anvendes ikke i UDK består af de to følgende elementer. Alternativ sagstitel der kan anvendes i forbindelse med lukkede Tekst Nej AlternativTitel Anvendes ikke i UDK dagsordenspunkter, som skal vises på åbne dagsordener samt i forbindelse med postlister. Tekstuel henvisning til lovhjemmel, der anvendes som grundlag for beslutning om Tekst Nej Hjemmel Anvendes ikke i UDK undtagelse fra offentligheden. Indikator for om sagen er udnævnt som Nej/Ja Nej Principiel principsag. Kassationskode, der styrer varighed før Tekst Ja Kassationskode kassation. Er afleveret til Statens Arkiver/ 7 arkiv. Nej/Ja Nej Afleveret Sagens forretningsmæssige fremdrift i Opstået Ja Sagstilstand Bilag 3A Behovsopgørelse Side 38 af 78

40 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 Sagens relationer Ovenfor er vist 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 Bilag 3A Behovsopgørelse Side 39 af 78

41 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 Sagens oprettelse og livsforløb En familieydelsessag består af en sag der er tilknyttet minimum to parter et barn og en forælder. Barnet er sekundær part mens forælderen som den berettigede til ydelsen er primær part. Desuden kan der være 3. part tilknyttet hvis en anden person forsørger barnet eller en kommune indtræder i retten til bidrag. En person kan have flere sager, hvis personen er berettiget til flere ydelser for samme barn eller har flere børn. Sagerne knyttes til hinanden via den berettigede person og via barnet. Figur 6: Eksempel på Sagsrelationer Det der binder sagerne sammen er referencer mellem parterne. Det betyder, at ved en søgning på et givent CPR nr., vil der dukke et antal sager frem i søgeresultatet. På det tidspunkt hvor en kunderådgivergiver vælger en af disse sager i Systemet, vil kunderådgivergiveren kunne danne sig et overblik over de tilhørende sager til den valgte part. I tilfældet i Figur 6 vil kunderådgivergiveren kunne se, at den valgte familieydelsessag, de har søgt på, er relateret til to andre familieydelsessager. Derfor er referencernes synlighed mellem sagerne i kunderådgivergiverens brugergrænseflade både i Systemet. På den måde kan et overblik over et sagskompleks skabes hurtigt f.eks. i forbindelse med en telefonsamtale mellem Udbetaling Danmark og en borger. Bilag 3A Behovsopgørelse Side 40 af 78

42 En familieydelsessag oprettes primært o o o Ved besked fra Beriget Grunddata om nyt barn i CPR, dette gælder både fødsler og indrejser Ved anmodning om Børne- Ungeydelse fra EØS borgere. Ved ansøgning om ægtefællebidrag (kan være uden barn på samlesag) Under behandlingen af en sag kan det vise sig, at sagsparten er berettiget til andre ydelser, ud over den ydelse, som sagen oprindeligt havde været oprettet for. I disse tilfælde opretter Systemet automatisk en ny sag pr. den bevilligede ydelse. Fx hvis under behandlingen af Børne- eller Ungeydelsessag er vurderet, at ydelsesmodtager desuden er berettiget til flerbørnstilskud, børnetilskud til kun en/ingen forældre, børnetilskud til pensionister mm (dvs. de tilskud, hvor der er ingen ansøgningspligt), opretter Systemet en ny sag pr. den bevilligede ydelse. Sagen sluttes når ydelsesmodtager ikke længere er berettiget. Sagen ændrer tilstand i løbet af sin levetid: Beskrivelse Værdisæt Obl. Betegnelse Sagens forretningsmæssige fremdrift i forhold til behandling Fremdrift Noget kræver myndighedens ageren. Sagen er i proces med en oplysning Der er truffet afgørelse på sagen, fx bevilling eller afslag Sagsbehandling er fuldført Opstået Under Oplysning Afgjort Afsluttet Tabel 6: Tilstande for "Sag " Sagens tilstand kan skifte frem og tilbage mellem de forskellige værdisæt i løbet af levetiden Part I familieydelser har en sag en primær part, den der er berettiget til ydelsen, og barnet som sekundær part. Der kan knyttes flere parter til en sag, fx i bidragssager Bilag 3A Behovsopgørelse Side 41 af 78

43 vil begge forældre være parter i en sag. Som det vises i figur 6 er Mor primær part i sin egen sag som modtager af normalbidrag, mens far er sekundær part. En part er en person i en familieydelsessag. En part har ret til aktindsigt i sin egen sag Sagsdokumentation Systemerne for de enkelte ydelsesområder har ansvaret for sagen gennem hele sagens levetid fra oprettelsen, over ændringer på sagen, til sagen sluttes. Det er det enkelte Systems ansvar at sørge for at vedligeholde Rammearkitekturens Sags- og dokumentindeks og Ydelsesindeks (se snitfladerne PYDI1 Udstil oplysninger i Ydelsesindeks og PSDI1 Udstil oplysninger i Sags- og dokumentindeks) samt rettidig synkronisering, således at indeksene til en hver tid afspejler fagsystemet. Det er ligeledes Systemets ansvar at vedligeholde data alt hvad der vedrører sagen, journalnotater, beskeder, digitale henvendelser, scannende dokumenter samt journalisering af henvendelser Informationsmodel Familieydelser Informationsmodellen for familieydelser indeholder familieydelsesbegreber og deres relationer. Begreberne er grupperet i logiske enheder, hvor de vigtigste er Familieydelsessag, FamilieydelseGrundoplysninger, Familieydelsestype, FamilieydelseYdelse, Udbetaling og FamilieydelseSystemadministration. Disse beskrives kort nedenfor Familieydelsessag En familieydelsessag indeholder oplysninger om et sagsforløb for en sagspart, der kan være en person eller en myndighed, som skal have en økonomisk ydelse/bidrag. Andre personer end mor og far kan indtræde i retten til ydelser. Det kan fx være en mormor der har barnet boende. Bevillingen vil dog forsat være afhængig af den forælder med forældremyndighed og bevillingen, og dermed skal denne forælder fortsat opfylde berettigelse. En familieydelsessag arver alle de generelle attributter fra Sag. En myndighed kan indtræde i retten til bidrag ved anbringelse af barnet. Bilag 3A Behovsopgørelse Side 42 af 78

44 7.3.6 FamilieydelserGrundoplysning Grundoplysninger er oplysninger til brug for afgørelser og beregninger på familieydelsessagen. Oplysningerne fås fra andre myndigheder, offentlige registre, indtastes af kunderådgivergiver eller via ansøgers selvbetjening FamilieydelsesType Systemets ydelsestyper er opdelt i tre områder: BørneUngeYdelse Børne- og ungeydelse udbetales automatisk, hvis personen opfylder en række betingelser. Børneydelse er til børn i alderen 0-14 år og udbetales en gang i kvartalet. Ungeydelse er til børn i alderen år og udbetales en gang i måneden. Der findes en række satser for ydelsen alt efter hvor gammel barnet er. Børnetilskud Børnetilskud består af børnetilskud til enlige forsørgere samt en række mindre børnetilskud. Der er forskellige betingelser for at opfylde kravene til de forskellige børnetilskud, men også nogle generelle betingelser. OrdinærtBørnetilskud Enlige forsørgere kan søge om et ordinært børnetilskud. Det er en betingelse, at borgeren er reelt enlig. Det ordinære børnetilskud udbetales pr. barn. EkstraBørnetilskud Det ekstra børnetilskud udbetales en gang i kvartalet pr. familie. Personen søger om ordinært og ekstra børnetilskud på samme ansøgning. BørnetilskudTilForældreUnderUddannelse Særligt børnetilskud til forældre under uddannelse kan udbetales, når en forælder er i lære eller i gang med en uddannelse, hvor man kan få SU eller blive optaget i en a-kasse. Tilskuddet er indkomstbestemt. SupplerendeBørnetilskud Supplerende børnetilskud kan udbetales til forældre under uddannelse, der er i en praktik- eller skoleperiode med løn eller skolepraktikydelse. Tilskuddet er indkomstbestemt. Adoptionstilskud Bilag 3A Behovsopgørelse Side 43 af 78

45 En person kan søge om adoptionstilskud, hvis han eller hun har adopteret et udenlandsk barn gennem en godkendt adoptionsorganisation. Adoptionstilskuddet er et engangsbeløb. OrdinærtBørnetilskudtilpensionist Folkepensionister kan have ret til børnetilskuddet. Førtidspensionister på de gamle regler kan også få tilskuddet. Børnetilskuddet udbetales automatisk. Der modtages besked fra Pensionssystemet om nye pensionister med børn. SærligtBørnetilskudtilpensionist Hvis kun en af forældrene er pensionist, vil pensionisten modtage særligt børnetilskud til pensionister, men ikke det ordinære børnetilskud til pensionister. Hvis begge forældre er pensionister, vil de både modtage det ordinære og det særlige børnetilskud samt et ekstra tillæg i hvert kvartal. Børnetilskuddet er indkomstbestemt og udbetales automatisk. Børnetilskudtilbidragsbetalendepensionist Folkepensionister eller førtidspensionister efter gamle regler, der betaler bidrag kan søge et tilskud til dækning af normalbidragets grundbeløb. Det særlige børnetilskud til bidragsbetalende pensionister kan enten udbetales ved at tilskuddet bliver modregnet i Personens bidragsopkrævning eller hele tilskuddet udbetales til Personens Nemkonto. SærligtBørnetilskud Der kan gives et særligt børnetilskud, når der kun er én eller ingen forældre. Tilskuddet gives: - Når den ene forælder er død - Når begge forældre er døde (her gives der to tilskud) - Når der ikke er fastslået faderskab - Mens der er en igangværende faderskabssag i Statsforvaltningen - Når barnet er kommet til ved kunstig befrugtning - Når barnet er adopteret af en enlig adoptant Nogle af tilskuddene skal der søges om, mens andre skal startes automatisk. Bilag 3A Behovsopgørelse Side 44 af 78

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

47 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 Familieydelsessystemet 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 Familieydelsessystemet, således at det fulde omfang af snitflader klarlægges. I modsætning til forretningsarkitekturen beskriver IT-arkitekturen ikke den interne opbygning af Familieydelsessystemet. Den interne IT-arkitektur for Systemet skal beskrives af Tilbudsgiver i bilag 3B (Løsningsbeskrivelse). IT-udbudsarkitekturen vil være en del af en transitionsplan mod målarkitekturen beskrevet i bilag 3 (Leverancebeskrivelse). Det udmønter sig dels ved, at ikke alle de indgående systemer vil blive benyttet i deres endelige form. IT-udbudsarkitekturen fremgår af Figur 7 og forskellene i forhold til ITmålarkitekturen beskrives kort i det følgende. Bilag 3A Behovsopgørelse Side 46 af 78

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

49 familieydelsesordningen. Systemerne er afbildet på IT-målarkitekturen i bilag 3 (Leverancebeskrivelse), og præsenteres kort her. Systemet leverer informationer til en lang række andre parter: Til brug for statistik m.m. leveres data til hhv. Danmarks Statistik, SU Styrelsen og Ministeriet for Børn, Ligestilling, Integration og Sociale forhold (BLIS). Derudover leveres forskellige oplysninger til SKAT, hvor der leveres oplysninger til Skattefrie Beløb, Grøn Check, EFI og Enlige Forsørgere. Derudover bliver der hentet information fra SKATs systemer (Forskud og Årsopgørelse) samt information fra Feriepenge.dk. 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 Integrationer. På systemkontekst diagrammet er hver integration tildelt et ID ud fra mønsteret IntegrationsID = <ydelsesområdeforkortelse F ><3-bogstavs systemforkortelse><fortløbende nr.>. Fra aktivitetsbeskrivelser og fra krav er der refereret til integrationsid et. Systemkonteksten er illustreret på Figur 8. Bilag 3A Behovsopgørelse Side 48 af 78

50 Figur 8: Systemkonteksten for Systemet. Diagrammet viser alle de systemer, som Systemet skal integrere til. Figuren viser ikke infrastruktur-komponenter men udelukkende applikationer på logisk niveau Integrationer Alle integrationerne er listet i nedenstående tabel 7. Integrationspart IntegrationsID Integrationsnavn ATP-systemer ATP ERP FERP1 Posteringer til ERP ATP Afstemning FAAF1 Afstemningsdata til ATP ATP Datawarehouse FDWH1 Data til datawarehouse ATP idm & idp FIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM Bilag 3A Behovsopgørelse Side 49 af 78

51 Integrationspart IntegrationsID Integrationsnavn FIDP1 Login via ATP s IdP Interne tværgående støttesystemer & Eksterne services Posthåndterings-leverandør (PHL) FPHL1 Modtag indgående post FPHL2 Send post til genjournalisering Fjernprint FFPR1 Send besked Sikker Post FSIP1 Send sikker post. Beriget Grunddata FBGD1 Hent data fra Beriget Grunddata Eksterne kanaler Borger.dk FBOR1 Visuel integration i Borger.dk Fælleskommunale systemer Sags- og dokumentindeks FSDI1 Udstil oplysninger i Sags- og dokumentindeks FSDI2 Hent oplysninger fra Sags- og dokumentindeks Ydelsesindeks FYDI1 Udstil oplysninger i Ydelsesindeks FYDI2 Hent oplysninger fra Ydelsesindeks Fælles systemer & registre NemKonto FNKS1 Send udbetalingsanmodninger NemLogin FNLO1 Login til selvbetjening via NemLogin Digital Fuldmagt FDIF1 Hent digital fuldmagt SKAT eindkomst FSKE1 Hent indkomstoplysninger SKAT Forskud FSKF1 Hent topskattegrundlag FSKF2 Hent skattepligtskode SKAT Årsopgørelse FSKS1 Hent topskattegrundlag Danmarks Statistik FDST1 Levering af oplysninger til Danmarks Statistik Ydelsesområde-specifikke systemer og registre SKAT (CSC) FSKA1 Indberet skattefrie beløb SKAT Datawarehouse FSBI1 Levering af datawarehouseoplysninger Bilag 3A Behovsopgørelse Side 50 af 78

52 Integrationspart IntegrationsID Integrationsnavn SKAT Enlige forsørgere FSEF1 Indberet ekstra børnetilskud SKAT Grøn Check FSGR1 Indberet antal børn FSGR2 Indberet udbetalt børne- og ungeydelse på antallet af børn SKAT EFI FEFI1 Indberet til SKAT EFI Ministeriet for Børn, Ligestilling, Integration og Sociale forhold FBLI1 Levering af oplysninger til BLIS (BLIS) SU Styrelsen FSUS1 Levering af oplysninger til SU Styrelsen Feriepenge.dk FFEP1 Modtagelse af oplysninger fra feriepenge.dk Fagsystemer Pensionsfagsystem FPFS1 Hent oplysninger fra pension Debitorfagsystem FOFS1 Send krav FOFS2 Modtag kravstatus FOFS3 Modtag modregning FOFS4 Send modregningsstatus Tabel 7 Systemets integrationer En detaljeret beskrivelse af hver integration er at finde i bilag 3A.6 (Integrationer). Da systemintegrationerne kan ændre sig over tid, er det vigtigt, at der er løs kobling og klare grænseflader til systemerne. Ved løs kobling forstås, at en given komponent ikke er afhængig af den konkrete implementering af en anden komponent, men kun af systemgrænsefladen (data), som udstilles via ovenstående snitflader jf. tabel 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 51 af 78

53 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 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 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ådgivergivere 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 Udbetalingskørsler De største udbetalingskørsler er månedlige og kvartalsvise. Dertil kommer daglige udbetalingskørsler af bidrag. Kørslerne er afhængige af, at der forinden er blevet dannet et endeligt udbetalingsgrundlag, hvor indbetalinger og modregningsaftaler fra Debitor tages med i beregningen af hvor meget der skal udbetales. Kørslen er omdrejningspunktet for hele Systemet, og det er derfor væsentligt, at Systemet er gearet til at håndtere alle udbetalinger, såvel som de bagvedliggende processer, der direkte eller indirekte indgår i udbetalingsprocessen. Bilag 3A Behovsopgørelse Side 52 af 78

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

55 9.3 Logning I forhold til omfanget og karakteren af logning i Systemet, har ATP en række krav. Kravene definerer hvilke informationer Systemet skal logge, og skal føre til, at der etableres sporbarhed og at den gældende lovgivning efterleves, eksempelvis ved kontrol af adgang til personfølsomme data. Logningskravene skal desuden sikre, at Leverandøren kan dokumentere hvordan servicemål efterleves, ligesom de skal afhjælpe fejlsøgning og generel overvågning af Systemet. 9.4 Systemfleksibilitet ATP ønsker et System som er fleksibelt og modulært opbygget, så fremtidige tilpasning kan gennemføres ved konfiguration af processer, nye ydelsestyper, regler, kontroller og øvrige systemparametre ATP anser systemfleksibilitet som en væsentlig kilde, til at minimere vedligeholdelse omkostningerne for Systemet. 9.5 Tilgængelighed ATP ønsker et driftsstabilt System med høj grad af tilgængelighed og lave svartider. Kravene i bilag 3A.1 (Kravliste) fastsætter, sammen med servicemålene i bilag 7 (Servicemål), kravene til Systemets tilgængelighed. 9.6 Datakonvertering Dette 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 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 9). Der er primært fokus på opsætningen af diverse abonnementer (Beriget Grunddata, SKAT snitflader mv.) samt integrationen til Debitorfagsystemet, da det danner grundlaget for korrekt udbetaling. Dernæst på de øvrige leverancer til dels ATP og til de øvrige offentlige myndigheder samt halv offentlige instanser, såsom Danmarks Statistik m.v. Konverteringen vil ske systemopdelt, hvor først data vedrørende børne- og ungeydelse samt børnetilskud konverteres over i Systemet, og så efter en Bilag 3A Behovsopgørelse Side 54 af 78

56 månedsudbetaling konverteres data vedrørende underholdsbidrag. Eksisterende løsning består af to fysisk adskilte fagsystemer (KMD Børneydelse og KMD Underholdsbidrag), der hver især udgør en konverteringsbølge. Derudover vil der være fra det nuværende KMD OPUS Debitor som skal indkonverteres i Systemet, da ydelsesspecifik data fra familieydelser, omkring underholdsbidrag, bliver behandlet der. Ved hver konverteringsbølge skal data behandles ud fra et fast specificeret regelsæt. Scenariet er tilrettelagt efter følgende faser: 1. Udfasning af børneydelser (KMD Børneydelse) med data fra tilhørende støttesystemer, undtagen KMD OPUS Debitor. 2. Udfasning af underholdsbidrag (KMD Underholdsbidrag), samt den til Familieydelse hørende del af KMD Opus Debitor (både Børneydelser og Underholdsbidrag). Scenariet er derfor tilrettelagt således at krav i KMD Opus Debitor først udkonverteres i sidste bølge, sammen med underholdsbidrag. Krav tilhørende børneydelser vil derfor ligge i KMD Opus Debitor, indtil underholdsbidrag udkonverteres. Det betyder bl.a. at der ikke sendes nye krav over til nyt Debitorfagsystem, før at underholdsbidrag er konverteret i Systemet og i nyt Debitorfagsystem. Alle data fra Eksisterende Løsning, som indeholder information om familieydelsesområ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 prøveudtræk, så det er muligt for Leverandøren, at igangsætte prøvekonverteringen tidligt i forløbet. Dette sker for at få erfaring med både kompleksiteten og datakvaliteten. Endvidere afdækkes behovet for manuelle/maskinelle korrektioner inden data 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 9. Bilag 3A Behovsopgørelse Side 55 af 78

57 Figur 9 Ansvarsfordeling og dataflow for konvertering af data fra Eksisterende Løsning til Systemet. Udtræk af data: Den Eksisterende Løsning består af flere systemer, og støttesystemer. Der er således flere systemer, som indeholder data, der er relateret til en familieydelsessag. Dataudtrækket fra Eksisterende Løsning gennemføres af KMD og er aftalt i udfasningsassistancen. Udfasningsassistancen forefindes på ATP Udbudsportal ( 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 56 af 78

58 Aktiviteterne under Udtræk, Transformering, Indlæsning og validering uddybes nærmere i de følgende punkter. Leverandørens metode for transformering, indlæsning og validering vil fremgå af Leverandørens konverteringsstrategi Udtræk af data KMD leverer fuldt udtræk af alle de data fra KMD-systemer, som kan tænkes at skulle bruges i den nye løsning. Data udtrækkes som filer og placeres på en FTPserver. Udtræk af data fra Eksisterende Løsning omfatter: Systemdata fra KMD Børneydelse og KMD Underholdsbidrag. For disse vil data omfatte både afsluttede og igangværende sager, samt eventuelt tilknyttede opgaver. Generelle sagsdata fra KMD Sag vedrørende familieydelsessager. Dette inkluderer journalnotater og dokument metadata for tilknyttede dokumenter. Dokumenter fra KMD Sag EDH og KMD doc2archive. Erstatningspersonnumre fra KMD P-Data / Borgerkomponent. Detaljeret beskrivelse af data og udtræksformat findes i bilag 2B (Eksisterende data). KMD s ydelser i forhold til dataudtrækket fra Eksisterende Løsning er overordnet følgende: Leverer detaljeret design og dokumentation af udtrækket Levere data fra systemerne i det format, der er overordnet beskrevet i bilag 2B (Eksisterende data). Data leveres i samme kvalitet, som de i dag har i systemerne. Bidrager til den tværgående test af konverteringen, herunder at levere et prøveudtræk af produktionsdata. Bidrager til idriftsættelsesplan (ansvarlig for de aktiviteter, der skal foregå på KMD s side) Leverancerne er yderligere beskrevet i udfasningsassistance kravspecifikation og kravbesvarelse, som kan findes på ATP udbudsportal under Udfasningsassistance ( ATP vil fungere som kontaktpunkt mellem KMD og Leverandøren. Leverandøren skal hente prøveudtræk og endeligt dataudtræk fra KMD s FTPserver. FTP-serveren er yderligere beskrevet i udfasningsassistancens underbilag som ligger på ATP udbudsportal Bilag 3A Behovsopgørelse Side 57 af 78

59 ( tp_infrastruktur.pdf). Leverandøren skal sørge for, at dataudtræk bliver slettet fra FTP-serveren efter afhentning. Leverandøren skal verificere, at dataudtrækket fra KMD matcher den leverede dokumentation af udtrækket, samt at dataudtrækket overholder kravene fra udfasningsassistance-kravspecifikationen. Dette skal ske på tidspunktet for modtagelse af prøveudtræk fra KMD og skal ske ved indlæsning af de modtagne data. Herigennem kan det verificeres, om der er referentiel integritet mellem tabeller, og om data har det beskrevne format. Ved mangler i leverancen fra KMD håndteres dette af ATP Transformering af data Leverandøren skal bortfiltrere eventuelt unødvendige data, sammenstille data således at relationer bevares og transformere de data, som skal indlæses i Systemet i forbindelse med overgangen. Det vil bl.a. sige, at data ensrettes med Systemets informationsmodel. Leverandøren skal indledningsvist, gennem dokumentationsmateriale og evt. deltagelse i workshops med KMD, opbygge den dataforståelse som er nødvendig, for at gennemføre den efterfølgende konvertering. Leverandøren er ansvarlig for, at data migrationen fra den Eksisterende Løsning til Systemet sker korrekt ud fra de af KMD leverede databeskrivelser. ATP bidrager med forretningskendskab til data. Leverandøren skal i den forbindelse facilitere de workshops, som er nødvendige, for i samarbejde med ATP, at kunne mappe data fra den Eksisterende Løsning til Systemet. Leverandøren skal levere en beskrivelse af transformationen på informationsmodel-niveau, som skal godkendes af ATP. Transformeringen skal kunne håndtere data, som de er leveret af KMD, og som det vil fremgå af den detaljerede dokumentation, der leveres af KMD. ATP har ansvaret i tilfælde af, at der skal rettes op på data i Eksisterende Løsning. Leverandøren skal gennemføre en dataanalyse for at fastlægge behovet for datavask. ATP skal bistå med forretningsviden. Leverandøren skal sikre, at der etableres fuldt transaktionsspor på datatransformeringen og den efterfølgende indlæsning af data i Systemet. Bilag 3A Behovsopgørelse Side 58 af 78

60 Nødvendigt værktøj og programmel til transformering af data udvikles/stilles til rådighed af Leverandøren Indlæsning og viderefordeling af data Leverandøren er ansvarlig for, at alle data konverteres korrekt ind i Systemet, og at sagerne oprettes i den rette tilstand. Endvidere skal Leverandøren sørge for, at der foretages den fornødne viderefordeling af data og synkronisering med støttesystemer. Det skal sikre at data er konsistente på tværs af Systemet og støttesystemer Indlæsning af data i Systemet Leverandøren skal indlæse fyldestgørende data til at sagsbehandlingen kan videreføres i Systemet med al den funktionalitet, der er i Systemet (såfremt der er de tilstrækkelige data til rådighed i dataudtrækket fra KMD). Herunder gælder særligt at: Aktive sager fra Eksisterende Løsning skal videreføres i Systemet, og sagsbehandlingen og/eller udbetalingerne skal forsætte i Systemet. Som minimum skal historik, svarende til indeværende år + 3 år for børne- og ungeydelsesager samt børnetilskudssager og indeværende år + 10 år for underholdsbidragssager, konverteres ind i Systemet. Afsluttede sager fra Eksisterende Løsning skal kunne genberegnes i forhold til de på det tidspunkt gældende regler. Der skal være adgang til dokumenter og journalnotater på sagerne. Kassations- og arkiveringsprocesserne skal virke for alle indlæste data. Bemærk at konfigurationsdata fra KMD Sag ikke skal indlæses i Systemet, selvom de fremgår af databeskrivelsen i bilag 2B (Eksisterende data). Leverandøren skal i Afklaringsetapen i samarbejde med ATP afklare, om der er data, der kan/skal håndteres manuelt. Anbefalingen godkendes af ATP som en del af den opdaterede konverteringsstrategi Viderefordeling af data og synkronisering med støttesystemer Leverandøren skal udveksle data med følgende systemer: Beriget Grunddata Personer med erstatningspersonnumre etableres i Beriget Grunddata. Bilag 3A Behovsopgørelse Side 59 af 78

61 Der skal opsættes abonnement for personkredsen, og persons- /myndighedsdata skal modtages fra Beriget Grunddata i den daglige replikering. SKAT Der skal oprettes abonnementer på og hentes indkomstoplysninger for alle i personkredsen. Herunder skal der oprettes abonnement på forskud og årsopgørelse. Sags- og dokumentindeks Alle aktive sager skal oprettes i sags- og dokumentindeks med tilknyttede dokumenter og journalnotater. Dataene vil herfra automatisk blive synkroniseret over i KMD Sag via den sædvanlige mekanisme til synkronisering mellem indekses og KMD Sag. Ydelsesindeks Bevillinger og ydelser skal oprettes i ydelsesindeks. ATP Datawarehouse Datawarehouse skal modtage et dataudtræk, når konverteringen er tilendebragt og alle data er konverteret ind. Data skal leveres i samme format som i de daglige dataleverancer se integrationsbeskrivelse FDWH1 i bilag 3A.6 (Integrationer). KMD Sag Når alle data er indlæst i Sags- og dokumentindeks og Ydelsesindeks, og alle sager derved er blevet synkroniseret til KMD Sag, skal de gamle sager i KMD Sag logisk slettes og herved også de gamle sager i Sags- og dokumentindeks. Sletningen i KMD Sag foretages af KMD ud fra en liste over de sager og dokumenter, der skal slettes. Leverandøren er ansvarlig for at levere denne sletteliste. Leverandøren skal sikre, at der etableres fuldt transaktionsspor på viderefordelingen af data Afstemning og datavalidering Leverandøren skal udvikle automatiseringsrutiner til afstemning af data. Kriterier for datavalidering og efterfølgende godkendelse, opsættes i samarbejde mellem Bilag 3A Behovsopgørelse Side 60 af 78

62 ATP og Leverandøren i forbindelse med migrationen af data fra Eksisterende Løsning til Systemet. Leverandøren skal som minimum gennemføre: Afstemning efter flytning af KMD dataudtræk til Systemets informationsmodel, som bevis for at alle relevante data er indlæst korrekt. Afstemning efter henholdsvis transformation og indlæsning af data, som bevis for at alle relevante data fra KMD dataudtrækket er indlæst korrekt og fuldstændigt i Systemet. Afstemning efter ajourføring af sager i Sags- og dokumentindeks og Ydelsesindeks som bevis for at der er overensstemmelse mellem sager i Systemet og i indekses, samt at sagerne er synkroniseret korrekt til KMD Sag. Verifikationen af KMD Sag synkronisering sker i samarbejde med KMD. Afstemmes op mod afstemningsdata leveret fra KMD. Beløbsafstemning på laveste niveau. Ad-hoc afstemning og kontroller, som skal gøres tilgængelige for ATP Bestandsafstemning og sumkontroller. Validering af transformeringen som sikrer, at der ikke sker data tab eller forvanskning af data ved overgangen til Systemet. Alle felter med parametre eller kodeværdier (f.eks. 01 = myndighed, 02 = person m.m.) skal dokumenteres konverteret korrekt. Alle numeriske felter skal dokumenteres konverteret korrekt. Alle felter, der forandrer udseende (evt. sammenlægning af adresse oplysninger), skal dokumenteres konverteret korrekt. Leverandøren skal i forbindelse med gennemførsel af konverteringen levere en afstemningsrapport som dokumentation for afstemning af data inklusive dokumentation/forklaring af evt. afvigelser, samt redegørelse for påkrævede handlinger for håndtering af afvigelser. Afstemningsrapporten skal godkendes af ATP Gennemførsel af konverteringen Leverandøren skal udarbejde en strategi for konvertering og beskrive denne overordnet i bilag 3B (Løsningsbeskrivelse), så ATP kan evaluere og betrygges i at Leverandøren har prøvet dette før. Bilag 3A Behovsopgørelse Side 61 af 78

63 Leverandøren skal med input fra ATP og KMD, tilrettelægge og gennemføre konverteringen, så overgangen fra Eksisterende Løsning til Systemet foregår på en sikker og forsvarlig måde, med særlig fokus på driftsstabilitet så forstyrrelser af den daglig drift, påvirkes mindst muligt. Leverandøren er ansvarlig for udarbejdelsen af en drejebog. ATP bidrager med overgangsinstrukser til kunderådgivergiver samt øvrige forretningsmæssige afklaringer. Drejebogen skal som minimum indeholde nedenstående punkter: a) Forretningsmæssig nedlukning/opstart ved overgangen til ny Familieydelsesløsning. b) Jobafvikling, udbetalinger, data udtræk. c) Koordinering med ATP ERP, Afstemning, DWH. d) Overgangsinstrukser til kunderådgivergiver. e) Integration til eksterne parter jf. systemkonteksten i bilag 3A (Behovsopgørelse), som skal nedlukkes og opstartes igen (databehandleraftaler og snitfladeaftaler). Leverandøren er ansvarlig for at konverteringen kan gennemføres indenfor den fastsatte tidsramme for konverteringen. De enkelte lukkevinduer til brug for den trinvise konvertering skal være så lille som muligt og skal være placeret uden for kritisk forretningstid, jf. bilag 7 (Servicemål). ATP skal godkende hvis Leverandøren ønsker at fravige dette. Selvbetjeningsløsningen skal i så vid mulig udstrækning være tilgængelig i et lukkevindue, således at borgere kan afgive deres ansøgning. Det er dog acceptabelt at opsamle disse informationer separat således at de efter et lukkevindue kan indlæses i Systemet. Hvis der er aktiviteter, der gennemføres indenfor kritisk forretningstid, skal der så vidt muligt fortsat være læseadgang til data, for sager der tidligere er konverteret ind i Systemet Håndtering af prøveudtræk Til brug for afprøvning af konverteringsprogrammellet vil der fra KMD blive leveret et prøveudtræk fra den Eksisterende Løsning. Der vil være tale om et fuldt udtræk af umaskerede produktionsdata; Indeholdende alt data for hele bestanden, dog kun med repræsentativ data fra udvalgte støttesystemer. Hvis der er behov for yderligere prøveudtræk (f.eks. af en delbestand), skal dette aftales med ATP. Bilag 3A Behovsopgørelse Side 62 af 78

64 Leverandøren skal ved anvendelse af udtræk fra den Eksisterende Løsning sikre at de non-funktionelle krav i bilag 3A.1 (Kravliste) vedrørende test og datasikkerhed overholdes. 9.7 Brugervenlighed Dette emneområde angiver krav til, hvor nemt det skal være at benytte og tilgå Systemet. Brugervenlighed drejer sig primært om kvaliteten af brugergrænsefladen, hvilket eksempelvis drejer sig ergonomi, den visuelle oplevelse, skærmbillede opbygning, hvordan der navigeres rundt i Systemet og de hjælpemidler der stilles til rådighed for handikappede. 9.8 Lovgivning ATP ønsker sikkerhed for at Leverandøren i sit arbejde overholder gældende lovgivning, ligesom Systemet skal være konstrueret på en sådan måde, at ATP kan varetage de forretningsmæssige opgaver Systemet understøtter, således at almen og ATP-specifik lovgivning til en hver tid overholdes. Kravene fremgår af bilag 3A.1 (Kravliste). Det påhviler ATP at identificere og foretage de nødvendige fortolkninger af relevante dele af UDK-specifik lovgivning (fx Børne- og ungeydelsesloven, Børnetilskudsloven, Forvaltningsloven og Udbetaling Danmark Loven) samt omsætte disse til krav til Systemet. Leverandøren skal på ATP s anmodning deltage i dette arbejde. 9.9 Sikkerhed IT sikkerhed handler om at sikre konfidentialitet, integritet og tilgængelighed af information imod forskellige sikkerhedsrisici. Dette behov skal sikres ved at indarbejde tekniske og systemspecifikke kontroller både i infrastrukturen og i designet af Systemet samt i de underliggende forretningsprocesser. Kravene til sikkerhed fremgår af bilag 3A.1 (Kravliste) Miljøer Leverandøren skal tilvejebringe et driftsmiljø samt en række interne såvel som eksterne miljøer til brug for udvikling, test og uddannelse. Til brug for afprøvningerne, beskrevet i bilag 6 (Afprøvninger), vil der være behov for et internt testmiljø, et eksternt testmiljø, et præproduktionsmiljø og så selve Bilag 3A Behovsopgørelse Side 63 af 78

65 produktionsmiljøet. Kravene til de forskellige miljøer vil fremgå af bilag 3A.1 (Kravliste) Projektledelse Leverandøren har det overordnede projektledelsesansvar og ansvarlig for projektledelsen i perioden fra kontraktindgåelsen og til Overtagelsesdagen. Projektledelsen skal ske i overensstemmelse med en formaliseret projektledelsesmetode og Leverandøren er ansvarlig for gennemførelsen af projektledelsesaktiviteter som fx planlægning og udarbejdelsen af tidsplaner jf. bilag 1 (Tidsplan) og kravene i bilag 3A.1 (Kravliste) Uddannelse Leverandøren skal levere følgende uddannelse med tilhørende uddannelsesmateriale ATP s projektteam skal uddannes indenfor leverandør-, løsnings- og metodespecifikke områder, således at ATP s projektteam bliver i stand til at deltage effektivt i projektet omkring design, udvikling og ibrugtagning af Systemet. ATP s forretningsadministratorer skal uddannes i konfiguration og tilpasning af Systemet. ATP s undervisere skal uddannes, således at de er i stand til at uddanne øvrige brugere af Systemet ( train-the-trainer -princippet). De konkrete krav til uddannelse fremgår af bilag 3A.1 (Kravliste) Dokumentation Leverandøren skal levere fyldestgørende og til en hver tid fuldt opdateret dokumentation af Systemet, herunder den efterfølgende drift og vedligeholdelse af dokumentationen. Leverandøren skal sikre, at ATP til enhver tid har adgang til opdateret og detaljeret dokumentation, der gør ATP i stand til at få fuld indsigt i Systemet. Samtidig skal dokumentationen være i en sådan stand, at en anden it-leverandør, uden unødigt besvær, vil kunne sætte sig ind i Systemet og eventuelt overtage drift, vedligeholdelse og videreudvikling heraf. Den del af dokumentationen, der falder uden for Leverandørens ansvarsområde, jf. bilag 4 (Dokumentation) og programmel, skal som hovedregel udarbejdes og Bilag 3A Behovsopgørelse Side 64 af 78

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

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

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

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

70 Etablering af processer for tværgående leverandør samarbejde Leverandøren skal sikre at samarbejde med Øvrige Leverandører understøttes i alle IT Service Management processer samt medvirker efter aftale i fora for tværgående leverandørsamarbejde. Der henvises også til bilag 15 (Leverandørkoordinering) Etablering af processer og værktøjer til vedligeholdelse af Systemet Leverandøren skal etablere processer til vedligehold af Systemet, herunder processer til fejlfinding, rettelse af fejl og samarbejde med ATP. Desuden skal Leverandøren etablere de værktøjer, der er nødvendige for at understøtte processerne til vedligehold af Systemet Vedligeholdelse og videreudvikling af Systemet Vedligeholdelse af Systemet Leverandøren varetager håndteringen af Fejl og Mangler ved Systemet, herunder vedligehold. På baggrund på vedligeholdelsen, skal Leverandøren løbende ajourføre Dokumentationen for Systemet. Leverandøren skal løbende fejlfinde og -afhjælpe konstaterede Fejl i Systemet i henhold til Kontrakten. Vedligehold dækker over løsning af alle Fejl og Mangler, som Leverandøren eller ATP måtte opdage samt forebyggende vedligehold og support. Forhold vedrørende rapportering af Incidents, fejlkategorier mv. sker på samme måde som den øvrige del af Driftsmiljøet. Der henvises også til bilag 7 (Servicemål) og bilag 8 (Samarbejdsorganisation og rapportering). Bilag 3A Behovsopgørelse Side 69 af 78

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

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

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

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

75 Service Operation Supportløsningen Alle brugerrelaterede Servicedesk henvendelser håndteres af ATP som 1. level support. Alle tekniske alarmer/ incidents genereret inden for Leverandørens ansvarsområder, håndteres af Leverandøren som 1. level support. Leverandøren varetager ligeledes 2. level support. For en nærmere beskrivelse af samarbejdsorganisationen henvises til bilag 8 (Samarbejdsorganisation og rapportering) Incident management Incident management omfatter ATP s krav til Leverandørens processer inden for incident management. Incident management skal sikre, at hændelser, der ikke er en del af den normale Drift håndteres, således at Driften kan varetages optimalt og som minimum i overensstemmelse de definerede Servicemål, jf. bilag 7 (Servicemål). Incident management skal følge ITILs anbefalinger til best practice. Forebyggelse baseret på incidents. Efter løsning af incidents, skal Leverandøren i relevant omfang, eventuelt i samarbejde med ATP s Øvrige Leverandører, foretage en opfølgning på processen for at sikre erfaringsopsamling, der kan forbedre fremtidige processer (proaktiv incident management) Problem management Problem management omfatter ATP s krav til Leverandørens processer inden for problem management. Problem management skal medvirke til at minimere og forebygge de driftsmæssige konsekvenser af Incidents og Problems. Problem management processen har både reaktive og proaktive aspekter. Det reaktive aspekt vedrører løsning af problemer som reaktion på en eller flere incidents. Proaktiv problem management vedrører identifikation og løsning af problemer og kendte fejl (known errors) før en incident indtræffer. Leverandøren skal proaktivt konstatere og forebygge problemer, eksempelvis ved at reducere eller helt forebygge incidents, i forbindelse med løbende trendanalyser, som udføres i forbindelse med ydelsen. Trendanalysen kan eksempelvis håndteres ved Bilag 3A Behovsopgørelse Side 74 af 78

76 gennemgang af alle Incidents (både løste og uløste) for gentagne fejlmønstre og root causes Change management Changes opstår på flere måder, fx som resultat af incidents, problemer, fra proaktiv søgning af forretningsfordele, eller på initiativ fra ATP. Change management processerne skal sikre, at standardiserede metoder og procedurer anvendes for effektiv og hurtig håndtering af alle ændringer under kontrakten. En change er en hvilken som helst ændring af ATP s It-miljø. Samtlige ændringer skal følge change management processen med undtagelse af eventuelle standardændringer, som godkendes af ATP, og som dokumenteres i den af Leverandøren udarbejdede Driftsaftalehåndbog Release management Leverandøren skal sikre en struktureret og sikker udrulning af Programmel og maskinel i ATP s It-miljø, herunder skabe enighed om det faktiske indhold i releases gennem dialog med Change- og Releasegruppen, jf. bilag 8 (Samarbejdsorganisation og rapportering) Event management - Overvågning Leverandøren varetager løbende overvågning af samtlige hovedydelser omfattet af aftalen. Leverandøren tilbyder ligeledes, efter ATP s anmodning, opsætning af udvidet overvågning, fx af applikationsprogrammel Configuration management Gennem configuration management skal der etableres Dokumentation af konfigurationer, miljøer, maskinel mv. for at støtte service management processerne. Konfigurationsstyring skal ske i overensstemmelse med ITILs anbefalinger til best practice. Krav til Dokumentation er endvidere beskrevet i bilag 4 (Dokumentation) Capacity management Leverandøren skal sikre, at der er tilstrækkelig kapacitet i miljøerne til at kunne levere servicen i henhold til de aftalte servicemål samt Kontraktens øvrige krav. Bilag 3A Behovsopgørelse Side 75 af 78

77 Leverandøren skal overvåge kapacitetsforbruget på alle relevante områder jf. bilag 8 (Samarbejdsorganisation og rapportering), punkt Målingerne af kapacitetsforbruget skal være så hyppige eller af en sådan karakter, at det vil være muligt for Leverandøren rettidigt at spore selv mindre ændringer i forbrug, der kan fordre en skalering af kapacitetsydelserne og deraf følgende vederlagsregulering. Leverandøren skal registrere og opbevare de historiske målinger af kapacitetsforbruget. Bilag 3A Behovsopgørelse Side 76 af 78

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

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