Teoretisk mognadsgrad vid konsolideringar av informationssystem: en fallstudie vid ett energiföretag

EXAMENSARBETE

SYSTEMVETENSKAPLIGA PROGRAMMET • C-NIVÅ Institutionen för Industriell ekonomi och samhällsvetenskap Avdelningen för Systemvetenskap • Informatik och systemvetenskap

MARKUS ERIKSSON LARS LINDGREN

2003:112 SHU

Teoretisk mognadsgrad vid konsolideringar av

informationssystem

En fallstudie vid ett energiföretag

Samhällsvetenskapliga och ekonomiska utbildningar

Teoretisk mognadsgrad vid konsolideringar av informationssystem - En fallstudie vid ett energiföretag

Theoretical maturity in consolidations of information systems - A case study of an energy company

Examensarbete utfört inom ämnesområdet Data och systemvetenskap vid

Luleå tekniska universitet

av

Markus Eriksson

Lars Lindgren

Luleå 2003-05-23

Förord

Denna rapport är ett examensarbete i systemvetenskap vid Institutionen (IES) och avdelningen (Systemvetenskap), Luleå Tekniska Universitet. Studien är gjord i samarbete med Vattenfall Norrnät och Mari Runardotter har fungerat som vår handledare.

Vi vill tacka Peder Ström på Vattenfall Norrnäts IS/IT-avdelning för att han generöst bidragit med sin tid och hjälpt oss i vårt arbete. Utan Peders engagemang hade det aldrig blivit någon undersökning. Vi vill även tacka vår handledare Mari Runardotter som alltid har stöttat oss i arbetet.

Sammanfattning

Vi lever idag i ett informationssamhälle, där mängden av information och informationssystem tenderar att öka med tiden. Företag strävar hela tiden efter en ökad kontroll av sina informationssystem och därför har begreppet ”konsolideringar av informationssystem” blivit ett populärt koncept. Begreppet är nytt och i dagsläget finns ingen sammanställd teori med åtgärdsförslag som företag kan nyttja i sina konsolideringsarbeten. Denna sammanställning har författarna till denna uppsats gjort. I uppsatsen sammanställs och kategoriseras de olika konsoliderings-teorierna, och en empirisk studie av ett företags teoretiska mognadsgrad gällande konsolideringar redovisas. Dvs. hur väl företaget, medvetet eller omedvetet, följer teoriernas föreskrifter i sitt konsolideringsarbete. Med hjälp av den empiriska studien dras slutsatsen att företaget har en mycket hög teoretisk mognadsgrad gällande åtgärdsförslag som involverar analytiska och tekniska aspekter. De har dock en låg teoretisk mognadsgrad gällande åtgärdsförslag som behandlar användaraspekter och datalagring. Inom dessa två områden finns det stora förbättringsmöjligheter i företagets arbete, enligt författarna till denna uppsats.

Sökord:

Konsolidering, serverkonsolidering, applikationskonsolidering, lagringskonsolidering, systemutveckling, systemintegration, centralisering, sammanställd teori.

Abstract

We are currently living in an information-society where the amount of information and information systems amongst companies tend to increase. Companies are constantly struggling to gain control over their information systems. Because of this, “consolidation of information systems” is a notion that has become a popular concept. It is a new notion and today there are no compiled measures in theory which companies can use in their consolidation projects, although that is one thing the authors of this paper intend to do. The authors of this paper have compiled and categorized the suggestions mentioned in different theories, and empirically investigated the theoretical maturity of a consolidation performed by a company, i.e. the degree to which the company, deliberately or not, follows the theoretical suggestions in their work. The result of the investigation shows that when it comes to the theoretical suggestions that involve analytical and technical aspects the company has a high degree of theoretical maturity. Although the degree of theoretical maturity is low when it comes to suggestions which involves users or data storage. In these two subject areas there are large contingencies to improve the work of the company, according to the authors.

Keywords:

Consolidation, server, application, storage, system development, system integration, centralization.

Innehållsförteckning

1 Inledning... 1

1.1 Bakgrund ... 1

1.2 Syfte ... 2

1.3 Problem/Forskningsfråga ... 2

1.4 Avgränsningar ... 2

2 Teori ... 3

2.1 Generellt om konsolidering... 3

2.1.1 Generella åtgärdsförslag vid konsolideringar ... 5

2.2 Serverkonsolidering ... 5

2.2.1 Åtgärdsförslag vid serverkonsolideringar ... 8

2.3 Lagringskonsolidering... 9

2.3.1 Åtgärdsförslag vid lagringskonsolideringar ... 10

2.4 Applikationskonsolidering ... 10

2.4.1 Åtgärdsförslag vid applikationskonsolideringar ... 13

3 Metod ... 14

3.1 Hermeneutiskt angreppssätt ... 14

3.2 Kvalitativ ansats ... 14

3.3 Fallstudie ... 15

3.4 Litteraturstudie ... 15

3.5 Tekniker för insamlandet av data ... 15

3.6 Kvalitet i kvalitativa studier ... 16

3.6.1 Kvalitativ bearbetning ... 17

3.7 Vårt metodarbete ... 18

Empiri... 22

3.8 Vattenfall... 22

3.8.1 IS/IT-avdelningen... 23

3.8.2 Vår kontaktpersons yrkesbakgrund... 24

3.8.3 Modell över IS/IT-avdelningens dagliga arbete... 25

3.8.4 Konsolideringsarbete... 27

3.8.5 Användarna ... 32

4 Analys... 34

4.1 Generella åtgärdsförslag vid konsolideringar ... 34

4.2 Åtgärdsförslag vid serverkonsolideringar ... 35

4.3 Åtgärdsförslag vid lagringskonsolideringar ... 37

4.4 Åtgärdsförslag vid applikationskonsolideringar ... 38

4.5 Sammanfattande analys... 39

5 Diskussion ... 40

5.1 Inledande diskussion ... 40

5.2 Generella åtgärdsförslag vid konsolideringar ... 40

5.3 Åtgärdsförslag vid serverkonsolideringar ... 41

5.4 Åtgärdsförslag vid lagringskonsolideringar ... 42

5.5 Åtgärdsförslag vid applikationskonsolideringar ... 42

6 Slutsatser ... 43

7 Fortsatt forskning ... 45

8 Litteraturförteckning ... 46

Bilagor:

Bilaga A: Intervju 1 med chefen på IS/IT-avdelningen.

Bilaga B: Intervju 2 med chefen på IS/IT-avdelningen.

Bilaga C: Intervju 3 med chefen på IS/IT-avdelningen.

Bilaga D: Intervju 4-7 med användare på Vattenfall Norrnät.

Bilaga E: Centrala system på Vattenfall Norrnät.

1 Inledning

I detta kapitel ger vi en bakgrund till vårt forskningsområde, där vi även återger teoriernas motiv till att konsolideringar idag är en trend. Efter bakgrunden specificerar vi rapportens syfte, forskningsfrågor och avgränsningar.

1.1 Bakgrund

I och med IT: s¹ framfart så har organisationers informationsstrategier², förändrats under årens lopp. I mitten av 1980-talet ansåg företag superdatorer som framtidens teknik för databehandling, de centraliserade därför sina informationssystem. Detta perspektiv ändrades dock i början av 1990-talet, då företag decentraliserade organisationen över sina informationssystem för att snabbare kunna överföra produkter till marknaden (Ambler, 2002).

Företagen märkte dock att decentraliseringen snabbt ledde till ökade kostnader eftersom informationssystemen blev komplexa och svårhanterliga (Currid, 1996; Zrimsek, 2003), något som ledde till att man började standardisera och förenkla databehandlingen (McCune &

Jenny, 1994). ”Pendeln” började svänga tillbaka, dvs. företag började återgå till att centralisera sina informationsverksamheter, de började konsolidera. Företag kan inte längre ignorera kostnadseffektiviteten som finns i en konsolidering (von Simson, 1995) och därför avvecklar många företag i dagsläget sina gamla, komplicerade system och bygger nya, mindre komplicerade, billigare och förhoppningsvis mer effektiva system (McCune & Jenny, 1994).

För att illustrera detta har Gartner Group, ett oberoende företag som specialiserar sig på undersökningar gällande bl.a. konsolideringar, utfört en undersökning bland IT-managers, som visade att 69 % av affärsföretag försökte konsolidera servrar år 2001, detta är en uppgång på 36 % sedan 1998 (Chen, 2003). En annan undersökning, bland 57 av Sveriges IT-chefer, bekräftade att konsolideringar är en av de hetaste trenderna för 2003 (idg, 2003).

Konsolidering är ett begrepp som används inom en mängd olika vetenskapliga områden såsom informationsteknologi, geoteknik, ekonomi och medicin. Den gemensamma betydelsen av konsolidering inom alla ämnesområden är dock att: förstärka, göra fast, göra tät (Nationalencyklopedin, 2003). När det gäller konsolidering av informationssystem nämns ofta tre olika typer; server-, lagrings- (plattforms-) eller applikationskonsolidering. De tre typerna av konsolideringar är väldigt nära relaterade till varandra, med tanke på att en serverkonsolidering involverar att samla applikationer på en separat maskin och dela data i lagringspooler (Chu, 2003).

Litteratur inom ämnet föreslår att man ska följa vissa punkter/åtgärdsförslag när man genomför en konsolidering, bl.a. att man ska planera arbetet, fokusera på företagets affärsmål och ta hjälp av modern teknik (Hall, 1998; Phelps, 2002a; Whiting, 1997; Reimers, 2002;

Chen, 2003). Men blir företags konsolideringsarbeten mer lyckosamma om de följer dessa åtgärdsförslag?

1 IT, informationsteknik, även informationsteknologi (eng. Information Technology), samlingsbegrepp för de tekniska möjligheter som skapats genom framsteg inom datateknik och telekommunikation(Nationalencyklopedin, 2003).

2 Informationsstrategi är ett begrepp som innefattar verksamhetens informationsbehov, vilken information som ska lagras, vem som ansvarar för underhållet av databaser, vilka aktualitetskrav som gäller samt hur kostnader för uppläggning och underhåll av databaserna skall fördelas (Falk & Olve, 1996).

Vårt antagande är att ju fler av dessa åtgärdsförslag som företag följer desto smidigare blir konsolideringsarbetet att genomföra och desto bättre resultat nås vid dess färdigställande.

Syftet med vår uppsats är att undersöka ett företags teoretiska mognadsgrad, vilket vi definierar som den grad företaget, medvetet eller omedvetet, följer det konsolideringsteorier föreskriver. Anledningen till att vi valt att använda och definiera begreppet teoretisk mognadsgrad som vi gör grundas i vår rapports kvalitativa ansats, eftersom vi vill skapa en djup inblick i företagets konsolideringsarbete. Vår intention med begreppet teoretisk är inte att kartlägga ifall företag kan konsolideringsteorierna, utan intentionen är att undersöka huruvida deras konsolideringsarbete stämmer överens med det teorierna föreskriver, oavsett företagets kännedom om dem. Begreppet mognadsgrad använder vi för att tydliggöra att det finns nyanser i hur företag arbetar gentemot teoriernas föreskrifter. Vi vill således undkomma att företags förhållning till teorierna antingen är ”svart eller vitt”, utan det finns en gråskala däremellan.

Med detta som bakgrund har vi valt att undersöka ett verkligt konsolideringsarbete och hur de förhåller sig till de punkter som teorierna föreslår. Vår empiriska studie har utförts på energiföretaget Vattenfall. Vid vår första kontakt med Vattenfall, som i dagsläget genomför ett konsolideringsarbete, fick vi intryck av att de utför arbetet efter egna idéer och erfarenheter och inte efter konsolideringsteorier. Vår uppsats är alltså en jämförelse mellan företagets arbetsåtgärder och de teoretiska åtgärdsförslagen. Uppsatsen innehåller även en sammanställning av de åtgärder som teorierna föreslår vid de olika konsolideringarna som finns. Eftersom vår uppsats skett i samarbete med ett företag syftar den också till att hjälpa dem i deras fortsatta konsolideringsarbete.

1.2 Syfte

Vi vill studera den teoretiska mognadsgraden vid en konsolidering av informationssystem.

1.3 Problem/Forskningsfråga

Vilka punkter tar teorierna upp gällande konsolideringsarbeten?

På vilka sätt överensstämmer respektive skiljer sig företagets konsolideringsarbete från teorierna?

1.4 Avgränsningar

Vi kommer att fokusera vår undersökning på hur IS/IT-avdelningen på företaget utför ett konsolideringsarbete. Vi kommer även att komplettera undersökningen med synpunkter från anställda som berörs av konsolideringsarbetet. Vi kommer dock inte att undersöka alla anställda vid företaget utan gör ett urval bland dem. Studien kommer endast att genomföras vid det initiala skedet av konsolideringen.

2 Teori

I detta kapitel redogör vi för de teorier som kommer att ligga till grund för den jämförelse som uppsatsen syftar till att göra. Utifrån teorierna har vi strukturerat och sammanställt de olika åtgärdsförslag som föreslås.

De olika teorier som behandlar konsolideringar av informationssystem, delar upp ämnet i tre olika nivåer. Dessa är; server-, lagrings-, och applikationskonsolideringar (Fig. 1). De beskriver åtgärder för de enskilda uppdelningar men även gemensamma åtgärder som gäller för samtliga av dem, något som vi har valt att lägga under en egen rubrik och kalla - generellt om konsolidering. I denna del har vi även valt att lyfta upp åtgärder som olika teorier nämner inom de olika delarna. De åtgärdsförslag som vi nämner efter varje avsnitt är en sammanfattning och kan ses som goda råd eller riktlinjer för verksamheter som ska konsolidera sin IT-verksamhet.

Konsolidering

Applikationskonsolidering Lagringskonsolidering

Serverkonsolidering

Generellt om konsolidering

Fig. 1. Uppdelning av konsolideringar

2.1 Generellt om konsolidering

Huvudmotivet för konsolidering av IT-system är ofta att göra kostnadsbesparingar. IT- managers som flyttar ihop sina system till så få platser som möjligt gör att verksamheten som helhet oftast ser omedelbara kostnadsminskningar gällande anställda, licenskostnader, kostnader för inhyrning av kontor, och resekostnader. Konsolideringar kan även leda till att organisationer blir mer effektiva, en utdelning man kan se på tre sätt. För det första en mycket högre nivå av nätverkskontroll, något man uppnår genom att man kopplar ihop applikationerna inom den aktuella organisationen. För det andra så får verksamheten tillgång till bättre IS-specialister som lockas av den tekniska och den karriärmässiga utmaningen som konsolideringen ger. Den tredje, och den viktigaste, utdelningen när det gäller effektivitet är möjligheten att ta vara på affärsmöjligheter. Detta uppnår man på grund av de stordriftsfördelar organisationen får i och med en konsolidering (Carlyle, 1990).

Att integrera olika IT-kulturer och IT-system är emellertid svårt. Komplexiteten i informationssystemets miljö, storleken på investeringar som måste göras kan vara begränsande faktorer när det gäller att dra nytta av ett informationssystems fördelar. (Taylor, 1998). Ett annat problem kan t.ex. vara att anställda från olika avdelningar har satt ihop egna system och mjukvara, som duplicerar det som redan finns (McCune & Jenny, 1994).

Det som oftast bestämmer om ett konsolideringsprojekt blir lyckat är hur arbetet med analys och planering genomförs (Whiting, 1997). Därför är valet av dem som ska utföra förändringsarbetet lika viktigt som att välja vilka system som ska vara kvar, respektive tas bort. Det är väldigt viktigt att utvecklaren förstår företagets mål och syftet med systemet (Taylor, 1998).

Genom att en verksamhet använder sig av supercenters, ett alternativt arbetsnamn på en konsoliderad IT-verksamhet, får de bättre informationskontroll. Supercenters är inte bara datacentraler utan centraler för hela nätverk och kontroll av dem, de kan också innehålla avancerade grupper för teknik och mjukvaruutveckling. Vidare så får verksamheten i och med supercenters också skickligare IT-anställda eftersom de mindre skickliga har varslats, vilket medför att de kvarvarande får bättre betalt. Därför fruktar de anställda på IT-avdelningar konsolideringar. Carlyle (1990) beskriver en konsolidering som - svärdet som bringar oro och smärta till de anställdas värld, som hugger itu deras IS-budget och som förstör deras vanor.

Många anställda förknippar alltså konsolideringar med att man tappar sitt jobb, och de mest sårbara är de som inte har någon direkt spetskompetens, eller de med sådana arbetsuppgifter som kan ersättas av system med mer intelligent mjukvara. Det är lätt att förstå de anställdas oro eftersom det första en verksamhet bör göra efter genomförandet av en konsolidering är att uppgradera skickligheten bland de anställda (Carlyle, 1990).

Innan ett företag genomför en konsolidering av sina datasystem bör de överväga vissa faktorer. Därför har Gartner Group utvecklat en checklista, som kan hjälpa verksamheter att se ifall man bör överväga att genomföra en konsolidering.

Affärsfaktorer

- Direktiv genom hela organisationen att reducera kostnader.

- Organisationens datasystem sköter varuhantering, som varken är viktiga för företagets framgång eller för att differentiera sig från konkurrens.

- Behov av att betala av skulder, sälja IT-utrustning.

- Nuvarande IT-system klarar inte av att hantera vad verksamhetens aktiviteter kräver.

- Ett behov av att fokusera på organisationens kärnverksamhet. IT ses som oviktigt och avledande för ledningen.

Tekniska faktorer

- Dålig IT-miljö på grund av för lite resurser.

- Systemet tillfredsställer inte verksamhetens behov.

- Organisationen är för liten för att hantera ökade behov.

- Man drar inte nytta av systemets kapacitet på grund av minskade affärsbehov.

- Teknisk komplexitet, divergent hårdvaru- och mjukvaruplattform, som med fördel kan centraliseras och dra nytta av en gemensam miljö.

- Organisationen kan varken attrahera ny eller behålla befintlig personal.

- Behov av att öka IT-systemens tillgänglighet.

- Behov av en gemensam standard för skötsel av system.

- Behov av att konsolidera verksamhet inom organisationen som sköts av externa företag (outsourcing).

- Behov av att stabilisera fasta kostnader som hårdvara, utrymme, projektteam (Carlyle, 1990).

Fallgropar vid konsolideringar

Verksamheter som bedriver en konsolideringsstrategi utan att omdesigna, eller blir överentusiastiska när det gäller att minska antalet anställda, kommer att få en ökad långsiktig IT-kostnad och en bräcklig IT-miljö (Nicolett, Morello & Scardino, 2002). IT-managers måste se längre än bara de tekniska aspekterna, de måste även ta de sociala perspektiven i beaktande vid ett konsolideringsarbete, det kan annars bli så att avdelningar och affärsenheter ”krigar”

mot varandra då alla vill ha kontroll över de centrala servrarna. När företag konsoliderar gör många misstaget att man har för stor distans mellan sig själva och användarna. De fokuserar även för mycket på tekniska frågor och släpper fokuseringen på verksamhetens affärsmål. En konsoliderad verksamhet sparar förvisso pengar på sin IT-avdelning eftersom det blir mindre hårdvara och färre anställda, men de anställda minskar dock sin produktivitet (Currid, 1996).

Politiska roller kan alltså vara ett stort hinder i en konsolideringsprocess. Exempelvis kan oberoende affärsenheter vara motsträviga till att flytta sina applikationer till en server där andra avdelningar har sina applikationer. Därför är det viktigt att man klarar av att tydligt motivera värdet av konsolideringen och implementerar strategier för kontroll av IT-system, som ska bemästra de problem som följer med en konsolidering (Chu, 2003).

2.1.1 Generella åtgärdsförslag vid konsolideringar

I ovanstående teorier har vi identifierat ett antal generella åtgärdsförslag vid konsolideringar, som vi har kategoriserat och sammanställt i punktform. Vi har kategoriserat dessa åtgärdsförslag efter de mönster som vi sett under våra litteraturstudier, dvs. tekniska, analytiska, och användaraspekter.

9 Gör en grundlig analys och planera konsolideringsarbetet innan det startar. Välj även en utvecklare som förstår målet med systemet och verksamheten.

9 Arbeta tillsammans med användarna och motivera värdet av konsolideringen för dem.

9 Ta hjälp av modern teknik och skapa en ny design av systemen men behåll fokus på företagets affärsmål.

9 Analysera vilken eller vilka plattformar som passar bäst för ens procedurer. Sträva efter en gemensam hårdvaruplattform, ett operativsystem, och en databas som majoriteten av verksamhetens applikationer använder.

2.2 Serverkonsolidering

Den riktiga styrkan med serverkonsolidering är dess läglighet i tiden (Hall, 1998). Företags IT-omgivningar blir bara mer och mer komplicerade med tiden, men serverkonsolidering är ett område som kan förändra detta (Solarte, Blackburn, Krustapentus & Kiley, 1999). Just nu så behöver IT-managers en datamodell som behåller fördelarna av distribuerade processer men som hjälper till att lösa problemet med ökningen av antalet servrar, tillmötesgåendet av applikationskrisen och de blandade datorkraven som finns i organisationer.

Serverkonsolidering är den närmsta valmöjligheten idag och IT-managers har börjat anamma detta (Hall, 1998). Serverkonsolidering kan också göra kärnaktiviteter som mjukvarudistribution, backup och återvinnande enklare, allt medan systemsäkerheten förbättras (Whiting, 97).

En serverkonsolidering centraliserar de olika funktionerna via standardisering. Något som leder till reducerade kostnader genom att man på ett bättre sätt kan upprätta köpevillkor och inflytande mot en enskild försäljare. Serverkonsolidering tillåter också att man reducerar personalen som sköter support och man tillåts på ett bättre sätt styra över sina data (Solarte, Blackburn, Krustapentus & Kiley, 1999).

Kostnadsaspekter är en annan anledning till att genomföra serverkonsolideringar (Hall, 98;

Vijayan, 2003). Många företag runt om i världen fokuserar idag på serverkonsolideringar just för att få ner kostnader och för att förenkla IT-verksamheten (Powell, 2002). Enligt analytikern John Phelps är den huvudsakliga drivkraften för en serverkonsolidering att företagsledare tror att de kan spara en massa pengar, vilket både kan vara sant och falskt. För att försäkra sig om att de förväntningar som finns med serverkonsolideringen är riktiga bör verksamheten titta på beräknade kostnader av projektet, samt hur lång tid det kommer att ta innan serverkonsolideringen ger utdelning (Chen, 2003).

När det gäller själva begreppet serverkonsolidering finns det ingen standarddefinition, därför definierar olika teoriförfattare begreppet annorlunda. Gartner Group väljer t.ex. att dela in serverkonsolideringar i logiska, fysiska och rationella serverkonsolideringar (Fig. 2) (Phelps, 2002b).

Serverkonsolidering

Rationell Fysisk

Logisk

Fig. 2. Uppdelning av serverkonsolidering

Logisk konsolidering är en konsolidering där man inte flyttar på servrarnas fysiska placering.

Målet är i stället att implementera liknande processer. Dessutom vill man göra det möjligt att sköta systemen på ett standardiserat sätt. Den fysiska konsolideringen innebär att man flyttar de servrar man har till gemensamma utrymmen. När det gäller den rationella typen av serverkonsolidering innebär den att man implementerar multipla applikationer på färre, mer kraftfulla plattformar³, ofta genom partitionering och workload management. Partitionering är möjligheten att ta ett enskilt system, kapabelt att köra en enskild instans av ett operativsystem, och dela in det i flera mindre system, som vart och ett är kapabelt att köra sin egen kopia av ett operativsystem. Workload management är de tekniker som används för att effektivt möjliggöra att olika arbetsbördor körs tillsammans i en enskild instans av ett operativsystem genom att balansera de olika arbetsbördornas tillgångskonsumtion (Phelps, 2002a). I dagsläget utför de mest framåtsträvande företagsverksamheterna logisk och fysisk serverkonsolidering (Chen, 2003).

3 Plattform är ett annat ord för operativsystem.

Innan man startar sin konsolidering är det viktigt att tänka på vissa aspekter. Drivkraften att utföra serverkonsolideringar ska vara affärsfrågor i stället för tekniska frågor (Hall, 98). IT- chefer måste se över och analysera vad de försöker åstadkomma, om t.ex. höga kostnader beror på hårdvaruförvärv eller management. De ska även titta på vilken typ av serverkonsolidering som skulle göra nytta för deras organisation (Chen, 2003; Chu, 2003).

När man väl förstått vilken typ av konsolidering som ska bedrivas så har arbetet bara börjat (Hall, 98). IT-chefer måste också se till att kritiska system kan köras utan problem och existera i en konsoliderad miljö (Chu, 2003).

Det är viktigt att komma ihåg att serverkonsolidering är en pågående process och inte en engångsföreteelse. IT-chefer måste noggrant beräkna konsolideringsstrategin över tiden för att mäta riskerna och utöka sin räntabilitet (ROI), dvs. utöka resultatet av de investeringar som gjorts. För att avgöra de ekonomiska aspekterna av en serverkonsolidering är det bra att utföra en analys där man jämför den totala kostnaden av ett IT-system före och efter en serverkonsolidering. En sådan analys innefattar kostnader av IT-personal, ledning, administration, mjukvarulicenser, mjukvarudistribution och säkerhet (Whiting, 1997).

Det är viktigt att dela upp serverkonsolideringar punktvis och undersöka varje typ av konsolidering för att utvärdera potentiella besparingar (Phelps, 2002a). Nyckeln till en lyckad serverkonsolidering är att hålla processen enkel, man ska sträva efter en gemensam hårdvaruplattform och ett operativsystem (Solarte, Blackburn, Krustapentus & Kiley, 1999).

Verksamheter bör även inventera antalet servrar inom organisationen och kategorisera dem efter hur de används (Hall, 1998; Whiting, 1997), det övervägande är att det ofta bara finns en applikation per server (Hall, 1998). Det kan låta enklare än vad det är att inventera och kategorisera servrar, men som ett exempel började ett stort telekomföretag att göra detta i början av 1998. Vid årsslutet 1998 var de ännu inte klara, de hade då identifierat 11,000 servrar, ett antal som de innan inventeringen trodde var ca 4,000. Efter inventeringen är det dags att formulera en strategi som inkluderar mål och målsättningar med serverkonsolideringen (Whiting, 1997; Phelps, 2002b) och därefter bör en plan som inkluderar en systemarkitektur, planerade standards, gränssnitt, kostnader, krav på tillväxt, etc. utvecklas (Whiting, 1997).

Verksamheter bör sedan analysera vilken plattform eller plattformar som bäst passar för deras procedurer, plattformsfrågan är för övrigt den mest komplexa och viktiga frågan i en serverkonsolidering. De måste även ta reda på ifall ursprungsservern har samma operativsystem som den konsoliderade maskinen. I de flesta fall är detta osannolikt eftersom den konsoliderade servern ofta har nyare operativsystem än den gamla. Det mest troliga blir att man tvingas flytta applikationer från en operativsystemsmiljö till en annan och därför kan koordineringen av leverans och schemaläggning bli ens största huvudvärk. Verksamheter måste också komma ihåg att kraven på den konsoliderade servern kommer att vara mycket större än vad det var på ursprungsservern, det gäller att inte bli lurad av de extra resurserna för de kommer att spridas över på de multipla applikationerna. Det finns självklart politiska motiv kring alla plattformsdiskussioner och dessa sätter utvecklarens diplomatiska förmåga på prov.

Alla utvecklare har sin individuella politiska ståndpunkt gällande plattformsfrågor, dvs. den plattform de känslomässigt föredrar framför andra. Exempelvis kan en utvecklare använda och förorda en Unix-miljö vid serverkonsolideringar utan att överväga andra alternativ. Det är dock de tekniska styrkorna av serverkonsolidering som är det viktigaste när man tar beslut

När plattformsfrågan är löst bör verksamheter ta hjälp av modern teknik och investera i stora servrar för att öka pålitligheten och funktionaliteten. De bör även se till att skaffa tillräckligt med bandbredd till nätverk, det går aldrig att få för mycket så de bör planera för ett överflöd.

All processkraft i världen hjälper inte om användarna ändå inte kan komma åt den eller motarbetas av dåliga svarstider (Solarte & Blackburn & Krustapentus & Kiley, 1999).

Mjukvarufrågan får heller inte glömmas bort i en serverkonsolidering. Det är viktigt att undersöka och förstå vad effekten av en konsolidering blir gällande mjukvarukostnader.

Beroende på mjukvaruutvecklarens prissättning så är det möjligt att mjukvarukostnaderna i själva verket ökar när man flyttar till en större server (Phelps, 2002a).

När verksamheter sedan ska implementera de nya systemen bör de vara väl medvetna om att man inte kan sänka förväntade prestationsnivåer för de anställda som berörs av konsolideringen. Det är den första politiska regeln av konsolidering. Misslyckas detta så blir projektet en katastrof, vilket betyder att operativsystemstillverkare tävlar för att dominera serverkonsolideringsmarknaden (Hall, 98).

Fallgropar vid serverkonsolideringar

Var och en av de olika typerna av serverkonsolideringar innebär en mängd fördelar men det finns också risker. Noggrann planering, tydliga mål och exakta kostnadsberäkningar är nödvändiga för att försäkra sig om ett lyckat serverkonsolideringsprojekt (Chen, 2003). Att konsolidera servrar kan vara ett komplext arbete och konsolideringsprojekt tar ofta längre tid än väntat innan de väntade vinsterna visar sig. Experter inom området varnar t.ex. för att det även kan dyka upp en massa oväntade kostnader under projektets gång. Att flytta till större servrar kan exempelvis leda till stora ökningar av licenskostnader för mjukvara, att nätverkets bandbredd måste ökas, mer omfattande utgifter för backup, och hög säkerhet tillkommer. Som ett resultat av detta bör IT-managers som planerar konsolideringsprojekt vara väldigt försiktiga med att sätta upp förväntningar enligt experter (Chen, 2003).

Verksamheter som ska genomföra en konsolidering bör inte heller övercentralisera sina servrar utan det gäller att behålla arkitekturen flexibel. Ifall man fokuserar för mycket på snabba kostnadsbesparingar så kan man få betala för det i slutändan (Currid, 1996). Fel på en centraliserad server som flera hundra människor är beroende av i sitt arbete kommer att göra mer skada än fel på en server som betjänar ett dussin anställda på en avdelning (Whiting, 97).

2.2.1 Åtgärdsförslag vid serverkonsolideringar

I ovanstående serverkonsolideringsteorier har vi identifierat ett antal åtgärdsförslag, som vi har kategoriserat och sammanställt i punktform. Vi har kategoriserat dessa åtgärdsförslag efter tidigare nämnt mönster, se avsnitt 2.1.1.

9 Beräkna konsolideringsstrategin noggrant över tiden, utveckla en plan och jämför den totala kostnaden av ett IT-system före och efter en serverkonsolidering. Förutspå även mjukvarukostnader efter konsolideringen.

9 Inventera antalet servrar och kategorisera de efter hur de används.

9 Investera i stora servrar men övercentralisera inte utan behåll arkitekturen flexibel.

Kom ihåg att kraven på den konsoliderade servern är mycket större än vad det var på ursprungsservern.

9 Skaffa tillräckligt med bandbredd till nätverk och se till att kritiska system kan köras utan problem och existera i en konsoliderad miljö.

2.3 Lagringskonsolidering

Lagringskonsolidering är ett fenomen som växer ute i företagsvärlden eftersom IT-managers vill att lagringssystem ska vara bättre förenade med varandra (Koller & Wagner, 2000).

Lagringskonsolidering är ett begrepp som inte nödvändigtvis hör ihop med serverkonsolidering men man kan utföra dem i förbindelse till varandra (Phelps, 2002a; Chen, 2003). Lagringskonsolidering baseras på att lagringen sker i nätverk. Därför har försäljare inom datalagringsbranschen utvecklat både hårdvara anpassad till lagringskonsolidering, och mjukvara för skötsel av den konsoliderade lagringen (Phelps, 2002b). Speciellt olika mjukvarulösningar när det gäller lagring har varit utspridda och skilda från varandra tidigare men nu försöker man konsolidera även dem (Baltazar, 2002).

Det finns fem punkter som en verksamhetsledning kan följa när man genomför en lagringskonsolidering. Första åtgärden är att verksamheten som ska konsolidera måste förankra policyn att lagringen ska ske i ett datacenter, dvs. en central för datalagring.

Verksamheten måste också se till att konsolideringen utförs på samtliga plattformar för att reducera management- och underhållskostnader. Exempelvis om en verksamhet har, säg, sju servrar där lagringen är direkt anknuten till var och en av de olika servrarna så är det betydligt mer effektivt att ha ett Storage Area Network (SAN)⁴. SAN fungerar som en lagringspool, vilken kan användas av samtliga servrar. För det första är en sådan lagringspool billigare att sköta jämfört med separerade servrar och vid användandet finns heller inget behov av att upprätthålla stora mängder av överflödig kapacitet (i backup syfte) för var och en av servrarna i organisationen.

En annan fördel med att använda nätverk, och likaså en annan åtgärd, är att man kan sätta in extra kapacitet på ett modulärt⁵ sätt när organisationens verksamhet kräver det. I och med detta undviks att hela system ligger nere på grund av att lagringssystemet brister. Ett lagringsnätverk som kan hantera modulära uppdateringar gör det också lättare att upprätthålla och fördela lagring i enlighet med verksamhetens behov. Det reducerar även kostnader, både kostnader som kommer i samband med att systemet ligger nere såväl som operationella kostnader. Det kräver som sagt betydligt mer resurser att upprätthålla ett system med flera lagringsenheter jämfört med ett SAN. Modularitet hjälper IT-organisationer att reducera kostnader för skötseln av systemet.

Verksamheter ska också hålla systemets användare ansvariga för lagringen. De måste även veta hur mycket lagringskapacitet som finns inom organisationen och vad det används till.

Många organisationer har ingen plan för hur de ska hantera nyttan med sin lagring. I UNIX- miljöer uppskattar man inom industrin att 30 % av lagringskapaciteten går till spillo. I Windows-miljöer uppgår samma siffra till 70 %. Organisationer bör hålla reda på vad de lagrar för att undkomma detta slöseri med resurserna.

4 Storage Area Network eller på svenska datalagringsnät: nät av sammankopplade datalagringsenheter. En specialiserad del av ett företagsnät. Förutom att det snabbt förser användarna på företagsnätet med data sköter ett lagringsnät mer eller mindre automatiskt funktioner som säkerhetskopiering, dubblering (spegling) av data för avbrottsfri drift samt arkivering. (computersweden.se, 2003-05-16)

5 Modul beskrivs som: konstruktion i datorprogramspråk för uppdelning av stora program i mindre delar. En modul består normalt av logiskt besläktade procedurer och datastrukturer och är i vissa språk det primära stödet för abstrakta datatyper. Ofta tillåts

separatkompilering av moduler, vilket underlättar samtidig programutveckling. (http://www.computersweden.se, 2003-05-16)

Interoperabilitet⁶, dvs. hur kompatibla systemen är, anses som det viktigaste inom datalagring.

Interoperabilitet ger kunderna möjligheten att välja från flertalet enheter i lagringsnätverk, något man alltid strävar efter för att hålla nere kostnader. Om verksamheter ser reducering av lagringskostnader som en steg-för-steg process, så är tillsättandet av ny teknik det slutgiltiga steget. Det finns många nya tekniker, vars förespråkare hävdar att just deras teknik reducerar långsiktiga kostnader, nyckeln är dock att genomföra de viktigaste åtgärderna. En bra planering, standardisering och konsolidering är kritiska åtgärder som måste genomföras när man ser över sina lagringskostnader. Att migrera till modulära subsystem, interoperabila lagringsenheter är de efterföljande logiska stegen man bör genomföra. Man bör även styra mängden lagring, genom att försäkra sig om att användarna förstår att lagring inte är en resurs som är gratis och oändlig (Reimers, 2002).

Fallgropar vid lagringskonsolideringar

Det kan vara ekonomiskt givande att centralisera sin datalagring, men det kan också äventyra känsliga uppgifter som berör exempelvis sjukvårds-, finansiella, och juridiska frågor om de inte skyddas väl. Lagringskonsolideringar lyckas endast om man genomför den med en omfattande analys av säkerhet (Hughes & Rashba & McCabe, 2002).

2.3.1 Åtgärdsförslag vid lagringskonsolideringar

I ovanstående teorier har vi identifierat ett antal åtgärdsförslag vid lagringskonsolideringar, som vi har kategoriserat och sammanställt i punktform. Vi har kategoriserat åtgärdsförslagen efter tidigare nämnt mönster, se avsnitt 2.1.1.

9 Använd ett SAN som lagringspool, sträva efter interoperabilitet och använd moduler vid extra lagringskapacitet.

9 Förankra policyn att lagringen ska ske i ett datacenter till systemets användare, håll dem ansvariga för lagringen och se till att de förstår att lagring inte är en resurs som är gratis och oändlig.

9 Inventera lagringskapacitet inom organisationen och bestäm vilken nytta lagringshanteringen ska ha.

9 Bestäm hur man ska hantera känsliga uppgifter.

2.4 Applikationskonsolidering

En annan åtgärd för att effektivisera en verksamhets IT-miljö är att genomföra en applikationskonsolidering, där hårdvarulösningen för en applikation optimeras. Syftet med en applikationskonsolidering är att minska mängden utrustning vilket också kan leda till lägre kostnader för licenser och avtal. En annan stor vinst med detta är att man får en enhetlig och standardiserad applikationsmiljö som i förlängningen kan ge mervärden som lägre förvaltningskostnader. Företagen bör också fråga sig var mjukvaran är behövlig för att dynamiskt kunna konfigurera eller re-konfigurera sina maskiner i syfte att matcha sina ändrade behov (Goldstein, 2003).

Vilken typ av applikationskonsolidering verksamheten än ska genomföra måste man förstå vilka applikationer som är möjliga att centralisera. Vissa kan inte centraliseras och därmed inte konsolideras. När man genomför en serverkonsolidering är det viktigt att man tittar på just detta i ett tidigt skede av utvecklingsprocessen (Hall, 1998).

6 Ordet interoperability är “försvenskat” och är ett väldigt centralt begrepp gällande datalagring. Ordet betyder ungefär kompatibel.

Man ska exempelvis aldrig tvinga in en utspridd applikation till en konsoliderad miljö för att spara fysisk plats. Ett sätt att avgöra om en applikation bör konsolideras är att bestämma vad som är en acceptabel prestationsnivå vid hög belastning. Sedan testar man applikationen, i det dagliga arbetet, och ser om den presterar lika bra eller bättre i konsoliderade situationer på en gemensam server. Om en applikation delar resurser med en eller flera andra applikationer så innebär det att man måste genomföra tester med alla applikationer inblandade. I testerna varierar man applikationernas krav på belastning från medel till hög. Som en regel så skiftar användningen av applikationer konstant, vilket innebär att man oftast kan reducera den gemensamma serverns resursbehov i den konsoliderade maskinen (Hall, 1998). Om man har exempelvis fem applikationer som ska användas på en server så gör de konstanta skiftningarna i användningen av applikationerna att man inte behöver avsätta resurser för maxbelastning till alla fem applikationer.

Generellt så förbättrar konsoliderade applikationer sin prestation eftersom ett övergripande systems resurser är bättre. Nya servrar har mycket större minneskapacitet, mycket snabbare mikroprocessorer, och snabbare system och databussar⁷ med mindre betydelse jämfört med hos äldre servrar (Hall, 1998).

Gartner Group⁸ har genomfört en undersökning där man utreder vad som kostar mest att äga, en centraliserad applikation av en verksamhets moduluppbyggda program (ERP⁹) eller en decentraliserad applikationslösning. Gartner Group rekommenderar att verksamheter genomför en studie som utreder eventuella fördelar med en konsolidering av ERP. Man ska inte konsolidera om (Zrimsek, 2003):

- Varierande enheter i verksamheten redan har ett antal separata system och de är nöjda med denna lösning.

- Varierande enheter i verksamheten är nöjda med de totala operationella kostnaderna för alla system.

- Verksamheten föredrar att de olika enheterna sköts på ett oberoende sätt, vilket gör en centralisering svår.

- Verksamheten inte får ut något stort värde av att standardisera ERP-processer.

När verksamheter genomför applikationskonsolideringar finns det ett antal åtgärder de bör överväga. Bland annat bör de välja ett konventionellt operativsystem och databas som konsolideringsarbetet utgår ifrån. Detta operativsystem och databas ska sedan sköta så stor del av verksamhetens olika applikationer som möjligt (Chen, 2003).

7 En databuss är en sammansatt signal som passerar datorns olika inre delar (processor, hårddisk, grafikkort, cd-spelare) i tur och ordning längs en slinga. (http://www.computersweden.se, 2003).

8Gartner Group ett oberoende företag som specialiserar sig på undersökningar gällande bl.a. konsolideringar (http://www.gartner.com).

9 ERP, enterprise resource planning. Övergripande term för moduluppbyggda program som håller reda på produktion, tillverkning, beställning, kundtjänst, inköp, underleverantörer och annat. Erp bygger vanligen på en relationsdatabas (http://www.computersweden.se).

De bör även använda flyttbara programmeringsgränssnitt (APIs¹⁰) och allmän SQL¹¹. Ansi C med POSIX ¹², Java, Perl¹³ och .NET språk ger samtliga möjligheten till flyttbarhet.

Ansvariga inom verksamheten bör också sätta upp en policy i organisationen att man föredrar allmän SQL och att man ska använda dataabstrakta APIs i programspråket så mycket som möjligt (Chen, 2003).

En annan åtgärd verksamheter bör utföra är att modularisera applikationerna i organisationen.

Detta då webbapplikationer och andra designer med tre nivåer kostar mindre och är lättare att konsolidera än monolitisk design, dvs. design utförd i en enda nivå, eftersom delarna av applikationen vid design på flera nivåer kan konsolideras utan att påverka andra applikationsnivåer. Det gäller även att verksamheterna undviker inbyggda applikationsregister och byter till skriv-i-register eller verktyg för att synkronisera register. Gör man detta kan gamla användarnamn och lösenord behållas, vilket underlättar applikationskonsolideringen (Chen, 2003).

Att köra flera applikationer som är kritiska för verksamheten, på en ensam server alternativt serverpartition betyder att serverns uptime¹⁴ är väldigt kritisk för hur den konsoliderade verksamheten kommer att fungera. Därför bör det nya systemet designas för en hög tillgänglighet för användarna. De system verksamheten har för att hantera om något händer med något ordinarie system måste vara väl genomtänkta och katastrofplaner är ett måste. Man måste veta vad man ska ta sig till om något inträffar, om du sätter alla dina ägg i en korg måste du bevaka den korgen väldigt noggrant (Chen, 2003).

Man bör även dela upp maskinerna vertikalt och horisontellt. Horisontell uppdelning, genom att man slår ihop stormaskiner, är mycket billigare då det gäller den initiala investeringen och ger det bästa pris/prestation förhållandet för en konsolidering. De är dock också mycket mer begränsade när det gäller antalet applikationer som de stödjer. De ansvariga bör också delegera administrativa domäner, vilket är en av de största utmaningarna tekniskt sett vid en applikationskonsolidering och en stor orsak till att servrar spreds ut förr i tiden. Många hoppackade applikationer stöder inte konceptet med administrativa domäner eller delegationer. Tekniker för serverpartitionering eller systemvirtualisering kan vara de enda livskraftiga lösningarna för att kunna sätta ihop applikationer på rätt sätt (Chen, 2003).

10 API eller application programming interface står för programmeringsgränssnitt. En tillämpnings gränssnitt mot andra tillämpningar; de regler man måste följa när man skriver tillämpningar som ska kommunicera med en given tillämpning. (http://www.computersweden.se, 2003)

11 SQL eller structured query language är ett standardiserat språk för arbete med databaser. SQL används för att ställa frågor (queries) till databaser och för att ändra ochuppdatera dem. (http://www.computersweden.se, 2003)

12 POSIX eller portable operating system interface är en standard för gränssnitt för Unix och andra operativsystem. Tillämpningar som skrivits för ett Posix-godkänt operativsystem ska kunna köras utan omkompilering på andra Posix-godkända operativsystem.

(http://www.computersweden.se, 2003)

13 Perl eller practical extraction and reporting language. Ett programspråk som är avsett för att finna och bearbeta information i textfiler.

Det är också lämpligt för så kallade skript, och används ofta för att skriva cgi-program för webbsidor. ( , 2003)

http://www.computersweden.se

14 Uptime, tiden som systemet ligger uppe, dvs så länge systemet fungerar ökar dess uptime.

2.4.1 Åtgärdsförslag vid applikationskonsolideringar

I ovanstående applikationskonsolideringsteorier har vi identifierat ett antal åtgärdsförslag, som vi har kategoriserat och sammanställt i punktform precis som vid de föregående konsolideringsteorierna. Även här har vi kategoriserat åtgärdsförslagen efter mönstret som nämns i avsnitt 2.1.1.

9 Utvärdera vilka applikationer som är möjliga att konsolidera, bestäm var de är behövliga och modularisera dem. Använd även flyttbara programmeringsgränssnitt och allmän SQL.

9 Undvik inbyggda applikationsregister så att gamla användarnamn och lösenord kan behållas och designa systemen med hög tillgänglighet för användarna.

9 Utforma en katastrofplan för oförutsedda händelser.

9 Genomför vertikal och/eller horisontell uppdelning av maskinerna och delegera administrativa domäner.

3 Metod

I detta avsnitt ges en förklaring av de angreppssätt vi valt i vår undersökning. Vi beskriver sedan hur det praktiska metodarbetet gått tillväga, dvs. hur vårt arbete med att samla in data gått till, samt hur vi analyserat våra data. För att underlätta för läsaren är vårt metodarbete visualiserat i en bild med olika delar (Fig. 3). Till sist kommer vi även att diskutera begreppen validitet och reliabilitet.

3.1 Hermeneutiskt angreppssätt

Hermeneutik beskrivs numera som en ”ofta utvidgat vetenskapsteoretisk riktning som framhäver betydelsen av förståelse och inlevelse i human- och samhällsvetenskaperna”

(Nationalencyklopedin, 2003). Hermeneutik är en tolkningslära där man studerar, tolkar och försöker förstå grundbetingelserna för den mänskliga existensen. Läran innefattar kvalitativa förståelse- och tolkningssystem och en forskarroll som är öppen, subjektiv¹⁵, och engagerad.

Forskaren närmar sig forskningsobjektet subjektivt utifrån sin egen förförståelse (Patel &

Davidsson, 2003; Carlsson, 1991).

Vi har ett hermeneutiskt angreppssätt, eftersom vi studerat, tolkat och försökt förstå konsolideringsprojektet på Vattenfall Norrnät utifrån vår egen förförståelse inom konsolideringsteorier. Denna förförståelse skapade vi genom litteraturstudier och detta har säkerligen påverkat vår undersökning. Vi är medvetna om att våra subjektiva värderingar påverkat studien och denna insikt har gjort att vi varit extra noggrann med att inte dra förhastade slutsatser. Dessa subjektiva värderingar är vår förkunskap tillsammans med de förutfattade meningarna vi hade innan de olika intervjutillfällena. Den förkunskap vi syftar på är den kunskap vi erhållit från konsolideringsteorierna, samt övrig systemutvecklingskunskap.

Våra förutfattade meningar var att konsolideringen på Vattenfall Norrnät inte var så väl genomtänkt, utan att man genomförde den ganska ostrukturerat. Vi trodde inte heller att den teoretiska mognadsgraden var särskilt hög.

3.2 Kvalitativ ansats

Kvalitativ metod är ett av flera redskap vi har till vår hjälp när vi ska ta itu med ett problemområde. Syftet är att man ska få en bättre förståelse av vissa faktorer och därefter kunna analysera helheten. Jämfört med kvantitativa metoder försöker man i kvalitativ forskning att skapa en djupare kunskap och undersökningen präglas ofta av just den person som genomför den. Kvalitativa metoder möts med större skepsis än kvantitativa metoder.

Forskare måste ofta legitimera sitt metodval och argumentera för att det resultat man kommit fram till är hållbara och riktiga (Patel & Davidsson, 2003; Holme & Solvang, 1997).

Forskaren befinner sig i den sociala verksamheten som analyseras samt att forskaren söker fånga såväl människors handlingar som dessa handlingars innebörder. (Nationalencyklopedin, 2003; Holme & Solvang, 1997)

15 När den som forskar mest tar hänsyn till egna värderingar (och förutfattade meningar) vid bedömning.

(Nationalencyklopedin, 2003)

Vi har också en kvalitativ ansats i vår studie eftersom vi själva befunnit oss i verkligheten som analyserats, dvs. mitt i arbetsprocessen. Vår datainsamling och analys har skett parallellt och i växelverkan med dem som arbetar med projektet. Vi har försökt fånga människors handlingar och dess innebörder, genom att vi skapat oss en djupare kunskap av hur konsolideringsarbetet på Vattenfall utförts. Vår strävan har även varit att försöka komma de olika individerna in på livet för att försöka förstå deras tankebanor, gällande konsolideringsarbetet. Vår studie har som tidigare nämnts säkerligen blivit präglad av oss som individer och våra omedvetna subjektiva tolkningar, men vår ansats har hela tiden varit att återge det vi observerat på ett så noggrant sätt som möjligt. Vi har därför alltid spelat in våra intervjuer på band och återgett direkta citat från intervjupersonerna, för att minimera vår subjektivitet så mycket som möjligt.

3.3 Fallstudie

Vid en fallstudie utgår man från ett helhetsperspektiv och försöker få så täckande information som möjligt. Fallstudier kommer ofta till användning när man vill studera processer och förändringar. Generaliserbarheten på resultaten beror på hur vi valt våra fall (Patel &

Davidsson, 2003). Forskaren har liten eller ingen kontroll under en fallstudie och det är validiteten som är det viktiga, dvs. trovärdigheten (Yin, 1994). Ett ”fall” kan vara en individ, en grupp individer, en organisation eller en situation, men det kan även innebära att man studerar fler än ett fall, t.ex. två organisationer (Patel & Davidsson, 2003)

Vår undersökning är gjord som en fallstudie eftersom vi valt att undersöka en mindre avgränsad grupp individer, på IS/IT-avdelningen, inom Vattenfall i Luleå som är mitt inne i ett stort konsolideringsprojekt, ett förändringsarbete som berör hela Vattenfall Norrnät.

3.4 Litteraturstudie

Innan vi började söka efter litteratur så diskuterade vi igenom vilka teorier som kunde vara relevanta för vår studie. De böcker vi använt i arbetet är lånade på Luleå Tekniska Universitet.

Artiklarna är hämtade från olika databaser som universitetet och Gartner Inc. tillhandahåller. I det första skedet av arbetet ville vi skapa oss en översiktlig bild, varför vi använde sökord som

”konsolidering”, ”consolidation”, ”consolidat*”. Allteftersom vi blev mer insatta i ämnet och fann de olika delarna inom en konsolidering använde vi mer specifika sökord som

”serverkonsolidering”, ”lagringskonsolidering”, ”applikationskonsolidering”, ”fysisk konsolidering”, ”rationell konsolidering”, och ”logisk konsolidering”. Sedan använde vi även deras engelska motsvarigheter ”Server AND consolidat*”, ”application AND consolidat*”,

”storage AND consolidat*”, ”physical consolidat*”, ”rational consolidat*”, och ”logical consolidat*”. Den databas som vi använt mest frekvent är Academic Search Elite (Ebsco).

3.5 Tekniker för insamlandet av data

Det finns flera olika tekniker för hur man samlar in data, t.ex. dagböcker, intervjuer och dokument. Vid insamlandet gäller det att ta all data i beaktande, dvs. inte bara samla in data som stödjer ens egna idéer (Patel & Davidsson, 2003; Carlsson, 1991). Vi har använt oss av intervjuer och dagböcker i vår datainsamling. Intervjuerna gjorde vi för att få djupgående svar och möjlighet att ställa följdfrågor vid intervjutillfällena. De personliga dagböckerna har använts för att kontinuerligt samla information och viktiga saker i vårt fortsatta arbete. Dessa dagböcker har hjälpt oss att komma ihåg viktiga aspekter i vårt arbete och varit ett stöd då vi sammanställt arbetet.

En intervju är en samtalsform som primärt syftar till utfrågning av en person (Nationalencyklopedin, 2003). Graden av standardisering i en intervju kan variera, dvs. hur mycket ansvar som lämnas till intervjuaren när det gäller frågornas utformning och inbördes ordning. Vid en intervju brukar det rekommenderas att informationen ges i flera steg. Till att börja med så skickar man ett brev där man informerar om syftet med den kommande intervjun och vem som är ansvarig för undersökningen. Därefter ringer man och ger den fullständiga informationen. När man sedan träffas så presenterar man sig, legitimerar sig och ger den fullständiga informationen. Som intervjuare gäller det att ha förberett intervjun noggrant och skriva anteckningar eller spela in hela intervjun på band (Patel & Davidsson, 2003).

En dagbok är en form av självrapportering för att samla in information (Patel & Davidsson, 2003). Vanligtvis är det anteckningar förda dag för dag om händelser som skribenten blivit indragen i eller vittne till, om det dagliga livets göromål eller kanske om antecknarens inre utveckling (Nationalencyklopedin, 2003).

3.6 Kvalitet i kvalitativa studier

För att bedöma kvaliteten i en kvalitativ studie tillämpas ofta begreppen validitet och reliabilitet. Begreppet validitet gäller hela forskningsprocessen och är inte bara relaterad till datainsamlingen, strävan efter en god validitet gäller samtliga delar av forskningsprocessen i en kvalitativ studie. Begreppet reliabilitet ses mot bakgrund av den unika situation som råder vid undersökningstillfället. Dessa två begrepp är väldigt sammanflätade i kvalitativa studier, därför använder kvalitativa forskare sällan begreppet reliabilitet utan begreppet validitet får en vidare innebörd. När det gäller datainsamlingen kopplas validiteten t.ex. till om forskaren lyckats skaffa underlag för att göra en trovärdig tolkning av den studerades livsvärld, och om forskaren lyckats fånga det som är mångtydigt och kanske motsägelsefullt. Ett annat sätt att arbeta med validiteten är att låta respondenter ta del av resultatet och ge återkoppling till forskaren om dennes tolkningar och slutsatser är rimliga (Patel & Davidsson, 2003).

För att uppnå så bra validitet som möjligt i vår studie utgick våra intervjufrågor från konsolideringsteorier och utformades i enlighet med uppsatsens syfte. Innan varje intervju informerade vi intervjuobjektet om syftet med intervjun, vilket ämnesområde vi avsett att diskutera, samt vad vi förväntar oss av intervjuobjektet i fråga. Vi spelade även in alla intervjuer in på band och återgav dem sedan i text. Eftersom undersökningen behandlar hur ett konsolideringsarbete går till i praktiken kan vissa frågor ha känts personliga för våra respondenter, vi var därför noggrann med att poängtera vikten av ärliga svar eftersom vår intention var att undersöka verkligheten. Trots att vi gjort vårt bästa för att få respondenterna att känna sig trygga kan vissa av svaren de lämnat vara något tillrättalagda eftersom de inte vill framstå som alltför slarvig eller omedveten om konsolideringsarbeten, vilket kan ha påverkat validiteten negativt. Vi har också lagt stor vikt vid att vara uppmärksamma på när respondenterna tvekat eller varit osäkra på olika svar, då har vi ställt följdfrågor för att klargöra hur det verkligen förhåller sig. Genom att vi har varit två personer som suttit med vid intervjuerna, där en av oss ställt frågor och båda har antecknat och observerat, har vi dessutom haft möjlighet att förklara frågorna närmare vid behov. Med ovanstående som bakgrund anser vi att vi har en god validitet gällande vår datainsamling.

Vi har grundat mycket av vår rapport efter att ha pratat med en anställd i chefsposition. Denna person är ansvarig för konsolideringsarbetet och i rapporten refereras han som kontaktperson.

Därför har vi till stor del fått hans synvinkel på hur konsolideringsarbetet utförs och vi är medvetna om att det kan påverka vår validitet negativt.

3.6.1 Kvalitativ bearbetning

När man har samlat in den information man behöver så måste man bearbeta den. Det finns två olika metoder för detta, kvantitativ- och kvalitativ bearbetning. Vid den kvalitativa metoden så försöker man skapa en djupare kunskap än vid den kvantitativa bearbetningen och där är ambitionen att försöka förstå och analysera helheter. När man bearbetar information kvalitativt så präglas resultatet ofta av just den person som genomför arbetet. Varje forskningsproblem kräver sin unika variant av metod och för att bli bra som kvalitativ forskare måste man ha god överblick över hela det kvalitativa forskningsfältet, ett fält som ständigt ändras och kräver en kontinuerlig reflektion. Det är ofta praktiskt att göra löpande analyser under arbetet med en kvalitativ undersökning för att sedan avsluta med en slutbearbetning av allt material. Man får inte heller glömma bort att redogöra hur den kvalitativa bearbetningen gått tillväga, läsaren måste kunna följa hur författaren arbetat eftersom det inte finns någon bestämd metod för hur en kvalitativ bearbetning utförs (Patel &

Davidsson, 2003; Carlsson, 1991).

Vi har analyserat all data på ett kvalitativt sätt eftersom vi ville få en djupare förståelse av hur konsolideringsarbetet på Vattenfall Norrnät gick till. Vi ville försöka förstå de bakomliggande orsakerna till beslut som fattades. Under vårt arbete har vi också varit medvetna om att vi, i form av kvalitativa forskare, har påverkat undersökningen. I syfte att ha så god överblick på det kvalitativa forskningsfältet har vi försökt sätta vår personliga prägel på metoderna vi använt, främst genom att göra personliga tolkningar av respondentens svar vid de olika intervjutillfällena. Vid intervjutillfällena har vi spelat in allt som sagts på band och sedan lyssnat igenom dessa flertalet gånger för att i slutändan återge dem i text. Genomlyssningarna av banden har skett direkt efter att intervjuerna genomförts för att undvika att viktiga tolkningar som vi gjort vid intervjutillfällena inte ska gå förlorade. Denna text har sedan legat till grund för vår empiri, analys, diskussion och våra slutsatser. Avsnitt som innehåller såväl citat som våra egna tolkningar av materialet. De renskrivna intervjuerna finns också sparade, men de är dock inte tillgängliga i rapporten eftersom det är en stor mängd text. Vi anser därför att vi har en god validitet gällande bearbetningen av det material som vi samlat in.

3.7 Vårt metodarbete

För att tydliggöra hur vi gått tillväga i vårt arbete har vi valt att illustrera detta med en figur, se Fig. 3. Delarna i figuren följer en kronologisk ordning av vår arbetsgång och finns

beskrivna under respektive rubrik i löptexten.

Fig. 3. Modell över de olika delarna i vår metod.

Litteraturstudier och sammanställning av teorier

Vi började med att läsa böcker och artiklar som behandlade ämnet konsolideringar, för att skapa en bättre förståelse för begreppet och dess innebörd. Litteraturstudierna pågick under hela arbetets gång, vilket indikeras av ovalen som inkluderar alla delar i figuren. De var dock mest intensiva under arbetets initiala skede. Vi märkte rätt snabbt att det inte skrivits så många böcker inom ämnet utan att det mesta som skrivits var artiklar eftersom begreppet konsolidering är relativt nytt. En stor del av vårt arbete bestod därmed av att sammanställa och kategorisera de olika teorierna med tillhörande åtgärdsförslag. Samtidigt som vi läste in oss på ämnet så tog vi kontakt med företaget Professional Enterprise Management (Pro|e|ma), ett företag som bara arbetar med att utföra konsolideringar. Detta gjorde vi för att få en översiktlig bild av ämnet och för att få synpunkter från personer som dagligen arbetar med konsolideringar. Företaget gav oss långa utförliga svar via mail och fortsatte att hjälpa oss under arbetets gång.

Intervju 1 (Bilaga A)

Därefter tog vi kontakt med energiföretaget Vattenfall, som vi genom personliga kontakter fått reda på bedrev ett konsolideringsprojekt. Vi bokade en tid för en första intervju, högst upp till vänster i figuren, med IS/IT-avdelningens chef eftersom vi tagit reda på att han ansvarade för projektet, han fungerade även som kontaktperson under vår studie. Vår tanke med denna intervju var att den skulle vara helt ostrukturerad, dvs. intervjufrågorna lämnade maximalt utrymme för intervjupersonen att svara inom (Patel & Davidsson, 2003; Carlsson, 1991).

Utv. av modell Litteraturstudier

och sammanställning av teorier Fortlöpande analys

Intervju 1 Intervju 3

Intervju Intervju 2 4-7

Analys Diskussion

Slutsatser

Innan intervjun skickade vi ett mail till vårt intervjuobjekt, där vi förklarade vilka vi var och syftet med den kommande intervjun. Därefter ringde vi och gav den fullständiga informationen angående intervjun, allt för att ge honom en så bra förberedelse som möjligt (Patel & Davidsson, 2003). I denna fas av arbetet hade vi inte kommit fram till något syfte eller någon forskningsfråga i vår uppsats utan vi ville avvakta till efter intervjun, eftersom vi hoppades att få nya idéer och infallsvinklar till arbetet, utifrån intervjun. Under intervjun lät vi honom berätta fritt om Vattenfall Norrnäts organisation och konsolideringsarbete, detta för att vi skulle kunna skaffa oss en bra bild av organisationen och konsolideringsprocessen. Vi frågade även om han upplevde några problem med konsolideringsarbetet. Hela intervjun spelades in på band, samt att vi även förde personliga anteckningar för att inte missa viktiga aspekter. Intervjun gav oss en bra bild av hur Vattenfalls konsolideringsarbete var organiserat och hur det fungerade, vi fick även uppslag till olika intressanta problemområden. Vid detta intervjutillfälle var vår avsikt, som tidigare nämnts, att få en översiktlig bild av Vattenfalls organisation och deras konsolideringsarbete.

Fortlöpande analys av intervju 1

Den första intervjun var som tidigare nämnts ostrukturerad och det ledde till att ganska många irrelevanta delar berördes, varför vi valde att sammanfatta denna intervju i text för att slippa all irrelevant information. Vi analyserade sedan innehållet för att ta oss vidare i vårt arbete.

Patel & Davidsson (2003) nämner att det är en fördel att göra löpande analyser, exempelvis direkt efter ett intervjutillfälle, just på grund av att det kan ge nya idéer om hur man kan gå vidare i sitt arbete. Ovalen som omfattar intervju 1-3 i figuren indikerar att vi genomförde en fortlöpande analys efter varje intervju med vår kontaktperson. Med denna nyvunna kunskap fortsatte vi att fördjupa oss inom ämnet genom att läsa fler artiklar och genom ny mailkontakt med Pro|e|ma. Vi skapade ett syfte och en forskningsfråga till vår uppsats och informerade sedan vår kontaktperson på Vattenfall om undersökningens syfte. Eftersom vi inte kom i kontakt med någon enskild litteratur som berörde alla aspekter av ett konsolideringsarbete, försökte vi åskådliggöra detta i vårt teoriavsnitt genom en sammanställning. Vi har även försökt konkretisera och dela upp de olika begreppen under olika rubriker, dessa är: generell konsolideringsteori, serverkonsolidering, lagringskonsolidering, och applikations- konsolidering. Denna sammanställning förenklade också vår strävan i att svara på rapportens syfte. I samband med sammanställningen av denna intervju analyserade vi den och insåg att det fanns områden som vi behövde komplettera för att skapa en djupare insikt av Vattenfalls konsolideringsarbete.

Intervju 2 (Bilaga B)

Utifrån de olika konsolideringsteorierna tog vi fram olika punkter som utgångspunkt för vår andra intervju, punkter som resulterade i ett antal intervjufrågor. Vi bestämde oss för att denna intervju skulle vara mer strukturerad än vår första. Patel & Davidsson (2003) och Carlsson (1991) nämner att strukturerade intervjuer leder till att forskaren på ett enkelt sätt kan styra in samtalet på de saker som är intresserant för studien. Inför vår andra intervju gick vi tillväga på liknande sätt som vid vår första intervju. Först kontaktade vi intervjuobjektet via mail och förklarade vad denna intervju skulle behandla. Eftersom intervjun skulle utföras i samarbete med samma person som vid första intervjutillfället behövdes ingen vidare presentation av oss och vad arbetet gällde, vi kunde fokusera på att beskriva vad just denna intervju skulle behandla. Under denna intervju fungerade våra intervjufrågor som en strukturerad utgångspunkt, där vi började med de frågor som på ett generellt sätt behandlar konsolideringar, för att sedan gå in på de frågor som i tur och ordning behandlar server-,

svar på den aktuella frågan. Även denna intervju spelades in på band och kompletterades med personliga anteckningar.

Fortlöpande analys av intervju 2

Eftersom denna intervju var mer strukturerad än vår första och samtliga frågor behandlade viktiga aspekter för vår undersökning, valde vi att återge denna intervju ordagrant. I samband med sammanställningen av denna intervju analyserade vi den och insåg att det fanns områden som vi behövde komplettera för att skapa en djupare insikt av Vattenfalls konsolideringsarbete. Vi förberedde nya intervjufrågor och började även skriva på empiriavsnittet.

Utveckling av modell

Efter intervju 2 valde vi att strukturera upp IS/IT-avdelningen på Vattenfall Norrnät med en modell för att visa hur de arbetar i dagsläget, som kan ses strax under mitten av figuren. Vi baserade modellen på Stafford Beers Viable System Model (VSM) (Beer, 1985). Modellen förtydligar IS/IT-avdelningens arbetsprocesser och olika kommunikationsvägar. Denna modell tog vi sedan med oss till vår kontaktperson vid tredje intervjutillfället för att försäkra oss om att vi uppfattat IS/IT-avdelningen och deras dagliga arbete på ett korrekt sätt.

Intervju 3 (Bilaga C)

Även denna intervju skedde med vår kontaktperson och spelades in på band. Eftersom vi vid detta lag var väl bekant med honom, behövdes ingen vidare presentation av oss. Vi bestämde en tid för intervjutillfället och berättade att den mest skulle komplettera och vara en fördjupning av de tidigare intervjuerna. Målet med denna intervju var att försäkra oss om att vi uppfattat saker och ting på ett riktigt sätt och att för få en djupare inblick inom de områden som vi ansåg oss ha för lite material om. Vi började med att förklara VSM modellen och beskrev sedan hur vi använt den i vårt arbete för vår kontaktperson. Detta gjorde vi för att minimera risken att vi missuppfattar arbetet på avdelningen, samt för att få med alla viktiga operationer som utförs. Vår kontaktperson var väldigt intresserad av modellen och sa att vi uppfattat det mesta på ett korrekt sätt, men han kom även med synpunkter och värdefulla tips på hur vi kunde utveckla vår modell när det gällde omgivningen, system 3, och system 4.

Dessa synpunkter tog vi till oss och la till i vår modell, för att den bättre skulle stämma överens med verkligheten. Han kom även med förslag på hur vi kunde utveckla modellen med en lägre rekursiv nivå, vilket vi dock inte har gjort eftersom vårt syfte med att använda modellen endast var att ge en översiktlig bild av IS/IT-avdelningens dagliga arbete. Intervjun fortsatte sedan med att vi ställde fördjupade frågor kring deras arbetsprocess i konsolideringsarbetet, det var främst deras 5 stegs modell som diskuterades. Efter intervjutillfället så lyssnade vi igenom intervjun ett par gånger och sammanfattade den i skrift för att ytterligare öka vår trovärdighet. Vi kompletterade sedan vår VSM modell för att få med alla aspekter som framkom under intervjutillfället.

Fortlöpande analys av intervju 3

Även denna intervju valde vi att renskriva ordagrant och analysera direkt efter den var utförd.

I och med analysen av den märkte vi att det också hade varit intressant att få ta del av några användares synpunkter, för att bredda vår analys. Därför utformade vi intervjufrågor som vi tänkte ställa till några anställda på Vattenfall Norrnät. Intervjufrågorna satte vi upp enligt de punkter där teorierna föreslår att användarna på något sätt involveras i konsolideringsarbetet.

Vi ville även ha användarnas åsikter om hur lagringen sköts inom Norrnät eftersom vi vid de tre första intervjuerna fått uppfattningen att det fanns förbättringar att göra inom det området.