Bilag 2 Situationsbeskrivelse

Transkript

1 Bilag 2 Situationsbeskrivelse Version

2 Indhold 1 VEJLEDNING TIL TILBUDSGIVER INDLEDNING BILAGETS FORMÅL OG OPBYGNING UNDERBILAG INTRODUKTION TIL ATP KONCERNEN ATP S OPGAVER ORGANISATION ATP S DIGITALISERINGSSTRATEGI INTRODUKTION TIL UDBETALING DANMARK FORMÅL LOVGIVNING ENSARTET SAGSBEHANDLING KONTROL MED YDELSER ATP DRIVER MYNDIGHEDEN YDELSESOMRÅDERNE SELVBETJENING FOR BORGERE PÅ BORGER.DK UDBETALING DANMARKS CENTRE ORGANISATION INTRODUKTION TIL YDELSESOMRÅDET BOLIGSTØTTE INDLEDNING YDELSESOMRÅDETS LOVE HVAD ER BOLIGSTØTTE? Bilag 2 Situationsbeskrivelse Side 1 af 42

3 5.3.1 SÆRLIGE FORHOLD FOR BOLIGSTØTTE - HUSLEJEREGISTER OG BOLIGORGANISATIONER HVEM KAN MODTAGE BOLIGSTØTTE, OG HVILKE KRAV STILLES DER? FAKTA OM BOLIGSTØTTE DEN EKSISTERENDE FORRETNINGSLØSNING KMD BOLIGSTØTTE UDFORDRINGER I DEN NUVÆRENDE LØSNING IGOE FOR BOLIGSTØTTE UDFASNING AF NUVÆRENDE LØSNING ARBEJDET MED MANUELLE OPGAVER I UDBETALING DANMARK ARBEJDSPAKKER OG OPGAVER SAGER TELEFONBETJENING PROCES FOR DRIFTSPLANSTYRING KLAGER UDBETALING OG OPKRÆVNING HELHEDSORIENTERET KONTROL (HOK) ATP S IT-MILJØ ATP S NETVÆRK ATP S PC-ARBEJDSPLADS ATP S DRIFTSPROCESSER SERVICE OPERATION ATP S SERVICEDESK INCIDENT MANAGEMENT SITUATION MANAGEMENT (MAJOR INCIDENTS) PROBLEM MANAGEMENT Bilag 2 Situationsbeskrivelse Side 2 af 42

4 9.2.5 EVENT MANAGEMENT (OVERVÅGNING) SERVICE TRANSITION RELEASE MANAGEMENT TEST RELEASE MANAGEMENT CHANGE MANAGEMENT CONFIGURATION MANAGEMENT DEPLOYMENT MANAGEMENT VALIDATION & CONTROL IT SERVICE MANAGEMENT SYSTEM INTRO TIL ITSM FUNKTIONALITET SOM PRODUKTET TILBYDER EKSTERNE SNITFLADER KAPACITET Bilag 2 Situationsbeskrivelse Side 3 af 42

5 1 Vejledning til Tilbudsgiver Bilaget skal ikke ændres af Tilbudsgiver. Tabel 1 Vejledning til Tilbudsgiver Bilag 2 Situationsbeskrivelse Side 4 af 42

6 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 Ydelsesområdet for boligstøtte Den nuværende it-løsning til administration af boligstøtte og hvordan denne udfases ATP s nuværende it-miljø ATP s IT-driftsprocesser ATP s metode til forretningsmodellering og behovsopgørelse 2.2 Underbilag Bilaget har følgende underbilag: Bilag Bilag 2A (Sådan forretningsmodellerer vi i ATP) Indhold Beskrivelse af ATP s metoder til forretningsmodellering og opgørelse af forretningsmæssige behov. Bilag 2B (Eksisterende data) Bilag 2C (ATP PC-arbejdsplads) En introduktion til de data, der skal konverteres fra den nuværende lø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. Detaljeret beskrivelse af ATP PC-arbejdsplads. Tabel 2 Underbilag til bilag 2 (Situationsbeskrivelse) Bilag 2 Situationsbeskrivelse Side 5 af 42

7 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 samt myndigheden 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. juni 2015 har ATP Koncernen ca 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

8 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, Bilag 2 Situationsbeskrivelse Side 7 af 42

9 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. Ulla Schjødt-Hansen (Konst.) Bo Foged Figur 2 Organisationsdiagram for ATP Organiseringen af ATP s administrationsforretning er vist i efterfølgende figur. Bilag 2 Situationsbeskrivelse Side 8 af 42

10 Figur 3 Organisationsdiagram for ATP s administrationsforretning 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

11 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 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 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 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 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 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 Bilag 2 Situationsbeskrivelse Side 10 af 42

12 ydelser, skal undersøges i tæt samarbejde mellem Udbetaling Danmark og kommunerne. 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 ATP driver myndigheden ATP leverer teknisk og administrativ bistand til Udbetaling Danmark og er også arbejdsgiver for medarbejderne i Udbetaling Danmark Ydelsesområderne Familieydelser, barseldagpenge, opkrævning og helhedsorienteret kontrol overgik til Udbetaling Danmark den 1. oktober 2012, og den 1. marts 2013 blev boligstøtte og pension overdraget. Fra den 1. juni 2013 har Udbetaling Danmark også overtaget ansvaret for international pension og social sikring fra Pensionsstyrelsen 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. 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 11 af 42

13 5 Introduktion til ydelsesområdet boligstøtte 5.1 Indledning Ydelsesområdet boligstøtte beskrives i det nedenstående gennem følgende overskrifter: Ydelsesområdets lovgivning Hvad er boligstøtte? Hvem kan modtage boligstøtte, og hvilke krav stilles der? Fakta om boligstøtte 5.2 Ydelsesområdets love Ydelsesområdet boligstøtte reguleres af lov om individuel boligstøtte. Lovgivningens formål er at yde hjælp til betaling af den løbende boligudgift. Derigennem sikres dårligt stillede borgere adgang til bolig og tålelig boligstandard. 5.3 Hvad er boligstøtte? Boligstøtte, som er en fælles betegnelse for boligsikring og boligydelse, er med til at sikre borgerens sociale og økonomiske grundtryghed. Boligstøtte er økonomisk tilskud til huslejen og kan søges af alle lejere. Dertil kan boligstøtte tildeles i form af lån til ejere og andelshavere, som er folkepensionister, førtidspensionister eller personer med særlige behov, jf. loven om individuel boligstøtte. Udover boligsikring og boligydelse, består boligstøtte også af beboerindskudslån. Beboerindskudslån varetages 100% af kommunerne. Boligstøtte udmåles på baggrund af en række objektivt fastlagte oplysninger omkring husstanden og boligen. I visse tilfælde vil et forvaltningsmæssigt skøn også være påkrævet. Ressortministeriet for boligstøtteområdet er Ministeriet for Børn, Ligestilling, Integration og Sociale Forhold (MBLIS) Særlige forhold for boligstøtte - Huslejeregister og boligorganisationer Huslejeregisteret er Udbetaling Danmarks primære kilde til data om almene boliger med betydning for boligstøtte. Formålet med huslejeregisteret er bl.a. at levere huslejerelateret information til brug ved myndighedsbehandling af opstart/ansøgning, beregning og senere om-beregning af boligstøtte for de omfattede boliger. Boligorganisationerne modtager også en stor del af Bilag 2 Situationsbeskrivelse Side 12 af 42

14 udbetalingerne på vegne af deres lejere. Der er tale om en frivillig ordning som boligorganisationerne skal tilmelde sig. Når boligsorganisation har tilmeldt sig denne ordning, så samler Udbetaling Danmark udbetalingerne til én udbetaling og udbetaler dem til organisationens Nemkonto. 5.4 Hvem kan modtage boligstøtte, og hvilke krav stilles der? For at være berettiget til boligstøtte, skal ansøgeren: Have fast ophold i boligen Der skal være tale om helårsbeboelse Boligen skal have eget køkken med indlagt vand og forsvarligt afløb for spildevand. Boligsikring ydes som udgangspunkt kun til lejere, der ikke er pensionister, men kan også ydes til førtidspensionister, som har fået tilkendt førtidspension efter 1. januar Førtidspensionister, som enten er ejere eller andelshavere, kan modtage boligsikring i form af lån. Stærk bevægelseshæmmede og døgnhjælp modtagere kan også modtage boligsikring i form af lån. Boligydelse ydes til folkepensionister samt førtidspensionister, der har fået tilkendt førtidspension efter regler gældende indtil den 1. januar Såfremt der bor flere personer i en hustand, kan boligydelse tildeles, hvis blot én af husstandsmedlemmer er pensionist og berettiget. Boligydelse kan også tildeles i form af lån til ejere og andelshavere, der modtager dansk folkepension, førtidspension eller pension efter EF-forordninger. Borgere som bor i et kollektiv bofællesskab, og deles om en bolig med fælles køkken, kan også søge boligstøtte. Boligstøtte til deltagere i et bofællesskab kan ydes til beboere i tre typer bofællesskaber: Kollektive bofællesskaber etableret i støttet byggeri efter udgangen af 1997 Særlige bofællesskaber for personer, der har et socialt betinget behov for at bo i kollektivt bofællesskab, og som anvises bolig i et sådant af kommunalbestyrelsen, regionen, en almen boligorganisation eller en privat organisation. 55+ bofællesskaber for personer, der er fyldt 55 år. 5.5 Fakta om boligstøtte Tabellen nedenfor viser mængder og omfang af hændelser relateret til administrationen af boligstøtte. Tallene er løst anslået og baseret på ATP s Bilag 2 Situationsbeskrivelse Side 13 af 42

15 foreløbige kendskab til sagsmængder indenfor boligstøtteområdet, og mængderne vil kunne variere over tid: Hændelser Cirka antal årligt 2015 Blanketansøgninger om boligstøtte* Digitale ansøgninger om boligstøtte Antal opkald* Info advisering og erindringsadviser Boligforeningsadviser Til- og fraflytninger Tabel 3 Mængder og omfang af hændelser relateret til administrationen af boligstøtte. *) Forventes at være faldende hen over tid pga. øget selvbetjening. Tabellen nedenfor angiver fakta omkring administrationen af boligstøtte: Fakta omkring administrationen af boligstøtte Antal Modtagere af boligsikring Modtagere af boligydelse Antal lånesager (andelshavere) Antal lånesager (ejere) 750 Udbetalt årligt boligsikring 4,5 mia. kr. Udbetalt årligt boligydelse 9,5 mia. kr. Udbetalinger til boligorganisationerne Modregning i huslejeopkrævning 52 % Antal Udbetaling Danmark centre 5 Antal brugere eksl. støttefunktioner Antal brugere inkl. støttefunktioner Tabel 4 Fakta om administrationen af boligstøtte Nedenfor i tabellen er angivet webstatistik for den eksterne brugergrænseflade for en afgrænset periode (Q1 2015). Tallene viser en høj anvendelsesgrad både på informationssider og i selvbetjeningsløsning. Forekomst Gennemsnit pr. måned Periode Besøg på siderne om boligstøtte på besøg Q Borger.dk Besøg i selvbetjeningsløsningen Din besøg (siteimprove*) Q Boligstøtte Besøg i Beregn din boligstøtte besøg (siteimprove*)** Q Bilag 2 Situationsbeskrivelse Side 14 af 42

16 Forekomst Gennemsnit pr. måned Periode Procentdel af alle besøgende på hele 23,9 % Q borger.dk som tilgår fra mobil og tablet Tabel 5 Webstatistik for selvbetjeningsløsningen (periode Q1) * Definitionen af et besøg (trukket fra statistikværktøjet Siteimprove) er: Et besøg defineres ved en række sideforespørgsler fra den samme, unikke defineret besøgende med et tidsinterval på højst 30 minutter mellem hver. ** Tallet er præget af at løsningen har været iframet ind på andre sider. Bilag 2 Situationsbeskrivelse Side 15 af 42

17 6 Den eksisterende forretningsløsning 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.1 KMD Boligstøtte Den eksisterende forretningsløsning bygger på KMD Boligstøtte (Boligstøttesystemet) og en række tilknyttede moduler. Modulerne er placeret udenfor Boligstøttesystemet og tilgås via en særskilt brugergrænseflade. Dertil indgår en række KMD støttesystemer som supplement til den eksisterende boligstøtteløsning, der understøtter en række processer. Disse støttesystemer anvendes ikke kun til administrationen af boligstøtte, men også til administrationen af de øvrige ydelsesområder, som Udbetaling Danmark administrerer; pension, familieydelser og barselsdagpenge. Fagsystemet håndterer overordnet set modtagelse og behandling af indberetninger fra borgere, myndigheder og offentlige registre, mens støttesystemerne håndterer processer som dokumenthåndtering, udbetaling, opkrævning, dannelse af breve m.v. 6.2 Udfordringer i den nuværende løsning Den Eksisterende Løsning har en række udfordringer, som ATP ønsker løst i forbindelse med implementering af en ny systemunderstøttelse: Den Eksisterende Løsning er ikke designet til Udbetaling Danmarks masseadministration af sager. Eksisterende Løsning er designet med udgangspunkt i papirbaserede arbejdsgange frem for digitalisering, hvilket forårsager unødige manuelle arbejdsgange. Eksisterende Løsning er opbygget således, at en sag færdigbehandles i en samlet forretningsgang dette harmonerer ikke med at ATP s tilgang til arbejdsopgaver (se Afsnit 7). Eksisterende Løsning er opbygget således, at fejludbetalinger eller udbetalte aconto beløb ikke kan håndteres smidigt. Disse skal håndholdes i parallelle processer, understøttet af andre systemer. Processen for udveksling af informationer med boligorganisationerne er tung og manuel og skal udbedres. Bilag 2 Situationsbeskrivelse Side 16 af 42

18 Eksisterende Løsning er ikke konfigurebar det er således meget omkostningsfyldt for ATP at fortage en række procesoptimeringer eller andre ændringer i form af brevindhold mv. Selvbetjeningsløsningen understøtter ikke til fulde borgernes behov. Udfordringerne er især forbundet med ansøgningsprocessen, men også andre ændringsprocesser. Samspillet mellem opkrævning og det nuværende Boligstøttesystem er uhensigtsmæssigt. Den nuværende løsning med integration mellem KMD Boligstøtte og KMD Sag har også udfordringer: Integrationen mellem KMD Boligstøtte og KMD sag er opbygget således, at når en sag oprettes i KMD Boligstøtte, oprettes der automatisk en sag i KMD sag, men løsningen kan ikke håndtere, at sagen også automatisk afsluttes i KMD Boligstøtte, når den afsluttes i KMD Sag. Der er ingen automatisk måde hvorpå man kan fastslå, hvilken sag et dokument skal tilknyttes, når der findes mere end en aktiv sag på en person. Det er vanskeligt at adskille aktive sager, da disse ikke er periodiseret i KMD Sag. Dvs. man kun kan se hvilken sag der er nyest, men ikke hvilken periode den omfatter. 6.3 IGOE for Boligstøtte Der er udarbejdet en IGOE, 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 O (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 17 af 42

19 Figur 4 IGOE for To-Be Boligstøtte 6.4 Udfasning af nuværende løsning Forud for igangsættelsen af dette udbud er der indgået en hensigtserklæring om udfasningsassistance med den eksisterende leverandør af Eksisterende Løsning. Denne aftale benævnes populært Udfasningsassistance. Aftalen om udfasningsassistance omfatter leverance af data ekstrakt, dokumentation af data mv. Bilag 2 Situationsbeskrivelse Side 18 af 42

20 7 Arbejdet med manuelle opgaver i Udbetaling Danmark I dette punkt 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. Bilag 3A.7 (Brugergrænseflader), der indeholder inspirationsgivende wireframes på brugergrænsefladerne. 7.1 Arbejdspakker og opgaver En arbejdspakke er en samling af ensartede opgaver, som bruges til at styre driften af opgaverne. En opgave er typisk en advisering genereret af fagsystemet eller et dokument (fysisk eller digitalt), som er indscannet af Posthåndteringsleverandøren. En arbejdspakke kan derfor bestå af fx ansøgninger om boligydelse, en anden arbejdspakke kan omhandle boligoplysninger, mens en tredje arbejdspakke kan indeholde advisering om flytninger. Opgaverne i den enkelte arbejdspakke løses manuelt af kunderådgiverne. Når en opgave åbnes, fremkommer metadata på opgaven, typisk i form af et dokument eller tekst (ved en advisering). Herefter foretager kunderådgiver den påkrævede sagshåndtering. 7.2 Sager Sagshåndteringen foregår fra sagen i fagsystemet. Kunderådgiveren kan enten tilgå sagen gennem en opgave fra en arbejdspakke eller fra et tværgående overblik i systemet. Det tværgående overblik giver kunderådgiveren mulighed for, at se hvilke sager samt udbetalinger m.v., som er tilknyttet til et bestemt CPR nr. på tværs af ydelsesområderne. På sagen ligger journalnotater og dokumenter, og det er vist, hvilke referencer sagen har til andre sager. Herudover indeholder sagen alle relevante oplysninger, for at kunderådgiveren kan danne sig et overblik over sagen. Kunderådgiveren har endvidere mulighed for at ændre i redigerbare data. Bilag 2 Situationsbeskrivelse Side 19 af 42

21 I forbindelse med afsendelse af beskeder til en myndighed eller borger har kunderådgiveren mulighed for at fremfinde relevante beskedskabeloner. Beskedskabelonerne er koblet til et KL Emnesystematik 1 (KLE nummer), hvilket betyder at det KLE nummer en sag er født med, har et vist antal beskedskabeloner til rådighed. Når en beskedskabelon hentes frem fra en sag, flettes eventuelle data fra Systemet ind i skabelonen afhængig af opsætningen. Hvis en kunderådgiver har ændringer til en allerede journaliseret besked, genereres et nyt versionsnummer af beskeden. Det er kun den besked med det nyeste versionsnummer, som kan ses af kunderådgiveren i brugergrænsefladen til Systemet. De andre beskeder med tidligere versionsnumre, er dog stadig tilgængelige for kunderådgiveren i Systemet. 7.3 Telefonbetjening Kunderådgivere modtager opkald om mange forskellige ting i relation til en boligstøttesag. Når en kunderådgiver taler med en borger i telefonen fx ved spørgsmål, fremsøges relevante opgaver for sagen, som evt. kan færdiggøres samtidig med, at man har sagen åben. Udover Systemet har kunderådgiverne en Vidensløsning med instrukser og hjælpeartikler til rådighed. Vidensløsningen bruges i de tilfælde, hvor der er tale om ikke sagsrelaterede spørgsmål informationshenvendelser. Telefoner fordeles jævnt udover de 5 centre via et centralt telefonsystem. Telefonerne håndteres i en selvstændig desktop uden integration til Systemet. 7.4 Proces for driftsplanstyring Forretningsdriften i Udbetaling Danmark afrapporteres til bestyrelsen og skal leve op til bestemte servicemål, som udvalgte arbejdspakker skal overholde. For at udnytte ressourcerne bedst muligt koordineres dette fra centralt hold via produktionsplanen. Produktionsplanen er fundamentet i Udbetaling Danmarks driftsstyring. Den er IKKE understøttet i Systemet, men foregår via et centralt driftsstyringsværktøj. 1 KL Emnesystematik er en lovbaseret kommunal taksonomi (journaliseringsnøgle), der bruges til at registrere de kommunale opgaver (emner) og forvaltningshandlingen ift. opgaven (handlingsfacetterne) på den enkelte sag Bilag 2 Situationsbeskrivelse Side 20 af 42

22 Produktionsplanen laves uge for uge, og der følges dagligt op på produktionen så det sikres, at servicemål overholdes. Planen indeholder en samlet oversigt over alle arbejdsopgaver som f.eks. sager, telefoner og specialopgaver. En driftsleder har ansvaret for at fordele opgaverne i den enkelte sektion, samt følge op på daglig basis. 7.5 Klager Klager modtages digitalt (langt de fleste), pr. post eller telefonisk. De ender i en arbejdspakke, hvorfra klagegruppen behandler dem. I 2014 er der tilkommet ca klagesager på boligstøtteområdet. Klagegruppen visiterer klagerne og registrerer dem i databasen ATP-BI, som benyttes til orientering af Udbetaling Danmarks bestyrelse, men også i forbindelse med at videreudvikle og evaluere på Udbetaling Danmarks praksis. Klagerne behandles, og borgeren meddeles enten medhold i klagen, delvis medhold eller får at vide at Udbetaling Danmark fastholder afgørelsen. Alle sager, hvor Udbetaling Danmark fastholder afgørelsen, sendes direkte til Ankestyrelsen, der er øverste myndighed og træffer den endelige afgørelse. 7.6 Udbetaling og opkrævning Boligstøtte udbetales månedligt. Dette sker automatisk i systemet. Det kan være nødvendigt at foretage ad-hoc udbetalinger til borgere fra dag til dag. Oftest skyldes det sagsændringer eller sagskorrektioner tilbage i tid, som gør, at borgeren mangler at modtage penge for en tidligere periode. Ved korrektioner eller ændringer i sagerne kan der også opstå krav til borgeren. Når et krav er identificeret i systemet, sendes det automatisk til Opkrævningssystemet, hvorfra det afgøres, hvordan kravet skal betales. Kravet kan betales direkte af borgeren, men kan også betales gennem modregning i kommende boligstøtteudbetaling, såfremt der er tale om en igangværende sag. Hvis der indgås en aftale mellem borger og Udbetaling Danmark om modregning i kommende boligstøtteudbetalinger, vil Opkrævningssystemet sende samtlige debitorposter til Boligstøttesystemet, der herefter udfører modregningerne. Denne proces foretages automatisk i Boligstøttesystemet. Bilag 2 Situationsbeskrivelse Side 21 af 42

23 7.7 Helhedsorienteret Kontrol (HOK) Hvis en kunderådgiver undrer sig i en sag, og den indikerer, at der kan være tale om snyd med sociale ydelser (fx en undring i forhold til samliv, udlandsophold mv.), udfylder kunderådgiverne et skema over undringen. HOK ambassadørerne på fagsporet screener sagerne og videresender dem til HOK afdelingen, hvis det er nødvendigt. Hvis kunderådgiveren kan se, at der er en sag i HOK i det tværgående overblik, skal kunderådgiveren kontakte HOK, inden de behandler sagen. Bilag 2 Situationsbeskrivelse Side 22 af 42

24 8 ATP s it-miljø I dette punkt 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å Data- LAN 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 5 ATP s netværksinfrastruktur. Bilag 2 Situationsbeskrivelse Side 23 af 42

25 8.2 ATP s PC-arbejdsplads En detaljeret beskrivelse af ATP s PC-arbejdsplads findes i bilag 2C (ATP PCarbejdsplads). Bilag 2 Situationsbeskrivelse Side 24 af 42

26 9 ATP s driftsprocesser Dette punkt 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 Integration Det primære formål med ATP s Service Integration er at støtte etableringen og implementeringen af nye driftssamarbejder, samt løbende tage ansvar for opfølgning på daglig drift med ATP s leverandører. Figur 5 ATP s Service Integration Service Integration tilsikrer en ensartet og succesfuldt IT leverance i et multileverandør set-up, samt sikrer at leverancen lever op til aftalt pris og kvalitet. Service Integration er organisatorisk forankret under IT Service Management og fungerer som SPOC for leverandørens Service Delivery-ansvarlige. Service Integration har følgende ansvarsområder: Bilag 2 Situationsbeskrivelse Side 25 af 42

27 Sikre stabil drift, herunder ansvarlig for end-to-end SLA opfyldelse. Tæt dialog med forretningen med hensyn til kundeoplevelsen. Styring af Leverandør ydelser, ved at sikre, at de aftalte ydelser tilvejebringes og sikre den nødvendige opfølgning og eskalering. Indgå i relevante fora sammen med forretningen. Ansvarlig for den løbende governance mellem leverandør og ATP. (IT og forretning). Opbygge og vedligeholde relationer med/mod leverandør i tæt samarbejde med relevante interne parter. Varetage driftsmæssig Vendor Management i forhold til 3. parts leverandører. Primært dagligt bindeled mellem forretning og leverandør i forhold til drift og ansvarlig for kundetilfredshed (forretningen) Ansvarlig for de krav til drift, som er stillet i udbud. Sikre, at der løbende sker opfølgning på opfyldelse af kravene. Kravmateriale holdes opdateret og løbende justeres med henblik på udbudsmateriale. Sikrer opgørelser og rapportering i forhold til kontrakt økonomien. Bidrager til at sikre balancen mellem de økonomiske mål og effektmål via driftsstabilitet. Sikre samspil mellem leverandør og IT Service Management, herunder etablere og drive egne processer og identificere og initiere ændringer til eksisterende processer Sikre opfølgning og fremdrift på eskalationssager, når disse ikke kan løses gennem normale processer og i den aftalte governance. I etablerings- og implementeringsfaserne indgår Service Integration som en væsentlig aktør ved: kontrol af leverandørens besvarelse af krav vedrørende ydelser, krav og servicemål etablering og implementering af Servicen og governance modellen mod leverandøren udarbejdelse af driftsaftalehåndbog mellem ATP og leverandør, samt etablering af tværgående driftsprocesser med øvrige leverandører etablering af egne IT processer til en driftssituation etablering af SLA målinger etablering af værktøjsintegration (fx ITSM tools), samt tilsikre overdragelse fra projekt til drift Bilag 2 Situationsbeskrivelse Side 26 af 42

28 9.2 Service Operation 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 hurtig og effektiv 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 ITsystemerne. Bilag 2 Situationsbeskrivelse Side 27 af 42

29 Borgere ATP s driftsstatus Spørgsmål vedr. applikationer / proceser Fagcoach superbruger Kundeservice medarbejdere ATP ServiceDesk Leverandør X s driftsstatus Leverandør A Leverandør B Leverandør C Leverandør Y Leverandør Z Leverandør W M.m.m. ATP IT-tekniker / Udbetaling IT-specialist Danmark organisation Tekniker / specialist Tekniker / specialist Tekniker / specialist Tekniker / specialist Tekniker / specialist Tekniker / specialist Figur 6 ATP Servicedesk Nedenstående processer anvendes i ATP s IT service operation: Figur 7 Processer i ATP's IT service operation 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

30 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? High Medium Low Urgency High Medium Low Tabel 5 Prioritetsmatrix. Kriterier for Incidents Reaktion stid Løsningstid Nedbrud på forretningskritisk Der arbejdes indtil Prioritet 1 system. < 15 min. løsning/ work-around er Kritisk Alle brugere i samme funktion 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

31 Prioritet 2 Haster Prioritet 3 Normal Prioritet 4 Kriterier for Incidents Forøgede svartider, som belaster forretningskritiske systemer. Flere brugere i samme funktion er forhindret i at udføre deres arbejde. Overvågningssystemer viser generelle fejl / lang svartid, som berører brugerne. Arbejde afbrudt, men der findes alternativ løsning (work-around). Problemet vedrører én eller flere 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. Incident er omgået med workaround og skal løses, men det haster ikke. Brugeren har Problemer med sin ITarbejdsplads / applikation, som påvirker arbejdet, men det kan accepteres midlertidigt. Reaktion Løsningstid stid Der arbejdes indenfor < 60 min. arbejdstid indtil løsning/ work-around er fundet. < 8 timer. 2 dage. Efter Efter aftale. aftale. Tabel 6 Kriterier for Incidents 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

32 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 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: 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

33 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. Oneviewsystemet 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.3 Service Transition Release Management 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 Releasevinduer Type Mindre løft Beskrivelse 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 Bilag 2 Situationsbeskrivelse Side 32 af 42

34 Type Beskrivelse udvikling. Efter løft skal eksisterende leverandører selv foretage teknisk verifikation. Ved fejl skal en kendt fall-back iværksættes. Systemerne skal være fuldt funktionsdygtigt efter et mindre løft. Releases 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 Test Release Management 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

35 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.) 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 Change Management 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

36 Figur 8 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). o Releaseoversigt og Change statistik. Bilag 2 Situationsbeskrivelse Side 35 af 42

37 o Eksisterende leverandøraftaler Change typer ATP anvender følgende kategorisering af Changes: Change type Emergency Change Normal Change Standard Change (Preautoriseret Change) Beskrivelse 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 definition Change der kan planlægges og implementeres jf. aftalt forløb. Ny funktionalitet såvel som fejlrettelser. I forbindelse med Change Management kan det tillades at gennemfø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 Servicevinduer De planlagte servicevinduer i produktionsmiljøerne ligger typisk uden for servicemål-perioden, det vil sige i perioden ATP har opdelt servicevinduerne efter følgende kategorier: Infrastruktur Change (dagligt omtalt som tekniske servicevinduer). Bilag 2 Situationsbeskrivelse Side 36 af 42

38 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. Aftalte servicevinduer er ikke omfattet i servicemål-målingerne. Nedenfor vises en oversigt over nuværende servicevinduer i ATP. Bilag 2 Situationsbeskrivelse Side 37 af 42

39 Figur 9 Oversigt over servicevinduer i ATP. Bilag 2 Situationsbeskrivelse Side 38 af 42

40 9.3.4 Configuration Management 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 Deployment Management 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. 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

41 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 Validation & Control 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. 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: 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 Rapportering på batchjobs. Eksisterende leverandører udarbejder daglig rapport med seneste døgns afvikling på medarbejderportal opdateres kl samt løbende over dagen. ATP rapporterer via IT Dashboard og servicemål-månedsrapport. Bilag 2 Situationsbeskrivelse Side 40 af 42

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 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 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 Bilag 2 Situationsbeskrivelse Side 41 af 42