Simuleringsverktyg för optimering av produktion - …861356/FULLTEXT01.pdf · Simuleringsverktyg...

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

1.1. Bakgrund

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 𝑘2 ⋯ 𝑘𝑛

𝐴 = [𝑎𝑖𝑗] =

𝑘1

𝑘2

⋮𝑘𝑛

[

1 𝑎12 ⋯ 𝑎1𝑛

1/𝑎12 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 ⋯ 𝑘30] ∗ [

𝑝1,1 ⋯ 𝑝5,1

⋮ ⋱ ⋮𝑝1,30 ⋯ 𝑝5,30

] = [𝑣1 𝑣2 𝑣3 𝑣4 𝑣5]

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.

31

burkarna som tidigare nämnts i vissa batcher packas i kartonger som också tar mycket av

operatörens tid.

Idén är att installera ett transportband från det laddade rummet in till mellanrummet. Detta

skulle då transportera de fyllda burkarna från fyllningsstationen in till mellanrummet. Det är

här Coboten kommer in i bilden, där den kan ta över allt arbete i mellanrummet från

operatören i det laddade rummet. Först kan Coboten ta emot burkarna från bandet och sätta

ned dem direkt på pallen om burkarna inte behöver packas i kartonger. Om de ska packas i

kartonger kan Coboten även sköta detta arbete. Operatören i renrummet kan då oavbrutet

arbeta med att fylla burkarna och slipper ställa ned dem på en pall och den andra operatören

behöver inte flytta pallen från slussen till mellanrummet.

En av anledningarna till att man ville effektivisera operatörens arbete var att man såg en stor

potential att kunna få ner beläggningen. Varför vill man då minska operatörens

arbetsuppgifter ytterligare? Man har spekulerat i att en operatör skulle kunna sköta hela

produktionen själv istället för två men tror inte att det är möjligt i nuläget. Om däremot en

Cobot köps in och tar över vissa arbetsuppgifter kan det vara möjligt. Man skulle i så fall

kunna flytta en operatör till andra arbetsuppgifter. Detta undersöker vi i Scenario 1 för V1.

Scenario 2 - Operatörer samarbetar

Utöver att testa implementation av en Cobot ville vi också testa att låta operatörerna

samarbeta. Som det ser ut idag arbetar operatörerna parallellt i varsitt rum med laddat

respektive oladdat pulver. Eftersom GE arbetar enligt Lean är man intresserade av att minska

Work in Progress, samt att minska ledtiden. Work in Progress är en av de åtta slöserierna

enligt Lean och bör därför minimeras. En minskning av ledtiden gör att man blir mer

responsiv och flexibel och kan på så vis möta kundorder snabbare. Detta gör också att man

inte behöver lagra lika mycket färdiga produkter; lager finns till för att snabbare kunna

leverera varor till kunden när en order kommer in. Om ledtiden minskar kan man dock möta

ordern snabbare utan att behöva ha stora lager som även det är en form av slöseri som kostar

pengar.

Ett förslag från Lean Leader om hur ledtiden skulle kunna kortas ned var att låta operatörerna

arbeta tillsammans med en typ av pulver i taget. Vissa av stegen i processen skulle kunna

utföras parallellt, till exempel skulle den ena operatören kunna hämta tunnor med material i

källaren medan den andra förbereder pappersarbete och annat. Eller så kan en operatör fylla

hinkarna medan den andra arbetar i mellanrummet precis som tanken var för Coboten. Vissa

stationer utföra snabbare genom att båda operatörerna arbetar samtidigt på samma process,

som till exempel fyllningsstationen. En operatör skulle då kunna fylla pulver i burkarna

medan den andra sätter på en etikett. Vissa processer kommer däremot inte gå att utföra

snabbare även om operatörerna hjälps åt. Den data vi hade tillgång till via Standard Work

Combination sheet visade tidsåtgången i varje steg av processen när en operatör utförde dem.

I simuleringen fick vi därför göra egna antaganden om hur snabbt de olika processerna skulle

ta om två operatörer hjälptes åt.

De frågeställningar som sattes upp inför caset i V1 var:

34

nummer. Alltså kommer först nr 1 fyllas på, därefter tank 2 eftersom 1 är full. Om tank 1 töms

helt kommer den återigen få högsta prioritet att bli fylld. Alltså kommer till exempel tank 11

bara att fyllas på om alla tankar 1-10 redan är upptagna. På så vis kunde vi se att om tank 11

fyllts på minst en gång visste vi att det vid den tidpunkten behövdes minst 11 tankar.

Prognosen för framtiden är att produktionsvolymerna väntas öka, vi ville därför testa sådana

scenarier. Vi körde simuleringen för 10 %, 20 %, 50 % och 100 % volymökning och tittade på

hur många tankar som behövdes.

De frågeställningar vi ställde upp inför detta case var:

Klarar man sig på 10 stycken tankar?

o Om inte, hur många tankar behövs?

Vad händer om volymerna ökar?

35

6 Resultat

6.1 Utvärdering av programmen Resultaten för utvärderingen av programmen presenteras här enligt samma upplägg som i

metoden.

6.1.1 Första kartläggning

Efter den första kartläggningen identifierades följande 14 program som vi valde att utvärdera.

6.1.2 Första utvärdering och urval

Under andra steget av processen kunde vi filtrera bort flera av de utvalda programmen på

grund av att de inte uppfyllde hårdkriterierna. De hårdkriterier som togs fram var:

Krav på stöd för kontinuerligt flöde

Maximalt pris på 200 000 kr

Snabb respons från försäljare vid kontakt

Rätt typ av simulering (flöden av material och inte simulering på operationsnivå)

Rätt komplexitetsnivå (ska kunna användas av nybörjare inom simulering)

Arena simulerade endast diskreta flöden. Automod var för komplex, antingen bör användaren

ha tidigare erfarenhet av simuleringsprogram eller så kommer det krävas en del hjälp av

konsulter vilket tar tid och kostar mycket pengar. Vi vill undvika det. Delmia är väldigt bra

för att simulera monteringslinor, då den simulerar varje rörelse robotarna gör och tar hänsyn

till produkternas exakta storlek. Däremot är Delmia för detaljorienterat, det skulle ta alldeles

för långt tid att simulera produktionslinorna. Enterprise Dynamics har en prismodell som inte

är önskvärd av avdelningen vi skriver vårt arbete hos. De vill kunna betala en engångskostnad

men man kan endast hyra Enterprise Dynamics licenser, man får då betala en årlig avgift för

att få använda programmet. TechnoMatix låg inte inom vår prisram, den var för dyr. Extend

Sim var lite för simpel.

36

De programmen som blev kvar efter första urvalsprocessen blev Anylogic, Flexsim, Simcad

Pro, Simul8 och Witness. Dessa fem program utvärderades vidare enligt AHP.

6.1.3 Analytical Hierarchy Process

Steg 1: Val av kriterier

Då vi undersökt tidigare vetenskapliga artiklar för att välja kriterier för val av

simuleringsmjukvara kom vi fram till en egen lista kriterier som antingen är eller kan vara

viktiga för GE. Det viktiga är att vi fått med alla relevanta kriterier, om vi fått med några som

senare skulle visa sig vara mindre relevanta kommer de få en mindre vikt i hela bedömningen.

Det skadar alltså inte att ha med något extra kriterium av mindre vikt. Valet av kriterier är

främst baserat på Nikoukarans förslag på kriterier och hierarki (Nikoukaran, 1998). Vi valde

dock att presentera förklaringen av kriterierna som fraser enligt samma upplägg som Azadeh

et al (Azadeh, 2010). Många av förklaringarna har inspirerats av Azadeh et al, men

formulerats om där de inte var tillräckligt tydliga eller deskriptiva. Uppdelningen av

kriterierna i grupper har ändrats om en del från Nikoukarans ursprungliga gruppering för att

göras mer distinkt och ortogonal. Vi ansåg att innehållet i vissa av de ursprungliga grupperna

gick in i varandra och att det därför skulle bli svårt att utvärdera dem mot varandra om de var

för lika varandra.

Vidare ansåg vi att nivån på Hlupic och Pauls sätt att organisera kriterier var allt för detaljerad

och innehöll för många grupper av kriterier för att passa Analytical Hierarchy Process. Vi

valde att inte använda denna detaljnivå utan istället ungefär samma nivå som Nikoukaran

föreslår. Dock inkluderades några av kriterierna från Hlupic och Pauls lista som inte fanns

med i Nikoukarans till vår lista av kriterier. Dessutom lades även kriteriet Lean tools till i våra

kriterier. Lean har det senaste decenniet utvecklats till en mycket vanlig produktionsfilosofi

bland företag och är av stor vikt för GE:s simuleringssyften. Simuleringsprogrammen har

olika mycket stöd för att göra analyser med inriktning mot Lean och detta ansågs därför

behöva inkluderas som ett kriterium.

Nedan följer vår lista av kriterier, 30 kriterier indelade i fem grupper. Till varje grupp av

kriterier (User, Vendor, Input & Modeling, Simulation, Output och Integration) ses

delkriterierna till vänster sida och förklaringarna till varje delkriterium på höger sida.

Kriterierna har uttryckts i engelska för 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å

intervjuer med programleverantörerna genomfördes eftersom i stort sett alla var

internationella företag.

37

Main-criteria

Sub-criteria User

Required

experience

If working with the software requires any previous experience or any

kind of knowledge in simulation or software

Ease of learning If the software is quick and easy to learn for new users

Financial

Cost of the software; including the price, installation cost, cost of extra

hardware requirements, maintenance cost (any discounts should be

considered)

Hardware How little performance the software requires from the computer

Tabell 4. Kriterier med beskrivningar för gruppen User.

Main-criteria

Sub-criteria Vendor

Training Availability of helpful user manual, training courses and online tutorials

which enables user to be independent from software supplier

Support If the vendor provides elements such as online help, online error

message, support by phone and online user forums

Pedigree Related to the history of the software and the vendor, how well

established they are.

Run-only Software version that can only run the simulation but not edit (cheaper

than full license)

Maintenance Availability of maintenance and update of the software

Tabell 5. Kriterier med beskrivningar för gruppen Vendor.

Main-criteria

Sub-criteria Input and Modeling

Building model

Whether the development of the model is easy and intuitive and if the

model can be made graphically or by entering codes, intuitive and

appealing screen layout and menus

Statistical

distribution

If it include some standard statistical distributions such as normal,

exponential, gamma, and rectangular distributions and if the software

can enable user to define a different distribution.

Customization How well library items can be customized in terms of behavior and

properties

Icons If the package has a large library of standard icons, icon editors,

possibility of creating new icons

Debugging If the software package provides elements such as logical error checks,

and error handling

Tabell 6. Kriterier med beskrivningar för gruppen Input and Modeling.

38

Main-criteria

Sub-criteria Simulation

Display features

Whether the software can provide dynamic display of the values of

variables, material flow, attributes, functions, and the state of the

elements while simulation is running

Simultaneous

modeling If the user can model while the simulation is running

Visual

appearance

Issues related to the graphical presentation of the model appearance on

the screen, how good and appealing it looks

Breakpoints If the user can determinate some points of the time for the model to stop

or start some other actions

Run simulation

by step The ability to go through the simulation step by step

Start in non-

empty state

Enables user to specify initial values for variables and attributes and

determinate the situation of the entities, queues, and activities

Tabell 7. Kriterier med beskrivningar för gruppen Simulation.

Main-criteria

Sub-criteria Output

Optimizer

Ability to optimize the variables of the model with different tools, such

as multiple run or similar methods to run the model multiple times and

changing the variables. What-if scenarios

Lean tools Lean tools for analyzing the model, such as the ability to generate value

stream maps, spaghetti diagrams and Lean/Six sigma KPI:s

Statistical

graphics

Whether results could be presented in the form of statistical graphics

such as histograms, bar charts, pie charts, and line graphs

Report Standard reports such as queue lengths, waiting times, and utilization.

User-defined reports are an advantage

Steady-state data If the user can choose to only collect steady-state data and statistics

Tabell 8. Kriterier med beskrivningar för gruppen Output.

Main-criteria

Sub-criteria Integration

Network version Whether the software has a network version or not

Import data If data can be imported by reading from a file or a system and if this

historical data can be used for more accurate statistical distribution

Integrated 3D Whether 3D-simulation is integrated with the model, or if a new model

needs to be built just for 3D-visualization

Import Icons If icons can be imported from other software packages or libraries (e.g.

CAD-objects)

Export data

If the software can be integrated with other packages such as

spreadsheets, statistical packages, database management systems, CAD,

and word processors

Tabell 9. Kriterier med beskrivningar för gruppen Output.

40

Steg 3&4: Utveckla och fyll i utvärderingsformulär & Skapa parvis jämförelsematris

Alla de 41 utvärderingsformulären redovisas inte denna rapport. Ett exempel på ett

utvärderingsformulär visas nedan, där de olika kriteriegrupperna utvärderats mot varandra.

Bild 3. Ifyllt utvärderingsformulär för kriteriegrupperna.

Alla resultat från utvärderingsmatriserna fördes in i jämförelsematriser, dessa finns i sin

helhet i bilaga 3. I tabellen nedan visas jämförelsematrisen för kriteriegrupperna efter att

resultatet från utvärderinsformuläret fyllts i.

Tabell 10. Exempel på parvis jämförelsematris för kriteriegrupperna.

Resultatet från utvärderingen har förts in i den vänstra jämförelsematrisen ovan, till exempel

ser man att User fick en relativ vikt=7 mot Vendor. Till höger visas samma matris efter att

Huvudkriterier

Use

r

Ven

do

r

Inp

ut

and

Mo

del

ing

Sim

ula

tio

n

Ou

tpu

t

Inte

grat

ion

Norm

Use

r

Ven

do

r

Inp

ut

and

Mo

del

ing

Sim

ula

tio

n

Ou

tpu

t

Inte

grat

ion

Wei

ghts

User 1 7 3 3 1 7

User 0,34 0,27 0,36 0,36 0,34 0,27 32%

Vendor 1/7 1 1/5 1/5 1/7 1

Vendor 0,05 0,04 0,02 0,02 0,05 0,04 4%

Input and Modeling

1/3 5 1 1 1/3 5

Input and Modeling

0,11 0,19 0,12 0,12 0,11 0,19 14%

Simulation 1/3 5 1 1 1/3 5

Simulation 0,11 0,19 0,12 0,12 0,11 0,19 14%

Output 1 7 3 3 1 7

Output 0,34 0,27 0,36 0,36 0,34 0,27 32%

Integration 1/7 1 1/5 1/5 1/7 1

Integration 0,05 0,04 0,02 0,02 0,05 0,04 4%

Sum 1 1 1 1 1 1 100%

Determinant 0,000 Eigenvalue 6,130 CI 0,026 CR 0,021

41

värdena har normaliserats, samt beräkningen av kriteriegruppernas vikter uttryckt i procent.

Längst ned visas värden relaterade till kontroll av konsekvens (CI & CR)

Steg 5: Kontrollera att resultatet är konsekvent

Resultatet från utvärderingen visade på inkonsekvens i svaren i 4 av de 41 matriserna, då

C.R.-värdet översteg 0,1 för dessa. Dessa utvärderingar gjordes då om med fokus på att hålla

svaren så konsekventa som möjligt och fick efter detta godtagbara resultat.

Steg 6: Beräkna kriteriernas vikter och programmens poäng

Kriteriernas vikter

Här har vi fått fram resultaten av de olika kriteriernas vikt efter att Lean Leaders från GE

gemensamt fyllt i AHP för huvudkriterierna och sedan har de fått fylla i en ny AHP för varje

grupp av delkriterier. Weights Level 2 står för huvudkriteriernas vikt, tillsammans ska den

kolumnen bli 100 % för att man väger dem relativt varandra. Weights Level 3 står för

delkriteriernas vikt, vilken är uppdelad i 6 grupper. Varje grupp ska tillsammans bli 100 %,

därav siffran 600 % längst ner i kolumnen. Efter vi fått fram dessa siffror kan vi räkna ut varje

delkriteriums totala vikt (Overall weight = Weights level 2 * Weights level 3).

Tabell 11. Kriteriernas slutliga vikter.

42

Om vi sorterar totalvikten för kriterierna får vi fram dessa tabeller. Vi kan då se att vissa av

kriterierna som vi valde inte var högt prioriterade av Lean Leaders på GE, därför fick de

kriterierna på botten väldigt lågt värde. Medan de två viktigaste kriterierna fick 15,9 % var

Tabell 12 & 13. Kriteriegrupper och kriterier sorterade efter vikt.

43

Simuleringsprogrammens poäng

I denna tabell presenteras hur väl de olika simuleringsprogrammen presterar för varje

delkriterium, det vill säga hur många poäng de kammar hem. Summan av varje rad blir 100 %

eftersom programmen betygsätts gentemot varandra.

Programmens vikt i förhållande till varandra för varje delkriterium

Sub-criteria

Anylogic Flexsim Simcad

pro Simul8 Witness User Required experience 6% 28% 43% 18% 6% 100%

Ease of learning 7% 43% 19% 28% 3% 100%

Financial 22% 7% 13% 55% 4% 100%

Hardware 10% 4% 9% 31% 46% 100%

Vendor Training 35% 35% 13% 11% 5% 100% Support 24% 12% 49% 10% 4% 100% Pedigree 49% 6% 15% 23% 6% 100% Run-only 48% 5% 16% 26% 5% 100%

Maintenance 27% 17% 42% 8% 5% 100%

Input &

Modeling Building model 7% 30% 15% 45% 4% 100%

Statistical

distribution 20% 20% 20% 20% 20% 100% Customization 4% 25% 47% 14% 9% 100%

Icons 35% 18% 18% 10% 18% 100% Debugging 10% 18% 31% 10% 31% 100%

Simulation Display features 11% 32% 32% 18% 7% 100% Simultaneous

modeling 5% 13% 56% 13% 13% 100% Visual appearance 27% 27% 27% 15% 5% 100%

Breakpoints 20% 20% 20% 20% 20% 100% Step-function 24% 24% 5% 24% 24% 100%

Start in non-empty

state 20% 20% 20% 20% 20% 100%

Output Optimizer 8% 38% 38% 8% 8% 100%

Lean tools 7% 7% 57% 23% 7% 100% Statistical graphics 13% 34% 34% 13% 6% 100%

Report 20% 20% 20% 20% 20% 100% Steady-state data 20% 20% 20% 20% 20% 100%

Integration Network version 38% 38% 10% 4% 10% 100% Input Data 9% 27% 27% 27% 9% 100%

Integrated 3D 20% 33% 33% 6% 8% 100% Input Icons 20% 20% 20% 20% 20% 100% Output data 33% 17% 17% 17% 17% 100%

Tabell 14. Hur väl programmen uppfyller varje kriterium.

47

Figur 13. Pugh-matris för subjektiv utvärdering av simuleringsprogram

Med denna undersökning kom vi fram till liknande resultat som från AHP. Det är samma

rankning på vilket program som rekommenderas från både undersökningarna.

1. Simcad Pro: 13

2. Flexsim: 11

3. Simul8: 7

4. Anylogic: 3

5. Witness: -4

6.1.5 Test av demoversioner

Resultaten från testning av demoversioner är svårt att uttrycka i siffror utan gav mer en

subjektiv bild hos oss själva. Ett av målen med detta var att identifiera irritationsmoment vid

modellbyggandet, alla tre programmen klarade detta test och var ungefär lika.

6.1.6 Val och inköp av simuleringsprogram

Baserat på resultaten från utvärderingen genom AHP samt vår egna subjektiva bild från

testning av demoversioner rekommenderade vi för GE Healthcare’s produktions-

ledningsgrupp i Uppsala att införskaffa simuleringsprogrammet Simcad Pro. Detta program

köptes in och installerades. En beskrivning av Simcas Pro finns under bilaga 4, där

programmets olika funktioner och byggblock finns förklarade.

6.2 Simuleringsmodell Här visas bilder på modellerna som byggts upp i programmet Simcad Pro, med tillhörande

beskrivningar.

6.2.1 V1

Här är modellen över nuläget i V1. En planritning har infogats och modellen har byggts

ovanpå denna för att få rätt proportioner. Processblock är utplacerade och sammanbundna

med linjer där material eller produkter ska kunna färdas.

48

Bild 3. Modell i Simcad Pro över nuläget.

Bilden ovan demonstrerar hur det ser ut i verkligen och var vissa aktiviteter sker. För att

lättare se hur operatörerna och flödet av material flyter på valde vi att möblera om i

mellanrummet som ni kan se i bilden nedan.

Bild 4. Modellen över nuläget med ommöblerat mellanrum.

Renrum laddat Mellanrum Renrum oladdat Kontor

49

6.2.2 Macktankar

Modellen för macktankar visas i bilden nedan. 15 processblock som representerar tankar har

placerats i mitten. Det finns också start- och endblock där flödet av de olika produkterna

börjar och slutar. Graferna visar dels den nuvarande volymen i var och en av de 15 tankarna,

samt hur många ordrar som gått igenom (här 100 % av årsvolymen).

Bild 5. Modellen för macktankar då simuleringen körts igenom med historiska data för

produktionsvolymer.

Siffran 10 står för antalet ordrar av en vätska som önskades men inte fanns i någon tank.

Siffran 0 står för antalet batcher som ville sättas in i en tank men som inte hittade någon

tillgänglig.

6.3 Data från simulering

6.3.1 V1

När vi simulerade dessa 3 scenarier körde vi de första 50 batcherna från 2014 års

orderhistorik. Dessa 50 batcher hade i snitt 24 burkar med pulver per batch. Om vi räknar med

de siffror som finns på Standard work combination sheet får vi fram att ledtiden för en batch

med 26 burkar att gå igenom system tar cirka två timmar (sekretessbelagt, varför en

uppskattning anges här).

50

Scenario: Nuläget

Bild 6. Modell över nuläget i V1.

På bilden ser man att varje operatör arbetar på varsin lina. När vi simulerar de 50 första

batcherna får vi en genomsnittsledtid på 2 timmar och 3 minuter. Outputen blir 25

hinkar/timme för båda operatörerna tillsammans.

Scenario: Cobot

Bild 7. Modell över Scenario med Cobot i mellanrum.

51

Här ser kan man se den implementerade Coboten som befinner sig i mellanrummet. Den ser

till att operatören inte behöver gå in i mellanrummet förutom när han/hon ska hämta pallen

med de färdiga produkterna förpackade. Genomsnittliga ledtiden blev 1 timme och 43

minuter. Outputen blev 15 hinkar med pulver per timme.

Scenario: Operatörer Samarbetar

Bild 8. Modell över scenariot då operatörerna samarbetar.

Bilden ovan visar hur 2 operatörer arbetar tillsammans på en och samma produktionslina.

Operatör 1 står inne i renrummet och fyller pulver i hinkar medan operatör 2 tar emot

hinkarna i mellanrummet och förpackar dem i kartonger. Den genomsnittliga ledtiden blev 1

timme och 22 minuter, med en produktionshastighet på 19 hinkar per timme för de två

operatörerna tillsammans. Det produceras färre färdiga produkter i timmen men ledtiden blir

kortare, dessutom halveras även work in progress.

Resultat årsvolymen 2014 med 1 operatör

Nuläge: 89 % beläggning för 1 operatör (klar på 197 arbetsdagar)

Med Cobot: 75 % beläggning för 1 operatör (klar på 158 arbetsdagar)

53

Vi beslöt oss för att undersöka vår historiska data:

Volym IN till macktankar

Batcher per år

Produceras varje x dag

Produceras varje x timme

Liter/ batch

Total volym/år

HF 35

HF35 Z

HF 55

HF70

Volym UT från macktankar

Batcher per år

Produceras var x dag

Produceras var x timme

Liter/ batch

Total volym/år

summa av olika ämnen

HF 35

HF35 Z

HF35 Z

HF35 Z

HF35 Z

HF 55

HF 55

HF70

HF70

HF70

Differenser

Ämne Differens på volym

IN och UT Differens formulerat i

batcher Diff. batcher

avrundat uppåt

HF 35 - -1,7 -2

HF35 Z - -1,2 -2

HF 55 6,3 7

HF70 2,2 3

Tabell 18. Historisk data över produktionsvolymer för macktankar.

Som vi ser på differenserna så har vi ett underskott på vissa ämnen och ett väldigt stor

överskott på ett annat ämne. Detta är historisk data från GE Healthcare så svaret till varför det

finns ett underskott kan bero på att det har funnits kvar av det ämnet från förra årets

produktion. Men att ha ett överskott på 7 batcher är för mycket. Det är slöseri att lagra så

mycket.

Kundernas efterfrågan år 2014 kan vi inte ändra på, men det vi kan ändra på är hur mycket

som egentligen borde produceras. Vi testade därför att ändra data i simuleringen till att de

tillverkar en batch för mycket mot vad som behövs avrundat uppåt. (Det måste finnas en för

mycket ifall differensen inte blir exakt 0, vilket det inte blir i något av våra fall.) Efter dessa

justeringar såg data till simuleringen ut enligt tabellen nedan.

54

Volym IN till macktankar

Batcher per år

Produceras varje x dag

Produceras varje x timme

Liter/ batch

Total volym/år

HF 35

HF35 Z

HF 55

HF70

Volym UT från macktankar

Batcher per år

Produceras var x dag

Produceras var x timme

Liter/ batch

Total volym/år

Summa av olika ämnen

HF 35

HF35 Z

HF35 Z

HF35 Z

HF35 Z

HF 55

HF 55

HF70

HF70

HF70

Differenser

Ämne Differens på volym

IN och UT Differens formulerat i

batcher Diff. batcher

avrundat uppåt

HF 35 0,33 1

HF35 Z 0,82 1

HF 55 0,29 1

HF70 0,17 1

Tabell 19. Justerad historisk data över produktionsvolymer för macktankar.

Vi importerade den nya datan till Simcad Pro och lät den simulera de nya batchordrarna.

57

7 Analys & Diskussion

7.1 Utvärdering av simuleringsprogram

7.1.1 Tillförlitlighet i val av program

En faktor som måste tas hänsyn till vid analys av resultatet från utvärderingen är vilka

personer som användes för att vikta kriterierna. Vi använde oss av Lean Leaders på GE

Healthcare eftersom de ansågs väldigt kunniga om företaget och dess processer, dock är de

inga experter på simulering. Vi förklarade under utvärderingen för dem vad de olika

funktionerna och kriterierna innebar. Dock kan det vara så att de själva inte vet exakt vad de

vill ha. Step function kan tas som exempel, då utvärderingen gjordes hade vi själva provat på

några demo-versioner med och utan step-function. Dock används step-function främst till att

validera modellerna, något vi inte gjorde i demo-versionerna. När vi senare byggde de riktiga

modellerna i Simcad Pro, som saknade step function, märkte vi hur bra denna funktion hade

varit. Om viktningen gjordes om idag skulle sannolikt step function få högre vikt.

Simcad Pro var det program som fick högst poäng i utvärderingen och även valdes att köpa in.

Dock kom FlexSim väldigt nära och fick nästan lika hög poäng. Den metod vi använt för att

utvärdera är utformad för att ge så tillförlitliga resultat som möjligt, dock kan den väldigt lilla

skillnaden i poäng mellan Simcad Pro och Flexsim bero på små slumpmässiga faktorer och

andra anledningar som exemplet med step function ovan. Därför anser vi att Flexsim säkert

hade kunnat vara ett lika bra val som Simcad Pro för GE. Om man dock tittar på priset för

programmen så ligger Flexsim på ungefär dubbelt så mycket, vilket var en av anledningarna

till att Simcad Pro köptes.

7.1.2 Viktiga implikationer vid viktning av kriterier

Viktningen av kriterierna är däremot av väldigt stor betydelse eftersom detta spelar en

avgörande roll i vilket program som väljs. Om fel vikt läggs för ett kriterium kommer

resultatet att bli missvisande och programmen riskerar då att inte kunna uppfylla de behov

användaren har. Efter att ha studerat och arbetat med simulering har vi lärt oss mycket om vad

de olika kriterierna verkligen har för betydelse. I detta avsnitt diskuterar vi för varje grupp av

våra kriterier vilken effekt det skulle få om de utvärderas fel och får felaktig vikt, eller om

man helt skulle utesluta ett visst kriterium från sin lista av kriterier.

User

Dessa kriterier handlar om omständigheter och behov som är specifika för användaren. Om

dessa kriterier utvärderas fel kan man råka köpa ett program som är väldigt bra på pappret

men som inte passar användaren. Programmet kan vara anpassat för personer med mycket

erfarenhet inom simulering och vara för komplext för nybörjare att sätta sig in i. Vissa

program använder sig av relativt krävande grafisk presentation av modellen, vilket medför

krav på hårdvaran den ska köras på. Detta kan innebära att programmets funktion blir

begränsad eller att nya datorer behöver köpas in, vilket leder till ytterligare kostnader utöver

programmet.

58

Vendor

Denna kategori rör programleverantörens kredibilitet och vilken typ av service och tjänster de

erbjuder. Många leverantörer erbjuder någon typ av utbildningsmaterial för att lära sig

programmet, eller support efter det att programmet köpts in. De olika leverantörerna varierar i

erfarenhet och storlek på företaget. De mindre leverantörerna kan till exempel tänkas kunna

ha bättre personlig kontakt med användarna, medan större leverantörer kan ha en större

kunskapsbas med fler användare och mer aktiva forum. Detta kan också utvecklas till en

kostnadsfråga eftersom det skiljer mycket på hur leverantörernas modell för support och

underhåll ser ut. Ofta erbjuds någon typ av underhållskontrakt som tecknas för varje år, priset

för detta varierar kraftigt. Även priset för support varierar kraftigt, där det finns leverantörer

som erbjuder gratis support medan vissa tar så mycket betalt att supporten kan komma att

kosta mer än programmet självt. Detta bör absolut tas hänsyn till vid utvärderingen av

kriteriernas vikt och programmens poäng. Om användaren själv sitter på mycket kunskap om

simulering kommer inte lika mycket support behövas som om användaren saknar tidigare

erfarenhet om hur simuleringsprogram används.

Input & Modeling

Denna grupp kriterier tar upp aspekter om hur modellen byggs upp i programmet och hur den

kan anpassas och justeras. Själva byggandet av modellen är en central del i användningen av

programmet och kommer sannolikt ta upp en stor del av tiden som spenderas på simulering.

Just tidsaspekten är därför något som spelar in här; om metoden för att bygga modellen är

omständlig eller menyerna inte är intuitiva kommer tidsåtgången att öka kraftigt. Längre

tidsåtgång för varje modell betyder att man tvingas lägga ner mer resurser på modellering än

planerat. Den andra viktiga delen i denna kategori är hur väl och detaljerat modellen kan

anpassas. De olika programmen kan skilja sig i hur detaljerat modellens beteende kan ställas

in. Med mindre alternativ för anpassning blir det svårare att få modellens beteende att

överensstämma med verkligheten. Detta leder i sin tur till att data och resultat från

simuleringen får större felmarginal och blir mindre tillförlitlig och användbar. Anpassning av

modellen kan också vara av visuell karaktär, vilket skiljer sig åt mellan olika program. Om

simulering främst ska användas för interna syften inom ett företag spelar oftast inte det

visuella särskilt stor roll. Om man däremot vill använda simulering som ett verktyg för att

presentera för ledning eller kunder om ett förslag till investering eller förändring kan visuella

anpassningar som ikoner och animationer spela större roll.

Simulation

Dessa kriterier har med funktionaliteten under simuleringen att göra; till exempel vilken

information som visas eller vilka inbyggda hjälpmedel som finns för användaren att styra

simuleringen. Genom att visa simuleringens nuvarande status med hjälp av data och grafer får

användaren en bättre insikt om hur modellen fungerar. Detta spelar en stor roll vid verifiering

och validering av modellens funktionalitet, det vill säga att kontrollera att den beter sig som

användaren tänkt sig och stämmer överens med verkligheten. Valideringen av modellen kan

också göras betydligt enklare genom funktioner för att bättre kunna styra hastigheten och

flödet vid simuleringen. Till exempel har vissa program en ”step-function”, som innebär att

användaren kan välja att pausa simuleringen och gå direkt vidare till nästa steg genom att

59

trycka ”next”. Utan denna funktion kan användaren behöva gå igenom hela simuleringen från

början till den process man vill undersöka närmare. Om många av processerna innan

processen man vill undersöka tar lång tid blir detta mycket tidskrävande. Detta kan delvis

hanteras genom att snabba på simuleringen för att komma till rätt tidpunkt i simuleringen,

dock blir problemet då istället att man riskerar att köra förbi tidpunkten och får börja om från

början. Vissa program har så kallade ”break points” som låter användaren definiera en

tidpunkt eller process som simuleringen ska pausas vid. Dessa två funktioner kan verka

marginella men har en väldigt viktig roll och är något som i de flesta fall bör kontrolleras

innan ett program väljs. Om man under utvärderingen missar att ta hänsyn till dessa kriterier

kan det leda till val av ett program som gör valideringen av modellen mycket svårare.

Validering utgör en väldigt viktig del av hela simuleringsprocessen, utan den kan inte

modellens korrekthet kontrolleras och som nämnts tidigare blir då utdata mindre korrekta.

Output

I denna kategori ingår alla kriterier som rör de resultat användaren får ut från simuleringen.

Utdata fås i de flesta program i en rapport som listar flera olika KPI:er och mätdata som

genererats under simuleringen. Det som kan skilja sig är att vissa program automatiskt räknar

ut fler och mer specialiserade KPI:er. Till exempel finns program som inriktar sig mot Lean

och ger relaterade KPI:er och Lean-rapporter. Programmen ger också olika möjlighet för att

analysera resultaten och även optimera modellen. Detta är ett område där programmen kan

skilja sig väldigt mycket. Traditionellt har simuleringsprogram enbart varit ett sätt att testa

och visualisera olika lösningar och scenarion, det är då upp till användaren själv att förbättra

modellen och hitta bättre lösningar. Vissa simuleringsprogram har på senare tid även fått

funktioner för att optimera modellen inuti programmet. Eftersom att detta är relativt nytt är

skillnaden mellan programmet relativt stor på den här punkten. Om dessa funktioner värderas

högt spelar de en viktig roll i utvärderingen.

Integration

Integration innefattar hur programmet kommunicerar med andra applikationer och databaser,

hur data importeras och exporteras. Indata som används kan vara antingen historisk data eller

prognoser om framtiden angående produktionsvolymer, personaltillgång, kvalitetsbrister, eller

tidsdata och produktionsscheman. Exportfunktioner tar de resultat som simulering ger och

exporterar dem för att analysera i externa program som till exempel Excel. Vanligtvis finns

funktioner för import och export av dessa data men det kan variera hur enkelt detta är och

vilka filformat som stöds. Integration spelar en väldigt viktig roll i hur programmet kommer

att användas i den organisation där det implementeras. Om möjligheten att importera data är

begränsad kommer det göra det mer omständligt att använda programmet. Om användaren

hela tiden behöver leta reda på dokument och Excel-filer blir programmet mer en fristående

applikation som är mindre sannolikt att användas. Genom att se till att företaget kan interagera

direkt med företagets databassystem blir programmet istället en integrerad del av

organisationen. Integration spelar därför en viktig roll för att framgångsrikt lyckas

implementera programvaran och se till att den fortsätter att användas i framtiden. När

programmen utvärderas bör dessa faktorer undersökas väldigt noggrant.

60

7.2 Simulering av V1 Från resultaten ser vi vilka förbättringsalternativ det finns beroende på vad som önskas. Om

det är väldigt viktigt för kunden att få sin produkt (batch) så tidigt som möjligt kan det vara

värt att köra med 2 personer på en och samma lina eftersom man får ner ledtiden med 34 %.

Men samtidigt så minskar produktiviteten med 24 %, så man får göra en avvägning om det är

värt det eller inte. Fördelen med att arbeta 2 operatörer i ett rum i taget är att man får ner WIP

till hälften så mycket, eftersom man endast kör med 1 lina istället för 2 åt gången. Från

resultaten ser vi att 1 operatör och 1 Cobot har en kortare ledtid plus att de har en högre

produktionshastighet. Ledtiden minskar med 16 % samtidigt som produktionshastigheten ökar

med 10-20%. Det man får tänka på är att om man har 2 operatörer och 1 Cobot så kommer

Coboten bli en flaskhals och därför innebär det 2 operatörer + 1 Cobot inte ger en output på

30 hinkar i timmen. Den faktiska outputen kommer hamna på 27.5-30 hinkar i timmen. Om

man tänker sig att ena linan består av 1 operatör och 1 Cobot (ger 15 i output) och den andra

linan med endast en operatör (ger 12.5 i output) så får vi en output på 27.5. Coboten kommer

dock kunna hjälpa den andra operatören till viss del ändå så outputen kommer hamna på ett

genomsnittligt intervall mellan 27.5 och 30 hinkar i timmen. Därav produktions-

hastighetsökningen på 10-20 %.

En produktionshastighetsökning på 10-20% kanske inte ses som tillräckligt mycket för att

investera i en ny Cobot, men om man tittar på andra siffror, såsom hur många arbetsdagar det

tar för en operatör att producera hela årets batcher själv så ser vi från resultaten att det tar 197

arbetsdagar. Det innebär att operatören är 89 % belagd under hela året. Det är på gränsen till

för mycket, det kan vara svårt att hinna med allting med tanke på att operatörerna kan bli

sjuka ibland och att de inte lägger ned hela sin tid på produktion, de går även på utbildningar

under sin arbetstid ibland. Om man då väljer att investera i en Cobot som är relativt billigt i

jämförelse med vanliga industrirobotar så får man ner beläggningen på operatören till 75 %.

Det är mycket mer rimlig siffra, det är något en operatör skulle klara av i verkliga livet. Om

GE Healthcare väljer detta alternativ kommer deras payback time vara ca 1 år. Det innebär att

det är en väldigt bra investering. När vi säger att payback time är ca 1 år menar vi att man inte

kommer betala för operatören i denna produktionslina. Det innebär att en operatör kan sättas

på andra aktiviteter.

7.3 Simulering av Macktankar Resultaten från macktankarna visade att man klarade sig med 10 tankar för en volymökning

på ordrarna ända upp till 50 %. För en 100 % volymökning krävdes dock 11 tankar enligt

simuleringen. Detta var ett ganska överraskande resultat. När vi samlade information om

processen fick vi intrycket att de vi pratade med hade uppfattningen att ”ökad

produktionsvolym med 50 % innebär ökat antal tankar med 50 %”. Efter vidare analys och

diskussion av modellens uppbyggnad kom vi fram till att om GE Healthcare kan producera

dessa basprodukter när så önskas så räcker 10 tankar till om de planerar schemat för

produktion bättre. Om vi tänker på att det endast får finnas en batch per tank i taget och

analyserar batchstorlekarna för t.ex. HF 35. HF 35 har en batchvolym på 900 liter. Ordrarna

som kommer behöva ta ämnet HF35 ur tankarna har en batchvolym på 400 liter. Så efter 2

ordrar som gått ut har man tömt en tank med 800 liter. Då återstår det 100 liter av HF 35 i

61

tanken. När en tredje order kommer in ska den alltså ta dessa 100 liter + resterande 300 liter

från en annan tank. Så i något skede kommer det behövas minst 2 tankar för varje basprodukt

eftersom volymerna på batcherna skiljer sig åt. Det finns i nuläget 4st basprodukter, varje

behöver 2 stycken vardera, vilket resulterar att i värsta fall kan man behöva ha 8st tankar.

Men att 8 stycken tankar ska räcka fungerar i en perfekt värld, vilket vi inte lever i. Det kan

förekomma variation och störningar i produktion. Flera ordrar kan komma direkt efter

varandra så man kan vara tvungen att bygga upp ett litet lager i förhand för att hinna med

efterfrågan ifall den inte är jämt fördelad. Så om man kör med 10 stycken tankar har man

ändå en buffert på minst 2 tankar.

Det är alltså inte ordervolymen som är det essentiella i frågan om hur många tankar man

behöver. Vad som bestämmer hur många tankar som behövs är antalet basprodukter och hur

flödet av dessa ordrar är. Om det är stor skillnad på in och utflöde av ordrarna så krävs det fler

tankar. Via vår simulering för 100 % volymökning krävdes 11 tankar. Vi är övertygade att

den siffran kan sjunka ifall man planerar in när man ska skapa batcherna istället för att ha de

spridda jämnt fördelat över året. HF 35Z har 4st slutprodukter, dessa slutprodukter är var för

sig jämnt fördelade över året, inte tillsammans. Det betyder att efterfrågan på HF 35Z inte

kommer vara jämnt fördelat över året. Därför behöver man anpassa sin produktion till

efterfrågan.

Efter att ha kommit fram till att det är planeringen som är ett av de stora problmen för caset

Macktankar diskuterade vi med en person från support till Simcad Pro hur modellen skulle

kunna användas för att underlätta planeringen. Vi kom då fram till att modellen kan utvecklas

för detta, nästa steg i simuleringsmodellen av macktankarna är att skapa ett pull-flöde av

ordrarna för slutprodukterna. Man kommer då kunna ta hänsyn till processtiden, setup-tiden

osv. Denna modell kommer kunna fungera som ett planeringsverktyg för GE Healthcare. De

kommer kunna importera in sina ordrar som de har fått av kunderna och sedan kommer de få

ut information om när de ska börja producera varje basprodukt och i vilken mängd.

7.4 Simulering som verktyg Efter att ha arbetat med simulering under detta examensarbete har vi märkt att simulering är

ett väldigt bra och effektivt verktyg. Förutsatt att en modell har en hög validitet kan

simulering hjälpa ett företag att mäta och experimentera med sina nyckeltal. Mätningen kan

göras mycket effektivare eftersom körningar kan göras i högre hastighet än i verkligheten,

samt att programmet automatiskt samlar in data och beräknar många nyckeltal. Många

nyckeltal som annars hade varit allt för svåra eller tidskrävande kan med simulering relativt

enkelt fås fram. Tittar vi på principerna i Del II av Toyotas 4P-modell, och även de 8

slöserierna inom Lean, kan vi konstatera att många simuleringsprogram har väldigt bra

funktioner för att eliminera slöserier och hjälpa företag att göra sina processer mer Lean.

Under arbetet har vi använt oss av Banks metod för hur ett simuleringsprojekt ska utföras.

Något vi märkte under arbetets gång var att det lönade sig att lägga ner tid på varje steg och

utföra de grundligt, särskilt de två första stegen där simuleringens mål och syfte definieras.

Man bör anpassa nivån på modellen efter vilket syfte man har för analys. Detta hänger också

ihop med KPI:er; vill man till exempel bara mäta output behöver egentligen inte operatörernas

62

operationer läggas till på detaljnivå. Och om man vill hitta en optimal lagerstorlek behöver

operatörer kanske inte ens implementeras eftersom de inte påverkar denna KPI särskilt

mycket. För att spara tid bör man alltså från början tänka på vad som är syftet med

simuleringen och vilka KPI:er det är man vill mäta. En modell kan (iallafall i Simcad Pro)

göras väldigt detaljerad, men tidsåtgången för att modellera ökar också exponentiellt med

detaljnivån. Säg att det tar 20 timmar att få modellen att överensstämma till 85-90 % med

verkligheten, ytterligare 5 % kan ta minst lika lång tid till. Tidsåtgången är i detta avseende

inte linjär och modelleraren bör avväga hur mycket tid som kan läggas ned för att uppnå en

tillräcklig validitet i modellen. Simulering har många fördelar framför andra traditionella

analysverktyg, men för att det ska vara värt att göra får inte tidsåtgången vara allt för hög.

Relaterat till detta är hur man väljer att använda sig av simulering, där vi har identifierat två

olika tillvägagångssätt. Det ena är att använda simuleringsverktyget för att bygga upp hela sin

fabrik ”i punkt och pricka”. Enligt en av försäljarna vi pratade med under utvärderingen av

programmen nämnde att ett annat stort svenskt företag använde sitt simuleringsprogram för

att bygga upp en virtuell fabrik. Denna virtuella fabrik såg de som sin ”faktiska” eller ”ideala”

fabrik, så som det ska se ut i verkligheten. Den andra typen av simulering vi identifierat är en

mer projektbaserad variant. Istället för att bygga upp en virtuell fabrik används simulering

istället som ett verktyg för att lösa ett specifikt problem. Denna typ av simulering är den som

vi utfört under examensarbetet och passar bra ihop med Banks metod. Dessa två

tillvägagångssätt skiljer sig ganska mycket åt och ett företag bör tänka över vilket sätt man

tänkt använda programmet innan man köper in det. Om man väljer att gå på strategin ”virtuell

fabrik” bör man nog ha minst en anställd eller kanske ett simuleringsteam som ägnar hela sin

tid åt det. Om det snarare ska användas av ett Lean-team i vissa särskilda fall kan det nog vara

mer effektivt att använda en mer projektbaserad modellering där man bygger modellen utefter

det aktuella syftet. Många simuleringsprogram (inklusive Simcad Pro) stöder också en

modulbaserad modellering. Det skulle också kunna användas med framgång vid en

projektbaserad approach, där moduler snarare läggs till och kopplas ihop en efter en. Detta är

ett alternativ till att i ett initialt implementeringsskede av simuleringsprogrammet mappa upp

hela siten. Ett sådant projekt skulle kräva specialistkompetens inom simulering och möjligtvis

konsulter. Detta togs inte direkt hänsyn till i vår utvärdering av programmen; det kan visa sig

att vissa program bättre stöder den ena modelleringsapproachen än den andra. Vi anser dock

att Simcad Pro kan användas till båda.

7.5 Hållbar utveckling och etiska aspekter Simulering är ett effektivt verktyg för företag att analysera sin verksamhet och testa

förbättringsförslag. De åtgärder som i första hand åsyftas är sådana som ökar effektiviteten,

sänker kostnader eller ökar kapaciteten. Det är också dessa faktorer som leverantörerna av

simuleringsprogram marknadsför. Dock anser vi att simulering även kan hjälpa företag och

andra organisationer ur ett ekologiskt perspektiv. Genom att använda sig av ett

simuleringsverktyg kan man spara väldigt mycket resurser. Ett av de huvudsakliga syftena till

att använda sig av simulering är att man vill testa en lösning i programmet innan man

implementerar den i verkligheten. Ta som exempel att ett företag överväger att köpa in en ny

maskin. En simulering kan visa att den nya maskinen egentligen inte behövs eller att en annan

63

typ av maskin egentligen borde köpas. Utan simulering skulle maskinen ändå kunna köpas in

på grund av bristande beslutsunderlag. Detta skulle vara en stor ekonomisk förlust för ett

företag, men också negativt ur ett hållbart perspektiv. Många resurser har säkerligen lagts ner

för att producera och frakta maskinen till företaget, dessa resurser användes i onödan när det

visar sig att maskinen var en onödig investering. Utöver detta kan också simuleringsverktyg

användas för att direkt simulera miljöpåverkan och utsläpp. Ett företag skulle till exempel

kunna använda energiförbrukning eller mängd utsläppt koldioxid som en parameter i

simuleringen. Därefter kan man välja att optimera modellen utefter dessa parametrar.

Vi har konstaterat att simulering är ett väldigt kraftigt verktyg för att ge beslutsunderlag. Den

som är användare av simulering i ett företag har ofta en större chans att motivera varför just

hans/hennes förslag bör implementeras eftersom man kan ge siffrorna svart på vitt och även

visa modellen vilket är väldigt visuellt tilltalande. Dock bör man komma ihåg att dessa siffror

endast är giltiga och relevanta om modellen har en hög validitet. Simuleringsverktyget kan ge

en person i ett företag ökad makt och inflytande, vilket också kan missbrukas genom att

manipulera indata till modellen. Detta bör tas i beaktning och man bör komma ihåg att inte

ens simulering kan ge ett 100 % säkert beslutsunderlag, simuleringen är en representation av

verkligheten.

64

8 Slutsats I slutsatsen ämnar vi besvara arbetets syfte och de frågeställningar som ställts upp.

Delfrågorna löd:

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

Vi har undersökt olika metoder för att utvärdera och kommit fram till en metod som

involverar Analytical Hierarchy Process passar bäst för detta ändamål. Genom att använda vår

utvärderingsmetod kom vi fram till att Simcad Pro var det bästa simuleringsprogrammet för

GE Healthcare. Flexsim kan säkerligen vara en lika stark kandidat men kostar dubbelt så

mycket.

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

Vi har med de case vi genomfört demonstrerat hur programmet kan användas. Det kan till

exempel användas för att optimera resurserna (om man köper in en Cobot krävs det en

operatör mindre och man sparar på så vis pengar). Det kan även användas för att optimera

inköp av utrustning. Detta visade vi i caset med macktankarna; de tänkte köpa 14 stycken men

vi visade att det endast krävs 10 som mest utan någon riktigt planering. Programmet har

många funktioner som stöder arbete för förbättringsarbete och Lean och kan vara till stor

hjälp inom detta område jämfört med klassiska Lean-verktyg. Något vi också kommit fram till

var att programmet kan användas som schemaplanerare.

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

Vi har identifierat en simuleringsmetod utvecklad av Banks (Banks, 2010) som ger en tydlig

process att följa vid användning av simulering, vi rekommenderar starkt att följa denna för att

spara tid och uppnå ett tillförlitligt slutresultat. Vi har diskuterat två olika tillvägagångssätt

vid simulering, den ena bygger på att man har en virtuell fabrik i programmet och den andra

använder en mer projektbaserad strategi där man modellerar en viss del i taget efter behov.

För GE passar i nuläget den projektbaserade metoden bäst, och det var också den ursprungliga

tanken att Lean-teamet ska använda sig av simuleringen för att testa olika förbättringsförslag

innan de implementeras. Vill man dock gå över till att mappa upp hela sin produktion bör man

överväga att anställa personer dedikerade till simulering. Något som vi vill understryka är

vikten av att ha syftet med simuleringen klart för sig från början.

Syftet med detta examensarbete var ”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.” Med vår

rapport anser vi ha lyckats uppnå detta. För andra företag som är intresserade av att investera i

ett simuleringsprogram kan vårt arbete komma till stor nytta. Genom att använda vår metod

för att vikta kriterier och utvärdera programmen kan de hitta det som passar deras behov bäst.

Våra exempel och case demonstrerar programmets kapacitet och hur det kan användas. Vi

rekommenderar att använda den strukturerade metod som utvecklats av Banks (Banks, 2010)

vid användning av simuleringsprogram.

65

9 Referenser Azadeh, A., Shirkouhi, N., Rezaie, K., 2010, A robust decision-making methodology for

evaluation and selection of simulation software package, International Journal of Advanced

Manufacturing Technology, vol 47, nr 1-4, s 381-393, ISSN 0268-3768 print, 1433-3015

online

Banks, J. et al (2010) Discrete Event System Simulation, USA, Pearson Education, Upplaga 5

Behn, R., 2005, Resistance to Measurement. Public Management Report. vol 3, nr 3

Carton, R. B. (2006) Measuring organizational performance: metrics for entrepreneurship

and strategic management research, Cheltenham, UK; Northampton, MA, Edward Elgar

Publications, ISBN 978-1845426200

Dias, L. et al, 2011, Discrete Simulation Tools Ranking – a Commercial Software Packages

comparison based on popularity, Department of Productions and Systems, University of

Minho, Braga, Portugal

Hlupic, V., 2000, Simulation Software: A Survey of Academic and Industrial Users,

International Journal of Simulation, vol 1, nr 1-2, s 1-11, ISSN 1473-804x online, 1473-8031

print

Hlupic, V., Paul, R., 1999, Guidelines for selection of manufacturing simulation software, IIE

Transaction, vol 31, nr 1, s 21-29, online ISSN 1573-9724

Jadhav, A., Sonar R., 2009, Evaluating and selecting software packages: a review,

Information and Software Technology, vol 51, nr 3, s 555–563

Klingstam, P., Gullander, P., 1999, Overview of simulation tools for computer-aided

production engineering, Computers in Industry, vol 38, nr 2, s 173-186

Liker, J. K. (2004) The Toyota way: 14 management principles from the world's greatest

manufacturer. New York: McGraw-Hill, ISBN 978-0071392310

Mogard, M., von Heijne, G., (2014), Användning av nyckeltal, Key performance indicators,

som underlag till resurseffektivisering av produktion, Examensarbete, KTH, School of

Industrial Engineering and Management (ITM), Production Engineering.

Neely, A. et al (1994) Mapping measures and activities: A practical tool for assessing

measurement association systems. First international conference of the European operations

management association conference, Cambridge, UK, s 313-318

66

Pidd, M., 2010, Why Modelling and Model Use Matter, The Journal of the Operational

Research Society, vol 61, nr 1, s 14-24

Rajabi, A., Lean Leader, GE Healthcare, Personlig intervju, 2015-03-20


Larsson, E., Lean Leader, GE Healthcare, Personlig intervju, 2015-04-10

Rajabi, A., & Larsson, E., båda Lean Leader, GE Healthcare, Personlig intervju, 2015-04-20




Reid, D., Sanders, N. (2010) Operations Management – An Integrated Approach, 4th edition,

International student version, Wiley, ISBN 978-0470325049

Rethink Robotics, Baxter with intera 3, 2015-08-04, http://www.rethinkrobotics.com/baxter/

Saaty, T., 1990, How to make a decision: The analytical Hierarchy Process, European

Journal of Operational Research, vol 48, nr 1, s 9-26

Senge, P., 1997 The Fifth Discipline, Measuring Business Excellence, vol 1, nr 3, s 46-51

Vorne Industries Inc., Theory of Constraints, 2015-06-16, www.leanproduction.com/theory-

of-constraints.html

Womack, J., 2006, Value Stream Mapping, Manufacturing Engineering Magazine, May

edition

Xonitek, The Operational Excellence Manifesto, 2015-09-03, http://www.xonitek.com/press-

room/company-news/the-operational-excellence-manifesto/

Observation av produktionssituation, GE Healthcare, Uppsala, 2015-05-15

67

10 Bilagor

Bilaga 1: Utvärderingsformulär

68

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

USER

1. What kind of previous experience or knowledge/training is required to be working

with your software?

2. In what way would you say that your software is easy to learn?

3. What is the cost for the software?

4. What are the requirements and the recommendations for the pc-hardware?

VENDOR

5. What kind of material do you have for learning? (E.g. user manuals/training

courses/online tutorials)

6. What kind of support do you offer, and does any of these support options cost

anything and if so how much? (E.g. Online chatting/forums/phone support)

7. What other companies use your software now?

8. Do you offer a “run-only” version, where you can´t edit it but you can run the

simulation, for free (or cheaper than full version) ?

9. What kind of maintenance and update services do you provide and how often do they

normally occur?

10. Is there a demo version available for the software?

INPUT AND MODELING

11. Can you describe the way to model, in what way is it easy and intuitive to build?

12. What statistical distributions can be used in the software and can we define a different

distribution by ourselves?

13. What can be customized in the library items in terms of behavior and properties?

14. Can the icons from the library be edited?

15. What kind of help does the software provide for debugging? (E.g. logical error

checks/error handling)

16. What queuing policies are offered? (E.g. FIFO, LIFO, by attribute)

SIMULATION

17. Can data be displayed in graphic charts while the simulation is running?

18. Can you make changes to the model while it´s simulating?

19. Could you send some links to videos that shows the modeling and the simulation?

20. Does the software have the ability to automatically run the model several times and

change the random variables each time to see variations between the different runs?

21. Can the user determine some points of the time for the model to stop or start some

other actions?

22. Does the software have the ability to go through the simulation step by step?

23. Can the simulation start in a “non-empty” state?

OUTPUT

24. What lean tools does the software have for analyzing, controlling and optimizing the

production?

69

25. How can the results be presented? (E.g. histograms, bar charts, pie charts)

26. Can the reports be customized?

27. Can the user choose to only collect steady-state data and statistics?

INTEGRATION

28. Do you offer a network license version?

29. Can you import data from external files and software and if yes, which ones?

30. Is 3D-simulation integrated with the model, or does a new model need to be built just

for 3D-visualization?

31. Can icons be imported from other software packages or libraries (E.g. CAD-objects)?

32. Can data from your software be used by other software (export-function and

integration with other software)?

70

Bilaga 3: Parvis jämförelsematriser

Huvudkriterier

Delkriterier

Huvudkriterier

Use

r

Ven

do

r

Inp

ut

and

Mo

del

ing

Sim

ula

tio

n

Ou

tpu

t

Inte

grat

ion

Norm

Use

r

Ven

do

r

Inp

ut

and

Mo

del

ing

Sim

ula

tio

n

Ou

tpu

t

Inte

grat

ion

Wei

ghts

User 1 7 3 3 1 7

User 0,34 0,27 0,36 0,36 0,34 0,27 32%

Vendor 1/7 1 1/5 1/5 1/7 1

Vendor 0,05 0,04 0,02 0,02 0,05 0,04 4%

Input and Modeling

1/3 5 1 1 1/3 5

Input and Modeling

0,11 0,19 0,12 0,12 0,11 0,19 14%

Simulation 1/3 5 1 1 1/3 5

Simulation 0,11 0,19 0,12 0,12 0,11 0,19 14%

Output 1 7 3 3 1 7

Output 0,34 0,27 0,36 0,36 0,34 0,27 32%

Integration 1/7 1 1/5 1/5 1/7 1

Integration 0,05 0,04 0,02 0,02 0,05 0,04 4%

Sum 1 1 1 1 1 1 100%

Determinant 0,000 Eigenvalue 6,130 CI 0,026 CR 0,021

User

Req

uir

ed

exp

erie

nce

Ease

of

lear

nin

g

Fin

anci

al

Har

dw

are

User

Req

uir

ed

exp

erie

nce

Ease

of

lear

nin

g

Fin

anci

al

Har

dw

are

We

igh

ts

Required experience

1 1/2 3 7

Required experience

0,29 0,27 0,37 0,33 31%

Ease of learning

2 1 4 8

Ease of learning

0,58 0,53 0,49 0,38 49%

Financial 1/3 1/4 1 5

Financial 0,10 0,13 0,12 0,24 15%

Hardware 1/7 1/8 1/5 1

Hardware 0,04 0,07 0,02 0,05 4%

sum 1 1 1 1 100%

Determ 0,000

Eigenvalue 4,120

CI 0,040

CR 0,045

71

Vendor

Trai

nin

g

Sup

po

rt

Ped

igre

e

Ru

n-o

nly

Mai

nte

nan

ce

Vendor

Trai

nin

g

Sup

po

rt

Ped

igre

e

Ru

n-o

nly

Mai

nte

nan

ce

we

igh

ts

Training 1 3 7 6 5

Training 0,54 0,63 0,39 0,44 0,51 50%

Support 1/3 1 5 4 3

Support 0,18 0,21 0,28 0,30 0,31 25%

Pedigree 1/7 1/5 1 1/2 1/3

Pedigree 0,08 0,04 0,06 0,04 0,03 5%

Run-only 1/6 1/4 2 1 1/2

Run-only 0,09 0,05 0,11 0,07 0,05 8%

Maintenance 1/5 1/3 3 2 1

Maintenance 0,11 0,07 0,17 0,15 0,10 12%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,136

CI 0,034

CR 0,031

Input and Modeling

Bu

ildin

g m

od

el

Stat

isti

cal

dis

trib

uti

on

Cu

sto

miz

atio

n

Ico

ns

Deb

ugg

ing

Input and Modeling

Bu

ildin

g m

od

el

Stat

isti

cal

dis

trib

uti

on

Cu

sto

miz

atio

n

Ico

ns

Deb

ugg

ing

We

igh

ts

Building model

1 3 7 8 4

Building model

0,54 0,62 0,40 0,36 0,54 49%

Statistical distribution

1/3 1 5 6 2


0,18 0,21 0,29 0,27 0,27 24%

Customization 1/7 1/5 1 2 1/4

Customization 0,08 0,04 0,06 0,09 0,03 6%

Icons 1/8 1/6 1/2 1 1/5

Icons 0,07 0,03 0,03 0,05 0,03 4%

Debugging 1/4 1/2 4 5 1

Debugging 0,14 0,10 0,23 0,23 0,13 17%

Sum 1 1 1 1 1 100%

Determ 0,000 Eigenvalue 5,170 CI 0,043 CR 0,038

72

Output

Mu

ltip

le r

un

An

alys

is

Stat

isti

cal

grap

hic

s

Rep

ort

Stea

dy-

stat

e

dat

a

Output

Mu

ltip

le r

un

An

alys

is

Stat

isti

cal

grap

hic

s

Rep

ort

Stea

dy-

stat

e

dat

a

We

igh

ts

Multiple run 1 3 6 6 5

Multiple run 0,54 0,62 0,43 0,43 0,50 49%

Analysis 1/3 1 4 4 3

Analysis 0,18 0,21 0,29 0,29 0,30 27%

Statistical graphics

1/6 1/4 1 1 1/2


0,09 0,05 0,07 0,07 0,05 6%

Report 1/6 1/4 1 1 1/2

Report 0,09 0,05 0,07 0,07 0,05 6%

Steady-state data

1/5 1/3 2 2 1

Steady-state data

0,11 0,07 0,14 0,14 0,10 11%

Sum 1 1 1 1 1 100%


Simulation D

isp

lay

feat

ure

s

Sim

ult

aneo

us

mo

del

ing

Vis

ual

ap

pea

ran

ce

Bre

akp

oin

ts

Step

-fu

nct

ion

Star

t in

no

n-

emp

ty s

tate

Simulation

Dis

pla

y fe

atu

res

Sim

ult

aneo

us

mo

del

ing

Vis

ual

ap

pea

ran

ce

Bre

akp

oin

ts

Step

-fu

nct

ion

Star

t in

no

n-

emp

ty s

tate

We

igh

ts

Display features

1 1 2 1/4 1/6 1/2

Display features

0,07 0,08 0,09 0,04 0,08 0,05 7%

Simultaneous modeling

1 1 2 1/4 1/4 1/2


0,07 0,08 0,09 0,04 0,12 0,05 8%

Visual appearance

1/2 1/2 1 1/4 1/7 1/3

Visual appearance

0,03 0,04 0,04 0,04 0,07 0,04 4%

Breakpoints 4 4 4 1 1/4 2

Breakpoints 0,28 0,32 0,17 0,16 0,12 0,21 21%

Step-function 6 4 7 4 1 5

Step-function 0,41 0,32 0,30 0,64 0,50 0,54 45%

Start in non-empty state

2 2 7 1/2 1/5 1


0,14 0,16 0,30 0,08 0,10 0,11 15%

Sum 1 1 1 1 1 1

100%

Determ -0,001 Eigenvalue 6,437 CI 0,087 CR 0,070

73

Programjämförelse för kriteriegruppen User

Required experience

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/5 1/6 1/4 1

Anylogic 0,06 0,05 0,08 0,04 0,06 5,7%

Flexsim 5 1 1/2 2 5

Flexsim 0,29 0,26 0,23 0,31 0,29 27,7%

Simcad pro 6 2 1 3 6

Simcad pro 0,35 0,51 0,46 0,46 0,35 42,8%

Simul8 4 1/2 1/3 1 4

Simul8 0,24 0,13 0,15 0,15 0,24 18,1%

Witness 1 1/5 1/6 1/4 1

Witness 0,06 0,05 0,08 0,04 0,06 5,7%

Sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,081

CI 0,020

CR 0,018

Integration

Net

wo

rk v

ersi

on

Inp

ut

dat

a

Inte

grat

ed 3

D

Inp

ut

ico

ns

Ou

tpu

t d

ata

Integration

Net

wo

rk v

ersi

on

Inp

ut

dat

a

Inte

grat

ed 3

D

Inp

ut

ico

ns

Ou

tpu

t

We

igh

ts

Network version

1 2 6 6 3

Network version

0,46 0,51 0,35 0,35 0,46 43%

Input data 1/2 1 5 5 2

Input data 0,23 0,26 0,29 0,29 0,31 28%

Integrated 3D

1/6 1/5 1 1 1/4

Integrated 3D

0,08 0,05 0,06 0,06 0,04 6%

Input icons 1/6 1/5 1 1 1/4

Input icons 0,08 0,05 0,06 0,06 0,04 6%

Output data 1/3 1/2 4 4 1

Output 0,15 0,13 0,24 0,24 0,15 18%

sum 1 1 1 1 1 100%


74

Financial

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 5 3 1/5 6

Anylogic 0,15 0,29 0,29 0,12 0,26 22,2%

Flexsim 1/5 1 1/4 1/7 3

Flexsim 0,03 0,06 0,02 0,09 0,13 6,6%

Simcad pro 1/3 4 1 1/6 4

Simcad pro 0,05 0,23 0,10 0,10 0,17 13,1%

Simul8 5 7 6 1 9

Simul8 0,75 0,40 0,57 0,62 0,39 54,6%

Witness 1/6 1/3 1/4 1/9 1

Witness 0,02 0,02 0,02 0,07 0,04 3,6%

Sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,428

CI 0,107

CR 0,096

Hardware

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 5 1 1/5 1/6

Anylogic 0,08 0,20 0,08 0,06 0,09 9,9%

Flexsim 1/5 1 1/4 1/7 1/8

Flexsim 0,02 0,04 0,02 0,04 0,06 3,6%

Simcad pro 1 4 1 1/5 1/6

Simcad pro 0,08 0,16 0,08 0,06 0,09 9,1%

Simul8 5 7 5 1 1/2

Simul8 0,38 0,28 0,38 0,28 0,26 31,5%

Witness 6 8 6 2 1

Witness 0,45 0,32 0,45 0,56 0,51 46,1%

Sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,270

CI 0,067

CR 0,061

Ease of learning

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/6 1/4 1/5 3

Anylogic 0,06 0,08 0,04 0,05 0,11 6,8%

Flexsim 6 1 3 2 9

Flexsim 0,37 0,47 0,47 0,52 0,32 43,1%

Simcad pro 4 1/3 1 1/2 7

Simcad pro 0,24 0,16 0,16 0,13 0,25 18,8%

Simul8 5 1/2 2 1 8

Simul8 0,31 0,24 0,31 0,26 0,29 28,1%

Witness 1/3 1/9 1/7 1/8 1

Witness 0,02 0,05 0,02 0,03 0,04 3,3%

Sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,144

CI 0,036

CR 0,033

75

Programjämförelse för kriteriegruppen Vendor

Training

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 4 3 5

Anylogic 0,36 0,36 0,41 0,32 0,29 34,8%

Flexsim 1 1 4 3 5

Flexsim 0,36 0,36 0,41 0,32 0,29 34,8%

Simcad pro 1/4 1/4 1 2 3

Simcad pro 0,09 0,09 0,10 0,21 0,18 13,4%

Simul8 1/3 1/3 1/2 1 3

Simul8 0,12 0,12 0,05 0,11 0,18 11,5%

Witness 1/5 1/5 1/3 1/3 1

Witness 0,07 0,07 0,03 0,04 0,06 5,4%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,189

CI 0,047

CR 0,042

Support

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm A

nyl

ogi

c

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 3 1/3 3 5

Anylogic 0,21 0,29 0,18 0,29 0,24 24,1%

Flexsim 1/3 1 1/5 1 5

Flexsim 0,07 0,10 0,11 0,10 0,24 12,2%


Simcad pro 0,62 0,49 0,53 0,48 0,33 49,1%

Simul8 1/3 1 1/5 1 3

Simul8 0,07 0,10 0,11 0,10 0,14 10,3%

Witness 1/5 1/5 1/7 1/3 1

Witness 0,04 0,02 0,08 0,03 0,05 4,3%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,218

CI 0,054

CR 0,049

Pedigree

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 6 4 3 6

Anylogic 0,52 0,40 0,52 0,60 0,40 48,9%

Flexsim 1/6 1 1/3 1/4 1

Flexsim 0,09 0,07 0,04 0,05 0,07 6,3%

Simcad pro 1/4 3 1 1/2 3

Simcad pro 0,13 0,20 0,13 0,10 0,20 15,2%

Simul8 1/3 4 2 1 4

Simul8 0,17 0,27 0,26 0,20 0,27 23,4%

Witness 1/6 1 1/3 1/4 1

Witness 0,09 0,07 0,04 0,05 0,07 6,3%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,097

CI 0,024

CR 0,022

76

Run-only

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 7 5 3 7

Anylogic 0,55 0,35 0,53 0,64 0,35 48,5%

Flexsim 1/7 1 1/5 1/6 1

Flexsim 0,08 0,05 0,02 0,04 0,05 4,7%

Simcad pro 1/5 5 1 1/3 5

Simcad pro 0,11 0,25 0,11 0,07 0,25 15,8%

Simul8 1/3 6 3 1 6

Simul8 0,18 0,30 0,32 0,21 0,30 26,3%

Witness 1/7 1 1/5 1/6 1

Witness 0,08 0,05 0,02 0,04 0,05 4,7%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,288

CI 0,072

CR 0,065

Programjämförelse för kriteriegruppen Input & Modeling

Building model

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/5 1/3 1/6 3

Anylogic 0,07 0,05 0,04 0,08 0,13 7,3%

Flexsim 5 1 3 1/2 7

Flexsim 0,33 0,27 0,35 0,24 0,29 29,7%

Simcad pro 3 1/3 1 1/4 5

Simcad pro 0,20 0,09 0,12 0,12 0,21 14,7%

Simul8 6 2 4 1 8

Simul8 0,39 0,54 0,47 0,49 0,33 44,5%

Witness 1/3 1/7 1/5 1/8 1

Witness 0,02 0,04 0,02 0,06 0,04 3,7%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,185

CI 0,046

CR 0,042

Maintenance

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 2 1/2 4 5

Anylogic 0,25 0,30 0,23 0,30 0,28 27,2%

Flexsim 1/2 1 1/3 3 4

Flexsim 0,13 0,15 0,15 0,22 0,22 17,5%


Simcad pro 0,51 0,46 0,45 0,37 0,33 42,4%

Simul8 1/4 1/3 1/5 1 2

Simul8 0,06 0,05 0,09 0,07 0,11 7,8%

Witness 1/5 1/4 1/6 1/2 1

Witness 0,05 0,04 0,08 0,04 0,06 5,1%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,098

CI 0,024

CR 0,022

77

Icons

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 2 2 3 2

Anylogic 0,35 0,36 0,36 0,30 0,36 34,9%

Flexsim 1/2 1 1 2 1

Flexsim 0,18 0,18 0,18 0,20 0,18 18,4%

Simcad pro 1/2 1 1 2 1

Simcad pro 0,18 0,18 0,18 0,20 0,18 18,4%

Simul8 1/3 1/2 1/2 1 1/2

Simul8 0,12 0,09 0,09 0,10 0,09 9,8%

Witness 1/2 1 1 2 1

Witness 0,18 0,18 0,18 0,20 0,18 18,4%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,010

CI 0,002

CR 0,002


An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1 1 1

Anylogic 0,20 0,20 0,20 0,20 0,20 20,0%

Flexsim 1 1 1 1 1

Flexsim 0,20 0,20 0,20 0,20 0,20 20,0%


Simcad pro 0,20 0,20 0,20 0,20 0,20 20,0%

Simul8 1 1 1 1 1

Simul8 0,20 0,20 0,20 0,20 0,20 20,0%

Witness 1 1 1 1 1

Witness 0,20 0,20 0,20 0,20 0,20 20,0%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

Customization

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm A

nyl

ogi

c

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/5 1/7 1/4 1/3

Anylogic 0,05 0,04 0,07 0,03 0,03 4,4%

Flexsim 5 1 1/3 2 5

Flexsim 0,25 0,20 0,17 0,26 0,38 25,2%


Simcad pro 0,35 0,61 0,52 0,52 0,38 47,5%

Simul8 4 1/2 1/4 1 2

Simul8 0,20 0,10 0,13 0,13 0,15 14,2%

Witness 3 1/5 1/5 1/2 1

Witness 0,15 0,04 0,10 0,06 0,08 8,7%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,208

CI 0,052

CR 0,047

78

Programjämförelse för kriteriegruppen Simulation

Debugging

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/2 1/3 1 1/3

Anylogic 0,10 0,08 0,11 0,10 0,11 9,9%

Flexsim 2 1 1/2 2 1/2

Flexsim 0,20 0,17 0,16 0,20 0,16 17,6%


Simcad pro 0,30 0,33 0,32 0,30 0,32 31,3%

Simul8 1 1/2 1/3 1 1/3

Simul8 0,10 0,08 0,11 0,10 0,11 9,9%

Witness 3 2 1 3 1

Witness 0,30 0,33 0,32 0,30 0,32 31,3%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,013

CI 0,003

CR 0,003

Display features

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm A

nyl

ogi

c

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/3 1/3 1/2 2

Anylogic 0,11 0,11 0,11 0,09 0,14 11,0%

Flexsim 3 1 1 2 4

Flexsim 0,32 0,32 0,32 0,34 0,29 31,9%


Simcad pro 0,32 0,32 0,32 0,34 0,29 31,9%

Simul8 2 1/2 1/2 1 3

Simul8 0,21 0,16 0,16 0,17 0,21 18,4%

Witness 1/2 1/4 1/4 1/3 1

Witness 0,05 0,08 0,08 0,06 0,07 6,9%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,036

CI 0,009

CR 0,008

Visual appearance

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1 2 5

Anylogic 0,27 0,27 0,27 0,28 0,25 26,7%

Flexsim 1 1 1 2 5

Flexsim 0,27 0,27 0,27 0,28 0,25 26,7%


Simcad pro 0,27 0,27 0,27 0,28 0,25 26,7%

Simul8 1/2 1/2 1/2 1 4

Simul8 0,14 0,14 0,14 0,14 0,20 14,9%

Witness 1/5 1/5 1/5 1/4 1

Witness 0,05 0,05 0,05 0,03 0,05 4,9%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,027

CI 0,007

CR 0,006

79


An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/3 1/7 1/3 1/3

Anylogic 0,06 0,04 0,08 0,04 0,04 5,2%

Flexsim 3 1 1/5 1 1

Flexsim 0,18 0,12 0,11 0,12 0,12 13,0%


Simcad pro 0,41 0,60 0,57 0,60 0,60 55,7%

Simul8 3 1 1/5 1 1

Simul8 0,18 0,12 0,11 0,12 0,12 13,0%

Witness 3 1 1/5 1 1

Witness 0,18 0,12 0,11 0,12 0,12 13,0%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,071

CI 0,018

CR 0,016

Breakpoints

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1 1 1

Anylogic 0,20 0,20 0,20 0,20 0,20 20,0%

Flexsim 1 1 1 1 1

Flexsim 0,20 0,20 0,20 0,20 0,20 20,0%


Simcad pro 0,20 0,20 0,20 0,20 0,20 20,0%

Simul8 1 1 1 1 1

Simul8 0,20 0,20 0,20 0,20 0,20 20,0%

Witness 1 1 1 1 1

Witness 0,20 0,20 0,20 0,20 0,20 20,0%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

Run simulation by step

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 5 1 1

Anylogic 0,24 0,24 0,24 0,24 0,24 23,8%

Flexsim 1 1 5 1 1

Flexsim 0,24 0,24 0,24 0,24 0,24 23,8%

Simcad pro 1/5 1/5 1 1/5 1/5

Simcad pro 0,05 0,05 0,05 0,05 0,05 4,8%

Simul8 1 1 5 1 1

Simul8 0,24 0,24 0,24 0,24 0,24 23,8%

Witness 1 1 5 1 1

Witness 0,24 0,24 0,24 0,24 0,24 23,8%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

80

Programjämförelse för kriteriegruppen Output

Optimizer

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/5 1/5 1 1

Anylogic 0,08 0,08 0,08 0,08 0,08 7,7%

Flexsim 5 1 1 5 5

Flexsim 0,38 0,38 0,38 0,38 0,38 38,5%


Simcad pro 0,38 0,38 0,38 0,38 0,38 38,5%

Simul8 1 1/5 1/5 1 1

Simul8 0,08 0,08 0,08 0,08 0,08 7,7%

Witness 1 1/5 1/5 1 1

Witness 0,08 0,08 0,08 0,08 0,08 7,7%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

Lean tools

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1/7 1/4 1

Anylogic 0,07 0,07 0,09 0,04 0,07 6,8%

Flexsim 1 1 1/7 1/4 1

Flexsim 0,07 0,07 0,09 0,04 0,07 6,8%


Simcad pro 0,50 0,50 0,61 0,74 0,50 57,1%

Simul8 4 4 1/5 1 4

Simul8 0,29 0,29 0,12 0,15 0,29 22,6%

Witness 1 1 1/7 1/4 1

Witness 0,07 0,07 0,09 0,04 0,07 6,8%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,137

CI 0,034

CR 0,031


An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1 1 1

Anylogic 0,20 0,20 0,20 0,20 0,20 20,0%

Flexsim 1 1 1 1 1

Flexsim 0,20 0,20 0,20 0,20 0,20 20,0%


Simcad pro 0,20 0,20 0,20 0,20 0,20 20,0%

Simul8 1 1 1 1 1

Simul8 0,20 0,20 0,20 0,20 0,20 20,0%

Witness 1 1 1 1 1

Witness 0,20 0,20 0,20 0,20 0,20 20,0%

sum 1 1 1 1 1 100%


81


An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/3 1/3 1 3

Anylogic 0,12 0,12 0,12 0,12 0,18 13,0%

Flexsim 3 1 1 3 5

Flexsim 0,36 0,35 0,35 0,36 0,29 34,2%


Simcad pro 0,36 0,35 0,35 0,36 0,29 34,2%

Simul8 1 1/3 1/3 1 3

Simul8 0,12 0,12 0,12 0,12 0,18 13,0%

Witness 1/3 1/5 1/5 1/3 1

Witness 0,04 0,07 0,07 0,04 0,06 5,6%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,056

CI 0,014

CR 0,013

Report

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm A

nyl

ogi

c

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1 1 1

Anylogic 0,20 0,20 0,20 0,20 0,20 20,0%

Flexsim 1 1 1 1 1

Flexsim 0,20 0,20 0,20 0,20 0,20 20,0%


Simcad pro 0,20 0,20 0,20 0,20 0,20 20,0%

Simul8 1 1 1 1 1

Simul8 0,20 0,20 0,20 0,20 0,20 20,0%

Witness 1 1 1 1 1

Witness 0,20 0,20 0,20 0,20 0,20 20,0%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

Steady-state data

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1 1 1

Anylogic 0,20 0,20 0,20 0,20 0,20 20,0%

Flexsim 1 1 1 1 1

Flexsim 0,20 0,20 0,20 0,20 0,20 20,0%


Simcad pro 0,20 0,20 0,20 0,20 0,20 20,0%

Simul8 1 1 1 1 1

Simul8 0,20 0,20 0,20 0,20 0,20 20,0%

Witness 1 1 1 1 1

Witness 0,20 0,20 0,20 0,20 0,20 20,0%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

82

Programjämförelse för kriteriegruppen Integration

Network Version

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 5 7 5

Anylogic 0,39 0,39 0,41 0,30 0,41 38,1%

Flexsim 1 1 5 7 5

Flexsim 0,39 0,39 0,41 0,30 0,41 38,1%

Simcad pro 1/5 1/5 1 4 1

Simcad pro 0,08 0,08 0,08 0,17 0,08 9,9%

Simul8 1/7 1/7 1/4 1 1/4

Simul8 0,06 0,06 0,02 0,04 0,02 3,9%

Witness 1/5 1/5 1 4 1

Witness 0,08 0,08 0,08 0,17 0,08 9,9%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,180

CI 0,045

CR 0,041

Input data

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/3 1/3 1/3 1

Anylogic 0,09 0,09 0,09 0,09 0,09 9,1%

Flexsim 3 1 1 1 3

Flexsim 0,27 0,27 0,27 0,27 0,27 27,3%


Simcad pro 0,27 0,27 0,27 0,27 0,27 27,3%

Simul8 3 1 1 1 3

Simul8 0,27 0,27 0,27 0,27 0,27 27,3%

Witness 1 1/3 1/3 1/3 1

Witness 0,09 0,09 0,09 0,09 0,09 9,1%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

Integrated 3D

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1/2 1/2 3 4

Anylogic 0,18 0,17 0,17 0,19 0,30 20,0%

Flexsim 2 1 1 5 4

Flexsim 0,36 0,34 0,34 0,31 0,30 32,9%


Simcad pro 0,36 0,34 0,34 0,31 0,30 32,9%

Simul8 1/3 1/5 1/5 1 1/2

Simul8 0,06 0,07 0,07 0,06 0,04 5,9%

Witness 1/4 1/4 1/4 2 1

Witness 0,04 0,08 0,08 0,13 0,07 8,3%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,099

CI 0,025

CR 0,022

83

Input icons

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 1 1 1 1

Anylogic 0,20 0,20 0,20 0,20 0,20 20,0%

Flexsim 1 1 1 1 1

Flexsim 0,20 0,20 0,20 0,20 0,20 20,0%


Simcad pro 0,20 0,20 0,20 0,20 0,20 20,0%

Simul8 1 1 1 1 1

Simul8 0,20 0,20 0,20 0,20 0,20 20,0%

Witness 1 1 1 1 1

Witness 0,20 0,20 0,20 0,20 0,20 20,0%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

Output data

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

Norm

An

ylo

gic

Flex

sim

Sim

cad

pro

Sim

ul8

Wit

nes

s

We

igh

ts

Anylogic 1 2 2 2 2

Anylogic 0,33 0,33 0,33 0,33 0,33 33,3%

Flexsim 1/2 1 1 1 1

Flexsim 0,17 0,17 0,17 0,17 0,17 16,7%

Simcad pro 1/2 1 1 1 1

Simcad pro 0,17 0,17 0,17 0,17 0,17 16,7%

Simul8 1/2 1 1 1 1

Simul8 0,17 0,17 0,17 0,17 0,17 16,7%

Witness 1/2 1 1 1 1

Witness 0,17 0,17 0,17 0,17 0,17 16,7%

sum 1 1 1 1 1 100%

Determ 0,000

Eigenvalue 5,000

CI 0,000

CR 0,000

84

Bilaga 4: Information om Simcad pro Simcad Pro är ett väldigt kraftfullt simuleringsprogram. Det kan användas för många olika

områden, så som lagerhus & distributionscenter, supply chain logistik, kontor, mat & dryck,

och tillverkning & produktion. Eftersom vårt fokus ligger på produktion kommer vi skriva om

de viktigaste egenskaperna programmet har för det området.

Viktiga fördelar med Simcad Pro

Flaskhals och begränsningsanalys

Man kan väldigt enkelt hitta flaskhalsarna. Programmet kan skapa en detaljerad rapport med

information om begränsningarna och de bidragande faktorerna. Man kan även analysera

vilken effekt produktionen får om man ändrar på utrustningen som används och/eller om man

investerar i ny teknik, inklusive automatiserade utrustningar.

Omfattande leananalys

Programmet har omfattande lean analysverktyg. Det går att dynamiskt få fram value stream

map. Spaghetti diagram, färgdiagram, Swim Lanes, effektivitet och OEE analys (Overall

Equipment Effectiveness) (på svenska UTE (Utrustningens Totala Effektivitet)).

Optimeringsfunktioner

Optimera modellen medan simuleringen körs

Resurs- och utrustningsoptimering

Optimering av arbetsorder/schema

Dynamisk-Interaktiv Optimering

Scenarioanalys

Monte Carlo simulation (en klass av algoritm

som används för att simulera olika matematiska

och fysiska system)

Rapporter

Standardiserade rapporter

Anpassade rapporter

Scenario rapporter

Affärsrapporter

Anpassat prestationsmått

85

Dynamisk simulering

När simuleringen körs kan man bygga vidare på modellen. Det går att analysera vilka

påverkningar som uppkommer när man gör förändringar i modellen. Denna funktion är dock

begränsad. Det går att bygga in nya element och ändra på dem och deras beteende, men det

går inte att radera något element då simuleringen körs. För att radera ett element måste man

först stoppa simuleringen och sedan radera elementet.

Patenterad modellerings miljö som inte kräver kodning

Försäljaren utlovade att ingen programmering krävs för att simulera. Det stämmer till viss del.

Till de flesta enklare modeller krävs ingen programmering men när man ska modellera allt

mer komplexa modeller krävs kodning. Men man behöver ingen erfarenhet av något

kodningsspråk för man lägger in koden grafiskt. I deras program finns en kodningssida där du

får välja olika funktioner och villkor från en lista. Så man behöver ändå ha

programmeringstänket när man bygger komplexa modeller.

Omfattande anslutning till de flesta datasystem

Obegränsat antal externa anslutningar för importera eller exportera data. Man kan ansluta till

dessa datasystem före, under eller efter simuleringen. Den importerade informationen kan

t.ex. analyseras med den inbygga scenario managern. Du kan även välja att exportera ut data

till Excel eller till datasystem

Modellen i realtid

Createasoft som erbjuder Simcad Pro

erbjuder även SimTrack, med Simtrack

kan du ansluta modellen till

direktsända datasystem (Radio-

frequency identification (RFID), PLC

(av engelska Programmable Logic

Controller), GPS (förkortning av

Global Positioning System)). Eftersom

modellen är kopplad till produktionens

direktsända datasystem kan man utföra

nya prognoser utefter vad som sker på

plats i produktionen. Händer något

oväntat kan man därför utföra nya

prognoser/scheman.

Detaljrik

Man kan modellera upp produktionslinor i minsta detalj. Du kan inkludera setup-time,

processing time, downtime, traveltime. Du kan anpassa alla dessa tider beroende på typ av

objekt, operatör eller någon tillsatt variabel. Med hjälp av programmets inbyggda funktioner,

såsom eventhandler och tiggers så kan du modellera mycket komplexa modeller. Du kan

tillsätta villkor, och när dessa villkor uppfylls så ska en annan utvald process köras igång.

86

Varians, köteori

Man kan manuellt räkna ut hur långt tid det tar att producera/bearbeta ett ämne, du kan få

fram ledtider och hur mycket som produceras per timme osv. Men då har man räknat med

medelvärden och att operatörerna alltid jobbar i exakt den takten. I verkligheten så arbetar inte

människor lika snabbt hela tiden, de är inga robotar. Det kan variera ganska mycket.

Variansen på hur operatörerna arbetar bildar olika långa kötider. Detta påverkar ledtider och

hur mycket bufferstorlekar man behöver och hur mycket som produceras per timme.

Modellering i Simcad Pro

Uppbyggandet av modellen sker med hjälp av ett antal byggblock som finns tillgängliga.

Start Process: Skapar/genererar de objekt som ska gå igenom modellen. Objekt kan

skapas baserat på tidsintervall, fördelningar eller planeringsfiler importerade från

Excel.

Interprocess Connection/Connection Line: Objekten i modellen färdas längs

connection lines. Dessa binder ihop de olika byggblocken så att objekt kan

förflyttas mellan dem. Kan modifieras för att efterlikna ett löpande band

Generic Process: Detta är den enklaste och mest generiska typen av processblock i

Simcad Pro. Det kan användas för att simulera en arbetsstation eller maskin i en

produktionssmiljö. Den kan ges cykeltid, setuptid och kan även modifiera och ändra

ett objekt. Blocket är väldigt anpassningsbart och kan simulera många olika typer av

beteenden.

Join Process: Används för att simulera en monteringsprocess. Två eller flera typer

objekt leds in till processen för att monteras till ett nytt objekt.

Router Process: Detta block används för att styra flödet i modellen. Flöden av

objekt kan ha flera alternativa in- och utvägar ur blocket, där regler kan sättas upp

för hur objekten ska gå vidare enligt till exempel en viss fördelning eller vilken

av efterkommande processer som är tillgänglig.

Jump Process: Tillåter ett objekt att hoppa från ett block till ett annat utan att det

finns en connection line mellan dem. Används oftast för att modellera

undantagsregler.

87

End Process: Används som ett avslutande block för att avlägsna objekt från

simuleringen. Avslutningsblocket räknar hur många objekt som har gått igenom och

objektens livstid.

Image Process Holder: Detta block har ingen effekt på modellens funktionalitet utan

används endast för att visa en ikon eller bild. Till exempel kan en planritning över

produktionen läggas in som en image process holder som ligger bakom övriga block.

Results Process: Används för att visa textvärden eller grafer över olika parametrar i

modellen. Värdena kan uppdateras dynamiskt medan simuleringen körs.

Utöver dessa byggblock kan man även definiera olika typer av objekt, de produkter och

material som flyttas runt i modellen genom processerna. Resurser kan också definieras och

fungerar som operatörer.

88

Bilaga 5: Information om Collaborative robot Ett sätt för företag att förbättra och effektivisera sin produktion är genom automation - att låta

en maskin utföra ett arbete istället för manuellt arbete av en mänsklig operatör. Maskiner har

länge använts för att ersätta mänsklig arbetskraft. Några av fördelarna maskiner har är att de

kan göra vissa arbetsuppgifter mycket snabbare utan att behöva vila, de blir inte uttråkade av

ensidiga arbetsuppgifter, de kan vistas i miljöer som är skadliga för människor, samt kan en

investering i en maskin bli billigare än att ha en operatör anställd om maskinen kan utföra

motsvarande arbetsuppgifter.

En robot är en maskin som ofta används i industrin för att

automatisera arbetsuppgifter och operationer. En sådan så

kallad industriell robot (IRB) har oftast en arm som kan röra sig

i flera frihetsgrader likt en människoarm. De kan utföra många

typer av operationer inom tillverkning, målning och montering.

En ny typ av robot är det som kallas för Collaborative Robot

(Cobot). En cobot är enklare och billigare än andra mer

klassiska IRB. Tanken är att de ska kunna arbeta tillsammans

med operatörerna (därav collaborative). Vanliga IRB medför

några problem, till exempel kräver vissa en skyddsbur runt för

att skydda operatörer från att skadas av de höga krafter roboten

använder sig av. En Cobot är mycket säkrare eftersom den inte

har lika höga krafter, vilket förvisso begränsar dess hastighet och lyftkapacitet. Den är också

utrustad med sensorer som gör att rörelsen stoppas om den kommer i kontakt med något.

Detta gör att Coboten kan arbeta tillsammans med männsikor och de kan på så vis

komplettera varandra. Människan utför operationer som är svåra att automatisera medan

roboten kan utföra olika uppgifter som är påfrestande både fysiskt och psykiskt för

operatören. En annan fördel med Coboten är att den är otroligt lätt att installera och sätta

igång. En IRB kräver vanligtvis ganska mycket installation och programmering för att få den

att utföra önskad arbetsuppgift. Coboten ”programmeras” istället genom att armarna flyttas

fysiskt till den plats de ska greppa, släppa eller utföra något och man byggar på så vis upp

beteendet steg för steg. Priset är också relativt lågt för att vara en robot, en Cobot kan fås för

25 000 $ medan en IRB kan kosta betydligt mer (Rethink Robotics).

Date post:	18-Sep-2018
Category:	Documents
Upload:	phunghanh
View:	226 times
Download:	0 times

Simuleringsverktyg för optimering av produktion - …861356/FULLTEXT01.pdf · Simuleringsverktyg...

Documents