Paketeringsmöjligheter

gen ett enkelt graskt verktyg för utformning av etiketter och dokument, som kan användas i samråd med kunden.

7.3 Paketeringsmöjligheter

Den systemutveckling som görs vid implementering av WMS kan klassiceras i två olika kategorier:

• Integration avser utveckling av gränssnitt mellan WMS och andra mjukvarusystem. Vanligast är kommunikationsgränssnitt mot ERP- system.

• Lagerhantering innefattar utveckling i syfte att anpassa systemet till kundens materialhantering. Här inkluderas exempelvis transitlös- ningar, etikettanpassningar och regler för bäst före hantering.

De båda områdena kan i vissa fall överlappa varandra men är relativt väl åtskilda.

7.3.1 Integration

Integrationspunkterna för ett WMS kan vara många, ERP, automation och LMS är bara några exempel. Varje implementering kräver sin egen anpass- ning av integrationen. Detta tar tid och ställer stora krav på testning. In- tegrationsarbetet kräver även ett samarbete mellan WMS-leverantören och leverantören av det system som skall integreras. Detta kan resultera i miss- förstånd och även innebära intressekonikter då många ERP-system tillhan- dahåller egna WMS-moduler och därmed inte vill ersätta dessa med externa leverantörers.

En lösning som kan förenkla integrationen och lyfta den del av imple- menteringsarbetet som ligger längst från WMS leverantörens verksamhet, kan vara att samarbeta med en leverantör av middleware. Genom att skapa en färdig integration med ett middleware kan installationer hos nya kunder ske med endast mindre modieringar av gränssnitten. Det blir även enklare att ansluta era system till samma WMS-installation. En nackdel kan vara att ytterliggare en part blir inblandad i projekten. Det är viktigt att inte låsa sig till partnern utan låta kunderna välja huruvida de vill använda möj- ligheten. Fördelarna skall vara en snabbare och säkrare implementering, inte nödvändigtvis billigare.

7.3. PAKETERINGSMÖJLIGHETER Samarbetspartner för middleware måste väljas med omsorg. Middleware nns på många olika nivåer och det gäller att lägga sig på en nivå som erbjuder tillräcklig anslutbarhet och säkerhet utan att vara för komplicerad.

7.3.2 Lagerhantering

Trots att det inom många branscher nns stora likheter i lagerhanteringen är branschspecika paketeringar ingen lösning ur ett systemtekniskt perspek- tiv. Många funktioner används av företag i olika branscher och även om vissa funktioner kan klassiceras som t.ex. byggspecika så är skillnaderna i lager- hanteringen för stora även mellan företag med snarlik verksamhet. Risken med branschspecika paketeringar är att systemet blir svårt att anpassa och att problem uppstår då ett bygglager efterfrågar funktionalitet som nns in- om t.ex. livsmedelspaketet. Framförallt kommer funktioner som är oanvänd- bara för många företag i en bransch ändå att behöva ingå i branschpaketet. Ett WMS bör istället vara exibelt och bestå av moduler som var och en styr funktionaliteten inom ett visst område. Detta ställer höga krav på tydliga standarder vid nyutveckling och en enhetlig systemstruktur med t.ex. kompositmönstret som ledstjärna. Det skall inte krävas kännedom om hela systemets uppbyggnad för att kunna ansluta en ny modul. Modulerna bör heller inte vara beroende av varandra och var modul skall kunna anslutas separat.

Dokumentation

För att användning av moduler skall kunna ske smidigt måste deras funk- tion och design vara väl beskriven. Systemutvecklaren skall ha möjlighet att snabbt ta reda på om en modul med önskad funktion existerar eller om en liknande modul kan modieras för att passa kundens önskemål. Dokumenta- tionen måste därmed vara lätt att hitta genom någon form av eektiv sök- struktur. Standardiserade system för namngivning kan underlätta både vid sökning och arkivering av moduler. För varje modul bör följande information vara tillgänglig:

• Funktionell specikation - Beskriver modulens praktiska funktion ur ett logistikperspektiv. Systemteknisk information bör i största möjliga mån undvikas. Det väsentliga är vad modulen gör, hur den används och i vilka sammanhang.

• Teknisk specikation - Beskriver hur modulen är implementerad ur ett systemtekniskt perspektiv. Bör läggas på en högre abstraktionsnivå än

7.3. PAKETERINGSMÖJLIGHETER • Anslutningsanvisning - Anger hur modulen kopplas ihop med andra

moduler eller ansluts till systemkärnan.

I idealfallet, då en modul kan användas utan modiering, behövs således endast förståelse för modulens funktion (den funktionella specikationen) och hur den kopplas till det övriga systemet (anslutningsanvisningen). Då utveck- ling av modulen krävs kan den tekniska specikationen ge en grundförståelse för hur klasser och metoder samverkar.

För att strukturen skall fungera och vara möjlig att underhålla måste in- formation om vilken anpassning som används av vilken kund knytas samman i ett register. På så sätt kan berörda kunder identieras och uppdateras då en bugg i en anpassning upptäckts och åtgärdats. Buggxar behöver då en- dast göras en gång per modul och endast de kunder som använder modulen behöver uppdateras.

Anslutning

Genom att använda kompositmönstret enligt SOA kan förändringar i sys- temkärnan undvikas. En avskiljning kan åstadkommas m.h.a. ett anslut- ningslager (se gur 7.1) som fungerar som en länk mellan systemkärnan och anpassningsmodulerna. Klasserna i anslutningslagret nns alltid med men är passiva då ingen anpassning är ansluten. Då en anpassning däremot exister- ar skickar klassen i anslutningslagret data vidare till en eller era anpass- ningsmoduler. På så sätt resulterar de esta ändringar i anrop från kärnan endast i modiering av enkla anslutningsklasser. Anpassningslagret kan in- nehålla en mängd anpassningar i ett bibliotek. Endast de anpassningar som används hämtas ner till implementeringen.

Figur 7.1: Schematisk bild över hur kommunikationen mellan standard och anpassningar i ett WMS kan fungera.

I vissa fall kan utveckling av hela anslutningsbara moduler vara över- ödig. Enklare anpassningar på bara ett par rader kod kan tänkas placeras

7.3. PAKETERINGSMÖJLIGHETER direkt i anslutningsklasserna för att förenkla hierarkin. Dessa anpassningar bör samlas i ett register där koden enkelt kan sökas upp för användning vid nya implementeringar. På grund av de mindre anpassningarnas överblickbara natur är kraven på teknisk dokumentation inte lika höga som för moduler. Dock bör en kort funktionell beskrivning samt information om i vilken anslut- ningsklass koden skall placeras i nnas tillgänglig.

Utveckling

Vidareutveckling av WMS är nästan uteslutande kunddriven. En viss funk- tionalitet utvecklas endast om efterfrågan nns hos en eller era kunder och om utvecklingskostnaderna är rimliga. I syfte att möjliggöra återvinning av kod bör varje färdigställd modul arkiveras i ett SOA-bibliotek. Modulen kan sedan återanvändas med eventuell modiering nästa gång den efterfrågas. Generiska lösningar för alla typer av specialanpassningar är dock svårt att erhålla då utvecklingen är tidskrävande och förutsätter väl inarbetade rutiner och designmönster. Vilka moduler som skall utvecklas är en avvägning mellan de förväntade kostnadsbesparingarna och utvecklingskostnaderna. För min- dre frekventa funktioner blir kostnadsbesparingarna för små och pay-back tiden för lång. avsnitt 7.1 ger en indikation om vilka funktioner som är mest efterfrågade samt inom vilka branscher de är aktuella. Huruvida kostnader- na för utveckling av moduler för dessa funktioner över- eller underskrider besparingarna går utanför detta examensarbetes gränser. Dock kan påpekas att för CL utgör kostnaderna för den kundspecika utvecklingen (exklusive integrationsutveckling) närmare en femtedel av den totala kostnaden per pro- jekt. Det är den största enskilda kostnadsposten och onödigt programmer- ingsarbete, till följd av rigid systemarkitektur eller bristfällig dokumentation, är en dyr aär.

Parametrar vs. anpassningar

Parametrar är något som bör användas för att styra både standardfunktioner och anpassningar för att dessa skall passa varje verksamhet. De kan användas för att löpande justera hur systemet fungerar och för att trimma funktion- erna. Anpassningarna däremot ger nya funktioner och logiska lösningar. Det är därför en viktig skillnad mellan parametrar och anpassningar och båda typerna behövs för att uppnå ett exibelt system.

Anpassning av moduler

7.3. PAKETERINGSMÖJLIGHETER en färdig modul och påbörja utveckling utifrån denna. Med standardmod- uler förenklas både testning och uppgradering samt nya installationer. Dock kräver utveckling av generiska moduler en stor initial arbetsinsats.

Komplikationer

Det nns två stora problem med att skapa standardiserade moduler. Det första är att modulerna i viss mån måste kunna anpassas efter olika före- tags behov. Vilka dessa anpassningsmöjligheter skall vara måste fastställas redan då modulen skapas, något som kan vara svårt eftersom det kräver en insyn i hur olika företags verksamheter skiljer sig. Hänsyn måste även tas till nuvarande såväl som potentiella framtida kunders verksamheter.

Det andra problemet uppkommer då WMS måste kommunicera med före- tagens andra system, främst ERP-systemet med vilket det huvudsakliga in- formationsutbytet sker. Olika ERP-system innebär olika förutsättningar och det är inte säkert att systemen går att anpassa så att de passar förutsät- tningarna för en standardmodul i WMS. Ett tydligt exempel här är kit- tningsmodulen som kräver extra data från ERP-systemet för att fungera. Det är inte säkert att denna data kan skickas från ERP-systemet vilket in- nebär att WMS måste kunna utföra ytterliggare steg. En standardmodul för kittning måste således vara utvecklad för att smidigt kunna anpassas efter era tänkbara scenarier. Både teknisk och funktionell dokumentation måste nnas tillgänglig för att komponenter skall kunna återanvändas och modi- eras på ett eektivt sätt.

Beroenden

Olika moduler skall helst vara helt oberoende. På samma sätt bör olika funk- tioner i standard också vara oberoende. Detta är ett idealfall som i många fall inte är möjligt att realisera. Det är därför viktigt att kontinuerligt arbeta med att minska beroenden mellan olika funktioner, såväl i standard som i anpassningar. De beroenden som nns, och behöver nnas kvar, måste doku- menteras i en systemkarta. Dokumentationen är nödvändig då nyutveckling skall göras men ännu viktigare vid testning. Med väl dokumenterade beroen- den förenklas arbetet med att skapa testfall och de test som behöver utföras kan utföras. Med dokumenterade beroenden skapas en säkerhet för vilka test som behöver utföras och dessa blir då enklare att konstruera samtidigt som onödiga test kan undvikas.

Kapitel 8

Slutsats

För både ERP-system och renodlade WMS innebär en exibel systemarkitek- tur stora konkurrensfördelar och ekonomiska vinster. Kundernas överlevnad bygger på ett ständigt förändringsarbete i syfte att dierentiera och eek- tivisera sina respektive verksamheter. WMS bör fungera som ett stöd, inte som en bromsande eller begränsande faktor, för utveckling av de logistiska processerna. WMS måste således eektivt kunna anpassas till olika typer av lagerverksamhet. Detta ställer höga krav på en välplanerad systemarkitektur samt god kännedom om hur lagerhantering fungerar idag, och hur processer- na kan förändras i framtiden.

Analysen innehåller en sammanställning av de lagerhanteringsfunktioner vi anser vara signikanta för de olika branscherna. Dessa är lämpliga att utgå ifrån då en ny implementering projekteras. Listan bör fortlöpande komplet- teras då ny funktionalitet efterfrågas och kan på så vis ge en heltäckande branschöversikt för varje systemleverantör.

Några rena branschpaketeringar förespråkar vi inte då skillnaderna inom branscherna är för stora. För att branscherna skall bli tillräckligt homogena för paketeringar krävs en så smal indelning att de esta systemleverantörer bara har ett par kunder i varje bransch. Detta resulterar i att vinsten med en systemmässig paketering försvinner. Istället bör de specialanpassade funk- tioner som utvecklats samlas i ett bibliotek där de kan återanvändas vid andra projekt, oavsett bransch. Kundspecika funktioner kan anslutas till systemet som moduler via ett anslutningslager. Detta innebär en separering av de olika modulerna och systemkärnan, vilket förenklar uppdatering och leder till att eventuella buggar kan isoleras till en del av systemet. Modulerna måste vara generiska vilket kräver framförhållning, god planering och tydliga riktlinjer för hur systemutvecklingen skall ske. Enklare funktioner som implementeras på olika sätt hos olika kunder kan placeras direkt i anslutningsklasserna och arkiveras i ett kodregister.

8.1. VINSTER För att återanvändning och uppdatering skall fungera krävs noggrann dokumentation samt ett bibliotek från vilket önskad information snabbt kan uppsökas och hämtas. Det tar längre tid att skapa generiska moduler än att skriva anpassningar för endast en kund. För att denna tid skall kunna tas igen krävs att nästa projekt som kräver en motsvarande anpassning snabbt kan hitta den och inkorporera den på ett tidigt stadium. För att kunna testa nya moduler och anpassningar i gamla moduler krävs även att beroenden mellan moduler och mellan moduler och standard dokumenteras.

Slutsatsen bygger alltså på en SOA-liknande struktur för att kunna åter- använda tidigare utfört arbete. I mindre företag kan funktioner kommuniceras muntligt och dokumentationen glöms av. Det är dock av yttersta vikt att dokumentationen är fullständig för att arbetet skall löpa smidigt. Extra vik- tigt blir detta när era företag använder samma kod. Annars riskerar en bug- gx i en modul att uppfattas som en bugg på ett företag som implementerat modulen i tron att den skall fungera som den gjort med buggen.

Ur ett marknadsföringsperspektiv kan resultatet av examensarbetet an- vändas som riktlinjer för vilken funktionalitet som prioriteras av företag i en viss bransch. God kännedom om kundens behov kan innebära ett övertag i en försäljningssituation och även om ingen systemmässig paketering före- språkas nns det inget som hindrar att en ktiv branschpaketering används i marknadsföringssyfte.

8.1 Vinster

De direkta utvecklingskostnaderna för att anpassa WMS efter olika kun- ders anspråk utgör i genomsnitt ca 20% av implementationsprojektets totala kostnad, se gur 5.3. Genom att återanvända samma anpassningar hos era kunder kan kostnaden för en specik anpassning minska redan första gången den återanvänds. Minskad risk för dubbelarbete och ökad återanvändning av kod är kanske de tydligaste fördelarna med den föreslagna lösningen. Men systemet kan även bidra till kostnadsreduceringar inom andra delar av pro- jekten.

Uppsättning och installation kan underlättas till följd av att många mod- uler har installerats tidigare och det nns tydlig dokumentation om hur de skall anslutas och i vilka sammanhang de används. Projektgruppen slipper gissa hur olika moduler och funktioner fungerar. När buggar upptäcks i ko- den behöver de bara rättas en gång och sedan distribueras till de kunder som använder modulen. Underhållsarbetet blir således betydligt enklare och eektivare. Systemet kan även reducera tiden för testning. Detta till följd av att de moduler och kodsegment som hämtas från biblioteket respektive

8.2. KOSTNADER kodregistret, redan är testade och implementerade hos en eller era kunder. Många moduler bygger således på väl beprövade lösningar och eventuella buggar har i de esta fall redan upptäckts och åtgärdats.

Ett modulbaserat system kan även generera marknadsföringsmässiga fördelar. Det skapas, ut mot kund, branschpaket som visar att WMS- leverantören arbetar aktivt med kundens bransch. Det blir också enklare för säljarna att veta vad företag i olika branscher efterfrågar.

8.2 Kostnader

Utveckling av generiska moduler och underhåll av kodregister och bibliotek tar tid. För att register och bibliotek skall fungera måste koden dokumenteras bättre än då den bara används hos en kund. Anpassningar som läggs in i bib- lioteket men bara implementeras hos en kund kommer därför att bli dyrare än en direkt kundanpassning. Däremot bör det räcka med att koden återanvänds en gång för att dessa extrakostnader skall täckas. Här krävs löpande beslut om vilka anpassningar som endast skall gälla för kund, vilka som skall läggas i bibliotek och register och vilka som skall tillhöra standardfunktionaliteten. Det är av stor betydelse att den kod som katalogiseras för eventuell an- vändning i framtiden, testats för olika scenarier och att dess funktion är verierad. Buggar i biblioteket eller kodregistret kan snabbt spridas till era olika företag. Det är därför viktigt att hålla reda på hos vilka kunder bib- liotekets funktioner har implementerats.

8.3 Fortsatt forskning

Utveckling av WMS och aärssystem är dyrt och många företag väljer därför att, istället för att anpassa systemet till en för företaget optimal logistikstyrn- ing, begränsa logistiklösningen till vad systemet klarar av. Det är därför av yttersta vikt att skapa förståelse för olika verksamheters behov och utveckla nya metoder för utveckling av agila och generiska WMS, som snabbt kan anpassas efter kundernas önskemål.

Inom området systemarkitektur nns mycket skrivet och forskning pågår kontinuerligt. SOA lyfts, av de esta författare, fram som ett framtidens designmönster med stora möjligheter till utveckling. Rapporter om använd- ning av SOA vid utveckling av WMS nns. Den stora majoriteten litteratur handlar dock om SOA för aärssystem.

WMS-branschen är en växande marknad och än så länge nns lite forskn- ing inom området. Särskilt begränsad kunskap nns inom optimering av ma-

8.3. FORTSATT FORSKNING terialhantering samt hur algoritmer för sådan kan implementeras i en sys- temmiljö. Det är överhuvudtaget svårt att hitta bra litteratur på ämnet och den som nns ingår ofta som enstaka kapitel i böcker om lagerstyrning eller logistik. Än nns mycket att göra inom lagrens väggar och besparingarna för företagen kan vara stora.

Vår studie av hur lagerhantering fungerar i olika branscher är absolut inte fullständig. En djupare penetration med er undersökta företag och branscher kan ge en klarare bild av exakt vilka anpassningar som behövs och vilken branschindelning som är lämplig. Vidare är vår lösning för systemmässig planering bara enkla riktlinjer som kan fördjupas och speciceras betydligt grundliggare.

Bilaga A

Akronymlista

3PL Third party logistics

AGV Automated Guided Vehicles ASN Advance Shipment Notice CDC Customer Distribution Center CL Consafe Logistics

DC Distribution Center

EDI Electronic Data Interchange EMEA Europe, Middle East and Africa ERP Enterprise Resource Planning FCFS First Come First Served (FIFO) FEFO First Expire First Out

FIFO First In First Out

ISIC International Standard Industrial Classication JIT Just In Time

LCFS Last Come First Served (LIFO) LE Längdenhet

LIFO Last in First Out

LTH Lunds Tekniska Högskola MHO MaterialHanteringsOmråde PLC Programmable Logic Control SOA Service Oriented Architecture SSCC Serial Shipping Container Code TMS Transportation Management System TPL Se 3PL

VMI Vendor Managed Inventory WMS Warehouse Management System

Bilaga B

Enkätresultat

I tabell B.1 redovisas resultaten från den enkät som har genomförts på Con- safe Logistics. Enkäten har skickats till kundansvariga eller till personer med speciell kännedom om kundernas lager. För varje kund har angivits om funk- tionen används eller är önskvärd. Endast svaren Ja eller Nej har fått anges och svarsfrekvensen är 100 %. Resultaten redovisas av sekretessyfte per bran- sch och i procent ja-svar.

Branscherna förkortas enligt följande:

3PL - Tredjepartslogistik By - Bygg Ke - Kemi Ko - Kontor Li - Livsmedel Lä - Läkemedel De - Detaljhandel Ve - Verkstad

Funktion 3PL By Ke Ko Li Lä De Ve To Debiteringsunderlag ,33 ,00 ,00 ,00 ,00 ,00 ,00 ,00 ,02

Order entry modul ,33 ,08 ,00 ,17 ,09 ,00 ,00 ,00 ,08

Middleware ,67 ,62 ,00 ,33 ,64 ,00 ,50 ,33 ,50 Specialetiketter 1,0 ,77 1,0 ,83 ,91 1,0 ,88 1,0 ,88 LMS ,67 ,08 ,00 ,00 ,00 ,50 ,00 ,00 ,08 Orderkonsolidering ,67 ,62 ,50 ,83 ,73 ,50 ,63 ,67 ,67 Kabelmodul ,00 ,31 ,00 ,00 ,00 ,00 ,00 ,00 ,08 Shop order ,67 ,38 ,50 ,17 ,18 ,00 ,00 ,67 ,27 Certikat ,00 ,77 ,00 ,00 ,00 ,00 ,00 ,67 ,25 Serienummer ,33 ,85 ,00 ,00 ,00 ,50 ,25 ,33 ,33 Transit ,33 ,92 ,50 ,50 ,55 1,0 ,13 ,33 ,56 Automation ,33 ,77 1,0 ,00 ,00 1,0 ,13 ,67 ,38 YMS ,00 ,00 ,00 ,00 ,00 ,00 ,00 ,00 ,00 SSCC ,00 ,54 1,0 ,17 ,45 ,50 ,25 ,00 ,38 Emballagespårning ,33 ,38 ,00 ,67 ,09 ,50 ,00 ,00 ,25 Bäst före hantering ,67 ,23 1,0 ,00 1,0 ,50 ,25 1,0 ,50 Särskilld kölogik ,50 ,30 ,50 ,60 ,91 ,50 ,40 ,33 ,53 Upp/ompackning in ,67 ,85 1,0 ,67 ,73 1,0 ,50 ,33 ,71 Restr. packning ut ,33 ,23 1,0 ,00 ,36 1,0 ,13 ,67 ,31 Voice ,33 ,31 ,00 ,00 ,18 ,50 ,13 ,00 ,19 Spårning av gods ,67 ,85 ,00 ,50 ,91 1,0 ,75 ,33 ,73 Spärrning 1,0 ,92 1,0 1,0 1,0 1,0 1,0 ,67 ,96 Parti (batch) ,67 ,54 1,0 ,00 1,0 ,50 ,25 1,0 ,58 Ankomstkontroll ,33 ,54 ,00 ,67 ,73 ,50 ,38 ,67 ,54 Överplock ,67 ,77 ,00 ,67 ,18 ,00 1,0 ,33 ,56 Viktplock ,00 ,23 ,00 ,00 ,27 ,50 ,00 ,67 ,19 Crossdocking 1,0 ,23 ,00 ,33 ,45 ,50 ,00 ,33 ,31 CDC och DC ,33 ,46 ,00 ,33 ,09 ,00 ,50 ,00 ,29 Totalt ,46 ,48 ,36 ,30 ,41 ,46 ,29 ,39 ,40

Litteraturförteckning

[1] Ahl, Göran - Johansson, Per (2002). Tredjepartslogistik: Principer för ökad lönsamhet. CKM, Stockholm.

[2] Axsäter, Sven (1991). Lagerstyrning. Studentlitteratur, Lund.

[3] Axsäter, Sven - Olsson, Fredrik - Tydesjö, Patrik (2007). Handling Direct Upstream Demand in Multi-Echelon Inventory Systems. International Journal of Production Economics, 108:266270.

[4] Banker, Steve (2008). Warehouse Management Systems Worldwide Out- look. ARC Advisory Group.

[5] Berglund, Magnus (1997). Third-party logistics providers. Doktor- savhandling, Linköpings universitet.

[6] Bertholdi III, John J. - Hackman, Steven T. (Augusti 2008). Warehouse & Distribution Science Release 0.89. http://www2.isye.gatech.edu/~jjb/wh/book/editions/wh-sci-0.89.pdf, hämtad 2008.09.17.

[7] Bowersox, Donald J. - Closs, David J. - Cooper, M. Bixby (2007). Sup- ply chain logistics management. McGraw-Hill Irwin, New York, andra utgåvan.

[8] Coulouris, George - Dollimore, Jean - Kindberg, Tim (2001). Distributed Systems - Concepts and Design. Addison-Wesley, Harlow, tredje utgå- van.

[9] Fagerudd, Joakim - Jönsson, Henrik (2007). Evaluation of Bucket brigades - A next generation order picking strategy. Examensarbete, Lund Institute of Technology, Lund University.

LITTERATURFÖRTECKNING [11] Gamma, Erich - helm, Richard - Johnson, Ralph - Vlissides, John (1995). Design Patterns - Elements of Reusable Object-Oriented Soft- ware. Addison-Wesley, Reading.