Costdrivere i it- driftsaftaler
|
Costdrivere i it- driftsaftaler |
Juni 2018 |
Om vejledningen
Vejledningen er udarbejdet i samarbejde med Zangenberg Gruppen.
Zangenberg Gruppen benchmarker private og offentlige outsourcing aftaler og benchmarker således markedspriser for outsourcede it-services som drift af midrange, mainframe og netværk; cloud ydelser, helpdesk, og applikationsvedligehold.
Zangenberg Gruppen benytter en model, der beregner benchmarkingprisen for en kontrakt på samme måde, som leverandørerne beregner priser: baseret på enhedspriser for de enkelte komponenter i aftalen og baseret på omfanget, SLA’erne og kontraktvilkår- og betingelser.
Modellen bliver løbende vedligholdt og opdateres hvert kvartal med nye kontrakter og gennem løbende dialog med leverandører. Modellen spænder over mere end 175 unikke komponenter og mere end 2.000 parametre. Herunder er aktive aftaler med i alt 58.000 servere, 90.000 TB storage og 291.000 workstations med en samlet årlig markedsværdi på mere end 2 milliarder kr. Modellen er alment accepteret som grundlag for benchmark-klausuler og indeksregulering.
Indhold
2. Driftsaftalens primære costdrivere 7
2.1 Fastsættelse af overordnede mål for driftsaftalen 7
2.2 Om at arbejde med alternative aftale-scenarier 8
2.3 Standardydelser vs. specialydelser 9
2.4 Cloud-ydelser og cloud management 11
2.5 Sikkerhedsydelser: standard, tilkøb og special 13
2.6 SLA´er: Tilgængelighed og åbningsvindue 15
2.8 Kompleksitet og omkostninger 18
2.9 Transition og transformation 19
3.1 Kapacitetsfleksibilitet 24
3.3 Benchmarking og prisregulering 25
3.4 Governance og rapportering 26
3.8 Lokation – Overvågningspersonale 28
|
Driftsaftalers primære costdrivere |
|
Indledning
Denne vejledning er tiltænkt alle, der ønsker at forstå, hvilke faktorer (costdrivere), der driver prisen for outsourcet it-drift. Emnet er relevant i forbindelse med udbud og indgåelse af aftaler, og det er relevant i den løbende håndtering af aftaler, hvor ændringer kan have stor indflydelse på den fremadrettede pris.
Igennem vejledningen fokuseres der på costdrivere indenfor fire hovedkategorier:
Ydelsens omfang og afgrænsning kan have en betydelig indflydelse på prisen. Igennem vejledningen beskrives de aktiviteter, der typisk indgår i forskellige driftsydelser. De enkelte aktiviteter har forskellige vægtninger i forhold til prisen. Generelt kan det blot fastslås, at jo tættere på den typiske ydelse den indgåede aftale er, des lavere pris.
Antal enheder. Prisen pr. enhed påvirkes stort set ikke af den samlede mængde enheder, der købes, men den samlede pris er naturligvis afhængig af antallet. Her findes endnu en mulighed for at optimere aftalen: ”Rightsizing”. Rightsizing er justering af det købte antal servere i forhold til det nødvendige antal. Her er der ofte et betydeligt optimeringspotentiale for de fleste myndigheder.
SLA´er. Ydelser leveres med et sæt af Service Level Agreements (SLA´er), der er leverandørens forpligtigelse om f.eks. tilgængelighed, åbningstider, responstider etc. Disse SLA´er driver omkostningerne.
Aftalevilkår. En række vilkår i aftalen medfører ekstra omkostninger eller øget kommerciel risiko for leverandøren. Myndigheden kommer til at betale for dette. De aftalevilkår, der har den største indflydelse på prisen gennemgås.
Vejledningen følger en generisk opdeling af driftsopgaven i et antal overordnede ydelseskategorier, der er gængse på markedet.
Driftsydelserne |
De primære service towers:
Hver af ydelserne beskrives individuelt i vejledningens sidste del fra side Error: Reference source not found. |
Det anbefales, at enhver aftale følger denne opdeling, da det muliggør sammenligning af pris for sammenlignelige ydelser på tværs af leverandører. Myndighedens økonomi knyttet til intern it-drift med anvendelse af disse kategorier bør også kortlægges. Hermed sikres et overblik over den interne it-drift, som er direkte sammenlignelig med, hvad der kan sources i markedet.
Læsevejledning
Vejledningen består af tre dele:
I afsnit 2 gennemgås de primære costdrivere på et overordnet niveau. Læs dette for at forstå, hvad der er vigtigt.
I afsnit 3 gås i dybden med de aftalevilkår, der i særlig grad driver prisen. Læs dette, når udbudsmaterialet udarbejdes, så der er en balance mellem kravspecifikation, juridiske hensyn og kravet til økonomi.
Afsnit 4 er meget konkret og går i dybden med de enkelte ydelseskategorier. Hvad der specifikt driver prisen for den specifikke ydelse beskrives. Læs dette, når der arbejdes med de enkelte ydelsesområder i aftalen.
Driftsaftalens primære costdrivere
Fastsættelse af overordnede mål for driftsaftalen
Denne vejledning fokuserer på de elementer, der driver omkostningerne i en driftsaftale. Det er imidlertid vigtigt at være opmærksom på, at laveste omkostning ikke nødvendigvis er den vigtigste parameter, når der skal udarbejdes en aftale. Der kan være fokus på særlige krav til SLA´er eller særlige krav til fleksibilitet, der vil betinge en højere pris, end der ellers kunne være opnået.
Det anbefales derfor at starte med at gøre de strategiske målsætninger klart, og at søge at prioritere dem i forhold til hinanden, inden der træffes beslutninger om sourcing, og inden start af design af aftalen.
Målsætningerne skal bunde i realisme. Til grund for overvejelser om målsætninger ligger dels myndighedens forudsætninger for sourcing, og dels de muligheder og udfordringer, som eksisterer ved at source en given ydelse. Kun ud fra forudsætningerne og mulighederne, som udgør de aktuelle rammer for outsourcing, kan myndigheden få fastsat et realistisk overordnet mål med aftalen.
Konkret kan myndigheden med fordel arbejde med og prioritere outsourcingens målsætninger indenfor fire forskellige kategorier, som er vist i tabellen nedenfor: kvalitet, økonomi, fleksibilitet og agilitet. Hver især kan de trække strategien i forskellige retninger. For eksempel harmonerer ’lav omkostning’ dårligt med ’stor fleksibilitet’.
Mulige målsætninger |
Kvalitet
|
Økonomi
|
Fleksibilitet
|
Agilitet
|
Om at arbejde med alternative aftale-scenarier
Efter at målene med outsourcing er gjort klar, kan myndigheden arbejde med aftalens elementer og optimere dem i forhold til de opstillede mål. Med denne vejledning vil myndigheden kunne identificere de områder, hvor der er valgmuligheder, som kan have en reel indflydelse på den endelige pris. Der kan udarbejdes scenarier, som repræsenterer ”yderpositioner” af disse valg som i eksemplet her:
Scenarie 1:
Samme SLA´er for alle servere
Ingen anvendelse af cloud
Datacenter i Danmark
Scenarie 2
Differentierede SLA´er (guld, sølv og bronze)
Udvalgte systemer flyttes til Public Cloud
Datacenter i EU
Myndigheden kan regne på disse scenarier ved hjælp af forskellige eksterne nøgletal såsom prisindeks og andre kontrakter, eller det kan vælges at bede om pris-indikationer fra leverandører. Desuden bør der beskrives fordele og ulemper ved scenarierne. Arbejdet med scenarier er relevant forud for et udbud og ved forlængelser af aftalen. Brug vejledningen til at finde de elementer, hvor en ændring må forventes at have en betydelig indflydelse på den samlede pris.
Standardydelser vs. specialydelser
Tilstræb den højeste grad af standardisering
Markedet for driftsydelser er kendetegnet ved en høj grad af standardisering. Enhedspriserne på de primære datacenterydelser (serverdrift og storagedrift) falder betydeligt år efter år. En af forudsætningerne for dette er den høje grad af standardisering.
En række myndigheder vil have et standardiseringsefterslæb med et nuværende specialiseret (dedikeret) drift-setup.
Hvis det ønskes, at en leverandør skal overtage et meget specialiseret drift-setup og drive det videre ”as is”, vil ydelsens pris blive høj. Derudover vil de fleste leverandører have store problemer med at levere ydelserne i en passende kvalitet. Dette skyldes, at leverandørerne netop har gearet deres forretningsmodel til at levere standardiserede ydelser.
Samtidig er det essentielt, at være forberedt på, at systemerne skal kunne flyttes. Jo mere standardiseret det udbudte setup er, desto nemmere er det at dokumentere og flytte det i tilfælde af leverandørskifte.
Mere effektiv udbudsproces
I forhold til den samlede tid, der skal anvendes, kan udbudsprocessen også effektiviseres ved i videst muligt omfang at lægge sig op ad standardiserede ydelser. Her kan beskrivelserne af aktiviteter i afsnit fire bruges som udgangspunkt.
Specialydelser har været en tendens og har betydet højere priser
Når udbudsmaterialet først er udformet og sendt ud, er det i vid udstrækning bindende – også selvom myndigheden bliver klogere i den proces, hvor buddene kommer ind. I en række situationer har offentlige kunder udbudt drift med krav til driftsydelser, der afveg fra leverandørernes standardydelser. Konsekvensen har været, at leverandører er endt med at levere et større antal af varianter af basale driftsydelser til forskellige offentlige kunder, uden at noget umiddelbart har kunnet retfærdiggøre variansen. Disse specialydelser medfører typisk højere priser og udfordringer, når løsningerne skal genudbydes.
Designautoritet
Begrebet ”designautoritet” dækker over retten til at designe den faktiske infrastruktur. Hvis kunden vil have designautoritet og altså vil beskrive, hvordan leverandøren skal designe sin infrastruktur, begrænses leverandørens mulighed for at standardisere og udnytte stordriftsfordele. Det er ligesom specialydelser fordyrende vilkår. Udbudsmaterialet kan let blive udformet, så det dikterer en særlig opsætning af leverandørens infrastruktur. Tommelfingerreglen er, at det på dette punkt bør beskrive så lidt som muligt. Jo mere der beskrives, hvordan infrastrukturen skal se ud, des dyrere bliver det.
Overvej, om det er nok at stille krav til SLA’er, sikkerhed og ydelsernes indhold og ikke krav til den faktiske arkitektur.
Som et alternativ til designautoritet kan applikationerne, der skal drives på en given type infrastruktur, i stedet beskrives, og udbudsmaterialet kan lade det være op til leverandøren at komme med et bud på den endelige udformning af infrastrukturen.
Hvis udbuddet omfatter krav til selvstændige ydelser og til infrastruktur-optimering, eller hvis selve infrastruktur-optimeringen er en del af udbuddet, er det værd at gøre det til en selvstændig prissat opgave/projekt. Hvis virtualiseringsgraden eksempelvis er lav, vil der ofte være betydelige penge at spare ved at øge denne. Leverandøren kan imidlertid have vanskeligt ved at give bud på, hvor meget der kan virtualiseres uden at kende til applikationsdesign, faktisk performance mv. Lad derfor udbudsmaterialet efterspørge leverandørens tilgang til infrastruktur-designoptimering. Alternativet er at få gennemført en teknisk analyse af en uafhængig tredjepart før udbuddet.
Cloud-ydelser og cloud management
Cloud bliver en del af de fleste driftsaftaler
De seneste par år har set en markant vækst i antallet af både private virksomheder og offentlige myndigheder, der vælger at implementere cloud-løsninger. Datamængden i skyen vokser, og det går hurtigt. Ved indgåelse af nye aftaler bør det overvejes, om en del af de omfattede systemer skal flyttes i cloud – nu eller indenfor aftaleperioden.
At dokumentere og regne på den reelle business case knyttet til at gå i skyen er en udfordring, mange myndigheder kæmper med. Her er det vigtigt at forstå, hvad cloud-ydelser indeholder: Hvad er inkluderet, og hvad skal myndigheden selv gøre eller få andre til?
Cloud – private og public – er kendetegnet ved skalerbarhed, selvprovisionering og forbrugsafregning. Hardware, software og den underliggende infrastruktur ligger hos leverandøren. Den primære forskel mellem private og public cloud er, at der i en public cloud købes kapacitet (CPU’er og RAM), hvor ”cloud management” ikke er inkluderet og typisk vil skulle håndteres af egen it-afdeling eller tredjepart. ”Cloud management” dækker over en række opgaver, der ikke leveres som standard i et cloud setup: backup og restore, patch management af operativsystem, antivirus, monitorering og rapportering samt problem- og incident-management. Private cloud købes enten som en klassisk outsourcing, hvor kapacitet og cloud management købes som en samlet ydelse, eller hvor kapacitet og cloud management adskilles og aftages særskilt. Se i øvrigt Digitaliseringsstyrelsens Cloud Vejledning for detaljer.
Cloud-ydelser opdeles i Infrastructure as a Service (IaaS), Platform as a Service (PaaS) og Software as a Service (SaaS), der specificerer, hvor store dele af it-stakken cloud-udbyderen varetager.
Cloud-ydelser |
|
De største udfordringer i at kunne udnytte cloud-mulighederne optimalt er standardisering, governance og it-leverandørstyring, sikkerhed og kompetencer:
Brug af cloud-infrastrukturydelser kræver en høj standardisering af såvel applikationer som processer. Det handler grundlæggende om at have virtualiseret sit server-setup og strømlinet sine interne driftsprocesser. Migrering af virtuelle servere til et cloud-setup er ofte en tidskrævende proces og kræver detaljeret indsigt i myndighedens nuværende it-miljø. For mange myndigheder med legacy it, gamle systemer, operativsystemer, databaser mv. vil det være umuligt eller kræve en større transition at lægge systemer i skyen.
Også processer og governance generelt i myndigheden skal strømlines, hvis myndigheden ønsker at opnå de fordele, cloud kan medføre. Hvor der før måske har været en indkøbsproces, som uden problemer kunne tage et par uger, fordi indkøbene alligevel blev leveret med en vis tidshorisont, er dette ikke tilfældet med cloud. Her tager det et par museklik, før ressourcen er købt og aktiveret. På et overordnet plan handler det derfor om at have en governance og it-leverandørstyringsproces, der kan understøtte denne fleksible og agile tilgang til det at købe it-ydelser i skyen.
Sikkerhed og databeskyttelse nævnes ofte som de bærende argumenter mod at ville gå i skyen. Bekymringerne centrerer sig om databeskyttelse i forhold til såvel lovgivning som forretningsrisiko. For at imødegå disse udfordringer, bør data, der både kan og må ligge i skyen identificeres. Lovgivningen regulerer personfølsomme data, men der er store forskelle på de garantier, leverandørerne vil give for at få fat i væsentlige markedsandele. For mange myndigheder vil det være muligt at differentiere data og dermed håndtere databeskyttelsen på en måde, der muliggør anvendelsen af cloud-ydelser. En opdeling af data kan sikre, at de mest forretningskritiske og følsomme data ikke opbevares i skyen, samtidig med at de finansielle fordele ved cloud realiseres på ikke-følsomme eller mindre forretningskritiske områder.
Interne kompetencer og erfaring med cloud-ydelser bliver ved med at være en central udfordring for mange myndigheder. At gå fra klassisk infrastrukturdrift til at flytte infrastruktur og applikationer til skyen fordrer kompetencer, som myndigheden ikke nødvendigvis har til rådighed. Medmindre applikationerne i forvejen er skrevet og tilpasset direkte til skyen, kræver det specielle kompetencer at kunne håndtere og indarbejde integrationsflader (API’er), capacity management, automatiseringsscripts mv. Der er endnu ikke et modent marked for disse kompetencer og ressourcer, og det kan ligeledes være en udfordring at finde de rette eller nødvendige kurser eller efteruddannelser.
Sikkerhedsydelser: standard, tilkøb og special
Myndighedernes afhængighed af it til understøttelse af centrale forretningsprocesser er mere kritisk end nogensinde – og der er en tilsvarende tilvækst i it-landskabets samlede kompleksitet. Samtidig øges kravene til it-sikkerhed for at imødegå et mere og mere sofistikeret trusselsbillede.
I arbejdet med it-sikkerhed skal myndigheden på samme tid sikre data og systemers tilgængelighed, fortrolighed og integritet. Virkemidlerne er en kombination af teknologi, værktøjer, processer og de rette kompetencer. Det er her centralt løbende at have et opdateret billede af det trusselsniveau, myndigheden står overfor, samt de virkemidler, der kan sikre, at trusler forbliver trusler, og ikke går hen og bliver en realitet. Det gælder også for myndigheder, der outsourcer deres it-infrastrukturdrift til eksterne leverandører.
Standardisering og sikkerhed
Det niveau af sikkerhed, som it-leverandører kan levere som standard, er typisk også et godt svar på de trusler, de fleste offentlige myndigheder står overfor. Professionelle leverandører af it-drift har specialiseret sig, udviklet redskaber, kompetencer og processer indenfor sikker drift af it-infrastruktur. Det kan samtidig være svært for mindre myndigheder at fastholde og rekruttere talent og kompetencer, som en professionel leverandør modsat bør forventes at have sat i system og indarbejdet processer for. It-sikkerhed kan altså i mange tilfælde være en af flere faktorer, myndigheden vælger at lægge til grund for outsourcing for ad den vej at få adgang til et bedre og konsistent sikkerhedsniveau for myndighedens it-drift.
I en outsourcingsammenhæng er det også værd at notere sig, at sikkerheden generelt stiger med graden af standardisering. Som eksempel vil en leverandør i mange tilfælde samle og standardisere driften, hvor det er muligt. Det betyder, at drift af eksempelvis Windows-servere samles i større clusters, hvor sikkerhedspatches, operativsystemer, firewalls og antivirus mv. opdateres og installeres ud fra faste processer. Det giver i sidste ende et godt udgangspunkt for at skabe en best-in-class, konsistent og stabil drift.
I det øjeblik, myndigheden bevæger sig væk fra standard og køber specialiserede ydelser, eksempelvis dedikerede miljøer med særlige driftsydelser, kan det blive vanskeligere for leverandører at levere samme høje niveau af sikkerhed over en længere periode. Særlige og kundespecifikke ydelser giver altså ikke nødvendigvis et højere niveau af sikkerhed, og det bliver som hovedregel dyrere.
Uanset om der vælges standardydelser eller specialiserede ydelser, bør det sikres, at leverandøren jævnligt underkastes grundige audits af troværdige eksterne virksomheder, og at disse audits ikke udelukkende er baseret på leverandørens ”selvangivelse” af egne sikkerhedskontroller.
Behovet for tilkøb af sikkerhedsydelser
Enhver skal overveje berettigelsen af krav til sikkerhed, der går udover de elementer, der indgår i leverandørens standardydelser. I afsnit fire, hvor de enkelte ydelseskategorier gennemgås, er alle de sikkerheds-relaterede aktiviteter, der indgår i den typiske standardydelse eksplicit markeret. Brug dette til at vurdere, om der er behov for yderligere ydelser.
Typiske krav, der ligger ud over standardydelserne, omfatter særlige krav til kryptering mm. af netværk, krav til ”hot-switching” i spejlede datacenterkonfigurationer samt andre sikkerhedskrav, der medfører krav til særlig hardware eller software i datacentret.
SLA´er: Tilgængelighed og åbningsvindue
SLA eller Service Level Agreement betegner de aftalemæssige vilkår mellem myndigheden og leverandøren, der regulerer de centrale servicemål som tilgængelighed, responstider, udbedringstider mm. I mange outsourcingaftaler arbejdes der med betegnelserne bronze-, sølv-, guld-, og i nogle tilfælde med platin-SLA-grupper for at beskrive tilgængelighed og åbningstider. Tabellen herunder viser et typisk sæt definitioner for de fire SLA-niveauer for server-drift:
SLA-gruppe |
Tilgængelighed |
Åbningstider |
Bronze |
98 % |
8/5 |
Sølv |
99 % |
24/7 |
Guld |
99,5 % |
24/7 |
Platin |
99,9 % |
24/7 |
Der er knyttet selvstændige markedspriser til disse grupper. Samtidig er definitionerne i bevægelse, hvilket betyder, at der over tid er kommet højere SLA’er til samme pris.
I dag vil alle servere i et datacenter typisk være underlagt de samme driftsprocesser og krav til vedligehold, fornyelsesplaner mv., og dermed vil den interne styring hos leverandøren være gearet mod det højeste tilgængelighedskrav. Prisen for lavere tilgængelighedskrav er således ikke knyttet til de faktiske omkostninger, men knyttet til risiko og mere kommercielle hensyn med henblik på differentiering af produktudbuddet. Den teknologiske udvikling har ført til lavere risiko for nedbrud, og den naturlige konkurrence har herefter drevet grænserne for de enkelte SLA-niveauer op.
Overordnet set er forskellen i pris mindre mellem de lavere SLA-grupper end forskellen mellem de højere. Prisen stiger eksponentielt op igennem SLA-niveauerne.
Overvej derfor altid grundigt de valgte SLA-niveauer og brug eventuelt tabellen herunder som hjælp. Tabellen viser, hvor mange timer og minutter servere kan være nede ved forskellige SLA-niveauer. Husk på, at dette ikke er udtryk for, hvor lang tid infrastrukturen faktisk vil være utilgængelig, men angiver, hvornår leverandøren vil ifalde bod.
Tilladte nedetimer per måned (timer:minutter)
|
Åbningstid |
|
|
95 % |
8:00 |
10:00 |
36:00 |
97 % |
4:48 |
6:00 |
21:36 |
98 % |
3:12 |
4:00 |
14:24 |
99 % |
1:36 |
2:00 |
7:12 |
99,5 % |
0:48 |
1:00 |
3:36 |
99,8 % |
0:19 |
0:24 |
1:24 |
99,9 % |
0:10 |
0:12 |
0:43 |
Software
Der er både fordele og ulemper ved at købe softwarelicenser som en del af en it-driftsaftale. De væsentligste ulemper ved denne model knytter sig til den pris, kunder i sidste ende kan komme til at betale for software. Det har nemlig i praksis vist sig, at ikke alle outsourcing-leverandører har skaffet kunderne den bedste pris på software.
Da en række it-drifts- og softwareleverandører indgår partnerskaber på tværs af markedet, kan det skabe en situation, hvor outsourcing-leverandøren ikke nødvendigvis har en tilskyndelse til at sikre kunden den laveste software-pris. Kunder, der ønsker den skarpeste markedspris for supplerende software, er alt andet lige selv nødt til som minimum at tjekke, om priserne er optimale. Dog bør der altid arbejdes på at gøre outsourcingleverandøren til en aktiv medspiller i sådanne forhandlinger eller softwarekontraktforløb. Har kunden overladt store dele af it-driften til en leverandør, vil denne også have gode forudsætninger for at levere relevant rådgivning og ikke mindst den relevante dokumentation.
De væsentligste fordele ved øget outsourcing af softwarestyringen er:
Det kan ofte være vanskeligt for kunder selv at styre separate licensomkostninger, der typisk er betinget af komplekse afregningsmodeller og politikker. Det stiller store krav til kundens overblik og interne license management-processer. Outsourcingleverandøren vil ofte have gode forudsætninger for løbende at kunne fastholde et retvisende overblik over, hvor mange licenser kunden reelt forbruger.
I en række situationer vil leverandøren qua stordrift og mulighed for volumenrabat faktisk kunne opnå bedre enhedspriser end kunden selv. Her bør kunder dog være opmærksomme på eventuelle partnerskaber mellem software- og outsourcingleverandøren, der, som før omtalt, ikke nødvendigvis vil give den bedste pris.
Administrerer leverandøren i forvejen store dele af kundens it-infrastruktur, står denne også i en god position i forhold til at rådgive kundens interne it-organisation om optimering af licenser, hardware, brugere mv.
En professionel leverandør vil i forvejen have software asset management-værktøjer til rådighed. Sådanne værktøjer kan sikre, at outsourcingleverandøren også i praksis kan give kunden et overblik over forbrug af licenser.
Kompleksitet og omkostninger
Kompleksiteten af det samlede systemlandskab har en selvstændig indflydelse på prisen. Et enkelt system bestående af 10 applikationer, der anvender 250 servere, kan altså være billigere at drive end et mere kompleks system bestående af 10 applikationer, der også anvender 250 servere. Myndigheder med et meget stort og komplekst systemlandskab med eksempelvis legacy-systemer, der er tungt integreret på tværs af mainframe og midrange, har et højere omkostningsniveau end myndigheder med et systemlandskab med få integrationer og baseret på standardløsninger.
Jo højere kompleksitet, jo større vedligeholdsomfang. Incidents og changes vil typisk tage længere tid at løse, og der vil være flere ændringer, der grænser til krævende udviklingsopgaver. Vær også opmærksom på, at systemkompleksiteten driver mandskabsomkostninger. Jo større kompleksitet, jo større behovsspredning i forskellige typer af it-kompetencer med fokus på de enkelte applikationer, platforme og integrationer mm. I evalueringen af kontraktporteføljens kompleksitet er det også værd at være opmærksom på forholdet mellem antallet af driftskontrakter og udviklings-/implementeringskontrakter, da antallet af udviklings-/implementeringskontrakter som udgangspunkt øger kompleksitetsgraden i drifts-kontraktstyringen.
Prisen for kompleksiteten i aftalen følger generelt antallet af databaseplatforme, antallet af integrationer i forhold til antallet af systemer, typer af integrationer, og om aftalen omfatter kombination af mainframedrift og midrangedrift. Antallet af integrationer i forhold til systemer har betydning for, hvor afhængige systemerne er af hinanden, og har derfor indflydelse på kompleksiteten af den samlede driftsopgave. Et mere komplekst systemlandskab vil berettige en merpris på aftalen.
Det er vigtigt at tage stilling til kompleksiteten i systemlandskabet, inden en aftale sættes i udbud. Der kan være mange penge at spare, hvis kompleksiteten kan reduceres og et gammelt systemlandskab ikke ukritisk videreføres.
Antallet af databaseplatforme indvirker som nævnt kompleksiteten, og her kan det være en overvejelse værd, om der kan konsolideres til færre platforme hvormed en bedre pris på selve driften opnås.
Transition og transformation
En kritisk fase i et outsourcingforhold er transitionsfasen, hvor opgaven, systemerne og i visse tilfælde dele af selve infrastrukturen og eventuelt medarbejdere flyttes fra kundens miljø til leverandørens, eller der sker en flytning fra en leverandør til en anden.
Strømlining inden outsourcing første gang
En tommelfingerregel for førstegangs-outsourcing (fra kundens miljø til en leverandør) er, at tilstræbe at have ”orden i eget hus” for at undgå, at omkostningerne løber løbsk – ikke mindst i transitionsfasen. Derfor bør der så vidt muligt ske en strømlining inden outsourcing, og her er der tre grundlæggende trin: Standardisér, virtualisér og dokumentér.
Transitionen vil blive forenklet, hvis myndigheden har standardiseret sit setup forinden. Det kan være standardisering af operativsystemversioner på tværs af servere, database- og middleware-versioner eller opgradering af applikationer til seneste version. Hvis dette i stedet gøres til en del af aftalen med leverandøren, bør aktiviteterne være beskrevet og navnlig prissat selvstændigt.
I det omfang, det er muligt at virtualisere serversetuppet, bør dette være foretaget inden transitionen, så der ikke betales for unødige fysiske servere i etableringsfasen. Vær opmærksom på, at der kan være mange penge at spare her, og at det kan være svært at vurdere leverandørens tilbud, hvis den nøjagtige og maksimalt mulige virtualiseringsgrad inden transitionen er ukendt.
Kvaliteten af den tilgængelige operationelle driftsdokumentation har stor indflydelse på, hvor smidigt transitionen forløber og på omkostningerne knyttet til transitionen. Der bør foreligge en driftshåndbog, som er udførlig nok til, at en “vilkårlig” person reelt kan overtage driften. Driftshåndbogen skal blandt andet indeholde:
Daglige driftsrutiner
Håndtering af fejlsituationer
Afvikling af batch-job
Håndtering af ændringer: hvordan de flyttes fra udvikling til test, staging og produktion
Opdateringer af alle systemkomponenter
Detaljeret angivelse af, hvordan test skal gennemføres
Hvordan performancemålinger og end to end-SLA-målinger foretages
Hvad er med som standard?
Det er vigtigt at skelne imellem transition og transformation, da transformation kan være en markant vanskeligere omkostningskategori at håndtere. Transformation omfatter alle ændringer til systemer og data, der er nødvendige for at kunne flytte til den nye leverandør. Flytning fra traditionel outsourcing til forskellige cloud-scenarier skal også håndteres som transformation.
Transformationskomponenten kan udgøre et projekt i sig selv og vil oftest repræsentere en synlig udgift. Transition bør altid prissættes selvstændigt.
Virksomhedsoverdragelse af medarbejdere er endnu en opgave, der vil kunne afføde selvstændige omkostninger, og som derfor bør udskilles som en selvstændig omkostning.
En række transitionsopgaver er en del af leverandørernes standardydelse. De bør altså ikke prissættes selvstændigt:
Etablering af leverandørens egen hardwareinfrastruktur
Standard netværkskonfiguration
Installation og konfiguration af operativsystem
Installation af databaser og applikationer – uden ændringer
Transport af data – ikke konvertering af data
Etablering af overvågning
Test af kundens setup
Andre opgaver retfærdiggør en selvstændig betaling. Det gælder f.eks.:
Fysisk flytning af kundens hardware til leverandørens datacenter. Det er “lift out”-scenariet, og hvis dedikeret hardware overdrages, kan der være omkostninger til nedtagning, test, fysisk flytning med mere.
Opsætning, konfiguration og test af kundespecifik hardware.
Kundespecifik netværkskonfiguration. Hvis leverandøren skal overtage drift af en eksisterende netværkskonfiguration i modsætning til opsætning af egen konfiguration, vil dette kunne medføre selvstændige omkostninger. Tilsvarende, hvis kunden stiller særlige krav (for eksempel sikkerhedskrav) til konfigurationen.
Integration med kundens hardware. Er der hardware, som bliver tilbage i kundens setup, og skal der skabes integration mellem det outsourcede setup og kunden eller andre leverandører? Dette vil medføre selvstændige omkostninger og kan være en ganske kompliceret manøvre – navnlig i forhold til integration mellem mainframe- og midrange-platforme.
Særligt om leverandør-til-leverandør transition
En af de væsentligste forskelle på en kunde-til-leverandørtransition og en leverandør-til-leverandørtransition er, at hvor det før var to parter, der skulle løse transitionsopgaven, er der nu opstået en trepartskonstellation: Kunden, den oprindelige leverandør A og den fremtidige leverandør B. Det i sig selv øger kompleksiteten af opgaven, og den bliver øget yderligere af, at den ene part – leverandør A – ofte har mindre incitament i at gå “above and beyond” for at bringe transitionen i mål. Xxxxx sagt på en anden måde: Xxxxx flere ressourcer på transitionen, end hvad der juridisk forpligtes til.
Kompleksiteten i trepartskonstellationen påvirker en lang række aspekter i leverandør-til-leverandørtransitionen, men det er i særdeleshed værd at være opmærksom på følgende syv områder:
Organisering og governance af projektet
Teamkompetencer, især på den tekniske del
Teknisk kritiske afhængigheder mellem flyttede komponenter
Risikovurdering og plan B
Transitionsplanens detaljeringsgrad skal være meget høj
Opmærksomhed under eksekvering, da noget vil gå galt
Test af systemerne efter transitionen
Har kunden haft dette fokus, er det vigtigt at understrege, at omkostnings-, tids- og risikoprofilen på en række områder faktisk er lidt bedre i en leverandør-til-leverandørtransition end i en førstegangstransition. Det gælder:
Opsætning, konfiguration og test af hardware
Netværkskonfiguration
Udarbejdelse af kundespecifik dokumentation
Tilretning af applikationer
Fælles for de fire områder er, at der typisk flyttes et mere strømlinet setup end ved en førstegangstransition. Det sker som sagt under forudsætning af, at der har været fokus på processer, og at leverandøren har dokumenteret it-setuppet professionelt og sørget for løbende standardisering og opgradering.
Ses på de rent økonomiske forhold, er der to områder, der bør være særlig opmærksomhed på i leverandør-til-leverandørtransitionen. For det første må det forventes, at den eksisterende leverandør vil holde sig stramt til den eksisterende aftale. Da der typisk vil opstå forskydninger i transitionsplanen, anbefales det at budgettere med ekstra omkostninger i den forbindelse. Igen, jo mere standardiseret it-setuppet er, jo mindre vil disse omkostninger typisk være. For det andet skal der ses på ejerskab af dedikeret hardware. Ejes det af eksisterende leverandør, og ønskes det flyttet, skal det naturligvis frikøbes.
Aftalevilkår
I dette afsnit gennemgås de aftalevilkår, der typisk har størst indflydelse på aftalens samlede pris.
De enkelte vilkår har forskellige vægtninger, men ved indgåelsen af outsourcingaftaler er det vigtigt at overveje og tage stilling til hvert enkelt punkt. Det er vigtigt at gennemføre en vurdering af, hvilke behov myndigheden har for at stille specifikke krav til leverandøren. Jo færre krav, der stilles til leverandøren angående den daglige drift, jo bedre en pris kan alt andet lige opnås. Samtidig skal det sikres at leverandørens vilkår er markedskonforme – afsnittet her gennemgår de væsentligste vilkår, og hvad der betragtes som markedskonformt.
Der kan være gode grunde til at afvige fra standardvilkårene. For en række kunder er det tvingende nødvendigt eksempelvis af lovgivningshensyn eller på grund af særlige strategiske behov. Eksempelvis kan offentlige kunder være nødt til at stille særlige krav til lokalisering af datacentre, og der kan være gode grunde til at ønske stor fleksibilitet i forhold til kapacitet. I begge tilfælde vil dette så medføre en meromkostning. I forbindelse med forhandling af aftaler er det derfor vigtigt at fokusere på netop de områder, hvor der er særlige krav. For de øvrige bør det nøje overvejes, om der kan nøjes med ”standardbetingelser” og dermed opnå en bedre pris.
Kapacitetsfleksibilitet
En outsourcingaftale beskriver typisk leverance af en vis kapacitet – eksempelvis drift af en række applikationer og en tilhørende infrastruktur opgjort i antal servere, storage kapacitet mv. En aftale med indbygget kapacitetsfleksibilitet giver kunden mulighed for at skrue op og ned for forbruget af ydelser og lade den samlede pris følge ændringerne i kapacitet. For leverandøren er det især nedadgående fleksibilitet, der skaber usikkerhed om fremtidig omsætning og derfor berettiger en merpris.
Det vil som standard være muligt at have en vis nedadgående fleksibilitet (typisk omkring 20 %). Det kan være muligheden for at lukke enkelte systemer, der ikke længere er i brug, men så snart der skal være fleksibilitet på større dele af aftalen, vil leverandøren være nødsaget til at dække den kommercielle risiko. Som kunde, må ønsket om kapacitetsfleksibilitet afvejes i forhold til en mere fastlåst aftale med bedre enhedspris. Et alternativ til nedadgående fleksibilitet kunne være indgåelsen af mindre delaftaler med fordelagtige betingelser for udtrædelse.
Prismodel
I forbindelse med indgåelse af en aftale kan det groft sagt vælges at følge markedskonforme modeller eller at specificere en egen model. Hvis den bedste pris skal opnås, bør markedskonforme modeller følges. Det vil sige, at kundespecifikke krav til afregning af enhedspriser og lign. vil resultere i en merpris.
Det er særligt i forbindelse med udbudsmateriale vigtigt at overveje eventuelle krav til afregning. Bliver der i et udbud specificeret en prismodel fra kundens side, der ikke følger gængse standarder, kan dette altså fordyre den samlede aftale. De tilfælde, hvor kunden kunne forestille sig krav til prismodellen, kunne være, hvis der er særlige ønsker om en alternativ afregningsform som eksempelvis følger forbrug (antal transaktioner, serverkapacitet i stedet for antallet af servere mv.) i stedet for faste enhedspriser. Afregning i forhold til forbrug er standard, når det gælder cloudydelser, men ikke for de ”traditionelle” outsourcingaftaler. Det er altså noget, der i fremtiden kan vinde større indpas, men på nuværende tidspunkt må en merpris forventes, hvis alternative afregningsformer ønskes.
Benchmarking og prisregulering
Mange aftaler har i dag benchmark-klausuler, og leverandøren vil typisk kun påregne en merpris, hvis der er en bindende benchmark-klausul, det vil sige en klausul, hvor prisen automatisk reguleres som konsekvens af en benchmark. En benchmark-klausul med ret til regulering af prisen er ikke unormalt og vil ikke retfærdiggøre en merpris. Af hensyn til udbudsreglerne, skal reguleringsmulighederne være forudbestemt i kontrakten.
Det er derfor vigtigt, at myndigheden indskriver en benchmark-klausul, der er tilpasset egne behov. Det er den generelle erfaring, at selvom en bindende benchmark-klausul berettiger en merpris, vil gevinsten ofte værre større end merprisen. De kraftige prisfald på enhedspriserne gør, at aftaler uden automatisk prisjustering eller mulighed for benchmarking efter er par års løbetid kan være betydeligt over markedspris. Benchmarking kan være et vigtigt værktøj i bestræbelserne på at få aftaleprisen til at matche markedspriserne for længerevarende aftaler, og alle betydende leverandører giver mulighed for benchmarking-klausuler.
Governance og rapportering
Governance handler om samarbejdsorganisation, processer og beslutningsveje. Rapportering omfatter leverandørens månedlige og kvartalsvise rapportering af leverede ydelser og overholdelse af SLA'er. Igen handler det om, i hvor høj grad specielle vilkår ønskes. De fleste leverandører er i stand til at levere ydelser under markedskonforme governance- og SLA-regimer.
Jo mere en kunde indordner sig under sådanne standarder, jo billigere vil aftalen blive. Oftest vil leverandøren have helt klare strukturer både for en central governance og klare retningslinjer for måling og rapportering af SLA'er. Det kan være nødvendigt for nogle myndigheder at have en mere decentral governance, hvis der er mange decentrale lokationer, som ikke nødvendigvis arbejder tæt sammen med et hovedkontor. Som hovedregel anbefales det dog, at myndigheden søger at indordne sig leverandørens standardbetingelser og begrænser antallet af særlige krav til governance og rapportering.
Bod
Specielle krav til bodsbetingelser bliver fra leverandørens side omregnet direkte til kommerciel risiko, og alle krav til højere bodsbestemmelser vil blive direkte overført til aftaleprisen. Som hovedregel kan det siges, at en bodsbestemmelse, hvor mere end 10 % af det månedlige honorar er på spil, vil afføde en merpris.
Erfaringen viser, at skrappere krav til bodsbestemmelser er et af de områder, som sjældent har nogen gavnlig virkning på den daglige drift. Da skrappe bodsbestemmelser i tilfælde af mangelfuld drift allerede er regnet ind i den månedlige ydelse, er de de-facto ikke med til at skabe en bedre incitamentstruktur for den del af leverandørens organisation, der rent faktisk leverer ydelsen.
Indkrævelse af bod er heller ikke uproblematisk. Mange kunder har haft dårlige erfaringer med processen omkring indkrævelsen af bod, der ofte ender i slagsmål mellem advokater og i strid om tekniske opgørelser af SLA'er. Anbefalingen er derfor, at det grundigt analyseres, om skrappere bodsbestemmelser er noget, der ønskes i en aftale, da merprisen kan være betydelig. Muligvis kan mildere bodsbestemmelser betyde at denne merpris undgås, hvilket kan opveje risikoen på driftssiden.
Bindingsperiode
Længden på aftalen kan have både positiv og negativ effekt på prisen. En markedskonform aftaleperiode på omkring fire år giver hverken anledning til merpris eller et nedslag i prisen. Det er klart, at meget lange aftaleperioder må ses som fordelagtige for leverandøren, og derfor burde give et nedslag i prisen.
En kortere aftaleperiode giver mulighed for en ny aftale, inden diskrepansen mellem aftalens enhedspriser og markedspriserne bliver for stor. En aftaleperiode betydeligt under fire år pålægger leverandøren en risiko og en kortere afskrivningsperiode for eventuelt hardware, der er indkøbt til den specifikke aftale. Dette afspejles i prissætningen. Et længere samarbejde kan også være til fordel for myndigheden, der måske ønsker stabilitet omkring outsourcingaftalen. Set i lyset af udviklingen af markedspriserne, kan det dog ikke anbefales at indgå aftaler med lang løbetid, hvis ikke der som minimum er gunstige udtrædelsesmuligheder eller benchmark-klausuler med mulighed for benchmarking flere gange i løbet af aftaleperioden. Det kan i stedet for meget korte aftaleperioder bruges til at sikre, at priserne forbliver markedskonforme.
Lokation – Datacenter
Krav til lokation af datacenter har en vis indflydelse på prisen. Hvis kunden ikke stiller krav til lokation af datacenter bliver prisen lavere. Stiller kunden krav til, hvor datacenter skal være placeret, må der fra leverandøren påregnes en merpris. Derfor skal det vurderes, om der er eventuelle hindringer for, at datacenteret eksempelvis kan være placeret i et andet EU-land, eller om det kan være placeret udenfor EU.
Det er relativt få myndigheder i Danmark, som er underlagt juridiske restriktioner, der dikterer opbevaring af data indenfor Danmarks grænser. De fleste myndigheder vil som udgangspunkt kunne opbevare data indenfor EU, hvilket vil øge leverandørens fleksibilitet og dermed resultere i en lavere pris.
Lokation – Overvågningspersonale
Krav til lokation af personale til overvågning har også en vis indflydelse på prisen, og uden disse krav fås en lavere pris. Stiller kunden krav til, hvor personalet skal være placeret, må der fra leverandøren påregnes en merpris.
Ligesom med opbevaring af data er det meget få virksomheder i Danmark, som er underlagt juridiske restriktioner for placering af personale til overvågning i Danmark.
Særlige sikkerhedskrav
Særlige krav til sikkerhed vil give anledning til en højere pris. Skalaen her går fra kunder uden særlige sikkerhedskrav til militær- og efterretningsvirksomhed. Det kan være krav som dublering af datacenter eller dublering af udvalgte systemer (hot switch, aktiv-aktiv failover mm.). Alle ekstra sikkerhedskrav vil resultere i en merpris, og derfor skal krav om særlige sikkerhedsbestemmelser overvejes. I gennemgangen af de enkelte ydelseskategorier er alle sikkerheds-opgaver, der leveres som en del af standardydelserne, markeret med et ”(S)”.
|
Standardydelser i driftsaftaler |
|
Standardydelser i driftsaftaler
Serverdrift
Serverdrift udgør ofte en betydelig del af den samlede driftsaftale. Det kan derfor godt betale sig at være grundig med at sikre, at aftalen er med et optimeret setup, der ikke omfatter flere servere end der reelt er behov for, og virtuelle servere i stedet for fysiske, hvor dette er muligt.
Dernæst er det vigtigt at sikre, at ydelsesbeskrivelse i videst muligt omfang flugter med markedets standarder, og som derudover kun har aktiviteter, der er kritiske for myndigheden – for de vil typisk bære en synlig meromkostning. Hardware udgør en betydelig del af den samlede omkostning, og derfor har det stor betydning, om der er tale om drift på leverandørens hardware eller egen hardware.
Endelig skal det nøje overvejes, om server-setupet kan segmenteres, så f.eks. kritiske produktionsmiljøer med fuld ydelse og høje SLA´er er på den ene side og test/udviklingsmiljøer med lave SLA´er og mere begrænset ydelses-snit er på den anden.
Omkostningsområder
|
|
Valgmuligheder
Faktor |
Muligheder |
Betydning |
Type |
Fysiske eller virtuelle servere |
Fysiske servere er dyrere end virtuelle servere |
Operativsystem |
|
”Andre operativsystemer” er dyrere end Windows-servere, og Windows er dyrere end Linux-/Unix-servere. |
Størrelse |
Antal CPU´er og/eller cores |
|
Hukommelse |
Gb RAM til den enkelte server |
|
Ydelsens standardelementer
Aktiviteterne med rød skrift bidrager mest til den samlede omkostning og udgør tilsammen over 50 % af den samlede omkostning. Aktiviteterne markeret med (S) relaterer sig til sikkerhed. |
Service management
|
System management
|
Vedligeholdelse
|
Værktøj
|
Ejerskab
|
SLA´er
Åbningsvinduet angiver det tidsrum, hvor leverandøren garanterer, at serveren er tilgængelig. Dette kan f.eks. være 10 timer om dagen i ugens fem arbejdsdage eller 24 timer i døgnet syv dage om ugen.
Tilgængeligheden bliver målt som serverens tilgængelighed i procent af det lovede servicevindue. Dette er typisk i et interval fra 98 % til 99,9 %.
Den højeste SLA er typisk mellem 1,5 og 2,5 gange dyrere end den laveste SLA.
Hardware
Hardware omfatter server-CPU’en, tilhørende RAM, rackskabe, kabling, kølingsudstyr, brandslukningsudstyr, UPS, diske monteret i servere, datacenter-netværkskomponenter, terminaler og perifære enheder, der er nødvendige for at varetage normal serverdrift.
Software
Alle faktiske omkostninger til software, der anvendes i forbindelse med den almindelige drift af midrange-serverne. Dette omfatter alle operativsystemelementer, overvågning og datacenter-systemer, antivirus, firewall og andre centrale sikkerhedssystemer, der alle er nødvendige for den generelle drift. Omkostningerne omfatter ikke middleware, databaser eller systempakker udviklet internt eller købt eksternt til en specifik brugergruppe.
Andre omkostninger
Andre omkostninger omfatter alle relevante forbrugsstoffer som bånd og andre backupmedier, forbrugsstoffer til nødstrøm og brandsikring (diesel og halon) med mere.
Storage
Storagedrift udgør sammen med serverdrift ofte en betydelig del af den samlede driftsaftale, og det kan derfor godt betale sig at være grundig med at sikre, at aftalen er med et optimeret setup. For storage er det især vigtigt at have sat storagepolitikker op for brug, da forbrug afregnes direkte.
Det er vigtigt at gøre sig klart, om storage ønskes på eksempelvis SSD, som typisk vil være dyrere, men også levere klart bedre performance, eller om det kan nøjes med at være ældre teknologier, som vil have lavere performance.
Dernæst er det vigtigt at sikre en ydelsesbeskrivelse, der i videst muligt omfang flugter med markedets standarder, og som derudover kun har aktiviteter, der er kritiske for myndigheden – for de vil typisk bære en synlig meromkostning. Hardware udgør en betydelig del af den samlede omkostning, og derfor har det stor betydning, om der er tale om drift på leverandørens hardware eller egen hardware.
Omkostningsområder
|
|
Valgmuligheder
Faktor
|
Muligheder |
Betydning |
Teknologi |
SSD, SAS, SATA eller et mix |
Jo dyrere teknologi, jo højere vil prisen være. Dyrest er SSD, dernæst SAS og så SATA. |
Ydelsens standardelementer
Aktiviteterne med rød skrift bidrager mest til den samlede omkostning og udgør tilsammen over 50 % af den samlede omkostning. Aktiviteterne markeret med (S) relaterer sig til sikkerhed. |
Service management
|
System management
|
Vedligeholdelse
|
Værktøj
|
Ejerskab
|
SLA´er
Åbningsvinduet angiver det tidsrum, hvor leverandøren garanterer, at storagen er tilgængelig. Dette kan f.eks. være 10 timer om dagen i ugens fem arbejdsdage eller 24 timer i døgnet syv dage om ugen.
Tilgængeligheden bliver målt som storagens tilgængelighed i procent af det lovede servicevindue. Dette er typisk i et interval fra 98 % til 99,9 %.
Den højeste SLA er typisk mellem 1,2 og 2,0 gange dyrere end den laveste SLA.
Hardware
Hardware omfatter storage arrays, tilhørende controllers, rackskabe, kabling, kølingsudstyr, brandslukningsudstyr, UPS, datacenter-netværkskomponenter, og perifære enheder, der er nødvendige for at varetage normal storagedrift.
Software
Alle faktiske omkostninger til software, der anvendes i forbindelse med den almindelige drift af storage. Dette omfatter alt storagesoftware, overvågning og datacenter-systemer, antivirus, firewall og andre centrale sikkerhedssystemer, der alle er nødvendige for den generelle drift. Omkostningerne omfatter ikke middleware, databaser eller systempakker udviklet internt eller købt eksternt til en specifik brugergruppe.
Andre omkostninger
Andre omkostninger omfatter alle relevante forbrugsstoffer som bånd og andre backupmedier, forbrugsstoffer til nødstrøm og brandsikring (diesel og halon) med mere.
Netværk
Netværk omfatter drift af decentralt netværk, og omfatter derfor ikke datacenternetværk som er medregnet i eksempelvis server og storage.
Netværk er en central del af slutbrugernes oplevelse, og derfor vil der typisk være høje krav til SLA’er for netværk.
Hardware udgør en betydelig del af den samlede omkostning, og derfor har det stor betydning, om der er tale om drift på leverandørens hardware eller egen hardware. Det samme gør sig gældende for de serviceaftaler, som er knyttet op på hardwaren.
Omkostningsområder
|
|
Valgmuligheder
Faktor |
Muligheder |
Betydning |
Hardware typer |
8 port, 12 port, 24 port osv. |
Størrelsen på komponenterne har direkte indvirking på prisen. Jo flere porte, des højere pris. |
Lokationer |
Den geografiske spredning |
Stor geografisk spredning på mange små lokationer vil alt andet lige være dyrere end lille geografisk spredning. |
Ydelsens standardelementer
Aktiviteterne med rød skrift bidrager mest til den samlede omkostning og udgør tilsammen over 50 % af den samlede omkostning. Aktiviteterne markeret med (S) relaterer sig til sikkerhed. |
Management
|
Vedligeholdelse
|
Hardware
|
SLA´er
Åbningsvinduet angiver det tidsrum, hvor leverandøren garanterer, at netværket er tilgængeligt. Dette vil typisk være 24 timer i døgnet syv dage om ugen for netværk.
Tilgængeligheden bliver målt som netværkets tilgængelighed i procent af det lovede servicevindue. Dette er typisk i et interval fra 99 % til 99,9 %.
Hardware
Hardware omfatter omkostninger til komponenter som eksempelvis routers, switches, APs.
Software
Software i forbindelse med netværk inkluderer software til network management (for eksempel Netview) og målinger (for eksempel NetSpy og Openview). Desuden omkostninger til routermanagement-software.
Workstation/End-user
Det distribuerede miljø omfatter arbejdsstationer (desktop- og laptop-pc’er) samt tynde klienter. Workstation kan være den største omkostning i en driftsaftale, men er direkte afhængig af myndighedens størrelse, da omkostningerne til workstation typisk skalerer direkte med antallet af brugere.
Hardware er en betydelig komponent for workstation, og den samlede omkostning afhænger derfor meget af, om hardwaren er inkluderet i ydelsen (enten som leasing eller via anden ordning), eller om blot managementdelen af servicen købes.
For workstation findes der typisk også mange forskellige servicesnit, og det er muligt at tilkøbe dele af ydelse og levere resten eksempelvis internt. Der vil også være eksempler på multisourcing setup, hvor eksempelvis én leverandør står for hardware, én leverandør står for images osv.
Omkostningerne til hardware er også meget påvirket af, hvilken type hardware der vælges. Hardwaren skal typisk tilpasses slutbrugeren, og en myndighed med højere krav til hardwaren vil også medføre en betydelig meromkostning.
Omkostningsområder
|
|
Valgmuligheder
Faktor |
Muligheder |
Betydning |
Hardwaretype |
OSX eller Windows |
OSX vil typisk være dyrere i hardwarepris end Windows. |
Hardwarekonfiguration |
Low-end, standard eller high-end |
Den valgte hardwarekonfiguration for de enkelte pc’er vil have stor indvirkning på prisen. |
Ydelsens standardelementer
Ingen af de distribuerede miljøers aktiviteter bidrager i højere grad end andre til den samlede omkostning. Aktiviteterne markeret med (S) relaterer sig til sikkerhed. |
Asset management
|
Indkøbshåndtering
|
Break & Fix
|
IMACD - Inkluderer IMACD service koordination og IMACD service ydeevne (S)
|
Software distribution (S)
|
Service Management (S)
|
Hardware
|
SLA´er
Leveringstid er hvor lang tid, leverandøren har til at leverer en ny pc til en bruger. Det vil sige at leverandøren eksempelvis har fem arbejdsdage til at levere en ny pc til en bruger. Typisk vil SLA for dette ligge et sted mellem en og 10 dage.
Problem resolution time er et udtryk for, hvor lang tid leverandører har til at løse de mest kritiske problemer for brugerne. SLA’en vil typisk ligge mellem 4-8 timer.
Hardware
Hardware omfatter alle pc’er, hvad enten der er tale om bærbare eller stationære.
Alle komponenter, der indkøbes til opgradering af pc’er (memory, CPU’er, diskdrev) er også en del af hardwaren, og det gælder også tilkøbshardware som eksempelvis skærme, dockingstations, mus osv.
Software
Alle faktiske omkostninger til software, der anvendes i forbindelse med den almindelige drift af workstation. Dette omfatter eksempelvis SCCM-systemer eller andre softwareprodukter, som er nødvendige for den generelle drift.
Servicedesk
Servicedesk eller helpdesk er en organisatorisk enhed (fysisk eller virtuel), der sikrer en fordeling af indkomne telefonopkald, typisk med forespørgsler indenfor et eller flere specifikke områder.
Servicedesk kan afhængigt af myndighedens størrelse være en meget betydelig del af omkostningerne.
Servicedesk-ydelsen leverer brugersupport på en række veldefinerede it-områder frem til det punkt, hvor brugerens problem enten er løst eller må sendes videre til systemeksperter, der kan håndtere problemet og eventuelt rette fejlen. Denne sidste del er ikke omfattet af servicedesken, men derimod af teknisk service for de enkelte teknologiområder.
Under servicedesk skelnes typisk mellem førstelinje- og andenlinje-support. Førstelinje-support er de personer, brugerne henvender sig til. Førstelinje-support skal kunne håndtere alle problemer, som har at gøre med den “normale” brug af systemet. Her hjælpes en bruger, der ikke kan finde ud af at løse en given opgave i systemet. Problemer, som kræver dybere systemviden, håndteres som andenlinje-support. Her sidder eksperter indenfor de enkelte af systemets områder, som kan hjælpe med at løse egentlige systemfejl og komplicerede problemer. Første- og andenlinje-support kan sources forskelligt.
Omkostningsområder
|
|
Valgmuligheder
Faktor |
Muligheder |
Betydning |
Sprog |
Dansk, engelsk, andre sprog |
Krav om dansktalende ressourcer vil typisk have stor indflydelse på prisen, da dansktalende ressourcer ikke vil kunne leveres fra andre lande. |
Servicesnit |
1. eller 2. level |
På servicedesk er det vigtigt at klarlægge, hvor langt det ønskes at leverandøren skal levere service. Jo større omfang, jo større omkostninger. |
Afregningsmetrik |
Per kald/ticket, per bruger |
Afhængigt af hvor mange kald/tickets, der bliver genereret per bruger, bør der tænkes i hvilken metrik, der mest fordelagtigt kan afregnes efter. |
Ydelsens standardelementer
Ingen af servicedesks aktiviteter bidrager i højere grad end den anden til den samlede omkostning. Aktiviteterne markeret med (S) relaterer sig til sikkerhed. |
Desktop support (S)
|
Brugeradministration (S)
|
SLA´er
Åbningsvinduet angiver det tidsrum, hvor leverandøren garanterer, at servicedesken er tilgængelig. Dette kan f.eks. være 10 timer om dagen i ugens fem arbejdsdage eller 24 timer i døgnet syv dage om ugen.
First time resolution er et mål for, hvor mange kald/tickets, der løses ved første kontakt. Dette mål kan fastsættes i kontrakten for at sikre, at leverandøren har tilstrækkelig kvalificeret personale til at løse en stor andel af kald/tickets ved første kontakt.
Problem resolution time er et mål for, hvor lang tid leverandøren har til at løse de mest kritiske incidents. Dette vil typisk være et sted mellem fire og otte timer for incidents med kritikalitet 1.
Hardware
På servicedesk vil der kun i begrænset omfang indgå hardware. Det kan være særlige telefonisystemer eller andre komponenter, der indgår i leverancen af servicedesken, men som udgangspunkt vil hardware være en mindre post.
Software
Alle faktiske omkostninger til software, der anvendes i forbindelse med den almindelige drift af servicedesk. Dette omfatter eksempelvis ITSM-systemer eller andre softwareprodukter, som er nødvendige for den generelle drift.
Databasedrift
Databasedrift vil i nogle kontrakter udgøre en betydelig del af den samlede driftsaftale, og det vil derfor være vigtigt at kigge på, om setupet er optimeret. Databasedrift er en ren managementydelse, og licenserne til databaserne er derfor ikke inkluderet i driftsprisen. Det er derfor vigtigt at kigge på licenserne særskilt for at sikre den rigtige pris på disse.
Dernæst er det vigtigt at sikre, at ydelsesbeskrivelsen, i videst muligt omfang flugter med markedets standarder, og som derudover kun har aktiviteter, der er kritiske for myndigheden.
Endelig skal det overvejes nøje, om database-setupet kan segmenteres, så f.eks. kritiske produktionsmiljøer med fuld ydelse og høje SLA´er er på den ene side og test/udviklingsmiljøer med lave SLA´er og mere begrænset ydelses-snit er på den anden.
Omkostningsområder
|
|
Valgmuligheder
Faktor |
Muligheder |
Betydning |
Type |
Oracle, MsSQL, DB2 osv. |
Typisk vil Oracle og DB2 være dyrere end SQL. |
Ydelsens standardelementer
Ingen af databasedrifts aktiviteter bidrager i højere grad end andre til den samlede omkostning. Aktiviteterne markeret med (S) relaterer sig til sikkerhed. |
Overvågning og rapportering (S)
|
Backup og restore (S)
|
Sikkerhedshåndtering og administration (S)
|
Håndtering af kapacitet og performance
|
Vedligehold af database
|
SLA´er
Åbningsvinduet angiver det tidsrum, hvor leverandøren garanterer, at databasen er tilgængelig. Dette kan f.eks. være 10 timer om dagen i ugens fem arbejdsdage eller 24 timer i døgnet syv dage om ugen.
Tilgængeligheden bliver målt som databasens tilgængelighed i procent af det lovede servicevindue. Dette er typisk i et interval fra 98 % til 99,9 %.
Den højeste SLA er typisk mellem 1,5 og 2,5 gange dyrere end den laveste SLA.
Software
Alle faktiske omkostninger til software, der anvendes i forbindelse med den almindelige drift af databaserne. Dette omfatter alle overvågning- og datacenter-systemer. Omkostningerne omfatter ikke middleware, databaselicenser eller systempakker udviklet internt eller købt eksternt til en specifik brugergruppe.
Applikationsdrift
Applikationsdrift udgør ofte en mindre del af den samlede driftsaftale, da applikationsdrift er en relativ snæver ydelse. Applikationsdrift omhandler kun driftselementet og indeholder derfor hverken vedligehold eller udvikling.
Dernæst er det vigtigt at sikre, at ydelsesbeskrivelsen, i videst muligt omfang flugter med markedets standarder, og som derudover kun har aktiviteter, der er kritiske for myndigheden – for de vil typisk bære en synlig meromkostning.
Applikationsdrift er en ren management- og softwareomkostning, og der indgår derfor ikke omkostninger til hardware.
Endelig skal det overvejes nøje om applikations-setupet kan segmenteres, så f.eks. kritiske produktionsmiljøer med fuld ydelse og høje SLA´er er på den ene side og test/udviklingsmiljøer med lave SLA´er og mere begrænset ydelses-snit er på den anden.
Omkostningsområder
|
|
Ydelsens standardelementer
Ingen af applikationsdrifts aktiviteter bidrager i højere grad end andre til den samlede omkostning. Aktiviteterne markeret med (S) relaterer sig til sikkerhed. |
Overvågning og rapportering (S)
|
Backup og restore (S)
|
Håndtering af kapacitet og performance
|
Administration og patch management (S)
|
SLA´er
Åbningsvinduet angiver det tidsrum, hvor leverandøren garanterer, at applikation er tilgængelig. Dette kan f.eks. være 10 timer om dagen i ugens fem arbejdsdage eller 24 timer i døgnet syv dage om ugen.
Tilgængeligheden bliver målt som applikationens tilgængelighed i procent af det lovede servicevindue. Dette er typisk i et interval fra 98 % til 99,9 %.
Den højeste SLA er typisk mellem 1,5 og 2,5 gange dyrere end den laveste SLA.
Software
Alle faktiske omkostninger til software, der anvendes i forbindelse med den almindelige drift af applikationerne. Dette omfatter alle overvågnings- og datacenter-systemer. Omkostningerne omfatter ikke middleware, databaser eller systempakker udviklet internt eller købt eksternt til en specifik brugergruppe.
Mainframedrift
Mainframeaftaler er typisk meget omkostningstunge. En mere detaljeret indsigt i, hvordan leverandører afregner mainframedrift og -vedligehold, kan hjælpe til at forstå costdriverne i en mainframe-driftsaftale.
Overpriser vil typisk være drevet af manglende indsigt i forbrugsmønstre, uklarhed omkring kapacitetsopgørelsen og behovet for prisdifferentiering mellem de forskellige kapacitetstyper.
Det er derfor vigtigt, at prioritere for at sikre de fornødne basiskompetencer for de ressourcer, der skal modtage og kontraktstyre mainframeleverancen.
Alt for mange kunder er ikke tilstrækkeligt klædt på til at håndtere den løbende dialog om optimering af såvel økonomi som performance. Det gælder især for kunder med meget enkle afregningsmetrikker, der potentielt kunne spare mellem 15 og 45 procent af den totale MIPS-betaling (Million Instructions Per Second) ved at skrue på en række af håndtag.
Omkostningsområder
|
|
Den typiske måde at beregne en pris for mainframedrift på er fortrinsvist at samle eller ’bundle’ servicen afregnet efter antal MIPS, DASD (disk storage) og Tape (backup). Prisenheden er således en loaded pris, der dækker alle driftsaktiviteterne fra mainframeleverandøren.
Denne “bundling” og loadede enhedspris, der inkluderer en række aktiviteter, betyder dog begrænset transparens, og stiller krav til myndighedens forståelse af scope for den indeholdte ydelse samt de tekniske software-/hardwarekomponenter. Kun via en nedbrydning af den samlede ydelse kan der foretages en meningsfuld vurdering af prisniveau.
Software
Software udgør i langt størstedelen af mainframekontrakter den største omkostningspost i den samlede mainframepris. Omkostninger til software vil typisk udgøre mellem 40 og 75 procent af den samlede MIPS-pris, afhængigt af det specifikke softwarelag, der er indeholdt i servicen.
Softwaredelen sætter således rammen for omkostningsniveauet og medfører en række kommercielle afhængigheder til det fysiske setup. Derfor vil de fleste optimeringstiltag ske under hensyntagen til, hvordan det påvirker den samlede softwareportefølje.
Det anbefales, at kunder både er bevidste om, hvilken software der er installeret på deres mainframe, og er opdateret om lancering af nye, mindre omkostningstunge, softwarealternativer. En løbende dialog med leverandøren bør desuden tilstræbes for at “hjælpe” med at hjemtage besparelser på software ved at udvise fleksibilitet i forhold til softwarevalg i det omfang, det kan lade sig gøre, Det bør også tilstræbes at være opmærksom på, om leverandøren selv foretager ændringer i softwaresammensætningen. Eventuelle besparelser, der hentes af leverandøren, bør du som kunde få del i, hvis det betyder ændringer af de vilkår, der ligger til grund for aftalens prissætning.
Den konkrete softwarepakke i den enkelte driftsydelse varierer betydeligt, men kan primært kategoriseres i henholdsvis basissoftware fra IBM og tredjepartssoftware.
IBM-basissoftware udgør en stor andel af den samlede omkostning, men bliver typisk afregnet forskelligt, og er i varierende omfang forbrugsafhængigt. Prisen for MIPS vil bl.a. variere betydeligt alt efter, hvilken IBM-software der er tale om, samt på hvilken partition af mainframen (LPAR) den afvikles.
Tredjepartssoftware følger generelt en enklere afregningsmodel, hvor det samlede antal MIPS på LPARs for det pågældende produkt ofte vil skulle licenseres fuldt ud frem for at blive afregnet efter det faktiske forbrug.
Hardware
Med få undtagelser ejer kunder ikke selv mainframes, men køber et “hjørne” af en leverandørs samlede mainframeinstallation i form af en eller flere logiske partitioner (LPAR). Det betyder, at kunder med outsourcet mainframedrift typisk vil have omkostninger knyttet til afskrivning, vedligehold og housing af hardware, hvilket vil blive afholdt som en del af MIPS-prisen.
Da den underliggende hardwareomkostning kan være betydelig, er det centralt, hvilken type af hardware ens mainframeapplikationer driftes på. De samlede hardwareomkostninger vil typisk udgøre mellem 12 og 20 procent af en samlet mainframekontrakt.
Hardwaredelen af en samlet MIPS-pris opgøres i henhold til en række MIPS-ratingtabeller (Watson, LSPR), der danner udgangspunkt for betaling til hardwareproducenten. Kunder, der ikke har foretaget eller oplevet “hardware-refresh” og fortsat afvikler drift på ældre mainframes, vil ved en opgradering typisk opleve markante performanceforbedringer i form af lavere responstid og lavere MIPS-forbrug.
Det er i forhold til omkostningsniveauet for hardware vigtigt at være særligt bevidst om følgende primære elementer:
Generationen af mainframe har betydning for den samlede omkostning for hardware både i forhold til hvilke rabatter, der er gældende, og i forhold til afledte omkostninger til software, vedligehold etc.
Andelen af hardwareafskrivning, som kunden ender med at betale for, er en funktion af leverandørens udnyttelsesgrad af maskinen, hvor en lav udnyttelsesgrad vil betyde et generelt højere omkostningsniveau for leverandørens kunder.
Økonomiske gevinster ved hjælp af særlige processorer 'specialty engines'. Udover de almindelige “general purpose”- processorer (GP), der kan beregne alle typer mainframetransaktioner, findes der en række såkaldte ’specialty engines’, som har til formål at nedbringe den samlede omkostning på mainframedriften. Disse processorer kan afvikle specielle transaktionstyper til en stærkt reduceret softwareomkostning.
Management
Mainframekunder har typisk begrænsede interne mainframekompetencer til varetagelse af driftsaktiviteter. Det er dyre og knappe kompetencer som eksempelvis COBOL-ressourcer. Bl.a. derfor vælger mange kunder at outsource hele mainframeydelsen til en leverandør, der som en del af servicen håndterer facility mangement, kapacitetsplanlægning, drift, overvågning, batchplanlægning og databasedrift. Det ses ligeledes ofte, at både mainframeapplikationsdriften og -vedligeholdelsen også håndteres inden for aftalens scope.
En anden version ses hos store og mellemstore kunder, der aftager housing, kapacitet og basal overvågning fra leverandøren, men selv har kompetencer til at varetage drift af infrastruktur, database, applikationer, batch og vedligehold og i øvrigt anvender konsulentbistand til specialopgaver.
En struktureret overvågning af kapacitetsforbrug og løbende dialog med leverandøren om mulig tuning af drift, batchjobs og databaseopgaver kan føre til meget væsentlige økonomiske gevinster. Myndigheden bør derfor som led i leverandørstyringen opretholde interne kompetencer på mainframeområdet.
Andre omkostninger
Udover den rå driftsydelse, herunder omkostninger til software, hardware og management, er rammerne og omkostningen for leverancen i høj grad dikteret af kundens terms and conditions. Det er her vigtigt at gøre sig klart, at en række centrale vilkår, som eksempelvis hvordan servicen leveres, det samlede risikobillede og leverandørernes mulighed for konkurrencedygtig prissætning, spiller ind på den samlede TCO for en mainframeaftale. Krav til en bestemt fortolkning af lovgivning, f.eks. i forhold til krigsreglen eller krav til hvilke data, der skal forblive i Danmark, kan gøre det umuligt at løfte omkostningstunge opgaver som overvågning, fejlløsning og batchafvikling til nearshore- eller offshorelokationer – hvilket for de fleste leverandører er en inkorporeret del af basisleverancen.
Kunder bør gøre sig klart, i hvilket omfang offshoring af driften er mulig, da leverance af overvågnings- og driftsopgaver med nearshore- eller offshoreressourcer typisk kan bidrage med en reduktion af den samlede driftspris på op til 10 procent. Hav en afklarende dialog med leverandøren om, hvilke krav der er kritiske i forhold til intern compliance, og hvilke der kan være fleksibilitet omkring.
[Indsæt tekst her eller slet (max. 800 anslag)] |
xxxxx.xx |