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 76

3 5.1.1 POSTHÅNDTERING 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 PERSON- OG VIRKSOMHEDSDATA SAGER & DOKUMENTER ØVRIGE KOMPONENTER SIKKERHED RAPPORTER JOBAFVIKLING ØKONOMI HÆNDELSER AFSTEMNING ARKIVERING INDEKSSYNKRONISERING Bilag 3A Behovsopgørelse Side 2 af 76

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 generede oplysninger 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 - Effektuer udbetaling person INFORMATIONSARKITEKTUR OVERORDNET BEGREBSMODEL FOR UDBETALING DANMARK BEGREBS- OG INFORMATIONSMODELLER FOR FORRETNINGSLØSNINGEN DOKUMENTATION TIL LEVERANDØR INFORMATIONSMODEL SAG Sag Sag - Nøgler og Egenskaber Sagens oprettelse og livsforløb PART SAGSDOKUMENTATION INFORMATIONSMODEL DEBITOR Debitorsag Krav Bilag 3A Behovsopgørelse Side 3 af 76

5 Opkrævning Indbetaling Afskrivning Udbetaling Rykker Modregningsordning Afdragsordning Inddrivelsessag Modregningssag IT ARKITEKTUR IT-UDBUDSARKITEKTUREN SYSTEMKONTEKST OG INTEGRATIONER INTEGRATIONER OG INFRASTRUKTUR NON-FUNKTIONELLE KRAV TIL SYSTEMET ARKITEKTUR RAMMER FOR ARKITEKTUREN BELASTNING OG SKALERING Krav modtaget fra Fagsystemer Opkrævningskørsler MODREGNINGER Status på EFI Sager Journaliser post på sagen Dataudtræk og øvrig rapportering DESIGN OG APPLIKATIONSSTRUKTUR LOGNING SYSTEMFLEKSIBILITET TILGÆNGELIGHED DATAKONVERTERING Bilag 3A Behovsopgørelse Side 4 af 76

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

7 10.4 LØBENDE DRIFT LOKALITETER INFRASTRUKTUR OG MASKINEL PROGRAMMEL TEKNOLOGISK RÅDGIVNING, RAPPORTERING OG SUPPORT DOKUMENTATION OG KONFIGURATIONSSTYRING SIKKERHED OG BEREDSKAB OVERVÅGNING OPHØRSBISTAND SERVICE OPERATION Supportløsningen INCIDENT MANAGEMENT PROBLEM MANAGEMENT CHANGE MANAGEMENT RELEASE MANAGEMENT EVENT MANAGEMENT - OVERVÅGNING CONFIGURATION MANAGEMENT CAPACITY MANAGEMENT FREMTIDIGE TILPASNINGER TIL SYSTEMET OPTIONER OPTION PÅ INDBETALINGSLØSNING, HVOR BORGER / VIRKSOMHED KAN BETALE VIA ANDRE KANALER END FI-KORT OG BS-OPKRÆVNING OPTION PÅ OPRETTELSE AF AFDRAGS- ELLER MODREGNINGSORDNING VIA SELVBETJENINGSLØSNING PÅ BORGER.DK OPTION PÅ KOMMUNIKATION DIREKTE MED KMD AKTIV OG KOMMUNALT YDELSESSYSTEM (KY) 75 Bilag 3A Behovsopgørelse Side 6 af 76

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

9 2 Indledning Dette bilag indeholder en overordnet beskrivelse af ATP s krav til det nye System samt de øvrige krav til Leverandøren. Bilaget udgør sammen med tilhørende underbilag ATP s behovsopgørelse for Systemet. 2.1 Underbilag Bilaget har følgende underbilag: Bilag Bilag 3A.1 (Kravliste) Bilag 3A.2 (Løsningsflows) Bilag 3A.3 (Aktivitetsbeskrivelser) Bilag 3A.4 (Informationsmodeller) Bilag 3A.5 (Regel- og beslutningsmodeller) Bilag 3A.6 (Integrationer) Bilag 3A.8 (Oversigter) Indhold Bilaget indeholder en liste over ATP s krav til Leverancen, hvor Leverandøren skal angive opfyldelsesgrad mv. i overensstemmelse med vejledningen til bilaget. Bilaget skal for en del krav læses i sammenhæng med de øvrige underbilag. Bilaget indeholder de løsningsflows, der indgår i de forretningsprocesser, som er forbundet med indberetning, administration og udbetaling af debitorrelaterede forhold. 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. Bilaget indeholder UML modeller af de væsentligste forretningsmæssige begreber og de informationer, som vedrører indberetning, administration og udbetaling af debitorrelaterede forhold. Bilaget indeholder en oplistning af de regler Debitorsystemet skal kunne understøtte og en overordnet forretningsmæssige beskrivelser heraf. Bilaget indeholder uddybende information om de integrationer, som Leverandøren skal etablere fra Systemet. Bilaget indeholder følgende oversigter: Brevoversigt Akt LF - DM Rolleoversigt Informationsbehandling_gui Tabel 1 Behovsopgørelsen og tilhørende underbilag Bilag 3A Behovsopgørelse Side 8 af 76

10 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 9 af 76

11 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- Bilag 3A Behovsopgørelse Side 10 af 76

12 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: Bilag 3A Behovsopgørelse Side 11 af 76

13 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 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 Bilag 3A Behovsopgørelse Side 12 af 76

14 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 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 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. Bilag 3A Behovsopgørelse Side 13 af 76

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

16 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 Behovsopgørelse Side 15 af 76

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

18 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. Bilag 3A Behovsopgørelse Side 17 af 76

19 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 18 af 76

20 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: Bilag 3A Behovsopgørelse Side 19 af 76

21 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 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 Bilag 3A Behovsopgørelse Side 20 af 76

22 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 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) 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. Bilag 3A Behovsopgørelse Side 21 af 76

23 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 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). Bilag 3A Behovsopgørelse Side 22 af 76

24 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 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 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). Bilag 3A Behovsopgørelse Side 23 af 76

25 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 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 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 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- Bilag 3A Behovsopgørelse Side 24 af 76

26 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 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. 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. 5.4 Støttekomponenter Denne gruppe af komponenter varetager informationer om borgere og virksomheder fra autoritative registre samt sager og dokumenter: Person- og Virksomhedsdata Bilag 3A Behovsopgørelse Side 25 af 76

27 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 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. Bilag 3A Behovsopgørelse Side 26 af 76

28 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 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 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 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. Bilag 3A Behovsopgørelse Side 27 af 76

29 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 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 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. Bilag 3A Behovsopgørelse Side 28 af 76

30 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. Debitor Figur 4 Samlet procesoverblik Bilag 3A Behovsopgørelse Side 29 af 76

31 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 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 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 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 generede oplysninger LF Debitor Håndter automatisk generede oplysninger 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 Bilag 3A Behovsopgørelse Side 30 af 76

32 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 modtagne 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 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 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 via FIK eller BS. Bilag 3A Behovsopgørelse Side 31 af 76

33 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 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 vide- Bilag 3A Behovsopgørelse Side 32 af 76

34 rebehandles, eller blive ændret 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 skatter 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 Efterfølgende sendes kravet videre i korrekt i flow ift. denne vurdering. Bilag 3A Behovsopgørelse Side 33 af 76

35 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. 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 Bilag 3A Behovsopgørelse Side 34 af 76