Förstudie för implementering av 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
87
Embed
Förstudie för implementering av affärssystemet Oracles tidrapporteringsmodul …kth.diva-portal.org/smash/get/diva2:579118/FULLTEXT01.pdf · 2012-12-19 · Förstudie för implementering
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Förstudie för implementering av affärssystemet Oracles
tidrapporteringsmodul OTL (Oracle Time and Labor)
Feasibility Study for Implementation of the Oracle System Module OTL (Oracle Time and Labor)
Ida JohanssonMaria Örnjäger
Examensarbete inom teknik och management, grundnivåKandidat
Degree Project in Engineering and Management, First Level
Stockholm, Sweden 2012Kurs IK120X, 15hp
TRITA-ICT-EX-2012:153
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
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
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 i
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
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 ii
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.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 iii
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
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 iv
Innehållsförteckning
Sammanfattning ................................................................................................................................. i
Abstract ................................................................................................................................................ ii
Förord .................................................................................................................................................. iii
Terminologi ....................................................................................................................................... vi
2. Teori ............................................................................................................................................ 3
2.1 Oracle E-Business Suite (EBS) ................................................................................................. 3
2.1.1 Oracle Time and Labor (OTL) ............................................................................................. 3
2.3.1 GAP analys .................................................................................................................................. 5
3. Metod .................................................................................................................................................. 7
4.2 GAP analys ...................................................................................................................................... 24
Elicitering Den process och de aktiviteter som bidrar till att upptäcka och ta fram alla krav som finns inom detta projekts utveckling.
As is Syftar till modeller över hur verksamheten ser ut i dagsläget
To be Syftar till modeller över hur det önskade läget av verksamheten ser ut
Peer review 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
GAP analys En metod där man mappar företagets krav mot funktionaliteter i ett system.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 1
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.
1.1.1 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]
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 2
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).
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 3
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 12.1.1. 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]
2.1.1 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]
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 4
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]
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 5
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]
2.3.1 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.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 6
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]
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 7
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.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 8
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.
3.2.1 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.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 9
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
Lednings- grupp
Lednings- grupp
Konsulter
Admin
Lednings-grupp
Kunder
Lednings- grupp
Projektledare
Databas- administratör
Utvecklare
Styrelse
Underkonsult
Ledningsgrupp
AdminKonsult
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 10
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
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 11
ä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]
Intressent
Roll Ansvars- område
Intresse Framgångs- kriterier
Oros- faktorer
Lednings-grupp
Sponsor
Produkt-
mä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 implementations-tid.
Dyr drift.
Konsult Direkt
Leverantör
Tid-rapportera i systemet.
Effektivare sätt att tidrapportera.
Bättre kontroll vid tidrapportering.
Minimera försenade tidrapporter.
Minimera fel vid löneutbetalning.
Förtroende hos kund.
Är beroende av att systemet är tillgängligt.
Får ej bli ett mer komplicerat sätt att tidrapportera på.
Admin Direkt Kontrollera tidrapporter.
Skapa fakturor.
Skapa löne-specifikationer.
Slippa dubbelarbete.
Effektivare arbetssätt.
Minimera fakturafel.
Minimera tidrapportsfel.
Minimera tid för faktura och tidrapportshantering.
Är bekväm vid nuvarande arbetssätt och mindre van vid datoranvändning.
Tillförlitelse till systemet.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 12
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: Beskrivning 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.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 13
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]
Figur 3. Relationskarta visar in och utdata för aktörer, kunder och externa enheter i tidrapporteringsprocessen. Källa: [20]
Underkonsult
Konsult
Admin
Ledningsgrupp
Tidrapport
Ändringshantering
Ändrings-hantering
HistorikFaktura underlag
Ändringshantering
Ändrings-hantering
FakturaTidrapport
Kund
Sänd faktura
Ändringshantering
Godkänd fakturaunderlagLöne-specifikation
Fakturabetalning
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 14
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.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 15
Vi valde att modellera ur två olika perspektiv konsulten respektive underkonsulten för att få en tydligare bild.
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]
Admin
EBS
LedningsgruppKonsult
Registrera timmar
Hämta tidrapport
Ändringshantering
Hämta status
Aktivera rapport
Ta emot felrapport Godkänn faktura
Hämtafakturaunderlag
Skapa faktura underlagGodkänd tidrapport
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 16
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.
Admin
EBS
LedningsgruppUnderkonsult Faktura
Hämta underlag
Ändringshantering
Tidsunderlag
Felrapport
Ta emot tidsunderlag
Godkänn tidsunderlag
Ta emot felrapport
Godkänn faktura
Fakturabetalning
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 17
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]
OTL
AP PA AR
GL
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 18
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.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 19
Tabell 3. Utdrag av användningsfall. Källa: [26]
Användningsfall
Användningsfall ID A_09
Användningsfall namn Noteringar
Krav ID 012, Noteringar i tidrapport
Aktör Konsult
Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall vara inloggad och behörig.
Huvudflöde 1. Systemet visar startsida med alternativ. – Kontrollera status på tidrapport
– Hämta felrapport
– Skapa ny tidrapport –Välj befintlig tidrapport
2. Aktören väljer Skapa ny tidrapport.
3. Systemet hämtar ny tidrapport.
4. Aktören väljer tidsperiod.
5. Systemet hämtar projekt inom vald tidsperiod.
6. Aktören väljer aktuellt projekt.
7. Systemet hämtar valt projekt.
8. Aktören väljer aktivitet.
9. Systemet hämtar aktivitet.
10. Aktören fyller i egna noteringar i kommentarfält. Sparar.
11. Systemet sparar noteringar
Resultat Systemet skall visa kommentarfält och spara noteringar som aktören har fyllt i.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 20
Prioritera krav
Då detta arbete inte hade genererat så stort antal krav ansåg vi det var hanterbart att samla intressenter på Navigate och prioritera kraven enligt MoSCoW (skall, bör, kan). [27]
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 21
3.2.3 SPECIFIKATION Under utvecklingsmetodens alla faser höll vi kraven dokumenterade och arbetade iterativt med att förfina dessa. Målet med specifikations fasen är enligt Gottesdiener att utveckla detta kravdokument och generera en specificerad förteckning över de funktionella– och icke funktionella kraven som vi tidigare har identifierat.
Dokumentation av funktionella– och icke funktionella krav
Alla krav som vi framställt från de olika kravmodellerna samt identifierat under möten med kund har sammanställts med textuella beskrivningar i ett och samma dokument, (se bilaga 4).
Vi har för varje krav angivit en aktör, en kortare beskrivning och utifrån den namngivit dem. Kraven är redovisade i tabellform enligt tabellen sedan (Se Tabell 4).
Tabell 4. Utdrag ur kravdokument.[28]
ID 001
Aktör Konsult
Namn Månadsvis/veckovis tidrapportering
Beskrivning Systemet skall kunna hantera månadsvis samt veckovis tidrapportering.
Prioritet Skall
Användningsfall A_01
GAP 1.1
Kraven har vi kopplat till ett GAP ID som skapats i GAP analysen. För varje krav som har en tillhörande användningsfallsbeskrivning har vi angett dess användningsfalls ID. Detta för att få en god spårbarhet mellan krav, användningsfall och GAP analys.
Verifiering av krav
När kravdokumentet var färdigsammanställt kontrollerade vi återigen att det inte fanns motsägelsefulla krav samt att alla krav var korrekt formulerade. Vi korrigerade felstavningar och ofullständiga krav och försäkrade oss om att vi hade definierat samtliga krav korrekt. Vi såg även till att inga dubbletter förekom i dokumentet. Kunden fick ta del av dokumentet för att verifiera att kraven var korrekta. [29]
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 22
Validering
Syftet med att validera de identifierade kraven är att kontrollera att de är tillräckligt specificerade för att säkerställa kundens behov. [30] Det vill säga att vi ville kunna garantera att kravspecifikationen verkligen beskrev vad kunden ville ha ut av modulen OTL. Vi såg även över de icke funktionella kraven så att de gav en klar bild över den avsedda modulens kapacitet och karaktär. Skall-kraven validerades tidigt i projektet då dessa var de viktigaste att få korrekta. När ett krav ändrades kontrollerade vi att prioriteringen av kravet fortfarande var rätt. Vi säkerställde att kravdokumentet gav en heltäckande grund för att kunna fortsätta med design och testning.
Peer review
En metod som vi använde oss av kallas ”Peer review”. Det innebar att vi ordnade möten med vår kund där vi tillsammans verifierade de krav vi hade identifierat. Intressenterna fick under mötena kontrollera att dokumentationen verkligen beskrev det som de ville ha ut av systemet samt att kraven var kompletta, konsistenta och av hög kvalitet.[31]
3.2.4 MANAGEMENT Under hela projektet med kravframtagning har vi arbetat med ändringshantering. Detta i och med att kunden hade nya önskemål, nya krav identifierades och krav var tvungna att omdefinieras. Vi har varit noggranna med att kontinuerligt förnya och korrigera modeller och kravdokument. Kunden har alltid hållits uppdaterad genom avstämningsmöten, mail eller telefonkontakt. [32]
3.2.5 ANTAGANDEN & BEROENDEN Vi antar att alla konsulter har tillräckligt med goda kunskaper om att tidrapportera i OTL att detta inte kommer att utgöra några hinder för en eventuell implementering.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 23
4 RESULTAT I följande avsnitt följer vi upp mål och syfte och presenterar det resultat vi har kommit fram till.
Under avsnitt 1.2 och 1.3 har vi formulerat arbetets syfte och mål.
4.1 VERKSAMHETSBESKRIVNING Verksamhetsbeskrivning som inkluderar processbeskrivning av Navigates tidrapportering, intressentprofil samt intressentkategorisering.
Resultatet i en rapport är menat att reflektera de mål som har formulerats för arbetet. Men under arbetets gång har vi kommit till insikt hur delen verksamhetsbeskrivning fallit bort från vårt resultat och gått in mer under genomförande. Det är en del av vårt arbete som har hjälpt oss att identifiera intressenter inom Navigate och gett oss en förståelse för verksamhetens behov. Den utvecklingsmetod vi har valt att följa genererar information om verksamheten genom modeller och kravdokument. Vi har därför valt att presentera verksamhetsbeskrivningen under kapitlet genomförande, då det endast är en del för att hjälpa oss att komma fram till vårt faktiska resultat.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 24
4.2 GAP ANALYS Vi har arbetat utifrån de krav vi har tagit fram och med hjälp av självstudier samt möten med konsulter inom OTL lyckats lyfta fram krav som systemet både uppfyller och inte uppfyller. Detta arbete har resulterat i en GAP analys (se bilaga 5).
I dokumentet kan man läsa om hur/om Oracle EBS R12 hanterar de krav som kunden ställt eller den alternativa lösningen som erbjuds för att uppfylla kravet. I kommentarsfälten ges eventuell extra information som är nödvändig för kunden.
Utifrån GAP analys har vi identifierat gap för följande krav:
ID003 – Mobil tidrapportering
ID008 – Aktuellt projekt
ID018 – Påminnelse
ID019 – Påminnelse efter deadline
ID023 – Avstämning mot inköpsorder
ID025 – Godkännande
ID035 – Budgeterad tid anställd
ID050 – Webbaserat gränssnitt
ID054 – Hjälpfunktion
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 25
Nedan har vi valt att på ett enkelt sätt illustrera hur kraven mappar mot systemet genom ett spindel-, cirkel- och stapeldiagram.
Vi valde att använda oss av ett spindeldiagram då vi ansåg att det skulle ge en enkel och överskådlig bild av hur varje krav mappar mot systemet. Vi influerades av det spindeldiagram som visas i artikeln ”Benchmarking and gap analysis: what is the next milestone?” [10] där de illustrerar en GAP analys över kundtillfredsställelse. Cirkeln har åtta ekrar som var och en står för varsin framgångsindikator.
Eftersom vi endast inriktat oss på en modul valde vi att göra ett spindeldiagram där vi för listar upp alla krav och visa till vilken grad var och en av dessa uppfylls av just OTL. (Se figur 7). Varje eker i spindeldiagrammet representerar ett krav. Vi ansåg att det skulle vara ett enkelt sätt att redovisa vårat resultat över hur systemet mappar mot de krav som Navigate ställt.
De krav som systemet uppfyller är grönmarkerade. Krav som systemet uppfyller, men på ett sätt som skiljer sig mot vad kunden har tänkt sig, är markerade i orange. Tillslut har vi kraven som systemet inte stödjer, de är rödmarkerade.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 26
Figur 7. Diagram I, visar hur varje krav mappar mot systemet.
0
5
10
15
20
001 002 003 004
005 006
007 008
009 010
011
012
013
014
015
016
017
018
019
020 021
022 023
024 025
026 027028 029
030 031 032 033
034 035
036 037
038 039
040
041
042
043
044
045
046
047
048
049 050
051 052
053 054
055 056 057 058 Hanteras av OTL
Finns lösning i OTL
Hanteras ej av OTL
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 27
För att ge ytterligare en bild över hur väl systemet uppfyller kundens krav har vi tagit fram tabeller över procenten krav som systemet uppfyller, inte stödjer eller erbjuder en alternativ lösning för (Se figur 8).
Figur 8. Diagram II, visar procentuellt hur kraven mappar mot systemet av det totala antalet.
Då procent kan vara lite missvisande har vi även presenterat resultatet i ett stapeldiagram. (Se figur 9). Här ser vi klart och tydligt antalet krav inom varje kategori. Av de totalt 58 kraven, hanterar OTL 50 st av dessa, 6 st finns det en lösning till och 3 krav hanteras ej av OTL.
84,75%
10,17% 5,08%
Hanteras av OTL Lösning finns Hanteras ej av OTL
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 28
Figur 9. Diagram III, visar hur många krav av de totala som hanteras, finns lösning till och ej hanteras av OTL.
50
6 3 0 5
10 15 20 25 30 35 40 45 50 55 60
Hanteras av OTL
Lösning finns
Hanteras ej av OTL
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 29
4.3 LÖSNINGSFÖRSLAG Utifrån de självstudier som vi har genomfört samt möten OTL experter har vi kunnat arbeta fram lösningsförslag på de gap som vi identifierade i GAP analysen (se Tabell 5).
Ett av de 3 krav som OTL inte hanterar kommer stödjas i Oracle´s kommande affärssystem Fusion. De andra två är ”bör krav” och känns inte som avgörande krav för att få en fungerande tidrapportering.
Till de resterande kraven finns lösningar som vi tror kunden kommer att finna som godtagbara alternativ. I några av fallen kommer det krävas ytterligare implementationer till moduler som kunden kommer behöva ta ställning till.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 30
Tabell 5. Lösningsförslag. Källa: [33]
Krav ID Krav Lösning Prioritet
ID003 Systemet bör kunna hantera tidregistrering via smarta telefoner eller ipads.
OTL erbjuder ingen applikation för tidsregistrering via smarta telefoner eller iPads.
Man kommer däremot kunna tidregistrera i både i en webapplikation eller ett offline kalkylblad.
Konsulten kommer givetvis kunna ha åtkomst till webapplikationen genom sin smartphone eller ipad.
En tidregistreringsapplikation kommer att erbjudas i Oracle Fusion som är Oracle´s kommande release av affärssystem.
Bör
ID008 Systemet skall kunna föreslå det mest aktuella/troliga projektet att tidrapportera för.
OTL erbjuder inte en sådan funktion. Detta går däremot att lösas genom två alternativ:
Alt 1: Man kan välja att använda sig utav ”Senaste tidrapport”. Man laddar då den tidrapport man senast rapporterade i.
Alt 2: Man kan skapa en mall där de projekt man är kopplad till dyker upp. Detta kräver en integration med Project Resource Management. En sådan implementation är dock överflödig för ett litet företag som Navigate.
Bör
ID018/
ID019
Systemet skall kunna sända påminnelse för tidrapportering till konsult/ Systemet skall kunna sända påminnelse för tidrapportering till konsult efter deadline.
Här kan man istället använda sig utav funktionen “Missing Timecards”, där kan man välja datum där systemet ser över vilka tidrapporter som inte kommit in.
För ett litet företag som Navigate är det därför enkelt att kunna identifiera de tidrapporter som inte kommit in inom det önskade datumet. Utifrån listan som visas kan admin manuellt skicka ut en påminnelse till de
Skall
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 31
konsulter som ännu inte skickat in sin tidrapport.
ID023 Systemet skall kunna hantera avstämning mellan redovisad tid och beställd inköpsorder.
Detta är möjligt med en integration med Service Procurement kommer att krävas.
Skall
ID025 Aktören skall kunna markera en dag, vecka, månad som godkänd.
OTL hanterar endast att man godkänner hela tidrapporter (veckovis eller månadsvis).
Bör
ID035 Systemet skall kunna visa status på budgeterad tid för varje anställd per projekt/aktivitet.
Det finns ingen synlig status på tidkortet över den budgeterade tiden. Om man vill undvika att konsulten registrerar tid över mer än den budgeterade tiden kan man lösa detta med time entry rules.
Bör
ID050 Webbaserat användargränssnitt skall kunna köras på; MS Internet Explorer 7.0 eller högre, Firefox 3.0 eller högre, Safari 4.0 eller högre.
Oracle EBS har bristande stöd för internet explorer 7.0, men stödjer de två senare versionerna. Oracle visar inga tecken på att sluta certifieras med de kommande versionerna av Internet explorer, Firefox och Safari.
Skall
ID053 Systemet skall hantera funktion med text som förklarar datafält i användargränssnittet som visas då man rör markören över det.
Oracle EBS har inte så mycket av den här funktionen men däremot finns det ett hjälpavsnitt som är kopplat till varje formulär/html-sida man är inne på. Detta skulle även kunna lösas med ett utvecklat tillägg.
Bör
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 32
5 DISKUSSION & ANALYS
Syftet med detta projekt var att förse Navigate med ett beslutsunderlag för att de skulle kunna avgöra om OTL är ett lämpligt tidrapporteringssystem för deras verksamhet.
Idag är det många IT projekt som misslyckas på grund av bristfällig kravhantering. För att lyckas med kravhantering är det därför viktigt att verkligen förstå vad kunden vill ha ut av systemet. Även om vi har följt en metod som är fasindelad och kan ses som en enkelriktad vattenfallsmetod, så valde vi att kombinera detta med ett mer iterativt arbetssätt. Det är ett beslut vi tog just för att försäkra oss om att vi hela tiden var överens med kunden och förstått deras behov. Genom regelbundna möten med kunden där vi tillsammans gick igenom framtagna modeller och kravdokument har vi kunnat lyfta fram kundens synpunkter och fått svar på våra funderingar som funnits under arbetets gång.
Under elicitering fasen var det viktiga för oss var att först få en bild över hur företaget tidrapporterar i dagsläget och hur de ville tidrapportera i framtiden. Det var en utmaning i sig att utvinna krav från de möten vi hade med kunden och vi insåg tidigt hur stor inverkan det iterativa arbetssättet skulle ha på vårt resultat. Detta har varit särskilt hjälpsamt i formuleringen av krav, då kundens uppgifter inte alltid uppfattats helt korrekt från första början.
Under analysfasen märkte vi att processerna som vi modellerade visade sig vara till större hjälp vid framtagning av krav än vi tidigare trott. Men vi kunde även i efterhand inse att vissa modeller var lite överflödiga för vårt arbete. Här gäller det att tidigt noga identifiera vilka modeller som man faktiskt kommer ha nytta utav.
Det svåra under analysfasen var att bestämma hur vi skulle begränsa oss i vårt arbete. Då tidrapportering för ett konsultföretag t.ex. går hand i hand med fakturering så var det lätt att ta sig vatten över huvudet. Vi kunde då tillsammans med kunden och med hjälp av de modeller vi tagit fram bestämma var gränsen skulle sättas.
Arbetet beskrivet ovan resulterade i ett kravdokument som vi sedan kunde ha som utgångspunkt i utformning av användningsfallen. Det svåra med användningsfallen var att formulera dem utifrån hur kunden ville interagera med systemet. Det visade sig vara ett mycket tidskrävande moment, men det var här som vi verkligen fick förståelse för kundens krav. Vid formuleringen av användningsfall blev det även mer konkret för kunden hur systemet skulle se ut, och fler krav identifierades. Här gällde det för oss att inte låta kunden överskrida de gränser som vi tidigare satt.
Kraven som vi identifierade validerades och prioriterades noggrant tillsammans med kunden. Detta lärde oss hur viktig valideringsfasen är för att kunna säkerställa att man
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 33
får ett komplett kravdokument. Kravens prioritering kommer att spela en stor roll när Navigate ska ta ett beslut om en framtida implementation.
Resultatet av detta arbete var en Gap analys och det var också den som var den största utmaningen med detta projekt, i och med att detta var ett främmande begrepp för oss. Det visade sig däremot vara en populär och framgångsrik metod som på ett enkelt sätt visualiserar hur väl systemet matchar verksamhetens krav. Här utgick vi ifrån kravdokumentet och användningsfallen för att kunna göra en jämförelse mot OTL´s funktionaliteter. Det största problemet med att mappa kraven mot OTL var den bristande kunskap vi hade om Oracle E-business Suite. Det resulterade i att mycket tid gick åt att leta information vilket inte alltid var helt enkelt. Eftersom många krav endast uppfylls när OTL är integrerat med andra moduler, då speciellt projektmodulen, behövdes kunskap om dessa också. Trots att det ibland var svårt att mappa kraven mot OTL tycker vi att det var en bra metod att arbeta med. Den visar svart på vitt vad systemet kan och inte kan hantera, på ett sätt så att även den som inte är insatt i analysen kan förstå.
Detta arbete har fått oss att inse värdet av att förstå kundens behov för att kunna säkerställa att slutprodukten verkligen ger det som kunden behöver och efterfrågar.
Men det är viktigt att tänka på att det är intressenternas rutiner som kommer att förändras och automatiseras. Det är därför kritiskt att i förändringsprojekt fånga allas önskan och behov eftersom man omöjligt kan tillfredsställa varenda individ. Vi har även fått en förståelse av uttrycket “good enough” inom implementationsprojekt. Ibland kanske kunden vill ha mer av systemet än vad de egentligen behöver vilket kan resultera i längre implementationstider och större kostnader.
Författarna har tidigare under sin utbildning utfört ett projekt inom Oracle EBS och fick då en bild över hur omfattande systemet är. Detta medförde vissa förväntningar vilka visade sig stämma ganska bra överens med resultatet. Vi hade inställningen att systemet skulle hantera de krav som Navigate ställde vilket GAP analysen också visar. Men det var även intressant att hitta brister i ett världsledande system som Oracle, vissa gap till och med förvånade oss.
Ser man till resultaten är vi medvetna om att hänsyn måste tas till de avgränsningar vi har gjort, då vi endast har koncentrerat oss funktionsmässigt på vad kunden vill ha och vad OTL kan erbjuda. Vid ett framtida beslut kommer även andra faktorer att spela in så som kostnadsanalys etc.
Under GAP analysen fick vi upp ögonen för Fusion som är Oracle´s senaste affärssystem. Vi såg att detta system skulle lösa några av de GAP som vi identifierat. Det framstod även som ett väldigt modernt och hållbart affärssystem. Detta fick oss att fundera över om man skulle sätta sikte på Fusion istället för EBS R12.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 34
Samarbetet med Navigate har inte bara hjälpt oss att få tillämpa den teoretiska kunskap vi har inhämtat under vår utbildning. Vi har även fått ta del av hur ett konsultföretag inom IT branschen fungerar vilket kommer att vara till stor nytta i det framtida arbetet.
Vidare kan man läsa projektarbetet ”Prototypframställning för tidrapportering i Oracle E-Business Suite R12” av författaren Nikki Chau och som bygger på detta projekt. Där illustreras en prototyp över tidrapporteringsprocessen i Oracle EBS R12. Prototypframställning har blivit en allt vanligare metod och är ett bra komplement till vårt arbete. Där får kunden får en första bild på hur slutprodukten kommer att se ut, vilket är ett effektivt sätt för att minska missförstånd som är mycket vanligt förekommande inom kravhantering.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 35
6 SLUTSATS
Utifrån vårt arbete kan vi se att en implementation av OTL i Navigate är fullt möjlig. Systemet hanterar den största delen av kraven men för de gap som identifieras krävs det att Navigate tar ställning till de lösningförslag vi tagit fram.
Utöver de moduler som Navigate har för avsikt att implementera kommer ytterligare moduler behöva implementeras för att systemet skall kunna uppfylla samtliga krav.
Här kommer Navigate att få väga för och nackdelar med hur viktiga kraven är mot den tid och kostnad som tillkommer. I och med att Navigate redan har beslutat att införskaffa Oracle EBS R12, skulle en integration med OTL bli betydligt smidigare än om man skulle välja ett helt annat tidrapporteringssystem.
Vid ett beslut är det även viktigt att komma ihåg att Navigates anställda redan besitter kunskaper inom Oracle. Då tidrapportering ofta ses som ett väldigt tidsödande och besvärligt moment hos anställda ska man inte göra det svårare än nödvändigt. Vid val av ett annat system än vad de anställda är vana vid kan komma att resultera i missnöjdhet och kanske till och med försämrad tidrapportering. Det som kan vara värt att tänka på då är att försöka se till att anställda är informerade om företagets policy gällande tidrapportering, samt att se till att de har alternativt får kunskap inom tidrapporteringssystemet.
Men även om EBS R12 skulle vara ett lämpligt system för Navigate skulle vi rekommendera att de istället tittade närmare på Oracle Fusion som beräknas ankomma hösten 2012.1
1 Oracle Fusion affärssystem har inte släppts på marknaden än, detta är endast ett antagande från författarnas sida.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 36
7 REFERENSER
[1] Navigate Consulting Business Solutions AB, http://www.navigateconsulting.se/index.php?option=com_content&view=article&id=78&Itemid=53&lang=sv, Hämtad 2012-06-05
[8] TeachTarget, “The difference between gap analysis and requirements analysis”, http://searchsoftwarequality.techtarget.com/answer/The-difference-between-gap-analysis-and-requirements-analysis , hämtad 2012-06-09
[9] Navigate Consulting Business Solutions AB. “AN.010 – Map business requirements”
[10] Gerald J. Balm, (1996), “Benchmarking and gap analysis: what is the next milestone?”, Benchmarking: An International Journal, Vol. 3 Iss:4pp- 28-33
[11] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005
[12] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.43-46.
[13] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.65-69.
[14] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.49-57.
[15] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.58.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 37
[16] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.59-61.
[17] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.62-63.
[18] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.117.
[19] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.118-119.
[20] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.120.
[21] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.122-124.
[22] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.127-129.
[23] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.130.
[24] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.137-141.
[25] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.150-164.
[26] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.165.
[27] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.229.
[29] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.231-233.
[30] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.261-263.
[31] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.263-269.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 38
[32] E. Gottesdiener, “The Software Requirements memory jogger”, GOAL/QPC 2005, s.281-283.
[33] Oracle® Time and Labor Implementation and User Guide, http://docs.oracle.com/cd/B34956_01/current/acrobat/120hxtig.pdf, hämtad 2012-05-20.
Förstudie för implementering av
tidrapporteringsmodulen Oracle OTL
2012-08-29 39
8 BILAGOR Bilaga 1 Processer
Bilaga 2 Processbeskrivning
Bilaga 3 Användningsfall
Bilaga 4 Kravdokument
Bilaga 5 GAP analys
Navigate Consulting
Konsult LedningsgruppAdmin1
Fyll
i tid
rapp
.mal
l
10Gr
ansk
a tid
rapp
ort
11Sk
icka
tid
rapp
ort
3Hä
mta
un
derla
g
4Gr
ansk
a un
derla
g
12Sk
apa
fakt
ura
5Än
drin
gsha
nter
ing
9Ta
em
ot
felra
ppor
t
13Go
dkän
n fa
ktur
a
14Sä
nd fa
ktur
a
7Ha
nter
a fe
lrapp
ort
6Ko
ntak
ta
kons
ult
2Sk
icka
in
tidra
pp./
fakt
.und
erla
g
AS IS
– P
_01
8Ko
ntak
ta
ledn
ings
-gr
upp
15U
ppfö
ljnin
g
Bila
ga1
Proc
esse
r
Underkonsult Navigate Consulting
Admin Ledningsgrupp1
Skic
ka in
tid
sund
erla
g +
fakt
ura
10Gr
ansk
a
11Sk
icka
tid
rapp
ort
2Hä
mta
un
derla
g
3Gr
ansk
a un
derla
g
12Sk
apa
fakt
ura
5Än
drin
gsha
nter
ing
13Go
dkän
n fa
ktur
a
14Sä
nd fa
ktur
a
9Ta
em
ot
felra
ppor
t
7Ha
nter
a fe
lrapp
ort
6Ko
ntak
ta
kons
ult
4N
y tim
tarif
f
8Ko
ntak
ta
ledn
ings
-gr
upp
15U
ppfö
ljnin
g
AS IS
– P
_02
Navigate Consulting
Admin LedningsgruppKonsult
2Hä
mta
un
derla
g
3Gr
ansk
a un
derla
g
7Ko
ntro
llera
fa
ktur
a
4Än
drin
gs-
hant
erin
g
8Go
dkän
n fa
ktur
a
9Sä
nd fa
ktur
a
1Ti
drap
port
era
1 Ti
drap
port
era
6N
y tim
tarif
f
5Ha
nter
a fe
lrapp
ort
10U
ppfö
ljnin
gTO B
E –
P_03
Navigate Consulting
Konsult
1Lo
gga
in
3 Välj
tidsp
erio
d
5Vä
lj ak
tuel
lt pr
ojek
t
7Re
gist
rera
tim
mar
13Ak
tiver
a ra
ppor
t för
go
dkän
nand
e
8Lä
gg in
no
terin
g
12Ko
ntro
llera
st
atus
på
tidra
ppor
t
10Hä
mta
fe
lrapp
ort
11Ko
rrig
era
tidra
ppor
t
14Av
sluta
tid-
rapp
orte
ring
2Sk
apa
ny
tidra
ppor
t
6Vä
lj ak
tivite
t
4Vä
lj be
fintli
g ra
ppor
t
9Sp
ara
tidra
ppor
t
TO B
E –
P_04
Bilaga 2 Processbeskrivning
Process: P_01
Nr Aktivitet Aktör AktivitetsbeskrivningNästföljandeaktivitet
1 Fyll i tidrapport Konsult Konsulten fyller i sina timmar i entidrapporteingsmall (Excelfil). Här ska detfinnas följande information: Fullständigtnamn och adress till konsulten. Referens
(projektnr, ..) och referensperson tillkunden. etc
2
2 Skicka in tidrapport Konsult Konsulten skickar in tidrapporten till admin. 3
3 Hämta underlag Admin Admin tar emot tidrapport ochfakturaunderlag.
4
4 Granska underlag Admin Admin granskar underlag och kontrolleraratt den ser korrekt ut.
5 alt. 12
5 Ändrings hantering Admin Admin gör ändringar i rapporten. Häridentifieras om ledningsgrupp eller konsult
måste kontaktas för korrektion avtidrapport.
6 alt. 8
6 Kontakta konsult Admin Admin kontaktar konsult via telefon ellermail om ändringar som måste göras.
Konsult Konsulten väljer attaktivera tidrapport för
godkännande
14
14 Avslutatidrapportering
Konsult Konsulten avslutar sitttidrapporterande genom
att logga ut.
Bilaga 3 Användningsfall Användningsfall Användningsfall ID A_01 Användningsfall namn Intervall för tidrapportering Krav ID 001, Månadsvis/veckovis tidrapportering Aktör Konsult Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Testas för vecka och månad Huvudflöde 1. Systemet visar startsida med alternativ:
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport. 12. Aktören aktiverar rapport för godkännande. 13. Systemet gör tidrapport tillgänglig för admin.
Alternativt flöde 1. Systemet visar startsida med alternativ. – Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport. 12. Aktören aktiverar rapport för godkännande. 13. Systemet gör tidrapport tillgänglig för admin.
Resultat Systemet aktiverar rapporten för godkännande och gör tidrapport tillgänglig för admin.
Användningsfall Användningsfall ID A_02 Användningsfall namn Tidrapportering via webb Krav ID 002, Tidrapportering via webb Aktör Konsult Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport. 12. Aktören aktiverar rapport för godkännande. 13. Systemet gör tidrapport tillgänglig för admin.
Alternativt flöde 1. Systemet visar startsida med alternativ – Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport. 12. Aktören avslutar tidrapportering. 13. Systemet gör tidrapport tillgänglig för admin.
Resultat Systemet aktiverar rapporten för godkännande och gör tidrapport tillgänglig för admin.
Användningsfall Användningsfall ID A_03 Användningsfall namn Tidrapportering projektnivå Krav ID 005, Projektnivå Aktör Konsult Trigger Konsult har valt att skapa ny tidrapport alt. öppna befintlig rapport samt
valt tidsperiod. Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ:
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören registrerar timmar. Sparar rapport. 9. Systemet sparar tidrapport
Resultat Systemet sparar tidrapporten på projektnivå.
Användningsfall Användningsfall ID A_04 Användningsfall namn Tidrapportering befintliga projekt Krav ID 006, Befintliga projekt Aktör Konsult Trigger Konsult har valt att skapa ny tidrapport alt. öppna befintlig rapport samt
valt tidsperiod. Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt.
Resultat Systemet skall endast visa befintliga projekt som finns inom ramarna för den valda tidsperioden.
Användningsfall Användningsfall ID A_05 Användningsfall namn Tidregistrering på olika projekt Krav ID 007, Tidrapportering på olika projekt Aktör Konsult Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Väl befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören välj projekt X. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Välj Spara. 11. Systemet sparar. 11. Välj projekt Y. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Välj Spara. 11. Systemet sparar tidrapport.
Resultat Systemet sparar tidrapporten.
Användningsfall Användningsfall ID A_06 Användningsfall namn Föreslå projekt Krav ID 008, Aktuellt projekt Aktör Konsult Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet visar värdelista över projekt
Resultat Systemet skall visa en värdelista över projekt med det mest aktuella projektet överst.
Användningsfall Användningsfall ID A_07 Användningsfall namn Tidregistrering på aktivitetsnivå Krav ID 009, Aktivitetsnivå Aktör Konsult Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport.
Resultat Systemet sparar tidrapporten på aktivitetsnivå.
Användningsfall Användningsfall ID A_08 Användningsfall namn Tidsregistrering på förutbestämda aktiviteter Krav ID 010, Förutbestämda aktiviteter Aktör Konsult Trigger Konsult har valt att skapa ny tidrapport alt. öppna befintlig rapport samt
valt tidsperiod och projekt. Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet.
Resultat Systemet skall endast visa förutbestämda aktiviteter som finns inom ramarna för den valda tidsperioden och projektet.
Användningsfall Användningsfall ID A_09 Användningsfall namn Noteringar Krav ID 012, Noteringar i tidrapport Aktör Konsult Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport –Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören fyller i egna noteringar i kommentarfält. Sparar. 11. Systemet sparar noteringar
Resultat Systemet skall visa kommentarfält och spara noteringar som aktören har fyllt i.
Användningsfall Användningsfall ID A_10 Användningsfall namn Status på tidrapport Krav ID 013, Status Aktör Konsult, Admin Förutsättningar Systemet skall vara aktivt, integrerat med projektmodulen. Aktören skall
vara inloggad och behörig. Huvudflöde 1. Systemet visar status på tidrapport för de aktiva projekten. Alternativt flöde 1. Aktören väljer Sök tidrapport.
2. Systemet tar fram sökformulär. 3. Aktören fyller i information om önskad tidrapport. Väljer Sök. 4. Systemet hämtar tidrapport. 5. Aktören väljer Status. 6. Systemet hämtar status på tidrapport.
Resultat Systemet skall visa tidrapportens status.
Användningsfall Användningsfall ID A_11 Användningsfall namn Projektsökning Krav ID 014, Sökfunktion Aktör Konsult Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och vara behörig. Huvudflöde 1. Aktören väljer Sök projekt.
2. Systemet tar fram sökformulär. 3. Aktören fyller i önskad variabel. Väljer Sök. 4. Systemet hämtar projekt som eftersökts.
Alternativt flöde 1. Aktören väljer tidsperiod. 2. Systemet tar fram sökformulär. 3. Aktören fyller i önskad variabel. Väljer Sök. 4. Systemet hämtar projekt inom vald tidsperiod.
Resultat Systemet skall visa projekt som eftersökts alt. aktuella projekt inom ramarna för den tidsperiod som valts
Användningsfall Användningsfall ID A_12 Användningsfall namn Tidrapport sökning Krav ID 015, Tidrapport sökfunktion Aktör Konsult, Admin, Ledningsgrupp Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och vara behörig. Huvudflöde 1. Aktören väljer Sök tidrapport.
2. Systemet tar fram sökformulär. 3. Aktören fyller i önskad variabel. Väljer Sök. 4. Systemet hämtar tidrapport.
Resultat Systemet skall visa tidrapport som eftersökts inom ramarna för den sökvariabel som angivits.
Användningsfall Användningsfall ID A_13 Användningsfall namn Aktivera tidrapport Krav ID 016, Aktivera tidrapport Aktör Konsult Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport. 12. Aktören aktiverar rapport för godkännande. 13. Systemet gör tidrapport tillgänglig för admin.
Alternativt flöde 1. Systemet visar startsida med alternativ. – Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport 2. Aktören väljer kontrollera status på tidrapport. 3. Systemet hämtar vald tidrapport. 4. Aktören väljer aktivera rapport. Systemet gör tidrapport tillgänglig för admin. 5. Systemet gör tidrapport tillgänglig för admin.
Resultat Systemet aktiverar rapporten för godkännande och gör tidrapport tillgänglig för admin.
Användningsfall Användningsfall ID A_14 Användningsfall namn Neka ändringar av aktiverad rapport Krav ID 017, Aktiverad rapport Aktör Konsult Trigger Aktören skall ha godkänt en tidrapport. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Sök tidrapport.
2. Systemet tar fram sökformulär. 3. Aktören fyller i önskad variabel. Väljer Sök. 4. Systemet hämtar tidrapport. 5. Aktören väljer Korrigera tidrapport. 6. Systemet visar felmeddelande.
Resultat Systemet skall neka ändringar av en aktiverad tidrapport samt visa ett felmeddelande.
Användningsfall Användningsfall ID A_15 Användningsfall namn Tidrapportera med olika lönearter Krav ID 020, Löneart Aktör Konsult Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören väljer löneart. 12. Systemet visar värdelista med förutbestämda lönearter. 13. Aktören väljer en löneart. 14. Systemet hämtar löneart. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport.
Resultat Systemet skall registrera och spara tidrapport där timmar är registrerade på olika lönearter.
Användningsfall Användningsfall ID A_16 Användningsfall namn Attestera tidrapport Krav ID 024, Attestering Aktör Konsult Trigger Aktör har aktiverat tidrapport för godkännande. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Öppna tidrapport.
Resultat Systemet skall ge en konfirmation på att den valda tiden registreras som godkänd./ Systemet skall registrera den valda tiden som godkänd Skicka iväg notifiering till konsult?
Användningsfall Användningsfall ID A_17 Användningsfall namn Godkänn tidrapport Krav ID 025, Godkännande Aktör Admin Trigger Aktör har aktiverat tidrapport för godkännande. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Öppna tidrapport.
2. Systemet hämtar tidrapport. 3. Aktören väljer dag. 4. Systemet hämtar vald dag. 4. Aktören väljer Godkänn dag. 5. Systemet godkänner vald dag.
Resultat Systemet skall ge en konfirmation på att den valda tiden registreras som godkänd./ Systemet skall registrera den valda tiden som godkänd
Användningsfall Användningsfall ID A_18 Användningsfall namn Tidrapport meddelande Krav ID 026, Elektroniskt meddelande Aktör Konsult Trigger Tidrapport blivit avvisad alt. godkänd av admin. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Godkänn tidrapport.
2. Systemet tar fram formuläret Godkänd rapport – kommentar. 3. Aktören fyller i valfri notering. Väljer Spara. 4. Systemet registrerar godkänd rapport.
Alternativt flöde 1. Aktören väljer Avvisa tidrapport. 2. Systemet tar fram formuläret Avvisad rapport – kommentar. 3. Aktören fyller i valfri notering. Väljer Spara. 4. Systemet registrerar avvisad rapport.
Resultat Systemet konfirmerar att elektroniskt meddelande skickas till berörd person angående avvisad alt. godkänd tidrapport med kommentarer.
Användningsfall Användningsfall ID A_19 Användningsfall namn Korrigering av tidrapport Krav ID 029, Korrigera tidrapport Aktör Konsult Trigger Tidrapport har blivit avvisad. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Hämta felrapport.
2. Systemet tar fram felrapport. 3. Aktören väljer Korrigera tidrapport. Gör ändringar, välj Spara. 4. Systemet sparar ändringar. 5. Aktören aktiverar rapport för godkännande. 6. Systemet gör tidrapport tillgänglig för admin.
Resultat Systemet konfirmerar att tidrapporten har korrigerats och gör den nya versionen tillgänglig för admin.
Användningsfall Användningsfall ID A_20 Användningsfall namn Tidrapport Krav ID 030, Korrigera godkänd tidrapport Aktör Admin, konsult Trigger Konsult har aktiverat tidrapporten för godkännande. Admin har godkänt
tidrapporten. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Korrigera rapport. Gör ändringar, välj Spara.
2. Systemet tar fram felrapport. 3. Aktören väljer Korrigera tidrapport. Gör ändringar, välj Spara. 4. Systemet sparar ändringar. 5. Aktören aktiverar rapport för godkännande. 6. Systemet gör tidrapport tillgänglig för admin.
Resultat Systemet konfirmerar att tidrapporten har korrigerats och gör den nya versionen tillgänglig för admin.
Användningsfall Användningsfall ID A_21 Användningsfall namn Öppna/ stäng perioder. Krav ID 031, Perioder Aktör Admin Förutsättningar Systemet skall vara aktivt, aktören skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Öppna period.
2. Systemet visar formulär Öppna/stäng period. 3. Aktören väljer period och Öppna. Välj Spara. 4. Systemet öppnar perioden och sparar ändringar.
Alternativt flöde 1. Aktören väljer Stäng period. 2. Systemet visar formulär Öppna/stäng period. 3. Aktören väljer period och Stäng. Välj Spara. 4. Systemet stänger perioden och sparar ändringar.
Resultat Systemet öppnar/stänger period.
Användningsfall Användningsfall ID A_22 Användningsfall namn Avvisa tidrapport Krav ID 036, Avvisa tidrapport Aktör Admin Trigger Det finns felaktigheter i tidrapport som skickats in för godkännande. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Öppna tidrapport.
Resultat Systemet ger en konfirmation på att tidsrapport blivit avvisad.
Användningsfall Användningsfall ID A_23 Användningsfall namn Notering vid avvisad rapport Krav ID 037, Notering avvisad tidrapport Aktör Admin Trigger Det finns felaktigheter i tidrapport som skickats in för godkännande. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Aktören väljer Öppna tidrapport.
2. Systemet hämtar tidrapport. 3. Aktören väljer Avvisa tidrapport och skriver en notering i kommentarfältet. 4. Systemet sparar notering och registrerar rapporten som avvisad.
Resultat Systemet registrerar tidrapporten som avvisad. Systemet skickar noteringen till konsulten.
Användningsfall Användningsfall ID A_24 Användningsfall namn Tillåt försenad tidrapport Krav ID 039, Tillåt försenad tidrapport Aktör Konsult Trigger Tidrapporten aktiveras för godkännande efter tidrapporteringsperiod. Förutsättningar Systemet skall vara aktivt och integrerat med projektmodulen. Aktören
skall vara inloggad och behörig. Huvudflöde 1. Systemet visar startsida med alternativ.
– Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer Skapa ny tidrapport. 3. Systemet hämtar ny tidrapport. 4. Aktören väljer tidsperiod. 5. Systemet hämtar projekt inom vald tidsperiod. 6. Aktören väljer aktuellt projekt. 7. Systemet hämtar valt projekt. 8. Aktören väljer aktivitet. 9. Systemet hämtar aktivitet. 10. Aktören registrerar timmar. Sparar rapport. 11. Systemet sparar tidrapport. 12. Aktören aktiverar rapport för godkännande. 13. Systemet gör tidrapport tillgänglig för admin.
Alternativt flöde 1. Systemet visar startsida med alternativ. – Kontrollera status på tidrapport – Hämta felrapport – Skapa ny tidrapport – Välj befintlig tidrapport 2. Aktören väljer kontrollera status på tidrapport. 3. Systemet hämtar vald tidrapport. 4. Aktören väljer aktivera rapport för godkännande. 5. Systemet gör tidrapport tillgänglig för admin.
Resultat Systemet skall ge en konfirmation på att rapporten är sparad och göra den tillgänglig för admin.
Bilaga 4 Kravdokument Funktionella krav ID 001 Aktör Konsult Namn Månadsvis/veckovis tidrapportering Beskrivning Systemet skall kunna hantera månadsvis samt
veckovis tidrapportering. Prioritet Skall Use Case A_01 GAP 1.1
ID 002 Aktör Konsult Namn Tidrapportering via webb Beskrivning Systemet skall kunna hantera tidrapportering via
webben. Prioritet Skall Use Case A_02 GAP 1.2
ID 003 Aktör Konsult Namn Mobil tidrapportering Beskrivning Systemet bör kunna hantera tidregistrering via
smarta telefoner eller iPads Prioritet Bör GAP 1.3
ID 004 Aktör Konsult Namn Almanacka Beskrivning Det bör finnas koppling till almanacka Prioritet Bör GAP 1.4
ID 005 Aktör Konsult Namn Projektnivå Beskrivning Systemet skall kunna hantera att tid läggs på
projektnivå Prioritet Skall Use Case A_03 GAP 1.5
ID 006 Aktör Konsult Namn Befintliga projekt Beskrivning Systemet skall endast tillåta tidrapportering på
befintliga projekt. Kommentar Gäller endast befintliga projekt som är kopplade
till aktören. Prioritet Skall Use Case A_04 GAP 1.6
ID 007 Aktör Konsult Namn Tidrapportering på olika projekt Beskrivning Systemet skall kunna hantera att tid läggs på
olika projekt under samma dag. Prioritet Skall Use Case A_05 GAP 1.7
ID 008 Aktör Konsult Namn Aktuellt projekt Beskrivning Systemet bör kunna föreslå det mest
aktuella/troliga projekt att tidrapportera för. Prioritet Bör Use Case A_06 GAP 1.8
ID 009 Aktör Konsult Namn Aktivitetsnivå Beskrivning Systemet skall kunna hantera att tid läggs på
aktivitetsnivå Prioritet Skall Use Case A_07 GAP 1.9
ID 010 Aktör Konsult Namn Förutbestämda aktiviteter Beskrivning Tid skall endast kunna läggas på förutbestämda
kostnadsställen Prioritet Skall Use Case A_08 GAP 1.10
ID 011 Aktör Konsult Namn Period som avser projekt Beskrivning Aktören skall endast kunna tidrapportera på den
period som projektet avser. Prioritet Skall GAP 1.11
ID 012 Aktör Konsult Namn Noteringar i tidrapport Beskrivning Aktören skall kunna göra egna noteringar i
tidrapporten. Prioritet Skall Use Case A_09 GAP 1.12
ID 013 Aktör Konsult Namn Status Beskrivning Aktören skall kunna se status för tidrapport Prioritet Skall Use Case A_10 GAP 1.13
ID 014 Aktör Konsult Namn Sökfunktion Beskrivning Aktören skall kunna söka efter projekt Prioritet Skall Use Case A_11 GAP 1.14
ID 015 Aktör Admin, Konsult Namn Tidrapport sökfunktion Beskrivning Aktören skall kunna söka efter aktuella och
gamla tidrapporter Kommentar Tidsperiod, Projekt, Aktivitet, Namn.. Prioritet Skall Use Case A_12 GAP 1.15
ID 016 Aktör Konsult Namn Aktivera tidrapport Beskrivning Aktören skall kunna aktivera tidrapporten för
godkännande Prioritet Skall Use Case A_13 GAP 1.16
ID 017 Aktör Konsult Namn Aktiverad rapport Beskrivning Aktören skall ej kunna ändra tid i en tidrapport
som har aktiverats för godkännande. Prioritet Skall Use Case A_14 GAP 1.17
ID 018 Aktör Konsult Namn Påminnelse Beskrivning Systemet skall kunna sända påminnelse för
tidrapportering till konsult Prioritet Skall GAP 1.18
ID 019 Aktör Konsult Namn Påminnelse efter deadline Beskrivning Systemet skall kunna sända påminnelse för
tidrapportering till konsult efter deadline Prioritet Skall GAP 1.19
ID 020 Aktör Konsult Namn Löneart Beskrivning Systemet skall kunna hantera att aktör kan
tidrapportera för olika lönearter Prioritet Skall Kommentar Exempel på lönearter är OB, semester, frånvaro
etc. Use Case A_15 GAP 1.20
ID 021 Aktör Ledningsgrupp Namn Frånvaro Beskrivning Systemet skall tillåta tidrapportering av annan
person än den som tidrapporten avser. Prioritet Skall Kommentar Skulle det uppstå en situation där man inte kan
tidrapportera, t.ex. vid sjukdom, skall tidrapportering kunna göras av närmsta chef.
GAP 1.21
ID 022 Aktör Admin, Avdelningschef Namn Rapport över tid Beskrivning Aktören skall ha tillgång till rapport över nedlagd
tid Prioritet Skall GAP 1.22
ID 023 Aktör Admin Namn Avstämning mot inköpsorder Beskrivning Systemet skall kunna hantera avstämning mellan
redovisad tid och beställd inköpsorder. Kommentar Aktören skall kunna göra en avstämning mellan
underkonsulters registrerade tid och den beställda inköpsordern (timmar).
Prioritet Skall GAP 1.23
ID 024 Aktör Admin, Projektledare Namn Attestering Beskrivning Aktören skall kunna attestera tidrapport Prioritet Skall Use Case A_16 GAP 1.24
ID 025 Aktör Admin Namn Godkännande Beskrivning Aktören skall kunna markera en dag, vecka eller
månad som godkänd Prioritet Bör Use Case A_17 GAP 1.25
ID 026 Aktör Admin Namn Elektroniskt meddelande Beskrivning Systemet skall kunna hantera att elektroniskt
meddelande sänds till den berörda personen vid avvisad eller godkänd tidrapport.
Prioritet Skall Kommentar Förklaring: Ett meddelande ska skickas så att
konsulten kan läsa notisen när han loggar in i systemet.
Use Case A_18 GAP 1.26
ID 027 Aktör Admin Namn Rapportuppföljning Beskrivning Aktören skall kunna göra rapportuppföljning per
konsults avtal och nedlagd tid/kostnad. Prioritet Skall GAP 1.27
ID 028 Aktör Ledningsgrupp Namn Regler Beskrivning Systemet skall kunna hantera regler kopplade till
projekt/aktivitet. Prioritet Skall Kommentar T.ex. gräns på maximalt antal registrerade
timmar per projekt/aktivitet. GAP 1.28
ID 029 Aktör Admin, Konsult Namn Korrigera tidrapport Beskrivning Aktören skall kunna korrigera tidrapport som
blivit avvisad Prioritet Skall Use Case A_19 GAP 1.29
ID 030 Aktör Admin Namn Korrigera godkänd tidrapport Beskrivning Aktören skall kunna korrigera en godkänd men ej
bokförd tidrapport Prioritet Skall Use Case A_20 GAP 1.30
ID 031 Aktör Admin Namn Perioder Beskrivning Aktören skall kunna öppna/stänga
tidrapporteringsperioder Prioritet Skall Use Case A_21 GAP 1.31
ID 032 Aktör Ledningsgrupp Namn Attestering av tidrapport Beskrivning Tidrapporter skall attesteras av minst två
personer Prioritet Skall GAP 1.32
ID 033 Aktör Admin Namn Resultatenhet Beskrivning Aktören skall kunna koppla ihop användare med
en resultatenhet Prioritet Skall GAP 1.33
ID 034 Aktör Konsult, Ledningsgrupp Namn Budgeterad tid Beskrivning Systemet skall kunna visa status på budgeterad
tid för varje projekt/aktivitet Prioritet Bör GAP 1.34
ID 035 Aktör Konsult, Ledningsgrupp Namn Budgeterad tid anställd Beskrivning Systemet skall kunna visa status på budgeterad
tid för varje anställd per projekt/aktivitet Prioritet Bör GAP 1.35
ID 036 Aktör Admin Namn Avvisa tidrapport Beskrivning Aktören skall kunna avvisa en tidrapport Prioritet Skall Use Case A_22 GAP 1.36
ID 037 Aktör Admin Namn Notering avvisad tidrapport Beskrivning Aktören skall kunna göra noteringar när en
tidrapport avvisas Prioritet Bör Use Case A_23 GAP 1.37 ID 038 Aktör Admin Namn Påminnelse för godkännande Beskrivning Systemet skall kunna sända påminnelse för
godkännande av tidrapport Prioritet Bör GAP 1.38
ID 039 Aktör Konsult Namn Tillåt försenad tidrapport Beskrivning System skall kunna hantera att tidrapporter
skickas in försent Prioritet Skall Use Case A_24 GAP 1.39
ID 040 Aktör Admin Namn Notifiering för försenade tidrapporter Beskrivning System skall automatiskt kunna generera en
värdelista över tidrapporter som ej är inskickade i tid till admin
Kommentar Admin ska få en lista på tidrapporter som inte har skickats in i tid.
Prioritet Bör GAP 1.40
ID 041 Aktör Admin Namn Faktura Beskrivning System skall automatiskt kunna generera fakturor
(AR), per projekt/aktivitet baserat på registrerade timmar
Prioritet Bör GAP 1.41
Icke funktionella ID 042 Namn Integration mot projektmodul Beskrivning Tidrapporteringsmodulen skall kunna integreras
mot projektmodulen Prioritet Skall GAP 1.42
ID 043 Namn Tillgänglighet Beskrivning Systemet skall vara tillgängligt 24h om dygnet Prioritet Skall GAP 1.43
ID 044 Namn Integration mot projektmodul Beskrivning Systemet skall lagra användarspecifika
inställningar centralt, skall ej vara beroende av vart användaren befinner sig
Prioritet Bör GAP 1.44
ID 045 Namn Audit trail Beskrivning Systemet skall kunna stödja en Audit
trail/spårbarhetsfunktion Kommentar Samtliga ändringar och registreringar skall
loggas med, användare, inloggningsställe och tidpunkt
Prioritet Skall GAP 1.45
ID 046 Namn MS Excel kompatibilitet Beskrivning Systemet skall kunna hantera att exportera
tidrapporter till MS Excel kompatibla format Prioritet Skall GAP 1.46
ID 047 Namn Tidsenhet Beskrivning Systemet skall kunna hantera tidsenheten timmar
och % Prioritet Skall GAP 1.47
ID 048 Namn Historik Beskrivning Systemet skall kunna hantera att historik sparas i
10 år Prioritet Skall GAP 1.48
ID 049 Namn Plattform Beskrivning Användargränssnitt skall kunna köras på följande
klientplattformar; Windows XP, Vista, Windows 7, MacOS X, Linux
Prioritet Skall GAP 1.49
ID 050 Namn Webbaserat gränssnitt Beskrivning Webbaserat användargränssnitt skall kunna köras
på: MS Internet Explorer 7.0 eller högre, Firefox 3.0 eller högre, Safari 4.0 eller högre
Prioritet Skall GAP 1.50
ID 051 Namn Valideringar Beskrivning Alla valideringar mot projekt och timmar skall
ske med realtidsintegrationer Prioritet Skall GAP 1.51
ID 052 Namn Säkerhet Beskrivning Systemet skall kunna hantera lösenordsregler Prioritet Bör GAP 1.52
ID 053 Namn Användargränssnitt Beskrivning Systemet skall hantera funktion med text som
förklarar datafält i användargränssnittet som visas då man rör markören över det
Prioritet Bör GAP 1.53
ID 054 Namn Hjälpfunktion Beskrivning Det skall finnas en hjälpfunktion med förklarande
texter om funktioner Prioritet Bör GAP 1.54
ID 055 Namn Roller Beskrivning Systemet skall stödja olika roller/behörigheter Kommentar Olika åtkomst till information, funktionalitet,
behörighet att uppdatera information. Prioritet Skall GAP 1.55
ID 056 Namn Backup Beskrivning Backup skall kunna göras utan att tillgång till
systemet påverkas Prioritet Bör GAP 1.56
ID 057 Namn XML Beskrivning Systemet skall kunna importera och exportera
XML filer Prioritet Skall GAP 1.57
ID 058 Namn Timkostnad Beskrivning Systemet skall kunna hantera att timkostnad
direkt belastar berört projekts aktivitet Prioritet Skall GAP 1.58