Från- och närvaroplanering för Scania Sverige

(1)

Från- och närvaroplanering

för Scania Sverige

Work Attendance Planning for Scania Company in Sweden

Hussein Al-Sahaf

Madi Susso

Examensarbete inom teknik och management, grundnivå Kandidat Degree Project in Engineering and Management, First Level Stockholm, Sweden 2013

(2)

(3)

(4)

(5)

Från-‐‑ och närvaroplanering Hussein Al-‐‑Sahaf & Madi Susso

Sammanfattning

2013-‐‑06-‐‑10

Sammanfattning

Detta examensarbete gjordes i två syften, att ge Scania teoretiskt un-‐‑ derlag till en ny teknik för hantering av personalens från-‐‑ och närvaro-‐‑ planering, samt implementera den nya tekniken. Scanias dåvarande lösning utnyttjades genom att använda olika Excel-‐‑ark, dessa har uppfattats som ineffektiva och krångliga att arbeta med. Detta har lett till en hel del extra administrativt arbete och behovet av en ny lösning definierades till ett examensarbete.

Den initiala fasen av projektet handlade om att förstå relevanta proces-‐‑ ser rörande från-‐‑ och närvaroplanering. Allt eftersom processerna var förstådda definierades krav på den nya lösningen genom kvalitativa metoder och intervjuer med respondenter av olika befattningar från verksamheten. Kraven som erhölls från intervjuerna visade sig vara relativt konsistenta och fastställdes i en kravspecifikation. Kravspecifi-‐‑ kationen användes för att utvärdera olika lösningar som valts ut från marknadens utbud. Vidare genomfördes en make or buy analys som gjorde det möjligt att avgöra om lösningen skulle köpas in eller utveck-‐‑ las internt. Efter interna diskussioner inom Scania, där resultaten från utvärderingen och make or buy analysen analyserades, fattades beslutet att den nya lösningen skulle byggas i en Microsoft SharePoint miljö. Miljön var redan tillgänglig för Scania och implementeringen gjordes i form av en pilotimplementering. Två grupper från Scanias verksamhet fick en förfrågan om de ville agera piloter, i syfte att utvärdera lösning-‐‑ en efter styrkor, svagheter och önskad funktionalitet. Pilotfasen är planerad att starta i början av september 2013.

Nyckelord: Frånvaro, närvaro, SharePoint, make or buy, kravspecifikat-‐‑

(6)

Abstract

2013-‐‑06-‐‑10

Abstract

This thesis was done with two-‐‑fold purpose, to give Scania a theoretical base for a new technology for management of the personnel presence and absence planning and to implement this new technology. Scanias former solution was utilized by using different Excel sheets and these have been perceived as inefficient and cumbersome to work with. This has led to a lot of additional administrative work and the need for a new solution was defined to this thesis.

The initial phase of the project focused on understanding the relevant processes related to the presence and absence planning. When the processes were well understood, requirements on the new system were captured through qualitative methods and interviews with respondents of different positions from the enterprise. The requirements obtained from the interviews proved to be relatively consistent and was defined in a requirement specification. These requirements were used to evaluate different solutions chosen from the commercial stock. In addition, a make or buy analysis were created and made it possible to determine whether the solution would be bought or developed internally. After internal discussions within Scania, where the results from the alternative solution evaluation and the make or buy analysis was considered, it was decided that the new solution would be built in a Microsoft SharePoint environment.

The environment was already available for Scania and the implementation was done as a pilot implementation. Two groups from Scanias enterprise was asked to act pilots, in order to evaluate the solution by strengths, weaknesses and desired functionalities. The pilot phase is planned to start in early September 2013.

Keywords: Absence, SharePoint, make or buy, requirements, implemen-‐‑

tation, long-‐‑term planning

(7)

Förord

2013-‐‑06-‐‑10

Förord

Vi skulle vilja tacka vår handledare Carina Larsson och Anette Rydh för ert engagemang och stöd i detta projekt. Ett stort tack riktas även till Frederic Anquetil som har varit väldigt hjälpsam under implementeringen. Tack!

(8)

(9)

Från-‐‑ och närvaroplanering

Hussein Al-‐‑Sahaf & Madi Susso Innehållsförteckning 2013-‐‑06-‐‑10

Innehållsförteckning

Sammanfattning ... ii Abstract ... iii Förord ... iv Terminologi ... vii 1 Introduktion ... 1

1.1 Bakgrund och problemmotivering ... 2

1.2 Övergripande syfte / Högnivåproblemformulering ... 2

1.3 Avgränsningar ... 2

1.4 Konkreta och verifierbara mål / Lågnivåproblemformulering .... 3

2 Teori ... 4

2.1 Kvalitativ metod ... 4

2.2 Intervju ... 5

2.2.1 Intervjuundersökningens 7 stadier (Kvale, 1997, 85) 6 2.3 Krav ... 7

2.4 Make or buy analys ... 8

2.5 Processmodellering ... 9

2.6 SharePoint ... 10

3 Metod ... 12

3.1 Processmodell för arbetet ... 12

3.2 Litteraturstudier ... 14

3.3 Intervju och möten ... 14

3.4 Kravspecifikation ... 15

3.5 Make or buy analys ... 16

4 Lösningsalternativ ... 17 4.1 Workshop ... 17 5 Konstruktion ... 18 5.1 Arbetsprocess ... 18 5.2 Intervjuer ... 19 5.3 Uppsättning ... 21

5.4 Toolkit Pentalogic Planner ... 22

6 Resultat ... 24

(10)

Hussein Al-‐‑Sahaf & Madi Susso Innehållsförteckning 2013-‐‑06-‐‑10

7.1 Metod-‐‑ och resultatdiskussion ... 29

7.2 Framtida arbete ... 32

7.3 Etisk/hållbarutveckling diskussion ... 33

Källförteckning ... 34

Bilaga A: Kravspecifikation ...

Bilaga B: Utvärdering ...

Bilaga C: Make or buy analys ...

Bilaga D: Use Case ...

Bilaga E: User manual ...

(11)

Hussein Al-‐‑Sahaf & Madi Susso Terminologi 2013-‐‑06-‐‑10

Terminologi

Förkortningar och akronymer

Scania När Scania nämns i rapporten syftar man på Scania Sverige.

ActiveDirectory En katalogtjänst där Scania bland annat lagrar information om användare och resurser.

Avdelning Består av både sektioner och grupper. Sektion Består av grupper.

Grupp Är den lägsta nivån av verksamhetens uppdelning. SharePoint En webbapplikation som utvecklats av Microsoft.

E-‐‑Days Webbaserat frånvaroplaneringssystem som utvecklats av E-‐‑Days.

Personec Ett system som är utvecklat av Aditro innefattar tidregi-‐‑ strering, projektrapportering och arbetskostnadsupp-‐‑ följning.

Outlook Programvara som tjänar som mejlklient och kalender.

(12)

(13)

Hussein Al-‐‑Sahaf & Madi Susso Introduktion 2013-‐‑06-‐‑10

1 Introduktion

Idag är de flesta industriella och kommersiella företag starkt beroende av sin informationsteknik. Företag tillbringar flera procent av sina totala intäkter på IT-‐‑drift och det är vanligt att företagen har flera IT-‐‑projekt och andra projekt igång samtidigt (Larsson och Ljungberg, 2001, 320). Detta är en vanlig företeelse även på Scania och därför är det viktigt för cheferna att få en bra överblick över personalens från-‐‑ och närvaro för att kunna planera effektivt arbete.

En fungerade och effektiv hantering av från-‐‑ och närvaroplanering i verksamheter kan vara en betydelsefull faktor för att minska det administrativa arbetet. De olika avdelningarna på Scania använder en väldigt simpel form av Excel-‐‑ark för att hantera personalens från-‐‑ och närvaroregistrering och planering. Detta medför en hel del administrativt arbete och har upplevts som krångligt av många medarbetare. Scania IT tog initiativet att handleda två examensarbetare för att införa en effektivare metod att hantera detta. Uppgiften bestod av en förstudie, vilket skulle resultera i en kravspecifikation, en utvärdering och en make or buy analys, eventuellt följt av en implementeringsfas. På marknaden finns det redan lösningar som behandlar från-‐‑ och närvaroplanering men det gällde att analysera både verksamheten och de system som finns tillgängliga för att hitta den optimala lösningen. Det är alltså viktigt att förstå verksamheten och dess relevanta processer som en helhet för att kunna avgöra vilka konsekvenser olika lösningsförslag ger.

Scania är ett globalt företag och finns på ett eller annat sätt i över 100 länder, produktionen är dock begränsad till Europa och Latinamerika. Huvudkontoret finns i Södertälje, Sverige, med runt 9100 anställda (Scania, 2013). På grund av Scanias storlek så är verksamheten uppdelad i avdelningar, sektioner och grupper. Scania IT, beställaren av examensarbetet, är ett dotterbolag som är helägt av Scania. Scania IT’s uppgift är att skapa och underhålla IT-‐‑lösningar åt koncernen.

(14)

1.1 Bakgrund och problemmotivering

”En fungerande men ineffektiv metod”, var betyget på Scanias Excel-‐‑ark som användes för att hantera från-‐‑ och närvaroregistrering och planering av semester, utbildning/tjänsteresor, föräldraledighet etcetera. Metoden resulterade i en onödig mängd administration och Scania har länge visualiserat en förbättring, men av olika anledningar har det inte verkställts. I den nya lösningen skulle många hänsyn tas, då i princip samtliga Scaniaarbetare är berörda och kommer att påverkas av det nya tillvägagångssättet. Det gällde därför att samla in synpunkter och uppfattningar från olika delar av verksamheten.

Ett problem är att Scania är en stor verksamhet som är nedbruten i ett mycket stort antal verksamheter, avdelningar och grupper. Därför ser behoven och kraven olika ut, men eftersom lösningen ska utnyttjas i hela Scania måste lösningen täcka samtliga essentiella krav.

1.2 Övergripande syfte / Högnivåproblemformulering

Projektets övergripande syfte är att identifiera behov och krav på ett nytt system samt tillvägagångssätt för att ersätta Scanias från-‐‑ och närvaroregistrering, hantering och planering, vars befintliga system har upplevts som ineffektiv och krånglig. Lösningen ska vara både använ-‐‑ darvänlig och enkel för att rapportera och ta ut rapporter för arbetarnas från-‐‑ och närvaro.

1.3 Avgränsningar

Arbetet är avgränsat till två faser, en förstudie och en implementering. Förstudien är i sin tur avgränsad till tre milstolpar, en kravspecifikation, en utvärdering och en make or buy analys. Implementeringsfasen är starkt beroende av resultatet från förstudien. Skulle det visa sig att förstudien kräver betydligt mer arbetstid än förutspått kan det vara ett komplementresultat för hela projektet. Dock är det optimala att projektet ska resultera i en praktisk och implementerad lösning. Lösningen har fokus på att hantera från-‐‑ och närvaroplanering, det vill säga när det talas om semester, tjänsteledighet, föräldraledighet etc. och inte frånvaro på daglig nivå.

(15)

1.4 Konkreta och verifierbara mål /

Lågnivåproblemformulering

Första delen av arbetet består av en förstudie som ska behandla projektmål 1-‐‑4:

§ P1: Identifiera behov, arbetssätt och processer relaterade till från-‐‑ och närvaroplanering

§ P2: Samla krav och skapa en kravspecifikation

§ P3: Utvärdera möjliga lösningar och skapa en sammanställning med för-‐‑ och nackdelar

§ P4: Genomföra en make or buy analys § P5: Implementera vald lösning

Förstudien följs eventuellt upp av en implementering som kan mätas mot funktionella samt icke-‐‑funktionella krav, projektmål 5.

(16)

(17)

Hussein Al-‐‑Sahaf & Madi Susso 2013-‐‑06-‐‑10 Teori

2 Teori

2.1 Kvalitativ metod

En otroligt stor mängd information går att hitta på internet, i böcker och i forskningsrapporter. Betydelsen av information som fås från intervjuer och användbarhetsstudier är otroligt viktigt för att förstå problemsituationen och för att erhålla förstahandsinformation. Två metoder brukar därför diskuteras, kvantitativa samt kvalitativa metoder (Preece, Rogers, och Sharp, 2002, 228). Kvantitativa metoder tyder på mätningar och flexibilitet, medan kvalitativa metoder behandlar beskrivningar, strukturering och anekdoter. Det går således att säga att när man talar om kvantitativa metoder, talar man om objektiv, och kvalitativa metoder subjektiv. Dock behöver detta inte alltid vara sant och läsaren bör därför inte begränsa sin ställning till detta. Om man diskuterar ordens betydelse innefattar en kvantitativ metod en analys av en stor mängd data och en kvalitativ metod en mindre mängd data med mer fördjupad information (Holme och Solvang, 1997, 92-‐‑93) (Starrin och Svensson, 1994, 51-‐‑52).

I detta projekt kommer huvudsakligen kvalitativa metoder att utnyttjas och dessa kommer att genomföras via intervjuer. Detta innebär ofta en längre kontakt med respondenten vilket ger möjligheten att få ut mer detaljerad information och gå in mer djupgående i intressanta aspekter som kommer fram under samtalen. Det blir enklare och tydligare att kartlägga vilka aspekter som är extra viktiga då de relateras av olika respondenter. Dock kan det ibland vara svårt att bestämma exakt vad det är som är viktigt om man endast har ett fåtal respondenter. Därför är det viktigt att vara tydlig med vad man vill få fram. Risken finns att en viss subjektivitet uppkommer i resultaten, då enskilda personers åsikter kan få stor vikt (Holme och Solvang, 1997, 99). Till sist bör man påpeka att man inte borde definiera kvantitativa studier med objektivitet och kvalitativa med subjektivitet. Man bör istället, oavsett val av metod, försöka utesluta osäkerhetsfaktorer i så stor utsträckning som möjligt.

(18)

2.2 Intervju

En intervju kan definieras genom tre olika kategorier: ostrukturerade, strukturerade och halvstrukturerade (Preece, Rogers och Sharp, 2002, 228). För att få en allmän bild över ett problemområde lämpar sig ostrukturerade intervjuer. En sådan intervju kan ge svar på en mängd olika frågor som behandlas i olika områden och kan resultera i underlag till mer detaljerade och strukturerade intervjuer. Fördelen med ostrukturerade intervjuer är att de tillhandahåller kvalitativ data och intervjun brukar ofta leda till nya frågor som man ännu inte definierat och tagit hänsyn till, vilket kan vara bra när respondentens syfte är något oklart. Dock finns nackdelen med ostrukturerade intervjuer att de kan ta mycket tid och att utvunnen data kan vara svår att analysera då resultatet inte är förutspått från början (Kvale 1997, 19,117) (Preece, Rogers, och Sharp, 2002, 228-‐‑230).

Det finns en stor fördel med att tillämpa strukturerade intervjuer, då en förbestämd och strukturerad frågepool förbereds, och som följs noggrant, vilket leder till att intervjuaren har kontroll över intervjun. På så vis blir det enkelt att anteckna och ta emot svaren. Halvstrukturerade intervjuer är ett mellanting av de tidigare beskrivna metoderna, intervjun är upplagd med både fria och förutbestämda frågor. Denna metod är lämplig att anpassa om det finns tydliga frågeställningar som ska besvaras och samtidigt en vilja att leda en öppen diskussion (Preece, Rogers, och Sharp, 2002, 228-‐‑230).

När antalet personer som ska intervjuas ska bestämmas gäller det helt enkelt att ”intervjua så många personer som behövs för att ta reda på vad du behöver veta” (Kvale, 1997, 97). Det är viktigt att få in rätt mängd intervjuer, för få intervjuer leder till att det blir svårt att generalisera och omöjligt att pröva hypoteser, för många intervjuer leder till att det inte går att göra mer ingående tolkningar av intervjuresultaten. Antalet intervjuer beror således på undersökningens syfte (Kvale, 1997, 97)

(19)

2.2.1 Intervjuundersökningens 7 stadier (Kvale, 1997, 85) 1. Tematisering

Under detta steg formuleras undersökningens syfte och frågeställ-‐‑ ningar fastställs. Undersökningens varför och vad bör klargöras in-‐‑ nan frågan hur ställs.

2. Planering

Innan intervjuerna påbörjas ska upplägget av undersökningen med hänsyn till alla sju stadierna planeras. Planering görs utifrån vilken kunskap som eftersträvas och med beaktande av de mora-‐‑ liska konsekvenserna av undersökningen.

3. Intervju

Genomföra intervjuer med hjälp av en intervjuguide och vald me-‐‑ tod.

4. Utskrift

Förbered intervjumaterialet för analys, vilket vanligtvis innebär en överföring från talspråk till skriftspråk.

5. Analys

Avgör utifrån undersökningens syfte och ämne och på grundval av intervjumaterialets karaktär vilka analysmetoder som är lämp-‐‑ liga.

6. Verifiering

Under detta steg fastställs intervjuresultatets reliabilitet, validitet och generaliserbarhet. Reliabiliteten handlar om resultatets konsi-‐‑ stens och validitet om intervjustudien undersökt vad den var av-‐‑ sedd att undersöka.

7. Rapportering

Rapportera resultatet av undersökningen och de använda meto-‐‑ derna i en form som motsvarar vetenskapliga kriterier, som beak-‐‑ tar etiska aspekter av undersökningen och leder till en läsbar pro-‐‑ dukt.

(20)

2.3 Krav

Innan en design och/eller en implementering av ett system kan genomföras måste det finnas en förståelse för vad syftet med systemet är. Vad ska systemet göra och med vilken prestanda? Ur detta växer det fram olika behov av funktionaliteter som systemet skall och bör kunna hantera, dessa funktionalitetsaspekter är de som benämns som krav (Professor Jelena, 2013) (Sommerville, 2010, 36). En kravspecifikation pekar på processen att skriva ner användarkrav och systemkrav i ett kravdokument. En kravspecifikation kan se ut och konstrueras på många olika sätt, idealet är att kraven är tydligt formulerade, väl definierade, lätt begripna, kompletta och logiska. Kravspecifikationer kan bli väldigt stora och komplexa, det är därför viktigt att utveckla kraven med ett perspektiv, eftersom intressenterna med stor sannolikhet kommer tolka dem olika. En organiserad kravspecifikation hjälper till med förståelse, sökning, evaluering och återanvändning av krav

(Professor Jelena, 2013).

Krav brukar huvudsakligen vara av två typer: användarkrav och systemkrav (Professor Jelena, 2013) (Sommerville, 2010, 37). Användarkraven för ett system beskriver de funktionella kraven, det vill säga de krav som beskriver funktionaliteten hos det önskade systemet,

samt de icke-‐‑funktionella kraven, det vill säga krav som beskriver hur

systemet ska arbeta så att det blir lättförståeligt för systemets slutanvändare, som troligen inte har någon detaljerad teknisk kunskap. Användarkraven ska alltså skrivas på ett naturligt språk med enkla tabeller, formler och diagram. Kraven bör endast specificera det externa beteendet av systemet och kravdokumenten ska därför inte inkludera detaljer av systemets arkitektur eller design (Sommerville, 2010, 94).

Systemkraven är en fördjupning av användarkraven och används av mjukvaruingenjörer som en grund för systemdesignen. Systemkraven ger en mer detaljerad information och beskriver konkreta interaktioner mellan användare och systemet (Sommerville, 2010, 94).

(21)

2.4 Make or buy analys

Make or buy är en analys som ska ligga till grund för det strategiska beslut som kan påverka organisationens konkurrenskraft och handlar om att göra ett välplanerat val mellan att tillverka en produkt internt (in-‐‑house) eller köpa produkten av en extern leverantör (Östh, 2013) (Balakrishnan och Cheng, 2005, 1-‐‑2). Beslutet består av två viktiga faktorer som ska beaktas, dessa är kostnaden och tillgängligheten av produktionskapaciteten. När kostnaderna övervägs bör alla relevanta kostnader inkluderas och vara långsiktiga i sin natur. Ett företag kan besluta att köpa produkten istället för att tillverka den internt, om det är billigare att outsourca än att tillverka, eller om det inte finns tillräcklig produktionskapacitet att tillverka den inom företaget (Balakrishnan och Cheng, 2005, 1-‐‑2).

Traditionellt har kostnaden varit den viktigaste drivkraften när beslut tagits, men organisationer idag fokuserar mer på den strategiska betydelsen av beslutet. Till exempel outsourcar inte ett bilföretag skapandet av motorer eftersom motorerna är en betydelsefull del av bilen, däremot outsourcar bilföretag produktionen av bilbatterier till en leverantör som kan leverera till hög kvalitet och låga kostnader (Balakrishnan och Cheng, 2005, 1-‐‑2). Generellt outsourcar organisationer inte kärnverksamheten utan bara aktiviteter som inte är centrala. En tumregel för outsourcing är att en produkt ska utvecklas internt om något av följande krav inte kan uppfyllas (Leong, Tan och Wisner, 2011, 53-‐‑54)

§ Varan är avgörande för framgången av produkten, inklusive kundens uppfattning om viktiga produktegenskaper.

§ Varan kräver specialiserad konstruktion och färdigheter till-‐‑ verkning eller utrustning, och antalet duktiga och pålitliga le-‐‑ verantörer är mycket begränsade.

§ Varan passar väl inom företagets kärnverksamhet eller inom det som företaget måste utveckla för att uppnå framtida mål.

(22)

2.5 Processmodellering

Business Process Modeling Notation (BPMN) är en global standard för processmodellering, det primära målet med BPMN är att ge en notation som är lätt att förstå av alla affärsanvändare, från analytiker som skapar de första utkasten till processer till de tekniska utvecklarna som ansvarar för genomförandet av teknik som kommer att utföra dessa processer. Den visar även hur processen genomförs, vad det är för relation mellan komponenterna, vem som ansvarar för vad och när saker genomförs, samt varför det genomförs (White, 2004).

Unified Modeling Language (UML) är ett allmänt visuellt modellerings-‐‑ språk som används för att specificera, visualisera, konstruera och dokumentera beståndsdelarna av ett mjukvarusystem. UML är ett språk som alla modellerare kan förstå och använda, det måste vara tydligt nog för att hantera alla de begrepp som uppstår i ett modernt system. Genom att använda UML kan beslut fattas och man kan få en förståelse om systemet som ska konstrueras. Det är viktigt att inte förväxla UML med en fullständig utvecklingsmetod, då den inte omfattar någon steg för steg utvecklingsprocess (Fowler, 2004, 1) (Larman, 2004, 4, 10).

Det finns inga tydliga gränser mellan olika begrepp och konstruktioner i UML och för enkelhetens skull har språket delats upp i olika vyer. En så kallad Use Case vy möjliggör modellering av funktionaliteten i systemet som uppfattas av utomstående användare, som kallas aktörer. Ett Use Case, eller användningsfall, är en konsekvent enhet av funktionalitet uttryckt som en transaktion mellan aktörer och systemet. Syftet med att presentera ett användningsfall är att lista aktörer och användningsfall och visa hur dessa två integrerar (Fowler, 2004, 99) (Larman, 2004, 46-‐‑ 47).

(23)

2.6 SharePoint

”SharePoint är kortnamnet som en del använder på olika Microsoft SharePoint-‐‑ produkter eller -‐‑tekniker. SharePoint kan användas för att skapa samarbetswebbplatser där det går att dela information med andra, hantera dokument från början till slut och publicera rapporter som alla kan använda för att fatta bättre beslut.”-‐‑ (Microsoft Office, 2013)

SharePoint omfattar en mångsidig uppsättning av webbteknologier som backas upp av en gemensam teknisk infrastruktur. SharePoint kan beskrivas som ett operativsystem för stora företag, har ett Microsoft Officeliknande gränssnitt och är integrerad med Officepaketet. Systemet kan användas för att åstadkomma intranät portaler, hantera dokument och filer, hemsidor, Business Intelligence (BI) med mera. SharePoint består även av arbetsflödes automation, process-‐‑ och systemintegration (Microsoft Office, 2013).

Vad är då en SharePoint Site? En SharePoint site är en webbsida som ger ett centralt lagringsutrymme för dokument, information och idéer. En SharePoint webbplats är ett verktyg för samarbete, precis som en telefon är ett verktyg för kommunikation eller ett möte är ett verktyg för beslutsfattande. Webbplatsen hjälper grupper av människor (oavsett arbets-‐‑ eller socialgrupp) att dela information och arbete med varandra. Med hjälp av webbplatsen kan du till exempel:

§ Samordna projekt, kalendrar och scheman

§ Diskutera idéer och granska dokument eller förslag

§ Dela information och hålla kontakten med andra människor. SharePoint webbplatser är dynamiska och interaktiva – medlemmar på webbplatsen kan bidra med egna idéer och innehåll samt kommentera eller bidra till andras (Anquetil, 2013).

(24)

Det finns två olika versioner av SharePoint:

§ SharePoint Foundation – den grundläggande tekniken för alla Sha-‐‑

rePoint webbplatser. SharePoint Foundation är tillgängligt för gratis lokal distribution. Du kan använda SharePoint Foundation om du snabbt vill skapa olika typer av webbplatser där du kan arbeta till-‐‑ sammans med andra med webbsidor, dokument, listor, kalendrar och data. Denna version är alltså av den längsta nivån och har be-‐‑ gränsade utvecklingsmöjligheter (Microsoft Office, 2013).

§ SharePoint Standard -‐‑ En serverprodukt som är beroende av Sha-‐‑

rePoint Foundation-‐‑teknik för att tillhandahålla ett konsekvent och välbekant ramverk för listor och bibliotek, webbplatsadministration och webbplatsanpassning. SharePoint Server innehåller alla funkt-‐‑ ionerna i SharePoint Foundation plus ytterligare funktioner som in-‐‑ nehållshantering för företag, Business Intelligence, företagssökning, personliga profiler och nyhetskällor. SharePoint Server är tillgängligt för lokal distribution eller som en del av ett molnbaserat tjänsteer-‐‑ bjudande som Microsoft Office 365 (Microsoft Office, 2013).

(25)

Hussein Al-‐‑Sahaf & Madi Susso 2013-‐‑06-‐‑10 Metod

3 Metod

Projektet har handlat om att studera och analysera Scanias verksamhet och mer ingående deras process hur de hanterar planeringen för personalens från-‐‑ och närvaro för semester, tjänstledighet, föräldraledighet etcetera. Studierna och analysen har lett fram till ett ramverk för att kunna utforska marknaden och möjliggöra en presentation av ett verktyg som ska ersätta verksamhetens nuvarande metod att hantera planeringen. Projektet introducerades med ett klart behov som bestod av två essentiella delar, en förstudie och en implementering. Mycket gick ut på att ta fram och förstå de huvudsakliga kraven som systemet måste uppfylla och utifrån dem hitta den mest optimala lösningen med hänsyn till både funktionalitet och kostnad.

3.1 Processmodell för arbetet

Sättet som arbetsgången har utformats efter refereras till ett agilt tillvägagångssätt och anpassades på grund av att det fanns stora sannolikheter att till exempel kravspecifikationen skulle kunna byggas på under projektets gång, även fast det var en del av det initiala steget.

Till en början studerades Excel-‐‑arken som användes samt relevanta processer som lösningen är beroende av, parallellt med att boka in intervjuer med anställda från olika avdelningar. Respondenterna tillhandahölls av handledarna och valdes ut för att ge synpunkter från olika delar av verksamheten. Dessa intervjuer resulterade i en samling krav som fastställdes i form av en kravspecifikation som dessutom var projektets första milstolpe.

(26)

Informations-‐‑ samling Intervjuer Krav speciﬁk-‐‑ ation Make or buy analys Implementerin g

Kravspecifikationen resulterade i en detaljerad förståelse över behovet av en ny lösning, projektet gick vidare med en studie över marknadens utbud av lösningar samt en undersökning av hur en egen lösning skulle kunna utvecklas. Ett beslut togs relativt tidigt att utveckla en egenlösning inte var relevant då bristfällig kompetens och tidsresurs rådde inom projektet. Handledarna för projektet konstaterade även att Scania brukar försöka avstå från att bygga egna lösningar då de kan bli väldigt dyra och komplexa att underhålla. En annan anledning till att en egen lösning inte ansågs relevant var att förvaltningen av systemet blir svår när utvecklarna inte längre finns tillgängliga. Efter att marknadens utbud studerats valdes de lösningar som ansågs mest relevanta för verksamheten. Dessa alternativ ställdes mot varandra i en utvärdering och i en make or buy analys vilket var projektets andra milstolpe och som i sin tur ledde till ett beslut för en lösning.

Implementeringen verkställdes i form av en pilot-‐‑implementering där två utvalda grupper valdes som piloter. Detta gjordes i syfte att ordentligt testa den uppsatta lösningen med verkliga användare. Implementationen var projektets tredje och sista milstolpe.

Figur 1. Projektarbetets arbetssätt

(27)

3.2 Litteraturstudier

För att få bättre förståelse för teorin som tillämpats i projektet, genom-‐‑ fördes litteraturstudier. Med litteraturstudier menas informationsför-‐‑ djupning genom böcker, vetenskapliga artiklar och tidigare examensar-‐‑ beten vilka erhölls genom att söka i KTH’s bibliotek, Scanias bibliotek, KTH’s DiVA portal, KTHB Primo och Google Schoolar. För att hitta relevanta artiklar har sökorden kravhantering, make or buy analys, UML

Use Case, intervjuteknik, resursallokering och från-‐‑ och närvaroplanering

främst används. När det gäller att hitta relevant och pålitlig data krävs det att vara källkritisk och noggrann, därför sorterades resultaten från sökningarna efter tillämplighet, men även med hänsyn till publicerings-‐‑ datum och antalet gånger artikeln citerats av andra. På så sätt kunde projektmedlemmarna bättre förlita sig på den erhållna informationen. Syftet med litteraturstudierna var att öka förståelsen för de teorier som tillämpats i projektet. Den teoretiska studien innefattade bland annat intervjuteknik, från-‐‑ och närvaroplanering, krav, process modellering, make or buy beslut, UML och Use Case. Detta gjordes för att bland annat komma fram till vad som menas med en effektiv resursplanering, samt vilka för-‐‑ och nackdelar ett resursplaneringssystem kan bidra till.

3.3 Intervju och möten

Denna del refereras till projektmål 1 och 2.

▪ P1: Identifiera behov, arbetssätt och processer relaterade till från-‐‑ och närva-‐‑ roplanering

▪ P2: Samla krav och skapa en kravspecifikation

För att tolka vilken intervjumetod som bäst skulle tillämpas för projektet undersöktes olika intervjustrategier och hur de används, och ett antal faktorer vägdes då in. Den viktigaste faktorn var att utvinna de bästa svaren från Scanias medarbetare som var relevant för dennes avdelning och dessutom använda den metod som företaget var bekväm med. Eftersom kunskapen om avdelningarna på Scania var liten, var det svårt att på ett någorlunda sätt förutspå frågorna och svaren. Därför hölls en relativt öppen diskussion, som kan refereras till som en ostrukturerad intervjumetod, med respondenter med olika befattningar, och enligt Kvale är intervjuer den mest grundläggande metoden för att nå människors tankar.

(28)

3.4 Kravspecifikation

Denna del refereras till projektmål 2.

§ P2: Samla krav och skapa en kravspecifikation

Det finns många sätt att utveckla en kravspecifikation och därmed finns det ingen direkt standard för hur ett sådant dokument skall se ut. Scania försöker att utforma en kravspecifikationsmall som ska representera en standard internt i verksamheten. Denna mall tillhandahölls och utnyttjades i projektet. Dokumentet i sig består av ett antal rubriker med en tydlig förklaring till vad som ska ingå i dessa. Inledningsvis definieras systemets betydelse, omfattning samt syfte. Följt av detta listas funktionella samt icke-‐‑funktionella krav. Dessa rubriker är något som är självklart i ett kravspecifikationsdokument, men för Scania har det visats sig vara viktigt att få mer ingående information kring användbarhet, reliabilitet, supportmöjligheter och gränssnittsaspekter. Dessa delar uppkommer inte alltid i en kravspecifikation, och vissa delar uppfattades otydliga om vad de skulle innehålla, dels på grund av beskrivningen, men även på grund av kunskapen angående ämnet. Genom diskussioner med den ansvariga för dokumenten, Kenneth Bergström, konstaterades att delar av dokumentet kunde uteslutas och endast de punkter som behandlats i tidigare moment i projektet var relevant att beteckna.

För att göra systemets syfte tydligare förklarades den befintliga lösningen som utnyttjas av verksamheten följt av en beskrivning av den önskade lösningen som ska kompensera svagheterna. Kraven, som är de mest essentiella delarna av dokumenten, definierades i små kolumntabeller för att tydligt kunna specificera kravets huvudaktör, namn, beskrivning och prioritet. Samtliga krav tilldelades även en identifiering i form av ett ID, vilket gjordes för att enkelt kunna referera till kraven i andra dokument genom att ange ID för kravet. En annan del som inte togs upp i Scanias mall var risker. Dock valde projektmedlemmarna att dokumentet för projektets kravspecifikation skulle innehålla risker, just för att ytterligare klargöra kravens betydelse.

Som svar på projektmål 2 levererades ett kravspecifikationsdokument. För att täcka ytterligare aspekter av kraven skapades även ett Use Case dokument. Detta dokument gör det tydligt att se hur kraven hänger samman och hur olika flöden ser ut och uppkommer.

(29)

3.5 Make or buy analys

Denna del refereras till projektmål 4.

§ P4: Genomför en make or buy analys

Liksom kravspecifikationer finns det ett stort antal olika sätt att genomföra en make or buy analys, dock finns det två faktorer som måste vara med, dessa är kostnaden och tillgängligheten av produktionskapaciteten. För att skapa en make or buy analys som Scania kunde få användning av rådfrågades handledare och genom dem kontaktades Anna Östh. Anna har tidigare genomfört en make or buy analys för ett projekt på Scania och efter intervjun med henne tillhandahöll projektmedlemmarna en mall som tidigare hade skapats. Mallen studerades och det beslutades att arbetet skulle genomföras utefter denna mall.

Som svar på projektmål 4 levererades en Make or buy analys i form av ett textdokument samt ett Excel ark.

(30)

(31)

Hussein Al-‐‑Sahaf & Madi Susso Lösningsalternativ 2013-‐‑06-‐‑10

4 Lösningsalternativ

Detta kapitel refereras till projektmål 3.

§ P3: Utvärdera möjliga lösningar och skapa en sammanställning med för-‐‑och

nackdelar

Se bilaga B I dokumentet listas de alternativa lösningar som erhållits när marknadens utbud undersökts och potentiella utvecklingsmöjligheter. För att få en klarare bild av hur väl lösningarna skulle matcha de behov som finns av systemet, ställs funktionaliteterna av lösningarna mot de krav som erhållits och sammanställts i kravspecifikationen. Utifrån lösningarnas ståndpunkter görs en bedömning angående hur väl lösningen skulle tjäna verksamhetens behov. Utvärderingen utesluter faktorer som kostnader etc. som kommer tas hänsyn till i make or buy analysen.

4.1 Workshop

En workshop används inom projekt som ett sätt för att samla kompetens för att lösa en specifik fråga (Wikipedia, Workshop, 2013).

För att få åsikter från slutanvändarna angående de alternativa lösningarna utfördes en workshop, och för presentationen skapades ett flertal användarfall, se bilaga D. Syftet med workshopen var att demonstrera lösningarna och deltagarna var medarbetare från olika avdelningar som hade god erfarenhet av Excel-‐‑arken. Efter varje presenterad lösning diskuterades den och medarbetarna fick en chans att ge feedback på lösningen. Detta resulterade i ett ytterligare beslutsunderlag som kunde användas när en lösning skulle väljas.

(32)

(33)

Hussein Al-‐‑Sahaf & Madi Susso Konstruktion 2013-‐‑06-‐‑10

5 Konstruktion

Detta kapitel refereras till projektmål 1 och 5.

§ P1: Identifiera behov, arbetssätt och processer relaterade till från-‐‑ och

närvaroplanering

§ P5: Implementera vald lösning

5.1 Arbetsprocess

Mycket av från-‐‑ och närvaroplaneringen sker muntligt på Scania. Dock finns det en relativt bestämd process för just semesterplaneringen, se figur 2.

(34)

Denna process utvecklades ytterligare till ett BPMN diagram, se figur 3. Dessa illustrationer gäller endast för semesterplanering, då det finns tydligt uppsatta datum då frånvarobegäran ska vara rapporterade. För annan typ av frånvaro som föräldraledighet, kompledighet etcetera sker en muntlig diskussion mellan medarbetaren och gruppchefen, innan det förs in i Excel arket.

Figur 3. Scanias semester processmodell

5.2 Intervjuer

För att få en känsla för hur intervjuerna skulle utformas och för att förbättra självförtroendet inför kommande intervjuer genomfördes en pilotintervju. Pilotintervjun gav projektdeltagarna möjlighet att planera en strategi angående vem som ska säga vad osv. och inför kommande intervjuer kunde koordinationen ske smidigare. Pilotintervjun var tänkt att genomföras med handledarna Anette Rydh och Carina Larsson, men genomfördes istället med Ulf Olsson från DynaMate.

Sc

an

ia

IT

Sc an ia IT M G Le dn in gs gr up p An st äl

ld Skriv in önskade semesterdagar

Excel Ark

Granska Excel ark Planering inom grupp & avdelning Stäm av planeringen med andra avdelningar Försonas inom avdelningen

Fatta beslut Ja _{semsterschema}Publicera

Funkar? Funkar? Ja Nej 2veck or 2veckor semst ersche ma semst ersche ma Nej

(35)

Urvalet av respondenter erhölls av projektets handledare med syfte att täcka den största delen av Scanias organisation och personal med varierande befattningar inom olika avdelningar var utvalda. Ett slumpmässigt val av de listade respondenterna kontaktades via Microsoft Outlook och möten bokades in med de personer som var intresserade och tillgängliga. Som det nämndes tidigare leddes ostrukturerade intervjuer med hopp om att den ena intervjun skulle bygga på kunskapen om ämnesområden till den nästa.

Det essentiella var att få ut så många krav som möjligt från intervjuerna och i följd med dem konstruerades en lista med erhållna krav. Dessa krav presenterades för kommande respondenter vilket gjorde det lätt att fastslå om deras avdelning hade liknade krav eller andra krav utöver de krav som redan var listade. Intervjuerna tillät även respondenten att ge synpunkter och tips på hur problemet skulle kunna lösas. Parallellt hölls ett antal möten för att klara upp problemställningar angående praktiska frågor kring licenser, servers, kostnader etc.

Intervjuerna genomfördes med följande personer: § Ulf Olsson från DynaMate

§ Susanne Söderlund från HAS -‐‑ system support § Heidi Wester, DX från Transmission Machining

§ Ann-‐‑Christin Isaksson från UTI – IT Coordination and Support R&D § Peter Lindström från UTIC – CAD and PDM development

§ Hogir Rasul från UTTE -‐‑ Automation and electronic systems § Hans Sjöholm från UTTI -‐‑ Head of Testing Systems

§ Anne Jensson från DT -‐‑ Axle-‐‑ and Gearbox Assembly § Anna Östh från ID -‐‑ Project & Vendor Management Office § Rickard Ångman från ITWA -‐‑ Service Management

§ Mattias Järnhäll från ITMF -‐‑ Integration Platform § Anette Rydh från IP -‐‑ Operations

§ Carina Larsson från I – Scania-‐‑IT

§ Frédéric Anquetil från IPPF -‐‑ Site Angers § Monica Aspebo från BT – Services Operations

För att lättare kunna minnas, analysera och citera svaren spelades samtliga intervjuer in, intervjuerna resulterade i en lista med krav som sen fastställdes i en kravspecifikation.

(36)

5.3 Uppsättning

När samtliga nödvändiga leverabler lämnats in och godkänts togs ett beslut i samråd med projektets handledare över vilket system som Scania skulle implementera. Valet föll på en SharePoint lösning och projektet följdes upp med

att undersöka hur implementeringen skulle genomföras.

För att validera att den valda lösningen verkligen var något lämpligt för Scania att använda, genomfördes en pilotimplementering. Det vill säga att systemet sattes upp i en verklig miljö, men endast ett urval av grupper skulle agera som piloter för att testa lösningen. Projektets handledare valde ut två grupper som ska använda systemet vid nästa från-‐‑ och närvaroplaneringsfas.

Uppsättningen av systemet gjordes tillsammans med Scanias SharePoint expert Frédéric Anquetil från Frankrike. Anledningen till att uppsättningen inte kunde göras på egen hand berodde på att det fanns begränsade behörigheter och utvecklingsmöjligheter i den version Scania Sverige hade tillgång till. Frédéric använde nämligen SharePoint Standard medan projektmedlemmarna endast hade tillgång till SharePoint Foundation. Via ett flertal telefonsamtal och mejlkonversationer diskuterades kraven från kravspecifikationen ifall de kunde verkställas och hur, kraven och arbetsflöden definierades, och därefter implementerade Frédéric dessa. Frédéric gav projektmedlemmarna tillgång till utvecklingssidan och på så sätt kunde utvecklingsprocessen följas. När nya funktioner implementerades var det därför enkelt att konstatera om det blivit implementerade på rätt eller fel sätt.

(37)

Figur 4. SharePoint utvecklingssida, det röda fältet indikerar hur man skapar ett objekt i kalendern

5.4 Toolkit Pentalogic Planner

En stor utmaning upptäcktes under uppsättningen av SharePoint sidan. Det kalendergränssnitt som fanns tillgänglig (se figur 2) motsvarade inte den funktionalitet som behövdes för få en ordentlig överblick över medarbetarna och de objekt de lagt in. Det gick alltså inte att göra ordentliga kopplingar mellan en användare och det objekt användaren lagt in i kalender. Istället behövdes en lista bredvid kalender där alla medarbetares namn är listade. På så sätt får alla en egen rad och när de då lägger in ett objekt i kalendern blir det tydligt vilket objekt som tillhör vem och när det finns luckor i mellan medarbetarnas frånvaro. Denna typ av kalendergränssnitt fanns inte tillgängligt som standard av SharePoint.

Problemet analyserades tillsammans med Frédéric och därefter hittades ett verktyg till SharePoint som företaget Pentalogic erbjöd för semesterplanering. Detta verktyg (se figur 3), som alltså kunde ersätta det otillräckliga kalendergränssnittet, var just det som eftersträvades och handledarna fick förslaget att köpa in detta verktyg.

(38)

Figur 5 Pentalogic vacation and absence planner toolkit

Handledarna förstod problematiken med det dåvarande kalendergränssnittet och beslutet togs att det externa verktyget skulle köpas in.

Lista med arbetare

Frånvaroattribut

(39)

Hussein Al-‐‑Sahaf & Madi Susso 2013-‐‑06-‐‑10 Resultat

6 Resultat

I detta kapitel redovisas resultatet av implementeringen (projektmål 5). För att en implementering skulle vara möjlig var kravet att en kravspecifikation (projektmål 2), en utvärdering (projektmål 3) och en make or buy analys (projektmål 4) genomförts och godkänts. Tillsammans med handledarna ansågs projektmål 1-‐‑4 godkända när dokumenten täckt alla relevanta aspekter för att kunna påbörja en implementering.

För att underlätta för framtida användare skapades en användarmanual, se bilaga E.

6.1 SharePoint

Projektmål 1-‐‑4 användes som beslutsunderlag för att välja vilket system som skulle implementeras. Tillsammans med projektets handledare och avdelningschefen Niclas Falkeling togs beslutet att SharePoint lösningen skulle implementeras. Lösningen var optimal i den mening att den erbjöd god funktionalitet samtidigt som kostnaderna var mycket rimliga.

Sidan är skapad och tillgänglig endast från Scanias intranät och integrerar med Scanias Active Directory(AD) där alla medarbetare är definierade, bland annat med en identifieringskod. Detta är alltså resultatet av den sida som skapades för pilotkörningen och är tillämpad för två grupper, IPSC samt IPSA och består sammanlagt av 75 medarbetare. Alla dessa medarbetare sattes manuellt in i systemet.

Sidan som sattes upp fick följande utseende på startsidan. I figur 4 kan man se att det externa verktyget som köptes in har ersatt standard kalendergränssnittet.

(40)

Figur 6. Startsida

Det som visas på första sidan är en kalender med en lista över hela sektionen. Detta valdes för att få en överskådlig bild över alla grupper inkluderade i sektionen, vilket kan underlätta från-‐‑ och närvaroplane-‐‑ ringen.

(41)

Längre ner på startsidan (se figur 5) skapades tre essentiella fält. I Select

the Department to filter skapades möjligheten att sortera sektionen efter

grupper. När man väljer en grupp kommer endast de medarbetare som ingår i den gruppen visas i kalendern Filtered by departement. I det tredje fältet Absences visas alla ny tillagda objekt. Gruppchefen kan då enkelt se relevanta förfrågningar angående frånvaro och hantera dessa.

När en användare vill skapa ett objekt (se figur 6) måste de ange några obligatoriska attribut. Absence for indikerar vem objektet syftar på, här utnyttjas Scanias AD. Det räcker alltså att ange AD koden för personen i fråga. Department syftar på vilken grupp personen tillhör, detta möjliggör sortering. Därefter gäller det att ange vilket typ av frånvaro som gäller, Category, följt av start datum, Start Time, samt slut datum,

End Time.

Figur 8. Skapa objekt

Viktigt att påpeka att objektet är av standard Approved vilket betyder att objektet anses som godkänd av gruppchefen redan när objektet skapats. Dock kan gruppchefen vid behov avböja en förfrågan genom att gå in i objekten och ändra Approved till Rejected. När detta görs får personen i fråga ett mail till sin Outlook att förfrågan har blivit nekad och måste ändras. I figuren nedan visas det objekt som skapats och genom att klicka på den får man fram en del information (se figur 8).

(42)

Figur 9. Skapat objekt

Något som saknades i Excel-‐‑arken var spårbarhet. I denna lösning kan man i objektet se när objektet skapades och av vem samt när någon ändrade objektet senast. Det gör att ingen kan ändra i sitt objekt utan att gruppchefen är medveten om det.

Figur 10. Objekt

På grund av Scanias verksamhetsuppbyggnad sattes olika behörighetsnivåer upp, se figur 9.

Figur 11. Behörigheter

Editera objekt

(43)

En gruppchef identifieras genom behörigheten Planning IPS Owners vilket tillåter personen att hantera samtliga objekt. En medarbetare, som endast utnyttjar sidan för att göra frånvaroförfrågningar, ges behörigheten Planning IPS Members vilket tillåter personen att endast hantera sina egna objekt, men kan se alla andras. Utöver dessa finns behörigheten Planning IPS Visitors som identifierar alla andra som har rätt att besöka sidan. Dessa kan vara personer från andra avdelningar och kan endast läsa sidan.

När sidan utvärderats har det konstaterats att den omfattar alla de viktiga krav som framförts. Sidan kommer att utnyttjas vid nästa semesterplaneringsfas och är planerad att verkställas i början av

(44)