BESKRIVELSE AF FORSLAG TIL REVIDERET DRIFTSLEVERANDØRSTRATEGI TIL HØRING

BESKRIVELSE AF FORSLAG TIL REVIDERET DRIFTSLEVERANDØRSTRATEGI TIL HØRING

Indholdsfortegnelse: 1 Ledelsesresume... 3 2 Formål og introduktion... 5 3 Valg mellem de fire driftsmodeller og implementeringsstrategi...8 4 Overordnet beskrivelse af forslag til revideret driftsstrategi... 10 5 Applikationsleverandørernes ansvar og opgaver...11 6 Infrastrukturdriftsleverandørens overordnede opgaver og ansvar... 14 7 Samarbejdsmodellen... 19 8 Implementeringsstrategi... 22 FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 2

1 Ledelsesresume Driftstrategien for de fælleskommunale it-systemer er, at leverandørerne af de enkelte løsninger i de første år selv gennemfører udviklingen og derefter varetager den fulde drift, dvs. både applikationsvedligeholdelsen, -driften og infrastrukturdriften i det af leverandøren valgte driftssetup. Såfremt dette setup fortsætter uændret på længere sigt, vil det medføre en række uhensigtsmæssigheder for driften af og sammenhængen i den samlede fælleskommunale systemportefølje, idet man fælleskommunalt med den nuværende strategi vil få mange mindre driftsleverandører at forholde sig til. Hver af disse driftsleverandører har sit eget setup, hvilket komplicerer KOMBIT s samlede forvaltning på kommunernes vegne, idet KOMBIT således får en uforholdsmæssig stor opgave med at binde enderne samme for at levere en stabil service til kommunerne. Driftstrategien indebærer derfor, at driften for en række fælleskommunale systemer bør samles, når driften er stabiliseret efter de første års videreudvikling af it-systemet, afhængig af systemernes karakteristika. Bl.a. er det besluttet, at driften af serviceplatformen, støttesystemerne i rammearkitekturen, og SAPA med tiden skal samles hos én samlet driftleverandør. Dette letter SAPAs omfattende træk på støttesystemer mv., og det letter den samlede adgang til disse infrastrukturer. Leverandørens opgaver i driftfasen foreslås opdelt i tre lag dækkende henholdsvis applikationsvedligehold, der er videreudvikling af ny funktionalitet, applikationsdrift, der indeholder den samlede levering af driftservice til kommunerne, samt infrastrukturdrift, der er den rå drift af servere, netværk mv. Ved denne opdeling vil der fælleskommunalt blive fire modeller for applikationsvedligehold, -drift og infrastrukturdrift og får mulighed for mere frit at kunne vælge og under vejs også skifte mellem disse modeller. Dette betyder, at flytning af drift til en fælles driftleverandør kan foregå i etaper, hvor man først flytter hardware/os, derefter driftsupport, og eventuelt for simple it-systemer også vedligeholdelsen. Valget af model vil afhænge af, hvad der giver bedst mening for det enkelte system (applikation inkl. infrastruktur) og i forhold til den samlede fælleskommunale driftsportefølje. Der kan således vælges Model 1 for nogle systemer og Model 2, 3 og/eller 4 for andre systemer alt afhængig af disses karakter (kompleksitet, modenhed, afhængigheder til andre systemer mv.). De fire modeller er illustreret på nedenstående figur. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 3

Model 1 er den nuværende praksis med hele systemet (og al ansvaret) placeret hos en leverandør. Store, komplekse og/eller selvstændige systemer vælges til start i Model 1 og kan så over tid evt. overgå til Model 2 og evt. også videre til Model 3, hvorimod Model 4 næppe bliver aktuel for de største og mest komplekse systemer. Model 2 samler infrastrukturen hos en driftsleverandør mens al drift og vedligehold vedr. applikationen forbliver hos applikationsleverandøren. Model 2 forventes anvendt for store dele af Rammearkitekturens infrastruktursystemer når deres drift er modnet efter nogle års videreudvikling, hvorefter dele af Rammearkitekturen gradvist kan gå over i Model 3 og de mest simple måske videre til 4. Støttesystemer mv. i rammearkitekturen er tæt koblet, hvorfor det drifts- og forvaltningsmæssigt er en fordel for KOMBIT at konsolidere leverandørsetup et. Model 3 overdrager applikationsdriften til driftsleverandøren, mens kun vedligehold forbliver hos applikationsleverandøren. Der er således en leverandør, der varetager den samlede drift, mens man i Model 3 har mulighed for at lægge vedligeholdeses- og udviklingsopgaver hos andre leverandører. Model 4 er den fulde overdragelse af systemet til driftsleverandøren. Model 4 kan være et valg på udvalgte dele af Rammearkitekturen, når denne er fuldt produktionsmodnet. Man skal dog nøje overveje omfanget af Model 4 i forhold til fremtidig konkurrenceudsættelse. Der er højst to leverandører involveret i hver af modellerne, dvs. i Model 2 er snittet mellem infrastruktur- og applikationsdriftsleverandøren, mens i Model 3 er snittet mellem applikationsdrifts- og applikationsvedligeholdelsesleverandøren. I model 1 og 4 er det som illustreret på figuren samme leverandør, der varetager alle tre opgaver i lagdelingen. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 4

KOMBIT forventer på sin egne interne forvaltnings- og driftskoordineringsopgaver for kommunerne på Rammearkitekturen at kunne reducere omkostningerne med 25%, når Model 3 nås samtidigt med at ansvarsforholdene i drift simplificeres, og det gør det lettere for KOMBIT qua renere snit at flytte opgaver vedr. støttesystemer mv. mellem leverandører. Endvidere forventes at der kan opnås en besparelse på 15% på interne forvaltnings- og driftskoordineringsopgaver for fagsystemer. Foruden de interne forenklinger samt besparelser i KOMBIT opnås også en øget konkurrenceudsættelse og dermed over tid bedre priser. Den øgede konkurrenceudsættelse opnås for det første ved at de enkelte leverandører skal forberede opdeling af deres drift i de 4 modeller, hvilket alt andet lige gør driften mere transparent for KOMBITs leverandørstyring og gør det lettere for andre leverandører at overtage et givet system. Konkurrenceudsættelsen øges også ved at få de specialiserede danske udviklingsfirmaer som mulige leverandører. Disse har i dag udfordrende konkurrencevilkår, da de ikke tilbyder end2end løsninger, dvs. også inkluderer drift i deres ydelsessortiment. Når driften i Model 2 eller 3 således er adskilt kan disse udviklingsfirmaer lettere konkurrere på videreudvikling og vedligehold. Infrastrukturpriserne har været generelt faldende i en årrække. Specielt de seneste 5 år har markedet for applikationsdrift qua øget automatisering, off-shoring, tilpasning af serviceniveauerne samt generelt lavere overskudsgrader for disse ydelser også oplevet faldende priser. Dette sammenholdt med at indgåede T&M-afregninger og ændringer i øvrigt ved genudbud bliver samlet og konverteret til ny baseline for driften, samt at man fælleskommunalt med dette forslag opnår øget fleksibilitet og mindre leverandørafhængighed på de enkelte systemer, betyder bedre reel konkurrence og dermed lavere priser. Kommunerne opnår med den reviderede driftsleverandørstrategi øget mulighed for at få synergi på tværs af de fælles systemer. Den reviderede driftsleverandørstrategi forventes integreret og implementeret i udvalgte af de kommende udbud. 2 Formål og introduktion Formålet med dette dokument er overordnet at beskrive et forslag til en revideret driftsleverandørstrategi med henblik på derefter at indsamle høringssvar fra interessenter. Når inputtet fra disse er modtaget bruges dette til evt. at revidere driftsleverandørstrategien. Dernæst vil den reviderede driftsleverandørstrategi integreres og implementeres i udvalgte af de kommende udbud. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 5

KOMBIT s nuværende praksis er, at leverandørerne af de enkelte løsninger selv gennemfører udviklingen og derefter varetager den fulde drift, dvs. både applikationsvedligeholdelsen, -driften og infrastrukturdriften i det af leverandøren valgte driftssetup. Dette kan samlet set på længere sigt medføre en række uhensigtsmæssigheder for driften af den fælleskommunale systemportefølje, idet KOMBIT med den nuværende strategi vil få mange mindre driftsleverandører at forholde sig til. Hver af disse driftsleverandører har sit eget setup, hvilket komplicerer KOMBIT s samlede forvaltning på kommunernes vegne, da KOMBIT således får en uforholdsmæssig stor opgave med at binde enderne samme. Dette dokument bruger terminologimæssigt således betegnelsen infrastrukturdriftsleverandør for den leverandør, som på et tidspunkt efter et udbud forventes valgt og som derefter varetager opbygningen, driften og tilpasningen af en mere samlede infrastruktur, dette dog med undtagelse af de decentrale infrastrukturkomponenter (eks. netværk og PC er/laptops), som fortsat håndteres af de enkelte kommuner. Tilsvarende bruges samlet betegnelsen applikationsleverandør for den eller de leverandører, som efter et udbud vælges til at videreudvikle/vedligeholde hhv. supportere applikationerne. Delingen mellem hhv. videreudvikling/vedligeholdelse, applikationsdrift/support og infrastrukturdrift er beskrevet i særskilt dokument om 3-lagsmodellen. Den reviderede strategi foreslår således at samle dele af den fælleskommunale infrastrukturdrift i et mere konsolideret set-up, hvor udvalgte applikationer afvikles og driftes. Der vil naturligvis blive stillet krav til infrastrukturdriftsleverandøren om at understøtte en bred vifte af platforme og forskellige SLA er, og til på en smidig måde at støtte projekterne og applikationsvedligehold. Omvendt stilles der som følge af den revidere driftsstrategi også en række krav til applikationsleverandørerne, som beskrives i de følgende afsnit. Forslaget til den nye driftsstrategi er fleksibel og giver mulighed for frit at vælge og under vejs at skifte mellem de fire modeller for applikationsvedligehold, -drift og infrastrukturdrift. Dette valg afhænger af, hvad der giver bedst mening for det enkelte system (applikation inkl. infrastruktur) og i forhold til den fælleskommunale driftsportefølje. Man kan således vælge Model 1 for nogle systemer og Model 2, 3 og/eller 4 for andre systemer alt afhængig af disses karakter (kompleksitet, modenhed, afhængigheder til andre systemer mv.). FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 6

De fire modeller er illustreret på nedenstående figur. Model 1 er KOMBIT s nuværende praksis med hele systemet (og al ansvaret) placeret hos en leverandør. Nogle systemer vil altid skulle driftes sådan. Model 2 samler infrastrukturen hos infrastrukturdriftsleverandøren mens al drift og vedligehold vedr. applikationen forbliver hos applikationsleverandøren. Model 3 overdrager applikationsdriften til infrastrukturdriftsleverandøren, mens kun vedligehold forbliver hos applikationsleverandøren. Model 4 er den fulde overdragelse af systemet til infrastrukturdriftsleverandøren. Baggrunden for ovenstående driftsstrategi er et ønske om forenkling af ansvarsforholdene og opgaverne på tværs af systemerne og af integrationerne (performance, sikkerhed, driftseffektivitet) samt forventningen om fremtidige stordriftsfordele. KOMBITs leverandørstyring får således med Model 2, 3 og 4 et renere standardiseret snit mellem enten applikationsvedligehold, drift eller infrastrukturdrift med tilhørende formelle procedurer for idriftssættelse, opgraderinger, overvågning mv. med indbyggede kvalitetssikringsaktiviteter. Den reviderede strategi medfører, at driftsleverandøren i Model 3 og 4 også tager end-toend ansvar for applikationsdriften for at undgå mange applikationsleverandører med driftsansvar for komplicerede integrationer/afhængigheder i forvaltningen, hvilket også er fordyrende internt for KOMBIT, og dermed for kommunerne. Før infrastrukturdriftsleverandøren kan tage driftsansvaret for applikationerne, kræves det at disse er driftsstabile. Der må således for visse applikationer påregnes en overgangsperiode, hvor endelig stabilisering først sker i drift. Applikationsleverandørerne vil fortsat i Model 3 forestå applikationsvedligeholdelsen og skal supportere infrastrukturdriftsleverandøren ved applikationsfejl, som kræver ændringer i koden/konfigurationen. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 7

De renere snit mellem applikationsvedligehold, drift og infrastrukturdrift gør det også lettere fremadrettet at skifte/konsolidere applikationsleverandører i Model 2, 3 og 4, hvilket specielt forventes at blive aktuelt ved genudbud (kontraktsforlængelse) af eksisterende systemer i vedligehold og drift. Når nye løsninger udbydes, vil man fortsat typisk starte i Model 1, men man har fremadrettet muligheden for også at anvende en af de andre modeller. For nuværende projekter og løsninger vil det i hvert enkelt tilfælde blive vurderet om den pågældende løsning med fordel flyttes over i en anden model eller bibeholdes i det nuværende driftsset-up (Model 1). Den efter et udbud valgte driftsleverandør vil med forslaget få en stor og central rolle for den fælleskommunale it-portefølje. Infrastrukturdriftsleverandøren forventes således med forslaget at repræsentere godt en tredjedel af de samlede månedlige forvaltningsvederlag for systemerne i Model 2 (naturligvis varierende system for system) samt op imod halvdelen for systemerne i Model 3 og 4. Infrastrukturdriftsleverandøren skal udelukkende levere veldokumenterede standardiserede ydelser med høj stabilitet på tværs af applikationerne til en konkurrencedygtig pris. Det påhviler infrastrukturdriftsleverandøren til stadighed at holde alle ydelser og softwareversioner fuldt opdateret. Driftsset-up et skal være standardiseret i en sådan grad, at flytning til anden (efter et udbud) mere konkurrencedygtig infrastrukturdriftsleverandør er en absolut gennemførbar transformation. Netop fordi udbuddet har et stort omfang på en standardiseret ydelse har KOMBIT gode forudsætninger for at opnå attraktive priser i markedet. For at forstå det samlede forslag til revideret driftsstrategi med dets implikationer m.v. må hele dokumentet ses i sammenhæng. 3 Valg mellem de fire driftsmodeller og implementeringsstrategi Valget af den driftsmodel, der er bedst egnet, afhænger som nævnt af systemets karakteristika. Store, komplekse og/eller selvstændige systemer vælges til start i Model 1 og kan så over tid evt. overgå til Model 2 og evt. også videre til Model 3, hvorimod Model 4 næppe bliver aktuel for disse systemer. Et eksempel på forventet start i Model 1 er Kommunernes Ydelsessystem (KY), som er et stort selvstændigt system i den forstand, at KY har mange brugere, der anvender dagligt som deres primære system og kun i begrænset omfang har FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 8

brug for andre fælleskommunale systemer i arbejdet. Et selvstændigt system kan også være et funktionelt isoleret system. Model 2 forventes anvendt for store dele af de infrastrukturelle systemer i rammearkitekturen efter at systemernes drift er modnet over nogle år, hvorefter dele af disse systemer gradvist vil gå over i Model 3 og måske også 4. Model 2 og senere Model 3 og 4 forventes således forberedt for SAPA, Forretningskrav, Sags- og Dokumentindeks, Klassifikation, Organisation og Beskedfordeler. Serviceplatformen har været i udbud og er også forberedt til at overgå til Model 2. Rammearkitekturen er tæt koblet, hvorfor det drifts- og forvaltningsmæssigt er en fordel for kommunerne at konsolidere leverandørsetup et. KOMBIT forventer på sin egen interne forvaltningsopgave på Rammearkitekturen at reducere omkostningerne med 25%, når Model 3 nås samtidigt med at ansvarsforholdene i drift simplificeres og det gør det lettere for KOMBIT qua renere snit at flytte opgaver vedr. infrastruktur i rammearkitekturen mellem leverandører. Foruden systemerne i rammearkitekturen vil KOMBIT også undersøge hensigtsmæssigheden for start i Model 2 på resten af Beskæftigelse og Ydelsesområdet (KY undtaget ref. ovenstående) og andre områder/systemer kan også komme i betragtning i forbindelse med genudbud. KOMBIT har pt. ingen forventninger om at starte med nye projekter/systemer direkte i Model 3 eller 4. Såfremt den nye driftsstrategi besluttes vil KOMBIT gennemføre overflytningen af de udvalgte systemer gradvist, dvs. system for system for hen ad vejen at høste erfaringer, modne setup et og mitigere uhensigtsmæssigheder, risici mv. Forudsætningen for start af udvalgte systemer i Model 2 er, at et udbud gennemføres for at vælge en driftsleverandør. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 9

4 Overordnet beskrivelse af forslag til revideret driftsstrategi Hensigten med dette kapitel er overordnet at præsentere forslaget i forhold til opgaverne for de forskellige leverandører for Model 2, 3 og 4. Opgaverne detaljeres i efterfølgende kapitler. Forlaget til den revidere driftsstrategi for Model 2 kan lettere forenklet illustreres som på nedenstående figur, hvor kun en infrastrukturdriftsleverandør er vist. Figuren illustrerer Rammearkitekturen (Serviceplatformen, SAPA m.v.) som en applikation, men det er fortsat KOMBIT s forventning, at systemerne i den samlede rammearkitektur konkurrenceudsættes i flere komponenter og derfor sandsynligvis opdeles mellem flere applikationsleverandører. For hver af applikationerne er vedligehold og drift anført på figuren. Vedligehold, brugersupport og applikationsdrift påtænkes således i Model 2 gennemført af applikationsleverandørerne. De sidste afsluttende tests inden idriftsættelse skal gennemføres på en måde så der tages højde for integrationer og funktionalitet på tværs af det samlede driftsset-up. Dette må derfor i høj grad ske i miljøer etableret hos infrastrukturdriftsleverandøren. Disse afsluttende tests er: 1. Tekniske tests af performance, stress, integrationer, sikkerhed m.v. 2. Overtagelsesprøve 3. Idriftsættelsestest 4. Driftsprøve (gennemføres i produktionsmiljøet) Applikationsleverandøren skal på tilbudstidspunktet specificere kravene til såvel miljøer til ovenstående tests som produktionsmiljøet samt kravene til gennemførelse af vedligehol- FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 10

delsen. Kravene til miljøerne skal i højest mulig grad ligge indenfor de standardydelser, som infrastrukturdriftsleverandøren stiller til rådighed i servicekataloget, der gøres transparent for applikationsleverandørerne. Applikationsleverandørerne skal således fortsat selv etablere og drive de nødvendige udviklings- og testmiljøer. Applikationsleverandørerne skal yderligere specificere og aftale etablering, adgang til og drift af miljøerne til de afsluttende tests og efterfølgende drift (produktion) inkl. vedligehold hos infrastrukturdriftsleverandøren. Applikationsleverandørerne har overfor KOMBIT hovedansvaret for applikationerne inkl. tilhørende databaser og grænsesnit i drift og er dermed i direkte dialog med driftsleverandøren om at overholde SLA er m.v. Disse ansvarsforhold uddybes i næste kapitel. Infrastrukturdriftsleverandøren skal smidigt og sikkert understøtte applikationsleverandørerne i test, idriftsættelse og produktion (drift) af de enkelte applikationer. Infrastrukturdriftsleverandørens kontraktperiode forventes at blive 5 år med optioner for yderligere 1 + 1 år, dvs. hvis infrastrukturdriftsleverandøren leverer god driftsstabilitet samt opfylder kontrakten til en fortsat konkurrencedygtig pris, kan den samlede periode i alt udgøre 7 år før ny konkurrenceudsættelse nødvendigvis gennemføres. 5 Applikationsleverandørernes ansvar og opgaver Dette kapitel beskriver applikationsleverandørernes ansvar og opgaver pr. fase, dvs. henholdsvis tilbud, projekt og vedligeholdelse. 5.1 Tilbudsfasen Ved indlevering af tilbud til KOMBIT skal applikationsleverandørerne med dette forslag specificere kravene til miljøerne herunder antal og sizing (serverkapacitet og storage m.v.), baseret på udbudsmaterialet. Applikationsleverandørerne specificerer også på tilbudstidspunktet valg af databaser og behovet for integrationer i miljøerne til de afsluttende tests (tekniske tests, overtagelsesprøven, idriftsættelsestest og driftstest) og produktion. KOMBIT anvender dette input til prisevalueringen af tilbuddet bl.a. i forhold til infrastrukturdriftsleverandørens transparente servicekatalog. Det er således applikationsleverandørernes ansvar at sikre, at de specificerede miljøer til de afsluttende tests hænger sammen med projektplanen og har tilstrækkelig sizing. Ligeledes er applikationsleverandørerne ansvarlige for sizing af produktionsmiljøet. Hvis sizing FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 11

af miljøerne i senere faser viser sig ikke at være tilstrækkelig og mere kapacitet (servere, storage mv.) skal bestilles hos infrastrukturdriftsleverandøren, så hæfter applikationsleverandørerne for denne udgift jvnf. Servicekataloget, med mindre applikationsleverandøren kan henvise til, at de i kontrakten nævnte forecasts fra KOMBIT overskrides. 5.2 Projektfasen Applikationsleverandørerne har i projektfasen hovedansvaret for at planlægge, koordinere og samarbejde med infrastrukturdriftsleverandøren, således at miljøer m.v. bliver detaljeret, dokumenteret og etableret i overensstemmelse med specifikationerne. Applikationsleverandørerne har hovedansvaret for at planlægge og gennemføre serviceintroduktionen af det nye system. Dette ansvar dækker i forhold til infrastrukturdriftsleverandøren at: 1. driftsaftaler etableres og godkendes 2. dokumentation (driftsaftalehåndbog m.v.) færdiggøres og godkendes 3. driftsset-up et med overvågning, alarmer m.v. testes og godkendes 4. udarbejdelse og godkendelser af processer og procedurer for samarbejdet mellem applikationsleverandør og driftsleverandør 5. idriftsættelse gennemføres og godkendes Applikationsleverandørerne etablerer som udgangspunkt selv udviklingsmiljøer og de første testmiljøer i eget set-up. Dette giver den fordel, at applikationsleverandørerne ikke i projektopstart er afhængig af de leveringstider, procedurer m.v., der er gældende for en infrastrukturdriftsleverandør. Applikationsleverandøren har dog mulighed for at bestille disse udviklings- og testmiljøer hos infrastrukturdriftsleverandøren, jf. servicekataloget. Denne mulighed forventes primært at være aktuel i forbindelse med bestilling af testmiljøer med integrationer til KOMBIT s øvrige systemer som applikationsleverandøren har behov for. Såfremt applikationsleverandørerne har specificeret (sized) et eller flere af miljøerne forkert, er det applikationsleverandørernes leverancemæssige og økonomiske ansvar at få dette rettet rettidigt i samarbejde med infrastrukturdriftsleverandøren. Såfremt applikationsleverandørerne konstaterer behov for ændringer i specifikationen, aftaler applikationsleverandørerne de nødvendige tiltag og udvidelser med infrastrukturdriftsleverandø- FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 12

ren, således at forsinkelser undgås. Hvis applikationsleverandørerne på tilbudstidspunktet har specificeret hvad der senere viser sig at være en overkapacitet, gælder ligeledes at applikationsleverandørerne kan få refunderet penge, jvnf. servicekatalogets vilkår herfor. Applikationsleverandørerne har ansvaret for at tilvejebringe de til applikationen tilhørende databaser og set-up, herunder som en del af kontrakten at betale licenser og support. KOMBIT vil fremadrettet stille krav om at anskaffede licenser følger systemet, dette gælder bl.a. licenser til de mest gængse kommercielle databaser (DB2, SQL-server og Oracle), middleware (Websphere, Biztalk, Oracle Weblogic Server). Dette vil sige, at kommunerne og/eller en eventuel ny applikationsleverandør efter et udbud af vedligeholdelsen ikke pålægges nye (unødige) initielle licensomkostninger. Det er således fortsat applikationsleverandørerne, som anskaffer og har det projekt- og konfigureringsmæssige ansvar for databaser inkl. DBA og middleware for de enkelte systemer. Ved Model 3 og 4 overleverer applikationsleverandørerne hen over serviceintroduktionen de standardiserede driftsprocedurer til driftsleverandøren, således at procedurer, værktøjer m.v. er klar ved idriftsættelse. Infrastrukturdriftsleverandøren varetager, når systemet er driftsstabilt, alle opgaverne i den daglige drift. 5.3 Vedligeholdelsesfasen Det er med det nye forslag til driftsstrategi fortsat applikationsleverandørerne, der (bortset fra Model 4) har hovedansvaret for at de givne systemer opfylder SLA erne i kontrakten. Infrastrukturdriftsleverandøren har i den forbindelse naturligvis ansvaret for alle opgaver herunder SLA erne for infrastrukturen. Applikationsleverandørerne skal i form af applikationsalarmer m.v. etablere den nødvendige overvågning af applikationerne. Når driftsprøven er godkendt overgår overvågningen, herunder også alarmovervågningen, og den almindelige daglige standarddrift af applikationen i Model 3 og 4 til infrastrukturdriftsleverandøren. Den almindelige applikationsdrift gennemføres således derefter af infrastrukturdriftsleverandøren, jf. applikationsleverandørens standardanvisninger. Hvis alarmer, standardanvisninger m.v. ikke er tilstrækkelige, påhviler det applikationsleverandøren at udbedre disse, ligesom opdateringer af applikationsdriftsdokumentationen er applikationsleverandørens ansvar. Applikationsleverandørerne vil af infrastrukturdriftsleverandøren få stillet overvågnings-, log- og rapporteringsværktøjer til rådighed til at foretage fejlsøgning i de pågældende systemer. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 13

Kontrakten for vedligeholdelsesfasen påregnes fortsat at være 5 år med optioner for forlængelse (1 +1 år). 6 Infrastrukturdriftsleverandørens overordnede opgaver og ansvar Hvis denne reviderede driftsstrategi besluttes, vil den efter et udbud valgte fælles driftsleverandør til KOMBIT bl.a. blive målt på sikker og stabil drift høj fleksibilitet og god support til applikationsleverandørerne og KOMBIT attraktive priser de fælleskommunale systemer I den foreslåede reviderede driftsstrategi vil snittet mellem infrastrukturdriftsleverandøren og kommunerne forblive det samme, hvilket vil sige at kommunerne fortsat forestår driften af de decentrale netværk og desktop m.v. 6.1 Krav til platforme Driftsleverandøren skal som minimum stille følgende overordnede servertyper/os til rådighed i servicekataloget: MS LINUX UNIX (enten AIX, HPUX og/eller Oracle Solaris) Infrastrukturdriftsleverandøren ejer al infrastruktur (netværk, storage samt servere). Ved overgang til ny driftsleverandør (efter udbud) etableres en ny opdateret infrastruktur. Infrastrukturdriftsleverandøren ejer ligeledes ITSM værktøjerne, der skal være åbne tilgængelige i forhold til applikationsleverandørerne og KOMBIT. Infrastrukturdriftsleverandøren skal minimum have kompetencer indenfor følgende databaser: DB2, SQL-server og Oracle, og følgende middleware: Websphere, Biztalk, Oracle Weblogic Server. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 14

Infrastrukturdriftsleverandøren må kun anvende proprietære teknologier, produkter og driftsset-up s, hvis disse kan erhverves eller licensen kan erhverves af KOMBIT på normale markedsvilkår, eller hvis disse proprietære teknologier, produkter eller driftsset-up s let kan erstattes af standardteknologier, produkter og driftsset-up s, som er gjort offentligt tilgængelige på almindelige markedsvilkår, således at skifte (transition) fra én infrastrukturdriftsleverandør til en anden (efter et nyt udbud) kan foregå problemfrit. Endvidere bør anvendelsen af proprietær teknologi og produkter ikke medføre, at KOM- BIT pålægges væsentlige omkostninger ved anvendelsen af disse teknologier og produkter. 6.2 Krav til tilgængelighed (oppetid) Infrastrukturdriftsleverandøren skal stille følgende fire niveauer af tilgængelighed til rådighed afhængig af, hvor forretningskritisk det givne system er for KOMBIT. Det er som nævnt applikationsleverandøren, der på baggrund af udbudsmaterialet afgør behovene for de forskellige miljøer. Niveau 1 Niveau 2 Niveau 3 Niveau 4 Kritiske Vigtige Administrative Ikke kritiske Anvendelse Serviceniveau 1 vælges til forretnings-kritiske systemer, f.eks. Serviceplatformen Serviceniveau 2 vælges til forretnings-vigtige systemer Serviceniveau 3 vælges typisk til administrative systemer Serviceniveau 4 vælges typisk til lavt prioriterede systemer herunder testmiljøer Driftstid Mandag-søndag 0.00-24.00 Mandag-søndag 0.00-24.00 Mandag-fredag 7.30-16.30 Mandag-fredag 7.30-16.30 Oppetid 99,95 % 99,9 % 99 % 95 % Beregning af oppetid (Aftalt driftstid planlagt nedetid ikke-planlagt nedetid) * 100 (Aftalt driftstid planlagt nedetid) FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 15

Alle større infrastrukturdriftsleverandører bruger med visse variationer disse niveauer. KOMBIT vil i et vist omfang ud fra et økonomisk perspektiv lægge op til at indrette sig ud fra driftsleverandørens eksisterende SLA rammeværk. Infrastrukturdriftsleverandøren skal også kunne håndtere forskellige sikkerhedsniveauer, herunder for data. Infrastrukturdriftsleverandøren vil levere og rapportere på SLA særskilt på platformen (infrastruktur til og med OS) samt på applikationsdriften (databaser, middleware, applikationer og grænsesnits). 6.3 Vederlag for miljøerne m.v. Vederlaget for miljøerne udgøres primært af variable vederlag. De variable vederlag, opgøres på baggrund af de i perioden forbrugte ressourceenheder per måned. Dette vil sige, at infrastrukturdriftsleverandørens vederlag for alle ydelser under ydelsesområderne server inkl. OS, applikationsdrift, storage og backup/restore/recovery som managed service afregnes som variable månedlige vederlag. Ved efterfølgende genudbud overvejer KOM- BIT at inkludere større dele af driften i faste vederlag samt muligheden for også at dække dele af applikationsdriften. Eksempler på ressourceenheder: Server; enten virtuel eller fysisk o En serverressourceenhed (serverinstans) består af en kombination af et antal CPU-kerner, et antal RAM, 32/64 bit miljø, samt et serviceniveau. OS som managed service o En OS som managed service ressourceenhed aftages af en serverressourceenhed (serverinstans). OS angives med software-navn inkl. angivelse af version, kategori forstået ved Microsoft-, Linux- og Unix -baserede systemer, opdeling i 32/64-bit versioner samt serviceniveau. Applikationsdrift o Den daglige applikationsdrift som påhviler driftsleverandøren, såsom overvågning og reaktion på applikationsalarmer skal defineres ifm. udbud. Storage o En storageressourceenhed defineres som et antal GB storage, et Tier, en storagetype (SAN/NAS/DAS) samt serviceniveau. Back-up/restore/recovery o En back-up og restore/recovery ressourceenhed opgøres i antal GB pr. serviceniveau. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 16

Infrastrukturdriftsleverandøren er ansvarlig for at udføre målinger af ressourceenheder og den samlede service inkl. oppetid, der stilles til rådighed for applikationsleverandørerne. Infrastrukturdriftsleverandøren skal i overensstemmelse med de dokumenterede processer og procedurer måle, opgøre og validere brugen af ressourceenheder. Applikationsleverandørerne og KOMBIT har adgang til overvågningen samt de data (inkl. logs), som produceres i produktionsmiljøet. Evt. begrænsede faste vederlag kan i første driftsudbud komme på tale og vil primært bestå af infrastrukturdriftsleverandørens omkostninger forbundet med at levere forbindelsen til kommunernes netværk og lignende. Vederlaget for ny funktionalitet/nye ydelser (samlet ændringer ) opgøres og betales særskilt i henhold til processerne aftalt mellem infrastrukturdriftsleverandøren, applikationsleverandørerne og KOMBIT. Vederlaget for ændringer beregnes ved at benytte: Servicekatalogets fastdefinerede ydelser Timepris baseret på medgået tid og forbrugte materialer i overensstemmelse med prismodellen for timeforbrug 6.4 Incident og Problem Management Infrastrukturdriftsleverandøren skal over for applikationsleverandørerne og KOMBIT leve op til servicemål afhængig af Incident prioritet. KOMBIT har normalt SLA på følgende: Reaktionstid, omgåelsestid, afhjælpningstid, eskalationstid og informationstid. Prioritet 1 og 2 Incidents giver samtidig nedetid på driftseffektiviteten, og der skal udarbejdes en root cause analysis for disse hændelser. Prioritet tager udgangspunkt i følgende tabel: Prioritet Impact Høj Medium Lav Urgency Høj 1 2 3 Medium 2 3 4 Lav 3 4 5 FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 17

Infrastrukturdriftsleverandøren har ansvaret for at rejse incidents over for applikationsleverandørerne vedr. fejl og (begrundede) uhensigtsmæssigheder i driften af applikationerne. Det påhviler så applikationsleverandørerne at analysere og løse disse indenfor applikationsvederlaget. Ligeledes kan applikationsleverandørerne rejse incidents over for infrastrukturdriftsleverandøren, hvilke også løses inden for driftsvederlaget. Både applikationsleverandørerne og infrastrukturdriftsleverandøren har således klare incitamenter til at sikre driftsstabilitet og -effektivitet. 6.5 Krav om ikke eksklusivitet og benchmarking Selvom det er KOMBIT s klare hensigt at samle al drift hos færre infrastrukturdriftsleverandør, så påregner KOMBIT dog ikke at indgå en infrastrukturdriftsleverandørkontrakt, der er eksklusiv i henhold til levering af driftsydelserne. Det skyldes, at kommunerne giver målet om konkurrence meget høj prioritet. Dette krav om ikke eksklusivitet skyldes behovet for hurtigt at kunne vælge alternativer, hvis infrastrukturdriftsleverandørens ydelser og/eller pris ikke skønnes tilfredsstillende af KOMBIT. KOMBIT vil kræve at en benchmarking af driftskontrakten udføres af en uafhængig part et antal gange i kontraktens løbetid, eventuelt årligt. Mulige benchmarkere vælges ud fra firmaer som Gartner, Compass, Maturity, ProBenchmark eller Forrester Research. Intet i infrastrukturdriftsleverandørkontrakten bør således forhindre KOMBIT i at købe de samme ydelser eller tilsvarende ydelser fra en anden infrastrukturdriftsleverandør eller selv frembringe tilsvarende ydelser i kontraktperioden. 6.6 Krav til lokationer Infrastrukturdriftsleverandøren må kun opbevare, tilgå og behandle data samt styre det nødvendige programmel fra faciliteter og lokationer, som: opfylder lovgivningen, herunder bl.a. den danske persondatalov er under infrastrukturdriftsleverandørens fulde kontrol er godkendt af KOMBIT KOMBIT har ret til at gennemføre audits med henblik på at sikre ovenstående samt at driftskontrakten efterleves. KOMBIT skal i denne forbindelse have adgang til infrastrukturdriftsleverandørens faciliteter og lokationer. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 18

6.7 Anvendelse af teknologier, produkter og standarder Infrastrukturdriftsleverandøren må ikke anvende teknologier, ydelser, produkter eller standarder, der har negativ indvirkning på eller ændrer de fælleskommunale business cases, ydeevne og funktionalitet, interoperabilitet, præcision, hastighed, reaktionsevne, kvalitet, slutbrugertilfredshed, omkostninger (inklusive øgede licensomkostninger grundet driftsleverandørens valg af Udstyr og Programmel) og ressourceeffektivitet i relation til projekter og vedligehold. 6.8 Ophørsplan Infrastrukturdriftsleverandøren skal ud over at holde sig til gænge teknologier, have en til stadighed opdateret dokumentation mv. Endvidere skal infrastrukturdriftsleverandøren udarbejde og vedligeholde en ophørsplan for at sikre en smidig og sikker transition til eventuel ny driftsleverandør. Ophørsplanen skal bl.a. indeholde en udpeget en seniorprojektleder, der skal være ansvarlig for den overordnede varetagelse af ophørsassistancen og transitionen til ny infrastrukturdriftsleverandør. 7 Samarbejdsmodellen Som nævnt er applikationsleverandørerne hovedansvarlige for levering af de aftalte projekter til tiden og SLA erne for de respektive idriftsatte fælleskommunale rammearkitektur- og fagsystemer til KOMBIT. Ansvarsfordelingen leverandørerne imellem er detaljeret i dokumentet vedr. 3-lagsmodellen. De funktionelle henvendelser (ændringsønsker og anvendelsessupport) fra brugerne vil således også i den reviderede driftsstrategi fortsat gå direkte til applikationsleverandørerne, der har ansvaret for fejlrettelser, test og releasemanagement. Disse er dermed det primære kontaktpunkt og driver løsningerne med koordinering til infrastrukturdriftsleverandøren. De enkle tekniske brugerafklaringer og administration (eks. ændring af brugeradgang) mv. indenfor standardsupport håndteres af infrastrukturdriftsleverandøren. Dette dog under antagelse af, at applikationsdriften i Model 3 og/eller 4 er overdraget til infrastrukturdriftsleverandøren; ellers er det applikationsleverandørens opgave at varetage også standardsupport. Kun ved eskaleringer bør KOMBIT inddrages. Dette er illustreret på nedenstående figur. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 19

Det overvejes, hvorvidt KOMBIT på længere sigt med fordel kan etablere en SPOC (Single Point of Contact vist med stiplede linjer og evt. delvist outsourcet til tredjepart) med ansvar for at håndtere eskalerede anmodninger i forbindelse med håndtering af Incidents, Problems, Issues m.v. I visse situationer kan der blandt parterne opstå tvivl om, hvem der ejer en given opgave. Der skal derfor etableres en struktur, som minimerer omfanget af Issues, der cirkulerer mellem applikationsleverandørerne indbyrdes og med involvering af infrastrukturdriftsleverandøren. 7.1 Samarbejdsorganisation KOMBIT s nuværende leverandørstyring bygger på et 1:1 forhold mellem KOMBIT og de enkelte leverandører. I den reviderede driftsstrategi vil der blive behov for mere kommunikation og koordination mellem direkte leverandørerne ift. de enkelte (isolerede) projekter/systemer men på sigt mindre direkte koordination for KOMBIT. KOMBIT skal dog etablere de nødvendige styringsfora over projekt- og systemniveauet til håndtering af koordination omkring arkitektur, projekter, release, test og change management. FORSLAG TIL DRIFTSLEVERANDØRSTRATEGI SIDE 20