Bilag 3A Behovsopgørelse

Transkript

1 Bilag 3A Behovsopgørelse Version

2 Indhold 1 VEJLEDNING TIL TILBUDSGIVER INDLEDNING UNDERBILAG FORRETNINGSUDBUDSARKITEKTUR OG KOMPONENTMODEL FORRETNINGSUDBUDSARKITEKTUREN AUTOMATISERET OG MANUEL SAGSBEHANDLING KANALER OG KOMMUNIKATION ØVRIGE ELEMENTER I FORRETNINGSUDBUDSARKITEKTUREN KOMPONENTMODEL KANALER Call center & telefoni Digital Post Selvbetjening Fysisk Post MANUELT Opgaveindbakke Tværgående Overblik Sagshåndtering Manuelle Breve System Administration AUTOMATISK Validering Beskedhåndtering Udbetaling Kontrol Skatteberegning Bilag 3A Behovsopgørelse Side 1 af 79 1

3 (Gen)beregning af Ydelser Regel Administration STØTTEKOMPONENTER Borger & Virksomhedsdata Sager og dokumenter ØVRIGE KOMPONENTER Sikkerhed Rapporter Jobafvikling Økonomi Hændelser Afstemning Arkivering Indeks Synkronisering SYSTEMETS BRUGERGRÆNSEFLADER SELVBETJENINGSLØSNING FOR BORGERE BRUGERGRÆNSEFLADE TIL KUNDERÅDGIVERE Opbygning af kunderådgivernes brugergrænseflade BRUGERGRÆNSEFLADE TIL FORRETNINGSADMINISTRATORER WIREFRAMES FOR SELVBETJENINGSLØSNINGEN OG BRUGERGRÆNSEFLADE TIL KUNDERÅDGIVERE UDVIKLINGSMODEL FOR SELVBETJENINGSLØSNINGEN OG BRUGERGRÆNSEFLADE TIL KUNDERÅDGIVERE ROLLER OG RETTIGHEDER FORRETNINGSPROCESSER SAMLET PROCESOVERBLIK KERNEPROCESSER End-to-end-processer for barseldagpengeordningen LØSNINGSFLOWS FOR KERNE-PROCESSER Bilag 3A Behovsopgørelse Side 2 af 79 2

4 Udfyld indberetning, person Udfyld indberetning, virksomhed Opret/opdater ansøgning Afgør ansøgning Håndter løbende ændring person Håndter løbende ændring virksomhed Håndter indgående automatisk genererede hændelser Vurder økonomisk effektueringsplan TVÆRGÅENDE PROCESSER AKTIVITETSBESKRIVELSER REGEL- OG BESLUTNINGSMODELLER PARAMETERSTYRING OG KONFIGURERING INFORMATIONSARKITEKTUR BEGREBS- OG INFORMATIONSMODELLER BEGREBET SAG FÆLLESOFFENTLIG DEFINITION AF SAG UDBETALING DANMARK DEFINITION AF SAG SAGSEGENSKABER Nøgler og Egenskaber Sagens oprettelse og livsforløb Part SYSTEMANSVAR SAGSTYPER BARSELSSAG Referencer mellem barselssager Sagsbegreb i barsel Forskelle til sagsbegreb i Eksisterende Løsning IT ARKITEKTUR Bilag 3A Behovsopgørelse Side 3 af 79 3

5 7.1 IT-UDBUDSARKITEKTUREN SYSTEM KONTEKST OG INTEGRATIONER INTEGRATIONER OG INFRASTRUKTUR NON-FUNKTIONELLE KRAV TIL SYSTEMET ARKITEKTUR 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 DATAVALIDERING GENNEMFØRSEL AF KONVERTERINGEN HÅNDTERING AF DATAUDTRÆK OG PRØVEUDTRÆK BRUGERVENLIGHED LOVGIVNING SIKKERHED MILJØER PROJEKTLEDELSE UDDANNELSE DOKUMENTATION IDRIFTSÆTTELSE HYPERCARE SAMARBEJDE OG RAPPORTERING AFPRØVNINGER Bilag 3A Behovsopgørelse Side 4 af 79 4

6 9 FREMTIDIGE TILPASNINGER TIL SYSTEMET INDHENTELSE AF LÆGEATTESTER INTEGRATION TIL OPKRÆVNINGSSYSTEM HENT INDKOMSTOPLYSNINGER UDENOM KMD INDKOMST INTEGRATION TIL ANDET UDBETALINGSSYSTEM DIGITAL FULDMAGT KRAV TIL DRIFT, VEDLIGEHOLDELSE, SUPPORT OG VIDEREUDVIKLING (YDELSERNE) OVERORDNEDE KRAV ETABLERINGSYDELSEN ETABLERING AF LOKALITETER ETABLERING AF KOMMUNIKATIONSINFRASTRUKTUR OG RELEVANTE MILJØER 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 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 Bilag 3A Behovsopgørelse Side 5 af 79 5

7 PROBLEM MANAGEMENT CHANGE MANAGEMENT RELEASE MANAGEMENT EVENT MANAGEMENT - OVERVÅGNING CONFIGURATION MANAGEMENT PROCESBESKRIVELSERNES OPBYGNING EN LÆSEVEJLEDNING TIL UNDERBILAG PROCESBESKRIVELSERNES OPBYGNING PROCESOVERBLIKKET SÅDAN LÆSES ET LØSNINGFLOW SÅDAN LÆSES EN AKTIVITETSBESKRIVELSE SÅDAN LÆSES REGLERNE SÅDAN LÆSES BEGREBS- OG INFORMATIONSMODELLERNE SAMMENHÆNGEN TIL BILAG 3A.1 (KRAVLISTE) Bilag 3A Behovsopgørelse Side 6 af 79 6

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

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 og aktivitetsbeskrivelser - barselsspecifikke) Bilag 3A.3 (Løsningsflows og aktivitetsbeskrivelser tværgående) 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 ses i læses i sammenhæng med bilag 3A.2 Procesbeskrivelser Bilaget indeholderen de løsningsflows og aktivitetsbeskrivelser, der indgår i de forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af barseldagpenge. Bilaget indeholderen de løsningsflows og aktivitetsbeskrivelser, der indgår i de tværgående forretningsprocesser, som understøtter de barselsspecifikke forretningsprocesser. Bilaget indeholder UML modeller af de begreber og de informationer, som vedrører indberetning, administration og udbetaling af barseldagpenge. Bilaget indeholder standardiserede modeller af de regler af lovgivningsmæssig, og anden karakter forbundet med indberetning, administration og udbetaling af barseldagpenge. Bilaget indeholder uddybende information om de integrationer, som Leverandøren skal etablere fra Systemet. Bilaget indeholder rammesættende wireframes for brugergrænseflader, der har til formål at give Leverandøren inspiration til design af brugergrænsefladerne i Systemet. Bilaget indeholder følgende oversigter: Brevoversigt Kobling til lovgrundlag Krydstabulering af løsningsflow mod aktivitetsbeskrivelser for barselsspecifikke løsningsflow. Tabel 2 Behovsopgørelsen og tilhørende underbilag Bilag 3A Behovsopgørelse Side 8 af 79 8

10 3 Forretningsudbudsarkitektur og komponentmodel I dette afsnit beskrives forretningsudbudsarkitekturen som den ser ud ved implementering af nyt System. Herefter beskrives fagløsningen via en komponentmodel. 3.1 Forretningsudbudsarkitekturen Forretningsudbudsarkitekturen beskriver dels sammenhænge mellem de forskellige dele af den forretningsmæssige løsning og dels den ønskede forretningsmæssige funktionalitet, men den beskriver ikke, hvordan det enkelte konkrete it-system nødvendigvis skal indrettes. Figuren nedenfor er en viser de væsentligste elementer i forretningsudbudsarkitekturen. De enkelte elementer beskrives i efterfølgende afsnit. Figur 1: Forretningsudbudsarkitektur for Barseldagpengeordningen Den samlede forretningsmæssige løsning består af selve Fagsystemet, som er vist med blå farve. Denne del er specifik for Barselsfagsystemet, mens de øvrige dele af figuren viser samspillet med omkringliggende systemer. Bilag 3A Behovsopgørelse Side 9 af 79 9

11 De enkelte elementer beskrives overordnet i det efterfølgende Automatiseret og manuel sagsbehandling Denne del er selve Fagsystemet, hvor man finder it-understøttelse til administration af selve barseldagpengesagerne. Fagsystemet er at betragte som en hel løsning hvor både automatisering samt manuel funktionalitet er placeret. Dette betyder at en kunderådgiver for Barsel arbejder i Fagsystemet som deres primære system og kan bruge det til at løse noget nær alle deres opgaver. Fagsystemet indeholder alle de data der er behov for i forhold til 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 STP ( straight through processing ) i videst muligt omfang uden at det går ud over kvaliteten af sagsbehandlingen. Princippet er, at sagerne fødes i selvbetjeningsløsningerne og behandles så automatisk som muligt i Fagsystemet, gerne 100 %. 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 kommunikation med omverdenen. En vigtig del af løsningen er selvbetjeningsløsningerne på borger.dk og virk.dk, som skal give borgere og virksomheder nem adgang til indberetning af oplysninger, mulighed for at se oplysninger og generel vejledning Ø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 grænseflader til. De tværgående dele understøtter interne behov for rapportering, forpligtelser i forhold til ekstern rapportering og udbetaling. Bemærk, at en fuldstændig liste over integrationer findes i afsnit 7 IT arkitektur. 3.2 Komponentmodel Dette afsnit detaljerer de funktioner som Barseldagpengesystemet skal løse. Det beskrives i form af en Komponentmodel. Til forskel fra forretningsudbudsarkitekturen, så omhandler Komponentmodellen kun den fagspecifikke løsning. Bilag 3A Behovsopgørelse Side 10 af 79 1

12 Komponentmodellen viser, hvordan vi tænker Barseldagpengesystemet opdelt i forretningsmæssige logiske komponenter. Komponentmodellen og de efterfølgende komponentbeskrivelser har to formål. at give et overblik over, hvad Barseldagpengesystemet skal indeholde af funktionalitet at vise hvordan vi forretningsmæssigt, ser det opdelt fra et logisk 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. Hvis det er tilfældet, så er det vigtigt, at Leverandøren tydeliggør, hvordan løsningen samlet leverer den beskrevne funktionalitet i forhold til vores komponentmodel og beskriver sin løsning med ændringer eller andre muligheder i forhold hertil igennem besvarelsen af kravene. De komponenter, som indeholder funktionalitet, der ændres hyppigt, fx ved lov- og regelændringer skal kunne ændres smidigt. Derfor bør komponenternes funktionalitet kunne ændres igennem skærmbilleder, hvor ATP s forretningsadministratorer kan konfigurere regler og parametre. Figuren nedenfor viser komponentmodellen for Barseldagpengesystemet. Bilag 3A Behovsopgørelse Side 11 af 79 1

13 Figur 2: Komponentmodel Komponentmodellen er inddelt i fem hovedområder: Kanaler Manuelt 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 det er tænkt at Systemet skal fungere sammen med ATP s telefoni, post og selvbetjeningsløsning Call center & telefoni Indgående og udgående opkald til borgere, virksomheder og offentlige myndigheder, håndteres i ATP`s Call center agent. Der er ingen integration mellem agenten og Systemet. Bilag 3A Behovsopgørelse Side 12 af 79 1

14 Digital Post Systemet skal kunne modtage digital post fra borgere og virksomheder. Digital post vil komme fra de fællesoffentlige løsninger på Borger.dk og Virk.dk Den digitale post hentes af en posthåndteringsleverandør inden den overleveres til Systemet Selvbetjening Selvbetjening leverer en web løsning, som skal udstilles på borger.dk og viser de personlige oplysninger og eventuelle barselplan, som Udbetaling Danmark har registeret for en borger. Derudover kan man gennemføre en simulering af hvor mange barseldagpenge, man kan få udbetalt. Selvbetjening modtager indtastede data og sender disse til Systemet for validering og eventuel registrering Fysisk Post I Barseldagpengesystemet skal man kunne modtage fysisk post fra borgere og virksomheder. Fysisk post vil primært være struktureret information, som ikke kan understøttes digitalt og ustruktureret post. Den fysiske post scannes af en posthåndteringsleverandør inden den overleveres til Systemet 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 samlet i logiske arbejdspakker. En opgave kan være fysisk post, digital post og hændelser, som systemet ikke kan håndtere automatisk. En kunderådgiver skal kunne reservere og arbejde med en opgave. Hvor det er muligt skal komponenten igangsætte det automatiserede flow igen, når opgaven afsluttes. Bilag 3A Behovsopgørelse Side 13 af 79 1

15 Tværgående Overblik Barseldagpengesystemet skal kunne præsentere et Tværgående Overblik, der samler alle relevante informationer om den enkelte borger eller virksomhed. Denne komponent leverer en brugergrænseflade til et Tværgående Overblik. Formålet er at give kunderådgiveren mulighed for, ved et enkelt opslag, hurtigt at få et overblik over borgerens personlige forhold eller virksomhedens forhold. Fra det Tværgående Overblik skal kunderådgiveren have mulighed for få præsenteret yderligere detaljer om en sag og borgeren Sagshåndtering Denne komponent leverer en brugergrænseflade, hvor man kan man udføre den manuelle sagsbehandling og hvor barselsdata kan vises og redigeres Manuelle Breve Denne komponent har ansvaret for at kunne administrere og vedligeholde brevskabeloner til udsendelse af manuelle breve. 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 skabeloner System Administration Barseldagpengesystemet 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. Brugergrænsefladen skal være rettet mod brugere uden særlige tekniske forudsætninger Automatisk Denne gruppe af komponenter understøtter de sager der behandles automatisk på motorvejen Validering Denne komponent har ansvaret for at validere inputdata (en indberetning eller ændring) til brug for kontrol, afgørelse og beregning. 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 be- Bilag 3A Behovsopgørelse Side 14 af 79 1

16 slutningsregler, der er implementeret i komponenten Regel Administration. Validering udstiller services til Selvbetjening Beskedhåndtering Beskedhåndtering initierer beskedudsendelse, herunder breve og identificerer afsendelseskanal. Den indsamler informationer og genererer den maskinelle besked. Beskedhåndtering indeholder desuden en brugergrænseflade til konfigurering af beskeder. Komponenten muliggør oprettelse og vedligehold af beskedskabeloner (automatiske breve) med tilpasning og forudfyldelse af tekstblokke for alle beskedtyper Udbetaling Komponenten skal samle og overføre udbetalinger til udbetalingssystemet. Den registrerer udbetalingsdata og genererer udbetalingsfiler ligesom den producerer data til Kommunal Medfinansiering indeholdende data opdelt pr. kommune på personniveau med information om kommune, person og beløb Kontrol Kontrol behandler en ansøgning/indberetning efter Validering succesfuldt har valideret inputdata. Komponenten udfører kontrol af ansøgning/indberetning for at sikre, at ansøger retsmæssigt er berettiget til at modtage barsel/refusion. Kontrollen sker ud fra et sæt af beslutningsregler, som er defineret i Regel Administration Skatteberegning Skatteberegning foretager beregning af A-skat, ATP-bidrag 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 (Gen)beregning af Ydelser (Gen)beregning af Ydelser indeholder beregningsfunktionaliteten for alle typer af sagsforløb, herunder også de specielle som fx adoption, graviditetsrelateret sygdom, dødfødt barn og alvorligt syge børn. Komponenten træffer en afgørelse på baggrund af beskæftigelseskrav og beregner ydelsen. Herefter oprettes en barselplan på baggrund af de data som ansøgeren Bilag 3A Behovsopgørelse Side 15 af 79 1

17 har angivet. Der holdes også styr på, hvor meget der er brugt af den samlede barselsperiode, samt de forskellige orlovstyper og sørger for, at der ikke kan afholdes for meget orlov eller udbetales for meget. Beregningen baserer sig på de beslutningsregler og beslutningsparametre, der er defineret for tilkendelse og ydelsesberegning i Regel Administration Regel Administration Regel Administration indeholder de nødvendige og tilstrækkelige beregningsparametre til tilkendelse og ydelsesberegning. Komponenten leverer en brugergrænseflade til at vedligeholde regler/parametre til at udføre validering, kontrol, afgørelse (beslutning), beregning af ydelse samt skatteberegning. Derudover vedligeholdes regler for fortolkning af hændelser i Regel Administration Støttekomponenter Denne gruppe af komponenter varetager informationer om borgere og virksomheder fra autoritative registre samt sager og dokumenter Borger & Virksomhedsdata Denne komponent har ansvaret for at hente person- og virksomhedsdata fra Beriget Grunddata. Person & Virksomhedsdata udstiller disse informationer for de øvrige komponenter i systemet. Komponenten skal ligeledes vedligeholde de ydelsesspecifikke person- og virksomhedsdata fx relationer, som brugere kan opdatere igennem Barseldagpengesystemet. 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 Barseldagpengesystemet bliver alle sags- og ydelsesinformationer gemt i Sager & Dokumenter. Denne komponent er en avanceret data container, som vedligeholder metadata for sager og dokumenter og holder referencer mellem sager og mellem sager og dokumenter. Til gruppen af dokumenter hører blandt andet blanketter, breve, post, og andet bilagsmateriale som Udbetaling Danmark modtager eller selv udsender. Bilag 3A Behovsopgørelse Side 16 af 79 1

18 3.2.5 Ø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 logon forespørgsel fra hhv. Fagsystem og Selvbetjeningsløsning Rapporter Rapporter har ansvaret for, at der laves 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 på bestandsniveau. Komponenten vedligeholder regler for kørselstidspunkter og flowregler for afvikling af de automatiske kørsler Økonomi Barseldagpengesystemet overfører posteringer til ATP`s ERP system i forbindelse med udbetalinger, ændringer til udbetalinger etc. Kontonumrene fra ERP skal altid matche de kontonumre som anvendes i Systemet, så sum-posteringer etc. placeres korrekt i forbindelse med en overførsel. Systemet generer endvidere afstemningsposter, som afsendes til ATP`s ERP system. Samlet set sikrer denne dataudveksling, at regler til understøttelse af regnskabslovgivning samt gældende revisionskrav kan overholdes 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 beslutningsregler, der er gældende for den aktuelle proces. Bilag 3A Behovsopgørelse Side 17 af 79 1

19 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, samt foretager afstemning af interne dataflyt i Fagsystemet Arkivering Barseldagpengesystemet 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 Indeks Synkronisering Barseldagpengesystemet henter sags- og ydelsesinformationer fra de fælleskommunale systemer Sags- og ydelsesindeks. Systemet skal tilsvarende levere sags- og ydelsesinformationer for barselssager til de samme indeks, dels for at stille informationerne til rådighed for kommunerne men også for at kunne etablere et opdateret overblik i KMD Sag i den overgangsperiode hvor nogle af Udbetalingsordninger 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 18 af 79 1

20 4 Systemets brugergrænseflader Der findes tre typer af brugere af Systemet: 1. borgere 2. kunderådgivere 3. forretningsadministratorer Disse tre typer af brugere anvender forskellige brugergrænseflader i Systemet. De tre brugergrænseflader er beskrevet i de følgende afsnit. 4.1 Selvbetjeningsløsning for borgere For at understøtte den fællesoffentlige digitaliseringsstrategi og imødekomme borgernes behov for at forstå og overskue barseldagpengeprocessen, skal Systemet indeholde selvbetjeningsmuligheder for borgerne. Selvbetjeningsløsningen skal integreres på borger.dk. Når en arbejdsgiver har startet en barselsag, vil borgeren, som sagen vedrører, modtage underretning om, at sagen er startet (et orienteringsbrev via Digital Post). Underretningen indeholder et link hvorfra borgeren kan komme ind på selvbetjeningsløsningen. På selvbetjeningsløsningen skal borgeren kunne se: Egne og en eventuel arbejdsgivers stamdata Beregningsgrundlaget, hvilken løn (perioder og beløb) danner grundlag for fastlæggelsen af beskæftigelseskravet og beregning af dagpengesatsen Tydelig angivelse af opfyldelse af beskæftigelseskrav og hvilken dagpengesats borgeren er berettiget til Overblik over den gældende Barselplan; terminsdato, dato for barselsorlovens start og slut, evt. fødselstidspunkt (når det er indtruffet), tydelig visning af periode med løn og periode med barseldagpenge, samt hvornår og hvor meget der kommer til udbetaling. Barselplanen omfatter eget forbrug og borgerens egne, kommende udbetalinger. Af planen skal sagens anden forældre også fremgå, men kun med angivelse af forbrugte og planlagte orlovsperioder, således der fremstår et reelt overblik over restorlov. Udbetalingsspecifikationer for egne barseldagpenge, samt hvilke refusioner, der er udbetalt til egne arbejdsgivere. Borgeren skal via selvbetjeningsløsningen Bilag 3A Behovsopgørelse Side 19 af 79 1

21 kunne lave en foreløbig Barselplan, med ændringer i perioder ved at anvende udskydelse, forlængelse eller de mere fleksible afviklinger der etableres under Forældreorloven, og herunder se, hvilke konsekvenser dette får for udbetalingerne, og hvordan perioderne samlet set vil blive påvirket kunne signere en barselplan, og dermed have mulighed for at indberette oplysninger om den kommende forældreorlov. Indberetningen skal valideres imod de oplysninger, der allerede eksisterer på sagen. Det betyder fx, at borgeren ikke kan indberette en orlovsperiode, der er længere end hvad der faktisk er orlov til på sagen, eller som ligger uden for de lovbaserede muligheder kunne sende barselplanen via mail (borgeren angiver selv en adresse) kunne indberette ferie og genoptagelse af arbejde kunne bekræfte oplysningerne fra arbejdsgiverens ansøgning, og dermed kunne overgå til barseldagpenge. Borgeren skal i alle sager bekræfte arbejdsgiverens oplysning inden der kan udbetales barseldagpenge til borgeren. De konkrete krav til selvbetjeningsløsningen fremgår af bilag 3A.1 (Kravliste). 4.2 Brugergrænseflade til kunderådgivere Kunderådgiverne er fysisk placeret i landets fem administrationscentre. Deres arbejde udspringer af fire typer henvendelser: Digitale henvendelser (ansøgning eller digital post) Telefoniske henvendelser Fysisk post Systemhændelser, dvs. hændelser genereret af systemet på baggrund af ændringer i fx autoritative registre og tid. Arbejdet for kunderådgivere er baseret på arbejdspakker. Arbejdspakker er foruddefinerede og afgrænsede søgninger som leder til de hændelser der skal behandles. Alle kunderådgivere kan tilgå alle arbejdspakker på eget ydelsesområde, hvilket skaber et mere effektivt flow i sagsbehandlingen, da dette udligner arbejdsmængden blandt kunderådgiverne samt afhængighed af specifikke medarbejdere. Opsætningen og den daglige styring af arbejdspakkerne sikrer flow i behandlingen af henvendelser. Arbejdspakkerne skaber en stor uddelegering af og fleksibilitet i Bilag 3A Behovsopgørelse Side 20 af 79 2

22 arbejdet med telefoner, dokumenter og adviser. Den daglige benyttelse af arbejdspakker koordineres centralt og håndteres ikke i systemet. Kunderådgiveren skal leve op til en række servicemål fx vedrørende ekspeditionstid, og kan finde hjælp til sagsbehandling gennem konkrete instrukser i Vidensløsningen udarbejdet af Udbetaling Danmark Opbygning af kunderådgivernes brugergrænseflade En intuitiv og tilgængelig brugergrænseflade påvirker kunderådgiverens effektivitet i høj grad. Den skal til enhver tid understøtte kunderådgiverens konkrete opgaveløsning. Den gode brugergrænseflade gør det let og overskueligt at komme rundt i systemet. Overblikket skal bevares samtidig med at relevante oplysninger hele tiden er til rådighed. Det handler om flow i opgaveløsningen og rådgivningssituationen så mængden af klik, indtastningsfejl eller forglemmelser reduceres. De konkrete krav til kunderådgivernes brugergrænseflade fremgår af bilag 3A.1 (Kravliste). 4.3 Brugergrænseflade til forretningsadministratorer Systemet skal understøtte at en forretningsadministrator kan rette og slette i regler, beslutninger, skabeloner og tekster der styrer en automatiseret funktionalitet i Systemet. Et eksempel herpå kunne være, at man retter en parameter til igangsættelse af en automatisk kørsel fra 14 til 10 dage eller opretter en ny manuel brevskabelon. Brugergrænsefladen skal være udformet så den giver en logisk tilgang til dette arbejde og minimere risikoen for fejl. De konkrete krav til forretningsadministratorernes brugergrænseflade fremgår af bilag 3A.1 (Kravliste). 4.4 Wireframes for selvbetjeningsløsningen og brugergrænseflade til kunderådgivere For at illustrere ATP s tanker omkring selvbetjeningsløsningen og brugergrænsefladen til kunderådgivere, er der udarbejdet en række inspirationsgivende wire- Bilag 3A Behovsopgørelse Side 21 af 79 2

23 frames, som fremgår af bilag 3A.7 (Wireframes). Disse er tænkt som funktionsvisende guidelines, og der er således ikke tale om egentlige krav til Systemet, men om at viderebringe af ATP s opfattelse af best practice. Det skal bemærkes, at de inkluderede wireframes ikke nødvendigvis er dækkende for de endelige brugergrænseflader i Systemet. Den selvbetjeningsløsning og brugergrænsefladen til kunderådgiverne, der skal leveres som en del af Systemet, er kravsat på samme måde, som resten af Systemet i bilag 3A.1 (Kravliste) Udviklingsmodel for selvbetjeningsløsningen og brugergrænseflade til kunderådgivere ATP har særlige krav til udviklingsmodellen for selvbetjeningsløsningen og brugergrænsefladen til kunderådgivere, som skal ske i et tæt samarbejde med Leverandøren. Kravene til udvikling af selvbetjeningsløsningen og brugergrænseflader til kunderådgivere fremgår af bilag 8 (Samarbejdsorganisation og rapportering). 4.5 Roller og rettigheder For de interne brugere af Systemet, dvs. de der har direkte adgang til Systemet, er der identificeret følgende roller: Afstemningsmedarbejder Ansvarlig for den forretningsmæssige afstemning af ydelser og økonomi. Driftsleder Ansvarlig for, det overordnede overblik og kontrol over ordningen, samt den overordnede styring og prioritering af opgaver og sager. Forretningsadministrator Ansvarlig for defineringen og administrationen af de ydelsesmæssige regler, parametre, skabeloner m.v., som danner den overordnede styring af sagshåndtering og processer, samt godkendelse og styring af den helhedsorienterede kontrol. Kunderådgiver sagsbehandler adgang Ansvarlig for håndtering af sager. Bilag 3A Behovsopgørelse Side 22 af 79 2

24 Driftsleder Forretningsadministrator Kunderådgiver sagsbehandler adgang I Kunderådgiver læse adgang Afstemningsmedarbejder IT - support Intern Revision Kunderådgiver læse adgang Ansvarlig for håndtering af kontrol sager, har kun behov for at se sagerne, men har ikke behov for at redigerer eller sagsbehandle på sagerne. IT - support Ansvarlig for, tildeling af roller og rettigheder, samt adgangskontrol. Intern Revision Ansvarlig for den forretningsmæssige afstemning af processer, kontrol af transaktionsspor og adgangskontrol. Som udgangspunkt er Informationsmodellen anvendt til at lave en relativ grov inddeling af data i et antal områder, hvortil der er lavet en CRUD -matrice, som illustrerer behovet for adgangsrettigheder for hver User Story. Leverandøren skal i samarbejde med ATP afdække evt. yderligere behov for findeling af dataelementer og rettigheder hertil i løbet af Afklaringsetapen. Attributterne i matricen betyder følgende: C create, giver ret til at oprette et dataobjekt R read, giver ret til at læse et dataobjekt U update, giver ret til at opdatere et dataobjekt D delete, giver ret til at slette et dataobjekt. Figuren viser CRUD-rettighedsmatricen med rollerne og deres rettigheder: Figur 3: Oversigt over rettigheder Dataelementer/adgang til Sag sagen: Data vedrørende selve sagen ( Kontoen ), inkl. afgørelser, bevillinger, ydelser, ind- og udbetalinger. CRUD R CRU R R R R Bilag 3A Behovsopgørelse Side 23 af 79 2

25 Sag - journal/dok: Data vedrørende Journal, dokumenter, beskeder og arkiv. Adm - forretning: Data vedrørende styring af sager og afgørelser, dvs. regler, parametre, skabeloner m.v. Adm - styring: Data vedrørende det overordnede overblik og den overordnede styring af ydelsen, samt opgavestyring, prioritering m.v. Adm -adgang: Data vedrørende adgangskontrol Person og Virksomheds data: Detaljerede informationer vedr. personer, virksomheder og myndigheder, samt vidensdeling Logning: Loggede data vedrørende bl.a. adgange, transaktionsspor, grænseflader m.v. CRUD R CRUD R R R R R CRUD R R R CRUD R R R CRUD R R R R R R R R R R Bilag 3A Behovsopgørelse Side 24 af 79 2

26 5 Forretningsprocesser I dette afsnit beskrives de processer som indgår i Barseldagpengeløsningen, herunder hvordan processerne er beskrevet i aktivitetsbeskrivelser som knyttes til informationsmodeller, lovgivning samt regel- og beslutningsmodeller. Beskrivelsen her er kortfattet, den detaljerede beskrivelse af forretningsprocesserne og de forskellige niveauer heri fremgår af bilag 3A.2 Procesbeskrivelser. Den metodemæssige tilgang til forretningsmodellering i ATP er beskrevet i bilag 2A Sådan forretningsmodellerer vi i ATP Samlet procesoverblik Procesoverblikket i figur xx markeret med viser samtlige de forretningsmæssige processer der benyttes i den samlede administration af Barseldagpenge. 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 79 2

27 Her det fulde procesoverblik: Figur 5 Samlet procesoverblik Kerneprocesser Kernerprocesser er beskrevet via fire end-to-end-processer, der er specifikke for barseldagpengeordningen som yderligere er nedbrudt i Løsningsflow End-to-end-processer for barseldagpengeordningen I det følgende beskrives de fire end-to-end-processer, der er specifikke for barseldagpengeordningen, og er nummereret i henhold metodikken beskrevet i bilag 2A Sådan forretningsmodellerer vi i ATP. Detaljerede beskrivelser af end-to-end-processerne fremgår af bilag xyz. Bilag 3A Behovsopgørelse Side 26 af 79 2

28 Håndter indberetning Processen beskriver modtagelse af en virksomheds indberetning vedrørende persons fravær og ansøgning om lønrefusion, udstilling af barselplan for person og modtagelse af personens bekræftelse af overgang til barseldagpengeperioden Træf afgørelse Processen beskriver oprettelsen af en sag, vurdering af sagsoplysninger med henblik på at træffe afgørelse, beregning af ydelse og meddelelse af afgørelse herom til virksomhed hhv. person Håndter løbende ændring Processen beskriver modtagelse af ændringer til en sag fra virksomhed, person eller eksterne registre og vurdering af de ny indkomne oplysninger med henblik på fortsat berettigelse til og omfang af ydelsen Håndter drift Processen beskriver validering og evt. korrektion af en sags data til udbetaling umiddelbart før udbetaling samt igangsættelse af udbetaling af lønrefusion eller barseldagpenge Løsningsflows for kerne-processer De fire end-to-end-processer udmønter sig i følgende barselspecifikke løsningsflows, der er nummereret i henhold til metodikken i bilag 2A Sådan forretningsmodellerer vi i ATP. Løsningsflows er beskrevet nedenfor og fremgår endvidere af bilag 3A.2 Procesbeskrivelser Udfyld indberetning, person Processen beskriver personens orientering i barselplan, bekræftelse af overgang til barseldagpengeperiode samt simulering af et barselforløb Udfyld indberetning, virksomhed Processen beskriver modtagelse af virksomhedens indberetning af personens fravær i forbindelse med barsel samt ansøgning om lønrefusion Opret/opdater ansøgning Processen beskriver oprettelse af sagen på baggrund af ansøgningen og relatering med eksisterende sager og delsager, samt meddelelse af status herom til den ansøgende virksomhed. Bilag 3A Behovsopgørelse Side 27 af 79 2

29 Afgør ansøgning Processen beskriver vurdering af personens berettigelse til barseldagpenge, validering, screening for snyd, beregning af ydelse samt meddelelse af afgørelse herom til virksomheden eller personen Håndter løbende ændring person Processen beskriver personens indberetning af ændringer til barselplan, vurdering heraf og evt. genbehandling af sag samt meddelelse om ændringer til personen og evt. til virksomheden Håndter løbende ændring virksomhed Processen beskriver modtagelse af virksomhedens indberetning af ændringer til en sag, vurdering heraf, evt. genbehandling af sag samt meddelelse om betydelige ændringer til virksomheden eller personen Håndter indgående automatisk genererede hændelser Processen beskriver modtagelse af sagsrelaterede oplysninger via abonnement til eksterne registre, vurdering heraf, evt. genbehandling af sagen, samt meddelelse om betydelige ændringer til virksomhed eller person Vurder økonomisk effektueringsplan Processen beskriver kontrol af personens lønindkomstoplysninger og evt. korrektion heraf umiddelbart før udbetaling af barseldagpenge eller refusion til person hhv. virksomhed Tværgående processer Behov for systemunderstøttelse af tværgående processer er forankret i userstories Aktivitetsbeskrivelser 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 Regel- og beslutningsmodeller Aktivitetsbeskrivelserne indeholder reference til de beslutninger og forretningsregler som Systemet skal understøtte. Forretningsreglerne og beslutninger er dokumenteret i regel- og beslutningsmodeller, jf. bilag 3A.2 - Procesbeskrivelser. Bilag 3A Behovsopgørelse Side 28 af 79 2

30 5.1.7 Parameterstyring og konfigurering 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. Barselsdagpengeordningen er underlagt lovgivning, som med jævne mellemrum justeres i større eller mindre omfang. Lovændringer implementeres ofte med en tidsfaktor på 6 måneder, fra et lovforslag er vedtaget, til det træder i kraft. Derfor er det væsentligt, at rettelser, som sikrer at ordningen håndteres lovmedholdeligt, kan indføres hurtigt. Langt de fleste af disse ændringer relaterer sig til ændringer i løsningsflow og regler. De konkrete krav til parameterstyring og konfigurering af Systemet fremgår af bilag 3A.1 Kravliste. Bilag 3A Behovsopgørelse Side 29 af 79 2

31 6 Informationsarkitektur 6.1 Begrebs- og informationsmodeller I dette afsnit redegøres kort for de begrebs- og informationsmodeller, der indeholder de forretningsmæssige informationer, som det nye System skal understøtte. Der indgår følgende begrebs- og informationsmodeller i Løsningen Barseldagpenge Sag Derudover er informationsmodellen for Beriget Grunddata vedlagt, idet den viser hvilke informationer, der er til rådighed for Løsningen for Person, Virksomhed og Myndighed. Begrebs- og informationsmodellerne er detaljeret beskrevet i bilag 3A.4 og er metodemæssigt afstemt med KOMBIT. En konsekvens af den metodemæssige afstemning er, at KOMBIT og ATP har fælles, centrale begreber i begrebsmodellerne, hvilket betyder at eventuelle ændringer i begrebsmodeller skal aftales/koordineres med ATP. 6.2 Begrebet Sag Begrebet Sag er velkendt i den offentlige administration, men er ikke nødvendigvis forstået og behandlet på samme måde i alle fagområder og i alle kommuner og i statslige institutioner. Udbetaling Danmark er udsprunget af ATP, hvor begrebet Sag ikke har været anvendt og vi har derfor, som nye parter i den offentlige administration, haft behov for at få klarhed over hvad vi mener, når vi taler om sager, og vi har også brug for at kunne formidle vores sagsbegreb til eksterne parter. Udbetaling Danmark behandler forskellige typer af sager for omverdenen, som set i den overordnede begrebsmodel, figur 1. 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. UDK s sagsbehandling kan være automatisk eller manuel. Sag er et centralt begreb i Udbetaling Danmarks forretning, men det anvendes på forskellige måder i de forskellige fagsystemer og i KMD sag. I forbindelse med ud- Bilag 3A Behovsopgørelse Side 30 af 79 3

32 bud af de nye fagsystemer ønsker vi at indføre ét fælles sagsbegreb, som er defineret fælles og anvendes på samme måde i hele Udbetaling Danmark. Vi ønsker også en dialog med de forskellige forretningsområder om sagsbegrebet og dets anvendelse, så vi får defineret et fælles brugbart forretningsbegreb til understøttelse af ATP s succeskriterium, koncernstrategi 2014, om effektiv og konkurrencedygtig drift. Figur 6: Overordnet begrebsmodel for Udbetaling Danmark Fællesoffentlig definition af 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 definition af Sag Udbetaling Danmark har valgt at definere en sag sådan: Bilag 3A Behovsopgørelse Side 31 af 79 3

33 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 sag definition stemmer overens med den fællesoffentlige definition, bortset fra at vi ikke har den sidste sætning om dokumenters relationer med. Vi samler dokumenter, data, information om en afgrænset arbejdsproces i en Sag. Sagen er således en hængemappe for dokumentation og en sag kan fremsøges ved hjælp af forskellige nøgler, som identificerer denne Sagsegenskaber 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 for myndigheden. Tekst Ja BrugervendtNøgle Frit sagsnummer Tekst Ja Sagsnummer Officiel sagstitel, der kan anvendes i forbindelse med Tekst Ja Titel åbne dagsordenspunkter. Dette er også dokumentets objektnavn, jf. Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet. Sagsbeskrivelse i fri tekst. Evt. supplerende beskrivelse af indhold og formål. Tekst Ja Beskrivelse Tabel 3: Nøgler for "Sag" Sagen har også en række generelle egenskaber: Beskrivelse Værdisæt Obl. Betegnelse Henvisning til hjemmel fx lov og for sagens Tekst Nej Hjemmel behandling. Angives, hvis der er truffet beslutning om undtagelse fra offentligheden. Værdisættet består af de to følgende elementer. OffentlighedUndtaget Nej OffentlighedUndtaget Bilag 3A Behovsopgørelse Side 32 af 79 3

34 Alternativ sagstitel der kan anvendes i Tekst Nej AlternativTitel forbindelse med lukkede dagsordenspunkter, som skal vises på åbne dagsordener samt i forbindelse med postlister. Tekstuel henvisning til lovhjemmel, der Tekst Nej Hjemmel anvendes som grundlag for beslutning om undtagelse fra offentligheden. Indikator for om sagen er udnævnt som Nej/Ja Nej Principiel principsag. Kassationskode, der styrer varighed før Tekst Ja Kassationskode kassation. Er afleveret til Statens Arkiver/ 7 arkiv. Nej/Ja Nej Afleveret Tabel 4: Generelle egenskaber for "Sag" 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 barselssag løber normalt over 9 år, en pensionssag løber over hele pensionsperioden indtil dødsfald fx år. En familieydelsessag løber over barnets hele berettigelsesperiode typisk 18 år. En boligydelse kan også have et meget langt tidsforløb, men her er det sværere at sætte en tidsramme på. Sagen ændrer tilstand i løbet af sin levetid: Beskrivelse Værdisæt Obl. Betegnelse Sagens forretningsmæssige fremdrift i forhold til Fremdrift behandling Noget kræver myndighedens ageren. Opstået Sagen er i proces med en oplysning Under Oplysning Der er truffet afgørelse om sagen, fx bevilling Afgjort eller afslag Sagsbehandling er fuldført Afsluttet Tabel 5: Tilstande for "Sag " Sagens tilstand kan skifte frem og tilbage mellem de forskellige værdisæt i løbet af levetiden. Bilag 3A Behovsopgørelse Side 33 af 79 3

35 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 Systemansvar 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 Sagstyper I Udbetaling Danmark har vi det generelle begreb Sag, som altid er en bestemt type af sag. Vi har følgende sagstyper: Barsel Pension Familieydelse Boligstøtte Opkrævning HelhedsorienteretKontrol Klage Den generelle Sag har en række generelle attributter, som dækker alle sagstyper, attributterne nedarves, og hver sagstype har yderligere attributter, som er specifikke for typen Barselssag I Systemet har et barn/ufødt barn sin egen sag, den kalder vi for en Samlesag fordi den samler de sager, der har barselsdagpenge eller refusion ydelsesmodtagere for dette barn, disse sager kalder vi for delsager Referencer mellem barselssager En delsag har altid en relation til en samlesag og en delsag kan også godt have relationer til andre delsager. Fx en mor, som har en barseldagpengesag (delsag), har Bilag 3A Behovsopgørelse Side 34 af 79 3

36 en relation til sin arbejdsgiver, som har en refusionssag (delsag), og en relation til sit barn, som har en samlesag. Disse relationer ligger i sagsrelationer. Se Figur 7. Det der binder sagerne sammen er referencer mellem sagerne. Det betyder, at ved en søgning på et givent CPR nr., vil der dukke et antal sager frem i søgeresultatet. På det tidspunkt hvor en kunderådgiver vælger en af disse sager i systemet, vil kunderådgiveren kunne danne sig et overblik over de tilhørende sager til den valgte delsag. I tilfældet i Figur 7 vil kunderådgiveren kunne se, at den valgte delsag, de har søgt på, er relateret til 3 delsager samt en samlesag. Derfor er referencernes synlighed mellem sagerne i kunderådgiverens brugergrænseflade både i Barseldagpengesystemet. På den måde kan et overblik over et sagskompleks skabes hurtigt f.eks. i forbindelse med en telefonsamtale mellem Udbetaling Danmark og en virksomhed/borger. Figur 7: Relationer i Barselsag Sagsbegreb i barsel Delsagerne tilknyttet samlesagen, er bundet op på de resterende interessenters CPR nr. eller CVR P-numre. Teknisk set er det dog sagsid erne som udgør referencen, men set fra kunderådgiveren er det CPR/CVR numre og en sagstype. Antallet af delsager kan variere i antal, afhængig af om det både er moderen og faderen, der søger om barseldagpenge, og om faderens og moderens respektive arbejdsgivere søger om refusion. Barseldagpengesystemet skal i forbindelse med oprettelse af sager, skabe referencer mellem sager med baggrund i opstillede regler. Bilag 3A Behovsopgørelse Side 35 af 79 3

37 Forskelle til sagsbegreb i Eksisterende Løsning Det beskrevne sagsbegreb, som skal understøttes af Systemet, er forskelligt fra det sagsbegreb, der benyttes i den Eksisterende Løsning. Figur 8 og Figur 9 illustrerer med et eksempel, hvad der vil være af sager i henholdsvis Eksisterende Løsning og Barseldagpengesystemet. Det pågældende eksempel tager udgangspunkt i et barn, hvor mor har to arbejdsgivere, mens far kun har én. Begge holder barselsorlov omkring barnets fødsel, og mor genoptager endvidere orloven på et senere tidspunkt, inden barnet er 9 år. I Eksisterende Løsning vil der være en sag pr. ydelsesberettiget pr. sammenhængende fraværsperiode. Dvs. at moren vil have to sager, mens faren vil have en enkelt sag. De forskellige fraværsforhold hos de forskellige arbejdsgivere vil ligge som delsager under den ydelsesberettigedes sag, men de vil ikke optræde som selvstændige sager. Barnet vil ikke have sin egen sag, men der vil blive holdt en samlet opgørelse over forbrugt orlov tilknyttet barnet. Der er i den Eksisterende Løsning en årlig tilvækst i antallet af sager på ca Figur 8: Illustration af sagsbegrebet i den Eksisterende Løsning med angivelse af den omtrentlige årlige tilvækst i antallet af sager. Samlet set er der ca nye sager om året. Bilag 3A Behovsopgørelse Side 36 af 79 3

38 I Barseldagpengesystemet vil barnet få en samlesag, og hver part vil få sin egen delsag. Dvs. at moren vil få en delsag som dækker begge orlovsperioder, faren vil få en delsag, og hver arbejdsgiver vil få en delsag. Der vil i Barseldagpengesystemet være en årlig tilvækst i antallet af sager på ca sager samlet set. Figur 9: Illustration af sagsbegrebet i Barseldagpengesystemet med en angivelse af den omtrentlige årlige tilvækst i antallet af sager. Samlet set vil der være ca nye sager med det nye sagsbegreb. Bilag 3A Behovsopgørelse Side 37 af 79 3

39 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 hvilke 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 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 ordninger fortsat understøttes af disse. Der vil således i udbudsarkitekturen indgå en række eksisterende itsystemer fra KMD, som kun skal benyttes i en periode frem til den endelige målarkitektur kan realiseres. IT-udbudsarkitekturen fremgår af Figur 10 og forskellene i forhold til ITmålarkitekturen beskrives kort i det følgende. Bilag 3A Behovsopgørelse Side 38 af 79 3

40 Figur 10: IT-udbudsarkitekturen for Barsel. Diagrammet viser de systemer, der indgår i løsningen til administration af barseldagpenge. Bilag 3A Behovsopgørelse Side 39 af 79 3

41 Fagsystemer Barseldagpengesystemet er det centrale system i IT-udbudsarkitekturen og det første fagsystem, der bliver konkurrenceudsat af ATP. De øvrige ydelsesområder under Udbetaling Danmark vil fortsat benytte fagsystemer fra KMD på tidspunktet for ibrugtagning af Barseldagpengesystemet. Opkrævning vil ligeledes foregå i KMD Opus Debitor, hvor eventuelle tilbagesøgninger af for meget udbetalt refusion eller barseldagpenge vil skulle håndteres manuelt. 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 eindkomst og årsopgørelsen håndteres via KMD Indkomst. Opkrævning af kommunernes andel af visse ydelser håndteres via KMD KMF (Kommunal MedFinansiering). Endelig vil KMD Sag 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å barseldagpengesager. Dette vedligehold vil ske indirekte via synkronisering af sags- og ydelsesoplysninger mellem KMD Sag og de fælleskommunale støttesystemer. 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. Ordningsspecifikke systemer og registre De ordningsspecifikke systemer og registre er de systemer, som ikke skal anvendes på de øvrige ydelsesområder, og som kun Barsel skal anvende eller aflevere data til. Systemerne var også afbildet på IT-målarkitekturen i bilag 3 (Leverancebeskrivelse), og de præsenteres kort her. NemRefusion er det mest centrale system, som anvendes som selvbetjeningsløsning til virksomheder. Statens Administration administrerer et forsikringsregister for selvstændige, og oplysninger herfra skal benyttes til beregning af dagpengesats for selvstændige. Barsel.dk, Barselsudligning for selvstændige (BUS), SKAT (Rapport over refusioner), samt KSD (Kommunalt SygeDagpenge system) er alle systemer/parter som skal modtage visse oplysnin- Bilag 3A Behovsopgørelse Side 40 af 79 4

42 ger fra Barseldagpengesystemet. KSD modtager dog kun oplysninger indirekte via de fælleskommunale støttesystemer. 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.3 Integrationer og infrastruktur. På system kontekst diagrammet er hver integration tildelt et ID ud fra mønsteret IntegrationsID = <ordningsforkortelse B ><3-bogstavs systemforkortelse><fortløbende nr.>. Fra aktivitetsbeskrivelser og fra krav er der refereret til integrationsid et. Systemkonteksten er illustreret på Figur 11. Bilag 3A Behovsopgørelse Side 41 af 79 4

43 Figur 11: Systemkonteksten for Systemet. Diagrammet viser alle de systemer, som Systemet skal integrere til. Figuren viser ikke infrastruktur-komponenter men udelukkende applikationer på logisk niveau. Alle integrationerne er listet i den følgende tabel. Integrationspart IntegrationsID Integrationsnavn NemRefusion BNRE1 Hent indberetninger fra NemRefusion BNRE2 Opdater indberetning på NemRefusion Beriget Grunddata BBGD1 Hent person, virksomhed el. myndighed fra Beriget Grunddata Bilag 3A Behovsopgørelse Side 42 af 79 4

44 Integrationspart IntegrationsID Integrationsnavn KMD Udbetaling BKUD1 Udbetalingsanmodninger til KMD Udbetaling SKAT eindkomst BSKE1 Rekvirer eskattekort fra eindkomst BSKE2 Indberet til eindkomst ATP ERP BERP1 Posteringer til ERP KMD KMF BKMF1 Træk af kommunal medfinansiering KMD Indkomst BKIK1 Indkomstoplysninger fra eindkomst og årsopgørelse Forsikringsregister hos Statens Administration BFSA1 Opdateringer fra forsikringsregister for selvstændige erhvervsdrivende Fjernprint BFPR1 Send besked via Fjernprint Barsel.dk BBDK1 Refusionsoplysninger til Barsel.dk Barseludligning for selvstændige (BUS) BBUS1 Udbetalingsoplysninger til Barselsudligning for selvstændige Beskæftigelsesministeriet/STAR BBMI1 Levering af dagpengeperioder til Beskæftigelsesministeriet/STAR BBMI2 Levering af feriedagpengeopgørelse til Beskæftigelsesministeriet/STAR BBMI3 Levering af kortperiodestatistik til Beskæftigelsesministeriet/STAR BBMI4 Levering af fraværsstatistik til Beskæftigelsesministeriet/STAR Danmarks Statistik DST1 Levering af oplysninger til Danmarks Statistik SKAT BSKR1 Refusionsrapport til SKAT ATP afstemning BAAF1 Afstemningsdata til ATP ATP Datawarehouse BDWH1 Data til datawarehouse ATP IdM og IdP BIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM BIDP1 Login via ATP s IdP NemLog-in BNLO1 Login til selvbetjening via NemLog-in Borger.dk BBOR1 Visuel integration i Borger.dk Bilag 3A Behovsopgørelse Side 43 af 79 4

45 Integrationspart IntegrationsID Integrationsnavn Sags- og dokumentindeks BSDI1 Udstil oplysninger i Sags- og dokumentindeks BSDI2 Hent oplysninger fra Sags- og dokumentindeks Ydelsesindeks BYDI1 Udstil oplysninger i Ydelsesindeks BYDI2 Hent oplysninger fra Ydelsesindeks Statens arkiver BSTA1 Aflever til Statens arkiver Posthåndteringsleverandør BPHL1 Modtag indgående post BPHL2 Send post til genjournalisering Tabel 6 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.3 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 44 af 79 4

46 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 mener 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 generelt benytte den integrationsmetodik og -platform, som serviceudbyderen stiller til rådighed. Bilag 3A Behovsopgørelse Side 45 af 79 4

47 8 Non-funktionelle krav til Systemet Ud over de funktionelle krav til Systemet i kapitel 0 har ATP en række nonfunktionelle 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 kravlisten 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. 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. 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 Bilag 3A Behovsopgørelse Side 46 af 79 4

48 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 xyz - Servicemål. 8.6 Datakonvertering Dette afsnit fastsætter de overordnede vilkår for konvertering af data fra den Eksisterende Løsning til Systemet. ATP s overordnede mål for konverteringen er at sikre, at der sker behørig konvertering og afstemning af relevante data og en sikker overgang til Systemet og støttesystemer Konverteringskonceptet generelt På tidspunktet for overgang til ny barseldagpengeløsning vil KMD barseldagpenge fagsystemerne (KMD Dagpenge og Opus Barsel) blive lukket ned, alle data vil blive trukket ud, og data vil blive konverteret ind i den nye barseldagpengeløsning. Det samme vil gøre sig gældende for tilhørende data fra relevante støttesystemer, herunder KMD sag mfl. Herefter behandles alle sager i den nye løsning; dog vil KMD Sag fortsat blive holdt opdateret. 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 12. Bilag 3A Behovsopgørelse Side 47 af 79 4

49 Figur 12 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 barseldagpengesag. Udtræk af data fra Eksisterende Løsning gennemføres af KMD. Udtræk af data fra Forsikringsregister for selvstændige erhvervsdrivende gennemføres af Statens Administration. 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. Bilag 3A Behovsopgørelse Side 48 af 79 4

50 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 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 Opus Barsel og KMD Dagpenge. For Opus Barsel vil data omfatte både afsluttede og igangværende sager, samt eventuelt tilknyttede opgaver. For KMD Dagpenge vil der kun være tale om afsluttede sager med kun en begrænset mængde data. Person- og Virksomhedsdata fra Opus-systemet inklusiv fiktive cpr-numre på udenlandske børn. Generelle sagsdata fra KMD Sag vedrørende Barseldagpengesager. 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 i den kvalitet, de nu engang har i systemerne Bidrager til den tværgående test af konverteringen 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 verificere at dataudtrækket fra KMD matcher den leverede dokumentation af udtrækket. Dette skal ske på tidspunktet for modtagelse af prøveudtræk fra KMD og skal ske ved indlæsning af de modtagne data i en relationel database. Herigennem kan det verificeres, om der er referentiel integritet mellem ta- Bilag 3A Behovsopgørelse Side 49 af 79 4

51 beller, og om data har det beskrevne format. Ved mangler i leverancen fra KMD håndteres dette af ATP. Udover udtræk af data fra Eksisterende Løsning vil der også blive leveret udtræk af forsikringsregisteret for selvstændige erhvervsdrivende hos Statens Administration. Udtrækket leveres i samme format som de dataleverancer, der modtages via integrationen BFSA1 (se bilag 3A.6 (Integrationer)) Transformering af data Leverandøren skal bortfiltrere eventuelt unødvendige data og transformere de data, som skal indlæses i Systemet og støttesystemer 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.2). 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. 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. 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 50 af 79 5

52 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: Der skal være styr på forbrugt orlov fordelt på orlovstyper og ydelsesmodtager for alle børn under 10 år. Aktive sager fra Eksisterende Løsning skal videreføres i Systemet, og sagsbehandlingen og/eller udbetalingerne skal forsætte hvor de slap. Passive sager med restorlov fra Eksisterende Løsning skal videreføres i Systemet og kunne genoptages ved nye hændelser. Afsluttede sager (hvor der ikke er restorlov) fra Eksisterende Løsning skal kunne genberegnes, evt. ved manuel oprettelse. Forudsætning herfor er, at data som minimum skal indeholde forbrugt orlov fordelt på orlovstyper og ydelsesmodtagere, parter, skattetræk, fradrag, oplysninger om hvad der er udbetalt til arbejdsgiver og borger, samt borgers arbejdstid. 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) 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 Bilag 3A Behovsopgørelse Side 51 af 79 5

53 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. ATP Datawarehouse Datawarehouse skal modtage et initielt load af alle data. Data skal leveres i samme format som i de daglige dataleverancer se integrationsbeskrivelse BDWH1 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. Barsel.dk og BUS ATP skal til brug for Barsel.dk og BUS modtage en mapningsfil der specificerer hvordan sager fra Eksisterende Løsning er tranformeret til sager i Systemet. Leverandøren skal i Afklaringsetapen afklare hvilke snitflader, der skal anvendes til ovenstående dataudvekslinger mod Beriget Grunddata, Sags- og dokumentindeks og Ydelsesindeks 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. Bilag 3A Behovsopgørelse Side 52 af 79 5

54 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. 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 transformering, som sikrer at der ikke sker data tab eller forvanskning af data ved overgangen til det nye System. 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øsningen 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 skal beskrive, 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 bør helst kunne gennemføres over en weekend. Hvis der er aktiviteter, der strækker sig over hverdage, skal der så vidt muligt fortsat være læseadgang til data. Bilag 3A Behovsopgørelse Side 53 af 79 5

55 8.6.7 Håndtering af dataudtræk og prøveudtræk Til brug for afprøvning af konverteringsprogrammellet kan der fra KMD leveres et prøveudtræk af data fra den Eksisterende Løsning, som beskrevet i [ref. udfasningsassistance tilbud ]. Prøveudtrækket vil være et fuldt udtræk af produktionsdata. Leverandøren skal ved håndtering og anvendelse af udtræk fra den Eksisterende Løsning sikre at Persondatalovens bestemmelser overholdes, herunder sikre at: Der ikke behandles flere data end nødvendigt. Leverandøren skal derfor etablere mekanismer til udtræk af delmængder af data fra prøveudtrækket, således at der kan gennemføres prøvekonverteringer (se Bilag 6 Afprøvninger, konverteringsprøve) med en begrænset mængde af data. Data anonymiseres eller maskeres tilstrækkeligt inden indlæsning i miljøer eller systemer, som ikke overholder Persondatalovens bestemmelser, herunder sikkerhedsbekendtgørelsen. 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 Barselloven, 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. Bilag 3A Behovsopgørelse Side 54 af 79 5

56 8.9 Sikkerhed IT sikkerhed handler om at sikre konfidentialitet, integritet, og tilgængelighed af information imod forskellige sikkerhedsrisici. Dette behov skal sikres ved at indarbejde 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 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. Bilag 3A Behovsopgørelse Side 55 af 79 5

57 8.13 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. 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. 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 Bilag 3A Behovsopgørelse Side 56 af 79 5

58 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 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 57 af 79 5

59 9 Fremtidige tilpasninger til Systemet TODO: Find ud af om dette afsnit er placeret rigtigt. TODO: Dette afsnit bør nok tjekkes af jura for om formuleringerne er holdbare ifht. at de fremtidige tilpasninger/udvidelser skal være omfattet af udbuddet. 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 skal ikke prissættes (TODO: BRM formuler dette ordentligt), og de forventede tilpasninger til Systemet præsenteres derfor blot ganske overordnet i det følgende. Det er ikke sikkert, at alle de her beskrevne tilpasninger skal gennemføres. 9.1 Indhentelse af lægeattester Til brug for sagsbehandling af barseldagpengesager, hvor fraværet skyldes sygeligt forløbende graviditet og fravær under graviditet grundet arbejdets særlige karakter, ønsker ATP en digital løsning til udveksling af lægeattesten (UD 235) samt anmodning om attest (UD 231), der fremsendes til borgeren sammen med en kopi af lægeattesten. Begge attester er udarbejdet i samarbejde med Lægeforeningen og overholder MedComs standarder for blanketter til udveksling af oplysninger. Der skal yderligere sendes et følgebrev til lægen, hvor teksten er defineret af Udbetaling Danmark. Herpå skal fx stå, at lægen kun kan sende fakturaer digitalt til Udbetaling Danmark. Løsningen skal både håndtere udsendelse og modtagelse af lægeattester, der sendes digitalt og med fysisk post. Baseret på ATP s foreløbige erfaringer, udveksles ca. 60 % af lægeattesterne digitalt, mens de resterende håndteres som fysisk post. Det forventes, at antallet af fysisk udsendte lægeattester er markant faldende, da flere lægesystemer ifølge MedCom vil integrere med de nødvendige digitale standarder inden for de kommende år. Endvidere følger det af lov om offentlig digital post, at alle borgere skal have en digital postkasse fra november 2014, medmindre de bliver fritaget herfor. Bilag 3A Behovsopgørelse Side 58 af 79 5

60 Udbetaling Danmark rekvirerer samlet ca lægeattester på årsbasis. Løsningen skal kunne benyttes af ca. 100 kunderådgivere fordelt på 5 lokationer rundt i landet. Løsningen skal understøtte følgende standarder for kommunikation af LÆblanketter (se herunder Den dynamiske blanket (DBB) vs Den Gode LÆ Service (DGLÆ) vs. 1.0 Den Specifikke DBB:LÆ Blanketbeskrivelse Den Gode WebService (DGWS) vs Integration til opkrævningssystem I tilfælde af at der er udbetalt for mange penge til en person eller virksomhed, skal disse tilbagesøges fra personen eller virksomheden. Selve opkrævningen foregår i et separat opkrævningssystem, og i udbudsarkitekturen er der ingen integration til opkrævningssystemet; Systemet sørger blot for at der oprettes en opgave på at foretage opkrævningen, når en sådan skal finde sted. Der ønskes en tilpasning til Systemet, så opkrævningerne automatisk oprettes i et kommende opkrævningsfagsystem via en integration til dette system. De oplysninger, der skal overføres til opkrævningsfagsystemet, forventes at være cirka de samme, som der ellers har indgået i den dannede opgave. 9.3 Hent indkomstoplysninger udenom KMD Indkomst I IT-udbudsarkitekturen anvendes KMD Indkomst til at hente indkomstoplysninger fra henholdsvis SKAT s eindkomst-system 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.4 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. 9.5 Digital fuldmagt Den fællesoffentlige basale fuldmagtsløsning under NemLog-in kan anvendes til at lade personer give en anden person fuldmagt til at anvende hele eller dele af selvbetjeningsløsningen på ens vegne. Der ønskes en tilpasning til selvbetjeningsløs- Bilag 3A Behovsopgørelse Side 59 af 79 5

61 ningen og login et til denne, så den digitale fuldmagtsløsning under NemLog-in understøttes. Bilag 3A Behovsopgørelse Side 60 af 79 6

62 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 13 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 61 af 79 6

63 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 og relevante miljøer 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 62 af 79 6

64 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, jf. punkt Fejl! Henvisningskilde ikke undet.. Der henvises også til bilag 7 (Servicemål) og bilag 8 (Samarbejdsorganisation og rapportering). Bilag 3A Behovsopgørelse Side 63 af 79 6

65 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 7 Definition af vedligeholdelse og support. Bilag 3A Behovsopgørelse Side 64 af 79 6

66 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 65 af 79 6

67 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 8 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 66 af 79 6

68 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 67 af 79 6

69 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 68 af 79 6

70 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 69 af 79 6

71 11 Procesbeskrivelsernes opbygning en læsevejledning til underbilag Dette kapitel indeholder en læsevejledning til følgende underbilag Bilag 3A.2 Løsingsflows og aktivitetsbeskrivelser - barselsspecifikke Bilag 3A.3 Løsingsflows og aktivitetsbeskrivelser - tværgående Bilag 3A.4 Begrebs- og informationsmodeller Bilag 3A.5 Regel- og beslutningsmodeller 11.1 Procesbeskrivelsernes opbygning Forretningsprocesserne er beskrevet i flere niveauer, som det fremgår af figuren nedenfor. Disse niveauer er beskrevet i det efterfølgende. Figur 14 Opbygningen af procesbeskrivelserne i bilag 3A.2 De 2 øverste niveauer, procesoverblikket og End-to-End processerne indeholder ingen kravspecifikinformation, men viser struktur og overblik i forhold til de underliggende niveauer, der indeholder krav til Systemet. End-to-End processerne er nedbrudt i løsningsflow. Løsningsflow forkortes LF. Hvert løsningsflow består af et antal aktiviteter. Til hver aktivitet er knyttet en aktivitetsbeskrivelse, som indeholder information om, hvad aktiviteten omfatter. Det skal bemærkes, at en aktivitetsbeskrivelse stort set svarer til det som i andre sammenhænge betegnes en use case, dvs, enten en system use case eller en bruger use case. Bilag 3A Behovsopgørelse Side 70 af 79 7

72 De enkelte niveauer beskrives yderligere i de efterfølgende afsnit Procesoverblikket Procesoverblikket er vist i Figur 15. Centralt i figuren ses de fire end-to-end processer, nummereret 1.3.1, 1.3.2, og Disse end-to-end processer benævnes kerne end-to-end processer, fordi de er forretningsspecifikke i forhold til administrationen af barseldagpenge. Ud over de fire kerne end-to-end processer ses en række tværgående processer. Disse processer er tværgående i den forstand, at de ikke kun benyttes i forbindelse med administrationen af barseldagpenge, men også i forbindelse med administration af Udbetaling Danmarks og ATP s øvrige ordninger. Eksempelvis benyttes processen 10.x.1 Håndter udbetaling øverst til højre i figuren i alle de ordninger, som Udbetaling Danmark og ATP administrerer. Kun de processer der er markeret i procesoverblikket, anvendes i løsningen til Barsel. Bemærk, at overskriften Driftsprocesser i procesoverblikket, skal forstås som Forretningsdriftsprocesser ikke som it-driftsprocesser. Figur 15: Procesoverblik kerne end-to-end processer og tværgående processer Bilag 3A Behovsopgørelse Side 71 af 79 7

73 I den klikbare html-version af procesbeskrivelserne, kan end-to-end processerne i procesoverblikket foldes ud ved at klikke på den lille kvadratiske figur, som findes under processen, jf. Figur 16 nedenfor. Figur 16: En end-to-end proces kan foldes ud ved at klikke på det lille kvadratiske figur under processen i procesoverblikket. Herefter ses, at den udfoldede end-to-end proces Barselsdagpenge, Træf afgørelse består af 2 løsningsflow. End-to-end processerne kan foldes yderligere ud til at vise de løsningsflow, de indeholder. Den udfoldede end-to-end proces illustrerer den administration, som er knyttet til end-to-end processen. Dette overblik indeholder ikke i sig selv krav til systemunderstøttelsen, men giver et overblik over processen. En gennemgang af de udfoldede end-to-end kerne processer kan derfor med fordel foretages inden løsningsflowene, på niveauet under end-to-end processerne, læses. Bilag 3A Behovsopgørelse Side 72 af 79 7

74 Figur 17: Udfoldning af end-to-end processerne giver overblik over den administration, som end-to-end processen repræsenterer. De enkelte løsningsflow, som er tilknyttet end-to-end processerne, kan også foldes ud. Figur 18: Udfoldning af et løsningsflow og en tilhørende aktivitetsbeskrivelse Dette gøres ved at klikke på den lille kvadratiske figur under løsningsflowet, som det er vist i Figur 18Fejl! Henvisningskilde ikke fundet.. Denne figur viser også, Bilag 3A Behovsopgørelse Side 73 af 79 7

75 hvordan de aktivitetsbeskrivelser, som løsningsflowet er bygget op af, kan foldes ud ved at klikke på de enkelte aktiviteter i løsningsflowet Sådan læses et løsningflow Løsningsflowene i bilag 3A.2 og 3A.3 beskriver hvordan en given barseldagpengesag gennemløber forskellige tilstande fra indberetning over afgørelse og under udbetaling mv. indtil sagen afsluttes. Et løsningsflow består primært af pile, rektangler og svømmebaner : En pil repræsenterer en overgang fra en aktivitet til den næste i pilens retning. Der er ofte knyttet information til en sådan overgang, således at output fra den første aktivitet bliver input til den næste. Et rektangel repræsenterer en aktivitet, der behandler input og producerer output. En svømmebane repræsenterer i bred forstand en aktør, som fx en kunderådgiver, Systemet eller et tilgrænsende system som NemRefusion. Den aktør, som gennemfører aktiviteten, er bestemmende for hvilken svømmebane aktiviteten placeres i. Pile på tværs af svømmebaner repræsenterer integrationer både interne (som fx brugergrænsefladen mellem Systemet og kunderådgiveren) og eksterne (som fx Systemets grænseflade til NemRefusion). Pilene i løsningsflowene er endvidere tildelt en farve, som afspejler mængde og kompleksitet af sager, som ekspederes via den vej (delflow) som pilen repræsenterer. Grønne pile benævnes motorveje, blå pile landeveje og røde pile benævnes bjergveje. Farve af en pil afgøres på baggrund ad det kryds mellem kompleksitet og mængde, som er vist i Figur 19. Bilag 3A Behovsopgørelse Side 74 af 79 7

76 Figur 19: Kombinationen af mængden og kompleksiteten af sager afgør om et delflow betegnes en motorvej, en landevej eller en bjergvej. Bjergveje repræsenterer delflow af sager af høj kompleksitet men lav volumen osv. De vigtigste svømmebaner er *Barselsdagpengesystemet Automatisk indeholder de aktiviteter, som skal være automatiseret i større eller mindre grad. *Kunderådgiver indeholder de aktiviteter, der er knyttet til kunderådgiverens interaktion med Systemet. Her findes typisk aktiviteter relateret til Systemets brugerdialog. *Selvbetjener indeholder aktiviteter, der er knyttet til Selvbetjeningsløsningen. *Kanal indeholder aktiviteter knyttet til ATP s middleware EKKO, der benyttes til at beskytte Systemet mod ændringer i eksterne grænseflader. Listen er ikke udtømmende, og det skal bemærkes, at der kan være krav til Systemet i aktivitetsbeskrivelser i enhver svømmebane. Bilag 3A Behovsopgørelse Side 75 af 79 7

77 Figur 20: Forklaring af den notation, som anvendes i løsningsflowene. De samme signaturer anvendes i end-to-end processerne. Bemærk, at kun bronzefarvede aktiviteter indeholder krav til System, mens gråtonede aktiviteter ikke indeholder sådanne krav. De gråtonede aktiviteter er med af hensyn til forståelsen af sammenhængen. Løsningsflowenes signaturer er forklaret i Figur 20. Den anvendte standard for nummerering af procesflow fremgår nedenfor: Indberetning: 1.3 o Håndter indberetning Udfyld indberetning, person (LF) Udfyld indberetning, virksomhed o Træf afgørelse Bilag 3A Behovsopgørelse Side 76 af 79 7