Bilag 3A Behovsopgørelse

Transkript

1 Bilag 3A Behovsopgørelse Version

2 Indhold 1 VEJLEDNING TIL TILBUDSGIVER INDLEDNING UNDERBILAG FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER FORRETNINGSUDBUDSARKITEKTUR OG KOMPONENTMODEL FORRETNINGSUDBUDSARKITEKTUREN AUTOMATISERET OG MANUEL SAGSBEHANDLING KANALER OG KOMMUNIKATION ØVRIGE ELEMENTER I FORRETNINGSUDBUDSARKITEKTUREN KOMPONENTMODEL KANALER Modtagelse af post Selvbetjening MANUELT Opgaveindbakke Tværgående Overblik Sagshåndtering Manuelle Breve System Administration Regeladministration AUTOMATISK Hændelser Validering Beskedhåndtering Dan Udbetaling Kontrol Bilag 3A Behovsopgørelse Side 1 af 77

3 Skatteberegning Beregning af Ydelser STØTTEKOMPONENTER Persondata Sager og dokumenter ØVRIGE KOMPONENTER Sikkerhed Rapporter Jobafvikling Økonomi Afstemning Arkivering (på nuværende tidspunkt er det ikke afklaret hvorvidt pensionssystemet skal aflevere data til statens arkiver) Indekssynkronisering SYSTEMETS ROLLER RISIKOVURDERING PERSONDATALOVEN FUNKTIONSADSKILLELSE DOKUMENTATION KONTROLLER FORRETNINGSROLLER FORRETNINGSPROCESSER SAMLET PROCESOVERBLIK KERNEPROCESSER KERNEPROCES - HÅNDTER INDBERETNING Løsningsflow, Opret sag Løsningsflow, Udfyld indberetning KERNEPROCES - TRÆF AFGØRELSE Bilag 3A Behovsopgørelse Side 2 af 77

4 Løsningsflow, Træf afgørelse KERNEPROCES - HÅNDTER LØBENDE ÆNDRINGER Løsningsflow, Håndter løbende ændringer person Løsningsflow, Håndter løbende ændring myndighed Løsningsflow, Håndter indgående automatisk genererede hændelser KERNEPROCES HÅNDTER DRIFT Løsningsflow, Vurder økonomisk effektueringsplan Løsningsflow, Håndter satsregulering Løsningsflow, Håndter årlig regulering Løsningsflow, Udfør årlig kontrol af udskudt pension Løsningsflow, Udfør årlig kontrol af leveattester Løsningsflow, Udfør årlig kontrol af varmeregnskaber LØSNINGFLOW, HÅNDTER UDBETALING LØSNINGSFLOW, HÅNDTER OPKRÆVNING INFORMATIONSARKITEKTUR OVERORDNET BEGREBSMODEL FOR UDBETALING DANMARK BEGREBS- OG INFORMATIONSMODELLER FOR FORRETNINGSLØSNINGEN DOKUMENTATION TIL LEVERANDØR INFORMATIONSMODEL SAG SAG Sag - Nøgler og Egenskaber Sagens oprettelse og livsforløb PART SAGSDOKUMENTATION INFORMATIONSMODEL PENSION PENSIONSSAG Forskelle til sagsbegreb i Eksisterende Løsning PENSIONSINPUTGRUNDOPLYSNING PENSIONSYDELSESTYPE PENSIONSYDELSE Bilag 3A Behovsopgørelse Side 3 af 77

5 6.4.5 UDBETALING PENSIONSSYSTEMADMINISTRATION IT ARKITEKTUR IT-UDBUDSARKITEKTUREN SYSTEM KONTEKST OG INTEGRATIONER TRANSITIONSARKITEKTUR INTEGRATIONER OG INFRASTRUKTUR NON-FUNKTIONELLE KRAV TIL SYSTEMET ARKITEKTUR RAMMER FOR ARKITEKTUREN BELASTNING OG SKALERING Telefonopkald Breve Blanketter (yderligere underretningsbreve) Digital Post DESIGN OG APPLIKATIONSSTRUKTUR LOGNING DRIFTSSTYRING TILGÆNGELIGHED DATAKONVERTERING KONVERTERINGSKONCEPTET GENERELT 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 Bilag 3A Behovsopgørelse Side 4 af 77

6 8.6.7 HÅNDTERING AF PRØVEUDTRÆK BRUGERVENLIGHED LOVGIVNING SIKKERHED MILJØER PROJEKTLEDELSE UDDANNELSE DOKUMENTATION IDRIFTSÆTTELSE HYPERCARE SAMARBEJDE OG RAPPORTERING AFPRØVNINGER FREMTIDIGE TILPASNINGER TIL SYSTEMET HENT INDKOMSTOPLYSNINGER UDENOM KMD INDKOMST INTEGRATION TIL ANDET UDBETALINGSSYSTEM KRAV TIL DRIFT, VEDLIGEHOLDELSE, SUPPORT OG VIDEREUDVIKLING (YDELSERNE) OVERORDNEDE KRAV ETABLERINGSYDELSEN ETABLERING AF LOKALITETER ETABLERING AF KOMMUNIKATIONSINFRASTRUKTUR ETABLERING AF PROGRAMMEL ETABLERING AF PROCESSER FOR DRIFTSAFVIKLING OG SUPPORT ETABLERING AF PROCESSER OG VÆRKTØJER TIL VEDLIGEHOLDELSE AF SYSTEMET VEDLIGEHOLDELSE OG VIDEREUDVIKLING AF SYSTEMET VEDLIGEHOLDELSE AF SYSTEMET VIDEREUDVIKLING AF SYSTEMET LØBENDE DRIFT LOKALITETER Bilag 3A Behovsopgørelse Side 5 af 77

7 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 Bilag 3A Behovsopgørelse Side 6 af 77

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

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 (Begrebs- og informationsmodeller) Bilag 3A.5 (Regel- og beslutningsmodeller) Bilag 3A.6 (Integrationer) Bilag 3A.7 (Wireframes) 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 pension. Bilaget indeholder de løsningsflows og aktivitetsbeskrivelser, der indgår i de løsningsflows og forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af pension. Bilaget indeholder UML modeller af de væsentligste forretningsmæssige begreber og de informationer, som vedrører indberetning, administration og udbetaling af pension. Bilaget indeholder standardiserede modeller af de regler af lovgivningsmæssig og anden karakter forbundet med indberetning, administration og udbetaling af pension Bilaget indeholder uddybende information om de integrationer, som Leverandøren skal etablere fra Systemet. Indgår ikke i markedsdialog. 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 Tabel 1 Behovsopgørelsen og tilhørende underbilag Bilag 3A Behovsopgørelse Side 8 af 77

10 2.2 Farveanvendelse på arkitekturdiagrammer I dette bilag optræder en række arkitekturdiagrammer. 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 77

11 3 Forretningsudbudsarkitektur og komponentmodel I dette afsnit beskrives forretningsudbudsarkitekturen, som den ser ud ved implementering af det nye System. Herefter beskrives Systemet via en komponentmodel. 3.1 Forretningsudbudsarkitekturen Forretningsudbudsarkitekturen beskriver sammenhænge mellem de forskellige dele i den forretningsmæssige løsning og dels den ønskede forretningsmæssige funktionalitet. Tegningen og den efterfølgende forklarende tekst tjener som introduktion til pensionsløsningen på et konceptuelt plan. Figuren nedenfor viser de væsentligste elementer i forretningsudbudsarkitekturen. Figur 2: Forretningsudbudsarkitektur for pensionsløsningen I den samlede forretningsmæssige løsning er selve fagsystemet illustreret ved udvalgte forretningskomponenter med blå farve. Denne del er specifik for fagsystemet til administration af folke- og førtidspension, mens de øvrige dele af figuren viser samspillet med omkringliggende systemer. For at lette overblikket er kun ud- Bilag 3A Behovsopgørelse Side 10 af 77

12 valgte 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 for en komplet oversigt over eksterne systemer, som Systemet skal integrere til Automatiseret og manuel sagsbehandling Denne del er selve fagsystemet, hvor man finder it-understøttelse til administration af folke- og førtidspension. De blå kasser repræsenterer forretningskomponenter, der beskrives i afsnit 3.2. Fagsystemet skal betragtes som en hel løsning, hvor både automatiseret og manuel funktionalitet er placeret. Dette betyder, at kunderådgiverne arbejder i fagsystemet som deres primære system og kan bruge det til at løse stort set alle deres opgaver. Det er en forudsætning, at sagsbehandlingen automatiseres i vid udstrækning for at ATP kan realisere det effektiviseringspotentiale, der fremgår af ATP s business case. Dette er særdeles vigtigt for de løsningsflows i bilag 3A.1 (Løsningsflows og aktivitetsbeskrivelser), der er kategoriseret som motorveje eller landevej, jf. Fejl! Henvisningskilde ikke fundet.. Fagsystemet indeholder den funktionalitet og sikrer adgang til de data, der er behov for at behandle en ansøgning. Dokumenter, journalnotater og digital post er endvidere placeret på sager og er journaliseret i fagsystemet. Fagsystemet skal understøtte ønsket om at gennemføre straight through processing (STP) i videst muligt omfang uden, at det går ud over kvaliteten af sagsbehandlingen. Princippet er, at sagerne behandles så automatisk som muligt i fagsystemet, især på motorvejene jf. Fejl! Henvisningskilde ikke fundet., og hvor det er muligt ud fra oplysninger i de autoritative registre. I de tilfælde, hvor der er behov for manuel sagsbehandling, sendes en opgave videre til kunderådgivernes opgaveindbakke i fagsystemet 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 pensionsydelser og tillæg, at indberette ændrede oplysninger samt mulighed for at se egne oplysninger. Bilag 3A Behovsopgørelse Side 11 af 77

13 Udbetaling Danmark har etableret en kviklinje for kommunerne, som er en direkte linje til Udbetaling Danmark. Den skal sikre hurtige svar og afklaringer vedr. en borgers sag mellem kommunen og Udbetaling Danmark. Udbetaling Danmark arbejder tæt sammen med udenlandske myndigheder om pensionister, der får pension i udlandet. F.eks. udveksles stamoplysninger mellem en række lande og der samarbejdes med lokale myndigheder om tilkendelse af førtidspension for danskere, der bor i udlandet. Derudover illustreres 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 Øvrige elementer i forretningsudbudsarkitekturen De øvrige dele af forretningsudbudsarkitekturen er tværgående (indenfor Udbetaling Danmark) støttesystemer, komponenter eller registre, som fagsystemet skal have snitflader til. De tværgående dele understøtter interne behov for rapportering, forpligtelser i forhold til ekstern rapportering og udbetaling. Bemærk at en fuldstændig liste over integrationer findes i afsnit 7 IT arkitektur. 3.2 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, vi tænker Systemet 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 Bilag 3A Behovsopgørelse Side 12 af 77

14 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. Derfor skal komponenternes funktionalitet kunne ændres igennem skærmbilleder, hvor ATP s forretningsadministratorer kan konfigurere regler og parametre til regler. Figuren nedenfor viser komponentmodellen for pension. Figur 3: Komponentmodel Komponentmodellen er inddelt i fem hovedområder: Kanaler Manuelt Bilag 3A Behovsopgørelse Side 13 af 77

15 Automatisk Støttekomponenter Øvrige komponenter De følgende afsnit gennemgår komponenterne i modellen enkeltvis og præsenterer overordnet den funktionalitet, som komponenterne leverer. De detaljerede krav til komponenterne er listet i bilag 3A.1 Kravlisten Kanaler Komponenterne i denne gruppe angiver hvordan Systemet skal fungere sammen med ATP s postmodtagelse og Systemets selvbetjeningsløsning Modtagelse af post Systemet skal kunne modtage digital og fysisk post fra borgere og myndigheder. Digital post vil komme fra de fællesoffentlige løsninger på Borger.dk. 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 Selvbetjening Selvbetjening leverer en webbaseret løsning, som udstilles på borger.dk, der anvendes af borgere til ansøgning om pensionsydelser og tillæg, indberetning af oplysninger samt informationer om pensionistens sag og vejledning. Derudover kan borgerne foretage en simulering af hvor meget, den enkelte forventes at få udbetalt. Selvbetjening modtager indtastede data og sender disse til Systemet for validering og eventuel registrering Manuelt Denne gruppe af komponenter støtter op om den daglige manuelle sagsbehandling, som foretages af kunderådgiverne Opgaveindbakke Udgangspunktet for det daglige arbejde for en kunderådgiver er Opgaveindbakken. Opgaveindbakken indeholder opgaver, som er struktureret i arbejdspakker. En opgave kan bestå behandling af fysisk post, digital post og hændelser, som systemet ikke kan håndtere automatisk. Bilag 3A Behovsopgørelse Side 14 af 77

16 En kunderådgiver skal kunne reservere og arbejde med en opgave Tværgående Overblik Systemet skal kunne præsentere et Tværgående Overblik, der samler alle relevante informationer om den enkelte borger. Formålet er at give kunderådgiveren mulighed for, ved et enkelt opslag, hurtigt at få et overblik over borgerens personlige forhold. Fra det Tværgående Overblik skal kunderådgiveren have mulighed for at få præsenteret yderligere detaljer om en sag og borgeren Sagshåndtering Denne komponent leverer en brugergrænseflade, hvorfra kunderådgiveren udfører manuelle sagsbehandling, og hvor pensionsdata kan vises og redigeres Manuelle Breve Denne komponent har ansvaret for at administrere og vedligeholde brevskabeloner til udsendelse af manuelt udarbejdede breve. Disse breve sendes ad samme kanal til Fjernprint som automatisk genererede breve, og kan herfra enten afsendes til borgeren eller myndighed som fysisk post eller digital besked. Kunderådgiveren skal her kunne genere et manuelt brev med udgangspunkt i prædefinerede brevskabeloner, og forretningsadministratoren skal kunne oprette nye skabeloner og rette i eksisterende System Administration Systemet indeholder en brugergrænseflade, hvor man kan udføre administration af systemet. Med administration menes her fx rettelse af forskellige parametre (fx datoer, grænseværdier mv.), tekster, hjælpeinformation og genvejstaster mv 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 tilkendelse og ydelsesberegning. Bilag 3A Behovsopgørelse Side 15 af 77

17 Komponenten leverer en brugergrænseflade til at vedligeholde regler/parametre til at udføre validering, kontrol, afgørelse (beslutning), beregning af ydelse samt skatteberegning, herunder beregning af ATP-bidrag og bidrag til Supplerende Arbejdsmarkedspension. I Regeladministration vedligeholdes også regler for hvilke processer, der skal igangsættes når hændelser indtræffer. De konkrete krav til parameterstyring og konfigurering af Systemet fremgår af bilag 3A.1 Kravliste Automatisk Denne gruppe af komponenter understøtter den automatiske sagsbehandling på motorvejene (for nærmere om motorvejene se Fejl! Henvisningskilde ikke fundet.) Hændelser Hændelser har ansvaret for at styre et automatiseret flow i fagsystemet efter en given ændring i interne eller eksterne registre. Komponenten igangsætter den proces, der følger efter en given ændring i eksterne eller interne registre. Det sker på baggrund af de beslutningsmodeller, der er gældende for den aktuelle proces Validering Denne komponent har ansvaret for at validere inputdata såsom ansøgninger og ændringer til Systemet. Valideringen skal sikre konsistens i Systemets data, således, at beløb f.eks. ikke indtastes i datofelter. Validering kan både ske på feltniveau (enkelt attribut validering) og ved at vurdere sammenhænge mellem flere forskellige informationer. Det sker ud fra et sæt af beslutningsregler, der er implementeret i komponenten Regel Administration. Validering udstiller services til Selvbetjening (jf. kravliste validering ) Beskedhåndtering Beskedhåndtering initierer udsendelse af beskeder til Digital Post og fysiske breve til Fjernprint. Den indsamler informationer og genererer automatisk beske- Bilag 3A Behovsopgørelse Side 16 af 77

18 den/brevet. På baggrund af retursvaret fra Fjernprint registreres den anvendte afsendelseskanal. Beskedhåndtering indeholder desuden en brugergrænseflade til konfigurering af beskeder/breve. Komponenten muliggør oprettelse og vedligehold af besked- /brevskabeloner med tilpasning og forudfyldelse af tekstblokke Dan Udbetaling Komponenten skal samle og overføre udbetalinger til udbetalingssystemet. Den registrerer udbetalingsdata og genererer udbetalingsfiler. Hvis en bevilget ydelse har kommunal medfinansiering, dvs. borgerens kommune skal betale en andel af ydelsen, sender komponenten Dan udbetaling data til systemet Kommunal Medfinansiering, jf. Systemkontekstdiagrammet. Data er opdelt pr. kommune på personniveau med information om kommune, person og beløb Modregning Komponenten Modregning effektuerer modregninger i pensionsydelser for krav, der indmeldes fra opkrævningssystemet og eksterne systemer som Boligstøttesystemet, Kommunernes Ydelsessystem og kommunale systemer, der håndterer opkrævning af serviceydelser (se evt. Systemkontekstdiagrammet i afsnit 7.2). Komponenten har ansvar for at danne udbetalingsposter til fordringshavere for de modregninger den foretager Dan Opkrævning Dan opkrævning skal kunne danne opkrævningsposter, der sendes til opkrævningssystemet Kontrol Kontrol behandler ansøgninger, indberetninger og ændringer efter, at Validering succesfuldt har valideret inputdata, og borgeren er fundet berettiget til ansøgte ydelser. Komponenten udfører kontroller ved inddragelse af yderligere data end de, der direkte danner grundlag for berettigelse til ydelser. Et eksempel på en kontrol kunne være om der bor en anden pensionist på samme adresse, som ansøger, der angiver at være enlig. 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 nogle kontrolbetingelser er opfyldt adviseres en kunderådgiver herom for videre inspektion af sagens oplysninger og yderligere kontroller. Bilag 3A Behovsopgørelse Side 17 af 77

19 Skatteberegning Skatteberegning foretager beregning af A-skat, ATP-bidrag, bidrag til Supplerende Arbejdsmarkedspension og nettoydelse. Den kan foretage enkeltberegninger samt bestandsberegninger, som enten er igangsat automatisk eller manuelt af en kunderådgiver. Komponenten benytter parametre fra Regel Administration til at gennemføre en skatteberegning. Skatteberegning understøtter, at man foretager en genberegning baseret på tidligere udgaver af input og skattekort, som den henter fra e-indkomst Beregning af Ydelser Beregning af Ydelser indeholder beregningsfunktionaliteten for alle typer pensionsydelser og tillæg. Komponenten træffer afgørelser på baggrund af bl.a. indkomstoplysninger, beskæftigelsesgrad, formue, samliv og beregner ydelsen. Herefter oprettes en effektueringsplan som afspejler de ydelser, borgeren er tilkendt. Hvis beregningerne resulterer i at borgeren har fået for meget udbetalt i pensionsydelser, sørger komponenten for at korrigere de kommende pensionsydelser i indeværende kalenderår. Hvis komponentens beregninger resulterer i, at der skal rettes et krav mod borgeren, sender komponenten automatisk en opkrævning til Opkrævningssystemet, hvorfra beløbet opkræves. Opkrævningen kan enten ske ved udsendelse af et girokort til borgeren eller ved modregning i kommende pensionsudbetalinger. Beregningen baserer sig på de beslutningsregler og beslutningsparametre, der er defineret for tilkendelse og ydelsesberegning i komponenten; Regel Administration Støttekomponenter Denne gruppe af komponenter varetager informationer om borgere fra autoritative registre samt sager og dokumenter Persondata Denne komponent har ansvaret for at hente persondata fra Beriget Grunddata. Borgerdata udstiller disse informationer for de øvrige komponenter i Systemet. Komponenten skal vedligeholde de ydelsesspecifikke persondata som ikke vedligeholdes i det tværgående støttesystem, Beriget Grunddata. Dette drejer sig f.eks.om enligstatus og undtagelse for obligatorisk selvbetjening, som brugere kan Bilag 3A Behovsopgørelse Side 18 af 77

20 opdatere igennem Systemet. Det vil sige gemme disse lokalt og understøtte at disse kan opdateres, ligesom komponenten har ansvaret for, at historiske data bevares og kan tilgås fra de andre komponenter 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 Øvrige Komponenter 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 Rapporter Rapporter har ansvaret for, at der dannes dataudtræk og genereres afleveringsfiler, så der kan dannes rapporter til interne ATP systemer og eksterne rapporter til forskellige samarbejdsparter primært offentlige instanser Jobafvikling Komponenten har ansvaret for at håndtere driftflows for interne hændelser i fagsystemet, hvilket typisk drejer sig om batchkørsler. Komponenten vedligeholder regler for kørselstidspunkter og flowregler for afvikling af de automatiske kørsler Økonomi Systemet overfører posteringer til ATP`s ERP system i forbindelse med udbetalinger, dannelse af opkrævningsposter, ændringer til udbetalinger etc. Systemets kontonumre skal stemme overens med de kontonumre som anvendes i ERP, så sum-posteringer etc. placeres korrekt i forbindelse med en overførsel. Samlet set sikrer denne dataudveksling, at regler til understøttelse af regnskabslovgivning samt gældende revisionskrav kan overholdes. Bilag 3A Behovsopgørelse Side 19 af 77

21 Afstemning Afstemning leverer afstemningsdata fra fagsystemet til et file share hos ATP for videre behandling. Afstemning har ansvaret for at udtrække og samle afstemningsdata fra fagsystemet, da det forretningsmæssige formål med afstemning er at dokumentere, at regnskabstallene er retvisende. Komponenten har ligeledes ansvar for at foretage afstemning af interne dataflyt i Systemet Arkivering (på nuværende tidspunkt er det ikke afklaret hvorvidt pensionssystemet skal aflevere data til statens arkiver) Systemet skal efterleve de offentlige arkivers krav til elektronisk aflevering iht. de til enhver tid af de offentlige arkiver (herunder Statens Arkiver) fastsatte regler, herunder Arkivloven. Arkiveringskomponenten skal sikre dette Indekssynkronisering Systemet henter sags- og ydelsesinformationer fra de fælleskommunale støttesystemer, Sags- og dokumentindeks og Ydelsesindeks. Systemet skal tilsvarende levere sags- og ydelsesinformationer for pensionssager 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 i den overgangsperiode hvor nogle af ydelsesområdernes systemunderstøttes der. Samlet sikrer denne dataudveksling, at kunderådgiverne har et overblik over sager i både Udbetaling Danmark og i kommunerne og på denne baggrund kan man foretage helhedsorienteret vejledning af borgeren på tværs af Udbetaling Danmarks og kommunernes opgavesnit. Bilag 3A Behovsopgørelse Side 20 af 77

22 4 Systemets roller Det er et grundlæggende arkitekturkrav, at der anvendes roller til at styre adgang til data og funktioner. Adgangstildelingen skal være baseret på en risikovurdering og foregå i overensstemmelse med informationssikkerheds- og kontrolpolitikken i ATP. Det er ATP som tildeler brugerne 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. 4.1 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. En hensigtsmæssig opbygning af roller er en vigtig forebyggende kontrol i forhold til at afdække risici. 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. 4.2 Persondataloven Persondataloven stiller krav til behandling af data. Ved behandling af data forstås adgang til at se, registrere, slette eller arkivere data. Ret til at behandle alle personfølsomme oplysninger skal være begrundet i et kontinuerligt arbejdsrelateret behov. Ved design og vedligeholdelse af roller bør det sikres, at der kun tildeles adgange til personfølsomme oplysninger, hvis der er et kontinuerligt arbejdsrelateret behov. Bilag 3A Behovsopgørelse Side 21 af 77

23 4.3 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 i forretningen og 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. 4.4 Dokumentation Rollerne og de tilhørende rettigheder skal dokumenteres i en rolle/rettighedsmatrice. I rolle/rettighedsmatricen skal rollerne stå nævnt vandret og de tilhørende rettigheder lodret. Det skal for hver rettighed være angivet om der er tale om oprette-, læse-, opdatere- og/eller sletterettigheder. Matricerne skal til enhver tid holdes opdaterede, så de altid afspejler virkeligheden. Rettighedstabellerne kan ændres ved konstruktion af nye funktioner/transaktioner, ændrede funktioner eller nye forretningsmæssige behov. Der vil uvilkårligt ske ændringer, både som følge af udvikling af ny funktionalitet og som følge af forretningens ønsker om tilpasning af roller og arbejdsfunktioner. 4.5 Kontroller Rollerettighedsmatricerne og adgangstildelingen revideres årligt. Chefer skal på halvårlig basis dokumentere at de har kontrolleret at de roller som deres medarbejdere har fået tildelt er korrekte og givet i overensstemmelse med retningslinjerne. Leverandøren vil blive bedt om at kontrollere at de IT roller som deres medarbejdere har fået tildelt er korrekte og givet i overensstemmelse med ATP s retningslinjer. Bilag 3A Behovsopgørelse Side 22 af 77

24 4.6 Forretningsroller Der er på nuværende tidspunkt identificeret et behov for nedenstående forretningsroller. Rollerne er ordnet i en matrix, der angiver hvilke pakker af informationer fra pensionsområdets informationsmodel, de skal have adgang til henholdsvis at oprette (C), læse (R), opdatere og slette (CRUD). Leverandøren skal selv definere IT rollerne. I Etape II skal leverandøren, som en del af Delleverancerne, i samarbejde med ATP udspecificere forretningsrollernes adgang til informationer på klasse- og attributniveau og mappe dem til IT-rollerne. Bilag 3A Behovsopgørelse Side 23 af 77

25 Rolle /inf. PensionInputGrundoplysning Udbetaling PensionUdgåendedokument PensionSystemadministration PensionBeregningsmotor PensionYdelsesType PensionsSag PensionSkatteberegningskomponent PensionValidering PensionKontrol PensionYdelse PensionPart Løsningsspecialist R R R R R R R R R R R R CRUD CRUD CRUD CRUD CRUD R R R R R R R R R R R R Afstemning R R R R R R R R R R R R Økonomi R R R R R R R R R R R R Direktions-klage R R R R R R R R Intern revision R R R R R R R R R R R R Jurist R R CRUD R R R CRUD R R R R R Sektionschef R R CRUD CRUD R R CRUD R R R R R Sektionschef i HOK R R R R R R R R R R R R Centerdirektør R R R R R R R R R R R R Forespørger R R R R R R R R R R R Kunderådgiver CRUD R CRUD R R R CRUD R R R R R Kunderådgiver HOK R R R R R R R R R R R R Superbruger CRUD R CRUD CRUD R R CRUD R R R R R Superbruger HOK R R R R R R R R R R R R CRUD R CRUD CRUD R R CRUD R R R R R R R R R R R R R R R R R VIP rolle CRUD R CRUD R R R CRUD R R R R R Postadministrator R R CRUD R R R R R R R R R Journal-medarbejder R R CRUD R GO-LIVE rolle CRUD R CRUD CRUD R R CRUD R R R R R Forretningsadministrator Rapporteringmedarbejder Udbetalingsmedarbejder Administrator sikkerhed Posthåndteringsleverandør CRUD R R Bilag 3A Behovsopgørelse Side 24 af 77

26 5 Forretningsprocesser Her en beskrivelse af de processer, som indgår i Pensionsløsningen, herunder hvordan processerne er beskrevet i aktivitetsbeskrivelser, som knyttes til informationsmodeller, lovgivning samt regel- og beslutningsmodeller. For en detaljeret beskrivelse af forretningsprocesserne og de forskellige niveauer henvises til bilag 3A.2 Løsningsflow mens den metodemæssige tilgang til forretningsmodellering i ATP er beskrevet i bilag 2A (Sådan forretningsmodellerer vi i ATP). 5.1 Samlet procesoverblik Procesoverblikket i figur 5 markeret med viser samtlige forretningsmæssige processer, der benyttes i den samlede administration af pension. ATP har udarbejdet et fuldt proceskatalog for Udbetaling Danmark. Kerneprocesser er nedenfor markeret med rødt, mens samtlige tværgående processer er markeret med grønt: Figur 4 Procesoverblik med markering af kerne- og tværgående processer Bilag 3A Behovsopgørelse Side 25 af 77

27 Her det fulde procesoverblik: Figur 5 Samlet procesoverblik 5.2 Kerneprocesser Kernerprocesserne beskriver hvordan Udbetaling Danmark indberetter, administrerer og udbetaler pension. Kerneprocesserne er nedbrudt i Løsningsflow, som er yderligere beskrevet nedenfor Kerneproces - Håndter indberetning Processen håndterer overordnet set udsendelse af orienteringsbrev samt modtagelse af ansøgning eller tilkendelse om henholdsvis folkepension og førtidspension fra borger, kommune eller udenlandsk myndighed. Bilag 3A Behovsopgørelse Side 26 af 77

28 Løsningsflow, Opret sag Løsningsflow Opret sag beskriver, hvordan pensionssagsprocessen initieres. Formålet med dette løsningsflow er i hovedtræk at vurdere hvilke sager, der er oprettet, hvilke der skal oprettes. For folkepension gælder, at der automatisk indhentes information om hvilke borgere, der har bopæl i Danmark og snart når pensionsalderen. Tidspunktet, for hvornår denne udsøgning af kommende folkepensionister foretages, skal kunne justeres løbende. Da der ikke skal kunne oprettes to pensionssager på samme borger, skal systemet automatisk kontrollere for eksisterende pensionssag. Typisk vil en eksisterende sag være en førtidspensionssag, men det kan også være en sag, der er oprettet idet en borger allerede har søgt folkepension via selvbetjeningsløsningen. Hvis det drejer sig om en allerede eksisterende førtidspensionssag, opdateres denne til folkepension fra måneden efter at borgeren opnår pensionsalderen. Hvis ikke der allerede findes en pensionssag, udsendes automatisk orienteringsbrev til de borgerer, der snart når folkepensionsalderen. Der udsendes sådanne orienteringsbreve til kommende pensionister månedligt. For førtidspension er det kommunen, der træffer afgørelse i sager om bevilling af pension. Oprettelsen af en pensionssag i Udbetaling Danmark sker derfor som følge af, at kommunen sender besked til Udbetaling Danmark om, at de har bevilget pension og fra hvilken dato, udbetalingen skal påbegyndes. På baggrund af denne første henvendelse fra kommunen skal systemet kunne foretage en validering af, om førtidspensionssagen skal sendes til manuel behandling, eller den kan oprettes automatisk. Kriterier for manuel behandling skal kunne ændres, men vil typisk være indikationer på udenlandsophold, flygtningestatus og eller svage borgere med særlige behov. I de tilfælde, hvor sagen kan valideres i det automatiske flow, sendes automatisk brev med anmodning om at borger indgiver relevante oplysninger på baggrund af hvilke den kommende pensionsudbetaling skal beregnes. En væsentlig forskel mellem opstart af henholdsvis folkepension og førtidspension er, at i tilfælde af førtidspension, er der fra kommunen truffet afgørelse om pensionsretten. Omvendt er det udelukkende borgerens alder der indikerer overfor Udbetaling Danmark, om det kunne være relevant at søge folkepension. Udbetaling Danmark skal derfor ved ansøgning om folkepension, hvor der ikke i forvejen er en pensionssag, vurdere pensionsretten. Systemet skal i videst muligt omfang kunne automatisere denne vurdering, der hvor relevante og afgørende oplysninger kan trækkes fra andre systemer eller indgives via selvbetjeningsløsningen, og derpå valideres af fagsystemet. Bilag 3A Behovsopgørelse Side 27 af 77

29 For begge sagstyper gælder det, at der skal sendes automatisk brev til borgeren om at indberette relevante oplysninger. Endvidere skal systemet kunne generere en automatisk opfølgning på, om borger har henvendt sig. Borger kan i princippet henvende sig ad forskellige kanaler; telefonisk, skriftligt eller via de digitale selvbetjeningsløsninger. Personer, der er bosiddende i udlandet, initierer selv processen for sagsoprettelsen. Dette sker i form af en ansøgning om enten førtidspension eller folkepension til Udbetaling Danmark. Ansøgningen kan komme enten fra person selv eller fra en myndighed i det land person bor i Løsningsflow, Udfyld indberetning Løsningsflow udfyld indberetning beskriver processen for ansøgning om folkepension og processen for afgivelse af oplysninger for beregning af førtidspension. Flowet fastlægger samtidig, hvordan systemet understøtter borgerens mulighed for såvel simulering af berettigelse af pension (hvad og hvor meget) samt simulering af hvordan kommende udbetalinger kan ændre sig. Desuden skal systemet kunne foretage en vurdering af fordelagtigheden ved at udskyde folkepensionen frem for at få den udbetalt straks ved berettigelsestidspunktet. Borgere skal kunne tilgå selvbetjeningsløsningen både direkte via borger.dk og via links i de breve, borgeren har modtaget fra Udbetaling Danmark. Det skal således være muligt at klikke sig direkte til den del af selvbetjeningsløsningen, der er målrettet borgerens situation. Når en borger via selvbetjeningsløsningen vælger at ansøge om folkepension eller at afgive oplysninger til beregning af førtidspension, skal systemet guide borgeren. Der er et fastlagt regelsæt for hvem, der har mulighed for at ansøge om folkepension, og dermed hvilke borgere, der skal kunne logge på selvbetjeningsløsningen. Kriterierne, for hvornår systemet automatisk skal fortsætte og oprette en sag, og hvornår borgeren skal afvises i selvbetjeningen, skal kunne ændres af forretningsadministrationen. Når en borger opfylder kriterierne for at ansøge, skal systemet understøtte, at borgerens samtykke til at indhente de nødvendige oplysninger om samlivs- og bopælsforhold samt økonomiske forhold fra autoritative registre indhentes. Borgerens samtykke er en forudsætning for, at ansøgningsprocessen kan fortsætte. Ved manglende accept skal borgeren gøres opmærksom på, at det ligestilles Bilag 3A Behovsopgørelse Side 28 af 77

30 med frasigelse af pension. Borgeren skal herpå bekræfte frasigelse af pensionen eller have mulighed for at give samtykke. Gives samtykke til indhentning af samlivs og bopælsoplysninger trækkes oplysninger om borgerens adresse, hvem der i øvrigt bor på adressen, ægteskabsforhold samt bopælsperioder i Danmark og personens statsborgerskab. Oplysningerne analyseres af systemet i forhold til, om der er forhold, der kunne give anledning til ønsket uddybning. Det kunne være adresse-sammenfald med andre personer over 18 år med hvem borgeren kan indgå ægteskab eller med tidligere ægtefæller eller det kunne være ægtefæller, personen ikke umiddelbart deler adresse med. Er der anledning til forhold der skal belyses skal borgeren dirigeres til at afgive yderligere oplysninger. Gives der som udgangspunkt ikke samtykke til, at Udbetaling Danmark kan indhente bopæls og samlivsoplysninger dirigeres personen til selv at oplyse disse forhold i selvbetjeningsløsningen. De nødvendige oplysninger om borgerens økonomiske forhold fremkommer ved borgerens egen indtastning samt ved automatisk indhentning fra SKAT. Sidstnævnte oplysninger præsenteres for borgeren (til godkendelse). Økonomiske oplysninger om borgerens ægtefælle/samlever skal samtidig angives af borgeren med mindre at ægtefælle/samlever er pensionist. Hvor ansøgning om folkepension udelukkende bevilges fremadrettet, kan tilkendelse at førtidspension ske med tilbagevirkende kraft. Dette medfører, at der her ofte opstår perioder med dobbelt forsørgelse. I disse tilfælde skal systemet kunne modregne tidligere udbetalte sociale ydelser i efterbetalingen af førtidspension. Det er kommunen der oplyser hvilket beløb der skal modregnes i pensionen. Ved såvel ansøgning om folkepension samt beregning af førtidspension skal der kunne vedhæftes dokumentation. Inden afslutningen skal borgeren endvidere have mulighed for at vælge mellem at gemme indberetningen som kladde på egen PC med henblik på senere afsendelse og eventuel redigering, eller at afsende indberetning/ansøgningen med det samme Kerneproces - Træf afgørelse Processen håndterer overordnet set modtagelse af data i systemet, validering af disse med henblik på at træffe en afgørelse, som kan være en bevilling eller et afslag. Bilag 3A Behovsopgørelse Side 29 af 77

31 Løsningsflow, Træf afgørelse Processen initieres når en borger har afgivet oplysninger eller sendt ansøgning via den digitale selvbetjening og er afsluttet når, der er truffet afgørelse i sagen. Det kan dreje sig enten om indkomne oplysninger jf. afsnit , svar på partshøringer og agterskrivelser eller ansøgninger om varmetillæg, der er modtaget på et senere tidspunkt end umiddelbart i forbindelse med sagsopstarten. Systemet skal understøtte, at indkomne data - udefrakommende eller interne hændelser - lagres, og at der logges med oplysninger om dato og tid for hvornår, de konkrete data er modtaget i systemet. Ved en borgers indberetning via selvbetjeningen skal der automatisk sendes kvittering til borgeren, hvor det fremgår, hvad der er indberettet og hvornår. Uagtet hvilken type data der er indkommet, skal systemet kunne validere oplysningerne for at afgøre hvorvidt der er behov for manual behandling eller om der skal foretages yderligere kontrol af eventuelle uoverensstemmelser. Denne form for validering skal finde sted hver gang systemet modtager eller trækker nye oplysninger. For at der kan skabes den mest effektive og automatiserede afgørelsesproces er det afgørende, at systemet i videst muligt omfang henter de oplysninger, der er nødvendige for at kunne foretage valideringen af data og derpå træffe afgørelse i sagen. Kriterierne, for hvordan data skal valideres og hvilke oplysninger, der skal ligge til grund for valideringen, skal kunne reguleres løbende af forretningsadministrationen. Ligeledes skal kriterierne for hvornår sager trækkes ud til manuel behandling løbende kunne reguleres af forretningsadministrationen. Drejer det sig eksempelvis om en ansøgning om varmetillæg skal der automatiskforetages opslag i Boligstøttesystemet. Dette da, beregningen af varmetillæg er afhængig af, om der er bevilget boligstøtte. Såfremt data kan valides umiddelbart skal systemet sende en automatisk afgørelse til borgeren. Dette uagtet om der er tale om et afslag eller en bevilling. Samtidig skal systemet kunne vurdere hvilke oplysninger vedrørende sagen, der skal gøres tilgængelige for andre og for hvem Kerneproces - Håndter løbende ændringer Processen håndterer, hvordan systemet skal validere ændringer til eksisterende sager. Beskrivelsen er opdelt i tre situationer: De situationer hvor borger selv indberetter ændringer via selvbetjeningsløsningen; de situationer hvor Udbetaling Danmark modtager oplysninger fra anden myndighed, her tænkes primært på pen- Bilag 3A Behovsopgørelse Side 30 af 77

32 sionssager hvor person har bopæl i udlandet; og det forhold at systemet skal abonnere på meddelelser fra eksterne registre med henblik på at foregribe ændringer af betydning for udbetalingen Løsningsflow, Håndter løbende ændringer person Løsningsflow håndter løbende ændringer person beskriver retningslinjerne for, hvordan systemet skal håndtere, at en borger meddeler ændringer til eksisterende sag eller søger om tillægsydelser til eksisterende sag. For borgere med bopæl i Danmark vil sådanne ændringsmeddelelser omhandle varmetillæg, samlivsændringer, og for folkepensionisterne formueændringer eller start/stop af udskudt pension. For personer med bopæl i udlandet vil der desuden komme indberetninger af indkomstforhold, svar på leveattester, kontooplysninger samt ansøgninger om personlige tillæg herunder bistandsplejetillæg. For denne personkreds vil dog gælde, at mange henvendelser sker via fysisk post til Udbetaling Danmark. Generelt skal systemet understøtte validering af de oplyste nye data. Systemet skal kunne trække relevante informationer fra relevante eksterne registre med henblik på validering. Herefter skal systemet kunne vurdere, om der eventuelt er behov for ekstra kontrolforanstaltninger, eller om data er af en sådan karakter, at de umiddelbart kan anvendes. Vurderes det at data kan implementeres, skal sagen ændres i henhold hertil. Alternativt skal sag trækkes ud til manuel behandling, og systemet skal kunne generere en sag til kunderådgiveren. Ændres og godkendes nye data i systemet, skal systemet vurdere hvilke oplysninger, der skal gøres tilgængelige for andre og for hvem jf. i øvrigt proces i afsnit Løsningsflow, Håndter løbende ændring myndighed Beskriver processen, når en udenlandsk myndighed retter henvendelse til Udbetaling Danmark med nye informationer til en sag eller, at borger bosiddende i udlandet henvender sig med ændringer eller ny data i en given sag. Udenlandske myndigheder kommunikerer primært via fysisk post og blanketter, hvorfor denne type sager hovedsagligt behandles manuelt. Fagsystemet skal dog understøtte at data registreres korrekt således, at kunderådgiver kan trække data ud og behandle og indberette manuelt i systemet. Bilag 3A Behovsopgørelse Side 31 af 77

33 Såfremt personer bosiddende i udlandet har Nem id, kan de søge og indberette ændringer via selvbetjeningsløsningen, dette vil dog fortsat dreje sig om et mindre tal. Kommer der digitale henvendelser, skal systemet kunne validere data på lige fod som i de nationale pensionssager. Det skal kunne vurderes om sagen kan afgøres umiddelbart, eller om den skal trækkes ud til manuel behandling. Systemmæssigt ligner processen på dette punkt afsnit Systemet skal endvidere understøtte manuel behandling af henvendelse via fysisk post og telefon. Som i de nationale sager kan henvendelser dreje sig om flytninger og samlivsændringer samt ændring af indkomst/formueforhold. Kommer henvendelsen fra udenlandsk myndighed, vil den desuden kunne indeholde oplysninger om dødsfald/leveattester. Vi vil af denne kanal endvidere modtage henvendelse om udenlandske kontonumre, som fagsystemet skal kunne udbetale til. Endvidere skal systemet kunne modtage meddelelser om tilkendt udenlandsk pension til personer bosiddende i Danmark Løsningsflow, Håndter indgående automatisk genererede hændelser Beskriver hvordan ændringer og meddelelser fra eksterne registrer modtages, og hvordan disse valideres og behandles gennem systemet. Automatisk genererede meddelelser er meddelelser som systemet abonnerer på. Det kan være data fra forskudsopgørelsen, ændrede årsopgørelser, formueoplysninger i forbindelse med beregning og udbetaling af ældrechecks eller træk af skattekort ved løbende ændringer af skattekort eller ved opstart af sag. Omfanget og karakteren af disse meddelelser skal kunne justeres løbende. De automatiske meddelelser har til hensigt løbende at sikre en korrekt udbetaling og dermed korrekt beregning af pension og tillægsydelser. På den anden side drejer det sig om meddelelser, sendt til Udbetaling Danmark fra kommunen. I disse tilfælde kan det dreje sig om ændringer i status på førtidspension såsom om den gøres hvilende eller bliver frakendt, anmodninger om beregning af pension til huslejebetaling i forbindelse med fængslingssager, orientering om udenlandsophold og anmodning om stop/start af administration af en pensionssag. I forhold til validering af indkommet data og udtræk af data til manuel behandling, skal systemet agere på samme måde, som ved andre typer af data input. Systemet skal dog i forhold til automatisk genererede hændelser kunne håndtere og undgå dobbelt behandling af data. Idet en stor mængde af de automatiske hændelser er nogen forretningen selv rekvirerer, vil der være tilfælde, hvor samme data er indkommet af anden kanal, det kan være via selvbetjeningsløsningen, som fysisk post Bilag 3A Behovsopgørelse Side 32 af 77

34 eller via telefonen. Systemet skal derfor i denne proces kunne validere hændelsen i forhold til om den indeholder data, der allerede er modtaget og evt. behandlet via anden kanal Kerneproces Håndter drift Processen håndterer omregning af ydelser og årlig kontrol af tre forhold: 1) beskæftigelseskravet i forbindelse med udskudt pension, 2) at personer, der modtager pension i udlandet, fortsat er i live og berettiget og 3) årlig kontrol af, at vi har de nødvendige oplysninger for fortsat at beregne varmetillæg til de borgere, der modtager dette. I forhold til omregning drejer det sig om løbende genberegning af ydelserne primært set i forhold til løbende ændrede forskudsopgørelser og siden årlig regulering af seneste kalenderårs udbetaling dette på baggrund af SKAT s årsopgørelser Løsningsflow, Vurder økonomisk effektueringsplan Beskriver, hvordan data, der medfører en revurdering af udbetalingen af pension, skal behandles. Hændelserne indeholder, blandt andet, data skabt af månedlige kontroller mellem fagsystemets indkomstoplysninger år til dato og forskudsopgørelsen. Hver måned sammenholdes anvendt beregningsgrundlag med forskudsindberetningen til skat. Er der ændringer i forskudsindberetningen, skal pensionssagen omregnes i forhold hertil. Systemet skal sammenholde anvendt indkomstgrundlag fra forskudsopgørelsen med oplysninger om faktiske udbetalinger til person i det elektroniske indkomstregister. Formålet herved er at kunne sende advarselsbreve til borgeren, når det faktisk indtjente beløb nærmer sig det forskudsregistrerede. Skrivelsen til person skal opfordre person til at ændre forskudsregistreringen i forhold til reel forventet indkomst. Reagerer borgeren ikke på advarselsbrevet, sendes rykkerbrev. Sker der stadig ingen ændring i forskudsregistreringen og indkomsten fortsætter med at stige over det forskudsregistrerede niveau, skal fagsystemet omregne sagen måned for måned i forhold til den opsummerede indkomst. Data der medfører forandring i udbetaling kan også være også automatisk genererede oplysninger om, at en førtidspensionist har nået folkepensionsalderen, og at pensionssagen derfor overgår fra udbetaling af førtidspension til udbetaling af folkepension. Da overgang er aldersbetinget, kan denne proces håndteres automatisk i systemet, og person orienteres herefter om den nye udbetaling. Bilag 3A Behovsopgørelse Side 33 af 77

35 Uanset oprindelsen på nye oplysninger skal disse valideres i forhold til, om de umiddelbart kan anvendes til beregning af pensionen, eller om sagen skal trækkes ud til manuel behandling. Er der tale om omregning af pension, skal systemet lave en ny udbetalingsberegning fra den efterfølgende første, såfremt omregningen vedrører indeværende år. Såfremt det ikke er muligt at indeholde det fulde krav i resten af indeværende år, eller der er tale om omregning af tidligere år sendes kravet til opkrævningen Løsningsflow, Håndter satsregulering Beskriver den årlige regulering af satserne for de enkelte pensionsbestanddele. Hvert år modtager forretningen oplysning fra Social og Integrationsministeriet om de nye satser. Systemet skal understøtte, at de nye satser kan indtastes og godkendes af forretningsadministrator. Der skal kunne foretages prøvekørsler i systemet, og systemet skal årligt genberegne pensionssagerne i forhold til de nye satser. Herefter skal systemet sende automatisk orientering til borger om kommende års beregning og forventede udbetaling. Der skal endvidere sendes orientering til SKAT med de enkelte personers forventede pensionsudbetalinger i det kommende år med henblik på, at SKAT kan lave korrekte forskudsopgørelser Løsningsflow, Håndter årlig regulering Beskriver den årlige regulering af seneste kalenderårs pension. For borgere med bopæl i Danmark og udbetalt pension sker reguleringen, når SKAT s årsopgørelse af seneste kalenderår er færdig. For hovedparten af sagerne vil reguleringen falde omkring maj måned, men for de borgere og deres samlevere/ægtefæller, der har selvstændig virksomhed, vil reguleringen finde sted lidt senere på året. Systemet skal som udgangspunkt sammenholde den af SKAT udfærdigede årsopgørelse med det grundlag, som fagsystemet har anvendt til beregning af pension. Er der udsving, skal sagen trækkes ud til regulering og omregning. I videst muligt omfang skal validering og omregning ske automatisk i systemet. Der, hvor det ikke er muligt, skal sagen trækkes ud til manuel behandling. Umiddelbart vil dette dog fortrinsvis omfatte selvstændige og herunder i særdeleshed uklarheder i forbindelse med passiv og aktiv drift. Systemet skal automatisk på fastlagte tidspunkter i løbet af året trække diverse kontrollister ud fra hvilke, de forskellige kontroller udføres. Bilag 3A Behovsopgørelse Side 34 af 77

36 Løsningsflow, Udfør årlig kontrol af udskudt pension Beskriver, hvordan systemet kontrollerer, om personer med udskudt pension i det seneste kalenderår har opfyldt beskæftigelseskravet. For borgere med bopæl i Danmark, der har valgt at udskyde deres pensionsudbetaling, skal det årligt kontrolleres, at de inden for senest afsluttede kalenderår opfyldte beskæftigelseskravet. Hvis dette er tilfældet skal opsætning for afsluttet kalenderår godkendes og borger skal orienteres om, hvor mange måneder borgeren fortsat kan have sin pension opsat. Oplysninger om udførte antal arbejdstimer registreres for lønmodtagernes vedkommende i KMD indkomst. For selvstændige kan dokumentation af beskæftigelseskravet primært ske via en erklæring fra person. Disse skal derfor ved tvivl tilsendes borger. Opfyldes beskæftigelseskravet ikke, skal systemet vurdere muligheden for udbetaling af engangsbeløb, til vurderingen anvendes årsopgørelsens tal. Engangsbeløb udgøres af den pension borgeren kunne have fået hvis pensionen ikke havde været udskudt. Engangsbeløbet beregnes på baggrund af de faktiske indtægter borgeren havde under perioden, det er skatte pligtigt og udbetales uden venteprocent idet pensionen for så vidt stadig er udskudt. Som med efter reguleringen af de udbetalte pensioner kontrolleres udskudte pensioner af to omgange afhængigt af hvornår deres årsopgørelse er tilgængelig Løsningsflow, Udfør årlig kontrol af leveattester Beskriver, hvordan det hvert år kontrolleres, at de personer der har bopæl i udlandet men modtager dansk pension fortsat er i live. Systemet skal derfor med fast interval en gang årligt udsende leveattester til personer i udlandet. Personer, der bor i lande, der indgår i aftalen om elektronisk dataudveksling, er undtaget fra dette. Systemet skal kunne identificere de sager, hvor personen ved en tidligere lejlighed har logget ind med nem id. I disse tilfælde skal systemet tilskrive personen digitalt, mens de resterende personer skal tilskrives via fysisk post. Systemet skal formå at kontrollere om leveattesterne er kommet retur til Udbetaling Danmark Løsningsflow, Udfør årlig kontrol af varmeregnskaber Beskriver det forhold, at fagsystemet skal kontrollere, om der foreligger tilstrækkelige oplysninger til fortsat at udbetale varmetillæg eller om person skal tilskrives. Varmetillæg beregnes på baggrund af et gennemsnitsforbrug på 3 fortløbende varmeregnskabsår. I en opstartsfase kan varmetillæg udbetales på baggrund af aconto varmeudgift eller 1 eller 2 varmeregnskabsår. Disse sager skal systemet trække løbende ud til kontrol og samtidige anmode borgeren om at indsende næ- Bilag 3A Behovsopgørelse Side 35 af 77

37 ste varmeregnskab. Tre måneder efter varmeregnskabsåret slutter skal borgeren indsende varmeopgørelsen. Systemet skal automatisk udsøge de sager, der ikke har et treårigt grundlag, sende anmodning og efterfølgende følge op på de sager, hvor vi modtager den nødvendige dokumentation. Modtages der ikke dokumentationen træffes automatisk en afgørelse om, at udbetalingen skal stoppes Løsningflow, Håndter udbetaling Beskriver processen omkring formidlingen af udbetaling af pension til borger eller myndighed herunder modregning af eventuelle krav og bogføringsopgaver. Pension udbetales månedligt på den sidste hverdag. Før pensionen sendes til udbetaling, skal evt. modregninger fradrages. Modregninger kommer til dels fra kommunen, der kan anmode om at serviceydelser og tilbagebetaling af tillæg skal modregnes inden udbetaling. Til dels kommer modregningsanmodningerne fra opkrævningssystemet og kan indeholde krav fra de forskellige ydelsesområder i Udbetaling Danmark. Efter modregning er foretaget, skal systemet kvittere for at krav er indeholdt. Når systemet har udregnet beløb til udbetaling, skal systemet sikre, at der sendes besked til eindkomst med oplysning om udbetaling til person. Systemet skal understøtte, at kunderådgiverne kan lave manuelle korrektioner til udbetalingerne, og at der kan udbetales til specifik konto. Det vil sige, at en person har mulighed for at henvende sig til Udbetaling Danmark, og få sin udbetaling sendt til en alternativ konto til NemKonto. Det skal sikres, at der også fremover således kan udbetales til en specifik anden konto. Når den endelige pensionsudbetaling er opgjort og klar til afsendelse, skal systemet til dels generere en meddelelse til person, og til dels skal systemet sikre en korrekt bogføring i ATP ERP. Meddelelsen om den nye beregnede pensionsudbetaling skal dog kun genereres i de sager, hvor der er udsving i forhold til seneste udbetaling. Som udgangspunkt skal bogføring ske, når sag er afgjort og udbetalingsprocessen iværksat. Der skal med fastsatte frekvenser trækkes korrekte udbetaling og afstemningsoplysninger fra både udbetalingssystem og fagsystem til borføring Løsningsflow, Håndter opkrævning Beskriver hvordan et tilbagebetalingskrav formidles videre til opkrævning, og hvordan selve kravet bogføres efter, at det er opgjort i systemet. Bilag 3A Behovsopgørelse Side 36 af 77

38 Krav der medfører efterfølgende opkrævning vil typisk opstå i forbindelse med den årlige omregning af pensionen. Når årsopgørelsen for de enkelte personer er færdiggjort i SKAT skal systemet opgøre, om der er for meget udbetalte ydelser og behandle disse som krav med efterfølgende opkrævning. Uanset om kravet kræves tilbagebetalt eller ej, skal kravet sendes til opkrævningssystemet og bogføres i regnskabssystemet. De data som systemet skal sende til opkrævningssystemet skal indeholde informationer om kravets art og størrelse samt person id på den person, kravet skal stilles til. Samtidig sendes afstemnings oplysninger til bogføring. Er der således foretaget omregning med skattemæssige implikationer, skal systemet endvidere understøtte, at der sendes besked til SKAT om omregnet indkomst og A-skat. Omregninger i løbet af et kalenderår håndteres umiddelbart ved omregning af resten af årets pension. Således vil der i denne situation ikke opstå et regulært krav med opkrævning til følge jf. i øvrigt punkt Alle løsningsflow indeholder et antal aktiviteter. Hver aktivitet har en tilknyttet aktivitetsbeskrivelse, som indeholder de konkrete krav til systemet. Dette er beskrevet nærmere i bilag 3A.2 Procesbeskrivelser. Bilag 3A Behovsopgørelse Side 37 af 77

39 6 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 rapporter 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 hele Udbetaling Danmarks forretning set ude fra. Niveauet under den overordnede begrebsmodel er begrebsmodeller for hver af de sagstyper som vi håndterer, en generisk begrebsmodel for det generelle Sagsbegreb samt 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. 6.1 Overordnet begrebsmodel for Udbetaling Danmark Udbetaling Danmark behandler forskellige typer af sager for omverdenen, som set i den overordnede begrebsmodel, se Figur 6. Udbetaling Danmark administrerer og udbetaler økonomiske ydelser til personer eller virksomheder. Ydelserne kan være af typen barselsdagpenge, refusion til virksomhed, pension, boligstøtte, 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 38 af 77

40 Figur 6: Overordnet begrebsmodel for Udbetaling Danmark 6.2 Begrebs- og informationsmodeller for Forretningsløsningen Begrebs- og Informationsmodeller er forretningens modeller over de væsentligste begreber, som Forretningsløsningen 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: Pension Sag. Det er valgt at udelade Begrebsmodellerne i udbudsmaterialet idet Informationsmodellerne giver den tilstrækkelige information til leverandøren Dokumentation til leverandør Informationsmodellerne er detaljeret beskrevet i bilag 3A.4, både i diagramform og i rapportform hvor diagrammer, logiske samhørende enheder, begreber og attributter er beskrevet med definition, kildehenvisning og relevante kommentarer. Bilag 3A Behovsopgørelse Side 39 af 77

41 Systemet er beskrevet i: Informationsmodel Pension Informationsmodel Sag Derudover er informationsmodellen for Beriget Grunddata vedlagt, idet den viser hvilke informationer, der er til rådighed i Forretningsløsningen for Person, Virksomhed og Myndighed. Den metodemæssige tilgang til begrebs- og informationsmodellering i ATP er beskrevet i bilag 2A (Sådan forretningsmodellerer vi i ATP). 6.3 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 Sag er defineret i den fællesoffentlige OIO standard Specifikation af serviceinterface for sag sådan: Sag forstås som en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces, typisk til administrative formål, herunder til at træffe afgørelser. En sag består af et antal dokumenter, der vedrører det samme begivenhedsforløb. Et dokument kan indgå i flere sager, dvs. have relation til flere begivenhedsforløb Udbetaling Danmark har valgt at definere en sag sådan: En sag er en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces, typisk til administrative formål, herunder til at træffe afgørelser Udbetaling Danmarks sagsbegreb betyder at en person/virksomhed/myndighed har én sag i et ydelsesområde, som dækker hele forløbet for vedkommende. Undtagelsen fra denne regel er klagesager, hvis en part klager over sin sag oprettes der en klagesag med relation til den oprindelige sag, så en sag kan godt have relateret en eller flere klagesager i et ydelsesområde. Bilag 3A Behovsopgørelse Side 40 af 77

42 Vi samler dokumenter, data, information om en afgrænset arbejdsproces i en Sag. Sagen er således en digital hængemappe for dokumentation og en sag kan fremsøges ved hjælp af forskellige nøgler, som identificerer denne Sag - Nøgler og Egenskaber Udbetaling Danmarks sag er modelleret efter OIO Specifikation for Sag version 1.2 og har dermed følgende nøgler: Beskrivelse Værdisæt Obl. Betegnelse Primær nøgle, en teknisk nøgle som er unik UUID ja Sag ID Brugervendt identifikation, der er unik inden Tekst Ja BrugervendtNøgle for myndigheden. Frit sagsnummer Tekst Ja Sagsnummer Officiel sagstitel, der kan anvendes i forbindelse Tekst Ja Titel med å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 2: Nøgler for "Sag" Sagen har også en række generelle egenskaber: Beskrivelse Værdisæt Obl. Betegnelse Henvisning til hjemmel fx lov og for sagens behandling. Angives, hvis der er truffet beslutning om undtagelse fra offentligheden. Værdisættet består af de to følgende elementer. Alternativ sagstitel der kan anvendes i forbindelse med lukkede dagsordenspunkter, som skal vises på åbne dagsordener samt i forbindelse med postlister. Tekstuel henvisning til lovhjemmel, der anvendes som grundlag for beslutning om undtagelse fra offentligheden. Tekst Nej Hjemmel OffentlighedUndtaget Nej OffentlighedUndtaget Tekst Nej AlternativTitel Tekst Nej Hjemmel Bilag 3A Behovsopgørelse Side 41 af 77

43 Beskrivelse Værdisæt Obl. Betegnelse Indikator for om sagen er udnævnt som principsag. Kassationskode, der styrer varighed før kassation. Er afleveret til Statens Arkiver/ 7 arkiv. Nej/Ja Nej Principiel Tekst Ja Kassationskode Nej/Ja Nej Afleveret Tabel 3: Generelle egenskaber for "Sag" De generelle attributter, som dækker alle sagstyper, nedarves, og hver sagstype har yderligere attributter, som er specifikke for typen Sagens oprettelse og livsforløb Vi har valgt, at en sag oprettes ved den første henvendelse fra en person/virksomhed/myndighed om udbetaling af en ydelse. Sagen sluttes først, når alle relevante ydelser knyttet til denne, er udbetalt, eller, når en given berettigelsesperiode for ydelsen er udløbet. Det betyder, at sager, hos os, kan være meget langvarige. en pensionssag løber over hele pensionsperioden, både førtidspension og folkepension, indtil dødsfald fx år eller mere. Sagen ændrer tilstand i løbet af sin levetid: Beskrivelse Værdisæt Obl. Betegnelse Sagens forretningsmæssige fremdrift i forhold til behandling Noget kræver myndighedens ageren. Sagen er i proces med en oplysning Der er truffet afgørelse om sagen, fx bevilling eller afslag Sagsbehandling er fuldført Opstået Under Oplysning Afgjort Afsluttet Fremdrift Tabel 4: Tilstande for "Sag " Sagens tilstand kan skifte frem og tilbage mellem de forskellige værdisæt i løbet af levetiden Part Hver Udbetaling Danmark sag har én part tilknyttet og vi har derfor ikke behov for begreberne primær og sekundær part. En part er en person, virksomhed eller myndighed. En part har ret til aktindsigt i sin egen sag. Bilag 3A Behovsopgørelse Side 42 af 77

44 6.3.3 Sagsdokumentation Fagsystemerne har ansvaret for sagen gennem hele sagens levetid fra oprettelsen, over ændringer på sagen, til sagen sluttes. Det er fagsystemets ansvar at sørge for at vedligeholde sagsindeks, dokumentindeks og ydelsesindeks samt rettidig synkronisering, således at indeksene til en hver tid afspejler fagsystemet. Det er ligeledes fagsystemets ansvar at vedligeholde data alt hvad der vedrører sagen, journalnotater, beskeder, digitale henvendelser, scannende dokumenter samt journalisering af henvendelser. 6.4 Informationsmodel Pension Informationsmodellen for pension indeholder pensionsbegreber og deres relationer. Begreberne er grupperet i logiske enheder, hvor de vigtigste er Pensionsag, PensionsinputGrundoplysninger, Pensionsydelsestype, Pensionsydelse, Udbetaling og Pensionsystemadministration. Pensionssag. Disse beskrives kort nedenfor Pensionssag En pensionssag opstår når vi modtager en ansøgning om pension, eller når en person ønsker at gemme simulerede data fra Borger.dk eller hvis en udenlandsk myndighed henvender sig. Pensionssagen lukkes først når personen dør eller af andre årsager mister retten til pensionsydelse Forskelle til sagsbegreb i Eksisterende Løsning Pension nuværende løsning For dansk pension er der ingen forskel på sagsbegrebet i den nuværende og den fremtidige løsning. En ydelsesansøgende pensionist/førtidspensionist får en sag som følger vedkommende i hele pensionsforløbet. Udenlandsk pension, nuværende IPOS system, her anvender man enkeltsagsprincippet, hvor hver ny afgørelse om fx et tillæg registreres i en ny sag. Pension, ny løsning I det nye pensionssystem hvor udenlandsk og dansk pension er samlet vil vi følge den nuværende danske løsning hvor en ydelsesansøgende pensionist/førtidspensionist får en sag som følger vedkommende i hele pensionsforløbet. Det nye sagsbegreb vil reducere antallet af sager for udenlandsk pension væsentligt, men vil ikke ændre det nuværende sagsbegreb for dansk pension. Bilag 3A Behovsopgørelse Side 43 af 77

45 6.4.2 Pensionsinputgrundoplysning Grundoplysninger er oplysninger til brug for pensionssag, oplysningerne fås fra andre myndigheder, indtastet af kunderådgiver eller via ansøgers selvbetjening Pensionsydelsestype Pensionssystemets ydelsestyper opdelt i hovedtyper og undertyper: Førtidspension med Undertyper: International og national Folkepension med Undertyper: International og national Tillæg med Undertyper: Ældrecheck, Helbredstillæg, Varmetillæg, Ventetillæg, Personligt tillæg Pensionsydelse Samling af de effektueringsbegreber, der skal til for at danne en udbetaling/opkrævning, og som skal danne grundlag for dataafsendelse til YdelsesIndeks Udbetaling Udbetalingspakken indeholder informationer for hver udbetaling og opkrævning Pensionssystemadministration Begreber som anvendes i forbindelse med planlægning af kunderådgivernes opgaver og til rapportering til den daglige driftledelse. Bilag 3A Behovsopgørelse Side 44 af 77

46 7 IT arkitektur Dette kapitel præsenterer: 1. IT-udbudsarkitekturen. Her præsenteres hvilke it-systemer, der skal indgå i den forretningsløsning, som skal være etableret på Overtagelsesdagen 2. System kontekst. Her præsenteres integrationer, der skal etableres fra Systemet. 3. Integrations-infrastrukturen. Her beskrives overordnet den tekniske infrastruktur omkring integrationerne. 7.1 IT-udbudsarkitekturen I det følgende præsenteres hvilke it-systemer, der skal indgå i den 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 it-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 Systemet, således at det fulde omfang af snitflader klarlægges. I modsætning til forretningsarkitekturen beskriver IT-arkitekturen ikke den interne opbygning af fagsystemet og selvbetjeningsløsningen. Den interne IT-arkitektur for fagsystem og selvbetjeningsløsning skal derimod beskrives af Tilbudsgiver i Bilag 3B Løsningsbeskrivelse. IT-udbudsarkitekturen vil være en transitionsarkitektur i forhold til 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, og dels ved at der i løsningen indgår en række af de eksisterende it-systemer fra KMD, som er nødvendige, så længe andre af Udbetaling Danmarks ydelsesområder fortsat understøttes af disse. Der vil således i IT-udbudsarkitekturen indgå en række eksisterende IT-systemer fra KMD, som kun skal benyttes i en periode frem til den endelige IT-målarkitektur kan realiseres. 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 45 af 77

47 Figur 7: IT-udbudsarkitekturen for Forretningsløsningen for administration af Pension. Bilag 3A Behovsopgørelse Side 46 af 77

48 Fagsystemer Systemet er det centrale system i IT-udbudsarkitekturen og det andet fagsystem, der bliver konkurrenceudsat af ATP (efter Barsel-fagsystemet). De øvrige ydelsesområder under Udbetaling Danmark vil fortsat benytte fagsystemer fra KMD på tidspunktet for ibrugtagning af Systemet. Opkrævning vil foregå i KMD Opus Debitor, og via dette system håndteres eventuelle opkrævninger, herunder administration af betalingsaftaler, hvor der er beløb, der skal modregnes i pensionen. Midlertidige systemer Som nævnt vil der skulle benyttes en række KMD systemer i en midlertidig periode. Til at effektuere udbetalinger anvendes KMD Udbetaling, mens hent af indkomstoplysninger fra både årsopgørelsen og forskudsopgørelsen håndteres via KMD Indkomst. Opkrævning af kommunernes andel af visse ydelser håndteres via KMD KMF (Kommunal MedFinansiering). KMD Sag vil være indirekte i brug, idet de øvrige ydelsesområder under Udbetaling Danmark fortsat vil anvende KMD Sag til at få et tværgående sags- og ydelsesoverblik på tværs af både Udbetaling Danmarks og kommunernes ydelsesområder. KMD Sag skal derfor vedligeholdes med også pensionssager. Dette vedligehold vil ske indirekte via den synkronisering af sags- og ydelsesoplysninger mellem KMD Sag og de fælleskommunale støttesystemer, som etableres af KOMBIT. Endelig vil KMD Social Pension fortsat være i anvendelse af kommunerne til visse kommunale ydelser, og dette skal understøttes af pensionsfagsystemet. Interne tværgående støttesystemer Til levering af person- og virksomhedsoplysninger skal benyttes et Beriget Grunddata-system, som etableres til brug 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. Beriget Grunddata vil blive anvendt frem til den fællesoffentlige grunddatafordeler er på plads. 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 Pension. Systemerne er også afbildet på IT-målarkitekturen i bilag 3 (Leverancebeskrivelse), og de præsenteres kort her. Pensionssystemet udveksler data med kommunerne på en række områder. Det mest centrale system er Kommunernes Ydelsessystem, hvormed der skal udveks- Bilag 3A Behovsopgørelse Side 47 af 77

49 les oplysninger, som har betydning for pensionsudbetalingerne og de kommunale tillægsydelser. Fra kommunerne indsendes derudover oplysninger om kommunale træk i pensionen, og disse oplysninger kommer ind via en fælles Kommunale trækkomponent. Derudover leverer pensionssystemet data til økonomiopfølgning for kommunerne i FLIS. Herudover leverer Systemet også data til en lang række parter: Til brug for statistik m.m. leveres data til hhv. Danmarks Statistik, Arbejdsmarkedsstyrelsen (AMS) og Ministeriet for Børn, Ligestilling, Integration og Sociale forhold (BLIS). Derudover leveres forskellige oplysninger om pensioniststatus og/eller ydelser til DR, pensionsbranchen, SKAT, SKAT s ejendomsværdisystem, KMD Boliglån og KMD Struktura. NETS benyttes til betaling af bidrag til supplerende arbejdsmarkedspension i andre selskaber end ATP. Endelig benyttes Huslejeregisteret til hent af oplysninger om aconto varmebeløb. Alle øvrige områder af IT-udbudsarkitekturen er som beskrevet i IT-målarkitekturen i bilag 3 (Leverancebeskrivelse). 7.2 System kontekst og integrationer Nedenfor præsenteres systemkonteksten for Systemet. Hvor IT-udbudsarkitekturdiagrammet siger noget om hvilke systemer, der samlet set indgår i Forretningsløsningen, men ikke noget om hvordan de er forbundet, illustrerer systemkonteksten hvilke systemer, der skal integreres til fra Systemet. Systemkonteksten holdes på logisk niveau, og infrastruktur-komponenter såsom servicebrokere er derfor ikke medtaget her. Disse infrastrukturkomponenter beskrives i stedet i afsnit 7.4 Integrationer og infrastruktur. På system kontekst diagrammet er hver integration tildelt et ID ud fra mønsteret IntegrationsID = <ydelsesområdeforkortelse P ><3-bogstavs systemforkortelse><fortløbende nr.>. Fra aktivitetsbeskrivelser og fra krav er der refereret til integrationsid et. Systemkonteksten er illustreret på Fejl! Henvisningskilde ikke fundet.. Bilag 3A Behovsopgørelse Side 48 af 77

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. 7.3 Transitionsarkitektur For at understøtte den trinvise udfasning af KMD Social Pension skal der etableres en mekanisme som sikre, at forespørgslen behandles uagtet i hvilket system sagen administreres. Til dette formål skal der etablere en flette-/fordeler mekanisme hvis opgave det er, at dirigere kaldet til det system som anvendes for den pågældende kommune. Flette-/fordeleren er beskrevet i bilag 3A.6 (Integrationer), hvor også alle itsystemer som skal håndteres særskilt er listet. Bilag 3A Behovsopgørelse Side 49 af 77

51 Alle integrationerne er listet i den følgende tabel. Integrationspart IntegrationsID Integrationsnavn ATP-systemer ATP ERP PERP1 Posteringer til ERP ATP Afstemning PAAF1 Afstemningsdata til ATP ATP Datawarehouse PDWH1 Data til datawarehouse ATP idm & idp PIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM PIDP1 Login via ATP s IdP Udbetaling Danmark-systemer & eksterne services Posthåndteringsleverandør PPHL1 Modtag indgående post (PHL) PPHL2 Send post til genjournalisering Beriget Grunddata PBGD1 Hent person fra Beriget Grunddata KMD systemer KMD Udbetaling PKUD1 Udbetalingsanmodninger til KMD Udbetaling KMD KMF PKMF1 Træk af kommunal medfinansiering KMD Opus Debitor PKOD1 Modregning i pensionen PKOD2 Opret betalingsaftale KMD Indkomst PKIK1 Indkomstoplysninger fra årsopgørelsen og forskudsopgørelsen PKIK2 Advisering om ændringer til årsopgørelsen og forskudsopgørelsen KMD BYS PBYS1 Oplysning om en borger er pensionist KMD Boliglån PBOL1 Oplysning om en borger er pensionist KMD Struktura PSTU1 Oplysning om en borger er pensionist KMD Boligstøtte PKBO1 Oplysning om en borger er pensionist PKBO2 Hent kompensationsbeløb fra boligstøtte Eksterne systemer Danmarks Radio PDRA1 Levering af oplysninger til DR Nets PNET1 Overfør supplerende arbejdsmarkeds pensions-bidrag Fælleskommunale systemer Bilag 3A Behovsopgørelse Side 50 af 77

52 Integrationspart IntegrationsID Integrationsnavn FLIS PLIS1 Data til FLIS Sags- og dokumentindeks PSDI1 Udstil oplysninger i Sags- og dokumentindeks PSDI2 Hent oplysninger fra Sags- og dokumentindeks Ydelsesindeks PYDI1 Udstil oplysninger i Ydelsesindeks PYDI2 Hent oplysninger fra Ydelsesindeks KY PADM1 Pensionsudbetalinger på borgere under administration PNLK1 Persondata til vurdering af helbredstillæget Kommunernes Sygedagpengesystem PKSD1 Oplysning om en borger er pensionist (KSD) Kommunale træk PKOT1 Træk af kommunale fradrag i pensionen Fællesoffentlige systemer PensionsInfo PPIN1 Hent basis pensionsoplysninger PPIN2 Beregn pension Borger.dk PBOR1 Visuel integration i Borger.dk NemLogin PNLO1 Login til selvbetjening via NemLog-in Digital Fuldmagt PFUL1 Hent oplysninger om digital fuldmagt Fjernprint PFPR1 Send besked via Fjernprint SKAT eindkomst PSKE1 Rekvirer eskattekort fra eindkomst PSKE2 Indberet til eindkomst PSKE3 Hent indkomstoplysninger fra eindkomst SKAT Forskud PSKF2 Indberet forventet udbetaling til forskudsopgørelsen CSC SKAT PSKA1 Indberet årets skattefrie beløb til SKAT SKAT EVS (Ejen- domsværdi- Skattesystem) PEVS1 Oplys om førtidspensionister m.m. til SKAT EVS Bilag 3A Behovsopgørelse Side 51 af 77

53 Integrationspart IntegrationsID Integrationsnavn Danmarks Statistik PDST1 Levering af oplysninger til Danmarks Statistik Ministeriet for Børn, PBLI1 Levering af oplysninger til BLIS Ligestilling, Integration og Sociale forhold (BLIS) Pensionsbranchen PPEB1 Førtidspensionsoplysninger til Pensionsbranchen ArbejdsMarkeds- PAMS1 Levering af oplysninger til AMS Styrelsen (AMS) Huslejeregister PHUS1 Hent acontobeløb for varme Statens Arkiver PSTA1 Aflever til Statens Arkiver Transitions-snitflader Flette-/fordeleren PFEL1?? KMD Social Pension PKSP1?? Tabel 5 Systemets integrationer En detaljeret beskrivelse af hver integration er at finde i bilag 3A.6 (Integrationer). Da de tilstødende systemerne 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 komponenter ikke er afhængige af den konkrete implementering af en anden komponent, men kun den systemgrænseflade, komponenten udstiller. De konkrete krav til integrationer fremgår af bilag 3A.1 (Kravliste). 7.4 Integrationer og infrastruktur Alle integrationer fra Systemet til andre systemer er som udgangspunkt point-topoint, hvor det er Leverandørens ansvar at etablere integrationen fra Systemet til den anden part i integrationen, samt levere den nødvendige infrastruktur til integrationen. Der er dog typer af systemer, hvor integrationsprincippet er anderledes, og hvor nedenstående integrationsinfrastruktur kommer i spil. System Beskrivelse Bilag 3A Behovsopgørelse Side 52 af 77

54 System ATP Integrationsplatform, EKKO Den fælleskommunale Serviceplatform Den fælleskommunale Beskedfordeler Beskrivelse ATP-IT integrationsplatform som benyttes til integration mellem ATP s interne systemer samt til al integration mellem ATP s interne systemer og eksterne parter. Integrationsplatformen understøtter mange forskellige former for kommunikation, herunder både online services og batch overførsler. Integrationsplatformen vedligeholdes af ATP-IT. Integrationsplatformen skal benyttes til al dataudveksling mellem Systemet og ATP-interne systemer. Se mere om ATP s integrationsplatform i bilag 3A.6a Produkt- og snitfladebeskrivelser/atp Integrationsplatform Produktbeskrivelse v1.0.pdf. En støttekomponent i den fælleskommunale rammearkitektur. Serviceplatformen er en integrationsplatform, som kan udstille data fra forskellige kildesystemer og funktionalitet fra forskellige systemer. Serviceplatformen administreres af KOMBIT. Støttesystemer leveret af KOMBIT kan blive udstillet via Serviceplatformen. Ligesom KOMBIT s Fagsystemer vil kunne blive udstillet på Serviceplatformen. Det vil fremgå af dokumentationen til det enkelte system, om det udstilles på Serviceplatformen. Se mere om Serviceplatformen på Beskedfordeleren er en støttekomponent i den fælleskommunale rammearkitektur, som understøtter modtagelse og distribution af hændelser til alle abonnerende systemer. Beskedfordeleren er endnu ikke etableret, men er sat i udbud af KOMBIT. Hændelsesudveksling med systemer leveret af KOMBIT vil skulle ske via Beskedfordeleren. Brugen af Beskedfordeleren vil fremgå af dokumentationen til henholdsvis støttesystemer og fagsystemer. Se mere om den fælleskommunale beskedfordeler i bilag 3A.6a Produkt- og snitfladebeskrivelser/rasts integrationsvilkår/bilag 3. Vilkår for integration til støttesystemet Beskedfordeler.pdf Leverandøren skal benytte den integrationsmetodik og -platform, som serviceudbyderen stiller til rådighed. Bilag 3A Behovsopgørelse Side 53 af 77

55 8 Non-funktionelle krav til Systemet Ud over de funktionelle krav til Systemet i Bilag 03A.1 Kravliste har ATP en række non-funktionelle krav til Systemet. Disse non-funktionelle krav er inddelt i en række kravgrupper, som gennemgås i de følgende underafsnit. Kravgrupperingen anvendt i dette bilag anvendes også i bilag 3A.1 (Kravliste) og i bilag 3B (Løsningsbeskrivelse), således at der er samme struktur i de tre bilag. 8.1 Arkitektur ATP har en række krav til de overordnede rammer for Løsningen. Disse krav fremgår af bilag 3A.1 (Kravliste), og kravene angiver ligeledes de arkitektoniske afgrænsninger, som Løsningen 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 har Leverandøren i bilag 3B (Løsningsbeskrivelse) indsat en besvarelse på udvalgte cases, der omhandler fiktive, men dog realistiske, ændringer til Systemet. Leverandørens besvarelse af disse cases afspejler endvidere Leverandørens estimerings- og projektledelsesmetoder, således at besvarelsen vil udgøre fundamentet for alle de faktiske ændringer til Systemet, der vil blive gennemført efter kontraktindgåelse Belastning og skalering Systemet skal være fleksibelt opbygget, således at en stigende belastning kan håndteres Telefonopkald ATP modtager xx indgående telefonopkald pr år jævnt fordelt henover året som er relateret til specifikke pensionssager. ATP modtager xx indgående telefonopkald pr år jævnt fordelt henover året, som er relateret til generel vejledning om pension. ATP foretager xx udgående telefonopkald pr år jævnt fordelt henover året. ATP modtager xx indgående telefonopkald pr år jævnt fordelt henover året som er relateret til kviklinjen, som fx Borgerservice benytter. Bilag 3A Behovsopgørelse Side 54 af 77

56 I peak modtager ATP xx indgående telefonopkald pr time relateret til administration af pension. I gennemsnit modtager ATP xx indgående telefonopkald pr time relateret til administration af pension Breve ATP udsender xx maskinelle breve pr år jævnt fordelt henover året som er relateret til administration af pension. ATP udsender xx manuelle breve pr år jævnt fordelt henover året som er relateret til administration af pension. ATP modtager xx manuelle breve pr år jævnt fordelt henover året som er relateret til administration af pension. Af Bilag 03A.8 Oversigter fremgår antallet og de enkelte varianter, som i dag er i brug for pensionsområdet Blanketter (yderligere underretningsbreve) ATP modtager i dag xx blanketter pr år jævnt fordelt henover året som er relateret til administration af pension. ATP udsender i dag xx blanketter pr år jævnt fordelt henover året som er relateret til administration af pension. Det forventes at xx % af disse fortsat vil blive modtaget/udsendt som blanketter på papir Digital Post ATP modtager xx s og digital post pr år jævnt fordelt henover året som er relateret til administration af pension. ATP udsender xx s og digital post pr år jævnt fordelt henover året som er relateret til administration af pension. 8.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 55 af 77

57 8.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, fx 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. 8.4 Driftsstyring Kravområde driftsstyring dækker ATP s krav til hvordan driften af Systemet skal håndteres. Driftsstyring involverer flere forskellige områder: Fejlstyring Her findes kravene, som skal sikre at processen, der understøtter at fejl bliver rettet, kan etableres og gennemføres. Ændringshåndtering Her findes kravene, som skal sikre at processen, der understøtter at ændringer bliver implementeret, kan etableres og gennemføres. Konfigurationsstyring Her findes kravene, som skal sikre, at processerne, der understøtter styring af hvilke versioner af software, applikationer, konfigurationer etc., der eksisterer og er installeret i de forskellige miljøer, kan etableres og gennemføres. Processerne skal sikre integritet og sporbarhed både i udviklings- og driftsfaserne. 8.5 Tilgængelighed ATP ønsker et driftsstabilt System med høj grad af tilgængelighed og lave svartider. Kravene til tilgængelighed i bilag 3A.1 (Kravliste) fastsætter sammen med servicemålene i bilag 7 (Servicemål). 8.6 Datakonvertering Dette afsnit fastsætter de overordnede vilkår for konvertering af data fra den Eksisterende Løsning til Systemet. Bilag 3A Behovsopgørelse Side 56 af 77

58 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 og støttesystemer Konverteringskonceptet generelt Konverteringsstrategien for pensionssystemet er følgende; der gennemføres et antal konverteringer hvor en kommune konverteres af gangen, når kommunen er overgået til ny pensionsløsning tages ny pensionsløsning i brug på den pågældende kommune. Trinet gennemføres et antal gange indtil ATP og Leverandøren vurdere at det er forsvarligt at gennemføre konverteringen af rest bestanden. Alle data fra KMD Social Pension og øvrige KMD systemer, som indeholder information vedrørende pension ydelsesområdet, vil blive trukket ud i separate filer. Der dannes forventelig en fil pr. tabel, relationerne mellem filer vil fremgå af den medfølgende dokumentation. 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 49. Bilag 3A Behovsopgørelse Side 57 af 77

59 Figur 4 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, både fagsystemer og støttesystemer. Der er således flere systemer, som indeholder data, der er relateret til en Pensionssag. Udtræk af data fra Eksisterende Løsning gennemføres af KMD. Transformering: Leverandøren skal gennemføre transformering af data, samt stille de fornødne værktøjer til rådighed herfor. Indlæsning og validering af data: Leverandøren skal indlæse, validere og afstemme data i Systemet. Leverandøren er endvidere ansvarlig for at videredistribuere de fornødne data til øvrige støttesystemer, hvori der skal loades eller konverteres data. Aktiviteterne under Udtræk, Transformering, Indlæsning og validering uddybes nærmere i de følgende afsnit. Leverandørens metode for transformering, indlæsning og validering vil fremgå af Leverandørens konverteringsstrategi. Bilag 3A Behovsopgørelse Side 58 af 77

60 8.6.2 Udtræk af data KMD leverer fuldt udtræk af alle de data fra KMD-systemer, som kan tænkes at skulle bruges i den nye løsning. Data udtrækkes som filer og placeres på en FTPserver. Udtræk af data fra Eksisterende Løsning omfatter: Fagsystemdata fra KMD Social Pension. For KMD Social pension vil data omfatte både afsluttede og igangværende sager, samt eventuelt tilknyttede opgaver. Generelle sagsdata fra KMD Sag vedrørende pensionssager. Dette inkluderer journalnotater og dokumentmetadata for tilknyttede dokumenter. Dokumenter fra KMD Sag EDH og KMD doc2archive. Detaljeret beskrivelse af data og udtræksformat findes i bilag 2B (Eksisterende data). KMD s ydelser i forhold til udtræk af data fra Eksisterende Løsning er overordnet følgende: Leverer detaljeret design og dokumentation af udtrækket Bidrager til forståelse af eksisterende data via dataforståelsesworkshops Udtrækker data fra systemerne i det format, der er overordnet beskrevet i bilag 2B (Eksisterende data). Data leveres i den kvalitet, de har i systemerne. Bidrager til den tværgående test af konverteringen, herunder leverer et prøveudtræk af produktionsdata. Bidrager til cut-over plan (ansvarlig for de aktiviteter, der skal foregå på KMD s side) Leverancerne er yderligere beskrevet i udfasningsassistance kravspecifikation og kravbesvarelse, som kan ses her: 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 2.2.X Udveksling af dataudtræk ( 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 (se Dette skal ske på tidspunktet for modtagelse af prøveudtræk fra KMD og skal ske ved indlæsning Bilag 3A Behovsopgørelse Side 59 af 77

61 af de modtagne data i en relationel database. 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 og transformere de data, som skal indlæses i Systemet i forbindelse med overgangen. Det vil bl.a. sige, at data ensrettes ny begrebsmodel (se afsnit 6) med særligt fokus på, at sager transformeres fra gammelt til nyt sagsbegreb (se afsnit 6.3). Leverandøren skal indledningsvist, gennem deltagelse i workshops med KMD, opbygge den dataforståelse som skal til, for at gennemføre den efterfølgende konvertering. Leverandøren er ansvarlig for, at mapning af data fra den Eksisterende Løsning til Systemet sker korrekt ud fra de af KMD og ATP leverede databeskrivelser. ATP bidrager med forretningskendskab til data. Leverandøren skal i den forbindelse facilitere de workshops, som er nødvendige, for i samarbejde med ATP, at kunne mappe data fra den Eksisterende Løsning til det nye System. Leverandøren skal levere en beskrivelse af transformationen og data mapningen på informationsmodel-niveau, som skal godkendes af ATP. Tranformeringen af data skal kunne håndtere data, som de ser ud fra Eksisterende Løsning, og som det vil fremgå af den detaljerede dokumentation, der leveres af KMD. Datakvaliteten forventes overordnet at være god, da der primært er tale om data fra et nyere fagsystem. ATP har ansvaret i tilfælde af, at der skal rettes op på data i Eksisterende Løsning. Leverandøren skal sikre, at der etableres fuldt transaktionsspor over datatransformeringen og den efterfølgende indlæsning af data i Systemet. Nødvendigt værktøj og programmel til transformering af data udvikles/stilles til rådighed af Leverandøren 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, således at data er konsistente på tværs af Systemet og støttesystemer, og data i de fornødne støttesystemer afspejler det ændrede sagsbegreb. Bilag 3A Behovsopgørelse Side 60 af 77

62 Indlæsning af data i Systemet Leverandøren skal indlæse tilstrækkelige 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 hvor de slap. Afsluttede sager fra Eksisterende Løsning skal kunne genberegnes. Der skal være adgang til dokumenter og journalnotater på sagerne. Selvbetjeningsløsningen skal have de fornødne data til rådighed; Kassations- og arkiveringsprocesserne skal virke for alle indlæste data. Bemærk at konfigurationsdata og adviser 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, og dette skal 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 fiktivt cpr-nr. skal oprettes i Beriget Grunddata, eventuelt ved manuel indtastning. Der skal oprettes de nødvendige abonnementer på person- og virksomhedsdata og hentes/modtages de fornødne data fra Beriget Grunddata. SKAT Der skal oprettes abonnementer på og hentes de fornødne skattekort. Sags- og dokumentindeks Alle aktive sager skal oprettes i sags- og dokumentindeks med tilknyttede dokumenter og journalnotater. Dataene vil herfra blive synkroniseret over i KMD Sag via den sædvanlige mekanisme til synkronisering mellem indekses og KMD Sag. Ydelsesindeks Bevillinger og de sidste 3 måneders udbetalinger skal oprettes i ydelsesindeks. Bilag 3A Behovsopgørelse Side 61 af 77

63 ATP Datawarehouse Datawarehouse skal modtage et initielt load af alle data. Data skal leveres i samme format som i de daglige dataleverancer se integrationsbeskrivelse PDWH1 i bilag 3A.6 (Integrationer). KMD Sag Når alle data er indlæst i Sags- og dokumentindeks og Ydelsesindeks, og alle sager efter det nye sagsbegreb - 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. Indhold og format aftales i Afklaringsetapen Afstemning og datavalidering Leverandøren skal udvikle automatiseringsrutiner til afstemning af data. Kriterier for afstemningerne skal udarbejdes i samarbejde med og formelt godkendes af ATP i forbindelse med Afklaringsetapen som en del af den endelige fastlæggelse af konverteringsstrategien. Kriterier for datavalidering og efterfølgende godkendelse, opsættes i samarbejde mellem ATP og Leverandøren i forbindelse med mapning af data fra Eksisterende Løsning til Systemet. Leverandøren skal som minimum gennemføre: Afstemning efter flytning af KMD dataudtræk til relationel database, som bevis for at alle relevante data er flyttet 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 det nye System. Afstemning efter populering 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. Afstemning op mod afstemningsdata leveret fra KMD. Beløbsafstemning på laveste niveau uden ubegrundede afvigelser. Ad-hoc afstemning og kontroller, som skal gøres tilgængelige for ATP Bestandsafstemning og sumkontroller uden ubegrundede afvigelser. Validering af transformeringen, herunder særligt af sagsbegrebet, som sikrer at der ikke sker data tab eller forvanskning af data ved overgangen til det nye System. Bilag 3A Behovsopgørelse Side 62 af 77

64 Alle felter med parametre eller kodeværdier (f.eks. 01 = virksomhed, 02 = person m.m.) skal dokumenteres konverteret korrekt. Evt. ved stikprøve kontrol. Alle numeriske felter skal dokumenteres konverteret korrekt (evt. med nonsens-totaler). 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 afstemningsrapporter som dokumentation for afstemning af data inklusiv dokumentation/forklaring af evt. afvigelser, samt redegøre for påkrævede handlinger for opsamling af afvigelser. Afstemningsrapporterne skal formelt godkendes af ATP Gennemførsel af konverteringen 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 måde, som forstyrrer daglig drift så lidt som muligt. Leverandøren skal udarbejde en konverteringsdrejebog, der som minimum beskriver, hvilke aktiviteter der skal finde sted hvornår, afhængigheder mellem aktiviteterne, verifikationspunkter, fallback-plan og fastlæggelse af lukkevinduer. Konverteringsdrejebogen skal godkendes af ATP. Det nødvendige lukkevindue for at kunne gennemføre konverteringen skal være så lille som muligt og skal helst placeres uden for kritisk forretningstid, jf. bilag 7 (Servicemål). Hvis der er aktiviteter, der gennemføres inden for kritisk forretningstid, skal der så vidt muligt fortsat være læseadgang til data Håndtering af prøveudtræk Til brug for afprøvning af konverteringsprogrammellet vil der fra KMD blive leveret et prøveudtræk af data fra den Eksisterende Løsning. Der vil være tale om et fuldt udtræk af umaskerede produktionsdata; dog vil der kun være indeholdt et begrænset antal dokumenter. 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. Dette indebærer at Leverandøren skal etablere mekanismer til udtræk af delmængder af data fra prøveudtrækket, samt mekanismer til nødvendig maskering/anonymisering af dataene fra prøveudtrækket. Bilag 3A Behovsopgørelse Side 63 af 77

65 8.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 fx drejer sig ergonomi, den visuelle oplevelse, skærmbilledeopbygning, hvordan man navigerer rundt i applikationen og hvilke hjælpemidler der skal stilles til rådighed for handikappede. 8.8 Lovgivning ATP ønsker at 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 kan overholdes. Kravene til dette fremgår af bilag 3A.1 (Kravliste). Det påhviler ATP at identificere og foretage de nødvendige fortolkninger af relevante dele af ATP-specifik lovgivning (fx Loven om social pension, ATP-loven og Udbetaling Danmark Loven) samt omsætte disse til krav til Systemet. Leverandøren skal på ATP s anmodning deltage i dette arbejde efter bedste evne. 8.9 Sikkerhed IT sikkerhed handler om at sikre konfidentielt, integritet, og tilgængelighed af information imod forskellige sikkerhedsrisici. Dette behov skal sikres ved at indarbejde forskellige kontroller både i designet af Systemet, men også 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 øvrige interne såvel som eksterne miljøer til brug for udvikling, test og uddannelse. Til brug for afprøvningerne, beskrevet i bilag 6 (Afprøvninger), vil der være behov for et internt testmiljø, et eksternt testmiljø, et præproduktionsmiljø og så selve produktionsmiljøet. Kravene til de forskellige miljøer vil fremgå af bilag 3A.1 (Kravliste) 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 Bilag 3A Behovsopgørelse Side 64 af 77

66 Leverandøren er ansvarlig for gennemførelsen af projektledelsesaktiviteter som f.eks. 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 opsætning, konfigurering og tilpasning af Systemet ATP s undervisere skal uddannes, således at de er i stand til at uddanne øvrige brugere af Systemet ( train-the-trainer -princippet). De konkrete krav til uddannelse fremgår af bilag 3A.1 Kravliste Dokumentation ATP ønsker en fyldestgørende dokumentation af Systemet, herunder den efterfølgende drift og vedligeholdelse. Leverandøren skal sikre, at ATP til enhver tid har adgang til opdateret og detaljeret dokumentation, der gør ATP i stand til at opnå 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. Den del af dokumentationen, der falder uden for Leverandørens ansvarsområde, jf. bilag 4 Dokumentation og programmel, skal som hovedregel udarbejdes og vedligeholdes af ATP. Leverandøren er dog ansvarlig for at assistere ATP med udarbejdelsen, kvalitetssikringen og vedligeholdelsen af denne dokumentation. De konkrete krav til Leverandøren i forhold til dokumentation fremgår af bilag 3A.1 Kravliste og bilag 4 Dokumentation og programmel 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, f.eks. ved en minimering af nedetid. Leveran- Bilag 3A Behovsopgørelse Side 65 af 77

67 døren skal have et særligt fokus på første gang funktionalitet idriftsættes og første gang jobs i Systemet afvikles. I disse situationer skal Leverandøren 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. 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 lokation 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 ATP s øvrige fag- og støttesystemer, hvilket betyder at Leverandøren skal 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 Afprøvninger ATP ønsker et funktionelt, driftsstabilt og brugervenligt System, der lever op til arkitekturprincipperne jf. bilag 3 Leverancebeskrivelse. ATP anser Afprøvninger for at være væsentlige kilder til at opnå dette, hvorfor Afprøvninger har høj prioritet. En forudsætning for en succesfuld proces i forhold til Bilag 3A Behovsopgørelse Side 66 af 77

68 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 avendes 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 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 67 af 77

69 9 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 her beskrevne tilpasninger skal gennemføres. 9.1 Hent indkomstoplysninger udenom KMD Indkomst I IT-udbudsarkitekturen anvendes KMD Indkomst til at hente indkomstoplysninger fra henholdsvis SKAT s forskudsopgørelse og SKAT s årsopgørelse. KMD Indkomst optræder ikke i IT-målarkitekturen, og der skal derfor ske en tilpasning af Systemet, så indkomstoplysninger hentes andet steds fra formodentlig direkte fra kilden, men det ligger endnu ikke fast. 9.2 Integration til andet udbetalingssystem Anvendelsen af KMD Udbetaling til at gennemføre udbetalingerne af ydelser og refusion er en midlertidig løsning. Hvis ATP ikke vælger at gøre brug af optionen på integration direkte til NemKonto, skal der i stedet skiftes til et andet udbetalingssystem på et senere tidspunkt. Bilag 3A Behovsopgørelse Side 68 af 77

70 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 bilag og bilag 7B.1 (Kravliste) indeholder kravene til Leverandørens Ydelser. Et overblik over Ydelserne fremgår af nedenstående figur: Kundens opgaver Leverandørens ydelser Enterprise-arkitektur Kontraktstyring Brugersupport Etablering Vedligehold Videreudvikling Drift Rådgivning Dokumentation Sikkerhed Overvågning Optioner Figur 5 Kundens opgaver og Leverandørens ydelser 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 69 af 77

71 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 (Test og Prøver). 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 Ydelseslokationer, 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 Ydelseslokationer, Leverandøren vil benytte sig af i forbindelse med leveringen af Ydelserne. Leverandøren etablerer endvidere kommunikationsinfrastruktur mellem Leverandørens egne lokationer, 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 for driftsafvikling og support Leverandøren forbereder og etablerer samtlige Servicedesk-procedurer, herunder IT Service Management værktøjer til understøttelse for supportprocesserne og integration mellem ATP s og andre relevante leverandørers IT Service Management værktøjer. Integrationen skal omfatte integration til alle discipliner i Service management, herunder Problem-, Incident-, Configuration-, Event- og Change management Etablering af processer og værktøjer til vedligeholdelse af Systemet Leverandøren skal etablere processer til vedligehold af Systemet, herunder processer til fejlfinding, rettelse af fejl og samarbejde med ATP. Desuden skal Leve- Bilag 3A Behovsopgørelse Side 70 af 77

72 randø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 71 af 77

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

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

75 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) Tabel 7 Definition af videreudvikling Løbende Drift Lokaliteter Leverandøren varetager den løbende vedligeholdelse af Ydelseslokationer, 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 m.v. Leverandøren skal ligeledes løbende orientere ATP om eventuelle optimeringsmuligheder jf. Kontraktens punkt 6.3 Rådgivningspligt Teknologisk rådgivning, rapportering og support Leverandøren er ansvarlig for teknologisk rådgivning i forhold til Ydelserne Kontraktens punkt 6.3 Rådgivningspligt. Det er endvidere Leverandørens opgave at foretage løbende rapportering, jf. bilag 8 (Samarbejdsorganisation og Rapportering), i forhold til f.eks. driftsstatus, incidents og overholdelse af Servicemål. Alle brugerrelaterede Servicedesk henvendelser håndteres af ATP som 1. level support. Alle tekniske alarmer/incidents genereret på områder, som Leverandøren har ansvaret for, håndteres af Leverandøren som 1. level support. Bilag 3A Behovsopgørelse Side 74 af 77

76 Dokumentation og konfigurationsstyring Leverandøren er ansvarlig for Dokumentation jf. bilag 4 (Dokumentation) og konfigurationsstyring og skal bl.a. vedligeholde en configuration management database (CMDB). I CMDB skal alle konfigurationselementer være sporbare, således at det bliver muligt at følge historikken på et specifikt konfigurationselement. Gennem configuration management skal der etableres Dokumentation af konfigurationer, miljøer, maskinel m.v. for at støtte service management processerne. Konfigurationsstyring skal ske i overensstemmelse med ITIL s anbefalinger til best practice. Krav til Dokumentation er endvidere beskrevet i Bilag 4 (Dokumentation) 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å punkt [54] i 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 m.v. Endelig sikrer Leverandøren backup, restore og disaster recovery 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) 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. Bilag 3A Behovsopgørelse Side 75 af 77

77 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 ITIL s anbefalinger til best practice. Forebyggelse baseret på incidents. Efter løsning af incidents, skal Leverandøren i relevant omfang, eventuelt i samarbejde med ATP s øvrige leverandører, foretage en opfølgning på processen for at sikre erfaringsopsamling, der kan forbedre fremtidige processer (proaktiv incident management) 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, fx ved at reducere eller helt forebygge incidents, i forbindelse med løbende trendanalyser, som udføres i forbindelse med ydelsen. Trendanalysen kan eksempelvis håndteres ved gennemgang af alle Incidents (både løste og uløste) for gentagne fejlmønstre og root causes 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. Bilag 3A Behovsopgørelse Side 76 af 77

78 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 m.v. for at støtte service management processerne. Konfigurationsstyring skal ske i overensstemmelse med ITIL s anbefalinger til best practice. Krav til Dokumentation er endvidere beskrevet i Bilag 4 (Dokumentation). Bilag 3A Behovsopgørelse Side 77 af 77