Simuleringsverktyg för optimering av produktion: En studie i hur simuleringsprogram kan väljas och användas för förbättringsarbete

Simuleringsverktyg för optimering av produktion

En studie i hur simuleringsprogram kan väljas och användas för förbättringsarbete

Marcus Demir, Tobias Rogefelt 9/21/2015

MG202X Examensarbete inom Industriell Produktion

I

Abstract

The main goal for this thesis project has been to investigate how companies can make use of simulation software to optimize and improve the flow of their production. The report is aimed towards companies or users that are interested in starting to use simulation software but lack the know-how. We set out to investigate and demonstrate how the selection of simulation software can be done, how the functions of the program can be used to optimize production, and in which way a simulation project can be efficiently conducted. The thesis was conducted as a case study at GE Healthcare’s department for Continuous Improvement in Uppsala, Sweden, where a simulation program was chosen, procured and used to test different scenarios and suggestions for improvement. A method for selection and evaluation of the simulation software was developed, where a previously developed method called Analytical Hierarchy Process plays a central part. As simulation software are not as generic as they are often promoted by vendors, the selection of the right software is of great importance. Our method of selecting simulation software aims to ensure that the right software is chosen based on the need of the user. The simulation software determined as most suitable for GE Healthcare’s needs was Simcad Pro. Using this program, two different production situations were modeled and simulated. The results from the simulation of the first production case showed potential for optimization of work force utilization where one worker could run a production line alone with the help of a robot, instead of using two operators. The simulations also resulted in suggestions for reduction in lead-time and work in progress. For the second production case, the simulation showed that the procurement of only 10 tanks was needed instead of the planned 14 tanks, by better planning of the flow of material. Our conclusions are that simulation software can be of great use for companies working with continuous improvement, provided that the right software is chosen and that the right method for working with the program is utilized.

II

Förord

Denna rapport är resultatet av vårt examensarbete om 30 högskolepoäng som utförts under perioden mars-september år 2015 hos GE Healthcare i Uppsala. Examensarbetet ingår som avslutande moment i våra studier till civilingenjör inom Industriell Ekonomi med teknisk inriktning Integrerad Produktion. Arbetet har skrivits vid institutionen för Industriell produktion på Kungliga Tekniska Högskolan i Stockholm.

Vi vill rikta ett stort tack till personalen på GE Healthcare i Uppsala, framför allt till vår handledare Arash Rajabi som har varit ett stort stöd och bidragit med hjälp och vägledning under hela projektets gång. Tack riktas även till övrig personal på GE Healthcare som ställt upp och hjälpt oss genom att besvara de frågor vi haft.

Vi vill också speciellt tacka vår handledare från KTH, Daniel Semere för hans engagemang, kompetenta vägledning och åsikter om projektet.

Stockholm, 21 September 2015

Marcus Demir & Tobias Rogefelt

III

Innehåll

1 Inledning ... 1

1.1. Bakgrund ... 1

1.2. Tidigare forskning och rapportens bidrag ... 1

1.3. Syfte ... 1

1.4. Frågeställningar ... 2

1.5 Avgränsningar ... 2

2 Metodik ... 3

3 Metod ... 3

3.1 Val av simuleringsprogram ... 4

3.2 Använda programmet ... 13

3.3 Metodens tillförlitlighet ... 14

4 Teoretisk referensram ... 16

4.1 Simulering som verktyg ... 16

4.2 Operationsstyrning ... 22

5 Kartläggning och casebeskrivning ... 29

5.1 Case 1 - V1 ... 29

5.2 Case 2 - Macktankar ... 32

6 Resultat ... 35

6.1 Utvärdering av programmen ... 35

6.2 Simuleringsmodell ... 47

6.3 Data från simulering ... 49

7 Analys & Diskussion ... 57

7.1 Utvärdering av simuleringsprogram ... 57

7.2 Simulering av V1 ... 60

7.3 Simulering av Macktankar ... 60

7.4 Simulering som verktyg ... 61

7.5 Hållbar utveckling och etiska aspekter ... 62

8 Slutsats ... 64

9 Referenser ... 65

10 Bilagor ... 67

Bilaga 1: Utvärderingsformulär ... 67

Bilaga 2: Frågeformulär för intervju med företag ... 68

IV

Bilaga 3: Parvis jämförelsematriser ... 70

Bilaga 4: Information om Simcad pro ... 84

Bilaga 5: Information om Collaborative robot ... 88

Bilaga 6: Standardiserat arbetssätt för V1 ... 89

1

1 Inledning

GE Healthcare är en del av General Electric, ett globalt konglomerat som verkar i olika branscher, till exempel energi, flygindustri, logistik, finans och fastigheter med flera. GE Healthcare tillverkar kontrastmedel för röntgen, MR, ultraljud och radiofarmaka, som möjliggör för vårdgivare att bättre förutse och diagnosticera sjukdomar i det tidiga stadiet. I Uppsala utvecklar och tillverkar de produkter som används vid framställning av biotekniska läkemedel som till exempel insulin samt laboratorieinstrument. På företagets enhet Continuous Improvement bedriver man verksamhet för att förbättra processer i den nuvarande organisationen och produktionen. Man arbetar mycket med Lean som ett verktyg för detta. I arbetet lägger man fram förslag för förbättringsåtgärder för produktionen, men det är ofta svårt att på förhand veta hur väl dessa förändringar faktiskt kommer att påverka systemet eftersom flera olika parametrar samspelar. De verktyg som används idag för analys är begränsade till främst Excel-ark och traditionella Leanverktyg. Det finns en önskan av att i förväg kunna testa vilka resultat eventuella förändringar kommer medföra. Ett alternativ som GE är intresserade av att undersöka är möjligheten att använda sig av ett simuleringsprogram.

Detta skulle kunna användas för att bygga upp produktionen virtuellt och på så vis använda det i sitt förbättringsarbete. Man vet däremot inte tillräckligt om simulering för att själva kunna besluta vilket simuleringsverktyg som passar bäst eller hur simulering kan användas.

1.2. Tidigare forskning och rapportens bidrag

Det har genomförts viss forskning inom området för hur ett simuleringsprogram kan implementeras och användas för att optimera produktion. Dock är dessa metoder i ständigt behov av att uppdateras eftersom tekniken utvecklas och programmen får nya funktioner.

Dessutom ändras i takt med detta även användarens behov. Det är därför viktigt att utföra denna typ av forskning kontinuerligt för att anpassa utvärderingsmetoder efter användarkraven. Det finns forskning och framtagna modeller för val av programvara, men dessa tar oftast inte hänsyn till de specifika förhållandena hos företaget i fråga.

Detta examensarbete riktar sig till företag som är intresserade av att börja använda sig av simulering men inte har tillräckligt mycket kunskap om hur det bör införskaffas och användas. Rapporten bidrar med en metod för val av programvaran, en demonstration av viss kapabilitet simuleringsprogram har, samt förslag till hur arbetet med simulering kan utföras.

1.3. Syfte

Syftet är att utreda om och hur avdelningar för förbättringsarbete kan använda sig av Simuleringsprogram för att optimera flödet i verksamheten.

2 1.4. Frågeställningar

För att uppnå syftet valdes följande forskningsfråga:

Hur kan ett simuleringsprogram hjälpa GE Healthcare’s avdelning för Continuous Improvement att förbättra verksamhetens produktion?

Denna huvudfråga delades upp i tre mer fokuserade delfrågor:

1. Hur kan man göra val av simuleringsprogram på ett systematiskt sätt?

2. Hur kan detta simuleringsprogram användas för att optimera produktionen?

3. Hur bör GE använda sig av simuleringsprogrammet i framtiden?

1.5 Avgränsningar

Simuleringsprogram har en mängd olika funktioner och en modell som byggs upp kan konfigureras på väldigt många sätt för att efterlikna verkligheten. Fokus i denna rapport har inte främst lagts på att bygga upp en modell med så hög detaljnivå och verklighetsanpassning som möjligt. Ett sådant arbete skulle kräva mer tid än vad som låg inom ramen för detta examensarbete. Syftet har snarare varit att demonstrera hur man gör tillväga då man börjar använda sig av simulering, hur programmet väljs och hur simulering kan användas som verktyg för beslutsunderlag. Detta har gjorts genom att ge exempel från modeller med godtagbar detaljnivå för detta syfte.

3

2 Metodik

Den övergripande metodiken för detta examensarbete är en fallstudie. Genom att utföra en studie hos GE Healthcare kan vi demonstrera vår metod och våra resultat på ett tydligt sätt med bra anknytning till verkligheten. Andra företag kan dra nytta av detta genom att använda sig av vår metod och tillvägagångssätt i sina egna organisationer.

Vi har använt oss av ett antal metoder för att besvara forskningsfrågorna:

Hur kan man göra val av simuleringsprogram på ett systematiskt sätt?

 Litteraturstudie för att komma fram till vetenskaplig utvärderingsmetod för att rangordna programmen

 Marknadsundersökning av programmen genom bland annat semistrukturerade intervjuer med representanter från programleverantörer

 Öppna intervjuer med personal på GE Healthcare för att identifiera behovet av simuleringsprogram

Hur kan detta simuleringsprogram användas för att optimera produktionen?

 Programmanualer och web-möten med support från programleverantören

 Utföra case för att bekräfta och demonstrera optimeringsfunktionerna

 Öppna intervjuer med personal på GE Healthcare för att samla information om produktionen

 Egna observationer från produktionen

Hur bör GE använda sig av simuleringsprogrammet i framtiden?

 Litteraturstudie

 Personlig erfarenhet från användning av simuleringsprogram

Dessa beskrivs närmare i metodkapitlet där vi ger en tydligare bild av hur varje steg i arbetet har utförts.

3 Metod

Metoden som används syftar till att besvara de forskningsfrågor som ställts. Detta examensarbete kan delas upp i två huvudsakliga delar. Den första delen (3.1) ämnar att besvara delfråga 1 och består av att bestämma en metod för att välja rätt simuleringsprogram, och sedan använda denna metod för att identifiera vilket simuleringsprogram som bäst möter GE:s behov.

Den andra delen (3.2) består av att använda programmet för att bygga upp en modell och simulera produktionen där vi testar förändringsförslag för att visa hur programmet kan

4

användas som ett verktyg för Continuous Improvement. På så vis kommer forskningsfråga 2 och 3 besvaras.

3.1 Val av simuleringsprogram

För att besvara den första forskningsfrågan, ”Hur kan man göra val av simuleringsprogram på ett systematiskt sätt?”, gjordes en litteraturstudie för att hitta den utvärderingsmetod som bäst passade ändamålet.

GE Healthcare använder sig i nuläget inte av något simuleringsprogram i sin avdelning för Continous Improvement. Det första viktiga steget för ett företag som planerar att börja använda sig av simulering är att välja ut det program som ska användas. Det finns en stor mängd olika simuleringsprogram tillgängliga på marknaden. Även om dessa program delar vissa övergripande egenskaper skiljer de sig åt på en hel del punkter. Programmen är oftast inte så generiska som leverantörerna själva påstår, ett visst program kan passa väldigt bra för ett företag medan det inte alls passar för ett annat (Pidd, 2010). Olika företag har olika behov och man bör därför inte välja första bästa program, utan genomföra en genomgående analys och utvärdering av programmen.

Det finns flera olika typer av metoder för att utvärdera mjukvara. Dessa utvärderingsmetoder går i stora drag ut på att man har ett antal kriterier eller behov som man vill ska uppfyllas.

Mjukvaran utvärderas sedan efter hur väl den uppfyller kriterierna. Målet med utvärderingen är att den ska ge ett resultat som representerar verkligheten så väl som möjligt. Hur detta görs kan skilja sig åt mellan olika utvärderingsmetoder, fördelar och nackdelar hos några av de vanligaste metoderna tas upp nedan (Jadhav, 2009).

Analytical hierarchy process (AHP) Fördelar:

+ Strukturerar beslutsproblemet i en hierarki, vilket underlättar förståelsen för problemet och låter beslutsfattaren fokusera på en mindre del av problemet åt gången. På så vis reduceras komplexiteten i beslutsfattandet.

+ Flexibelt och kraftfullt för att hantera både kvalitativa och kvantitativa kriterier.

+ Kan användas både för grupp-beslut såväl som individuella beslut.

Nackdelar:

 Hög tidsåtgång på grund av matematiska beräkningar och det höga antalet parvis jämförelser.

 Beslutsfattarna behöver göra om utvärderingen om antalet kriterier eller programalternativ ändras.

(Jadhav, 2009)

5 Feature analysis

Fördelar:

+ Utvärderingen kan göras på alla olika detaljnivåer genom att organisera utvärderingen i olika sätt, så som fallstudier, screening mode, formellt experiment eller enkätundersökning

+ Kan användas för att utvärdera både tekniska aspekter av programmen och leverantörens styrka.

Nackdelar:

 Att presentera resultatet som en enda siffra kan vara missledande eftersom olika kombinationer kan ge samma totalpoäng.

(Jadhav, 2009)

Weighted average sum Fördelar:

+ Väldigt enkel och snabb att använda sig av.

Nackdelar:

 Vikter tilldelas godtyckligt. Det blir dessutom väldigt svårt att tilldela vikter när antalet kriterier är stort.

(Jadhav, 2009)

Fuzzy based approach Fördelar:

+ Språkliga termer kan användas för att utvärdera alternativ enkelt och intuitivt.

+ Förbättrar beslutsprocessen genom att ta hänsyn till tvetydigheter och inkonsekvenser som kan uppstå på grund av mänskliga faktorer under utvärderingen.

Nackdelar:

 Svårt att beräkna värden på fuzzy lämplighetsindex och ranka värdena för alla alternativ.

(Jadhav, 2009)

Efter att ha granskat de olika metodernas för- och nackdelar ansåg vi att Analytical hierarchy process var den bästa utvärderingsmetoden för att välja simuleringsprogram på grund av flera skäl. AHP har flera stora fördelar för beslutsprocess vid val av just simuleringsprogram. För att utvärderingen ska vara så omfattande och korrekt som möjligt bör ett relativt stort antal kriterier tas hänsyn till. AHP hanterar detta mycket väl genom att strukturera kriterierna i en hierarki och på så vis underlätta och göra utvärderingen mer hanterbar. En annan fördel med AHP är att den kan hantera både kvalitativa och kvantitativa kriterier. Vissa av de kriterier som används för val av simuleringsprogram är subjektiva och är svåra att sätta en direkt siffra på, till exempel hur visuellt tilltalande programmet är för användaren. Andra kriterier kan vara booleska ja- eller nej-frågor, till exempel om en viss funktion finns tillgänglig, medan en del kriterier kan vara rent kvantitativa, som hur mycket programmet kostar. AHP är relativt unik i att kunna hantera att utvärdera alla dessa typer av kriterier mot varandra, vilket görs genom att de jämförs parvis mot varandra. På detta vis kan alla olika kriterier jämföras och man får i slutändan ändå ett tydligt kvantitativt resultat (detta förklaras mer ingående senare i detta

6

kapitel). Den sista stora fördelen med AHP är att den kan inkorporera åsikter från flera olika personer. Simulering kan påverka flera olika delar av en organisation, om detta är fallet kan man använda sig av input från flera olika intressenter. Nackdelen med AHP är att det kan bli relativt tidskrävande jämfört med simplare metoder som till exempel Weighted average sum.

Tidsåtgången bedömdes dock som överkomlig för att kunna göra en så bra utvärdering som möjligt. AHP visade stor potential för att användas till att välja rätt simuleringsprogram och valdes därför som utvärderingsmetod i detta arbete.

Utöver AHP utfördes några ytterligare steg i urvalsprocessen. Hela processen för att välja program följde flödesschemat nedan, varje steg i vårt tillvägagångssätt beskrivs sedan utförligt i fortsättningen av detta kapitel.

8 3.1.1 Första kartläggning

I detta första steg var målet att identifiera vilka olika program som fanns tillgängliga på marknaden. Detta gjordes genom att vi sökte på internet och därefter tittade på företagens egna hemsidor. Artiklar om simuleringsprogram lästes, där till exempel Dias et al (Dias, 2011) listar de mest använda simuleringsprogrammen på marknaden. Vi läste också i olika forum på internet om simulering, där användare rekommenderade och diskuterade olika program. Slutligen diskuterades de program som hittills identifierats med handledare på KTH, som gav tips om ytterligare intressanta program som inte tidigare identifierats. Handledare på GE gav också förslag på olika program som företaget själva identifierat som möjliga kandidater.

3.1.2 Första utvärdering och urval

Den första kartläggningen resulterade i 14 program, vilket ansågs för många för att kunna utvärdera varje i detalj. Därför gjordes en första översiktlig utvärdering för att gallra bort några program. Denna utvärdering gjordes efter ett antal hårdkriterier, det vill säga kriterier som programmet måste uppfylla för att kunna användas och ge de resultat som behövs. De hårda kriterierna arbetades fram genom diskussion med Lean Leaders på GE. Efter detta steg fanns fem kandidater kvar för vidare utvärdering i AHP.

3.1.3 Analytical Hierarchy Process

För att utvärdera de fem kvarvarande programmen användes metoden Analytical Hierarchy Process (AHP), introducerad av Thomas Saaty (Saaty, 1985). Det är ett effektivt verktyg för beslutsfattande vid val mellan olika alternativa lösningar då många olika kriterier ska tas hänsyn till. Metoden har rekommenderats av Azadeh et al (Azadeh, 2010) vid just val av simuleringsprogram. Metoden går ut på att kriterierna delas in i grupper i olika nivåer i en hierarki och sedan görs parvis jämförelser mellan två objekt i taget. På detta vis reduceras komplexiteten som annars kan uppstå då ett stort antal kriterier ska viktas. I vårt fall kunde vi istället för att försöka vikta alla våra 30 stycken kriterier mot varandra samtidigt fokusera på endast 4-6 åt gången. Nedan beskrivs de sex stegen som ingår i AHP och hur vi genomfört dem.

Steg 1: Val av kriterier

Det första steget i AHP är att identifiera de kriterier som ska viktas.

För att välja ut kriterier att utvärdera programmen efter genomförde vi först en litteraturstudie för att se vilka kriterier tidigare forskning rekommenderar. Därefter hölls intervjuer med Lean Leaders på GE Healthcare för att identifiera kriterier som var specifika för företaget och applikationsområdet. Litteraturstudien gav oss generella kriterier för att utvärdera mjukvaruprogram som bör tas med oavsett användningsområde. Intervjuerna kompletterade litteraturstudien och gjorde att kriterierna blev bättre anpassade för den specifika utvärderingssituationen. Genom att kombinera dessa metoder erhöll vi en högre validitet i valet av kriterier. De kriterier och tillhörande beskrivningar som togs fram valdes att uttryckas på engelska eftersom att vi ville att även icke svenskspråkiga på GE skulle kunna ta del av och förstå dess innebörd. Dessutom blev det enklare att ha kriterierna på engelska då

10

Figur 2. Exempel på hierarkisk struktur vid utvärdering via AHP.

Steg 3: Utveckla och fyll i utvärderingsformulär

De olika kriterierna utvärderas här relativt varandra, därefter utvärderas programmen efter varje kriterium. Detta steg är inte med i Saatys ursprungliga AHP-modell, istället för att använda sig av ett utvärderingsformulär görs utvärderingen direkt i en jämförelsematris enligt steg 4. Andra författare (Azadeh, Jadhav) rekommenderar dock att använda sig av någon typ av formulär för att förenkla utvärderingen och göra den mer visuell. För att underlätta så mycket som möjligt för utvärderarna och erhålla ett så riktigt resultat som möjligt valde vi att använda oss av ett utvärderingsformulär, och därefter föra in resultaten i jämförelsematriser.

En utvärderingsmall föreslagen av Azadeh et al. (Azadeh, 2010) valdes på grund av dess tydlighet och enkelhet (se bilaga 1). Formuläret fylls i en rad i taget, där två kriterier åt gången utvärderas mot varandra. Ett kryss sätts närmast det kriterium som anses viktigast, enligt en skala som sträcker sig från ”Equally important” till ”Extremely more important”.

Detta formulär fylldes i av två Lean Leaders på GE. Lean Leaders valdes eftersom det framförallt är de som kommer att använda simuleringsprogrammet i framtiden, samt att de har ett ingående kunnande om företagets processer och behov. Först ifylldes formuläret för nivå 2 av AHP, där User, Vendor, Input & Modeling, Simulation, Output och Integration utvärderades mot varandra parvis. Därefter ifylldes sex stycken motsvarande formulär för Nivå 3 av AHP, där kriterierna utvärderades parvis mot varandra inom varje grupp. För gruppen User utvärderades alltså Required experience, Ease of learning, Financial och Hardware mot varandra.

Därefter utvärderades de olika programalternativen mot varandra i liknande formulär för alla 30 kriterier. I detta formulär byttes ordet ”important” ut mot ”good”/”better” eftersom utvärderingen skulle avgöra vilket program som var bäst på en punkt, medan det för kriterierna handlade om vilket som var viktigast. Detta formulär fylldes i av rapportförfattarna själva. Informationen om programmen baserades på information insamlad genom intervjuer med företagen som säljer simuleringsprogrammen, information från deras hemsidor och faktablad, samt test av demoversioner av programmen. Intervjuerna som utfördes var av semistrukturerad karaktär och följde ett frågeformulär som arbetats fram av oss själva (se bilaga 2). Formuläret består av 32 frågor som är indelade efter de kriterier och kriteriegrupper som tagits fram i steg 1 av AHP. Varje fråga är tänkt att motsvara ett kriterium, där två kriterier fått en extra fråga för att täcka in den.

AHP använder sig av matematiska beräkningar för att komma fram till programmens slutgiltiga poäng. Därför måste svaren från utvärderingsformulären först kvantifieras. En skala baserat på Azadehs modell (Azadeh, 2010) användes för att omvandla fraserna från utvärderingsformuläret till numeriska värden som sträcker sig från 1-9 enligt tabellen nedan.

Mellanliggande värden kunde också fyllas in i formuläret.

11

Frasering i utvärderingsformulär Numerisk skala (Värde på aij)

Equally important 1

Moderately more important 3

More important 5

Strongly more important 7

Extremely more important 9

Tabell 1. Lingvistisk skala med motsvarande numeriskt värde för omvandling (Azadeh, 2010).

Steg 4: Skapa parvis jämförelsematris

Resultatet från utvärderingsformulären fördes sedan in i en parvis jämförelsematris, A.

Matrisen A är en nxn matris där n är antalet kriterier som utvärderades i formuläret (alternativt antalet program för nivå 4). Varje element aij i matrisen A representerar den relativa vikten mellan kriterium i och j, som erhölls i steg 3. Om aij>1 betyder det att kriterium i är viktigare är kriterium j. För A gäller även att: aij* aji = 1. Detta innebär att elementen under diagonalen kommer att vara den övre halvans invers.

𝑘1 𝑘₂ ⋯ 𝑘_𝑛

𝐴 = [𝑎_𝑖𝑗] = 𝑘₁ 𝑘₂

⋮ 𝑘_𝑛

[

1 𝑎₁₂ ⋯ 𝑎_1𝑛

1/𝑎₁₂ 1 ⋯ 𝑎_2𝑛

⋮ ⋮ ⋱ ⋮

1/𝑎_1𝑛 1/𝑎_2𝑛 ⋯ 1 ]

Efter detta gjorts för alla utvärderingsformulär hade vi sex matriser för nivå 2, fem matriser för nivå 3, och 30 matriser för nivå 4 (41 matriser totalt, se bilaga 3).

Steg 5: Kontrollera att resultatet är konsekvent

Eftersom att alla jämförelser görs parvis mellan två kriterier i taget finns det en viss risk för att utvärderingsformuläret av misstag fylls i inkonsekvent. Exempel: Kriterium k1 och k2 sätts först till att vara ”Equally important” och får relativ vikt = 1. När k1 och k3 sedan jämförs sätts k1 som ”Moderately more important” och får relativ vikt = 3. När utvärderaren sedan ska jämföra k2 och k3 sätts k2 som ”More important”, relativ vikt = 5. Detta resultat blir inkonsekvent eftersom k1 och k2 enligt första utvärderingen ska vara lika viktiga, men är olika viktiga jämfört med k3. Fördelen med AHP är att den låter utvärderaren fokusera på endast två kriterier åt gången vilket minskar komplexiteten. Men detta kan alltså också medföra att svaren blir inkonsekventa. AHP klarar av en viss grad av inkonsekvens, men ett test görs för att säkerställa att noggrannheten är tillräckligt hög i resultatet.

Saaty föreslår att Consistency Index (C.I.) och Consistency Rate (C.R.) beräknas för varje jämförelsematris A för att kontrollera att utvärderaren varit tillräckligt konsekvent. Om C.R. <

0,1 godkänns resultatet som tillräckligt konsekvent, annars fylls utvärderingsformuläret i på nytt. C.I. beräknades enligt formeln:

13

mellan kriterierna inom grupperna. Nu hade varje grupp en vikt och varje kriterium en inbördes vikt; för att få fram den slutgiltiga vikten mellan alla 30 kriterier multiplicerades vikten i nivå 2 med vikten i nivå 3. Även här kontrollerades att summan av alla vikter blev = 1 (100 %). Anorm togs även fram för alla de 30 jämförelsematriserna i nivå 4, och vikterna beräknades på samma sätt som nivå 2 och 3. Resultaten från beräkningarna i nivå 4 blev alla programmens poäng för vart och ett av kriterierna, vilket fördes in i en matris P.

Resultatet var nu att vi hade en 1x30 radvektor k där elementen beskriver varje kriteriums vikt, samt en 30x5 matris P där varje kolumn beskriver ett programs poäng för varje kriterium. För att få fram den sammanlagda programpoängvektorn v, multiplicerades vektorn k med matrisen P. Resultatet blir en vektor med programmens sammanlagda poängvikter:

𝑣 = 𝑘 ∗ 𝑃 = [𝑘₁ ⋯ 𝑘₃₀] ∗ [

𝑝_1,1 ⋯ 𝑝_5,1

⋮ ⋱ ⋮

𝑝_1,30 ⋯ 𝑝_5,30] = [𝑣1 𝑣₂ 𝑣₃ 𝑣4 𝑣₅] 3.1.4 Subjektiv utvärdering

Efter att AHP utförts genomfördes också på GE:s inrådan en ytterligare analys genom att fylla i en Pugh-matris. AHP är ett väldigt kraftfullt verktyg och är tänkt att ta hänsyn till alla faktorer som påverkar beslutet. GE ville gärna att vi själva kom med en mer subjektiv bedömning om vad vi själva tyckte om de fem programmen som utvärderades i AHP, mest som en slags ”check” för att styrka resultatet från AHP. En Pugh-matris fylldes i genom att programmen betygsattes på åtta olika områden, med 1, 0, eller -1. Varje område gavs en vikt enligt vår subjektiva åsikt om vad som var viktigast. Därefter räknades summan av dessa poäng ihop.

3.1.5 Test av demoversioner

Resultatet från AHP visade att tre program stack ut som toppkandidater. Innan det slutgiltiga valet av program gjordes testade vi att bygga upp enklare modeller i demoversioner i de tre programmen. Detta gjordes som en sista kontroll för att upptäcka eventuella irritationsmoment eller andra problem vid användning av programmet.

3.1.6 Val och inköp av program

Baserat på resultaten från tidigare steg rekommenderades ett program för GE:s ledningsgrupp som valde att köpa in detta program. Efter förhandling om pris köptes programmet in och installerades.

3.2 Använda programmet

Efter att rätt program valts och köpts in var nästa steg att använda det för att besvara forskningsfråga 2, ”Hur kan detta simuleringsprogram användas för att optimera produktionen”, samt fråga 3, ”Hur bör GE använda sig av simuleringsprogrammet i framtiden?”. För att besvara fråga 2 valde vi att göra en fallstudie på GE:s egen produktion.

En fallstudie har fördelen att resultatet blir väl förankrat till verkligheten. Denna fallstudie gick ut på att modellera och simulera exempel från GE:s produktion. På detta sätt kunde vi demonstrera programmets funktionalitet och hur det kan användas för att optimera och förbättra produktionen. För att besvara fråga 3 gjordes en litteraturstudie för att ta reda på vad

14

teorin säger om tillvägagångssätt vid simulering. Detta kombinerades med vår personliga erfarenhet och lärdomar från att ha arbetet med simulering.

För fallstudien simulerades två olika produktionssituationer från siten i Uppsala som valdes i samråd med Lean Leaders på GE. Eftersom syftet med arbetet var att visa hur ett simuleringsverktyg kan användas i förbättringsarbete ville vi ta med två olika case där programmet används på olika sätt. De två casen som valdes för simulering var ”V1” och

”Macktankar”

3.2.1 Information- och datainhämtning om produktion

För att kunna bygga upp en modell av de två produktionssituationerna behövdes data och information om hur processerna fungerar i verkligheten.

3.2.1.1 V1

Information om V1 erhölls genom att vi gick in i produktionsmiljön tillsammans med Lean Leader, där vi fick en övergripande förklaring om hur processen gick till och gjorde egna observationer. Därefter gick vi också tillsammans men Lean Leader igenom processen i detalj via dokumentation som fanns upprättad om processens standardiserade arbetssätt.

3.2.1.2 Macktankar

En intervju med Lean Leader hölls för att få information om hur processen fungerar. Därefter erhölls data om produktmix och historiska produktionsvolymer från datablad.

3.2.2 Simuleringsmetod

För att utföra simuleringen utgick vi ifrån en metod föreslagen av Banks et al (Banks 2010).

Processen består av totalt 12 steg och finns närmare beskriven i den teoretiska referensramen.

Metoden valdes för att säkerställa att simuleringsprocessen sker på ett strukturerat och kontrollerat sätt. Den är uppbyggd för att kontinuerligt verifiera att varje steg utförts korrekt, annars re-itereras det.

3.2.3 Optimering och testning av scenarier

Efter att modellen byggts upp och validerats testade vi att införa vissa förändringar för att förbättra produktionsprocessen. Dessa förbättringsförslag gjordes ur ett Lean- och Operational Excellence-perspektiv. Förslag till förbättringar kom från Lean Leaders på GE, samt från författarna själva baserat på litteratur om operationsstyrning. De olika scenarierna (före och efter) kördes i simuleringar för att jämföra data mot varandra och se vilken effekt förbättringsförslaget gav. Simuleringsprogrammets inbyggda verktyg för analys och optimering användes också för att identifiera och förbättra problemområden.

3.3 Metodens tillförlitlighet

Metoden för att välja program är tänkt att i ett första stadie (genom AHP) ge en så kvantifierbar och objektiv bild som möjligt av vilket program som bör väljas. Detta baseras på antagandet att de två Lean Leaders korrekt kan ge kriterierna vikter som motsvarar GE:s behov. Här kan deras personliga, subjektiva värderingar spela en viss roll vilket kan ge olika resultat beroende på vilka personer som väljs. Lean Leaders har dock en väldigt ingående kompetens om produktionsprocesserna vilket gör att vi kan argumentera för att de ändå är de

15

som kan ge de mest korrekta vikterna. Den andra delen i val av program är vår egen kompetens att korrekt kunna utvärdera programmen. Den fakta vi baserat våra beslut på kommer först ifrån intervjuer med representanter från företagen som säljer programvaran.

Dessa kommer naturligtvis alltid att försöka få just sitt program att framstå så bra som möjligt. Genom att ha ett kritiskt och ifrågasättande förhållningssätt under intervjuerna har vi försökt genomskåda så kallat ”säljsnack”. Dessutom kontrollerades uppgifterna från intervjuerna genom att själva prova på demoversioner av programmen och läsa andra användares åsikter på forum.

Simulering i sig medför alltid en viss grad av osäkerhet. Modellen är bara en representation av verkligheten och det är i stort sett omöjligt att uppnå en validitet på 100 %. Beroende på simuleringssituationen kommer modellen och simuleringens resultat att få olika hög säkerhet.

Valet att simulera V1 på en väldigt hög detaljnivå innebar också att vissa antaganden och generaliseringar var nödvändiga. Ju högre detaljnivå, desto svårare är det generellt att uppnå den verkliga processens beteende. Vid simulering på en mer övergripande nivå, som Macktankar, blir reglerna och beteendet lättare att sätta upp i modellen. Man bör vara medveten om detta när resultaten analyseras.

16

4 Teoretisk referensram

Detta kapitel innehåller relevant litteratur och teoretisk bakgrund som rapporten stöder sig på.

4.1 Simulering som verktyg

I detta avsnitt beskrivs simulering som koncept, varför det används och hur man kan gå tillväga då ett simuleringsprogram används.

4.1.1 Intro till Simulering

Simulering kan definieras på en mängd olika sätt, två definitioner som passar bra för simulering inom produktion är:

Simulering är konsten och vetenskapen att skapa en representation av en process eller ett system med avsikten experimentering och utvärdering. (Klingstam, Gullander, 1999)

Simulering är processen för att utforma en modell av ett verkligt system och utföra experiment i modellen för att skapa en förståelse för systemets beteende och/eller analysera olika strategier för att driva systemet. (Klingstam, Gullander, 1999)

Den grundläggande betydelsen är densamma; att göra tester i en modell för beslutsunderlag.

Simulering görs normalt via mjukvaruprogram i en dator vilket det idag finns en mängd olika program för. Andra typer av datorstöd har länge använts för andra ändamål inom producerande verksamhet, till exempel för produktdesign där det då ofta benämns Computer Aided Design (CAD). Även i själva tillverkningen är utrustning och maskiner till stor del ofta automatiserad och datorstyrd. Inom produktionsstyrning och industriell design är dock fortfarande användandet av datorstöd relativt lågt, man förlitar sig till stor del på manuella verktyg som Value Stream Mapping eller enklare program som MS Excel. Simulering kan hjälpa till att fylla luckan mellan design och tillverkning genom att det införs som ett datorbaserat verktyg för att utforma och planera produktionen. Detta har fått namnet Computer aided production engineering (CAPE). (Klingstam, Gullander, 1999)

4.1.2 Varför simulera

Simulering kan utföras av flera olika anledningar men har egentligen alltid samma underliggande syfte; att ge underlag för att fatta bättre beslut. Det används alltså som ett verktyg för beslutsfattande för att öka effektiviteten eller sänka kostnader, vilket är två av de främsta målen för operationsstyrning. (Klingstam, Gullander, 1999)

Några generella fördelar med att använda sig av simulering jämfört med traditionella metoder är:

 Möjligheten att testa olika alternativ utan att behöva investera i nya maskiner och utrustning

 Man undviker störningar och stopp i den dagliga produktionen

 Ger en bra grund för bättre underbyggda beslut

 Körningar över väldigt lång tid kan simuleras snabbt

 Problem kan upptäckas innan de når verkstadsgolvet

 Nya situationer och scenarion kan utforskas

17

 Ger ökad kunskap om och bättre överblick över systemet

Simulering kan alltså bidra med många fördelar, men man bör också vara medveten om dess begränsningar (Klingstam, Gullander, 1999):

 En modell är bara en förenklad representation av verkligheten

 Svårt att bestämma detaljnivån för simuleringsmodellen

 Svårt att sätta upp rätt mål som är realistiska

 Brist på kunskap om simulering

 Svårighet att analysera resultaten

 Hög tidsåtgång

 Dyr programvara

Tidigare var simulering främst ett verktyg för användaren att testa olika lösningar och programmen kunde inte själva ge förslag på lösningar. Användaren fick då själv komma fram till olika alternativa lösningsförslag och därefter mata in dem i programmet för att få utdata att jämföra (Klingstam, Gullander, 1999). Senare versioner av vissa program har dock fått mer avancerade funktioner för att även kunna hitta optimala lösningar. Detta görs ofta genom så kallad Monte Carlo-simulering där flera olika scenarier körs när olika variabler varierar mellan bestämda värden. Simuleringsprogrammen har alltså gått från att enbart vara testverktyg till att även generera lösningar.

4.1.3 Val av simuleringsprogram

Att välja rätt mjukvaruprogram för en viss tillämpning är en viktig och ofta komplex uppgift.

Valet av mjukvara baseras i grund och botten på två saker; vilka behov användaren har, och hur bra de olika programmen uppfyller dessa behov. En undermålig utvärdering kan resultera i ett felaktigt val av program och därmed att pengar spenderas på ett program som inte uppfyller de behov som användaren eller ett företag har. De svårigheter som finns när beslut ska fattas kombinerat med beslutets stora betydelse har lett till att en hel del forskning bedrivits för att utreda och hitta bättre metoder för att välja ett mjukvaruprogram. De två viktigaste frågorna som utretts är vilka kriterier som används, och vilken metod som används för att utvärdera mjukvaran. (Jadhav, 2009)

Val av kriterier

Det första steget i val av simuleringsprogram är att definiera det egna behovet; varför vill man använda sig av simulering och vad vill man att programmet ska kunna göra? Ett bra sätt att göra detta är att sätta upp ett antal kriterier som man sedan kan kontrollera hur väl programmen uppfyller. När kriterierna ska definieras bör man inte lägga något större fokus på hur viktiga de är. Det viktiga är att alla faktorer som påverkar valet av simuleringsprogram uttrycks på något sätt genom kriterierna som sätts upp. Det gör egentligen inte så mycket om man tar med för många. Dessa kriterier kommer att få en lägre vikt när de senare viktas. Om man är osäker på om ett kriterium påverkar beslutet eller inte är det bättre att ta med det för att inte riskera att en viktig del av beslutet inte tas hänsyn till.

Ett antal studier har gjorts för att fastställa de kriterier som bör tas med vid utvärderings av simuleringsprogram. Nikoukaran (Nikoukaran et al, 1998) har arbetat fram en omfattande

18

lista kriterier organiserade i ett hierarkiskt system. Ett hierarkiskt system innebär att kriterierna är indelade i grupper på olika nivåer. I sin hierarki har Nikouran delat in kriterierna i sju huvudgrupper enligt figuren nedan. Fem av dessa grupper är direkt relaterade till mjukvaran medan Vendor och User tar upp aspekter relaterat till användaren och programförsäljaren.

Figur 3. Hierarkisk indelning av kriteriegrupper (Nikoukaran et al, 1998).

Gruppen Vendor innehåller kriterier relaterade till utvärdering av programförsäljarens kredibilitet, support, träningsmaterial och liknande. Model and Input handlar om modellen och hur den byggs upp. Gruppen av kriterier inom Execution rör aktiviteter relaterat till experimentation med modellen. Animation handlar om de visuella aspekterna vid skapande av modellen och körning av simuleringen. Testing & Efficiency handlar om programmets funktioner för testning, validering, debuggning och liknande. Kriterier inom Output rör sådant som man får ut från programmet efter körningen, som olika typer av utdata och hur denna kan användas och analyseras. User handlar om faktorer specifika för användarens behov och omständigheter (Nikoukaran et al, 1998).

Var och en av dessa grupper består av kriterier som i sin tur kan delas in i ännu lägre nivåer. I figuren nedan visas gruppen Output som består av kriterierna Delivery, Reports, Data base, Integration, Analysis, och Business graphics. Programmen kommer senare att utvärderas efter dessa kriterier.

19

Figur 4. Hierarkisk indelning av kriteriegruppen Output, (Nikoukaran et al, 1998).

I figuren ovan visas även lägre nivåer i hierarkin som består av vidare indelning och förklaringar av kriterierna. Vid utvärderingen av programmen är dessa lägre nivåer värdefulla.

För kriteriet Analysis i gruppen Output är de funktioner man bör titta efter i programmet det som är listat i den lägre nivån; funktioner som konfidensintervall, tidsserieanalys, hypotestestning, optimering, och så vidare. Om programmet har stöd för många av dessa funktioner och utför dem bra bör programmet få en hög poäng på denna punkt. Samma upplägg gäller för alla kriterierna i alla de olika huvudgrupperna i Nikoukarans modell för kriterier.

Azadeh et al (Azadeh, 2010) har använt sig av Nikoukarans modell för kriterier, men har omvandlat de lägsta nivåerna i hierarkin (dem under kriterierna själva) till fraser för att förklara kriteriernas innebörd. Ett exempel för hur detta ser ut visas för kriteriegruppen Output i tabellen nedan.

Tabell 3. Hierarkisk indelning av kriteriegruppen Output med tillhörande beskrivningar (Azadeh, 2010).

I detta format blir förklaringarna mer sammanfattade, och inte fullt lika mycket information finns med. Dock blir det mycket lättare att snabbt kunna tolka och förstå vad varje kriterium innebär.

Hlupic och Paul (Hlupic & Paul, 1997) presenterar i sin artikel tre olika listor över kriterier för olika ändamål. Man har valt att göra en differens i hur simuleringsprogram används för

20

utbildningssyften (skolor och lärosäten) och inom producerande verksamhet (företag). För producerande verksamhet har man vidare delat in behovet mellan snabb & grundläggande simulering och detaljerad & komplex simulering. I jämförelse med Nikoukarans modell är alla dessa listor mycket mer detaljerade. Kriterierna är även här indelade i grupper, för detaljerad simulering finns hela 17 grupper. Även om Hlupic och Pauls lista innehåller många fler kriterier är Nikoukarans är det egentligen inte mer omfattande. Anledningen är att Hlupic och Pauls modell bara innehåller två nivåer i hierarkin; många av deras kriterier är istället uttryckta lägre i hierarkin av Nikoukaran.

4.1.4 Tillvägagångssätt vid simulering

När ett program valts ut och införskaffats är det dags att börja använda det. När man använder sig av ett simuleringsprogram underlättar det att följa en strukturerad metod. Banks (Banks, 2010) har utvecklat en omfattande modell för detta. Flödesschemat nedan illustrerar denna metod. Denna modell består av flera olika steg och kontrollpunkter för att hjälpa användaren av ett simuleringsprogram att se till att arbetet hålls på rätt kurs och att man kommer fram till ett tillförlitligt resultat.

21

Figur 5. Flödesschema över processen vid simulering (Banks, 2010).

Simuleringsprocessen börjar med steg 1, där problemet ska definieras. Vanligtvis utförs simulering för att man antingen vill lösa ett problem man är medveten om, eller för att hjälpa till att identifiera vilka problem som finns. I steg 2 sätts mål och en plan upp för projektet, vad som ska ingå och vad man vill få ut av simuleringsprojektet. Dessa två första steg är de kanske viktigaste i hela projektet, det underlättar otroligt mycket om man redan från början har en klar bild av vad man vill få ut av simuleringen (Banks 2010).

I steg 3 sker en konceptualisering av hur modellen ska se ut. Detta görs inte i själva simuleringsprogrammet utan med papper och penna eller andra enkla verktyg. Steg 3 är en designfas och meningen här är att strukturen ska fastställas innan man börjar modellera. Man bör utgå från en väldigt övergripande nivå för att sedan arbeta sig ned mot detaljerna. Här ska

22

också fastställas vilken detaljnivå den framtida modellen faktiskt ska ligga på genom att utgå från det som konstaterats i steg 1 och 2. Det finns ingen mening i att göra modellen mer komplex än vad mål och syfte för simuleringen kräver. Högre detaljnivå ökar arbetsmängden avsevärt, därför är det viktigt att konceptmodellen stämmer överens med den ursprungliga planen. Parallellt med steg 3 görs steg 4, datainsamling. All data som kommer att behövas ska först identifieras och sedan samlas in (Banks 2010).

I steg 5 ska konceptet byggas upp till en modell i ett utvalt simuleringsprogram. Om tidigare steg gjorts utförligt blir detta steg lättare och går snabbare. Efter detta ska modellen verifieras i steg 6 där den felsöks. Här kontrolleras att modellen är byggd utefter de specifikationer som satts upp och att den stämmer överens med konceptmodellen. Om den inte överensstämmer går man tillbaka till steg 5 och gör korrektioner i modellen. Detta görs tills modellen kan anses verifierad och man kan först då gå vidare till steg 7, validering. I valideringen testas hur väl modellen stämmer överens med verkligheten. Resultat och utdata från simuleringen jämförs med motsvarande data från den verkliga processen. Om det visar sig att modellen inte är representativ innebär det att man gjort något fel tidigare i processen. Man måste då gå tillbaka till steg 3 och 4 för att korrigera designen och strukturen av modellen. Detta kan verka omständligt men är en nödvändighet; en modell som inte motsvarar det den är tänkt att göra har man ändå ingen nytta av. De resultat man får ut från simuleringen blir missvisande och kan göra mer skada än nytta (Banks, 2010).

När modellen väl validerats kan man gå vidare till steg 8 där man börjar testa och experimentera med modellen. Ett av huvudsyftena med simulering är att testa alternativ till den nuvarande situationen vilket alltså realiseras i detta steg. I steg 8 bestäms vilka olika scenarion som ska testas och vilka parametrar i modellen som ska justeras. I steg 9 körs sedan dessa alternativ i simuleringsprogrammet och resultatet analyseras. Utdata och KPI:er från den ursprungliga modellen jämförs med de från körningarna av de nya alternativen. I steg 10 utvärderar man om man är nöjd med de resultat man kommit fram till eller om fler experiment ska göras med modellen. Antingen kan man då gå tillbaka till steg 9 om man anser att fler körningar behövs för att statistiskt säkerställa de resultat man fått. Alternativt kan man gå tillbaka till steg 8 och utforma nya typer av tester som man vill utföra i modellen.

När man testat de alternativ man vill ska allt tidigare arbete dokumenteras i steg 11. Syftet med detta är att andra ska kunna sätta sig in i och förstå modellen om den ska användas igen i framtiden. Både resultat och beskrivning av arbetsprocessen ska därför ingå i rapporteringen.

Det sista steget i hela simuleringsprojektet är implementering. Förhoppningsvis har man med hjälp av simuleringen kommit fram till hur en process kan förbättras. I steg 12 ska dessa förändringar av processen implementeras i verkligheten, vilket är slutmålet för ett simuleringsprojekt (Banks, 2010).

4.2 Operationsstyrning

Operationsstyrning är aktiviteten och läran om att leda och utforma produkter, processer, tjänster och supply chains. Operationsstyrning sker på både en strategisk och en taktisk nivå.

Strategiska uppdrag kan vara att bestämma storlek och plats för en fabrik, strukturen i ett service- eller telekommunikationsnätverk, eller att designa supply chains. Taktiska uppdrag

23

innefattar beslut om fabrikslayout och struktur, projektstyrningsmetoder, val av utrustning och maskiner, kvalitetskontroll, materialflöden och underhållsrutiner (Reid, Sanders, 2010).

4.2.1 Lean & Op-ex

Lean har sitt ursprung hos den japanska biltillverkaren Toyota, som sedan 1980-talet gjort sig kända för enastående kvalitet och effektivitet. Kärnan i Lean består av att eliminera slöserier, vilket definieras som allt som inte tillför något värde ur kundens synpunkt. Enligt Lean finns det sju olika sorters slöserier, och en extra åttonde som ibland också brukar läggas till. Dessa är (Liker, 2004):

1. Överproduktion. Produktion av varor som det inte finns någon order för.

2. Väntan. Operatörer som bara iakttar en automatiserad process eller väntar på nästa steg i processen, verktyg eller delar.

3. Onödiga transporter. Förflyttning av produkter i arbete (Work In Progress, WIP) genom ineffektiva vägar eller förflyttning till och från lager.

4. Överbearbetning. Genomgå onödiga operationer för att bearbeta produkten, uppnå högre kvalitet än vad som behövs.

5. Onödiga lager. Överskott på råmaterial, WIP eller färdiga produkter leder till längre ledtider, åldrande av produkter, transport- och lagerkostnader.

6. Onödiga förflyttningar. All typ av onödig rörelse operatörer måste utföra, som att leta efter eller hämta verktyg och delar. Att behöva gå är också slöseri.

7. Defekter. Produktion eller korrektioner av defekta delar leder till slöseri med tid och resurser.

8. Outnyttjad kreativitet. Att gå miste om idéer, förmågor, förbättringar och lärande genom att inte lyssna på de anställda.

Produktens värdekedja är central inom Lean och målet är att endast värdeadderande aktiviteter ska finnas kvar genom att de sju slöserierna elimineras. Organisationen och dess processer ska slimmas ned och bli Lean genom att allt onödigt slöseri arbetas bort. Inom Toyota arbetar man efter något som kallas ”The Toyota Way” för att bli Lean, vilket består av 14 principer för företaget att följa (Liker, 2004).

Del I: Långsiktig filosofi

Princip 1: Basera dina ledarskapsbeslut på långsiktig filosofi, även på bekostnad av kortsiktiga finansiella mål.

Del II: Rätt process ger rätt resultat

Princip 2: Skapa ett kontinuerligt precessflöde för att föra fram problem till ytan.

Princip 3: Använd ett pull-system för att undvika överproduktion Princip 4: Jämna ut arbetsbelastningen (Heijunka)

24

Princip 5: Bygg en kultur där man stannar processen för att åtgärda problemet så att rätt kvalitet uppnås första gången.

Princip 6: Standardiserade uppgifter är grunden för ständig förbättring och ökat ansvar hos de anställda.

Princip 7: Använd visuell kontroll så att inga problem döljs

Princip 8: Använd endast pålitlig och ordentligt testad teknologi som arbetar för människor och processer.

Del III: Addera värde till organisationen genom att utveckla dina anställda och partners Princip 9: Utveckla ledare som fullständigt förstår arbetet, lever filosofin,

och lär ut den till andra.

Princip 10: Utveckla enastående individer och team som följer företagets filosofi.

Princip 11: Respektera ditt nätverk av partners och leverantörer genom att utmana dem och hjälpa dem att förbättra sig

Del IV: Att ständigt lösa grundorsaken till problem driver lärande i organisationen Princip 12: Gå och titta på situationen själv för att förstå den fullständigt.

Princip 13: Fatta beslut sakta genom konsensus, där alla alternativ tagits hänsyn till; implementera dock besluten snabbt.

Princip 14: Bli en lärande organisation genom obeveklig reflektion (Hansei) och ständiga förbättringar (Kaizen).

Något som är viktigt att poängtera är att för att en organisation verkligen ska kunna bli Lean krävs att man arbetar efter principerna i alla de fyra delarna. Ett misstag många organisationer gör är att alltför stort fokus läggs på processerna (Del II). Man kan använda sig av många olika Lean-verktyg på denna nivå och se vissa kortsiktiga resultat, men för att uppnå långsiktiga konkurrensfördelar krävs det att hela filosofin implementeras i organisationen.

Många har också misslyckats genom ta genvägar att försöka kopiera Toyotas metoder rakt av, vilket inte är i linje med Lean-filosofin. Alla organisationer är olika och har olika kulturer, varför också Lean-arbetet måste anpassas (Liker 2004). Tittar vi på simuleringens plats i Lean så blir det främst ett verktyg för att arbeta med processerna, det vill säga Del II i Toyota Way.

26

De olika stegen i processen beskrivs i vänstra kolumnen, därefter fylls tiden i (siffervärde) som det tar att göra steget. Tiden delas in i tre olika typer, manuell tid (kräver att operatören utför arbetet), autotid (maskintid som inte kräver operatörens input) eller rörelse (operatören behöver förflytta sig). Därefter visualiseras detta genom att tiden fylls in i rutmönstret till höger, i exemplet ovan motsvarar en ruta . Målet är därefter att försöka placera de olika aktiviteterna i en ordningsföljd som minimerar väntetid och förflyttning för operatören, och samtidigt tar hänsyn till vilken ordning de olika stegen faktiskt kan utföras. Om det är ett enkelt flöde utan förgreningar med endast en operatör finns det inte så många olika alternativ och uppgiften blir relativt enkel. Om däremot två eller flera operatörer ska arbeta tillsammans i ett flöde som inte är lika strikt kan pusslandet bli betydligt mer komplext. Ofta måste även andra faktorer än enbart processen som sådan tas hänsyn till, så som raster och relativt rättvis fördelning i aktiviteter mellan olika operatörer (Larsson, 2015-04-10).

Value Stream Mapping

Value stream mapping (VSM) är ett klassiskt Lean-verktyg som används för att analysera en värdekedja (value stream). Det är ett effektivt sätt att visualisera flödet för att kunna identifiera problem som bör åtgärdas. Det första steget är att rita upp en current state map, där man mappar upp alla aktiviteter som är involverade i en produkts väg genom företaget från leverantör till kund. De olika delprocesserna läggs till med sina respektive cykeltider och ställtider, flödet av material och information ritas in, alla typer av lager läggs till och man räknar ut ledtiden för de olika delarna samt den totala ledtiden för hela värdekedjan. Därefter börjar man ritar upp en future state map, vilket symboliserar den ideala värdekedjan dit man vill ta sig. Sedan börjar arbetet med att ta fram en plan för hur man ska ta sig från current state till future state (Womack, 2006).

Figur 7. Exempel på utseendet hos en Value stream map (Womack, 2006).

27 4.2.3 Prestationsmätning

Vid förbättringsarbete och operationsstyrning spelar prestationsmätning en viktig roll.

Managementgurun Peter Druckers citat,”If you can’t measure it, you can’t manage it”, är välkänt inom managementlitteraturen (Behn 2005). Enligt Neely et al (Neely, 1994) menas med prestationsmätning en kvantifiering av effektivitet och/eller ineffektivitet över en viss tidsperiod. Prestation ses då som skapande av värde givet mänskliga, fysiska och kapitalmässiga resurser (Carton 2006). Operational Excellence defineras som ett tillstånd i en organisation då dess ansträngningar och prestationer är sammanriktade för att uppfylla dess strategier, samt att organisationen har en kultur som uppmuntrar till ständiga förbättringar för organisationens prestation och förhållandena för de som arbetar där (Xonitek). Operational excellence går alltså ut på att förbättra en organisation, men innan man kan förbättra något måste man först identifiera hur nuläget ser ut. Syftet med att mäta prestationen är alltså för att kunna analysera värdet och sedan göra en bedömning om värdet är högt eller lågt, först därefter bör man vidta åtgärder för att förbättra det. Enligt Hannula (Hannula, 2002) är användbara mätetal ofta en kompromiss mellan validitet (hur väl ett mätetal att mäter det som avses), reliabilitet (hur noga och konsekvent ett mätetal kan mätas), relevans (användbarhet och betydelse hos mätetalet) och praktikalitet (kostnad och tidsåtgång för att mäta talet).

Nyckeltal har en stor påverkan på en organisation. Systemet svarar mot hur man väljer att mäta och utvärdera det; genom att mål sätts upp för särskilda nyckeltal kommer individer att sträva mot att uppfylla dessa. Om felaktiga nyckeltal sätts upp uppmuntrar det fel typ av beteende. Nyckeltalen bör därför väljas med omsorg så att de överensstämmer med företagets övergripande strategi (Senge, 1990).

Nedan följer beskrivningar av några vanliga och viktiga KPI:er (Mogard & von Heijne, 2014):

Throughput rate - Anger hur många produkter man tillverkar per tidsenhet.

Utilization efficiency - Beskriver hur stor andel av upptagen tid som är värdeskapande tid hos en maskin/operatör.

Production process ratio - Beskriver hur stor andel av ordertiden som utgörs av faktisk produktionstid.

Work in progress (WIP) - Anger antalet icke-färdiga produkter som befinner sig i produktionsflödet vid en given tidpunkt.

Lead time - Tiden det tar från att göra klart en order från det att den kommer in.

Movement - Hur långt operatören rör sig under en viss tidsperiod, kan mappas upp med ett spaghetti diagram.

4.2.4 Theory of Constraints

Theory of constraints (TOC) är en metodologi för att identifiera och arbeta bort den begränsande faktorn i ett system. Den begränsande faktorn är det som hindrar systemet från

28

att uppnå ett visst mål och brukar inom produktion ofta kallas för en flaskhals (Vorne Industries Inc).

Kärnan i konceptet utgår från att varje system består av ett antal processer varav en är den svagaste länken, flaskhalsen. TOC fastslår att systemets kapacitet inte kan ökas utan att den begränsande faktorn elimineras. En viktig implikation från detta är att det inte lönar sig att lägga tid på att optimera icke-begränsande faktorer. TOC erbjuder en metod för att identifiera och eliminera flaskhalsar, kallad Five Focusing Steps som visas i figuren nedan.

Figur 8. Visualiserad modell för Five Focusing Steps inom Theory of Constraints (Vorne Industries Inc).

1. Identifiera begränsningen. Det första steget är att identifiera den nuvarande begränsningen – den enskilda faktorn som begränsar systemets kapacitet eller hindrar det från att uppnå ett mål.

2. Pressa begränsningen. Här genomför man enkla och snabba förbättringar i den begränsande aktiviteten. Tanken är att man ska pressa aktiviteten till max, medan förändringarna ska ligga inom ramen för de resurser som redan finns tillgängliga. Ett exempel är att omfördela operatörer från andra aktiviteter eller att effektivisera aktiviteten utan att lägga ner allt för mycket arbete eller göra några nya investeringar.

3. Underordna och anpassa. Se över alla andra aktiviteter i systemet för att säkerställa att de stödjer den begränsande faktorns behov, anpassa om möjligt icke-begränsande aktiviteter efter flaskhalsen.

4. Öka prestanda. Om begränsningen fortfarande kvarstår (inte har förflyttats till någon annan aktivitet), överväg vilka andra åtgärder som kan vidtas för att eliminera flaskhalsen. Oftast ligger man kvar i detta steg och implementerar nya åtgärder tills det att begränsningen inte längre ligger kvar i aktiviteten. I vissa fall kan investeringar i ökade resurser vara nödvändiga.

5. Repetera. Five focusing steps fungerar som en cykel för ständiga förbättringar. När begränsningen eliminerats från aktiviteten, blir automatiskt en annan aktivitet den nya flaskhalsen i systemet. I nästa varv tar man tag i denna aktivitet. Att metoden är en cykel fungerar som en påminnelse att förbättringsprocessen aldrig är över utan är ett ständigt pågående arbete. (Vorne Industries Inc)

29

5 Kartläggning och casebeskrivning

Detta kapitel innehåller beskrivning av två stycken produktionssituationer på GE Healthcares site i Uppsala, dels hur de ser ut i nuläget samt de scenarier vi simulerat.

5.1 Case 1 - V1

5.1.1 Nulägesbeskrivning

På GE:s site i Uppsala produceras olika pulver som används av läkemedelsföretag för vidare framställning. Detta pulver placeras i tunnor som lagras i väntan på att förpackas i mindre behållare och skickas till kund. I V1 sker förpackningen av detta pulver. I byggnadens källare finns ett lager där tunnor med pulver lagras. Processen utförs av två operatörer som arbetar efter ett standardiserat arbetssätt upprättat av Lean Leaders på GE. Processen går i stora drag ut på att operatörerna hämtar tunnor från källaren, för att fylla upp det i plastburkar som skickas till kunden. Pulvret är känsligt för kontaminering och dess kvalitet påverkas negativt om det blandas ut med smuts och andra partiklar. Förpackningen sker därför i renrum med slussar för in- och utpassering. Pulvret finns i två olika varianter, laddat och oladdat, förpackningen av dessa sker i två separata renrum eftersom de inte får blandas.

Processen startas genom att operatören skriver ut batchprotokoll från en planeringsfil i datorn som innehåller ordrar från kunden. Batchstorleken kan variera mellan 1-500 burkar. Därefter går operatören ned i källaren och hämtar tunnor med produkten som ska förpackas. Allt material som krävs för förpackning slussas in till renrummet och operatören byter om.

Därefter väger operatören upp rätt mängd pulver från tunnan till burkarna som sedan ställs på pall. Vissa kunder vill att burkarna ska förpackas i en kartong innan de skickas, andra tar burkarna som de är utan kartong. Om burkarna ska packas i kartonger slussas de ut till ett

”mellanrum” som ligger mellan de två renrummen. Där packas burkarna i kartonger som tejpas och etiketteras. Därefter tas de färdiga produkterna vidare för att skickas till kund.

Sedan städas renrummet och batchen avslutas i datorn. Därefter kan en ny batch påbörjas.

Oftast delas dagens arbetsuppgifter upp mellan operatörerna så att de tar ett rum var (laddat respektive oladdat). Processen består också av flera mellanliggande steg med dokumentation och övrigt. Nedan visas det standardiserade arbetssättet för steg 1-16+18 i processen i detalj.

Motsvarande bilder för övriga steg finns i bilaga 6.