Förstudie för implementering av affärssystemet Oracles tidrapporteringsmodul OTL (Oracle Time and Labor)

Transkript

1 affärssystemet Oracles tidrapporteringsmodul OTL (Oracle Time and Labor) Feasibility Study for Implementation of the Oracle System Module OTL (Oracle Time and Labor) Ida Johansson Maria Örnjäger 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:153

2 Förstudie för implementering av affärssystemet Oracles tidrapporteringsmodul OTL (Oracle time and labor) Kravhantering och GAP analys för tidrapporteringsprocess i Oracle EBS R12 Ida Johansson, Maria Örnjäger Kungliga Tekniska Högskolan

3 SAMMANFATTNING Detta är en rapport för vårt examensarbete som har genomförts som en avslutning på vår kandidatutbildning Affärssystem vid Kungliga Tekniska Högskolan (KTH). Arbetet är utfört i samarbete med företaget Navigate Consulting Business Solutions AB (Navigate). De har sin främsta expertis inom Oracle E-Business Suite och har sedan tidigare valt att implementera Oracle EBS R12 i sin verksamhet. De tänkta modulerna är Huvudbok(GL), Leverantörsreskontra(AP), Kundreskontra(AR), Projektmodul(PA), Inköp och CRM. För ett konsultföretag som Navigate är det särskilt viktigt att ha en enkel och fungerande tidrapportering. Vi fick därför i uppdrag att förse Navigate med ett beslutsunderlag för att de ska kunna avgöra om Oracle Time & Labor (OTL) är ett lämpligt tidrapporteringssystem för deras verksamhet. För att uppnå arbetets syfte och mål beslutade vi att följa en utvecklingsmetod med fem olika faser. Faser med arbetssteg som genererade olika dokument, som gav oss tillräcklig information för att strukturera upp hela företaget och lättare skapa en klar bild över organisationen och dess struktur. Utifrån detta kunde vi arbeta fram ett kravdokument och sedan mappa dessa krav mot OTL. Detta resulterade i en GAP analys där man kan läsa vilka krav som hanteras utav OTL samt eventuella lösningar till de krav som ej hanteras. Resultatet av detta arbete presenteras i processkartor, en kravspecifikation, ett användningsfallsdokument samt en GAP analys. Nyckelord: Tidrapportering, processmodellering, kravhantering, användningsfall, GAP analys, OTL i

4 ABSTRACT This is a report for our thesis that was conducted as a conclusion of our bachelor degree in Business engineering at the Royal Institute of Technology (KTH). The work is done in cooperation with the firm Navigate Consulting Business Solutions AB. They have their leading expertise in Oracle E-Business Suite and has previously chosen to implement Oracle EBS R12. The modules that are planned to be implemented are general ledger (GL), accounts payable (AP), accounts receivable (AR), project module (PA), purchases, and CRM. For a consulting company like Navigate, it is particularly important to have a simple and effective time reporting process. We were therefore asked to provide new tabs with a decision-making process to determine if Oracle Time & Labor (OTL) is a useful time tracking system for their business. In order to achieve the company s aim and objective we decided to follow a development method with five different phases. The phases included a set of work steps that generated various documents, which gave us enough information to structure the entire company and helped us to create a clear picture of the organization and its structure. From this, we could work out a requirements document and then map those requirements to OTL. This resulted in a gap analysis where you can read the requirements that are handled by OTL and possible solutions to the requirements that OTL doesn t handle. The result of this work is presented in process maps, a requirement specification, an use case documents, and a GAP analysis. Keywords: Time reporting, process modeling, requirements management, use case, GAP analysis, OTL ii

5 FÖRORD Denna rapport är skriven för att redovisa vårt examensarbete som har genomförts som en avslutning på vår kandidatutbildning Affärssystem vid Kungliga Tekniska Högskolan (KTH). Arbetet är utfört i samarbete med företaget Navigate Consulting Business Solutions AB. Först och främst vill vi tacka företaget Navigate och dess medarbetare för allt stöd och värdefull kunskap som hjälpt oss att nå det slutliga resultatet. Ett särskilt tack vill vi ge till uppdragsgivare Mats Eriksson som gav oss förtroendet och som gjorde detta projekt möjligt. Vi vill även rikta ett stort tack till Peter Johansson och Heléne Wenster för stort engagemang och vägledning under hela examensarbetet. Vi vill även tacka vår examinator Anders Sjögren vid KTH för att ha givit oss inspiration och som bistått med goda råd under arbetets gång. Slutligen vill vi tacka Nikki Chau för ett fantastiskt bra och roligt samarbete som förgyllde kämpiga dagar. Arbetet har varit mycket stimulerande och lärorikt och har gett oss värdefulla erfarenheter som vi kommer ha stor användning av i vårt framtida arbete. Stockholm, augusti 2012 Ida Johansson & Maria Örnjäger iii

6 Innehållsförteckning Sammanfattning... i Abstract... ii Förord... iii Terminologi... vi 1. Inledning Bakgrund Navigate Consulting Business Solutions Övergripande syfte Målformulering Begränsningar Författarens bidrag Teori Oracle E-Business Suite (EBS) Oracle Time and Labor (OTL) Kravhantering OUM (Oracle Unified Method) GAP analys Metod Utvecklingsmetod Elicitering Analys Specifikation Management Antaganden & beroenden Resultat iv

7 4.1 Verksamhetsbeskrivning GAP analys Lösningsförslag Diskussion & Analys Slutsats Referenser Bilagor v

8 TERMINOLOGI EBS OTL PRM AP AR GL OUM Admin Elicitering As is To be Peer review GAP analys E-Business Suite Oracle Time & Labor Project resource management Accounting payables Accounting receivables General ledger Oracle Unified Method Administratör Den process och de aktiviteter som bidrar till att upptäcka och ta fram alla krav som finns inom detta projekts utveckling. Syftar till modeller över hur verksamheten ser ut i dagsläget Syftar till modeller över hur det önskade läget av verksamheten ser ut En teknik inom validering där en mindre grupp intressenter samlas för att granska kravdokument för att hitta fel och förbättra kvaliteten En metod där man mappar företagets krav mot funktionaliteter i ett system vi

9 1. INLEDNING Detta examensarbete har genomförts som en avslutning på vår kandidatutbildning Affärssystem vid Kungliga Tekniska Högskolan (KTH). Arbetet är utfört i samarbete med det svenska företaget Navigate Consulting Business Solutions AB (Navigate). Vi fick i uppdrag att göra en förstudie och undersöka lämpligheten i att installera systemet Oracle E-Business Suite för tidredovisning, därmed skulle fokus vara på modulen Oracle Time & Labor (OTL). 1.1 BAKGRUND Idag använder sig Navigate av manuella processer vid tidrapportering. Eftersom att Navigate ständigt växer börjar det bli svårt att hantera allt pappersarbete. Mycket onödig tid går också åt när konsulterna ska tidrapportera manuellt, tid som istället kan läggas på effektiv arbetstid. För ett konsultföretag som Navigate är det särskilt viktigt att ha en enkel och fungerande tidrapportering. Det är inte bara för konsultens egen del, lön som ska betalas ut, som det är av hög betydelse utan även för kunden som ska debiteras. Att skicka ut felaktiga eller försenade fakturor kommer leda till minskat förtroende och missnöje hos kund. Detta skulle kunna innebära stora konsekvenser och leda till att företaget rentutav tappar en kund. Vi fick därför i uppdrag att förse Navigate med ett beslutsunderlag för att de ska kunna avgöra om Oracle Time & Labor (OTL) är ett lämpligt tidrapporteringssystem för deras verksamhet. Navigate har sedan tidigare beslutat att implementera Oracle EBS R12 som affärssystem i sin verksamhet. Moduler som de har valt att använda är Huvudbok(GL), Leverantörsreskontra(AP), Kundreskontra(AR), Projektmodul(PA), Inköp och CRM. Arbetet kommer därmed gå ut på en granskning av tidrapporteringsmodulen OTL NAVIGATE CONSULTING BUSINESS SOLUTIONS Navigate är ett konsultföretag som startade sin verksamhet 2003 och arbetar med att driva och genomför affärssystemsprojekt. Företaget erbjuder konsulttjänster genom hela affärssystemets livscykel, såsom val av lösning, implementering och förvaltning. Bland Navigates kunder finner man företag som Skanska, SEB, Com Hem och Apoteket AB. Deras främsta expertis finns inom affärssystemet Oracle E-Business Suite men företaget har även erfarenhet och kompetens inom Microsoft Dynamics och Oracle Database. De är officiella partners till både Oracle och Microsoft. För närvarande har företaget 17 anställda fördelade på två kontor i Sverige, Stockholm och Göteborg. Navigate hade år 2010 en nettoomsättning på 18.3 miljoner kronor och vinsten för samma år hamnade på 2.0 miljoner kronor. [1]

10 1.2 ÖVERGRIPANDE SYFTE Syftet med detta arbete var att förse Navigate Consulting med ett underlag för att de skulle kunna avgöra om OTL är lämpligt tidrapporteringssystem för deras verksamhet. 1.3 MÅLFORMULERING Arbetets mål var att förse Navigate med information inför valet av system för tidregistrering. Det system som vi har granskat är Oracle EBS R12, modulen OTL. Under arbetet har vi utfört följande aktiviteter: Verksamhetsbeskrivning som inkluderar processbeskrivning av Navigates tidrapportering, intressentprofil samt intressentkategorisering. Analys och förankring av Navigates krav på tidredovisningssystem. GAP analys mellan Navigates krav och OTL s funktionalitet. 1.4 BEGRÄNSNINGAR Projektet begränsades till att ta fram och analysera funktionella såväl som icke funktionella krav samt att utföra en GAP analys. Fokus låg på Navigates tidrapporteringsprocess. 1.5 FÖRFATTARENS BIDRAG Dokument som har erhållits av Navigate är dokumentationsmall för GAP analys (AN.010 Map business requirements)

11 2. TEORI Följande kapitel behandlar den bakgrundsteori som är relevant för arbetet. 2.1 ORACLE E-BUSINESS SUITE (EBS) Vi har under projektet arbetat med Oracle E-Business Suite Oracle E-Business Suite R12 är en integrerad och komplett svit av applikationer där man som företag kan implementera antingen en modul, flera moduler eller en komplett svit. Genom att E- Business Suite R12 tillhandahåller färdiga funktioner för hela företaget kan större fokus läggas på utvecklingen av affärsverksamheten. Den ger en god insikt i företaget, hjälper att skydda och dra nytta av befintliga investeringar samt öka värdet av applikationerna och utvecklas mot nästa generations affärssystem. Oracles filosofi bakom E-Business Suite R12 är bland annat att det ska finnas ett stöd för modulär utbyggnad av skräddarsydda affärsflöden, främja lågkostnads integration med serviceinriktad och standardbaserad arkitektur samt att man kan skapa en global definition som gör att alla i hela världen får tillgång till samma uppgifter. Det betyder att E-Business Suite R12 är sig lik i hela världen, att det inte skiljer sig åt mellan olika länder. En heltäckande uppsättning av affärssystem som är integrerat på en enda datamodell. [2] ORACLE TIME AND LABOR (OTL) OTL är en tidrapporteringsmodul och tillhör Human Resource Management System (HRSM) som är en nyckelkomponent i EBS. OTL är ett en webbaserad lösning som har till sitt syfte att minimera kostnader associerade med tid och närvaro registrering genom att helt automatisera denna process. OTL kan integreras med flera andra moduler som Oracle Human Resources (HR), Oracle Internet Expenses, Oracle Project Resource Management, Oracle Payroll, Oracle Projects, Oracle Enterprise Asset Management and Oracle Procurement som kan ta del av denna information.[3] 2.2 KRAVHANTERING Innan design och implementering av ett system kan genomföras måste det finnas en förståelse över vad syftet med systemet är. Vad ska systemet göra? Ur detta växer det fram olika funktionaliteter som systemet skall kunna hantera, dessa funktionaliteter är de som benämns som krav. Med intressenternas behov i fokus arbetar man fram en skriftlig dokumentation över de krav som eliciteras. Värdet av en korrekt och väl genomarbetad kravspecifikation är stort då felaktiga och tvetydiga krav försvårar och blir mer kostsamt för kunden.[4] För att undvika detta kan man använda sig av ett iterativt arbetssätt.[5]

12 Funktionella krav fångar upp den önskade funktionaliteten, vad systemet förväntas att klara av.[5] Det vill säga tjänster som systemet bör tillhandahålla. De icke funktionella kraven specificerar egenskaper och begränsningar, kapacitet, tillförlitlighet, tillgänglighet, användbarhet, säkerhet och design.[6] Dessa krav ska kunna testas och vara mätbara.[4]

13 2.3 OUM (ORACLE UNIFIED METHOD) OUM är Oracles standard baserade metod som tillhandahåller ett omfattande projektramverk och material som stödjer Oracles växande fokus på företagens IT strategier, arkitektur och förvaltning. Fördelar med OUM är att den fokuserar mycket på att definiera verksamheten och dess behov för att lättare kunna skapa verksamhetsprocessmodeller. Oracle hävdar att med OUM kommer man kunna spara mycket tid eftersom informationstekniker och metodutvecklare med lång erfarenhet har kryddat metoden med sina kunskaper som projektdeltagare kan dra nytta av. Projekten kommer erhålla högre kvalitet eftersom man jobbar iterativt, vilket betyder att man testar under hela projektets livscykel istället för att endast göra det i slutet. Det kommer även gynnas ekonomiskt eftersom den använder sig av en Work breakdown structure som endast tillåter att man använder sig av nödvändiga aktiviteter. OUM s organiserade, definierade styrsystem hjälper till att hitta kritiska projekts behov och kommer att minska projektriskerna genom att man använder sig av iterativ implementering. OUM stödjer teknologier som tjänsteorienterad arkitektur(soa), verksamhets integration och Business Intelligence (BI). OUM har en inbyggd flexibilitet där man kombinerar aktiviteter på olika sätt så att de kan tillämpas på många olika utvecklings- och implementationsprojekt, där GAP analys är en del av det. [7] GAP ANALYS Inom informationsteknik är GAP analys oftast en studie som definierar skillnaden mellan vad vi behöver och vad som är tillgängligt. Ett gap beskriver utrymmet mellan där vi är och vart vi vill vara.[8] Det finns inga riktiga standardmallar för GAP analys utan många företag utformar sina egna mallar. Oracles mall för GAP analys tillhör OUM (Oracles Unified Method) och används vid implementerings projekt. Vid mappning av krav är det vanligt att man använder sig utav samma projektgrupp som vid framtagning utav processer och krav. GAP analysen är en uppsättning av aktiviteter som oftast behandlas i ett försäljningsstadium av ett projekt och fortsätter i den inledande fasen. Resultatet av ett genomförande resulterar i följande: En bestämmelse av hur systemfunktioner kan användas för att uppfylla de framtagna kraven. En beskrivning av "lösningar" som kan användas för att de gap som identifierats. Identifiering av eventuella anpassningar som behövs för att kunna tillfredsställa kraven

14 Lösningar till gap kan vara allt från enkla modifieringar till att man hittar alternativa vägar. Att tänka på vid framtagning av lösningar för gap är: De alternativa lösningarna ska visas för verksamhetens önskade tillstånd snarare än det nuvarande behovet. Föredra alltid att hitta alternativa vägar innan föreslå ett anpassat tillägg. När flera lösningar identifierats för ett gap bör man presentera den lösning som stödjer verksamhetens mål snarare än en enskild avdelning.[9] En GAP analys kan illustreras i ett spindeldiagram som enkelt visar skillnaden mellan det önskvärda läget och det faktiska nuläget. [10]

15 3. METOD Följande kapitel redogör för den utvecklingsmetod som har använts samt hur vi har gått tillväga under arbetets gång. 3.1 UTVECKLINGSMETOD Vi visste att en välbeprövad metod skulle underlätta vårt arbete med att ta fram ett komplett och välarbetat kravdokument. Genom de litteraturstudier som vi gjorde visade sig olika författare hantera snarlika metoder men med olika benämningar. Baserat på egna erfarenheter valde vi att följa en utvecklingsmetod som Ellen Gottesdiener presenterar i sin bok The software Requirements [11]. Nedan (Se Figur 1) illustreras metodens olika faser för kravframtagning, dessa är Elicitering, Analys, Specifikation, Validering & Management. Figur 1 Utvecklingsmodell tagen från Ellen Gottesdiener som vi följde som utvecklingsmetod

16 3.2 Genomförande Vi har under arbetets gång följt olika kravhanteringsfaser, som alla har ett antal aktiviteter med syftet att vara till hjälp vid framtagningen av ett komplett kravdokument ELICITERING Vi inledde arbetet med eliciteringsfasen som har målet att identifiera alla möjliga källor som kan komma att ställa krav på samt påverkas av det nya tidrapporteringssystemet. Detta var relativt enkelt då Navigate är ett litet företag med ca 20 anställda. [12] Datainsamling Under datainsamlingen togs ett beslutade att använda en kombination av ett par väl utvalda tekniker, för att på bästa möjliga sätt få ut de behov och krav på systemet som de olika intressenterna har. Vi valde dels att använda oss av intervjuer [13], då vi anser att det är ett bra sätt för oss att få en god översikt över verksamheten, samt att få ut önskvärda krav på det nya systemet. Det vi såg som en fördel med denna teknik är den flexibilitet som erbjuds, då vi har möjlighet att utforma den allt eftersom intervjun fortgår. Vi pratade med Navigates administratör, ledningsgrupp och konsulter. Då Navigate är ett konsultföretag fick vi ta hänsyn till att konsulterna inte alltid var tillgängliga och vi fick då använda oss av telefonintervjuer och mail. Vi hade även gruppmöten tillsammans med konsulter och ledningsgrupp där vi tillsammans kunde arbeta fram krav och modeller. Vi använde oss av interna dokument och manualer som hjälpte oss att identifiera processer samt icke- och funktionella krav. Vi använde även olika manualer och data sheets kring E-business Suite och OTL som hjälpte oss vid mappning utav krav. Identifiera källor Vi påbörjade vår utredning av verksamheten med ett möte med uppdragsgivare och handledare på Navigate. Utifrån den verksamhetsinformation som samlats in kan man sedan enkelt modellera upp företaget i en organisationskarta (Se figur 2). Att få en klar bild över verksamheten underlättar hela kravhanteringsarbetet

17 Styrelse Ledningsgrupp Underkonsult Admin Figur 2 Organisationskarta illustrerar verksamhetens olika enheter i en karta. För att kunna avgöra vilka av de olika intressenterna som kommer att påverkas av det nya systemet bör man enligt Gottesdiener göra en intressentkategorisering (Se Tabell 1). [14] Genom att kategorisera de olika intressenterna fås en bra bild över de som kommer att ställa krav på systemet. Utifrån detta har vi även kartlagt de aktörer som interagerar med systemet samt de som har relevant kunskap gällande krav. Vi strukturerade vår intressentkategorisering enligt följande: Tabell 1. Intressentkategorisering [15] Kunder Användare Övriga Sponsor Produkt- Mästare Direkta Indirekta Rådgivare Leverantörer Ledningsgrupp Ledningsgrupp er Admin Ledningsgrupp Kunder Ledningsgrupp Projektledar e Databasadministratö r Utvecklare

18 Kunder Kunder är de som ansvarar för godkännande av slutprodukten och är också de som betalar för den. Kunder består av följande subklasser: Sponsorer Är de som bemyndigar och betalar för projektet. Produktmästare Produktmästare är de som ansvarar för att slutprodukten tillgodoser de behov som finns från de olika intressenterna. Användare Användaren är de som på något sätt kommer i kontakt med systemet. Det finns två kategorier av användare, direkta och indirekta. Direkta Direkta användare är de som på något sätt ska ge eller vill ha ut information från systemet dvs. de som direkt integrerar med systemet. Indirekta Indirekta användare integrerar inte direkt med systemet utan kommer i kontakt med något som genereras av systemet som t.ex. fakturor och databaser. Övriga Under kategorin övriga benämns ofta de kunder som har något intresse för systemet eller besitter kunskap om det. Man delar in övriga i subklasserna rådgivare och leverantörer. Rådgivare Rådgivare är de som innehåller relevant kunskap om produkten. Rådgivaren besitter oftast kunskaper om aktuella verksamhetsregler som måste tas till hänsyn vid en eventuell implementering. Leverantörer Leverantörer i denna aspekt är de som utifrån kraven levererar slutprodukten. [14] Nu när vi hade klart vilka intressenter som skulle beröras av ett nytt tidrapporteringssystem var det även viktigt att ta reda på vilken slags relation de skulle ha till ett implementeringsprojekt. Nästa aktivitet blev därför att skapa en profil över vad som karaktäriserar de olika intressenterna (Se Tabell 2). [16] Eftersom Navigate själva tillhandahåller konsulter som utvecklare och databasadministratörer ingår dessa inom kategorin konsult. Detta underlättar processen med att ta ut de intressenter som

19 är viktigast för utvecklingen av kravdokumenten samt att kunna se när och till vad vi skulle kunna använda oss av de olika intressenterna. Vi beslutade att administratör, konsult och ledningsgrupp var de primära intressenterna. De fick under möten och intervjuer förklara vad de hade för intresse med att anskaffa ett nytt tidrapporteringssystem. Det var även viktigt för oss att få en uppfattning om det var något särskilt som de hoppades på att systemet skulle leverera. Här fick vi en första indikation på de krav och behov som de olika intressenterna hade samt vilka förväntningar de hade på det nya systemet. Vi strukturerade vår intressentprofil enligt följande: Tabell 2. Intressentprofil [17] Intressen t Roll Ansvarsområde Intresse Framgångskriterier Orosfaktorer Ledningsgrupp Sponsor Produktmästare Indirekt Rådgivare Betala för projektet. Spara pengar. Bättre kontroll. Effektivisera och förenkla processer för de anställda. Nöjda konsulter. Minimera klagomål från kunder. Rapporter på hur företaget går. Dyra licenser. Lång implementationstid. Dyr drift. Direkt Leverantör Tidrapportera i systemet. Effektivare sätt att tidrapportera. Minimera försenade tidrapporter. Är beroende av att systemet är tillgängligt. Bättre kontroll vid tidrapportering. Minimera fel vid löneutbetalning. Förtroende hos kund. Får ej bli ett mer komplicerat sätt att tidrapportera på. Admin Direkt Kontrollera tidrapporter. Skapa fakturor. Slippa dubbelarbete. Effektivare arbetssätt. Minimera fakturafel. Minimera tidrapportsfel. Är bekväm vid nuvarande arbetssätt och mindre van vid datoranvändning. Skapa lönespecifikationer. Minimera tid för faktura och tidrapportshanter ing. Tillförlitelse till systemet

20 Roll: Den roll som intressenten tillhör (Direkt användare, Sponsor etc.) Ansvar: Den övergripande roll intressenten har när det gäller projektet. Intresse: Behovet, önskan och förväntningarna för produkten. Framgångskriterier: på den förmågan systemet måste ha för att kunna anses som framgångsrikt. Orosfaktorer: De begränsningar som kan försvåra projektet eller hämma intressenternas acceptans av systemet [16] Kravdokument Vi skapade även ett första utkast av ett kravdokument som vi sedan har arbetat iterativt med under hela arbetets gång. Kravdokumentet, likt alla andra dokument som har genererats under arbetet, har varit öppna för kunden och möjliggjort detta arbetssätt

21 3.2.2 ANALYS Syftet med analysfasen var att ta fram olika kravmodeller för att stödja utvecklingen av de textuella beskrivningarna av kraven. De olika modellerna visualiserar kraven och har en viktig roll då de bildar en brygga mellan tekniska och affärsinriktade personer på företaget. Att använda både textuella beskrivningar och visualisering av kraven ger även en bredare förståelse för samtliga parter. [18] Modellera verksamheten För att lättare förstå hur systemet skulle stödja verksamhetsprocesser började vi med att modellera upp verksamheten. Först skapade vi en relationskarta för att illustrera den information som utbyts mellan olika aktörer, kunder och externa enheter, både indata och utdata (Se Figur 3). Relationskartan hjälpte oss att se sammanhanget mellan de olika aktörerna samt identifiera eventuella processförbättringar. Relationskartan visar de direkta systemaktörerna och informationsflödet emellan dem. Dessa aktörer är de som huvudsakligen kommer att bli berörda vid en eventuell implementering av ett nytt tidsrapporteringssystem. [19] Ändringshantering Ledningsgrupp Ändringshantering Tidrapport Lönespecifikation Ändringshantering Historik Faktura underlag Godkänd fakturaunderlag Ändringshantering Admin Faktura Tidrapport Ändringshantering Underkonsult Sänd faktura Fakturabetalning Kund Figur 3. Relationskarta visar in och utdata för aktörer, kunder och externa enheter i tidrapporteringsprocessen. Källa: [20]

22 Med hjälp av relationskartan och dess flöden kunde vi lättare modellera upp de processer som ansågs relevanta för arbetet. [21] Vi började med att kartlägga hur företaget tidrapporterar idag, vilket visade sig ske till största del manuellt. Processerna arbetades fram iterativt i samarbete med kunden där de olika intressenterna har fått förklara vad de har för arbetsuppgifter gällande tidrapportering. Det finns en skillnad hur processen såg ut beroende på om det var en konsult eller underkonsult som tidrapporterade. När underkonsulter tidrapporterar blir Navigate fakturerade, administratören tar emot en faktura och tidsunderlag, medan en vanlig konsult skickar in en tidrapport samt ett fakturaunderlag. Det fakturaunderlag som konsulten skickar in ska sedan resultera i en faktura som, efter ett godkännande av ledningsgruppen, går ut till kund. När as is processerna var godkända av kunden började vi med att kartlägga det önskade läget. I så stor mån som möjligt vill man att ledningsgruppen utesluts ur processen. Administratören får ett stort ansvar gällande ändringshantering. Här kunde vi även ta hjälp av den intressentprofil som vi tidigare framställt. De processer som har identifierats och modellerats med hjälp av BPMN notation redovisas i bilaga 1. För att vi skulle få en bra kontroll över processerna gjorde vi även mer detaljerade processbeskrivningar som finns i bilaga 2. Den processkarta som har varit särskilt viktig för vårt resultat är processen P_04, där vi har fokuserat på hur Navigate vill att tidrapporteringen för konsulten ska gå till i systemet. Processen P_04 är avsiktligen modellerad på en lägre detaljnivå än övriga processer. Med hjälp av denna process kunde vi identifiera ytterligare krav på systemet. Definiera projektets omfattning Som vi kan se i de framtagna processkartorna (se bilaga 1) finns det även aktiviteter för fakturering av kund. För att vi skulle undvika att ådra oss för utbredda krav var det viktigt för oss att komma överens med kunden om projektets omfattning. Ett hjälpmedel för detta är att modellera upp hur flödet skulle se ut med EBS implementerat i ett kontextdiagram (Se Figur 4 & 5). Ett kontextdiagram illustrerar systemet i den tänkta miljön, även de externa enheter som på något sätt ger eller tar emot information eller material från systemet. Det verifierar de direkta och indirekta användarna som har identifierats i intressentkategoriseringen. [22] Kontextdiagrammet hjälpte oss att enkelt se vad systemet behöver ta emot för indata och tillhandahålla för utdata. Detta i sin tur resulterade i att vi, tillsammans med kunden, kunde identifiera ytterligare krav. Som ett exempel kunde vi minska belastning på ledningsgruppen genom en smidigare ändringshantering

23 Vi valde att modellera ur två olika perspektiv konsulten respektive underkonsulten för att få en tydligare bild. Hämta status Registrera timmar Hämta fakturaunderlag Ledningsgrupp Ta emot felrapport EBS Godkänn faktura Aktivera rapport Ändringshantering Skapa faktura underlag Godkänd tidrapport Hämta tidrapport Admin Figur 4. Kontextdiagram I, illustrerar systemet i den tänkta miljön som på något sätt ger eller tar emot information eller material från systemet. Källa: [23]

24 Underkonsult Faktura Ta emot tidsunderlag Godkänn tidsunderlag Ledningsgrupp Tidsunderlag Fakturabetalning Felrapport EBS Ta emot felrapport Godkänn faktura Ändringshantering Hämta underlag Admin Figur 5. Kontextdiagram II, samma som figur 4 fast för underkonsult i fokus. Källa: [23] För att kunna bilda oss en uppfattning om hur produktmiljön som EBS skulle implementeras i såg ut räckte det inte med ett kontextdiagram. Vi valde att gå in på en mer detaljerad nivå för att kunna se hur de olika modulerna, som Navigate har valt att implementera, är integrerade med varandra (Se Figur 6). Det hade inte varit möjligt att fortsätta vårt arbete utan att ha en förståelse över vad Navigates visioner med det nya systemet var. Det vill säga hur det var tänkt att systemet skulle interagera moduler emellan samt med de olika aktörerna

25 OTL AP PA AR GL Figur 6. Integrationskartan visar de moduler som Navigate sedan innan avsett att implementera. Förklaring: Figur över hur de moduler som Navigate har tänkt implementera är integrerade med varandra. Verksamhetsregler I utformningen av krav var det viktigt att också ta hänsyn till verksamhetsregler. Verksamhetsreglerna sätter restriktioner på krav samt identifierar nya. Under möten tillsammans med ledningsgruppen har vi tillsammans kontrollerat kraven så att de följer de regler som råder. [24]

26 Skapa detaljerad modell över användarkraven För att få en mer detaljerad förståelse över hur aktörerna önskar utföra sina arbetsuppgifter i systemet har vi utvecklat ett användningsfallsdokument (se bilaga 3). Övergripande syfte med detta var att underlätta vårt arbete med att utvinna funktionella krav samt fungera som ett stöd för utvecklingen av GAP analysen. Det är även enligt Gottesdiener användbart för verifiering av de framställda kraven då användningsfall kan anses lättförståeliga till skillnad mot de textuella kravbeskrivningarna, i synnerhet när verifiering har förekommit över mailkontakt. [25] Vi har arbetat fram användningsfallsbeskrivningarna utifrån krav, processer och kundernas önskemål om hur tidrapporteringen ska gå till. Varje användningsfall har en koppling till ett krav. Nedan är ett exempel på hur vi har valt att strukturera användningsfallen. Se Tabell 3). För att få mer passande användningsfall valde att göra en några modifieringar av Gottesdieners mall. Här illustreras hur aktören interagerar med systemet