Bilag 3A Behovsopgørelse

Transcription

Version 1.0
23-02-2015
Indhold
1 VEJLEDNING TIL TILBUDSGIVER ................................................................................. 7
2 INDLEDNING ............................................................................................................. 8
2.1 UNDERBILAG ............................................................................................................. 8
2.2 FARVEANVENDELSE PÅ ARKITEKTURDIAGRAMMER .............................................................. 9
3 DEN SAMLEDE FORRETNINGSMÆSSIGE LØSNING .................................................... 10
3.1 BRUGERNE AF SYSTEMET............................................................................................ 10
3.2 BORGERNE OG VIRKSOMHEDERNE ................................................................................ 10
3.3 KUNDERÅDGIVERNE .................................................................................................. 10
3.4 FORRETNINGSADMINISTRATORERNE ............................................................................. 11
3.5 ROLLER OG RETTIGHEDER ........................................................................................... 12
3.5.1 RISIKOVURDERING........................................................................................................... 12
3.5.2 PERSONDATALOVEN ........................................................................................................ 12
3.5.3 FUNKTIONSADSKILLELSE ................................................................................................... 12
3.5.4 DOKUMENTATION ........................................................................................................... 13
3.5.5 PRIVILEGEREDE ROLLER .................................................................................................... 13
3.5.6 FORRETNINGSROLLER ...................................................................................................... 14
4 FORRETNINGSUDBUDSARKITEKTUREN .................................................................... 15
4.1 AUTOMATISERET OG MANUEL SAGSBEHANDLING ............................................................. 16
4.2 KANALER OG KOMMUNIKATION .................................................................................. 16
4.3 ØVRIGE ELEMENTER I FORRETNINGSUDBUDSARKITEKTUREN ................................................ 17
5 KOMPONENTMODEL .............................................................................................. 18
5.1 KANALER ............................................................................................................... 19
Side 1 af 76
5.1.1 POSTHÅNDTERING .......................................................................................................... 20
5.1.2 SELVBETJENING .............................................................................................................. 20
5.2 MANUELT .............................................................................................................. 20
5.2.1 OPGAVEINDBAKKE .......................................................................................................... 21
5.2.2 TVÆRGÅENDE OVERBLIK .................................................................................................. 21
5.2.3 SAGSHÅNDTERING .......................................................................................................... 21
5.2.4 MANUELLE BREVE........................................................................................................... 21
5.2.5 SYSTEMADMINISTRATION ................................................................................................. 22
5.2.6 REGELADMINISTRATION ................................................................................................... 22
5.3 AUTOMATISK .......................................................................................................... 23
5.3.1 VALIDERING ................................................................................................................... 23
5.3.2 OPKRÆVNINGS- OG BETALINGSADMINISTRATION.................................................................. 23
5.3.3 HÅNDTER MODREGNING .................................................................................................. 24
5.3.4 RYKNING ....................................................................................................................... 24
5.3.5 EFI HÅNDTERING ............................................................................................................ 24
5.3.6 HÅNDTER INDBETALING ................................................................................................... 25
5.3.7 DAN UDBETALING ........................................................................................................... 25
5.3.8 AFSKRIVNING ................................................................................................................. 25
5.3.9 BESKEDHÅNDTERING ....................................................................................................... 25
5.4 STØTTEKOMPONENTER .............................................................................................. 25
5.4.1 PERSON- OG VIRKSOMHEDSDATA ...................................................................................... 26
5.4.2 SAGER & DOKUMENTER................................................................................................... 26
5.5 ØVRIGE KOMPONENTER ............................................................................................ 26
5.5.1 SIKKERHED ..................................................................................................................... 26
5.5.2 RAPPORTER ................................................................................................................... 27
5.5.3 JOBAFVIKLING ................................................................................................................ 27
5.5.4 ØKONOMI ..................................................................................................................... 27
5.5.5 HÆNDELSER ................................................................................................................... 27
5.5.6 AFSTEMNING ................................................................................................................. 27
5.5.7 ARKIVERING ................................................................................................................... 28
5.5.8 INDEKSSYNKRONISERING .................................................................................................. 28
Side 2 af 76
6 FORRETNINGSPROCESSER ....................................................................................... 29
6.1 SAMLET PROCESOVERBLIK .......................................................................................... 29
6.2 KERNEPROCESSER..................................................................................................... 30
6.2.1 KERNEPROCES - HÅNDTER INDBERETNING 1.5.1 .................................................................. 30
6.2.1.1 LF – Debitor – Opret krav 1.5.1.1 ............................................................................ 30
6.2.2 KERNEPROCES - HÅNDTER LØBENDE ÆNDRINGER 2.5.1 ........................................................ 30
6.2.2.1 LF – Debitor – Håndter automatisk generede oplysninger 2.5.1.1 ......................... 30
6.2.3 KERNEPROCES – HÅNDTER DRIFT 2.5.2 .............................................................................. 31
6.2.3.1 LF – Debitor - Håndter Opkrævning 2.5.2.1 ............................................................ 31
6.2.3.2 LF – Debitor - Håndter Afdragsordning 2.5.2.2 ....................................................... 31
6.2.3.3 LF – Debitor - Håndter indbetaling 2.5.2.3 .............................................................. 32
6.2.3.4 LF – Debitor - Håndter rykker 2.5.2.4 ...................................................................... 33
6.2.3.5 LF – Debitor - Håndter restance 2.5.2.5 .................................................................. 33
6.2.3.6 LF – Debitor Håndter afskrivning 2.5.2.6 ................................................................ 34
6.2.4 KERNEPROCES – HÅNDTER UDBETALING 3.5.1 .................................................................... 35
6.2.4.1 LF – Debitor - Effektuer udbetaling – person 3.5.1.1. ............................................. 35
7 INFORMATIONSARKITEKTUR ................................................................................... 36
7.1 OVERORDNET BEGREBSMODEL FOR UDBETALING DANMARK ............................................... 36
7.2 BEGREBS- OG INFORMATIONSMODELLER FOR FORRETNINGSLØSNINGEN ................................ 37
7.2.1 DOKUMENTATION TIL LEVERANDØR ................................................................................... 37
7.2.2 INFORMATIONSMODEL SAG .............................................................................................. 38
7.2.2.1 Sag ........................................................................................................................... 38
7.2.2.2 Sag - Nøgler og Egenskaber ..................................................................................... 39
7.2.2.3 Sagens oprettelse og livsforløb ............................................................................... 39
7.2.3 PART ............................................................................................................................ 40
7.2.4 SAGSDOKUMENTATION .................................................................................................... 40
7.2.5 INFORMATIONSMODEL DEBITOR........................................................................................ 40
7.2.5.1 Debitorsag ............................................................................................................... 40
7.2.5.2 Krav.......................................................................................................................... 40
Side 3 af 76
7.2.5.3 Opkrævning ............................................................................................................. 41
7.2.5.4 Indbetaling .............................................................................................................. 41
7.2.5.5 Afskrivning ............................................................................................................... 41
7.2.5.6 Udbetaling ............................................................................................................... 41
7.2.5.7 Rykker ...................................................................................................................... 41
7.2.5.8 Modregningsordning ............................................................................................... 41
7.2.5.9 Afdragsordning ........................................................................................................ 42
7.2.5.10 Inddrivelsessag ...................................................................................................... 42
7.2.5.11 Modregningssag .................................................................................................... 42
8 IT ARKITEKTUR........................................................................................................ 43
8.1 IT-UDBUDSARKITEKTUREN .......................................................................................... 43
8.2 SYSTEMKONTEKST OG INTEGRATIONER .......................................................................... 45
8.3 INTEGRATIONER OG INFRASTRUKTUR ............................................................................ 48
9 NON-FUNKTIONELLE KRAV TIL SYSTEMET ................................................................ 49
9.1 ARKITEKTUR ........................................................................................................... 49
9.1.1 RAMMER FOR ARKITEKTUREN............................................................................................ 49
9.1.2 BELASTNING OG SKALERING .............................................................................................. 49
9.1.2.1 Krav modtaget fra Fagsystemer .............................................................................. 49
9.1.2.2 Opkrævningskørsler ................................................................................................ 50
9.1.3 MODREGNINGER ............................................................................................................ 50
9.1.3.1 Status på EFI Sager .................................................................................................. 50
9.1.3.2 Journaliser post på sagen ........................................................................................ 50
9.1.3.3 Dataudtræk og øvrig rapportering .......................................................................... 50
9.2 DESIGN OG APPLIKATIONSSTRUKTUR ............................................................................. 50
9.3 LOGNING ............................................................................................................... 50
9.4 SYSTEMFLEKSIBILITET ................................................................................................ 51
9.5 TILGÆNGELIGHED ..................................................................................................... 51
9.6 DATAKONVERTERING ................................................................................................ 51
Side 4 af 76
9.6.1 KONVERTERINGSKONCEPTET GENERELT............................................................................... 51
9.6.2 UDTRÆK AF DATA ........................................................................................................... 53
9.6.3 TRANSFORMERING AF DATA .............................................................................................. 54
9.6.4 INDLÆSNING OG VIDEREFORDELING AF DATA ....................................................................... 55
9.6.4.1 Indlæsning af data i Debitorsystemet ..................................................................... 55
9.6.4.2 Viderefordeling af data og synkronisering med støttesystemer ............................ 56
9.6.5 AFSTEMNING OG DATAVALIDERING .................................................................................... 57
9.6.6 GENNEMFØRSEL AF KONVERTERINGEN ............................................................................... 58
9.6.7 HÅNDTERING AF PRØVEUDTRÆK ........................................................................................ 59
9.7 BRUGERVENLIGHED .................................................................................................. 59
9.8 LOVGIVNING ........................................................................................................... 59
9.9 SIKKERHED ............................................................................................................. 59
9.10 MILJØER .............................................................................................................. 60
9.11 PROJEKTLEDELSE .................................................................................................... 60
9.12 UDDANNELSE ........................................................................................................ 60
9.13 DOKUMENTATION .................................................................................................. 60
9.14 IDRIFTSÆTTELSE ..................................................................................................... 61
9.15 HYPERCARE .......................................................................................................... 61
9.16 SAMARBEJDE OG RAPPORTERING ............................................................................... 61
9.17 TEST ................................................................................................................... 62
10 KRAV TIL DRIFT, VEDLIGEHOLDELSE OG SUPPORT (YDELSERNE).............................. 63
10.1 OVERORDNEDE KRAV .............................................................................................. 63
10.2 ETABLERINGSYDELSEN ............................................................................................. 64
10.2.1 ETABLERING AF LOKALITETER........................................................................................... 64
10.2.2 ETABLERING AF KOMMUNIKATIONSINFRASTRUKTUR............................................................ 64
10.2.3 ETABLERING AF PROGRAMMEL ........................................................................................ 64
10.2.4 ETABLERING AF PROCESSER FOR DRIFTSAFVIKLING OG SUPPORT ............................................ 64
10.2.5 ETABLERING AF PROCESSER OG VÆRKTØJER TIL VEDLIGEHOLDELSE AF SYSTEMET ...................... 64
10.3 VEDLIGEHOLDELSE AF SYSTEMET ................................................................................ 65
10.3.1 VEDLIGEHOLDELSE AF SYSTEMET ..................................................................................... 65
Side 5 af 76
10.4 LØBENDE DRIFT ..................................................................................................... 67
10.4.1 LOKALITETER ................................................................................................................ 67
10.4.2 INFRASTRUKTUR OG MASKINEL ........................................................................................ 67
10.4.3 PROGRAMMEL ............................................................................................................. 67
10.4.4 TEKNOLOGISK RÅDGIVNING, RAPPORTERING OG SUPPORT.................................................... 67
10.4.5 DOKUMENTATION OG KONFIGURATIONSSTYRING ............................................................... 67
10.4.6 SIKKERHED OG BEREDSKAB ............................................................................................. 68
10.4.7 OVERVÅGNING ............................................................................................................. 68
10.4.8 OPHØRSBISTAND .......................................................................................................... 68
10.4.9 SERVICE OPERATION...................................................................................................... 68
10.4.9.1 Supportløsningen .................................................................................................. 68
10.4.10 INCIDENT MANAGEMENT .............................................................................................. 68
10.4.11 PROBLEM MANAGEMENT ............................................................................................. 69
10.4.12 CHANGE MANAGEMENT ............................................................................................... 69
10.4.13 RELEASE MANAGEMENT ............................................................................................... 70
10.4.14 EVENT MANAGEMENT - OVERVÅGNING .......................................................................... 70
10.4.15 CONFIGURATION MANAGEMENT ................................................................................... 70
10.4.16 CAPACITY MANAGEMENT ............................................................................................. 70
11 FREMTIDIGE TILPASNINGER TIL SYSTEMET ............................................................. 71
12 OPTIONER............................................................................................................. 72
12.1 OPTION PÅ INDBETALINGSLØSNING, HVOR BORGER / VIRKSOMHED KAN BETALE VIA ANDRE
KANALER END FI-KORT OG BS-OPKRÆVNING ........................................................................... 72
12.2 OPTION PÅ OPRETTELSE AF AFDRAGS- ELLER MODREGNINGSORDNING VIA
SELVBETJENINGSLØSNING PÅ BORGER.DK................................................................................ 72
12.3 OPTION PÅ KOMMUNIKATION DIREKTE MED KMD AKTIV OG KOMMUNALT YDELSESSYSTEM (KY)
75
Side 6 af 76
1
Vejledning til Tilbudsgiver
Bilaget skal ikke ændres af Tilbudsgiver.
Tabel 1 Vejledning til Tilbudsgiver
Side 7 af 76
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
Indhold
Bilag 3A.1 (Kravliste)
Bilaget indeholder en liste over ATP’s krav til Leverancen,
hvor Leverandøren skal angive opfyldelsesgrad mv. i overensstemmelse med vejledningen til bilaget. Bilaget skal for
en del krav læses i sammenhæng med de øvrige underbilag.
Bilag 3A.2 (Løsningsflows)
Bilaget indeholder de løsningsflows, der indgår i de forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af debitorrelaterede forhold.
Bilag 3A.3 (Aktivitetsbeskrivelser)
Bilaget indeholder de løsningsflows og aktivitetsbeskrivelser,
der indgår i de løsningsflows og forretningsprocesser, som er
forbundet med indberetning, administration og udbetaling af
debitorrelaterede forhold.
Bilag 3A.4 (Informationsmodeller)
Bilaget indeholder UML modeller af de væsentligste
forretningsmæssige begreber og de informationer, som
vedrører indberetning, administration og udbetaling af
debitorrelaterede forhold.
Bilag 3A.5 (Regel- og beslutnings-
Bilaget indeholder en oplistning af de regler Debitorsystemet
modeller)
skal kunne understøtte og en overordnet forretningsmæssige
beskrivelser heraf.
Bilag 3A.6 (Integrationer)
Bilaget indeholder uddybende information om de integrationer, som Leverandøren skal etablere fra Systemet.
Bilag 3A.8 (Oversigter)
Bilaget indeholder følgende oversigter:
•
Brevoversigt
•
Akt – LF - DM
•
Rolleoversigt
•
Informationsbehandling_gui
Tabel 1 Behovsopgørelsen og tilhørende underbilag
Side 8 af 76
2.2
Farveanvendelse på arkitekturdiagrammer
Der optræder en række arkitekturdiagrammer i bilagsmaterialet. Der er anvendt en
farvekodning på tværs af alle disse figurer, som siger noget om, hvem der ejer eller
anskaffer et system/komponent. Betydningen af farverne fremgår af Figur 1.
Figur 1: Farveanvendelse på arkitekturdiagrammer.
Side 9 af 76
3
Den samlede forretningsmæssige løsning
Beskrivelsen af den forretningsmæssige løsning for debitor tager udgangspunkt i
brugerne af Systemet; borgere og virksomheder, kunderådgivere, Forretningsadministratorer og deres behov. Brugernes behov er i det efterfølgende skildret gennem:
-
Brugerne af Systemet – hvornår og hvordan møder brugerne Systemet
-
Forretningsudbudsarkitekturen – systemer, parter og sammenhænge
-
Komponentmodellen – hvad Systemet skal understøtte
-
Forretningsprocesser – tekniske understøttelse af de forretningsmæssige behov
-
Informationsarkitekturen – beskrivelse og gruppering af forretningsmæssige
begreber
3.1
Brugerne af Systemet
Udgangspunktet for brugergrupperne af Systemet er forskelligt, og de tre typer af
brugere har forskellige behov. De forskellige brugeres anvendelse af Systemet er
beskrevet i de følgende afsnit.
3.2
Borgerne og virksomhederne
Borgernes og virksomhedernes primære behov er, at det skal være nemt at betale
og nemt at kommunikere med Udbetaling Danmark.
Borgerne og virksomhederne skal opleve at kommunikationen fra debitorfunktionen
er sammenhængende og meningsfuld i forhold til den øvrige kommunikation, de
har med både Udbetaling Danmark og andre myndigheder.
Borgerne og virksomhederne skal modtage korrekt væsentlig information via opkrævningerne og rykkerne, og har borgerne og virksomhederne behov for yderligere information, skal de kunne orientere sig via borger.dk og virk.dk.
Via borger.dk og virk.dk skal borgerne og virksomhederne endvidere kunne sende
målrettede spørgsmål og ønsker i forhold til de oftest forekommende spørgsmål.
3.3
Kunderådgiverne
Kunderådgiverne skal have alle de relevante oplysninger for en konkret debitor til
rådighed, når de betjener denne via telefonen. Relevante oplysninger er primært
oplysninger om borgeren eller virksomheden, samlet restance og status på de enkelte krav. Overblikket skal nemt kunne tilpasses kunderådgiverens behov af-
Side 10 af 76
hængig af, hvad borgerens eller virksomhedens henvendelse vedrører således, at
den enkelte kunderådgiver oplever et overblik, der er tilpasset den konkrete Opgave / henvendelse.
Kunderådgiverne skal kunne tilgå de manuelle Opgaver via en opgaveindbakke,
hvor alle Opgaver er prioriteret. Opgaverne i opgaveindbakken skal desuden kunne fremfindes ved brug af sorterings- og udsøgningskriterier. Når kunderådgiveren
åbner en Opgave, skal alle relevante oplysninger og muligheden for at foretage
sagshåndtering være til stede straks (efter samme princip som telefonisk henvendelse).
Kunderådgiverne skal opleve, at det er nemt at behandle de manuelle Opgaver i
Systemet. Den oplevelse skal bl.a. skabes ved at skærmbilleder og funktioner er
tilpasset de forskellige typer af Opgaver, og ved at de oplysninger, der er nødvendige for at kunne løse den konkrete Opgave, fremgår tydeligt i Systemet.
Endvidere skal løsningen sikre en enkel systemdialog i behandlingen af Opgaverne, så det er nemt at indtaste de konkrete informationer de rigtige steder.
Der henvises i øvrigt til:
•
Bilag 2 (Situationsbeskrivelse), Kapitel 7, der beskriver arbejdet med manuelle processer. Kravene til kunderådgivernes brugergrænseflader er beskrevet med udgangspunkt i disse.
•
Bilag 3A.1 (Kravliste), der indeholder de konkrete krav til kunderådgivernes
brugergrænseflade
•
Bilag 7 (Servicemål), der indeholder de konkrete krav til svartider og tilgængelighed på kunderådgivernes brugergrænseflader.
3.4
Forretningsadministratorerne
Systemet skal understøtte, at en Forretningsadministrator kan rette og slette i regler, parametre, skabeloner og tekster, der styrer en automatiseret funktionalitet i
Systemet. Et eksempel herpå kan være, at man retter en parameter til igangsættelse af en automatisk kørsel fra 14 til 10 dage eller opretter en ny manuel brevskabelon.
Brugergrænsefladen skal være udformet, så den giver en logisk tilgang til dette arbejde og minimerer risikoen for fejl.
Der henvises i øvrigt til:
Side 11 af 76
•
Bilag 3A.1 (Kravliste), der indeholder de konkrete krav til Forretningsadministratorernes brugergrænseflade.
3.5
Roller og rettigheder
Det er et grundlæggende arkitekturkrav, at der anvendes roller til at styre adgang til
data og funktioner. Adgangstildelingen skal være baseret på en risikovurdering og
foregå i overensstemmelse med informationssikkerheds- og kontrolpolitikken i
ATP. Det er ATP som tildeler brugerne (inklusiv Leverandørens medarbejdere og
systembrugere) adgange, og adgangene skal kunne styres via TIM (IBM Tivoli
Identity management). I det følgende gennemgås grundprincipperne for opbygningen af rollerne, hvor risikovurdering, persondataloven, funktionsadskillelse, dokumentation og kontroller er vigtige elementer. Til sidst nævnes de forretningsroller,
som der på nuværende tidpunkt er identificeret behov for.
3.5.1
Risikovurdering
Risikovurderingen skal foretages i forhold til de konkrete processer, som den pågældende rolle giver adgang til. Generelt vurderes det, at følgende risici skal overvejes ved opbygningen og vedligeholdelse af roller: fejl i transaktionsdata, fejl i
stamdata, fejl i beregningsparametre, fejl i kørsler, overtrædelse af persondatalovens regler og besvigelser. Rolleopbygningen er (sammen med adgangstildelingen) en effektiv kontrol, når en risiko kan afdækkes ved funktionsadskillelse eller
ved at begrænse adgang til transaktioner og data.
3.5.2
Persondataloven
Persondataloven stiller krav til behandling af data. Ved behandling af data forstås
adgang til at se, registrere, slette eller arkivere data. Ved design og vedligeholdelse af roller skal det sikres, at der kun tildeles adgange til personfølsomme oplysninger, hvis der er et kontinuerligt arbejdsrelateret behov.
3.5.3
Funktionsadskillelse
ATP’s informationssikkerhedspolitik stiller krav om, at der skal være grundlæggende funktionsadskillelse mellem a) udvikling og vedligeholdelse af systemer, b) drift
Side 12 af 76
og c) ATP’s forretningsaktiviteter og brugerfunktioner. Dette betyder blandt andet,
at der ikke må tildeles IT roller til forretningen eller omvendt. Ved design af roller er
det således væsentlig, at forretningsopgaver ikke lægges i IT-roller, og IT-opgaver
ikke lægges i forretningens roller. Inden for ATP’s forretningsaktiviteter, skal der ligeledes etableres funktionsadskillelse, der sikrer, at samme person ikke alene kan
initiere, udføre og godkende transaktioner.
3.5.4
Dokumentation
Rollerne og de tilhørende rettigheder skal dokumenteres i en rolle-/rettighedsmatrix. I rolle-/rettighedsmatrixen skal rollerne stå nævnt vandret og de tilhørende
rettigheder lodret. Det skal for hver rettighed være angivet om der er tale om oprette-, læse-, opdatere- og/eller sletterettigheder. Matricerne skal til enhver tid holdes
opdaterede, så de altid afspejler virkeligheden. Rettighedstabellerne kan ændres
ved konstruktion af nye funktioner/transaktioner, ændrede funktioner eller nye forretningsmæssige behov. Der vil uvilkårligt ske ændringer, både som følge af udvikling af ny funktionalitet og som følge af forretningens ønsker om tilpasning af roller
og arbejdsfunktioner.
Roller bør ikke anskues enkeltstående, og derfor bør kombinationen af roller vurderes. Det er vigtigt, at der ikke tildeles roller, som er konfliktende. Konfliktende roller
skal derfor identificeres og dokumenteres.
3.5.5
Privilegerede roller
Leverandøren skal levere en beskrivelse af, hvilke privilegerede roller de ønsker til
deres egne medarbejdere. Beskrivelsen skal samtidig indeholde de funktioner,
som kan udføres af den enkelte rolle. Rollerne skal godkendes af ATP, men ansvaret for opdatering ligger hos leverandøren. Der skal være en revisionsmæssig gennemgang (intern audit) af, hvilke medarbejdere, der har hvilke roller, 2 gange årligt.
ATP’s sikkerhed er en revisionspåtegning i leverandørens regnskab.
Side 13 af 76
3.5.6
Forretningsroller
ATP har defineret et antal forretningsroller. Rollerne er ordnet i en matrix, der angiver, hvilke pakker af informationer fra debitorområdets informationsmodel den enkelte rolle skal have adgang til. Der skelnes mellem at: oprette (C), læse (R), opdatere og slette (CRUD), jf. bilag 3A.8 (Oversigter), fane Forretningsroller. Det er ikke
alle informationer i en pakke, som de enkelte roller skal have adgang til. I Etape II,
jf. bilag 1 (Tidsplan) skal leverandøren, som en del af Delleverancerne, i samarbejde med ATP specificere forretningsrollernes adgang til informationer på klasse- og
attributniveau og mappe dem til systemroller.
Side 14 af 76
4
Forretningsudbudsarkitekturen
Forretningsudbudsarkitekturen beskriver dels sammenhænge mellem de forskellige systemer, registre og parter i den forretningsmæssige løsning, dels den ønskede forretningsmæssige funktionalitet. Modellen og den efterfølgende forklarende
tekst tjener som introduktion til Debitorsystemet på et konceptuelt plan.
Figuren nedenfor viser de væsentligste elementer i forretningsudbudsarkitekturen.
Figur 2: Forretningsudbudsarkitektur for debitorløsningen
I den samlede forretningsmæssige løsning er Debitorsystemet illustreret ved udvalgte forretningskomponenter med blå farve. Denne del er specifik for Systemet til
administration af debitorfunktionalitet, mens de øvrige dele af figuren viser samspillet med omkringliggende systemer. For at bevare overblikket er kun udvalgte systemer illustreret i forretningsudbudsarkitekturen. I nogle tilfælde er systemer slået
sammen og repræsenteret ved én kasse, og konkrete systemnavne er navngivet
ved den primære funktionalitet, de leverer, frem for konkrete systemnavne. Vi henviser til bilag 3A.6 (Integrationer) for en komplet oversigt over de eksterne systemer, som Systemet skal integrere til.
Side 15 af 76
4.1
Automatiseret og manuel sagsbehandling
Denne del er selve fagsystemet, hvor man finder it-understøttelse til administration
af debitorfunktionalitet. De blå kasser repræsenterer forretningskomponenter, der
beskrives i afsnit 5. Fagsystemet skal betragtes som en hel løsning, hvor både automatiseret og manuel funktionalitet er placeret. Kunderådgiverne arbejder primært
i Systemet, og de løser stort set alle deres Opgaver her. Det er en forudsætning, at
sagsbehandlingen automatiseres i vid udstrækning for, at ATP kan realisere det effektiviseringspotentiale, der indgår i ATP’s business case. Dette er særdeles vigtigt
for de løsningsflows i bilag 3A.2 (Løsningsflow), der er kategoriseret som ’motorveje’ eller ’landevej, jf. bilag 2A (Sådan forretningsmodellerer vi i ATP).
Debitorsystemet indeholder den funktionalitet og sikrer adgang til de data, der er
nødvendige for at behandle en given Opgave. Dokumenter, journalnotater og digital post er placeret på sager og er journaliseret i fagsystemet.
Debitorsystemet skal understøtte ønsket om at gennemføre straight through processing (STP) i videst muligt omfang uden, at det går ud over kvaliteten af sagsbehandlingen. Princippet er, at sagerne behandles så automatisk som muligt i Systemet ud fra de oplysninger, der blandt andet hentes og modtages fra autoritative
registre eksempelvis Beriget Grunddata. I de tilfælde, hvor en sag ikke kan behandles automatisk ud fra de autoritative registre, borgerens oplysninger eller de
regler, der i øvrigt er defineret i Systemet, skal der oprettes en Opgave i opgaveindbakken. Opgaven fortæller en kunderådgiver, hvilke oplysninger på sagen, der
ikke kunne behandles automatisk. Kunderådgiveren løser Opgaven ved at kontrollere og konkludere disse oplysninger, og sagen afgøres herefter ved automatisk
behandling. Det er derved primært Systemet, der behandler debitorsagerne. Kunderådgiverne støtter op om behandlingen ved at konkludere på oplysningerne,
samt behandler de sager, der ikke kunne behandles automatisk.
4.2
Kanaler og Kommunikation
Her vises de kanaler, der bruges til kommunikation med omverdenen.
Hvis ATP ønsker at udstille generelle oplysninger omkring Debitor til borgere og
virksomheder skal dette ske via borger.dk og virk.dk.
En anden væsentlig del af løsningen er at sikre, at de digitale beskeder, der sendes, bl.a. indeholder nem og forståelig information, så det er tydeligt, hvad årsagen
til kravet er, samt hvordan man kan betale det.
Side 16 af 76
Derudover illustrerer forretningsarkitekturen også, at vi modtager fysisk og Digital
Post gennem hhv. ”Scanning Fysisk Post” og ”Digital Post”.
Afsendelse af post sker til Fjernprint, der videresender beskeder til Digital Post eller printer, kuverterer og afsender fysisk post, hvis modtageren er undtaget fra Digital Post.
4.3
Øvrige elementer i forretningsudbudsarkitekturen
De øvrige dele af forretningsudbudsarkitekturen er tværgående støttesystemer for
Udbetaling Danmark, komponenter eller registre, som fagsystemet skal have snitflader til. De tværgående dele understøtter interne behov for rapportering, forpligtelser i forhold til ekstern rapportering og udbetaling.
Bemærk at indkomstoplysninger fra årsopgørelser og forskudsopgørelser hentes/tilgås via KMD Indkomst, hvorimod lønoplysninger hentes via integration til
SKAT/eIndkomst.
En fuldstændig liste over integrationer findes i afsnit 8 IT arkitektur.
Side 17 af 76
5
Komponentmodel
Den funktionalitet, som Systemet skal besidde, beskrives i form af en Komponentmodel. Til forskel fra forretningsudbudsarkitekturen omhandler Komponentmodellen kun den fagspecifikke løsning.
Komponentmodellen illustrerer, hvordan Systemet er tænkt opdelt i forretningsmæssige logiske komponenter, der leverer beslægtet funktionalitet. Komponentmodellen og de efterfølgende komponentbeskrivelser har to formål:
•
At give et overblik over den funktionalitet Systemet skal indeholde
•
At gøre os i stand til at italesætte og kategorisere Systemets funktionalitet
fra et forretningsmæssigt perspektiv.
Leverandøren må gerne byde ind med forslag til en anden opdeling end den viste,
hvis det er mere fordelagtigt set ud fra Leverandørens systemopbygning. Det er
blot vigtigt, at leverandøren tydeliggør, hvordan løsningen samlet leverer den beskrevne funktionalitet i forhold til komponentmodellen.
Generelt skal de komponenter, som indeholder funktionalitet, der ændres hyppigt,
fx ved lov- og regelændringer, kunne ændres smidigt. Dette gælder eksempelvis
funktionalitet til håndtering af hændelser, beslutning om sager skal til manuel kontrol, ændring af parametre ift. opkrævning, rykning og modregningsregler. Derfor
skal komponenternes funktionalitet kunne ændres gennem skærmbilleder, hvor
ATP’s Forretningsadministratorer enkelt kan konfigurere regler og parametre til
regler.
Figuren nedenfor viser komponentmodellen for debitor.
Side 18 af 76
Figur 3: Komponentmodel
Komponentmodellen er inddelt i fem hovedområder:
•
Kanaler
•
Manuelt
•
Automatisk
•
Støtte komponenter
•
Ø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).
5.1
Kanaler
Denne gruppe af komponenter angiver, hvordan Systemet skal fungere sammen
med ATP’s postmodtagelse og Systemets selvbetjeningsløsning:
Side 19 af 76
5.1.1
•
Posthåndtering
•
Selvbetjening
Posthåndtering
Systemet skal kunne modtage digital og fysisk post fra borgere, virksomheder og
myndigheder.
Den digitale post hentes af en posthåndteringsleverandør, inden den overleveres til
Systemet gennem en snitflade. Samme posthåndteringsleverandør modtager fysisk post, som overleveres til Systemet ad samme snitflade.
Breve til borgere, virksomheder og myndigheder sendes via den fællesoffentlige
printløsning, og der anvendes i videst muligt omfang digital post.
5.1.2
Selvbetjening
Borger og virksomheder kan orientere sig vedrørende generel information omkring
opkrævninger mv. i relation til Udbetaling Danmark på hhv. borger.dk og virk.dk. og
kan sende beskeder til Udbetaling Danmark via disse kanaler.
5.2
Manuelt
Denne gruppe af komponenter understøtter kunderådgivernes daglige manuelle
sagsbehandling (jf. afsnit 3.3):
•
Opgaveindbakke
•
Tværgående overblik
•
Sagshåndtering
•
Manuelle breve
Disse fire komponenter udgør tilsammen kunderådgivernes primære arbejdsredskab. De er her beskrevet i separate komponenter, men skal ikke betragtes som
enkeltstående skærmbilleder. Deres funktionalitet kan med fordel integreres i
samme skærmbillede, så kunderådgiverne herved får mulighed for at udføre deres
arbejde på en effektiv måde. Den samlede funktionalitet, der er beskrevet her og i
bilag 3A.1 (Kravliste), skal være til stede i Systemet.
Komponenterne, som understøtter Forretningsadministratorerne i deres arbejde er
beskrevet i nedenstående komponenter (jf. afsnit 3.4):
•
Systemadministration
•
Regeladministration
Side 20 af 76
5.2.1
Opgaveindbakke
Udgangspunktet for det daglige arbejde for en kunderådgiver er opgaveindbakken.
Opgaveindbakken indeholder Opgaver, som er struktureret i arbejdspakker.
En Opgave kan bestå af behandling af fysisk post, digital post eller hændelser,
som systemet ikke kan håndtere automatisk.
En kunderådgiver skal kunne reservere og arbejde med en Opgave.
En afsluttet Opgave i opgaveindbakken fortsætter på det automatiske flow.
5.2.2
Tværgående Overblik
Systemet skal kunne præsentere et Tværgående Overblik, der samler alle relevante informationer om den enkelte borger eller virksomhed. Det Tværgående Overblik
er kunderådgiverens indgangsvinkel til Systemet ved telefonrådgivning.
Komponenten leverer en grænseflade til det Tværgående Overblik.
Formålet er at give kunderådgiveren mulighed for, ved ét enkelt opslag, hurtigt at
få et overblik over borgerens eller virksomhedens forhold. Fra det Tværgående
Overblik skal kunderådgiveren have mulighed for at få præsenteret yderligere detaljer om en sag og borgeren eller virksomheden.
Det Tværgående Overblik viser data fra både Systemet, Sags- og Dokumentindeks
og Ydelsesindekset (se afsnit 8.2 Systemkontekst).
5.2.3
Sagshåndtering
Denne komponent leverer en brugergrænseflade, hvorfra kunderådgiveren kan udføre den manuelle sagsbehandling, og hvor debitordata kan vises og redigeres.
Manuelt behandlede sager fortsætter i det automatiske flow efter endt manuel behandling.
5.2.4
Manuelle Breve
Denne komponent har ansvaret for at administrere og vedligeholde brevskabeloner
til udsendelse af manuelt udarbejdede breve. Disse breve sendes ad samme kanal
til Fjernprint som de automatisk genererede breve. Fjernprint styrer om brevet til
borgeren, virksomheden og / eller myndigheden skal sendes som fysisk post eller
digital besked.
Kunderådgiveren skal kunne generere et brev med udgangspunkt i prædefinerede
brevskabeloner, og Forretningsadministratoren skal kunne oprette nye skabeloner
samt rette i eksisterende.
Side 21 af 76
5.2.5
Systemadministration
Systemadministration er en brugergrænseflade, hvor man kan ændre forskellige
systemopsætninger som eksempelvis arbejdspakker, tekster, hjælpeinformation og
genvejstaster. Endvidere kan der ske oprettelse og efterfølgende konfiguration af
besked / brevskabeloner via brugergrænsefladen. Det er også via denne brugergrænseflade, at Forretningsadministratoren selv kan definere rapporter i Systemet.
Brugergrænsefladen skal være rettet mod brugere uden særlige tekniske forudsætninger.
5.2.6
Regeladministration
For ATP er det væsentligt, at Systemet er fleksibelt og robust for indførsel af nye
forretningsprocesser og ændret lovgivning. Vi forventer, at der sker en løbende tilpasning af regler for, hvad der håndteres automatisk, og hvad der skal behandles
manuelt. Det er væsentligt for optimeringen af arbejdsprocesserne, at disse tilpasninger kan ske smidigt og uden store implementeringsomkostninger.
Komponenten ”Regeladministration” indeholder fx informationer om, hvilke rykkerprocedurer, der skal anvendes på de forskellige kravtyper, modregningsadgange
ift. specifikke kravtyper, modregningsfunktionalitet ift. kravtyper samt tilsvarende
typer af regler, der er nødvendige for at gennemføre korrekt sagsbehandling.
Komponenten indeholder tillige de parametre, der enten indgår i de enkelte regler
eller selvstændigt styrer en given proces som eksempelvis tidspunktet for udsendelse af opkrævninger, rykkerprocedurer, definition af betalingsfrister.
Komponenten leverer en brugergrænseflade til at vedligeholde de regler, parametre og grænseværdier, der anvendes til at udføre validering, afgørelse (beslutning)
og håndtering af automatiske processer i Systemet ift. sagsbehandlingen.
Brugergrænsefladen skal være rettet mod brugere uden særlige tekniske forudsætninger.
I Regeladministration vedligeholdes også regler for, hvilke processer der skal
igangsættes, når konkrete hændelser indtræffer.
De konkrete krav til regel- og parameterstyring samt konfiguration af Systemet
fremgår af bilag 3A.1 (Kravliste).
Side 22 af 76
5.3
Automatisk
Denne gruppe af komponenter understøtter den automatiske sagsbehandling af
primært motorvejene og består af følgende komponenter:
5.3.1
•
Validering
•
Opkrævnings- og betalingsadministration
•
Håndter modregning
•
Rykning
•
EFI Håndtering
•
Håndter indbetaling
•
Dan Udbetaling
•
Afskrivning
•
Beskedhåndtering
Validering
Denne komponent har ansvaret for at validere inputdata såsom krav og indbetalinger til brug for opkrævning, udligning eller øvrig håndtering af allerede kendte krav.
Valideringen skal sikre konsistens i Systemets data.
Validering kan både ske på feltniveau i forhold til enkeltindtastninger, ved at vurdere sammenhænge mellem flere forskellige informationer og ved validering af modtagne data fra eksempelvis ydelsessystemerne validering sker tilsvarende, forinden
en manuel Opgave fortsætter i det automatiske flow.
5.3.2
Opkrævnings- og betalingsadministration
Komponenten registrerer opkrævningsdata og beriger dem med informationer om,
hvorvidt kravet skal til videre til direkte opkrævning hos borgeren eller virksomheden, eller om kravet skal betales via modregning i ydelsesudbetalinger i andre fagsystemer.
Komponenten registrerer og opretter endvidere flere hæftere ift. det enkelte krav i
de tilfælde, hvor der er hæftere på kravet.
Komponenten har ansvaret for at danne opkrævningerne på de forskellige krav,
som der skal ske opkrævning af. Efterfølgende gennemfører Systemet opkrævningen på det korrekte tidspunkt til de relevante personer eller virksomheder. Komponenten har ansvaret for, at det enkelte krav bliver opkrævet via den korrekte kanal.
Komponenten genererer uddata til digitale beskeder (opkrævninger).
Side 23 af 76
Alle ovenstående handlinger udfører Systemet ud fra regelsæt, der er implementeret i komponenten Regeladministration.
5.3.3
Håndter modregning
Denne komponent har ansvaret for at registrere data vedr. krav til modregning i
udbetalende fagsystemer og efterfølgende gennemføre korrekt modregning. Gennemførsel af modregning sker ved, at komponenten sender anmodning om modregning afsted til de udbetalende fagsystemer.
Komponenten har tillige ansvaret for at sikre, at der dannes uddata til digitale beskeder (aftalebrev, afgørelse) i de situationer, hvor det er påkrævet.
Ovenstående handlinger udføres ud fra regelsæt, der er implementeret i komponenten Regeladministration
5.3.4
Rykning
Denne komponent har ansvaret for at håndtere den videre proces ift. de krav, der
ikke er betalt. Det sker ud fra et regelsæt og en parameteropsætning, der er implementeret i komponenten Regeladministration, så der eksempelvis ikke dannes
rykkere på krav, der har et rykkerspær.
Komponenten registrerer rykkerdata og genererer uddata til digitale beskeder (rykkerbreve) samt Opgaver til opgaveindbakken.
Systemet vælger typen af rykkerskrivelse ud fra regelsæt, der er implementeret i
komponenten Regeladministration
5.3.5
EFI Håndtering
Komponenten har ansvaret for at oversende EFI sager til Restanceinddrivelsesmyndigheden (RIM) via EFI, når de skal registreres ift. mulighed for modregning i
overskydende skatteudbetaling, samt når de er inddrivelsesmodne og skal oversendes som inddrivelsessager. Restanceinddrivelsesmyndigheden forestår inddrivelse af gæld til det offentlige. Kompetencen til at inddrive restancer for det offentlige er delegeret til SKAT.
Komponenten har tillige ansvaret for at sikre korrekt håndtering af kravet ift. den efterfølgende kommunikation mellem Systemet og EFI på de konkrete sager.
Komponenten registrerer kommunikationsflow og indhold af kommunikationen.
Systemet vælger tidspunktet for oversendelsen af kravene til RIM via EFI og håndteringen af kommunikationsindholdet ud fra en parameteropsætning og et regel-
Side 24 af 76
sæt, der er implementeret i komponenterne Systemadministration og Regeladministration.
Komponenten har tillige ansvaret for at generere uddata til komponenten beskedhåndtering i forbindelse med oversendelsen af kravet til RIM via EFI. Systemet
vælger, om der skal dannes skrivelse ud fra et regelsæt, der er implementeret i
komponenten Regeladministration.
5.3.6
Håndter indbetaling
Komponenten har ansvaret for at registrere indbetalinger og sikre korrekt udligning
af de indbetalte beløb. Det sker ud fra et regelsæt, der er implementeret i komponenten Regeladministration.
Komponenten registrerer indbetalingsdata og genererer besked til de respektive
fagsystemer om modtaget indbetaling.
5.3.7
Dan Udbetaling
Komponenten skal samle og overføre udbetalinger til indenlandske- og udenlandske konti gennem NemKonto. Den registrerer udbetalingsdata og genererer udbetalingsfiler.
Komponenten genererer uddata til digitale beskeder (udbetalingsmeddelelse). Systemet vælger typen af udbetalingsmeddelelse ud fra et regelsæt, der er implementeret i komponenten Regeladministration.
5.3.8
Afskrivning
Denne komponent har ansvaret for at gennemføre afskrivning. Det sker ud fra et
regelsæt, der er implementeret i komponenten Regeladministration.
Komponenten registrerer data vedr. afskrivningen og genererer besked til de respektive fagsystemer om afskrivning af kravet.
5.3.9
Beskedhåndtering
Komponenten initierer udsendelse af beskeder til Fjernprint, som afgør om beskeden sendes som Digital Post eller fysisk brev til borgeren. Komponenten indsamler
informationer og genererer automatisk beskeden/brevet. På baggrund af retursvaret fra Fjernprint registreres den anvendte afsendelseskanal.
5.4
Støttekomponenter
Denne gruppe af komponenter varetager informationer om borgere og virksomheder fra autoritative registre samt sager og dokumenter:
•
Person- og Virksomhedsdata
Side 25 af 76
•
5.4.1
Sager & Dokumenter
Person- og Virksomhedsdata
Denne komponent har ansvaret for at hente og gemme person- og virksomhedsdata fra Beriget Grunddata. Komponenten udstiller disse informationer for de øvrige
komponenter i Systemet. Beriget Grunddata er et register der indeholder en række
oplysninger, som ikke kan fås fra de autoritative kilder, men som Udbetaling Danmark har fået fra personer, virksomheder eller andre myndigheder
Komponenten skal vedligeholde de specifikke persondata f.eks. partsrepræsentation, som brugere kan opdatere gennem Debitorsystemet. Komponenten skal
håndtere informationer fra Beriget Grunddata og informationer, som brugere har
opdateret i Systemet. Komponenten har tillige ansvaret for, at historiske data bevares og kan tilgås fra de andre komponenter.
5.4.2
Sager & Dokumenter
I Systemet bliver alle sags- og ydelsesinformationer gemt i Sager & Dokumenter.
Denne komponent er en datacontainer, 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, beskeder fra Digital Post,
breve, post, og andet bilagsmateriale, som ATP modtager eller selv udsender.
5.5
Øvrige Komponenter
Denne gruppe indeholder Systemets øvrige komponenter:
5.5.1
•
Sikkerhed
•
Rapporter
•
Jobafvikling
•
Økonomi
•
Hændelser
•
Afstemning
•
Arkivering
•
Indekssynkronisering
Sikkerhed
Sikkerhed har ansvaret for konfiguration og administration af sikkerhed, herunder
rolle og rettighedsstyring i forhold til de brugerrettede dele af Systemet.
Side 26 af 76
5.5.2
Rapporter
Rapporter har ansvaret for, at der kan dannes dataudtræk og genereres afleveringsfiler, så der kan dannes rapporter til interne ATP-systemer og eksterne rapporter til forskellige samarbejdsparter – primært offentlige instanser.
Ud over informationer på debitorsagerne leverer komponenten også informationer
om interne processer i Systemet, f.eks. hvor mange Opgaver, der er oprettet på
baggrund af en bestemt regel. Disse informationer anvendes til løbende driftsoptimering i ATP.
5.5.3
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.
5.5.4
Økonomi
Komponenten overfører posteringer til ATP`s ERP system i forbindelse med opkrævninger, ændringer til opkrævninger, indbetalinger, afskrivninger, udbetalinger,
ændringer til udbetalinger etc. Systemets kontonumre skal altid stemme overens
med de kontonumre, som anvendes i ERP, så sum-posteringer etc. placeres korrekt i forbindelse med en overførsel.
Samlet set sikrer denne dataudveksling, at regler til understøttelse af regnskabslovgivning samt gældende revisionskrav kan overholdes.
5.5.5
Hændelser
Hændelser har ansvaret for at styre et automatiseret flow i Systemet efter en given
ændring i interne eller eksterne registre eller ud fra et retursvar vedr. modregning i
ydelsesudbetalinger, som Systemet modtager fra de respektive fagsystemer.
Komponenten igangsætter den proces, der følger efter en given ændring i eksterne
eller interne registre eller retursvar fra fagsystemerne. Det sker på baggrund af de
regler, der er gældende for den aktuelle proces.
5.5.6
Afstemning
Afstemning leverer afstemningsdata fra Systemet til videre behandling.
Afstemning har ansvaret for at udtrække og samle afstemningsdata fra Systemet
for at sikre retvisende regnskab.
Side 27 af 76
Komponenten har endvidere ansvaret for at levere logning på data, som udsendes
til andre systemer, så der kan foretages afstemninger af grænseflader.
Komponenten har ligeledes ansvar for at foretage afstemning af interne dataflyt i
Systemet, såfremt sådanne finder sted.
5.5.7
Arkivering
Komponenten har ansvaret for sikre korrekt og lovmedholdelig arkivering af sager.
Dvs. sikre at Udbetaling Danmark overholder opbevaringspligten, og at lukkede
sager markeres til kassation på det rette tidspunkt. Efter udløb af opbevaringspligten skal Systemet automatisk gennemløbe sagerne og slette sager der ikke længere skal opbevares.
I det omfang der træffes beslutning om at der skal afleveres til Statens Arkiver skal
komponenten håndterer denne afleveringen af data.
5.5.8
Indekssynkronisering
Systemet henter sags- og ydelsesinformationer fra de fælleskommunale støttesystemer ”Sags- og dokumentindeks og Ydelsesindeks”.
Systemet skal levere sags- og ydelsesinformationer for debitorsager til Sags- og
dokumentindeks i det omfang, der er pligt til at udveksle oplysninger mellem myndighederne.
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 foretage
helhedsorienteret vejledning af borgeren på tværs af Udbetaling Danmark og
kommunernes opgavesnit. Dataudvekslingen anvendes tilsvarende i reglerne til afgørelser i det automatiske flow.
Side 28 af 76
6
Forretningsprocesser
Forretningsprocesserne beskriver den tekniske understøttelse af de forretningsmæssige behov, som Debitorsystemet skal understøtte.
For en detaljeret beskrivelse af forretningsprocesserne og de forskellige niveauer
henvises til bilag 3A.2 (Løsningsflow), mens den metodemæssige tilgang til forretningsmodellering i ATP er beskrevet i bilag 2A (Sådan forretningsmodellerer vi i
ATP).
6.1
Samlet procesoverblik
Processerne markeret med
i procesoverblikket angiver samtlige forretnings-
Debitor
mæssige processer, der benyttes i den samlede administration af debitor.
Figur 4 Samlet procesoverblik
Side 29 af 76
6.2
Kerneprocesser
Kerneprocesserne beskriver, hvordan Udbetaling Danmark indberetter, administrerer og udbetaler debitorrelaterede forhold. Kerneprocesserne er nedbrudt i Løsningsflow (LF), som er yderligere beskrevet nedenfor.
6.2.1
Kerneproces - Håndter indberetning 1.5.1
Processen håndterer opstart og indberetning af et krav til en borger eller virksomhed Kerneprocessen Håndter Indberetning består af følgende løsningsflow: LF –
Debitor - Opret krav 1.5.1.1.
6.2.1.1
LF – Debitor – Opret krav 1.5.1.1
Formålet med løsningsflowet er at modtage informationer om krav, der skal oprettes eller rettes, oprette eller tilpasse dem med udgangspunkt i de fremsendte informationer og efterfølgende berige de enkelte krav med yderligere informationer
ud fra definerede regler. Krav kan modtages automatisk fra Udbetaling Danmarks
øvrige fagsystemer eller oprettes manuelt, hvor der ikke er etableret en snitflade.
Informationerne, der er fremkommet dels ved modtagelsen af data, dels ved den
efterfølgende berigelse, anvendes til at styre, hvilket flow kravet efterfølgende skal
føres videre i.
Løsningsflowet igangsættes ved modtagelse og automatisk indlæsning af oplysninger fra et givent fagsystem, der sender data via en foruddefineret snitflade eller
ved en manuel indtastning af informationer omkring oprettelse af krav.
6.2.2
Kerneproces - Håndter løbende ændringer 2.5.1
Processen håndterer overordnet set, at ændringer til eksisterende sager kan modtages og behandles af Systemet. Håndter løbende ændringer består af følgende
løsningsflow: LF – Debitor - Håndter automatisk generede oplysninger 2.5.1.1.
6.2.2.1
LF – Debitor – Håndter automatisk generede oplysninger 2.5.1.1
Formålet med processen er at sikre, at Systemet kan håndtere ændringer vedr.
konkrete debitorer og krav.
Oplysninger om ændringer kan modtages via eksterne kanaler som eksempelvis
Nets samt via opdaterede informationer fra Beriget Grunddata eller ved henvendelse fra borger eller virksomhed.
Ved modtagelse af ændringer til debitoren eller kravet skal Systemet kontrollere,
om oplysningerne er tilstrækkelige og entydige til at fortsætte i det automatiske
Side 30 af 76
flow eller, hvorvidt der skal indhentes supplerende oplysninger fra borgeren. Ændringer til eksisterende sager opdateres i løsningsflowet eller sendes til relevant
håndtering i andet løsningsflow.
6.2.3
Kerneproces – Håndter drift 2.5.2
Processen håndterer overordnet set dannelse af opkrævninger, afdragsordninger –
herunder modregningsordninger, rykker og restantbehandling samt håndtering af
modtagne indbetalinger. Kerneprocessen består af løsningsflow: LF – Debitor Håndter Opkrævning 2.5.2.1, LF – Debitor - Håndter Afdragsordning 2.5.2.2, LF –
Debitor - Håndter indbetaling 2.5.2.3, LF- Debitor - Håndter rykker 2.5.2.4, LF –
Debitor – Håndter restance 2.5.2.5 og LF – Debitor - Håndter afskrivning 2.5.2.6.
6.2.3.1
LF – Debitor - Håndter Opkrævning 2.5.2.1
Formålet med løsningsflowet er at sikre, at der dannes opkrævninger til borgere og
virksomheder, og at disse udsendes via de korrekte kanaler.
Endvidere er formålet at sikre, at krav hvor debitor er død behandles korrekt ift.
anmeldelse til skifteretten eller boet.
Processen starter, når der er oprettet et krav, der ikke skal straksafskrives eller
håndteres via en modregningsordning.
Endvidere kan processen startes i forlængelse af registreringen af et dødsfald på
debitoren.
Opkrævningen til borgere og virksomheder kan sendes via flere kanaler. Hvis borgeren har tilmeldt sig betalingsservice vil opkrævningen blive sendt via Nets, og ellers vil de blive sendt som FIK-opkrævninger som digitale Beskeder.
Opkrævningerne til virksomheder skal både kunne sendes som en elektronisk faktura og som en almindelig opkrævning via de øvrige kanaler.
Såfremt der er flere hæftere på kravet, vil der også skulle sendes opkrævning til
den / de andre hæftere under forudsætning af, at dette er defineret i reglerne.
6.2.3.2
LF – Debitor - Håndter Afdragsordning 2.5.2.2
Formålet med processen er at sikre, at Systemet kan håndtere oprettelse og administration af afdragsordninger - både de afdragsordninger, der skal betales via
modregning i udbetalende ydelsessystemer, og de afdragsordninger, der skal opkræves via FIK eller BS.
Side 31 af 76
Processen starter ved, at der automatisk registreres data i systemet vedr. afdragsordningen, hvorefter det vurderes, hvorvidt den kan sendes videre til direkte automatisk oprettelse, eller om den skal håndteres som en manuel Opgave. Sidstnævnte vil være tilfældet, hvis ydelsestypen for kravet kræver subjektiv betalingsevnevurdering, før afdragsordningens form og størrelsen på afdraget kan fastsættes. Processen kan tilsvarende starte ved, at der sker en manuel indtastning af data vedr. afdragsordningen i Systemet.
Når en afdragsordning er oprettet, enten via manuel registrering eller via automatisk oprettelse, sikrer løsningsflowet, at der sker videre behandling af de fastlagte
afdrag via korrekt kanal. Afdragsordninger, der skal afdrages via modregning i
ydelsesudbetalinger, håndteres ved, at der sendes anmodning om betaling af afdraget via en besked direkte til det respektive fagsystem. Afdrag vedr. de øvrige
ordninger håndteres via løsningsflowet, der behandler dannelsen af opkrævninger
(LF – Debitor – Håndter Opkrævning 2.5.2.1.) Løsningsflowet sikrer endvidere, at
der sker korrekt videre håndtering af krav, såfremt der ikke sker forventet indbetaling af et modregningsafdrag.
Når et krav skal betales via modregning af afdrag i en ydelsesudbetaling sikrer flowet endvidere, at der sker registrering af kravet i EFI ift. modregning i eventuelle
overskydende skatter.
I forbindelse med oprettelsen af afdragsordningen udsendes Beskeder til borger eller virksomhed i form af brev vedr. frivillig aftale, afgørelse om modregning eller afgørelse om fastsættelse.
6.2.3.3
LF – Debitor - Håndter indbetaling 2.5.2.3
Formålet med processen er at modtage og udligne indbetalinger på krav tilknyttet
den enkelte debitor.
Endvidere håndteres modtagelse af de EFI-renter, som RIM videreafregner til fordringshaver (Udbetaling Danmark) også i dette flow.
Indbetalingen kan ske via flere forskellige kanaler, og udligningen sker med udgangspunkt i foruddefinerede udligningsregler.
Såfremt gennemførelsen af udligningen medfører, at der er en overskydende indbetaling, vil denne enten fremgå af en mellemværendeliste, hvorfra den kan vide-
Side 32 af 76
rebehandles, eller blive ændret til en udbetaling, der sendes videre via løsningsflowet, der håndterer udbetalinger (LF – Debitor – Håndter udbetaling 3.5.1.1).
6.2.3.4
LF – Debitor - Håndter rykker 2.5.2.4
Formålet med processen er at:
-
Danne rykkere til debitorer for de krav, der ikke er betalt eller
-
Sende kravet til manuel behandling, hvis rykkerprocessen for kravtypen er defineret til dette eller
-
Sende kravet til løsningsflowet, der håndterer modregningsordningerne (LF –
Debitor – Håndter afdragsordning 2.5.2.2), hvis der kan ske lovhjemlet modregning.
Processen starter ved en tidsbestemt kørsel, der udsøger de krav, der ikke er betalt, og hvor betalingsfristen er overskredet med et nærmere defineret antal dage.
Man må ikke sende et krav til inddrivelse (LF – Debitor – Håndter restance
2.5.2.5), hvis man ikke har udtømt alle egne muligheder ift. at få dækket kravet.
Der kan sendes forskellige rykkere afhængig af, hvilken kravtype der er tale om, og
afhængig af hvor det enkelte krav er i processen.
I forbindelse med dannelsen af rykker 1 skal der tilskrives og opkræves et rykkergebyr sammen med rykkeren, hvis dette er defineret i rykkerprocessen for den
konkrete kravtype.
Løsningsflowet sikrer endvidere, at der sker / kan ske registrering af krav i EFI ift.
modregning i eventuelle overskydende skatter.
6.2.3.5
LF – Debitor - Håndter restance 2.5.2.5
Formålet med processen er at sikre, at Systemet vurderer hvorvidt et krav, der har
fået tilsendt alle de definerede rykkere ift. rykkerprocessen:
-
Skal sendes til inddrivelse hos RIM via EFI eller
-
Automatisk oprettes som modregningsordning, fordi der er lovhjemlede ydelser
at modregne i
-
Eller indgå i arbejdspakke som manuel Opgave, fordi der kræves betalingsevnevurdering, før der kan træffes afgørelse om modregning
Efterfølgende sendes kravet videre i korrekt i flow ift. denne vurdering.
Side 33 af 76
Hvis der oprettes modregningsordninger eller Opgaver til manuel behandling i form
af betalingsevnevurderinger, fortsætter den aktuelle sag i LF – Debitor – Håndter
Afdragsordning 2.5.2.2.
Processen starter enten ved, at kravet udsøges automatisk i en tidsbestemt kørsel
eller ved, at en kunderådgiver manuelt vælger at oversende kravet til inddrivelse
ud fra et ønske fra borgeren.
Processen sikrer, at såfremt kravet ikke skal videre i Håndter afdragsordning, så
oversendes det til inddrivelse hos RIM via EFI, og der oprettes data ift. inddrivelsessagen i Systemet.
Når der sker overdragelse af kravet til EFI, skal der i nogle tilfælde ske orientering
til borgere. Processen sikrer at denne orientering dannes og sendes.
6.2.3.6
LF – Debitor Håndter afskrivning 2.5.2.6
Formålet med processen er at understøtte afskrivningen af krav, der ikke kan inddrives.
Processen starter hovedsageligt enten ved, at der modtages information om en afskrivning fra RIM via EFI, eller ved at et tilbagebetalingskrav, i forbindelse med oprettelsen af kravet, er beriget med information fra fagsystemet om, at kravet skal
straksafskrives.
Processen kan også startes ved, at en kunderådgiver manuelt igangsætter en afskrivning.
Udbetaling Danmark har som udgangspunkt ikke hjemmel til at eftergive gæld, og
beslutning omkring afskrivning kommer derfor som hovedregel fra RIM via EFI.
Orienteringen fra EFI om afskrivningen kommer som en automatisk information på
den enkelte inddrivelsessag, hvorefter kravet ikke længere består hos RIM. Konsekvensen heraf er, at Udbetaling Danmark tilsvarende skal gennemføre afskrivning
af kravet.
Afskrivning af krav kan både ske som en automatisk igangsat afskrivning på baggrund af eksempelvis nogle af afskrivningsinformationerne fra RIM, og som en afskrivning der igangsættes manuelt af en kunderådgiver.
Afskrivning vil blive gennemført automatisk, hvis kravet på oprettelsestidspunktet
er beriget med informationer fra fagsystemet om, at det skal afskrives med det
Side 34 af 76
samme. Det kan fx være tilfældet, hvis tilbagebetalingskravet er opstået som følge
af en kunderådgiverfejl i Udbetaling Danmark eller i andre tilfælde, hvis borger har
været i god tro ift. den oprindelige udbetaling af ydelsen.
Såfremt et krav ikke er sendt til inddrivelse, kan det forældes, hvis der ikke er sket
en forældelsesafbrydende handling. Det kan fx være tilfældet ved beløb, der ligger
under den bagatelgrænse, som RIM har ift., hvilke krav de vil modtage til inddrivelse. Disse krav udsøges, og afskrivningskørsel af pågældende krav vil efterfølgende blive iværksat.
Efter gennemført afskrivning dannes der automatisk besked om afskrivningen til
det fagsystem, der oprindelig har oversendt kravet til opkrævning eller afskrivning.
6.2.4
Kerneproces – Håndter udbetaling 3.5.1
Processen håndterer udbetaling af overskydende indbetalinger samt videreafregning af modtagne EFI-renter, herunder indberetning af renteudbetalinger til SKAT.
Kerneprocessen Håndter udbetaling består af løsningsflow LF – Debitor - Håndter
udbetaling 3.5.1.1.
6.2.4.1
LF – Debitor - Effektuer udbetaling – person 3.5.1.1.
Formålet med processen, er at udbetale overskydende indbetalinger til borger,
virksomhed eller myndighed samt videreafregne modtagne EFI-renter til borger.
Processen starter, når der er iværksat en udbetaling jf. LF – Debitor – Håndter indbetaling 2.5.2.3
Når den endelige udbetaling er opgjort og klar til afsendelse, skal Debitorsystemet
både generere en Besked til borgeren, virksomheden eller myndigheden samt sikre en korrekt bogføring i ATP ERP.
Side 35 af 76
7
Informationsarkitektur
Informationsarkitekturen fastlægger de forretningsmæssige begreber, som forretningen anvender og som Debitorsystemet skal indeholde i form af data. Begreber
og sammenhænge vises i UML Diagrammer, og begreberne defineres og kommenteres i tekst i de medfølgende bilag med kildehenvisning til begrebernes definition.
Udbetaling Danmark har modelleret de forretningsmæssige begreber i et hierarki af
begrebs- og informationsmodeller. Den Overordnede Begrebsmodel har det højeste abstraktions niveau og viser begreber fra hele Udbetaling Danmarks forretning.
Niveauet under den overordnede begrebsmodel er begrebsmodeller for hver af de
sagstyper, vi håndterer, en generisk begrebsmodel for det generelle sagsbegreb
samt en begrebsmodel for de grunddata vi registrerer for parter/aktører/ interessenter i sager. Hver begrebsmodel har en informationsmodel under sig, som detaljerer og beriger begrebsmodellen.
Informationsmodellerne præsenterer således den forretningsmæssige konceptuelle
information, der skal danne grundlag for leverandørens logiske og fysiske datamodeller af de systemmæssige informationer.
7.1
Overordnet begrebsmodel for Udbetaling Danmark
Udbetaling Danmark behandler forskellige typer af sager, som det fremgår af den
overordnede begrebsmodel for Udbetaling Danmark i Figur 6. Udbetaling Danmark
administrerer og udbetaler økonomiske ydelser til personer eller virksomheder.
Ydelserne kan være af typen pension, barseldagpenge, refusion til virksomhed, boligstøtte og familieydelse. Derudover opkræver vi børnebidrag i relation til familieydelser og tilbagebetalingskrav for alle ydelsesområderne, samt foretager Helhedsorienteret Kontrol.
Side 36 af 76
Figur 6: Overordnet begrebsmodel for Udbetaling Danmark
7.2
Begrebs- og informationsmodeller for Forretningsløsningen
Begrebs- og Informationsmodeller er forretningens modeller over de væsentligste
begreber og informationer, som Systemet skal kunne oprette, læse, ændre og slette. Modellerne er på et konceptuelt niveau. Begrebsmodellerne giver det overordnede overblik, og informationsmodellerne giver yderligere detaljering med angivelsen af attributter og relationer. Informationsmodellerne indeholder de begreber og
attributter, som aktivitetsbeskrivelser, beslutningsmodeller og datamodeller skal referere til i forbindelse med beskrivelsen af et sammenhængende system. Anvendelsen af modellerne er metodemæssigt afstemt med KOMBIT.
Begrebsmodellerne indgår ikke i udbudsmaterialet, da informationsmodellerne giver den tilstrækkelige information til leverandøren.
7.2.1
Dokumentation til leverandør
Informationsmodellerne er beskrevet i bilag 3A.4 (Informationsmodeller) både i diagramform og i rapportform, hvor diagrammer, logiske samhørende enheder, begreber/klasser og attributter er beskrevet med definition, kildehenvisning og relevante kommentarer.
Debitorsystemet er beskrevet i:
•
Informationsmodel Debitor
•
Informationsmodel Sag
Side 37 af 76
•
Informationsmodel Beriget Grunddata
Informationsmodellen for Beriget Grunddata er vedlagt, idet den viser hvilke informationer, der er til rådighed i Debitorsystemet for Person, Virksomhed og Myndighed.
Den metodemæssige tilgang til begrebs- og informationsmodellering i ATP er beskrevet i bilag 2A (Sådan forretningsmodellerer vi i ATP).
7.2.2
Informationsmodel Sag
Informationsmodellen for Sag indeholder de generelle sagsbegreber og deres relationer. Begreberne er grupperet i logiske samhørende enheder, hvor de vigtigste er
Sag, Sagsdokumentation og Part. Disse beskrives kort nedenfor.
7.2.2.1
Sag
Sag er defineret i den fællesoffentlige OIO standard ”Specifikation af serviceinterface for sag” http://digitaliser.dk/resource/1567587 sådan:
”Sag forstås som en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces,
typisk til administrative formål, herunder til at træffe afgørelser.
En sag består af et antal dokumenter, der vedrører det samme begivenhedsforløb.
Et dokument kan indgå i flere sager, dvs. have relation til flere begivenhedsforløb”
Udbetaling Danmark har valgt at definere en sag sådan:
”En sag er en samling af sammenhørende dokumenter og øvrige sammenhørende
oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces, typisk til
administrative formål, herunder til at træffe afgørelser”
Udbetaling Danmarks sagsbegreb betyder, at en person, virksomhed eller myndighed har én sag i et ydelsesområde, som dækker hele forløbet for vedkommende. I
Debitor oprettes der således en sag på parten, dvs. person, virksomhed eller myndighed, der refererer til alle underliggende Debitorsager, således at en person på
sin sag kan have én Debitorsag vedr. Børnetilskud, Børne- ungeydelse og Underholdsbidrag.
Vi samler dokumenter, data, information om en afgrænset arbejdsproces i en sag.
Sagen er således en digital hængemappe for dokumentation og en sag kan fremsøges ved hjælp af forskellige nøgler, som identificerer denne. I Debitor samles
Side 38 af 76
dokumenter på Debitorsagen, som vedrører det eller de konkrete krav, der er overført fra de udbetalende ydelsesområder i forbindelse med en Afgørelse.
7.2.2.2
Sag - Nøgler og Egenskaber
Udbetaling Danmarks sag er modelleret efter OIO Specifikation for Sag version 1.2
og har dermed følgende nøgler:
Beskrivelse
Værdisæt
Obl.
Betegnelse
Primær nøgle, en teknisk nøg-
UUID
ja
Sag ID
Tekst
Ja
BrugervendtNøgle
Frit sagsnummer
Tekst
Ja
Sagsnummer
Officiel sagstitel, der kan an-
Tekst
Ja
Titel
Tekst
Ja
Beskrivelse
le som er unik
Brugervendt identifikation, der
er unik inden for myndigheden.
vendes i forbindelse med åbne
dagsordenspunkter. Dette er
også dokumentets objektnavn,
jf. ”Generelle egenskaber for
serviceinterfaces på sags- og
dokumentområdet”.
Sagsbeskrivelse i fri tekst. Evt.
supplerende beskrivelse af
indhold og formål.
Tabel 2: Nøgler for "Sag"
Disse attributter, som dækker alle sagstyper, nedarves, og hver sagstype har yderligere attributter, som er specifikke for typen.
7.2.2.3
Sagens oprettelse og livsforløb
En Debitorsag oprettes
•
Ved modtagelse af et krav fra et udbetalende fagsystem
•
Ved oprettelse af et krav ud fra manuel indtastning i Systemet
Debitorsagen sluttes først, når der er sket fuld udligning ved indbetaling af det eller
de underliggende krav, eller hvis kravene er blevet afskrevet. Sagen på parten vil
således være åben, så længe der er krav på Debitorsager, der ikke er udlignet eller
Side 39 af 76
afskrevet. Debitorsagen sluttes på baggrund af de regler der er defineret i kassationskoden, som kan være forskellig alt efter sagstype.
Sagens tilstand kan skifte frem og tilbage mellem de forskellige værdisæt i løbet af
levetiden.
7.2.3
Part
Hver sag i Udbetaling Danmark har én part tilknyttet, og vi har derfor ikke behov for
begreberne primær og sekundær part. En part kan være en person, virksomhed eller myndighed i Debitor. En part har ret til aktindsigt i sin egen sag.
7.2.4
Sagsdokumentation
Systemerne for de enkelte ydelsesområder har ansvaret for sagen gennem hele
sagens levetid fra oprettelsen, over ændringer på sagen, til sagen sluttes – dette
gør sig også gældende for fagområdet Debitor. Det er det enkelte Systems ansvar
at sørge for at vedligeholde Rammearkitekturens Sags- og dokumentindeks (se
snitfladerne DSDI1 – Udstil oplysninger i Sags- og dokumentindeks) samt rettidig
synkronisering, således at indeks til en hver tid afspejler systemet.
Systemet skal ligeledes sikre, at data vedligeholdes – alt hvad der vedrører sagen,
journalnotater, Beskeder, digitale henvendelser, scannende dokumenter samt
journalisering af henvendelser.
7.2.5
Informationsmodel Debitor
Informationsmodellen for Debitor indeholder de begreber, der er relevante for Debitorløsningen, samt deres indbyrdes relationer. Begreberne er grupperet i Klasser,
hvor de vigtigste er debitorsag, krav, opkrævning, indbetaling, afskrivning, udbetaling, rykker, modregningsordning, afdragsordning, inddrivelsessag og modregningssag. Disse beskrives kort nedenfor.
7.2.5.1
Debitorsag
En Debitorsag er en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere den arbejdsproces,
der følger, når der i et ydelsesområde er truffet en afgørelse, som danner et eller
flere krav hos Debitor.
7.2.5.2
Krav
Krav er de tilbagebetalingskrav eller bidragskrav, som Debitor præsenterer for personer, virksomheder eller myndigheder som følge af afgørelser truffet i ydelsesområderne eller i området, der varetager opgaven omkring helhedsorienteret kontrol.
Side 40 af 76
En Debitorsag kan indeholde flere krav. Debitorsager af typen underholdsbidrag
kan således indeholde flere krav vedrørende det samme barn.
7.2.5.3
Opkrævning
En opkrævning er en fysisk eller digital præsentation af et eller flere krav til en part.
Opkrævninger indeholder altid en unik identifikation, et eller flere tekststykker der
specificerer opkrævningen og tilhørende informationer om den videre proces ved
manglende betaling, minimum et beløb og en sum samt en frist for rettidig betaling.
7.2.5.4
Indbetaling
En indbetaling er modtagelse af pengebeløb fra en part via kendte indbetalingskanaler. Indbetalinger sker med henblik på at udligne et krav, som parten er blevet
præsenteret for via en opkrævning, rykker, afdragsordning, mv. indbetalinger matches og udlignes automatisk mod kendte krav, hvor det er muligt ift. definerede udligningsregler.
7.2.5.5
Afskrivning
En afskrivning er en bortpostering af et krav, som ikke længere kan gøres gældende overfor parten.
7.2.5.6
Udbetaling
En udbetaling er overførelse af et pengebeløb til en part.
7.2.5.7
Rykker
Der fremsendes rykkere i tilfælde af, at der ikke er modtaget betaling for krav inden
fristen for rettidig betaling. Rykkeren er en påmindelse om betaling og indeholder
altid en unik identifikation, et eller flere tekststykker, der specificerer rykkeren og de
tilhørende informationer ift. videre proces ved manglende betaling, minimum et beløb og en sum samt en betalingsfrist. Håndtering af rykkere er defineret ud fra forretningsmæssige processer, regler og parametre.
7.2.5.8
Modregningsordning
En modregningsordning er en aftale om at et krav skal betales via modregning i
ydelsesudbetalinger. Modregningsordningen kan både opstå som følge af, at der
er indgået en frivillig aftale mellem parten og Udbetaling Danmark om modregning,
eller den kan opstå som følge af, at Udbetaling Danmark eller en kommune har
truffet afgørelse om modregning. Modregningsordningen sikrer at anmodning om
betaling sendes til det ydelsessystem, som modregningen skal ske i. Via modregningsordningen kan der både sende anmodninger på at få modregnet dele af kra-
Side 41 af 76
vet (svarende til principperne for en afdragsordning) eller det fulde krav. Det afhænger af, hvad aftalen eller afgørelsen indeholder i relation til beløbet.
7.2.5.9
Afdragsordning
En afdragsordning er en opsplitning af krav i et antal afdrag. Afdragsordninger kan
både opstå som en frivillig aftale, der bliver indgået mellem parten og Udbetaling
Danmark, eller den kan opstå som følge af, at Udbetaling Danmark træffer afgørelse om fastsættelse af afdrag.
7.2.5.10 Inddrivelsessag
En inddrivelsessag er et krav der sendes til RIM via EFI. Kravet sendes når en part
ikke har indbetalt et eller flere skyldige krav i tide, og når Udbetaling Danmarks egne rykkermuligheder for det pågældende krav er udtømte. Kravet kan også oprettes, hvis parten selv ønsker, at der skal oprettes en inddrivelsessag eller for nogle
kravtyper, hvis der allerede ligger en inddrivelsessag på Debitorsagen. Med oprettelsen af en inddrivelsessag beder Udbetaling Danmark RIM om at inddrive kravet
ved brug af de inddrivelsesadgange, som de har til rådighed via Inddrivelsesloven.
Når RIM har inddrevet kravet eller dele heraf sender de beløbet til Debitorsystemet.
7.2.5.11 Modregningssag
En modregningssag er et krav, der oprettes og sendes til RIM via EFI. Sagen oprettes når en part ikke har indbetalt rettidigt. Sagen kan også oprettes selv om parten ikke har modtaget en opkrævning med en betalingsfrist. Det vil være tilfældet
ved nogle af de modregningsordninger, der bliver oprettet. Selv om man har indgået en aftale om afdrag eller modregning vil man stadig får oprettet en modregningssag hos RIM via EFI for nogle af kravtyperne. Med oprettelsen af en modregningssag fortæller Udbetaling Danmark RIM, at parten har et ubetalt krav til en offentlig myndighed, og såfremt der sker udbetaling af overskydende skatter eller
lign., skal pengene dække det ubetalte krav, før der sker en evt. restudbetaling til
parten. Når RIM har modregnet et beløb i en udbetaling til parten videresender de
beløbet til Debitorsystemet på modregningssystemet. Indbetalingen indeholder også information om, hvilken type udbetaling RIM har modregnet beløbet i.
Side 42 af 76
8
IT arkitektur
Dette kapitel præsenterer:
1. IT-udbudsarkitekturen. Her præsenteres hvilke it-systemer, der skal indgå i
den samlede forretningsløsning, som skal være etableret på Overtagelsesdagen
2. System kontekst. Her præsenteres integrationerne, der skal etableres fra Systemet samt de eksterne services som Systemet skal etablere og udstille.
3. Integrations-infrastrukturen. Her beskrives overordnet den tekniske infrastruktur omkring integrationerne.
8.1
IT-udbudsarkitekturen
I det følgende præsenteres hvilke it-systemer, der skal indgå i den samlede Forretningsløsning, som skal være etableret på Overtagelsesdagen.
IT-arkitekturen understøtter forretningsarkitekturen ved at udmønte de forretningsmæssige behov i et konkret systemlandskab. IT-arkitekturen bygger videre på og
konkretiserer forretningsarkitekturen i forhold til hvilke systemer og registre, der
indgår i løsningen. Endvidere angives de eksterne systemer og parter, som skal
modtage-/levere data fra Systemet, således at det fulde omfang af snitflader klarlægges.
Den interne IT-arkitektur for Systemet skal beskrives af Tilbudsgiver i bilag 3B
(Løsningsbeskrivelse).
IT-udbudsarkitekturen vil være en del af en transitionsplan mod målarkitekturen
beskrevet i bilag 3 (Leverancebeskrivelse). Det udmønter sig dels ved, at ikke alle
de indgående systemer vil blive benyttet i deres endelige form, og dels ved at der i
Systemet indgår enkelte eksisterende systemer fra KMD, som er nødvendige. Der
vil således i IT-udbudsarkitekturen indgå en række eksisterende IT-systemer fra
KMD, som kun skal benyttes i en periode frem til den endelige IT-målarkitektur kan
realiseres.
IT-udbudsarkitekturen fremgår af Figur 7 og forskellene i forhold til ITmålarkitekturen beskrives kort i det følgende.
Side 43 af 76
Figur 7: IT-udbudsarkitekturen for den samlede Forretningsløsning for administration af Debitor.
Udbetaling Danmark systemer
Debitorsystemet indgår i den række af systemer, som bliver konkurrenceudsat af
ATP. Debitorsystemet indgår i den overordnede målarkitektur for Udbetaling Danmark, men vil på udbudstidspunktet integrere med enkelte systemer, som er midlertidige i forhold til målarkitekturen.
Midlertidige systemer
Det er i udbudsmaterialet beskrevet som option, at Debitorsystemet skal kunne integrere til KY og KMD Aktiv i en periode. Derudover benytter Debitorsystemet KMD
Indkomst i en interimsperiode, indtil SKAT Årsopgørelse kan udstilles som en snitflade.
Fagsystemer
Figur 7 viser et antal Udbetaling Danmark fagsystemer (Pension, Boligstøtte, Familieydelse m.v.) Debitorsystemet skal integrere med de nye systemløsninger til disse områder, ligesom Debitorsystemet skal kunne integrere til evt. fremtidige fagsystemer.
Side 44 af 76
Interne tværgående støttesystemer
Til levering af person- og myndighedsoplysninger skal benyttes et register - Beriget
Grunddata, som etableres i Udbetaling Danmark. Dette system skal bl.a. sikre, at
”berigelser” af persondata fra de autoritative registre kan deles på tværs af Udbetaling Danmarks ydelsesområder. Beriget Grunddata skal dog i målarkitekturen erstattes af den fælleoffentlige datafordeler.
Områdespecifikke systemer og registre
De områdespecifikke systemer og registre er de systemer, som kun indgår i administrationen af debitorområdet.
Nets benyttes som en af kanalerne til opkrævning og indbetaling af krav fra Udbetaling Danmarks fagsystemer.
Visse virksomheder opkræves som alternativ via eFakturering. Fakturaer skal sendes på baggrund af EAN nummer.
Debitorsystemet anvender desuden Pengeinstitutternes Bogføringscentral (BFC) til
at modtage indbetalinger via bank-til-bank overførsler.
Fællessystemer og registre
Debitorsystemet udveksler data med SKAT, dels ved modtagelse af formueinformationer fra SKAT og indberetning af renteoplysninger til SKAT, men i særdeleshed ved integration til SKAT’s EFI (Et Fælles Inddrivelsessystem), som anvendes
til modregning i overskydende skat samt inddrivelsen af Udbetaling Danmarks
krav, når egne rykkermuligheder er udtømte.
NemKonto anvendes til udbetalinger, f.eks. tilbagebetalinger af overskydende indbetalinger eller videreafregning af modtagne EFI-renter.
Alle øvrige områder af IT-udbudsarkitekturen er som beskrevet i IT-målarkitekturen
i bilag 3 (Leverancebeskrivelse).
8.2
Systemkontekst og integrationer
Nedenfor præsenteres systemkonteksten for Debitorsystemet. Hvor ITudbudsarkitektur-diagrammet siger noget om hvilke systemer, der samlet set indgår i Debitorsystemet men ikke noget om, hvordan de er forbundet, illustrerer systemkonteksten, hvilke systemer der skal integreres med Debitorsystemet. Systemkonteksten holdes på logisk niveau, og infrastruktur komponenter er ikke med-
Side 45 af 76
taget her. Disse infrastrukturkomponenter beskrives i stedet i afsnit 8.4 Integrationer og infrastruktur.
På system kontekst diagrammet er hver integration tildelt et ID ud fra mønsteret IntegrationsID = <ydelsesområdeforkortelse ”P”><3-bogstavs systemforkortelse><fortløbende nr.>.
Fra aktivitetsbeskrivelser og fra krav er der refereret til integrationsID’et.
Systemkonteksten er illustreret på Figur 8.
Figur 8: Systemkonteksten for Debitorsystemet. Diagrammet viser alle de systemer, som Debitorsystemet skal integrere til. Figuren viser ikke infrastruktur-komponenter, men udelukkende applikationer på
logisk niveau.
Alle integrationerne er listet i nedenstående tabel 5.
Integrationspart
IntegrationsID Integrationsnavn
ATP-systemer
ATP ERP
DERP1
Posteringer til ERP
ATP Afstemning
DAAF1
Afstemningsdata til ATP
ATP Datawarehouse
DDWH1
Data til datawarehouse
Side 46 af 76
Integrationspart
ATP idM & idP
DIDM1
Bruger- og rettighedsoplysninger fra ATP’s IdM
DIDP1
Login via ATP’s IdP
Udbetaling Danmark-systemer & eksterne services
Posthåndterings-leverandør (PHL)
Beriget Grunddata
DPHL1
Modtag indgående post
DPHL2
Send post til genjournalisering
DBGD1
Hent data fra Beriget Grunddata
Fagsystem (UDK Ydelsessystem)
DFSY1
Krav
DFSY2
Kravstatus
DFSY3
Modregningsanmodning
DFSY4
Modregningsstatus
DNET1
Opkrævning
DNET2
Indbetaling
DNET3
BS-aftale
NemKonto
DNEM1
Udbetaling
Bogføringscentral
DBFC1
Indbetaling
eFakturering
DEAN1
Opkrævninger sendt via EAN
Eksterne systemer
Nets
nummer
Fælleskommunale systemer
Sags- og dokumentindeks
DSDI1
Udstil oplysninger i Sags- og
dokumentindeks
Kommunernes Ydelsessystem
DKKY1
DKKY2
Modregningsstatus
Fjernprint
DFPR1
Send besked
Sikker Post
DSPT1
Send besked til myndighed
SKAT EFI
DEFI1
Fordringsindberetning
DEFI2
Fordringsstatus
DSKA1
Renteoplysninger
DKIN1
Forskudsopgørelse
DKIN2
Årsopgørelse
DKIN3
Formueoplysninger
Fællesoffentlige systemer
SKAT COR
Midlertidige systemer
KMD Indkomst
Side 47 af 76
Integrationspart
KMD Aktiv
DKAK1
DKAK2
Modregningsstatus
Tabel 4 Systemets integrationer
En detaljeret beskrivelse af hver integration er at finde i bilag 3A.6 (Integrationer).
Da systemintegrationerne kan ændre sig over tid, er det vigtigt, at der er løskobling
og klare grænseflader til systemerne. Ved løskobling forstås, at en given komponent ikke er afhængig af den konkrete implementering af en anden komponent,
men kun af systemgrænsefladen (data), som udstilles via ovenstående snitflader jf.
tabel 5. De konkrete krav til integrationer fremgår af bilag 03A.1 (Kravliste).
8.3
Integrationer og infrastruktur
Alle integrationer fra Debitorsystemet til andre systemer er som udgangspunkt
”punkt-til-punkt”. Det er leverandørens ansvar at etablere de enkelte integrationer
fra Debitorsystemet til den anden part i integrationen, samt at levere den nødvendige infrastruktur.
Leverandøren skal benytte den integrationsmetodik og -platform, som serviceudbyderen stiller til rådighed.
Side 48 af 76
9
Non-funktionelle krav til Systemet
Ud over de funktionelle krav til Systemet i bilag 3A.1 (Kravliste) har ATP en række
non-funktionelle krav til Systemet. Disse non-funktionelle krav er inddelt i en række
kravgrupper, som gennemgås i de følgende underafsnit.
Kravgrupperingen anvendt i dette bilag anvendes også i bilag 3A.1 (Kravliste) og i
bilag 3B (Løsningsbeskrivelse), så strukturen fremstår ensartet i de tre bilag.
9.1
Arkitektur
ATP har en række krav til de overordnede rammer for Debitorsystemet. Disse krav
fremgår af bilag 3A.1 (Kravliste), og kravene angiver ligeledes de arkitektoniske afgrænsninger, som Debitorsystemet skal efterleve.
9.1.1
Rammer for arkitekturen
Leverandøren skal sikre, at Debitorsystemet er fleksibelt opbygget, så Systemet
kan modificeres og videreudvikles i hele Systemets levetid uden unødige omkostninger eller unødige risici.
Som en dokumentation for Debitorsystemets fleksibilitet skal Leverandøren i bilag
3B (Løsningsbeskrivelse) indsætte en besvarelse på udvalgte cases, der omhandler fiktive, men dog realistiske, ændringer til Systemet.
9.1.2
Belastning og skalering
Systemet skal designes med skalerbarhed for øje, så det til enhver tid kan skaleres
til at håndtere et stigende/faldende antal brugere/hændelser, dokumenter og journalnotater. Med Bruger forstås såvel antallet af kunderådgivere som borgere.
Hændelser er de automatisk genererede ændringer, som bevirker, at Systemet udfører en foruddefineret handling, en beregning, en opkrævning eller ved at servicere en af snitfladerne jf. Systemkonteksten.
9.1.2.1
Krav modtaget fra Fagsystemer
Krav fra fagsystemer skal kunne modtages enkeltvis og på daglig basis. De enkeltvist afsendte krav skal være oprettet i Debitorsystemet inden for ganske kort tid
regnet fra tidspunktet, hvor de er afsendt fra fagsystemet.
Side 49 af 76
9.1.2.2
Opkrævningskørsler
Opkrævningskørslerne kører dagligt for nogle typer af krav og er en månedlig kørsel for andre typer af krav.
Volumen/antallet vil afhænge af de fagsystemer, som afgiver krav, men der vil i et
vist omfang være et fast mønster for hver kravtype og opkrævningskørsel. Bemærk
at opkrævninger for forskellige kravtyper kan have forskellige mønstre ift. året.
9.1.3
Modregninger
Krav, som skal betales via modregning i udbetalinger fra andre UDK fagsystemer
eller fra kommunale ydelsessystemer, vil have sit mønster efter modtagelsen af
krav.
9.1.3.1
Status på EFI Sager
Der er behov for en daglig opfølgning på udestående EFI sager.
9.1.3.2
Journaliser post på sagen
Al post digitaliseres og hentes via systemintegrationen til Posthåndtering. Posten
placeres på sagen ud fra de medfølgende metadata, som Posthåndteringsleverandøren har løftet ud af forsendelsen.
9.1.3.3
Dataudtræk og øvrig rapportering
Systemet skal være gearet til at levere de dataudtræk og rapporter, som er beskrevet i bilag 3A.1 (Kravliste), uden at det har betydning for kunderådgivernes systemoplevelse. Det vil sige at svartiderne jf. bilag 7 (Servicemål) er gældende, såfremt kørslen forekommer inden for kritisk forretningstid. At Systemet eller en bruger danner/henter en rapport, anses som værende en almindelig arbejdsrutine,
som foretages indenfor Kritisk forretningstid.
9.2
Design og applikationsstruktur
ATP har ligeledes en række krav til afgrænsningerne omkring designet af løsningen, som løsningen skal efterleve. Kravene fremgår af bilag 3A.1 (Kravliste), og er
rettet imod specifikke applikationsstrukturer, herunder integrationsmønstre, og angiver hvordan disse skal opbygges.
9.3
Logning
I forhold til omfanget og karakteren af logning i Systemet, har ATP en række krav.
Kravene definerer, hvilke informationer Systemet skal logge og skal føre til, at der
etableres sporbarhed, og at den gældende lovgivning efterleves, eksempelvis ved
kontrol af adgang til personfølsomme data.
Side 50 af 76
Logningskravene skal desuden sikre, at leverandøren kan dokumentere, hvordan
servicemål efterleves, ligesom de skal afhjælpe fejlsøgning og generel overvågning
af Systemet.
9.4
Systemfleksibilitet
ATP ønsker et System, som er fleksibelt og modulært opbygget, så fremtidige tilpasninger kan gennemføres ved konfiguration af processer, nye ydelsestyper, regler, kontroller og øvrige systemparametre. ATP anser systemfleksibilitet som en
væsentlig kilde til at minimere vedligeholdelsesomkostningerne for systemet.
9.5
Tilgængelighed
ATP ønsker et driftsstabilt System med høj grad af tilgængelighed og lave svartider. Kravene i bilag 3A.1 (Kravliste) fastsætter sammen med servicemålene i bilag
7 (Servicemål) kravene til Systemets tilgængelighed.
9.6
Datakonvertering
Dette afsnit fastsætter de overordnede vilkår for konvertering af data fra den Eksisterende Løsning (KMD Opus Debitor og tilhørende støttesystemer) til Debitorsystemet.
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 Debitorsystemet.
9.6.1
Konverteringskonceptet generelt
ATP er ansvarlig for, at der foreligger et prøveudtræk, så det er muligt for leverandøren at igangsætte prøvekonverteringen tidligt i forløbet. Dette sker for at få erfaring med både kompleksiteten og datakvaliteten. Endvidere afdækkes behovet for
manuelle/maskinelle korrektioner, inden data konverteres til Debitorsystemet.
Baseret på erfaringerne fra prøvekonverteringerne skal der etableres en drejebog
for konverteringen. Drejebogen skal indeholde de aktiviteter, som leverandøren
skal sikre i forbindelse med overgangen til Debitorsystemet (jf. figur 9). Der er primært fokus på opsætningen af diverse abonnementer (Beriget Grunddata, EFI,
m.v.).
Ved konverteringen skal data behandles ud fra et fast specificere regelsæt. Konverteringen gentages-/genafspilles igen og igen, indtil det kan verificeres, at alle informationer er konverteret korrekt over i Debitorsystemet.
Side 51 af 76
Alle data fra KMD Opus Debitor og øvrige KMD systemer, som indeholder information om debitorområdet, vil blive trukket ud og placeret på en FTP server. Dataudtrækket, begrebs-, informationsmodel og datamodel vil fremgå af bilag 2B (Eksisterende data).
Den endelige konvertering skal koordineres mellem KMD, ATP og leverandøren.
Det overordnede dataflow under konverteringen samt ansvarsfordelingen mellem
KMD og leverandøren er illustreret i figur 9.
Figur 9 Ansvarsfordeling og dataflow for konvertering af data fra Eksisterende Løsning til Debitorsystemet.
Udtræk af data:
Den Eksisterende Debitorløsning består af flere systemer, herunder støttesystemer. Der er således flere systemer, som indeholder data, der er relateret til debitorområdet.
Dataudtrækket fra Eksisterende løsning gennemføres af KMD og er aftalt i udfasningsassistancen. Udfasningsassistancen forefindes på ATP Udbudsportal.
Side 52 af 76
Mapning og transformering:
Leverandøren skal gennemføre mapning og transformering af data udtrukket fra
Eksisterende Løsning, således at data ensrettes Systemets informationsmodel,
samt stille de fornødne værktøjer til rådighed herfor.
Indlæsning og validering af data:
Leverandøren skal indlæse, validere og afstemme data i Debitorsystemet. Leverandøren er endvidere ansvarlig for at videredistribuere de fornødne data til øvrige
støttesystemer, hvori der skal loades eller konverteres data.
Aktiviteterne under Udtræk, Transformering, Indlæsning og validering uddybes
nærmere i de følgende afsnit. Leverandørens metode for transformering, indlæsning og validering vil fremgå af leverandørens konverteringsstrategi.
9.6.2
Udtræk af data
KMD leverer fuldt udtræk af alle de data fra KMD-systemer, som kan tænkes at
skulle bruges i den nye løsning. Data udtrækkes som filer og placeres på en FTPserver. Udtræk af data fra Eksisterende Løsning omfatter:
•
Systemdata fra KMD Opus Debitor. For KMD Opus Debitor vil data omfatte
både afsluttede og igangværende krav og sager samt eventuelt tilknyttede
opgaver.
•
Generelle sagsdata fra KMD Sag vedrørende debitorsager. Dette inkluderer
journalnotater og dokument metadata 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 dataudtrækket fra Eksisterende Løsning er overordnet
følgende:
•
Leverer detaljeret design og dokumentation af udtrækket
•
Bidrager til forståelse af eksisterende data
•
Leverer data fra systemerne i det format, der er overordnet beskrevet i bilag 2B
(Eksisterende data). Data leveres i samme kvalitet, som de har i systemerne i
dag.
•
Bidrager til den tværgående test af konverteringen, herunder at levere et prøveudtræk af produktionsdata.
Side 53 af 76
•
Bidrager til idriftsættelsesplan (ansvarlig for de aktiviteter, der skal foregå på
KMD’s side)
Leverancerne er yderligere beskrevet i udfasningsassistance kravspecifikation og
kravbesvarelse, som kan findes på ATP udbudsportal under Udfasningsassistance
(http://www.atp.dk/udbudsportal/udfasningsassistance). ATP vil fungere som kontakt-
punkt mellem KMD og leverandøren.
Leverandøren skal hente prøveudtræk og endeligt dataudtræk fra KMD’s FTPserver. FTP-serveren er yderligere beskrevet i udfasningsassistancens underbilag
og er vedlagt i bilag 3A.6a – Produkt og snitfladebeskrivlser\bilag_x_kmd_udfasningsassistance_ftp_infrastruktur.pdf. Leverandøren skal sørge for, at dataudtræk bliver slettet fra FTP-serveren efter afhentning.
Leverandøren skal verificere, at dataudtrækket fra KMD matcher den leverede dokumentation af udtrækket, samt at dataudtrækket overholder kravene fra udfasningsassistance-kravspecifikationen. Dette skal ske på tidspunktet for modtagelse
af prøveudtræk fra KMD og skal ske ved indlæsning af de modtagne data. Herigennem kan det verificeres, om der er referentiel integritet mellem tabeller, og om
data har det beskrevne format. Ved mangler i leverancen fra KMD håndteres dette
af ATP.
9.6.3
Transformering af data
Leverandøren skal bortfiltrere eventuelt unødvendige data og transformere de data, som skal indlæses i Debitorsystemet i forbindelse med overgangen. Det vil bl.a.
sige, at data ensrettes med Debitorsystemets informationsmodel.
Leverandøren skal indledningsvist, gennem workshops med ATP, opbygge den
dataforståelse, som er nødvendig for at gennemføre den efterfølgende konvertering.
Leverandøren er ansvarlig for, at datamigrationen fra den Eksisterende Løsning til
Debitorsystemet 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 Debitorsystemet. Leverandøren
skal levere en beskrivelse af transformationen på informationsmodel-niveau, som
skal godkendes af ATP.
Side 54 af 76
Transformeringen skal kunne håndtere data, som de er leveret af KMD, og som det
vil fremgå af den detaljerede dokumentation, der leveres af KMD. Datakvaliteten
forventes overordnet at være god. ATP har ansvaret i tilfælde af, at der skal rettes
op på data i Eksisterende Løsning.
Leverandøren skal gennemføre en dataanalyse for at fastlægge behovet for datavask. ATP skal bistå med forretningsviden.
Leverandøren skal sikre, at der etableres fuldt transaktionsspor på datatransformeringen og den efterfølgende indlæsning af data i Debitorsystemet.
Konteringsdata skal være kravtypespecifikke og skal kunne spores tilbage til cpr.
overførte sumposter til økonomisystem, skal kunne følges til cpr-niveau i Debitorsystemet. Kontering skal afspejle kravtype, uanset at der sker summering af de
enkelte krav m.fl.
Nødvendigt værktøj og programmel til transformering af data udvikles/stilles til rådighed af leverandøren.
9.6.4
Indlæsning og viderefordeling af data
Leverandøren er ansvarlig for, at alle data konverteres korrekt ind i Debitorsystemet, og at sagerne oprettes i den rette tilstand. Endvidere skal leverandøren sørge
for, at der foretages den fornødne viderefordeling af data og synkronisering med
støttesystemer. Det skal sikre, at data er konsistente på tværs af Debitorsystemet
og støttesystemer.
9.6.4.1
Indlæsning af data i Debitorsystemet
Leverandøren skal indlæse tilstrækkelige data til, at sagsbehandlingen kan videreføres i Debitorsystemet med al den funktionalitet, der er i Systemet (såfremt der er
de tilstrækkelige data til rådighed i dataudtrækket fra KMD). Herunder gælder særligt at:
•
Aktive krav og sager fra Eksisterende Løsning skal videreføres i Debitorsystemet, og sagsbehandlingen og/eller udbetalingerne skal forsætte i Debitorsystemet.
•
Som minimum skal historik svarende til indeværende år + 4 år for hver sag
konverteres ind i Systemet.
•
Der skal være adgang til dokumenter og journalnotater på sagerne.
•
Kassations- og arkiveringsprocesserne skal virke for alle indlæste data.
Side 55 af 76
Bemærk at konfigurationsdata fra KMD Sag ikke skal indlæses i systemet, selvom
de fremgår af databeskrivelsen i bilag 2B (Eksisterende data).
Leverandøren skal i Afklaringsetapen i samarbejde med ATP afklare, om der er data, der kan/skal håndteres manuelt. Anbefalingen godkendes af ATP som en del af
den opdaterede konverteringsstrategi.
9.6.4.2
Viderefordeling af data og synkronisering med støttesystemer
Leverandøren skal udveksle data med følgende systemer:
Beriget Grunddata
•
Personer med administrative cpr-nr. etableres i Beriget Grunddata.
•
Der skal opsættes abonnement for interessentkredsen, og grunddata skal
modtages fra Beriget Grunddata i den daglige replikering.
SKAT EFI
•
Debitorløsningen skal tildeles ny fordringshaveraftaleidentifikation hos RIM
•
Udestående fordringer i SKAT’s EFI system skal opdateres, så de får et nyt
”Fordringshaver ID”. Denne opgave skal koordineres mellem KMD, ATP og
Leverandøren.
Nets
•
Alle BS-aftaler tilknyttet de konkrete PBS-numre for krav vedr. de enkelte
ydelsesområder udfases på det tidspunkt, hvor det enkelte ydelsesområde
udfases.
BS-aftaler tilknyttet afdragsordninger udfases ikke. Hvis der ligger afdragsordninger med betaling via BS blandt de udfasede sager, så vil borgeren
skulle gentilmelde sin afdragsordning til BS, efter den er reetableret i det nye
System.
Sags- og dokumentindeks
•
Alle aktive sager skal oprettes i sags- og dokumentindeks med tilknyttede dokumenter og journalnotater. Dataene vil herfra automatisk blive synkroniseret
over i KMD Sag via den sædvanlige mekanisme til synkronisering mellem indekses og KMD Sag.
ATP Datawarehouse
•
Datawarehouse skal modtage et dataudtræk, når konverteringen er tilendebragt, og alle data er konverteret ind. Data skal leveres i samme format som i
Side 56 af 76
de daglige dataleverancer – se integrationsbeskrivelse PDWH1 i bilag 3A.6 (Integrationer).
KMD Sag
•
Når alle data er indlæst i Sags- og dokumentindeks og Ydelsesindeks, og alle
sager derved er blevet synkroniseret til KMD Sag, skal de gamle sager i KMD
Sag logisk slettes og herved også de gamle sager i Sags- og dokumentindeks.
Sletningen i KMD Sag foretages af KMD ud fra en liste over de sager og dokumenter, der skal slettes. Leverandøren er ansvarlig for at levere denne ”sletteliste”.
Leverandøren skal sikre, at der etableres fuldt transaktionsspor på viderefordelingen af data.
9.6.5
Afstemning og datavalidering
Leverandøren skal udvikle automatiseringsrutiner til afstemning af data. Kriterier
for datavalidering og efterfølgende godkendelse opsættes i samarbejde mellem
ATP og leverandøren i forbindelse med migrationen af data fra Eksisterende Løsning til Debitorsystemet.
Leverandøren skal som minimum gennemføre:
•
Afstemning efter flytning af KMD dataudtræk til Debitorsystemets informationsmodel som bevis for, at alle relevante data er indlæst korrekt.
•
Afstemning efter henholdsvis transformation og indlæsning af data som bevis for, at alle relevante data fra KMD dataudtrækket er indlæst korrekt og
fuldstændigt i det nye Debitorsystem.
•
Afstemning efter ajourføring af sager i Sags- og dokumentindeks og Ydelsesindeks som bevis for at der er overensstemmelse mellem sager i Debitorsystemet og i indekset, samt at sagerne er synkroniseret korrekt til KMD
Sag. Verifikationen af KMD Sag synkronisering sker i samarbejde med
KMD.
•
Afstemmes op mod afstemningsdata leveret fra KMD.
•
Beløbsafstemning på laveste niveau.
•
Ad-hoc afstemning og kontroller, som skal gøres tilgængelige for ATP.
•
Bestandsafstemning og sumkontroller.
•
Validering af transformeringen som sikrer, at der ikke sker datatab eller forvanskning af data ved overgangen til det nye Debitorsystem.
Side 57 af 76
•
Alle felter med parametre eller kodeværdier skal dokumenteres konverteret
korrekt.
•
Alle numeriske felter skal dokumenteres konverteret korrekt.
•
Alle felter, der forandrer udseende (evt. sammenlægning af adresse oplysninger), skal dokumenteres konverteret korrekt.
Leverandøren skal i forbindelse med gennemførsel af konverteringen levere en afstemningsrapport som dokumentation for afstemning af data inklusive dokumentation/forklaring af evt. afvigelser samt redegørelse for påkrævede handlinger for
håndtering af afvigelser. Afstemningsrapporterne skal godkendes af ATP.
9.6.6
Gennemførsel af konverteringen
Leverandøren skal udarbejde en strategi for konvertering og beskrive denne overordnet i bilag 3B (Løsningsbeskrivelse), så ATP kan evaluere og betrygges i, at leverandøren har prøvet dette før.
Leverandøren skal, med input fra ATP og KMD, tilrettelægge og gennemføre konverteringen, så overgangen fra Eksisterende Løsning til Debitorsystemet foregår
på en sikker og forsvarlig måde med særlig fokus på driftsstabilitet, så forstyrrelser
af den daglig drift påvirkes mindst muligt.
Leverandøren er ansvarlig for udarbejdelsen af en drejebog. ATP bidrager med
overgangsinstrukser til kunderådgiver samt øvrige forretningsmæssige afklaringer.
Drejebogen skal som minimum indeholde nedenstående punkter:
a) Forretningsmæssig nedlukning/opstart ved overgangen til ny Familieydelsesløsning.
b) Jobafvikling, udbetalinger, data udtræk.
c) Koordinering med ATP ERP, Afstemning, DWH.
d) Overgangsinstrukser til kunderådgiver.
e) Integration til eksterne parter jf. systemkonteksten i bilag 3A (Behovsopgørelse), som skal nedlukkes og opstartes igen (databehandleraftaler og snitfladeaftaler).
Leverandøren er ansvarlig for, at konverteringen kan gennemføres inden for den
fastsatte tidsramme for konverteringen.
Side 58 af 76
Hvis der er aktiviteter, der gennemføres inden for kritisk forretningstid, skal der så
vidt muligt fortsat være læseadgang til data, for sager der tidligere er konverteret
ind i Debitorsystemet.
9.6.7
Håndtering af prøveudtræk
Til brug for afprøvning af konverteringsprogrammellet vil der fra KMD blive leveret
et prøveudtræk fra den Eksisterende Løsning. Der vil være tale om et fuldt udtræk
af umaskerede produktionsdata.
Leverandøren skal ved anvendelse af udtræk fra den Eksisterende Løsning sikre
at de non-funktionelle krav i bilag 3A.1 (Kravliste) vedrørende test og datasikkerhed overholdes.
9.7
Brugervenlighed
Dette emneområde angiver krav til, hvor nemt det skal være at benytte og tilgå
Debitorsystemet.
Brugervenlighed drejer sig primært om kvaliteten af brugergrænsefladen, hvilket
eksempelvis drejer sig om ergonomi, den visuelle oplevelse, skærmbilledeopbygning, og hvordan der navigeres rundt i Debitorsystemet.
9.8
Lovgivning
ATP ønsker sikkerhed for, at leverandøren overholder gældende lovgivning i sit arbejde, ligesom Debitorsystemet skal være konstrueret på en sådan måde, at ATP
kan varetage de forretningsmæssige opgaver, Debitorsystemet understøtter, således, at almen og specifik lovgivning til en hver tid overholdes. Kravene fremgår af
bilag 3A.1 (Kravliste).
Det påhviler ATP at identificere og foretage de nødvendige fortolkninger af relevante dele af specifik lovgivning (f.eks. Forvaltningsloven og Udbetaling Danmark Loven) samt omsætte disse til krav til Systemet. Leverandøren skal på ATP’s anmodning deltage i dette arbejde.
9.9
Sikkerhed
IT sikkerhed handler om at sikre konfidentielt, integritet, og tilgængelighed af information imod forskellige sikkerhedsrisici.
Dette behov skal sikres ved at indarbejde forskellige tekniske og systemspecifikke
kontroller, både i infrastrukturen og i designet af Debitorsystemet, og i de underliggende forretningsprocesser. Kravene til sikkerhed fremgår af bilag 3A.1 (Kravliste).
Side 59 af 76
9.10
Miljøer
Leverandøren skal tilvejebringe et driftsmiljø samt en række interne såvel som eksterne miljøer til brug for udvikling, test og uddannelse. Til brug for afprøvningerne,
beskrevet i bilag 6 (Afprøvninger), vil der være behov for et internt testmiljø, et eksternt testmiljø, et præproduktionsmiljø og så selve produktionsmiljøet. Kravene til
de forskellige miljøer vil fremgå af bilag 3A.1 (Kravliste).
9.11
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).
9.12
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 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).
9.13
Dokumentation
Leverandøren skal levere fyldestgørende og til en hver tid fuldt opdateret dokumentation af Systemet, herunder den efterfølgende drift og vedligeholdelse dokumentationen.
Leverandøren skal sikre, at ATP til enhver tid har adgang til opdateret og detaljeret
dokumentation, der gør ATP i stand til at få fuld indsigt i Systemet. Samtidig skal
dokumentationen være i en sådan stand, at en anden it-leverandør, uden unødigt
besvær, vil kunne sætte sig ind i Systemet og eventuelt overtage drift, vedligeholdelse og videreudvikling heraf.
Side 60 af 76
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)non.
9.14
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. Leverandøren skal have et særligt fokus i forbindelsen med den trinvise idriftsættes og første gangs afviklings af de enkelte jobs (batch kørsler, udbetalingskørsler m.v.) .
Leverandøren skal samarbejde med ATP for at sikre, at dette forløber succesfuldt,
hvilket kan kræve øget bemanding og/eller øget kontrol/overvågning.
Leverandøren skal sikre, at der foreligger en af ATP godkendt fallback-plan for enhver idriftsættelse. KMD har udarbejdet en beskrivelse for fallback til Eksisterende
Løsning (KMD Opus Debitor). Vinduet for denne er limiteret til perioden fra udkonverteringen og er mulig, indtil ATP og leverandøren siger ok for de konverterede
data i Systemet.
De konkrete krav til leverandøren i forhold til idriftsættelsen fremgår af bilag 3A.1
(Kravliste).
9.15
Hypercare
I forbindelse med idriftsættelsen af Systemet ønsker ATP, at leverandøren leverer
hypercare-ydelser, hvilket bl.a. inkluderer et øget beredskab hos leverandøren og
fysisk tilstedeværelse af leverandørens nøglepersoner på ATP’s lokalitet i Hillerød.
Hypercare-ydelserne skal give ATP’s undervisere og andre nøglepersoner hos
ATP øget adgang til bistand fra leverandøren med henblik på at sikre en succesfuld implementering og ibrugtagning af Systemet.
De konkrete krav til leverandøren i forhold til hypercare fremgår af bilag 3A.1
(Kravliste).
9.16
Samarbejde og rapportering
ATP ønsker et konstruktivt samarbejde med en professionel it-leverandør. Systemet er afgørende for Udbetaling Danmarks forretning og er tæt integreret med en
Side 61 af 76
lang række af ATP’s øvrige systemer, og medfører at leverandøren skal indgå i regelmæssige og ad hoc møder med både ATP og ATP’s Øvrige Leverandører, da
dette vurderes som værende essentielt for opretholdelsen af driftsstabilitet og den
tværgående koordinering.
Leverandøren skal deltage i samarbejdsorganisationen og levere rapportering jf.
kravene i bilag 8 (Samarbejdsorganisation og rapportering).
9.17
Test
ATP ønsker et funktionelt, driftsstabilt og brugervenligt Debitorsystem, der lever op
til arkitekturprincipperne jf. bilag 3A.1 (Kravliste).
ATP anser Afprøvninger for at være en væsentlig kilde til at opnå dette. Afprøvninger prioriteres derfor meget højt. En forudsætning for en succesfuld proces i forhold til Afprøvninger er, at både ATP og leverandøren indgår i processen på den
mest hensigtsmæssige vis.
Afprøvning af Leverancen skal gennemføres for at sikre, at Leverancen opfylder de
specificerede krav, og at Leverancen kan anvendes i henhold til det aftalte.
En beskrivelse af de forskellige Afprøvninger, rækkefølgen for Afprøvningerne set i
forhold til udviklingsmodellen, testværktøjer, testdokumentation samt review af
processen indgår ligeledes.
For hver Afprøvning angives formålet, processen for gennemførelsen samt de
Godkendelseskriterier, Leverancen skal opfylde for, at en Afprøvning kan betragtes
som godkendt.
Leverandøren er ansvarlig for planlægningen og udførelsen af alle Afprøvninger og
har dermed det fulde ansvar for alle Afprøvninger.
De konkrete beskrivelser i forhold til Afprøvninger fremgår af bilag 6 (Afprøvninger).
Side 62 af 76
10
Krav til Drift, vedligeholdelse og support (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 afsnit og bilag 3A.1 (Kravliste) indeholder kravene til leverandørens ydelser.
Et overblik over Ydelserne fremgår af nedenstående figur:
Kundens opgaver
Enterprise-arkitektur
Leverandørens ydelser
Kontraktstyring
Brugersupport
Etablering
Vedligehold
Videreudvikling
Drift
Rådgivning
Dokumentation
Sikkerhed
Overvågning
Optioner
Figur 10 Kundens opgaver og Leverandørens ydelser.
10.1
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.
Side 63 af 76
10.2
Etableringsydelsen
Leverandøren skal etablere grundlaget for varetagelse af Ydelserne, herunder
Drift, vedligeholdelse og support af Systemet. Etape III i Kontrakten afsluttes med
en række prøver, som beskrevet i Kontraktens bilag 1 (Tidsplan) og bilag 6 (Afprøvninger).
Leverandøren har det fulde ansvar for at etablere den samlede tekniske platform,
herunder alle relevante miljøer og kommunikationsinfrastruktur samt hertil hørende
Programmel og maskinel, som specificeret i Kontrakten.
I det efterfølgende gennemgås de overordnede Ydelser i etableringsperioden.
10.2.1
Etablering af lokaliteter
Leverandøren skal etablere og forberede de Ydelseslokaliteter, hvorfra maskinellet, der stilles til rådighed for ATP, skal drives.
10.2.2
Etablering af kommunikationsinfrastruktur
Leverandøren skal anskaffe og etablere kommunikationsinfrastruktur og maskinel
på de Ydelseslokaliteter, leverandøren vil benytte sig af i forbindelse med leveringen af Ydelserne. Leverandøren etablerer endvidere kommunikationsinfrastruktur
mellem leverandørens egne lokaliteter, mellem leverandøren og ATP samt mellem
leverandøren og ATP’s Øvrige Leverandører.
10.2.3
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.
10.2.4
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.
10.2.5
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-
Side 64 af 76
randøren etablere de værktøjer, der er nødvendige for at understøtte processerne
til vedligehold af Systemet.
10.3
Vedligeholdelse af Systemet
10.3.1
Vedligeholdelse af Systemet
Leverandøren varetager håndteringen af Fejl og Mangler ved Systemet, herunder
vedligehold.
På baggrund af vedligeholdelsen, skal leverandøren løbende ajourføre Dokumentationen for Systemet.
Leverandøren skal løbende fejlfinde og -afhjælpe konstaterede Fejl i Systemet i
henhold til Kontrakten. Vedligehold dækker over løsning af alle Fejl og Mangler,
som leverandøren eller ATP måtte opdage samt forebyggende vedligehold og
support.
Forhold vedrørende rapportering af Incidents, fejlkategorier mv. sker på samme
måde som den øvrige del af Driftsmiljøet. Der henvises også til bilag 7 (Servicemål) og bilag 8 (Samarbejdsorganisation og rapportering).
Side 65 af 76
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. 1-8.
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.
4.
Simpel problemdiagnosticering (kan udføres på under 3 timer).
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.
I bilag 7 (Servicemål), kap. 4.3.2 er Vedligeholdelse og Support benævnt ændringskategori
C
Side 66 af 76
Tabel 6 Definition af vedligeholdelse og support.
10.4
Løbende Drift
10.4.1
Lokaliteter
Leverandøren varetager den løbende vedligeholdelse af Ydelseslokaliteter, herunder eksempelvis nødstrømsanlæg, brandslukning og køling mv. Endvidere foretager leverandøren overvågning 24/7 af driftscenterlokaliteterne for at sikre overholdelsen af Servicemål og opretholdelse af sikkerhedsprocedurer.
Leverandøren har det fulde ansvar for den samlede Drift af Systemet i overensstemmelse med det i det efterfølgende specificerede og Kontraktens krav i øvrigt.
10.4.2
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.
10.4.3
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 bestemmelser om
rådgivningspligt.
10.4.4
Teknologisk rådgivning, rapportering og support
Leverandøren er ansvarlig for teknologisk rådgivning i forhold til Ydelserne. Det er
endvidere leverandørens opgave at foretage løbende rapportering, jf. bilag 8
(Samarbejdsorganisation og Rapportering), i forhold til 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.
10.4.5
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.
Side 67 af 76
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).
10.4.6
Sikkerhed og beredskab
Leverandøren, dennes medarbejdere, Underleverandører og disses medarbejdere
skal overholde de sikkerhedspolitikker, der til enhver tid er gældende i ATP’s organisation, herunder krav om backup og vedligeholdelse af beredskabsplaner, jf. også Kontrakten samt bilag 13 (Sikkerhed). Leverandøren skal ligeledes løbende
vedligeholde sikkerhedsprocedurer, herunder eksempelvis i forhold til fysiske og
logiske adgange, elektronisk kommunikation, beskyttelse af personoplysninger
m.v. Endelig sikrer leverandøren backup, genetablering og systemberedskabet i
forhold til det omfattede maskinel og infrastruktur.
10.4.7
Overvågning
Leverandøren varetager overvågning 24/7 af Ydelserne.
10.4.8
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).
10.4.9
Service Operation
10.4.9.1 Supportløsningen
Alle brugerrelaterede Servicedesk henvendelser håndteres af ATP som 1. level
support. Alle tekniske alarmer/ incidents genereret inden for leverandørens ansvarsområder, håndteres af Leverandøren som 1. level support. Leverandøren varetager ligeledes 2. level support.
For en nærmere beskrivelse af samarbejdsorganisationen henvises til bilag 8
(Samarbejdsorganisation og Rapportering).
10.4.10 Incident management
Incident management omfatter ATP’s krav til leverandørens processer inden for incident management.
Side 68 af 76
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).
10.4.11 Problem management
Problem management omfatter ATP’s krav til leverandørens processer inden for
problem management.
Problem management skal medvirke til at minimere og forebygge de driftsmæssige
konsekvenser af Incidents og Problems.
Problem management processen har både reaktive og proaktive aspekter. Det reaktive aspekt vedrører løsning af problemer som reaktion på en eller flere incidents. Proaktiv problem management vedrører identifikation og løsning af problemer og kendte fejl (known errors) før en incident indtræffer. Leverandøren skal
proaktivt konstatere og forebygge problemer, eksempelvis ved at reducere eller
helt forebygge incidents, i forbindelse med løbende trendanalyser, som udføres i
forbindelse med ydelsen. Trendanalysen kan eksempelvis håndteres ved gennemgang af alle Incidents (både løste og uløste) for gentagne fejlmønstre og root causes.
10.4.12 Change management
Changes opstår på flere måder, fx som resultat af incidents, problemer, fra proaktiv
søgning af forretningsfordele, eller på initiativ fra ATP.
Change management processerne skal sikre, at standardiserede metoder og procedurer anvendes for effektiv og hurtig håndtering af alle ændringer under kontrakten.
En change er en hvilken som helst ændring af ATP’s It-miljø. Samtlige ændringer
skal følge change management processen med undtagelse af eventuelle standardændringer, som godkendes af ATP, og som dokumenteres i den af Leverandøren udarbejdede Driftsaftalehåndbog.
Side 69 af 76
10.4.13 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).
10.4.14 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.
10.4.15 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).
10.4.16 Capacity management
Leverandøren skal sikre, at der er tilstrækkelig kapacitet i miljøerne til at kunne levere servicen i henhold til de aftalte servicemål samt Kontraktens øvrige krav.
Leverandøren skal overvåge kapacitetsforbruget på alle relevante områder jf. bilag
8 (Samarbejdsorganisation og Rapportering) afsnit 9.1.1. Målingerne af kapacitetsforbruget skal være så hyppige eller af en sådan karakter, at det vil være muligt for
Leverandøren rettidigt at spore selv mindre ændringer i forbrug, der kan fordre en
skalering af kapacitetsydelserne og deraf følgende vederlagsregulering.
Leverandøren skal registrere og opbevare de historiske målinger af kapacitetsforbruget.
Side 70 af 76
11
Fremtidige tilpasninger til Systemet
Det forventes, at der vil kunne opstå behov for tilpasninger til Systemet, som skal
ske efter overtagelsesdagen. Det kan eksempelvis opstå som følge af lovændringer, optimering og effektivisering af administrative arbejdsgange eller som følge af
ændringer i andre systemer, der integrerer med Systemet. På nuværende tidspunkt er der dog ikke kendskab til konkrete forventede tilpasninger til Systemet.
Side 71 af 76
12
Optioner
Kontrakten omfatter tre optioner der er relateret til Systemet. De tre optioner er beskrevet i det efterfølgende.
Leverandørens løsningsbeskrivelse for optionen relateret til Systemet fremgår af
bilag 3B (Løsningsbeskrivelse), og alle optionerne er prissat i bilag 5 (Priser og betalingsplan), hvor leverandøren også har anført fristen for ATP’s bestilling af optionerne, hvis de skal leveres som en del af Udviklingsprojektet.
12.1
Option på indbetalingsløsning, hvor borger / virksomhed kan betale via andre
kanaler end FI-kort og BS-opkrævning
Indbetalingsløsningen skal give borgere og virksomheder en alternativ mulighed for
at indbetale krav (og rykkere), der er opkrævet af Udbetaling Danmark.
Indbetalingsløsningen skal være et supplement til betaling via et FI-kort eller betaling via BS-opkrævning.
Der kan være flere tilgængelige indbetalingsløsninger, men minimum en af indbetalingsløsningerne skal også kunne anvendes af borgere og virksomheder, der ikke
er tilknyttet en dansk eller udenlandsk bank.
Indbetalingsløsningen skal kunne understøttes af den alment brugte teknologi, der
ligger til rådighed på markedet ift. betalinger. Det er således vigtigt, at teknologien
er velafprøvet, og at løsningen har en kritisk brugermasse.
Indbetalingsløsningen skal sikre, at alle betalinger, der bliver gennemført via denne
løsning, beholder den entydige reference på kravet, så betalingen automatisk kan
blive udlignet på det korrekte krav. Dvs. det krav der blev opkrævet, som betalingen vedrører.
12.2
Option på oprettelse af Afdrags- eller Modregningsordning via selvbetjeningsløsning på borger.dk
Den digitale løsning på boger.dk skal give borgerne mulighed for at oprette en afdragseller modregningsordning på krav, der er forsøgt opkrævet af Udbetaling
Danmark.
Brugergrænsefladen til selvbetjeningsløsningen skal være let tilgængelig og brugervenlig.
Side 72 af 76
Det skal være muligt at lægge hjælpetekster og videovejledning på siden.
Løsningen
Når borgeren logger på selvbetjeningsløsningen skal denne selv kunne oprette en
afdragseller modregningsordning. Borgeren skal have udstillet de krav, som denne kan oprette en afdragseller modregningsordning på i Udbetaling Danmark. Det
er ikke alle kravtyper, som en borger selv må oprette en afdragseller modregningsordning på, og det er kun de tilladte kravtyper, der skal fremgå af den oversigt, som borgeren kan vælge åbne krav ud fra.
Endvidere skal krav, hvor der allerede ligger en afdragseller modregningsordning
tilknyttet, samt krav, hvor der er oprettet en EFI Inddrivelsessag, ikke fremgå af
oversigten, da en borger som udgangspunkt ikke kan indgå nye afdragseller modregningsordninger for de krav.
Der vil dog være enkelte kravtyper, hvor en borger skal have mulighed for at se og
rette i en allerede oprettet modregningsordning, hvis det er en modregningsordning, der er oprettet af Udbetaling Danmark. Hvilke kravtyper det skal være gældende for skal kunne styres via regler.
Det skal være muligt at skrive en oplysning til borgeren, hvor der gøres opmærksom på, at det ikke nødvendigvis er alle krav, der fremgår på den oversigt, som de
kan vælge krav på.
Informationer på de viste krav
Det er den aktuelle restance, der skal fremgår af overblikket. Det skal fremgå af
oversigten, hvad restancen på de forskellige kravtyper er d.d., hvor man logger ind
og vil oprette en afdragseller modregningsordning.
Det skal ikke fremgå af den aktuelle restance, om der har været indbetalinger på
kravet. Eventuelle indbetalinger vil ”blot” have reduceret restancebeløbet der bliver
oplyst på det enkelte krav. Hvis der ligger flere krav, må restancen ikke fremgå
som et totalsum for dem alle. Det skal tydeligt fremgå, hvilket krav der er tale om,
og om der er opkrævet et gebyr.
Systemet skal kunne håndtere, at ved krav, hvor der er tilknyttet flere hæftere, er
det kun den hæfter, der er blevet opkrævet gebyr, der skal kunne se og indgå aftale på gebyret.
Side 73 af 76
Oprettelse af Afdrags- eller Modregningsordning
Ved oprettelsen skal det være muligt at vælge, om man ønsker kravet afviklet som
en afdragseller modregningsordning. Hvis borgeren vælger modregningsordning
skal det tillige være muligt for borgeren at vælge, hvilke ydelse borgeren ønsker, at
modregningen skal ske i. Her skal der fremgå en liste over de ydelser, som borgeren kan vælge at få modregnet kravet i. Listen må kun vise de ydelser, som borgeren er tilkendt.
Det skal være muligt at oprette en afdragseller modregningsordning, hvor borgeren tager flere forskellige krav med i samme ordning.
Borgeren skal have mulighed for at oprette forslag til beløb eller antal rater i ordningen.
Når afdragseller modregningsordningen oprettes via selvbetjeningsløsningen skal
den automatisk oprettes i Systemet med det samme.
Ved oprettelsen eller ændringen af en eksisterende ordning i Systemet skal der
ske stempling på sagen, hvoraf det tydeligt fremgår, at afdragseller modregningsordningen er oprettet eller ændret via selvbetjeningsløsningen.
For hvert billede og funktion, som borgeren bliver præsenteret for i selvbetjeningsløsningen skal det være muligt at tilføje en bemærknings- eller hjælpetekst til borgeren.
Når afdragseller modregningsordningen er oprettet skal der ske automatisk godkendelse af denne i Systemet, hvis ordningen lever op til betingelserne for afdragseller modregningsordning.
I forbindelse med den automatiske godkendelse af Ordningen i Systemet skal der
udstilles en kvitteringsside (besked) med mulighed for print og gem til fil. Kvitteringssiden (Beskeden) er dokumentationen for den indgåede aftale og skal også
gemmes på sagen i Systemet.
Kvitteringssiden der bliver dannet ved godkendelsen af en afdragseller modregningsordning skal indeholde:
•
Dato og tidspunkt for oprettelsen af ordningen.
•
Tekststykke der bekræfter, at der er indgået en aftale om en afdragseller
modregningsordning.
Side 74 af 76
•
Hvilke krav der er indeholdt i ordningen samt det skyldige beløb på hvert enkelt krav.
•
En afdragseller modregningsplan med dato for betaling.
•
Oplysning om, hvilken ydelse der modregnes i, hvis det er en modregningsordning
I forbindelse med oprettelse af en afdragsordning, skal det endvidere være muligt
for borgeren at tilmeldelse afdragsordningen til betalingsservice. Ved tilmelding af
ordningen til betalingsservice skal der dannes et kvitteringssvar (Besked) til borgeren.
Verificering af data ved oprettelsen af ordningen
Systemet skal kunne verificere ønsket til oprettelse af afdragseller modregningsordningen, således at det kun er afdragseller modregningsordninger, der overholder Udbetaling Danmarks betingelser, der kan blive oprettet. Betingelserne, der
skal danne grundlag for verificeringen, defineres via regler.
Hvis en afdragseller modregningsordning ikke kan oprettes fordi den ikke overholder betingelserne, skal Systemet give borgeren besked herom og komme med
forslag til, hvilken afdragseller modregningsordning, der kan oprettes inden for
betingelserne.
Systemet skal understøtte, at det skal være muligt at sætte en nedre grænse for,
hvor lavt et afdrag kan være. Hvis borgeren indtaster et beløb, der er for lavt, skal
der komme en tekst frem, der fortæller hvad minimumbeløbet skal være.
12.3
Option på Kommunikation direkte med KMD Aktiv og Kommunalt Ydelsessystem (KY)
Ændring af kommunikationen, så den sker direkte med KMD Aktiv og KY i stedet
for kommunikation via modregningsfordeleren på Serviceplatformen.
Kravstillet løsning i udbudsmaterialet:
I den kravstillede løsning sker kommunikationen mellem Debitorsystemet og de
kommunale fagsystemer ved, at Debitorsystemet sender en anmodning om modregning til modregningsfordeleren på Serviceplatformen. Serviceplatformen sikrer
den videre kommunikation til det kommunale fagsystem, hvori modregningen skal
ske. Svaret der kommer retur fra de kommunale fagsystemer vedr. anmodningen
vil ligeledes blive distribueret via modregningsfordeleren. Svaret retur fra de kom-
Side 75 af 76
munale ydelsessystemer kan både være besked om indbetalingen og besked om,
at der ikke kunne gennemføres modregning inden for den anførte tidsfrist.
Løsning ift. optionen:
I optionen til den kravstillede løsning, skal kommunikationen fra og til Debitorsystemet ske direkte med KMD Aktiv og Kommunernes Ydelsessystem (KY). Kommunikationen skal ske via de eksisterende snitflader i KMD Aktiv og de tilsvarende
kravstillet snitflader i KY. Det betyder, at de kommunale ydelsessystemer, i forbindelse udbetalingskørslerne, sender en forespørgsel til Debitorsystemet om, hvorvidt Udbetaling Danmark har nogle krav, de ønsker modregnet i udbetalingen fra
det pågældende system. Udbetaling Danmark sender svar retur med oplysning om
beløb, hvorefter de kommunale fagsystemer returnerer et svar med beløb, når de
har gennemført modregningen.
Såfremt optionen skal anvendes skal der etableres snitflade til KMD Aktiv og KY.
Side 76 af 76

Bilag 3A Behovsopgørelse

Transcription

Similar documents

1 Sundhedsordning for medarbejdere i Tønder Kommune

Forelæsning på ITU - Thomas Axen

Lejebetingelser for Det Hvide Fyr

Praktisk hjælp - Aalborg Kommune

Udtalelse fra Aabenraa Kommune af 23. juni 2015

Simon Schøler, KMD

Spørgsmål og svar - Region Hovedstaden

Kravspecifikation Akademisk boghandel Aalborg Universitet