Affärsutvecklarens verktygslåda – - Högskolan i Skövde

Affärsutvecklarens verktygslåda – 

utvecklingsarbete med metoder i samspel 

Informatik 

Institutionen för Informationsteknologi 

Karlstads universitet 

SE-651 88 Karlstad 

Sverige 

Tel: +46 (0)54 7002107 

Fax: +46 (0)54 7001446 

E-mail: Anders.Nilsson@kau.se 

Anders G. Nilsson 

1 

Institutet för Verksamhetsutveckling 

Institut V 

Handelshögskolan i Stockholm 

Box 6501 

SE-113 83 Stockholm 

Sverige 

Tel: +46 (0)8 4414884 

Fax: +46 (0)8 322620 

E-mail: Anders.Nilsson@hhs.se




Anders är professor och ämnesföreträdare i informatik vid Karlstads universitet. 

Ekonomie doktor i Information Management vid Handelshögskolan i Stockholm. 

Docent i Informationssystemutveckling vid Linköpings universitet. Forskar kring 

modeller och metoder för utvecklingsarbete med affärsstrategier, verksamhetsprocesser 

och informationssystem. Speciellt intresserad av standardsystem och affärssystem 

inom organisationer. Arbetat inom EU-projektet ”Compete” kring professionell 

användning av moderna IT-verktyg inom små och medelstora företag. 

Forskningsledare för konsortiet Business Modelling som undersöker svenska företags 

satsningar på processorienterat utvecklingsarbete. Rådgivare till förändringsprojekt 

inom näringsliv och offentlig verksamhet via Institut V. Författare till 12 böcker kring 

teman om systemutveckling (ISAC-metoden), standardsystem (SIV-metoden, VFSmetoden) 

och verksamhetsmodellering (Business Modelling). 

2




Abstrakt: I början av 90-talet fick jag ett uppdrag av några svenska företag att skapa 

konturerna för ett koncept som kallades för ”Affärsutvecklarens Verktygslåda”. 

Företagens problem visade sig inte ligga i hur själva urvalet av metoder går till inom 

organisationen utan snarare hur man kan skapa fruktbara kombinationer mellan de 

olika metoder som används vid utvecklingsarbete. Fokus blev således hur man kan få 

ett väl fungerande samspel mellan valda metoder i en verktygslåda. Ett konkret 

förslag på angreppssätt att kreera en Affärsutvecklares Verktygslåda har presenterats 

tidigare i Nilsson (1999). Detta bidrag är ett försök att gå ett steg vidare och reflektera 

över viktiga dimensioner att beakta vid konstruktion av en Affärsutvecklares 

Verktygslåda. En checklista med 10 olika dimensioner presenteras vilka bygger på 

tidigare kunskaper från egen forskning kring metodutveckling samt kartläggningar av 

olika etablerade metoder som idag används på marknaden. 

Nyckelord: Affärsutveckling, Förändringsarbete, Meta-modellering, Metod, Metodkombination, 

Modelleringsaspekt, Systemutveckling, Utvecklingsarbete, Verksamhetsutveckling, 

Verktygslåda 

3




FOKUS PÅ METODER I SAMSPEL 

Varför behöver metoder användas när vi bedriver utvecklingsarbete inom företag och 

organisationer? Detta är en fråga som diskuterats och ventilerats under fyra decennier 

inom området systemutveckling. En hel del svar för att motivera användning av 

systematisk metodik vid utvecklingsarbete eller förändringsarbete har presenterats 

under årens lopp. Jag vill här omnämna tre ofta citerade behov av metodanvändning 

(Nilsson 1999, s. 218): 

• Kravspecifikationer; behov av att framställa exakta, konsistenta och fullständiga 

kravspecifikationer för att utforma framtida verksamhetsprocesser med olika 

systemlösningar (Bubenko jr. och Kirikova 1999). 

• IT som möjliggörare; behov av att kunna förklara hur nya IT möjligheter kan 

förbättra verksamhetsprocesser och affärsstrategier inom våra organisationer 

(Steneskog 1999, Tolis och Nilsson 1998; Venkatraman 1994; Österlee 1995). 

• Verksamhetsbeskrivning; behov av att beskriva och koordinera det komplexa 

sambandet mellan materialflöden, informationsflöden och monetära flöden inom 

ett företag (Nissen och Andersen 1977). 

Det finns idag många olika typer av metoder som lärs ut vid universitet/högskolor och 

som används vid praktiskt utvecklingsarbete inom organisationer (Andersen 1994; 

Avison och Fitzgerald 1995, Iivari och Lyytinen 1999; Werr et al. 1995). Ett 

intressant mönster som jag funnit är att vi verkar leta efter den kompletta metoden 

som täcker in alla situationer som kan tänkas uppstå vid utvecklingsarbete (Nilsson 

1995). Eller annorlunda utryckt att vi skulle vara på jakt efter ”super-metoden”! 

Historiskt sett har det genomförts en hel del experiment för att finna den maximala 

metoden för systemutveckling. Det är dock en illusion att tro att vi ska nå ett sådant 

tillstånd! Hur vi än försöker så är vi alltid begränsade vid en metodkonstruktion. Om 

det gick att konstruera en super-metod så skulle det bli en väldigt komplex metod. 

Och denna super-metod skulle säkerligen inte vara stark på alla delar utan högst 

märkbart variera i kvalitet. Kan vi då finna lösningar på företagens behov av 

heltäckande metoder för det vida spektrum av situationer som kan uppstå vid 

utvecklingsarbete i praktiken? 

En intressant möjlighet är att skapa en verktygslåda för utvecklingsarbete (Bergman 

1981; Benthede 1995; Björk 1992). Den bärande idén med en verktygslåda är att ha 

ett samspel mellan olika metoder som behövs för att klara av skilda situationer som 

kan uppstå vid utvecklingsarbete inom en organisation. Urvalet av metoder i 

verktygslådan ska stämma överens med företagets sätt att bedriva utveckling av 

verksamheter och informationssystem. Man behöver vidare situationsanpassa aktuella 

4

metoder till företagets behov och syfte med sitt utvecklingsarbete – valda metoder kan 

inte användas ”rakt av” enligt skolboken eller handboken! 

I början av 90-talet fick jag ett uppdrag av några svenska företag att skapa konturerna 

för ett koncept som kallades för ”Affärsutvecklarens Verktygslåda”. Detta forskningsarbete 

har skett inom ramen för konsortiet Business Modelling som är ett samarbete 

mellan Handelshögskolan i Stockholm (HHS), Kungliga Tekniska Högskolan (KTH) 

och Linköpings universitet (LiU) tillsammans med företagen ABB, Ericsson, Scania, 

Posten och Försäkringskassan (Nilsson et al. 1999). Företagens problem visade sig 

inte ligga i hur själva urvalet av metoder går till inom organisationen utan snarare hur 

man kan skapa fruktbara kombinationer mellan de olika metoder som används vid 

utvecklingsarbete. Fokus blev således hur man kan få ett väl fungerande samspel 

mellan valda metoder i en verktygslåda. Ett konkret förslag på angreppssätt att kreera 

en Affärsutvecklares Verktygslåda har presenterats tidigare i Nilsson (1999). Detta 

bidrag är ett försök att gå ett steg vidare och reflektera över viktiga dimensioner att 

beakta vid konstruktion av en Affärsutvecklares Verktygslåda. Mitt bidrag är framtaget 

inom de två forskningsmiljöer som jag är verksam inom idag: Karlstadskolan 

inom informatik (Nilsson och Pettersson 2000) och Institut V i Stockholm. 

VIKTIGA DIMENSIONER – EN CHECKLISTA 

Jag väljer att presentera mina erfarenheter kring att skapa verktygslådor med metoder 

för utvecklingsarbete i form av en checklista över viktiga dimensioner att tänka på i 

ett sådant sammanhang. Denna checklista bygger på kunskaper från dels egen 

forskning med att konstruera metoder för olika typer av systemutveckling (ISACmetoden, 

SIV-metoden och VFS-metoden) dels olika kartläggningar inom Business 

Modelling konsortiet av etablerade metoder för utvecklingsarbete som i dagsläget 

används på marknaden. 

Mitt förslag till checklista innehåller 10 viktiga dimensioner att kunna beakta vid 

konstruktion av en Affärsutvecklares Verktygslåda. Med nödvändighet blir checklistan 

ett subjektivt urval av vad jag vill lyfta fram som speciellt viktiga lärdomar. Det 

finns ingen logisk rangordning av dimensionerna utan de presenteras i en möjlig 

tidsordning som de kan aktualiseras vid arbete med metodutveckling. 

1 Metod 

Begreppet metod för utvecklingsarbete har debatterats under flera decennier inom 

ämnet Informationsbehandling (under olika benämningar som ADB, informatik, 

informationssystem, informationsvetenskap, informationsledning eller Information 

Management). I detta sammanhang vill jag hänvisa till t.ex. Andersen (1994), 

Jayaratna (1994) och Langefors (1995). I dagens läge verkar många forskare överens 

om att en metod ger riktlinjer, anvisningar och föreskrifter om ett systematiskt arbetssätt 

för utvecklingsverksamhet inom företag. Med andra ord en praktisk vägledning 

och handfasta råd för hur utvecklingsarbete bör bedrivas. Metod ger på detta sätt en 

norm för önskvärt beteende hos olika aktörer under ett förändringsarbete. För det 

mesta manifesteras en metod i form av en ”idealmodell” för arbete med utvecklings- 

5

frågor, men det finns alltid möjligheter till avvikelser när så är lämpligt i en konkret 

tillämpning. 

Normalt kan man tänka i olika abstraktionsnivåer när man i det svenska språket hör 

ordet ’metod’. I detta sammanhang ska en viktig åtskillnad göras. Jag föreslår att 

’metodik’ används som ett generellt begrepp för en ’metod på typ-nivå’ medan 

’metodansats’ nyttjas som ett specifikt begrepp för en ’metod på instans-nivå’. En viss 

metodansats är en konkretisering av någon metodik. ISAC som metodansats är en 

konkretisering av metodik för egenutveckling av informationssystem (Lundeberg et 

al. 1978), SIV som metodansats är en konkretisering av metodik för anskaffning eller 

upphandling av standardsystem (Nilsson, 1991), och så vidare. En generell eller 

generisk metod på typ-nivå omfattar domänkunskaper för det problemområde som 

avses stödjas med handlingsregler. En konkret metod på instans-nivå kan inte vara 

heltäckande för alla situationer som kan uppstå i ett utvecklingsarbete – jämför 

diskussionen om ”super-metod” ovan! 

Ibland används begreppet ’ansats’ eller på engelska ’approach’ i en något annorlunda 

bemärkelse. Med ansats menas då en ofullständig metod t.ex. att den ej är tillräckligt 

genomarbetad eller att vissa delar saknas. Vidare är då en ansats vanligtvis mindre 

normativ eller preskriptiv till sin karaktär än en metod. Det finns även möjligheter att 

kombinera flera fristående metoder t.ex. till en s.k. ’metodkedja’ för att nå en mer 

komplett metodik (se Fåhraeus 1986). Mer om detta kommer jag att behandla under 

dimensionen Metodkombination nedan. 

Ett möjligt sätt att precisera begreppet metod ytterligare är att försöka ange ett antal 

beståndsdelar. Detta ger svar på frågan vad en metod kan tänkas bestå av. Jag urskiljer 

tre huvuddelar i en ’metod’ med ett antal underdelar enligt följande (Nilsson 1991, s. 

80; Nilsson 1995): 

1. Perspektiv 

Synsätt, Vägval, Begrepp. 

2. Arbetsmodell 

Utvecklingsområden, Arbetssteg, Bedömningsfaktorer, Dokumentation, Verktyg. 

3. Intressentmodell 

Aktörer, Samarbetsformer, Ansvarsmodeller. 

Det är viktigt att inse att varje metod bygger på ett visst perspektiv med ett antal 

bakomliggande antaganden om hur utvecklingsarbete bör bedrivas på företag (jfr 

Nurminen 1988). Med perspektiv menar jag här alla de synsätt, vägval och begrepp 

som påverkar uppbyggnaden av den föreslagna arbets- och intressentmodellen. 

Synsätt anger olika principer och värderingar om vad som anses vara ”bra” affärer, 

verksamheter och informationssystem samt effektiv utveckling av dessa. Vid 

konstruktion av en metod har ursprungligen ett antal vägval gjorts. För att kunna 

förstå metodens uppbyggnad är det värdefullt om vägvalen beskrivs explicit (Nilsson 

1991, s. 102). Vidare behöver en metod bygga på en uppsättning fruktbara och väldefinierade 

begrepp. 

6

Ett utvecklingsarbete inom en organisation är vanligtvis en rätt omfattande och 

komplicerad uppgift. Man behöver ta ställning i ett stort antal frågor och fatta många 

olika beslut under en förändringsprocess. För att kunna angripa detta systematiskt 

behövs en arbetsmodell. Den kan sägas utgöra metodens ”kärna”. Modellen delar upp 

arbetet i ett antal överblickbara och avgränsade uppgifter. Arbetsmodellen består i sig 

av flera underdelar som utvecklingsområden med arbetssteg, lämpliga bedömningsfaktorer 

och utvärderingskriterier, förslag på dokumentationsformer eller beskrivningstekniker 

samt rekommenderade verktyg/hjälpmedel som stöd för arbetet. 

Arbetsmodellen behöver kompletteras med en intressentmodell för att bli en helhetsmetod. 

Intressentmodellen preciserar vem som ska göra vad under utvecklingsarbetet. 

Modellen visar härmed vilka aktörer som kan delta under arbetet och möjliga 

samarbetsformer mellan dessa intressenter. En viktig del av intressentmodellen är att 

beskriva själva ansvarsfördelningen d.v.s. vilka roller aktörerna ska spela under olika 

arbetssteg. På detta sätt får man ett samspel mellan arbetsmodell och intressentmodell. 

Det finns givetvis alternativa sätt att klassificera beståndsdelarna i en metod och hur 

man kan benämna dessa olika delar (jfr t.ex. Andersen 1994; Goldkuhl 1992). Mitt 

budskap är här inte hur man exakt klassificerar och namnger delar i en metod utan att 

det är av större betydelse att man preciserar sitt metodbegrepp när man önskar bygga 

upp en verktygslåda för utvecklingsarbete inom organisationer. Har vi inte en bra 

”koll” på vad som avses med en metod och dess delar ställs vi inför ett antal 

svårigheter att formulera innehållet i en Affärsutvecklares Verktygslåda. Vidare att få 

ett bra samspel mellan valda metoder i verktygslådan! 

2 Användningssituation 

Utvecklingsarbete hos företag och organisationer kan betraktas ur två synvinklar: 

leverantör eller kund. Leverantörer utvecklar och marknadsför olika erbjudanden till 

en kundkrets t.ex. IT-lösningar, verksamhetskunnande och affärsrådgivning. En kund 

anskaffar, upphandlar och använder de olika produkter och tjänster som erbjuds på 

leverantörsmarknaden. En metod för utvecklingsarbete kan ta utgångspunkt i något av 

följande två användningssituationer (Nilsson 1991, s. 103): 

• Kundsituation 

Småföretag, Storföretag, Inter-organisatorisk samverkan. 

• Leverantörssituation 

Plattformsmarknad, Programvarumarknad, Konsultmarknad. 

För en kundsituation innebär det att metoden främst hjälper kunden att utveckla en 

helhetslösning för att få företagets verksamhet att fungera så effektivt som möjligt i 

framtiden. En sådan helhetslösning kan omfatta en förnyad affärsstrategi, förbättrade 

verksamhetsprocesser och modernare former av IT-stöd. Metoden behöver även 

precisera när och hur en dialog med olika leverantörer kan eller bör äga rum. Det har 

visat sig genom tidigare forskning att metoder för utvecklingsarbete bör utformas 

något annorlunda för småföretag och storföretag (se t.ex. Nilsson 1991). Flertalet 

metoder på marknaden har ett fokus på utvecklingsprojekt inom större företag. Under 

90-talet har en del experiment kring metodutveckling för småföretag ägt rum t.ex. 

7

genom EU-projektet Compete (Fariselli 1998). Det har även visat sig att situationer 

med inter-organisatorisk samverkan mellan företag utgör en speciell problematik och 

till viss del kräver särskild metodik för utvecklingsarbete (se exempelvis M.-T. 

Christiansson, 2000). 

För en leverantörssituation innebär det att metoden främst hjälper leverantören att 

framhäva sina produkter och tjänster på marknaden samt att nå lyckade resultat hos 

sina kunder. Metoden bör även hjälpa leverantören att värdera kundens förutsättningar 

för att kunna dra nytta av potentiella lösningar i företagets verksamhet. En leverantör 

kan agera på olika marknader för plattformar, programvaror och konsulttjänster. Det 

kan också gälla kombinerade lösningar t.ex. när ett standardsystem (programvara) 

levereras med hårdvara (plattform) samt stöd för installation och utbildning (konsulttjänster). 

En metod för utvecklingsarbete ur ett leverantörsperspektiv bör hantera de 

förhållanden som kan uppstå i en affärstransaktion med en kund och hur önskade 

produkter och tjänster kan framställas. 

En verktygslåda behöver fokusera på vilken användningssituation som gäller för 

aktuell organisation som ska bedriva utvecklingsarbete. Det är ett viktigt vägval om 

metoderna i verktygslådan ska gälla för kunder eller leverantörer. Vidare blir fokus 

olika om en Affärsutvecklares Verktygslåda ska innehålla t.ex. konsultmetoder (Werr 

1999) eller förenklade metoder för småföretag (Andersson 1999; Stymne et al. 2000). 

3 Metodomfattning 

En metod kan byggas, konstrueras eller utformas med olika omfattning vad avser t.ex. 

antal rekommenderade arbetssteg och dokumenttyper (se Nilsson 1991, s. 105). En 

möjlig indelning av metodomfattning är efter en stigande skala av komplexitet: 

• Minimal metod (enkel problemstituation) 

• Normal metod (genomsnittlig problemsituation) 

• Maximal metod (svårare problemsituation) 

Som exempel på metodansats som utnyttjat ett sådant koncept är den senaste referensmodellen 

för systemutveckling från SIS (1989) som presenteras i tre metodversioner: 

Maxi, Midi och Mini. Jag vill i detta sammanhang laborera med en något annorlunda 

klassificering eller indelning av metodomfattning: 

• Basmetod (grundmetoden i originalutförande) 

• Förenklad metod (bantad snabbvariant) 

• Fördjupad metod (olika påbyggnader) 

Vanligtvis utformas en viss metod i ett originalutförande (basmetod) av en metodinnovatör 

som kan vara t.ex. en forskargrupp eller konsultorganisation. Efter en tid 

uppstår ofta behov av metodvarianter för dels kortare och snabbare utvecklingsarbete 

(förenklad metod) dels påbyggnadsmöjligheter för utvecklingsarbete med olika typer 

av specialfall (fördjupad metod). Som exempel på metodansatser som genomgått ett 

sådant utvecklingsförlopp kan nämnas SIV-metoden (Nilsson 1991, kap. 5) och OPRmetoden 

(Sundgren 1992; 1999). 

8

En vital fråga som man ställs inför vid design av en Affärsutvecklares Verktygslåda är 

vilken omfattning olika ingående metoder bör ha i startläget och sedan i kommande 

versioner. Räcker det med en uppsättning basmetoder eller bör vissa metoder även ha 

förenklade och/eller fördjupade varianter i verktygslådan? 

4 Applikationsbredd 

En metod för utvecklingsarbete kan vara uppbyggd på olika sätt när det gäller frågan 

om applikationsbredd. Här avses hur många applikationsområden som metoden kan 

tillämpas inom. Exempel på olika applikationsområden är marknadsföringssystem 

(Mattsson 1997), ekonomistyrsystem (L. Samuelson 1990), MPS eller material- och 

produktionsstyrningssystem (Olhager och Rapp 1985) samt kemiinformatiksystem (K. 

Samuelsson 2000). Grovt sett kan man urskilja följande vägval när det gäller 

applikationsbredd för en metod (Nilsson 1991, s. 104; Carlsson 2000, s. 121): 

• Specifik metod (för endast ett applikationsområde) 

• Generell metod (övergripande för alla applikationsområden) 

• Gemensam metod (inslag av både specifik och generell metodik) 

En specifik metod stödjer ett avgränsat applikationsområde vilket leder till artskilda 

metoder för olika områden, t.ex. RP-metoden för ekonomistyrsystem (Magnusson och 

Wahlgren 1995). En generell metod är övergripande till sin natur och kan användas 

inom alla tänkbara applikationsområden. Flertalet metoder för systemutveckling är 

traditionellt uppbyggda som generella metoder t.ex. ISAC-metoden (Lundeberg et al. 

1978) och VFS-metoden (Brandt et al. 1998). En gemensam metod innehåller både en 

övergripande del och möjligheter till fördjupningar för varje applikationsområde. En 

sådan metod kan vara en kombination av en generell metod och ett antal specifika 

metoder. Den s.k. MiniSIV-metoden är förutom att vara en förenklad metod för 

anskaffning av standardsystem även en gemensam metod eftersom MiniSIV innehåller 

specificerade kravlistor för ett stort antal applikationsområden (Moberg et al. 

1991). 

Metoder kan vara uppbyggda med olika applikationsbredd. I en Affärsutvecklares 

Verktygslåda är det viktigt att fundera över vilken mix av applikationsområden som 

behövs för att kunna klara av olika utvecklingsarbeten inom aktuell organisation. En 

attraktiv idé är att ha någon slags gemensam metod som plattform i verktygslådan 

vilken förenar en uppsättning metodansatser med olika applikationsinrikningar. 

5 Utvecklingsstrategi 

Man kan bedriva utvecklingsarbete inom företag och organisationer på olika sätt – 

med andra ord med olika utvecklingsstrategier. Nya moderna hjälpmedel för att 

effektivisera arbetet med att utveckla informationssystem, verksamheter och affärsstrategier 

dyker hela tiden upp på marknaden. Det är därför angeläget att försöka 

karakterisera utvecklingsarbete med olika strategier eller tillvägagångssätt i en 

lämplig form. Varje utvecklingsstrategi ställer krav på speciella metoder eller arbetssätt. 

Jag sammanställde i mitten av 80-talet en referensram som kan användas som 

underlag för olika vägval vid utvecklingsarbete inom organisationer (Nilsson 1987; 

9

1989). Detta synsätt har senare vidareutvecklats och expanderats av Andersen (1994, 

s. 343). Min referensram består i dess ursprungsform av en klassificering utefter tre 

olika indelningsgrunder (Nilsson 1991, s. 57): 

• Förspecificering 

Manuella system, Skräddarsydda system, Genererade system, Standardsystem. 

• Konkretisering 

Analytisk utveckling, Experimentell utveckling. 

• Användarmedverkan 

Expertbetjäning, Samverkan, Självbetjäning. 

Den första indelningsgrunden berör utveckling av informationssystem efter graden av 

förspecificering. Här avses hur mycket färdiga specifikationer som finns över ett 

informationssystem på förhand innan man påbörjar utvecklingsarbetet. Detta leder 

fram till olika systemtyper (Nilsson 1995). Först kan man särskilja manuella system 

och datorbaserade system. Datorbaserade system kan sedan delas in i skräddarsydda 

system, genererade system och standardsystem. Manuella system tillåter en hög grad 

av frihet vid systemdesign jämfört med datorbaserade system som kräver en högre 

grad av specificering och formalisering. 

Standardsystem är färdigutvecklade system och har en högre grad av förspecificering 

än skräddarsydda system som byggs upp från grunden (”scratch”). Standardsystem 

eller numera kallade för affärssystem eller ERP-system har under årens lopp fått en 

allt större betydelse för att effektivisera företags affärsverksamheter (Davenport 2000; 

Kalderén 1995; Nilsson 2000). Genererade system är ett samlingsnamn för olika 

systemlösningar uppbyggda med någon form av halvfabrikat. Tidigare var det vanligt 

att använda olika typer av informationshanteringsverktyg (IH-verktyg) för att 

generera önskade informationssystem i verksamheten (Lie-Nielsen och Colliander 

1983). Idag har detta successivt ersatts med ett koncept som kallas för komponentbaserade 

system som utnyttjar ”byggstenar” i miniatyrformat för att generera önskade 

informationssystem (Fagerström 1995; Asker et al. 1996; B. Christiansson 2000). 

Den andra indelningsgrunden berör graden av konkretisering vid olika former av 

utvecklingsarbeten inom organisationer. Ett förändringsarbete kan upplevas som en 

abstrakt eller konkret process av en användare. Vid analytisk utveckling konstruerar 

man abstrakta modeller av informationssystem och verksamheter. Kravspecifikationen 

måste här vara helt klar eller ”fryst” innan en implementering får äga rum. Vid 

experimentell utveckling skapar man en förenklad prototyp som snabbt införs i 

verksamheten. Användarna får en möjlighet att pröva och testa resultaten i olika 

omgångar i verklig miljö. Det sker i en växelverkan mellan kravspecificering och 

prototypimplementering. 

Den tredje indelningsgrunden berör graden av användarmedverkan vid utvecklingsarbete. 

Man kan ha olika samarbetsformer mellan användare (lekmän) i verksamheten 

och specialister (experter) på teknikfrågor under en förändringsprocess (Docherty et 

al. 1977; Targama 1978). Vid expertbetjäning är det specialisterna som rätt och sätt 

utarbetar en lösning åt användarna. Vid självbetjäning är det användarna själva som 

driver på utvecklingsarbetet och tar fram lösningar med råd och stöd av specialisterna. 

10

En mellanform är en samverkan på lika villkor mellan användare och specialister att 

gemensamt kunna komma fram till en acceptabel lösning för verksamheten. 

Val av utvecklingsstrategi påverkar starkt vilken typ av metod som är lämplig att 

använda i ett visst förändringsarbete. I en Affärsutvecklares Verktygslåda behöver 

finnas olika typer av metoder för att på ett professionellt sätt kunna hantera situationer 

med bl.a. upphandling av standardsystem (Andersen et al. 1987), generering av 

komponentbaserade system (L. Axelsson 1998), arbete med prototyping (Rantzer 

1994) och principer för självbetjäning av användare (Bergner et al. 1982). 

6 Modelleringsaspekt 

Metoder för utvecklingsarbete kan betona olika modelleringsaspekter eller angreppssätt 

vid beskrivning av verksamheter och deras behov av olika informationssystem 

(Andersen 1994, s. 119; Lindström 1999; Sowa och Zachman 1992; Willars 1999). En 

vanligt förekommande klassificering av metoder har varit efter följande tre grundläggande 

aspekter (Hernbäck et al. 1990; Olle et al. 1991; Nilsson 1991) : 

• Funktioner 

organiserade aktiviteter och arbetsuppgifter, s.k. hierarkiskt synsätt. 

• Data 

användarnas begrepp och språkbruk, s.k. resurssynsätt. 

• Beteenden 

vilka sätter igång olika rutiner i verksamheten, s.k. händelsesynsätt. 

Till en början konkurrerade flera olika metodskolor, som var och en representerade 

någon av dessa modellingsaspekter, med varandra. Men alltmer började man fokusera 

på att söka lämpliga kombinationer av modelleringsaspekter vid praktiskt utvecklingsarbete. 

Det visade sig att vi behöver en lämplig mix av modelleringsaspekter vid 

verkliga tillämpningar. Under 90-talet har ett antal fruktbara kombinationer av 

modelleringsaspekter vuxit fram (Nilsson 1995): 

• Processer 

kombination av funktioner och händelser, d.v.s. efter tidsordning. 

• Objekt 

kombination av funktioner och data, s.k. inkapsling. 

• Transaktioner 

kombination av data och händelser, m.a.o. fokus på regler. 

• Influens 

som förändrar förutsättningarna för övriga modelleringsaspekter. 

Modelleringsaspekten ’influens’ är av lite speciell karaktär då den påverkar övriga 

aspekter med fokus på att förändra verksamheten från ett nuläge till ett önskat 

framtida läge (Tolis och Nilsson 1998). Med influens avses en samlande aspekt för 

olika förhållanden som mål/intentioner, aktörer/kraftfält, problem/styrkor/KFF och 

behov/åtgärder vilka behöver modelleras under ett utvecklingsarbete. Att arbeta med 

olika modelleringsaspekter är inte trivialt. Man kan lösa detta på olika sätt t.ex. genom 

att (i) ange regler för övergångar eller transformationer mellan aspekterna (jfr Nilsson 

1989; Söderlund och Persson 2000), (ii) skapa korsreferenser för att stämma av 

11

aspekterna mot varandra (jfr Olle et al. 1991; Gustas 2000) eller (iii) utgå från en 

grundaspekt och sedan bygga på och komplettera med en eller flera andra aspekter (jfr 

Sundgren 1992). 

Vid utveckling av organisationer behöver vi ”vrida och vända” på våra beskrivningar 

och modeller av verksamheten. Genom att växla perspektiv med hjälp av olika 

modelleringsaspekter får vi en fördjupad förståelse av bakomliggande mekanismer i 

organisationen och därmed ett underlag för att föreslå kraftfulla förändringar av 

verksamheten. Att hålla sig fast vid en isolerad modelleringsaspekt leder till ett 

”endimensionellt” tänkande vid utvecklingsarbete! Därför är det viktigt att en 

Affärsutvecklares Verktygslåda innehåller ett varierat utbud av metoder som tillsammans 

representerar en god mix av modelleringsaspekter. 

7 Utvecklingsnivå 

En allmän trend under de senaste decennierna är att försöka placera in arbete med 

systemutveckling i ett större sammanhang (Andersen 1981; Nilsson 1995). Det 

började med olika försök att betrakta systemutveckling som en del av en mer 

övergripande verksamhetsutveckling. Det har senare fortsatt med att vända fokus mot 

företagets mission eller uppdrag och affärsinrikta systemutvecklingen. Man bedriver 

affärsutveckling idag med mer eller mindre inslag av systemutveckling – härav 

uppstod konceptet ’Affärsutvecklarens Verktygslåda’. Detta leder fram till att vi 

numera har ett intimare samspel mellan tre mer eller mindre parallella förändringsprocesser 

eller utvecklingsnivåer inom företag: 

• Affärsutveckling 

Strategisk planering som leder fram till olika affärs- och verksamhetsplaner med 

kompletterande IT-policies. Affärsutveckling innebär arbete med att på olika sätt 

stärka företagets relationer till olika aktörer i omvärlden och på marknaden 

(Mintzberg och Quinn 1992; Alarik 1988; Fredriksson 2000). 

• Verksamhetsutveckling 

Intern utveckling av funktioner, processer och arbetsuppgifter i verksamheten med 

olika former av IT-stöd. Verksamhetsutveckling kan beröra en eller flera delar 

inom ett företag t.ex. produktion, logistik, marknadsföring, ärendehandläggning, 

personalorganisation och ekonomistyrning (Stymne et al. 2000). 

• Systemutveckling 

Framtagning och förvaltning av organisationens portfölj av informationssystem 

bestående av egna applikationer, komponentbaserade lösningar och standardpaket. 

Informationssystemen kan betraktas som verksamhetsstöd (resurser) eller som 

”triggers” för att bedriva helt nya affärer (möjliggörare) (Tolis och Nilsson 1998). 

Genom att koppla systemutveckling till affärs- och verksamhetsutveckling behöver vi 

använda kunskaper från både Informationsbehandling och Företagsekonomi. Det 

finns inom företagsekonomin en tradition att skapa metoder för affärs- och 

verksamhetsutveckling (jfr Bengtsson och Skärvad 1988). En intressant idé är då att 

importera vissa företagsekonomiska metoder för förändringsarbete som utgångspunkt 

för fortsatt eller samtidig systemutveckling (jfr Rapp 1999). Vissa förändringsarbeten 

12

inom företag och organisationer berör frågor på alla tre utvecklingsområdena ovan. 

Exempel på detta är tjänsteutveckling (jfr Edvardsson 1996), produktutveckling (jfr 

Norell 1992) och multimediautveckling (jfr L.E. Axelsson 2000; Molin 2000; Ulfhake 

2000). 

Utvecklingsområdena ovan berör tre centrala nivåer inom ett företag: affärer/uppdrag, 

verksamhet och informationssystem (Nilsson et al. 1999; Earl et al. 1996; Österlee 

1995). Ett nivåsynsätt börjar alltmer användas vid utvecklingsarbeten inom företag 

(Lundeberg 1996). En viktig observation är att den mellersta nivån bildar en 

förmedlande länk. Verksamhetsprocesser har beröring med både strategiska ledningsfrågor 

och användning av informationssystem på företag. Det är svårt om inte 

omöjligt att få ut strategiska effekter av IT-stöden utan hårt arbete med verksamhetsprocesserna 

inom organisationen! 

Ett allmänt problem hos företag idag är att sambanden eller kopplingarna mellan de 

tre utvecklingsnivåerna inte alltid fungerar på ett tillfredsställande sätt. Det är inte 

ovanligt att det uppstår olika kommunikationsgap mellan affärsledning, användare i 

verksamheten och systemspecialister. Vid praktiskt förändringsarbete kan man valfritt 

börja med affärs-, verksamhets- eller system-nivån. I vilken ända man än börjar får 

det konsekvenser för de övriga områdena. 

Olika typer av innovationer påverkar i mer eller mindre omfattning alla tre nivåerna 

för ett företag. Detta innebär att vi inte ensidigt kan fokusera på en utvecklingsnivå i 

taget vid förändringsarbete. De stora förtjänsterna ligger i att arbeta parallellt med 

utvecklingsfrågor kring affärer/uppdrag, verksamhetsprocesser och informationssystem. 

Allt detta ställer krav på att en Affärsutvecklares Verktygslåda innehåller 

metoder från alla tre utvecklingsnivåerna och att det finns välfungerande samspel 

mellan dessa olika typer av metoder. 

8 Metodkombination 

Som tidigare nämnts är det orimligt att tänka sig en ”super-metod” som kan hantera 

all den problematik och komplexitet som kan uppstå vid utvecklingsarbete inom 

företag och organisationer. Istället är det ett mer fruktbart angreppssätt att försöka 

kombinera flera metoder som passar den utvecklingssituation som man för tillfället 

befinner sig i. Det finns i princip två möjliga handlingsstrategier för att genomföra 

metodkombinationer enligt Nilsson (1992; 1999 s. 220): skapa en Metodkedja eller 

skapa en Metodallians. 

• Metodkedja 

Här avses en kombination av metoder mellan olika utvecklingsnivåer. Vi skapar ett 

samspel i form av en kedja mellan metoder för affärsutveckling, verksamhetsutveckling 

och systemutveckling. Denna handlingsstrategi är en form av vertikal 

samordning av metoder längs en tänkt livscykel för en utvecklingsprodukt. Man 

skapar övergångar eller ”vägar” mellan metoder genom livscykeln. När det gäller ett 

systems livscykel skapas en metodkedja mellan två eller flera faser i livscykeln. Ryan 

et al. (1996) kallar detta för en ”inter-process” strategi. 

13

• Metodallians 

Här avses en kombination av metoder inom en och samma utvecklingsnivå. Vi skapar 

ett samspel i form av en allians mellan metoder inom respektive område för affärsutveckling, 

verksamhetsutveckling och systemutveckling. Metoder brukar fokusera på 

vissa problem eller frågor inom ett utvecklingsområde. Genom en metodallians har vi 

möjlighet att hantera flera aspekter och perspektiv vid utvecklingsarbete, d.v.s. att 

vara ”multi-problem-orienterade”. Denna handlingsstrategi är en form av horisontell 

samordning av metoder inom samma del eller fas av en tänkt livscykel för en 

utvecklingsprodukt. När det gäller ett systems livscykel kallar Ryan et al. (1996) detta 

för en ”intra-process” strategi. 

Som underlag för att genomföra metodkombinationer kan man utgå från hela eller 

delar av metoder. Det bedrivs viss forskning kring detta tema inom såväl Sverige som 

internationellt. Grovt sett kan man urskilja tre olika förhållningssätt: 

• Metodkomponent 

Den bärande idén är här att strukturera en viss metod utifrån ett antal avgränsbara 

komponenter. Det påminner om ett objekt-orienterat tänkande fast applicerat i ett 

metodsammanhang. Man använder så många komponenter som behövs för att klara 

av en given utvecklingssituation. En viktig egenskap är att metodkomponenterna är 

generiska och flexibla till sin uppbyggnad. Detta garanterar att komponenterna blir 

utbytbara och anpassbara så att de kan ingå i olika metodsammanhang. En intressant 

idé blir då att återanvända komponenter mellan olika konkreta metoder (se vidare 

Röstlinger och Goldkuhl 1996). 

• Metodfragment 

Den bärande idén är här att identifiera olika fragment eller ”byggstenar” för 

utvecklingsarbete genom att gå igenom olika sammanhängande delar av existerande 

metoder. För en viss metod är det möjligt att särskilja dels produktfragment 

(leverabler och resultat) dels processfragment (riktlinjer och arbetsgång). Metodfragment 

kan ha varierande granularitet och räckvidd för ett utvecklingsarbete. På så 

sätt är ett metodfragment ett relativt koncept som kan sträcka sig från en avgränsad 

metodkomponent till ett helt metodkomplex (se vidare Brinkkemper 1996; 2000). 

• Metodkomplex 

Den bärande idén är här att utgå från existerande metoder som de är uppbyggda utan 

att försöka bryta ned dessa i avgränsbara metodkomponenter eller urskiljbara 

metodfragment. Metoder är för det mesta av olika omfattning vilket kan innebära att 

det kan bli en ojämnhet eller skevhet vid en jämförande analys av olika metodkomplex. 

Men styrkan kan ligga i att metoderna förblir ”orörda” när de utgör underlag 

för en metodkombination – metoddelarna i ett metodkomplex är ofta väl integrerade 

med varandra och ger då ett stöd för helheten. 

Vi har ovan berört dimensionen Metodkombination som jag bedömer som själva 

kärnfrågan för att kunna erhålla en kraftfull verktygslåda för utvecklingsarbete. Det 

räcker inte med ett antal isolerade metoder i en Affärsutvecklares Verktygslåda utan 

14

de ingående metoderna behöver ha ett fungerande samspel. Metodkombinationer kan 

genomföras genom att kedja samman eller alliera metoder med varandra. Som 

utgångspunkt kan man ha komponenter, fragment och/eller hela komplex av metoder. 

En svårighet kan uppstå då man försöker kombinera metoder med olika uppbyggnad. 

9 Metodsamordning 

När man funnit en möjlig och lämplig metodkombination är det dags att fundera över 

hur metoderna exakt ska samordnas med varandra. Det är viktigt att genomföra en 

effektiv metodsamordning så att man verkligen kan utnyttja potentialen i en önskad 

metodkombination. Om vi exempelvis önskar kombinera tre metoder för affärsutveckling, 

verksamhetsutveckling och systemutveckling i en kedja så behöver man 

studera möjligheterna att fullt ut kunna skapa affärsstödjande informationssystem som 

stärker företagets konkurrenskraft på marknaden. Vid en metodsamordning är olika 

vägval möjliga (Nilsson 1991, s. 106, Seigerroth 1998, s. 54) – här ska jag behandla 

två sådana möjligheter: 

• Metodlänkning 

Ett gränssnitt skapas mellan aktuella metoder utan att ändra något i innehållet och 

logiken i metodansatserna. Metoderna länkas samman genom en lösare form av 

hopkoppling. (Seigerroth benämner detta ’metodkombinering’) 

• Metodntegration 

De aktuella metoderna integreras till en enhetlig metodansats. Här får man vara 

beredd på att ändra på en eller flera metoder för att få till stånd en fruktbar 

integration. (Seigerroth benämner detta ’metodsammansmältning’) 

En metodintegration är en högre ambitionsnivå än en metodlänkning. En metodlänkning 

ger främst en större frihet och öppenhet för en viss metodansats att kunna 

koppla sig samman med flera andra metoder på marknaden. En metodintegration leder 

å andra sidan fram till ett mer genomarbetat metodförslag som kan ge ett bättre stöd 

för framtida utvecklingsarbete. Inför en metodintegration krävs normalt att ingående 

metodkandidater formaliseras och preciseras för att kunna tydliggöra sammansmältningen 

(jfr Eriksson och Penker 2000; Yi 2000). En metodintegration bör 

betraktas som en lärprocess eftersom man behöver vara flexibel för att kunna göra 

förändringar i metoderna (Goldkuhl et al. 1998). 

Efter att ha studerat förutsättningarna för en möjlig och lämplig metodkombination 

följer det konkreta arbetet med en metodsamordning där man kan välja mellan att 

länka samman eller integrera ihop metodkandidaterna till en helhet. För Affärsutvecklarens 

Verktygslåda är det ett strategiskt val om vi ska satsa på en lösare 

metodlänkning som ger större flexibilitet eller en hårdare metodintegration som ger en 

bättre helhet och en tydligare profil. 

10 Meta-modellering 

För att kunna skapa effektiva metodkombinationer har det visat sig lämpligt att 

genomföra en meta-modellering (metodmodellering, kunskapsmodellering) för att 

15

undersöka om metoderna går att koppla ihop och på vilket sätt (Goldkuhl, 1996). 

Principerna bakom meta-modellering beskrivs närmare i Ljungberg och Kinnula 

(1993) samt Tolvanen och Lyytinen (1993). Meta-modellering är ett skarpt instrument 

för att kunna tränga in i och analysera olika metoder. På detta sätt beskriver man exakt 

hur metoderna fungerar och är uppbyggda. För att kunna fånga huvudkontentan 

bakom en viss metodansats är det lämpligt att framställa tre typer av meta-modeller 

(enligt Nilsson 1999, s. 222): 

1. Intentionsmodell 

meta-modell över värderingsfilosofi, mål, visioner, problem, styrkor, intressegrupper 

och kritiska framgångsfaktorer (KFF) för att använda en viss metod. 

2. Begreppsmodell 

meta-modell över koncept, termer och definitioner som nyttjas för att strukturera 

och bygga upp en viss metod (d.v.s. metodens ”byggstenar” och deras relationer). 

3. Flödesmodell 

meta-modell över aktiviteter (faser, moment, arbetssteg) och huvudsakliga resultat 

(modeller, dokument) vid ett utvecklingsarbete när man tillämpar en viss metod. 

En sådan form av meta-modellering ger tre olika perspektiv för att analysera specifika 

metoder. Meta-modellering ger vidare en djupare förståelse av den bakomliggande 

logiken för olika metoder och underlättar därmed skapandet av lämpliga metodkedjor 

och metodallianser. Syftet med meta-modelleringen är att finna likheter och skillnader 

mellan de studerade metoderna. Med andra ord analyserar vi om två metoder: 

• Är motstridiga eller förenliga? (intentionsmodellering) 

• Har samstämmiga eller olikartade koncept? (begreppsmodellering) 

• Har fungerande övergångar? Kan de i så fall kopplas ihop i en viss sekventiell, 

parallell och/eller iterativ arbetsordning? (flödesmodellering) 

En lämplig arbetsgång för att bedriva meta-modellering är att man inleder med 

intentionsmodellering, fortsätter med begreppsmodellering och avslutar med flödesmodellering 

(enligt Nilsson 1999). Efter varje sådan modelleringsfas sker en kontroll 

av om det finns förutsättningar att gå vidare i arbetat med att skapa fruktbara metodkombinationer. 

Om det exempelvis inte går att förena två metoder (enligt intentionsmodelleringen) 

är det onödigt att fortsätta arbetet med en meta-modellering av 

metodernas begreppsapparat. Vidare om det inte finns en tillräcklig begreppsöverensstämmelse 

mellan metoderna är det onödigt att gå vidare och försöka metamodellera 

metodernas arbetsflöden. Men helt naturligt kan det finnas behov av att 

under meta-modelleringen iterera mellan de tre modelleringsfaserna för att kartlägga 

metodernas intentioner, begrepp och arbetsflöden. 

Efter att ha genomfört ett stort antal meta-modelleringsövningar har vi erhållit ett 

antal intressanta erfarenheter. Ett intryck är att de etablerade metoderna på marknaden 

är välpaketerade och bra dokumenterade i handböcker och publikationer. När det 

gäller att meta-modellera själva metoderna har vi funnit ett antal genomgående 

mönster: 

16

• Intentioner eller mål för att tillämpa metoderna är ofta implicita och verkar till 

stor del finnas i ”huvudet” på metodinnovatörerna. 

• Begreppen eller ”byggstenarna” är relativt enkla att identifiera i metoderna men 

svårare att relatera eller koppla ihop till varandra på ett ändamålsenligt sätt. 

• Arbetsflödet i form av föreslagna aktiviteter och resultat varierar mycket i klarhet 

och precision mellan metoderna. 

Affärsutvecklarens Verktygslåda ska innehålla en uppsättning värdefulla metoder som 

ska användas vid olika typer av utvecklingsarbeten inom företag och organisationer. 

För att kunna förstå dessa metoder på djupet behöver vi meta-modellera metodernas 

intentioner, begreppsapparat och arbetsflöden. Detta arbete med meta-modellering 

bildar sedan underlag för att skapa effektiva kombinationer i form av kedjor och 

allianser mellan verktygslådans olika metodansatser. 

NÅGRA UTMANINGAR 

Det finns ett stort antal utmaningar för fortsatt forskning kring hur man kan skapa 

ändamålsenliga verktygslådor med metoder för utvecklingsarbete inom företag och 

organisationer. Inom ämnet informatik vid Karlstads universitet bedriver vi idag 

omfattande forskning om metodanvändning i organisationer (Håkangård och Nilsson 

2000). Jag vill här i korthet beröra fyra olika forskningsfrågor för framtida studier 

som jag identifierat under arbetet med mitt bidrag: 

1. Vilka övriga dimensioner bör man beakta vid konstruktion av Affärsutvecklarens 

Verktygslåda? 

Jag har här fokuserat på 10 olika dimensioner som jag som forskare och konsult funnit 

speciellt viktiga att tänka på vid konstruktion av verktygslådor. Det finns med 

säkerhet flera andra viktiga dimensioner att beakta när man har en vision om att få 

metoder i samspel vid utvecklingsarbete inom organisationer. Christer Nellborn 

(1999) och Christofer Tolis (1999) presenterar exempelvis inom ramen för Business 

Modelling konsortiet ett antal intressanta dimensioner av värde för konstruktion av 

verktygslådor. Att kreera fram nya dimensioner lämnar jag vidare för fortsatt 

forskning! 

2. Vilka betydelsefulla samband råder mellan olika dimensioner och som därför bör 

studeras och analyseras i ett helhetssammanhang? 

Denna intressanta frågeställning har jag inte haft möjlighet att penetrera på djupet 

inom ramen för denna avgränsade forskningsuppgift. Det föreligger en hel del 

betydelsefulla samband mellan de studerade dimensionerna. Som exempel kan 

nämnas sambandet mellan dimensionerna ”Modelleringsaspekt” och ”Utvecklingsnivå”. 

Björn Nilsson (1999) har inom konsortiet Business Modelling formulerat ett 

intresseväckande ramverk över hur olika modelleringsaspekter har sina motsvarigheter 

på olika utvecklingsnivåer inom företag. Fler studier kring intressanta samband 

mellan olika dimensioner eftersökes härmed! 

17

3. Vilka typer av verktygslådor ska vi forskare experimentera med? 

Här kan man tänka sig olika uppläggningar för att undersöka användbarheten av 

konceptet bakom Affärsutvecklarens Verktygslåda. En möjlighet är att konstruera en 

uppsättning typexempel eller idealtyper för verktygslådor som underlag för olika 

laboratorieexperiment. En annan möjlighet är att genomföra ett antal ”skarpa” fältexperiment 

i verklig miljö ute på olika företag som använder sig av verktygslådor vid 

förändringsarbete inom organisationen. Jag upplever det som fruktbart att i fortsatt 

forskningsarbete försöka gå båda vägarna för att nå olika typer av insikter kring 

betydelsen av verktygslådor vid utvecklingsarbete! 

4. Vilken betydelse spelar egentligen metoder för utvecklingsarbete för att nå 

önskade effekter i affärsverksamheten? 

I inledningen av mitt bidrag här nämnde jag tre praktiskt förankrade motiv för 

användning av metoder vid utvecklingsarbete inom organisationer – nämligen behov 

av Kravspecifikationer, IT som möjliggörare och Verksamhetsbeskrivning. Men 

frågan kvarstår om vi verkligen får ut önskade effekter av metodanvändning vid 

utvecklingsarbete i våra företag? (jfr Fitzgerald 1996). Detta är i grunden en vital 

forskningsfråga för fortsatta studier. Om det föreligger ett begränsat behov av metoder 

så är det ju ingen idé att konstruera verktygslådor! 

Jag vill i detta sammanhang avsluta mitt bidrag med några intressanta slutsatser från 

min doktorsavhandling (Nilsson 1991) kring metodanvändning i standardsystemmiljöer. 

Detta formuleras som två samverkande hypoteser för fortsatt penetrering i 

framtiden: 

Hypotes om ökat metodbehov: 

”Ju större investering ett företag gör i ett IT-system och ju mindre förkunskap om 

systemutveckling aktörerna har desto större behov av att använda systematisk 

metodik i förändringsarbetet.” 

Och omvänt! 

Hypotes om minskat metodbehov: 

”Ju mindre investering ett företag gör i ett IT-system och ju större förkunskap om 

systemutveckling aktörerna har desto mindre behov av att använda systematisk 

metodik i förändringsarbetet.” 

REFERENSER 

Alarik, B. Företagsutveckling & strategi, Liber, Malmö, 1988. 

Andersen, E.S. Introduktion till verksamhetsöversyn, Rapport V-1101, Institutet för 

Verksamhetsutveckling (Institut V), Stockholm, 1981. 

18

Andersen, E.S. Systemutveckling – principer, metoder och tekniker, Studentlitteratur, 

Lund, 1994. 

Andersen, E.S., Grude, K.V., og Aarø, A. Vellykket edb-anskaffelse, NKI-forlaget, 

Oslo, 1987. 

Andersson, J. ”Business Process Development and Information Technology in Small 

and Medium-sized Companies”, in Perspectives on Business Modelling – 

Understanding and Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn 

(eds.), Springer, Berlin, 1999, pp. 117-130. 

Asker, B., Nilsson, M., Söderström, P., och Wiktorin, L. Återanvändning i 

verkligheten – Rapport från projekt Särimner, Studentlitteratur, Lund, 1996. 

Avison, D.E. and Fitzgerald, G. Information Systems Development – Methodolgies, 

Techniques and Tools, 2 nd ed., McGraw-Hill, London, 1995. 

Axelsson, L. Praktisk Verksamhetsutveckling – inriktad på engagemang, kvalitet och 

snabba resultat, Studentlitteratur, Lund, 1998. 

Axelsson, L.E. ”Konceptuell modellering av databaser – går det?”, i Om metoder för 

systemutveckling i professionella organisationer – Karlstadskolans syn på 

informatikens roll i samhället, A.G. Nilsson och J.S. Pettersson (red.), 

Studentlitteratur, Lund, 2000, s. 182-203. 

Bengtsson, L., och Skärvad, P.-H. Företagsstrategiska perspektiv, Studentlitteratur, 

Lund, 1988. 

Benthede, B. Verktyg för Verksamhetsutveckling – Verktygslådan 1995, svensk 

version, Ericsson, Stockholm, 1995. 

Bergman, L. En verktygslåda för användarmedverkan vid problemorienterad 

systemutveckling, Rapport 10:10, Dataföreningen i Sverige (f.d. Riksdataförbundet), 

Stockholm, 1981. 

Bergner, T., Hernæs, K., Johansson, E., Lundeberg, M., och Olstedt, D. Självbetjänad 

databehandling – Samlevnadsformer, Rapport V-4203, Institutet för Verksamhetsutveckling 

(Institut V), Stockholm, 1982. 

Björk, S. Verktygslådan – Analyshjälpmedel för företagsledning, Svenska Dagbladets 

Förlag, Stockholm, 1992. 

Brandt, P., Carlsson, R., och Nilsson, A.G. Välja och Förvalta Standardsystem, 

Studentlitteratur, Lund, 1998. 

Brinkkemper, S. ”Method Engineering: Engineering of Information Systems 

Development Methods and Tools”, Information and Software Technology (37:11), 

1995, pp. 1-6. 

19

Brinkkemper, S. ”Method Engineering with Web-enabled Methods”, in Information 

Systems Engineering – State of the Art and Research Themes, S. Brinkkemper, E. 

Lindencrona and A. Sølvberg (eds.), Springer, London, 2000. 

Bubenko jr., J.A., and Kirikova, M. ”Improving the Quality of Requirements 

Specifications by Enterprise Modelling”, in Perspectives on Business Modelling – 



Carlsson, S. Lärande systemutveckling och samarbetsformer – från kommunikation 

till samförstånd genom lärande och undervisning, Doktorsavhandling, Avdelning 

Informatik, Institutionen för informationsteknologi, Karlstads universitet, 2000. 

Christiansson, B. ”Komponentbaserad systemutveckling – genväg eller senväg”, i Om 

metoder för systemutveckling i professionella organisationer – Karlstadskolans syn på 

informatikens roll i samhället, A.G. Nilsson och J.S. Pettersson (red.), Studentlitteratur, 

Lund, 2000, s. 226-243. 

Christiansson, M.-T. ”Verksamhetsmodellering i en inter-organisatorisk samverkan – 

vad beskriva, varför och hur”, i Om metoder för systemutveckling i professionella 

organisationer – Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson 

och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 258-277. 

Davenport, T.H. Mission Critical – Realizing the Promise of Enterprise Systems, 

Harvard Business School Press, Boston, Massachusetts, 2000. 

Docherty, P., Magnusson, Å., Stymne, B., Callbo, K. och Herber, S. Hur man lyckas 

med systemutveckling – En analys av fem praktikfall, EFI, Handelshögskolan i 


Earl, M.J., Sampler, J.L., and Short, J.E. ”Relationships between Strategy and 

Business Process Reengineering: Evidence from Case Studies”, in Information 

Management – The Organisational Dimension, M.J. Earl (ed.), Oxford University 

Press, Oxford, UK, 1996, pp. 171-195. 

Edvardsson, B. Kvalitet och tjänsteutveckling, Studentlitteratur, Lund, 1996. 

Eriksson, H.-E., and Penker, M. Business Modeling with UML – Business Patterns at 

Work, OMG Press, John Wiley & Sons, New York, 2000. 

Fagerström, J. Objektorienterad analys och design – en andra generationens metod, 


Fariselli, P. (ed.) Innovating SME Business Practices – The Compete Methodology 

and Tools, Nomisma, edizioni Pendragon, Bologna, Italy, 1998. 

Fitzgerald, B. ”Formalized Systems Development Methodologies : A Critical Perspective”, 

Information Systems Journal (6:1), Blackwell Science Ltd, 1996, pp. 3-23. 

20

Fredriksson, O. ”IT-baserade tjänsteverksamheter – affärsdriven bankutveckling”, i 

Om metoder för systemutveckling i professionella organisationer – Karlstadskolans 

syn på informatikens roll i samhället, A.G. Nilsson och J.S. Pettersson (red.), 

Studentlitteratur, Lund, 2000, s. 31-48. 

Fåhraeus, E. Metodkedjornas och verktygens roll vid systemutveckling, Rapport 24, 

Dataföreningen i Sverige (f.d. Riksdataförbundet), Stockholm, 1986. 

Goldkuhl, G. Stöd och Struktur i Systemutvecklingsprocessen, Research Report 

LiTH-IDA-R-92-41, Forskningsgrupp VITS, Institutionen för datavetenskap (IDA), 

Linköpings universitet, 1992. 

Goldkuhl, G. Metodarkitektur för metodanalys, Research Report LiTH-IDA-R-96-06, 

Forskningsgrupp VITS, Institutionen för datavetenskap (IDA), Linköpings universitet, 

1996. 

Goldkuhl, G., Lind, M., and Seigerroth, U. ”Method Integration: the Need for a 

Learning Process”, IEE Proceedings Software (145:4), 1998, pp. 113-118. 

Gustas, R. ”Analys av affärsproceser utifrån begreppet koherens – exempel från en 

fallstudie inom skogsindustrin”, i Om metoder för systemutveckling i professionella 



Hernbäck, J., Hultman, P.-O., Ininbergs, P., och Lindqvist, I. Systempraktikan – En 

handbok i systemanalys, Liber, Malmö, 1990. 

Håkangård, S., och Nilsson, A.G. ”Användbar forskning inom informatik – perspektiv 

och spetsområden”, i Om metoder för systemutveckling i professionella 



Iivari, J., and Lyytinen, K. ”Research on Information Systems Development in 

Scandinavia – Unity in Plurality”, Scandinavian Journal of Information Systems (10: 

1&2), 1998, pp. 135-186. 

Jayaratna, N. Understanding and Evaluating Methodologies – A Systemic 

Framework, McGraw-Hill, London, 1994. 

Kalderén, H. Affärssystem, Ekerlids Förlag, Stockholm, 1995. 

Langefors, B. Essays on Infology – Summing Up and Planning for the Future, 


Lie-Nielsen, S., och Colliander, L. Principer för en ny generation systemutvecklingsverktyg, 

Rapport 16, Dataföreningen i Sverige (f.d. Riksdataförbundet), Stockholm, 

1983. 

Lindström, C.-G. ”Lessons Learned from Applying Business Modelling – Exploring 

Opportunities and Avoiding Pitfalls”, in Perspectives on Business Modelling – 

21



Ljungberg, J., and Kinnula, T. ”Metamodellering ny tvärvetenskap”, Datorpulsen, 

våren 1993, Studentförlaget, 1993, s. 52-54. 

Lundeberg, M. ”Nivå-synsättet – en första introduktion”, i Att Föra Verksamheten 

Framåt – Människor och informationssystem i samverkan, M. Lundeberg och B. 

Sundgren (red.), Studentlitteratur, Lund, 1996, s. 9-32. 

Lundeberg, M., Goldkuhl, G., och Nilsson, A.G. Systemering, Studentlitteratur, Lund, 

1978. 

Magnusson, Å., och Wahlgren, H. Utveckling av ekonomistyrsystem enligt RP, 

utgåva 3, Industrilitteratur, Stockholm, 1995. 

Mattsson, L.-G. ” ’Relationship Marketing’ and the ’Market-as-Networks Approach’ 

– A Comparative Analysis of Two Evolving Streams of Research”, Journal of 

Marketing Management (13), 1997, pp. 447-461. 

Mintzberg, H., and Quinn, J.B. The Strategy Process – Concepts and Contexts, 

Prentice-Hall, Englewood Cliffs, New Jersey, 1992. 

Moberg, B., Nilsson, A.G., och Tägtström, I. Välj rätt programvara – En skrift om hur 

man stärker företagets affärsverksamhet genom att välja rätt programvara, STUrapport 

nr. 780-1990, Nutek (f.d. STU), Stockholm, 1991. 

Molin, L. ”Vad kan systemutvecklare och multimediautvecklare lära sig av varandra – 

planera eller parera?”, i Om metoder för systemutveckling i professionella 



Nellborn, C. ”Business and Systems Development – Opportunities for an Integrated 

Way-of-Working”, in Perspectives on Business Modelling – Understanding and 

Changing Organisations”, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, 

Berlin, 1999, pp. 197-213. 

Nilsson, A.G. ”Systemering – En referensram”, Nordisk Datanytt (17:4), 1987, s. 46- 

50. 

Nilsson, A.G. ”Information Systems Development – A Frame of Reference and 

Classifications”, in CASE89 – The first Nordic Conference on Advanced Systems 

Engineering, SISU & SSI, Kista, Stockholm, 1989. 

Nilsson, A.G. Anskaffning av standardsystem för att utveckla verksamheter – 

Utveckling och prövning av SIV-metoden, Doktorsavhandling, Sektionen för 

Information Management, EFI, Handelshögskolan i Stockholm, 1991. 

Nilsson, A.G. ”Business Modelling as a Base for Information Systems Development”, 

in Proceedings of The Third International Conference on Informations Systems 

22

Developers Workbench, S. Wrycza (ed.), University of Gdansk, Poland, 1992, pp. 

77-88. 

Nilsson, A.G. Utveckling av metoder för systemarbete – ett historiskt perspektiv, 

Research report LiTH-IDA-R-95-13, Forskningsgrupp VITS, Institutionen för 

datavetenskap (IDA), Linköpings universitet, 1995. 

Nilsson, A.G. ”The Business Developer’s Toolbox: Chains and Alliances between 

Established Methods”, in Perspectives on Business Modelling – Understanding and 

Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, 

Berlin, 1999, pp. 217-241. 

Nilsson, A.G. ”Användning av standardsystem i organisationer – kritiska framgångsfaktorer”, 

i Om metoder för systemutveckling i professionella organisationer – 

Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson och J.S. 

Pettersson (red.), Studentlitteratur, Lund, 2000, s. 204-225. 

Nilsson, A.G., och Pettersson, J.S. (red.) Om metoder för systemutveckling i 

professionella organisationer – Karlstadskolans syn på informatikens roll i samhället, 


Nilsson, A.G., Tolis, C., and Nellborn, C. (eds.) Perspectives on Business Modelling 

– Understanding and Changing Organisations, Springer, Berlin, 1999. 

Nilsson, B.E. ”On Why to Model What and How: Concepts and Architecture for 

Change”, in Perspectives on Business Modelling – Understanding and Changing 

Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, Berlin, 1999, 

pp. 269-303. 

Nissen, H.-E., och Andersen, E.S. Systemering – Verksamhetsbeskrivning, Studentlitteratur, 

Lund, 1977. 

Norell, M. Stödmetoder och samverkan i produktutveckling, Doktorsavhandling, 

Rapport TRITA-MAE 1992:7, Institutionen för Makinelement, Kungliga Tekniska 

Högskolan (KTH), Stockholm, 1992. 

Nurminen, M.I. People or Computers: Three Ways of Looking at Information 

Systems, Studentlitteratur, Lund, 1988. 

Olhager, J., och Rapp, B. Effektiv MPS – Referenssystem för datorbaserad material- 

och produktionsstyrning, Studentlitteratur, Lund, 1985. 

Olle, T.W., Hagelstein, J., Macdonald, I.G., Rolland, C., Sol, H.G., Van Assche, 

F.J.M., and Verrijn-Stuart, A.A., Information Systems Methodologies – A Framework 

for Understanding, 2 nd ed., Addison-Wesley, Wokingham, England, 1991. 

Rantzer, M. Programvarusystem: Prototyping – ökad träffsäkerhet vid systemutveckling, 

Rapport nr. 3, Informationsteknologi, Sveriges Verkstadsindustrier (VI), 


23

Rapp, B. ”Principal-Agent and Transaction Cost Theories in Business Modelling”, in 

Perspectives on Business Modelling – Understanding and Changing Organisations, 

A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, Berlin, 1999, pp. 181-196. 

Ryan, K., Kronlof, K., and Sheehan, A. ”Method Integration”, in Lessons Learned 

from the Use of Methodologies, Proceedings of the Fourth Conference of the Brittish 

Computer Society (BCS), N. Jayaratna and B. Fitzgerald (eds)., University of College 

Cork, Cork, Ireland, 1996, pp. 235-246. 

Röstlinger, A, och Goldkuhl, G. Generisk Flexibilitet – På väg mot en 

komponentbaserad metodsyn, Research Report LiTH-IDA-R-96-15, Forskningsgrupp 

VITS, Institutionen för datavetenskap (IDA), Linköpings universitet, 1996. 

Samuelson, L. Models of Accounting Information Systems – The Swedish Case, 


Samuelsson, K. ”Kemiinformatik som flervetenskap – att utnyttja standardiserade 

system för nomenklatur”, i Om metoder för systemutveckling i professionella 



Seigerroth, U. Integration av förändringsmetoder – en modell för välgrundad 

metodintegration, Licentiatavhandling, Informationssystemutveckling, Institutionen 

för datavetenskap (IDA), Filosofisk Fakultet, Linköpings universitet, 1998. 

SIS. Referensmodell för systemutveckling, Teknisk rapport SIS TR 321, 

Standardiseringskommissionen i Sverige (SIS), Stockholm, 1989. 

Sowa, J.F., and Zachman, J.A. ”Extending and Formalizing the Framework for 

Information Systems Architecture”, IBM Systems Journal (31:3), 1992, pp. 590-616. 

Steneskog, G. ”Business Process Models Revised – Challenging the Physical 

Metaphor”, in Perspectives on Business Modelling – Understanding and Changing 


pp. 165-179. 

Stymne, B., Belotti, C., Eriksson, M., Nilsson, A.G., Rapp, B., Stjernberg, T., och 

Tunälv, C. Det konkurrenskraftiga småföretaget – en guide för affärsutveckling med 

IT-stöd, Studentlitteratur, Lund, 2000 (under utgivning). 

Sundgren, B. Databasorienterad systemutveckling – Grundläggande begrepp, 

Datamodellering, Systemkonstruktion, Studentlitteratur, Lund, 1992. 

Sundgren, B. ”Business Modelling in a Historical Perspective: Experiences from 

Statistics Sweden”, in Perspectives on Business Modelling – Understanding and 


Berlin, 1999, pp. 93-115. 

Söderlund, E., and Persson, A. Transitioning Between Modelling Techniques: An 

Experience Report, Department of Computer Science, University of Skövde, 2000. 

24

Targama, A. Former för Administrativt Utvecklingsarbete, Doktorsavhandling, BAS 

och Företagsekonomiska Institutionen, Göteborgs universitet, 1978. 

Tolis, C. ”Facilitating Understanding and Change – The Role of Business Models in 

Development Work”, in Perspectives on Business Modelling – Understanding and 


Berlin, 1999, pp. 133-150. 

Tolis, C., och Nilsson, A.G. ”Business Models and IS/IT in Process Orientation”, in 

Innovating SME Business Practices – The Compete Methodology and Tools, P. 

Fariselli (ed.), Nomisma, edizioni Pendragon, Bologna, Italy, 1998, pp. 27-48. 

Tolvanen, J.P., and Lyytinen, K. ”Flexible Method Adaptation in CASE 

Environments – The Metamodelling Approach”, Scandinavian Journal of Information 

Systems (1:5), 1993, pp. 51-77. 

Ulfhake, L. ”Systemutvecklingsmodell för framställning av pedagogiska programvaror 

– multimedia till nytta och nöje”, i Om metoder för systemutveckling i 

professionella organisationer – Karlstadskolans syn på informatikens roll i samhället, 

A.G. Nilsson och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 138-160. 

Venkatraman, N. ”IT-Enabled Business Transformation – From Automation to 

Business Scope reddefinition”, Sloan Management Review, Winter, 1994, pp. 73-87. 

Werr, A. The Language of Change – The roles of methods in the work of 

management consultants, Doktorsavhandling, PMO sektionen, EFI, Handelshögskolan 

i Stockholm, 1999. 

Werr, A., Stjernberg, T., och Docherty, P. ”Att förändra strukturer – en översikt och 

jämförelse”, i Människan och strukturerna – Organisationsteori för förändring, J. 

Löwstedt (red.), Nerenius & Santérus Förlag, Stockholm, 1995, s. 153-175. 

Willars, H. ”Business Modeller’s Checklist – ”Dos” and ”Dont’s” in Hands-on- 

Practice”, in Perspectives on Business Modelling – Understanding and Changing 


pp. 305-323. 

Yi, C.-h. ”Informella och formella metoder för systemutveckling – med fokus på 

UML”, i Om metoder för systemutveckling i professionella organisationer – 

Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson och J.S. 

Pettersson (red.), Studentlitteratur, Lund, 2000, s. 301-318. 

Österlee, H. Business in the Information Age – Heading for New Processes, Springer, 

Berlin, 1995. 

25

Affärsutvecklarens verktygslåda – - Högskolan i Skövde

Create successful ePaper yourself

Delete template?

Save as template?