Detta kapitel innefattar analys och diskussion utifrån teoriområdet i kapitel 2 och resultatet i kapitel 4.
5.1 TakeCare anses inte vara tillräckligt kompatibelt med andra system
Respondent 4, 5 och 6 upplever att journalsystemet överlag fungerar i det dagliga arbetet.
Detta innebär enligt Ullman (2014) att endast användarnas basbehov är uppfyllda, vilket gör att funktionaliteten med systemet uppfylls men att nöjdheten hos användarna är relativt låg.
Detta kan vi se stämmer i och med att respondenterna uttryckte behov som inte uppfylls i systemen men som skulle göra dem mer tillfredsställda, vilket vi tolkar tillhör kategorin uttalade behov enligt Ullmans definition.
Ett uttalade behov som uttrycktes av både Respondent 4, 5 och 6 och som ej är uppfyllt i journalsystemet är kopplat till dess kompatibilitet med andra system inom sjukvården. Även Respondent 3 poängterar att kompatibiliteten är betydelsefull i det vardagliga arbetet. Ett annat exempel på ett uttalat behov hos dessa fyra respondenter är att Region Stockholm, allra helst hela Sverige, ska ha samma journalsystem. Detta påpekar både Respondent 4, 5 och 6 som ett problem kopplat till patientsäkerhet på grund av risken att viktig information om en patient missas eller inte finns tillgänglig för alla. I och med detta kan vi se att
patientsäkerheten har en stark koppling till bristande kompatibilitet och avsaknaden av ett enhetligt journalsystem i landet. Eftersom dessa brister inte endast orsakar problem för användarna själva utan även har en negativ inverkan på patienterna så ser vi att detta bör ses som en prioriterad funktion vid utveckling.
I Kano-modellen finns även så kallade outtalade behov vilket är behov som användaren själv inte kan beskriva (Ullman, 2014). Dessa har vi i studien inte kunnat identifiera hos
sjukvårdspersonalen, vilket kan ha sin förklaring i att studien inte har som fokus att ta reda på de outtalade behoven. Då sjukvårdspersonalens basbehov gällande produktfunktion är
uppfyllda men att det uttalade behovet gällande förbättrad kompatibilitet inte uppfylls, innebär enligt Ullman (2014) att kundnöjdheten inte blir lika hög.
5.2 CGM och Acceptus arbetar med användarinvolvering på olika sätt
Mumford (1995) beskriver konsultativ involvering som när användarna ger feedback på alternativ under produktutvecklingsprocessen och klassas som en medel grad av involvering.
Enligt Respondent 1 och 2 så använder sig båda företagen av detta i och med att de tar in åsikter från slutanvändarna. Genom informativ involvering, som har en låg grad av
involvering och inflytande, så sker en dialog mellan slutanvändare och utvecklare (Mumford, 1995), vilket Acceptus använder sig av i början av processen.
21
Abras et al. (2004) hävdar att en sådan här insamling av användardata är ett sätt att ta reda på användarnas behov, vilket Respondent 2 bekräftar genom att detta görs för att ta reda på hur användarna arbetar och att det är nödvändigt för att kunna anpassa journalsystemet till dem.
Mumford (1995) beskriver en medverkande metod av involvering med hög påverkan och involvering av användarna, vilket CGM använder sig av i och med användargrupperna. CGM och Acceptus arbetar på olika sätt med TakeCare vilket vi kan se vara en förklaring till varför metoderna samt graden av användarinvolvering skiljer sig åt mellan de två företagen. Då CGM är utvecklarna till systemet så kan vi se att de har ett behov av att involvera användarna i högre grad än vad Acceptus har som enbart förvaltar och inför systemet hos verksamheter.
En annan intressant aspekt är att användargrupperna som CGM använder sig av består av ganska få användare, vilket kan vara en bidragande orsak till att behoven inte identifieras korrekt. En användare från en vårdenhet kanske har helt andra behov än användare som arbetar på andra ställen.
Enligt Al-Rahman et al. (2012) kräver det mycket tid, är dyrt och ansträngande för
användarna att involveras i processen. Detta beskriver även Respondent 2 genom att Acceptus kunder till majoritet består av mindre privata vårdgivare som inte alltid har resurser att lägga på ytterligare deltagande av utvecklingen. I och med detta kan vi se att det faktiskt kan finnas ett behov hos Acceptus kunder att involveras mer i processen för att på så sätt få fler behov tillgodosedda.
5.3 Agila och integrerade processer innebär bättre användarinvolvering
Enligt Tonnquist (2018) och Azanha (2016) är agila arbetsmetoder dominerande inom mjukvaruprojekt och ett effektivt tillvägagångssätt vid föränderliga omständigheter. Detta stärks Respondent 1 som berättar att CGM arbetar agilt under utvecklingsprocessen där det ofta dyker upp nya krav och behov under processens gång som utvecklarna måste ta hänsyn till.
De olika utvecklingsteamen på CGM arbetar integrerat och parallellt med TakeCare under processen för att ta fram lösningar och kravspecifikationer utifrån önskemål. Enligt O’Connor (2003) ökar ett integrerat arbetssätt möjligheten till positiva resultat och Tonnquist (2018) hävdar att arbetssättet gör att problem kan upptäckas i god tid. Detta beskriver även
Respondent 1 i och med att utvecklarna via regelbundna sprintdemos uppdaterar varandra om processen och hur de gemensamt kan lösa problem som dyker upp. Säljarna på CGM har regelbunden kontakt med kunden Region Stockholm för att löpande uppdatera under utvecklingsprocessen och genomföra delleveranser. Tonnquist (2018) och Azanha (2016) menar att dessa typer av kontinuerliga feedbackloopar mot användare och täta leveranser är centralt för att upptäcka förändringar i tid.
Samtidigt säger Respondent 1 att ett återkommande problem har varit att de sent i processen upptäcker att fokus inte ligger på rätt behov, vilket vi kan tolka som att utvecklingsprocessen
22
någonstans brister. En möjlig orsak kan vara att säljarnas täta kontakt sker med kunden Region Stockholm och inte specifikt mot slutanvändarna, vilket kan innebära att utvecklingsteamen i första hand utvecklar utifrån vad Regionen vill ha och inte
slutanvändarna själva. Detta resonemang förstärks även genom att Respondent 1 förklarar att de behov som uttrycks av Region Stockholm inte alltid stämmer överens med vad som egentligen behövs och att detta är upp till utvecklarna att reda på. Ullman (2014) beskriver detta som ett outtalat behov genom Kano-modellen och att det är dessa behov som gör användarna som mest tillfredsställda om de uppfylls.
En annan möjlig orsak till att CGM haft återkommande problem med att fel behov identifierats går att beskriva enligt Design-paradoxen som visar att designfriheten är som störst i början av processen, men att förståelsen för produkten som ska utvecklas här är lägre (Ullman, 2014). Detta ser vi kan vara en förklaring till varför behov som utvecklarna
identifierar hos kunden och användarna tidigt i processen senare har visat sig inte stämma överens med vad som egentligen behövs, i och med att utvecklarna får mer kunskap om problemet ju längre processen fortskrider.
5.4 Användarbehov prioriteras olika vid utvecklingen
Abras et al. (2004) beskriver det inte som nödvändigt att få med alla intressenter i
utvecklingsprocessen, men att det är viktigt att känna till vilka de är och hur produkten kan komma att påverka dem. Respondent 1 förklarar dock att utvecklarna strävar efter att få in användare från olika professioner på sjukhus och förvaltning i användargrupperna för att på så sätt kunna få en bred representation av användarnas behov och sedan använda det för att ta fram en efterfrågad produkt. Samtidigt säger Respondent 1 att en utveckling av systemet inte genomförs om inte alla användare och intressenter blir positivt påverkade. CGM har många intressenter och typer av användare vid utveckling av journalsystemet och Respondent 1 menar att detta innebär att alla behov och önskemål inte kan tillgodoses utan måste prioriteras.
Faktumet att CGM endast gör förändringar i TakeCare om alla användare påverkas positivt kan innebära en fördel i och med att alla på något vis kommer gynnas av utvecklingen.
Däremot ser vi att detta kan vara ett hinder för utvecklingen av systemet, eftersom
förbättringar kan utebli på grund av att till exempel en specifik avdelning eller profession blir negativt påverkade. Respondent 1 beskriver även att konsekvenserna blir väldigt stora om en felaktig prioritering görs, vilket vi kan se riskerar leda till ett sämre resultat genom att de viktigaste behoven inte tillgodoses eller att en funktion i TakeCare till och med kan försämras.
23
5.5 Typ av utvecklingsprojekt avgör mängd och metod för användarinvolvering
Respondent 1 poängterar att en löpande kontakt med kunden är prioriterat och att
användargrupper används för att aktivt identifiera användarnas behov och utifrån det iterativt utveckla lösningar. Detta är enligt Gulliksen och Göransson (2002) samt Maguire (2001) centrala aspekter inom användarcentrerad design för att skapa en tydlig förståelse för
användarens krav och behov. Däremot på vilket sätt och hur hög grad användarna involveras vid utvecklingen varierar beroende på typ av projekt samt utvecklingens omfattning och längd. Användarinvolveringen var liten eller helt obefintlig i korta projekt samt i projekt med fokus på back-end utveckling. Däremot i projekt fokuserade på front-end utveckling är det vanligare att användarna involveras under hela processen, där användarinvolveringen i form av fokusgrupper och tester sker både tidigt och löpande i processen, innefattandes
diskussioner om problem och krav men även användartester. Detta är inte enligt Abras et al.
(2004) som menar att tester endast ska göras tidigt eller i slutet och fokusgrupper endast i början, vilket vi inte ser vore gynnsamt vid utvecklingen av TakeCare eftersom utvecklarna löpande gör iterationer som de presenterar för användargruppen med syftet att förbättra systemet.
Användarinvolvering vid mjukvaruutveckling beskrivs enligt Al-Rahman et al. (2012) som central för användarnas nöjdhet. Det går att se en brist av involvering applicerat på back-end utvecklingen i och med att behov kanske inte fångas upp på grund av låg eller obefintlig användarinvolvering. Detta förstärks av Respondent 3, 4, 5 och 6 som alla har uttryckt behov gällande utökad kompatibilitet mellan andra system, vilket är kopplat till back-end
avdelningens arbete, men inte är uppfyllt i tillräckligt hög grad. Vid front-end utveckling verkar utvecklarna lyckats bra med användarinvolvering, eftersom samma fyra respondenter anser att systemet är användarvänligt. Detta tolkar vi som att respondenterna är nöjda med systemets gränssnitt. I och med detta kan vi se ett behov av att CGM bör använda mer resurser på användarinvolvering vid back-end projekt så att systemet kan utvecklas med fler funktioner som efterfrågas av användarna, såsom kompatibiliteten.
5.6 Det finns återkommande problem med användarinvolvering
Även om Respondent 1 beskriver många fördelar som användarinvolvering för med sig, så betonas även risker ur tre perspektiv: om inte rätt användare är involverade från start, om användare byts ut eller om involveringen blir för hög. Att fel behov identifieras är ett återkommande problem hos CGM vilket de förklarar har sin grund i att de från start inte lyckats få tag på tillräckligt bra spridning av deltagare från relevanta professioner samt att användare ibland byts ut under processens gång. Att involvera användare är tidskrävande enligt Al-Rahman et al. (2012) vilken också beskrivs av Respondent 1 som säger att anledningen till att spridning av deltagare saknas, byts ut och rätt användare inte är medverkande, är en konsekvens av att sjukvårdspersonalen har svårt att komma ifrån sitt
24
dagliga arbete. Detta problem påpekas även av Respondent 4 som ser svårigheter för sjukvårdspersonalen att få tid till att engagera sig i utveckling av TakeCare. Eftersom det återges av flera respondenter så tolkar vi det som att slutanvändarnas brist på tid att engagera sig är en faktor till att användarinvolveringen inte sker på det sätt som CGM skulle önska.
Al-Rahman et al. (2012) och Ullman (2014) beskriver att det finns en stor riskfaktor i att inte involvera användarna tillräckligt, eftersom det kan leda till att viktiga krav inte integreras.
Samtidigt säger Respondent 1 att det finns en risk med att involvera användarna i för hög grad eftersom det kan försvåra utvecklingsprocessen och resultera i en spretig process. Delvis på grund av att användarna funderar mycket på egen hand och därmed kan uttrycka nya behov dag till dag samt att för många åsikter från olika användare kan göra det svårt att fokusera utvecklingen. Utifrån detta kan vi tolka att användarinvolvering är viktigt för att identifiera rätt behov men att det även kan få motsatt effekt om det görs i för hög grad.
5.7 Det finns faktorer som hindrar genomförandet av användarinvolvering
Det finns faktorer som försvårar möjligheten för utvecklarna på CGM och förvaltarna på Acceptus att involvera och tillgodose användarnas behov. Respondent 2 beskrev att TakeCare är ett gammalt system vilket försvårar möjligheten att göra stora förändringar och anpassa systemet utifrån användarbehov utan att det krävs mycket resurser för att förändra. Att systemet i TakeCare är gammaldags är något som även Respondent 3 bekräftar och att det är en förklaring till varför det inte uppfyller de behov som användarna har i dagsläget. I och med detta kan vi se svårigheter att via systemet som det ser ut idag kunna uppnå de behov som användarna har. Därför ser vi att en möjlig lösning är att utveckla ett nytt journalsystem från grunden i och med Framtidens vårdinformationssystem.
En annan aspekt som kan innebära svårigheter för utveckling och användarinvolvering är den pågående upphandlingen av ett nytt journalsystem vilket bekräftas av respondenterna med avseende på risken med att användare inte ser någon mening med att uttrycka sina behov angående ett journalsystem som kanske inom en snar framtid inte finns kvar. Respondent 3 såg även att detta kan gälla med avseende på utvecklarna, vilket vi kan se som ett möjligt problem för att genomföra större förbättringar i systemet innan upphandlingen av ett nytt journalsystem är genomförd. En konsekvens av detta är att användarnas behov som är av mer omfattande karaktär förmodligen inte kommer kunna ske inom en nära framtid.
Respondent 4, 5 och 6 säger att de inte har blivit tillfrågade om vilka behov de har gällande journalsystemet och Respondent 3 påpekar att det finns svårigheter för sjukvårdspersonalen att få igenom förslag gällande större förändringar på TakeCare. Alla sex respondenter är eniga om att det finns möjlighet för sjukvårdspersonalen att komma med feedback och önskemål.
Däremot är de osäkra på om systemet skulle utvecklas genom de behov som uttrycks i och med att det saknas en tydlig struktur för att den feedback som ges till IT-avdelning eller närmaste ansvarig förs vidare till förvaltare eller utvecklare. Detta förstärks av Respondent 3
25
som beskrev det som oerhört viktigt att kommunikationen mellan sjukvårdspersonalen och TakeCare-förvaltningen fungerar men att det finns brister som kan ha en negativ inverkan.
Detta betonas även av Westerlund (2009) som uttrycker vikten av att ha en tydlig struktur och förståelse för hur användaren involveras i utvecklingsprocesser. Både Respondent 4 och 5 tror att det är bra att involvera användarna mer i utvecklingen och att det kan resultera i bättre journalsystem. Att det inte finns en tydlig struktur och att kommunikationen verkar brista ser vi som en möjlig orsak till att ingen av respondenterna känner sig involverade vid
utvecklingen av TakeCare samt att viktiga användarbehov inte uppfylls.
Respondent 3 hävdar att CGM med stor sannolikhet känner till att användarna har
återkommande behov att göra TakeCare mer kompatibelt med andra system, samtidigt som CGM hävdar att de inte har identifierat något särskilt behov som har återkommit från
användarna. Respondent 1 ser även en risk med att behov kan falla bort längs vägen eftersom utvecklarna är sist i kedjan, vilket vi kan se resultera i att användarnas önskemål inte når fram.
Då krav inte integreras på grund av bristen på förståelse av behovet så leder detta till en misslyckad produkt som användarna inte är tillfredsställda med (Al-Rahman et
al., 2012; Ullman, 2014). Faktumet att respondenterna inte har samma uppfattning angående återkommande behov och att behoven kan falla bort längs vägen kan vi se vara ett
betydelsefullt hinder för utveckling av systemet.
Om det finns en struktur i den konsultativa involveringen när sjukvårdspersonalen förmedlar feedback och önskemål så ser vi att utvecklarna kan få en större uppfattning om behov. Detta i form av kvantitativ involvering där en större andel användare kan vara delaktiga som kan vara ett bra komplement till de kvalitativa användargrupper som CGM använder sig av. Enligt Abras et al (2004) så kan även kvantitativ data fås genom tester, vilket inte görs vid
utveckling av TakeCare idag enligt respondenten. Detta ser vi kan resultera i att utvecklarna får en överblicksbild över användarnas behov och kan få in dessa från ett större antal
användare. Vi ser även en positiv aspekt i att kombinera kvantitativa tester med kvalitativa för att på så vis få en djupare förståelse för de identifierade behoven.
26