Regnskab 2013-14 med budget 2015 til hjemmeside.pdf
Bilag 2 Situationsbeskrivelse Version 0.9 19-12-2014 Indhold 1 VEJLEDNING TIL TILBUDSGIVER ................................................................................. 4 2 INDLEDNING ............................................................................................................. 5 2.1 BILAGETS FORMÅL OG OPBYGNING ................................................................................. 5 2.2 UNDERBILAG ............................................................................................................. 5 3 INTRODUKTION TIL ATP KONCERNEN ........................................................................ 6 3.1 ATP’S OPGAVER ........................................................................................................ 6 3.2 ORGANISATION ......................................................................................................... 7 3.3 ATP’S DIGITALISERINGSSTRATEGI ................................................................................... 9 4 INTRODUKTION TIL UDBETALING DANMARK ........................................................... 10 4.1 FORMÅL ................................................................................................................ 10 4.1.1 LOVGIVNING .................................................................................................................. 10 4.1.2 ENSARTET SAGSBEHANDLING ............................................................................................ 10 4.1.3 KONTROL MED YDELSER ................................................................................................... 10 4.1.4 ATP DRIVER MYNDIGHEDEN ............................................................................................. 11 4.1.5 SAGSOMRÅDERNE ........................................................................................................... 11 4.1.6 SELVBETJENING FOR BORGERE PÅ BORGER.DK ...................................................................... 11 4.1.7 SELVBETJENING FOR ARBEJDSGIVERE, A-KASSER OG SELVSTÆNDIGE VIA NEMREFUSION .............. 11 4.2 UDBETALING DANMARKS CENTRE................................................................................. 12 4.3 ORGANISATION ....................................................................................................... 12 5 INTRODUKTION TIL DEBITORFUNKTIONEN .............................................................. 13 5.1 INDLEDNING ........................................................................................................... 13 5.2 HVAD ER DEBITORFUNKTIONEN? .................................................................................. 13 Bilag 2 Situationsbeskrivelse Side 1 af 42 5.3 LOVGIVNINGEN........................................................................................................ 14 5.4 SÆRLIGE FORHOLD FOR DEBITORFUNKTIONEN ................................................................. 14 5.5 IGOE FOR YDELSESOMRÅDET ...................................................................................... 16 5.6 ADMINISTRATION AF NUVÆRENDE FORRETNINGSLØSNING.................................................. 17 5.7 FAKTABOKS FOR DEBITORFUNKTIONEN .......................................................................... 18 6 DEN EKSISTERENDE FORRETNINGSLØSNING ............................................................ 19 6.1 INDLEDNING ........................................................................................................... 19 6.2 KMD OPUS DEBITOR ................................................................................................ 19 6.3 UDFORDRINGER I DEN NUVÆRENDE LØSNING .................................................................. 22 6.3.1 UDFASNING AF NUVÆRENDE LØSNING ................................................................................ 23 7 ARBEJDET MED MANUELLE OPGAVER I UDBETALING DANMARK.............................. 24 7.1 ARBEJDSPAKKER ...................................................................................................... 24 7.2 SAGER ................................................................................................................... 24 7.3 HÆNDELSER ............................................................................................................ 24 7.4 TELEFONBETJENING .................................................................................................. 24 7.5 PROCES FOR DRIFTSPLANSTYRING ................................................................................. 24 7.6 KLAGER ................................................................................................................. 24 7.7 UDBETALING ........................................................................................................... 24 7.8 HELHEDSORIENTERET KONTROL (HOK) ......................................................................... 24 8 ATP’S IT-MILJØ........................................................................................................ 25 8.1 ATP’S NETVÆRK ...................................................................................................... 25 8.2 ATP’S PC-ARBEJDSPLADS........................................................................................... 26 9 ATP’S DRIFTSPROCESSER ......................................................................................... 27 9.1 SERVICE OPERATION ................................................................................................. 27 9.1.1 ATP’S SERVICEDESK ........................................................................................................ 27 Bilag 2 Situationsbeskrivelse Side 2 af 42 9.1.2 INCIDENT MANAGEMENT ................................................................................................. 28 9.1.3 SITUATION MANAGEMENT (MAJOR INCIDENTS) .................................................................. 30 9.1.4 PROBLEM MANAGEMENT ................................................................................................ 31 9.1.5 EVENT MANAGEMENT (OVERVÅGNING).............................................................................. 31 9.2 SERVICE TRANSITION................................................................................................. 32 9.2.1 RELEASE MANAGEMENT .................................................................................................. 32 9.2.2 TEST RELEASE MANAGEMENT ........................................................................................... 33 9.2.3 CHANGE MANAGEMENT .................................................................................................. 34 9.2.4 CONFIGURATION MANAGEMENT ....................................................................................... 39 9.2.5 DEPLOYMENT MANAGEMENT ........................................................................................... 39 9.2.6 VALIDATION & CONTROL ................................................................................................. 40 10 IT SERVICE MANAGEMENT SYSTEM ....................................................................... 41 10.1 INTRO TIL ITSM ..................................................................................................... 41 10.2 FUNKTIONALITET SOM PRODUKTET TILBYDER................................................................. 41 10.3 EKSTERNE SNITFLADER ............................................................................................. 42 10.4 KAPACITET ............................................................................................................ 42 Bilag 2 Situationsbeskrivelse Side 3 af 42 1 Vejledning til Tilbudsgiver Bilaget skal ikke ændres af Tilbudsgiver. Tabel 1 Vejledning til Tilbudsgiver Bilag 2 Situationsbeskrivelse Side 4 af 42 2 Indledning 2.1 Bilagets formål og opbygning Bilaget indeholder en situationsbeskrivelse, der har til formål at give Leverandøren en grundlæggende forståelse af en række områder: • ATP koncernen og dens opgaver • Udbetaling Danmarks formål, opgaver og organisering og ATP’s rolle i forhold hertil • Debitorfunktionen • Den nuværende it-løsning til administration af debitorfunktionen og hvordan denne udfases 2.2 • ATP’s nuværende it-miljø • ATP’s IT-driftsprocesser • ATP’s metode til forretningsmodellering og behovsopgørelse Underbilag Bilaget har følgende underbilag: Bilag Indhold Bilag 2A (Sådan forretningsmodelle- Beskrivelse af ATP’s metoder til forretningsmodellering og rer vi i ATP) opgørelse af forretningsmæssige behov. Bilag 2B (Eksisterende data) En introduktion til de data, der skal konverteres fra den nuværende debitorløsning. Dels beskrives den nuværende løsnings data på et forretningsmæssigt niveau i begrebs- og informationsmodeller, og dels beskrives den overordnede struktur og format af det dataudtræk, som den nuværende leverandør skal etablere. Bilag 2C (ATP PC-arbejdsplads) Detaljeret beskrivelse af ATP PC-arbejdsplads. Tabel 2 Underbilag til bilag 2 Situationsbeskrivelse Bilag 2 Situationsbeskrivelse Side 5 af 42 3 Introduktion til ATP koncernen ATP Koncernen er Danmarks største pensions- og sikringsselskab og løser opgaver for næsten alle borgere og virksomheder i Danmark. ATP er blandt Europas største pensionsvirksomheder. Grundlaget for ATP’s virksomhed er fastlagt ved lov. ATP er således en lovreguleret, selvejende institution med det formål at administrere pensionsordningen ATP. Ved siden af ATP-ordningen har Folketinget placeret administrationen af Supplerende Arbejdsmarkedspension (SUPP) hos ATP. ATP administrerer herudover en række andre lovbestemte ordninger på omkostningsdækket basis, herunder Udbetaling Danmark. Herudover sælger ATP via et helejet datterselskab administrationsydelser på markedsvilkår. ATP Koncernen har hovedsæde i Hillerød. Udbetaling Danmarks centre er placeret i Frederikshavn, Holstebro, Haderslev, Vordingborg og Hillerød. Pr. 1. september 2014 har ATP Koncernen ca. 2.000 medarbejdere. 3.1 ATP’s opgaver ATP Koncernens aktiviteter kan inddeles i fire virksomheder, som arbejder med: • Pension • Afdækning • Investering • Administration De ordninger, som ATP administrerer, fremgår af nedenstående figur: Bilag 2 Situationsbeskrivelse Side 6 af 42 Figur 1 Overblik over de ordninger, som ATP administrerer 3.2 Organisation ATP-loven fastlægger formål og rammer for ATP’s administration, herunder for ATP’s ledelse. ATP ledes af et repræsentantskab, en bestyrelse og en direktør, og sammensætningen af ATP’s repræsentantskab og bestyrelse er fastsat i loven. ATP’s direktør ansættes af bestyrelsen. Repræsentantskabet er sammensat af 15 arbejdsgiverrepræsentanter, 15 lønmodtagerrepræsentanter og en formand, som repræsentantskabet udnævner. Formanden må ikke have tilknytning til nogen lønmodtager- eller arbejdsgiverorganisation. Bestyrelsen er sammensat af 6 arbejdsgiverrepræsentanter, 6 lønmodtagerrepræsentanter og repræsentantskabets formand. Det følger af loven, at ATP ikke har en næstformand, og at ATP’s medarbejdere ikke er repræsenteret i bestyrelsen. ATP’s organisation er vist i efterfølgende figur. Bilag 2 Situationsbeskrivelse Side 7 af 42 Figur 2 Organisationsdiagram for ATP Organiseringen af ATP’s administrationsforretning er vist i efterfølgende figur. Figur 3 Organisationsdiagram for ATP’s administrationsforretning Bilag 2 Situationsbeskrivelse Side 8 af 42 3.3 ATP’s digitaliseringsstrategi ATP’s digitaliseringsstrategi beskriver ATP’s tanker om, hvordan ATP ønsker at fastholde en position som en konkurrencedygtig administrator, der er kendt for enkle og intuitive løsninger. Det skal ske gennem god kundeservice i øjenhøjde og effektivisering af vores administrative processer. Strategien tager afsæt i ATP’s forretningsmål og det offentlige Danmarks digitaliseringsmål. ATP vil sammen med relevante offentlige instanser styrke den digitale udvikling i Danmark. Yderligere detaljer om digitaliseringsstrategien kan findes i dokumentet atp_digitaliseringsstrategi2014_2018.pdf, der er vedlagt udbudsmaterialet. Bilag 2 Situationsbeskrivelse Side 9 af 42 4 Introduktion til Udbetaling Danmark 4.1 Formål Udbetaling Danmark er en offentlig myndighed, der drives af ATP-koncernen. Myndigheden har ansvar for udbetaling af en række offentlige ydelser til borgerne. Opgaverne lå tidligere i landets 98 kommuner. Udbetaling Danmark blev dannet, da KL og regeringen i juni 2010 indgik en aftale om at samle dele af den objektive sagsbehandling i fem centre med virkning fra efteråret 2012. Efter en toårig indfasning skal centraliseringen spare kommunerne for knap 300 mio. kr. om året. Ud over besparelsen skal stordriftsorganisationen sikre en mere ensartet sagsbehandling på de berørte områder. 4.1.1 Lovgivning I december 2010 vedtog Folketinget Lov om etablering af Udbetaling Danmark, som danner den juridiske ramme for etablering af myndigheden. Den 29. marts 2012 vedtog Folketinget to love, der erstatter og supplerer etableringsloven fra 2010. Den ene lov fastlægger rammerne for Udbetaling Danmarks sagsbehandling og administration af lovgivningen på de respektive myndighedsområder. Loven fastlægger desuden rammerne for samarbejdet med kommunerne om helhedsorienteret vejledning af borgeren, udveksling af oplysninger og samarbejde om kontrol. Den anden lov omhandler de ændringer i ydelseslovgivningen, som fastlægger den nærmere fordeling af sagsområder mellem Udbetaling Danmark og kommunerne. 4.1.2 Ensartet sagsbehandling Centraliseringen skal sikre en mere ensartet sagsbehandling på områderne, og arbejdet skal udføres som omkostningsdækket virksomhed, hvor Udbetaling Danmark afregner med kommunerne. 4.1.3 Kontrol med ydelser Udbetaling Danmark har også ansvaret for, at borgere til enhver tid opfylder kravene for at få ydelsen og for at forebygge, at borgere modtager ydelser uberettiget fra Udbetaling Danmark. Sager, hvor der er mistanke om uberettigede ydelser, skal undersøges i tæt samarbejde mellem Udbetaling Danmark og kommunerne. Bilag 2 Situationsbeskrivelse Side 10 af 42 Ved etableringen af Udbetaling Danmark skabes der nye digitale muligheder i form af registersamkøringer, samtidig med at der skal udveksles informationer på tværs af instanser. Samlet skabes der på landsplan et omfattende kontrolapparat, som giver bedre muligheder for at forhindre socialt bedrageri og dermed også realisere det betydelige økonomiske potentiale, der er på området. Der er vedtaget en strategi for arbejdet med kontrol i bestyrelsen for Udbetaling Danmark. Udgangspunktet er, at der allerede ved tilkendelsen af ydelsen skal laves et grundigt kontrolarbejde for at undgå, at der sker udbetalinger, som borgeren ikke er berettiget til. I strategien beskrives også samarbejdsmodellen for kommuner og Udbetaling Danmark på kontrolområdet. 4.1.4 ATP driver myndigheden ATP leverer teknisk og administrativ bistand til Udbetaling Danmark og er også arbejdsgiver for medarbejderne i Udbetaling Danmark. 4.1.5 Sagsområderne Familieydelser og barseldagpenge overgik i slutningen af 2012 til Udbetaling Danmark, og den 1. marts 2013 blev de sidste tre sagsområder – boligstøtte, folkepension og udbetaling af førtidspension overdraget sammen med opgaven med opkrævning og helhedsorienteret kontrol. Fra den 1. juni 2013 har Udbetaling Danmark også overtaget ansvaret for international pension og social sikring fra Pensionsstyrelsen. 4.1.6 Selvbetjening for borgere på borger.dk En altovervejende del af Udbetaling Danmarks borgerbetjening foregår på borger.dk, hvor borgeren kan få overblik og ansøge om ydelserne. Derudover er det muligt at ringe eller sende digital post til Udbetaling Danmark. Borgere med særlige behov, kan fortsat kontakte deres kommune. Kommunerne vil fortsat tage sig af enkelte opgaver - fx skal de fortsat afgøre, om borgeren er berettiget til førtidspension, men kommunen skal ikke udbetale pengene. 4.1.7 Selvbetjening for arbejdsgivere, a-kasser og selvstændige via NemRefusion Selvbetjening for arbejdsgivere, a-kasser og selvstændige foregår i løsningen NemRefusion, der ligger på virk.dk. Løsningen blev gjort obligatorisk i september 2011, og er dermed den primære digitale kanal for ovenstående til Udbetaling Danmark. Bilag 2 Situationsbeskrivelse Side 11 af 42 Løsningen gør det muligt for ovenstående at anmelde et fravær. Arbejdsgivere kan desuden søge om refusion for den løn de udbetaler til medarbejdere under barsel og selvstændige kan søge om barseldagpenge via NemRefusion. Herudover kan arbejdsgivere fremsøge deres udbetalinger af refusion, og derved gør NemRefusion det muligt for arbejdsgivere at afstemme udbetalinger af refusion. 4.2 Udbetaling Danmarks centre Udbetaling Danmark løser opgaverne fra fem centre i Frederikshavn, Holstebro, Haderslev, Vordingborg og Hillerød. Alle centre betjener borgere fra hele landet. 4.3 Organisation Udbetaling Danmark er en offentligt reguleret selvejende institution med myndighedsansvar. Udbetaling Danmark ledes af en bestyrelse og en direktør. Bilag 2 Situationsbeskrivelse Side 12 af 42 5 Introduktion til debitorfunktionen 5.1 Indledning For at give en introduktion til debitorfunktionen, beskrives dette kort i de nedenstående afsnit i form af 5.2 • Hvad er debitorfunktionen • Lovgivningen • Særlige forhold for debitorfunktionen • IGOE for ydelsesområdet • Administration af nuværende forretningsløsning • Faktaboks for debitorfunktionen Hvad er debitorfunktionen? Debitorfunktionen håndterer overordnet set nedenstående hovedområder: • Løbende opkrævning og rykning af bidragskrav • Opkrævning og rykning af tilbagebetalingskrav • Oversendelse af krav til Skat via EFI (både til modregning og inddrivelse) og efterfølgende behandling af restantsager • Fastsættelse af afdragsordninger eller henstand • Frivillige afdragsordninger • Håndtering af krav, der bliver betalt via modregning i egne og andre ydelser – både interne og eksterne. • Låneadministration for boligstøttelån – håndtering af rentetilskrivning, opkrævning mv. Ovenstående områder varetages for de ydelser, som Udbetaling Danmark administrerer. Debitorbestanden hos Udbetaling Danmark består af både borgere og virksomheden, hvoraf størstedelen er borgere, der betaler bidragskrav. Hver måned dannes der ca. 80.000 opkrævninger. Heraf opkræves de 24.000 via Betalingsservice. En stor andel af opkrævningerne bliver efterfølgende overdraget direkte til SKAT via EFI i stedet for at indgå i almindelig rykkerprocedure. Der er registreret knap 1 mio. borgere / virksomheder i det nuværende debitorsystem. Registreringen vedrører både igangværende og afsluttede gældsforhold. Bilag 2 Situationsbeskrivelse Side 13 af 42 5.3 Lovgivningen Debitorfunktionen er underlagt den til enhver tid gældende lovgivning. For debitorfunktionen favner den gældende lovgivning bredt og omfatter bl.a.: • Forvaltnings- og personretlige regler • Specifikke regler for Udbetaling Danmark der bl.a. følger af Udbetaling Danmark-loven • Ydelsesspecifikke love i det omfang der er bestemmelser, som regulerer håndteringen af krav ift. det konkrete ydelsesområde • Forældelseslovens regler • Inddrivelseslovens regler med tilhørende bekendtgørelser. Ovenstående liste af regler er ikke udtømmende. Det er kun et udsnit af lovgivningen og skal illustrere bredden i den lovgivning, der regulerer debitorfunktionen. Ved siden af lovgivningen gælder også praksis samt almindelige forvaltningsretlige principper om god sagsbehandlingsskik. 5.4 Særlige forhold for debitorfunktionen Der er nogle forskellige forhold i Udbetaling Danmark, hvor Udbetaling Danmark adskiller sig fra en ”almindelig” debitorfunktion: Forskellige typer af krav: Udbetaling Danmark håndterer to typer af krav: Bidragskrav og Tilbagebetalingskrav. Bidragskrav vedrører betaling af underholdsbidrag (primært børne- og ægtefællebidrag). De opkræves normalt som et månedligt bidrag, hvor beløbet er fastsat af Statsforvaltningen. Bidragskravene kan igen overordnet opdeles i typer, som Udbetaling Danmark opkræver: • Forskudsvist udlagt bidrag, hvor Udbetaling Danmark allerede har udbetalt bidraget til berettigede og efterfølgende opkræver bidraget hos bidragsbetaler. • Ej forskudsvist udlagt bidrag, hvor der først sker udbetaling til bidragsberettigede, når bidragsbetaler har betalt. Det er Statsforvaltningen der træffer afgørelse om, hvorvidt de forskellige bidrag skal være forskudsvis udlagte eller ej-forskudsvis udlagte. Bilag 2 Situationsbeskrivelse Side 14 af 42 Bidragskravene udgør langt størstedelen af de 80.000 krav, der sendes opkrævning på hver måned. Tilbagebetalingskrav er typisk enkeltstående krav, der dannes og opkræves, når de opstår. Tilbagebetalingskrav kan både opstå som følge af reguleringer på sager, og de kan opstå i forlængelse af kontrolarbejdet. Boligstøtteområdet og pensionsområdet står for størstedelen af tilbagebetalingskravene, men de kan opstå for alle de ydelsesområder, som Udbetaling Danmark administrerer. Tilbagebetalingskrav opkræves hos både borgere, virksomheder og offentlige myndigheder. I løbet af et år dannes der ca. 65.000 tilbagebetalingskrav for alle ydelserne, heraf dannes over halvdelen af kravene i maj måned og er foranlediget af den årlige efterregulering på boligstøtte- og pensionsområdet. Modregning: Som følge af lovgivningen skal Udbetaling Danmark kunne håndtere, at ”betalingen” af udvalgte krav skal ske via modregning i ydelser, der udbetales af forskellige fagsystemer, både interne og eksterne. EFI: Inddrivelsen af krav, som borgeren ikke har betalt, sker via EFI (SKAT). Internt i Udbetaling Danmark betyder det, at en del af processerne og den systemmæssige understøttelse skal være tilrettet EFI og de informationer, der modtages herfra. For borgeren har det bl.a. den konsekvens, at kommunikationen om gæld til Udbetaling Danmark, kommer fra to forskellige myndigheder. Det stiller store krav til viden om processerne hos SKAT, når man ønsker at give en klar og overskuelig kommunikation til borgeren omkring disse forhold. Medhæfter: Medhæfter anvendes når flere personer hæfter for samme krav. Det er tilfældet, når der bor flere personer over 18 år på den adresse, som der sker udbetaling af boligstøtte for, uanset hvem af de pågældende personer, der modtager boligstøtteudbetalingen. Bilag 2 Situationsbeskrivelse Side 15 af 42 Behov for ændringer: Der er forholdsvis ofte lovmæssige ændringer til de ydelsesområder, som Udbetaling Danmark administrerer, og antallet af ydelser, som Udbetaling Danmark skal administrere, kan ændre sig. Idet debitorfunktionen skal håndtere krav for alle Udbetaling Danmarks ydelsesområder, er det essentielt, at der kan ske ændringer i funktionen, så man kan behandle eksisterende krav på en ny måde eller modtage krav for nye områder. Rapporteringskrav: Der stilles store krav til rapporteringsmuligheder fra debitorområdet både i form af særlige krav i forbindelse med regnskabsaflæggelsen og krav om rapportering foranlediget af stor politisk bevågenhed i forhold til, hvor mange penge der kommer tilbage i hhv. statskassen og kommunekasserne. Der er stor interesse for kontrolområdet, og i forbindelse med forskellige politiske tiltag er der også efterspørgsel på viden omkring øvrige mængder af krav (antal og beløb) ud fra forskellige kriterier. 5.5 IGOE for ydelsesområdet Der er udarbejdet en IGOE for ydelsesområdet som illustrerer det fremtidige ydelsesområde ud fra 4 kriterier: • I (Input) = Hvad er input til start af processen og hvem kommer med det • G (Regler/rammer) = Rammerne relaterer til ATP`s interne politikker og reglerne er at sidestille med den lovgivning, der er styrende for processerne • (Output) = Hvilket output generer processen • E (Ressourcer) = Hvilke systemer samt ressourcer er tilknyttet for at understøtte den faglige og tekniske del af processen. De er alle kilder til den endelige destination; resultatet. Bilag 2 Situationsbeskrivelse Side 16 af 42 Det sammenkædede billede kan ikke vises. Filen er muligvis blevet flyttet, omdøbt eller slettet. Kontroller, at hyperlinket peger på den korrekte fil og placering. Figur 4 IGOE for To-be Debitor 5.6 Administration af nuværende forretningsløsning Opkrævningerne dannes med udgangspunkt i de informationer, der modtages fra de forskellige fagsystemer. Generering af krav har derfor en stor afhængighed til de fagsystemer, hvori selve sagsbehandlingen sker. I dag sker der både manuel og automatisk oprettelse af krav på baggrund af informationer fra fagsystemerne. Debitorfunktionen opretter automatisk krav vedr. løbende opkrævninger af underholdsbidrag. Tilbagebetalingskrav oprettes automatisk vedr. boligstøtte og som følge af efterregulering af børneungeydelsen. Bidragsområdet og boligstøtteområdet kører fuldautomatisk for de fleste krav. I dag oprettes der manuelle krav indenfor alle ydelsesområderne. For bidragsområdet sker det, når der er tale om et tilbagebetalingskrav på dette område, og mere generelt sker det, når der opstår tilbagebetalingskrav på baggrund af kontrolarbejdet. Håndteringen af processerne sker ud fra kendt debitorfunktionalitet kombineret med en del fagspecifikke regler, der er integreret ind i løsningen. Når egne opkrævnings- og modregningsmuligheder er udtømte, overdrages kravet til inddrivelse via EFI. Bilag 2 Situationsbeskrivelse Side 17 af 42 5.7 Faktaboks for debitorfunktionen Tabellen nedenfor viser mængder og omfang af hændelser relateret debitorfunktionen. Tallene er anslået og baseret på ATP’s foreløbige kendskab til sagsmængder, og vil kunne variere over tid: [her vil i en endelig version af udbudsmaterialet blive indsat hændelsesoversigt inkl. mængder for hændelserne] Tabel 3 Mængder og omfang af hændelser relateret til debitorfunktionaliteten Tabellen nedenfor angiver fakta omkring debitorfunktionaliteten. Fakta omkring administrationen af debitorfunktionaliteten Antal Antal opkrævninger pr. mdr. i alt (snit) 80.000 Antal opkrævninger pr. mdr. via Betalingsservice 24.000 Delmængde af de 80.000 opkrævninger pr. mdr. Antal tilbagebetalingskrav pr. år 65.000 Heraf ligger over halvdelen i maj måned. Antal debitorer sendt til inddrivelse via SKAT 113.000 Alle har minimum 1 krav. Der er typisk en del krav pr. person. Antal døde pr. måned 2.000 Tilbagebetalingskrav skal anmeldes til boet / Skifteretten Antal afdragsordninger oprettet pr. år 29.000 Antal modregningsaftaler pr. år 18.000 Modregnes i hhv. pension-, boligstøtte- og kontanthjælpsudbetaling Antal personer / virksomheder registreret i systemet Antal brugere på systemet Bilag 2 Situationsbeskrivelse 980.000 180 Side 18 af 42 6 Den eksisterende forretningsløsning 6.1 Indledning I det følgende gives en introduktion til hvilke systemer, der indgår i den nuværende forretningsløsning. Dette præsenteres med henblik på at give en forståelse af hvilket systemkompleks, der skal udfases fra. 6.2 KMD Opus Debitor Den eksisterende forretningsløsning er baseret på et KMD Opus Debitor samt en række KMD-støttesystemer. KMD Opus Debitor er et SAP-baseret fagsystem, som Udbetaling Danmark har taget i brug i december 2012, hvor Udbetaling Danmark overtog administrationen af debitorfunktionaliteten. KMD Opus Debitor indgår i et systemlandskab sammen med fagsystemer for Udbetaling Danmark ydelsesområderne barsel, pension, familieydelse og boligstøtte. KMD Opus Debitor anvendes desuden i forbindelse med andre ydelser og områder, som ikke administreres af Udbetaling Danmark. Der indgår en hel række KMD-støttesystemer i den eksisterende debitorløsning. Disse støttesystemer anvendes ikke kun til administrationen af debitorfunktionen, men også til administrationen af de øvrige ydelsesområder, som Udbetaling Danmark administrerer; barsel, pension, familieydelser og boligstøtte. Den efterfølgende figur viser den eksisterende debitorløsning: Bilag 2 Situationsbeskrivelse Side 19 af 42 Figur 5 Den eksisterende forretningsløsning til debitorfunktionen er baseret på KMD systemer. Som det fremgår af figuren består det nuværende debitorsystem primært af KMD Opus Debitor. Debitorsystemet integrerer til en række komponenter for at kunne levere sin fulde funktionalitet. Hver enkelt komponent der indgår i den eksisterende løsning er kort beskrevet i Tabel 6 nedenfor. Desuden anvendes KMD Sag, bestående af komponenterne KMD Sag Basis, KMD Sag Journal og KMD Sag EDH, som i den eksisterende løsning benyttes for at få en dækkende sagsbehandling af sager i debitorområdet. KMD Sag benyttes for at få et overordnet overblik over ind- og udgående post, journalnotater og manuelle og maskinelle adviser. For yderligere detaljer om KMD’s systemlandskab henvises til KMD kundenet: http://www.kundenet.kmd.dk/. Nedenstående komponentoversigt er foreløbig, og baseret på ATP’s foreløbige afdækning. Den vil blive opdateret i en senere version af udbudsmaterialet. Bilag 2 Situationsbeskrivelse Side 20 af 42 Komponent Beskrivelse BCF (Bogføringscentral) KMD Opus Debitor modtager indbetalingsadvisering fra Pengeinstituttets Bogføringscentral (BFC). Digital Post (E-boks) Borgerens eller virksomhedens digitale postkasse hos E-boks. Her kan kunden vælge at modtage digital post fra det offentlige, herunder post vedrørende debitorsager. Kassefunktion KMD Opus Debitor indeholder en kassefunktion til håndtering af kontantindbetalinger KMD Opus Kontoplan KMD Opus Kontoplan anvendes til opsætning af kontoplan, og sender relevante kontoplan information til KMD Opus Debitor. KMD Opus Organisations- KMD Opus Organisationsstyring anvender administrative enheder til brug for styring afsender-adressering. Disse oplysninger sendes til KMD Opus Debitor. ”KMD Fagsystemer” NB: Er ikke angivet som specifikke systemer. KMD Opus Debitor modtager krav fra et antal Fagsystemer, som Udbetaling Danmark administrerer, f.eks. KMD Social Pension, KMD Boligstøtte, KMD Børneydelser, KMD Opus Barsel, KMD UHB og KMD UHB Administration. KMD P-data KMD P-data leverer oplysninger om alle personer i Danmark til flere forskellige KMD systemer på baggrund af data fra CPR-registeret. KMD Sag Basis KMD Sag Basis er et centralt sagshåndteringssystem, som anvendes af både Udbetaling Danmark og kommunerne til administrationen af mange forskellige ydelser. I KMD Sag opbevares bl.a. debitorsager og udstiller et personoverblik, som inkluderer et overblik over personens ydelser på tværs af fagsystemer. KMD Sag EDH Elektronisk dokumenthåndteringssystem som benyttes til håndtering af ind- og udgående post, samt udgående manuelle breve. Systemet er tæt integreret med KMD Sag Basis. Systemet benyttes bl.a. til tilknytning af dokumenter til sager, ud- og indtjekning af dokumenter, samt oprettelse af dokumenter på baggrund af skabeloner. Komponenten stiller søgefunktioner til rådighed, og kan sende til en digital postkasse. Den har også ansvaret for at håndtere dokument konvertering og skanning. KMD Sag Journal KMD Sag Journal har ansvaret for at danne journalnoter. Den kan vise systemnotater og manuelt oprettede noter. Systemet har ansvaret for automatisk journalisering af sagsoplysninger og afgørelser om bevilling/afslag i KMD Sag Journal iht. god administrativ praksis om notatpligt. KMD Udbetaling KMD Udbetaling modtager udbetalingsanmodninger fra KMD Opus Debitor, f.eks. i forbindelse med tilbagebetaling af for meget indbetalte beløb. Systemet håndterer selve udbetalingen til modtagers NemKonto. Bilag 2 Situationsbeskrivelse Side 21 af 42 Komponent Beskrivelse KMD V-DATA KMD V-data leverer virksomhedsoplysninger til en række KMD systemer baseret på virksomhedsoplysninger fra CVR og SKAT. Nets Nets tager sig af de opkrævninger, som foretages med Betalingsservice. KMD Opus Debitor sender opkrævninger til Nets, samt til- og frameldelser af BS-aftaler. Nets returnerer indbetalinger, afvisninger og tilbagekaldelser af indbetalinger, samt til- og frameldelser af BS-aftaler. KMD Mailcenter KMD Mailcenter anvendes til print, kuvertering og udsendelse af uddata. KMD Opus Brugerstyring KMD Opus Brugerstyring anvendes til at effektivisere styringen af brugere og rettigheder på tværs af koncernløsningen KMD Opus. SKAT EFI SKAT EFI (Et fælles Inddrivelsessystem) modtager fordringer (krav) fra KMD Opus Debitor til modregning i overskydende skat, eller til inddrivelse, når KMD Opus Debitors egne rykkermuligheder er udtømt. SKAT COR SKAT COR modtager årligt oplysningspligtige beløb (bl.a. renter/bidrag) for debitorsager. Tabel 4 KMD støttesystemer 6.3 Udfordringer i den nuværende løsning En af de væsentlige udfordringer i den eksisterende forretningsløsning er, at en stor del af regler mv. er kodet ”dybt” ind i funktionaliteten i systemet. Det bliver således meget tungt og komplekst at få gennemført de ændringer, som løbende sker i regler og lovgivning. Der opstår ligeledes behov for rettelser i de tilfælde, hvor den eksisterende forretningsløsning forhindrer, at Udbetaling Danmark kan leve op til egne succeskriterier om borgernes oplevelse af Udbetaling Danmark og effektiv administration. Udfordringerne i den nuværende løsning opstår især i samspillet med fagsystemerne for de øvrige ydelsesområder. Det er ikke muligt at få alle data og informationer ind i debitorsystemet, som er nødvendige for, for at kunne gennemføre korrekte opkrævninger og videre korrekt behandling af de enkelte krav. ATP oplever også udfordringer ift. målet om, at borgeren skal opleve sags- og kommunikationsgangen som en sammenhængende proces. Udfordringerne grunder i samspillet med fagsystemerne i forbindelse med efterfølgende tilretninger af krav ved ændringer og mulighederne for at indarbejde informationer fra fagsystemet i dialogen med borgeren. Der mangler tillige automatiske varianter af breve, for at kommunikationen med borgerne er korrekt i alle situationer. Bilag 2 Situationsbeskrivelse Side 22 af 42 En anden udfordring er, at muligheden for tildeling af adgange i systemet ikke understøtter den krævede funktionsadskillelse. Adgangen til at løse konkrete (manuelle) opgaver i debitorsystemet i den nuværende løsning bliver derfor betinget af organisatorisk tilhørsforhold, hvilket giver ressourcemæssige udfordringer i perioder, hvor der er mange opkrævninger. 6.3.1 Udfasning af nuværende løsning Forud for igangsættelsen af dette udbud er der indgået aftale med den eksisterende leverandør af debitorløsningen, omkring udfasning af debitordata vedrørende familieydelse. Denne aftale benævnes populært ”Udfasningsassistance”. Aftalen om udfasningsassistance omfatter leverance af data ekstrakt, dokumentation af data mv. for data i KMD OPUS Debitor vedrørende Familieydelser. Udfasning af data for øvrige fagsystemer vil skulle indgås senere. Aftalen kan findes på ATP’s udbudsportal her: [her vil i en endelig version af udbudsmaterialet blive indsat et link til udfasningsaftalen, når denne er indgået] Bilag 2 Situationsbeskrivelse Side 23 af 42 7 Arbejdet med manuelle opgaver i Udbetaling Danmark I dette kapitel beskrives den arbejdsform, der anvendes i Udbetaling Danmark ved den manuelle sagsbehandling. Der henvises i øvrigt til: • Bilag 3A.1 (Kravliste), der indeholder kravene til den fremtidige brugergrænseflade. [Dette afsnit er endnu ikke udarbejdet] 7.1 Arbejdspakker 7.2 Sager 7.3 Hændelser 7.4 Telefonbetjening 7.5 Proces for driftsplanstyring 7.6 Klager 7.7 Udbetaling 7.8 Helhedsorienteret Kontrol (HOK) Bilag 2 Situationsbeskrivelse Side 24 af 42 8 ATP’s it-miljø I dette afsnit præsenteres den del af ATP’s it-miljø, som er relevant for Systemet. Det drejer sig om ATP’s netværksstruktur omkring de forskellige Udbetaling Danmark centre, samt kunderådgivernes PC-arbejdsplads. 8.1 ATP’s netværk Den overordnede struktur af ATP’s netværk er illustreret på Figur 5. Som det fremgår af figuren, har alle ATP’s lokaliteter/centre et Data-LAN og et Service-LAN. Data-Lan er det daglige LAN, trådført og trådløst. Udstyr på DataLAN har internet adgang. Service-LAN er et driftsnet til døralarmer, overvågning og bygningskomponenter der kræver netværksadgang. Udstyr på Service-LAN har internet adgang. Drift af ATP’s netværk leveres dels af KMD (WAN) og dels af Atea (LAN). Alle ATP’s lokaliteter og KMD Datacenter er forbundet via WAN funderet på MPLS teknologi. Eksterne leverandører er forbundet via firewall i KMD Datacenter. Alt netværksudstyr er overvåget. Figur 6 ATP's netværksinfrastruktur. Bilag 2 Situationsbeskrivelse Side 25 af 42 8.2 ATP’s PC-arbejdsplads En detaljeret beskrivelse af ATP’s PC-arbejdsplads findes i bilag 2C (ATP PCarbejdsplads). Bilag 2 Situationsbeskrivelse Side 26 af 42 9 ATP’s driftsprocesser Dette afsnit indeholder en beskrivelse af ATP’s nuværende IT driftsprocesser. ATP’s IT-afdeling arbejder i udgangspunktet efter ITIL standardprocesserne. Den konkrete implementering af processerne er tilpasset ATP’s organisation. I det følgende gennemgås ATP’s tilpassede ITIL standardprocesser, startende med de processer, der bruges i forbindelse med Service Operation og herefter beskrives processerne under Service Transition. 9.1 Service Operation 9.1.1 ATP’s ServiceDesk ATP’s ServiceDesk fungerer som SPOC (single point of contact) i forhold til alle henvendelser vedr. IT-fejl (Incidents) og IT-service bestillinger (Service Requests) både for ATP’s interne kunder og eksisterende leverandører som har driftsansvar for ATP’s forretningssystemer. ATP’s IT Service Operation er sektionen, der skal sikre stabil drift ved at: • ATP’s forretning og eksisterende leverandører har ét kontaktpunkt (ATP’s ServiceDesk), når de skal henvende sig med fejlmeddelelser og forespørgsler vedr. IT-service. • Levere IT service effektivt som aftalt indenfor alle processer og funktioner under Service Operation. • Sikre hurtigt og effektivt at reetablering af IT services i tilfælde af nedbrud. • Kommunikere status på IT services til forretning / eksisterende leverandører ved nedbrud. ATP’s ServiceDesk skal sikre overblik over alle henvendelser, uanset løsningsansvarlig tekniker / eksisterende leverandør, og er ansvarlig for opfølgning, eskalation og kommunikation til slutbrugerne i forbindelse med fejl i IT-systemerne. Bilag 2 Situationsbeskrivelse Side 27 af 42 Borgere ATP’s driftsstatus Spørgsmål vedr. applikationer / proceser Fagcoach superbruger Kundeservice medarbejdere Leverandør X’s driftsstatus ATP ServiceDesk Leverandør A Leverandør B Leverandør C Leverandør Y Leverandør Z Leverandør W M.m.m. Tekniker / specialist Tekniker / specialist ATP IT-tekniker / Udbetaling IT-specialist Danmark organisation Tekniker / specialist Tekniker / specialist Tekniker / specialist Tekniker / specialist Figur 7 ATP ServiceDesk. Nedenstående processer anvendes i ATP’s IT service operation: Figur 8 Processer i ATP’s IT service operation. 9.1.2 Incident Management Det primære mål med Incident Management er at genskabe normalt IT-service niveau så hurtigt som muligt og efter de gældende service aftaler – og samtidig sikre, at IT-driftsforstyrrelser belaster den primære forretning mindst muligt. Bilag 2 Situationsbeskrivelse Side 28 af 42 De primære opgaver for Incident Management er: • Modtage, registrere og prioritere alle henvendelser (Incidents) vedrørende IT • Undersøge, diagnosticere og afhjælpe kendte Incidents. • Kontrollere at der findes kendte løsninger /”work-arounds” på registrerede Incidents. • Eskalere Incidents, når årsag/løsning ikke kan identificeres /anvendes. Alle Incidents prioriteres efter følgende kriterier: Impact Prioritets matrix I hvilken grad har denne Incident konsekvenser for forretningen? I hvilken grad påvirker denne Incident IT-miljøets øvrige driftsstabilitet? Urgency High Medium Low High 1 2 3 Medium 2 3 4 Low 3 4 4 Tabel 5 Prioritetsmatrix. Kriterier for Incidents • Prioritet 1 Kritisk onstid Alle brugere i samme funktion er Løsningstid Der arbejdes indtil løs- Nedbrud på forretningskritisk system. • Reakti- < 15 min. ning/”work-around” er fundet. forhindret i at udføre deres arbejde. • Fejl med forretningskritisk konsekvens. Fejl med prioritet 1 håndteres via processen (Situation Management). Bilag 2 Situationsbeskrivelse Side 29 af 42 Kriterier for Incidents • Prioritet 2 Haster • onstid Løsningstid Der arbejdes indenfor Forøgede svartider, som belaster forretningskritiske systemer. • Reakti- < 60 min. arbejdstid indtil løs- Flere brugere i samme funktion er ning/”work-around” er forhindret i at udføre deres arbejde. fundet. Overvågningssystemer viser generelle fejl / lang svartid, som berører brugerne. • Arbejde afbrudt, men der findes Prioritet 3 alternativ løsning (work-around). Normal Problemet vedrører én eller flere < 8 timer. 2 dage. around” – og skal løses, men det Efter Efter aftale. haster ikke. aftale. personer, som er generet i at udføre sit arbejde og kun kan anvende IT i begrænset omfang. • Adgang til relevante drev / ustabil PC. • Lange svartider i applikation eller lignende, men der er øvrige opgaver, som kan udføres samtidig. • Prioritet 4 • Incident er omgået med ”work- Brugeren har Problemer med sin ITarbejdsplads / applikation, som påvirker arbejdet, men det kan accepteres midlertidigt. Tabel 6 Kriterier for Incidents. 9.1.3 Situation Management (Major Incidents) Situation Management igangsættes i forbindelse med Major Incidents (prioritet 1). I Service Operation er der ansat et team af medarbejdere, som har rollen ”Situation manager” i tilfælde af en Major incident. Formålet med processen for Major Incident er: • Sikre styring og koordinering af alle løsningsansvarlige for at retablere service hurtigst muligt. Bilag 2 Situationsbeskrivelse Side 30 af 42 • Sikre at brugere og forretnings-interessenter holdes løbende orienteret omkring fremdrift og løsningshorisont. Hvor eksterne leverandører har ansvar for løsning / omgåelse, er det pågældende leverandørers ansvar at håndtere fejlen jf. Incident Management processen, herunder information til ATP samt horisontal og vertikal eskalation i egen organisation. Indenfor normal arbejdstid vil ATP udpege en Situation Manager hos ATP, som dels er i dialog med eksisterende leverandørers Situation Manager, og dels varetager den interne kommunikation til interessenter i ATP. Når en løsning er fundet og service reetableret er det Situation Managerens ansvar at skrive en redegørelse til interne forretningsinteressenter, herunder en beskrivelse af mulige årsagsforklaringer, hvis de eksisterer på dette tidspunkt. Alle Major Incidents initierer et efterfølgende forløb hos Problem Management for at afklare årsag (root cause) til fejlen. 9.1.4 Problem Management Formålet med Problem Management processen er at minimere generne for Kunderne ved proaktivt at identificere og analysere årsagen til fejl og ved at håndtere Problemer og kendte fejl, indtil disse lukkes. For Problems, som påvirker aftalte IT-services indenfor ATP’s eget driftsansvarsområde, har ATP følgende opgaver. • Identificere root-cause for fejlen til endelig redegørelse. • Arbejde på løsninger, for at undgå lignende fejl opstår igen. • Løbende at rapportere status til interessenter i forhold til fremdriften på initierede Problems. • Et Incident genererer et Problem, når én eller flere af følgende betingelser er opfyldt: 9.1.5 o Ved et Major incident, hvor der er foretaget work around. o Root cause til et Incident ikke er fundet. o Der er genereret mange identiske Incidents. Event Management (overvågning) Formålet med Event Management er at sikre, at aftalte IT-services overvåges og monitoreres, således at reaktions- og løsningstid ved evt. driftsforstyrrelser minimeres. Den etablerede overvågning danner samtidig grundlag for rapportering af aftalte servicemål (KPI’er). Bilag 2 Situationsbeskrivelse Side 31 af 42 ATP overvåger egne driftsmiljøer med 2 overvågningsværktøjer: • HP BSM (BAC) version 9: Formålet med BAC-overvågningen er at etablere en bruger-simulereret end-to-end måling for udvalgte forretningstransaktioner (services) efter aftale med ATP’s forretning. • OneView: Formålet med Oneview systemet er at overvåge infrastruktur på egne driftsmiljøer, samt overvåge udvalgte Web-services, hvor overvågningen bidrager til at klarlægge årsager til Incidents. Oneview-systemet aflæser blandt andet logfiler fra driftsmiljøet. Der er opsat overvågningsskærme i ServiceDesk og eventuelle. udsving på BAC og Oneview eskaleres fra ServiceDesk til Situation Management. 9.2 Service Transition 9.2.1 Release Management 9.2.1.1 Formål Formålet med Release Management processen er at fastlægge indhold i en Release i samspil med forretningen, sikre at afhængigheder og risici for en Release bliver afdækket, samt sikre, at iværksættelse af ny og ændret funktionalitet bliver idriftsat sikkert med minimal og aftalt afbrydelse af eksisterende drift. Release Management fastlægger Releasekalender i samarbejde med Change Management, overvåger arbejdet, håndterer Problems, rapporterer fremdrift og foretager korrigerende handlinger for at sikre, at Releasen holder sig inden for de fastsatte tolerancer. 9.2.1.2 Releasevinduer Type Beskrivelse Mindre løft Mindre løft vil i henhold til Releasekalender ligge i servicevindue på udvalgte torsdage. Disse mindre løft er kendetegnet ved: • Kendt lav risiko (lav sandsynlighed for at der opstår fejl og lav konsekvens, hvis der opstår fejl). • Kendt kvalitet. • Lav kompleksitet (lav Impact på andre ting i eget systemområde (ingen impact på andre systemområder). • Løsning må ikke kræve ændring af integrationsaftaler. • Ubemandet ift. Release Management, Change Management og udvikling. Bilag 2 Situationsbeskrivelse Side 32 af 42 Type Beskrivelse • Efter løft skal eksisterende leverandører selv foretage teknisk verifikation. Ved fejl skal en kendt fall-back iværksættes. • Releases Systemerne skal være fuldt funktionsdygtigt efter et mindre løft. Releases vil i henhold til Releasekalender ligge i servicevindue 5 weekender årligt. For at komme med i en given Release kræves det, at: • Der er en Release koordinator, som single point of contact. • Test skal være planlagt. • Integrationspunkter er analyseret. • Hvilke systemområder der påvirkes er analyseret. • Projektdeltagere er allokerede til projektet. • Den valgte Release er realistisk iht. Release iværksættelsestidspunkt. • Der er foretaget en risikovurdering ift. ovenstående. Ved eksisterende leverandørers klarmelding til Release, skal følgende være udført og tilsendt ATP: • Tests skal være gennemført som specificeret. • Systemområdets Change Order til Pilot og Prod frigivet til Change Management med godkendt projekttestrapport (Pilot udgave) • Projektets drejebøger fremsendt og godkendt af Release Management. Under iværksættelse skal eksisterende leverandører stille med ressourcer til følgende discipliner: • Koordination • Deployment • Teknisk verifikation • Fejlsøgning og koderettelser • Fall-back Tabel 7 Releasevinduer 9.2.2 Test Release Management 9.2.2.1 Formål • At sikre, at samspil mellem de enkelte ændringer er testet. • At Releasen i sin helhed understøtter performance og stabilitetskrav på baggrund af aftalte servicemål. • At sikre, at Releasen i sin helhed opfylder testkrav Bilag 2 Situationsbeskrivelse Side 33 af 42 9.2.2.2 Væsentligste triggere og input • Forretningsmæssige krav og ønsker til test • Ændringer i scope for en given Release - typisk på baggrund af: o Release-ledelses beslutninger. o Styregruppebeslutninger. o Ændret opsætning eller anvendelse af miljøer. o Ad hoc – Løbende håndtering af teststatus på projektleverancer (Release ændringsanmodninger m.v.). 9.2.2.3 Væsentligste output • Release teststrategi. • Leveranceoversigt ift. test. • Rapportering af samlet testfremdrift til brug for Release Management. • Kommunikation i form af møder med testledere, mail til interessenter samt information på Testportal. • Ændringer til scope/rammeplan på baggrund af test. 9.2.3 Change Management 9.2.3.1 Formål ATP's Change Management proces sikrer, at alle ændringer bliver registreret, vurderet, godkendt, prioriteret, planlagt, testet, implementeret, dokumenteret og reviewet i et kontrolleret forløb. Dette skal sikre, at standardiserede procedurer anvendes, for at gennemføre Changes kontrolleret og begrænse påvirkninger på forretningsapplikationer før og efter iværksættelse. Bilag 2 Situationsbeskrivelse Side 34 af 42 Figur 9 ATP’s Change Management proces. Formålet med ATP's Change Management proces er at sikre • At Changes i ATP's IT-systemer registreres. • At Changes oprettes effektivt og efter standardiserede metoder og standarder. • At alle Changes registreres i IT Service Management systemet, hvorfra der sker løbende rapportering og opfølgning til IT ledelsen. Herudover, kontrol af: o Rapporter (ordnings-, go-live-, afvigelses -, diverse opfølgningsrapporter). Bilag 2 Situationsbeskrivelse Side 35 af 42 9.2.3.2 o Releaseoversigt og Change statistik. o Eksisterende leverandøraftaler. Change typer ATP anvender følgende kategorisering af Changes: Change type Beskrivelse Emergency Change Formål med Emergency Change proceduren er at sikre løsning af en driftskrise hurtigst muligt (Major Incident eller Problem), eller at forhindre en nært forestående driftskrise i at opstå. Emergency Change definition: Alene fejlerettelser, ikke ny funktionalitet. Begrænsninger: • Må ikke implementere ny funktionalitet • Må kun bruges, når der akut skal rettes en fejl • Skal altid kunne relateres til Incident/Problem prioritet 1 eller 2 Normal Change Normal Change definition Change der kan planlægges og implementeres jf. aftalt forløb. Ny funktionalitet såvel som fejlrettelser. Standard Change (Pre- I forbindelse med Change Management kan det tillades at gen- autoriseret Change) nemføre pre-autoriserede Changes. Disse er opdelt i følgende kategorier: 1. Change under bagatelgrænsen (kræver ingen Change registrering) 2. Change på Positivlisten (pre-autoriseret, men som kræver Change registrering) Standard Changes kan gennemføres på alle tidspunkter og må ikke påvirke aftale servicemål og/eller generere nedetid. Changes under bagatelgrænsen skal fremgå på bagatellisten. Med bagatellisten gives der en mulighed for, at eksisterende leverandører og ATP kan tilføje specifikt definerede opgaver til listen, hvor begge parter vurderer, at disse kan gennemføres uden Change registrering. Tabel 8 Kategorisering af Changes. 9.2.3.3 Servicevinduer De planlagte servicevinduer i produktionsmiljøerne ligger typisk uden for servicemål-perioden, det vil sige i perioden 22-06. ATP har opdelt servicevinduerne efter følgende kategorier: Bilag 2 Situationsbeskrivelse Side 36 af 42 • Infrastruktur Change (dagligt omtalt som tekniske servicevinduer). • Patch (sikkerhedsopdateringer). • Mindre løft (se under Release Management). • Releases (se under Release Management). Der vil kunne forventes større eller mindre forstyrrelser i svartider og manglende tilgængelighed under servicevinduer. Servicevinduer er ikke omfattet i servicemålmålingerne. Nedenfor vises en oversigt over nuværende servicevinduer i ATP. Bilag 2 Situationsbeskrivelse Side 37 af 42 Figur 10 Oversigt over servicevinduer i ATP. Bilag 2 Situationsbeskrivelse Side 38 af 42 9.2.4 Configuration Management 9.2.4.1 Formål Formålet med Configuration Management er at: • Sikre overblik over og kontrolleret status på valgte komponenter, der indgår i de leverede services og infrastruktur. • Bibringe status på historik og aktuel status. • Vedligeholde nøjagtig konfigurationsinformation for komponenter og services og levere konfigurationsmodel for services, assets og infrastruktur ved at registrere relationerne mellem service assets og configuration items. Configuration Management bliver håndteret i tæt samarbejde med vores eksisterende leverandører, hvor eksisterende leverandører til enhver tid skal kunne udlevere data fra deres CMDB til ATP. 9.2.5 Deployment Management 9.2.5.1 Formål Formålet med Deployment Management er at: • Sørge for at der er værktøjer til rådighed, således der er fuld funktionsadskillelse mellem test og produktion. • I samarbejde med 3. parts eksisterende leverandører sikre at produktionsiværksættelse sker på betryggende måde. • Sikre ændringer implementeres i henhold til indgåede aftaler. • Koordinere med såvel interne som eksterne ressourcer og sikre, at de nødvendige kompetencer er til stede. • Sikre, at iværksættelser tilrettelægges, således at de kan ske indenfor aftalt tid og med minimal afbrydelse af eksisterende service. • 9.2.5.2 Indgå i opfølgning med de ansvarlige for den praktiske gennemførsel. Væsentligste triggere og input • Change til gennemførsel. • Nye applikations komponenter. • Ændringer til servicemål. • Nye procedurer og/eller revisionsmæssige krav. • Change og Release kalender. • Oversigt over deploy til eksisterende leverandør og egne ressourcer. • Godkende Changes til implementering. Bilag 2 Situationsbeskrivelse Side 39 af 42 • 9.2.5.3 Udføres ad hoc på request fra Change Management. Væsentligste output • Status på gennemførte deploys / iværksættelser. • Rettelser til CMDB / Configuration Management. 9.2.6 Validation & Control 9.2.6.1 Formål Formålet med Validation & Control er: • At sikre driftsopfølgning indenfor Service Transition overfor eksisterende leverandører. • At levere overblik og bistand i forbindelse med udvikling og rettelser på ATP’s kørselsmønstre mv. • At indgå i arbejdet omkring kørselsflows med særlig awareness og kritiske kørselsflows. • På baggrund af ”Daglig rapport for kritiske flows” at der foretages månedsvis opfølgning. 9.2.6.2 • IT servicemål status – kørselsafvikling. • At der foretages udredninger af Incidents (på anmodning). Kategorisering af batchkørsler Batchkørsler i ATP er kategoriseret som følger: 9.2.6.3 • Kategori A – Incidents håndteres som Major Incident prioritet 1 eller 2. • Kategori B – Incidents håndteres som Major Incident prioritet 2. • Kategori C og D - incidents håndteres som Major incident prioritet 3. Rapportering på batchjobs. • Eksisterende leverandører udarbejder daglig rapport med seneste døgns afvikling på medarbejderportal opdateres kl. 09.00 samt løbende over dagen. • ATP rapporterer via IT Dashboard og servicemål-månedsrapport. Bilag 2 Situationsbeskrivelse Side 40 af 42 10 IT Service Management system 10.1 Intro til ITSM ITSM dækker området IT Service Management. For ATP er det vigtigt, at have et samlet overblik over komponenter, fejl og ændringer i det kørende miljø. Dette gælder både på applikationsniveau samt på teknisk- og infrastrukturkomponentniveau. ATP anvender et fælles IT Service Management system, produktet POB, til understøttelse af flere af driftsprocesserne. Dette system beskrives i det følgende. ATP benytter tilrettede ITIL processer og begreber, som understøttes POB. De processer der foreløbig er implementeret er følgende: • Incident Management. • Change Management. • Configuration Management. • Problem Management. Situation Management træder i kraft, når en Incident er alvorlig nok. 10.2 Funktionalitet som produktet tilbyder POB benyttes til at registrere alle IT-relevante hændelser, samt drive det workflow, der er blevet sat op til opfølgning samt løsning af disse hændelser. Der laves udtræk fra systemet, der benyttes til opfølgning og servicemål-målinger på processerne. Det er muligt, at oprette, vedligeholde og lukke en Incident. Det er muligt, at oprette, vedligeholde og markere en Change for gennemført, med forskellige udfald. Det er muligt, at oprette, vedligeholde og udgå hardware komponenter, herunder at sætte dem ”out of service”. Det er muligt at læse en Problem sag. Oprettelse, vedligehold og lukning varetages altid af ATP’s Problem managers. Herudover tilbyder POB yderligere funktionalitet, som ikke er taget i brug på nuværende tidspunkt, men som ATP overvejer at anvende i fremtidige scenarier. Bilag 2 Situationsbeskrivelse Side 41 af 42 10.3 Eksterne snitflader Det er muligt, at integrere med POB ved hjælp af WebServices, der kaldes med SOAP over HTTP. Der er på nuværende tidspunkt ikke taget stilling til sikring af linjen, men der er basic authentication, som specificeret af W3C. Det er ikke muligt, at lave en session, så hvert request skal have en authentication header. POB har mulighed for masseopdateringer, hvor der benyttes FTP, dette kan f.eks. benyttes når configuration items skal oprettes og vedligeholdes. ATP stiller relevante WSDL til rådighed. ATP stiller testmiljø til rådighed, når integrationerne skal udvikles og vedligeholdes. 10.4 Kapacitet Systemet tilbydes på 24/7 basis, dvs. hele døgnet alle ugens dage. Flertallet af masseopdateringer skal afvikles uden for normal kontortid, da disse opdateringer er ressourcekrævende. Der er vagt på systemet indenfor normal kontortid. Bilag 2 Situationsbeskrivelse Side 42 af 42
© Copyright 2024