Bilag 3A Behovsopgørelse

Transkript

1 Bilag 3A Behovsopgørelse Version

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

3 5.1.1 CALLCENTER OG TELEFONI DIGITAL POST OG FYSISK POST SELVBETJENING MANUELT OPGAVEINDBAKKE TVÆRGÅENDE OVERBLIK SAGSHÅNDTERING MANUELLE BREVE SYSTEMADMINISTRATION REGELADMINISTRATION AUTOMATISK VALIDERING OPKRÆVNINGS- OG BETALINGSADMINISTRATION HÅNDTER MODREGNING RYKNING EFI HÅNDTERING HÅNDTER INDBETALING DAN UDBETALING AFSKRIVNING BESKEDHÅNDTERING STØTTEKOMPONENTER BORGER OG VIRKSOMHEDSDATA SAGER & DOKUMENTER ØVRIGE KOMPONENTER SIKKERHED RAPPORTER JOBAFVIKLING ØKONOMI HÆNDELSER AFSTEMNING INDEKSSYNKRONISERING Bilag 3A Behovsopgørelse Side 2 af 40

4 6 FORRETNINGSPROCESSER SAMLET PROCESOVERBLIK KERNEPROCESSER KERNEPROCES - HÅNDTER INDBERETNING LF Debitor Opret krav KERNEPROCES - HÅNDTER LØBENDE ÆNDRINGER LF Debitor Håndter automatisk genererede hændelser KERNEPROCES HÅNDTER DRIFT LF Debitor - Håndter Opkrævning LF Debitor - Håndter Afdragsordning LF Debitor - Håndter indbetaling LF Debitor - Håndter rykker LF Debitor - Håndter restance LF Debitor Håndter afskrivning KERNEPROCES HÅNDTER UDBETALING LF Debitor - Håndter udbetaling INFORMATIONSARKITEKTUR IT ARKITEKTUR NON-FUNKTIONELLE KRAV TIL SYSTEMET KRAV TIL DRIFT, VEDLIGEHOLDELSE, SUPPORT OG VIDEREUDVIKLING (YDELSERNE) FREMTIDIGE TILPASNINGER TIL SYSTEMET OPTIONER Bilag 3A Behovsopgørelse Side 3 af 40

5 1 Vejledning til Tilbudsgiver Bilaget skal ikke ændres af Tilbudsgiver. Tabel 1 Vejledning til Tilbudsgiver Bilag 3A Behovsopgørelse Side 4 af 40

6 2 Indledning Dette bilag indeholder en overordnet beskrivelse af ATP s krav til det nye System samt de øvrige krav til Leverandøren. Bilaget udgør sammen med tilhørende underbilag ATP s behovsopgørelse for Systemet. 2.1 Underbilag Bilaget har følgende underbilag: Bilag Bilag 3A.1 (Kravliste) Bilag 3A.2 (Løsningsflows) Bilag 3A.3 (Aktivitetsbeskrivelser) Bilag 3A.4 (Informationsmodeller) Bilag 3A.5 (Regel- og beslutningsmodeller) Bilag 3A.6 (Integrationer) Indhold Bilaget indeholder en liste over ATP s krav til Leverancen, hvor Leverandøren skal angive opfyldelsesgrad mv. i overensstemmelse med vejledningen til bilaget. Bilaget skal for en del krav læses i sammenhæng med de øvrige underbilag. I denne version indeholder bilaget kun udvalgte krav inden for konkrete områder. Bilaget indeholder de løsningsflows, der indgår i de forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af debitorrelaterede forhold. I denne version er LF Debitor Håndter udbetaling ikke medtaget. 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. I denne version er det aktivitetsbeskrivelser der indgår i de fremlagte løsningsflows, der er medtaget. Bilaget indeholder UML modeller af de væsentligste forretningsmæssige begreber og de informationer, som vedrører indberetning, administration og udbetaling af debitorrelaterede forhold. I denne version er dette bilag ikke medtaget. Bilaget indeholder standardiserede modeller af de regler af lovgivningsmæssig og anden karakter forbundet med indberetning, administration og udbetaling af debitorrelaterede forhold. I denne version indeholder dette bilag kun eksempler på regel for to udvalgte aktivitetsbeskrivelser. Bilaget indeholder uddybende information om de integrationer, som Leverandøren skal etablere fra Systemet. I denne version er dette bilag ikke medtaget. Bilag 3A Behovsopgørelse Side 5 af 40

7 Bilag Bilag 3A.7 (Brugergrænseflader) Bilag 3A.8 (Oversigter) Indhold Bilaget indeholder rammesættende beskrivelse af brugergrænseflader, der har til formål at give Leverandøren inspiration til design af brugergrænsefladerne i Systemet. I denne version er dette bilag ikke medtaget. Bilaget indeholder følgende oversigter: Brevoversigt Akt LF - DM Beregningsregler Informationsbehandling_gui I denne version er dette bilag ikke medtaget. Tabel 1 Behovsopgørelsen og tilhørende underbilag 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. Bilag 3A Behovsopgørelse Side 6 af 40

8 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: 3 Brugerne af Systemet hvornår og hvordan møder brugerne Systemet 4 Forretningsudbudsarkitekturen systemer, parter og sammenhænge 5 Komponentmodellen hvad Systemet skal understøtte 6 Forretningsprocesser tekniske understøttelse af de forretningsmæssige behov 7 Informationsarkitekturen beskrivelse og gruppering af forretningsmæssige begreber (Dette afsnit er ikke med i denne version). 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. For at understøtte dette behov, skal borgerne og virksomhederne kunne gennemføre sine betalinger og kommunikere via den gængse teknologi, der udbydes på markedet. 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 kunne 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. Bilag 3A Behovsopgørelse Side 7 af 40

9 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 afhængig af, hvad borgerens eller virksomhedens henvendelse vedrører således, at den enkelte kunderådgiver oplever et overblik, der er tilpasset den konkrete arbejdsopgave / 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 arbejdsopgaver, og ved at de oplysninger, der er nødvendige for at kunne løse den konkrete arbejdsopgave, fremgår tydeligt i systemet. Endvidere skal løsningen sikre en enkel systemdialog i behandlingen af arbejdsopgaverne, så det er nemt at taste de konkrete informationer de rigtige steder. 3.4 Forretningsadministratorerne Systemet skal understøtte, at en forretningsadministrator kan rette og slette i regler, beslutninger, skabeloner og tekster, der styrer en automatiseret funktionalitet i Systemet. Et eksempel herpå 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. 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 Bilag 3A Behovsopgørelse Side 8 af 40

10 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 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 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 Funktionsadskillelse ATP s informationssikkerhedspolitik stiller krav om, at der skal være grundlæggende funktionsadskillelse mellem a) udvikling og vedligeholdelse af systemer, b) drift og c) ATP s forretningsaktiviteter og brugerfunktioner. Dette betyder blandt andet, at der ikke må tildeles IT roller til forretningen eller omvendt. Ved design af roller er det således væsentlig, at forretningsopgaver ikke lægges i IT-roller, og IT-opgaver ikke lægges i forretningens roller. Inden for ATP s forretningsaktiviteter, skal der li- Bilag 3A Behovsopgørelse Side 9 af 40

11 geledes etableres funktionsadskillelse, der sikrer, at samme person ikke alene kan initiere, udføre og godkende transaktioner Dokumentation Rollerne og de tilhørende rettigheder skal dokumenteres i en rolle-/rettighedsmatrice. I rolle-/rettighedsmatricen skal rollerne stå nævnt vandret og de tilhørende rettigheder lodret. Det skal for hver rettighed være angivet om der er tale om oprette-, læse-, opdatere- og/eller sletterettigheder. Matricerne skal til enhver tid holdes opdaterede, så de altid afspejler virkeligheden. Rettighedstabellerne kan ændres ved konstruktion af nye funktioner/transaktioner, ændrede funktioner eller nye forretningsmæssige behov. Der vil uvilkårligt ske ændringer, både som følge af udvikling af ny funktionalitet og som følge af forretningens ønsker om tilpasning af roller og arbejdsfunktioner. Roller bør ikke anskues enkeltstående, og derfor bør kombinationen af roller vurderes. Det er vigtigt, at der ikke tildeles roller, som er konfliktende. Konfliktende roller skal derfor identificeres og dokumenteres 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 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), opda- Bilag 3A Behovsopgørelse Side 10 af 40

12 tere og slette (CRUD), jf. bilag 3A.8 (Oversigter), fane Forretningsroller (Bilag 3A.8 er ikke vedlagt i denne version). Det er ikke alle informationer i en pakke, som de enkelte roller skal have adgang til. Bilag 3A Behovsopgørelse Side 11 af 40

13 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. (Bilag 3A.6 er ikke medtaget i denne version). Bilag 3A Behovsopgørelse Side 12 af 40

14 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 arbejdsopgave. 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. En del af løsningen er visning på borger.dk og virk.dk., som skal give borgere og virksomheder nem adgang til generelle informationer omkring opkrævning og indbetaling af krav. 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. Bilag 3A Behovsopgørelse Side 13 af 40

15 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 en fuldstændig liste over integrationer findes i afsnit 8 IT arkitektur. (Afsnit 8 er ikke indeholdt i denne version). Bilag 3A Behovsopgørelse Side 14 af 40

16 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. Bilag 3A Behovsopgørelse Side 15 af 40

17 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 alle komponenterne vil i den endelige version være listet i bilag 3A.1 (Kravlisten). I denne version fremgår udvalgte detaljerede krav til nogle af komponenterne i bilag 3A.1 (Kravlisten). 5.1 Kanaler Denne gruppe af komponenter angiver, hvordan Systemet skal fungere sammen med ATP s postmodtagelse, Systemets selvbetjeningsløsning samt den Callcenter og telefoni løsning, som kunderådgiverne anvender: Callcenter og Telefoni Digital post Bilag 3A Behovsopgørelse Side 16 af 40

18 Fysisk post Selvbetjening Callcenter og Telefoni Systemet skal understøtte kunderådgiverne i deres arbejde, når de sagsbehandler via telefonen Digital post og fysisk post 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 Selvbetjening Selvbetjening leverer en webbaseret løsning, som udstiller den fremsendte opkrævning. Borgeren kan via løsningen indbetale sin gæld direkte til Udbetaling Danmark. Selvbetjeningsløsningen skal udstilles på borger.dk og virk.dk. Selvbetjening udstiller og modtager derved data i relation til de enkelte opkrævninger og rykkere og sender disse til Systemet for validering og registrering. 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. 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 Bilag 3A Behovsopgørelse Side 17 af 40

19 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 Opgaveindbakke Udgangspunktet for det daglige arbejde for en kunderådgiver er Opgaveindbakken. Opgaveindbakken indeholder opgaver, som er struktureret i logiske arbejdspakker. En opgave kan bestå af behandling af fysisk post, digital post eller hændelser, som systemet ikke har kunnet eller 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 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 og fra Sags- og Dokumentindeks (se afsnit 8.2 Systemkontekst) (Afsnittet er ikke med i denne version). Bilag 3A Behovsopgørelse Side 18 af 40

20 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 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 Systemadministration Systemadministration er en brugergrænseflade, hvor man kan udføre administration af systemet. Med administration menes her fx rettelse af forskellige parametre (fx tidspunktet for udsendelse af opkrævninger, rykkerprocedurer, definition af betalingsfrister), brevskabeloner, arbejdspakker, tekster, hjælpeinformation og genvejstaster mv. Brugergrænsefladen skal være rettet mod brugere uden særlige tekniske forudsætninger 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 in- Bilag 3A Behovsopgørelse Side 19 af 40

21 formationer, der er nødvendige parametre til at gennemføre korrekt sagsbehandling. 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 parameterstyring og konfiguration af Systemet vil fremgå af bilag 3A.1 (Kravliste) i den endelige version. De er ikke medtaget i denne version. 5.3 Automatisk Denne gruppe af komponenter understøtter den automatiske sagsbehandling af primært motorvejene og består af følgende komponenter: 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. Valideringen sker ud fra et sæt af Bilag 3A Behovsopgørelse Side 20 af 40

22 beslutningsregler, der er implementeret i komponenten Regeladministration. Validering sker tilsvarende, forinden en manuel opgave fortsætter i det automatiske flow 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 medhæfter ift. det enkelte krav i de tilfælde, hvor der er medhæfter 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). Alle ovenstående handlinger udfører Systemet ud fra regelsæt, der er implementeret i komponenten Regeladministration 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 beskeder afsted til de udbetalende fagsystemer med konkrete modregningsanmodninger. 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 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 im- Bilag 3A Behovsopgørelse Side 21 af 40

23 plementeret i komponenterne Systemadministration og 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 EFI Håndtering Komponenten har ansvaret for at oversende krav til 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. 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 regelsæ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 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 Dan Udbetaling Komponenten skal samle og overføre udbetalinger til indenlandske- og udenlandske konti gennem NemKonto. Den registrerer udbetalingsdata og genererer udbetalingsfiler. Bilag 3A Behovsopgørelse Side 22 af 40

24 Komponenten genererer uddata til digitale beskeder (udbetalingsmeddelelse). Systemet vælger typen af udbetalingsmeddelelse ud fra et regelsæt, der er implementeret i komponenten Regeladministration 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 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. Beskedhåndtering indeholder desuden en brugergrænseflade til konfiguration af beskeder/breve. Komponenten muliggør oprettelse og vedligehold af besked- /brevskabeloner med tilpasning og for udfyldelse af tekstblokke. 5.4 Støttekomponenter Denne gruppe af komponenter varetager informationer om borgere og virksomheder fra autoritative registre samt sager og dokumenter: Borger og Virksomhedsdata Sager & Dokumenter Borger 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. Komponenten skal vedligeholde de specifikke persondata fx partsrepræsentation, som brugere kan opdatere gennem Debitorsystemet. Komponenten skal håndtere informationer fra Beriget Grunddata og informationer, som brugere har opdateret i Bilag 3A Behovsopgørelse Side 23 af 40

25 Systemet. Komponenten har tillige ansvaret for, at historiske data bevares og kan tilgås fra de andre komponenter 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: 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. Sikkerhed har desuden ansvaret for håndtering af log on forespørgsel fra Systemet og selvbetjeningsløsningen / indbetalingsløsningen via Web 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å Bilag 3A Behovsopgørelse Side 24 af 40

26 baggrund af en bestemt regel. Disse informationer anvendes til løbende driftsoptimering i ATP. Komponenten har en brugergrænseflade, som muliggør at forretningsadministratorer selv kan definere rapporter i Systemet Jobafvikling Komponenten har ansvaret for at håndtere driftflows for interne hændelser i fagsystemet, hvilket typisk drejer sig om batchkørsler på bestandsniveau. Komponenten vedligeholder regler for kørselstidspunkter og flowregler for afvikling af de automatiske kørsler Økonomi Systemet 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 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 Afstemning Afstemning leverer afstemningsdata fra Systemet til videre behandling. Afstemning har ansvaret for at udtrække og samle afstemningsdata fra Systemet for at sikre retvisende regnskab. Komponenten har endvidere ansvaret for at levere logning på data, som udsendes til andre systemer, så der kan foretages afstemninger af grænseflader. Bilag 3A Behovsopgørelse Side 25 af 40

27 Komponenten har ligeledes ansvar for at foretage afstemning af interne dataflyt i Systemet, såfremt sådanne finder sted Indekssynkronisering Systemet henter sags- og ydelsesinformationer fra de fælleskommunale støttesystemer Sags- og dokumentindeks og Ydelsesindeks. Systemet skal tilsvarende levere sags- og ydelsesinformationer for debitorsager til de samme indeks 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. Bilag 3A Behovsopgørelse Side 26 af 40

28 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 forretningsmæssige processer, der benyttes i den samlede administration af debitor. Figur 4 Samlet procesoverblik Bilag 3A Behovsopgørelse Side 27 af 40

29 6.2 Kerneprocesser Kernerprocesserne beskriver, hvordan Udbetaling Danmark indberetter, administrerer og udbetaler debitorrelaterede forhold. Kerneprocesserne er nedbrudt i Løsningsflow (LF), som er yderligere beskrevet nedenfor Kerneproces - Håndter indberetning 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 LF Debitor Opret krav Formålet med løsningsflowet er 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 Kerneproces - Håndter løbende ændringer 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 genererede hændelser LF Debitor Håndter automatisk genererede hændelser 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. Bilag 3A Behovsopgørelse Side 28 af 40

30 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 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 Kerneproces Håndter drift Processen håndterer overordnet set dannelse af opkrævninger, afdragsordninger herunder modregningsordninger, rykker og restantbehandling samt håndtering af modtagene indbetalinger. Kerneprocessen består af løsningsflow: LF Debitor - Håndter Opkrævning , LF Debitor - Håndter Afdragsordning , LF Debitor - Håndter indbetaling , LF- Debitor - Håndter rykker , LF Debitor Håndter restance og LF Debitor - Håndter afskrivning LF Debitor - Håndter Opkrævning 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 en medhæfter på kravet, vil der også skulle sendes opkrævning til medhæfteren under forudsætning af, at dette er defineret i reglerne. Uanset om borgeren eller virksomheden modtager den ene eller den anden type opkrævning, skal de endvidere kunne betale opkrævningen direkte fra en selvbetjeningsløsning, hvor opkrævningen med de specifikke informationer er udstillet. Bilag 3A Behovsopgørelse Side 29 af 40

31 Borgere og virksomheder skal kunne tilgå selvbetjeningsløsningen direkte via links i de breve, borgeren har modtaget fra Udbetaling Danmark vedr. opkrævningen. Samtidig skal de have mulighed for at logge sig på betalingsløsningen på anden vis LF Debitor - Håndter Afdragsordning 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 på normal vis. 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 ) 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. Bilag 3A Behovsopgørelse Side 30 af 40

32 LF Debitor - Håndter indbetaling 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 viderebehandles, eller blive transformeret til en udbetaling, der sendes videre via løsningsflowet, der håndterer udbetalinger (LF Debitor Håndter udbetaling ) LF Debitor - Håndter rykker 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 ), 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 ), 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 skatteudbetalinger. Bilag 3A Behovsopgørelse Side 31 af 40

33 LF Debitor - Håndter restance 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 og efterfølgende sender dem korrekt videre i flow ift. denne vurdering. Hvis der oprettes modregningsordninger eller opgaver til manuel behandling i form af betalingsevnevurderinger, fortsætter den aktuelle sag i LF Debitor Håndter Afdragsordning 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 LF Debitor Håndter afskrivning 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. Bilag 3A Behovsopgørelse Side 32 af 40

34 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 samme. Det kan fx være tilfældet, hvis det er et tilbagebetalingskrav som følge af dødsfald, og der er boudlæg. Eller det kan opstå, hvis kravet er opstået som følge af fx en kunderådgiverfejl i Udbetaling Danmark eller i nogle 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ælde, hvis der ikke er sket 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 Kerneproces Håndter udbetaling 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 LF Debitor - Håndter udbetaling 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 Bilag 3A Behovsopgørelse Side 33 af 40

35 Når den endelige udbetaling er opgjort og klar til afsendelse, skal Debitorsystemet både generere en meddelelse til borgeren, virksomheden eller myndigheden samt sikre en korrekt bogføring i ATP ERP. Bilag 3A Behovsopgørelse Side 34 af 40

36 7 Informationsarkitektur Dette afsnit er ikke med i denne version. Bilag 3A Behovsopgørelse Side 35 af 40

37 8 IT arkitektur Dette afsnit er ikke med i denne version. Bilag 3A Behovsopgørelse Side 36 af 40

38 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. Kravgrupperingen anvendt i dette bilag anvendes også i bilag 3A.1 (Kravliste) og i bilag 3B (Løsningsbeskrivelse), således at strukturen fremstår ensartet i de tre bilag. Dette afsnit er ikke med i denne version. Bilag 3A Behovsopgørelse Side 37 af 40

39 10 Krav til Drift, vedligeholdelse, support og videreudvikling (Ydelserne) Dette afsnit er ikke med i denne version. Bilag 3A Behovsopgørelse Side 38 af 40

40 11 Fremtidige tilpasninger til Systemet Dette afsnit er ikke med i denne version. Bilag 3A Behovsopgørelse Side 39 af 40

41 12 Optioner Dette afsnit er ikke med i denne version. Bilag 3A Behovsopgørelse Side 40 af 40