2010:242
C - U P P S A T S
Systemförvaltning med Cloud Computing
David Strand Erik Söderström
Luleå tekniska universitet C-uppsats
Data och systemvetenskap
Institutionen för Industriell ekonomi och samhällsvetenskap Avdelningen för Systemvetenskap
2010:242 - ISSN: 1402-1773 - ISRN: LTU-CUPP--10/242--SE
Sammanfattning
Syftet med den här undersökningen var att ta reda på vad som händer i en system- förvaltning när Cloud Computing införs. Vilka roller och aktiviteter i systemför- valtningen som påverkas vid byte av IT-lösning.
För att få svar på detta har vi utfört en fallstudie på ett företag som utvecklar och levererar tjänster baserade på Cloud Computing, där vi intervjuat två respondenter för att samla in information. En analys har utförts där informationen jämförts mot teoriramen. Därefter har slutsatser dragits utifrån arbetet.
Slutsatserna av denna undersökning visar på att förvaltningsarbetet minskar hos tjänsteleverantören, samma arbetsuppgifter måste utföras för förvaltningen av systemet, team effektiviserar systemförvaltningen och kunden ställer krav på sy- stemet.
Abstract
The purpose of this study was to find out what happens in a system management when Cloud Computing is introduced. What are the roles and activities of the sys- tems management that are affected when changing the IT solution.
In order to answer this we have conducted a case study of a company that devel- ops and provides services based on Cloud Computing, where we interviewed two respondents to collect information. An analysis has been performed in which the information was compared against the theoretical framework. Then the conclu- sions were drawn from the survey.
The conclusion for this survey show that the management works reduces for the consulting firm, the same tasks must be performed for managing the system, teams make the system management more effective and the customer requires the functionality of the system.
Förord
Denna C-uppsats tillhör den avslutande delen av en kandidatexamen i Systemve- tenskap, inom institutionen för Industriell ekonomi och samhällsvetenskap vid Luleå tekniska universitet. Uppsatsen innefattar 15 högskolepoäng och är skriven under våren 2010.
• Vi vill tacka vår handlare Dan Harnesk för all handledning och kritik un- der arbetets gång.
• Vi vill även tacka våra respondenter på eBuilder AB i Luleå för att de ställt upp på intervjuer.
• Ett stort tack till Magnus Dyrander för all hjälp och alla synpunkter vi fått under arbetets gång.
Luleå, 2010-05-26
David Strand Erik Söderström
Innehållsförteckning
1 INLEDNING ... 1
1.1 BAKGRUND ... 1
1.2 PROBLEMBAKGRUND ... 2
1.3 PROBLEMDISKUSSION ... 2
1.4 SYFTE OCH FORSKNINGSFRÅGA... 3
1.5 AVGRÄNSNINGAR ... 3
1.6 DEFINITIONER ... 3
2 TEORI ... 4
2.1 SYSTEMFÖRVALTNING ... 4
2.1.1 Varför systemförvaltning? ... 4
2.1.2 Outsourcing av systemförvaltning ... 5
2.1.3 Förvaltningsobjekt ... 5
2.1.4 Roller i en systemförvaltning ... 6
2.1.5 Förvaltningsaktiviteter ... 8
2.2 CLOUD COMPUTING ... 9
2.2.1 Software as a Service (SaaS) ... 11
2.2.2 Infrastructure as a Service (IaaS) ... 11
2.2.3 Platform as a Service (PaaS) ... 11
2.2.4 Systemförvaltning av cloudtjänster ... 12
3 METOD ... 13
3.1 VETENSKAPLIGT FÖRHÅLLNINGSSÄTT ... 13
3.1.1 Kvalitativ eller kvantitativ studie? ... 13
3.2 FALLSTUDIE ... 14
3.3 VAL AV UNDERSÖKNINGSOBJEKT OCH INTERVJUPERSONER ... 14
3.4 DATAINSAMLING ... 14
3.4.1 Intervjuer ... 15
3.5 ANALYSMETOD ... 16
3.5.1 Tillvägagångssätt vid analys ... 16
3.6 VALIDITET OCH RELIABILITET ... 16
4 EMPIRI ... 18
4.1 PRESENTATION AV FÖRETAG ... 18
4.2 PRESENTATION AV RESPONDENTER ... 19
4.2.1 Respondent A ... 19
4.2.2 Respondent B ... 19
4.3 SAMMANSTÄLLNING AV DEN EMPIRISKA UNDERSÖKNINGEN ... 19
5 ANALYS ... 22
5.1 ROLLER ... 22
5.1.1 Solution Manager och Project Manager ... 22
5.1.2 Development Team, Maintenance Team och Operation Team ... 23
5.1.3 Processägare... 23
5.1.4 Business Manager och Business Developer ... 24
5.1.5 Support Team och Driftleverantör ... 24
5.2 FÖRVALTNINGSAKTIVITETER ... 25
5.2.1 Förvaltningsstyrning ... 25
5.2.2 Användarstöd ... 25
5.2.3 Ändringshantering ... 26
5.2.4 Daglig IT-drift och underhåll ... 26
5.3 SYSTEMFÖRVALTNING AV CLOUDTJÄNSTER... 27
5.3.1 Vanliga åtgärder ... 27
5.3.2 Underhållsåtgärder ... 27
5.3.3 Akuta åtgärder ... 27
6 SLUTSATSER ... 29
6.1 SLUTSATS... 29
6.2 METODDISKUSSION ... 29
6.3 FÖRSLAG TILL VIDARE FORSKNING ... 30
REFERENSER ... 31
BILAGOR ... 1
BILAGA A–INTERVJUMALL ... 1
BILAGA B–SVAR PÅ INTERVJUERNA ... 1
1
1 Inledning
I detta inledande kapitel beskrivs bakgrunden för studien av Systemförvaltning med Cloud Computing med de problemområden som finns. Undersökningens syfte och forskningsfråga redovisas tillsammans med avgränsningar och definitioner.
1.1 Bakgrund
Med Internet har nya sätt att utveckla IT-tjänster blivit möjliga då Internet för- summar de geografiska gränserna. En av de mest lovande och aktuella IT- lösningar som tagits fram är Cloud Computing.
Idén kring Cloud Computing bygger på att företag hyr en specialanpassad IT- lösning, som nås via Internet, från ett externt företag istället för att ha IT- lösningen lokalt inom företaget. I den specialanpassade IT-lösningen ingår både hård- och mjukvara samt IT-support och underhåll som det externa företaget till- handahåller (Arnold, 2009).
I en artikel, Molnet förändrar allt, beskriver Fredrik Wass (2008) Cloud Compu- ting:
”Föreställ dig ett moln. Det är osynligt, finns precis utom räck- håll och ändå tillgängligt precis när du vill. I molnet finns all tänkbar information som du delar med dina vänner, din familj och dina kontakter. Inte nog med det. Även din kommunikation med omvärlden finns samlad i molnet. Det är ditt utbyggda medvetande.”
Eftersom vi i en tidigare kurs under programmets gång kommit i kontakt med fe- nomenet Cloud Computing väcktes vårt intresse för den nya IT-lösningen. Då Cloud Computing är ett aktuellt ämne som diskuteras friskt i svenska IT- tidskrifter så började vi fundera över vilka konsekvenser införskaffandet av IT- lösningen skulle få för organisationer, i både positiv och negativ mening. Detta då Cloud Computing faktiskt förväntas ta stor plats i framtida företag.
Systemförvaltning har funnits sedan utvecklingen av informationssystem började förekomma. Begreppet kommer i användning så fort ett system tas i bruk då sy- stemet kräver förändringar av olika anledningar. Dessa förändringar kan vara till exempel förändringar i verksamheten och behov av nya funktioner (Nordström &
Welander, 1993).
Systemförvaltning har för oss alltid varit i fokus då vi som blivande systemvetare har haft vår utbildning kretsande kring systemutveckling och systemunderhåll.
Det blev ett enkelt val att blanda in denna del av IT-verksamheten i vårt intresse- område, då vi lyckades kombinera dessa två områden, som länge intresserat oss, till ett aktuellt problemområde. Problemområdet tycker vi behöver undersökas
2 utförligare och då blev saken klar – vi valde att undersöka Systemförvaltning med Cloud Computing.
1.2 Problembakgrund
Ett ökänt problem med systemförvaltning är att det kostar mycket pengar. Hela 33-75 % av IT-verksamhetens budget går åt till att underhålla och förvalta syste- men. Den stora variationen av kostnaden beror troligast på att innebörden av sy- stemförvaltning varierar från organisation till organisation, det vill säga att olika organisationer räknar in olika områden i systemförvaltningen. För den höga kost- naden finns flera förklaringar till exempel förändrings- och utvecklingsarbete och att systemen inte är byggda så de underlättar för förvaltningsarbetet. Förändrings- och utvecklingsarbete är en given kostnad då verksamhetens system kontinuerligt kommer att måste anpassa sig efter organisationens behov eftersom organisatio- nen ständigt är under förändring (Nordström & Welander, 2002).
Tomas Augustsson (2009) skriver att med den nuvarande lågkonjunkturen tvingas företag att se över sina kostnader och därför blir ekonomiskt givande IT-lösningar ett väldigt attraktivt alternativ.
Fredholm (2004) hänvisar till tidigare forskning när han skriver att företag som vågar satsa på att utveckla och implementera nya tekniker är ofta de företag som redan är framgångsrika. Dessa satsningar leder oftast till att de blir mer lönsamma och stärker sin marknadsposition. De företag som det går sämre för vågar oftast inte investera i nya IT-lösningar på samma sätt som de framgångsrika företagen, vilket leder till att de oftast hamnar i en ännu sämre situation.
Andra bekymmer med systemförvaltning är att förvaltningen oftast betraktas som ett problem. Problemet ligger i att förvaltningen beskrivs i allmänhet som kost- samt, har låg status, trist benämning och oklara ansvarsroller. Yrket anses i all- mänhet som tråkigt av de som inte jobbar inom systemförvaltning (Nordström &
Welander, 2002).
1.3 Problemdiskussion
Systemförvaltning ses som en kostsam verksamhet då förvaltningen behöver stora resurser för att aktivt förvalta system efter organisationernas behov. Ett alternativ till den interna systemförvaltningen är att lägga ut hela eller delar av funktioner till externa parter för förvaltning. Vi tror att med Cloud Computing kan dessa kostnader reduceras eftersom leverantören står för förvaltningen av de specifika tjänster som leverantören levererar. När cloudtjänsterna införs i en organisation så tror vi att det kan bidra till en hel del förändringar för organisationens systemför- valtning. Beroende på storleken av tjänsten som organisationen väljer att inför- skaffa så antar vi att respektive delar av systemförvaltningen flyttas över till tjäns- televerantören. Vi antar att detta i sin tur leder till att vissa roller och förvaltnings- aktiviteter ändras eller försvinner inom den egna systemförvaltningen eller också flyttas över till tjänsteleverantören, som numera sköter förvaltningen av den ut-
3 lagda delen av systemet. Därför är vi intresserade av att undersöka vilka föränd- ringar som faktiskt sker i en systemförvaltning vid införskaffandet av tjänster ba- serade på Cloud Computing.
1.4 Syfte och forskningsfråga
Syftet med den här undersökningen är att ta reda på vad som händer i en system- förvaltning när Cloud Computing införs. Vilka roller och aktiviteter i systemför- valtningen som påverkas vid byte av IT-lösning. Som forskningsfråga har vi ut- ifrån detta syfte formulerat följande:
Vilka förändringar blir det i en systemförvaltning vid införandet av Cloud Computing?
1.5 Avgränsningar
I vår undersökning har vi valt att avgränsa oss till att titta på hur en tjänsteleveran- tör tillhandahåller cloudtjänster. Undersökningen är avgränsad till ett systemför- valtningsperspektiv för dessa tjänster.
Applikationernas funktionalitet och kodningsspråk kommer inte att vara relevanta i denna studie.
1.6 Definitioner
I detta avsnitt definierar vi återkommande termer på det sätt som vi använt oss utav dem.
• End-to-end – Slutanvändare till slutanvändare
• Informationssystem – Datorstödda system som insamlar, bearbetar, lagrar och distribuerar information (Nationalencyklopedin, 2010).
• Outsourcing – Att lägga ut en process eller en funktion på ett annat företag (Nationalencyklopedin, 2010).
• Pay-asthey-go – En betalningsmodell som baseras på betalning per resurs- förbrukning (IASA, 2009).
• SLA – Service-Level Agreement är en del av ett tjänstekontrakt där storle- ken på tjänsten är formellt definierad. I praktiken är termen SLA något som ibland används för att referera till tjänstens leveranstid eller prestanda (Wikipedia, 2010).
4
2 Teori
I detta kapitel beskrivs relevanta teorier från det utvalda problemområdet som ligger till grund för undersökningen. Första delen av kapitlet innehåller en grund- läggande beskrivning av systemförvaltning och dess aktiviteter och roller. Sist i teoriavsnittet förklaras Cloud Computing och dess olika typer av tillvägagångs- sätt.
2.1 Systemförvaltning
Nordström & Welander (2002) konstaterar att systemförvaltning är ett svårdefini- erat begrepp. Detta beror på att ämnestillhörigheten skiljer sig internationellt mot det svenska synsättet. Internationellt anses systemförvaltning ha en teknisk tillhö- righet medan den här i Sverige gränsar mellan teknik och samhällsvetenskap.
Statskontoret (1990) skriver att systemförvaltning är en sammanfattande benäm- ning på de åtgärder som krävs för att administrera och hantera ett system i drift.
Systemförvaltning innebär att löpande följa systems beteende avseende viktiga egenskaper som till exempel: systemanvändning, systembesikt- ning/systemdiagnos, systemsäkerhet, handböcker och metoder, ändringshantering, bevakning av kompetens, samordning, ansvarsfördelning, dokumentation och av- tal av olika slag.
Systemförvaltningen sker i huvudsak centralt inom affärs- och IT-verksamheten.
Förvaltningen ligger oftast lokalt inom den egna organisationen där organisatio- nens egna anställda förvaltar systemen. Systemförvaltningen kan även ha en mar- kant extern placering. Med det menas att förvaltningen sköts hos en extern part av deras personal mot betalning (Brandt, 2005).
2.1.1 Varför systemförvaltning?
Révay (1992) skriver att systemförvaltning är nödvändigt för att kunna upprätthål- la en hög teknisk kvalitet på system i drift då system kontinuerligt kommer att behöva anpassas genom att till exempel korrigera brister och felaktigheter. Andra exempel på att systemförvaltningen behövs är för att hela tiden få full kontroll över det aktuella systemet och förvaltningskostnaderna som tillkommer. Om detta utförs korrekt bidrar detta till att nyttan ökas, livslängden förlängs och färre stör- ningar uppkommer genom ökad kvalitetskontroll samt att lägre kostnader till- kommer med en effektivare förvaltning.
Brandt (2005, s.38) svarar på frågan ’varför systemförvaltning?’ med följande mening:
”Systemförvaltning behövs primärt för att ändra informations- system och/eller tjänst och stödja affärsverksamheten i form av användarstöd av olika slag.”
5 Systemförvaltningen behövs alltså för att upprätthålla bra kvalitet på systemen.
Användarna kräver stöd vid användning av applikationerna och vid ändringar av eventuella systemfel. Vidare för att fortsättningsvis se till att organisationerna ska ha anpassade system efter sina behov trots att utvecklingen går framåt inom både verksamheten och IT-branschen.
2.1.2 Outsourcing av systemförvaltning
Systemförvaltningen har traditionellt legat inom den egna organisationen där or- ganisationen haft en egen avdelning dedikerad till att sköta förvaltningen av sy- stemen i bruk. Med outsourcing behöver inte systemförvaltningen ligga inom or- ganisationen, organisationerna kan välja att lägga ut hela eller delar av systemen till en extern part som kan ta över förvaltningsarbetet av de resurser som organisa- tionerna väljer att lägga ut till entreprenören mot betalning (Augustson & Berg- stedt Sten, 1999).
Augustson & Bergstedt Sten (1999, s.15) definierar outsourcing som:
”Utkontraktering av en aktivitet som tidigare utfördes internt, till en extern leverantör som sedan mot betalning förser organi- sationen med den aktuella aktiviteten under en avtalad tid.”
Nationalencyklopedin beskriver att organisationer genom outsourcing kan överlå- ta hela eller delar av funktioner som tidigare legat inom organisationen till extern underleverantör. Exempelvis systemutveckling, IT-drift och underhåll.
2.1.3 Förvaltningsobjekt
Det som förvaltas i en systemförvaltning beskriver Nordström & Welander (2002) som ett förvaltningsobjekt. Förvaltningsobjekt är egentligen informationssystem, fast då Nordström & Welander tycker begreppet är för databaserat så använder de sig av begreppet förvaltningsobjekt istället. De beskriver förvaltningsobjekt som av en mer allmän karaktär, detta för att modellen även används till förvaltning av flera olika typer av objekt såsom till exempel processer och supportfunktioner.
Figur 2.1: Förvaltningsobjekt (Nordström & Welander, 2002, s.11)
6 Figur 1 visar en modell som förställer en organisations marknad, tårtbiten i mo- dellen representerar ett förvaltningsobjekt i organisationen. Ett förvaltningsobjekt består av fyra olika skikt. Dessa skikt är:
1. Affärs/uppdrag (verksamhet)
2. Produkt/Tjänst/Process/Funktion (verksamhet) 3. Applikation (IT-stöd)
4. Teknisk plattform (IT-stöd)
I verkligheten skiljer sig detta dock något eftersom hela förvaltningen är upp- byggd kring applikationer. IT-stödet kan ofta ses som avskiljt från den övriga verksamheten då den kan ses som en stödorganisation. Gränsdragningen mellan verksamheten och IT-stödet är i verkliga fall långt ifrån lika klar som i figur 1 (Nordström & Welander, 2002).
2.1.4 Roller i en systemförvaltning
I en systemförvaltning finns det oftast definierade roller som sköter förvaltningen av systemen. När organisationer lägger ut sina system till externa parter eller kö- per in specifika tjänster behöver förvaltningen av systemen inte längre ligga inom företaget. Detta medför att rollerna kan flyttas eller upphöra att existera eftersom systemförvaltningen genomgår en förändring vid införandet av till exempel tjäns- ter baserade på Cloud Computing (Augustson & Bergstedt Sten, 1999; Nordström
& Welander, 2002).
Brandt (2005) menar att det finns ungefär åtta olika roller vid en systemförvalt- ning. Dessa roller brukar vara väl definierade och bemannade av personal som ska ha tillräckligt med kunskap för att kunna genomföra ändringar. Rollerna skapas för att urskilja vem som ska göra vad i större företag. En person kan axla flera roller i företaget.
Förvaltningsledare
Förvaltningsledaren har överordnat ansvar för ett eller fler definierade system.
Han har som huvudsaklig uppgift att administrera, planera och följa upp förvalt- ningsarbetet av ett eller flera system och samordna arbetet inom ansvarsområdet och med närliggande system (Brandt, 2004).
Förvaltningsledaren deltar vid förvaltningsmöten där bland annat förslag på för- bättringar ges och kostnads- och lösningsförslag tas fram. Han sköter kvalitetssäk- ringen av förvaltningsarbetet och uppdaterar förvaltnings- och systemdokument.
Han förbereder driftsättningar och systemändringar och upprättar konfigurations- planer och releaseplaner. Han ansvarar för resultatet vid ändringsarbeten och medverkar vid olika utredningar. Det är han som har den yttre kontakten med sy- stemägaren och/eller systemansvarige (Brandt, 2004).
7 Informationsägare
Informationsägaren har det övergripande och yttersta ansvaret för en definierad mängd information som används av ett eller flera system. Han har som huvudsak- lig uppgift att fatta det avgörande besluten om informationen, om det behövs ny- utveckling, vidareutveckling, förvaltning och avveckling av informationen (Brandt, 2004).
Informationsägaren har som ansvar att ta fram informationsbudget och genomföra nyttovärderingar på systemet för att se till att informationen stödjer verksamheten.
Han fullföljer säkerhetspolicys och ser till att nyttjandet av informationen inte bryter mot det utformade regelsystemet. I regelsystemet ansvarar han också för att se till att uppdateringar, ändringar och kontroll av informationen sköts på ett kor- rekt sätt (Brandt, 2004).
Produktförvaltare
Produktförvaltaren är produktägarens förlängda arm och ser till att produktägarens mål förverkligas i praktiken. Han har som huvudsakliguppgift att kanalisera alla önskemål, begäran och krav på ändringar, värderar och prioriterar dessa, beställa och bevaka att ändringar blir gjorda som avsetts på lokal nivå (Brandt, 2004).
Produktförvaltaren sköter uppföljningen av förvaltningsarbetet och ekonomin. Vid eventuella avvikelser från systemförvaltningsplanen eller budget överstigningar vid ändringsarbetet så rapporterar produktförvaltaren detta till produktägaren. Han bevakar att systemet stödjer verksamheten, följer upp att informationskvalitet och informationssäkerhets upprätthålls och föreslår vidareutvecklingsåtgärder vid be- hov. Dessa ändringar prioriteras av honom. Han ansvarar för att det finns en fun- gerande beställningsrutin och att förvaltningsstrategin följs. Vid samband med upphandling är det produktförvaltaren som agerar kravställaren. Han kontrollerar också om eventuellt behov av vidareutbildning behövs bland de anställda (Brandt, 2004).
Produktägare
Produktägare har övergripande ansvar över en eller fler produkter (företagets egna informationssystem med tillhörande tjänster). Han har som huvudsaklig uppgift att fatta avgörande beslut av produkternas förvaltning på lokal nivå (Brandt, 2004).
Produktägaren följer i sitt arbete den gällande systemförvaltningsstrategin för sin produkt där han också ansvarar för på dess informationssäkerhet. Han sköter vida- reutbildning av produktens användare och samordnar med de andra produktägar- na. Han tecknar avtal med systemägaren och ansvarar för att lokala system- och användardokument är aktuella (Brandt, 2004).
Systemansvarig
Systemansvarig är den som administrerar och ser till att systemägarens mål för- verkligas i praktiken. Systemansvarig har som huvudsaklig uppgift att kanalisera
8 alla önskemål, begäran och krav på ändringar, värdera och prioritera dessa, bestäl- la och bevaka att ändringarna blir gjorda som avsetts (Brandt, 2004).
Den systemansvarige ansvarar för kvalitetssäkringsarbetet där han tar fram princi- per och strukturer för användarnas behörighet för systemet. Han ser till att syste- met stödjer verksamheten och att förvaltningsstrategin följs samt analyserar beho- vet av eventuellt utbildningsbehov av anställda. Han prioriterar behovet för änd- ringar och värderar nyttan för dem när de är införs och han gör uppföljningar om hur förvaltningsarbetet sköts. Han gör uppföljning av den ekonomiska situationen för systemet och avrapporterar till systemägaren. Han är med och förhandlar om krav vid upphandling (Brandt, 2004).
Systemförvaltare
Systemförvaltarens huvudsakliga uppgift är att samordna, planera och följa upp ändringsarbetet för ett eller flera system (Brandt, 2004).
Systemförvaltaren ansvarar för att ändringar genomförs, han medverkar i änd- ringsarbetet där han bland annat uppdaterar ändringsdatabaserna och genomför tester för dessa ändringar. Han ser till att avtalad kvalitet på systemet upprätthålls och vid eventuella avbrott och incidenter så sköter han uppföljningsarbetet av des- sa. Han ser till att systemdokumenten är aktuella och rapporterar dessa till förvalt- ningsledaren. Han medverkar vid framtagning och diskussioner kring kostnader och lösningar (Brandt, 2004).
Systemägare
Systemägaren har som huvudsaklig uppgift att fatta avgörande beslut om syste- met, om nyutveckling, vidareutveckling, förvaltning och avveckling (Brandt, 2004).
Systemägaren ansvarar bland annat för att skapa budget och planer för hur sy- stemförvaltningen ska genomföras. Det är han som ser till att förvaltningsstrategi och säkerhetspolicy används enligt förutbestämda regler för systemet. Han har det yttersta ägaransvaret för systemet och ser till att det stödjer verksamhetens krav fullt ut. Han sköter även den affärsmässiga kontakten med produktägaren (Brandt, 2004).
Systemrättsägare
Systemrättsägaren har liknande ansvar och befogenheter som systemägaren, men inte ägaransvaret för systemet efter som det som regel är en leverantör eller annan part som äger systemet. Systemägaren har nyttjanderätten av systemet. Hans hu- vudsakliguppgift är att ha inflytande och kravställande av det hyrda/leasade sy- stemet (Brandt, 2004).
2.1.5 Förvaltningsaktiviteter
Förvaltningen av system sköts med hjälp utav ett antal olika förvaltningsaktivite- ter. Dessa förvaltningsaktiviteter behöver nödvändigtvis inte skötas inom organi- sationen utan de kan med enkelhet flyttas över till ett utomstående företag som
9 utför förvaltningen av dessa aktiviteter (Augustson & Bergstedt Sten, 1999; Nord- ström & Welander, 2007).
Nordström & Welander (2007) skriver att förvaltningsverksamheten har fyra hu- vudsakliga aktiviteter.
Förvaltningsstyrning
Förvaltningsstyrningen innebär mestadels verksamhetsplanering av systemför- valtningsverksamheten samt operativ styrning och ledning, det vill säga beställ- ningar, prioriteringar, omvärldskontakter och möten med användare. Det innebär också uppföljning av överenskomna mål och beslut om olika åtgärder för att kor- rigera möjliga avvikelser i förvaltningsobjektet (Nordström & Welander, 2007).
Användarstöd
Användarstöd är ofta en dold aktivitet i förvaltningsarbetet men som oftast kräver stora resurser. Olika uppdrag som ingår inom användarstöd kan vara att hjälpa användare med ett IT-system, att utbilda användare inom IT-system, ändra använ- dardokumentation och att informera användaren om driftstatus. Den huvudsakliga uppgiften ligger dock på att utbilda och informera slutanvändaren genom att be- svara dess frågor och agera support (Nordström & Welander, 2007).
Ändringshantering
Ändringshantering är den mest förekommande förvaltningsåtgärden eftersom den är aktiva inom varenda ändring som sker inom systemförvaltningen. När en för- valtningssituation är väl fungerade görs ändringar endast schemalagt med ett fåtal akuta åtgärder. Specialfall som kan förekomma är ändringar som berör den tek- niska plattformen, utbyte av operativsystem och implementering av nya säkerhets- lösningar (Nordström & Welander, 2007).
Daglig IT-drift och underhåll
Med daglig IT-drift och underhåll innefattar det dagliga löpande arbetet med inf- rastruktur och IT-system. IT-driftens uppdrag ligger i att utföra backups, övervak- ning, körningar och filöverföringar av den tekniska infrastrukturen. Arbetet utförs kontinuerligt då det pågår ständigt med mer eller mindre automatiserade flöden, rutiner och arbeten som resulterar i ett förbyggande underhåll av förvaltningsob- jektet (Nordström & Welander, 2007).
2.2 Cloud Computing
När Cloud Computing kommer på tal är definitionen i mångas ögon ganska otyd- lig, även bland IT-folket. IT-lösningen kan ses som ganska luddig och svårför- stådd då den är relativt ny och har en väldig bredd. Proofpoint har med hjälp av Osterman Research har gjort undersökningen, Using SaaS to Reduce the Costs of Email Security (2009), riktad till IT-folket där de bland annat har ställt frågan:
”När jag hör termen ’Cloud Computing’ är jag allmänt konfunderad av alla defi- nitioner?” På den svarade 52 % av de tillfrågade respondenterna ”nej”, 33 % sva- rade att de trodde att ”Cloud Computing var mer hypat än att det var av sub-
10 stans” medan 24 % svarade ”att de inte var säkra.” Förutom det så svarade även 59 % av respondenterna att deras VD inte skulle kunna definiera Cloud Compu- ting på ett korrekt sätt, medan endast 24 % trodde att deras VD skulle kunna klara av uppgiften.
Cloud Computing förväntar att din arbetsmiljö; hårdvara, mjukvara och datalag- ring, sker på Internet istället för på din PC berättar Arnold (2009). Han fortsätter att berätta att Cloud Computing är en Internettjänst som existerar någonstans i Internetmolnet. Användarna kommer åt molnet via sina egna API (Application Programming Interface) där det är lätt att förena moln tillsammans då allt bygger på webbtjänster. Andra fördelar med Cloud Computing är implementeringen av samarbete, standardiserad innehållsdistribution, enkel sökning och snabb pro- gramutveckling. Arnold (2009) skriver vidare att en utbredning av bredband, den ökande användningen av sociala nätverk, ett ökat utbud av Internet artefakter, önskan om att få tillgång till information överallt och närsomhelst och den massi- va ekonomiskalan för de stora Internetföretagen har bidragit till att suget efter Cloud Computing blivit en verklighet.
Företagen ska i teorin inte behöva oroa sig över vem som underhåller och uppda- terar systemen. Detta eftersom tjänsteleverantören är beroende av att tjänsterna ska fungera snabbt, effektivt och utan problem, då det annars kan orsaka stor ska- da hos både kunden och leverantören om systemen inte presterar som de förväntar (Arnold, 2009; Yoshino et al, 2008).
Vaquero et al (2009, s.51) har myntat ett förslag för en definition av Cloud Com- puting. Förslaget lyder:
“Clouds are a large pool of easily usable and accessible virtua- lized resources (such as hardware, development platforms and/or services). These resources can be dynamically re- configured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typi- cally exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs.”
Iasa (International Association of Software Architects) har också definierat Cloud Computing. Deras formuleringar lyder enligt följande:
”Cloud Computing karaktäriseras av två viktiga egenskaper;
upplevt oändliga resurser och betalning per resursförbrukning.
Den tjänst som erbjuds av molnet kallas Utility Computing, vil- ket närmast kan jämföras med resursförbrukning av till exempel el och vatten.”
11
”Termen Cloud Computing relaterar både till applikationer som levereras som tjänster över Internet och till den hårdvara och systemmjukvara som tillhandahåller dessa tjänster.”
Trots att begreppet Cloud Computing ses som ganska oklart av många, även bland branschfolket, och att definitionerna skiljer sig från varandra så pekar ändå det mest åt samma håll: det vill säga att Cloud Computing erbjuder ett alternativ till företag där man kan köpa in IT på kran till pay-asthey-go modellen efter sina egna önskemål.
2.2.1 Software as a Service (SaaS)
I en rapport av SIIA (2004), SOFTWARE AS A SERVICE: CHANGING THE PARADIGM IN THE SOFTWARE INDUSTRY, definieras SaaS grovt som en referens till vilken modell som helst som bygger på åtkomsten av mjukvaruappli- kationer via nätverk. Applikationerna i SaaS finns på ett externt datacenter där de blir underhållna av tjänsteutvecklarna. Från det externa datacentret kommer an- vändarna åt applikationerna via sina egna webbläsare. SaaSs affärsmodell talar om en ”en till många” leveransmodell där applikationerna är delade över alla kunders användare. Detta medför en minimal mängd av applikationsförändringar för att undvika stora implementerings- och integrationskostnader. En nyckelpremiss för denna modell är att företaget som levererar SaaS-tjänster investerar i teknologin, hårdvaran och den pågående supporttjänsten istället för att kunden ska behöva göra detta. Som gengäld betalar kunden enligt ”pay-asthey-go” modellen för pre- numerationen av Service-Level Agreement som försäkrar kunden om en specifik prestandanivå och försäkrar tillgänglighet. Detta resulterar i att företaget som le- vererar SaaS-tjänsterna får en långsiktig relation till kunden/kunderna.
2.2.2 Infrastructure as a Service (IaaS)
IaaS sköts av en infrastrukturleverantör (infrastructure provider) som genom till- gång till stor datakapacitet sköter processer som till exempel lagring och bearbet- ning. Genom virtualisering har infrastrukturleverantörerna möjlighet att dela upp, ge åtkomst åt och dynamiskt ändra storleken på denna datakapacitet för att kunna bygga system efter tjänsteleverantörens (service provider) krav. Tjänsteleverantö- ren distribuerar i sin tur sedan den uppdelade datakapaciteten till kunden som där- efter kan använda datakapaciteten för att köra sina tjänster (Vaquero et al, 2009).
2.2.3 Platform as a Service (PaaS)
Vaquero et al (2009) menar att med PaaS tillgängliggörs ytterligare en abstrak- tionsnivå. Istället för att som med IaaS endast förser kunden med en virtuell infra- stuktur så möjliggör PaaS en hel mjukvaruplattform för kunden som denne kan köra sina system på. Kraven för storleken på hårdvaruresurserna bestäms efter hur stor datakapacitet som krävs för utförandet av de specifika tjänsterna i det aktuella fallet, detta kan variera. Ett välkänt exempel på denna teknik är Google Apps Eng- ine.
12 2.2.4 Systemförvaltning av cloudtjänster
Med Cloud Computing blir själva systemförvaltningen av cloudtjänster osynlig för den vanliga användaren skriver Yoshino et al (2008).
Yoshino et al (2008) beskriver att i en systemförvaltning för cloudtjänster så ingår tre huvudsakliga mål. Dessa mål är vanliga åtgärder, underhållsåtgärder och akuta åtgärder.
Vanliga åtgärder
Vanliga åtgärder är åtgärder som utförs under normala omständigheter. Dessa kan till exempel vara; omstart av hela eller delar av system, backup av data för att för- hindra bortfall vid eventuella systemfel, samla in systemstatistik för vidare utvär- dering av system och borttagning eller delvis borttagning av data (Yoshino et al, 2008).
Underhållsåtgärder
Underhållsåtgärder är åtgärder som utförs när system behöver underhållas. Exem- pelvis uppdatering av hårdvara eller mjukvara och ändring av systemkonfiguratio- nen (Yoshino et al, 2008).
Akuta åtgärder
Akuta åtgärder är åtgärder som utförs vid systemfel och vid avvikelser i systemet som kan leda till eventuella systemfel. Exempel på dessa åtgärder är övervakning av system och respons på funktionsfel (Yoshino et al, 2008).
13
3 Metod
I detta kapitel presenteras de ansatser denna undersökning bygger på, utvärde- ring och kritisk granskning av de använda metoderna, validitet och reliabilitet för våra data i undersökningen.
3.1 Vetenskapligt förhållningssätt
Patel & Davidson (2003) menar att det finns två olika förhållningssätt, dessa är deduktion och induktion.
Det deduktiva arbetssättet beskrivs genom att från befintliga teorier dra egna slut- satser om enskilda fall. Från befintlig teori förklaras hypoteser som prövas empi- riskt mot det aktuella fallet (Patel & Davidson, 2003).
Det induktiva arbetssättet däremot förklaras genom att en forskning genomförs utan att först ha förankrat forskningen i en tidigare publicerad teori, och sedan utifrån den insamlade informationen formulera en egen teori (Patel & Davidson, 2003).
Vi har valt att utgå från befintliga teorier när vi utfört vår undersökning på vårt företag. Därför passar det deduktiva arbetssättet vår undersökning bäst.
3.1.1 Kvalitativ eller kvantitativ studie?
En kvalitativ metod förklarar Patel & Davidson (2003) som en metod för att under en undersökning få en djup inblick inom det valda området utifrån ett helhetsper- spektiv. Det är vanligt att det skrivs dagbok under arbetets gång då det senare blir möjligt att gå tillbaka och för att se sina dåvarande tankar och reflektioner från ett nytt perspektiv. Arbetet sker med löpande analyser av det insamlade datat för att precis som med dagboken kunna gå tillbaka och se på saker med nya ögon. I me- toden tolkas och förstås den aktuella informationen som insamlats med hjälp av bland annat intervjuer med respondenter.
Kvantitativa metoder, till skillnad från sin motsats kvalitativa metoder, bygger på ett statistiskt synsätt. Metoden kan användas som ett verktyg för att ordna, beskri- va, bearbeta och analysera data. Tillvägagångssättet för datainsamlingen sker ge- nom ett stickprov i en delmängd för att ge ett generaliserat resultat som kan speg- las över en hel population. Detta sker mestadels genom enkätutskick (Patel & Da- vidson, 2003).
Vi har valt att utföra vår studie utifrån det kvalitativa synsättet eftersom vi anser att intervjuer är det bästa och enda sättet för oss att samla in och tolka informatio- nen som vi behöver för att utföra denna studie. Detta för att vi behöver få en dju- pare förståelse för hur systemförvaltning påverkas när tjänster baserade på Cloud Computing köps in och implementeras.
14
3.2 Fallstudie
Merrain (1994) skriver att en fallstudie är en undersökning av en specifik företeel- se. Exempel på det kan vara en person, ett skeende, en institution, en händelse eller en social grupp.
Patel & Davidson (2003) skriver att en fallstudie kan undersöka fler än ett fall, till exempel två företag. I fallstudien utgås det från ett helhetsperspektiv för att få en heltäckande informationsbild. Ofta kommer fallstudien till användning när proces- ser och förändringar ska undersökas.
En fallstudie är ett bra sätt för oss att arbeta med då vi försöker få förståelse för ett visst område där vi vill studera förändringar inom systemförvaltningen där de in- fört en tjänst baserad på Cloud Computing.
3.3 Val av undersökningsobjekt och intervjupersoner
Vi har valt att göra vår undersökning hos ett företag, verksamt inom IT-branschen, som levererar och utvecklar tjänster baserade på Cloud Computing.
Kriterierna för val av företag har varit att:
• Företaget ska bedriva en näringsverksamhet inom IT-branschen
• Företagets storlek är begränsad till små och medelstora företag, där antalet anställda inte överstiger 250 och den årliga omsättningen inte överstiger 400 miljoner kronor
• Företaget ska leverera cloudtjänster
• Företaget ska ha ett flertal kunder.
För att respondenterna ska kunna ge svar på våra intervjufrågor har vi ställt upp följande kriterier på respondenterna:
• De ska ha varit anställda på företaget i minst två år
• De ska ha erfarenhet av cloudtjänster
• De ska ha insyn i hur cloudtjänsterna förvaltas.
3.4 Datainsamling
Patel & Davidson (2003) menar att det finns olika sätt att samla in information för att få frågeställningar besvarade. Det går att använda sig av befintliga dokument, test och prover av olika slag, olika former av självrapporteringar, attitydskalor, observationer samt intervjuer och enkäter. De menar att det inte finns någon abso- lut sanning om vilken metod som är mest effektiv, utan att det skiljer sig från fall till fall utifrån vilken tid och vilka medel som forskarna i fråga har tillgång till.
15 Trost (2005) menar att kvalitativa intervjuer kan karaktäriseras genom att beskriva intervjuerna som raka och enkla. Med raka och enkla frågor kommer komplexa och utförliga svar. Detta som i sin tur leder till att ett rikt material införskaffas.
Material som senare kan användas i analyser för att finna till exempel intressanta åsikter och vyer.
Med strukturerade intervjuer menar Trost (2005) intervjuer med fasta svarsalter- nativ. Det vill säga att den tillfrågade endast kan svara på frågorna enligt ett förut- bestämt mönster skapat av frågekonstruktören. Om svarsalternativen istället är öppna så heter det att intervjun är ostrukturerad. I dessa intervjuer är det mer van- ligt att följande termer förekommer: ofta, sällan och aldrig istället för dygn, må- nad och år som annars oftast skulle förkomma i en strukturerad intervju. I forsk- ningssammanhang så är det strukturering som förekommer i en hög grad.
3.4.1 Intervjuer
Vi har valt att utföra en blandning av en strukturerad och en ostrukturerad inter- vju. I denna intervju kommer vi att ha ett förutbestämt mönster för svaren, dock så finns det plats för våra eventuella följdfrågor för att mer ingående komma in på vad vi faktiskt vill veta.
Vi har utformat ett frågeformulär utifrån våra teorier som vi ska använda mot re- spondenterna. Som respondenter har vi valt ut två personer från det distribuerande tjänsteföretaget som vi kommer utföra våra intervjuer på. Intervjuerna kommer att vara av en kvalitativ art då vi vill att svaren ska ge en grundlig inblick inom pro- blemområdet så detta kan bidra till ett svar på vår forskningsfråga.
Vi bokade in ett personligt möte med respektive respondent för att kunna utföra intervjuerna. Vi kom överens med respondenterna att varje möte skulle få ta unge- fär en timme av deras tid. Inför respektive möte skickade vi ut frågorna, som vi skulle ställa vid respektive intervjutillfälle, så att respondenterna skulle kunna förbereda sig inför frågorna. Vid de två intervjutillfällena började vi med att pre- sentera oss själva, vi berättade kort om vilken utbildning vi går och lite samman- fattat om vad vår undersökning handlar om och vad vi försökte få fram för resultat med den. Varje intervju spelades in för att senare möjliggöra en bättre samman- ställning av de empiriska data som framkom från respektive respondent.
Eftersom vi utförde intervjuerna efter en blandning av en strukturerad och en ostrukturerad form så följdes svaren på intervjufrågorna med ytterligare följdfrå- gor för att komma djupare in på ämnet och rikta respondenten så att denne skulle kunna svara på det som vi ville visa med undersökningen. Efter vi skrivit ner data från inspelningarna till text så uppkom vissa tomrum som inte blivit besvarade, detta löstes genom att skicka följdfrågor via e-post till respondenterna.
16
3.5 Analysmetod
Patel & Davidson (2003) skriver att analysera innebär att bearbeta och tolka den insamlade informationen med hjälp av teorier för att kunna svara på sin problem- ställning.
För att kunna analysera det insamlade data ska vi använda oss av en kvalitativ bearbetningsmetod. Den kvalitativa bearbetningen menar Patel & Davidson (2003) är när man till exempel bearbetar intervjun utifrån det nerskriva textmate- rialet. Detta för att ge oss en djupare kunskap inom problemområdet.
När det kommer till kvalitativ bearbetning finns det ingen bestämd metod för hur bearbetningen går tillväga. Det finns många olika varianter av tillvägagångssätt att välja bland, detta ger utrymme till egna lösningar och angreppssätt. För att detta ska kunna fungera måste författaren/författarna dokumentera hur de gått tillväga metodiskt för att läsaren ska kunna följa arbetsgången (Patel & Davidsson, 2003).
Det kan vara praktiskt att sköta analysen löpande, forskaren bör börja med analy- sen direkt efter intervjun för att få nya idéer om hur forskaren ska gå vidare med undersökningen. En annan fördel med löpande analys är att forskaren får ett le- vande förhållande till sitt material som han/hon annars inte skulle få om den- ne/denna väntade med analysen till dess att all data var insamlad (Patel & Davids- son, 1994).
3.5.1 Tillvägagångssätt vid analys
För att utföra vår analys har vi skapat en egen mall för hur vi skall gå tillväga för att bearbeta det införskaffade materialet vi tagit fram via datainsamlingen.
Genom att jämföra data från vår teori mot vårt empiriska material kan vi se skill- nader och likheter i en systemförvaltning. Vi har fokuserat analysen på roller och förvaltningsaktiviteter.
Vi ställde upp de teoretiska data mot de empiriska data under analyskapitlet för att förenkla analysarbetet. Under själva analysen så jämförde vi det som vår teori beskrev mot för hur vi hade tolkat ett verkligt fall för att kunde urskilja likheter och skillnader i hur en systemförvaltning bedrivs. Utifrån detta har vi kunnat dra slutsatser för att svara på vår forskningsfråga om förändringar i en systemförvalt- ning med Cloud Computing.
3.6 Validitet och reliabilitet
Validitet handlar om hur väl en undersökning överensstämmer med det som fak- tiskt ska undersökas. Det är ett mått på om det vi studerar eller mäter faktiskt är det vi verkligen tror oss mäta (Patel & Davidson, 1994; Merriam, 1994).
Med reliabilitet mäts i vilken utsträckning forskarens resultat kan upprepas, det vill säga att om resultatet kommer att vara detsamma som det ursprungliga resul- tatet om undersökningen skulle utföras igen. Reliabiliteten i en specifik forsk-
17 ningsmetod bottnar i antagandet att det endas finns en enda verklighet som kom- mer att ge samma resultat om denna verklighet studeras om och om igen (Merri- am, 1994).
Validitet och reliabilitet är två begrepp som till viss del hör ihop. Om vi med reli- abilitet mäter något specifikt kan vi inte utan validitet vara säkra på att det vi mä- ter faktiskt är det vi tror att vi mäter. Vi kan därför inte bara fokusera oss på det ena begreppet utan vi måste ta de båda i beaktning. Alltså så är hög reliabilitet är ingen garanti för hög validitet och fullständig reliabilitet är en förutsättning för fullständig validitet (Patel & Davidson, 1994).
För att uppnå hög validitet så har vi under våra intervjuer försökt hålla oss till vår intervjumall så att respondenterna inte haft möjlighet till att sväva iväg och prata om egna intressen utan att mer begränsa dem att prata kring vår ställda fråga. In- tervjuer med respondenterna spelades in, för att vi i senare skede skulle minska risken för misstolkning av informationen från respektive respondents svar. Sam- manställning och analys påbörjades direkt efter respektive intervju. Därefter har vi gått igenom materialet ytterligare några gånger, för att undvika eventuella miss- uppfattningar och för att säkerställa en så ren data som möjligt. Respondenterna som vi valde har haft god kännedom inom ämnet.
Till vår litteraturstudie har vi enbart använt oss av tillförlitliga källor från böcker och aktuella rapporter och artiklar. Dessa källor har kommit från ett flertal förfat- tare för att undvika att felaktig fakta insamlats.
För att öka reliabiliteten i vår undersökning har vi tänkt på vissa punkter. Vi har läst in oss på det aktuella ämnet innan intervjuerna utfördes detta för att minska den egna tolkningen och få bättre förståelse för respondenternas svar. Vår fråge- mall är skapad utifrån våra teorier för att vi ska kunna hålla frågorna inom ämnet vilket underlättar för eventuella framtida arbeten. Vi har under intervjuerna också ställt följdfrågor till respondenterna för att komma djupare in på ämnet vilket le- der till en bättre analys.
18
4 Empiri
Syftet med det här kapitlet är att presentera de empiriska data som har blivit in- samlat under intervjuerna. Först presenteras företaget och därefter responden- terna som intervjuerna utförts på. Till sist presenteras sammanställningen av de empiriska data vi samlat in.
4.1 Presentation av företag
eBuilder AB är ett multinationellt utvecklingsföretag verksamt inom IT-branschen med huvudkontor i Stockholm. Företaget skapades år 2006 efter att Markanda och Parcelhouse valt att slå sig samman. eBuilder AB har idag 140 anställda med kon- tor i Sverige, Sri Lanka och Australien och omsätter ca 80 miljoner kronor. Dess kundkrets sträcker sig över 50 länder i fem kontinenter och innefattar mer än en halv miljon användare. Företaget riktar sig mest mot den offentliga sektorn.
eBuilder ABs affärsidé bygger på att förse kunder med de snabbaste tillgängliga verktygen för att tillhandahålla och underhålla kundernas end-to-end affärsproces- ser. Detta möjliggörs via Cloud Computing/SaaS som genom att sammanföra ak- törer med varandra i en standardiserad affärsprocess via Internet. Det kan t ex handla om en komplett inköps- eller reseprocess eller att se till att en leverans sker enligt avtal.
eBuilder AB erbjuder följande tjänster:
Supply Chain Accelerator
Tjänsten ger kunden tillgång till ett system som består av en leveranskedjas stan- dardiserade processer och dess logistikfunktioner som företaget tillhandahåller, underhåller och tillgängliggör över Internet.
Travel Accelerator
Tjänsten automatiserar och rationaliserar administrationen kring end-to-end tjäns- tereseprocessen. Detta inkluderar reseprofiler, bokningar, godkännande, kostna- der, ersättning och betalning samt faktureringskontroll.
Procurement Accelerator
Tjänsten automatiserar transaktionen mellan köpare och säljare. Kunden väljer och definierar deras valda utbud av leverantörer och deras regler för affärsuppgö- relse för att försäkra upphandlingsprocessen mot de överenskomna policyerna, priserna, standarderna med mera
Customized Accelerator
Vid val av tjänst identifieras, optimeras och automatiseras unika kundprocesser som inte hamnar under någon av företagets standardtjänster. Tjänsten assisterar kundernas organisationer genom att kartlägga deras unika processflöden och möj-
19 liggöra hanteringen av deras organisation för att vidare kunna utveckla arbetsflö- den.
4.2 Presentation av respondenter
Här beskrivs de valda respondenterna från företaget som vi utfört våra intervjuer på för samla in data till vår empiriska undersökning.
4.2.1 Respondent A
Respondent A har arbetat fyra år inom företaget. Respondenten är en man i me- delåldern, han har varit aktiv inom IT-branschen sedan tidigt 90-tal. I dag arbetar han som processdesigner, arkitekt och projektledare inom företaget.
4.2.2 Respondent B
Respondent B har funnits med sedan företaget bildades år 2004. Respondenten är en man i medelåldern. Han har arbetat med att utveckla processer sedan -96 men har arbetat inom branschen med systemutveckling sedan -89. Respondenten arbe- tar idag som management konsult samt process- och verksamhetsutvecklare. Han har som grund en utbildning inom systemutveckling.
4.3 Sammanställning av den empiriska undersök- ningen
Här presenteras en sammanställning av svaren från vår empiriska undersökning.
Vi har slagit ihop svaren från respondenterna från tjänsteleverantören då vissa frågor gav överlappande svar. Detta för att ge en förenklad bild över hur verklig- heten ser ut i organisationen.
Vad tjänar kunden på att byta till era tjänster?
Kunden vinner på att den inte längre behöver underhålla systemen för den aktuella tjänsten, de senaste uppgraderingarna finns alltid tillgängliga. Hårdvarudelen för- summas och nyttan effektiviseras. Tid och pengar sparas. Tiden som sparas kan läggas på kundvärdeskapande arbete.
Är det vanligt att kunden tidigare har haft en egen applikation/system för denna process?
Oftast har kunden inte haft ett eget datasystem som täcker upp hela denna process, de kan dock ha haft manuella rutiner för arbetet. Om vi levererar 100 % nytta så hade kunden kanske 40 % sen tidigare eller kanske 60 % i ett eget system, men aldrig 100 %. Då hade de aldrig behövt handla av oss. Det är sällan att någon by- ter ut hela system.
Hur påverkar era tjänster kundens systemförvaltning?
20 Nya arbetsroller uppkommer och vissa gamla byts ut, till exempel så blir system- ägaren processägare/processledare i den nya systemförvaltningen av tjänsten. I vissa fall blir avdelningschefen processägare/processledare.
Kunden kan släppa vissa delar. De behöver inte drifta allt, men det ställs krav på dem att de ska förstå kopplingarna vid eventuell integration där data måste skickas och tas emot. Kunden får ett ansvar att se till att sina egna bitar håller kvalitet. De arbetar tillsammans och kräver att kunden ska ha koll på sitt.
Kunden kan inte bara ändra i ett av sina egna system då det kan få konsekvenser för hela processen. Då cloudtjänster ibland interagerar med kundens interna sy- stem, till exempel ekonomisystem kontra inköps/fakturasystem, kan det ställa krav på kunden och de system de behåller.
Tar ni över några arbetsuppgifter direkt när tjänsten/tjänsterna införs?
Nej, det är sällan vi tar över några arbetsuppgifter. Vi tillför nya. Vi tar oftast inte över alla system så kunden fortsätter förvalta sina system som de redan har sen tidigare. Beroende på om kunden tidigare haft en befintlig applikation för delar av denna process så tar vi över förvaltningen.
Har kunden någon speciell person som kontaktar er angående till exempel systemfel och problem över användarnivå?
Kunden behöver ha en speciell kontaktperson. Det är en förutsättning för att tjäns- ten ska fungera. Det blir processägaren/processledaren som tar rollen som krav- ställare och kontaktperson. Processägaren/processledaren ställer krav på processen och på systemstödet behöver finnas.
Förvaltar ni systemen som ni erbjuder kunderna separat från era egna sy- stem? Ligger det inom samma systemförvaltning?
Hårdvaran outsouras till samma driftleverantör. Men eftersom kundens lösningar ligger på andra miljöer så körs de på olika maskiner. Idag arbetar man mycket med virtualisering, flera kunder kan köras på samma server, alltså så behövs det inte en server per kund. Förvaltningen sköts inte av samma personer.
Vilka arbetsroller har ni för att hantera och underhålla era tjänster åt kun- derna?
Inom organisationen:
Business Organisation: Business Manager och Business Developer.
Assigment Organisation: Solution Manager, Support Team, Development Team, Maintenance Team, Operation Team och Project Manager.
Hos kunden:
21 Customer Relationship Management Team: Relationship Management och Ser- vice Management (world wide).
Kan du beskriva dessa arbetsroller?
Inom Assigment Organisation ligger en tredelad supportorganisation. Supportor- ganisationen är uppdelad i Firstline, Secondline och Thirdline. I Firstline arbetar Support Team, i Secondline arbetar Development Team och Maintenance Team och i Thirdline arbetar Operation Team. Project Manager ansvarar för projekten och Solution Manager ansvarar för produkten.
I Business Organisation arbetar Business Manager och Business Developer. Dessa två har kontakt med Customer Relationship Management Team som ligger hos kunden.
Vilka förvaltningsaktiviteter utför dessa arbetsroller?
I Firstline arbetar Support Team med att ta emot alla inkommande frågor från kunderna, de besvarar bara själva de enklare frågorna kring användargränssnittet och återkopplar direkt till användaren. De mer avancerade vidarebefordrar de ner- åt i supporthierarkin.
I Secondline sköter Development Team vidareutvecklingar och förbättringar av tjänsten och Maintenance Team sköter driften och utför enklare förändringar av tjänsten som inte berör direkt utveckling.
I Thirdline arbetar Operation Team med att felsöka buggar för att hitta problem.
Problem som de senare rättar till. En ny patch släpps för att uppdatera kundens system.
Project Manager leder projekt inom utveckling av nya funktioner i tjänsterna. När tjänsten är införd hos kunden blir Project Manager förvaltningsledare.
Solution Manager sköter användarutbildningen hos kunden. Är det många inblan- dade i projektet utbildar man bara några utvalda som i sin tur får till uppgift att utbilda de andra, i mindre projekt utbildas alla inblandade.
Business Manager och Business Developer sköter affärsdiskussionen vid änd- ringsbegär med Customer Relationship Management Team som ligger hos kunden där krav och kostnader diskuteras. Dessa parter sköter även kontakten på affärsni- vå gällande avtal med mera.
Samma person inom organisationen kan ha flera olika arbetsroller.
22
5 Analys
I detta kapitel presenteras analysen av arbetsroller, förvaltningsaktiviteter och systemförvaltning av cloudtjänster som ingår i en systemförvaltning som insam- lats i empiri och jämförs mot teori för att se skillnader och likheter.
5.1 Roller
I teorin skrivs det att i en systemförvaltning delas arbetsuppgifterna upp i olika roller som personalen tilldelas. Detta skiljer sig i vårt företag där rollerna inte är specificerade, med några undantag. De har valt att dela upp arbetet i olika team som ansvarar för flera olika arbetsuppgifter. Dessa team går dock att koppla till vissa av teorins olika roller eftersom teamen utför liknande arbetsuppgifter som rollerna har. Vissa team kan kopplas till flera roller då teamen har större bredd på arbetsuppgifterna än vad enskilda roller har. Som i teorin kan en person i företaget vid olika tillfällen tillhöra flera team och då utföra andra arbetsuppgifter till ex- empel så kan en person både vara kontaktperson för avtalsdelen men även vara aktiva i en del av supporten.
Teorin säger om outsourcing att när delar av systemet outsourcas till en extern part så kan även vissa arbetsuppgifter flyttas, det medför att rollerna kan ligga hos olika parter. I vårt fall ligger till exempel driftleverantören hos hårdvaruleverantö- ren, en kontaktperson som agerar kravställare hos kunden och förvaltningsdelen av tjänsten hos tjänsteleverantören.
5.1.1 Solution Manager och Project Manager Empiri
Solution Manager sköter användarutbildningen hos kunden. Är det många inblan- dade i projektet utbildar man bara några utvalda som i sin tur får till uppgift att utbilda de andra, i mindre projekt utbildas alla inblandade.
Project Manager leder projekt inom utveckling av nya funktioner i tjänsterna.
Teori
Förvaltningsledaren deltar vid förvaltningsmöten där bland annat förslag på för- bättringar ges och kostnads- och lösningsförslag tas fram. Han sköter kvalitetssäk- ringen av förvaltningsarbetet och uppdaterar förvaltnings- och systemdokument.
Han förbereder driftsättningar och systemändringar och upprättar konfigurations- planer och releaseplaner. Han ansvarar för resultatet vid ändringsarbeten och medverkar vid olika utredningar. Det är han som har den yttre kontakten med sy- stemägaren och/eller systemansvarige (Brandt, 2004).
Analys
Project Manager blir efter slutfört projekt Solution Manager mot sin kund. Solu- tion Manager ansvarar likt som teorins förvaltningsledare för att användarutbild- ningen håller kvalitet och ser till att rätt personer får rätt utbildning.
23 5.1.2 Development Team, Maintenance Team och Operation Team Empiri
Development Team arbetar i supportavdelningen Secondline med att sköta vida- reutveckling och förbättring av tjänsten.
Maintenance Team arbetar i Secondline och sköter driften och utför enklare för- ändringar av tjänsten som inte berör direkt kodning.
Operation Team arbetar i Thirdline med att felsöka buggar för att hitta problemet.
En ny patch släpps för att uppdatera kundens system.
Teori
Systemförvaltaren ansvarar för att ändringar genomförs, han medverkar i änd- ringsarbetet där han bland annat uppdaterar ändringsdatabaserna och genomför tester för dessa ändringar. Han ser till att avtalad kvalitet på systemet upprätthålls och vid eventuella avbrott och incidenter så sköter han uppföljningsarbetet av des- sa. Han ser till att systemdokumenten är aktuella och rapporterar dessa till förvalt- ningsledaren. Han medverkar vid framtagning och diskussioner kring kostnader och lösningar (Brandt, 2004).
Analys
Development Team, Maintenance Team och Operation Team kan jämföras med teorins systemförvaltare. Då systemförvaltaren leder och medverkar i ändringsar- betet och avrapporterar till förvaltningsledaren och/eller chefen för systemförvalt- ningen och får i huvudsak arbetsuppgifter från systemansvarig.
5.1.3 Processägare Empiri
Processägaren finns hos kunden och arbetar som kravställare för att se till att kra- ven på tjänsten uppfylls av leverantören.
Teori
Informationsägaren har som ansvar att ta fram informationsbudget och genomföra nyttovärderingar på systemet för att se till att informationen stödjer verksamheten.
Han fullföljer säkerhetspolicys och ser till att nyttjandet av informationen inte bryter mot det utformade regelsystemet. I regelsystemet ansvarar han också för att se till att uppdateringar, ändringar och kontroll av informationen sköts på ett kor- rekt sätt (Brandt, 2004).
Systemägaren ansvarar bland annat för att skapa budget och planer för hur sy- stemförvaltningen ska genomföras. Det är han som ser till att förvaltningsstrategi och säkerhetspolicy används enligt förutbestämda regler för systemet. Han har det yttersta ägaransvaret för systemet och ser till att det stödjer verksamhetens krav fullt ut. Han sköter även den affärsmässiga kontakten med produktägaren (Brandt, 2004).
24 Analys
Teorin säger att i en vanlig systemförvaltning finns det oftast en systemägare som har det yttersta ansvaret för systemet. I vårt fall, när Cloud Computing införs, så får den nya tjänsten en processägare som ansvarar för hela processen istället för en systemägare som teorin beskriver. Processägaren finns hos kunden. Pro- cessägaren kan även delvis kopplas till teorins informationsägare eftersom många av informationsägarens huvuduppgifter och befogenheter överlappar med pro- cessägarens. Exempelvis så är det processägaren som utför nyttovärderingarna.
5.1.4 Business Manager och Business Developer Empiri
Business Manager sköter affärsdiskussioner gällande affärsavtal med kunden.
Business Developer sköter affärsdiskussionen gällande ändringsbegär av tjänsten med kunden.
Teori
Produktägaren följer i sitt arbete den gällande systemförvaltningsstrategin för sin produkt där han också ansvarar för dens informationssäkerhet. Han sköter vidare- utbildning av produktens användare och samordnar med de andra produktägarna.
Han tecknar avtal med systemägaren och ansvarar för att lokala system- och an- vändardokument är aktuella (Brandt, 2004).
Analys
Utifrån sättet som teorin beskriver roller kan både Business Manager och Busi- ness Developer delvis jämföras med teorins roll produktägare eftersom denne har som huvuduppgift att bland annat teckna avtal med systemägaren som i vårt fall blir processägaren.
5.1.5 Support Team och Driftleverantör Empiri
Support Team arbetar i supportavdelningen Firstline med att ta alla inkommande frågor från kunderna, de besvarar bara själv de enklare frågorna kring användar- gränssnittet och återkoppla direkt till användaren. De mer avancerade vidarebe- fordrar de neråt i supporthierarkin.
Driftleverantören finns hos ett externt företag och står för driftorganisationen där de har som uppgift att se till att servrar och nät är uppe i drift.
Analys
Rollen driftleverantör kan inte kopplas till teorins beskrivna roller då den endast ansvarar för den hårda biten, det vill säga upprätthållande av servrar och nät. Inte heller kan teamet Support Team kopplas till någon av teorins roller då de i princip endast är telefonister som agerar som användarstöd och fördelar supportärenden neråt i supporthierarkin.
25
5.2 Förvaltningsaktiviteter
Teorin säger att med outsourcing behöver inte kunden sköta förvaltning av syste- met utan en extern konsultfirma kan ta över förvaltningsarbetet för de tjänster som organisationerna väljer att lägga ut till en konsultfirma mot betalning. I vårt fall så ligger hela förvaltningen av applikationerna utlagt på tjänsteleverantören bortsett från en aktivitet, det vill säga kravställning på tjänsten som ligger kvar hos kun- den. Upprätthållandet av hårdvaran och nätet ligger outsourcad till tredje part.
5.2.1 Förvaltningsstyrning Empiri
Affärsdiskussioner sker vid ändringsbegäran eller avtalsförändring av kund där krav och kostnader diskuteras.
Teori
Förvaltningsstyrningen innebär mestadels verksamhetsplanering av systemför- valtningsverksamheten samt operativ styrning och ledning, det vill säga beställ- ningar, prioriteringar, omvärldskontakter och möten med användare. Det innebär också uppföljning av överenskomna mål och beslut om olika åtgärder för att kor- rigera möjliga avvikelser i förvaltningsobjektet (Nordström & Welander, 2007).
Analys
I teorin beskrivs förvaltningsstyrningen som sätt att hantera kundrelationer mellan kund och leverantör. Vårt företag utför delar av sin förvaltning på ett liknande sätt som teorin beskriver nämligen genom att via bestämda kontaktpersoner utföra dialoger mellan kund och eget företag om ändringshantering där krav och kostna- der diskuteras. Även avtalsuppgörelser sköts på detta sätt när omförhandlingar vid eventuella kontraktförlängningar.
5.2.2 Användarstöd Empiri
Supporten tar emot alla inkommande frågor från kunderna, de besvarar de enklare frågorna kring användargränssnittet och återkopplar direkt till användaren.
Användarutbildningen hos kunden sker i förvaltningen Är det många inblandade i projektet utbildar man bara några utvalda som i sin tur får till uppgift att utbilda de andra, i mindre projekt utbildas alla inblandade.
Teori
Användarstöd är ofta en dold aktivitet i förvaltningsarbetet men som oftast kräver stora resurser. Olika uppdrag som ingår inom användarstöd kan vara att hjälpa användare med ett IT-system, att utbilda användare inom IT-system, ändra använ- dardokumentation och att informera användaren om driftstatus. Den huvudsakliga uppgiften ligger dock på att utbilda och informera slutanvändaren genom att be- svara dess frågor och agera support (Nordström & Welander, 2007).
