Produkt/process-matrisen (Olhager 2000)

Processtyp\Produkttyp I. låg volym, ej standard, en-styck II. låg volym, många pro- dukter III. hög volym, få stora pro- dukter IV. hög volym, standard, dagligvara I. Fast position Fartyg

II. Funktionell verkstad Tung utrustning

III. Flödesgrupper Truckar

IV. Lina Mikrovågsugnar

V. Kontinuerlig tillverkn-

ing Olja

Kontinuerlig tillverkning

Inom kontinuerlig tillverkning mäter man inte produkter i styck, utan i meter, liter, ton eller liknande. Tillverkningen sker i stora volymer av ofta lågvärdiga varor där den stora investeringen ligger i stora och dyra maskiner. Ett införande av en produkt kan innebära att en helt ny masikn måste införskaas då maskinerna som används ofta är helt utformade för en specik produkt och inta kan användas till andra produkter. Tillverkningen fokuserar oftast på en typ av industri, till expempel papper, men produkterna kan däremot ofta erbjudas i många olika dimensioner och varianter. Inom kontinuerlig tillverkning åternns också metallindustrin och oljeindustrin.(Olhager 2000)

Sammantaget nns de olika produktionsprocesserna återskapade i en produkt/process-matris, se tabell 3.1.

Kundorderpunkten

Kundorderpunkten är den punkt där ett företag övergår från att producera mot lager till att producera mot kundorder. Den är förlagd på olika ställen beroende på vilken typ av produkt som tillverkas. Man kan generellt säga att ju mer en kund har att säga till om vad gäller utformningen av en produkt, desto längre bak i kedjan är kundorderpunkten förlagd. Detta illustreras av gur 3.6.

Man kan till exempel se att ett företag som har kontinuerlig tillverkning oftast har en kundorderpunkt som ligger efter slutlagret, medan ett företag som arbetar efter fast position har en kundorderpunkt före konstruktion och inköp. (Olhager 2000)

3.4 Logistiksystemet

Här nedan presenteras ytterligare några centrala delar inom logistiksystemet som kommer att behand- las i den här rapporten.

Ett funktionsorienterat företag kontra ett processorienterat företag

Det nns en konikt mellan att ha eektiva funktioner(till exempel avdelningar) och att ha eektiva processer i ett företag. Det som är bra för hela processen kan innebära att en viss funktion kan bli

3. Teoretisk referensram 25

Fig. 3.6: Kundorderpunktens placering beroende på typ av produktionsprocess

(Olhager 2000)

lidande och motsvarande kan optimering för varje enskild funktion skilja sig, och gör oftast, från det optimala för hela processen.(Aronsson m. 2004)

Ett funktionsorienterat företag är ett företag där varje enskild avdelning, maskin eller annan funktion arbetar utefter egna mål om till exempel kostnadseektivisering och maximalt utnyttjande av sina resurser. Detta gör att man arbetar som ett enskilt företag där avdelningen före är leverantör och avdelningen efter är kund, utan något närmare samarbete. Det här är det klassiska sättet att arbeta på inom ett företag.(Aronsson m. 2004)

Detta arbetssätt kan dock innebära en rad problem. Bland annat är mellanlager vanligt mellan funk- tionerna och dessa tenderar att bli onödigt höga då varje avdelning ser till att ha en extra buert för att gardera sig mot störningar och eventuellt medföljande "`negativa"' siror. Eftersom att ingen blir ansvarig för helheten i företaget tenderar också ansvaret för en produkt att sluta i det ögonblicket den överlämnas till nästa avdelning. Detta ökar risken för att produkter till expempel försvinner eller får fel information. Ett funktionstänkande skapar dessutom en slags konkurrens mellan avdelningarna där företagets bästa kommer i skymundan till fördel för att enskilda avdelningar exempelvis håller sin egen beläggning så hög som möjligt.(Aronsson m. 2004)

Motsatsen till ett funktionsorienterat företag är ett processorienterat företag där man fortfarande har kvar enskilda funktioner men mellanlagren helt eller delvis har eliminerats. Istället för att se sig själva som enskilda företag fokuserar alla funktioner på en gemensam synlig slutkund. Budgetmålen är gemensamma för hela företaget och lager räknas i totallager över hela ödet. Istället för att optimera för varje enskild funktion eller en enskild produkt, optimeras hela ödet och alltså hela företaget. Figur 3.7 är en illustration av skillnaden mellan ett funktionsorienterat företag och ett processorienterat företag.(Aronsson m. 2004)

Utveckling av en integrerad försörjningskedja

Under 1990-talet gjordes ett försök med att få företag att gå över från funktionsorienterade till pro- cessorienterade. Utfallet blev att företagen i snitt reducerade sina ledtider med 43 procent, ökade produktiviteten med 39 procent och ökade vinstmarginalen med 8 procent.(Aronsson m. 2004) Man har identierat fyra steg i processen att utvecklas från ett funktionsorienterat företag till ett processorienterat företag. Dessa illustreras i g 3.8.

3. Teoretisk referensram 26

Fig. 3.7: Skillnaden mellan ett funktionsorienterat företag och ett processorienterat företag, fritt efter

(Aronsson m. 2004)

Fig. 3.8: Utvecklingen av en integrerad försörjningskedja, fritt efter

(Aronsson m. 2004)

• Lager nns på era ställen inom företaget på grund av bristande integration. • Varje avdelning har sitt eget informations- och styrsystem.

• Olika avdelningar styr varsin del av ödet, ofta med "`vattentäta skott"' eller "`murar"' mellan sig.

3. Teoretisk referensram 27

(Aronsson m. 2004)

Många företag benner sig på den här nivån och karaktäriseras av produktion mot lager, där varje avdelning kan planera fritt utan hänsyn till andra avdelningar. Ofta är lagerna för stora men ändå råder en dålig leveransservice då det sällan nns rätt produkter som nns i lagret.(Aronsson m. 2004) Utvecklingen i de efterföljande nivåerna består i att successivt slå samman olika funktioner inom före- taget och att minska onödiga mellanlager och onödigt höga lagernivåer. Företaget inför ett integrerat informationssystem som är samma för alla delar av ödet och som syftar till att öka kommunikationen mellan avdelningarna. När företaget arbetar efter ett processtänkande kan det gå till nivå fyra som även involverar leverantörer och kunder i det nya tänkandet. Här går företaget över till en kundori- entering där fokus på kundens behov och krav ska vara styrande för hur företaget agerar. (Aronsson m. 2004)

Logistikröret och trånga sektorer

Ett företags kapacitet är sällan jämnt över hela ödet. För att på ett enkelt och överskådligt sätt illustrera detta kan man använda sig av ett så kallat "`logistikrör"', se gur 3.9 och gur 3.10. Det fungerar så att själva röret symboliserar företaget där komponenter förs in i ena änden och färdiga produkter kommer ut i den andra. Längden på röret är den totala genomloppstiden för produkten och diametern är avdelningens kapacitet det innebär exempelvis att ett smalt rör släpper igenom färre produkter.(Aronsson m. 2004)

Fig. 3.9: Ett logistikrör med jämn kapacitet, fritt efter

(Aronsson m. 2004)

Målet för ett företag är att ha en så jämn kapacitet som möjligt, enligt gur 3.9. Verkligheten är dock oftast att kapaciteten varierar över kedjan och efterliknar därför mer gur 3.10. Genom att göra en sådan här illustration kan man identiera avdelningar som har överkapacitet eller avdelningar som är trånga sektorer och alltså begränsar kapaciteten för hela företaget. Det går också att se om det nns någon sektion i ödet som har för lång genomloppstid. Med det här verktyget syns var resurser för förbättring bör läggas och om vissa funktioner bör avskaas helt och hållet. (Aronsson m. 2004)

3. Teoretisk referensram 28

Fig. 3.10: Ett logistikrör med ojämn kapacitet, fritt efter

(Aronsson m. 2004)

3.5 Produktionsstyrning

Här nedan presenteras ett antal utvalda teorier vad gäller produktionsstyrning. Dessa är valda utifrån de scenarion som presenteras i kapitel 6.7 och ska fungera som ett teoretiskt stöd till experimenterin- gen.

3.5.1 Teorin om begränsning

Goldratts Teori om begränsning (eng. Theory of constraints) går ut på att identiera begränsningen i ett system, askhalsen, och fokusera på den. Alla andra delar av systemet blir underordnade askhalsen tills den är åtgärdad. När detta här gjort ökas kapaciteten på askhalsen tills det att en ny askhals uppstår och denna askhals hanteras på samma sätt. På så sätt kan man successivt arbeta sig igenom ett system och hitta en jämn kapacitet.(Olhager 2000)

3.5.2 Jämnt resursutnyttjande

Denna produktstyrningsloso bygger på Lean production och syftar till att hålla en jämn takt och ett jämnt öde genom produktionen. Detta för att minska onödiga stopp i maskinerna. För mer detaljer se avsnitt 3.1.

3.5.3 Specialisering

Denna metod syftar till att minska antal ställ för maskinerna. Varje byte av produkttyp och dimension kräver ett ställ av maskinen som tar tid och därmed innebär en kostnad för företaget. Om man istället specialiserar likvärdiga maskiner på en speciell produkt eller produkter som använder samma typ av ställ, kan ställtiderna minskas och produktionen öka. Nedan íllustreras hur ställtider kan reduceras med denna metod.(Olhager 2000)

3. Teoretisk referensram 29

Total tid utan specialicering:

t = s1+ p1+ s2+ p2+ s3+ p3

Total tid med specialisering:

t = s1+ p1+ p2+ p3

s1−3= St¨alltid f ¨or varje produkttyp

p1−3= P roduktionstid f ¨or varje produkttyp

Här syns tydligt att produkttyper som kräver omställ ger en längre total produktionstid än om de använder samma ställ.

3.5.4 Minimal hantering

Denna metod bygger också på Lean production där onödiga hanteringssteg identieras och elimineras. Det kan till exempel handla om onödiga transporter mellan produktionslinjer eller procedurer som skulle kunna uteslutas helt. Se avsnitt 3.1 för mer information.

3.6 Simulering

Detta avsnitt går igenom hur ett simuleringsprojekt bör läggas upp. Avsnittet behandlar också olika typer av silmulering samt in- och utdataanalys.

3.6.1 Modeller

En modell är en förenklad representation av verkligheten. Det är viktigt att tänka på att en modell aldrig kan vara en perfekt återgivning av verkligheten utan alltid innebär en förenkling. Modeller är of- tast baserade på teoretiska principer och lagar. Enligt Alan och Pritsker, (1998) underlättas modellbyg- gandet om det nns matematiska pinciper som angår systemet (isättet för mänskiligt beslutsfattande), om det går att göra en grask representation av systemet samt om osäkerheten i indata, komponenter och utdata är kvantierbara. Dessa kriterier passar sällan in på större mer komplexa system där det är svårt att identiera grundläggande fysikaliska principer, där slumptal är en signikant del av systemet samt där mänskligt beslutsfattande påverkar systemet. De innehåller även ofta policybaserade beslut vilka är svåra att kvantiera.(Alan, Pritsker 1998)

3.6.2 Simulering som verktyg

Simulering har blivit ett vanligt verktyg för att lösa problem. Simulering har blivit synonymt med datoriserad simulering och det är därför det vi kommer att diskutera i det här avsnittet av rapporten. Det nns några olika typer av simulering.

• Statisk och dynamisk. I en dynamisk modell beror modellens beteende av tiden. Dynamiska modeller används ofta då tidsaspekter nns i systemets uppförande exempelvis säsongsvariation- er och liknande. Statiska modeller beter sig alltid på samma sätt och används för exempelvis försörjningskedjor.

3. Teoretisk referensram 30

• Kontinuerlig och diskret. Vid diskret, eller händelsestyrd, simulering sker förändringar momen- tant i specika tidpunkter. Kontinuerliga system ändras kontinuerligt.

• Deterministisk och stokastisk. Deterministiska modeller har ingen slumpvariation. Där är alla värden kända på förhand. Det innebär att man alltid kommer att få samma utdata ur modellen, oberoende av hur många replikationer man kör. I en stokastisk modell har indata modellerats som fördelningar vilket gör att man kan få med variationer i processtider, ankomster, kötider och liknande. Stokastiska modeller ger olika utdata vid olika replikationer. (Oakshott 1997)

Enligt Oakshott (1997) kan följande kriterier användas för att avgöra vilken typ av simulering man bör använda för sitt simuleringsprojekt.

• Om man har ett statiskt system skall man använda så kallad Monte-Carlo-simulering, en simu- lering baserad på slumptal. Monte-carlosimulering kommer inte att diskuteras vidare i den här rapporten.

• Om man har ett dynamiskt och kontinuerligt system skall kontinuerlig simulering användas. • Om man har ett dynamiskt och diskret system skall händelsestyrd simulering används.

I resten av avsnittet kommer det sistnämnda alternativet diskuteras då det är det enda som är relevant för den här rapporten. För motivering se avsnitt 6.

Ett simuleringsprojekt kan delas in i fem faser. • Problemformulering • Insamling av data • Modellbyggnad • Experimentering • Analys av utdata (Oakshott 1997)

Figur 3.11 visar en schematisk bild av hur ett simuleringsprojekt går till från planering till imple- mentering.

Fig. 3.11: Schematisk bild av hur ett simuleringsprojekt går till

3. Teoretisk referensram 31

3.6.3 Problemformulering

Den fösta fasen består i att formulera problemet samt utreda om simulering är ett lämpligt verktyg för problemet, eller om det nns andra verktyg som skulle kunna ge ett bättre resultat eller vara mer kostnadseektivt. Simulering är inte ett självklart val för att lösa problem och det bör utredas om de problem man vill bahandla är lämpliga. Det kan nnas enklare metoder för att lösa problemet. Det behöver även bestämmas typ av simuleringsmodell som ska skapas och vilken programvara som kan vara mest lämplig för projektet. En projektplan med tillhörande målsättning, tidsplan och budget bör också göras för att kunna styra projektet på ett bra sätt. (Persson 2001)

Redan under planeringsfasen bör problemet avgränsas ordentligt för att det inte ska bli för komplext. Det är ingen risk att problemet avgränsas för mycket i det här skedet då det är lättare att utöka modellen senare än att avgränsa under modellbyggandets gång.(Oakshott 1997) Under planeringsfasen ska de parametrar som ska studeras denieras och det är också bra att få en uppfattning om hur dessa kommer att påverka projektets målsättning.(Persson 2001)

3.6.4 Datainsamling

För att kunna få en bra representation av systemet behöver modellen baseras på stora mängder data. För att få en stokastisk modell modelleras indata till stokastiska fördelningar. Detta görs med hjälp av indatamodellering.(Law, McCommas 2001)

För att kunna få tillfredställande fördelningar behövs mycket data, därför är datainsamling en be- tydande del av ett simuleringsprojekt. Vid indataanalys är det viktigt att data är IID (independent and identically distributed). IID innebär att varje unikt värde i datamängden inte beror av andra värden i samma datamängd. Antagandet om att en datamängd är IID är en vanlig förenkling in- om statistiken, även om det i praktiken är orealistiskt med en helt oberoende datamängd.(Law, McCommas 2001)

Det nns era programvaror för indataanalys, i vilka data läses in och kontrolleras mot statistiska fördelningar. Fördelningarna analyseras sedan med χ2_{-test och Kolmogorov-Smirnov-test som testar}

hur väl datan passar in i fördelningsfunktionen. Både Kolmogorov-Smirnov-test och χ2_{-test används}

för att se hur mycket de framtagna värdena skiljer sig från fördelningens förväntade värden. Med dessa test undersöks hur passande hur väl den valda fördelningen stämmer överens med värden som samlats in.(Law, McCommas 2001)

Som för de esta system gäller det att se till att indatan är korrekt och att den data som nns är rätt för att kunna lösa problemet. Ett vanligt uttryck inom modellering är "`garbage in, garbage out"' (GIGO) vilket innebär att om inte datan in i modellen är korrekt kommer inte heller resultatet att vara användbart.(Law, McCommas 2001)

3.6.5 Modellbyggnad

När ett system ska modelleras bör en konceptuell modell av systemet skapas. En konceptuell modell är en logisk bild av ödet där beslutsprocesser, logiska komponenter och principer nns representerade. Den konceptuella modellen används för att veriera att ödet avbildas korrekt och är viktig för att underlätta själva modellbyggandet.(Persson 2001)

Med en konceptuell modell kan modellbyggarens bild av systemet kontrollera och den kan och bör även valideras av beställaren. Genom att göra en konceptuell modell baserad på systemets strukturella komponenter kan scheman, algoritmer och kontrollsystem identieras. Dessa beslutskomponenter är

3. Teoretisk referensram 32

oftast den svåraste delen av modelleringen.(Alan, Pritsker 1998)

När den konceptuella modellen är färdig och verierad är det dags att börja modellbyggandet. För att modellera ett system måste modellbyggaren förstå strukturen och principerna som styr systemet. Avgörande frågor för allt modellbyggande är till exempel vilka förenklingar som kan göras och vilka detaljer som behöver tas med för att inte kompromissa med resultatet.(Persson 2001)

För att underlätta modellbyggandet nns det ett par saker som bör beaktas. 1. Skapa skräddarsydda indata, procedurer och gränssnitt

2. Dela upp modellen i relativt små logiska komponenter

3. Skapa och upprätthåll tydlig dokumentation direkt i modellen

4. Skapa en öppen modell, där komponenter kan läggas till för högre detaljgrad (Alan, Pritsker 1998)

3.6.6 Veriering och validering

Veriering görs för att kunna kontrollera att modellen fungerar som den ska. Med veriering kan moduler som inte fungerar upptäckas och åtgärdas, systemet avbuggas. Ett vanligt sätt att veriera modeller är att skicka in en enskild entitet i modellen och följa dess väg. Veriering är relativt enkelt jämfört med validering men det blir svårare ju större modellen är. I veriering ingår också att kon- trollera hur modellen uppför sig för extrema indata. Finns det problem i modellen så syns de tydligare om "`systemet stressas"' genom att till exempel alldeles för många entiteter skickas in. Mindre system kan även byggas för att testa varje modul för sig. Fungerar modulerna var för sig så är det inte svårt att kontrollera att de samverkar som de ska.(Law, McCommas 2001)

Validering av modellen görs för att säkerställa att modellen svarar på rätt frågeställning. Eftersom en modell är en förenkling av verkligheten och aldrig kan stämma till 100 procent behöver man kontrollera modellens tillförlitlighet. En modell av ett system ger bara tillförlitliga resultat för den frågeställning som den är byggd och validerad för. En vanlig valideringsmetod är att använda kända indata och se om utdatan kan förutsägas. Law och McCommas (2001) beskriver en sjustegsmetod som syftar till att bygga en valid modell. I den metoden läggs stor vikt vid den konceptuella modellen, som valideras för sig innan modellbygget fortsätter. Metoden lägger även stor vikt vid att frågeställningen måste vara exakt och genomtänkt och att systemet bör analyseras noggrant för att inga viktiga faktorer ska förbigås.(Law, McCommas 2001)

3.6.7 Experimentering

För att kunna dra slutsatser av en simuleringsmodell används experimentering. Ett experiment består av följande komponenter.

• Indata  Scenario  Parameterval

3. Teoretisk referensram 33

• Simulerad tid • Antal replikationer • Utdata

(Persson 2001)

Scenario och parameterval är skillnaderna mellan de olika experimenten. Genom att parametrar och scenarion ställs om kommer systemet att bete sig olika. Efter det kan skillnaderna mellan de olika experimenten analyseras.(Persson 2001)

Uppvärmningstiden är till för att starta upp modellen. Ofta är endast systemets steady-state-läge in- tressant och då måste systemet hinna starta upp innan datainsamling kan påbörjas.(Persson 2001) Ett experiment består av att modellen körs med en viss parameterinställning och ett visst antal replika- tioner. Det vill säga era körningar med samma inställningar men med olika slumptal. Flera replika- tioner minskar eekten av slumpmässiga variationer . Figur 3.12 visar hur standardavvikelsen varierar med antalet replikationer. (Persson 2001)

Fig. 3.12: Hur standardavvikelsen varierar med antalet replikationer

(Persson 2001) 3.6.8 Analys av utdata

För att kunna dra korrekta slutsatser av experimenteringen är det viktigt att granska utdatan med hjälp av statistiska test. Detta för att avgöra om resultatet är statistiskt signikant.(Alexopoulos, Seila 1998)

Utdataanalys är en analys av den data som genereras av simuleringen. Behovet av statistisk analys av utdata kommer från att olika körningar av modellen använder olika slumptalsfrön för indata. För att veta om resultatet av simuleringen beror på modellens uppbyggnad och inte på variationer i slump- talsföljden måste en utdataanalys göras.(Alexopoulos, Seila 1998)

För att göra den statistiska analysen beräknas medelvärde och varians för utdatan i de olika replikation- erna. Variansen går mot noll då antalet replikationer ökar. Baserat på dessa värden kan ett kondensin- tervall tas fram. Kondensintervallet tas fram med hjälp av medelvärde och varians hos dataföljden. Dessa används sedan i ett hypotestest med hjälp av t-fördelningen.(Alexopoulos, Seila 1998)

3. Teoretisk referensram 34 formel medelvärde ˆ X = 1 n n X i=1 Xi formel varians ˆ σ = var( ˆX) = 1 n − 1 n X i=1 ( ˆX − Xi)2 där Xi

är utdatan för replikation i // [ ˆX]rmedelvrdetavutdatan//[σ]rvariansenhostalf ljden// T-fördelningen ˆ X − tα 2,fσ ≤ X ≤ ˆˆ X + t α 2,fˆσ α = s¨akerhetsniv ˙a = 100(1 − α) f = f rihetsgrad = n − 1

Kondensintervall är ett intervall i vilket ett visst värde åternns med en viss procents säkerhet. Vanliga kondensintervall är 95 och 99 procents intervall Kondensintervallet kan exempelvis plockas fram med hjälp av ett så kallat t-test som är ett statistiskt hypotestest med fördelar som att det fungerar bra även vid små urval.(Alexopoulos, Seila 1998)

3.6.9 Arena

Arena är ett av de stora simuleringsverktygen på marknaden. Arena är en modulbaserad programvara för diskreta simuleringsmodeller. Arenamodeller byggs upp med hjälp av block som representerar olika operationer och detta innebär att det är enkelt att komma igång med enkla modeller. Arena har även fördelen att användaren under hela körningen graskt kan följa vad som händer i modellen, vilket gör modellen relativt enkel att validera och veriera.(Alexopoulos, Seila 1998)

4. PROBLEMFORMULERING

• Utifrån informationen i tidigare kapitel och önskemål från handledare har vi formulerat följande problem:

• Hur ser nuläget ut på Avesta Jernverk utifrån teoretiska analysmetoder och analys av observerade problem?

• Vilka problem (höga lagernivåer, informationsbrister, trånga sektorer och så vidare) kan Avesta Jernverk möta i och med investeringen, Projekt 2015 och hur kan dessa hanteras?

• Vilka blir konsekvenserna (vad gäller utlevererade produkter, max- och medellager, leveranssäk- erhet och tid i system) för ödet år 2015 vid följande simuleringsscenarion?