EXAMENSARBETE
Minska riskerna i globala affärssystemsprojekt
Ur ett ledningsgruppsperspektiv
Mikael Hansson 2016
Filosofie kandidatexamen Systemvetenskap
Luleå tekniska universitet Institutionen för system- och rymdteknik
Förord
Detta examensarbete är en del av systemvetenskapsprogrammet vid Luleå Tekniska Universitet, Institutionen System och rymdteknik, avdelningen systemvetenskap. Arbetet är utfört vårterminen 2016 och omfattar 15 högskolepoäng.
Jag vill passa på att tacka samtliga respondenter och mitt fallstudieföretag som deltagit i intervjuer och låtit mig få ta del av internt material som varit en förutsättning för studien. Jag vill också tacka handledarna Diana Chroneer och Mari Runardotter för stöd och konkreta tips till förbättring av examensarbetet.
Sist vill jag också tacka min familj som stöttat mig tålmodigt under min utbildning.
Onsala maj 2016
Mikael Hansson
Sammanfattning
Syftet med studien är att beskriva och öka förståelsen för en del av de aktiviteter som ett företag bör göra på planeringsstadiet för att minska riskerna i globala affärssystemsprojekt.
Litteraturstudien omfattar systemutveckling, affärssystem, projektstyrning, risker och riskanalys samt ett avsnitt om globala projekt. Teorin bildar en referensram för den empiriska undersökningen som gjordes i form av aktionsforskning med en fallstudie. Fallstudieföretaget var mitt i ett globalt affärssystemsprojekt och semi-strukturerade intervjuer gjordes med projektledaren, CIO, utvecklingschefen och driftschefen för att beskriva och förstå vilka risker de uppfattade att projektet hade och vilka motåtgärder som de använts sig av. Intervjuerna kompletterades med studier av internt material och genom att en loggbok fördes under de tre månader som projektet observerades. Det insamlade materialet kompletterade de transkriberade och kodade intervjuerna. Allt insamlat material inordnades i tre teman, karaktäristiska egenskaper, risker och motåtgärder, för att sedan kunna jämföras med teorin i den teoretiska referensramen. Studien gör det möjligt att se vilka risker som finns och vilka motåtgärder som fallstudieföretaget använts sig av för att minska riskerna.
Slutsatsen i studien är att de flesta risker och motåtgärder som hittades i teorin också, helt eller delvis, återfanns i det studerande projektet. Det som skiljer fallstudieföretagets projekt från teorin är att de via upphandling lyckats flytta utvecklingsrisker till leverantören, minskat sina tekniska risker genom att använda ny teknik och hittat rätt kompetens genom att frångå ett traditionellt partnersamarbete. De har också genom regelbundna workshops med teammiddagar skapat ett effektivt projektteam på kort tid. Resultatet av studien är en lista med risker för globala affärssystemsprojekt och lämpliga motåtgärder.
Nyckelord: Affärssystem, ERP, global, risker, projektplanering.
Abstract
The objective of this study is to describe and increase the understanding of some of the activities that a company should do in the planning phase to contain or reduce risks in a global ERP project. The literature study includes theory about system development, ERP systems, project management, risks and risk analysis and a part about global projects. The frame of reference becomes the basis for the empirical investigation which was conducted as an action research with a case study. The case study company was in the middle of a global ERP project and semi- structured interviews were conducted with the project manager, the CIO, the development manager and the operation manager in order to describe and understand the risks that they thought that the project was facing and what responses they used. The interviews were complemented by a study of internal material and by keeping a log during the three months that the project was under study. The collected material complemented the transcribed and coded interviews. All the collected material was grouped into three themes, characteristics, risks and responses, in order to later compare it with the theory in the frame of reference. The study makes it possible to investigate which risks were present and which activities the case company uses to mitigate the risks.
The conclusion from this study is that most risks and responses that were found in the theory also, in full or partly, exist also in the case study company. The deviations between the case study company and the theory are that the case study company has, through its procurement process, managed to move development process risks to its vendor, reduced the technical risks by using new technology and found the right competence by deviating from a traditional partner set-up. Through the use of regular workshops with team dinners they have quickly created an efficient project team. The results of the study are a list of risks for global ERP projects and a list of suitable responses.
Innehållsförteckning
1. Inledning ... 1
1.1. Bakgrund ... 1
1.2. Problemdiskussion ... 2
1.2.1. Syfte och forskningsfrågor ... 3
1.2.2. Avgränsningar ... 3
1.3. Centrala begrepp ... 3
2. Teori ... 5
2.1. Systemutveckling ... 5
2.1.1. Systemutveckling – några karaktäristiska egenskaper ... 5
2.1.2. Risker med systemutveckling ... 6
2.1.3. Motåtgärder kopplade till risker ... 8
2.2. Affärssystem ... 8
2.2.1. Definition ... 8
2.2.2. Risker och motåtgärder ... 8
2.3. Projektstyrning ... 12
2.3.1. Projektprocesser ... 12
2.3.2. Planering ... 13
2.4. Risker och riskanalys... 13
2.4.1. Vad är en risk? ... 14
2.4.2. Riskanalys ... 14
2.5. Globala projekt ... 16
2.5.1. Distribuerad systemutveckling ... 16
2.5.2. Kulturella skillnader ... 17
2.6. Sammanfattning - teoretisk referensram ... 18
3. Metod ... 22
3.1. Forskningsansatser ... 22
3.2. Forskningsstrategi ... 22
3.2.1. Min bakgrund och nuvarande roll ... 23
3.2.2. Val av metod ... 23
3.2.3. Fallstudie ... 23
3.2.4. Aktionsforskning ... 24
3.3. Datainsamlingsmetoder ... 24
3.3.1. Litteraturstudie ... 25
3.3.2. Intervjuer ... 25
3.3.3. Loggbok ... 26
3.3.4. Studier av internt material ... 26
3.4. Analys av data ... 26
3.5. Metodproblem, validitet, reliabilitet och trovärdighet ... 27
4. Empiri ... 29
4.1. Respondenter ... 29
4.2. Projektets karaktäristiska egenskaper ... 30
4.3. Projektets risker ... 31
4.4. Motåtgärder ... 34
5. Analys ... 37
5.1. Projektets karaktäristiska egenskaper ... 37
5.1.1. Sammanfattning ... 38
5.2. Risker ... 38
5.2.1. Sammanfattning ... 42
5.3. Motåtgärder ... 42
5.3.1. Sammanfattning ... 45
6. Slutsatser ... 47
7. Diskussion ... 51
7.1. Metoddiskussion ... 52
8. Fortsatt forskning ... 52
Referenser ... 53
9. Bilaga ... 56
9.1. Intervjuguide ... 56
sid 1
1. Inledning
Uppsatsen handlar om hur man kan planera för att minska riskerna i ett globalt affärssystemsprojekt. Dessa projekt är kanske de största och mest kostsamma och de mest riskfyllda som ett företag eller organisation kan göra, men vinsterna kan också bli mycket stora.
No risk – no reward!
(Anonym)
Det var knappast alla risker och problem som Christofer Columbus tänkte mest på när han bestämde sig för att försöka hitta en ny väg till Indien. Det fanns något mycket större. Något som han och hans besättning var uppfyllda av och som drev dem till att ge sig av på det äventyr som resulterade i att de ”upptäckte” Amerika. Kanske lockade pengar, guld och andra rikedomar. Kanske var det viljan att bekräfta sin teori och vara först att segla västerut till Indien eller att göra det som ingen annan hade klarat av (Sörlin, 1990). När kapten Billy Tyne, spelad av George Clooney, i filmen ”Den perfekta stormen” bestämmer sig för att åka ännu längre ut med sin fiskebåt Andrea Gail för att hitta bättre fångst är det ett beslut som inte är planerat utan
”tas i stunden” (Petersen, 2000). Kapten Billy är ingen nybörjare. Han förstår riskerna men ger sig ändå ut i det okända. Han tvingades ut för att ”han måste”. Pengarna var slut och kanske var kapten Billy också slut. Kanske hade han förlorat ”det” som gör att man hittar fångsterna.
Oavsett anledning finns det något större som gör att man är villig ”att ta riskerna”. Christofer Columbus planerade länge och väl och hade turen på sin sida. Trots att hans projekt misslyckades med målet (att hitta en ny väg till Indien) så blev man framgångsrika. För Kapten Billy gick det sämre. Han lyckades med målet (att hitta fisken) men gick under med skepp och allt i en storm som blev större och mer farlig än vad som någon dittills kunnat förutse.
När ett företag bestämmer sig för att införa ett nytt affärssystem, ett system som ska användas i företagets alla delar och där man också strävar efter att samordna eller helt införa gemensamma affärsprocesser, är det kanske affärslivets motsvarighet till Columbus amerikaresa. Vinsterna kan bli mycket stora och framtiden målas i ljusa färger av affärsystemförsäljarna. Men riskerna och kostnaderna är också stora. Precis som för Columbus är det svårt att exakt veta vad som kommer ut av ett stort projekt och för att lyckas (och överleva) krävs god planering och hantering av riskerna.
1.1. Bakgrund
Systemutveckling är svårt. Elin Lundström Ekman från konsultbolaget Decuria uttalar sig i en artikel i Computer Sweden och hävdar att upp till 85 procent av alla IT-projekt ute hos företag och organisationer misslyckas (Malmqvist, 2014). Om man dessutom jobbar med outsourcing blir det ännu svårare. Sitter resurserna på olika platser så blir det ännu mer komplext.
Ledningen och projektmedlemmarna ställs inför stora utmaningar inom många olika områden, från teknik till sociala och kulturella. Problemen orsakas oftast av faktorer som avstånd, tid och kulturella skillnader (Shrivastava & Date, 2010). Globala systemutvecklingsprojekt har ofta alla dessa egenskaper.
sid 2
När det gäller affärssystemsprojekt är de mer komplexa än ”vanlig” systemutveckling eftersom de berör hela företaget, detta oavsett om projekten är globala eller ej. Det är många affärsprocesser som påverkas och det innebär att antalet kravställare blir större än i vanliga projekt (Davenport, 2000). Om verksamheten är spridd i olika länder innebär det ofta att affärssystemsprojekten blir globala. För att framgångsrikt kunna införa ett affärssystem krävs ofta de största tekniska förändringar som ett bolag behöver genomgå och kanske ändå större och viktigare är de stora förändringar som verksamheten måste gå igenom (Davenport, 2000).
Mary Sumner menar att den största utmaningen med att implementera ett affärssystem är att välja mellan att anpassa företagets processer till systemet eller att försöka anpassa systemet till företagets processer (Sumner, 2004). Oavsett vad man väljer resulterar det i ett stort och riskfyllt projekt.
Vad som är gemensamt för alla projekt är att planeringen är viktig och ju större och mer komplext ett projekt är, desto viktigare. Projektplanen ska skapa förutsägbarhet och ger oss en möjlighet att identifiera avvikelser när problem och förseningar uppstår (Görling, 2009). I planeringsfasen av projektet ska man försöka hitta de risker som finns och skapa en handlingsplan för att bemöta dessa. När projektet väl är igång är det ofta svårt eller dyrbart att göra förändringar. Kan man identifiera riskerna och planera för att minska dessa i planeringsstadiet är mycket vunnet. Men riskhanteringen ses ofta som extra arbete och får inte tillräckligt med fokus av projektledarna (Aloini, Dulmin, & Mininno, 2007).
1.2. Problemdiskussion
Är ett globalt affärsystemsprojekt IT-världens ”Den perfekta stormen”? Kombinationen av global systemutveckling och affärsystemsimplementationens komplexitet skapar dåliga förutsättningar att nå målen. Trots alla risker, svårigheter och kostnader som väntar är det allt fler företag, inte bara stora, utan också medelstora, som startar dessa projekt (Davenport, 2000).
Affärsystemleverantörer som SAP och Microsoft har versioner som riktar in sig på medelstora företag. Riskerna med globala affärs- och systemutvecklingsprojekt är väl dokumenterade men det finns inte så mycket skrivet om vad man kan göra för att minska riskerna. Hakim och Hakim (2010) anser att det finns mer fallstudier om implementeringen av affärssystem och mindre forskning om implementationsrisker. Ehie och Madsen (2005) menar att det finns flera fallstudier om affärsystemsimplementationer men få empiriska studier som försöker koppla samman de kritiska faktorerna som resulterar i framgångsrika affärssystemsprojekt. En orsak kan vara att få organisationer och företag vill dokumentera och publicera misslyckade projekt.
Eftersom affärsystemsprojekt anses vara mer komplexa än vanliga systemutvecklingsprojekt (Aloini et al., 2007) innebär det att de också kostar mer. Enligt en amerikansk undersökning kan de kosta flera miljoner US dollar att köpa och många gånger mer att införa. Projekttiden är ofta flerårig och tidsåtgång och kostnad kan bli enorm (Aloini et al., 2007). De bolag som klarar av sina affärssystemprojekt och som når sina mål kan nå fördelar jämfört med sina konkurrenter medan de som misslyckas kan få acceptera minimala avkastningar eller till och med få avbryta sina implementationer. Det är viktigt att undersöka vad ett företag kan göra för att anpassa projektplaneringen för att möta dessa risker som kommer av att projektet bedrivs som ett globalt projekt. Uppsatsen beskriver den teoribildning som finns och gör en fallstudie i ett företag som just nu är mitt uppe i ett globalt affärssystemprojekt.
sid 3
1.2.1. Syfte och forskningsfrågor
Syftet med studien är att beskriva och öka förståelse för de aktiviteter som ett företag bör göra på planeringsstadiet för att minska riskerna i globala affärssystemsprojekt. Detta besvaras genom följande forskningsfrågor:
Vilka risker finns i globala affärssystemprojekt?
Hur kan företag eliminera eller minska risker redan i planeringsstadiet av ett projekt?
1.2.2. Avgränsningar
Perspektivet i studien kommer från företagets IT-ledningsgrupp och inte från projektdeltagarna eller från leverantörerna. Målgruppen är ett företags lednings- eller styrgrupp som funderar på att starta ett globalt affärssystemsprojekt.
Uppsatsen handlar om globala affärsystemsprojekt men i diskussionskapitlet finns en diskussion om resultaten kan vara mer generella och gälla också för globala system- utvecklingsprojekt.
1.3. Centrala begrepp
Affärssystem eller ERP
Det engelska begreppet ERP (enterprice resource planning) används ofta även i svensk text som en synonym till det svenska begreppet affärssystem. I denna uppsats används affärssystem. Ett annat begrepp som används är ES (enterprice system). ES kan oftast jämställas med ERP och även det begreppet översätts i denna uppsats till affärssystem.
Utkontraktering eller outsourcing
I uppsatsen används begreppet outsourcing istället för den svenska översättningen utkontraktering eftersom outsourcing numera finns med i SAOL (Svenska Akademien, 2016).
CEO, CFO och CIO
CEO, CFO och CIO - dessa begrepp är allmänt vedertagna positioner i internationella företag.
Företaget som studeras i denna undersökning har delvis en annan nomenklatur men dessa begrepp används för att göra det enkelt. Översättningarna nedan är inte helt korrekta men tillräckligt precisa för denna uppsats.
CEO – Chief Executive Officer, motsvaras av det svenska begreppet VD.
CFO – Chief Financial Officer, motsvaras av det svenska begreppet ekonomichef CIO – Chief Information Officer, motsvaras av det svenska begreppet IT-chef
IT, IS, IT/IS, ICT eller IKT
IT, IS, IT/IS, ICT eller IKT - alla dessa begrepp kan användas för att beteckna en IT-avdelning.
sid 4
IT – Information Technology – kan ibland beteckna den del av IT-avdelningen som hanterar teknik såsom hårdvara. Men ibland kallas hela IT-avdelningen för just IT.
IS – Information Systems – kan ibland beteckna den del av IT-avdelningen som hanterar systemen, dvs mjukvaran.
IT/IS – en avdelning som har ansvar för både IT och IS.
ICT eller IKT – Information, Technology och Communication (Kommunikation) – detta är ett alltmer använt begrepp på IT-avdelningen som speglar att även kommunikationen är en väsentlig del av det som en IT-avdelning sysslar med. Företagets IT-avdelning kallas internt för ICT, men i denna uppsats används oftast begreppet IT-avdelning, men även de andra begreppen kan förekomma, där det känns mer precist att använda dem.
Pilotinstallation och pilot
Den första implementationen av ett affärssystem på en marknad eller företag kallas ofta för en pilotinstallation eller kort bara för piloten.
sid 5
2. Teori
Kapitlet redogör för den teoretiska referensram som använts i denna studie. Först beskrivs systemutveckling och affärssystem. Sedan följer en beskrivning om projektstyrning och risker och riskanalys. Globala projekt är den sista pusselbiten som beskrivs innan kapitlet sammanfattas i en teoretisk referensram där karaktäristiska egenskaper, risker och dess mot- åtgärder från respektive område sätts samman.
2.1. Systemutveckling
Systemutveckling kallas processen som börjar med en beställning och slutar med driftsättningen av ett datorsystem. I processen ingår att skriva kravspecifikation, att systemera, testa, programmera och driftsätta (Ruparelia, 2012). Systemutveckling bedrivs ofta i projekt och det finns flera olika utvecklingsmetoder som kan användas, där den vanligaste har varit vattenfallsmetoden där arbetet är specifikationsdrivet (Ruparelia, 2012). I vattenfallsmetoden bedrivs arbetet i ett antal faser som genomförs sekventiellt och de brukar vara följande:
utvärdering, krav, analys, design, utveckling, validering och driftsättning (Ruparelia, 2012). En variant på vattenfallsmetoden är den spiraldrivna metoden som delar upp arbetet i iterationer och som är risk-drivet, dvs. att man i varje fas bestämmer mål, utvärderar alternativ och identifierar och minskar risker, utvecklar och testar, för att till sist planera nästa iteration. En annan metod kallas Unified Process Model och är istället modell- och användningsfallsdriven och kan sägas vara den metod som svarar upp på de speciella krav som objekt-orienterad systemutveckling ställer (Ruparelia, 2012). Ruparelia (2012) beskriver också flera andra metoder som agil, extreme programming, scrum och menar att framtidens metoder kommer att behöva låna idéer från domäner utanför systemutveckling som beteendeanalys, tidsstyrning och affärsstyrning för att ytterligare stärka samarbetet mellan deltagarna i ett systemutvecklingsprojekt.
2.1.1. Systemutveckling – några karaktäristiska egenskaper
Systemutveckling är ofta svårt och det finns undersökningar som visar att 31% av nya projekt avbryts innan de är klara och att 52,7% har dragit över budget med 189% när de väl är klara (Akmanligil & Palvia, 2004). Orsaker till varför systemutvecklingsprojekt misslyckas är olika men en dålig förståelse mellan affärsverksamheten och IT-avdelningarna verkar vara en av huvudanledningarna. Bennett, McRobb & Farmer (2010) konstaterar att åtminstone en del av de potentiella riskerna kan påverkas av utvecklarna och att det är varje professionell utvecklares ansvar att göra vad man kan för att minska dessa risker. Systemutveckling är komplext och individer kan ha olika perspektiv som kan påverka deras synsätt i en situation och det i sin tur kan påverka vad de anser att man ska göra åt situationen (Bennett et al., 2010).
Systemutvecklingsprojekt ställs inför en mängd olika utmaningar eftersom utvecklingsprojekt skiljer sig från andra projekt då de är osynliga, komplexa och har svårigheter att jämka samman kundkrav, tekniska parametrar, gruppmedlemmars och chefers erfarenheter och tekniska plattformar (Tomasi, Parolia, Han, & Porterfield, 2015). Vidare, menar Tomasi et al. (2015), är projekten centrerade runt människor och hanterar extrem osäkerhet. De har också tids- och budgetrestriktioner och utförs av grupper som ofta är tillfälligt sammansatta (Tomasi et al., 2015).
sid 6
2.1.2. Risker med systemutveckling
Bennett et al. (2010) presenterar följande tabell med problem varför systemutvecklingsprojekt misslyckas tillsammans med förslag på hur man kan minska dessa risker. Rekommendationerna tar bland annat upp ett systematiskt arbetssätt och användandet av moderna metoder som RUP (IBMs Rational Unified Process), AUP (Agile Unified Process), EUP (Enterprice Unified Process) och DSDM (Dynamic Systems Development Method) (Bennett et al., 2010, s. 65-66).
Prototyping och användarmedverkan, är två andra sätt att säkra upp systemutvecklingen.
Problemtyp Problem Hur man kan minimera
risken
Kvalitet Fel problem löses Strategisk information, Systemplanering, Affärsmodellering, Systematiskt angreppssätt Projektet startas av fel anledning Strategisk information,
Systemplanering, Affärsmodellering, Systematiskt angreppssätt, Prototyping
Tar inte hänsyn till det större sammanhanget.
Systematiskt angreppssätt, Krav, Prototyping
Saknar eller har olämplig funktionalitet
Felaktig kravanalys Systematiskt angreppssätt,
RUP, AUP, EUP
Användarna ändrar sig Prototyping,
Användarmedverkan, RUP, Yttre händelser ändrar förutsättningarna AUP
Dåligt designat gränssnitt Prototyping,
Användarmedverkan Olämplig datainmatning
Mjukvaran gör att man måste arbeta på ett olämpligt sätt
Systematiskt angreppssätt, Användarmedverkan Obegripliga felmeddelanden Användarmedverkan Hjälp som inte hjälper
Krav som ändras innan projektleveransen Systematiskt angreppssätt, RUP, Agile, AUP
Installation och drift
Dålig installation Systematiskt angreppssätt,
Test, Driftsättning Ej driftsäkert
Driftsproblem Systematiskt angreppssätt,
Test Dåliga svarstider
Dålig dokumentation försvårar underhåll Systematiskt angreppssätt, Utvecklarverktyg
Lokalt motstånd till nya informationssystem Användarmedverkan
sid 7
Tabell 1- Orsaker till varför IS-projekt misslyckas och förslag till lösningar (Bennett et al., 2010, s. 65) – [egen översättning]
I en internationell studie med ambitionen att skapa en auktoritativ lista fann man 53 olika risk faktorer (Schmidt, Lyytinen, Keil, & Cule, 2001). De olika faktorerna grupperades under följande 14 kategorier (Schmidt et al., 2001, s. 16):
1. Företagets miljö (Corporate Environment) 2. Ägarskap (Sponsorship/Ownership)
3. Hantering av relationer (Relationship Management) 4. Projektledning (Project Management)
5. Omfång (Scope) 6. Krav (Requirements) 7. Finansiering (Funding)
8. Schemaläggning (Scheduling)
9. Utvecklingsprocessen (Development Process) 10. Personal (Personnel)
11. Bemanning (Staffing) 12. Teknologi (Technology)
13. Externa beroenden (External Dependencies) 14. Planering (Planning)
I en annan studie fann man sex dimensioner av risker – Organisatoriska risker (exv. intern politik, organisationsförändringar och brist på support för projektet), användarrisker (exv. brist på användarmedverkan), kravrisker (exv. krav som ändras eller är oklara), komplexa projekt (exv. ny teknik eller många externa beroenden till andra system), planering och uppföljning (exv. dålig planering och uppföljning innebär orealistiska tidplaner och budgetar) och projekt- gruppen (exv. problem med motivation, kunskapsbrister, eller hög personalomsättning) (Wallace, Keil, & Rai, 2004).
Produktivitet Implementation är inte möjlig Prototyping
Omöjliga mål Systematiskt angreppssätt,
Agile, AUP, DSDM Tidsbegränsningar
Krav som ändras
Dålig projektkontroll Styra IS-utveckling,
Återanvändning Försenad leverans
Inget system levereras alls Kostnadsöverdrag
Utvecklare känner inte till Objekt- Orientering
Styra IS-utveckling, Utbildning
sid 8
2.1.3. Motåtgärder kopplade till risker
Ett systematiskt arbetssätt tillsammans med användarna av systemet verkar vara en del av lösningen till att minska riskerna. Andra moderna utvecklingsprinciper som manifestet för agil systemutveckling, tar också upp vikten av individer och interaktion och av kundsamarbete (Manifest för Agil systemutveckling, 2016). Riskerna verkar minska om utvecklarna arbetar tillsammans med användarna, har ett systematiskt arbetssätt och använder moderna metoder som prototyping (Bennett et al., 2010).
Tomasi et al. (2015) konstaterar att en framgångsrik systemutveckling beror på hur mycket man låter de mänskliga resurserna investera i projektet. Dessa investeringar fås genom att antingen utbilda befintlig personal eller genom att hyra in specialister. Han konstaterar att gruppens förmågor och relationer är viktigare än tekniska kunskaper som programmeringskunskap eller speciell applikationskunskap (Tomasi et al., 2015).
2.2. Affärssystem
Vad är ett affärssystem och vilka ”löften” får en organisation när man står inför en implementering av ett affärssystem? Ett affärssystem har karaktäristiska egenskaper som skiljer sig från andra system. Implementeringen av ett affärssystem har också speciella risker och dessa risker kan reduceras med motåtgärder.
2.2.1. Definition
En organisation använder en mängd olika applikationer, program och system och de finns ofta i en mängd olika former, allt från enskilda en-användarapplikationer till de stora verksamhetsöverskridande system som i dagligt tal kallas för affärssystem. Ett affärssystem kan definieras som ”… packages of computer applications that support many, even most, aspects of a company’s … information needs.” (Davenport, 2000, s. 2). Affärssystem beskrivs också som “Standardiserade verksamhetsövergripande systemstöd” (Magnusson & Olsson, 2008, s.
1). En annan definition är att affärssystem inte bara är mjukvara utan ett sätt att göra affärer (Bansal & Agarwal, 2015). I dessa definitioner finns löften om betydligt mer än bara systemstöd. De ska ge stöd åt varje verksamhetsdel av organisationen samtidigt som de ska vara överskridande och ge en överblickbarhet och göra det möjligt för ledningen att via en
”dashboard” kunna styra organisationen ungefär som en kapten kan styra en båt från bryggan (Magnusson & Olsson, 2008). Samtidigt förväntar sig organisationen få färdiga ”best practice”- processer som kan hjälpa dem att standardisera sina verksamhetsprocesser. Ofta finns en förväntan om att kunna rulla ut globala gemensamma (standardiserade) processer samtidigt som det finns en förväntan om att de ska vara flexibla och lätta att anpassa till lokala krav, om inte annat så till lokala kulturella (exempelvis språk, datumformat och valuta) och legala krav (Davenport, 2000).
2.2.2. Risker och motåtgärder
Det är inte svårt att förstå att önskemål och krav på verksamhetsöverskridande systemstöd kan skapa stora problem vid införandet av ett affärssystem. Davenport (2000) redogör för ett antal olika företagsfall som visar på vad som kan gå fel i en affärssystemsimplementation:
sid 9
Ett europeiskt oljebolag börjar efter åtta år äntligen att få affärsnytta av sitt system men då slår ägarna ihop företaget med en annan organisation vars system blir det som man väljer att fortsätta med (s. 34-36).
En amerikansk tillverkare av datorer försöker byta system utan att ha tydliga affärsskäl och baserar beslutet på tekniska överväganden. 160 människor arbetade fulltid och projektets kostnad närmade sig $225 miljoner dollar då projektet avbröts. Slutresultatet blev bara en HR modul. Företagets affärsmodell ändrades under projektet från att försöka implementera en global lösning med gemensamma processer till en mer decentraliserad lösning där geografiska- och produkt-enheter fick behålla sin autonomi.
Erfarenheten är att inte förändra affärsmodellen under projektet. Affärssystem fungerar bra i företag som är starkt centraliserade och de kan anpassas till att fungera i en decentraliserad organisation men det fungerar inte att byta från en centraliserad styrning till en decentraliserad under projektets gång. Även om företaget skulle fått igång systemet är det mycket osäkert om det någonsin skulle kunna realisera affärsnyttan eftersom affärsmålen var oklara från början (s. 36-39).
Ett bolags kultur kan också påverka hur man lyckas. General Semiconductor (inte ett riktigt namn) hade en kultur där dess ingenjörer arbetade hårt, snabbt och kreativt för att lösa alla tänkbara problem. Ingen hade tid att berätta hur man arbetade för konsulterna och varje problem sågs som en kundunik ”one-off exercise”. Erfarenheten från detta projekt är att företaget kommer att möta stora risker om det system man försöker implementera inte passar företagets kultur. Davenport menar följande ”If your company doesn’t care about business processes beforehand, buying an ES package won’t change that aspect of the culture. If your company doesn’t care much about information, an ES also isn’t a good fit.” (s. 40-41) (ES = Enterprice System, annat namn för affärssystem).
Dessa tre fall visar att ägarnas strategier, bolagets affärsmodell, självbild och kultur kan ha avgörande inverkan på om ett affärssystemsprojekt kommer att lyckas eller inte. Riskerna ovan ligger utanför vad en projektledare eller projektdeltagare förväntas hantera. Det är snarare projektets styrgrupp tillsammans med bolagets ledning som är ansvariga för att skapa förutsättningar för projektet. Men projektledaren är ofta den som först märker av problemen och den som bör ta upp riskerna i sin styrgrupp.
Aloini et al. (2007) har undersökt vilka de vanligaste riskfaktorerna i affärssystemsprojekt är genom att göra en litteraturgenomgång. De fem vanligaste riskerna är (Aloini et al., 2007):
1. Otillräcklig urvalsprocess inför val av affärssystem 2. Ineffektiv strategi och planering
3. Ineffektiva projektledningstekniker 4. Dåligt ledarskap
5. Otillräcklig hantering av förändringar
Enligt Aloini et al. (2007) har de första två riskerna studerats väl medan övriga behöver mer studier. Aloini et al. (2007) fortsätter med att konstatera att de flesta risker inträffar tidigt och har en stor inverkan under hela affärssystemslivscykeln.
sid 10
Ehie och Madsen (2005) har också undersökt vilka faktorer som har en stark korrelation med framgångsrika affärssystemsprojekt och de fann att följande sex faktorer var signifikanta:
1. Projektledningsprinciper
2. Genomförbarhet och utvärdering av affärssystem i bolaget 3. Stöd från högsta ledningen
4. Omformning av affärsprocesser (business process re-engineering) 5. Konsultstöd
6. Kostnader och budget
I en studie bland mellanstora företag i Indien fann Bansal och Agarwal (2015) att de viktigaste identifierade framgångsfaktorerna vid affärssystemsimplementering är ett starkt stöd från ledningen, förändring av företagets processer, användarutbildning och att använda konsulter med kunskap om både verksamheten och teknologin. ”Stress the enterprise, not the system”
(2015, s. 1338) och de menar att det är viktigt att hitta rätt system för sin verksamhet. De går vidare och konstaterar att det är ett måste för ett företag att ha egen ”in-house” IT-kapacitet och att det råder konsensus i litteraturen över vilka kritiska framgångsfaktorer som finns och att de flesta faktorer också är relevanta för mindre organisationer (Bansal & Agarwal, 2015).
Bansal och Agarwal (2015) har skapat följande ramverk som beskriver hur de sex viktigaste framgångsfaktorerna (se nedan i figuren) påverkar varandra och projektets framgång.
sid 11
Figur 1 - Ett ramverk för att tolka hur framgångsfaktorer påverkar varandra och framgången hos ett projekt (Bansal &
Agarwal, 2015, s. 1343).
Bansal och Agarwal (2015) menar att välja rätt leverantör och att försäkra sig om att man har ledningens stöd är en förutsättning och dessa faktorer påverkar i sin tur urvalsprocessen och projektgruppens kompetens. I ett mindre företag kan man anta att ledningen förstår och har insikt i hela verksamheten och om man ger sitt stöd åt affärssystemsprojektet kommer man också att tillsätta ett kompetent team (Bansal & Agarwal, 2015). Senare i projektet kan ett kompetent team driva ledningen till att fortsätta stödja projektet. Sambandet mellan faktorerna ändrar riktning (Bansal & Agarwal, 2015).
Även Davenport (2000) listar fem punkter med rekommendationer för att lyckas med affärssystemsprojektet.
Make it a business initiative – Implementera bara om det finns starka affärsskäl och se till att det är ett verksamhetsprojekt och inte ett IT-projekt.
A strong output orientation – fokusera på att realisera affärsnytta och glöm inte av att följa upp. Behandla affärssysteminvesteringen som alla andra investeringar.
A clear vision of “who we are” – skapa en gemensam bild av hur många av processerna och hur mycket av information som ska delas. Hur kommer bolagets kultur att påverka införandet?
sid 12
Strategic clarity - Alla i bolagets ledning måste vara överens om hur bolaget skapar värde. Fokuserar man på produktinnovation, operational excellence eller på
kundnärhet? Det passar kanske inte ett bolag att ha ett gemensamt affärssystemstöd för alla sina processer.
Constancy of purpose - Långsiktighet eller beständighet. Det kan ta över 10 år innan bolaget kan realisera sin fulla affärsnytta från investeringen. Se till att alla förstår att det tar tid och att det krävs en långsiktighet.
Det verkar finnas en samstämmighet i de olika studierna, att det är viktigt att affärssystems- projektet väl överensstämmer med bolagets strategi och att högsta ledningen är både väl medveten om vad som hur projektet påverkar bolaget och deltar aktivt för att stötta det (Aloini et al., 2012; Bansal & Agarwal, 2015; Davenport, 2000). Att det inte heller rör sig om ett rent IT-projekt förstår man av namnet. Det är i väldigt hög grad ett affärsprojekt och mjukvara och teknik är bara en del av projektet (Davenport, 2000). Omformningen av organisations processer är en stor del och det är också klart att projektet inte tar slut bara för att systemet är installerat.
Det är ett långsiktigt projekt och det kan dröja innan affärsnyttan realiseras. Det gör att projektet också påverkas av förändringar utanför själva projektet som konjunkturer, förändringar i bolagets strategier eller i koncernens organisation (Davenport, 2000).
2.3. Projektstyrning
Ett projekt brukar definieras som en tillfällig organisation som har skapats för att under en begränsad tid uppnå vissa mål (Görling, 2009). För att styra och kontrollera detta arbete som sker utanför den vanliga organisationen behövs en projektplan och gärna en projektmetod.
Planen förvaltas av projektledaren och visar hur projektet kan uppnå målen (Görling, 2009).
Metoden ger förslag på hur man kan arbeta.
PRINCE2 (Projects in Controlled Environments) är en av de populära projektmetoderna (Matos
& Lopes, 2013). PRINCE2 karakteriseras av att den drivs av ett projekts business case som granskas regelbundet under projektet för att se att det fortfarande uppfylls trots att affärsmålen kan ändras under projektet (vilket ofta sker) (Matos & Lopes, 2013). En annan populär metod som också är en internationell standard (IEEE Std 1490-2003) är PMBOK och den beskriver i detalj tekniker för projektledning (Matos & Lopes, 2013). Om PMBOK är beskrivande kan man säga att PRINCE2 är mer föreskrivande och föreslår hur tekniker för projektledning ska struktureras och implementeras (Matos & Lopes, 2013).
2.3.1. Projektprocesser
De olika projektmetoderna delar in ett projekt i processer och även om indelningen skiljer sig mellan de olika metoderna kan man hitta likheter (Matos & Lopes, 2013). Här presenteras processerna i PMBOK och i PRINCE2.
sid 13
PMBOK PRINCE2
Initiating Starting Up
Directing
Planning Inititating
Planning
Executing Controlling a Stage
Managing Product Delivery
Controlling Directing
Closing Closing
Tabell 2 - Projektets processer (Matos & Lopes, 2013, s. 791)
I tabellen ovan ser man att de olika metoderna har stora likheter i sin processindelning. Görling (2009) gör en liknande indelning men använder faser, Definitionsfasen, Planeringsfasen, Genomförandefas och Reflektionsfas. Varje process och fas har sina olika uppgifter men en gemensam uppgift är att man mellan de olika delarna stämmer av verkligheten mot planen, diskuterar eventuella korrigerande åtgärder samt genomför en ny riskanalys (Görling, 2009).
2.3.2. Planering
Planering är ett viktigt steg i all ledning och styrning och i projektstyrning är det en av sakerna som anses vara huvudorsak till att ett projekt lyckas (Zwikael, Pathak, Singh, & Ahmed, 2014).
Planen ska inte bara visa vägen till målet utan har också en uppgift att skapa förutsägbarhet, hantera risker och ge oss en möjlighet att följa upp hur projektet fortskrider (Görling, 2009).
Enligt Zwikael et al. (2014) har det under senare år blivit vanligare att ifrågasätta den formella planeringens nytta. I projekt med hög risk (som systemutvecklingsprojekt) verkar planeringen inte bidra lika mycket till projektets framgång som i projekt med lägre risk, exempelvis byggnadsprojekt (Zwikael et al., 2014).
Oavsett metod har valet av projektledare stor betydelse för hur projektet kommer att lyckas (Matos & Lopes, 2013). Även Besteiro, Pinto och Novaski (2015) konstaterar att projektledaren bidrar om de har god kunskap och förståelse för framgångsfaktorerna i ett projekt.
Ett projekts framgång analyseras traditionellt utifrån de tre projektrestriktionerna – funktionalitet, tid och kostnad (Besteiro et al., 2015). Enligt Besteiro et al. (2015) innebär detta att det är svårt att avgöra om ett projekt är framgångsrikt eftersom det beror på intressenternas perspektiv, vilken typ av projekt det är, tidsperspektivet och organisationen. Besteiro et al.
(2015) fortsätter genom att konstatera att även om projektets framgång ofta mäts i slutet av projektet kan det ta flera månader och ibland år innan framgången realiseras.
2.4. Risker och riskanalys
Risktagning är oundvikligt om man vill åstadkomma förändring oavsett om det är i form av ett projekt eller inte. Att hantera riskerna är något som görs under hela projektet men är extra viktigt
sid 14
i början. Det är nödvändigt för projektledaren att ta fram en realistisk projektplan och riskanalys för att visa att det är troligt att projektet kommer att nå sina mål (AXELOS Limited, 2013).
2.4.1. Vad är en risk?
En risk är en osäkerhet som har en påverkan på hur projektet kan nå sina mål (Aloini, Dulmin,
& Mininno, 2012). Risker är alltid osäkra. Om en risk blir säker så är det inte längre en risk.
När man talar om risker menar man ofta negativa saker som kan inträffa, men även osäkra möjligheter (positiva) bör hanteras i riskhanteringen (AXELOS Limited, 2013). Det visar sig att de flesta ledare enbart koncentrerar sig på de negativa utfallen och enbart ser dessa som risker (Wallace et al., 2004). Det är dessa negativa utfall som kan leda hot mot projektets framgång som ledare försöker kontrollera (Wallace et al., 2004). Risker har ofta olika namn som riskfaktorer, kritiska framgångsfaktorer eller osäkerhetsfaktorer. Alla dessa kan grupperas under benämningen risk (Aloini et al., 2007). Specifika risker med systemutveckling och i affärssystemsprojekt finns mer beskrivet under respektive rubrik (se ovan 2.1.2. och 2.2.2).
2.4.2. Riskanalys
Projektmetoden Prince2 menar att riskhanteringen ska vara ett systematiskt arbetssätt med att identifiera, bedöma och kontrollera riskerna (AXELOS Limited, 2013). Prince2 (AXELOS Limited, 2013) poängterar också att en riskhanteringsstrategi innebär att man skapar ett register över alla risker och att man skriver in projektets styrgrupps riskbenägenhet. Riskbenägenheten visar hur mycket risk en styrgrupp tolererar eller accepterar. När riskerna blir större än vad som accepteras ska en avvikelserapport skapas. Varje företag och/eller projekt har olika acceptans för risker (AXELOS Limited, 2013).
Ett av skälen varför projekt inte lyckas är att ledningen inte genomför en ordentlig riskanalys och därefter genomför de planer som har tagits fram för att hantera riskerna (Aloini et al., 2007).
I flera fall upplever projektledaren att riskhanteringen tar extra tid och arbete och om man ligger efter kan dessa åtgärder vara något som man drar in på. Aloini et al. (2007) presenterar en generell riskhanteringsprocess som består av sju olika faser:
1. Kontextanalys 2. Riskidentifiering 3. Riskanalys 4. Riskvärdering 5. Riskhantering
6. Övervakning och granskning 7. Kommunikation och konsultation
Aloini et al. (2007) modell kan förenklat ritas upp på följande sätt:
sid 15
Figur 2 – Riskhantering (Aloini et al., 2007, s. 548)
För att riskhanteringsprocessen ska passa för ett affärssystemsprojekt krävs dock att den tar hänsyn till att dessa projekt är tvärvetenskapliga och täcker ett stort område, både affärsprocesser och mjuk- och processutveckling. Aloini et al. (2007) menar vidare att riskhantering består av två delar där den första försöker reducera chansen att risken inträffar och att den andra delen handlar om att hantera risken när den väl har inträffat.
Riskhantering är en av de viktiga funktionerna i projektledning och har traditionellt setts som en separat aktivitet som genomförs i början på varje projektfas (Jaafari, 2001). Jaafari (2001) menar att detta är fel och i verkligheten utsätts ett projekt för kontinuerliga utmaningar. Istället för att analysera de enskilda riskerna, är det korrekta sättet, enligt Jaafari, att kontinuerligt omvärdera projektets möjligheter att nå målen och ha en beredskap för att handla. Inte ens med den bästa planeringen och utvärderingen av alla risker, kan projektet ta fram all nödvändig information och därför gäller det att ha så många alternativ öppna som möjligt och fatta besluten när de behövs för att undvika suboptimering som kan inträffa om man låser fast sig vid beslut för tidigt eller innan alla fakta är kända (Jaafari, 2001). Ett strategibaserat och målinriktat angreppssätt är, enligt Jaafari, det mest effektiva försvaret mot irrationalitet och bristande objektivitet.
Det är viktigt att förstå att man aldrig helt kommer att kunna eliminera riskerna i projektet. Det finns ingen som kan garantera att projektet lyckas men genom att genomföra en ordentlig riskanalys kan man balansera arbetet med att minska risker och med att hantera dem när de trots allt uppstår (Görling, 2009).
sid 16
2.5. Globala projekt
Tuff konkurrens och snabb globalisering gör att flera företag söker sig till andra marknader än sina hemmamarknad (Bansal & Agarwal, 2015). Även medelstora och mindre företag skapar globala organisationer och konkurrerar alltmer på en global marknad (Bansal & Agarwal, 2015). Bansal och Agarwal (2015) menar att för att lyckas krävs det att företagen kommer närmare sina kunder och kan leverera värdeskapande produkter och tjänster snabbare och snabbare och det innebär att organisationerna måste integreras och affärsprocesserna måste bli globala. Alltfler företag inför ett affärssystem för att nå dessa mål (Bansal & Agarwal, 2015).
2.5.1. Distribuerad systemutveckling
För att hitta sätt att reducera kostnaderna i projekt och få tillgång till kompetens har flera organisationer, som redan verkar globalt, börjat med det som kallas distribuerad systemutveckling (Distributed System Development, DSD). Det innebär att man söker efter resurser utanför sitt företag och på en annan plats (Shrivastava & Date, 2010). Holmström, Fitzgerald, Ågerfalk, och Conchúir (2006) anser att distribuerade utvecklingsprojekt är projekt som består av team som arbetar tillsammans för att uppnå projektmål från olika geografiska platser. Ibland hittar man dessa resurser utanför sitt lands gränser och då kan man tala om Global Software Development (GSD). Högre kompetens och/eller en lägre kostnad kommer med ett pris i form av högre komplexitet och därmed högre risk (Holmström et al., 2006).
Om flera olika team sitter på olika geografiska platser har teamen ofta olika teknisk kompetens och det finns en risk att den geografiska uppdelningen får en inverkan på uppdelningen av arbetet. Detta är inte alltid optimalt eftersom det kan leda till att vissa team blir specialister inom ett speciellt område. Detta kan leda till en arkitektur som återspeglar teamens geografiska utbredning (Conway’s law) (Shrivastava & Date, 2010).
Ett effektivt team har medlemmar vars erfarenheter, metoder, beslut och kunskaper ackumuleras under utvecklingsprocessen genom en effektiv informationsspridning och kunskapsdelning. För att åstadkomma detta i GSD-projekt får ett centralt bibliotek (eng.
repository) en nyckelroll. Saknas detta kan det innebära att ledningen inte kan dra nytta av GSD upplägget (Shrivastava & Date, 2010).
Det finns naturligtvis också fördelar med distribuerad systemutveckling, ofta tillsammans med outsourcing i en eller annan form. Holmström et al. (2006) menar att globaliseringen av många organisationer har inneburit att globalt distribuerade samarbeten och virtuella team blir allt vanligare. Tidigare var drivkrafterna låga kostnader och tillgång till kompetens, men nu är det allt oftare en närhet till nya marknader, snabbare virtuella företag som kan utnyttja marknadsmöjligheter och ett behov av att få flexibilitet när det gäller att kapitalisera på sammanslagningar och företagsköp när dessa möjligheter presenterar sig. Det är som ett resultat av dessa faktorer som Holmström et al. (2006) menar att mjukvaruutveckling alltmer är multisite (flera platser) och multikulturellt.
Projekt- och ledningsfrågor som planering och kostnadsuppskattningar blir mycket svårare att göra eftersom man ofta har krav och specifikationer som förändras över tiden, kulturella olikheter och brist på informell kommunikation (Shrivastava & Date, 2010). Det tar alltså mer
sid 17
resurser och tid att hantera GSD-projekt. Tekniska frågor som påverkar flera siter behöver ofta synkroniserade planer och det innebär att gemensamma milstolpar och klara start- och slutpunkter måste vara på plats. Planeringen måste göras på detaljnivå och spänna över ett stort område. Till sist nämner Shrivastava och Date (2010) att riskplaneringen naturligtvis också blir mer komplex och svår.
2.5.2. Kulturella skillnader
Affärssystemsimplementation pågår ofta över en längre tid och har större projektteam än många andra systemutvecklingsprojekt och det innebär att traditionella tekniker för att bygga ett projektteam inte räcker till (Jones, 2008). Projektledaren har i uppgift att skapa ett projektteam med medlemmar som har olika bakgrund, erfarenheter, perspektiv, kultur och mål samtidigt som de kan komma från olika funktioner och ha olika rang och senioritet (Jones, 2008). Jones (2008) menar att projektledare ofta tar till samma teamstärkande tekniker som i mindre projekt men att de ofta inte räcker till. Jones (2008) avser att en projektledare ofta släpper fokus på teambyggandet när andra dagliga kritiska händelser inträffar och att det kan ge team som fungerar sämre. Det är viktigt, enligt Jones (2008), att använda och adressera alla de fyra viktiga uppgifterna med aktiviteter och att kontinuerligt följa upp och repetera dessa allteftersom nya medlemmar kommer till, eller att det inträffar andra externa händelser.
Uppgift Förslag på aktivitet
Forma teamet (Build the Team) Formella och informella teamövningar, som middagar, för att överbrygga externa hinder som medlemmarna kan tänkas ha med sig.
Utjämna skillnader (Equalize the Team) Belöna alla teammedlemmar på samma sätt oavsett rang och senioritet eller försök att ta bort hierarkiska strukturer och markörer.
Strukturera teamet (Structure the Team) Ändra arbetsplatsen för teamet och placera dem utanför deras ordinarie plats för att minimera risken att de identifierar sig mer med gruppen som sitter nära dem, än med sitt projektteam.
Finjustera teamet (Tweak the Team) Fortsätt att övervaka och justera teamet över projektets hela livscykel för att hindra att teamet börjar falla sönder.
Tabell 3- Fyra teamuppgifter med aktiviteter och motiv (Jones, 2008, s. 116) [egen översättning]
Kulturella skillnader kan leda till kommunikationsproblem. GSD-projekt kräver mycket kommunikation och om denna är otillräcklig på grund av att teamets sammansättning ofta ändras eller på grund av problem med tidszonskillnader, kommer detta direkt att påverka produktiviteten (Shrivastava & Date, 2010).
Hakim och Hakim (2010) har i en studie gått igenom ett antal olika artiklar för att försöka skapa en praktisk modell för att kontrollera affärssystemsimplementationsrisker. De konstaterar att kultur och människor är de två huvudfaktorerna som påverkar utveckling av IT-system.
Förändringar i kultur måste börja i ett företags ledningsgrupp och hos de som definierar och
sid 18
skapar bolagets policys och det är deras beteende och beslut som får en direkt påverkan på de anställdas och företagets partners, prestationer och attityder. Företagskulturen påverkar alltså också den typ av relation som ett företag har med sina partners och därmed också den typ av service som man får från sina externa partners (Hakim & Hakim, 2010).
Kulturella skillnader inom kritiska dimensioner som nationella, professionella, etiska, organisatoriska, tekniska och teamkultur kan förstärka kommunikationsproblem. GSD-projekt kräver mycket kommunikation och om denna är otillräcklig på grund av att teamens sammansättning ofta ändras eller på grund av problem med tidszonskillnader, kommer detta direkt att påverka produktiviteten (Shrivastava & Date, 2010).
Sammantaget kan konstateras att för globala projekt innebär det att det finns ett geografiskt avstånd mellan projektdeltagarna, det kan också finnas ett tidsmässigt avstånd (olika tidzoner) och även kulturella skillnader.
2.6. Sammanfattning - teoretisk referensram
Genom att ordna de olika karaktäristiska egenskaperna, riskerna och motåtgärderna, från teorin, i grupper under varje rubrik, fås ett antal kategorier som kan användas för att tolka och analysera empirin.
Karaktäristiska egenskaper:
Svårt (Akmanligil & Palvia, 2004) och komplext (Bennett et al., 2010)
Stort omfång. Har moduler som täcker nästan alla av företagets processer, har stöd för
”best practice” och är både flexibla och anpassningsbara (Davenport, 2000)
Strategier. Ägarnas strategier, bolagets affärsmodell, självbild och kultur påverkar projektet (Davenport, 2000)
Pågår under lång tid (Jones, 2008; Davenport, 2000)
Stora projektteam (Jones, 2008)
Geografiskt avstånd mellan projektdeltagare (Shrivastava & Date, 2010)
Tidsmässigt avstånd mellan projektdeltagare (olika tidszoner) (Shrivastava & Date, 2010)
Kulturella skillnader mellan projektdeltagare (Jones, 2008)
Riskerna inordnades under de kategorier av riskfaktorer som Schmidt et al. (2001) tagit fram (se också tidigare under rubriken 2.1.2. Risker med systemutveckling):
Företagets miljö
o Ineffektiv strategi och planering (Aloini et al., 2007) o Omformning av affärsprocesser (Ehie & Madsen, 2005) o Förändring av företagets processer (Bansal & Agarwal, 2015) o Otillräcklig urvalsprocess (Aloini et al., 2007)
sid 19
o Genomförbarhet och utvärdering av affärssystem i bolaget (Ehie & Madsen, 2005)
Ägarskap
o Stöd från högsta ledningen (Ehie & Madsen, 2005) o Starkt stöd från ledningen (Bansal & Agarwal, 2015)
Hantering av relationer
o Dåligt ledarskap (Aloini et al., 2007)
o För lite användarmedverkan (Bennett et al., 2010)
Projektledning
o Projektledningsprinciper (Ehie & Madsen, 2005) o Riskhantering (Aloinie et al., 2007)
Omfång
o Dålig förståelse mellan verksamheten och IT-avdelningarna (Bennett et al., 2010)
o Otillräcklig hantering av förändringar (Aloini et al., 2007)
Krav
o Svårigheter att jämka samman kundkrav, tekniska parametrar, gruppmedlemmars och chefers erfarenheter och tekniska plattformar (Tomasi et al., 2015)
Finansiering
o Planering och kostnadsuppskattningar blir svårare att göra (Shrivastava & Date, 2010)
Schemaläggning
o Realistiska projektplaner (Görling, 2009)
Utvecklingsprocessen
o Brister i processen eller metoderna leder till kvalitetsproblem (Bennett et al., 2010)
Personal
o Brister i att hantera projektteam (Jones, 2008)
Bemanning
o Använda konsulter med kunskap om både verksamhet och teknologin (Bansal
& Agarwal, 2015)
o Konsultstöd (Ehie & Madsen, 2005)
Teknologi
o Användandet av ny teknologi (Schmidt et al., 2001)
Externa beroenden
o Konsultstöd (Ehie & Madsen, 2005)
Planering
o Svårt att planera (Ehie & Madsen, 2005)
sid 20 Motåtgärder:
Ändamålsenligt arbetssätt
o Strukturerat och systematiskt arbetssätt (Bennett et al., 2010) o Användandet av moderna metoder (Bennett et al., 2010) o Användarmedverkan och prototyping (Bennett et al., 2010)
o Interaktion och kundsamarbete (Manifest för Agil systemutveckling, 2016)
Rätt kompetens
o Utbildning och kompetenta konsulter (Tomasi et al., 2015) o Viktigt med egen IT-kompetens (Bansal & Agarwal, 2015) o Välja rätt leverantör (Bansal & Agarwal, 2015)
Verksamheten kommer först
o Ändra verksamheten och inte i systemet (Bansal & Agarwal, 2015)
o Se till att det är ett verksamhetsprojekt och inte ett IT-projekt (Davenport, 2000) o Skapa en gemensam bild av hur gemensamma processer och information ska ske
(Davenport, 2000)
Stöd från ledningen
o Försäkra sig om att man har ledningens stöd (Bansal & Agarwal, 2015) o Fokusera på att realisera affärsnytta (Davenport, 2000)
o Alla i bolagets ledning måste vara överens om hur bolaget skapar värde (Davenport, 2000)
o Förändringar i kultur måste börja i ledningsgruppen (Hakim & Hakim, 2010)
Långsiktighet
o Målen nås troligen inte under själva projektet utan det kan ta lång tid (Davenport, 2000)
Jobba aktivt med projektteamet
o Aktivt försöka skapa en team- eller vi-känsla (Tomasi et al., 2015)
o Fokusera på alla Jones fyra viktiga områden under hela projektets livscykel (Build the Team, Equalize the Team, Structure the Team och Tweak the Team) (Jones, 2008)
Realistisk projektplanering
o Realistiska projektplaner och en genomförd riskanalys (Aloini et al., 2007) o Synkroniserade detaljerade planer med gemensamma milstolpar och klara start-
och slutpunkter (Shrivastava & Date, 2010)
Dokumentation och kommunikation
o Dokumentera mer och gör dokumentation tillgänglig för alla (centralt bibliotek) (Shrivastava & Date, 2010)
Genom att sätta samman dessa egenskaper, risker, motåtgärder och projekttriangeln skapas denna modell.
sid 21
Figur 3- Referensmodell för att analysera risker i globala affärssystemsprojekt
Modellen har till syfte att hjälpa oss klassificera, presentera och analysera de resultat som samlats in. Den avser inte att visa på vilka egenskaper som leder till vilka risker eller vilka motåtgärder som motverkar vilka risker eller försöka leda i bevis att det alltid är på ett visst sätt.
sid 22
3. Metod
Detta kapitel beskriver uppsatsens forskningsansats, val av metod och motiv, en mer detaljerad beskrivning av metoderna, hur insamlingen av empirin har gått till samt hur den analyserades.
Avslutningsvis reflekteras kort över kvalitetsproblem och alternativa tillvägagångssätt.
3.1. Forskningsansatser
Utgångspunkten för studien är att studera vilka risker som finns och hur man kan minska dem i globala affärssystemsprojekt. Syftet är att beskriva de aktiviteter som ett företag kan göra på planeringsstadiet för att minska dessa risker. Studien vill vidare, i detalj, undersöka hur ett företag uppfattar riskerna och vad de gör för att motverka dem. För att få en helhetsbild tittar studien på hur olika individerna i ett projekt upplever riskerna och motåtgärderna utifrån deras perspektiv.
Deduktiv forskning är forskning som bygger på tidigare forskningsresultat och prövar teorin mot verkligheten medan induktiv forskning ofta använder flera olika metoder och försöker skapa ny teori ifrån det insamlade materialet (Bryman & Bell, 2012). En kombination av dessa ansatser kallas abduktion. Denna studie vill undersöka om de risker och motåtgärder som finns beskrivna i den teoretiska referensramen också återfinns i ett verkligt projekt och utifrån detta är studiens ansats deduktiv. Men studien undersöker också om det finns risker eller motåtgärder som används i praktiken och som inte finns med i teorin i den teoretiska referensramen och utifrån denna ansats kan studien kallas för induktiv. Eftersom denna studie kombinerar dessa ansatser blir studiens ansats abduktiv.
3.2. Forskningsstrategi
För att studera ett komplext problem på djupet krävs mycket material som behöver samlas in, tolkas och förstås. Syftet med denna studie är att beskriva och förstå en del av de aktiviteter som ett företag bör göra på planeringsstadiet för att minska riskerna i globala affärssystemsprojekt. För att kunna beskriva och förstå behöver studien intervjua nyckelpersoner i fallstudieföretaget och få deras beskrivningar av hur de uppfattar vilka risker och motåtgärder som finns i fallstudieföretaget. Beskrivningar behöver tolkas och förstås tillsammans med respondenterna i studien för att kunna öka kunskapen inte bara hos forskaren utan också i fallstudieföretaget. Problemet som studeras i denna studie är väl avgränsat men det finns många variabler och mycket av det insamlade materialet är beskrivningar av hur olika respondenter uppfattar situationen. En forskningsstrategi som lägger vikt vid ord, har ett tolkande synsätt och lägger tonvikten på hur individer uppfattar och tolkar sin sociala verklighet, är kännetecken på en kvalitativ forskning (Bryman & Bell, 2012). Denna studie är därmed en kvalitativ undersökning. Valet av vilka metoder man kan använda i sin undersökning styrs av vilken vetenskapssyn studien har, om det är en induktiv eller deduktiv ansats och om metoderna är kvantitativa eller kvalitativa. I detta fall har jag som forskare en speciell roll som också påverkar valet av metoder.
sid 23
3.2.1. Min bakgrund och nuvarande roll
Jag har arbetat med systemutveckling i mer än trettio år och har deltagit i många olika projekt, både lokala och globala. Mina roller har varit allt från utvecklare till beställare och projekten har ibland bedömts som framgångsrika och ibland som misslyckade. I många fall har projektets mål ändrats över tiden och ofta har projekten bedömts som framgångsrika även om man kanske inte nådde de mål som sattes upp initialt. De senaste åren har jag arbetat allt mer med affärssystemsprojekt och då ofta i en internationell miljö. När denna studie genomförs har jag ett uppdrag för det svenska bolaget som analyseras i studien och är ansvarig för de projekt som ska skapa gränssnitten mellan affärssystemet och omgivande systemen. Jag har tidigare varit globalt ansvarig för företagets alla system och applikationer och varit en del av företagets IT- ledningsgrupp. I både min tidigare och nuvarande roll hjälper jag och stöttar företaget i dess roll som beställare mot olika leverantörer. Mitt och studiens perspektiv är alltså från fallstudie- företagets IT-ledningsgrupp snarare än som projektdeltagare eller leverantör. Företaget håller på att byta ut sitt gamla affärssystem mot ett nytt och detta bedrivs i ett globalt projekt, delvis med outsourcade resurser som befinner sig i olika delar av världen.
3.2.2. Val av metod
Min egen roll i projektet gav mig en unik möjlighet att genomföra en fallstudie med aktionsforskning samtidigt som jag arbetade i ett parallellt program. Som ansvarig för de gränssnitt som ska tas fram, har jag både insyn i affärssystemsprojektet och kan observera projektet utifrån men har samtidigt tillgång till nyckelpersoner och material. Som praktiker har jag en lång erfarenhet av att arbeta i globala projekt och litteraturstudierna skapar den teori som krävs för att reflektera, generalisera och teoretisera den praxis som används i projektet.
Uppslaget till uppsatsen har presenterats för företagets CIO och han såg fördelar med att göra denna studie och vill gärna se om den kan presentera förslag på hur man kan förbättra planeringen och arbetssättet i liknande projekt i framtiden. Det nuvarande projektet kommer att följas av flera implementationer på andra marknader. Enligt Bryman et al. (2012) är kravet på aktionsforskning att den ska vara till nytta för både praktikern och verksamheten.
Studien är en fallstudie där aktionsforskning används tillsammans med intervjuer. Valet att tillämpa aktionsforskning gör det möjligt att analysera praktiken och utifrån den öka kunskapen (Bryman & Bell, 2012).
3.2.3. Fallstudie
Fallstudien är begränsad till ett fall, dvs. ett företag. Fallstudier innebär att man undersöker ett mindre urval mer noggrant än vad som annars är möjligt i exempelvis en enkätstudie. Syftet är att få ökad kunskap och en djupare förståelse för sammanhanget (Bryman & Bell, 2012). Fallet som studeras är riskhanteringsprocessen i ett projekt som syftar till att införa ett nytt affärssystem inom en global koncern. Systemet ska införas på flera företag i olika länder.
Koncernen vill ha ett gemensamt arbetssätt och därför tar projektet fram en global lösning som ska installeras i ett pilotbolag (det svenska bolaget). När studien genomfördes var projektet i full gång och det befann sig i slutet av designfasen. Fallet passar för studiens forskning om globala affärssystem eftersom det har de förutsättningar som studien eftersöker.
sid 24
Företaget har valts ut på grund av att det var tillgängligt och kostnadseffektivt, dvs. ett bekvämlighetsurval. Mitt uppdrag på företaget i ett parallellprogram gav mig unik insikt och tillgång till internt material och till nyckelpersoner som jag kunde studera och intervjua.
Fallstudieföretaget
Koncernen består av ett antal tillverkande bolag med fabriker i flera länder i Europa, i Nord- och Sydamerika, i Indien och i Kina. Koncernen omsätter nästan 5 miljarder SEK och har runt 2 200 anställda. Det är noterat på Nasdaq Stockholm Exchange och har sitt huvudkontor i Sverige. Man kan säga att koncernen är ett litet ”stor-företag”. Koncernen producerar produkter till den tunga fordonsindustrin och har både så kallade OEM-kunder (Original Equipment Manufacturer) och eftermarknadskunder. (Paulcén, 2016). I uppsatsen kallar jag koncernen omväxlande för företaget eller bolaget.
3.2.4. Aktionsforskning
När man som praktiker på ett systematiskt sätt utforskar sin praxis kallas det för aktionsforskning och det kan liknas vid en spiral där man identifierar problem, samlar in data, startar nya åtgärder och slutligen omdefinierar problemet. Stegen planera – agera – observera – reflektera ingår. Det är kopplingen mellan ”aktion” och ”forskning” som bäst beskriver vad det handlar om, dvs. att pröva idéer för att förbättra eller öka kunskapen om sin praxis (Björndal, 2002). När processer i en organisation ska studeras är aktionsforskningen speciellt användbar och används ofta när forskaren är en del av organisationen som ska studeras men eftersom forskaren blir en del av studieområdet innebär detta också problem (Bryman & Bell, 2012).
Aktionsforskningen i denna studie är mer av det passiva slaget där forskaren inte själv planerar och genomför en aktion utan har en mer passiv roll i planeringen och genomförandet. Mitt uppdrag för fallstudieföretaget är i ett parallell program och inte i det projekt som studeras.
Intervjuerna tar upp hur arbetet planerats, hur det bedrivs idag och ställer frågor om förbättringar. Men eftersom jag också arbetar nära projektet har jag kunnat ha flera informella samtal och gjort observationer som kompletterar de svar jag fått i den formella intervjun.
Tillsammans har vi kunnat reflektera över vad som fungerar bra och vad som kan förbättras.
Detta får till följd att en omedelbar återkoppling, en lärprocess, kan ske till de aktörer som är verksamma i projektet (Björndal, 2002). Deltagande aktionsforskning kan utgöra en grund för kontinuerligt lärande för både forskaren och de organisationsmedlemmar som deltar (Bryman
& Bell, 2012).
3.3. Datainsamlingsmetoder
Undersökningen har använt olika datainsamlingsmetoder, litteraturstudie, intervjuer och förandet av en loggbok. Internt material som mötesanteckningar, presentationer och information på företagets interna webbplatser har också studerats för att hitta relevant information. Projektet, som studerades, har en egen central webbplats där all dokumentation samlas.
