Prototypframställning för tidrapportering i

Prototype development of a Working Time Reporting Solution in Nikki Chau Examensarbete inom teknik och management, grundnivå Kandidat Degree Project in Engineering and Management, First Level Stockholm, Sweden 2012 Kurs IK120X, 15hp TRITA-ICT-EX-2012:154

Sammanfattning SAMMANFATTNING Detta examensarbete har genomförts på företaget Navigate Consulting Business Solutions AB, ett konsultbolag som erbjuder tjänster inom affärssystem, såsom val av affärssystemslösning, implementering och förvaltning. Företaget vill utöka sitt framtida affärssystem,, genom att lägga till tidrapporteringsmodulen Oracle Time and Labor. För att ta reda på om tidsrapporteringsmodulen möter verksamhetens krav och förväntningar är det nödvändigt att företaget får en uppfattning hur systemet möjligtvis kan lämpa sig, innan de bestämmer sig för att implementera. Med detta som bakgrund och utgångspunkt syftar detta examensarbete till att visualisera den tidrapporteringsprocess och de krav som Navigate har för, genom användning av prototyp. En inkrementell och iterativ arbetsmetod har tillämpats vid utveckling av denna prototyp. Resultatet av detta examensarbete är en interaktiv prototyp över företagets tidrapporteringsprocess. Stora delar av deras krav har visualiserats, och det har totalt producerats femton skärmbilder för att utveckla prototypen. Dessa har kopplats samman och tillförts med interaktivitet genom prototypverktyget Justinmind Prototyper. Trots att det har inneburit en tidskrävande process för utveckling av prototypen har man funnit potentiella fördelar. Jämfört med stillbilder (traditionella skärmbilder), fångar en interaktiv prototyp fler aspekter av systemet som kan förmedlas till användaren. Detta skulle möjligtvis kunna vara ett effektivt säljverktyg för Navigate vid försäljning av exempelvis. För att utvecklingstiden ska kunna minskas bör därför Navigate bygga upp ett eget ramverk. I

Abstract ABSTRACT This bachelor thesis has been carried out at Navigate Consulting Business Solutions AB, a consulting firm that provides enterprise resource planning (ERP) services, such as choice of ERP system solutions, implementation and management. The company is currently looking to expand their future ERP system,, by supplementing the time reporting module Oracle Time and Labor. To find out if the system meets the business s requirements and expectations, it is necessary for the company to get an idea of how well the system may be suited before they decide to implement it. With this basis, the aim of this bachelor thesis is to visualize the time reporting process and the requirements Navigate has for Oracle E-Business Suite R12, by using a prototype. An incremental and iterative method has been applied for the development of this prototype. The result of this bachelor thesis is an interactive prototype of the company's time reporting process. Several of their requirements have been visualized, and a total of fifteen screenshots have been produced for the development of the prototype. The screenshots have been connected together and supplied with interactivity through a prototyping tool called Justinmind Prototypes. The development of the prototype has been a time consuming process, yet despite this, potential benefits have been discovered. Compared to stills (traditional screenshot), an interactive prototype captures several aspects of the system which can be conveyed to the user. This could possibly serve as an effective sales tool for Navigate in the sale of e.g. Oracle E-Business Suite R12. To reduce the development time is recommended that the company builds up its own framework. II

Förord FÖRORD Detta examensarbete om 15 hp är ett avslutande moment inom kandidatprogrammet Affärssystem vid Kungliga Tekniska högskolan. Arbetet har utförts i samarbete med Navigate Consulting Business Solutions AB under våren 2012. Ett stort tack ska främst riktas mot Mats Eriksson och Peter Johansson från Navigate. Deras stöd och engagemang har varit ovärderlig under arbetets gång. Ett särskilt tack ska riktas till Helene Wenster som bidragit med värdefulla kunskaper och tips. Jag vill också tacka min examinator Anders Sjögren som gett konstruktiv kritik och vägledning. Slutligen vill jag tacka Ida Johansson och Maria Örnjäger som genomförde deras examensarbete parallellt med mig. Det har varit en intressant resa med många nya lärdomar och intryck. Tack alla! III

Innehållsförteckning INNEHÅLLSFÖRTECKNING SAMMANFATTNING... I ABSTRACT... II FÖRORD... III FIGURFÖRTECKNING... V TABELLFÖRTECKNING... V 1 INLEDNING... 1 1.1 BAKGRUND... 1 1.2 PROBLEMFORMULERING... 2 1.3 SYFTE... 2 1.4 MÅL... 2 1.5 AVGRÄNSNINGAR... 2 2 TEORETISK REFERENSRAM... 3 2.1 PROTOTYP... 3 2.1.1 Definition... 3 2.1.2 Syfte... 3 2.1.3 Prototyper av olika karaktärer... 4 2.1.4 Prototyper av olika fokus... 5 2.1.5 Prototyper av olika aspekter... 6 2.1.6 För- & nackdelar med prototyper... 7 2.2 PROTOTYPUTVECKLINGSM ETODER... 8 2.2.1 Evolutionär... 8 2.2.2 Throw-away... 9 2.3 JUSTINMIND PROTOTYPER... 9 3 METOD/MODELL... 11 3.1 PROCESSMODELL FÖR PROTOTYPUTVECKLING... 11 3.2 UTVECKLINGSMODELL... 12 3.3 UTVECKLINGSMETOD... 13 4 RESULTAT... 15 5 ANALYS & DISKUSSION... 23 5.1 ÖVRIGT... 24 KÄLLFÖRTECKNING... 26 BILAGA A: TIDRAPPORTERING I ORACLE E-BUSINESS SUITE R12... 27 BILAGA B: KRAVSPECIF IKATION... 29 BILAGA C: SKÄRMBILDSÖVERSIKT... 31 BILAGA D: SKÄRMBILDER... 32 IV

Figurförteckning & Tabellförteckning FIGURFÖRTECKNING Figur 2.1 Hur prototyper kan skäras på olika sätt... 5 Figur 2.2 Fyra dimensioner i modellen.... 6 Figur 2.3 Prototyputvecklingsmetoder... 8 Figur 3.1 Processmodell för prototyputveckling... 11 Figur 3.2 Evolutionär utvecklingsmodell... 12 Figur 3.3 Inkrementell och iterativ utvecklingsprocess... 13 Figur 4.1 Vad prototypen avser att testa... 15 Figur 4.2 Scenariot för den centrala tidregisteringsprocessen i prototypen.... 16 Figur 4.3 Variabelanvändning i prototypen... 19 Figur 4.4 Scenariot vid granskning av inlämnad tidrapport.... 21 Figur 5.1 Tidrapporteringsflödet i Oracle EBS R12.... 27 Figur 5.2 Processflöde för att skapa tidrapport i Oracle EBS R12... 28 TABELLFÖRTECKNING Tabell 5.1 Kravspecifikation.... 30 V

Inledning 1 INLEDNING 1.1 BAKGRUND Att implementera ett affärssystem kräver mycket kapital i form av tid, pengar och kunskap. Vid utbyte av affärssystem påverkas hela verksamheten i ett företag, det är inte bara ett teknikskifte som berör vissa processer i arbetsflödet. Det är därför viktigt att säkerhetsställa att affärssystemet tillgodoser och stödjer alla affärsprocesser i företaget [1]. Innan man implementerar ett affärssystem kan man därför använda sig av en prototyp för att undersöka om det är möjligt eller lönsamt. Vad som menas med prototyp kommer att vidareutvecklas senare i denna rapport. Detta examensarbete har genomförts på företaget Navigate Consulting Business Solutions AB (Navigate) under våren 2012. Företaget är ett konsultbolag bestående av 17 anställda med en omsättning på cirka 23 miljoner kronor. De bedriver sin verksamhet inom området affärssystem och erbjuder tjänster som val av affärssystemslösning, implementering och förvaltning. De arbetar främst med produkter från Oracle och har därför också sin expertis inom det område. Navigate affärsidé är marknadens bästa kompentens för hantering av affärssystem och deras målsättning är bäst på att driva och genomföra affärssystemsprojekt [1]. Navigate har tidigare beslutat att implementera Oracle E-Business Suite R12 (Oracle EBS R12) som deras affärssystem. Moduler som kommer att användas är huvudbok, leverantörreskontra, kundreskontra, projekt, inköp och CRM. Navigate vill dessutom implementera en ytterligare modul i affärssystemet, tidrapporteringsmodulen Oracle Time and Labor (OTL). En förstudie har därför påbörjats för undersökning av systemets lämplighet. Förstudieprojektet med benämning Förstudie för implementering av tidrapporteringsmodulen OTL (FIMO) har bedrivits parallellt med detta examensarbete. Förstudieprojektet utfördes som ett examensarbete av studenter från Kungliga Tekniska högskolan. Informationsutbyte och samarbete har skett mellan dessa projekt för att kunna genomföra utvecklandet av prototypen. 1

Inledning 1.2 PROBLEMFORMULERING Som ett led i undersökning av OTLs lämplighet för Navigate är det nödvändigt att validera systemet mot företagets tidrapporteringsprocess och krav. Företaget behöver få en uppfattning på hur systemet möter verksamhetens krav och förväntning innan de bestämmer att implementera. 1.3 SYFTE Syftet med arbetet är att visualisera den tidrapporteringsprocess och de krav som Navigate har för Oracle EBS R12, genom användning av prototyp. 1.4 MÅL Målet med arbetet är att producera en interaktiv prototyp över Navigates tidrapporteringsprocess i Oracle EBS R12, med hjälp av prototypverktyget Justinmind Prototyper. 1.5 AVGRÄNSNINGAR Andra affärsprocesser inom Navigate, utöver tidrapportering, kommer inte att behandlas. Således kommer heller inte andra prototypverktyg användas under utveckling av prototypen än det som nämns tidigare, se avsnitt Mål. Denna avgränsning har gjorts på rekommendation av examinatorn. Bristen på tid att undersöka andra alternativa prototypverktyg har också varit en avgörande beslutsfaktor. 2

Teoretisk Referensram 2 TEORETISK REFERENSRAM 2.1 PROTOTYP 2.1.1 Definition Ordet prototyp är väldigt tvetydig och kan uppfattas på olika sätt beroende på vilken källa man refererar till. Nationalencyklopedins (NE) definition för ordet prototyp är följande: originalmodell, som följande former baseras på. Inom industriell produktutveckling avses försöksmodell som är riktig i funktion, konstruktion och utseende men inte i tillverkningsmetod. [2]. En annan definition av ordet prototyp får vi av Sommerville I [3]. Han ser prototyp som en första version av ett system. Den har som uppgift att demonstrera idéer, testa designförslag, undersöka problem och möjliga lösningar. Houde S och Hill C [4] tolkar ordet prototyp i likande bemärkelse. De definierar prototyp som en representation av en idé, oavsett medium. Enligt författarna utvecklar man en prototyp för att få svar på designfrågor, där design omfattar både formgivning och konstruktion. Göransson B och Gulliksen J [5] betraktar prototyp som ett fungerande system men som inte är helt färdigutvecklat. 2.1.2 Syfte En prototyp kan användas för olika typer av syften. Användningsområden kan bland annat vara: Kommunikation Demonstration av en idé Kravhantering Undersöka designproblem Utvärdera och testa lösningsförslag Modellskelett Utbildning och marknadsföring 3

Teoretisk Referensram Prototyper kan användas som ett verktyg för kommunikation mellan systemutvecklare och kund. Parterna får en gemensam grund att utgå ifrån och får förståelse på vad som egentligen ska utvecklas/levereras. En idé blir mycket mer konkret genom att demonstrera det med hjälp av en prototyp och kan därför användas i marknadsföringssyfte [6]. En annan anledning är att prototyper kan vara ett medel under kravhanteringsprocessen. Visualiserar krav men också ett sätt att samla och validera systemkrav [3]. Med en prototyp kan man simulera delar i ett system för att testa lösningsförslag eller kartlägga användarbarhetsproblem. I vissa fall kan prototypen användas som ett underlag till utveckling av ett system. Prototypen agerar som ett modellskelett som man successivt bygger ut till ett fungerande system [6]. För att utbilda användare i ett system kan man använda prototyp i utbildningssyfte. Det ger användarna en möjlighet att öva sig innan det riktiga systemet levereras. 2.1.3 Prototyper av olika karaktärer Ett sätt att dela in prototyper på är graden av detaljnivå. Det kan förklaras med hur verklighetstroget prototypen är mot slutprodukten. Till exempel kan skillnaden på graden av detaljnivå vara utseendemässiga men också datamässigt, interaktionsmässigt (animering, system respons m.m.) och funktionsmässigt. 2.1.3.1 Low fidelity En low fidelity prototyp ligger på en högre abstraktnivå och skiljer sig långt från den slutgiltiga produkten [6]. Dessa brukar framställas med hjälp av simpla verktyg som exempelvis papper och penna, post it-lappar och PowerPoint. Man brukar använda low fidelity prototyper för att generera fram krav och testa innehåll/logik i processflödet [6]. 2.1.3.2 High fidelity En high fidelity prototyp har en lägre abstraktnivå än low fidelity dvs. den har en högre grad av detaljnivå. Dessa prototyper brukar oftast vara interaktiva och datorbaserade eftersom de försöker efterlikna den slutgiltiga produkten så mycket som möjligt. High fidelity prototyper används med fördel för att testa gränssnittet och integrationen mellan 4

Teoretisk Referensram användaren och systemet [6]. Lämpar sig ofta som marknadsföringsverktyg tack vare att prototypen ser färdigutvecklat ut. 2.1.4 Prototyper av olika fokus Prototyper kan skäras på olika sätt beroende på vilket syfte de har [5], se Figur 2.1. Det kan finnas flera eller färre lager än vad som presenteras i figuren och det behöver inte nödvändigtvis vara användargränssnittet som är det översta lagret. Modellen är en förenkling av verkligheten för att få en lättare förståelse för konceptet. Vertikal Horisontell Scenario Användargränssnitt Användargränssnitt Användargränssnitt Logik Logik Logik Data Data Data Figur 2.1 Hur prototyper kan skäras på olika sätt. [5] 2.1.4.1 Vertikal Prototyper som skär vertikalt, skär på djupet där alla lager inkluderas. Det menas med prototypen utvecklas som en del av systemet fullt ut. All funktionalitet inom den delen av systemet finns representerad i en vertikal prototyp [5][7]. 2.1.4.2 Horisontell Horisontella prototyper skär endast genom ett enda lager. Till exempel kan en horisontell prototyp utvecklas för hela användargränssnittet. Men det ligger ingen funktionalitet bakom [5]. 5

Teoretisk Referensram 2.1.4.3 Scenario Scenario prototyper är ett enklare variant av vertikal prototyp, men som inte inkluderar alla lager. Den är baserad på att göra en vis typ av arbetsuppgift eller aktivitet [5]. 2.1.5 Prototyper av olika aspekter Enligt Houde S och Hill C [4] fokuserar man alldeles för mycket på prototypens egenskaper, vilket språk och verktyg som används för framställning. Denna fixering kan ge en förutfattad mening på prototypens egentliga syfte. Därför har Houde S och Hill C introducerat en annan typ av synsätt, där fokuseringen ligger i vad prototypen syftar att testa. De nämner tre dimensioner: Role (funktionalitet), Look and feel (utseende och känsla) och Implementation, se Figur 2.2. Varje dimension representerar en viktig aspekt som prototypen kan användas för att undersöka. Funktionalitet Implementation Utseende och känsla känsa Figur 2.2 Fyra dimensioner i modellen. Triangeln är ritat medvetet skev för att poängtera att ingen dimension i sig är viktigare än någon annan. [4] 2.1.5.1 Funktionalitet Denna dimension handlar om vilken roll som systemet ska spela hos användaren, dvs. vilka funktioner som systemet ska ha. En funktionalitetsprototyp beskriver funktioner som en användare ska ha nytta av [4]. Ett exempel kan vara en skiss över de aktiviteter som en webbsida tillhandahåller, exempelvis kundvagn, beräkning av frakt m.m. 6

Teoretisk Referensram 2.1.5.3 Utseende och känsla Prototyp inom denna dimension har i avsikt att utvärdera upplevelsen som användaren får vid användning. Exempelvis kan en pizzakartong agera som en look and feel prototyp för att underöka vilken form en bärbar dator ska ha [4]. 2.1.5.4 Implementation Implementationsprototyper används för att undersöka tekniska aspekter. Det handlar om tekniska lösningar för att få saker och ting att fungera. Programkod kan vara ett exempel på en implementationsprototyp. 2.1.6 För- & nackdelar med prototyper Enligt Tozer J [8] tillgodoses 80% av verksamhetens operationella behov genom att bara utnyttja 20% av systemet. Med andra ord, räcker det att bygga in 20% av kraven i prototypen för att uppnå verksamhetens huvudsakliga behov. Därför kan användning av prototyp vara ett effektivt sätt att utforska och testa nya lösningar, funktionaliteter och krav, speciellt innan man implementerar och utvecklar ett nytt system. Dessutom är det ett bra verktyg för att hitta svagheter och testa prestanda, användargränssnitt etc. [5]. Utvecklingskostnaderna kan även minskas eftersom eventuella problem och hinder redan fått en lösning tidigt i processen. Det är ett vedertaget faktum att utvecklingskostnaden ökar ju senare i processen man gör förändringar och löser problem. Men framförallt är prototyp ett kommunikationsverktyg mellan utvecklare och användare [8][9]. Olsson S, Denizhan F och Lantz A. [6] menar att prototyp kan hjälpa en att skapa en gemensam grund för ett projekt. Det är en viktig faktor för att få en förståelse vad målet egentligen är. Prototyp kan öka samspelet och förståelse mellan dem inblandade aktörerna, som exempelvis projektledare, styrelsemedlemar, investerare och andra externa intressenter. Risker eller nackdelar som finns med prototyper är att användarna kan få för höga förväntningar [9], som slutprodukten inte kan leverera. En prototyp som utvecklas på väldigt kort tid skapar förväntning om att det kommer ta lika lång tid att utveckla eller implementera det riktiga systemet [8]. Speciellt gäller det för high fidelity prototyper. Kunden ser i själva verket bara ett skal och kanske inte förstår att det egentligen inte 7

Teoretisk Referensram finns någon data eller logik bakom fasaden. Funktionaliteten i en prototyp kan vara fejkad, ett simulerat beteende i systemet som ännu inte är implementerad eller utvecklad. I slutändan handlar det om en missuppfattning om hur mycket arbete som återstår till det slutgiltiga systemet. Ett sätt att motverka detta är att man har en tydlig kommunikation mot kunden [8], att denne vet innebörden med prototypen och omfattningen av det fortsatta arbetet. En annan risk är att den prototypen som står som utgångpunkt vid utvecklande av det riktiga systemet inte stämmer överens med varandra. Vilket gör att kunden inte får den produkten som denne har förväntat sig. 2.2 PROTOTYPUTVECKLINGSMETODER Det finns två huvudkategorier inom metoder för prototyputveckling, evolutionär och throw-away. Den distinkta skillnaden mellan dessa metoder är vad det genererar för resultat, se I Figur 2.3. En annan viktig skillnad är även hur metoderna hanterar kvalitet i prototypen [3]. Evolutionär utveckling Slutgiltigt system Kravspecifikation Throw-away utveckling Prototyp + System specifikation Figur 2.3 Prototyputvecklingsmetoder. [3] 2.2.1 Evolutionär Målet med att använda evolutionär prototyputvecklingsmetod är enligt Sommerville I [3] att leverera ett slutgiltigt system till kunden och finna nya krav. Det gör att man börjar med att bygga prototypen efter användarnas krav som har högst prioritet. Göransson B och Gulliksen J [5] utrycker det att man utvecklar en kompromiss mellan det riktiga systemet och prototypen. Det kan förklaras med att prototypen utvecklas successivt till det bildar det riktiga systemet. Därför är det viktigt att välja rätt verktyg från start. Och kvaliteten måste 8

Teoretisk Referensram vara på en lämplig nivå från början eftersom allt man gör i prototypen kommer in i det slutgiltiga systemet. En nackdel med den evolutionära metoden för prototyputveckling är att man har en tendens att fixa brister än att försöka hitta andra lösningar eller alternativ. Man vågar inte riktigt kasta det man har och börja om på nytt. Vilket kan medföra att man mister en mer lämplig lösning [3]. 2.2.2 Throw-away Målet med att använda throw-away prototyputvecklingsmetod är att validera krav eller ta fram nya krav. Därför bör man börja med att utveckla prototypen efter de krav som man har minst koll på [3]. Eftersom prototypen inte kommer att återanvändas i det slutgiltiga systemet, bör man välja en teknik som är relativt billig i utvecklingskostnad [5]. Kvaliteten på prototypen behöver inte har lika hög standard jämfört med den evolutionära metoden, eftersom den ändå ska kastas. Som man ser i Figur 2.3 resulterar denna metod till en kravspecifikation för systemet. Prototypens roll i det här fallet är att agera som en modell för det slutgiltiga systemet [9]. Metoden är lämplig vid exempelvis testning av designlösningar eller utvärdering av andra aspekter som man vill ha svar på. Nackdelen med denna metod är att det finns risk att det slutgiltiga systemet inte överensstämmer med prototypen. 2.3 JUSTINMIND PROTOTYPER Justinmind Prototyper är ett programverktyg för att skapa prototyper, interaktiva mockups och wireframes. Mockups kan beskrivas som en generell modell över hur en eventuell webbplats eller programvara ska se ut. Wireframes är däremot en generell modell över funktionalitet och beteende. Tillsammans utgör de en generell benämning av ordet prototyp. Programmet erbjuder bland annat följande: Simulering av pekskärmsgester Lägg till gester som svepa, tryckoch-håll, nypa, roteringsgester etc. Interaktivitet och data simulering Lägg till interaktivitet som visa och dölj innehåll, navigering med villkor, inmatingefält etc. 9

Teoretisk Referensram Data simulering Lägg till data simulering i form av validering och sökning utan att behöva koda. Användarbarhetstest Delningstjänst som möjliggör användare att testa och kommentera prototypen. Exportering Prototypen kan exporteras till HTML format. All information om prototypen kan exporteras till Microsoft Word och OpenOffice. Verktyget Justinmind Prototyper finns för närvarande i två olika versioner. Ena som en 30-dagars testversion med stöd för all funktionalitet. Den andra är en gratisversion med begränsad funktionalitet. 10

Metod & Modell 3 METOD & MODELL 3.1 PROCESSMODELL FÖR PROTOTYPUTVECKLING Arbetet med prototypen har baserats enligt en procesmodell för prototyputveckling, se Figur 3.1. Modellen visar fyra olika moment (rektangel med runda hörn), där varje moment leder till ett resultat. (rektangel). De streckade linjerna mellan resultaten och momenten visar deras beroendeförhållande, resultatet som har tagits fram i föregående moment används till nästkommande moment. Aktiviteten inlärning av prototypverktyg har lagts till i den ursprungliga modellen, för att belysa tiden som behövdes för lära sig att använda verktyget. Men också den tiden för att undersöka verktygets möjligheter och begränsningar. Inlärning av prototypverktyg Fastställa syftet med prototyp Definiera funktionalitet i prototyp Utveckla prototyp Utvärdera prototyp Översiktlig beskrivning Prototyp Plan för prototyputveckling Utvärderingsrapport Figur 3.1 Processmodell för prototyputveckling. [3] Processen startar med att fastställa syftet med prototypen och utifrån det kunna göra en plan för prototyputveckligen. Beroende på vilket syfte prototypen har kommer utvecklingsplanen se annorlunda ut från fall till fall, eftersom olika avsikter kräver skilda typer av aktiviteter. Nästa steg är att definiera funktionaliteten på prototypen, dvs. bestämma sig vilka funktioner som ska ingå och vilka funktioner som ska lämnas utanför. Här kan man utgå ifrån kraven som kunden har på systemet för att kunna definiera funktionaliteten. Det är viktigt att de funktioner som man tar med i prototypen går i linje med prototypens syfte, för att säkerställa att man utvecklar rätt prototyp för ändamålet. Nästföljande momentet är att 11

Metod & Modell utveckla prototypen, under avsnittet Utvecklingsmetod beskrivs den utvecklingsmetod som har används under arbetet. Sista stegen i processen är att utvärdera prototypen. I det här fallet kommer resultatet av utvärderingen vara avsnittet Analys & Diskussion i denna rapport. 3.2 UTVECKLINGSMODELL Vid utvecklingen av prototypen kommer inte alla krav vara fastställda vid projektets start. Kraven kommer dessvärre uppdateras och tillkomma under processens gång. Därför har utvecklingsarbetet följt en modell som Sommerville J [3] benämner som evolutionär utvecklingsmodell, se Figur 3.2. Tanken är att en första version av prototypen utvecklas väldigt snabbt utifrån en översiktlig beskrivning. Prototypen kommer att förfinas genom flertals versioner innan den slutgiltiga versionen arbetas fram. Därför kommer aktiviteter som kravhantering, utveckling och validering att bedrivas parallellt. Det ger tid för återkoppling mellan både aktiviteterna och kunden. Notera dock att kravhantering inte har behandlats i denna rapport. Denna aktivitet är den del av förstudieprojektet som har bedrivits parallellt med detta projekt, se avsnitt Bakgrund för mer information. Parallella aktiviteter Kravhantering Första version Översiktlig beskrivning Utveckling Mellanliggande version Validering Slutgiltig version Figur 3.2 Evolutionär utvecklingsmodell. [3] 12

Metod & Modell 3.3 UTVECKLINGSMETOD Utifrån modellen som nämndes i avsnitt Utvecklingsmodell har en inkrementell och iterativ utvecklingsmetod tillämpats under utvecklingen av prototypen. Med inkrementell utveckling menas med att prototypen byggs stegvis, där man succesiv bygger på prototypen med tillägg [3]. I varje tillägg finns nya funktioner som sedan integreras med den befintliga prototypen. Definiera innehåll i prototyp Design av prototyparkitektur Specificera prototyp tillägg Bygga prototyp tillägg Validera tillägg Leverera slutgiltig prototyp Prototyp färdig? Validera prototyp Integrera tillägg Figur 3.3 Inkrementell och iterativ utvecklingsprocess. [3] Fokus har lagts på de centrala och viktigaste funktionerna. De mindre viktigare funktionerna har tillkommit senare eller inte alls beroende på om tiden har räckt till. Fördelen med denna metod är att man säkerställer att de centrala delarna kommer med från första början, vilket gör att de delarna också får mest tid för testning och bearbetning [3]. Med iterativ utveckling menas med att man upprepar samma process om och om igen för att förbättra och hitta eventuella brister eller fel. På detta sätt kan man fånga upp saker som blivit felaktiga och saker som man har missat, förhoppningsvis tidigt under utvecklingsprocessen. Nackdelen med inkrementell och iterativ utvecklingsmetod är att det kan motverka idéer till radikala förändringar, som kanske skulle leda till en bättre lösning på problemet [7]. Eftersom man alltid strävar till förbättring av det som hittills har utvecklats. Det blir därför svårt att tänka om i nya banor. Det finns också en risk att en dålig lösning bygger upp ett helt 13

Metod & Modell projekt, där brister lappas ihop på vägen. Det kan resultera till en slutprodukt med alldeles för många kompromisser. Figur 3.3 är ett exempel på hur man kan arbeta efter ett inkrementell och iterativ utvecklingsprocess. Notera att vid en inkrementell arbetsmetod arbetar man också iterativt. Detta kan uttydas genom loopen som finns i högra delen av figuren. 14

Resultat 4 RESULTAT En interaktiv prototyp har utvecklats baserat på material från förstudieprojektet FIMO. De material som har tagits del av är kravspecifikation och den framtida tidrapporteringsprocessen hos Navigate. För dem läsare som är intresserade hänvisas till FIMOs rapport för respektive dokument. Justering av Navigates framtida tidrapporteringsprocess har gjorts. Detta för att anpassa deras flöde efter systemet. En processkarta har tagits fram, denna finner ni under Bilaga A. Prototypen som har arbetats fram skulle kunna definieras som en blandning av high fidelity och low fidelity (se avsnitt Prototyper av olika karaktärer ). Med detta menas att prototypen ser verklighetstrogen ut och uppför sig som det riktiga systemet, därav high fidelity men det finns ingen riktig fungerande teknik bakom funktionaliteterna, därav low fidelity. Den är också scenariobaserad (se avsnitt Prototyper av olika fokus ) eftersom prototypen endast skär i användargränssnittslager och logiklager. Dessutom är inte all funktionalitetet inom modulen OTL inkluderad. Funktionalitet Prototypen Implementation Utseende och känsla Figur 4.1 Vad prototypen avser att testa. [4] I Figur 4.1 visar vilka aspekter som prototypen syftar att testa enligt modellen från Houde S och Hill C [4] (se avsnitt Prototyper av olika aspekter ). Figuren visar att koncentrationen har varit mot dimensionerna funktionalitet samt utseende och känsla. Och att dimensionen implementation varit helt utesluten under utvecklingen. Hela prototypen kan simulera stora delar av de krav som företaget har ställt. För ytterligare information om kraven som har berörts, se kravspecifikationslista under Bilaga B. För en fullständig lista över vilka 15

Resultat krav som Oracle EBS R12 stödjer, hänvisas till gap analysen i FIMOs rapport. I Figur 4.2 presenteras den centrala tidrapporteringsprocessen i prototypen. Den visar hur man skapar en tidrapport och skickar det vidare för godkännande. Varje rektangel representerar en skärmbild dvs. det innehåll som visas på skärmen. Totalt har femton skärmbilder producerats för att på ett så verklighetstroget sätt kunna simulera tidrapporteringsflödet i Oracle EBS R12. Gränssnittet på alla skärmbilder är baserat på Oracle EBS R12. Visuellt finns det ingenting som är annorlunda från det riktiga systemet. Login Recent Timecards Homepage OTL meny Create Timecard Review Templates Confirmation Figur 4.2 Scenariot för den centrala tidregisteringsprocessen i prototypen. Beskrivet med skärmbilder. Skärmbilderna har producerats genom en kombination av print screen (kopiera bildskärmens innehåll) från det riktiga systemet och manipulation i bildverktyget Photoshop. Dessa har sedan länkats samman i prototypverktyget Justinmind Prototyper. Med samma verktyg skapades även andra typer av interaktivitet såsom validering, data simulation, klickbara länkar och knappar m.m. 16

Resultat En fullständig karta över alla skärmbilderna som har producerats finns under Bilaga C. Kartan beskriver dessutom skärmbildernas förhållande till varandra. Nedan följer beskrivning av de skärmbilder som ingår i den centrala tidrapporteringsprocessen. I Bilaga D finns alla skärmbilderna visuellt beskrivna. 1. LOGIN Processen startar med att användaren ska logga in på Oracle EBS R12. Skärmbilden består av två inmatningsfält, User Name (användarnamn) och Password (lösenord). För att logga in behöver användaren ange rätt användarnamn och lösenord. Simulering av denna funktionalitet finns genom en when-funktion när man klickar på knappen Login. Funktionen kollar att båda fälten har rätt kombination av värden. Uppfyller de kraven skickas man vidare till nästa skärmbild, annars får man ett felmeddelande. 2. HOMEPAGE Denna skärmbild är det första som presenteras för användaren efter en lyckad inloggning. Här kan det finnas flera menyer med genvägar som leder till olika funktioner i affärssystemet. Menyn anpassas till användaren beroende på vilken behörighet som denne har. I det här fallet 17

Resultat finns det endast en meny, NC Navigate OTL Timecards. Den är klickbar som leder till nästa skärmbild OTL Meny. 3. OTL MENY Tre klickbara länkar har skapats: Recent Timecards (Senaste tidrapporter), Create Timecard (Skapa tidrapport) och Templates (Mallar). Varje länk är kopplad till respektive skärmbild, se Figur 4.2. 4. CREATE TIMECARD (SKAPA TIDRAPPORT) I den här skärmbilden registrerar man sin tid under en viss period. Det finns inmatningsfält för respektive dag i veckan, projekt (project), aktivitet (activities) och utgiftstyp (type). För att simulera integrationen med projektmodulen kan man endast välja fördefinierade projekt, aktiviteter och utgiftstyp. Varje projekt har i sin tur ett antal aktiviteter som är kopplade till sig. Det betyder att beroende på vilket projekt man väljer, blir endast vissa aktiviteter valbara. Funktionen data master har används för att kunna simulera detta beteende. Data master är Justinmind Prototypers motsvarighet till array eller databas. Information om projekt, aktivitet och utgiftstyp sparas i respektive data 18

Resultat master. Sedan kan värdena visas upp i skärmen i form av en tabell. Det går dessutom att filtrera värdena dvs. begränsa till ett antal värden som ska visas (simulering av sökningsfunktion). Genom att trycka på förstoringsglaset i kolumnen projekt visas de projekt som finns tillgängliga. Samma princip gäller för aktivitet och utgiftstyp. Vid val av aktivitet behöver användaren välja projekt först eftersom de är kopplade till varandra, som nämndes i tidigare stycke. Det går därför inte att välja aktivitet utan att först ha valt ett projekt. Knappen Recalculate summerar ihop timmar dygnvis, veckovis samt per rad. Detta görs med hjälp av att addera alla inmatningsfält per dag. All information som anges vid denna skärmbild lagras sedan i varsin variabel, som sedan kan återanvändas på flera olika ställen. I Figur 4.3 beskriver hur användning av variabler sett ut i prototypen. Figuren visar från vilka skärmbilder som information lagrats till variablerna och vilka skärmbilder som har återanvänt information från variablerna. En kontroll av inmatningsfälten görs via knappen Continue. För att komma vidare i processen måste användare ange rätt projekt, aktivitet och utgiftstyp. Review Timecard Confirmation Create Timecard Variabel Timecard 02 July Recent Timecards Submitted Figur 4.3 Variabelanvändning i prototypen. 19

Resultat 5. REVIEW (GRANSKA) I den här skärmbilden har de inmatade information från Create Timecard återanvänds. Information om timmar, projekt, aktivitet och utgiftstyp laddas från variablerna. 6. CONFIRMATION (BEKRÄFTELSE) Här får man en bekräftelse på att man har lämnat in sin tidrapport. Information om timmar, projekt, aktivitet och utgiftstyp laddas från variablerna. 20

Resultat FÖRLÄNGNING AV PROCESSEN Figur 4.4 visar en förlängning av den centrala tidrapporteringsprocessen. Denna förlängning börjar efter att man har fått bekräftelse på inlämnad tidrapport. Recent Timecard Submitted Timecard 02 July Figur 4.4 Scenariot vid granskning av inlämnad tidrapport. Processen startar efter att tidrapporten är inlämnad, dvs. efter man har gått igenom den centrala tidrapporteringsprocessen. 7. RECENT TIMECARDS SUBMITTED (SENASTE INLÄMNADE TIDRAPPORTER) Här presenteras de senaste tidrapporterna som användaren har skapat eller skickat in. På första raden är tidrapporten som skapades vid skärmbilden Create Timecard. Resterande raderna är statiska tidrapporter. De är tidrapporter som alltid finns i prototypen, en lösning för att visa hur olika tidrapporter ser ut i systemet. I kolumnen Timecard Status visas vilken status tidrapporten har, statusen kan antigen vara Approved (godkänd), Rejected (avvisad), Submitted (inlämnad) och Working (utkast, sparad men ej inlämnad). I kolumnen Details kan man klicka för att komma vidare för mer detaljerad information för den valda tidrapporten. 21

Resultat 8. TIMECARD 02 JULY (TIDRAPPORT 02 JULI) Tidrapporten som skapades vid skärmbilden Create Timecard presenteras här. Information om timmar, projekt, aktivitet och utgiftstyp laddas åter ifrån variablerna. 22

Analys & Diskussion 5 ANALYS & DISKUSSION Med hjälp av prototypverktyget Justinmind Prototyper, Phototshop och ett antal skärmbilder har man kunnat visualisera en rättvis bild över Navigates tidrapporteringsprocess i Oracle EBS R12. Stora delar av kraven har också visualiserat. Allt detta utan att ha implementerat någon del av det riktiga systemet. Arbetets syfte och mål har därför uppnåtts. Anledningen till varför inte prototypen omfattar alla de krav som Navigate har ställt, är en förklaring att det helt enkelt inte fanns tid för det. Därför blev det också en sållning bland kraven innan utvecklingsarbetet påbörjades men också under processen. Koncentrationen har varit att visualisera kraven som i första hand berört konsulten. En ytterligare förklaring är att det fanns krav som inte skulle vara möjligt att simulera med den typen av prototyp som producerades. Exempelvis fanns ett krav som gällde stöd för olika webbläsare. Sådant krav skulle kräva en annan inriktning på prototypen för att kunna simulera det. Nu i efterhand har den valda utvecklingsmetoden varit en bra utgångspunkt att arbeta efter. Det inkrementella arbetssättet passade väldigt bra när alla kraven inte var färdigställda innan arbetet startades. Fler och omarbetade krav kom in i processen allteftersom tiden gick. Det iterativa arbetssättet gjorde det lättare att ställa om sig och ändra på prototypen. Men det har även varit rörigt att arbeta på det sättet eftersom förutsättningarna alltid ändrades. Detta ledde till att visa delar som arbetats fram i början inte längre var aktuella och det man har planerat att göra behövdes revideras om. Efter många rundor av delleveranser kan det vara en utmaning att hålla reda på alla delar. Om prototypen hade varit större, dvs. omfattat mer så tror jag att det hade varit ohanterligt. Vid ett sådant projekt skulle den inkrementella metoden inte vara ett passande arbetssätt. Enligt Sommerville I [3] bör ett större projekt arbeta efter en modell som kombinerar vattenfallsmetoden och den inkrementella metoden. Utvecklingsprocessen har varit tidskrävande och frågan är om det hade tagit kortare tid att utveckla prototypen i det riktiga systemet istället. Det vill säga att göra en uppsättning i en testmiljö direkt i Oracle EBS R12, som faktiskt skulle kunna fungera som en prototyp inför en implementering. 23

Analys & Diskussion För en person som besitter den typen av kunskap om Oracle EBS R12 och OTL, skulle tidsåtgången möjligvis vara lägre jämfört med att bygga prototypen med Justinmind Prototyper. Men å andra sidan borde inte tidsåtgången minskas om personen besitter sin yttersta kunskap i prototypverktyget. Förståelse och kunskap behövs fortfarande för Oracle EBS R12 och OTL för att utvecklingen ska vara gynnsam Den största faktorn till att utvecklingsprocessen har varit så tidskrävande kan bero på att prototypen har utvecklats utifrån ett standardsystem, där funktionalitet och utseendet redan är fördefinierade. Standardsystem i det här fallet menas Oracle EBS R12. Ett system som är generell och passar för flera typer av användare. Det har lett till begränsningar och strikta regler som man är tvungen att följa, gällande bl.a. användargränssnitt, funktionalitet och beteende. Man vill inte att prototypen ska avvika från standardsystemet. Eftersom ett avvikande inom någon av dessa parametrar, kan vilseleda användaren. Det skapar en förväntning på systemet som det riktiga systemet inte kommer kunna uppnå. Med denna anledning är kanske inte utveckling av denna typ av prototyp passande till ett standardsystem. Möjligtvis fungerar det bättre att utveckla denna typ av prototyp för ett system under utveckling. 5.1 ÖVRIGT Trots tidsåtgången och restriktioner i utformande av den interaktiva prototypen, som är baserad på standardsystem, kan det fortfarande finnas potential att utnyttja. Prototypen som utvecklades under arbetet skulle kunna återavändas och lätt anpassas för andra företag. På detta sätt kan det fungera som ett effektivt säljverktyg vid försäljning av exempelvis Oracle EBS R12. Jämfört med stillbilder (traditionella skärmbilder) fångar en interaktiv prototyp fler aspekter av systemet som man kan förmedla till potentiella kunder. Om det ska vara värt i tid och ansträngning för Navigate att använda interaktiv prototyp som försäljningsverktyg bör de bygga ett eget ramverk till prototypverktyget. Med ramverk menas med att de har färdiga delar av gränssnittet som de kan återvända och anpassa efter behov. De kan till exempel vara färdiga scenarier inom fakturering där man visar hur man skickar en faktura till leverantör. Med en sådan grund skulle tidbesparingen vara mycket stor. Speciellt vid utveckling av en försäljningsprototyp för varje enskild kund. 24

Analys & Diskussion Om detta vore av intresse för Navigate bör de titta närmare på andra prototypverktyg som finns på marknaden än Justinmind Prototyper. Inte för att Justinmind Prototyper är ett dåligt verktyg för ändamålet utan mer om det kanske finns ett verktyg som skulle passa företaget bättre. Det gäller både faktorer som pris, funktionalitet och service. Värt att notera är att Justinmind för närvarande erbjuder ramverk för Oracle Fusion, som är senaste uppgraderade versionen av Oracle EBS R12. 25

Källförteckning KÄLLFÖRTECKNING [1] Navigate Consulting Business Solutions AB. [läst 2012-06-01] Tillgänglig: www.navigateconsulting.se [2] Nationalencyklopedin. [läst 2012-06-12] Tillgänglig: http://www.ne.se/lang/prototyp/287850 [3] Sommerville I. Software Engineering. 8 uppl. Harlow: Addison-Wesley; 2007. [4] Houde S, Hill C. What Do Prototypes Prototype? I: Helander M, Landauer T, Prabhu P, redaktörer. Handbook of Human-Computer Interaction. 2 [rev] uppl. Amsterdam: Elsevier Science B.V; 1997. [5] Göransson B, Gulliksen J. Användarcentrerad systemutveckling. Stockholm: Centre for User Oriented IT Design, Kungliga Tekniska högskolan; 2000. [6] Olsson S, Denizhan F, Lantz A. Prototyping. Stockholm: Centre for User Oriented IT Design, KTH; 2001. [7] Rosson MB, Carroll J. Usability Engineering: Scenario-Based Development of Human-Computer Interaction. San Francisco: Morgan Kaufmann Publishers; 2002. [8] Tozer J. Prototyping as a system development methodology: opportunities and pitfalls. Information and Software Technology. 1987; 29(5): 265 269. [9] Carey JM. Prototyping: alternative systems development methodology. Information and Software Technology. 1990; 32(2): 119 126. [10] Justinmind [läst 2012-06-20] Tillgänglig: http://www.justinmind.com 26

Bilaga A: Tidrapportering i BILAGA A: TIDRAPPORTERING I ORACLE E-BUSINESS SUITE R12 Logga in Kontrollera status på tidrapport Välj avvisad tidrapport Skapa tidrapport Välj befintlig tidrapport Korrigera tidrapport Spara tidrapport Logga ut Granska tidrapport Lämna in tidrapport Figur 5.1 Tidrapporteringsflödet i Oracle EBS R12. Se Figur 5.2 för information om vilka aktiviteter som ingår i Skapa tidrapport. 27

Bilaga A: Tidrapportering i Välj tidperiod Ange/sök och välj projekt Ange/sök och välj aktivitet Ange/sök och välj kostnadstyp Ange timmar Ange notering Figur 5.2 Processflöde för att skapa tidrapport i Oracle EBS R12 28

Bilaga B: Kravspecifikation BILAGA B: KRAVSPECIFIKATION ID Aktör Namn Beskrivning Prioritet ID001 Konsult Månadsvis/veckovis tidrapportering Systemet skall kunna hantera månadsvis samt veckovis tidrapportering Skall ID002 Konsult Tidrapportering via webb Systemet skall kunna hantera tidrapportering via webben Skall ID003 Konsult Mobil tidrapportering Systemet skall kunna hantera tidrapportering via smarta telefoner eller surfplattor Bör ID005 Konsult Projektnivå Systemet skall kunna hantera att tid läggs på projektnivå Skall ID006 Konsult Befintliga projekt Systemet skall endast tillåta tidrapportering på befintliga projekt Skall ID007 Konsult Tidrapportering på olika projekt System skall kunna hantera att tid läggs på olika projekt under samma dag Skall ID009 Konsult Aktivitetsnivå Systemet skall kunna hantera att lägga tid på aktivitetsnivå Skall ID010 Konsult Förutbestämda aktiviteter Tid skall endast kunna läggas på förutbestämda kostnadsställen Skall ID011 Konsult Period som avser projekt Aktören skall endast kunna tidrapportera på den period som projektet avser Skall ID012 Konsult Noteringar i tidrapport Aktören skall kunna göra egna noteringar i tidrapporten Bör ID013 Konsult Status Aktören skall kunna se status för tidrapport Skall ID014 Konsult Sökfunktion Aktören skall kunna söka efter projekt Skall Fortsättning på nästa sida. 29

Bilaga B: Kravspecifikation ID Aktör Namn Beskrivning Prioritet ID015 Admin Konsult Tidrapport sökfunktion Aktören skall kunna söka efter aktuella och gamla tidrapporter Skall ID016 Konsult Aktivera tidrapport Aktören skall kunna aktivera tidrapporten för godkännande Skall ID017 Konsult Aktiverad rapport Aktören skall ej kunna ändra tid i en rapport som har aktiverats för godkännande Skall ID020 Konsult Löneart Systemet skall kunna hantera att aktör kan tidrapportera för olika lönearter Skall ID029 Admin Konsult Korrigera tidrapport Aktören skall kunna korrigera tidrapport som blivit avvisad Skall ID039 Konsult Tillåt försenad tidrapport System skall kunna hantera att tidrapporterskickas in försent Skall Tabell 5.1 Kravspecifikation. Lista över de krav som har tagits med i prototypen. Kraven är ett urval från den fullständiga kravspecifikationen från förstudieprojektet FIMO. 30

Bilaga C: Skärmbildsöversikt BILAGA C: SKÄRMBILDSÖVERSIKT Login Timecard 04 June Timecard 11 June Recent Timecards Failed Login Timecard 18 June Timecard 25 June Homepage OTL meny Templates Timecard 02 July Submitted Recent Timecards Create Timecard Review Confirmation Från varje skärmbild kan man logga ut och hamnar då i skärmbild Login. Notera att det inte går att komma från Recent Timecards till Submitted Recent Timecards via gruppen Timecard (gråa rutan). 31

Bilaga D: Skärmbilder BILAGA D: SKÄRMBILDER LOGIN FAILED LOGIN HOMEPAGE 32

Bilaga D: Skärmbilder OTL MENY RECENT TIMECARDS TEMPLATES 33

Bilaga D: Skärmbilder CREATE TIMECARD Search Project Search Type Search Task Period Template 34

Bilaga D: Skärmbilder REVIEW CONFIRMATION 33

Bilaga D: Skärmbilder RECENT TIMECARDS SUBMITTED TIMECARD 02 JULY 34

Bilaga D: Skärmbilder TIMECARD 04, 11, 18, 28 JUNE 35