Vad kunde ha gjorts annorlunda? Varför blev resultatet som det blev? I följande kapitel diskuteras både resultat och utförande av studien. I denna del passar jag även på att presentera mina egna åsikter på vissa punkter.
6.1 Förarbete inför att utveckla ett nytt system
Enligt Eriksson (2007) beror mer än hälften av alla misslyckade IT-system på att kravinsamlingen varit bristfällig. Beställaren och kravinsamlaren har samlat krav och förhört sig med fel personer och vissa kravområden glöms helt och hållet bort. I den fas då beställaren till ITIS förmedlade vad det var han var ute efter hade han endast ett krav: att få bättre kontroll över den IT-utrustning som finns i företaget. Genom en verklighetsbeskrivning av företagets struktur, inköpsprocess av IT- utrustning, nyanställnings- och anställningsavslutsprocess lyckades vi få IT- och personalansvarige att hitta ett antal nya, lite mer detaljerade krav som de tidigare inte insett. Verklighetsbeskrivningen gjordes med hjälp av endast två personer, IT- och personalansvarig. För att hamna så nära
verkligheten som möjligt borde åtminstone ytterligare en person till per respektive process ha intervjuats. När endast en persons version av verkligheten behandlas är det större risk att denna hamnar längre ifrån den verkliga situationen (Eriksson, 2007).
Kraven som upptäcktes i samband med verklighetsbeskrivningen hade förmodligen inte upptäckts om inte de processer som sker vid anställningar och IT-inköp noggrant hade gåtts igenom,
tillsammans med IT- och personalansvarig. Samtidigt hade inte vi själva kunnat upptäcka dessa krav på egen hand. Redan här förändrades alltså beställarens krav. Projektet gick sedan vidare genom två workshops med IT-ansvarige respektive personalansvarige. I denna workshop fick de båda göra en beskrivning av hur systemet skulle se ut i en drömvärld. Både orealistiska och realistiska krav fick tas upp. I denna fas dök det upp ett antal krav som inte heller tidigare varit påtänkta. Genom att ge beställaren nya synvinklar på systemet och användandet kan de själva upptäcka krav som de från början inte varit medvetna om.
Processbeskrivningen hade beställaren om denne haft tid och kunskap kunnat göra på egen hand. Anledningen till att kraven vid beställningen ofta är otillräckliga för att utveckla ett lyckat IT- system verkar bero på en underskattning av det förarbete som ofta krävs inför inköp av ett nytt system. Det är en tidskrävande process men lönar sig förmodligen i längden precis som Andersen
(1994) menar, eftersom fel som måste åtgärdas kostar mer ju längre fram i utvecklandet man kommit.
6.1.1 Krav på användbarhet
Kraven på användbarhet är ofta svåra att formulera och blir inte sällan bättre formulerade än: ”Systemet ska vara lättanvänt”. Huruvida systemet får god användbarhet eller inte är i sådana fall helt och hållet upp till systemutvecklarens känsla. I denna studie upptäcktes att användarna förväntar sig att systemen ska bete sig som de system de redan arbetar med precis som Molich (2000) beskriver i sin studie på användbarhet för webben. Ett sätt att ställa mer konkreta krav på användbarheten är då att peka på system som man vill efterlikna vad gäller till exempel navigation, layout, kortkommandon med mera. Eriksson (2007) påpekar att det i kravspecifikationen inte ska finnas några lösningar på problem utan bara krav på vad som ska lösas eller uppfyllas. Både som kravinsamlare och som beställare upptäcktes flera fall där kraven egentligen var färdiga lösningar och därför fick problemet inte några alternativa förslag. Andersen (1994) menar att om lösningarna finns presenterade i kravspecifikationen får inte systemutvecklarna chans att lösa problemen utifrån sina kunskaper och färdigheter, det vill säga, de blir begränsade i utvecklandet.
Anledningen till att det är svårt att ställa ickefunktionella krav kan ha att göra med att man inte vet vilka krav som är rimliga att ställa. Beställaren vet till exempel inte vad som är rimligt vad gäller uppstartningstid för systemet eller hur snabbt det ska gå att genomföra en sökning. Dessa krav är lättare att ställa efter att man har testat systemet i form av till exempel en prototyp.
Prototyputveckling fungerade alltså i denna studie som metod för att ställa konkreta krav på just användbarhet och andra svårdefinierade områden. Eriksson (2007) menar att det inte går att samla in alla krav på en gång och detta styrks i denna studie då endast en bråkdel av kraven samlades in innan prototyputvecklandet påbörjades och dessa var huvudsakligen av funktionell karaktär. Ett sätt att ställa krav på användbarheten är att kräva en användarcentrerad utvecklingsprocess. Detta blir alltså inte ett krav på systemet i sig men tvingar åtminstone utvecklarna att sätta slutanvändarna i fokus under utvecklingsprocessen vilket i sin tur bör leda till ett användbart system.
6.2 Användbart eller många funktioner
Någonstans så måste antal funktioner i systemet möta användbarheten. Det går inte att ha oändligt med funktioner och samtidigt ha ett lättanvänt system som alla kan förstå. För att konkretisera
ytterligare krav på användbarhet kan det ifrågasättas huruvida man har möjlighet att utbilda och informera nya slutanvändare. Är det endast en slutanvändare har man kanske råd att genomföra en längre utbildning och det finns möjlighet att bygga ett mer komplext och avancerat system. Är däremot systemet riktat mot konsumenter på internet finns det ingen möjlighet överhuvudtaget att utbilda slutanvändarna och systemet måste därför fungera så pass enkelt att man förstår det på egen hand.
6.3 Vilket system lämpar sig för JMS?
Genom att göra det slutliga användartestet på personer med olika befattningar i verksamheten upptäckte vi att de hade olika synsätt på om de upplevde att de hade för många system eller inte. Ekonomi-, personal- och lönemedarbetarna satt med 2-3 system vardera och utförde samma uppgifter varje dag medan de två IT-medarbetarna i sin tur använde samtliga system i företaget, vilket var 7-8 stycken. Så länge IT-medarbetarna har kontroll över de system som finns är det lättast om man använder de flera avskalade systemen som är speciellt lämpade för sin sak istället för att försöka sträva efter att ha så få system som möjligt med samtliga funktioner samlade på ett och samma ställe. Det hade kanske hjälpt IT-medarbetarna men försvårat för övriga personer som arbetar med någon form av informationssystem, detta visade sig inte minst i det slutliga
användartestet där samtliga personer hade svårt för att hantera Intranätet Microsoft Share Point som är av den typ av system som är fyllt till bredden av funktioner för att det ska passa till många typer av verksamheter.
Ett av problemen som IT-ansvarig upplever hos JMS idag är att man har för många separata system som inte samverkar. Att investera i utvecklandet av ITIS till ett fungerande system kanske löser problemet med att på ett enkelt sätt få kontroll över IT-utrustningen men kan orsaka problem på andra områden, till exempel måste personalansvarig göra ändringar i ytterligare ett system varje gång någon i personalen nyanställs, slutar eller förflyttas. Att försöka utnyttja de system som redan finns i företaget och bli bra på dessa ger IT-medarbetarna kontroll över utrustningen och mer lätthanterlig situation vad avser antal system att sköta. Även om Microsoft Share Point fick sämst resultat i undersökningen så är det ett system som har stor potential på grund av sin dynamik att anpassas efter sitt användningsområde. Genom att se över Microsoft Share Point, som idag upplevs som rörigt av de personer som medverkat i användartesten, kan många av dess funktioner och information rensas upp och struktureras om för att göra det lättare att använda. Detta medför att, som Sundström (2005) hävdar, användaren snabbare hittar de funktioner och den information som denne söker.
Att använda Hogia PA som IT-inventariesystem hade inte fungerat lika bra som ITIS och Microsoft Share Point då det saknar funktioner för att tillgodose många av de krav som arbetats fram under projektets gång. Det har god användbarhet men är inte lämpat för inventarier utan för
personalhantering, vilket det fungerar alldeles utmärkt för.
IT-ansvarig upplevde att ITIS var bäst lämpat för uppgifterna i testet. Detta kan bero på dels som Barki & Hartwick (1994) menar att personer som aktivt deltar i utvecklandet av systemet utvecklar känslor i form av ägandeskap och tillfredställelse samt att förståelsen för hur systemet ökar eller på grund av som Dickstein & Mills (2000) menar att systemet utvecklats efter slutanvändarens medvetna och omedvetna krav och därför passar denna person bäst. En kombination av de båda teorierna är enligt mig mest sannolik. ITIS utvecklades efter de krav som successivt upptäcktes och är därför väl anpassat för sitt ändamål men IT-ansvarigs känslor för systemet stärktes genom att han har varit med i utvecklandet och kände därför en viss delaktighet och ägandeskap i ITIS. För att genomföra en förändring eller implementering av ett nytt system är det enligt båda teorierna fördelaktigt att involvera slutanvändarna i så stor grad som möjligt.