Rapport. Ändamålsenlig drift

Transkript

1 Rapport Ändamålsenlig drift

2 Sida 2 av 28 Innehåll 1 INLEDNING Syfte och innehåll Applikationsdrift och serverdrift SAMMANFATTNING FÖRUTSÄTTNINGAR Konsortiets ansvar Preliminär tidplan och beslutsordning Överlämning och produktionssättning Kravunderlag Upphandling och avrop Slutsatser NULÄGE OCH OMVÄRLD Ladok IT-drift på UHR och CSN IT-drift inom stat, landsting och kommun Leveransformer Slutsatser KRAV OCH BEHOV Verksamhetens krav Produktens krav Krav på driftleverantörerna Slutsatser DRIFT OCH SUPPORT Avgränsningar Förslag på definitioner ALTERNATIVA LÖSNINGAR FÖR DRIFT AV NYA LADOK Scenarios Slutsatser REKOMMENDATION Avgränsningar Rekommendation Beslutsalternativ Motivering GENOMFÖRANDE... 23

3 Sida 3 av Beslutsalternativ A Beslutsalternativ B RISKER OCH KONSEKVENSER För lärosätena För konsortiet För driftställena... 24

4 Sida 4 av 28 Denna rapport gick ut till samtliga medlemmar inom Ladokkonsortiet. Ett antal förtydliganden och mindre förändringar har gjorts innan förslaget i rapporten beslutades på Ladokstämman Observera att rapporten inte har uppdaterats med beslutade förändringar, de finns dokumenterade här. 1 Inledning Ladoksystemet ägs och förvaltas idag av Ladokkonsortiet medan varje lärosäte själv ansvarar för drift och förvaltning av sin installation av Ladok. Nästa generation av studieadministrativt systemstöd är under utveckling i Ladok3-projektet. Det nya systemet kommer att användas som en gemensam installation vilket ställer krav på ett centralt ansvar för driften av Ladok. Projektet Förnyad förvaltning har ett uppdrag att ta fram en rekommendation för framtida drift av Ladok. Arbetet drivs som ett delprojekt, Ändamålsenlig drift. 1.1 Syfte och innehåll Syftet är ta fram en rekommendation för den framtida driften av Ladok som tillsammans med förslaget på förvaltningsorganisation ska utgöra beslutsunderlag för konsortiets styrelse och stämma. Dokumentet ska beskriva förutsättningar, krav och behov beskriva driftsparter samt deras ansvarsområden beskriva konsekvenserna för lärosätena, befintliga driftställen och konsortiet ge en rekommendation för hur applikations- och serverdriften ska realiseras inklusive tillvägagångssätt och tidplan Dokumentet skickas till lokala systemägare för Ladok och IT-chefer som ges möjlighet att lämna synpunkter på rekommendationen. Dessa sammanställs och delges tillsammans med rekommendationen till konsortiet. Övriga primära målgrupper är förvaltningschefer och Ladokansvariga. Kostnadsuppskattning för applikations- och serverdrift inklusive kostnader för förvaltningsorganisationen beskrivs i ett särskilt dokument. 1.2 Applikationsdrift och serverdrift I kapitel 6.2 ges utförligare beskrivningar på applikations- och serverdrift. Med applikationsdrift avses driftrelaterade arbetsuppgifter kopplat till applikationer och andra programvaror som är kopplade till dessa. Serverdrift omfattar driftleveranser för kontinuerlig drift och övervakning av serverresurser och lagringsmiljöer, säkerhetskopiering/återställning inklusive långtidsbackup och hantering av teknisk kommunikation. Det är vanligt att dela på applikationsdrift och serverdrift för att det krävs olika kompetenser för de olika områdena. Serverdrift är hantering av teknik där storskalig drift är kostnadseffektiv. Många leverantörer bygger upp stora datacenter och sköter den tekniska plattformen åt många kunder. Det innebär att det oftast är billigare att köpa sådana tjänster på konkurrensutsatt marknad.

5 Sida 5 av 28 Applikationsdrift kräver verksamhetsnära kunskap. Med verksamhets- och systemkännedom upparbetas en kompetens som ger ett kvalitativt stöd till kärnverksamheten. Andra fördelar med att dela på de olika områdena är att driftleverantörena kan fokusera på sitt och bli bra på det. 2 Sammanfattning Den verksamhetsnära förvaltningen av Ladok kommer fortsättningsvis att hanteras av konsortiet. Konsortiet kommer även att ansvara för både serverdrift och applikationsdrift samt 2nd line support för den gemensamma installationen av Ladok. Projektet Förnyad förvaltning ansvarar för att ta fram den nya förvaltningsorganisationen som måste vara på plats innan den första leveransen från Ladok3-projektet sker. En upphandling av serverdrift av Ladok kommer att bli en upphandling över tröskelvärdet EUR som medför att upphandling ska göras i EU-området. Ett driftavtal bör vara förhandlat och klart Q för att kunna ta emot den första leveransen till förvaltningsorganisationen Q Ett avrop från Kammarkollegiets ramavtal kräver att en förnyad konkurrensutsättning görs. En upphandling kräver att förfrågningsunderlaget är väl underbyggt och att kraven är tydliga. En tillräckligt detaljerad kravspecifikation kan inte tas fram förrän efter produktsättning av tredje leveransen Q Med hänvisning till enkätsvar och diskussioner i projektets olika forum dras slutsatsen att lärosätena är eniga om att applikationsdriften och den centrala supportfunktionen ska hållas inom högskolesektorn. För att nå i mål till leverans hösten 2014 finns följande alternativ: Serverdrift på ett befintligt driftställe på kort sikt, sedan upphandling/avrop Upphandling/avrop snarast möjligt. Ändra Ladok3-projektets uppdrag till att omfatta drift av applikationen på kort sikt eller ge en annan part driftsuppdraget på kort sikt Rekommendationen är att serverdriften bör utföras av något av de befintliga driftställena och applikationsdriften på ett annat fram till och med att produkten är så pass klar att det finns bra kravunderlag för en upphandling. Med drift på två olika ställen är det lättare att på sikt upphandla serverdrift. Förvaltningsorganisationen rekommenderas att planera för en upphandla serverdrift i samband med att produkten slutlevereras. Möjligheten och konsekvensen av att upphandla serverdriften som en molntjänst bör beaktas och utredas särskilt. Skillnaden mellan traditionellt upphandlad IT-drift och molnbaserad IT-drift bör tydliggöras. Förvaltningsorganisationen bör tillsammans med de båda driftleverantörerna vidareutveckla och tydliggöra beskrivningarna av applikations- och serverdrift för att underlätta upphandlingen. Detta kan göras genom att kontinuerligt följa bland annat UHR och CSN utvecklingsarbete kring drift. Lärosätena kommer inte att påverkas av vilka som levererar applikations- och serverdrift. En central supportfunktion som endast kommer att tillhandahålla 2nd line support medför att alla lärosäten, precis som idag, tillhandahåller en lokal supportfunktion för sina studenter och personal.

6 Sida 6 av 28 För de befintliga driftställena innebär rekommendationen att ett driftställe endast kommer att ha kvar driften för gamla Ladok under övergångsperioden. För konsortiet innebär rekommendationen att beställarkomptensen för driftfrågor måste tillföras. Det kan omfatta krav på strategisk teknisk kompetens, omvärldsbevakning, outsourcing, upphandling, koordinering, avtal mm. 3 Förutsättningar Här presenteras de förutsättningar som Ändamålsenlig drift har utgått ifrån i denna rapport. I projektdirektivet för Förnyad förvaltning står det: Målet är att uppdraget ska resultera i en tydlig och väl fungerande förvaltning som är förankrad hos konsortiets medlemmar, och som säkrar att investeringen i Ladok3- projektet kan tas emot på ett så bra sätt som möjligt vid övergången till förvaltning. Det ska också säkerställas att lösningen kan fungera över lång tid därefter. Ägande- och associationsform med nationell samverkan inom högskolesektorn i konsortieform ska inte övervägas inom ramen för detta projekt, inte heller Konsortiets organisatoriska hemvist vid Umeå universitet. - Inte heller VHS-samarbetet, där Konsortiet använder VHS som huvudansvarig teknikleverantör för Ladokutvecklingen, ska omprövas mitt under Ladok3-projektet, detta för att minimera riskerna i projektet. (Ett nytt huvudavtal för perioden tecknades i december 2011.) Dessa områden kommer dock att vara intressanta att belysa i senare projekt. I projektplanen för Förnyad förvaltning står det: Projektet Förnyad förvaltning ansvarar för att ta fram den nya förvaltningsorganisationen som måste vara på plats innan den första leveransen från Ladok3-projektet sker. 3.1 Konsortiets ansvar Den verksamhetsnära förvaltningen av Ladok kommer fortsättningsvis att hanteras av konsortiet. I arbetet med att föreslå en framtida ändamålsenlig drift har det förutsatts att konsortiet ska ansvara för både serverdrift och applikationsdrift för den gemensamma installationen av Ladok. För att minimera konsortieorganisationen kommer operativa arbetet att utföras av andra parter. Andra alternativ för det centrala ansvaret för drift av Ladok har inte utretts. 3.2 Preliminär tidplan och beslutsordning Nedan presenteras de milstolpar för både Förnyad förvaltning och Ladok3 som har stor betydelse för den framtida driften. April 2013 Maj 2013 Maj 2013 Aug 2013 Rapporten skickas ut för synpunkter Sammanställning av inkomna synpunkter Information om förvaltningsorganisation och ändamålsenlig drift (konsortiestämma) Beslut om förvaltningsorganisation och ändamålsenlig drift (styrgrupp förnyad förvaltning)

7 Sida 7 av 28 Sep 2013 Beslut om förvaltningsorganisation och ändamålsenlig drift (konsortiets styrelse) Okt 2013 Beslut om förvaltningsorganisation och ändamålsenlig drift (konsortiestämma) Dec 2013 Kravspecifikation för applikations- och serverdrift klar Jun 2014 Avtal klart med driftleverantörer Nov 2014 Överlämning av del 1 från Ladok 3 till förvaltningsorganisationen Okt 2015 Produktionssättning del 1 Nov 2015 Överlämning av del 3 från Ladok 3 till förvaltningsorganisationen Okt 2016 Produktionssättning del Överlämning och produktionssättning Den första leveransen från Ladok3-projektet till förvaltningsorganisationen är beräknad till november Produktionssättningen för lärosätena beräknas att starta oktober Fram till produktionssättning av del tre kommer nya Ladok mest att användas för utdata. Efter produktionssättning av del tre i oktober 2016 kommer den stora användningen igång. Därefter kan mätningar av belastning och användning att kunna påbörjas. Detta förutsätter att motsvarande test-, acceptans- och driftmiljöer ska vara på plats i god tid före den tidpunkten för att både förvaltning och lärosätena ska kunna förbereda sig för leveranser och produktionssättning. 3.4 Kravunderlag Nya Ladok är en helt nyutvecklad produkt. Detta innebär att ett tillräckligt detaljerat kravunderlag för applikations- och serverdrift inte kan levereras från projektet förrän en tid efter produktionssättningen av den tredje leveransen. 3.5 Upphandling och avrop Lagen om offentlig upphandling (LOU) Statliga myndigheter ska göra upphandlingar enligt LOU. Det finns olika upphandlingsformer som beror på vilken omfattning den tjänst som ska upphandlas har. För upphandling över tröskelvärde EUR, ska denna göras i EU-området. Vid en upphandling kan även driftställena lämna in anbud Ramavtalsområde IT-driftstjänster 2010 Ett alternativ är att avropa ett ramavtal för IT-drift. Kammarkollegiets ramavtalsområde IT-driftstjänster 2010 består av fyra delområden: Påplatsdrift 2010, Hosting 2010, Helhetsdrift 2010 och Användarnära funktioner För serverdrift av Ladok är delområde Hosting 2010 relevant. Avtalet kräver en förnyad konkurrensutsättning vilket innebär att ett förfrågningsunderlag ska upprättas och skickas ut till samtliga ramavtalsleverantörer. Hosting kan levereras som en molntjänst. 3.6 Slutsatser Den verksamhetsnära förvaltningen av Ladok kommer fortsättningsvis att hanteras av konsortiet. Konsortiet kommer även att ansvara för både serverdrift och applikationsdrift

8 Sida 8 av 28 för den gemensamma installationen av Ladok. Det operativa arbetet ska utföras av andra parter. Enligt tidplanen förutsätts att test-, acceptans- och driftmiljöer ska vara på plats i god tid före första leveransen för att både förvaltning och lärosätena ska kunna förbereda sig för att ta emot leveransen. En upphandling av drift av Ladok kommer troligen att bli en upphandling över tröskelvärdet EUR. En upphandling kräver att förfrågningsunderlaget är väl underbyggt och att kraven är relevanta. Eftersom mätningar av belastning och användning inte kan påbörjas förrän efter produktionssättning av del tre i oktober 2016 kan inte en komplett kravspecifikation tas fram inför överlämning av den första leveransen. Ett avrop från Kammarkollegiets ramavtal kräver också en komplett kravspecifikation eftersom avtalet kräver en förnyad konkurrensutsättning. 4 Nuläge och omvärld Ladokkonsortiet, Universitets- och högskolerådet (UHR) och Centrala Studiestödsnämnden (CSN) är tre organisationer som ansvarar för olika nationella system för studieadministration. 4.1 Ladok Ladokkonsortiet ansvarar för förvaltning och vidareutveckling av Ladok. Förvaltningsorganisationen är uppdelad i två delar, verksamhetens förvaltningsorganisation och den tekniska förvaltningsorganisationen. Konsortiet köper tjänster kring Ladoks tekniska förvaltning och nyutveckling av UHR. Operativt arbete i den tekniska organisationen utförs av Enheten för IT-stöd och systemutveckling vid Umeå universitet (ITS) på uppdrag av UHR. I dagsläget ansvarar konsortiet för den verksamhetsnära förvaltning inklusive vidareutveckling samt teknisk förvaltning av Ladok. Tjänster kring den tekniska förvaltningen köps idag av UHR. Konsortiet har i dagsläget inget ansvar för driftmiljön. Det innebär att det kan finnas skillnader mellan utvecklingsmiljön och driftmiljön samt mellan olika driftmiljöer. Konsortiet använder UHR som huvudansvarig teknikleverantör i utvecklingen av Ladok. Samarbetet regleras i ett huvudavtal som gäller till Det är beslutat av Ladoks styrelse att samarbetet med UHR inte ska omvärderas medan Ladok3-projektet pågår för att minimera riskerna i projektet. När Ladok3-projektet avslutats bör vidareutvecklingen av Ladok ha utvärderats Ladokdrift Varje lärosäte tecknar egna avtal med ett driftställe för drift av den egna installationen av Ladok. Driften för ett eller flera lärosäten sker vid ett av Ladokkonsortiets tre certifierade driftställen. Lunds Universitet ansvarar för drift åt 15 lärosäten, Uppsala Universitet 17 lärosäten och Umeå Universitet 6 lärosäten.

9 Sida 9 av 28 Lund Umeå Uppsala Blekinge tekniska högskola Polishögskolan Uppsala universitet Högskolan i Borås Mittuniversitetet Ersta-Sköndal högskola Chalmers tekniska högskola Luleå tekniska universitet Högskolan i Jönköping Göteborgs universitet Umeå universitet Högskolan Dalarna Högskolan i Halmstad Konstfack Stockholms universitet Högskolan i Skövde Dans och cirkushögskolan Örebro universitet Karlstads universitet Kungliga Musikhögskolan Mälardalens högskola Högskolan Kristianstad Lunds universitet Malmö högskola Högskolan Väst Linnéuniversitetet Stockholms Dramatiska högskola Teologiska högskolan Kungliga tekniska högskolan Karolinska institutet Linköpings Universitet Försvarshögskolan Gymnastik och Idrottshögskolan Högskolan på Gotland Högskolan i Gävle Röda korset Sophiahemmet Södertörns högskola Sveriges lantbruksuniversitet De flesta lärosäten köper idag både applikationsdrift och serverdrift av sin driftleverantör. Det finns ingen gemensam definition av driftsformerna men i de enskilda avtalen är åtaganden definierade. Driften kan bestå av: Mottagning av programleveranser från ITS Installation, lokal testning och driftsättning av leveranser Lokalt driftstöd till Ladokansvarig Distribution och mottagning av data från externa intressenter, t.ex. CSN, SCB, UHR Lokal felavhjälpning på nät- och klientutrustning Tekniskt databasunderhåll och applikationsdrift Installation och underhåll av övrig programvara Underhåll av serverplattformar Övervakning, manuell och/eller automatiserad Felrapportering Backuptagning

10 Sida 10 av Samarbete lärosäten och driftställen För att få en uppfattning om nuvarande samarbete mellan lärosäten och driftleverantörerna har en enkät skickats ut till lärosätena under november Av 39 medlemslärosäten har 29 svarat på enkäten. De flesta lärosäten har giltiga avtal (28 av 29) och regelbundna avstämningsmöten med driftleverantören (23 av 29). Två av tre lärosäten får återkoppling från sin driftleverantör runt överenskomna mål. Samtliga lärosäten svarar att de har tydliga kontaktvägar till driftleverantören för support/problem. Alla utom ett lärosäte har en namngiven kontaktperson för övergripande leveransfrågor. Som svar på vad som saknas i nuvarande samarbete med driftleverantörerna har endast sex lärosäten uppgivit att något saknas. Det som tagits upp är snabbare svarstider för anmälda ärenden, bättre uppföljning och återkoppling kring tjänsten samt bättre samarbete med de lokala IT-avdelningarna Kostnader I enkäten ställdes en fråga om vilken årskostnad som lärosätet uppskattar driften till. För de 27 lärosäten som svarat i enkäten uppskattas kostnaden för drift av nuvarande Ladok till i genomsnitt kr/år. En uppskattning av den totala driftkostnaden för nuvarande Ladok blir då för 39 lärosäten 39* = 18,7 Mkr. 4.2 IT-drift på UHR och CSN UHR Universitet- och högskolerådet genomför på uppdrag av universitet och högskolor antagningar till högre utbildning via en e-tjänst. UHR är systemägare till lärosätenas gemensamma antagningssystem NyA, den nationella databasen för gymnasiebetyg och systemet Högskoleprovanmälan som används för anmälan och administration av anmälningar till högskoleprovet. Drift av NyA sker hos en extern leverantör medan drift av den nationella databasen för gymnasiebetyg samt Högskoleprovanmälen sker internt hos UHR. UHR förvaltar Ladok på uppdrag av konsortiet. UHR har kompetens och erfarenhet av att upphandla drift och hantera driftsfrågor kring nationella system och är därför en möjlig part att hantera driften av det framtida Ladok. Drift av NyA UHR har upphandlat drift för NyAs produktionstestmiljö och acceptanstestmiljöer av en extern leverantör som ansvarar för systemdrift samt installation av mjukvara. UHR har uppskattat att ca tim/år läggs ned för applikationsdrift för NyA vilket motsvarar drygt 7 årsarbetare. Utbildningsmiljö och en testmiljö för lärosätena driftas av ITS som också ansvarar för felrättning och vidareutveckling av NyA. UHR samarbetar med sin driftleverantör i gränssnittet applikations- och systemdrift. Felsökning görs många gånger gemensamt när problem inte direkt kan hänföras till applikation eller serverplattform. Relationen till driftleverantören är god. Samarbetsklimatet är bra och ambitionen är att löpande förbättra delar som inte fungerar optimalt. Driftleverantören har ett kundteam (en kundansvarig, en leveransansvarig samt en teknisk kontaktperson) som är primär kontakt för UHR i driftfrågor. Motparter till dessa roller finns på UHR där olika ärenden kan hanteras på olika nivå. Totalt är det ca personer hos driftleverantören som i varierande omfattning deltar i leveransen till UHR. Kvaliteten varierar i olika delar av leveransen där leveransen till produktionsdelarna har

11 Sida 11 av 28 en hög kvalitet. De perioder i verksamheten som skapar hög belastning på systemet genomlöps utan allvarliga störningar i systemet. Då acceptanstestmiljöerna är mycket viktiga för UHR och är att betrakta som produktionsmiljöer, uppstår ibland problem då driftleverantören inte förstår vikten av detta. Här finns ett förbättringsområde. Övriga förbättringsområden är/har varit: Kommunikation (Information om lagda beställningar, Återkoppling/proaktivitet) Kontinuitet avseende resurser (Ofta ny personal hos leverantören) Övervakning Även UHR systemdrift har ansvar för att förbättra vissa delar i rollen som beställare. För att befästa och tydliggöra samverkan inom avtalet har en samverkansmodell tagits fram. I denna specificeras vilka forum/möten som ska äga rum och med vilken frekvens. Det är möten med olika aktörer på strategisk, taktisk och operativ nivå. Beroende på forum kan både UHR och driftleverantören vara sammankallande. Det finns mycket att ta lärdom av i de relationer UHR har haft med driftleverantörer för NyA. Det är bl. a. viktigt att ha en klar bild av vad som förväntas av driftleverantören och utifrån det vara mycket tydlig i formuleringar i krav och avtalsskrivningar. Förväntningar kan vara både av ren teknisk karaktär - vad de faktiskt utför och med vilken kvalitet, men även hur relationen och samverkan ska fungera. Vidare är den egna interna organisationen i förhållandet mot driftleverantören viktig att tydliggöra CSN Centrala Studiemedelsnämnden använder systemet STIS, Studiestödets Information System, som stöd i sin kärnverksamhet. STIS är ett egenutvecklat stordatorsystem där serverdrift upphandlats hos en extern part. Driftleverantören ansvarar för hårdvara och servrar såsom uppgradering, backup, övervakning och återställning sker externt. Applikationsdrift, vidareutveckling och förvaltning av systemet sker internt hos CSN i en organisation med sammanlagt ca 60 medarbetare. CSN ansvarar själva för allt arbete kring webbapplikationerna och databasen. Support och felanmälan kring STIS sker till en service desk som sköts av den externa leverantören. Ärenden som rör applikationen hanteras av CSNs egen förvaltningsorganisation. Ärenden som rör infrastrukturen utreds tillsammans av CSN och driftleverantören. Det pågår förnärvarande en utredning kring service desk funktionen och hur den ska organiseras. Samarbetet med driftleverantören är gott och det råder sällan otydlighet i vem som ska hantera ett inkommande ärende. 4.3 IT-drift inom stat, landsting och kommun E-delegationen presenterade en förstudie 1. Förstudiens uppdrag var att identifiera och beskriva möjligheter till effektivisering av myndigheternas IT-drift samt att föreslå hur sådana lösningar kan utformas. Förstudien konstaterade att det finns en betydande effektiviseringspotential inom myndigheternas IT-drift. Ansatsen i rapporten var att varje myndighet har sin egen driftsorganisation. Slutsatsen blev att det är effektivare att endera dela på driftsresurser eller att outsourca den beroende på vad som ska driftas. 1 Effektiv IT-drift inom staten, Kammarkollegiet

12 Sida 12 av 28 I detta PM har ingen omfattande analys gjorts av hur IT-driften sker inom den offentliga sektorn. Det kan dock konstateras att högskolesektorn delvis har konsoliderat sin IT-drift och driver gemensamma utvecklingsprojekt. Exempel inom högskolesektorn är Ladok och Sunet. 4.4 Leveransformer Inom området drifttjänster används begreppet outsourcing för företeelsen att lägga över aktiviteter och ansvar på en leverantör. Leverantören levererar dessa aktiviteter som ITtjänster. Shared services är ett samlingsbegrepp för samutnyttjande av stödfunktioner inom en organisation eller mellan organisationer. Den samlade organisationen som svarar för att tillhandahålla dessa stödfunktioner, vanligen i form av paketerade tjänster, brukar benämnas Shared Service Center, SSC. Antalet definitioner av begreppet molntjänster är stort och det är svårt att hitta en helt ensad bild av vad molntjänster egentligen är. Engelska Wikipedia har ett kapitel om Cloud computing. Ett annat exempel på definition av molntjänster är den som Radar Group International tog fram i samband med att de fick i uppdrag av Kammarkollegiet att ta fram en rapport 2 angående användandet av molntjänster i offentlig sektor. Mer om olika leveransformer finns i Bilaga Slutsatser Både UHR och CSN har kompetens och erfarenhet av externa leverantörer av både applikations- och serverdrift. (UHR hanterar en del av applikationsdriften själva.) De utvecklar och följer upp sina relationer och avtal med leverantörerna kontinuerligt. Förvaltningsorganisationen för Ladok bör kontinuerligt följa deras utvecklingsarbete för att skapa en bra drift för Ladok. De slutsatser som E-delegationen har identifierat är inte direkt överförbar till driften av Ladok och lämnas därmed. Möjligheten att upphandla driften som en molntjänst bör beaktas och utredas särskilt. Skillnaden mellan traditionellt upphandlad IT-drift och molnbaserad IT-drift bör tydliggöras. En upphandling av molntjänster kräver förmodligen en särskild hantering och ställer andra krav på förvaltningsorganisationen. I Bilaga 1 finns ett resonemang beskrivet som kan användas som inledning till en utvärdering av molntjänster. 2 Radar Group Internationals rapport Användandet av molntjänster inom offentlig sektor, december 2009

13 Sida 13 av 28 5 Krav och behov Kraven och behoven kommer från både verksamhet och produkt. 5.1 Verksamhetens krav Verksamhetens krav på den nya driftorganisationen har samlats in via den enkät som gått ut till lärosätena. Följande slutsatser har dragits från enkätsvaren: Service och kompetens om Ladok är mest viktigt hos den framtida driftleverantören, men även pris och flexibilitet måste beaktas Möjlighet måste finnas att köpa utökat driftstöd under vissa perioder (beroende på vad som ingår i bastjänsten framöver) Det kan komma att finnas behov av att köpa andra tjänster från driftleverantören (beroende på vad nya Ladok ger för stöd) Det är viktigt att den nya förvaltningsorganisationen har snabb service och tätt samarbete med lärosätena vid behov av rättningar i databasen Det kommer att behövas centralt stöd kring REST gränssnitt/atom feeds Detta innebär att den leverantör som tillhandahåller applikationsdrift behöver kompetens om programvaran och verksamheten den stödjer. Med hänvisning till enkätsvaren och diskussioner i projektets olika forum dras slutsatsen att lärosätena är eniga om att applikationsdriften och den centrala supportfunktionen ska hållas inom högskolesektorn med följande motivering: Kompetensen om den studieadministrativa processen i relation till Ladok är strategisk Kompetens om Ladok och den verksamhet som systemet stödjer värderas högt av lärosätena Kompetens om systemet finns ej att köpa externt vilket är en följd av valet att egenutveckla Risken för att kompetensbrist uppstår är större ifall den köps externt än byggs upp inom högskolesektorn. 5.2 Produktens krav Nya Ladok är under utveckling i Ladok3-projektet. Hur det nya systemet byggs ställer krav på driften. Följande rekommendationer och krav på driftmiljön har identifierats av Ladok3-projektet: För att inte påverka prestandan negativt bör serverdriften vara på samma fysiska ställe. Placering av kopior av driftmiljöer för återställning kan ske på andra fysiska ställen än driftmiljön. Eftersom Ladok ska driftas som en gemensam installation innebär det också att de mjukvaruuppgraderingar som görs i systemet kommer att gälla alla lärosäten samtidigt. Ett antal driftmiljöer har identifierats och dimensionerats Icke-funktionella krav Ladok3-projektet har tagit fram icke-funktionella krav som ska beaktas vid utformning av kravspecifikation och driftavtal. Kraven är inte fastställda utan kan användas som riktvärden.

14 Sida 14 av Leveransflöden och driftmiljöer Nedanstående figur visar de olika stegen i leverans av nya versioner och små nödvändiga felrättningar samt lärosätenas beroenden. En utförligare beskrivning finns i dokumentet Kostnadsuppskattning förvaltning nya Ladok. Beroende på framtida ytterligare behov kan ovanstående flöde behöva kompletteras med fler miljöer. Produktionsmiljö Den miljö som den dagliga produktionen arbetar i. Personal och studenter. Innehåller uppföljningsmiljöer för lärosätena. Akuttestmiljö (verifikation/stagingmiljö) Används för att testa leveranser innan implementering i produktionsmiljö. Produktionslik. Utbildningsmiljö Utbildning av användare sker i denna miljö. Utbildare både på lärosäten och i förvaltningsorganisationen. Acceptanstestmiljö Här godkänner förvaltningsorganisationen nya leveranser. Här görs även prestandatester. Testmiljö befintlig version Den miljö som används av lärosätena för att testa rättningar, integrationer och felsökning för aktuell produktionsversionen. Testmiljö ny version Den miljö som används av lärosätena för att testa rättningar, integrationer och felsökning till ny version. Den MIT-miljö som sätts upp 2013 bör kunna övergå till denna miljö. Utvecklingsmiljöer Utvecklings-, test- och prestandatestmiljöer för utvecklarna vilka ska hanteras av utvecklingsorganisationen.

15 Sida 15 av Krav på driftleverantörerna För att kunna säkerställa en ändamålsenlig drift ska en tydlig kravspecifikation tas fram för de tjänster som en leverantör ska leverera. Den ska innehålla tydliga beskrivningar och upprättade SLA:er som möter verksamhetens och produktens krav. De leverantörer som ansvarar för drift av nuvarande Ladok system är certifierade avseende IT-säkerhetsaspekter. Framtida driftleverantör ska uppfylla dessa kriterier. Dessa kriterier anses grundläggande och kommer att finnas med som skallkrav i en upphandling/avtalsteckning. 5.4 Slutsatser Med lärosätenas höga krav på service och kompetens är rekommendationen att applikationsdrift och den centrala supportfunktionen ska hållas inom högskolesektorn. Arbetet med framtagning av kravspecifikationen för drift bör påbörjas under våren. 6 Drift och support Inför upprättande av driftorganisation är det nödvändigt att ha en gemensam definition av vilka tjänster som ska ingå i applikationsdrift respektive serverdrift samt hur den centrala supportfunktionen ska relateras till den lokala. E-delegationen har i sin rapport 3 tagit fram definitioner på drift. Där finns applikationsdrift, serverdrift, drift av lagring och utdatahantering. För att få fram nedanstående definition på serverdrift har e-delegationens definitioner för serverdrift, drift av lagring samt delar ur utdatahantering slagits samman och kompletterats. 6.1 Avgränsningar Katastrofhantering och behovet av kontinuitetsplanering har inte belysts i denna rapport. Kraven på kopierade miljöer och återställning är samma som idag. 6.2 Förslag på definitioner Förslagen är en utgångspunkt. Det finns anledning att vidareutveckla eller ändra innehållet allt eftersom projektet framskrider eftersom det finns arbetsuppgifter som kan utföras av båda driftleverantörerna. Det finns också anledning att bevaka hur UHR och CSN ska hantera sina driftfrågor framgent Applikationsdrift Med applikationsdrift avses driftrelaterade arbetsuppgifter kopplat till applikationer och andra programvaror som är kopplade till dessa. Applikationsdrift omfattar driftleveranser för installation, drift, underhåll och övervakning av applikationsprogramvara och relaterad middleware 4 samt databaser. Arbetet inom delområdet omfattar teknisk hantering (analys, planering, utförande/åtgärd, installation, konfiguration, support, felsökning och problemlösning, uppföljning, 3 Effektiv IT-drift inom staten, Kammarkollegiet 4 Termen middleware används för att beskriva olika produkter som fungerar som en länk mellan två program.

16 Sida 16 av 28 dokumentering, rapportering) av omfattade programvaror, hantering av körningar för bearbetning av stora datamängder och certifikatshantering samt manuella informationsuttag. I den tekniska hanteringen ingår hantering av relaterad IT-säkerhet. Vidare ingår även inköp. Arbetet beskrivs och styrs vanligen av processerna incidenthantering, problemhantering, ändringshantering, installation och konfiguration, prestanda- och kapacitetshantering samt styrning av leverantör Serverdrift Serverdrift omfattar driftleveranser för kontinuerlig drift och övervakning av serverresurser driftleveranser för kontinuerlig drift och övervakning av lagringsmiljöer (SAN 5 /disk) samt säkerhetskopiering/återställning inklusive långtidsbackup hantering av teknisk kommunikation (e-post, nätverk, brandväggar, DNS 6, extern kommunikation från systemet) Arbetet omfattar teknisk hantering (analys, planering, utförande/åtgärd, installation, konfiguration, support, felsökning och problemlösning, uppföljning, dokumentering, rapportering) av driftmiljöns serverutrustning (hårdvara, operativsystem, systemprogramvara), av lagringsutrustning (hårdvara, systemprogramvara) och annan utrustning. Vidare ingår livscykelhantering, hantering av relaterad IT-säkerhet och inköp. Arbetet beskrivs och styrs vanligen av processerna incidenthantering, problemhantering, ändringshantering, installation och konfiguration, prestanda- och kapacitetshantering samt styrning av leverantör Arbetsuppgifter för antingen applikations- eller serverdrift I ovanstående beskrivningar finns det utrymme för tolkningar av vem som ska ansvara för och utföra vissa arbetsuppgifter. Inför en framtida driftsituation bör ansvar och verkställighet utformas mera i detalj. Om det inte är möjligt så bör det finnas riktlinjer i avtalen för hur detta ska hanteras. Exempel på arbetsuppgifter som kan utföras av antingen applikations- eller serverdriften: konfigurationer felsökning installationer (t ex lägga in användare) brandväggskonfiguration databashantering optimering av prestanda 5 Storage Area Network används för att beskriva nätverk vars enda uppgift är att distribuera och lagra data 6 Domain Name System eller domännamnssystemet, är ett system för att förenkla adressering av datorer på IP-nätverk som till exempel Internet.

17 Sida 17 av Central supportfunktion för Ladok Den centrala supportfunktionen ska hantera och kanalisera ärenden från de lokala supportfunktionerna, utvecklings- och driftsorganisationerna samt från den den verksamhetsnära förvaltningen. Den blir då 2nd line support för Ladokärenden. Studenter och lärosätenas personal ska vända sig till lärosätets lokala supportfunktion för Ladok. Den lokala supportfunktionen kan sedan vid behov vända sig till den centrala supportfunktionen för Ladok. Den centrala supportfunktionen ska även hantera ärenden som kommer från utvecklingsoch driftsorganisationerna samt från den verksamhetsnära förvaltningen. Den centrala supportfunktionen ska hantera fyra typer av ärenden: Beställningar (certifikat, manuella informationsuttag m m), ändringsbegäran, fel och frågor. Ett flöde skulle kunna se ut så här: Lokal supportfunktion för Ladok Den lokala supportfunktionen för Ladok ska ge support till studenter och personal. Krav på den lokala supportfunktionen: ha kompetens för att kunna bedöma ifall ärendet ska utföras på lärosätet eller skickas vidare till den centrala supportfunktionen ha kunskap om vad som är lokala respektive centrala lösningar Exempel på lokala lösningar är beslutstödssystem, integrationer, studentgränssnitt ha kunskap om vad i de centrala lösningarna som lärosätet själva ska utföra, till exempel registervård, behörigheter ha kunskap om hur ärendehanteringen gentemot den centrala supportfunktionen ska utföras vara utbildade av den verksamhetsnära förvaltningen

18 Sida 18 av 28 7 Alternativa lösningar för drift av nya Ladok Ett antal scenarios har tagits fram och processats i olika grupperingar. 7.1 Scenarios Det finns för- och nackdelar med olika scenarios. Nedanstående scenarios är begränsade utifrån följande antagande: Serverdriften för den nya systemgenerationen Ladok ska hanteras av en leverantör Applikationsdriften och den centrala supporten ska hanteras inom högskolesektorn UHR ansvarar för utveckling, ändringar och felrättningar i Ladok till och med utgången av Scenario Ett Ett annat lärosäte än de befintliga driftställena anlitas för system- och applikationsdrift av nya Ladok. Konsortiet har upp till tre parter att förhålla sig till Detta alternativ är inte aktuellt då det innebär en engångskostnad för att bygga upp en ny driftsorganisation Scenario Två En annan myndighet (än UHR) som har kompetens kring drift/upphandling av drift anlitas för serverdrift av Ladok. Applikationsdriften hanteras inom högskolesektorn. Konsortiet har upp till tre parter att förhålla sig till + Konsortiet behöver inte ha lika hög beställarkompetens för serverdrift - Mindre möjlighet till prispress på standardtjänster - Konsortiet har mindre möjlighet att påverka serverdrift

19 Sida 19 av 28 - Ett led till vid felsökning och ansvarsfrågor, kan leda till långa ledtider Detta alternativ tillför inget Scenario Tre En annan myndighet (än UHR) som har kompetens kring drift/upphandling av drift anlitas för att upphandla serverdrift av Ladok. Applikationsdriften hanteras inom högskolesektorn. Konsortiet har upp till tre parter att förhålla sig till + Konsortiet behöver inte ha lika hög beställarkompetens för serverdrift + Möjlighet till prispress för standardtjänster som lagring, hårdvara mm - Konsortiet har mindre möjlighet att påverka serverdrift - Ett led till vid felsökning och ansvarsfrågor, kan leda till långa ledtider - Risk för problematik kring ansvar för helheten när drifttjänster delas upp, kräver bra samarbetsklimat och tydliga kontaktytor Detta alternativ tillför inget Scenario Fyra Avtal med UHR om serverdrift av nya Ladok, UHR upphandlar serverdrift externt/hos befintligt driftställe. Applikationsdriften hanteras inom högskolesektorn. Konsortiet har en till två parter att förhålla sig till + Möjlighet till samordningsvinster med serverdrift för NyA större volym att upphandla kan ge lägre pris + Konsortiet behöver inte ha lika hög beställarkompetens för serverdrift + Möjlighet till prispress för standardtjänster som lagring, hårdvara mm - Konsortiet har mindre möjlighet att påverka serverdrift - Ett led till vid felsökning och ansvarsfrågor, kan leda till långa ledtider - Risk för problematik kring ansvar för helheten när drifttjänster delas upp Detta alternativ kan vara aktuellt ifall konsortiet saknar beställarkompetens för drift. Tanken är att konsortiet ska tillföra beställarkompetens vilket medför att detta alternativ inte tillför något Scenario Fem System- och applikationsdrift för nya Ladok avtalas med något befintligt driftställe, som sedan upphandlar serverdrift externt. Konsortiet har en till två parter att förhålla sig till + Konsortiet behöver inte ha lika hög beställarkompetens för serverdrift (som i övriga scenarios)

20 Sida 20 av 28 + De som beställer serverdriften har applikationskompetens + Möjlighet till prispress för standardtjänster som lagring, hårdvara mm - Konsortiet har mindre möjlighet att påverka serverdrift - Ett led till vid felsökning och ansvarsfrågor, kan leda till långa ledtider - Risk för problematik kring ansvar för helheten när drifttjänster delas upp, kräver bra samarbetsklimat och tydliga kontaktytor Detta alternativ är en variant av det förra och kan vara aktuellt ifall konsortiet saknar beställarkompetens för drift. Tanken är att konsortiet ska tillföra beställarkompetens vilket medför att detta alternativ inte tillför något Scenario Sex Serverdrift för nya Ladok upphandlas av en kommersiell leverantör. Applikationsdriften hanteras inom högskolesektorn. Konsortiet har upp till tre parter att förhålla sig till + Möjlighet till prispress för standardtjänster som lagring, hårdvara mm + Kommersiellt avtal och väl avgränsade avtalsobjekt + Tillgång till resurser i och med kommersiellt avtal + Kompetens kring drift och teknisk spetskompetens hos leverantören + Etablerade processer för drift enligt Best Practice + Lättare att byta till ny/annan leverantör + Troligen billigare vid behov av tjänster utanför kontorstid - Risk för problematik kring ansvar för helheten när drifttjänster delas upp, kräver bra samarbetsklimat och tydliga kontaktytor - Risk för tvister om ansvar vid komplicerade fel - Kan vara svårt att kontrollera/följa upp resurssäkringen och kompetensförsörjningen - Konkurrens med andra kunder kring kompetens - Mindre kontroll på driftmiljön, t ex vid behov av snabba åtgärder - Lever med andra kunder i miljön. Kan påverkas av andras problem (jmf Tietokraschen) - Svårare med kundanpassningar - Risk för höga priser på tilläggbeställningar efter ingånget avtal Detta alternativ är relevant och har värderats inför rekommendationen Scenario Sju System- och applikationsdrift för nya Ladok avtalas med två befintliga driftställen, en för applikationsdrift och en för serverdrift. Konsortiet har upp till tre parter att förhålla sig till

21 Sida 21 av 28 + Driftställena kan fokusera på antingen serverdrift eller applikationsdrift och bygga spetskompetens + Tydliga ansvarsområden mellan applikations- och serverdrift arbetas fram som sedan kan användas vid upphandling av serverdrift + Lättare att på sikt byta leverantör av serverdrift när ansvarsområdena är tydliggjorda + Ökade möjligheter för kundanpassning + Verksamhetskännedom + Systemkännedom + Inget vinstintresse, självkostnadspris - Risk för problematik kring ansvar för helheten när drifttjänsterna delas upp, kräver bra samarbetsklimat och tydliga kontaktytor - Mindre möjlighet till prispress för standardtjänster - Inget kommersiellt avtal - Möjlighet för lärosätena att skapa egna kontaktytor till serverdriften - Risk för kostnadsineffektivitet Detta alternativ är relevant och har värderats inför rekommendationen Scenario Åtta System- och applikationsdrift för nya Ladok avtalas med något av de befintliga driftställena. Konsortiet har en till två parter att förhålla sig till + All drift samlad på ett ställe + Mindre problematik kring ansvarsfrågor vad gäller drift + Ökade möjligheter för kundanpassning + Verksamhetskännedom + Systemkännedom + Inget vinstintresse, självkostnadspris + Flexibilitet, t ex resurshantering vid realeaser + Helhetssyn + Nyckelkompetens kan utvecklas (applikation + server) - Mindre möjlighet till prispress på standardtjänster - Risk för att applikations- och serverdrift flyter ihop - Inget kommersiellt avtal - Möjlighet för lärosätena att skapa egna kontaktytor till serverdriften - Risk för kostnadsineffektivitet

22 Sida 22 av 28 - Svårare att på sikt byta leverantör av serverdrift när ansvarsområdena inte är tydliggjorda - Nyckelkompetens kan utvecklas hos enskilda individer vilket ökar sårbarheten Detta alternativ är relevant och har värderats inför rekommendationen. 7.2 Slutsatser Oavsett val av scenario är det viktigt att driftleverantörerna tillsammans vidareutvecklar beskrivningarna av applikations- och serverdrift. 8 Rekommendation I detta kapitel redovisas rekommendationen om applikationsdrift, support och serverdrift som är definierade i kapitel 6.1. Scenario sex, sju och åtta har analyserats och värderats i olika grupperingar. 8.1 Avgränsningar Konsortiets ansvar för den verksamhetsnära förvaltningen redovisas i Ny förvaltningsorganisation för Ladok. I förslaget föreslås att ansvaret för ny- och vidareutveckling samt acceptanstester ska ingå i den verksamhetsnära förvaltningen. Den part som utvecklar den nya applikationen ansvarar för drift av utvecklingsmiljöerna. Lärosätena ansvarar för lokala anpassningar och integrationer. 8.2 Rekommendation Förnyad förvaltning rekommenderar Scenario sju som innebär att serverdriften bör utföras av något av de befintliga driftställena och applikationsdriften på ett annat fram till att produkten är så pass klar att det finns bra kravunderlag för en upphandling. På lång sikt kommer då Scenario sex att införas. Scenario åtta stryks som alternativ. Förvaltningsorganisationen rekommenderas att planera för en upphandlad serverdrift i samband med att produkten slutlevereras. Möjligheten och konsekvensen av att upphandla serverdriften som en molntjänst bör beaktas och utredas särskilt. Skillnaden mellan traditionellt upphandlad IT-drift och molnbaserad IT-drift bör tydliggöras. Förvaltningsorganisationen bör tillsammans med de båda driftleverantörerna vidareutveckla och tydliggöra beskrivningarna av applikations- och serverdrift för att underlätta upphandlingen. Detta kan göras bland annat genom att kontinuerligt följa UHR och CSN:s utvecklingsarbete kring drift. 8.3 Beslutsalternativ För att nå i mål till leverans hösten 2014 finns följande beslutsalternativ: A. Serverdrift på ett befintligt driftställe på kort sikt, sedan upphandling/avrop på lång sikt enligt rekommendationen. B. Upphandling/avrop snarast möjligt, vilket innebär att upphandlingsproceduren startar efter konsortiestämman beslut att utöka konsortiets ansvar till att omfatta drift. Det medför att serverdrift på kort sikt bör ges till en annan part för att säkerställa att utvärdering av molntjänster och upphandling kan göras på ett godtagbart sätt.

23 Sida 23 av Motivering Med applikationsdrift och serverdrift på två olika ställen är det lättare att på sikt upphandla serverdrift vilket medför att Scenario åtta inte rekommenderas. Det är en stor risk för att förfrågningsunderlaget inför en upphandling blir ofullständig eftersom produkten inte är klar förrän Med en ofullständig kravspecifikation finns det risk för skenande kostnader när kompletteringar ska göras av driftavtalet. 9 Genomförande I de båda alternativen är det viktigt att en dialog med driftställena tidigt för att kunna bedöma deras ambitionsnivå. Nulägesanalysen ger information om dagens avtal och servicenivåer. Tidplanen följer Ladok3-projektets tidplan och ska ändras ifall tidplanen för Ladok3-projektet ändras. 9.1 Beslutsalternativ A start klart Nulägesanalys (driftavtal, servicenivåer) maj 13 jun 13 Dialog med driftställena maj 13 Utforma kravunderlag jun13 nov 13 Utforma urvalskriterier för val av driftställe okt 13 nov 13 Utvärdering dec 13 Val av två driftställen (applikations- och serverdrift) jan14 Upprätta avtal med två driftställen feb 14 mar 14 Införande mar 14 okt 14 Utforma uppdrag till förvaltningsorganisationen Q2 14 Q2 14 Utforma sourcingstrategi Q4 16 Q3 17 Införa sourcingstrategi Q3 17 Q Beslutsalternativ B I denna övergripande tidplan har ingen hänsyn tagits till en eventuell överprövning. Vid överprövning förskjuts införandet med 8 12 månader. start klart Nulägesanalys (driftavtal, servicenivåer) maj 13 jun 13 Dialog med driftställena maj 13 Utforma kravunderlag jun13 nov 13 Utforma förfrågningsunderlag okt 13 jan 13 Utskick och anbudsinlämning jan 13 mar 14 Utvärdering apr14 apr 14

24 Sida 24 av 28 Avtalsspärr maj 14 maj 14 Avtalsutformning maj 14 jun 14 Införande jun 14 okt Risker och konsekvenser Risker och konsekvenser har identifierats i olika grupperingar under projekttiden För lärosätena Det finns en risk att driften av befintligt Ladok inte fungerar tillfredsställande under återstående användningsperiod om det inträffar en kompetensflykt från driftställena. Rekommendationen innebär: att konsortiet ska ta fram gemensamma basnivåer för tillgänglighet och prestanda lägre kostnad för lokal förvaltning och drift inget behov av lokal beställarkompetens och uppföljningsansvar för drift av Ladok en enhetlig och tydlig process för Ladokansvariga en central supportfunktion som endast kommer att tillhandahålla 2nd line support medför att alla lärosäten, precis som idag, tillhandahåller en lokal supportfunktion för sina studenter och personal För konsortiet Det kan finnas en risk att inget av driftställena vill ta på sig serverdriften för att om några år avveckla den. Rekommendationen innebär att: beställarkompetens för driftfrågor måste tillföras förvaltningsorganisationen. Det kan omfatta krav på strategisk teknisk kompetens, omvärldsbevakning, outsourcing, upphandling, koordinering, avtal mm För driftställena Det finns risk för kompetensflykt vilket kan innebära konsekvenser för drift av befintligt Ladok. Rekommendationen innebär att: samtliga driftställen får förändrade roller driften för befintligt Ladok kommer att vara kvar för alla tre driftställen under övergångsperioden ett driftställe kommer att ansvara för applikationsdriften och den centrala supporten på lång sikt ett annat driftställe kommer att ansvara för serverdriften på några års sikt

25 Sida 25 av 28 Bilaga 1 I denna bilaga har E-delegationens rapport 7 använts som underlag. I avsnittet om molntjänster har engelska Wikipedia använts samt interna resurser 8 inom högskolesektorn. E-delegationen har i sin rapport analyserat alternativ till IT-drift i egen regi. Resultaten av analyserna kan inte direkt användas i detta fall då förutsättningarna är annorlunda. Outsourcing Inom området drifttjänster används begreppet outsourcing för företeelsen att lägga över aktiviteter och ansvar på en leverantör. Leverantören levererar dessa aktiviteter som ITtjänster. Outsourcing: Att lägga ut aktiviteter och ansvar, som tidigare hanterades av myndigheten till en extern leverantör, som mot betalning utför detta under avtalad period. Definitionen av begreppet outsourcing är skriven för att täcka in olika typer av outsourcing. På marknaden förekommer idag ett flertal begrepp, t.ex. Managed Services, Facilities management, Hosting, Funktionsoutsourcing. Inom offentlig sektor används ofta begreppet entreprenader för outsourcing. Begreppet outsourcing betyder inget avseende ägandet (eller plats) för tjänsternas utförande. Bilden nedan illustrerar dimensionerna Ansvar för utförandet och Ägande vid outsourcing. Exempelvis kan myndigheten lägga över ansvaret för utförandet av tjänsterna trots att myndigheten fortsatt äger utrustning, licenser och personal som används i tjänsten. Traditionellt har outsourcingleverantörerna tecknat unika leveransavtal med varje kund för att specificera tjänster, leveranser, priser och övriga villkor. På senare tid har det tillkommit en ny leveransform av outsourcade tjänster som kallas molntjänster. Shared Service Center Shared services är ett samlingsbegrepp för samutnyttjande av stödfunktioner inom en organisation eller mellan organisationer. Den samlade organisationen som svarar för att tillhandahålla dessa stödfunktioner, vanligen i form av paketerade tjänster, brukar benämnas Shared Service Center, SSC. Inom IT-drift skapar ett SSC ofta förutsättningar för skalfördelar genom att möjliggöra ett processinriktat, enhetligt och strukturerat arbetssätt. Ett SSC kan i sin tur konkurrensutsätta utförandet av avgränsade delfunktioner till leverantörer på marknaden. Utifrån ett myndighetsperspektiv kan Shared Service Center bedrivas; inom den enskilda myndigheten. som en egen myndighet. genom nyttjande eller skapande av någon annan form av aktör (exempelvis bolag). Molntjänster 7 Effektiv IT-drift inom staten, Kammarkollegiet 8 Tony Ottosson, Chalmers; Joakim Nejdeby, LiU

26 Sida 26 av 28 Största delen av detta kapitel är ett utdrag ur Förstudie Programvaror 2010 som i sin tur har citerat en rapport som Radar Group International gjort på uppdrag av Kammarkollegiet. Antalet definitioner av begreppet molntjänster är stort och det är svårt att hitta en helt ensad bild av vad molntjänster egentligen är. Engelska Wikipedia har ett kapitel om Cloud computing. Ett annat exempel på definition av molntjänster är den som Radar Group International tog fram i samband med att de fick i uppdrag av Kammarkollegiet att ta fram en rapport 9 angående användandet av molntjänster i offentlig sektor. Denna definition lyder: Massivt skalbara nätverksburna IT-resurser (t.ex. programvara, lokala nätverk, servrar, lagring och annat som förknippas med IT) som brukaren efter eget behov kan få tillgång till, anpassa, börja använda och som sedan debiteras per utnyttjad kapacitet. Detta ska ses i relation till den traditionella modellen att anskaffa IT vilket innebär inköp av programvara och hårdvara som installeras i egen infrastruktur med egna eller inhyrda resurser, med tillkommande kostnader för anpassningar, underhåll och uppgraderingar. I rapporten skriver också Radar Group International att molntjänster kan ha tre olika tjänstenivåer: Programvara som tjänst (SaaS - Software as a Service Plattform som tjänst (PaaS - Platform as a Service) Infrastruktur som tjänst (IaaS - Infrastructure as a Service) På Wikipedia finns fler typer av molntjänster beskrivna. Figuren 10 nedan beskriver vad som kan ingå i de olika tjänsterna. Sättet att ta betalt för molntjänster är annorlunda, eftersom betalning kan ske t.ex. genom att ta hyra per användare, per månad, per år eller per utnyttjad resurs. Molntjänster erbjuds av de flesta tillverkare, antingen via partners eller direkt till kund. 9 Radar Group Internationals rapport Användandet av molntjänster inom offentlig sektor, december en.wikipedia.org