UPTEC STS07 035

Examensarbete 20 p Oktober 2007

Hur gr det egentligen?

om tidsuppfljning p Sandvik Systems Development

Hanna Wennerstrm

Abstract
Hur gr det egentligen? - om tidsuppfljning p Sandvik Systems Development How Are Things Really Going? - About Time Follow Up Reports at Sandvik Systems Development
Teknisk- naturvetenskaplig fakultet UTH-enheten Besksadress: ngstrmlaboratoriet Lgerhyddsvgen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 471 30 03 Telefax: 018 471 30 00 Hemsida: http://www.teknat.uu.se/student

Hanna Wennerstrm

This master thesis investigates the possibilities of a new Business Intelligence application at Sandvik Systems Development. The aim is to review current situation, and critical factors for such a launch, to develop a prototype and to come with further recommendations to the management team. Since Sandvik Systems Development work as a consultancy firm it is crucial to measure the time spent by the personnel, since this constitutes their entire production and thereby correlates to business revenue. Analysis of the time report system is the base for the intended business intelligence solution. The work has been conducted through literature studies, interviews, technical design, continuous testing, and is concluded by analysis. The outcome is a comprehensive report including reviews of present situation, requirements specification, success factors and recommendations. The other outcome is a prototype designed to fulfill user and management requirements. The result is that the current system is a match of the management teams current requirements, but not necessarily their goals. Thus it will suffice for a limited amount of users and purposes. Greater possibilities are to be expected with a new application, but it comes with a development cost. A new solution could attract new users and new usage areas. The launch of a new application would require further investigation, preferably around the key factors suggested in Sderstrms theoretical model and according to my recommendations.

Handledare: Linda Fernqvist mnesgranskare: Roland Bol Examinator: Elisabet Andrsdttir ISSN: 1650-8319, UPTEC STS07 035

Populrvetenskaplig sammanfattning
P nstan varje arbetsplats finns det ngon form av kontroll ver hur personalen lgger sin tid. Det kan vara faststllda arbetstider, flex med stmpelkort eller frtroendearbetstid med faststlld totaltid. P Sandvik Systems Development registreras total arbetstid, men ocks mer detaljerat hur personalen lgger sina dagliga arbetstimmar. Sandvik Systems Development fungerar som ett intern konsultbolag t Sandviks affrsomrden. De timmar som personalen lgger p kunder r p s stt deras produktion. Fr att se hur det gr fr fretaget behvs ett bra stt att sammanstlla hur personalen lgger sina timmar. Idag finns ett antal olika frsk till sdan sammanstllning, och examensarbetet har gtt ut p att se ver dessa former och se vilka frutsttningar det finns fr en mer tekniskt avancerad lsning. Arbetet har ocks besttt i att ta fram en prototyp fr att se p hur en eventuell lsning skulle kunna se ut. Resultatet r en analys av dagslget som stadkommits med hjlp av intervjuer. Med detta som bas har ett kravdokument tagits fram fr en framtida lsning i QlikView. QlikView r en mjukvara som anvnds fr att analysera stora mngder data. Med grund i teori har ven ett antal viktiga faktorer fr framgng identifierats. En prototyp i QlikView, som utarbetats, visar praktiska exempel p hur en ny lsning kan se ut, och vad den kan stadkomma. QlikView erbjuder strre mjligheter n de rapporter som finns idag, men krver ocks mer arbete, och drmed kostnader. Jag tror att man i och med infrandet av en QlikViewlsning kan vnda sig till fler anvndare och f en utkad funktionalitet. Rekommendationer avslutar rapporten dr jag uppmanar ledningsgruppen att, vid eventuell vidareutveckling av mjukvaran, frdela ansvaret p ett tydligt stt, att ta hnsyn till, och frankra arbetet i verksamheten, samt kanske viktigast av allt, se till att anvnda slutprodukten.

Innehllsfrteckning
1. Inledning ___________________________________________________________________ 4 1.1 Problemformulering ______________________________________________________ 4 1.2 Syfte _________________________________________________________________ 4 1.3 Uppdragsgivare och expertis_______________________________________________ 4 1.4 Disposition_____________________________________________________________ 4 1.5 Sprkbruk _____________________________________________________________ 5 1.6 Lista ver frkortningar och ordfrklaring _____________________________________ 6 2 Fretagspresentation__________________________________________________________ 7 2.1 Sandvik _______________________________________________________________ 7 2.2 IT p Sandvik __________________________________________________________ 7 2.3 Sandvik Systems Development_____________________________________________ 8 3 Att arbeta med Business Intelligence_____________________________________________ 9 3.1 Vad r Business Intelligence? ______________________________________________ 9 3.2 Datalager_____________________________________________________________ 10 3.2.1 vergripande strukturer ___________________________________________ 12 3.2.2 Normalisering ___________________________________________________ 12 3.2.3 Flerdimensionella kuber ___________________________________________ 13 3.3.5 Associative Query Logic___________________________________________ 14 3.4 Ml som utgngspunkt fr Business intelligence ______________________________ 14 3.5 Framgngsfaktorer vid infrande av Business Intelligence _______________________ 15 3.5.1 Vision _________________________________________________________ 15 3.5.2 Struktur________________________________________________________ 16 3.5.3 Process _______________________________________________________ 16 3.5.4 Teknik_________________________________________________________ 16 3.5.5 Individ_________________________________________________________ 16 3.5.6 Organisation____________________________________________________ 17 3.6 Sammanfattning _______________________________________________________ 17 4 Metod______________________________________________________________________ 18 4.1 Om arbetet frn problem till lsning ________________________________________ 18 4.2 Perspektiv p teorin_____________________________________________________ 18 4.3 Att utreda behov och anvndare intervjufrfarande ___________________________ 19 4.4 Avgrnsningar _________________________________________________________ 19 4.5 Sekretess ____________________________________________________________ 20 5 Beskrivning av nulge ________________________________________________________ 21 5.1 Bakgrund_____________________________________________________________ 21 5.2 Hur produceras rapporterna idag? _________________________________________ 21 5.3 Vem anvnder rapporterna? ______________________________________________ 22

5.4 Struktur och nomenklatur ________________________________________________ 22 5.5 Hur ser dagens rapporter ut? _____________________________________________ 24 6 versikt av programvara ______________________________________________________ 28 6.1 IFS__________________________________________________________________ 28 6.2 Projus _______________________________________________________________ 28 6.3 SAP Business Information Warehouse (SAP BW) _____________________________ 28 6.3.1 Laddning av data till datalagret _____________________________________ 28 6.3.2 Datalagret______________________________________________________ 28 6.3.3 Rapportering ___________________________________________________ 29 6.4 SAP-connector ________________________________________________________ 29 6.5 QlikView _____________________________________________________________ 29 7 Frutsttningar fr en ny lsning _______________________________________________ 30 7.1 Stjrnstrukturer i praktiken _______________________________________________ 30 7.2 Underrttelsecykeln i praktiken ____________________________________________ 31 7.3 Frunderskning _______________________________________________________ 31 7.3.1 Problem med dagens rapporter _____________________________________ 31 7.3.2 Lsningar p dessa problem _______________________________________ 31 7.4 Kravspecifikation _______________________________________________________ 32 7.4.1 Funktionell beskrivning____________________________________________ 32 7.4.2 Konsekvenser __________________________________________________ 32 7.4.3 Tolkning av anvndarkrav _________________________________________ 32 7.5 Kritiska framgngsfaktorer i praktiken _______________________________________ 32 7.5.1 Vision _________________________________________________________ 32 7.5.2 Struktur________________________________________________________ 33 7.5.3 Process _______________________________________________________ 33 7.5.4 Teknik_________________________________________________________ 33 7.5.5 Individ_________________________________________________________ 34 7.5.6 Organisation____________________________________________________ 34 8 Prototypen _________________________________________________________________ 35 8.1 Design och innehll _____________________________________________________ 35 8.1.1 Datakopplingar __________________________________________________ 35 8.1.2 Layout ________________________________________________________ 35 8.1.3 Att gra skningar _______________________________________________ 37 8.2 Funktioner ____________________________________________________________ 38 8.2.1 Tidskategorier __________________________________________________ 38 8.2.2 Drill-down p nskad storhet _______________________________________ 38 8.2.3 Ett antal olika visningsmjligheter ___________________________________ 39 8.2.4 Budgetjmfrelse ________________________________________________ 40 8.2.5 Extern debiteringskvot ____________________________________________ 40 9 Diskussion _________________________________________________________________ 41 9.1 Prototypens styrkor _____________________________________________________ 41 9.2 Prototypens brister _____________________________________________________ 41

9.3 Tidsrapporteringssystemet som allt bygger p ________________________________ 41 9.4 En komplicerad verklighet ________________________________________________ 42 9.5 Frdelar med en framtida QlikView-lsning __________________________________ 42 9.6 Nackdelar med en framtida QlikView-lsning _________________________________ 43 9.7 Ekonomiska aspekter ___________________________________________________ 43 10 Sammanfattande rekommendationer ___________________________________________ 44 10.1 Rekommendation till Sandvik Systems Developments ledningsgrupp _____________ 44 10.2 Fljder vid ett eventuellt infrande ________________________________________ 44 11 Kllfrteckning _____________________________________________________________ 45 11.1 Publicerat material_____________________________________________________ 45 11. 2 Opublicerat material ___________________________________________________ 45 11.3 Elektroniska kllor _____________________________________________________ 45 11.4 Muntliga kllor ________________________________________________________ 45 11.5 Figurfrteckning_______________________________________________________ 46 11.3.1 Kllfrteckning fr figurer _________________________________________ 46 12 Bilagor ____________________________________________________________________ 47 Frteckning av bilagor ______________________________________________________ 47

1. Inledning
P Sandvik Systems Development sammanstller man kontinuerligt rapporter om hur verksamheten lper, och jmfr dessa mot ml och budget. En av faktorerna man r intresserad av r hur personalen spenderar sin arbetstid. Detta r mycket viktigt att hlla reda p eftersom fretaget fungerar som ett konsultfretag, vilket innebr att personalens timmar motsvarar fretagets produktion. Hur man kan hlla koll p fretagets produktion, allts personalens arbetstimmar kommer att granskas i detalj i detta examensarbete. I nulget sker detta p ett antal olika stt, men alla har sin bas i de tidsrapporteringssystem som finns till hands. Freliggande utredning kommer att ta upp p ett antal olika faktorer kring hur den rapporterade tiden presenteras, vilka rapporter som finns, vad dessa bestr av, var informationen hmtas, vad den anvnds till och hur man kan frbttra den.

1.1 Problemformulering
Sandvik Systems Development anvnder idag ett antal olika tidrapporter som alla har olika styrkor och brister. I mitt examensarbete utreder jag mjligheten att skapa en gemensam lsning, som kombinerar styrkorna frn nuvarande rapporter, och samtidigt frsker lsa ngra av de problemen som finns med dagens rapporter. Jag undersker vilka krav som br stllas p en sdan gemensam rapport samt hur en mjukvarulsning kan svara mot dessa krav. Jag har ven utvecklat en prototyp i QlikView1 fr att ge en bild av hur denna lsning kan se ut.

1.2 Syfte
Syftet med examensarbetet r i)att utreda bakgrunden och frutsttningarna fr en eventuell QlikView-applikation ii)att utveckla en prototyp i QlikView iii)att komma med rekommendationer fr vidare arbete

1.3 Uppdragsgivare och expertis

Uppdraget har tillkommit p bestllning frn delar av Sandvik Systems management team och utfrts inom den avdelning som jobbar med Business Intelligence p Sandvik Systems Development. Bestllarna har inte varit involverade i det dagliga arbetet under uppdraget. Det dagliga arbetet har handletts av personal frn avdelningen, frmst Linda Fernqvist, som arbetar med SAP BW. Jag har ocks ftt ovrderlig hjlp av Lena Josefsson, som arbetar som QlikView-expert p Climber och Erik Pihl p DAF har ftt mig att frst den rapportstruktur som finns p fretaget idag. Flera andra har ocks bidragit med experthjlp inom sitt omrde.

1.4 Disposition
Under Fretagspresentation ger jag en versyn av Sandvik och hur IT-verksamheten r koordinerad. Jag presenterar ven min uppdragsgivare, Sandvik Systems Development.
1

en mjukvara fr analys, frklaras senare

Att arbeta med Business Intelligence r den teoretiska grunden fr hur man kan tnka runt Business Intelligence. Avsnittet ger en referensram till viktiga begrepp, och presenterar analysverktyg som jag senare valt att ta hjlp av fr att presentera mina resultat. Beskrivning av nulge r en analys av lget kring de rapporter som finns idag. I Metod-delen resonerar jag kring hur jag valt att g till vga under arbetets gng samt vilka praktiska problem som jag tagit stllning till I Frutsttningar fr en framtida lsning har jag frskt sammanstlla det underskande arbete jag utfrt p ett s konkret stt som mjligt. Eftersom arbetet varit abstrakt p mnga stt har jag valt att ta hjlp av de presenterade teoretiska analysmodellerna. Avsnittet Prototyp beskriver den prototyp jag tagit fram. Diskussion r mitt stt att problematisera kring mina resultat. Hr diskuterar jag fljder och problem kring ett eventuellt skarpt infrande av systemet. Sammanfattande rekommendationer finns sist i arbetet och bestr av konkreta rd och slutsatser till utrednings bestllare, allts Sandvik Systems Developments ledningsgrupp.

1.5 Sprkbruk
Mycket av det material jag tar upp r datorrelaterade termer. Och de flesta sdana r p engelska. Jag har skrivit rapporten p svenska, men det har p mnga stllen smugit sig in datorsvengelska i texten. Exempel p detta r trigga, query, default och in house. Mlgruppen fr min text r dels ngon med kunskap motsvarande STS-programmets studenter och dels personalen p SSD. Det r min uppfattning att min mlgrupp frstr dessa typer av engelska datortermer. Jag har samlat ord och frkortningar som jag uppfattar som antingen utanfr mlgruppens kunskapsomrde eller som srskilt viktiga fr frstelse av uppsatsens innehll i en ordlista i stycket nedan. Vissa ord anvnds synonymt i texten fr att f ett varierat sprk. Begreppet datastrukturer anvnds bde allmnt och syftar p den struktur som data har (hur det r format, ihopkopplat etcetera) och specifikt i teori och analys som syftandes p en beskrivning av en srskilt struktur (exempelvis stjrnmodell som r synonymt med kubstruktur). Det kategorisystem som utvecklats tidstyper benmns som tidsuppdelningen eller tidskategorisystemet och finns bifogat i en bilaga (som r borttagen i denna version). Ordbruket kring de rapporter som finns kan ocks verka frvirrande. Det finns huvudsakligen fyra olika rapportformer som nmns; Bex-rapporter, tv sorters Excelrapporter samt min QlikView-prototyp. Jag har frskt att vid olika tillfllen som de nmns tydliggra vilken rapport som avses, men hr kommer ytterligare frtydningar. D jag skriver Excel-rapporten avses den rapport som produceras av DAF om jag inte specifikt skriver ngot annat. QlikView-rapporten benmns ven som prototypen och applikationen.

1.6 Lista ver frkortningar och ordfrklaring

1NF 2NF 3NF AQL BCNF BEx frsta normalformen andra normalformen tredje normalformen Associative Query Language Boyce-Codds normalform Business Explorer, ett rapportverktyg som finns i SAP BW. Detta r ven ett av de befintliga rapportverktygen p Sandvik Sysytems Development idag. Det finns tv aktuella BEx-rapporter aktuella fr mitt arbete, benmnda Scorecard och Project Follow Up. Business Intelligence, begreppet frklaras i kapitel 3 Business Warehouse r SAPs data warehouse-milj Team code fr den gemensamma ekonomiavdelningen p Sandvik Systems Development och Sandvik Information Technology det engelska ordet fr att borra anvnds fr att beskriva skning ned i datamngden fr att hitta de specifika detaljer som efterfrgas Entity Relationship Entity Relationship Modeling det finns ingen helt trffande svensk versttning; overksam, utan syfte, tekniskt stillastende och att g p tomgng r ngra exempel. I texten anvnds ordet oversatt som en kategori av tid d man inte r allokerad till en srskild uppgift, allts icke-produktiv tid. Online Analytical Processing r den beskrivande term som anvnds fr komplex analys av det data man hmtar frn ett datalager QlikView, programmet beskrivs i texten, i genomgngen av programvara ett script r en textfil som innehller kommandon till ett program eller operativsystem. I texten anvnds ordet om den textfil i QlikView dr man skriver kod som sedan exekveras d scriptet laddas Sandvik Systems Development Sandvik Information Technology Systems Applications and Products in Data Processes, SAP, r idag ett av vrldens strsta affrssystem med ett stort antal olika funktionsmoduler P SSD tillhr medarbetarna ett team. Detta team benmns med en bokstavskombination, dr alla p SSD-team brjar med bokstaven L, men annars utan strre logik . Antalet bokstver markerar hierarkin, exempel LC (Competence) ligger ver LCF (Microsoft). Varje team har en kompetenschef (ven benmnd teamchef), vars engelska titel r team manager strategi som innebr att man antingen brjar frn detalj- eller helhetsperspektiv och jobbar sig sedan antingen upp frn detaljerna eller ned frn helheten

BI BW DAF drilla ER ERM idle

OLAP QV script

SSD SIT SAP team code

top downbottom up

2 Fretagspresentation
Jag har skrivit examensarbetet fr Sandvik Systems Development (SSD). Eftersom deras kunder enbart utgrs av andra Sandvikbolag och eftersom att mycket p bolaget pverkas av koncernen i stort har jag valt att, frutom en beskrivning av SSD, ge en kort introduktion ven till Sandvik i stort.

2.1 Sandvik
Sandvik har funnits sedan 1862 och r en verkstadskoncern med produkter som r vrldsledande position i sina branscher. Sandvik finns representerat i 130 lnder ver hela vrlden och har ca 42 000 anstllda. Hela Sandvik Group omsatte 2006 ca 72 miljarder kronor. Sandviks krnverksamhet r olika typer av materialteknik inom tre huvudomrden, som var och en representeras av ett eget affrsomrde: Verktyg i hrdmetall och snabbstl fr metallbearbetning samt mnen och komponenter i hrdmetall. Bolaget som framstller dessa r Sandvik Tooling. Maskiner och verktyg fr bergavverkning och gruvdrift, vilket r Sandvik Mining and Constructions verksamhetsomrde Rostfria och hglegerade stl, specialmetaller, motstndsmaterial samt processystem. Dessa material utvecklas och produceras av Sandvik Material Technology. (Sandviks hemsida, 2007-08-13)

2.2 IT p Sandvik
Sandvik har tv fristende bolag fr att utveckla, leverera och skta driften av fretagets IT-lsningar. Sandvik Information Technology har hand om hrdvara, driftsfrgor och service. Sandvik Systems Development utvecklar mjukvara och producerar interna systemlsningar. Utver detta har de tre producerande bolagen egen IT-verksamhet, som oftast fungerar som bestllarsida gentemot IT-bolagen. All IT-verksamhet inom Sandvik Group koordineras av fretagets Chief Information Officer. De tre affrsomrdena (Tooling, SMT och SMC) har varsin respektive CIO som r understlld honom, och det r ven VD:arna fr IT-bolagen Sandvik Information Technology och Sandvik Systems Development. (The Sandvik IT Portal, 2007-08-13)

Figur 1- IT-koordineringen p Sandvik

2.3 Sandvik Systems Development

Sandvik Systems Development (SSD) r Sandviks systemutvecklingsbolag. SSD har runt 350 anstllda varav 210 i Sandviken och 5 i Gimo, resten r utplacerade p SSD-kontor vrlden om. SSD:s uppgift r att i nra samarbete med koncernens affrsomrden och bolag stdja dem med verksamhetsnra och innovativa IT-utvecklingar. Bolagets verksamhet omfattar analyser och utredningar, projektledning, systemutveckling, implementation och frvaltning av system. De arbetar i en internationell milj med Sandvikprojekt ver hela vrlden. SSD fungerar som ett konsultbolag, och har Sandvikbolagen som enda kund. SSD har nyligen ndrat hela sin organisationsstruktur till en s kallad matrisorganisation. Det innebr att organisationen r strukturerad i tv dimensioner, dels r personalen uppdelad i team, efter kompetens, som leds av en teamchef. Utver detta r man allokerad till ett aktuellt projekt eller leverans dr det finns en leveranschef. Vissa verksamheter faller utanfr den ramen, och dit hr exempelvis vergripande funktioner som HR, Sales & Marketing, vissa servicefunktioner samt ledningsgruppen. (SSD:s intrant, 2007-08-13)

3 Att arbeta med Business Intelligence

Under denna rubrik ska jag redogra fr ett antal olika faktorer kring Business Intelligence och hur man kan arbeta med det. Jag brjar med att redogra ett antal grundlggande frgor om vad data, information och Business Intelligence r, och vad som r relationen mellan begreppen. Informationen som ligger till grunden fr Business Intelligence mste tnkas igenom innan man brjar arbeta med det praktiska arbetet. En modell fr hur man kan lgga upp det analysarbetet presenteras genom en s kallad underrttelsecykel. I de flesta fall inhmtas informationen som anvnds frn ngon typ av lagringsklla. Eftersom det ofta rr sig om stora datakllor med olika faktorer och dimensioner (som kommer sig av att de frsker beskriva komplexa system, som exempelvis en hel organisation eller en hel leveransprocess) s anvnder man sig ofta av ett lagringsmedium kallat ett datalager (eng. data warehouse). Ett datalager har nmligen lagringsstrukturer fr mer komplex data n en vanlig databas. Jag beskriver drfr olika begrepp som gller lagring och modellering av datalager. Det r ven viktigt att frst varfr man anvnder sig av Business Intelligence. Den vanligaste och viktigaste anledningen r att det ger ett konkret och strukturerat stt att arbeta runt de ml som finns med verksamheten. Drfr behandlar jag mlarbete i nsta avsnitt. D ges konkreta tips p hur ml ska vara utformade s att de blir effektiva. Detta r ett mycket viktigt grundarbete som r helt avgrande fr verksamheten som bedrivs och ngot som br behandlas innan man brjar med implementeringen av Business Intelligence d BI-systemet kommer att vara avhngigt av att mlen r tydligt formulerade. Nr man valt att infra ett tekniskt Business Intelligence-system finns det en hel del faktorer som r viktiga att tnka igenom fr att undvika fallgropar. Peter Sderstrm har tagit fasta p ett antal sdana faktorer. Hans modell gller fr infrandet av ett datalager, men jag uppfattar en stor del av problematiken som jmfrbar med infrandet av ett BIsystem, bde drfr att de tekniska frutsttningarna r snarlika och fr att processen sker p liknande stllen i organisationen.

3.1 Vad r Business Intelligence?

Fr att frst Business Intelligence i ett sammanhang beskriver jag relationen mellan data, information, och intelligence. Intelligence kan ungefr versttas med underrttelse och d man anvnder det fr att samla och presentera information i affrssyften s kallas det Business Intelligence. Detta har blivit s vanligt att Business Intelligence blivit ett vedertaget begrepp. Data innebr obehandlade och neutrala utsagor om verkligheten som kan samlas in eller registreras p olika stt. Dessa utsagor blir i sig sjlva inte srskilt intressanta. Men om dessa data arrangeras eller stts i ett sammanhang kan de bli meningsfulla fr en person vid ett specifikt tillflle. D vergr datat till information. Man kan allts beskriva det som att information ligger till grund fr ett bestmt ml. Eftersom detta beror p sammanhang kan det vara s att det som r information vid en tidpunkt fr ngon kan vara meningslsa data fr ngon annan.(Saxby 1990, s 11)

Holopainen, Lillrank och Paavola menar att information bestr av tre olika faktorer. Innehllet r den substansen av fakta som informationen innehller, formen r de signaler, symboler och format som fr fram fakta och kontexten r den specifika situation som fakta framfrs i som information. Fr att uppn ytterligare en niv av meningsfullhet anvnds begreppet intelligence (vissa delar av litteraturen anvnder begreppet kunskap som nsta niv efter information). Nr olika delar av information filtreras och analyseras fr att uppn frstelse uppns intelligence. Detta kan exempelvis ligga till grund fr beslut eller analyser av olika slag. (Kahaner 1996, s 21) Ett svenskt ord som anvnds r underrttelse och mnga av de grundlggande iderna om intelligence r hmtade frn den militra vrlden och mnga exempel i litteraturen kring mnet r frn krigshistorien. Nr tillvgagngssttet anvnds inom ett fretag fr att p olika stt skaffa sig kunskap brukar det benmnas Business Intelligence. Detta kan anvndas inom en rad olika omrden som exempelvis att kartlgga konkurrenter, att kontrollera den egna produktionskedjan, sljframgngar, eller som i fallet fr denna utredning; fr att flja upp intern produktivitet. Sundstrm beskriver arbetet som en underrttelsecykel dr allting kretsar kring uppsatta ml. Underrttelsecykeln r ett begrepp som anvnts lnge inom militr underrttelseverksamhet fr att konkretisera hur fldet och analysen kring information br se ut, och modellen finns i ett antal olika varianter. I den modell Sundstrm presenterar har cykeln fyra delfunktioner som r att inrikta, inhmta, bearbeta samt att delge information. (Sandstrm, 2004, s 135ff)

Figur 2 Underrttelsecykeln

Under arbetet med informationshantering i underrttelsecykeln ligger mlet tydligt i mitten, och utgr en utgngspunkt. Detta r ett tecken p hur viktigt det r att arbeta med mlformulering. Mlformulering tas upp i ett senare stycke.

3.2 Datalager
Fr att kunna genomfra de olika stegen i underrttelsecykeln mste man ha ett medel att lagra inhmtad data. Det vanligaste sttet att lagra data i allmnhet r i en databas, som r

10

en samling av lagrad, relaterad data. Men d det gller Business Intelligence r det vanligare att lagra i ett s kallat datalager2. Den generella skillnaden mellan en databas och ett datalager (eng data warehouse) r att ett datalager har en mer komplex struktur med flera dimensioner. Detta innebr flera praktiska skillnader, som kan ses i Inmons definition nedan. Det innebr ocks att ett datalager ofta r mer passande fr OLAP (Online analytical processing), beslutsstdsfunktioner och olika typer av trendanalyser. Eftersom denna typ av funktioner r mer komplexa n vad som krvs av en databas krvs ocks att datalager har en effektivare tillgnglighet till datamngderna (eng query support). (Elmasri & Navathe 2004, s 900f och s 910) Bill Inmon, en av frgrundsfigurerna inom utvecklingen av datalager, definierade redan 1992 begreppet s hr: a data warehouse is a subject oriented, integrated, non-volatile, and time variant collection of data in support of managers decision. Dr de specifika orden definieras (egen versttning, med inspiration frn Forsberg & Morell 2006): Subjektorienterad: Ett datalager fokuserar p subjekt istllet fr dagliga transaktioner Integrerad: Ett datalager konstrueras genom att varierande kllor integreras till en sammanhllen enhet Icke ombytlig: Ett datalager ska innehlla stabil data. Data tillfrs men tas inte bort eller ndras. Detta bidrar till en konsekvent frstelse Tidsberoende: All data i datalagret r frknippad med en tidsperiod Definitionen str sig fortfarande vl trots att den formulerades fr ett och ett halvt decennium sedan, frutom de detaljer som ndrats genom att lagringskraven kat s enormt de senaste ren. Detta innebr att man i vissa fall kan bli tvungen att ta bort data, s bestndighetskravet kan ibland inte lngre uppfyllas i sin helhet. Inmons definition r mycket tydlig och exakt. Fr att ge lite perspektiv till definitionen vill jag ocks nmna en mer praktiskt orienterad definition. Jag har i mitt arbete anvnt mig av en analysmodell frn Sderstrm (1997), och han arbetar med en egen definition, som ligger till grund fr hans modell: ett datalager r en logiskt sammanhllen datamngd, som r avsedd fr analys och som speglar flera tidsperioder genom att data regelbundet hmtas frn andra register. Denna definition r mer inriktad p anvndandet och hur man praktiskt har nytta av ett datalager. Jag har inte sjlv tagit fram ngot datalager i detta arbete men som reflektion kan sgas att definitionen ocks speglar funktionen i den prototyp som tagits fram eftersom prototypen fungerar som logiskt sammanhllen datamngd som r avsedd fr analys. Den frdiga applikationen r tnkt att spegla data frn flera tidsperioder genom att data regelbundet ska hmtas frn andra datalager. Detta r ett argument fr att Sderstrms teorier r befogade att applicera inte bara vid arbetet med ett datalager, utan ven d man pratar om en teknisk Business Intelligence-lsning.
2

versttningen frn engelska r ngot otydlig eftersom det svenska ordet lager har tv mjliga betydelser. Jag vill pongtera att datalager syftar p att det r ett frrd med data och inte ett skikt, som man kan frledas att tro.

11

3.2.1 vergripande strukturer Nr man skapar ett datalager mste man ta hnsyn till ett antal faktorer gllande modelleringen av datamngderna. Det gller helt enkelt hur man ska kunna hantera all data p ett praktiskt stt. Denna modellering kan vara p olika plan, logiskt, konceptuellt eller fysiskt, och alla dessa tre stt r nra beslktade. Ett datalager och en databas r i grunden inte srskilt olika, frutom med avseende p komplexitet och vissa modellval. Jag beskriver inledningsvis tv strukturer fr databaser. ERM-modellen r den mest utbredda och lnge har utgjort grunden fr hur man konceptualiserar databaser. Den mjukvara som jag anvnt, QlikView, gr d den laddas, om tidigare strukturer till en associativ datastruktur fr att optimera prestanda. Ett av de mest knda stten att strukturera data r med Entity-Relationship Modeling (ERM). ERM r en logisk teknik som r tnkt att ta bort eventuell redundans, den bygger p att alla entiteter i modellen skapas med relationer sinsemellan. Det r ett stt att strukturera data som r detaljrikt och logiskt. Nackdelarna r dock att om komplexiteten p datat kar s blir ER-diagrammen vldigt komplexa och svrverblickbara. Eftersom datalager per definition r stora och komplexa s blir ER snabbt en svrhanterlig modell. Det kan bli s komplext att det inte finns mjlighet fr anvndaren att verblicka de olika relationerna. (McCarthy & Risch 2005, s 27ff) En associativ databas har frskt optimera problemen med relationsdatabaser fr att vinna tid och effektivitet. Posterna i databasen lagras som objekt och associationer. Objekt r oberoende av varandra och associationerna beskriver relationerna dem emellan. Ett illustrerande exempel kan vara om man vill fra register ver de anstllda p Sandvik Systems Development och deras kompetenser. I en relationsdatabas krvs tre tabeller; en fr de anstllda, en fr kompetenser och en fr vem som har vilken kompetens. I en associativ databas rcker det med tv; en fr anstllda, en fr kompetens samt en dubbelriktad association fr har kompetens inom. (Strmberg 2006, s 11ff) 3.2.2 Normalisering Fr att f en databasmodell som r s smart och icke-redundant som mjligt pratar man om begreppet normalisering. Det r ett stt att dels f tydliga tabellstrukturer och dels att effektivisera lagringen i databasen. Grundregeln fr normalisering r att det ska finnas en typ av sak per tabell och en sak per rad (McCarthy & Risch 2005, s 217). Fr att tydliggra hur normaliserad en datastruktur r finns det standarder fr normalisering. De vanligaste r 1NF, 2NF, 3NF och BCNF dr NF betyder normalform och BCNF betyder Boyce-Codds normalform. BCNF r den striktaste formen av de fyra, det vill sga att den ska uppfylla flest kriterier. Kortfattat kan man sga att de nmnda normalformerna bygger p kriterier fr att f en s entydig struktur som mjligt. 1NF innebr att det endast fr finnas atomra vrden, allts ett vrde per ruta och tabellrad. 2NF mste uppfylla 1 NF samt att de attribut som ej r nycklar ska vara fullstndigt funktionellt beroende av tabellens mjliga nycklar (kandidatnycklar).

12

Med fullstndigt funktionellt beroende menas att hela nyckelkombinationen [A] entydigt bestmmer ett annat attribut [B]. Detta kallas att [A] r en minimal determinant till [B]. Fr 3NF ska 2NF vara uppfyllt samt att de attribut som inte r nycklar inte fr vara fullstndigt funktionellt beroende av ngot annat attribut som inte heller r en nyckel. BCNF ska uppfylla 3NF samt att nyckelattribut inte fr vara fullstndigt funktionellt beroende av icke-nyckelattribut. I databaser normaliseras tabeller vanligen till 3NF eller BCNF fr att motverka redundans och fr att man bara behver ndra p ett stlle vid uppdatering. Skillnaden mellan skningar i databaser och datalager r att i en databas behvs oftast bara en post (ex. vad heter kund nummer X?) medan en skning i ett datalager kan behva mnga poster (ex. vilken anvndare har rapporterat tid p projekt Y under mnad Z?). Drfr optimerar man ett datalagers struktur med tanke p utskningar snarare n uppdateringar. Detta innebr vanligen att strukturen r denormaliserad, som allts innebr att man inte uppfyller ngon eller ngra av normaliseringskriterierna. Det finns ven flerdimensionella strukturer som kan vara normaliserade (exempelvis snflingestruktur, se figur 4). (McCarthy & Risch 2005, s 217ff) 3.2.3 Flerdimensionella kuber Datamngderna i lagret mste struktureras p ngot stt fr att det ska bli verblickbart samt g att hantera. Datat struktureras i olika grupper, niver eller tabeller med nycklar emellan fr att skdliggra hur det verkligen ser ut. Modellval kan bero p hur datat ser ut. Det finns olika strukturer, tv vanliga r stjrnstrukturer och snflingestrukturer. Stjrnstrukturer innebr att det finns en faktatabell dr faktiska transaktioner registreras, och till denna avskalade faktatabell r det kopplat ett antal dimensioner i form av tabeller med data3. (Elmasri & Navathe 2004, s 905)

Figur 3 - Schematisk skiss av en stjrnstruktur

Fr att exemplifiera s utgr de faktiska timrapporteringarna, X timmar under dag Y, transaktionerna i tidrapporternas faktatabeller. Dimensionerna utgrs av all kringdata, som personalinformation, jobbtitlar, vilka debiteringstaxor som finns etc. Fr detaljer, se kapitel 7.1 samt bilaga 5.

13

Det finns ven andra varianter s stjrnstrukturer, till exempel en s kallad vrdekedja som r en sammankoppling av ett antal stjrnstrukturer som r sammanfogade via gemensamma dimensionstabeller. (Sderstrm 1997 s 66) Snflingestrukturer bygger p samma princip som stjrnstrukturer, med en faktatabell fr transaktioner i mitten, men skillnaden r att de dimensioner som kopplar in mot faktatabellen r normaliserade, och det kan drfr finnas flera, organiserade hierarkiskt. (Elmasri & Navathe 2004, s 905)

Figur 4 - Schematisk skiss av snflingestruktur

3.3.5 Associative Query Logic I QlikView anvnds en annan datastruktur n dimensionsmodellerad information. Associative Query Logic (AQL) r QlikViews teknik fr att arbeta med stora datamngder och behandla skningar (queries) blixtsnabbt. Under laddningen till programmet omstruktureras datamngderna frn kubstrukturen till ett s kallat datamoln. Datamolnet bygger p icke-redundanta tabeller som hlls i minnet. Queries grs sedan direkt mot datamolnets minnesbank. Strukturen r minneseffektiv eftersom alla data sparas bara en gng och associationerna lagras som pekare. Det krver ingen indexering, register eller frdefinierad analys eller queries, allt kan kras direkt i applikationen. (Strmberg 2006, s 11ff)

3.4 Ml som utgngspunkt fr Business intelligence

Enligt March (1999, s 75) kan man definiera organisationers lrande som rutinbaserat, historieberoende och mlorienterat. En BI-lsning r ett stt fr en organisation att lra och skapa en chans till proaktivt agerande. Detta gr man genom att frska hitta en applikation som r just rutinbaserad och historieberoende samt, viktigast av allt, mlorienterad. Vikten av mlorientering r ngot som nmns i nstan varenda klla kring lrande, projekt och IT-system, och jag har drfr valt att ta upp det i ett separat stycke. De tidskategorier, budgetml och debiteringsgrader som bestmts av framfr allt SSD:s ledning r en typ av verksamhetsml. Fr att ge en bredare bild n enbart den tekniska vill jag ven fra in dimensionen kring rapporternas faktiska syfte. Eftersom dessa syftar till att ge ett verktyg fr mluppfljning s r det viktigt att ge en bakgrund till hur man ser p ml och mluppfljning, och hur Business Intelligence kommer in i det resonemanget.

14

Jag har p mnga stt frskt visa vikten av att stta upp ml fr arbetet och att det kommer att pverka en framtida BI-lsning. Ml str som en faktor i mitten av underrttelsecykeln och organisationens lrande (som styr om lsningen r till nytta eller ej) beror av om applikationen r mlorienterad. Med detta sagt s r det tydligt att mlen mste formuleras innan arbetet med sjlva BI-applikationen kan ta sin brjan. Det r allts viktigt att ha en tydlig mlbild som utgngspunkt fr att kunna arbeta p ett bra stt med Business Intelligence. Att styra verksamheten baserat p ml har blivit en grundregel fr ledarskap. Tanken har i modern verksamhetsstyrning ftt benmningen MBO- Management by Objectives, och r ett stt att kontinuerligt flja upp och utvrdera den verksamhet man r utsedd att leda (Anthony & Govindarjan 2007, s 136, 386f, 520). Fr att de ml man ska ta fram (och sedan ha som utgngspunkt i framtagandet av en BIlsning) ska fungera och vara effektiva finns det en konkret modell ver hur mlen ska vara utformade. Sandstrm (2004) menar att om mlen man stter upp fr verksamheten ska vara lyckade s br de vara SMART, allts specifika, mtbara, accepterade, realistiska och tidsbestmda. Lite mer utfrligt s innebr detta att mlen br vara entydiga och situationsanpassade (specifika), man ska kunna lsa av utfall och riktning (mtbara), det som r tnkt att uppfylla mlet mste godta detta (accepterat), det ska vara mjligt att n mlet (realistiskt), samt att det r viktigt att veta nr allting ska vara uppfyllt (tidsbestmda). (Sandstrm 2004, s 54ff)

3.5 Framgngsfaktorer vid infrande av Business Intelligence

Det finns mycket som kan g fel vid infrandet av ett tekniskt system. Risken att misslyckas blir strre ju strre del av verksamheten som berrs. Eftersom en BI-lsning har potential att berra mnga viktiga punkter i organisationen r det viktigt att f en bra verblick ver vad som kommer att avgra framgngen hos en framtida applikation. Peter Sderstrm tar i sin bok Datalager - verksamhet, metod, teknik upp en modell bestende av sex olika dimensioner som man br beakta vid implementering av ett datalager. Jag har valt att beskriva modellen eftersom jag tycker att det utgr ett handfast verktyg att beskriva dimensioner runt en teknisk lsning. Med dessa dimensioner inkluderas mnga av de faktorer som r relevanta fr att gra en bedmning av den BI-applikation som hela studien kretsar kring. Detta ger ett applicerbart verktyg att jobba med. Viktigt att pongtera r ocks att de system jag granskat inte rrt sig om en extern informationshantering utan intern, vilket gjort att jag valt att utesluta de delar som rr just externa faktorer, exempelvis marknadsfaktorer, kundpreferenser och liknande. 3.5.1 Vision Ett datalager r strukturerat fr att stdja beslutsfattande p ngot stt. Drfr r det viktigt att tillhandahlla de data som potentiellt r viktiga fr styr- och ledningsfunktioner. Fr att gra detta mste man veta vad ledningens visioner r och de visioner som finns med verksamheten. Kritiska framgngsfaktorer fr vision: Knyt datalager till prioriterade ml och strategier Visa omedelbart synliga vinster

15

Inse hur verksamheten kan utnyttja nyttan med datalagret 3.5.2 Struktur Fr att kunna utnyttja ett datalager till fullo r det viktigt att ha en bra struktur. Strukturen r det viktigaste verktyg fr att kunna extrahera intressant och relevant information. Strukturen br spegla det stt som beslutsfattarna ser p verksamheten. Fr att lyckas med detta r det viktigt att kravstllare och konstruktrer tillsammans jobbar fram en fungerande struktur. Kritiska framgngsfaktorer fr struktur: En begriplig struktur Viktigt med vergripande struktur Ta stllning detaljer eller summadata Denormalisering fr slutanvndaren eftersom det r enklare att frst 3.5.3 Process Med process menas hr tv olika saker. Dels den process som det innebr att bygga upp ett datalager (speciellt viktiga delprocesser r exempelvis frankring, kvalitetskontroll, utbildning och frvaltning). Dels det stt man beskriver och frhller sig till de interna processer som datalagret ska stdja. Kritiska framgngsfaktorer fr process: Verksamhetsdriven process Utveckla stegvis Top-down eller bottom-up? Bestllaren br ha kvalitetsansvaret 3.5.4 Teknik Vid datalagerdesign r det ofta tekniken som r den vervgande faktorn och ofta gnas tekniken s mycket uppmrksamhet att de vriga faktorerna kommer i skymundan. Men odiskutabelt r att databasens, och de kringliggande verktygens (exempelvis flyttverktyg och preprocessning) egenskaper r viktiga fr framgngen. Enkelhet, kvalitet, kapacitet och skerhet r viktiga frgor som man br ta stllning till. Kritiska framgngsfaktorer fr teknik: Skalbarhet r viktigt Vem ska leverera hrd- och mjukvara? Hur uppdateras datan, kontinuerligt eller grupperat? 3.5.5 Individ Datalagret kommer alltid i slutndan att definieras av hur slutanvndaren anvnder det. Nyckelord fr individen som anvndare r utbildning och anvndarstd. Kritiska framgngsfaktorer fr individ:

16

Slutanvndaren stller kraven Slutanvndaren r knapptryckare utan mellanhnder Det mste finnas begriplig metadata Anvndarens milj och std ska vara bekvm och begriplig 3.5.6 Organisation Organisationen r det sammanhang som datalagret ska fungera i. Drfr r det viktigt att lagret r anpassat efter organisationen. Detta gller till exempel ml, bde vergripande och detaljerade, terminologi och ansvar. Att tnka p: Frankra innan projektstart Utse tydligt frvaltaransvar Datalagret krver stdorganisation

3.6 Sammanfattning
Business Intelligence hjlper allts beslutsfattare att arbeta med ml och mot ml. Fr att implementera ett framgngsrikt BI-system krvs att vissa saker r uppfyllda. Det mste finnas ml som r specifika, mtbara, accepterade, realistiska och tidbestmda. Detta utgr basen fr hur man stter upp systemet. Nsta frutsttning r att det finns ett tekniskt kllsystem som kan uppfylla befintliga krav p datalagring informationsinnehll, kraven kan exempelvis identifieras med hjlp av de olika stegen i underrttelsecykeln. Detta r vanligtvis ett datalager. Utver dessa tv finns ett antal faktorer som r viktiga att beakta fr att implementeringen ska lyckas. Dessa r; vision, struktur, process, teknik, individ och organisation. Allt detta bidrar till ett framgngsrikt och stdjande system.

17

4 Metod
Jag har i metodavsnittet haft fr avsikt att resonera kring olika tillvgagngsstt och tankegngar under arbetet. Jag har delat upp rubrikerna tematiskt efter de olika huvudproblemen.

4.1 Om arbetet frn problem till lsning

Jag stlldes infr ett problem som var abstrakt och konkret samtidigt. Problemet var framlagt p ett sdant stt att det var greppbart och tydligt, eftersom jag frstod vad det var som frvntades av mig. Men samtidigt, hur utreder man ett behov, och vilken av alla mjliga riktningar r den mest lmpade? En stor del av arbetet har kommit att kretsa kring att gra rimliga avgrnsningar, som diskuteras i ett separat stycke. Jag brjade med att efter bsta frmga frska frst uppgiften, och de olika begrepp, system och den organisation som lg till grund fr problemet. Nr jag tyckte att bilden brjade klarna satte jag igng att i nrmre detalj frska utreda de behov som fanns och vilka problem som fanns med dagens situation. Detta ledde till en lista av problem med dagens lsningar, bde praktiska problem och anvndarbehov som inte tillgodoses. Med problemen som bas, samt examensarbetets grundramar fr gonen, frskte jag tnka ut potentiella lsningar p problemen och formulera dessa i tydliga ordalag. Allt detta (utredningsfasen) lg till grund fr den kravspecifikation som jag drefter sammanstllde. Efter att ha utrett problem och behov, och sammanstllt ett kravdokument vidtog nsta fas, utvecklingsfasen. Jag frskte efter bsta frmga att verfra mina tidigare resultat till en tnkt prototyp. Utvecklingen innefattade, grovt sett: laddning, modellering och design samt viss validering. Testning har varit en kontinuerlig process under arbetet. En del problem under arbetets gng har besttt i att p ett logiskt stt frska efterlikna tidigare rapporters (BEx/Excel) struktur i QlikView eftersom jag ftt bygga upp datastrukturen frn grunden. Hela kubstrukturen och alla nycklar har ftt terskapas p nya stt. I och med att prototypen var avslutad var den praktiska delen av arbetet utfrd. Den avslutande fasen, analysfasen, har innefattat reflektion, rekommendationer samt rapportarbete.

4.2 Perspektiv p teorin

Det teoretiska arbetet, som benmns Att arbeta med Business Intelligence, ska ses som ett grundlggande ramverk som fyller tre syften. Det beskriver grundlggande begrepp som r viktiga fr lsarens frstelse, det har naturligtvis ocks bidragit till att jag lyckats frst olika komponenter fr att kunna programmera och ladda (till exempel begrepp som multidimensionella kuber r helt centrala fr att frst hur man ska g till vga) och teoriavsnittet ger ven en grund fr analys. Arbetet har vergripande innefattat tv analysfaser, en infr prototypframstllningen, och en reflektion eftert. Det teoretiska ramverket anvnds frmst fr analys innan prototyparbetet, den avslutande analysen innefattar personliga sikter kring anvndande, frdelar, nackdelar etcetera.

18

Som en kommentar till den litteratur jag anvnt mig av kan man sga att omrdet kring Business Intelligence r ngot som snarare praktiseras n teoretiseras. Eftersom omrdet r starkt vxande s frndras applikationer och mjligheter snabbare n litteraturen hinner med. Detta innebr att de frhllandevis f bcker som finns om omrdet ofta r frldrade. Det rcker med ngra r s har verkligheten frndrats totalt. Jag har inte heller hittat mnga vetenskapliga artiklar inom mnet. Detta r ngot jag haft i tanke d jag beaktat de tillgngliga kllorna.

4.3 Att utreda behov och anvndare intervjufrfarande

En inventering av lmpliga respondenter gjorde genom en inledande kartlggning. Jag ville kontakta Anvndare av nuvarande system Skaparna av de nuvarande rapporterna Skaparna av det nya tidsuppdelningssystemet Potentiella anvndare av ett nytt system Expert p den aktuella programvaran Utifrn mina prioriterade kategorier har jag genomfrt ett antal intervjuer med personal p SSD. Riktlinjer fr intervjuerna har de flesta fallen varit fljande. Jag har sammanstllt en intervjumall (se bilaga 7) med vergripande frgor. Respondenterna har kontaktats och ftt veta p ett vergripande plan vad jag r intresserad av att prata med dem om. P verenskommen tid och plats har jag sedan hllit en semistrukturerad intervju med std frn intervjumallen. Tanken med frfarandet r att ha ett strukturerat tillvgagngsstt fr att inte missa viktiga mnesomrden, men s lst s att det nd funnits utrymme fr respondenterna sjlva att ta upp egna punkter eller diskussionsfrgor. Jag har frt anteckningar under intervjuerna och gjort en skriftlig sammanstllning direkt efter avslutad intervju. De intervjuer som inte fljt dessa riktlinjer r de personer som jag haft kontinuerlig kontakt med under arbetets gng, exempelvis min handledare och min QlikView-expert, samt vid vissa tillfllen ven min bestllande chef.

4.4 Avgrnsningar
Arbetet har p mnga stt handlat om att gra rimliga avgrnsningar, frmst under prototyparbetet. En del avgrnsningar har handlat om vergripande frgor, exempelvis vad som ligger inom arbetsuppgiften, medan en stor mngd har varit p detaljniv gllande olika val, modeller, vad som ska tas med eller ej, hur lika modellen och summeringarna mste vara originalet samt frgor gllande datamngderna. Jag ska frska sammanfatta de viktigast avgrnsningar som gjorts. En grundlggande avgrnsning gjordes i inledningsskedet av arbetet, dr uppgiften kring prototypbygget specificerades till QlikView. Detta gjordes av flera anledningar, dels fr att utredningsarbete kring programvaran med stor sannolikhet hade omjliggjort ett prototypbygge, p grund av tidsbrist och dels r den valda programvaran ngot som det fanns kompetens inom p fretaget, eftersom det r en tjnst som erbjuds externt till kund, och det var drfr lmpligt att testa programmet ven inom intern uppfljning. Jag behvde

19

inte heller lsa driftsfrgor eller uppdateringar i prototypen, dock grna tnka p mjliga lsningsfrslag. Resten av avgrnsningarna handlar om prototypen. Maj 2007 valdes som exempelmnad av rent praktiska skl, det var i juni som laddningarna skedde, och tidigare mnads data utgjorde en naturlig startpunkt. I den Excel-rapport som redan fanns gjordes ett antal specialkorrigeringar fr att rtta till felaktigheter i dataladdningar. Jag har hanterat dessa i mjligaste mn men inte helt. Det jag hanterat r att filtrera bort specifika teamkoder, samt vissa personer som betraktas som over head, allts icke budgeterade fr. Det jag inte har hanterat r hur resurser frn Gimo (dr ca 5 personer frn SSD arbetar) hanteras, samt den sjukdomstid som lggs in frn IFSsystemet manuellt. Jag har ven lst specifika problem lngs vgen som kan betraktas som avgrnsningar. Ett problem har legat i hur nycklarna (mellan tabeller) ska utformas i modellen fr att bst matcha verklighet, samt de vriga rapporterna, och dr har jag ftt ta stllning i varje enskilt fall vilken som r den rimligaste lsningen. De tre projektniverna var en annan nt att kncka eftersom de har legat i varsin separat tabell i BW, men fr att QlikViewkopplingarna skulle fungera behvdes en annan lsning. Min QV-expert hjlpte mig med att konkatinera (datorterm fr att stta ihop, gra en en s.k. join) de olika tabellerna till en stor. Att fra in budgetjmfrelse som en funktion var en avgrnsning s till vida att jag endast lste in de data som gllde fr maj, och endast fr de tidskategorier jag hade tillgng till budget fr. De kategorierna som fanns budgeterade var den gula och den bl tiden.

4.5 Sekretess
SSD har ltit mig publicera material kring deras system och datorarkitektur. Prototypen i sin helhet, koden och data betrffande SSD utgr inte en del av rapporten.

20

5 Beskrivning av nulge
Fr att f en bra grundfrstelse fr vidare analyser har jag frskt sammanfatta dagslget kring rapporteringen.

5.1 Bakgrund
Personalen p SSD rapporterar sin arbetstid p tv stt; p stmpelklocka(numera ett magnetkort) vid ankomst och hemgng. Dessa tider registreras i programmet IFS och skickas sedan vidare till Sandviks tidsrapporteringssystem Projus. I Projus rapporterar medarbetarna sin tid som lagts timvis p olika projekt. Fr att f en bra bild ver hur personalen lgger ned timmar och drigenom hur fretaget gr ekonomiskt har SSD:s ledningsgrupp tagit fram ett kategorisystem fr att se p den rapporterade tiden (beskrivs mer utfrligt nedan). Utifrn denna uppdelning har det tagits fram Excel-ark med de efterfrgade timmarna, uppdelade efter olika kriterier.

5.2 Hur produceras rapporterna idag?

Jag har frskt klarlgga hur rapporterna produceras idag. Detta r inte helt enkelt. Det finns nmligen olika versioner, som anvnds en aning olika. Det finns en rapportform som ligger inbyggd i SAP-BW, som r byggd fr att lyfta fram en del av den information som finns dr. Det grs via det verktyg som heter Business Explorer, kallad BEx-rapporter. Det finns tv relaterade BEx-rapporter som r aktuella i detta fall. Den ena visar total rapporterad arbetstid mot de timmar som rapporterats specifikt, denna rapport heter Scorecard IFS. Den andra visar hur tiden rapporterats p olika projekt och heter Project Follow Up. Dessa rapporter genereras frn programmet sjlvt efter att relevant data laddats in, efter att de en gng skapats och alla kategorier har definierats. Tyvrr r rapporterna s svranvnda att ingen som skulle ha nytta av dem faktiskt tittar p dem. De efterfrgade siffrorna ligger i ett Excel-dokument som r resultatet av en utskning (en query) frn informationskuben. Utskningen kan man modifiera via anvndargrnssnittet, men det krver tillgng till samt viss vana av Business Explorer. Eftersom de nmnda rapporterna inte anvnds, d de r krngliga att komma t och svrmodifierade, samt att man faktiskt har ett behov av den information som datalagret innehller, har man genomfrt en alternativ lsning. Genom en utredning tog man fram de data som man nskade att rapporten skulle innehlla (bilagan r borttagen ur denna versionen). Dessa nskeml gick sedan vidare till SSD:s ekonomiavdelning (benmnd DAF). De har utifrn nskemlen skapat ett Excel-dokument med den nskade informationen. Detta Excelblad bestr av 17 flikar som hmtar data frn de tidigare nmnda BEx-rapporterna. Datan r omstrukturerad efter anvndarnas nskeml, vilket innebr att den r grupperad p ett annat stt n BEx-rapporterna. Det finns ven andra detaljndringar, i form av ett antal undantag som mste lggas in fr hand. Detta sker genom att man varje mnad mste g in manuellt och hmta ut nskad information och sedan justera fr vissa tillflliga frndringar. Detta kan glla att ta bort eller lgga till tid, eller ndra tid frn extern till intern tid eller modifiera s.k. over head-tid. Enligt en grov uppskattning tar arbetet en dryg arbetsdag per mnad att sammanstlla, utspritt ver flera dagar. Ett problem

21

med denna rapportform r att arbetet inte kan pbrjas frrn efter den 10:e var mnad eftersom tidsstmplingen ska attesteras av nrmsta chef, vilket innebr en frdrjning fr datafrflyttningen. En tredje rapportform r den Excelrapport som hmtas direkt frn Projus, tidsrapporteringssystemet. Detta r en lsning p att man varit tvungen att vnta till efter den 10:e fr att f skra siffror, vilket beror p att rapporterade siffror ska godknns av en hgre instans innan de kan laddas, vilket gr att det drar ut p tiden. I denna tredje rapport hmtas datan direkt frn Projus, uppdelad p varje kompetensteam, och kan gras nr som helst i mnaden. Detta fr att f en snabb verblick ver dagslget, men r egentligen inget verktyg man kan bygga hllbara prognoser p.

5.3 Vem anvnder rapporterna?

Bestllaren fr den aktuella studien r SSD:s ledningsgrupp. De vill se ver de rapportformer som finns att tillg i dagslget. Excelrapporten som DAF producerar r till frmst fr ledningsgruppen, som anvnder dem fr att bedma hur fretagets resurser anvnds. Bex-rapporterna verkar ingen anvnda, utom att de ligger till grund fr ovan nmna Excelrapport. De rapporter som tas direkt frn Projus anvnds i dagslget av teamcheferna som gonblicksbild av hur deras team rapporterat olika tider, och kan i bsta fall leda till en proaktiv styrning. Men jag ser ven en potential att teamchefer och vriga med leveransansvar kan ha nytta av rapporterna i sitt planeringsarbete.

5.4 Struktur och nomenklatur

Den rapporterade tiden r uppdelad i olika kategorier, grn, bl och gul tid4. De olika kategorierna markerar olika typer av aktiviteter personalen lgger sin tid p. Grn tid markerar den debiterbara tiden mot kund, allts olika fasta projekt och avtal. Det kan vara licenser, fastprisavtal eller andra externa avtal. Bl tid innefattar den interna produktiva tiden, ssom interna frbttringsprojekt, kvalitetsarbete osv. Gul tid r vrig tid, som innefattar frsljning, utbildning, interna mten och aktiviteter och idle. Resurser r den personal som r tillgnglig, varje person r en resurs (en resurs kan teoretiskt sett ocks vara exempelvis en maskin eller dator som utfr arbete). De resurser som r markerade som OH r s kallad over head vilket innebr att de inte r budgeterade att producera ngot i projekt, dessa personer r oftast chefer eller eventuellt administrativ personal. All eventuell rapporterad tid frn dem rknas bonus fr fretaget, allts ren vinst som inte budgeterats fr.

I applikationen kallas dessa: grn-External debet, bl-Internal projects&assignments(P&A) gul- Other activities

22

Resurserna jobbar oftast i projektform. Ett projekt kan ha tre projektniver registrerade i Projus (vilka sedan fljer med genom systemen). Niverna r hierarkiska, dr det alltid finns en projektniv 1, och sedan kan det finnas niv 2 och niv 3 kopplade till toppnivn om projektet ha flera delgrenar. Projekten har ven andra kategorier som exempelvis en projektledare, team code, berknat slutdatum etcetera5. Gllande de olika tidstyperna i systemet s finns det tre olika typer av rapporterad tid. IFS-tid r den tid som kommer direkt frn tidsstmplingssystemet med samma namn. Follow Up-tid r de timmar som medarbetarna lgger ned p varje projekt, varje dag. Scorecard-tid r en summering av Follow Up-tiden p en dag. Jag illustrerar med ett exempel. Om du jobbar p SSD och kommer en dag 8.00, stmplar ut fr lunch en timme och gr hem 17.00 samt jobbar parallellt med tv projekt, Projekt A tv timmar p frmiddagen och Projekt B sex timmar resten av dagen kommer tiden att se ut som fljer: IFS-tid: 8.00-17.00 = 9h 1h lunch = 8h Follow Up-tid: Projekt A 2h + Projekt B 6 h Scorecard-tid: 2h + 6h = 8h Just i exemplet stmde alla tider vldigt vl, men i verkligheten r det vldigt sllan s att tiderna stmmer verrens. Detta r en av anledningarna till att man vill underska vad tiden egentligen gr t till.

Fr detaljer hnvisar jag till bifogade tabellstrukturer

23

5.5 Hur ser dagens rapporter ut?

Bex-rapporterna r ett Excelblad dr man kan specificera bestmda variabler och sedan hmta ut data. Detta r ocks exakt vad som grs i DAF:s Excelrapport. I figuren nedan har jag markerat vart man specificerar valen som den vre rutan och resultatet av utskningen nederst. Resultatet presenteras i stora Excel-rapporter. Som anas i bilden nedan r resultatet svrt att analysera d det r svrt att verblicka.

Figur 5 - Exempel p BEx-rapport Project Follow-Up

Bex-rapporterna ligger till grund fr de Excelrapporter som sammanstlls och anvnds av ledningsgruppen. Utskningen grs med Bex, men man gr sedan lngre och omformar utskningsresultatet utefter tidskategorisystemet. Excelrapporten bestr av ett stort antal flikar med information om bland annat olika tidstyper.
Figur 6 - Exempel p flikrad i Excel-rapport

Varje tidskategori har ett antal flikar som koncentrerar den information som finns om kategorin. Fr exempelvis den gula tiden innehller presentationsfliken information om de fyra olika gula kategorierna p detaljniv samt budget, ackumulerat och fr varje mnad. I exemplet nedan har jag tagit med den gula kategorin Internal och totalsumman.

24

Figur 7 - Intern tid och sammanstllning av gul tid i Excel-rapporten

I flikraden i figur 6 ses Sammanstllning SSD. Dr sammanstlls siffror frn de olika flikarna fr att ge en helhetsbild. Dr presenteras bland annat total tid, de olika tidskategorierna, IFS-tid och ackumulerad timsummeringar.

25

Figur 8 - Sammanstllning i Excel-rapport

Utver dessa tabellsummeringar finns det ocks tre stycken diagram i rapporten, en fr varje tidskategori. Dessa visar hur det gr mnad fr mnad fr en definierad kategori, se exemplet nedan.

26

Figur 9 - Diagram i Excel-rapport

Den Excel-rapport som gr med data direkt frn Projus r snarlik den ovan beskrivna rapporten men r inte lika detaljerad. Dr finns enbart tv flikar, en fr sammanstllning av data (grs ett per team) och en flik fr ett diagram liknande det ovan.

27

6 versikt av programvara
I detta avsnitt gr jag igenom de olika programvaror som r aktuellt fr arbetet. Jag beskriver dessa i vergripande termer, med fokus p den funktionella rollen, inte p den tekniska prestandan. De tv programmen som har anvnts mest r QlikView och SAP BW, varfr dessa r mer detaljerat beskrivna. I skissen nedan ses en schematisk bild av hur laddningarna gr till, steg fr steg.

Figur 10 Schematisk skiss ver dataladdningarna

6.1 IFS
IFS (Industrial and Financial Systems) r Sandvik System Developments bastidsrapporteringssytem. Det r detta system som loggar ankomst och hemgng via en terminal i entrn dr du drar ditt passerkort. Det r ocks via detta system som du manuellt kan rapportera in arbetade timmar d du inte dragit kortet (p resa, jobbat hemifrn etc). Systemet r fristende frn vriga system och hller enbart reda p antal arbetade timmar, men inte vad de spenderades p.

6.2 Projus
I Projus dremot gr varje anstlld in och rapporterar hur de spenderat tiden p jobbet. Eftersom SSD r ett konsultbolag (med bara Sandvik som kund) spenderar medarbetarna sina timmar p olika stt, vilka debiteras olika, och detta mste det finnas kontroll fr. Dessa inrapporterade timmar lagras i en datastruktur, dr den ligger till grund fr fretagets fakturering. Mnadsvis tankas informationen ver till SAP:s datalager, kallat Business Warehouse.

6.3 SAP Business Information Warehouse (SAP BW)

SAP r en av vrldens strsta leverantrer av affrssystem. BW-applikationen r deras Data Warehousing-lsning som anvnds av Sandvik Systems Development. Strukturen r uppbyggd av tre principiella funktioner: 6.3.1 Laddning av data till datalagret Detta innefattar ven extraktion och eventuell transformation som krvs fr att f den nskade strukturen p lagret. I det aktuella fallet handlar det allts om laddning frn IFS och Projus till SAP BW, vilket vanligtvis grs en gng i mnaden, med undantag fr vissa data som laddas veckovis. 6.3.2 Datalagret I datalagret sparas den transformerade datan i s kallade informationskuber. Begreppet kub anvnds fr att visa att datastrukturen r flerdimensionell. Det innebr i vrt aktuella fall att

28

det finns en faktatabell (tidsrapporteringsdata) och frn denna utgr ett antal dimensioner (likt en stjrnstruktur, se teoriavsnitt om datadimensioner). 6.3.3 Rapportering Verktyget fr den funktionella analysen kallas Business Explorer, frkortas BEx, och det r detta verktyg man anvnder idag p SSD. Verktyget hjlper till att producera rapporter i Excel-format med vald data.

6.4 SAP-connector
Fr att kunna ladda in data frn SAP BW till QlikView krvs ett s kallat middleware fr att det ska fungera. Till detta anvnds SAP Connector fr att plocka ut data ur SAP BWkuben och ladda ver till QlikView fr anvndning.

6.5 QlikView
QlikView grs av Qliktech International AB som har sitt ste i Lund och frsljningskontor ett stort antal frsljningskontor vrlden ver. QlikView r en modern OLAP-applikation med std fr ett grafiskt anvndargrnssnitt. En hel analyskub komprimeras och laddas i RAM-minnet. Grnsen fr hur stora tabeller och flt fr vara r i det nrmsta obegrnsad s datorns internminne stter grnserna fr hur stora datamngder som kan behandlas. Eftersom varje post finns snabbt tillgnglig grs varje berkning frst nr den efterfrgas. Den nskade informationen gr d mycket fort att d fram enbart genom ett antal klick, drav namnet klicka och titta. I en QV-applikation modelleras det mesta via ett script. Genom scriptet laddar man in datamngderna och formar sedan de tabeller och nycklar man r intresserad av. Man kan ven gra en mngd andra saker som att byta namn, exkludera mngder, konkatinera tabeller mm. Scriptsprket r enkel och grundlggande programmeringssyntax. De data man laddar in via scriptet blir sedan tillgnglig via ett grafiskt grnssnitt dr all presentation sker. Grnssnittet skapas inte via scriptet. Jag har samlat lite mer ingende information om hur jag laddat in data frn BW till QV och lagt som en bilaga fr nyfikna lsare.

29

7 Frutsttningar fr en ny lsning
Mycket av materialet detta avsnitt r hmtat frn mina intervjuer, men jag har satt in det i olika analytiska sammanhang, i ett kravdokument eller i modellen fr kritiska framgngsfaktorer.

7.1 Stjrnstrukturer i praktiken

De data som finns lagrat i BW-kuberna har inte en alldeles enkel struktur. Hr tnkte jag redogra fr ungefr hur det r tnkt att frsts. Som frstelsehjlp vill jag referera till de tabellstrukturer som ligger som en bilaga till arbetet (bilagan r borttagen i denna version). I BW finns tre faktatabeller, en fr varje tid som lagras, allts IFS-tid, Scorecard-tid och Follow Up-tid. Faktatabellerna (allts transaktionsraderna) r utbyggda med ett antal dimensionstabeller. Ngra av dessa dimensionstabeller r: Resurser innefattar all information om de resurser (anstllda) som finns registrerade Projektinformation all information om projekten finns i dessa tabeller, en fr varje projektniv, totalt tre stycken Priskoder information om vad de interna konsulterna med olika kompetens kostar Jobbkoder information om vilka olika yrkeskategorier som finns Fr att visa hur strukturen ser ut har jag infogat stjrnstrukturen fr den mest komplexa kuben (den transaktion med flest dimensioner). Se Follow Up-tid nedan, figur 10.

Figur 11 Stjrnstruktur fr Follow Up-tid

30

I alla dimensioner i figuren finns ett antal olika flt som jag har uteslutit fr att frbttra frstelsen. Fr detaljerade strukturer med alla fltnamn fr alla tre tidstyper se se bilaga 6 (bilagan r borttagen i denna version).

7.2 Underrttelsecykeln i praktiken

Av det arbete som beskrivs i modellen fr hur information br analyseras i underrttelsecykeln r det endast en del som r aktuellt inom detta arbetes ramar. Detta r ett frsk att placera in informationsbearbetningen i sitt sammanhang just gllande denna BI-lsning. Beslut om hur man ska inrikta data har redan gjorts, p tv stt. Dels har strukturen fr Projus och BW bestmts, och genom dessa design- och funktionsval har inriktningen begrnsats. Det andra beslutet som inriktat informationen r de beslut man tagit gllande strukturen p tidskategorierna som definierats. Dessa tv beslut tillsammans bildar en mall fr hur man br inrikta informationen. Inhmtningen sker genom att personal registrerar tid p olika stt, bde via kort och via Projus. I dagens lge skickas ven ett ftal tidsrapporter via manuella Excelark. Det r bearbetningen som varit fokus fr denna utredning, samt i viss mn delgivningen, och p vissa stt kan man sga att arbetet skett iterativt. Jag har underskt vilka delgivningsbehov som funnits, och frskt applicera de resultaten p bearbetningen, som jag gjort frn grsrotsniv i form av ett nytt applikationsfrslag.

7.3 Frunderskning
Jag gjorde en frunderskning i kombination med nulgesanalysen dr jag genom intervjuer frskte f fram de konkreta problem som fanns med dagens lsningar. Dessa problem frskte jag sedan finna lsningsfrslag p i och med den tnkta QlikViewapplikationen. Resultatet sammanfattar jag nedan i punktform fr att vara s tydlig som mjligt. 7.3.1 Problem med dagens rapporter 1. Olika personer har olika siffror eftersom det finns olika rapporter 2. Rapporterna tar lng tid att sammanstlla, vilket r kostnadskrvande 3. Kunskapen r lst till en person 4. Rapporterna r svrverskdliga 5. Alla har inte mjlighet att se just de som de vill, utan fr nja sig med frutbestmda val 6. Man kan inte drilla i informationen, den r statisk och mycket oflexibel 7.3.2 Lsningar p dessa problem 1. Bara en rapport! 2. Gr detta automatiskt s lngt det r mjligt, och spara p s stt tid och pengar

31

3. Om lsningen programmeras i en applikation, r det enklare att fra kunskapen vidare, och det krver inte lika mycket av en administratr 4. I QV byggs rapporterna upp p ett mycket mer lttverskdligt stt, eftersom man slipper faktabladen (allts det bakomliggande lagret) 5. Pongen med QV r just att man ska kunna gra alla val man vill 6. I QV r informationen dynamisk, att drilla gr ltt

7.4 Kravspecifikation
Utifrn de specificerade problemen och mjliga lsningar sammanstllde jag en kravspecifikation av en teknisk lsning som var tnkt att tillgodose behoven. Kravspecifikationen i sin helhet finns bifogad som en bilaga, men ger hr en verblick av vad den innehller. 7.4.1 Funktionell beskrivning Under denna rubrik i kravspecifikationen har jag frskt att i s konkreta ordalag som mjligt specificera de tekniska och funktionella krav och sammanhang som omger systemet. Allts hur det rent konkret borde se ut och vad man ska kunna gra. 7.4.2 Konsekvenser De olika omrden som jag uppfattar att systemet kommer att f konsekvenser inom tar jag upp var fr sig. Dessa omrden r; tillgnglighet, pverkan p befintligt rapportsystem, verksamhet, drift, utbildning samt migrering av data. 7.4.3 Tolkning av anvndarkrav Jag ger ven en kravspecificering gllande de anvndarkrav som uppkommit under utredningsarbetet. Jag har frskt att, s konkret som mjligt, beskriva hur dessa krav kan tolkas praktiskt, och drmed ven hur problemen kan lsas.

7.5 Kritiska framgngsfaktorer i praktiken

Arbetet har inte varit att ta fram en organisations datalager, utan en OLAP-applikation baserat p ett datalager. Jag uppfattar dock problematiken som snarlik och det r min sikt att de framgngsfaktorer som Sderstrm tar upp ocks kan appliceras p fall. De saker som tas upp i texten refererar till de faktorer som jag redogjort fr under motsvarande teoriavsnitt. 7.5.1 Vision Hur man br jobba med prioriterade ml och strategier tar jag upp under i de delar av arbetet som berr mlarbetet (SMART-modellen samt mlarbetet i praktiken). Det r viktigt att uppmrksamma de vinster som grs. Det kunde vara av stort vrde att uppmrksamma ngot fall dr rapportapplikationen varit till hjlp i en frga. Det r ven viktigt att gra ledningsgruppen samt vriga potentiella anvndare uppmrksamma p nyttan och mjligheten med systemet.

32

7.5.2 Struktur D man arbetade fram det nya tidskategorisystemet var mlet att f en begriplig struktur ver det som man ville analysera. Detta r ngot jag frskt fra vidare till prototypen, och varit s trogen den strukturen som det gtt att vara. Frdelen med tidskategorierna man satt upp r att de r ganska vergripande, men detta kan ocks vara (till exempel programmeringsmssigt) en nackdel eftersom det skulle kunna uppkomma grzoner. I en QlikView-applikation finns det en stor frdel i att man inte behver vlja mellan summadata (summerade berkningar) eller detaljer, det r enkelt att gra hopsummeringar, samt nd kunna f se datan p detaljniv vid intresse. Datastrukturen i QV r denormaliserad. 7.5.3 Process Det r naturligtvis mlsttningen att arbetet med att ta fram en ny applikation ska vara verksamhetsdriven. Jag har frskt s lngt det varit mjligt att jobba med verksamheten fr gonen, men vill ppeka att det funnits vissa praktiska svrigheter med detta d jag inte varit s insatt, eller inblandad i den faktiska verksamheten. Detta blir drfr en rekommendation till vidare arbete, att i mjligaste mn utg ifrn verksamhetens krav och processer. Resonemanget gr hand i hand med att processen i applikationen br vara tillmpningsdriven. Applikationsarbetet har utvecklats stegvis, men kanske inte i s iterativt samarbete med anvndarna som jag hoppats p. Man kan se prototypen som ett frsta steg, dr ytterligare arbete kan bygga vidare p den kravspecifikation och de lrdomar som dragits. Top-down eller bottom-up lsning r ett designval som inte behvts. Eftersom de stora datamngderna laddas ver i sin helhet och sedan modelleras efter en frdig struktur s kan man sga att det varit bde top-down och bottom-up var fr sig, med kanske en aning fokus p det senare. Att bestllaren har kvalitetsansvaret r ngot som kan vara viktigt att pongtera. Mycket teori kring anvndbarhet tar upp just bestllarens ansvar, och pratar om att bestllarkompetens r ndvndigt fr att f ett vl fungerande system. Detta r inte ngot som varit en del av mitt arbete, men ngot som jag kommer att rekommendera vid ett eventuellt vidare arbete mot en lsning. 7.5.4 Teknik Gllande tekniken s menar Sderstrm att skalbarheten r viktig, att man br kolla upp leverantr samt bestmma uppdateringsregler. Jag har enbart skapat en prototyp som gller fr en mnad. Men, utan att ha testat, s tror jag att skalbarheten att f upp datamngden till en tidsperiod av 2-3 r inte vore problematiskt. Laddningstiden r i dagslget runt 30 sekunder, men vid strre laddningar r det i stort sett bara faktatabellerna som kommer att ka i omfng s laddningstiderna borde vara hanterliga. Detta behver bara gras p mnadsbasis, och kan exempelvis gras nattetid.

33

Frgan om vem som levererar komponenter r redan avgjord i och med att avgrnsning fr arbetet gjordes, prototypen skulle utvecklas i QlikView som levereras av QlikTech. Datamngden i applikationen kan uppdateras p tre stt. Antingen lter man laddningen vara tidsbestmd, exempelvis att den laddas den frsta dagen p varje mnad. Ett annat alternativ r att laddningen triggas av en hndelse. I detta fallet skulle det till exempel vara att QlikView uppdateras d det laddats in nya tidsdata frn Projus till BW. Detta grs p mnadsbasis. Ett sista alternativ r att det skts manuellt, att en person mste g in och ladda det vid behov, vilket jag inte rekommenderar. 7.5.5 Individ Jag har samlat ihop krav bde frn slutanvndarna av dagens rapporter och tnkta nya anvndare. Min ambition vid utveckling har varit att tillgodose de kraven. Det r min rekommendation att fortstta arbeta p det sttet vid en eventuell vidareutveckling. Metadata finns p olika stt. Tidsstrukturen beskriver de olika tidstyperna, datastrukturen i QlikView visas i tabellschemat (i kapitel 8.1.1, figur 10). Det finns en enkel anvndarmanual under fliken How To i applikationen. Ambitionen r ocks att designen ska vara bekvm att anvnda och lttbegriplig. 7.5.6 Organisation Om det ska infras ett nytt, skarpt, rapportsystem i QlikView s r denna sista kvalitetsfaktor av yttersta vikt. Ett system dr medarbetarnas rapporterade tid lggs in, och besluten kring vem som ska ha tillgng till det samt hur det ska anvndas mste frankras. ven under mitt relativt korta arbete har jag mrkt av hur stora delar av organisationen som r berrd. Det mrks inte minns p bredden av respondenter. Det finns en mngd sikter i frgan, och fr att lyckas med systemet s r frankring helt centralt. Fr att lsningen ska fungera rent praktiskt krvs ven att ett tydligt frvaltaransvar utses. En stdorganisation som Sderstrm kallar det r kanske ett starkt ord fr en enda intern BI-applikation, men innebrden r viktig. De som jobbar med de andra systemen (Projus och BW) br knns till applikationen, dess innehll och vad som skulle hnda om de fick fr sig att ndra strukturen i de andra systemen, eller tminstone att ngot kunde hnda i tredje led. De eller den som utses till frvaltaransvarig br vara medveten om sitt ansvar samt ha kunskap att genomfra specifika frndringar.

34

8 Prototypen
Att utveckla prototypen var ett handfast stt att konfronteras med de problem som utretts under den fregende fasen av arbetet. Det r svrt att beskriva ett s interaktivt program som detta r i enbart ord och bild. Jag ska med hjlp av skrmdumpar frska gra en vergripande beskrivning, koden finns bifogad fr den tekniskt intresserade lsaren.

8.1 Design och innehll

8.1.1 Datakopplingar Kopplingarna som finns mellan de olika tabellerna grs genom att man definierar likadana nycklar i tv tabeller (dessa skapas i scriptkoden). Genom att skapa nycklar kopplas olika tabeller samman, och all data blir p s stt relaterad.

Figur 12 - Tabellkopplingar i QlikView.

8.1.2 Layout Applikationen bestr av sex stycken funktionella flikar varav en instruktionsflik. De sex flikarna svarar mot varsitt s kallat blad (eng. sheet).

Figur 13 - Flikraden i QlikView

35

versikt (Overview) presenterar alla data utan filtreringar. Det finns en flexibel tabell med flera olika val, och jag har ven lagt till tv tabeller med fler storheter i samma tabell. Dessa val r mycket ltt att anpassa efter behov. Budget bestr av en mtare av hur olika kategorier gtt jmfrt med budget. Resultatet finns ven i tabellform. Grn tid (External debet) presenteras som i versikten, med skillnaden att datan r filtrerad efter aktuell tidstyp. Detta grs med hjlp av flaggor som jag definierat i koden. Flaggan fr grn tid heter Green_Time_Flag, och r antingen 0 eller 1 beroende p vrde. Definieringen av skrmobjekten grs som en summering av alla timmar multiplicerat med flaggan (se figur nedan). P fliken grn tid finns ven en mtare fr extern debiteringsgrad.

Figur 14 - Exempel p hur tidstyper filtreras i tabelldefinitionen

Bl tid (Internal P&A) och gul tid (Other activities) fungerar som fliken fr grn tid med det finns ingen debiteringsgrad p dess flikar. Instruktion (How To) har jag inte arbetat fram, utan det r en standardinstruktion. En del av fliken syns i bilden nedan.

Figur 15 - Ett utdrag av instruktionsfliken i QlikView

36

8.1.3 Att gra skningar Nr man vill ska ut ngot i applikationen vljer p tre olika stt. Dels vljer man vilken tidsperiod man vill titta p. Detta vljs i den versta delen av fnstret. Man vljer ven vilka utskningskriterier som finns, vill man exempel se en enskild anstlld eller ett specifikt team s markeras detta i vnstermenyn i de olika flikarna. I nedanstende exempel har jag valt resurs Linda Fernqvist. Om jag vill specificera ytterligare, vidare p projektniv kan jag vlja mellan de fem projekt som hon lagt tid p under den valda tidsperioden.

Figur 16 - Nrbild p vnstermenyn i QlikView-rapporten

Utver detta s vljer man ocks vilken visningstyp man r intresserad av, tabell eller diagramtyp samt vilken av storheterna som ska presenteras. Jag har markerat de olika valen i bilden nedan. I detta exempel r maj 2007 valt verst. I vnsterspalten r valet att titta p team LCB och den tid de lagt p utbildning. Presentationsval som gjorts r att vis i tabellform, med namn som presenterad storhet.

Figur 17 Valmjligheter i QlikView-rapporten

37

Man kan ta bort gjorda val genom att trycka Clear uppe i menyraden eller ta bort enskilda val genom snabbkommandot i vre hgra hrnet p valrutorna i vnstermenyn. Det r ven mjligt att lsa val, att gra vissa val till bokmrken som det r ltt att terkomma till, eller att backa tillbaks till de val man tidigare gjort.

8.2 Funktioner
De funktioner som finns i prototypen har jag utformat efter uppdragsgivare och andra anvndares nskeml, p basis av den frunderskning som fregick prototyparbetet. 8.2.1 Tidskategorier Alla klassificeringar i applikationen r gjorda utifrn klassificeringen av de olika tidskategorierna. Alla projekt r uppdelade i kategorier (Categories, elva bla och fyra gula) samt markerade med en flagga utifrn den tidtypen (grn, bl eller gul) de tillhr. Denna klassificering har jag anvnt vid uppdelning p de olika flikarna.

Figur 18 - Exempel p tidskategorierna

8.2.2 Drill-down p nskad storhet De storheter jag har anvnt som mjliga val i prototypen r : namn, user-ID, team (tv olika sorter), tidstyp, projekt (3 niver) och kategori. Det r mycket enkelt att lgga till och ta bort nskade storheter.

38

Figur 19 - Exempel p hur valet av storhet ser ut i QlikView-rapporten

8.2.3 Ett antal olika visningsmjligheter Det finns mjlighet att se informationen p olika stt. Jag har valt cirkel- och stapeldiagram samt tabellform som default, samt gjort snabbkommandon fr alla tabeller och diagram att exporteras till Excel eller skrivas ut.

Figur 20 - Snabbkommandon fr print och Excel-export samt val av tabell- eller diagramformat

39

8.2.4 Budgetjmfrelse P budgetfliken finns en mtare som anger hur mnga procent av de budgeterade timmarna som uppntts. Det anges ven exakt antal budgeterade timmar samt registrerat antal timmar. Siffror finns fr de kategorier som funnits budgeterade i detalj, vilket har funnits fr gul och bl tid.

Figur 21 - Exempel p budgetmtare fr den bl kategorin IGEM dr 78% av budgeten uppntts

8.2.5 Extern debiteringskvot Den korrekta berkningen av extern debiteringskvot grs genom att ta andel rapporterad tid ut mot kund (grn Follow Up-tid) av total rapporterad tid (IFS-tid). IFS tiden har inte varit tillfrlitlig i applikationen s jag har rknat ut extern debiteringskvot som andel rapporterad tid ut mot kund (grn Follow Up-tid) av total rapporterad Follow Up-tid. Detta har jag illustrerat i en mtare. Fretagets budgeterade kvot r markerad och delen under kvoten r gul och delen ver budgeterad kvot r grn (d lggs mer tid n budgeterat mot kunderna, den vinstdrivande verksamheten). Aktuell kvot markeras med ett svart streck. Kvotmarkren finns under fliken External debet.

Figur 22 - Exempel p ett team som ligger ngot under budgeterad debiteringskvot

40

9 Diskussion
Arbetet med kravanalys och prototypbygge har varit intressant och lrorikt. I diskussionen tar jag upp styrkor och svagheter med prototypen och tv punkter som varit problematiska under arbetets gng, och som jag anser kommer att pverka en framtida lsning. Jag diskuterar ven frdelar och nackdelar med att genomfra lsningen skarpt samt fr en kortfattad diskussion kring ekonomiska aspekter. Jag vill understryka att de sikter som framfrs i diskussionen r mina egna och har framkommit som en bearbetning av det arbete jag bedrivit.

9.1 Prototypens styrkor

En prototyp r inte tnkt att fungera skarpt. Jag tycker att den aktuella prototypen lser uppgiften att ge en bra bild av hur ett verktyg i QlikView kan komma att se ut, vilket var syftet med att bygga den. Detta ser jag som en mycket stor styrka. Utver detta s kan prototypen fungera som inspiration och an handfast startpunkt fr vidareutveckling mot en frdig applikation. Den kan ocks anvndas fr att frankra idn hos berrda parter och fungera som beslutsunderlag. En annan praktisk detalj r att man, vid eventuell vidareutveckling, kan genomfra anvndartester p prototypen fr att f djupare frstelse fr anvndarnas behov

9.2 Prototypens brister

Det finns fel i summeringen av vissa tidstyper jmfrt med nuvarande rapporter. IFS-tid och Scorecard-tiden r felaktiga, med en felmarginal p runt 10%6. Jag tror att dessa tidsskillnader gr att komma t om man infr ngra av de avgrnsningar i form av undantag som jag valt att inte ta in i prototypen. Nr dessa tidstyper stmmer bttre kan man ven infr en slack-variabel, allts en variabel fr skillnaden mellan IFS-tid och rapporterad tid (allts mellan faktiskt tid p jobbet och rapporterad tid). OH-resurserna r i nuvarande lsning en egen grupp som kan rapportera tid p antingen grn, gul eller bl tid. Enligt en specificering r det endast intressant att se den tid som OHresurser lgger p extern tid, allts den grna tiden. Mnga grupperingar och definitioner har gjorts i koden, vilket gr att man mste ndra koden fr att ndra exempelvis tidstyperna eller andra detaljer. I en framtida lsning br s mycket som mjligt av dessa klassificeringar flyttas ut till externa dokument. Detta har idag endast gjorts fr budgetsiffror samt alla OH-resurser.

9.3 Tidsrapporteringssystemet som allt bygger p

Tidsrapporteringssystemet Projus som r datakllan till nstan all data i systemet r byggt in house av SSD. Systemet har, sedan det byggdes, byggts ut ett antal gnger efter att man nskat ytterligare funktionalitet. Men fr att kunna anvndas i den applikationen som jag tittat p och testat finns det viss funktionalitet som inte r s flexibel, och vissa
6

IFS-tid enligt Excel = 30756, enligt QV-prototyp = 28632. Diff = 6,9 % Scorcard-tid enligt Bex= 29869, enligt QV-prototyp = 33598. Diff = 11,1 %

41

variabeltyper som inte r mjliga, och drfr har ett antal problem behvt lsas. I frlngningen br kllan av tidsrapporteringsstrukturen ses ver i avseende att bli s kompatibel mot den faktiska verksamheten som mjligt. De kritiska framgngsfaktorer som gller QlikView-applikationen kan ocks appliceras p Projus, och att systemet ska vara verksamhetsdrivet r en central punkt.

9.4 En komplicerad verklighet

Verkligheten r de facto inte ett vlordnat system av ekvationer som kan kodas in i ett digitalt system av ettor och nollor. Gllande tidsrapportering och arbetstider s sker det stndigt frndringar. Exempel kan vara att folk blir befordrade, byter avdelningar, pltsligt slutar, eller byter bolag. ven arbetsuppgifter kan skilja sig frn hur det r programmerat att vara, projekt kan till exempel vara interna trots att de har en extern projektkod eller vara ett projekt som ligger kvar sedan gammalt som ett utbildningsprojekt, men har nu bytt karaktr. Ett system kan bara vara en modell av verkligheten, dr modellen frsker att efterlikna originalet i mjligaste mn. Undantag kan hanteras i enstaka fall, och drigenom ge en s komplett bild av verkligheten som mjligt. Men som sagt s kommer inget datorprogram att vara en exakt kopia av verkligheten, och s inte heller den aktuella prototyp eller en framtida vidareutvecklad applikation. Verkligheten r allts till sin natur komplicerad och inte kan beskrivas perfekt av datorer. Tidssystemet som tar in grunddatan r oflexibelt och kan inte, p ett optimalt stt fr just denna QlikView-lsning, hantera informationen. En applikation som bygger p en s komplicerad verklighet och oflexibel grunddata aldrig kan bli helt valid.

9.5 Frdelar med en framtida QlikView-lsning

En QlikView-applikation lser de flesta av de problem man hade med dagens rapportform (beskrivet i kapitlet om Frutsttningar fr en ny lsning). Man har mjlighet att ha all information som fanns i den tidigare rapporten, men med vldigt utkade mjligheter. Det r ltt att vxla mellan hgt och lgt, allts de stora perspektiven och de sm detaljerna. ver lag finns stor flexibilitet i anvndandet. Det finns fler perspektiv att titta p. Man kan vlja flera olika utgngsvariabler ssom person, team, projekt och tidstyp. Detta fr att applikationen kan ha ett bredare anvndningsomrde och kan vara intressant fr exempelvis teamchefer eller projektledare som vill flja upp sin verksamhet. Det r ltt att hitta enskilda poster. Detta gr att programmet skulle kunna vara effektivt fr problemlsning, och att reda ut olika tveksamheter i personalarbetet, en funktion som inte alls finns idag. Tanken r att de kontinuerliga dataladdningarna kommer att triggas automatiskt vilket r helt skilt frn hur det gr till idag. Detta gller dock inte undantag och specifika ndringar som mste sktas av en systemfrvaltare. En smakfrga r att det r roligare att anvnda programmet.

42

9.6 Nackdelar med en framtida QlikView-lsning

Systemet krver en viss kunskap om datat fr anvndning. Man br knna till namnbruket inom fretaget (ssom team, projekt och resurser) och ven den grundlggande strukturen kring tidskategorisystemet. Den kunskapen har de tilltnkta anvndarna idag (ledningsgruppen), men vid en kad anvndarkrets br man tnka p frgan. Lsningen kommer fortfarande att vara beroende av BW-laddningar frn Projus fr att kunna uppdatera, vilket sker ett specifikt datum, efter att Projus har lsts fr ndringar. Lsningen kommer ven fortsttningsvis att krva viss handplggning, det gr inte att automatisera hela lsningen. Detta gller frndringar som uppkommer lpande.

9.7 Ekonomiska aspekter

Dagens kostnad fr rapporteringen bestr i den arbetstid som krvs fr Excelarbetet. DAF berknar tidstgngen till en dryg arbetsdag i mnaden, och till det kan lggas ngra timmar som gr t till den andra rapporten, den som gr ut till teamcheferna. Utver detta anvnds ca en timme t att jmfra dessa tv rapporters siffror. Kalkylerad kostnad fr en ny lsning r dels tid fr nyutveckling och lansering av applikationen. Utver detta kommer ett visst systemunderhlla att krvas, vilket r svrt att uppskatta precis, det beror p hur mycket prototypen kan frbttras. Jag har gjort en uppskattning att det skulle kunna rra sig om 2h per laddning, per mnad. Excelrapporter: (drygt) 1 dag/mnad [ X] om X motsvarar antal dagar/mnad QV-rapporter: Utveckling Y dagar, samt underhll 2 timmar/mnad [Y+0,25X] Break even ns vid X=Y+0,25X, vilket innebr att det, beroende p vidareutvecklingstid, kan ta ett tag innan alternativinvesteringen blir lnsam . Men i berkningen ska ocks tas hnsyn till att man i och med dessa kostnader inte bara fr de rapportsiffror som tidigare finns, utan ven utkade anvndningsomrden och flera potentiella anvndare. Detta r ngot jag tror att Sandvik Systems Development kan f stor nytta av och ngot jag tror r viktigt att beakta.

43

10 Sammanfattande rekommendationer
Slutsatserna i arbetet gr att lsa kontinuerligt egentligen frn nulgesanalysen och framt, eftersom arbetsgngen i sig innefattat ett antal slutsatser fr vidare arbete. Under denna rubrik avser jag att kortfattat sammanfatta mina slutsatser fr vidare arbete. Detta fr att visa p hur arbetet r praktiskt tillmpbart.

10.1 Rekommendation till Sandvik Systems Developments ledningsgrupp

Under mitt arbete har jag funnit ett antal frdelar och ngra nackdelar med att frndra dagens rapportform. Fr att ta ett beslut om vidare arbete br ni frmst fundera ver vad ni r intresserade av. Dagens rapporter ger en versikt ver den information ni r primrt intresserade av. Det r bara ledningsgruppen som anvnder den rapport som DAF sammanstller. Om ni infr en QV-lsning kommer ni att kunna utka anvndarna av rapporterna, och detta mste ses ver vid vidareutveckling. Att f fler anvndare och kade mjligheter att f ut information man r intresserad av kring verksamheten r, enligt min sikt, den stora vinsten av att infra applikationen skarpt. Jag r vertygad om att det gr att f all funktionalitet som finns i dagens rapporter, samt ven ett stort antal nya mjligheter.

10.2 Fljder vid ett eventuellt infrande

Om ni vljer att vidareutveckla mot en frdig QV-applikation vill jag rekommendera er att Utse tydliga ansvarsomrden, bde utvecklings- och frvaltaransvar Formulera hur applikationen bst stdjer er vision, era ml och era processer Stll krav p den funktionalitet ni behver Frankra beslutet om applikationen hos berrda parter Identifiera vem utver ledningen som ska anvnda applikationen, min rekommendation r att fler n idag br dra nytta av den. Exempelvis team managers, service managers samt eventuellt project managers Avstt tid fr utbildning bland de identifierade anvndarna Ni jmkar ihop budget och tidskategorier efter de behov ni har att flja upp tidskategorier jmfrt med budget. Detta br gras p ett mer realistiskt stt n idag7. Anvnda applikationen d den r frdig

Totalbudget delas p 11 och juli nollbudgeteras

44

11 Kllfrteckning
11.1 Publicerat material
Anthony, R, Govindarjan, V (2007). Management Control Systems, 12th ed., McGraw-Hill, New York Elmasri, R, Navathe, S (2004). Fundamentals of Database Systems, 4th ed., Pearson/Addison-Wesley Education, Boston Holopainen, S, Lillrank, P, Paavola T (2001). Linking IT to Business a Tale of Discovering IT Benefits, Studentlitteratur, Lund Inmon, W.H (1992). Building the Data Warehouse, QED Technical Publ. Group, Boston Kahaner, L (1996). Competitive Intelligence: how to gather, analyze, and use information to move your business to the top, Simon & Schuster, New York March, J (1999). The Pursuit of Organizational Intelligence, TJ International, Padstow McCarthy, T, Risch, T (2005). Databasteknik, Studentlitteratur, Lund Sandstrm, B (2004). Att lyckas som operativ ledare, Industrilitteratur, Linkping Saxby, S (1990). The Age of Information: The past development and future signification of computing and communications, Macmillan, London Sderstrm, P (1997). Datalager Verksamhet, Metod, Teknik, Studentlitteratur, Lund

11. 2 Opublicerat material

Forsberg, M, Morell, M, (2006). Optimering av SQL-frgor fr analys i QlikView, examensarbete p C-niv, Karlstadsuniversitet Strmberg, D (2006). Analys av BI-system och utveckling av BI-applikationer, examensarbete p D-niv, Karlstads Universitet

11.3 Elektroniska kllor

Sandviks hemsida. Fakta i korthet, www.sandvik.se (2007-08-13) Sandviks hemsida. The Sandvik IT Portal (2007-08-13) Sandvik Systems Developments intrant (2007-08-13) QlikTechs hemsida. www.qliktech.se (2007-09-26)

11.4 Muntliga kllor

Gun Andersson, 2007-05-10 Bjrn Lindn, special services manager 2007-05-15, 2007-05-28, 2007-08-10 45

Eva K Larsson, ekonomichef 2007-05-24 Erik Pihl, business controller 2007-05-31 samt 2007-09-14 Anna-Lena Sderberg, application manager 2007-06-04 Kjell Persson, team manager 2007-06-07 Erik Ljungberg, team manager 2006-06-11 Lena Josefsson, QlikView-expert lpande juli-september 2007 Linda Fernqvist, systemutvecklare, lpande under perioden maj-oktober 2007 Johan Palm, team manager 2007-09-10

11.5 Figurfrteckning
Figur 1- IT-koordineringen p Sandvik _______________________________________________ 8 Figur 2 Underrttelsecykeln _____________________________________________________ 10 Figur 3 - Schematisk skiss av en stjrnstruktur ________________________________________ 13 Figur 4 - Schematisk skiss av snflingestruktur _______________________________________ 14 Figur 5 - Exempel p BEx-rapport Project Follow-Up ___________________________________ 24 Figur 6 - Exempel p flikrad i Excel-rapport __________________________________________ 24 Figur 7 - Intern tid och sammanstllning av gul tid i Excel-rapporten _______________________ 25 Figur 8 - Sammanstllning i Excel-rapport ___________________________________________ 26 Figur 9 - Diagram i Excel-rapport __________________________________________________ 27 Figur 10 Schematisk skiss ver dataladdningarna ____________________________________ 28 Figur 11 Stjrnstruktur fr Follow Up-tid____________________________________________ 30 Figur 12 - Tabellkopplingar i QlikView. ______________________________________________ 35 Figur 13 - Flikraden i QlikView_____________________________________________________ 35 Figur 14 - Exempel p hur tidstyper filtreras i tabelldefinitionen ___________________________ 36 Figur 15 - Ett utdrag av instruktionsfliken i QlikView ____________________________________ 36 Figur 16 - Nrbild p vnstermenyn i QlikView-rapporten ________________________________ 37 Figur 17 Valmjligheter i QlikView-rapporten ________________________________________ 37 Figur 18 - Exempel p tidskategorierna _____________________________________________ 38 Figur 19 - Exempel p hur valet av storhet ser ut i QlikView-rapporten _____________________ 39 Figur 20 - Snabbkommandon fr print och Excel-export samt val av tabell- eller diagramformat __ 39 Figur 21 - Exempel p budgetmtare fr den bl kategorin IGEM dr 78% av budgeten uppntts 40 Figur 22 - Exempel p ett team som ligger ngot under budgeterad debiteringskvot ___________ 40 Figur 23 - Illustration av datafldet vid laddning _______________________________________ 48

11.3.1 Kllfrteckning fr figurer Fr de figurer dr ingen klla anges r kllan den rapporten som figuren r tagen frn, allts DAF-rapport fr Excel eller egen fr QlikView. Figur 1. Sandviks intrant, The Sandvik IT Portal, 2007-08-13 Figur 3. Egen bearbetning av Sundstrm, s 135 Figur 3. Egen bearbetning av Sderstrm, s. 63 Figur 4. Egen bearbetning av Sderstrm, s. 64 Figur 21. Egen bearbetning av Strmberg 2006, s16

46

12 Bilagor
Frteckning av bilagor
I de fall d kllan inte r en produkt av examensarbetet anges klla inom parantes, dr efternamn refererar till de respndenter som terfinns under muntliga kllor. 1. Teknisk information om QlikView 2. Kravspecifikation 3. De olika tidskategorierna (Ljungberg) Borttagen ut denna version 4. Tabeller och flt som laddas till QV frn BW (Fernqvist) Borttagen ut denna version 5. Detaljerad stjrnstruktur i BW (Fernqvist) Borttagen ut denna version 6. Scriptkod (egen, med hjlp av Josefsson) Borttagen ut denna version 7. Intervjumall

47

Bilaga 1- Teknisk information om QlikView

Datamngden i det befintliga datalagret (BW) r sparad i en kubstruktur. Tyvrr r kubstrukturen svr att hmta data ur p ett strukturerat stt, rent teknisk. Drfr omformas strukturen, och man lgger in datan i en s.k. ODS (operational data store), ett lagringsformat dr alla flt har ett tekniskt namn (ex [/BIC/ZIS00048W]). Frn ODS:en kan man sedan via en SAP-connector lsa in strukturen till QV. Connectorn behver en s kallad FileClient fr att kunna lsa ver datat. De data som nskas specificeras i SQL-filer, som bestr av enkla SQL-queries (av typen SELECT ODS-fltnamn FROM ODS-tabellnamn). FileClient lser frn SQL-filerna och skapar en qvd-fil som motsvarar varje sql-query. Dessa laddar man sedan in i sjlva QlikView-programmet, i ett frsta steg. I QlikView bygger man applikationer genom att man lser in datan som ska anvndas via ett script. Scriptet kan man lsa in med egenskriven kod, eller s kan man ladda in datan via frdiga strukturer, till exempel qvd- eller xls-filer. I det frsta steget laddar man allts in de qvd-filer som skapats i ett QV-script. I nsta steg (sjlva applikationen) mste man ordna upp i datastrukturen. QV fungerar s att alla tabeller r kopplade, med en (och endast en) nyckel. Om det finns multipla nycklar s kopplas dessa ihop till en sammansatt nyckel. Det fr inte heller finnas mer n en variabel med samma namn, p de stllen dr det finns samma namn (date, hours, amount och liknande) mste dessa dpas om eller modelleras om fr att accepteras. Alla sdana hr ndringar grs i det aktuella scriptet, och sparas sedan, och laddas om. Nr scriptet r frdigt, och alla data r laddade kan man brja modellera med datamngderna. Beroende p vilken information man r intresserad av kan man gra olika typer av berkningar eller grafiska element. Det kan till exempel rra sig om statistiska berkningar, olika grafer eller summeringar.

Figur 23 - Illustration av datafldet vid laddning

48

Bilaga 2 - Kravspecifikation fr en Qlikview-applikation

Funktionell beskrivning
QlikView har olika worksheets, liknande Excel. Resultatet ska bli ett antal funktionella worksheets. Flikarna r tnkta att representera: En flik fr grn tid: extern debitering och OH-debitering En flik fr bl tid: interna projekt och uppgifter En flik fr gul tid: intern tid vrigt, uppdelat i ett antal kategorier En flik fr sammanstllning av de tre, hr ska man f en verblick ver hur verksamheten gr En flik fr budgetuppfljning fr de siffror som finns tillgngliga En flik fr instruktioner Alla flikar har samma utskningsgrunder, nmligen: Tid, r och mnad Team (ca 15 st) Projects (runt 100 st) Resources (>300) Hela SSD samt hela innevarande r r default-skningen, allts startvrde. (I prototypen finns dock enbart data frn maj 2007)

Konsekvenser
Tillgnglighet Applikationen lggs p den interna Sandvik-QV-portalen. Dr kommer de tilltna anvndarna t QV antingen som webdokument (rekommenderat) eller via att de har QV installerat (ej rekommenderat) Pverkan p befintligt rapportsystem Eftersom vi laddar ver data frn BW direkt till QV kommer inte det nuvarande Excelformatet att pverkas alls. Man kan fortstta med den befintliga rapporteringen som frut. Om frsket med QV skulle falla vl ut finns det god potential att utveckla QVapplikationen skarpt. D mste alla de undantag som hanteras i dagens rapporter men inte i prototypen fras in p ett smidigt stt i den nya applikationen. Verksamhet Tidsrapporteringen r en kritisk del av SSDs verksamhet. Eftersom rapporteringen utgr grunden fr faktureringen till kund s r det grunden till hela den ekonomiska analysen. Att ha ett fungerande och lttanvnt tidsuppfljningsverktyg r drfr helt avgrande fr verksamheten. Verksamheten kommer dock inte pverkas nmnvrt av prototypen, annat n om man beslutar att vidareutveckla den skarpt.

49

Drift Driftsproblemet r till strsta del okomplicerat, d uppdateringar laddas regelbundet frn BW krvs ingen strre insats. Det stora driftsproblemet bestr i de undantag som rapporten innehller. Det finns ett antal avvikelser som ndras mnadsvis i och med att verksamheten frndras. Dessa undantag mste matas in manuellt av ngon driftsansvarig, som har just den kunskapen, samt kunskapen om hur man modifierar QV-applikationen. Idag grs dokumentet frn grunden varje mnad, och en person sitter och lgger in alla dessa undantag. S jmfrt med idag blir det en minskning av underhllsbehov, men det gr inte att helautomatisera. Utbildning Ingen av de intervjuade anvndarna har ngonsin jobbat med QV. De har dock mycket god datorvana. Detta innebr att man mste ha ngon typ av inledande utbildning i hur man anvnder QV, och drefter borde de, om programmet r tillrckligt lttanvnt kunna navigera och anvnda det p egen hand. Migrering av data Hela applikationen bygger p att man kan verfra data mellan de olika systemen. Frn BW tar man verklig produktionsdata och fr ver via ODS-format till QlikView. Dr laddar man data i flera steg, i vilka man genomfr olika typer av modellering dr det sista steget r den slutgiltiga applikationen. (Se bilaga med dataflt fr information om vilka data som ska laddas ver frn BW till QV)

Tolkning av anvndarkrav
Hr beskriver jag de krav som anvndarna har, och hur jag tolkat detta i design och modellering, allts i rent praktiska termer. Ett lttanvnt format De tidigare tv rapportformerna var svranvnda av olika anledningar. Bex-rapporterna var dels svra att f tillgng till, och sedan mste man lra sig hur man gr specifika utskningar, vilket var fr svrt om de bara anvnds ca en gng per mnad. P Excel-bladet var skningarna frdiggjorda, och sammanstllningarna var frglagda enligt den specifika frgkod som tagits fram. Excelbladet innehller 17 flikar, av olika karaktr. Innehllet r svrverblickbart. En QV-lsning r anvndarvnlig p flera stt. Man skapar sjlv designen, s det finns alla mjligheter att gra lsningen effektiv och lttanvnd. Man kommer ven att ha tillgng till data i utvalda utskningsrutor, vilket underlttar frstelse och anvndning. Ett lttillgngligt format QV-lsningen kommer att lggas som ett webdokument p Sandviks interna QV-portal. Dr uppdateras det lpande, antingen hndelsetriggat eller tidsstyrt. Man kommer d alltid t de senaste siffrorna via ett enkelt web-grnssnitt.

50

Mjlighet till flexibilitet Skillnaden mellan QV och Excel r enorm, gllande just flexibilitet. Eftersom QV r ett OLAP-verktyg s jobbar den mot det insparade datalagret. Detta ger mjlighet till mycket specifika drill-downs, d all data finns inlst, och finns tillgnglig genom de utskningar man gr. Det r en designdetalj vilka skalternativ man vljer att ha, dessa kommer att tydliggra strukturen. Ltt jmfrbart mot budget Budgeten r bara att lgga in (frn exempelvis befintliga Excel-dokument) som separata data, och markera i grafiken, s data kommer alltid att jmfras mot budgetvrden p de stllen dr dessa finns. Tydligt grnssnitt Anvndarna har behov att kunna se bde det stora och det lilla, allts se trender och sammanhang samtidigt som det finns intresse av att kunna drilla p enskilda problemposter. Detta lser QlikView p ett bra stt dr anvndarens egna utskningar bestmmer nivn p den visade informationen. Det ska inte finnas olika bud om informationen Med dagens spridda rapportformer, dr det i nulget finns minst fyra8 olika stt att f fram liknande information dr alla bygger mer eller mindre p varandra. Detta problemet verbygger man genom att ha en enda rapport. Siffrorna i rapporten kommer frn en entydig dataklla, tabellerna i BW, och kan drfr enkelt kllgranskas om problem skulle uppst.

Tv excelrapporter, BEx-rapporter samt vanliga utskningar i Projus

51

Bilaga 7 - Intervjumall
Till vad (/hur) anvnder du rapporterna idag? Vilken information r viktig fr att du ska kunna gr bra bedmningar? Vilken av den informationen finns samt finns inte p dagens rapporter. r det ngot annat du tnkt p som fattas p dagens rapporter? Till vad skulle du vilja anvnda rapporterna? Hur skulle rapporterna kunna utformas fr att underltta ditt arbete? Vad p dagens rapporter r helt verfldigt? Det finns ett frslag p en lsning dr man kan gra utskningar, vilket inte r mjligt idag. Finns det ngot srskilt perspektiv du tycker skulle vara intressant fr din verksamhet? (projekt/leverans, enskilda personer etc.) Hur skulle du vilja komma t dem (intrant, epost??) Datorvana, hur stor r din datavana inom: stor SAP BW Excel Qlikview viss vana aldrig anvnt

52