Affärsutvecklarens verktygslåda – - Högskolan i Skövde
Affärsutvecklarens verktygslåda – - Högskolan i Skövde
Affärsutvecklarens verktygslåda – - Högskolan i Skövde
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Affärsutvecklarens</strong> <strong>verktygslåda</strong> <strong>–</strong><br />
utvecklingsarbete med metoder i samspel<br />
Informatik<br />
Institutionen för Informationsteknologi<br />
Karlstads universitet<br />
SE-651 88 Karlstad<br />
Sverige<br />
Tel: +46 (0)54 7002107<br />
Fax: +46 (0)54 7001446<br />
E-mail: Anders.Nilsson@kau.se<br />
Anders G. Nilsson<br />
1<br />
Institutet för Verksamhetsutveckling<br />
Institut V<br />
Handelshögskolan i Stockholm<br />
Box 6501<br />
SE-113 83 Stockholm<br />
Sverige<br />
Tel: +46 (0)8 4414884<br />
Fax: +46 (0)8 322620<br />
E-mail: Anders.Nilsson@hhs.se
<strong>Affärsutvecklarens</strong> <strong>verktygslåda</strong> <strong>–</strong><br />
utvecklingsarbete med metoder i samspel<br />
Anders G. Nilsson<br />
Anders är professor och ämnesföreträdare i informatik vid Karlstads universitet.<br />
Ekonomie doktor i Information Management vid Handelshögskolan i Stockholm.<br />
Docent i Informationssystemutveckling vid Linköpings universitet. Forskar kring<br />
modeller och metoder för utvecklingsarbete med affärsstrategier, verksamhetsprocesser<br />
och informationssystem. Speciellt intresserad av standardsystem och affärssystem<br />
inom organisationer. Arbetat inom EU-projektet ”Compete” kring professionell<br />
användning av moderna IT-verktyg inom små och medelstora företag.<br />
Forskningsledare för konsortiet Business Modelling som undersöker svenska företags<br />
satsningar på processorienterat utvecklingsarbete. Rådgivare till förändringsprojekt<br />
inom näringsliv och offentlig verksamhet via Institut V. Författare till 12 böcker kring<br />
teman om systemutveckling (ISAC-metoden), standardsystem (SIV-metoden, VFSmetoden)<br />
och verksamhetsmodellering (Business Modelling).<br />
2
<strong>Affärsutvecklarens</strong> <strong>verktygslåda</strong> <strong>–</strong><br />
utvecklingsarbete med metoder i samspel<br />
Anders G. Nilsson<br />
Abstrakt: I början av 90-talet fick jag ett uppdrag av några svenska företag att skapa<br />
konturerna för ett koncept som kallades för ”<strong>Affärsutvecklarens</strong> Verktygslåda”.<br />
Företagens problem visade sig inte ligga i hur själva urvalet av metoder går till inom<br />
organisationen utan snarare hur man kan skapa fruktbara kombinationer mellan de<br />
olika metoder som används vid utvecklingsarbete. Fokus blev således hur man kan få<br />
ett väl fungerande samspel mellan valda metoder i en <strong>verktygslåda</strong>. Ett konkret<br />
förslag på angreppssätt att kreera en Affärsutvecklares Verktygslåda har presenterats<br />
tidigare i Nilsson (1999). Detta bidrag är ett försök att gå ett steg vidare och reflektera<br />
över viktiga dimensioner att beakta vid konstruktion av en Affärsutvecklares<br />
Verktygslåda. En checklista med 10 olika dimensioner presenteras vilka bygger på<br />
tidigare kunskaper från egen forskning kring metodutveckling samt kartläggningar av<br />
olika etablerade metoder som idag används på marknaden.<br />
Nyckelord: Affärsutveckling, Förändringsarbete, Meta-modellering, Metod, Metodkombination,<br />
Modelleringsaspekt, Systemutveckling, Utvecklingsarbete, Verksamhetsutveckling,<br />
Verktygslåda<br />
3
<strong>Affärsutvecklarens</strong> <strong>verktygslåda</strong> <strong>–</strong><br />
utvecklingsarbete med metoder i samspel<br />
Anders G. Nilsson<br />
FOKUS PÅ METODER I SAMSPEL<br />
Varför behöver metoder användas när vi bedriver utvecklingsarbete inom företag och<br />
organisationer? Detta är en fråga som diskuterats och ventilerats under fyra decennier<br />
inom området systemutveckling. En hel del svar för att motivera användning av<br />
systematisk metodik vid utvecklingsarbete eller förändringsarbete har presenterats<br />
under årens lopp. Jag vill här omnämna tre ofta citerade behov av metodanvändning<br />
(Nilsson 1999, s. 218):<br />
• Kravspecifikationer; behov av att framställa exakta, konsistenta och fullständiga<br />
kravspecifikationer för att utforma framtida verksamhetsprocesser med olika<br />
systemlösningar (Bubenko jr. och Kirikova 1999).<br />
• IT som möjliggörare; behov av att kunna förklara hur nya IT möjligheter kan<br />
förbättra verksamhetsprocesser och affärsstrategier inom våra organisationer<br />
(Steneskog 1999, Tolis och Nilsson 1998; Venkatraman 1994; Österlee 1995).<br />
• Verksamhetsbeskrivning; behov av att beskriva och koordinera det komplexa<br />
sambandet mellan materialflöden, informationsflöden och monetära flöden inom<br />
ett företag (Nissen och Andersen 1977).<br />
Det finns idag många olika typer av metoder som lärs ut vid universitet/högskolor och<br />
som används vid praktiskt utvecklingsarbete inom organisationer (Andersen 1994;<br />
Avison och Fitzgerald 1995, Iivari och Lyytinen 1999; Werr et al. 1995). Ett<br />
intressant mönster som jag funnit är att vi verkar leta efter den kompletta metoden<br />
som täcker in alla situationer som kan tänkas uppstå vid utvecklingsarbete (Nilsson<br />
1995). Eller annorlunda utryckt att vi skulle vara på jakt efter ”super-metoden”!<br />
Historiskt sett har det genomförts en hel del experiment för att finna den maximala<br />
metoden för systemutveckling. Det är dock en illusion att tro att vi ska nå ett sådant<br />
tillstånd! Hur vi än försöker så är vi alltid begränsade vid en metodkonstruktion. Om<br />
det gick att konstruera en super-metod så skulle det bli en väldigt komplex metod.<br />
Och denna super-metod skulle säkerligen inte vara stark på alla delar utan högst<br />
märkbart variera i kvalitet. Kan vi då finna lösningar på företagens behov av<br />
heltäckande metoder för det vida spektrum av situationer som kan uppstå vid<br />
utvecklingsarbete i praktiken?<br />
En intressant möjlighet är att skapa en <strong>verktygslåda</strong> för utvecklingsarbete (Bergman<br />
1981; Benthede 1995; Björk 1992). Den bärande idén med en <strong>verktygslåda</strong> är att ha<br />
ett samspel mellan olika metoder som behövs för att klara av skilda situationer som<br />
kan uppstå vid utvecklingsarbete inom en organisation. Urvalet av metoder i<br />
<strong>verktygslåda</strong>n ska stämma överens med företagets sätt att bedriva utveckling av<br />
verksamheter och informationssystem. Man behöver vidare situationsanpassa aktuella<br />
4
metoder till företagets behov och syfte med sitt utvecklingsarbete <strong>–</strong> valda metoder kan<br />
inte användas ”rakt av” enligt skolboken eller handboken!<br />
I början av 90-talet fick jag ett uppdrag av några svenska företag att skapa konturerna<br />
för ett koncept som kallades för ”<strong>Affärsutvecklarens</strong> Verktygslåda”. Detta forskningsarbete<br />
har skett inom ramen för konsortiet Business Modelling som är ett samarbete<br />
mellan Handelshögskolan i Stockholm (HHS), Kungliga Tekniska <strong>Högskolan</strong> (KTH)<br />
och Linköpings universitet (LiU) tillsammans med företagen ABB, Ericsson, Scania,<br />
Posten och Försäkringskassan (Nilsson et al. 1999). Företagens problem visade sig<br />
inte ligga i hur själva urvalet av metoder går till inom organisationen utan snarare hur<br />
man kan skapa fruktbara kombinationer mellan de olika metoder som används vid<br />
utvecklingsarbete. Fokus blev således hur man kan få ett väl fungerande samspel<br />
mellan valda metoder i en <strong>verktygslåda</strong>. Ett konkret förslag på angreppssätt att kreera<br />
en Affärsutvecklares Verktygslåda har presenterats tidigare i Nilsson (1999). Detta<br />
bidrag är ett försök att gå ett steg vidare och reflektera över viktiga dimensioner att<br />
beakta vid konstruktion av en Affärsutvecklares Verktygslåda. Mitt bidrag är framtaget<br />
inom de två forskningsmiljöer som jag är verksam inom idag: Karlstadskolan<br />
inom informatik (Nilsson och Pettersson 2000) och Institut V i Stockholm.<br />
VIKTIGA DIMENSIONER <strong>–</strong> EN CHECKLISTA<br />
Jag väljer att presentera mina erfarenheter kring att skapa verktygslådor med metoder<br />
för utvecklingsarbete i form av en checklista över viktiga dimensioner att tänka på i<br />
ett sådant sammanhang. Denna checklista bygger på kunskaper från dels egen<br />
forskning med att konstruera metoder för olika typer av systemutveckling (ISACmetoden,<br />
SIV-metoden och VFS-metoden) dels olika kartläggningar inom Business<br />
Modelling konsortiet av etablerade metoder för utvecklingsarbete som i dagsläget<br />
används på marknaden.<br />
Mitt förslag till checklista innehåller 10 viktiga dimensioner att kunna beakta vid<br />
konstruktion av en Affärsutvecklares Verktygslåda. Med nödvändighet blir checklistan<br />
ett subjektivt urval av vad jag vill lyfta fram som speciellt viktiga lärdomar. Det<br />
finns ingen logisk rangordning av dimensionerna utan de presenteras i en möjlig<br />
tidsordning som de kan aktualiseras vid arbete med metodutveckling.<br />
1 Metod<br />
Begreppet metod för utvecklingsarbete har debatterats under flera decennier inom<br />
ämnet Informationsbehandling (under olika benämningar som ADB, informatik,<br />
informationssystem, informationsvetenskap, informationsledning eller Information<br />
Management). I detta sammanhang vill jag hänvisa till t.ex. Andersen (1994),<br />
Jayaratna (1994) och Langefors (1995). I dagens läge verkar många forskare överens<br />
om att en metod ger riktlinjer, anvisningar och föreskrifter om ett systematiskt arbetssätt<br />
för utvecklingsverksamhet inom företag. Med andra ord en praktisk vägledning<br />
och handfasta råd för hur utvecklingsarbete bör bedrivas. Metod ger på detta sätt en<br />
norm för önskvärt beteende hos olika aktörer under ett förändringsarbete. För det<br />
mesta manifesteras en metod i form av en ”idealmodell” för arbete med utvecklings-<br />
5
frågor, men det finns alltid möjligheter till avvikelser när så är lämpligt i en konkret<br />
tillämpning.<br />
Normalt kan man tänka i olika abstraktionsnivåer när man i det svenska språket hör<br />
ordet ’metod’. I detta sammanhang ska en viktig åtskillnad göras. Jag föreslår att<br />
’metodik’ används som ett generellt begrepp för en ’metod på typ-nivå’ medan<br />
’metodansats’ nyttjas som ett specifikt begrepp för en ’metod på instans-nivå’. En viss<br />
metodansats är en konkretisering av någon metodik. ISAC som metodansats är en<br />
konkretisering av metodik för egenutveckling av informationssystem (Lundeberg et<br />
al. 1978), SIV som metodansats är en konkretisering av metodik för anskaffning eller<br />
upphandling av standardsystem (Nilsson, 1991), och så vidare. En generell eller<br />
generisk metod på typ-nivå omfattar domänkunskaper för det problemområde som<br />
avses stödjas med handlingsregler. En konkret metod på instans-nivå kan inte vara<br />
heltäckande för alla situationer som kan uppstå i ett utvecklingsarbete <strong>–</strong> jämför<br />
diskussionen om ”super-metod” ovan!<br />
Ibland används begreppet ’ansats’ eller på engelska ’approach’ i en något annorlunda<br />
bemärkelse. Med ansats menas då en ofullständig metod t.ex. att den ej är tillräckligt<br />
genomarbetad eller att vissa delar saknas. Vidare är då en ansats vanligtvis mindre<br />
normativ eller preskriptiv till sin karaktär än en metod. Det finns även möjligheter att<br />
kombinera flera fristående metoder t.ex. till en s.k. ’metodkedja’ för att nå en mer<br />
komplett metodik (se Fåhraeus 1986). Mer om detta kommer jag att behandla under<br />
dimensionen Metodkombination nedan.<br />
Ett möjligt sätt att precisera begreppet metod ytterligare är att försöka ange ett antal<br />
beståndsdelar. Detta ger svar på frågan vad en metod kan tänkas bestå av. Jag urskiljer<br />
tre huvuddelar i en ’metod’ med ett antal underdelar enligt följande (Nilsson 1991, s.<br />
80; Nilsson 1995):<br />
1. Perspektiv<br />
Synsätt, Vägval, Begrepp.<br />
2. Arbetsmodell<br />
Utvecklingsområden, Arbetssteg, Bedömningsfaktorer, Dokumentation, Verktyg.<br />
3. Intressentmodell<br />
Aktörer, Samarbetsformer, Ansvarsmodeller.<br />
Det är viktigt att inse att varje metod bygger på ett visst perspektiv med ett antal<br />
bakomliggande antaganden om hur utvecklingsarbete bör bedrivas på företag (jfr<br />
Nurminen 1988). Med perspektiv menar jag här alla de synsätt, vägval och begrepp<br />
som påverkar uppbyggnaden av den föreslagna arbets- och intressentmodellen.<br />
Synsätt anger olika principer och värderingar om vad som anses vara ”bra” affärer,<br />
verksamheter och informationssystem samt effektiv utveckling av dessa. Vid<br />
konstruktion av en metod har ursprungligen ett antal vägval gjorts. För att kunna<br />
förstå metodens uppbyggnad är det värdefullt om vägvalen beskrivs explicit (Nilsson<br />
1991, s. 102). Vidare behöver en metod bygga på en uppsättning fruktbara och väldefinierade<br />
begrepp.<br />
6
Ett utvecklingsarbete inom en organisation är vanligtvis en rätt omfattande och<br />
komplicerad uppgift. Man behöver ta ställning i ett stort antal frågor och fatta många<br />
olika beslut under en förändringsprocess. För att kunna angripa detta systematiskt<br />
behövs en arbetsmodell. Den kan sägas utgöra metodens ”kärna”. Modellen delar upp<br />
arbetet i ett antal överblickbara och avgränsade uppgifter. Arbetsmodellen består i sig<br />
av flera underdelar som utvecklingsområden med arbetssteg, lämpliga bedömningsfaktorer<br />
och utvärderingskriterier, förslag på dokumentationsformer eller beskrivningstekniker<br />
samt rekommenderade verktyg/hjälpmedel som stöd för arbetet.<br />
Arbetsmodellen behöver kompletteras med en intressentmodell för att bli en helhetsmetod.<br />
Intressentmodellen preciserar vem som ska göra vad under utvecklingsarbetet.<br />
Modellen visar härmed vilka aktörer som kan delta under arbetet och möjliga<br />
samarbetsformer mellan dessa intressenter. En viktig del av intressentmodellen är att<br />
beskriva själva ansvarsfördelningen d.v.s. vilka roller aktörerna ska spela under olika<br />
arbetssteg. På detta sätt får man ett samspel mellan arbetsmodell och intressentmodell.<br />
Det finns givetvis alternativa sätt att klassificera beståndsdelarna i en metod och hur<br />
man kan benämna dessa olika delar (jfr t.ex. Andersen 1994; Goldkuhl 1992). Mitt<br />
budskap är här inte hur man exakt klassificerar och namnger delar i en metod utan att<br />
det är av större betydelse att man preciserar sitt metodbegrepp när man önskar bygga<br />
upp en <strong>verktygslåda</strong> för utvecklingsarbete inom organisationer. Har vi inte en bra<br />
”koll” på vad som avses med en metod och dess delar ställs vi inför ett antal<br />
svårigheter att formulera innehållet i en Affärsutvecklares Verktygslåda. Vidare att få<br />
ett bra samspel mellan valda metoder i <strong>verktygslåda</strong>n!<br />
2 Användningssituation<br />
Utvecklingsarbete hos företag och organisationer kan betraktas ur två synvinklar:<br />
leverantör eller kund. Leverantörer utvecklar och marknadsför olika erbjudanden till<br />
en kundkrets t.ex. IT-lösningar, verksamhetskunnande och affärsrådgivning. En kund<br />
anskaffar, upphandlar och använder de olika produkter och tjänster som erbjuds på<br />
leverantörsmarknaden. En metod för utvecklingsarbete kan ta utgångspunkt i något av<br />
följande två användningssituationer (Nilsson 1991, s. 103):<br />
• Kundsituation<br />
Småföretag, Storföretag, Inter-organisatorisk samverkan.<br />
• Leverantörssituation<br />
Plattformsmarknad, Programvarumarknad, Konsultmarknad.<br />
För en kundsituation innebär det att metoden främst hjälper kunden att utveckla en<br />
helhetslösning för att få företagets verksamhet att fungera så effektivt som möjligt i<br />
framtiden. En sådan helhetslösning kan omfatta en förnyad affärsstrategi, förbättrade<br />
verksamhetsprocesser och modernare former av IT-stöd. Metoden behöver även<br />
precisera när och hur en dialog med olika leverantörer kan eller bör äga rum. Det har<br />
visat sig genom tidigare forskning att metoder för utvecklingsarbete bör utformas<br />
något annorlunda för småföretag och storföretag (se t.ex. Nilsson 1991). Flertalet<br />
metoder på marknaden har ett fokus på utvecklingsprojekt inom större företag. Under<br />
90-talet har en del experiment kring metodutveckling för småföretag ägt rum t.ex.<br />
7
genom EU-projektet Compete (Fariselli 1998). Det har även visat sig att situationer<br />
med inter-organisatorisk samverkan mellan företag utgör en speciell problematik och<br />
till viss del kräver särskild metodik för utvecklingsarbete (se exempelvis M.-T.<br />
Christiansson, 2000).<br />
För en leverantörssituation innebär det att metoden främst hjälper leverantören att<br />
framhäva sina produkter och tjänster på marknaden samt att nå lyckade resultat hos<br />
sina kunder. Metoden bör även hjälpa leverantören att värdera kundens förutsättningar<br />
för att kunna dra nytta av potentiella lösningar i företagets verksamhet. En leverantör<br />
kan agera på olika marknader för plattformar, programvaror och konsulttjänster. Det<br />
kan också gälla kombinerade lösningar t.ex. när ett standardsystem (programvara)<br />
levereras med hårdvara (plattform) samt stöd för installation och utbildning (konsulttjänster).<br />
En metod för utvecklingsarbete ur ett leverantörsperspektiv bör hantera de<br />
förhållanden som kan uppstå i en affärstransaktion med en kund och hur önskade<br />
produkter och tjänster kan framställas.<br />
En <strong>verktygslåda</strong> behöver fokusera på vilken användningssituation som gäller för<br />
aktuell organisation som ska bedriva utvecklingsarbete. Det är ett viktigt vägval om<br />
metoderna i <strong>verktygslåda</strong>n ska gälla för kunder eller leverantörer. Vidare blir fokus<br />
olika om en Affärsutvecklares Verktygslåda ska innehålla t.ex. konsultmetoder (Werr<br />
1999) eller förenklade metoder för småföretag (Andersson 1999; Stymne et al. 2000).<br />
3 Metodomfattning<br />
En metod kan byggas, konstrueras eller utformas med olika omfattning vad avser t.ex.<br />
antal rekommenderade arbetssteg och dokumenttyper (se Nilsson 1991, s. 105). En<br />
möjlig indelning av metodomfattning är efter en stigande skala av komplexitet:<br />
• Minimal metod (enkel problemstituation)<br />
• Normal metod (genomsnittlig problemsituation)<br />
• Maximal metod (svårare problemsituation)<br />
Som exempel på metodansats som utnyttjat ett sådant koncept är den senaste referensmodellen<br />
för systemutveckling från SIS (1989) som presenteras i tre metodversioner:<br />
Maxi, Midi och Mini. Jag vill i detta sammanhang laborera med en något annorlunda<br />
klassificering eller indelning av metodomfattning:<br />
• Basmetod (grundmetoden i originalutförande)<br />
• Förenklad metod (bantad snabbvariant)<br />
• Fördjupad metod (olika påbyggnader)<br />
Vanligtvis utformas en viss metod i ett originalutförande (basmetod) av en metodinnovatör<br />
som kan vara t.ex. en forskargrupp eller konsultorganisation. Efter en tid<br />
uppstår ofta behov av metodvarianter för dels kortare och snabbare utvecklingsarbete<br />
(förenklad metod) dels påbyggnadsmöjligheter för utvecklingsarbete med olika typer<br />
av specialfall (fördjupad metod). Som exempel på metodansatser som genomgått ett<br />
sådant utvecklingsförlopp kan nämnas SIV-metoden (Nilsson 1991, kap. 5) och OPRmetoden<br />
(Sundgren 1992; 1999).<br />
8
En vital fråga som man ställs inför vid design av en Affärsutvecklares Verktygslåda är<br />
vilken omfattning olika ingående metoder bör ha i startläget och sedan i kommande<br />
versioner. Räcker det med en uppsättning basmetoder eller bör vissa metoder även ha<br />
förenklade och/eller fördjupade varianter i <strong>verktygslåda</strong>n?<br />
4 Applikationsbredd<br />
En metod för utvecklingsarbete kan vara uppbyggd på olika sätt när det gäller frågan<br />
om applikationsbredd. Här avses hur många applikationsområden som metoden kan<br />
tillämpas inom. Exempel på olika applikationsområden är marknadsföringssystem<br />
(Mattsson 1997), ekonomistyrsystem (L. Samuelson 1990), MPS eller material- och<br />
produktionsstyrningssystem (Olhager och Rapp 1985) samt kemiinformatiksystem (K.<br />
Samuelsson 2000). Grovt sett kan man urskilja följande vägval när det gäller<br />
applikationsbredd för en metod (Nilsson 1991, s. 104; Carlsson 2000, s. 121):<br />
• Specifik metod (för endast ett applikationsområde)<br />
• Generell metod (övergripande för alla applikationsområden)<br />
• Gemensam metod (inslag av både specifik och generell metodik)<br />
En specifik metod stödjer ett avgränsat applikationsområde vilket leder till artskilda<br />
metoder för olika områden, t.ex. RP-metoden för ekonomistyrsystem (Magnusson och<br />
Wahlgren 1995). En generell metod är övergripande till sin natur och kan användas<br />
inom alla tänkbara applikationsområden. Flertalet metoder för systemutveckling är<br />
traditionellt uppbyggda som generella metoder t.ex. ISAC-metoden (Lundeberg et al.<br />
1978) och VFS-metoden (Brandt et al. 1998). En gemensam metod innehåller både en<br />
övergripande del och möjligheter till fördjupningar för varje applikationsområde. En<br />
sådan metod kan vara en kombination av en generell metod och ett antal specifika<br />
metoder. Den s.k. MiniSIV-metoden är förutom att vara en förenklad metod för<br />
anskaffning av standardsystem även en gemensam metod eftersom MiniSIV innehåller<br />
specificerade kravlistor för ett stort antal applikationsområden (Moberg et al.<br />
1991).<br />
Metoder kan vara uppbyggda med olika applikationsbredd. I en Affärsutvecklares<br />
Verktygslåda är det viktigt att fundera över vilken mix av applikationsområden som<br />
behövs för att kunna klara av olika utvecklingsarbeten inom aktuell organisation. En<br />
attraktiv idé är att ha någon slags gemensam metod som plattform i <strong>verktygslåda</strong>n<br />
vilken förenar en uppsättning metodansatser med olika applikationsinrikningar.<br />
5 Utvecklingsstrategi<br />
Man kan bedriva utvecklingsarbete inom företag och organisationer på olika sätt <strong>–</strong><br />
med andra ord med olika utvecklingsstrategier. Nya moderna hjälpmedel för att<br />
effektivisera arbetet med att utveckla informationssystem, verksamheter och affärsstrategier<br />
dyker hela tiden upp på marknaden. Det är därför angeläget att försöka<br />
karakterisera utvecklingsarbete med olika strategier eller tillvägagångssätt i en<br />
lämplig form. Varje utvecklingsstrategi ställer krav på speciella metoder eller arbetssätt.<br />
Jag sammanställde i mitten av 80-talet en referensram som kan användas som<br />
underlag för olika vägval vid utvecklingsarbete inom organisationer (Nilsson 1987;<br />
9
1989). Detta synsätt har senare vidareutvecklats och expanderats av Andersen (1994,<br />
s. 343). Min referensram består i dess ursprungsform av en klassificering utefter tre<br />
olika indelningsgrunder (Nilsson 1991, s. 57):<br />
• Förspecificering<br />
Manuella system, Skräddarsydda system, Genererade system, Standardsystem.<br />
• Konkretisering<br />
Analytisk utveckling, Experimentell utveckling.<br />
• Användarmedverkan<br />
Expertbetjäning, Samverkan, Självbetjäning.<br />
Den första indelningsgrunden berör utveckling av informationssystem efter graden av<br />
förspecificering. Här avses hur mycket färdiga specifikationer som finns över ett<br />
informationssystem på förhand innan man påbörjar utvecklingsarbetet. Detta leder<br />
fram till olika systemtyper (Nilsson 1995). Först kan man särskilja manuella system<br />
och datorbaserade system. Datorbaserade system kan sedan delas in i skräddarsydda<br />
system, genererade system och standardsystem. Manuella system tillåter en hög grad<br />
av frihet vid systemdesign jämfört med datorbaserade system som kräver en högre<br />
grad av specificering och formalisering.<br />
Standardsystem är färdigutvecklade system och har en högre grad av förspecificering<br />
än skräddarsydda system som byggs upp från grunden (”scratch”). Standardsystem<br />
eller numera kallade för affärssystem eller ERP-system har under årens lopp fått en<br />
allt större betydelse för att effektivisera företags affärsverksamheter (Davenport 2000;<br />
Kalderén 1995; Nilsson 2000). Genererade system är ett samlingsnamn för olika<br />
systemlösningar uppbyggda med någon form av halvfabrikat. Tidigare var det vanligt<br />
att använda olika typer av informationshanteringsverktyg (IH-verktyg) för att<br />
generera önskade informationssystem i verksamheten (Lie-Nielsen och Colliander<br />
1983). Idag har detta successivt ersatts med ett koncept som kallas för komponentbaserade<br />
system som utnyttjar ”byggstenar” i miniatyrformat för att generera önskade<br />
informationssystem (Fagerström 1995; Asker et al. 1996; B. Christiansson 2000).<br />
Den andra indelningsgrunden berör graden av konkretisering vid olika former av<br />
utvecklingsarbeten inom organisationer. Ett förändringsarbete kan upplevas som en<br />
abstrakt eller konkret process av en användare. Vid analytisk utveckling konstruerar<br />
man abstrakta modeller av informationssystem och verksamheter. Kravspecifikationen<br />
måste här vara helt klar eller ”fryst” innan en implementering får äga rum. Vid<br />
experimentell utveckling skapar man en förenklad prototyp som snabbt införs i<br />
verksamheten. Användarna får en möjlighet att pröva och testa resultaten i olika<br />
omgångar i verklig miljö. Det sker i en växelverkan mellan kravspecificering och<br />
prototypimplementering.<br />
Den tredje indelningsgrunden berör graden av användarmedverkan vid utvecklingsarbete.<br />
Man kan ha olika samarbetsformer mellan användare (lekmän) i verksamheten<br />
och specialister (experter) på teknikfrågor under en förändringsprocess (Docherty et<br />
al. 1977; Targama 1978). Vid expertbetjäning är det specialisterna som rätt och sätt<br />
utarbetar en lösning åt användarna. Vid självbetjäning är det användarna själva som<br />
driver på utvecklingsarbetet och tar fram lösningar med råd och stöd av specialisterna.<br />
10
En mellanform är en samverkan på lika villkor mellan användare och specialister att<br />
gemensamt kunna komma fram till en acceptabel lösning för verksamheten.<br />
Val av utvecklingsstrategi påverkar starkt vilken typ av metod som är lämplig att<br />
använda i ett visst förändringsarbete. I en Affärsutvecklares Verktygslåda behöver<br />
finnas olika typer av metoder för att på ett professionellt sätt kunna hantera situationer<br />
med bl.a. upphandling av standardsystem (Andersen et al. 1987), generering av<br />
komponentbaserade system (L. Axelsson 1998), arbete med prototyping (Rantzer<br />
1994) och principer för självbetjäning av användare (Bergner et al. 1982).<br />
6 Modelleringsaspekt<br />
Metoder för utvecklingsarbete kan betona olika modelleringsaspekter eller angreppssätt<br />
vid beskrivning av verksamheter och deras behov av olika informationssystem<br />
(Andersen 1994, s. 119; Lindström 1999; Sowa och Zachman 1992; Willars 1999). En<br />
vanligt förekommande klassificering av metoder har varit efter följande tre grundläggande<br />
aspekter (Hernbäck et al. 1990; Olle et al. 1991; Nilsson 1991) :<br />
• Funktioner<br />
organiserade aktiviteter och arbetsuppgifter, s.k. hierarkiskt synsätt.<br />
• Data<br />
användarnas begrepp och språkbruk, s.k. resurssynsätt.<br />
• Beteenden<br />
vilka sätter igång olika rutiner i verksamheten, s.k. händelsesynsätt.<br />
Till en början konkurrerade flera olika metodskolor, som var och en representerade<br />
någon av dessa modellingsaspekter, med varandra. Men alltmer började man fokusera<br />
på att söka lämpliga kombinationer av modelleringsaspekter vid praktiskt utvecklingsarbete.<br />
Det visade sig att vi behöver en lämplig mix av modelleringsaspekter vid<br />
verkliga tillämpningar. Under 90-talet har ett antal fruktbara kombinationer av<br />
modelleringsaspekter vuxit fram (Nilsson 1995):<br />
• Processer<br />
kombination av funktioner och händelser, d.v.s. efter tidsordning.<br />
• Objekt<br />
kombination av funktioner och data, s.k. inkapsling.<br />
• Transaktioner<br />
kombination av data och händelser, m.a.o. fokus på regler.<br />
• Influens<br />
som förändrar förutsättningarna för övriga modelleringsaspekter.<br />
Modelleringsaspekten ’influens’ är av lite speciell karaktär då den påverkar övriga<br />
aspekter med fokus på att förändra verksamheten från ett nuläge till ett önskat<br />
framtida läge (Tolis och Nilsson 1998). Med influens avses en samlande aspekt för<br />
olika förhållanden som mål/intentioner, aktörer/kraftfält, problem/styrkor/KFF och<br />
behov/åtgärder vilka behöver modelleras under ett utvecklingsarbete. Att arbeta med<br />
olika modelleringsaspekter är inte trivialt. Man kan lösa detta på olika sätt t.ex. genom<br />
att (i) ange regler för övergångar eller transformationer mellan aspekterna (jfr Nilsson<br />
1989; Söderlund och Persson 2000), (ii) skapa korsreferenser för att stämma av<br />
11
aspekterna mot varandra (jfr Olle et al. 1991; Gustas 2000) eller (iii) utgå från en<br />
grundaspekt och sedan bygga på och komplettera med en eller flera andra aspekter (jfr<br />
Sundgren 1992).<br />
Vid utveckling av organisationer behöver vi ”vrida och vända” på våra beskrivningar<br />
och modeller av verksamheten. Genom att växla perspektiv med hjälp av olika<br />
modelleringsaspekter får vi en fördjupad förståelse av bakomliggande mekanismer i<br />
organisationen och därmed ett underlag för att föreslå kraftfulla förändringar av<br />
verksamheten. Att hålla sig fast vid en isolerad modelleringsaspekt leder till ett<br />
”endimensionellt” tänkande vid utvecklingsarbete! Därför är det viktigt att en<br />
Affärsutvecklares Verktygslåda innehåller ett varierat utbud av metoder som tillsammans<br />
representerar en god mix av modelleringsaspekter.<br />
7 Utvecklingsnivå<br />
En allmän trend under de senaste decennierna är att försöka placera in arbete med<br />
systemutveckling i ett större sammanhang (Andersen 1981; Nilsson 1995). Det<br />
började med olika försök att betrakta systemutveckling som en del av en mer<br />
övergripande verksamhetsutveckling. Det har senare fortsatt med att vända fokus mot<br />
företagets mission eller uppdrag och affärsinrikta systemutvecklingen. Man bedriver<br />
affärsutveckling idag med mer eller mindre inslag av systemutveckling <strong>–</strong> härav<br />
uppstod konceptet ’<strong>Affärsutvecklarens</strong> Verktygslåda’. Detta leder fram till att vi<br />
numera har ett intimare samspel mellan tre mer eller mindre parallella förändringsprocesser<br />
eller utvecklingsnivåer inom företag:<br />
• Affärsutveckling<br />
Strategisk planering som leder fram till olika affärs- och verksamhetsplaner med<br />
kompletterande IT-policies. Affärsutveckling innebär arbete med att på olika sätt<br />
stärka företagets relationer till olika aktörer i omvärlden och på marknaden<br />
(Mintzberg och Quinn 1992; Alarik 1988; Fredriksson 2000).<br />
• Verksamhetsutveckling<br />
Intern utveckling av funktioner, processer och arbetsuppgifter i verksamheten med<br />
olika former av IT-stöd. Verksamhetsutveckling kan beröra en eller flera delar<br />
inom ett företag t.ex. produktion, logistik, marknadsföring, ärendehandläggning,<br />
personalorganisation och ekonomistyrning (Stymne et al. 2000).<br />
• Systemutveckling<br />
Framtagning och förvaltning av organisationens portfölj av informationssystem<br />
bestående av egna applikationer, komponentbaserade lösningar och standardpaket.<br />
Informationssystemen kan betraktas som verksamhetsstöd (resurser) eller som<br />
”triggers” för att bedriva helt nya affärer (möjliggörare) (Tolis och Nilsson 1998).<br />
Genom att koppla systemutveckling till affärs- och verksamhetsutveckling behöver vi<br />
använda kunskaper från både Informationsbehandling och Företagsekonomi. Det<br />
finns inom företagsekonomin en tradition att skapa metoder för affärs- och<br />
verksamhetsutveckling (jfr Bengtsson och Skärvad 1988). En intressant idé är då att<br />
importera vissa företagsekonomiska metoder för förändringsarbete som utgångspunkt<br />
för fortsatt eller samtidig systemutveckling (jfr Rapp 1999). Vissa förändringsarbeten<br />
12
inom företag och organisationer berör frågor på alla tre utvecklingsområdena ovan.<br />
Exempel på detta är tjänsteutveckling (jfr Edvardsson 1996), produktutveckling (jfr<br />
Norell 1992) och multimediautveckling (jfr L.E. Axelsson 2000; Molin 2000; Ulfhake<br />
2000).<br />
Utvecklingsområdena ovan berör tre centrala nivåer inom ett företag: affärer/uppdrag,<br />
verksamhet och informationssystem (Nilsson et al. 1999; Earl et al. 1996; Österlee<br />
1995). Ett nivåsynsätt börjar alltmer användas vid utvecklingsarbeten inom företag<br />
(Lundeberg 1996). En viktig observation är att den mellersta nivån bildar en<br />
förmedlande länk. Verksamhetsprocesser har beröring med både strategiska ledningsfrågor<br />
och användning av informationssystem på företag. Det är svårt om inte<br />
omöjligt att få ut strategiska effekter av IT-stöden utan hårt arbete med verksamhetsprocesserna<br />
inom organisationen!<br />
Ett allmänt problem hos företag idag är att sambanden eller kopplingarna mellan de<br />
tre utvecklingsnivåerna inte alltid fungerar på ett tillfredsställande sätt. Det är inte<br />
ovanligt att det uppstår olika kommunikationsgap mellan affärsledning, användare i<br />
verksamheten och systemspecialister. Vid praktiskt förändringsarbete kan man valfritt<br />
börja med affärs-, verksamhets- eller system-nivån. I vilken ända man än börjar får<br />
det konsekvenser för de övriga områdena.<br />
Olika typer av innovationer påverkar i mer eller mindre omfattning alla tre nivåerna<br />
för ett företag. Detta innebär att vi inte ensidigt kan fokusera på en utvecklingsnivå i<br />
taget vid förändringsarbete. De stora förtjänsterna ligger i att arbeta parallellt med<br />
utvecklingsfrågor kring affärer/uppdrag, verksamhetsprocesser och informationssystem.<br />
Allt detta ställer krav på att en Affärsutvecklares Verktygslåda innehåller<br />
metoder från alla tre utvecklingsnivåerna och att det finns välfungerande samspel<br />
mellan dessa olika typer av metoder.<br />
8 Metodkombination<br />
Som tidigare nämnts är det orimligt att tänka sig en ”super-metod” som kan hantera<br />
all den problematik och komplexitet som kan uppstå vid utvecklingsarbete inom<br />
företag och organisationer. Istället är det ett mer fruktbart angreppssätt att försöka<br />
kombinera flera metoder som passar den utvecklingssituation som man för tillfället<br />
befinner sig i. Det finns i princip två möjliga handlingsstrategier för att genomföra<br />
metodkombinationer enligt Nilsson (1992; 1999 s. 220): skapa en Metodkedja eller<br />
skapa en Metodallians.<br />
• Metodkedja<br />
Här avses en kombination av metoder mellan olika utvecklingsnivåer. Vi skapar ett<br />
samspel i form av en kedja mellan metoder för affärsutveckling, verksamhetsutveckling<br />
och systemutveckling. Denna handlingsstrategi är en form av vertikal<br />
samordning av metoder längs en tänkt livscykel för en utvecklingsprodukt. Man<br />
skapar övergångar eller ”vägar” mellan metoder genom livscykeln. När det gäller ett<br />
systems livscykel skapas en metodkedja mellan två eller flera faser i livscykeln. Ryan<br />
et al. (1996) kallar detta för en ”inter-process” strategi.<br />
13
• Metodallians<br />
Här avses en kombination av metoder inom en och samma utvecklingsnivå. Vi skapar<br />
ett samspel i form av en allians mellan metoder inom respektive område för affärsutveckling,<br />
verksamhetsutveckling och systemutveckling. Metoder brukar fokusera på<br />
vissa problem eller frågor inom ett utvecklingsområde. Genom en metodallians har vi<br />
möjlighet att hantera flera aspekter och perspektiv vid utvecklingsarbete, d.v.s. att<br />
vara ”multi-problem-orienterade”. Denna handlingsstrategi är en form av horisontell<br />
samordning av metoder inom samma del eller fas av en tänkt livscykel för en<br />
utvecklingsprodukt. När det gäller ett systems livscykel kallar Ryan et al. (1996) detta<br />
för en ”intra-process” strategi.<br />
Som underlag för att genomföra metodkombinationer kan man utgå från hela eller<br />
delar av metoder. Det bedrivs viss forskning kring detta tema inom såväl Sverige som<br />
internationellt. Grovt sett kan man urskilja tre olika förhållningssätt:<br />
• Metodkomponent<br />
Den bärande idén är här att strukturera en viss metod utifrån ett antal avgränsbara<br />
komponenter. Det påminner om ett objekt-orienterat tänkande fast applicerat i ett<br />
metodsammanhang. Man använder så många komponenter som behövs för att klara<br />
av en given utvecklingssituation. En viktig egenskap är att metodkomponenterna är<br />
generiska och flexibla till sin uppbyggnad. Detta garanterar att komponenterna blir<br />
utbytbara och anpassbara så att de kan ingå i olika metodsammanhang. En intressant<br />
idé blir då att återanvända komponenter mellan olika konkreta metoder (se vidare<br />
Röstlinger och Goldkuhl 1996).<br />
• Metodfragment<br />
Den bärande idén är här att identifiera olika fragment eller ”byggstenar” för<br />
utvecklingsarbete genom att gå igenom olika sammanhängande delar av existerande<br />
metoder. För en viss metod är det möjligt att särskilja dels produktfragment<br />
(leverabler och resultat) dels processfragment (riktlinjer och arbetsgång). Metodfragment<br />
kan ha varierande granularitet och räckvidd för ett utvecklingsarbete. På så<br />
sätt är ett metodfragment ett relativt koncept som kan sträcka sig från en avgränsad<br />
metodkomponent till ett helt metodkomplex (se vidare Brinkkemper 1996; 2000).<br />
• Metodkomplex<br />
Den bärande idén är här att utgå från existerande metoder som de är uppbyggda utan<br />
att försöka bryta ned dessa i avgränsbara metodkomponenter eller urskiljbara<br />
metodfragment. Metoder är för det mesta av olika omfattning vilket kan innebära att<br />
det kan bli en ojämnhet eller skevhet vid en jämförande analys av olika metodkomplex.<br />
Men styrkan kan ligga i att metoderna förblir ”orörda” när de utgör underlag<br />
för en metodkombination <strong>–</strong> metoddelarna i ett metodkomplex är ofta väl integrerade<br />
med varandra och ger då ett stöd för helheten.<br />
Vi har ovan berört dimensionen Metodkombination som jag bedömer som själva<br />
kärnfrågan för att kunna erhålla en kraftfull <strong>verktygslåda</strong> för utvecklingsarbete. Det<br />
räcker inte med ett antal isolerade metoder i en Affärsutvecklares Verktygslåda utan<br />
14
de ingående metoderna behöver ha ett fungerande samspel. Metodkombinationer kan<br />
genomföras genom att kedja samman eller alliera metoder med varandra. Som<br />
utgångspunkt kan man ha komponenter, fragment och/eller hela komplex av metoder.<br />
En svårighet kan uppstå då man försöker kombinera metoder med olika uppbyggnad.<br />
9 Metodsamordning<br />
När man funnit en möjlig och lämplig metodkombination är det dags att fundera över<br />
hur metoderna exakt ska samordnas med varandra. Det är viktigt att genomföra en<br />
effektiv metodsamordning så att man verkligen kan utnyttja potentialen i en önskad<br />
metodkombination. Om vi exempelvis önskar kombinera tre metoder för affärsutveckling,<br />
verksamhetsutveckling och systemutveckling i en kedja så behöver man<br />
studera möjligheterna att fullt ut kunna skapa affärsstödjande informationssystem som<br />
stärker företagets konkurrenskraft på marknaden. Vid en metodsamordning är olika<br />
vägval möjliga (Nilsson 1991, s. 106, Seigerroth 1998, s. 54) <strong>–</strong> här ska jag behandla<br />
två sådana möjligheter:<br />
• Metodlänkning<br />
Ett gränssnitt skapas mellan aktuella metoder utan att ändra något i innehållet och<br />
logiken i metodansatserna. Metoderna länkas samman genom en lösare form av<br />
hopkoppling. (Seigerroth benämner detta ’metodkombinering’)<br />
• Metodntegration<br />
De aktuella metoderna integreras till en enhetlig metodansats. Här får man vara<br />
beredd på att ändra på en eller flera metoder för att få till stånd en fruktbar<br />
integration. (Seigerroth benämner detta ’metodsammansmältning’)<br />
En metodintegration är en högre ambitionsnivå än en metodlänkning. En metodlänkning<br />
ger främst en större frihet och öppenhet för en viss metodansats att kunna<br />
koppla sig samman med flera andra metoder på marknaden. En metodintegration leder<br />
å andra sidan fram till ett mer genomarbetat metodförslag som kan ge ett bättre stöd<br />
för framtida utvecklingsarbete. Inför en metodintegration krävs normalt att ingående<br />
metodkandidater formaliseras och preciseras för att kunna tydliggöra sammansmältningen<br />
(jfr Eriksson och Penker 2000; Yi 2000). En metodintegration bör<br />
betraktas som en lärprocess eftersom man behöver vara flexibel för att kunna göra<br />
förändringar i metoderna (Goldkuhl et al. 1998).<br />
Efter att ha studerat förutsättningarna för en möjlig och lämplig metodkombination<br />
följer det konkreta arbetet med en metodsamordning där man kan välja mellan att<br />
länka samman eller integrera ihop metodkandidaterna till en helhet. För <strong>Affärsutvecklarens</strong><br />
Verktygslåda är det ett strategiskt val om vi ska satsa på en lösare<br />
metodlänkning som ger större flexibilitet eller en hårdare metodintegration som ger en<br />
bättre helhet och en tydligare profil.<br />
10 Meta-modellering<br />
För att kunna skapa effektiva metodkombinationer har det visat sig lämpligt att<br />
genomföra en meta-modellering (metodmodellering, kunskapsmodellering) för att<br />
15
undersöka om metoderna går att koppla ihop och på vilket sätt (Goldkuhl, 1996).<br />
Principerna bakom meta-modellering beskrivs närmare i Ljungberg och Kinnula<br />
(1993) samt Tolvanen och Lyytinen (1993). Meta-modellering är ett skarpt instrument<br />
för att kunna tränga in i och analysera olika metoder. På detta sätt beskriver man exakt<br />
hur metoderna fungerar och är uppbyggda. För att kunna fånga huvudkontentan<br />
bakom en viss metodansats är det lämpligt att framställa tre typer av meta-modeller<br />
(enligt Nilsson 1999, s. 222):<br />
1. Intentionsmodell<br />
meta-modell över värderingsfilosofi, mål, visioner, problem, styrkor, intressegrupper<br />
och kritiska framgångsfaktorer (KFF) för att använda en viss metod.<br />
2. Begreppsmodell<br />
meta-modell över koncept, termer och definitioner som nyttjas för att strukturera<br />
och bygga upp en viss metod (d.v.s. metodens ”byggstenar” och deras relationer).<br />
3. Flödesmodell<br />
meta-modell över aktiviteter (faser, moment, arbetssteg) och huvudsakliga resultat<br />
(modeller, dokument) vid ett utvecklingsarbete när man tillämpar en viss metod.<br />
En sådan form av meta-modellering ger tre olika perspektiv för att analysera specifika<br />
metoder. Meta-modellering ger vidare en djupare förståelse av den bakomliggande<br />
logiken för olika metoder och underlättar därmed skapandet av lämpliga metodkedjor<br />
och metodallianser. Syftet med meta-modelleringen är att finna likheter och skillnader<br />
mellan de studerade metoderna. Med andra ord analyserar vi om två metoder:<br />
• Är motstridiga eller förenliga? (intentionsmodellering)<br />
• Har samstämmiga eller olikartade koncept? (begreppsmodellering)<br />
• Har fungerande övergångar? Kan de i så fall kopplas ihop i en viss sekventiell,<br />
parallell och/eller iterativ arbetsordning? (flödesmodellering)<br />
En lämplig arbetsgång för att bedriva meta-modellering är att man inleder med<br />
intentionsmodellering, fortsätter med begreppsmodellering och avslutar med flödesmodellering<br />
(enligt Nilsson 1999). Efter varje sådan modelleringsfas sker en kontroll<br />
av om det finns förutsättningar att gå vidare i arbetat med att skapa fruktbara metodkombinationer.<br />
Om det exempelvis inte går att förena två metoder (enligt intentionsmodelleringen)<br />
är det onödigt att fortsätta arbetet med en meta-modellering av<br />
metodernas begreppsapparat. Vidare om det inte finns en tillräcklig begreppsöverensstämmelse<br />
mellan metoderna är det onödigt att gå vidare och försöka metamodellera<br />
metodernas arbetsflöden. Men helt naturligt kan det finnas behov av att<br />
under meta-modelleringen iterera mellan de tre modelleringsfaserna för att kartlägga<br />
metodernas intentioner, begrepp och arbetsflöden.<br />
Efter att ha genomfört ett stort antal meta-modelleringsövningar har vi erhållit ett<br />
antal intressanta erfarenheter. Ett intryck är att de etablerade metoderna på marknaden<br />
är välpaketerade och bra dokumenterade i handböcker och publikationer. När det<br />
gäller att meta-modellera själva metoderna har vi funnit ett antal genomgående<br />
mönster:<br />
16
• Intentioner eller mål för att tillämpa metoderna är ofta implicita och verkar till<br />
stor del finnas i ”huvudet” på metodinnovatörerna.<br />
• Begreppen eller ”byggstenarna” är relativt enkla att identifiera i metoderna men<br />
svårare att relatera eller koppla ihop till varandra på ett ändamålsenligt sätt.<br />
• Arbetsflödet i form av föreslagna aktiviteter och resultat varierar mycket i klarhet<br />
och precision mellan metoderna.<br />
<strong>Affärsutvecklarens</strong> Verktygslåda ska innehålla en uppsättning värdefulla metoder som<br />
ska användas vid olika typer av utvecklingsarbeten inom företag och organisationer.<br />
För att kunna förstå dessa metoder på djupet behöver vi meta-modellera metodernas<br />
intentioner, begreppsapparat och arbetsflöden. Detta arbete med meta-modellering<br />
bildar sedan underlag för att skapa effektiva kombinationer i form av kedjor och<br />
allianser mellan <strong>verktygslåda</strong>ns olika metodansatser.<br />
NÅGRA UTMANINGAR<br />
Det finns ett stort antal utmaningar för fortsatt forskning kring hur man kan skapa<br />
ändamålsenliga verktygslådor med metoder för utvecklingsarbete inom företag och<br />
organisationer. Inom ämnet informatik vid Karlstads universitet bedriver vi idag<br />
omfattande forskning om metodanvändning i organisationer (Håkangård och Nilsson<br />
2000). Jag vill här i korthet beröra fyra olika forskningsfrågor för framtida studier<br />
som jag identifierat under arbetet med mitt bidrag:<br />
1. Vilka övriga dimensioner bör man beakta vid konstruktion av <strong>Affärsutvecklarens</strong><br />
Verktygslåda?<br />
Jag har här fokuserat på 10 olika dimensioner som jag som forskare och konsult funnit<br />
speciellt viktiga att tänka på vid konstruktion av verktygslådor. Det finns med<br />
säkerhet flera andra viktiga dimensioner att beakta när man har en vision om att få<br />
metoder i samspel vid utvecklingsarbete inom organisationer. Christer Nellborn<br />
(1999) och Christofer Tolis (1999) presenterar exempelvis inom ramen för Business<br />
Modelling konsortiet ett antal intressanta dimensioner av värde för konstruktion av<br />
verktygslådor. Att kreera fram nya dimensioner lämnar jag vidare för fortsatt<br />
forskning!<br />
2. Vilka betydelsefulla samband råder mellan olika dimensioner och som därför bör<br />
studeras och analyseras i ett helhetssammanhang?<br />
Denna intressanta frågeställning har jag inte haft möjlighet att penetrera på djupet<br />
inom ramen för denna avgränsade forskningsuppgift. Det föreligger en hel del<br />
betydelsefulla samband mellan de studerade dimensionerna. Som exempel kan<br />
nämnas sambandet mellan dimensionerna ”Modelleringsaspekt” och ”Utvecklingsnivå”.<br />
Björn Nilsson (1999) har inom konsortiet Business Modelling formulerat ett<br />
intresseväckande ramverk över hur olika modelleringsaspekter har sina motsvarigheter<br />
på olika utvecklingsnivåer inom företag. Fler studier kring intressanta samband<br />
mellan olika dimensioner eftersökes härmed!<br />
17
3. Vilka typer av verktygslådor ska vi forskare experimentera med?<br />
Här kan man tänka sig olika uppläggningar för att undersöka användbarheten av<br />
konceptet bakom <strong>Affärsutvecklarens</strong> Verktygslåda. En möjlighet är att konstruera en<br />
uppsättning typexempel eller idealtyper för verktygslådor som underlag för olika<br />
laboratorieexperiment. En annan möjlighet är att genomföra ett antal ”skarpa” fältexperiment<br />
i verklig miljö ute på olika företag som använder sig av verktygslådor vid<br />
förändringsarbete inom organisationen. Jag upplever det som fruktbart att i fortsatt<br />
forskningsarbete försöka gå båda vägarna för att nå olika typer av insikter kring<br />
betydelsen av verktygslådor vid utvecklingsarbete!<br />
4. Vilken betydelse spelar egentligen metoder för utvecklingsarbete för att nå<br />
önskade effekter i affärsverksamheten?<br />
I inledningen av mitt bidrag här nämnde jag tre praktiskt förankrade motiv för<br />
användning av metoder vid utvecklingsarbete inom organisationer <strong>–</strong> nämligen behov<br />
av Kravspecifikationer, IT som möjliggörare och Verksamhetsbeskrivning. Men<br />
frågan kvarstår om vi verkligen får ut önskade effekter av metodanvändning vid<br />
utvecklingsarbete i våra företag? (jfr Fitzgerald 1996). Detta är i grunden en vital<br />
forskningsfråga för fortsatta studier. Om det föreligger ett begränsat behov av metoder<br />
så är det ju ingen idé att konstruera verktygslådor!<br />
Jag vill i detta sammanhang avsluta mitt bidrag med några intressanta slutsatser från<br />
min doktorsavhandling (Nilsson 1991) kring metodanvändning i standardsystemmiljöer.<br />
Detta formuleras som två samverkande hypoteser för fortsatt penetrering i<br />
framtiden:<br />
Hypotes om ökat metodbehov:<br />
”Ju större investering ett företag gör i ett IT-system och ju mindre förkunskap om<br />
systemutveckling aktörerna har desto större behov av att använda systematisk<br />
metodik i förändringsarbetet.”<br />
Och omvänt!<br />
Hypotes om minskat metodbehov:<br />
”Ju mindre investering ett företag gör i ett IT-system och ju större förkunskap om<br />
systemutveckling aktörerna har desto mindre behov av att använda systematisk<br />
metodik i förändringsarbetet.”<br />
REFERENSER<br />
Alarik, B. Företagsutveckling & strategi, Liber, Malmö, 1988.<br />
Andersen, E.S. Introduktion till verksamhetsöversyn, Rapport V-1101, Institutet för<br />
Verksamhetsutveckling (Institut V), Stockholm, 1981.<br />
18
Andersen, E.S. Systemutveckling <strong>–</strong> principer, metoder och tekniker, Studentlitteratur,<br />
Lund, 1994.<br />
Andersen, E.S., Grude, K.V., og Aarø, A. Vellykket edb-anskaffelse, NKI-forlaget,<br />
Oslo, 1987.<br />
Andersson, J. ”Business Process Development and Information Technology in Small<br />
and Medium-sized Companies”, in Perspectives on Business Modelling <strong>–</strong><br />
Understanding and Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn<br />
(eds.), Springer, Berlin, 1999, pp. 117-130.<br />
Asker, B., Nilsson, M., Söderström, P., och Wiktorin, L. Återanvändning i<br />
verkligheten <strong>–</strong> Rapport från projekt Särimner, Studentlitteratur, Lund, 1996.<br />
Avison, D.E. and Fitzgerald, G. Information Systems Development <strong>–</strong> Methodolgies,<br />
Techniques and Tools, 2 nd ed., McGraw-Hill, London, 1995.<br />
Axelsson, L. Praktisk Verksamhetsutveckling <strong>–</strong> inriktad på engagemang, kvalitet och<br />
snabba resultat, Studentlitteratur, Lund, 1998.<br />
Axelsson, L.E. ”Konceptuell modellering av databaser <strong>–</strong> går det?”, i Om metoder för<br />
systemutveckling i professionella organisationer <strong>–</strong> Karlstadskolans syn på<br />
informatikens roll i samhället, A.G. Nilsson och J.S. Pettersson (red.),<br />
Studentlitteratur, Lund, 2000, s. 182-203.<br />
Bengtsson, L., och Skärvad, P.-H. Företagsstrategiska perspektiv, Studentlitteratur,<br />
Lund, 1988.<br />
Benthede, B. Verktyg för Verksamhetsutveckling <strong>–</strong> Verktygslådan 1995, svensk<br />
version, Ericsson, Stockholm, 1995.<br />
Bergman, L. En <strong>verktygslåda</strong> för användarmedverkan vid problemorienterad<br />
systemutveckling, Rapport 10:10, Dataföreningen i Sverige (f.d. Riksdataförbundet),<br />
Stockholm, 1981.<br />
Bergner, T., Hernæs, K., Johansson, E., Lundeberg, M., och Olstedt, D. Självbetjänad<br />
databehandling <strong>–</strong> Samlevnadsformer, Rapport V-4203, Institutet för Verksamhetsutveckling<br />
(Institut V), Stockholm, 1982.<br />
Björk, S. Verktygslådan <strong>–</strong> Analyshjälpmedel för företagsledning, Svenska Dagbladets<br />
Förlag, Stockholm, 1992.<br />
Brandt, P., Carlsson, R., och Nilsson, A.G. Välja och Förvalta Standardsystem,<br />
Studentlitteratur, Lund, 1998.<br />
Brinkkemper, S. ”Method Engineering: Engineering of Information Systems<br />
Development Methods and Tools”, Information and Software Technology (37:11),<br />
1995, pp. 1-6.<br />
19
Brinkkemper, S. ”Method Engineering with Web-enabled Methods”, in Information<br />
Systems Engineering <strong>–</strong> State of the Art and Research Themes, S. Brinkkemper, E.<br />
Lindencrona and A. Sølvberg (eds.), Springer, London, 2000.<br />
Bubenko jr., J.A., and Kirikova, M. ”Improving the Quality of Requirements<br />
Specifications by Enterprise Modelling”, in Perspectives on Business Modelling <strong>–</strong><br />
Understanding and Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn<br />
(eds.), Springer, Berlin, 1999, pp. 243-268.<br />
Carlsson, S. Lärande systemutveckling och samarbetsformer <strong>–</strong> från kommunikation<br />
till samförstånd genom lärande och undervisning, Doktorsavhandling, Avdelning<br />
Informatik, Institutionen för informationsteknologi, Karlstads universitet, 2000.<br />
Christiansson, B. ”Komponentbaserad systemutveckling <strong>–</strong> genväg eller senväg”, i Om<br />
metoder för systemutveckling i professionella organisationer <strong>–</strong> Karlstadskolans syn på<br />
informatikens roll i samhället, A.G. Nilsson och J.S. Pettersson (red.), Studentlitteratur,<br />
Lund, 2000, s. 226-243.<br />
Christiansson, M.-T. ”Verksamhetsmodellering i en inter-organisatorisk samverkan <strong>–</strong><br />
vad beskriva, varför och hur”, i Om metoder för systemutveckling i professionella<br />
organisationer <strong>–</strong> Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson<br />
och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 258-277.<br />
Davenport, T.H. Mission Critical <strong>–</strong> Realizing the Promise of Enterprise Systems,<br />
Harvard Business School Press, Boston, Massachusetts, 2000.<br />
Docherty, P., Magnusson, Å., Stymne, B., Callbo, K. och Herber, S. Hur man lyckas<br />
med systemutveckling <strong>–</strong> En analys av fem praktikfall, EFI, Handelshögskolan i<br />
Stockholm, 1977.<br />
Earl, M.J., Sampler, J.L., and Short, J.E. ”Relationships between Strategy and<br />
Business Process Reengineering: Evidence from Case Studies”, in Information<br />
Management <strong>–</strong> The Organisational Dimension, M.J. Earl (ed.), Oxford University<br />
Press, Oxford, UK, 1996, pp. 171-195.<br />
Edvardsson, B. Kvalitet och tjänsteutveckling, Studentlitteratur, Lund, 1996.<br />
Eriksson, H.-E., and Penker, M. Business Modeling with UML <strong>–</strong> Business Patterns at<br />
Work, OMG Press, John Wiley & Sons, New York, 2000.<br />
Fagerström, J. Objektorienterad analys och design <strong>–</strong> en andra generationens metod,<br />
Studentlitteratur, Lund, 1995.<br />
Fariselli, P. (ed.) Innovating SME Business Practices <strong>–</strong> The Compete Methodology<br />
and Tools, Nomisma, edizioni Pendragon, Bologna, Italy, 1998.<br />
Fitzgerald, B. ”Formalized Systems Development Methodologies : A Critical Perspective”,<br />
Information Systems Journal (6:1), Blackwell Science Ltd, 1996, pp. 3-23.<br />
20
Fredriksson, O. ”IT-baserade tjänsteverksamheter <strong>–</strong> affärsdriven bankutveckling”, i<br />
Om metoder för systemutveckling i professionella organisationer <strong>–</strong> Karlstadskolans<br />
syn på informatikens roll i samhället, A.G. Nilsson och J.S. Pettersson (red.),<br />
Studentlitteratur, Lund, 2000, s. 31-48.<br />
Fåhraeus, E. Metodkedjornas och verktygens roll vid systemutveckling, Rapport 24,<br />
Dataföreningen i Sverige (f.d. Riksdataförbundet), Stockholm, 1986.<br />
Goldkuhl, G. Stöd och Struktur i Systemutvecklingsprocessen, Research Report<br />
LiTH-IDA-R-92-41, Forskningsgrupp VITS, Institutionen för datavetenskap (IDA),<br />
Linköpings universitet, 1992.<br />
Goldkuhl, G. Metodarkitektur för metodanalys, Research Report LiTH-IDA-R-96-06,<br />
Forskningsgrupp VITS, Institutionen för datavetenskap (IDA), Linköpings universitet,<br />
1996.<br />
Goldkuhl, G., Lind, M., and Seigerroth, U. ”Method Integration: the Need for a<br />
Learning Process”, IEE Proceedings Software (145:4), 1998, pp. 113-118.<br />
Gustas, R. ”Analys av affärsproceser utifrån begreppet koherens <strong>–</strong> exempel från en<br />
fallstudie inom skogsindustrin”, i Om metoder för systemutveckling i professionella<br />
organisationer <strong>–</strong> Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson<br />
och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 278-300.<br />
Hernbäck, J., Hultman, P.-O., Ininbergs, P., och Lindqvist, I. Systempraktikan <strong>–</strong> En<br />
handbok i systemanalys, Liber, Malmö, 1990.<br />
Håkangård, S., och Nilsson, A.G. ”Användbar forskning inom informatik <strong>–</strong> perspektiv<br />
och spetsområden”, i Om metoder för systemutveckling i professionella<br />
organisationer <strong>–</strong> Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson<br />
och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 7-30.<br />
Iivari, J., and Lyytinen, K. ”Research on Information Systems Development in<br />
Scandinavia <strong>–</strong> Unity in Plurality”, Scandinavian Journal of Information Systems (10:<br />
1&2), 1998, pp. 135-186.<br />
Jayaratna, N. Understanding and Evaluating Methodologies <strong>–</strong> A Systemic<br />
Framework, McGraw-Hill, London, 1994.<br />
Kalderén, H. Affärssystem, Ekerlids Förlag, Stockholm, 1995.<br />
Langefors, B. Essays on Infology <strong>–</strong> Summing Up and Planning for the Future,<br />
Studentlitteratur, Lund, 1995.<br />
Lie-Nielsen, S., och Colliander, L. Principer för en ny generation systemutvecklingsverktyg,<br />
Rapport 16, Dataföreningen i Sverige (f.d. Riksdataförbundet), Stockholm,<br />
1983.<br />
Lindström, C.-G. ”Lessons Learned from Applying Business Modelling <strong>–</strong> Exploring<br />
Opportunities and Avoiding Pitfalls”, in Perspectives on Business Modelling <strong>–</strong><br />
21
Understanding and Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn<br />
(eds.), Springer, Berlin, 1999, pp. 151-164.<br />
Ljungberg, J., and Kinnula, T. ”Metamodellering ny tvärvetenskap”, Datorpulsen,<br />
våren 1993, Studentförlaget, 1993, s. 52-54.<br />
Lundeberg, M. ”Nivå-synsättet <strong>–</strong> en första introduktion”, i Att Föra Verksamheten<br />
Framåt <strong>–</strong> Människor och informationssystem i samverkan, M. Lundeberg och B.<br />
Sundgren (red.), Studentlitteratur, Lund, 1996, s. 9-32.<br />
Lundeberg, M., Goldkuhl, G., och Nilsson, A.G. Systemering, Studentlitteratur, Lund,<br />
1978.<br />
Magnusson, Å., och Wahlgren, H. Utveckling av ekonomistyrsystem enligt RP,<br />
utgåva 3, Industrilitteratur, Stockholm, 1995.<br />
Mattsson, L.-G. ” ’Relationship Marketing’ and the ’Market-as-Networks Approach’<br />
<strong>–</strong> A Comparative Analysis of Two Evolving Streams of Research”, Journal of<br />
Marketing Management (13), 1997, pp. 447-461.<br />
Mintzberg, H., and Quinn, J.B. The Strategy Process <strong>–</strong> Concepts and Contexts,<br />
Prentice-Hall, Englewood Cliffs, New Jersey, 1992.<br />
Moberg, B., Nilsson, A.G., och Tägtström, I. Välj rätt programvara <strong>–</strong> En skrift om hur<br />
man stärker företagets affärsverksamhet genom att välja rätt programvara, STUrapport<br />
nr. 780-1990, Nutek (f.d. STU), Stockholm, 1991.<br />
Molin, L. ”Vad kan systemutvecklare och multimediautvecklare lära sig av varandra <strong>–</strong><br />
planera eller parera?”, i Om metoder för systemutveckling i professionella<br />
organisationer <strong>–</strong> Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson<br />
och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 161-181.<br />
Nellborn, C. ”Business and Systems Development <strong>–</strong> Opportunities for an Integrated<br />
Way-of-Working”, in Perspectives on Business Modelling <strong>–</strong> Understanding and<br />
Changing Organisations”, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer,<br />
Berlin, 1999, pp. 197-213.<br />
Nilsson, A.G. ”Systemering <strong>–</strong> En referensram”, Nordisk Datanytt (17:4), 1987, s. 46-<br />
50.<br />
Nilsson, A.G. ”Information Systems Development <strong>–</strong> A Frame of Reference and<br />
Classifications”, in CASE89 <strong>–</strong> The first Nordic Conference on Advanced Systems<br />
Engineering, SISU & SSI, Kista, Stockholm, 1989.<br />
Nilsson, A.G. Anskaffning av standardsystem för att utveckla verksamheter <strong>–</strong><br />
Utveckling och prövning av SIV-metoden, Doktorsavhandling, Sektionen för<br />
Information Management, EFI, Handelshögskolan i Stockholm, 1991.<br />
Nilsson, A.G. ”Business Modelling as a Base for Information Systems Development”,<br />
in Proceedings of The Third International Conference on Informations Systems<br />
22
Developers Workbench, S. Wrycza (ed.), University of Gdansk, Poland, 1992, pp.<br />
77-88.<br />
Nilsson, A.G. Utveckling av metoder för systemarbete <strong>–</strong> ett historiskt perspektiv,<br />
Research report LiTH-IDA-R-95-13, Forskningsgrupp VITS, Institutionen för<br />
datavetenskap (IDA), Linköpings universitet, 1995.<br />
Nilsson, A.G. ”The Business Developer’s Toolbox: Chains and Alliances between<br />
Established Methods”, in Perspectives on Business Modelling <strong>–</strong> Understanding and<br />
Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer,<br />
Berlin, 1999, pp. 217-241.<br />
Nilsson, A.G. ”Användning av standardsystem i organisationer <strong>–</strong> kritiska framgångsfaktorer”,<br />
i Om metoder för systemutveckling i professionella organisationer <strong>–</strong><br />
Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson och J.S.<br />
Pettersson (red.), Studentlitteratur, Lund, 2000, s. 204-225.<br />
Nilsson, A.G., och Pettersson, J.S. (red.) Om metoder för systemutveckling i<br />
professionella organisationer <strong>–</strong> Karlstadskolans syn på informatikens roll i samhället,<br />
Studentlitteratur, Lund, 2000.<br />
Nilsson, A.G., Tolis, C., and Nellborn, C. (eds.) Perspectives on Business Modelling<br />
<strong>–</strong> Understanding and Changing Organisations, Springer, Berlin, 1999.<br />
Nilsson, B.E. ”On Why to Model What and How: Concepts and Architecture for<br />
Change”, in Perspectives on Business Modelling <strong>–</strong> Understanding and Changing<br />
Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, Berlin, 1999,<br />
pp. 269-303.<br />
Nissen, H.-E., och Andersen, E.S. Systemering <strong>–</strong> Verksamhetsbeskrivning, Studentlitteratur,<br />
Lund, 1977.<br />
Norell, M. Stödmetoder och samverkan i produktutveckling, Doktorsavhandling,<br />
Rapport TRITA-MAE 1992:7, Institutionen för Makinelement, Kungliga Tekniska<br />
<strong>Högskolan</strong> (KTH), Stockholm, 1992.<br />
Nurminen, M.I. People or Computers: Three Ways of Looking at Information<br />
Systems, Studentlitteratur, Lund, 1988.<br />
Olhager, J., och Rapp, B. Effektiv MPS <strong>–</strong> Referenssystem för datorbaserad material-<br />
och produktionsstyrning, Studentlitteratur, Lund, 1985.<br />
Olle, T.W., Hagelstein, J., Macdonald, I.G., Rolland, C., Sol, H.G., Van Assche,<br />
F.J.M., and Verrijn-Stuart, A.A., Information Systems Methodologies <strong>–</strong> A Framework<br />
for Understanding, 2 nd ed., Addison-Wesley, Wokingham, England, 1991.<br />
Rantzer, M. Programvarusystem: Prototyping <strong>–</strong> ökad träffsäkerhet vid systemutveckling,<br />
Rapport nr. 3, Informationsteknologi, Sveriges Verkstadsindustrier (VI),<br />
Stockholm, 1994.<br />
23
Rapp, B. ”Principal-Agent and Transaction Cost Theories in Business Modelling”, in<br />
Perspectives on Business Modelling <strong>–</strong> Understanding and Changing Organisations,<br />
A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, Berlin, 1999, pp. 181-196.<br />
Ryan, K., Kronlof, K., and Sheehan, A. ”Method Integration”, in Lessons Learned<br />
from the Use of Methodologies, Proceedings of the Fourth Conference of the Brittish<br />
Computer Society (BCS), N. Jayaratna and B. Fitzgerald (eds)., University of College<br />
Cork, Cork, Ireland, 1996, pp. 235-246.<br />
Röstlinger, A, och Goldkuhl, G. Generisk Flexibilitet <strong>–</strong> På väg mot en<br />
komponentbaserad metodsyn, Research Report LiTH-IDA-R-96-15, Forskningsgrupp<br />
VITS, Institutionen för datavetenskap (IDA), Linköpings universitet, 1996.<br />
Samuelson, L. Models of Accounting Information Systems <strong>–</strong> The Swedish Case,<br />
Studentlitteratur, Lund, 1990.<br />
Samuelsson, K. ”Kemiinformatik som flervetenskap <strong>–</strong> att utnyttja standardiserade<br />
system för nomenklatur”, i Om metoder för systemutveckling i professionella<br />
organisationer <strong>–</strong> Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson<br />
och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 244-257.<br />
Seigerroth, U. Integration av förändringsmetoder <strong>–</strong> en modell för välgrundad<br />
metodintegration, Licentiatavhandling, Informationssystemutveckling, Institutionen<br />
för datavetenskap (IDA), Filosofisk Fakultet, Linköpings universitet, 1998.<br />
SIS. Referensmodell för systemutveckling, Teknisk rapport SIS TR 321,<br />
Standardiseringskommissionen i Sverige (SIS), Stockholm, 1989.<br />
Sowa, J.F., and Zachman, J.A. ”Extending and Formalizing the Framework for<br />
Information Systems Architecture”, IBM Systems Journal (31:3), 1992, pp. 590-616.<br />
Steneskog, G. ”Business Process Models Revised <strong>–</strong> Challenging the Physical<br />
Metaphor”, in Perspectives on Business Modelling <strong>–</strong> Understanding and Changing<br />
Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, Berlin, 1999,<br />
pp. 165-179.<br />
Stymne, B., Belotti, C., Eriksson, M., Nilsson, A.G., Rapp, B., Stjernberg, T., och<br />
Tunälv, C. Det konkurrenskraftiga småföretaget <strong>–</strong> en guide för affärsutveckling med<br />
IT-stöd, Studentlitteratur, Lund, 2000 (under utgivning).<br />
Sundgren, B. Databasorienterad systemutveckling <strong>–</strong> Grundläggande begrepp,<br />
Datamodellering, Systemkonstruktion, Studentlitteratur, Lund, 1992.<br />
Sundgren, B. ”Business Modelling in a Historical Perspective: Experiences from<br />
Statistics Sweden”, in Perspectives on Business Modelling <strong>–</strong> Understanding and<br />
Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer,<br />
Berlin, 1999, pp. 93-115.<br />
Söderlund, E., and Persson, A. Transitioning Between Modelling Techniques: An<br />
Experience Report, Department of Computer Science, University of <strong>Skövde</strong>, 2000.<br />
24
Targama, A. Former för Administrativt Utvecklingsarbete, Doktorsavhandling, BAS<br />
och Företagsekonomiska Institutionen, Göteborgs universitet, 1978.<br />
Tolis, C. ”Facilitating Understanding and Change <strong>–</strong> The Role of Business Models in<br />
Development Work”, in Perspectives on Business Modelling <strong>–</strong> Understanding and<br />
Changing Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer,<br />
Berlin, 1999, pp. 133-150.<br />
Tolis, C., och Nilsson, A.G. ”Business Models and IS/IT in Process Orientation”, in<br />
Innovating SME Business Practices <strong>–</strong> The Compete Methodology and Tools, P.<br />
Fariselli (ed.), Nomisma, edizioni Pendragon, Bologna, Italy, 1998, pp. 27-48.<br />
Tolvanen, J.P., and Lyytinen, K. ”Flexible Method Adaptation in CASE<br />
Environments <strong>–</strong> The Metamodelling Approach”, Scandinavian Journal of Information<br />
Systems (1:5), 1993, pp. 51-77.<br />
Ulfhake, L. ”Systemutvecklingsmodell för framställning av pedagogiska programvaror<br />
<strong>–</strong> multimedia till nytta och nöje”, i Om metoder för systemutveckling i<br />
professionella organisationer <strong>–</strong> Karlstadskolans syn på informatikens roll i samhället,<br />
A.G. Nilsson och J.S. Pettersson (red.), Studentlitteratur, Lund, 2000, s. 138-160.<br />
Venkatraman, N. ”IT-Enabled Business Transformation <strong>–</strong> From Automation to<br />
Business Scope reddefinition”, Sloan Management Review, Winter, 1994, pp. 73-87.<br />
Werr, A. The Language of Change <strong>–</strong> The roles of methods in the work of<br />
management consultants, Doktorsavhandling, PMO sektionen, EFI, Handelshögskolan<br />
i Stockholm, 1999.<br />
Werr, A., Stjernberg, T., och Docherty, P. ”Att förändra strukturer <strong>–</strong> en översikt och<br />
jämförelse”, i Människan och strukturerna <strong>–</strong> Organisationsteori för förändring, J.<br />
Löwstedt (red.), Nerenius & Santérus Förlag, Stockholm, 1995, s. 153-175.<br />
Willars, H. ”Business Modeller’s Checklist <strong>–</strong> ”Dos” and ”Dont’s” in Hands-on-<br />
Practice”, in Perspectives on Business Modelling <strong>–</strong> Understanding and Changing<br />
Organisations, A.G. Nilsson, C. Tolis and C. Nellborn (eds.), Springer, Berlin, 1999,<br />
pp. 305-323.<br />
Yi, C.-h. ”Informella och formella metoder för systemutveckling <strong>–</strong> med fokus på<br />
UML”, i Om metoder för systemutveckling i professionella organisationer <strong>–</strong><br />
Karlstadskolans syn på informatikens roll i samhället, A.G. Nilsson och J.S.<br />
Pettersson (red.), Studentlitteratur, Lund, 2000, s. 301-318.<br />
Österlee, H. Business in the Information Age <strong>–</strong> Heading for New Processes, Springer,<br />
Berlin, 1995.<br />
25