Organisationshinder mot komponentbaserad systemutveckling (HS-IDA-EA-01-306) Kristoffer Byhlén (a98kriby@student.his.se) Institutionen för datavetenskap Högskolan i Skövde, Box 408 S-54128 Skövde, SWEDEN

Organisationshinder mot komponentbaserad systemutveckling

(HS-IDA-EA-01-306)

Kristoffer Byhlén (a98kriby@student.his.se) Institutionen för datavetenskap

Högskolan i Skövde, Box 408 S-54128 Skövde, SWEDEN

Examensarbete på det systemvetenskapliga programmet under vårterminen 2001.

Organisationshinder mot komponentbaserad systemutveckling

Examensrapport inlämnad av Kristoffer Byhlén till Högskolan i Skövde, för Kandidatexamen (B.Sc.) vid Institutionen för Datavetenskap.

2001-06-08

Härmed intygas att allt material i denna rapport, vilket inte är mitt eget, har blivit tydligt identifierat och att inget material är inkluderat som tidigare använts för erhållande av annan examen.

Signerat: _______________________________________________

Organisationshinder mot komponentbaserad systemutveckling Kristoffer Byhlén (a98kriby@student.his.se)

Sammanfattning

Komponentbaserad informationssystemutveckling är en metod där system utvecklas och byggs med komponenter. Dessa komponenter är utbytbara och tanken är att organisationer ska kunna minska utvecklingstiden och utvecklingskostnaderna för informationssystem. I det här arbetet har en undersökning gjorts där personer inom några organisationer intervjuats. Undersökningens mål har varit att svara på frågan om det finns någon skillnad mellan unga och gamla organisationers hinder mot införandet av komponentbaserad informationssystemutveckling. Undersökningen har kommit fram till att unga organisationer stöter på ett mindre motstånd mot förändringsarbetet än gamla organisationer och att detta kan bero på att unga organisationer har en organisationskultur som är mer öppen för förändringar.

Nyckelord: Komponentbaserad systemutveckling, förändringsarbete,

organisationshinder, unga och gamla organisationer.

Innehållsförteckning

1 Introduktion ... 1

2 Bakgrund... 2

2.1 Förändringsarbete inom organisationer...2

2.2 Informationssystemsutveckling ...2

2.3 Komponentbaserad systemutveckling...3

3 Tidigare och relaterade arbeten... 6

3.1 Kritiska framgångsfaktorer vid införande av komponentbaserad systemutveckling ...6

3.2 Skillnader mellan unga och gamla organisationers hinder...9

4 Problembeskrivning... 10

4.1 Problemprecisering ...10

4.2 Problemavgränsning...10

4.3 Förväntat resultat ...10

5 Val av metod... 12

5.1 Dokument ...12

5.2 Dagböcker...12

5.3 Intervju och enkät ...13

5.3.1 Standardisering ...13

5.3.2 Strukturering ...13

5.4 Attitydformulär ...15

5.5 Observation...15

6 Genomförande... 16

6.1 Företagskontakt...16

6.2 Presentation av organisationerna ...16

6.3 Intervjuer ...17

6.4 Intervjufrågor...18

7 Resultat och analys ... 22

7.1 Presentation av resultat ifrån intervjuerna...22

7.2 Analys av organisationerna ...31

7.3 Jämförelse av resultat och kritiska framgångsfaktorer...32

8 Slutsatser ... 36

9 Diskussion... 37

9.1 Olika typer av intervjuer ...37

9.2 Utvärdering av undersökningen...37

9.3 Litteratur...37

9.4 Förslag till fortsatt arbete ...38

Referenser

Introduktion

1 Introduktion

Tanken med komponentbaserad systemutveckling är att en organisation ska kunna sätta ihop ett system utifrån redan existerande komponenter (Herzum & Sims, 2000).

Dessa kan vara komponenter som finns i organisationens tidigare system och som de själva har utvecklat, eller så kan det vara en färdig komponent som köps in utifrån.

Genom att använda komponentbaserad systemutveckling så kan organisationer reducera utvecklingstiden och kostnaden för att utveckla informationssystem (Kunda

& Brooks, 2000). Även driftskostnaderna kan enligt Kunda och Brooks reduceras genom komponentbaserad systemutveckling.

Det finns trots detta en stor risk att kostnaderna för en organisation ökar kraftigt under övergångsperioden då den inför komponentbaserad systemutveckling, samt att övergångsperioden sträcker sig över flera år (Herzum & Sims, 2000). Organisationen bör alltså försöka att minska längden på övergångsperioden, samt se till att kostnadsökningarna under övergångstiden blir så små som möjligt.

Kostnadsökningarna kan vara en följd av att organisationen måste lära sig ett nytt arbetssätt.

Det finns ett antal kritiska framgångsfaktorer vid införandet av komponentbaserad systemutveckling i en organisation. Olika individer i organisationen kan ha olika mål och syften som kan påverka deras motivation till att ta del av förändringsarbetet.

Vidare kan organisationens struktur och ledarskap påverka förändringsarbetet (Kunda

& Brooks, 2000). Dessa kritiska framgångsfaktorer påverkar organisationens förmåga att ta till sig komponentbaserad informationssystemsutveckling och reducera kostnaderna för övergången.

En organisations förändringsvilja och förändringsbenägenhet är en viktig förutsättning för att organisationen ska klara en alltmer internationaliserad och hårdnad konkurrens (Angelöw, 1991). Att införa komponentbaserad informationssystemutveckling kan vara ett sätt för organisationer att korta ned utvecklingstiden för informationssystem och därigenom stärka sin position på markanden.

Kunda och Brooks (2000) skriver att det skulle vara av intresse att undersöka

skillnader mellan olika typer av organisationers hinder vid införandet av

komponentbaserad informationssystemsutveckling. Den här rapporten kommer att

titta på om det finns någon skillnad mellan unga och gamla organisationers hinder vid

införandet av komponentbaserad systemutveckling.

Bakgrund

2 Bakgrund

I det här kapitlet kommer ett antal begrepp som är relevanta för undersökningen att beskrivas. Det börjar med begreppet förändringsarbete inom en organisation. Sedan förklaras vad systemutveckling är för att sedan avslutas med en definition av vad komponentbaserad informationssystemutveckling är.

2.1 Förändringsarbete inom organisationer

Organisationer förändras i takt med sin omvärld och måste agera i förhållande till förändringar i samhället. En organisations förändringsvilja och förändringsbenägenhet är därför en viktig förutsättning för att organisationen ska klara av en alltmer internationaliserad och hårdnad konkurrens (Angelöw, 1991). Informationssystem är inte isolerade ifrån omvärlden, utan de existerar i ett socialt och organisatoriskt sammanhang (Kunda & Brooks, 2000). Dåliga informationssystem som inte används beror sällan på tekniska problem utan snarare på människor och organisatoriska problem (Avison & Fitzgerald, 1995). Det borde alltså finnas ett intresse hos organisationer att förbättra sitt arbetssätt ifall förändringen leder till bättre informationssystem som i högre grad används av användarna. Likaså borde det vara av intresse för organisationerna att förbättra sitt arbetssätt om det leder till kortare utvecklingstider för informationssystem, då detta skulle ge dem en fördel gentemot konkurrenter med längre utvecklingstider.

2.2 Informationssystemsutveckling

I Nationalencyklopedin (1996) definieras informationssystemsutveckling som följande:

Systemutveckling, aktivitet i vilken man systematiskt utreder förutsättningarna för att genom ett datorstött informationssystem (IS) förbättra verksamheten i ett företag eller en organisation samt i överensstämmelse med resultatet utformar, konstruerar och inför IS i praktisk tillämpning.

Ett informationssystem inom en organisation tillhandahåller användbara fakta för dess medlemmar och klienter vilket bör hjälpa organisationen att fungera effektivt (Avison

& Fitzgerald, 1995). Enligt Avison och Fitzgerald (2000) så är information fakta som inte lämnar några antydningar, utan är klar och tydlig. Människor med kunskap vet hur informationen som presenteras för dem ska användas, och bör därför bli bättre lämpade att utföra sin uppgift. Skillnaden mellan data och information är att information är relevant och meningsfull för någon person eller grupp (Avison &

Fitzgerald, 1995).

Enligt Avison och Fitzgerald (1995) så är många informationssystem designade att tillhandahålla relevant information till användarna som beslutsunderlag. Information behöver presenteras vid rätt tid, på en tillräcklig detaljnivå och med tillräcklig exakthet för att vara till användning för mottagaren. Detta kommer att hjälpa till att försäkra att organisationens informationsresurser utnyttjas till fullo (Avison &

Fitzgerald, 1995).

I allmänhet organiseras systemutveckling som projekt och uppfattas ofta som

bestående av ett antal faser (Nationalencyklopedin, 1996). Faserna i

Bakgrund

informationssystemsutveckling kan bestå i att analysera det nuvarande systemet och identifiera krav, analysera kraven och komma fram till förbättringar av informationssystemet, design och programmering, samt implementering av informationssystemet (Avison & Fitzgerald, 1995).

Till sin hjälp vid informationssystemsutveckling har systemutvecklare ett antal tekniker, verktyg och metoder. En teknik är ett sätt att utföra en specifik aktivitet i informationssystemsutvecklandet och kan involvera användande av ett eller flera verktyg (Avison & Fitzgerlad, 1995). Verktyg är ofta datorbaserade och utformade för att vara ett stöd i informationssystemsutvecklingen. Ett exempel på verktyg är CASE- verktyg (Computer aided software engineering) och som är designade till att hjälpa utvecklaren under hela utvecklingsfasen och inte bara under en specifik aktivitet. En metod definieras enligt Avison och Fitzgerald (1995, s. 10) som:

a collection of procedures, techniques, tools, and documentation aids which will help the systems developers in their efforts to implement a new information system. A methodology will consist of phases, themselves consisting of sub-phases, which will guide the systems developers in their choice of the techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate information systems projects.

En metod är alltså enligt Avison och Fizgerald (1995) ett antal procedurer, tekniker, verktyg och dokument som hjälper informationssystemsutvecklare i deras arbete. En metod består av ett antal faser som består av arbetsmoment som ska utföras under fasen. En metod kan även ge stöd och riktlinjer för hur projektet bör planeras, hanteras, kontrolleras, samt utvärderas (Avison & Fitzgerald, 1995).

2.3 Komponentbaserad systemutveckling

En av de grundläggande tankarna med komponentbaserad systemutveckling är att en organisation ska kunna sätta ihop ett system utifrån redan existerade komponenter (Herzum & Sims, 2000). Existerande komponenter kan vara komponenter som finns i organisationens tidigare system och som de själva har utvecklat, eller så kan det vara en färdig komponent som köps in utifrån. En färdig komponent som köps in utifrån kallas COTS vilket står för Commercial off-she-shelf business component (Herzum &

Sims, 2000).

Herzum och Sims (2000, s. 11) definierar komponentbaserad systemutveckling enligt följande:

Component-based development is a software development approach where all aspects and phases of the development lifecycle, including requirements analysis, architecture, design, construction, testing, deployment, the supporting technical infrastructure, and also the project management, are based on components.

I komponentbaserad systemutveckling så baseras alltså kravanalys, design, konstruktion, testning och implementation på komponenter. Alla aspekter och faser inom komponentbaserad systemutveckling genomsyras av komponenttänkandet.

Komponentbaserad systemutveckling har ungefär samma steg som en mer traditionell

Bakgrund

systemutvecklingsmetod. Den stora skillnaden mellan komponentbaserad systemutveckling och en mer traditionell systemutvecklingsmetod är att utvecklarna i komponentbaserad systemutveckling alltid ska tänka i och identifiera lämpliga komponenter (Herzum & Sims, 2000).

Enligt Kunda och Brooks (2000) så flyttar komponentbaserad systemutveckling fokus från systemspecifikation och konstruktion, till identifiering, införande, integrering och uppgradering av komponenter. Komponenttänkandet genomsyrar alltså hela utvecklingsprocessen. Komponentbaserad systemutveckling har potential att reducera utvecklingskostnader och utvecklingstiden för informationssystem, samt att reducera driftskostnaderna (Kunda & Brooks, 2000).

Två stora risker med att införa ett nytt arbetssätt i en organisation och sålunda även komponentbaserad informationssystemsutveckling är att kostnaderna ökar kraftigt under den övergångsperiod då organisationen inför den nya modellen, samt att övergångsperioden sträcker sig över flera år (Herzum & Sims, 2000). De största kostnaderna under övergångsperioden beror enligt Herzum och Sims (2000) till stor del på organisationens inlärningskurva och de ”barnsjukdomar” som finns hos nuvarande komponentbaserade teknologier. På grund av detta så är ett av de viktigaste målen vid införande av komponentbaserad informationssystemsutveckling att kontrollera övergångskostnaderna (Herzum & Sims, 2000). Ett stort motstånd hos utvecklare, köpare och ledning, leder till att organisationen enligt Kunda och Brooks (2000) måste lägga ned stora resurser på att informera och utbilda de anställda. Detta kan i sin tur leda till att övergångsperioden vid införandet av komponentbaserad systemutveckling blir längre, samt att kostnaderna under övergångsperioden ökar.

Enligt Herzum och Sims (2000) så är en komponent en komplett mjukvarukonstruktion med en definierad användning, som har ett run-time-gränssnitt, kan utvecklas självständigt, och är byggd med kunskap om en specifik komponentsocket. En komponentsocket gör det möjligt för komponenter att kommunicera med varandra. En komponents run-time-gränssnitt består av alla de möjliga operationer som komponenten kan utföra på förfrågan från en annan komponent. Herzum och Sims (2000, s. 40) definierar en komponent som:

(…) software implementation of an autonomous business concept or business process. It consists of all the software artifacts [sic] necessary to represent, implement, and deploy a given business concept as an autonomous reusable element of a larger distributed information system.

Autonom betyder i det här sammanhanget inte att komponenten är isolerad. En komponent kan tillhandahålla användbara funktioner genom samarbete med andra komponenter (Herzum & Sims, 2000). Med utgångspunkt i definitionen ovan så skulle en möjlig bra komponent kunna vara begreppet kund i en databas. Däremot så skulle begreppet datum antagligen inte vara lika bra som komponent, då datum ofta är förknippade med till exempel en händelse och därmed inte autonom.

En komponentsocket är en applikation som tillhandahåller ett väldefinierat och välkänt run-time-gränssnitt till en struktur i vilken en komponent passar (Herzum &

Sims, 2000). Komponenten kan via en komponentsocket kopplas samman med flera

Bakgrund

komponenter som tillsammans bildar ett system. En komponentsocket fungerar alltså som systemets infrastruktur, som håller alla komponenter samman och sköter kommunikationen mellan komponenterna.

En av de vanligast förekommande applikationer för integrering av komponenter är

enligt Kunda och Brooks (2000) CORBA. CORBA står för Common Object Request

Broker Architecture och är en applikation som gör det möjligt för komponenter att

kommunicera med varandra över nätverk (Lunney & McCaughey, 2000).

Bakgrund

3 Tidigare och relaterade arbeten

3.1 Kritiska framgångsfaktorer vid införande av komponentbaserad systemutveckling

Kunda och Brooks (2000) har gjort en undersökning där de har kartlagt hinder som tre organisationer har stött på vid införandet av komponentbaserad systemutveckling.

Utifrån dessa hinder så har Kunda och Brooks (2000) kommit fram till ett antal kritiska framgångsfaktorer som påverkar en organisations förmåga att införa komponentbaserad systemutveckling i verksamheten. Dessa kritiska framgångsfaktorer redovisas nedan i detta kapitel. Avslutningsvis så skriver Kunda och Brooks (2000) att det skulle vara intressant om någon undersökte om det finns några skillnader mellan de hinder som olika typer av organisationer stöter på vid införandet av komponentbaserad systemutveckling. Om det finns skillnader mellan olika typer av organisationers hinder vid införandet av komponentbaserad systemutveckling, kan detta påverka hur komponentbaserad systemutveckling bör introduceras i organisationen. Som exempel på fortsatt arbete skriver Kunda och Brooks (2000) att någon skulle kunna titta på om det finns någon skillnad mellan hinder som unga och gamla organisationer stöter på vid införandet av komponentbaserad systemutveckling.

Användarnas känsla av ägandeskap

Enligt Kunda och Brooks (2000) så är användarnas medverkan en viktig faktor vid komponentbaserad systemutveckling vilken kan leda till att användarna får en känsla av ägande och motivation. Om inte användare involveras i komponentbaserad systemutveckling så leder det till motstånd mot det nya systemet, då användarna inte känner att systemet tillhör dem (Kunda & Brooks, 2000). Vidare skriver Kunda och Brooks (2000) att då komponentbaserad systemutveckling är ett nytt sätt att se på systemutveckling så är det absolut viktigaste i förändringsprocessen att få intressenter och huvudsponsorer att stödja förändringsarbetet. Det är alltså viktigt att de som i slutändan ska använda informationssystemen är för användandet av komponentbaserad informationssystemutveckling, då deras medverkan i utvecklingsarbetet är viktigt för systemets acceptans och användning.

Motivation och grad av entusiasm

Det kan enligt Kunda och Brooks (2000) vara svårt att övertyga utvecklare inom organisationen som är vana att använda ett speciellt arbetssätt till att byta arbetssätt.

Dock är det enligt Kunda och Brooks (2000) viktigt att utvecklarna och även användarna är motiverade till att använda sig av komponentbaserad systemutveckling.

I den fallstudie som Kunda och Brooks (2000) gjorde så var det en del svarande som tyckte att informationen om hur komponentbaserade tekniker skulle införas och användas var otillräcklig och att utvecklarna tvingades att börja använda sig av komponentbaserad systemutveckling enbart för att det var det senaste ”inne-ordet”

inom informationssystemsutveckling. I och med detta anser Kunda och Brooks (2000)

att identifieringen och tillhandahållandet av lämplig träning inom komponentbaserad

systemutveckling är en viktig aktivitet vid införandet av komponentbaserad

systemutveckling i en organisation för att öka motivationen till att gå över till ett nytt

arbetssätt.

Bakgrund

Uppmuntran

Sättet som uppmuntran ges till utvecklare kan leda till motstånd mot återanvändning och komponentbaserad systemutveckling då en del utvecklare betalas utifrån antalet rader med kod som de skriver (Kunda & Brooks, 2000). Vidare så skriver Kunda och Brooks att en del chefer betalas utifrån den årliga produktionen vilket kan ge upphov till motstånd till införandet av komponentbaserad informationssystemutveckling hos cheferna. Det kan nämligen ta ett tag innan fördelarna med komponentbaserad systemutveckling uppstår på grund av långa övergångsperioder.

Politiska frågor

Individer som arbetar tillsammans i en grupp brukar normalt interagera och kommunicera på både ett formellt och ett informellt sätt. Om individer i en grupp inte är i harmoni, så kommer det att påverka systemet negativt (Kunda & Brooks, 2000).

På grund av detta så bör informell kommunikation, enligt Kunda och Brooks, uppmuntras under komponentbaserad systemutveckling. Om det är dålig kommunikation mellan ledning och de anställda kan det påverka de anställdas motivation till att medverka vid förändringsarbetet, vilket i sin tur kan påverka förändringsarbetet och det slutgiltiga resultatet negativt (Sarker & Lee, 1999). Enligt Sarker och Lee så är det viktigt att ledningen formulerar en vision för hur den nya organisationen ska se ut och fungera, för att skapa en förändringsvilja hos medlemmarna i organisationen.

Kunda och Brooks (2000) skriver att status, makt och auktoritet inom en organisation kan skapa problem vid införandet av komponentbaserad systemutveckling inom en organisation. Ett exempel kan vara att en person med stort inflytande inom organisationen kan tvinga utvecklarna att köpa ett verktyg som inte passar vid komponentbaserad systemutveckling bara för att personen såg en annons om verktyget. Att uppmärksamma olika maktfördelningar och deras verkningar kan vara till hjälp vid införandet av komponentbaserad systemutveckling (Kunda & Brooks, 2000).

Organisations- och affärsstrategi

Enligt Kunda och Brooks så kan det ta ett bra tag innan de positiva effekterna av komponentbaserad systemutveckling framträder. Om en organisation har en kortsiktig affärsstrategi, så kan det medföra ett motstånd eller bristande engagemang inom organisationen. Att uppmuntra en mer långsiktig affärsstrategi kan leda till en framgångsrik implementation av komponentbaserad systemutveckling (Kunda &

Brooks, 2000).

Organisationens upplägg och ledningens stil

Om organisationen har små resurser så kan det leda till att det blir svårare för förändringsprojekt att få ledningens stöd (Kunda & Brooks, 2000). Genom att utbilda ledningen och visa på fallstudier där införandet av komponentbaserad systemutveckling i en organisation har lyckats, så kan det öka ledningens stöd för projektet.

Olika avdelningar i organisationen kan tendera till att tävla med varandra vilket kan inverka negativt vid införandet av komponentbaserad systemutveckling (Kunda &

Brooks, 2000). Detta kan enligt Kunda och Brooks leda till bristande stöd för

Bakgrund

komponenter som skulle vara bra för båda avdelningarna, men som inte till hundra procent passar kraven för varje specifik avdelning. Avdelningarna ser till sina egna intressen framför organisationens intressen (Kunda & Brooks, 2000). Sarker & Lee (1999) beskriver hur ledningen i det företag de studerade, först och främst godkände modifieringar i organisationen som gynnade deras egna intressen i stället för att se till organisationens bästa, vilket fick en negativ inverkan på förändringsarbetet i organisationen.

Organisationens kultur

Enligt Angelöw (1991) så består en organisationskultur av existerande normer och värderingar inom organisationen. En organisations normer beskriver alltså hur en individ i organisationen bör handla, för att leva upp till de normer som råder inom organisationen. Normer gör det möjligt för organisationer att uppnå de mål som organisationen strävar efter (Nationalencyklopedin, 1996). Det kan alltså vara så att det i organisationen finns en åsikt att det arbetssätt som organisationen använder sig av i dagsläget är det bästa, vilket kan leda till motstånd mot förändringsarbete.

I grova drag kan en kultur definieras som ett antal påhittade lösningar av en grupp människor på specifika problem som uppkommit genom situationer som de ställs inför tillsammans (Van Maanen & Barley, 1985). En organisations kultur förändras sålunda över tiden, då medlemmar av organisationen ställs inför liknande problem och kommer på strategier för att lösa problemen. Dessa strategier för att lösa olika problem upptas av organisationen och förmedlas till nya medlemmar (Van Maanen &

Barley, 1985). Den ovanstående definitionen av en kultur är enligt Van Maanen och Barley (1985) giltig för alla grupper, såväl samhället i stort, som organisationer och familjer.

En organisations kultur påverkar systemkraven och acceptansen av dem.

Användarnas, utvecklarnas och ledningens motstånd mot förändring är i de flesta fall ärvt ifrån organisationens kultur (Kunda & Brooks, 2000). Vidare så skriver Kunda och Brooks att flera av de svarande i fallstudien som genomfördes indikerade att de inte var villiga att ändra sitt arbetssätt, vilket tyder på att organisationen behöver ändra på organisationskulturen för att lyckas med att införa komponentbaserad systemutveckling. Långsiktig utbildning och träning kan medverka till att ändra på människors attityder och organisationens kultur (Kunda & Brooks, 2000).

Kunda & Brooks (2000) skriver att nya förmågor, tankesätt och modeller, och organisationens engagemang är viktiga faktorer vid en förändring av en organisations kultur. Nya tankesätt och förmågor kan tillföras organisationens kultur genom att organisationen tar tillvara på de tankesätt och de förmågor som nyanställda tillför (Kanter m.fl.,1992). Utvecklares utbildning i nya modeller och tekniker, samt ledningens stöd vid införandet av komponentbaserad systemutveckling kan hjälpa till att förändra en organisations kultur.

Enligt Angelöw (1991) är det viktigt för organisationer att skapa en

organisationskultur, eller en form av förändringskultur som ger ett bra stöd och

underlättar vid förändringar i organisationen. Därför bör förändringsarbetet inom en

organisation inriktas på att analysera och förändra värderingar som finns inom

organisationen.

Bakgrund

3.2 Skillnader mellan unga och gamla organisationers hinder

Organisationers åldrande kan leda till att hinder uppstår. Till exempel så kan problem uppstå när grundarna av en organisation går i pension, eller på annat sätt släpper ifrån sig makten till nya personer. Nya ledare kan ha nya idéer om vilken inriktning, samt vilken strategi som organisationen ska ha. När fler och fler nya personer tillkommer i en ung organisation krävs det att organisationen definierar organisationens kultur samt ett sätt att föra över kulturen på nykomlingarna inom organisationen (Kanter m.fl., 1992). Vidare så kommer en ung organisation att tvingas till förändringar i och med att organisationen växer. Alla unga organisationer kommer att ställas inför förändringar som en del av åldringsprocessen (Kanter m.fl., 1992). Små, unga organisationer har ofta en enkel struktur och styrs ofta mer informellt av ledningen, som ofta består av grundarna.

Då organisationen växer krävs ofta förändringar av dess struktur för att hantera den större organisationen, vilket är ett problem som alla organisationer som växer måste hantera. Unga organisationer har enligt Kanter m.fl. (1992) även ofta problem med att bekosta kostnaderna för nya tekniker. De kan ha svårare att få banklån och har kanske inte lika stort kapital som en äldre eller större organisation. Ett annat problem som unga organisationer kan stöta på är att det går väldigt bra för organisationen vilket skapar en övertro på den egna kapaciteten. Detta kan leda till att organisationen för snabbt börjar konkurrera med de stora aktörerna på markanden, innan den är redo för det (Kanter m.fl., 1992).

Unga och gamla organisationer som växer måste även hantera alla nya personer som tillkommer till organisationen i och med att den växer. Organisationen kan då välja att stöpa de nya personerna efter organisationens egen ”form” och på så sätt bevara traditionerna och värderingarna inom organisationen. Eller så kan organisationen välja att låta de nya personerna påverka organisationskulturen och tillföra nya tankar och idéer till organisationen (Kanter m.fl., 1992).

Problem som gamla organisationer enligt Kanter m.fl. (1992) kan stöta på, är att

organisationen och personerna inom den är motvilliga till att förändras. Motviljan till

att förändras kan leda till att organisationen inte förändras i takt med sin omgivning

och därför går under. Gamla organisationer kan ha svårt att ta till sig nya tekniker då

tron på den egna organisationens förträfflighet kan vara stor (Kanter m.fl., 1992). Att

motivera en förändring kan vara svårt om det tidigare arbetssättet har varit

framgångsrikt. Organisationen kan då ha en motvilja mot att förändras.

Problembeskrivning

4 Problembeskrivning

Enligt Kunda och Brooks (2000) så är organiationella frågor ett problem vid användandet av komponentbaserad informationssystemsutveckling. Organisationers problem med att förstå och införliva organisationella frågor i utvecklingsprocessen, kan leda till att fördelarna med komponentbaserad informationssystemutveckling uteblir. Att integrera organisationella frågor i komponentbaserad informationssystemsutveckling kräver olika strategier beroende på organisationens struktur och omgivning (Kunda & Brooks, 2000). Till exempel så påverkar organisationskulturen systemkraven och accepterandet av dem. Användare, utvecklare och ledningens motvilja till förändring bottnar ofta i organisationens kultur (Kunda &

Brooks, 2000). Kunda och Brooks (2000) tror att unga organisationer är mer dynamiska och har en kultur som gör att de har lättare att införa komponentbaserad informationssystemsutveckling. Om en organisation är gammal eller ung kan i så fall påverka vilka hinder organisationen stöter på vid införandet av komponentbaserad informationssystemsutveckling, vilket i sin tur påverkar hur komponentbaserad systemutveckling bör introduceras i organisationen.

4.1 Problemprecisering

Finns det någon skillnad mellan unga och gamla organisationers hinder mot införandet av komponentbaserad informationssystemsutveckling?

Med unga organisationer i rapporten menas organisationer som inte är äldre än 5-10 år. Om en gammal organisation gått igenom stora förändringar som i grunden har förändrat organisationen kan den klassas som en ung organisation.

4.2 Problemavgränsning

Undersökningen kommer att begränsas till organisationer som utvecklar egna system.

Organisationer som endast utreder problemlösningar men som inte programmerar applikationerna själva kommer alltså inte att ingå i undersökningen. Anledningen är att organisationerna som ingår i undersökningen ska vara likvärdiga. En organisation som programmerar sina egna applikationer till problemlösningarna, kommer antagligen att ställas inför andra hinder än en organisation som endast kommer med problemlösningar. Arbetsprocesserna i organisationerna är olika.

4.3 Förväntat resultat

Undersökningen ska visa på eventuella hinder mot införandet av komponentbaserad informationssystemsutveckling för både unga och gamla organisationer. Dessa hinder ska sedan jämföras för att identifiera eventuella skillnader mellan unga och gamla organisationer.

Unga och gamla organisationer ställs nog inför olika hinder mot komponentbaserad informationssystemsutveckling då de antagligen har olika förutsättningar att utgå ifrån. Anställdas motvilja till förändring kan vara större i en gammal organisation med många traditioner, än i en ung organisation som kanske ännu inte blivit så traditionsbunden. Vidare så kanske unga organisationer har svårare att finansiera förändringarna vid införandet av komponentbaserad informationssystemsutveckling.

Detta kan leda till att anställda och ledning inte får lika stor träning i det nya

arbetssättet, jämfört med en gammal organisation.

Problembeskrivning

Om det finns skillnader mellan de hinder som unga och gamla organisationer stöter på vid införandet av komponentbaserad informationssystemutveckling så påverkar det hur införandet bör genomföras. Om gamla organisationer har en organisationskultur som gör att organisationen stöter på ett större motstånd mot införandet av komponentbaserad informationssystemutveckling än unga organisationer, bör de tänka på att lägga mer resurser på att utbilda utvecklare och ledning i komponentbaserad informationssystemutveckling.

Om unga organisationer har svårare att finansiera införandet av komponentbaserad

informationssystemutveckling kan det påverka hur bra organisationen lyckas med

förändringsarbetet. Om organisationen inte har tillräckligt med resurser att lägga ned

på utbildning av utvecklare och ledning kanske de inte får de kognitiva förmågor som

krävs för att kunna arbeta på det nya arbetssättet på ett effektivt sätt. Detta kanske

leder till att fördelarna med komponentbaserad informationssystemutveckling jämfört

med traditionell systemutveckling uteblir. Unga organisationer bör om så är fallet

vara extra säkra på att de har tillräckigt med resurser innan de börjar med införandet

av komponentbaserad informationssystemutveckling.

Val av metod

5 Val av metod

”Det finns olika sätt att samla information för att få våra frågeställningar besvarade.

(…) Vilken teknik vi väljer beror på vad som verkar ge bäst svar på vår frågeställning i förhållande till den tid och de medel som står till vårt förfogande” (Patel &

Davidsson, 1994, s. 54).

I detta kapitel kommer ett antal tekniker för att samla in information om ett visst problemområde att beskrivas övergripande. Efter varje teknik följer en kort motivering till varför tekniken används i den här undersökningen, eller varför tekniken inte används i undersökningen. De tekniker för att samla in information som beskrivs är dokument, dagböcker, intervjuer, enkäter, attitydformulär och observationer.

5.1 Dokument

En teknik för att samla in information är att studera dokument. Som dokument räknas information som nedtecknats eller tryckts, men även t.ex. filmer, ljudupptagningar, målningar, kartor och fotografier (Patel & Davidsson, 1994).

Komponentbaserad informationssystemsutveckling är en ganska ny metod för systemutveckling och det finns inte några dokument som exakt tar upp det problemområde som den här rapporten utgår ifrån. Därför så kommer inte dokument att användas för att besvara problemställningen. Dock användes dokument för att samla information till beskrivningen av bakgrunden till problemområdet, då det finns dokument som beskriver begrepp som tas upp i undersökningen och som behöver finnas med i rapporten. Vidare finns det tidigare arbeten som ligger till grund för problemområdet som även de behöver redovisas i rapporten.

5.2 Dagböcker

Med dagböcker menar Patel och Davidsson (1994) dagböcker som människor är ombedda att föra kring ämnen som är av intresse att undersöka. Exempelvis så kan det vara en anställd som ombeds att föra dagbok över de arbetsmoment som personen utför på dagarna. Dagböcker som människor skriver spontant är dokument.

Dagböcker kan till exempel användas för att samla in information om när, var och hur en aktivitet utförs, men även till att få reda på hur individen som skriver dagboken uppfattar sin egen tillvaro (Patel & Davidsson, 1994).

Ett sätt som dagböcker skulle kunna användas för att svara på problemställningen på, är om anställda och ledning fick föra dagbok om de tankar och åsikter om komponentbaserad informationssystemsutveckling som de har. Dagboken skulle anställda och ledning kunna föra under den period som komponentbaserad informationssystemsutveckling infördes i organisationen. Genom att analysera dagböckerna skulle sedan hinder mot införandet av komponentbaserad informationssystemsutveckling som anställda och ledning upplevt inom organisationen kunna identifieras.

Den här undersökningen görs under en kortare tidsperiod och därför så är dagböcker

inte ett sätt att samla information som lämpar sig för den här undersökningen, då det

enligt Patel och Davidsson (1994) är viktigt att försäkra sig om representativiteten. Är

Val av metod

veckan en typisk vecka eller var den på något sätt speciell? För att kunna svara på det så måste dagboken föras under flera veckor, något som det inte finns tid för i detta arbete. Därför kommer inte dagböcker att användas i undersökningen.

5.3 Intervju och enkät

Intervjuer och enkäter bygger på frågor. Vid intervjuer så träffar vanligtvis intervjuaren den intervjuade personen, men intervjuer kan även genomföras via telefon (Patel & Davidsson, 1994). Enkäter består oftast av formulär som skickas per post och som personen som ska besvara dem själv får fylla i, men det kan även vara så att en person sitter med och hjälper till att förtydliga frågorna vid behov.

5.3.1 Standardisering

Med standardisering menas hur mycket av ansvaret för frågornas utformning och inbördes ordning som lämnas till intervjuaren. Vid låg grad av standardisering så formulerar intervjuaren själv frågorna vid intervjutillfället, samt bestämmer i vilken ordning som frågorna ställs (Patel & Davidsson, 1994). Låg grad av standardisering gör att intervjuaren kan ställa frågorna i den ordning som är lämplig för den intervjuade. Vid en helt standardiserad intervju så ställs samma frågor i samma ordning till samtliga intervjuade (Patel & Davidsson, 1994).

5.3.2 Strukturering

Med strukturering menas den grad av ”svarsutrymme” som intervjupersonen får att tolka frågorna fritt utifrån sin egen ställning och tidigare erfarenheter. Vid en helt strukturerad intervju så kan intervjuaren förutse vilka svarsalternativ som är möjliga (Patel & Davidsson, 1994). Frågorna kan då förses med svarsalternativ som intervjupersonen får kryssa i. Ett exempel på en fråga med låg grad av strukturering kan till exempel vara ”Vad anser ni att en komponent är?”. Ett exempel på en fråga med hög grad av strukturering är ”Är du nöjd med din arbetssituation?”, då svaret antingen är ja eller nej.

Beroende på kombinationen av intervjuns eller enkätens grad av strukturering och standardisering, får den olika användningsområden (Patel & Davidsson, 1994). Till exempel så är en hög grad av strukturering samt en hög rad av standardisering, bra att använda för en undersökning med en kvantitativ analys av resultatet. En låg grad av strukturering och en låg grad av standardisering är bra att använda för en undersökning med kvalitativ analys av resultatet (Patel & Davidsson, 1994).

Vid intervjuer och enkäter så är intervjuaren beroende av individernas villighet att svara på frågorna. Det är därför viktigt att motivera personerna som ska svara (Patel

& Davidsson, 1994). Genom att klargöra syftet med intervjun eller enkäten, samt den intervjuades roll i att få till stånd en förändring kan den intervjuades motivation öka enligt Patel och Davidsson (1994). Vidare är det viktigt att klargöra om individens bidrag är konfidentiellt eller ej. All denna information måste ges till den intervjuade innan intervjun. Vid enkäter så skickas det ofta med ett brev med information om undersökningen, detta brev bukar kallas missiv.

Enligt Patel och Davidsson (1994) så bör både intervjuer och enkäter börja med

neutrala frågor där den intervjuade får svara på frågor som berör bakgrunden till

problemområdet. För att sedan avslutas med frågor där den svarande får tillfälle att

tillägga sådant som inte tagits med i frågorna men som den intervjuade tycker är

Val av metod

betydelsefulla, eller reflektera över innehållet i frågorna (Patel & Davidsson, 1994).

Ett annat sätt att ordna frågorna under en intervju är enligt Patel och Davidsson (1994) att använda sig av en teknik som heter ”tratt-teknik”. Tekniken anses vara motiverande och aktiverande för personen som blir intervjuad och innebär att intervjun inledes med stora öppna frågor för att sedan gå in på mer specifika frågor (Patel & Davidsson, 1994).

Vid intervjuer och enkäter bör långa, ledande, eller förutsättande frågor, samt negationer undvikas. Vidare bör ordet ”varför” användas med försiktighet vid öppna svar då det enligt Patel och Davidsson (1994) kan leda till kategoriseringsproblem, då de svarande har stort svarsutrymme. Vidare bör frågorna vara formulerade så att intervjupersonen uppfattar och förstår frågan rätt.

Både vid intervjuer och vid enkäter så är det viktigt att göra noggranna förberedelser.

Pilotstudier kan användas för att se om frågornas innehåll, ordning, antal och formulering behöver justeras (Patel & Davidsson, 1994). Pilotstudien bör utföras på en för undersökningen representativ grupp.

I den här undersökningen kommer intervjuer att användas för att samla in information om problemområdet, då intervjuer ger personer inom organisationerna en möjlighet att berätta vilka hinder som de upplever har funnits vid införandet av komponentbaserad informationssystemsutveckling. Intervjuerna kommer att ha en låg grad av standardisering där frågornas utformning är densamma för alla svarande, men där intervjuaren kan ändra på frågornas ordning beroende på vilken person som blir intervjuad. Vidare kommer intervjuerna att ha en låg grad av strukturering där personerna som blir intervjuade får ett stort ”svarsutrymme”. Svaren kommer alltså inte att bestå av ett antal svarsalternativ som intervjupersonen får kryssa för.

Anledningen till att frågorna har en låg grad av strukturering och en låg grad av standardisering är att det endast är fyra organisationer som ingår i undersökningen och därför kommer analysen av resultatet vara kvalitativ i stället för kvantitativ. Enkäter kommer inte att användas då jag anser att enkäter passar bäst till undersökningar där frågorna har en hög grad av standardisering och en hög grad av strukturering. Då undersökningen kommer att bestå av frågor med låg grad av standardisering så passar intervjuer bäst till att få dem besvarade.

Vid den inledande kontakten med organisationerna och de personer som ska intervjuas så kommer syftet med undersökningen att klargöras för att på så sätt öka de intervjuade personernas motivation till att svara på frågorna. Detta är viktigt då de intervjuades motivation att svara på frågorna är viktig för att undersökningen ska bli bra. Intervjuerna kommer att inledas med neutrala frågor där den intervjuade personen får svara på frågor om organisationen i största allmänhet. Sedan kommer frågor som behandlar problemområdet. Intervjun kommer sedan att avslutas med att den intervjuade får möjlighet att komma med egna tillägg samt kommentera frågornas innehåll. Att börja med neutrala frågor och sedan övergå till frågor som behandlar problemområdet anses vara aktiverande för de intervjuade (Patel & Davidsson, 1994).

Någon pilotstudie kommer inte att genomföras för att se om frågornas innehåll,

ordning, antal och formulering är bra. Genom att använda de kritiska faktorer som

Kunda och Brooks (2000) har arbetat fram, så anses frågornas innehåll bli relevant

och därför behövs inte en pilotstudie för att utreda detta. Vidare kommer frågornas

Val av metod

ordning och antal att variera något från intervju till intervju då intervjuerna har en låg grad av standardisering. Slutligen så är intervjuernas formulering inte av en avgörande betydelse då intervjuerna kommer att genomföras på plats och eventuella missförstånd kommer att kunna redas ut. Pilotstudier är nog viktigare att genomföra inför en enkät, där de svarande kommer att sitta själva och fylla i svaren utan någon att fråga om eventuella oklarheter.

5.4 Attitydformulär

En individs attityd är enligt Patel och Davidsson (1994) en individs grundläggande värderingar. Ett sätt att mäta attityder är att använda Likert-skalan, som består av ett antal påståenden som de svarande ska instämma i eller ta avstånd ifrån.

Attitydformulär skulle kunna användas för att få fram de anställdas värderingar och attityder, vilket skulle kunna vara ett sätt att kartlägga en organisations kultur.

Attitydformulär kommer dock inte att användas i undersökningen, då det inte kommer att ske någon djupare kartläggning av organisationernas kulturer och intervjuer därför kommer att kunna ta fram den information som behövs för undersökningen.

5.5 Observation

Observationer är enligt Patel och Davidsson (1994) bra för att samla in information om individers beteende vid vardagliga situationer. Observationer är även bra att använda för att samla in information vid olika tester och experiment. Nackdelen med observationer är att de är dyra och tidsödande (Patel & Davidsson, 1994). Ett annat problem med observationer är att det är svårt att avgöra om observationer av beteenden och skeenden är representativa.

Observationer kommer inte att användas i den här undersökningen, då människors

beteende inte är något som ingår i vår frågeställning.

Resultat och analys

6 Genomförande

I det här kapitlet kommer undersökningens genomförande att presenteras. Kapitlet börjar med att beskriva den inledande företagskontakten, för att sedan beskriva själva tillvägagångssättet vid intervjuerna. Kapitlet avslutas med reflektioner över tillvägagångssättet.

6.1 Företagskontakt

Då intervjuer på plats ute i organisationerna skulle användas i undersökningen, så var det geografiska läget för organisationerna av viss betydelse. Därför inleddes arbetet med att lokalisera lämpliga organisationer att intervjua, med att finna alla organisationer som arbetar med systemutveckling i närområdet. Mer information om organisationerna och deras arbetssätt erhölls genom organisationernas egna hemsidor.

På hemsidorna fanns ofta en indikation om hur organisationen i fråga arbetar, samt information om hur gammal organisationen är. Utifrån detta så gjordes en lista där alla organisationerna rangordnades utifrån hur intressanta de var för undersökningen.

Organisationer som det klart framgick att de arbetar med komponentbaserad informationssystemsutveckling kontaktades först. Personer som har varit intressanta att prata med inom organisationerna vid första kontakten, har varit personer som har kunskap om organisationens arbetssätt.

Den inledande kontakten med organisationerna skedde via telefon. Vid tillfället presenterades problempreciseringen, samt en förfrågan om organisationen kunde tänka sig att medverka i undersökningen. Om organisationen var positiv till medverkan, så planerades en intervju in.

Bortfallet av organisationer som inte kunde delta i undersökningen var relativt stort.

Då komponentbaserad informationssystemsutveckling är ett relativt nytt begrepp så var det en del av organisationerna som inte använde sig av det i sitt arbete. Andra föll ur på grund av att de inte hade tid att medverka i undersökningen, eller för att personerna med kunskap om komponentbaserad informationssystemsutveckling och organisationens arbetssätt inte var anträffbara. En organisation föll ur då de inte själva utvecklade några system utan endast kom med förslag på problemlösningar. En annan då de var mitt uppe i införandet av komponentbaserad informationssystemsutveckling och därför inte hunnit använda sig av det praktiskt ännu.

6.2 Presentation av organisationerna

De fyra organisationerna som ingår i undersökningen kommer att kallas organisation A, organisation B, organisation C och organisation D då en av organisationerna inte ville medverka med namn i rapporten. Då IT-branschen är en ganska ny bransch så finns det inte så många gamla organisationer som i mer traditionella branscher. Därför är de gamla organisationerna i undersökningen relativt unga jämfört med mer traditionella branscher.

Organisation A grundades 1978 och arbetar med att utveckla system för MPS (Material- och produktionsstyrning) och ERP (Enterprise resourse planning) system.

Organisationen har runt 600 anställda i 20 länder. Organisation A kommer i arbetet att

betraktas som en gammal organisation utifrån den definition av unga och gamla

organisationer som presenterats i kapitel 4.1, då den har funnits i 23 år och inte har

genomgått någon större förändring de senaste åren.

Resultat och analys

Organisation B grundades 1995 och arbetar främst med att utveckla lösningar för elektronisk handel. De flesta kunder finns inom bank- och finanssektorn och organisationen strävar efter att vara en betydande aktör inom sitt område, inom några år. Organisationen har för närvarande 30 anställda. Organisation B kommer att betraktas som en ung organisation i arbetet då organisationen endast funnits i 6 år och därför enligt definitionen av unga och gamla organisationer anses vara en ung organisation.

Organisation C grundades 1997 och arbetar med att utveckla affärslösningar för elektronisk handel. Organisationen är ett konsultbolag som jobbar med alla delar av utvecklingen av affärslösningarna. Organisationen har ett åttiotal medarbetare. Även denna organisationen kommer att betraktas som en ung organisation då organisationen endast funnits i 4 år.

Organisation D etablerades i Sverige 1989. De arbetar med verksamhetsutveckling, projektledning, arkitektur och systemutveckling. Organisationen har i Sverige ca 65, i Norden 250, i världen 1200 anställda. Organisation D har funnits i 12 år och är därför enligt definitionen en gammal organisation.

6.3 Intervjuer

Intervjufrågorna utarbetades utifrån de kritiska framgångsfaktorer som Kunda och Brooks (2000) specificerat. Dessa frågor kompletterades sedan med frågor som utarbetats med utgångspunkt i avsnitten 2 och 3. De svarande arbetar som utvecklare på respektive organisation, så undersökningen blir utifrån utvecklarens perspektiv.

Frågornas utformning är sådan att en del av frågorna har utvecklarna mer kunskap om, medan andra frågor vänder sig mer till ledningen. En lösning hade varit att intervjuat både utvecklare och ledning hos varje organisation. Anledningen till valet att endast utvecklare skulle svara på frågorna och inte ledning är flera. Det fanns ett par praktiska problem med att intervjua ledningen för en av organisationerna då det är en internationell organisation, där ledningen inte finns i Sverige. Vidare så har personer i organisationer som kontaktats med ledningsfunktioner, ofta hänvisat vidare till personer som är mer insatta i komponentbaserad informationssystemsutveckling.

Fyra intervjuer med två unga och två gamla organisationer har genomförts. Den ena intervjun genomfördes på plats hos organisationen, då organisationen fanns inom rimligt avstånd. Vid intervjun intervjuades två utvecklare inom organisationen och intervjun tog ungefär en och en halv timme. Intervjun inleddes med generella frågor om organisationen, för att sedan övergå till mer specifika frågor som berörde problempreciseringen. Den avslutades sedan med att de intervjuade fick komma med tillägg om hinder som de tyckte funnits inom organisationen vid införandet av komponentbaserad informationssystemsutveckling, samt kommentera frågornas relevans.

Den andra intervjun genomfördes genom att intervjufrågorna skickades via e-post till organisationen, som sedan besvarade frågorna och skickade tillbaka svaren via e-post.

Detta skedde på förfrågan från organisationen i stället för en telefonintervju, då

organisationen inte kunde besökas på plats på grund av stort avstånd. Kompletterande

frågor skickades sedan även de via e-post till organisationen.

Resultat och analys

6.4 Intervjufrågor

I det här kapitlet så presenteras frågorna som organisationerna fått besvara i intervjuerna. Vidare så följer en kort motivering till varje fråga där det framgår varför frågan är viktig för undersökningen. De inledande frågorna är generella frågor som är tänkta att ge en bra bild av organisationerna och deras arbetssätt. Det är viktigt att försöka hitta eventuella bakomliggande orsaker till hinder som organisationer har stött på för att kunna dra korrekta slutsatser utifrån intervjusvaren.

Vad jobbar ni med?

Besvarar om organisationen passar in i problemavgränsningen för undersökningen.

Hur länge har organisationen funnits?

Nödvändig för att kunna kategorisera organisationerna i unga och gamla organisationer.

Hur ser organisationens struktur ut?

Kunda och Brooks (2000) skriver att olika strategier för införandet av komponentbaserad informationssystemutveckling är nödvändiga beroende på organisationens struktur och omgivning.

Använder ni någon systemutvecklingsmetod?

Om en organisation använder en metod eller inte kan kanske påverka införandet av komponentbaserad informationssystemutveckling. Därför kan det vara bra att veta om organisationen använder sig av någon metod under analysen av intervjusvaren.

Använder ni er av komponentbaserad informationssystemutveckling i någon del av utvecklingsarbetet?

Herzum och Sims (2000) skriver att komponentbaserad informationssystemutveckling betyder att komponenttänkandet genomsyrar hela utvecklingsprocessen och inte bara delar av den. Det är därför viktigt att organisationerna använder komponentbaserad informationssystemutveckling på liknande sätt och under hela utvecklingsarbetet.

Har organisationen genomgått några stora förändringar innan komponentbaserad informationssystemutveckling infördes?

Om organisationen har genomgått stora förändringar så kan den kanske ha lättare att införa ett nytt arbetssätt. Om organisationen har genomgått stora förändringar kanske den ska klassas som en ung organisation i arbetet.

Vad använde ni för programmeringsspråk innan och efter att ni införde komponentbaserad informationssystemutveckling?

Då komponentbaserad informationssystemutveckling till viss del bygger på objekttänkandet så kan det vara enklare för organisationer som använt objektorienterade programmeringsspråk som Java eller C++, att införa komponentbaserad informationssystemsutveckling.

Hade ni en plan för införandet?

Herzum och Sims (2000) skriver att det är viktigt att ha en plan för införandet av

komponentbaserad informationssystemutveckling, för att ha kontroll över samt

minska kostnaderna och tiden för övergångsperioden.

Resultat och analys

Har komponentbaserad informationssystemutveckling reducerat

utvecklingskostnaderna? Samt har komponentbaserad

informationssystemutveckling reducerat utvecklingstiden?

En av grundidéerna med komponentbaserad informationssystemutveckling är att genom att använda komponenter och återanvända komponenterna, så ska utvecklingstiden och utvecklingskostnaderna reduceras i jämförelse med annan systemutveckling.

Har ni kontroll över utvecklingskostnaderna?

Enligt Herzum och Sims (2000) är det viktigt att organisationerna har kontroll över utvecklingskostnaderna.

Har ni haft stöd från intressenter och sponsorer i förändringsarbetet?

Kunda och Brooks (2000) skriver att det i systemutvecklingsprojekt är viktigt att organisationerna har sponsorers och intressenters stöd. Det är därför viktigt att organisationerna har stöd bland intressenter och sponsorer för införandet av komponentbaserad informationssystemutveckling.

Har ni sett någon skillnad i acceptansen av system före och efter införandet av komponentbaserad informationssystemutveckling?

Kan ge en indikation på om organisationen har lyckats att på ett bra sätt införa komponentbaserad informationssystemutveckling i arbetet och om detta har lett till en bättre slutprodukt.

Ge exempel på en typisk komponent.

Vad som någon anser är en komponent kan variera stort ifrån person till person. Det kan vara allt ifrån en knapp i en meny rad, ett ordbehandlingsprogram och allt däremellan. Det är därför av intresse att ta reda på vad varje organisation som ingår i undersökningen anser är en komponent.

Vilka hinder mot införandet av komponentbaserad informations- systemsutveckling tycker ni har funnits inom organisationen?

Här får den intervjuade en chans att berätta vilka hinder han tycker att organisationen har stött på vid införandet av komponentbaserad informationssystemutveckling. Här kan hinder som inte tas upp i de övriga frågorna komma fram

Frågorna som följer är frågor som besvarar problemställningen. Efter varje fråga presenteras den kritiska faktor som Kunda och Brooks (2000) tagit fram och som frågan är tänkt att besvara.

Hur är användarna involverade i utvecklingsarbete?

Om användarna involveras i utvecklingsarbetet så kan detta leda till en ökad

motivation och en känsla av ägandeskap över systemet vilket enligt Kunda och

Brooks (2000) kan öka användarnas stöd för komponentbaserad

informationssystemutveckling. Då användarna av informationssystemen ofta även är

kunderna och kunderna är intressenter, så är det enligt Kunda och Brooks (2000)

viktigt att ha deras stöd. Kritisk faktor: Användarnas känsla av ägandeskap.

Resultat och analys

Hur har utvecklarna ställt sig till införandet av komponentbaserad informationssystemutveckling?

För att lyckas med att införa komponentbaserad informationssystemutveckling i en organisation så är det enligt Kunda och Brooks (2000) viktigt att ha utvecklarnas stöd för förändringen. Kritisk faktor: Motivation och grad av entusiasm.

Har ledningen formulerat en vision för hur den nya organisationen ska se ut och fungera, samt presenterat den för utvecklarna?

Sarker och Lee (1999) skriver att det är viktigt att ledningen skapar en vision för hur den nya organisationen ska se ut och fungera, för att skapa en förändringsvilja inom organisationen. Kritisk faktor: Organisationens resurser och stöd.

Har det funnits motstånd eller bristande engagemang på grund av försenade positiva effekter av komponentbaserad informationssystemutveckling?

Det kan enligt Kunda och Brooks (2000) ta ett tag innan de positiva effekterna av komponentbaserad informationssystemutveckling framträder. Kritiska faktorer:

Organisations- och affärsstrategi och politiska frågor.

Har ledningens stöd vid införandet varit bristfällig?

Enligt Kunda och Brooks (2000) så är ledningens stöd viktigt för att en organisation ska lyckas med införandet av komponentbaserad informationssystemutveckling.

Kritisk faktor: Organisationens resurser och stöd.

Har ledningen utbildats på komponentbaserad informationssystemutveckling?

Genom att ledningen utbildas i komponentbaserad informationssystemutveckling så kan ledningens stöd för införandet enligt Kunda och Brooks (2000) öka. Kritisk faktor: Organisationens resurser och stöd.

Har ledningen informerats om fallstudier där komponentbaserad informationssystemutveckling införts?

Kunda och Brooks (2000) skriver att ledningens stöd för införandet av komponentbaserad informationssystemutveckling kan öka, genom att ledningen får ta del av fallstudier som presenterar lyckade projekt. Kritisk faktor: Organisationens resurser och stöd.

Finns det flera avdelningar med utvecklare?

Om ja, utvecklar de gemensamma komponenter?

Om ja, hur bra fungerar samarbetet mellan avdelningarna?

Finns det en konkurrens mellan avdelningarna på något sätt?

Om olika avdelningar inom en organisation konkurrerar med varandra så kan detta enligt Kunda och Brooks (2000) påverka införandet av komponentbaserad informationssystemutveckling negativt. Kritisk faktor: Organisationens upplägg och ledningens stil.

Har det funnits en allmän åsikt inom organisationen att det gamla arbetssättet varit det bästa?

Kunda och Brooks (2000) skriver att användares, utvecklares och lednings motvilja

till förändring ofta bottnar i organisationens kultur. Kritisk faktor: Organisationens

kultur.

Resultat och analys

Hur belönas utvecklare och chefer inom organisationen?

Enligt Kunda och Brooks (2000) så kan sättet på vilka utvecklare och chefer belönas på, leda till motstånd till återanvändning av komponenter. Kritisk faktor:

Uppmuntran.

Hur långt in i framtiden sträcker sig er organisations affärsstrategi?

Då de positiva effekterna av komponentbaserad informationssystemutveckling kan dröja, så kan en kortsiktig affärsstrategi enligt Kunda och Brooks (2000) påverka ledningens inställning till förändringsarbetet negativt. Kritisk faktor: Organisations- och affärsstrategi.

Har företagsledningen stöttat införandet av komponentbaserad informations- systemutveckling och har de tillfört de resurser som krävs?

Enligt Kunda och Brooks (2000) så är ledningens stöd för införandet av komponentbaserad informationssystemutveckling viktigt för att förändringsarbetet ska lyckas. Kritisk faktor: Organisationens resurser och stöd.

Har anställda och chefer fått någon undervisning i modeller, tekniker och metoder för komponentbaserad informationssystemsutveckling?

Kunda och Brooks (2000) skriver att undervisning i modeller, tekniker och metoder kan vara ett sätt att ändra en organisationskultur, vilket kan vara nödvändigt om det

finns ett motstånd mot införandet av komponentbaserad

informationssystemutveckling inom organisationen. Kritiska faktorer: Kognitiva

förmågor, organisationens kultur och organisationens resurser och stöd.

Resultat och analys

7 Resultat och analys

I det här kapitlet kommer resultatet av undersökningen att presenteras. Kapitlet inleds med en presentation av organisationerna som deltagit i undersökningen. Efter det så redovisas organisationernas svar på intervjuerna. Kapitlet avslutas sedan med en analys av organisationernas svar.

7.1 Presentation av resultat ifrån intervjuerna

Intervjuerna kommer att presenteras på så sätt att först presenteras frågan och sedan kommer organisationernas svar på den frågan. Svaren har i viss mån bearbetats. Alla organisationer har inte svarat på alla frågor. En del frågor har lagts till efter intervjun för att kompletera de tidigare frågorna och alla organisatioerna har inte varat på dem.

Vidare så ställdes inte alla frågor till alla organisationerna.

Vad jobbar ni med?

Organisation A: ”Vi utvecklar MPS (Material och Produktions Styrning) och ERP (Enterprise Resourse Planning) system.”

Organisation B: ”Vi är ett konsultföretag som utvecklar softwarelösningar främst inom värdepappershanteringen.”

Organisation C: ”Konsulter inom bank o finanssektorn.”

Organisation D: ”IT-konsulter som hjälper kunder med verksamhetsutveckling, projektledning, arkitektur och systemutveckling.”

Hur länge har organisationen funnits?

Organisation A: ”1978.”

Organisation B: ”Sedan 1995.”

Organisation C: ”1997.”

Organisation D: ”Drygt tio år.”

Hur ser organisationens struktur ut?

Organisation A: ”Utvecklingscentrum i Nacka, Skövde, Moskva & Rotkreuz.”

Organisation B: ”Platt.”

Organisation C: ”Konsultgrupp indelad i affärsområden, några personer jobbar på kontoret.”

Organisation D: ”Organisationen är en nordisk verksamhetsgren av en världsomspännande organisation. I den nordiska grenen finns svenska, danska, finska och norska grenar. Sverige är geografiskt uppdelat på Stockholm, Göteborg, Sundsvall.”

Använder ni någon systemutvecklingsmetod?

Resultat och analys

Organisation A: ”Nej, ingen som följs i Skövde. Dock finns det en metod som heter QMS men som inte används i Skövde i någon större utsträckning.”

Organisation B: ”Ramverk baserat på egna erfarenheter.”

Organisation C: ” Ja, RUP.”

Organisation D: ”Flera olika beroende på kundens behov, bland annat Reflex, Logic, Information Engineering, RAD, RUP m.fl.”

Använder ni er av komponentbaserad informationssystemutveckling i någon del av utvecklingsarbetet?

Organisation A: ”Komponentbaserad informationssystemsutveckling används under hela utvecklingsarbetet.”

Organisation B: ”Både i design- och utvecklingsfasen.”

Organisation C: ”Komponentbaserad informationssystemutveckling används inom hela utvecklingsprocessen.”

Organisation D: ”Från verksamhetsanalys hela vägen till leverans av system.”

Har organisationen genomgått några stora förändringar innan komponentbaserad informationssystemutveckling infördes?

Organisation A: ”Gjorde koden windows-baserad. Gick från DOS till windows.”

Organisation B: ”Nej.”

Organisation C: ”Nej, men organisationen har växt kraftigt.”

Organisation D: ”Inte vi själva, dock har de kunder som jobbar komponentbaserat gjort det i olika grad. Man bör t.ex. ha komponentägare i organisationen, förutom den stora mentala omställning det innebär för framförallt IT-sidan.”

Vad använde ni för programmeringsspråk innan och efter att ni införde komponentbaserad informationssystemutveckling?

Organisation A: ”Innan användes C Basic men nu går vi över till Visual Basic, som är objektorienterat.”

Organisation B: ”Java, Visual Basic.”

Organisation C: ”Java användes innan införandet av komponentbaserad informationssystemutveckling och används även med komponentbaserad informationssystemutveckling.”

Organisation D: ”Vårt komponentbegrepp är språkoberoende eftersom

begreppet inkluderar allt från specifikation t.o.m. valfri

implementation. Vanligast är COBOL och Java.”

Resultat och analys

Hade ni en plan för införandet?

Organisation A: ”Vi började med att införa komponentbaserad informationssystemutveckling i objekt till kundspecifika applikationer. Nästa steg är att använda komponentbaserad informationssystemutveckling även till större kunder och till standardkomponenter. Komponenter testas på betakunder som är medvetna om att de är ”försökskaniner”, sedan görs komponenterna till standardkomponenter. Detta görs genom att man tillför gamla funktioner. Det ska i framtiden även kunna gå från andra hållet. Det vill säga man tar standardkomponenter och kundanpassar, men det sker inte i dagsläget. Målet är att alla komponenter ska bli standardkomponenter som sedan kan kundanpassas.”

Organisation B: ”Vi prövade oss fram – först i internprojekt och sedan i kundprojekt.”

Organisation C: ”Internprojekt.”

Organisation D: ”Varierar beroende på vilken kund man pratar om.”

Har komponentbaserad informationssystemutveckling reducerat utvecklingskostnaderna?

Organisation A: ”Nej, då man bara har hållit på i några månader. Räknar med att det ska ge avkastning nästa år.”

Organisation B: ”Inte än – men vi räknar med det när vi kan öka återbruket.”

Organisation C: ”Svårt att säga i dagsläget. Man ser dock klart och tydligt att det borde förbättra utvecklingstiden och därmed kostnaderna rent teoretiskt.”

Organisation D: ”Vi har tyvärr inte tagit del av kundernas uppmätta resultat.

Det är dessutom i många fall för tidigt att avgöra, payback får man kanske 2-10 år efter att ha bytt till komponentbaserad utveckling, och där befinner sig ingen ännu.”

Har komponentbaserad informationssystemutveckling reducerat utvecklingstiden?

Organisation A: ”Vi använde oss förut av includefiler som kopierades in i den nya koden. Nu ersätts dessa med komponenter. Nackdelen med includefilerna är/var att vi måste kompilera om alla program som använder includefilen om denna ändras. Man måste då leverera ”hela systemet” varje gång man gjort ändringar. Med det nya systemet ska det bli lättare att leverera bara vissa komponenter separat när dessa ändrats.”

Organisation B: ”Inte än – men vi räknar med det när vi kan öka återbruket.”