1. No category

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