Utveckling av GUI utifrån en given affärsprocess

(1)

Utveckling av GUI utifrån en given affärsprocess

JOHN-BERNHARD STOOR

K TH K UNG LI G A TE KNI SK A HÖ G S KO L AN

I N F O R M AT I O N S - O C H K O M M U N I K AT I O N S T E K N O L O G I

EXAMENSARBETE INOM TEKNIK OCH MANEGEMENT, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2015

(2)

Utveckling av GUI utifrån en given affärsprocess

John-Bernhard Stoor

2017-01-13

Examensarbete för Kandidatexamen Kursnummer IK120X

Examinator Anders Sjögren

Akademisk handledare Anders Sjögren

KTH Kungliga Tekniska Högskolan

Skolan för Informations- och kommunikationsteknik (ICT) Avdelningen för Programvaru- och datorsystem (SCS) SE-164 40 Kista/Stockholm, Sverige

(3)

Abstrakt

Preem verkar inom drivmedelsbranschen som styrs av en mycket hög omsättning med förhållandevis små marginaler. Det är därför viktig med en väl fungerande lagerkontroll. Det man idag är ute efter är en ökad precision i lageruppföljningen och därmed behövs ett nytt systemstöd till detta.

Jag fick i min roll hos Preem uppgiften att titta närmre på GUI och processerna bakom. Det resulterade i denna rapport med ett framtaget förslag på användargränssnittet till det nya systemet och dess affärsprocesser som är kopplat till detta. Arbetet fokuserar på hur de två framställs i förhållande till varandra och vilka metoder som används för att konstruera dessa. Arbetet inkluderar illustrationer av as-is och to-be processmodeller enligt BPMN specifikation, wireframes och en sitemap.

Denna rapport visar ett förslag på ett sammanfört system och ett intuitivare GUI med nya processer bakom, för just Preem, och hur balansgången går mellan att skapa affärsprocesser och ett grafiskt användargränssnitt ur varandra, beroende av vilka som är involverade i projektet.

Nyckelord

Processmodellering, wireframe, sitemap, as-is, to-be, BPMN, GUI, User-story, User-centered design

(4)

Abstract

Preem is a Swedish company that operates in the oil industry, which is controlled by very high sales and with relatively small margins. It’s therefore essential with a well working stock control. Today they are looking for a better way of monitoring the stock with a higher precision and therefore they need a new system for that.

My role at Preem was to take a closer look at the GUI and the processes behind that. It resulted in this thesis that includes the user interface for the new system and the business processes that are linked to this. The work will focus on how these two methods are produced in relation to each other, and the methods that are used to construct them. The thesis includes illustrations of as-is and to-be process models of the BPMN specification, wireframes and a sitemap.

This report shows a proposal of an integrating system and an intuitive GUI with new processes, at Preem, and how the balance is between creating business processes and a graphical user interface out of each other, depending on the people who are involved in the project.

Keywords

Process modelling, wireframe, sitemap, as-is, to-be, BPMN, GUI, User-story, User-centered design

(5)

Förord

Jag vill tacka alla de som har varit involverade i detta projekt.

Anders Sjögren, handledare KTH.

Alexander Åhlström, handledare på Preem.

Peter Nilsson, produktägare och varulagerchef på Preem.

Akhlad Ali, student inom samma projektgrupp.

Johny Premanantham, student inom samma projektgrupp.

Karl Fridlund, student inom samma projektgrupp.

Rasha Zaki, student inom samma projektgrupp.

Sebastian Nilsson, student inom samma projektgrupp.

Xinmao Wang, student inom samma projektgrupp.

Kerstin Sköldberg m.fl., användarna på Preem.

Framförallt vill jag tacka Rasha Zaki som jag inledningsvis av projektarbetet jobbade intensivt med och min handledare Alexander Åhlström, på Preem, som har stått ut med oss!

John-Bernhard Stoor Kungsängen, 8 juni 2015

(6)

Lista på akronymer och förkortningar

GUI Graphical User Interface

MoSCoW Must, Should, Could, Wont

BPMN Business Process Modelling Notation

XML Extensible Markup Language

WSBPEL Web Services Business Process Execution Language

SEQUEL Semiotic Quality Framework

7PMG Seven Process Modeling Guidelines

(7)

Innehållsförteckning

1 INTRODUKTION ...1

1.1 Bakgrund ...1

1.2 Problemdefinition ...1

1.2.1 Ursprungligt problem och definition ...1

1.2.2 Vetenskaplig och ingenjörsmässig frågeställning ...2

1.3 Syfte ...2

1.4 Avgränsning...2

1.5 Metod ...3

2 METODVAL ...4

2.1 Förstudie...4

2.1.1 Utbildning och intervjuer ...4

2.1.2 Litteraturstudie ...5

2.1.3 Informationsinhämtning - feedback ...5

2.1.4 Produktmål ...6

2.2 Genomförande ...7

2.3.1 Grafiskt användargränssnitt...7

2.3.1.1 Wireframe ...8

2.3.1.2 Sitemap ...8

2.3.2 Processmodellering ...8

2.3.2.1 BPMN ...9

2.3.2.2 As-is och To-be...9

3 ANALYS ... 10

3.1 Intervjuerna – user stories ... 10

3.2 Användarkrav ... 11

3.3 As-is modell ... 12

3.4 ”Verktygssidan” ... 13

3.5 Wireframe och Sitemap ... 14

4 RESULTAT ... 16

4.1 To-be modellen ... 16

4.2 Konceptuellt GUI ... 17

5 DIskussion och sammanfattning ... 21

5.1 Diskussion ... 21

5.2 Sammanfattning ... 22

6 REKOMMENDATIONER OCH FRAMTIDA ARBETE ... 24

(8)

6.1 Rekommendationer ... 24

6.1.1 Rekommendationer enligt önskemål, efter redovisningen ...24

6.2 Framtida arbete ... 26

Referenser ... 27

(9)

(10)

1 INTRODUKTION

1.1 Bakgrund

Preem AB är Sveriges största företag som tillhandahåller drivmedel, för såväl den privata bilisten som till den tunga trafiken, över hela Sverige. Preem har cirka 80 procent av den totala svenska raffinaderikapaciteten och cirka 30 procent av den nordiska. Dessutom så exporterar man runt två tredjedelar av den totala produktionen utomlands, vilket gör Preem till ett av Sveriges största exportföretag just nu.

I Sverige har Preem runt 570 drivmedelsanläggningar, där runt 100 är bemannade stationer och 170 är Såifa-anläggningar, och som i sin tur har ett flertal cisterner för de olika drivmedlen som tillhandahålls för försäljning. Såifa-anläggningarna är inriktade mot den tunga trafiken och tillhandahåller därmed endast diesel. Övriga drivmedelsanläggningar har alla sorters bensinblandningar (95, 96, 98) och diesel (standard och ACP Evolution Diesel) och etanol (E85). Det skiljer från station till station vad som exakt tillhandahålls beroende på läge och möjlighet, men alla har i stort sett produkter från alla de tre olika kategorierna.

Drivmedelsbranschen styrs av en hög omsättning men med små marginaler, vilket leder till att en bra lagerkontroll är avgörande för företaget. Preems stora omfattning resulterar i att minsta förbättring kan leda till att mycket stora summor kan besparas. Därför har man sedan en tid tillbaka börjat titta på möjligheten att effektivisera varulagret genom förbättrade systemstöd, då man faktiskt har möjligheten att samla in stora mängder data från de olika drivmedelsanläggningarna

1.2 Problemdefinition

1.2.1 Ursprungligt problem och definition

Idag sitter man med tre olika system och jobbar mycket manuellt, i ex. Excel, för att övervaka lagerdifferenser. Arbetsprocesserna är inte definierade utan bestäms utifrån vad användaren kommer fram till vad som behöver göras. Vad jag ska titta närmare på är hur man arbetar idag med de system man tillhandahålls och därmed hur det kan förbättras med hjälp av ett helt nytt system som samlar ihop funktionalitet från de tre tidigare systemen och med specificerade, samt förbättrade, processer bakom detta. Frågor som ställs är alltså:

- Hur arbetar de idag med sina system?

- Hur ska ett förbättrat arbetssätt se ut?

(11)

IK120X | EXAMENSARBETE INOM TEKNIK OCH MANEGEMENT Utveckling av GUI utifrån en given affärsprocess | 2

1.2.2 Vetenskaplig och ingenjörsmässig frågeställning

Utifrån den vetenskapliga frågeställningen så handlar det egentligen om på vilket sätt man får fram förbättringarna, utifrån Preems enskilda fall. Är det genom nya framtagna processer och göra ett GUI utifrån dessa, eller ta fram ett nytt konceptuellt GUI som sedan får definiera processerna, eller en kombination av de båda? (Graphical User Interface = grafiskt användargränssnitt: underlättar interaktionen mellan människa och dator).

För att uppnå dessa förbättringar kommer det att behöva användas olika verktyg beroende på vilket sätt man väljer att förbättra organisationen i Preem. Därmed blir tillvägagångsättet man väljer helt beroende på vilken fråga man väljer att svara på. De frågor man får ställa sig blir därmed:

- Hur ska ett nytt GUI se ut för att få en förbättrad arbetsprocess?

- Hur ska en ny arbetsprocess se ut för att få ett förbättrat GUI?

1.3 Syfte

Syftet med detta examensarbete är att titta närmare på möjligheterna med vad ett effektivt GUI kan göra för förbättringar i verksamheten. Idag är arbetsprocesserna onödigt omständliga och blir därmed inte så effektiva som de skulle kunna vara.

För akademins del så ska jag titta på vad som är gjort inom området tidigare och sedan dra slutsatser om hur man ska komma fram till de mest effektiva processerna och intuitiva GUI för Preems organisation.

Jag själv har som syfte med detta examensarbete att få lära mig mer om GUI, hur det fungerar på riktigt i en organisation och processer inom just denna verksamhet. Det är även det sistnämnda jag kommer att lägga mest fokus på då det passar min utbildning allra bäst. Jag tror att jag kommer att få nytta utav det jag kommer i kontakt med i detta arbete, för min framtida karriär, och dessutom till slut bidra med ett resultat som kan vara intressant för Preem.

1.4 Avgränsning

De avgränsningar som har fått göras är att jag inte kommer att kunna göra en fullt fungerande produkt åt Preem. Med det så menar jag att det kommer att tas fram ett konceptuellt GUI, tillsammans med en annan student inom projektarbetet som gör koden till denna, som skulle kunna fungera mot Preems verksamhet i praktiken. Men i och med att arbetet är så stort så har Preem satt ihop en grupp om totalt sju studenter, som fått olika arbetsområden, för att kunna få ihop en lösning i teorin i alla fall.

(12)

1.5 Metod

Metodvalen nämns kortfattat i denna del, då de redovisas mer djupgående under nästa kapitel. Då frågan var, från arbetets första stund, om man ska utgå från givna processer och skapa ett GUI utifrån det, eller om man ska utgå från att ha illustrerat fram ett GUI och därefter specificera processerna.

Om arbetet kräver, kan man göra en blandning av de två metoderna, så det blir en mer flexibel arbetsprocess att ta fram det nya användargränssnittet och processerna.

GUI´ts nya funktioner tas fram i samspråk mellan student, produktägaren och användarna av systemet. Studenten kommer med förslag och därefter ger övriga parter feedback på om iden var god nog att titta närmare på. Efter ett sammanställande över vilka funktioner som ska ingå och vad som kan förbättras, tar studenten fram en sitemap över det nya systemet och ett wireframe över relevanta verktygsfönster i systemet.

Vid skapandet av processer används språket BPMN. Detta är något som är vanligt förekommande vid specificering av processer och notationer, och som även använts under tidigare studier inom KTH.

Sedan efter ett samspråk med handledaren från KTH, så kom man fram till att titta närmare på user- story kan vara relevant för detta projektarbete. User-story är ett första steg med att få fram vad produktägaren och dess användare har för beskrivning på vad användaren ska kunna göra i systemet och dess värde som skapas där. Resultatet är alltså inga skriftliga krav utan mer en diskussion mellan alla inblandade parter för att kunna anpassa systemet så bra som möjligt.¹ Detta är något som senare utvecklades till att även studera närmare på user-centered design som kan vara intressant i samband med att användarnas delaktighet i utvecklandet av det nya GUI´t. ²

1 Chon, Mike. Advantages of User Stories for Requirements. InformIT Network, 2004.

2 Endsley, Mica R och Jones, Debra G. Designing for Situation Awareness: An Approach to User-Centered Design. CRC Press, 2 edition, 2011.

(13)

2 METODVAL

Kapitlet är uppdelat under två kategorier: Förstudie och Genomförande.

2.1 Förstudie

En förstudie har genomförts under de första veckorna hos Preem. Den har som mål att samla på sig så mycket relevant information som möjligt om organisationen för att slutligen kunna sätta upp produktmålen.

Denna del är nödvändig för att kunna svara på frågorna under kapitlet: 1.2.1 Ursprungligt problem och definition.

Metodval del: 2.1.1 Utbildning och intervjuer, är för frågan:

- Hur arbetar de idag med sina system?

Metodval delarna: 2.1.2 Litteraturstudie, 2.1.3 Informationsinhämtning - feedback och 2.1.4 Produktmål, är för frågan:

- Hur ska ett förbättrat arbetssätt se ut?

2.1.1 Utbildning och intervjuer

I början av projektet så var det mestadels utbildning och intervjuer, vilket var information från både teoretiska och praktiska delar inom organisationen. Här så följde jag inga direkta metodval för bästa intervjuteknik eller insamling av data, förutom att det dokumenterades ned så mycket som möjligt.

Det som dock fanns i åtanke under hela projektets gång var vikten av att involvera användarna redan från början, user-stories, för att se hur de verkligen arbetar idag med systemen men främst hur ett förbättrat arbetssätt kan se ut enligt dem själva.

Efter detta så följde brainstorming inom projektgruppen, där vi hade som mål att framföra alla de inblandades tankar och idéer och föra de samman. Därefter sattes olika produktmål inom projektgruppen, utifrån vad man hade för område.

(14)

2.1.2 Litteraturstudie

Repetition av tidigare studier inom främst processmodellering har gjorts och där kommer mest kunskaper inom området ifrån kursen på KTH som heter Processmodellering och design. Den källa som jag har använt mig mest av är därmed kurslitteraturen där ifrån som heter Workflow Management:

Models, Methods, and Systems, skriven av van der Aalst, W och van Hee, K.

Kunskaper inom GUI kommer främst ifrån erfarenheter med olika datorsystem från kurser genom åren på KTH, exempelvis Affärssystem och tjänsteorienterade arkitekturer.

Mestadels av den nya kunskapen kommer direkt ifrån olika källor på internet, såsom Designing for Situation Awareness: An Approach to User-Centered Design av Endsley, Mica R och Jones, Debra G som beskriver vikten med fokuseringen kring användaren, och vidare diskussionen som bör uppstå mot användaren enligt Advantages of User Stories for Requirements, av Chon, Mike.

2.1.3 Informationsinhämtning - feedback

En annan nyckelfaktor är att ta in så mycket feedback som möjligt från användarna men samtidigt se från en organisatorisk synvinkel. Man måste alltså ta hänsyn till alla i organisationen, alltifrån högsta ledningen ner till slutanvändarna av systemet. Det kan vara krävande när man ska bestämma relationen mellan affärsprocesserna och GUI´t under projektets gång och då är user-centered design en bra metod att följa. Främst handlar det om att involvera alla som påverkas av systemet under hela projektets gång med återkommande feedback. Det ger i slutändan användbarhet och spårbarhet i systemen, som därmed ger flexibilitet för utvecklande av affärsprocesser.³

Principerna man ska tänka på med user-centered design är att organisera det tekniska kring användarens mål, uppgifter och förmågor. Dessutom hur det organiseras kring användaren för att bearbeta information och kring dess beslutsfattande. Det sista handlar om att användaren måste vara medveten om teknikens status.⁴

Det är alltid produktägaren som tar de slutgiltiga besluten, men i detta fall med Preem var de öppna för kreativitet vid skapandet av det nya systemet. Då detta var endast ett projekt på koncept-nivå, då icke-funktionella krav såsom säkerhet och tillgänglighet inte har tagits hänsyn till, har fokuseringen legat desto mer på användarna, och produktägaren har inte haft några direkta synpunkter på det.

Därmed ligger alltså fokuseringen främst kring user-centered design och feedbacken ifrån användarna.

3 Sousa, Kênia; Mendonça, Hildeberto och Vanderdonckt Jean. User Interface Derivation from Business Processes: A Model-Driven Approach for Organizational Engineering. 2008. pp. 555.

4 Endsley, Mica R och Jones, Debra G. Designing for Situation Awareness: An Approach to User-Centered Design. CRC Press, 2 edition, 2011. pp. 9-12.

(15)

2.1.4 Produktmål

Man kan ställa produktmål i form av MoSCoW-metoden. Den är utvecklad av Dai Clegg och är en prioriteringsmetod för ett projekts mål. Förkortningen betyder alltså Must, Should, Could, Won't.

Must är sådana produktmål som måste göras innan projektets slut, annars räknas projektet som ett misslyckande. Should är sådant som är viktigt att ha avklarat men inget måste innan projektets slut.

Could är sådant som är önskvärt att få avklarat och som då är mindre resurskrävande, och om det finns möjlighet till det efter allt annat viktigt är klart. Won't är sådant som inte alls är lönande, nödvändigt eller ens möjligt under detta projektets gång.⁵ Denna metod valdes av produktägaren.

Produktmålen kan sedan tas fram efter all insamling av information om organisationen och efter man tillsammans med produktägaren gått igenom processerna. Tillsammans med en MoSCoW-lista kan man därmed bestämma realistiska produktmål.

Vad som förväntas, enligt MoSCoW metoden:

- Must - Konceptuellt användargränssnitt med en process bakom, som visar arbetsflödet etc.

vid en specifik framtagen process och interaktionen mellan användaren och applikationen med dess verktyg. En sitemap över webbgränssnittet och de funktioner som ska ingå. Ett wireframe över de sidor som ingår. En väldokumenterad rapport över hela projektet.

- Should - Testköra riktig data genom en framtagen webbapplikation med dess processer.

- Could - Fungera tillsammans med övriga projekt, alltså databas och funktions- implementering.

- Wont - Alla nödvändiga processer för en fullt fungerande applikation för verksamhetens egentliga behov. Utbildning av användargränssnittet mot användarna, underhållning och support.

5 Clegg, Dai. Case Method Fast-Track: A RAD Approach. Addison-Wesley Longman, 1994.

(16)

2.2 Genomförande

Resterande delen av projektets tid gick till genomförandefasen. Själva upplägget under denna del följdes till stor del efter Polyas metod. Polyas problemlösning består av fyra faser. Först gäller det att förstå problemet, veta att man verkligen gör det. Därefter ska man skapa en plan för att kunna lösa det definierade problemet. Sedan genomför man planen som man planerat det och sen till sist kontrollerar man resultatet och går igenom det noggrant. Det är logiskt tänkande på det allra enklaste sättet, för att nå positiva resultat.⁶

Övergången till genomförandefasen betyder att det viktigt med att man verkligen förstår alla delar i förstudien, när man väl börjar skissa på det nya systemet. Därmed är det kritiskt att man är metodisk och noga när man väl sätter upp en plan för att lösa problemet. Därefter genomför man planen som planerat så det man har skapat är väl värt att presentera för produktägaren. Därifrån kan jobbet gå vidare tills man gjort alla de delar som man har satt upp som produktmål.

Denna del är till för att kunna svara på kapitel: 1.2.2 Vetenskaplig och ingenjörsmässig frågeställning.

Metod del: 2.3.1 Grafiskt användargränssnitt, finns verktygen för att svara på frågan:

-Hur ska ett nytt GUI se ut för att få en förbättrad arbetsprocess?

Metod del: 2.3.2 Processmodellering, finns verktygen för att istället svara på frågan:

- Hur ska en ny arbetsprocess se ut för att få ett förbättrat GUI?

2.3.1 Grafiskt användargränssnitt

GUI betyder Graphical User Interface, eller grafiskt användargränssnitt, möjliggör en enklare interaktion mellan dator och människa. Den grafiska bilden i datorer har de senaste 20 åren utvecklats väldigt fort och blivit ständigt mer intuitivt, vilket har lett till en mängd olika standarder och verktyg att jobba med. I detta arbete används metoderna wireframe och sitemap för att kunna skapa sig en enkel övergripande bild över hur det nya systemet skulle kunna se ut och hur det skulle vara upplagt.

Valet föll på dessa metoder efter tips från andra i projektgruppen, i och med att jag inte har tidigare erfarenheter av att arbeta med GUI.

6 Pólya, George. How to Solve It. Princeton University Press, 1945.

(17)

2.3.1.1 Wireframe

Att starta med att göra ett antal wireframes är ett bra första steg och ger en övergripande bild hur det slutgiltiga användargränssnittet kan se ut. Det går relativt fort att sätta upp ett antal prototyper, för att sedan kunna gå vidare med de som valts att vidareutvecklas. Då har man en bra grund, ett skelett, för att fortsätta utveckla sidan med ex. färg, typsnitt osv. Ett wireframe kan starta på ett vanligt ritblock men sedan övergå till en digital form, då det finns väldigt enkla program för att framställa en prototyp.

Wireframes är bara den första fasen vid skapandet av en GUI-prototyp och behöver därmed inte följas strikt genom hela projektet. För att kunna vara flexibel med funktioner och uppdateringar så behöver det endast överstämma i form av element och grupperingar.⁷

För att framställa wireframes används programmet Balsamiq, efter rekommendationer från projektgruppen.

2.3.1.2 Sitemap

Sitemap är ett begrepp som listar alla de olika grafiska sidor som ska ingå i ett system. De kan vara uppdelat i större kategorier och sedan fortsätta längre ut i mindre kategorier, så det flätas ut som ett träd fullt med olika sidor. Det är alltså den vanligaste metoden för att göra det enklare för användaren att hitta det man ska fort.⁸

2.3.2 Processmodellering

Samspelet mellan att ta fram ett nytt GUI tillsammans med användare och föra samman processer och GUI har lett till undersökningar om hur ett GUI faktiskt kommer till. Till att börja med kan man ha i åtanke vid skapandet av ett GUI, att ha en modelldriven approach med processmodellering. Då håller man ihop kraven från processmodelleringen och användargränssnittet på ett bra sätt.⁹

7 Garrett, Jesse James. The Elements of User Experience: User-Centered Design for the Web. New Riders, 2th edition, 2010, pp. 149.

8 usabilitynews.org, [Elektronisk] 2015.

9 Sousa, Kênia; Mendonça, Hildeberto och Vanderdonckt Jean. User Interface Derivation from Business Processes: A Model-Driven Approach for Organizational Engineering. 2008. pp. 553.

(18)

2.3.2.1 BPMN

För att specificera processerna i detta arbete har valet gått till att använda BPMN, som låter en grafiskt modellera affärsprocesser som finns i en organisation. Det är en så kallad notation som hanteras av Objekt Management Group och som är framtagen just för att grafiskt kunna visa på ett enkelt sätt hur ett flöde hanteras. Oavsett vilken position man har i organisationen, användare eller utvecklare, kan man se på ett enkelt sätt hur allt fungerar ihop. Vidare så är standarden kompatibel med språken XML och WSBPEL, som i sin tur kan implementera affärsprocesserna mot ett webbaserat system.¹⁰

2.3.2.2 As-is och To-be

Att göra en före och efter modell av en process kallas för as-is och to-be modell. Som det låter så specificerar man upp hur ett moment i verksamheten ser ut i dag och därefter gör man en modell över hur det skulle behöva se ut istället. Man tittar på alla onödiga steg som antingen skulle kunna automatiseras, delvis automatiseras eller helt enkelt tas bort. Det man måste tänka på vid förenkling och automatisering är att ändå ta hänsyn till alla tidigare aktiviteter, så inget viktigt moment missas.¹¹

10 bpmn.org, [Elektronisk], 2015.

11 Khosrowpour, Mehdi. Emerging Trends and Challenges in Information Technology Management. Idea Group Pub vol 1, 2006, pp.138.

(19)

3 ANALYS

I detta kapitel tas relevanta delar upp, för analys, från projektet.

3.1 Intervjuerna – user stories

Efter ett möte med de två som arbetar med systemen dagligen, så kom vi fram till att ett antal intervjuer skulle vara passande. Efter totalt två intervjuer så hade vi kommit fram till en hel del intressanta idéer om hur hela deras arbetsmoment skulle kunna förbättras. Först och främst så var deras sätt att arbeta med att behöva hoppa mellan flera olika system, för att kunna göra ett korrekt utfört arbete, ett besvärligt sätt att arbeta på. Man behöver veta vilka system som är nödvändiga för just det problemet som man ska lösa, man behöver komma ihåg siffror i huvudet för att flytta ett framtaget värde till den ursprungliga tabellen som ska bokföras.

Det fanns därmed ett stort problem som skulle kunna förbättras. Den framtagna prototypen på systemet löser problemet med just användandet av flera olika system.

De tre olika systemen som finns idag.

(20)

Användaren ska på ett enkelt sätt, inom samma applikation, kunna använda olika funktioner som både Preems Volymdifferens - lagerkontroll, Siteinfo och Kalibreringsverktygen i Excel, har idag.

 Volymdifferens – lagerkontroll: tar hand om leveransuppföljningar och anläggnings- inställningar.

 Siteinfo: innehåller anläggningsinfo/leveranshistorik och nivåhistorik.

 Kalibreringsverktygen i Excel: för kalibrering och tester av värden.

Se bilaga 1 med intervjuerna av användarna.

3.2 Användarkrav

Utifrån user-stories, eller intervjuerna som gjordes på användarna, kan man ta fram funktionella krav:

- Systemet ska dela upp varningar som kända fel och okända fel, i ordning efter antalet varningar. Även om de kända felen är fler på en drivmedelsstation är det de okända felen som är prioriterat och hamnar därmed högre upp.

- När man har valt en anläggning ska varningarna radas upp och med den varningen med högst prioritet högst upp i listan. Leveransdifferens har ex. högre prioritet än Stöld/läckage/pumpfel, då denna kategori oftast är ett pumpfel och därmed inte lika allvarligt som en oftast medveten differens i leveransen av drivmedel.

- Kända fel, såsom extremvärden och ingen kontakt med pejlen, ska autokorrigeras till normalvärdet. Detta menas med att systemet känner av dessa värden som extrema och därmed rättar systemet automatiskt dessa för att användaren bara ska kunna godkänna redan korrigerade värden, som i slutändan sedan bokförs.

- Olika verktyg för att få fram leveransinfo, kontaktinfo, kalibrering, anläggningsinfo och nivåhistorik, ska autogenereras fram i förhållande till vilken typ av varning som uppstått. Det menas med att systemet räknar ut vilken sorts varning det är och tar fram de mest relevanta verktygen som behövs för att lösa problemet.

- Korrigerade värden ska enkelt kunna godkännas och bokföras med ett knapptryck, i samma system som användaren arbetat fram det korrekta värdet i.

- Integrera i systemet en vidarebefordrande funktion av varningen med en skärmdump över detta, genom e-mail.

(21)

Funktionella krav är alltså sådant som beskriver hur systemet ska interagera med användarna.¹² Notera att inga krav har satts från produktägaren gällande funktionella eller icke funktionella krav.

De ville inte att man skulle låsa sig till sådant, utan vara kreativ och komma med nya idéer till det nya systemet. Krav sattes utifrån user-stories, intervjuerna, med exempel på hantering av ett fel.

Inga icke-funktionella krav sattes då systemet är på en konceptuell nivå på hur det ska fungera, alltså inte hur bra. Detta tas istället upp senare under kapitel 6.2 Framtida arbeten.

3.3 As-is modell

Utifrån user-stories, eller intervjuerna som gjordes på användarna, framställs as-is modellen över hur användarna idag arbetar steg för steg.

Idag så är mycket utav arbetet manuellt. Man får gå in på Lagerkontroll och sedan under Anläggningslista så visas drivmedelsanläggningar med mest antal varningar. Därifrån så får man antingen välja att gå in på Dagsavstämning eller Leveransuppföljning för att vidare undersöka vad det är för typ av varning. Dessutom så brukar man behöva gå utanför systemet Lagerkontroll för att lösa problemet. Det kan antingen vara i Infosite, som tillhandahålls av leverantören MCD, eller i Kalibreringsverktygen i Excel, där antingen kalibrering eller tester med att ändra värdet sker. Därefter får användaren komma ihåg siffran i huvudet och föra över det till tabellen som bokförs. Om varningen går att lösa, utan att någon mejlkontakt behövs, så justerar man alltså värdet och godkänner detta så det kan bokföras. Det fungerar, men det är inte så effektivt.

As-is modellen.

12 Wohlin, Claes. Introduktion till programvaruutveckling. 2005.

(22)

3.4 ”Verktygssidan”

Efter ett intensivt tankearbete med hur det nya GUI´t skulle kunna se ut och fungera så gjordes ett koncept med en "Verktygssida", där man samlar ihop allt man behöver för att kunna lösa ett fel som uppstått, pga. ex. ett pejlfel. Det som tidigare fungerat bra enligt användarna är de olika verktygen man haft men att det fanns i olika system, vilket blir ett extra tidskrävande arbete för användarna.

Första konceptet över Verktygssidan (version 1).

Redan vid denna tidpunkt så var tanken att sidan skulle kunna autogenerera fram nödvändiga verktyg för just en viss felvarning och att alla verktyg finns på ett och samma ställe. Efter att ha fått ett första godkännande av produktägaren, gällande konceptet som visas ovan, så kunde man gå vidare i arbetet med att fastställa vad som var möjligt att framställa eller förbättra med denna ”Verktygssida”.

(23)

3.5 Wireframe och Sitemap

Enklare wireframes togs fram och blev godkända av produktägaren för att utvecklas vidare på. För själva ”Verktygssidan” så krävdes det en mer detaljerad prototyp.

Huvudfokuset var att ständigt utveckla ”Verktygssidan”, som samlar ihop alla de olika verktyg de använder idag från Volymdifferens - lagerkontroll, Siteinfo och Kalibreringsverktygen i Excel,. Det var det problemet man kunde se tog mest resurser av hela arbetsmomentet användarna har och som nu skulle effektiviseras. Med samtal och feedback från användare och produktägaren kunde ett förslag på ”Verktygssida” godkännas, som man därefter kunde arbeta vidare med. Den nya funktionen med Verktygssidan v.2, utöver sammanförandet av verktyg och autogenerera, var att man på ena sidan har olika verktyg för att räkna fram rätt värde, som sedan ska ändras och bokföras på andra sidan.

Dessutom gjordes det nu för första gången i Balsamiq för ett snyggare utseende.

Den enklare varianten på Verktygssidan (version 2).

(24)

De större förändringarna i sitemap blev pga. den nya ”Verktygssidan”, då Leverensuppföljning och Dagsavstämning hamnade på samma sida. Det har lett till att under fliken Historik hittar man istället en direkt länk till Dagsavstämning, Leveransuppföljning och Förar- och bilinfo, som är en ny funktion av övriga i projektgruppen på Preem. Detta för att man ska lätt kunna ta sig in i dessa listor, utan att behöva gå igenom en felvarning.

Mindre förändringar än från dagens Preem lagerkontroll. Fliken Ekonomi är endast föreslaget innehåll. Eventuellt ska också Inställningar med, som finns idag i Lagerkontroll.

(25)

4 RESULTAT

4.1 To-be modellen

Förenklad process pga. den nya ”Verktygssidan”.

Nu visas endast varningar, under fliken Utredning som hamnar på sidan kallad Anläggning, sorterad efter antalet okända fel. Antalet varningar visas som en röd notifiering intill fliken Utredning så att man som idag inte behöver gå Anläggningslista för att se om det finns en eller flera varningar.

Processen börjar alltså med att en varning har rapporterats, som man sedan kan välja vilken man vill undersöka. När man väl trycker på en anläggning så kommer alltså relevanta verktyg att autogenereras fram, där parametrar har satts som bestämmer vilka verktyg som ska visas, men som man sedan kan välja att byta ut mot andra tillgängliga verktyg.

Under ”Verktygssidans” aktivitet så ingår mejlknappen, alltså att mejlkontakt sker i samma ögonblick som kontrollen. Nu kan man enkelt trycka på mejl- och skärmdumpsknappen på en gång med visning av felvarningen och eventuellt förslag på ändring av värden.

Det går från att vara manuellt arbete med att öppna ett mejlprogram och bifoga en skärmdump, till att vara semi-automatisk, för när man trycker på mejlknappen så kan man välja att få med en skärmdump samtidigt som data om problemet förs in i meddelandet, så inte användaren behöver skriva in det. Det kan annars leda till felskrivningar men som nu elimineras om all data förs in i meddelandet per automatik. För vidare kontakt med Hoyer, som är Preems transportör, krävs det svar innan värdet bokförs.

Vidare ska värden man har ändrat på kunna godkännas, då data skickas mellan ”Verktygssidan” och Dagsavstämning eller Leveransuppföljning.

Det är bara aktiviteten Rapportera och Anmäl händelse, som sker utanför det nya systemet. De görs på olika sätt beroende på hur situationen ser ut just för tillfället.

(26)

4.2 Konceptuellt GUI

Först så definierar systemet varningarna och delar in dessa i två kategorier. Extremvärden, midnattsleverans som ej kan matchas automatiskt, är kända fel. Leveransdifferenser, pejlfel, stöld/läckage/pumpfel är okända fel. Systemet har sorterat dessa fel, som behöver granskas, under tre kategorier som systemet ska känna igen och sorterat automatiskt. Sorteringen sker efter antalet okända fel. Se bilden nedan.

Först väljer man en anläggning, troligtvis den med mest antal okända fel. Då visas både kända och okända fel i två separata kolumner. Kända fel har autokorrigerats och är redo att godkännas, utan granskning. Okända fel ska man kunna trycka på och därefter autogenereras verktyg, för vidare granskning, så man kan lösa felvärdet på en och samma sida.

(27)

Värdet ändras och godkänns för att bokföras. Nästa fel/felen genereras fram igen i listan från anläggningen man gick in på med x-antal fel, alltså om och om igen tills inga fel finns kvar på anläggningen.

De kända felen, som användaren egentligen inte behöver granska, ska alltså ha fått rätt autogenererade värden som man bara sedan göra en snabb överblick över och därefter godkänner för bokföringen.

Detta ska man kunna göra efter man korrigerat alla okända fel dessutom. Det skulle exempelvis kunna vara en midnattsleverans som vid tillfället inte hade fler leveranser till anläggningen, då ska denna leverans kunna matchas automatiskt i efterhand i systemets bokföring.

Dessa olika verktygsknappar är till för att lösa alla olika felvarningar i systemet:

Knapp Beskrivning

Leveransinfo Information om chaufför och med tillhörande bil, rapporterade leveransmängd, tid och order- och fakturanummer.

Kontaktinfo Kontaktinformation till Hoyer eller reparatör.

(28)

Kalibrering Verktyget som är framställt i Excel av Preem själva.

Anläggningsinfo Här visas de olika drivmedlen med tillhörande info som mängd, tid för pejlat värde etc. Dessutom visas en graf över pejlat värde för relevant period. Denna går att ändra på med vilken period man vill se.

Nivåhistorik Valt drivmedel eller drivmedelsgrupp för en viss period (per dag).

I exemplet nedan visas att vid en leveransdifferens varning så autogenereras Kalibrering och Anläggningsinfo fram. Användarna kan även såklart bestämma själva vilka verktyg de vill använda sig utav, och dessa är bara ett knapptryck ifrån.

Den slutgiltiga Verktygssidan (version 3).

(29)

Beroende på vad det är för varning så kommer antingen listan på Dagsavstämning eller Leverensuppföljning upp på vänster sida. Vid pejlfel behöver man exempelvis kunna titta på båda delarna. Nedan följer hur systemet ska agera vid okända fel:

Händelse Autogenereras verktygen Uppstår

Vid en leveransdifferans varning

Chaufför - och bilinfo, kontaktinfo mot Hoyer, inzoomad graf över pejlvärde (Anläggningsinfo, kalibreringsverktyget.).

Vid 2% och 200 liter differens per leverans

Vid pejlfel Öppnas både Dagsavstämning och

Leveransuppföljning. Man ska kunna se graf över pejl (Anläggningsinfo), kontaktinfo och kalibreringsverktyg. Mejl- och fotoknappen är till för att kunna skicka mejl till den som behöver en skärmdump över problemet.

Om pejlen (värdet) fastnat eller om inget värde finns alls.

Vid

stöld/läckage/pumpfel

Tabell med given drivmedel/cistern under given dag (Nivåhistorik), graf över pejlen (Anläggningsinfo), tillsammans med verktyget Kalibrering.

Övriga differenser på 2%

och 200 liter.

Mejl- och skärmdumpsknapp ska finnas tillgänglig för varje felvarning. Dessutom så ska såklart möjlighet att ändra värden finnas, vilket blir under Dagsavstämning till vänster så värdet sedan justeras till det rätta, i tabellen som bokförs.

Idag så skriver dessutom användarna i ett Excel dokument, som man kallar för gamla Dagsavstämningen, och testar att ändra data i tabellen för att se om värdena justeras till det bättre, totalt sett. Detta ska användarna nu alltså göra till vänster i Dagsavstämning, på ”Verktygssidan”, och sedan godkänna ändringen för att det sedan ska kunna bokföras.

(30)

5 DISKUSSION OCH SAMMANFATTNING

5.1 Diskussion

Till att börja med tog den inledande fasen mer tid än man hade först hade trott. Det var en hel del att lära sig, vilket resulterade i att själva arbetet i sig tog ett tag att få igång men det var ändå nyttigt att lära sig mer ingående om alla system Preem använder sig utav. Det var dock en balansgång med hur mycket Preem ville dela med sig utav det som de har idag, främst för att vi studenter inte ska bli låsta till vissa tankegångar och metoder. Det var därför tufft i början, som sagt, att sätta sig in i arbetet med det resulterade nog istället i några kreativa lösningar Preem inte tänkt sig själva.

Vad har då detta arbete fått fram för resultat från de olika metodvalen Wireframe och Sitemap, respektive BPMN och As-is/To-be modell? Arbetet har genererat fram en hel del resultat genom de båda tillvägagångsätten av att skapa GUI och processer, som var huvudfrågan med detta arbete. Det ligger en hel del nya processer bakom det nya GUI´t. Men vilket tillvägagångssätt var det mest givande? Vilket alternativ skapade fram den andra delen bäst? Från början utgick man naturligt att förbättra processerna. Därefter började man skissa på hur GUI´t skulle kunna se ut om man nu skapar dessa nya processer. Sedan var tillvägagångssätten helt sammanlänkade i varandra under resterande tiden av projektets gång.

Det blir däremot tydligare när man arbetar tillsammans med antingen produktägaren eller användaren.

Slutsatsen jag kan dra från detta projekt är tydligt och kanske lätt förutspått:

- Produktägaren är mest intresserad av effektivare processer.

- Användaren är intresserad av enklare GUI.

Det är detta som skiljer de olika tillvägagångsätten åt. Det beror helt på vem man arbetar med, produktägaren eller användarna, som det ena tillvägagångsättet fungerar bättre än det andra.

Att arbeta med metoderna för att ta fram GUI var förhållandevis enkel att lära sig. Då jag inte har någon tidigare erfarenhet att arbeta med GUI, tyckte jag att det passade bra ändå att arbeta med detta kopplat till processer, då det är relevant med de båda delarna tillsammans. Det slutgiltiga förslaget på hur ett GUI ska se ut känns ändå bara som en del av en rad koncept i dagsläget. Det skulle behöva undersökas mer mot organisationen förmågor och krav, då jag inte tagit med aspekter som exempelvis att vissa arbetar med flera datorskärmar samtidigt. Något som kanske måste elimineras om man ska flytta över sådana här arbeten till surfplattor i framtiden. Sådana och liknande tankegångar tar ännu mer resurser, då även hårdvaruprestanda måste räknas in. Avsaknaden av icke-funktionella krav helt beror på att varken jag eller produktägaren fokuserade på detta då det var de funktionella kraven som var det mest intressanta för produktägaren.

(31)

BPMN var bra som processmodelleringsverktyg, främst för att få fram en före och efter modell (As- is och To-be modell) över arbetsprocessen, beroende på om ”Verktygssidan” fanns eller inte. Då kunde man på ett övergripligt sätt se de önskade effekterna som blev med hjälp av den nya

”Verktygssidan”.

User stories har varit en avgörande faktor med att få fram användarkraven, de funktionella kraven som var det viktiga enligt produktägaren. Det är alltså dessa intervjuer med användarna tillsammans med feedback från dessa, alltså med metoden User-centered design, som har varit avgörande med hur systemet ser ut och fungerar till slut.

5.2 Sammanfattning

Den akademiska frågan som ställdes vid det allra första skedet med detta examensarbete var hur användargränssnitt och affärsprocesser förhåller sig till varandra. Hur ska man ta fram ett användargränssnitt kopplat till affärsprocesser eller ska man tänka helt tvärtom istället? Ska affärsprocesserna skapa användargränssnittet? Det fick bli frågan i detta arbeta hur de båda skapas i förhållandevis till varandra.

Jag skulle säga att med detta specifika arbete så låg fokuseringen mycket på funktion och processerna i början och hur det skulle skapa ett effektivare GUI. Att tänka på att mycket mer ska automatiseras och effektiviseras ger inte så mycket för användarna själva. De vill ju ha ett enkelt GUI som är lätt att arbeta i, vilket kanske inte alltid ett automatiserat system bidrar till. Därför fick ett antal möten med användarna ske, där man visade upp förslag på utseende och funktion. Vad användarna var ute efter vid första stund var förbättringar i nuvarande system, vilket man egentligen inte skulle fokusera på. Speciellt då det är rätt så komplexa problem kopplat till både hårdvara och mjukvara ute på drivmedelstationerna. Det man förstod i efterhand, med mötena man hade med användarna, var att förklara funktioner för dem inte ledde till något då de hade svårt att förstå dessa i jämförelse med vad de redan har. Därför är det bra att utgå från ett wireframe och förklara till detta istället. Då var det enklare att föra en konversation och förklara hur det nya systemet skulle kunna fungera. Då var det mer GUI´t som togs fram, delvis med användarna, som skapade nya processer och tankar till nya funktioner i systemet.

Så det är egentligen beroende på personen i fråga vad det är som är den bästa arbetsmetoden. Om man ska arbeta mycket utifrån användarna är det bättre att arbeta utifrån ett illustrativt GUI som därmed skapar nya funktioner och processer. Sedan motsvarande sida i organisationen, som produktägaren, så är funktioner och effektivare processer mer intressant och som därmed skapar ett GUI. Så i slutändan blev det en hybrid av det både metoderna att framställa ett GUI med affärsprocesser till, då det är viktigt att lyssna på alla inom projektet.

(32)

Sammanfattningsvis så tycker jag, efter detta arbete, att involvera alla som är kopplat till projektet på ett eller annat vis är nyckelfaktorn till ett lyckat projekt.

Resultat om vad respektive tillvägagångssätt har för fördel:

Wireframe och Sitemap är för att ta fram sammanföringen av flera olika system till ett. Hur det i praktiken skulle kunna fungera och se ut i ett och samma system, enkelt och effektivt för användaren.

BPMN och To-be modellen är för att kunna effektivisera processerna utan att något fel eller problem skulle uppstå någonstans i den nya arbetsprocessen.

(33)

6 REKOMMENDATIONER OCH FRAMTIDA ARBETE

6.1 Rekommendationer

Om nu Preem ska fortsätta med detta startade projekt så följer nedan några rekommendationer.

Jag tror det är möjligt att skapa något utifrån detta projekt som startats med ett antal studenter. Det finns såklart mycket att göra i den inledande fasen av projektet fortfarande då det säkert ställs många fler krav än de som man jobbat med, inte minst inom säkerhet.

Att lyssna på användarna av det nya systemet är avgörande för ett lyckat system. Det jag har sett idag är att de stör sig på mindre saker som att vissa knappar inte går att trycka på ibland och att det inte går att urskilja drivmedelssort i de tre olika drivmedelsgrupperna. Små problem som troligtvis enkelt går att ändra på, allt för att användaren ska vara på bästa humör. Det ger nog goda synergieffekter vidare genom hela organisationen i slutändan.

För det sista så krävs mer tid för ett sådant här stort projekt. Det var säkert därför det krävdes att flera studenter involverades, men att slutföra en sådant här nytt system kräver ännu mer resurser. Men med tanke på vilka besparingar Preem skulle kunna göra vid effektiviseringar inom varulagren, så är det värt varenda krona.

6.1.1 Rekommendationer enligt önskemål, efter redovisningen

Preem blev nöjda med resultatet från detta arbete men efter en diskussion om processer under frågestunden vid anförandet, tyckte min handledare från KTH att jag skulle komplettera med ett alternativ till BPMN. SEQUEL togs upp som ett exempel och det var där jag började undersöka om det var en passande metod. Nedan följer resultatet från den undersökningen.

Utöver BPMN som används, och som är inriktat mot event-driven proceses, kan man även med fördel titta på ramverket SEQUAL. Den har det som BPMN saknar, såsom att enklare mäta förbättringar och ge ett tydligt ägarskap inom processen.

SEQUAL är ett ramverk för att utvärdera kvaliteten i processmodeller. Förkortningen betyder semiotic quality framework och den bygger på semiotiska studier, eller enklare sagt semantisk, syntax och pragmatisk. Det är utifrån kategorierna: fysisk, empirisk, syntaktisk, semantisk, uppfattad semantisk, pragmatisk, social och organisatorisk kvalitet, som man gör sin analys.

Utöver SEQUAL, som kan anses vara för abstrakt för nybörjare att applicera, finns en annan metod som heter 7PMG.¹³ Där får man riktlinjer över hur man ska modellera sin process på allra bästa

13Mendling, Jan, Hajo A. Reijers, and Wil MP van der Aalst. Seven process modeling guidelines (7PMG). Information and Software Technology 52.2, 2010, pp 1.

(34)

sätt för att undvika fel och hålla nere komplexiteten. För fel uppstår ju inte bara slumpmässigt, utan det är hur förståelig processen är. En onödigt komplex process har en avgörande roll på den mänskliga förståelsen av den, för man kan ändra processer till det enklare utan att påverka logiken i den.

1. Använda så få element som möjligt, ju större desto större chans till att det blir ett fel på vägen.

2. Minimera antalet vägar man kan ha från ett element, det gör annars det bara svårare att förstå processen.

3. Använda bara en start- och slutpunkt, då vissa work-flow engines endast stödjer en av vardera sorten.

4. Håll modellen så strukturerad som möjligt, sluta på samma sätt som du började på ett element som du delar på.

5. Undvik OR och använd istället AND eller XOR-split, då dessa är mindre benägna att generera fel.

6. Beskriv en aktivitet genom ett verb, följt av ett objekt.

7. Använd inte fler än 50 element i modellen, dela i så fall upp dessa i flera olika processer.

Dessa riktlinjer har jag faktiskt följt i stor utsträckning utan att veta om det sedan innan. Jag har förenklat processen, som verkar vara huvudmålet i 7PMG, men det enda jag inte gjorde var att inte använda en OR-split. Det tror jag dock inte skulle göra någon skillnad i den lilla process jag modellerade fram, men rekommenderar nog denna riktlinje vid mer komplexa processer som ju enkelt blir onödigt komplexa när man inte följer dessa riktlinjer. ¹⁴

Om man nu ska få med alla i en organisation i ett sådant här liknande projekt, så ska man inte använda sig uteslutande av metoder som inte alla är bekväma med, ex. SEQUAL, då finns andra alternativ, ex.

7PMG, som blir en bra inledande metod för alla inblandade och som i det här fallet är mindre abstrakt.

Visst ska mer avancerande utvecklare använda sig utav SEQUAL ändå från processmodellerings- momentets startskede men i mitt fall blev arbetsmetoden istället efter riktlinjerna hos 7PMG omedvetet, då det är framtagen på ett rätt så logiskt sätt och därmed också lättare för användarna att bidra till projektet.

14Mendling, Jan, Hajo A. Reijers, and Wil MP van der Aalst. Seven process modeling guidelines (7PMG). Information and Software Technology 52.2, 2010, pp 10-12.

(35)

6.2 Framtida arbete

För Preem själva så krävs det ovannämnda för framtida arbete. Dessutom om man ska tänka på framtida lösningar så är att framtidssäkra sig med den teknik som håller på att utvecklas i allt snabbare takt. Surfplattor bör man ha i åtanke vid utvecklandet av GUI´t, som jag då på ett bra sätt startat med att endast använda ett system. Det föreslagna systemet är alltså betydlig bättre än det nuvarande då en skärm endast behövs. Det ska vara flexibelt och fungera på olika skärmstorlekar, för att systemet ska kunna vara framtidssäkrat. Jag tror också att väl fungerande automatiseringar uppmanar användarna mer till att lösa problem, det blir helt enkelt mer underlättande för användaren att arbeta och därmed så blir det en trevligare arbetsplats. Så gällande icke-funktionella krav så är det ett måste att börja med om man vill ta detta projekt till högre nivåer. Nedan följer de olika kategorierna under icke-funktionella krav.¹⁵

- Funktionalitet: En hög kvalitet på mjukvaran.

- Tillförlitlighet: Hur systemet klarar av antalet användare prestandamässigt.

- Användbarhet: Vilken tid det tar för användaren att lära sig systemet.

- Effektivitet: Rätt arkitektur, alltså relation mellan resurser och prestanda.

- Underhållsbarhet: Hur underhåll och support är med tiden.

- Portabilitet: Om programmet är enkelt att flytta mellan olika miljöer.

För en själv och akademin så tror jag att fokuseringen kring användaren är viktig vid ett sådant här arbete. Något som skulle ha gjorts är även instudering av intervjuteknik och därefter mer intervjuer av användare och produktägaren. Nu var informationsflödet mest åt studentens håll och inte så mycket tillbaka. Det är kanske något som skulle gjorts annorlunda om arbetet skulle börjat om igen. Att lyssna på alla, har jag sagt tidigare, men också att fråga alla delaktiga inom projektet är något som därmed är viktigt för att det ska bli en bättre kommunikation mellan projektdeltagarna och organisationen. En ordentlig brainstorming med användarna hade nog varit bra. Det skulle med stor sannolikhet ge ett bättre slutresultat.

Avslutningsvis så kan jag bara säga att utöver det som jag valde är alltså de övriga metoderna, SEQUEL och 7PMG, också bra alternativ för Preem att titta närmare på för att specificera processer och vidare för processmodellering. Men för att få ut så mycket som möjligt av en viss metod, anpassa metoden efter användaren av just denna.

15 Al-Qutaish, Rafa E. An investigation of the weaknesses of the ISO 9126 international standard. In: Computer and Electrical Engineering, 2009.

ICCEE'09. Second International Conference on. IEEE, 2009. p. 275-279.

(36)

REFERENSER

Tryckta:

Aagesen, Gustav, and John Krogstie. Analysis and design of business processes using BPMN. Handbook on Business Process Management 1. Springer Berlin Heidelberg, 2010.

Al-Qutaish, Rafa E. An investigation of the weaknesses of the ISO 9126 international standard.

Computer and Electrical Engineering, 2009. ICCEE'09. Second International Conference on.

IEEE, 2009.

Chon, Mike. Advantages of User Stories for Requirements. InformIT Network, 2004.

Clegg, Dai; Barker, Richard. Case Method Fast-Track: A RAD Approach. Addison-Wesley, 2004.

Endsley, Mica R och Jones, Debra G. Designing for Situation Awareness: An Approach to User- Centered Design. CRC Press, 2 edition, 2011.

Garrett, Jesse James. The Elements of User Experience: User-Centered Design for the Web. New Riders, 2th edition, 2010.

Khosrowpour, Mehdi. Emerging Trends and Challenges in Information Technology Management. Idea Group Pub vol 1, 2006.

Krogstie, John, Guttorm Sindre, and Håvard Jørgensen. Process models representing knowledge for action: a revised quality framework. European Journal of Information Systems, 2006.

Mendling, Jan, Gustaf Neumann, and Wil van der Aalst. On the correlation between process model metrics and errors. Tutorials, posters, panels and industrial contributions at the 26th international conference on Conceptual modeling-Volume 83. Australian Computer Society, Inc., 2007.

Mendling, Jan, Hajo A. Reijers, and Wil MP van der Aalst. Seven process modeling guidelines (7PMG). Information and Software Technology 52.2, 2010.

Polya, G. How to Solve It. Princeton University Press. Princeton, NJ, 1945.

Sousa, Kênia; Mendonça, Hildeberto och Vanderdonckt Jean. User Interface Derivation from Business Processes: A Model-Driven Approach for Organizational Engineering. 2008.

van Bommel, P., et al. QoMo: A modeling process quality framework based on SEQUAL. Proceedings of EMMSAD. Vol. 7. 2007.

van der Aalst, W och van Hee, K. Workflow Management: Models, Methods, and Systems. The MIT Press, 2002. (Studentlitteratur från kursen: Processmodellering och design.)

Wohlin, Claes. Introduktion till programvaruutveckling. 2005.

(37)

Elektroniska:

A Guide to the Business Analysis Body of Knowledge. International Institute of Business Analysis.

2009 s. 165. Läst den 02.06.15.

http://www.bpmn.org/. Läst den 02.06.15.

http://usabilitynews.org/sitemap-design-alphabetical-or-categorical/. Läst den 03.06.15.

Muntliga:

Alexander Åhlström, handledare Preem (2015) Peter Nilsson, produktägare Preem (2015) Dag Hultgren, MCD AB (2015)

Intervjuer:

Av Kerstin Sköldberg, användare (2015) INTERVJU 1

1. Vilka funktioner förväntar ni er ska finnas i det nya systemet? Rangordna.

- Lagerkontroll, varningar, balans. Nivåhistorik för varje timme, volymhistorik för varje timme, temperaturhistorik för varje timme. Grafer, tabeller. Felanmälan. Pejlinformation, kanske en månad bakåt. Vilka bilar som har levererat drivmedel, bilen eller chauffören som är dålig.

2. Vilka brister finns idag? Bör åtgärdas osv.

- Man vet inte riktigt vilket som visar rätt, pejlen eller fakturan. Man skulle kunna lita på pejlen men den kan visa fel för att det registrerar alla händelser i lagret och då skulle det uppstå fel, tillexempel om lagret får leverans och det finns samtidigt en som tankar. Då kan det bli differenser.

3. Vad gillar/ogillar ni med systemet idag? Är användargränssnittet i Siteinfo något att följa? Etc.

- Vissa knappar kan tillexempel ibland inte funka. Man ska kunna summera olika drivmedel så att man vet hur mycket tillexempel bensin har kommit under en viss period.

(38)

4. Har ni några krav på hur gränssnittet ska se ut? Speciell design, någon standard vi ska följa?

- Köpinformation, leveransinformation och hur mycket det finns i lagret. Visa flera avstämningar på drivmedelslagret.

5. Vill ni ha all information ska visas direkt? Eller vill ni välja ut vilka information som ska visas?

- Nej, jag vill välja vilken information som ska visas. Men nivåhistorik och volymhistorik ska visas på samma sida. Så att man ska kunna jämföra. Temperaturhistorik och leveranshistorik på samma sida.

6. Ska det vara ett jätteenkelt gränssnitt, alltså alla funktioner och tabeller/grafer/diagram ska visas på en och samma sida?

- Jag skulle vilja kunna välja att se grafer/diagram eller inte. Men allting skulle vara bra att vara på ett och samma ställe.

INTERVJU 2

1. Vad tycker ni om den nya modellen? Är det något ni har önskat er?

- Vi tycker att det är något bra med kända och okända fel. Sådana kända fel skulle kunna skötas per automatik och det ska godkännas.

2. Finns det någon ändring ni vill att vi ska göra? Ett exempel är att ta bort en funktion som ni anser är onödig.

- Vi vill att helst pejlfel som ska skötas först (om ett sådant fel finns) eftersom det kan ta flera månader innan man fixar fel och få får man uppskatta värden för att det ska bli rätt.

3. Vad kan vi förbättra för att göra er nöjda?

- Man ska kanske döpa om kända och okända fel. För att enklare förstå vad felen handlar om.

(39)

TRITA-ICT-EX-2016:65

www.kth.se