Analysis of processes and use of Microsoft Madeleine Hübinette Examensarbete inom teknik och management, grundnivå Kandidat Degree Project in Engineering and Management, First Level Stockholm, Sweden 2012 Kurs IK120X, 15hp TRITA-ICT-EX-2012:292
Innehållsförteckning Sammanfattning Det här examensarbetet har utförts på uppdrag av Logica part of CGI och i samarbete med deras kund Thermoprodukter. Syftet med arbetet är att undersöka om Thermoprodukters verkliga processer stämmer överens med Microsoft Process Flows. Genom att först göra en analys av Microsoft Process Flows har den tänkta arbetsprocessen identifierats. Sedan har Thermoprodukters processer identifierats samt ritats upp i ett flödes- schema. För att slutligen kunna jämföra processerna och få ut ett resultat om dessa stämmer överens eller inte. Resultatet visar att processerna stämmer bra överens med varandra men att det självklart finns skillnader då Thermoprodukter har en del specialbyggda moduler. Nyckelord: Affärssystem, Kartläggning, Flödesschema, Inköpsprocess, Försäljningsprocess, Lagerprocesser ii
Innehållsförteckning Abstract This thesis has been carried out on behalf of Logica part of CGI and in cooperation with their customer Thermoprodukter. The purpose of this work is to analyze whether Thermoprodukter s actual processes is consistent with Microsoft Process Flows. By first doing an analysis of Microsoft Process Flows, the ideal processes have been identified. Then Thermoprodukter s actual processes was identified and drawn up in a flow diagram. Eventually a comparison was carried out between these processes. The results show that the processes are consistent with one another but naturally there are differences due to the fact that Thermoprodukter have some custom built modules. Keywords: ERP, Mapping, Flowchart, Purchasing process, Sales pro- cess, Inventory process iii
Innehållsförteckning Förord Först och främst vill jag tacka min bättre hälft Patriq Ramdert samt min familj och vänner som stöttat mig under arbetets gång. Ett stort tack till min handledare Martin Jinnelöv på Logica part of CGI för att jag fick möjligheten att genomföra mitt examensarbete hos er. Anders Sjöö, Patrik Hovenäs och Per Henemo på Thermoprodukter för att ni ville vara delaktiga i genomförandet. Jag vill tacka Johan Persson för korrekturläsning av rapporten. Sist men inte minst vill jag tacka min examinator Anders Sjögren som gett mig idéer och uppslag på hur jag ska lägga upp min rapport. Kalmar, november 2012 Madeleine Hübinette iv
Innehållsförteckning Innehållsförteckning Sammanfattning... ii Abstract... iii Förord... iv Terminologi... 7 1 Inledning... 8 1.1 Företagsbeskrivning... 8 1.2 Företagsbeskrivning av kunden... 8 1.3 Bakgrund och problemmotivering... 8 1.4 Avgränsningar... 9 1.5 Konkreta och verifierbara mål... 9 1.6 Bidrag till rapporten... 9 2 Affärssystem... 10 2.1 Vad är ett affärssystem... 10 2.2 Historisk utveckling... 11 2.3 Processdefinition... 12 2.3.1 Uppdelning av processer... 12 2.3.2 Kartläggning av processer... 13 2.4 Microsoft... 13 3 Metod... 14 3.1 Arbetsmetod... 14 3.2 Tillvägagångssätt... 14 3.2.1 Planering... 14 3.2.2 Förstudie... 14 3.2.3 Utförande... 15 3.2.4 Dokumentation... 15 3.3 Verktyg... 15 4 Konstruktion... 16 4.1 Thermoprodukters inköpsprocess... 16 4.2 Thermoprodukters försäljningsprocess... 17 4.3 Thermoprodukters lagerprocess... 18 4.4 Funderingar från Thermoprodukter... 20 4.5 Microsoft Process Flows Purchasing... 21 v
Innehållsförteckning 4.6 Microsoft Process Flows Sales... 23 4.7 Microsoft Process Flows Warehousing... 24 5 Resultat... 28 5.1 Inköpsprocessen... 28 5.2 Försäljningsprocessen... 29 5.3 Lagerprocessen... 29 5.4 Lösningförslag på Thermoprodukters funderingar... 30 6 Slutsats och diskussion... 32 6.1 Reliabilitet och validitet... 32 6.2 Egna reflektioner... 33 Källförteckning... 34 Bilaga A: Microsoft Process Flows Purchasing... 35 Bilaga B: Microsoft Process Flows Sales... 48 Bilaga C: Microsoft Process Flows Warehousing... 59 Bilaga D: Processkarta över Thermoprodukters processer... 80 vi
Inledning Terminologi Förkortningar och akronymer Best practice Riktlinjer för bästa sätt att utföra en viss aktivitet MRP MRPII ERP EAI SOA ANSI Material Requirements Planning Manufacturing Resource Planning Enterprise Resource Planning Enterprise Application Integration Service Oriented Architecture American National Standards Institute 7
Inledning 1 Inledning I det här kapitlet kommer en beskrivning om Logica part of CGI samt Thermoprodukter. Vidare kommer bakgrunden, syftet, avgränsningar samt mål med arbetet beskrivas. 1.1 Företagsbeskrivning Det här arbetet har utförts på uppdrag utav Logica part of CGI. Här är en kort beskrivning om företaget från starten 1969 till idag 2012. 1969 startade WM- data sitt första kontor i Stockholm, deras första kund blev Svenska Esso. Åren går och 2006 förvärvar LogicaCMG WM- data, 2008 byter WM- data namn till Logica. I augusti 2012, samtidigt som det här arbetet startar, går beslutet igenom att Logica har blivit uppköpta av det kanadensiska företaget CGI. Logica, det internationellt ledande IT- tjänsteföretag som erbjuder verksamhetsinriktade konsulttjänster, systemintegration och outsour- cing till sina kunder runt om i världen [1] heter numera Logica part of CGI och har 72 000 medarbetare i mer 40 än länder. 1.2 Företagsbeskrivning av kunden Thermoprodukter är ett familjeföretag som grundades 1983. Idag jobbar 10 personer på företaget som är beläget i Kalmar och det omsätter 40 miljoner SEK om året. Thermoprodukter är ett av de ledande företagen inom marinbranschen på tekniska produkter framförallt för komforten ombord på båten, bland annat säljer de kyl- och frysboxar, varmvatten- beredare och gasolspisar [2]. 1.3 Bakgrund och problemmotivering Många gånger händer det att företag inte har full koll på hur de effek- tivast använder sitt affärssystem, vilket till exempel kan bero på bris- tande kunskap inom företaget eller att nyanställd personal på företaget inte har fått tillräcklig utbildning i systemet. Det här arbetet går ut på att först och främst göra en analys av Micro- softs befintliga processer för Microsoft som Logica part 8
Inledning of CGI använder som sin best practice. Med best practice menar man att det finns riktlinjer för bästa sätt att utföra en viss aktivitet. Sedan identifieras Thermoprodukters processer och kartläggning av deras inköps-, lager- och försäljningsprocesser att genomföras. Efter att analysen av Microsofts processer och kartläggningen av Thermoprodukters processer är färdig kommer en jämförelse av dessa att genomföras för att se vad det finns för likheter och skillnader. 1.4 Avgränsningar Undersökningen har avgränsats till tre processer för att arbetet inte ska bli allt för stort. Dessa tre processer är inköp, lager samt försäljning då dessa mer eller mindre hänger ihop med varandra. 1.5 Konkreta och verifierbara mål Målet för det här arbetet är att undersöka Hur Thermoprodukter arbetar med Microsoft Hur ser Thermoprodukters inköps-, försäljnings- och lagerpro- cesser ut? Stämmer Microsoft Process Flows överens med Thermoprodukters verkliga processer? 1.6 Bidrag till rapporten Jag har fått hjälp av min handledare Martin Jinnelöv på Logica part of CGI att få kontakt med ett företag som är kund hos dem, Thermopro- dukter. Samt installation av programvara och tillgång till det material som beskriver Microsoft s processer som Logica part of CGI använder som sin best practice. Anders Sjöö, Patrik Hovenäs och Per Henemo på Thermoprodukter har tagit sig tid till att berätta och visa hur de arbetar i Microsoft Dynamics NAV. En beskrivning om affärssystemet kommer i kapitel 2.5 Microsoft. 9
Affärssystem 2 Affärssystem I det här kapitlet kommer en introduktion till vad ett affärssystem är, den historiska utvecklingen, en definition av vad en process är samt en beskrivning av affärssystemet Microsoft. 2.1 Vad är ett affärssystem Ett affärssystem samordnar data som tidigare hanterats i enskilda system. Grunden för ett affärssystem är ett gemensamt dataregister som stöds av en central databas. Företag kan själva välja vilka moduler de vill ha och dessa arbetar sedan mot databasen där all data är samlad centralt. Exempel på ett par moduler är redovisning, personaladminist- ration, inköp, försäljning, lager med flera. Att företag kan välja vilka moduler de vill ha gör det möjligt för dem att anpassa sitt affärssystem efter sin verksamhet. För många företag är köp av affärssystem en av de största investe- ringar i tid och pengar. En investering i affärssystem omfattar inte bara själva beslutet. Det är ofta resultatet av en lång process som även leder till en lång relation mellan företag, affärssystem och leverantör. [3] Enligt Magnusson och Olsson [4] finns det två syften till att använda affärssystem, förbättring av beslutskvalitet och effektivisering av processer. Vidare tar Magnusson och Olsson [4] upp fördelar och nackdelar med affärssystem. Fördelarna är att det blir effektivare processer, bättre kontroll av bland annat lagerstatus, sänkta driftkostnader och ökad datakvalitet. Nackdelarna är att det blir höga risker, det vill säga att det finns finansiella, projektrelaterade och operativa risker. En annan nackdel är att man blir leverantörberoende. 10
Affärssystem Nedan visas en klassisk bild på hur ett affärssystem är uppbyggt. Figur 1 Uppbyggnaden av ett affärssystem (Källa: [5]) At the heart of an enterprise system is a central database that draws data from and feeds data into a series of applications supporting di- verse company functions. Using a single database dramatically streamlines the flow of information throughout a business [5]. 2.2 Historisk utveckling En sammanfattning av vad Magnusson och Olsson [4] skriver om affärssystemens historiska utveckling. Under tidigt 1970- tal utvecklade man system som skulle underlätta materialplaneringen för verksamheter inom biltillverkningsindustrin, den engelsk beteckning för materialplanering är Material Requirements Planning (MRP). Man tänkte sig att materialplaneringen inte skiljde sig så mycket mellan olika företag inom biltillverkningsindustrin. Istället för att specialanpassa systemen till varje tillverkare så satte man upp ett standardsystem och ansåg att detta var bästa möjliga sätt att material- planera, man upprättade en best practice helt enkelt. 11
Affärssystem Under 1980- talet utvecklades Manufacturing Resource Planning (MRPII). MRPII är en vidareutvecklad version av MRP. I MRPII kom ett mer övergripande fokus på hela materialhanteringen, funktionalitet som inköpshantering och prognostisering av framtida försäljning. Under 1990- talet upptäckte många IT- ansvariga ute på företagen att de hade svårt att samordna sina resurser effektivt. Det här upptäckte leverantörerna av systemen och de var inte sena att komma med en lösning. Modultänkandet tog fart och en ny idé föddes om att moduler kunde tas bort och läggas till efter företagens behov. Det nya systemet kom att kallas Enterprise Resource Planning (ERP). I slutet av 1990- talet föddes Enterprise Application Integration (EAI). Det är en lösning som binder samman och integrerar verksamhetens redan befintliga applikationer. 2.3 Processdefinition I Ljungberg och Larssons bok som handlar om processbaserad verk- samhetsutveckling [6] berättar de att det finns en rad olika definitioner på begreppet process. Den vanligaste definitionen är att en process är en samling länkade aktiviteter som transformerar input för att skapa output. 2.3.1 Uppdelning av processer Vidare redogör Ljungberg och Larsson [6] om uppdelningen av proces- ser och det vanligaste är att man delar upp processer i tre olika katego- rier, huvud-, stöd- och ledningsprocesser. Huvudprocesserna är verksamhetens viktigaste processer. De är de övergripande processerna som på en hög nivå beskriver syftet med verksamheten. Det finns två processer som nästan alltid utgör huvud- processer och det är att tillgodose kundens behov idag och att tillgodose kundens behov imorgon. Man kan säga att huvudprocesserna är de processer som tillgodoser kundens behov genom att sälja verksamhet- ens produkter eller tjänster och processerna som syftar till att stödja kunden med produkten efter inköpet. Stödprocesser behövs för att huvudprocesserna ska fungera så bra som möjligt. Exempel på stödprocesser är att fakturera kunder, skapa budget, skapa prognoser, planera produktionen och göra bokslut. För 12
Affärssystem att avgöra om en process är en stödprocess eller huvudprocess kan man överväga om processen bidrar till att beskriva syftet med verksamheten och om den kan ses som avgörande till verksamheten. Om den inte är det är det troligtvis en stödprocess. Ledningsprocesser används för att styra och koordinera huvudproces- serna och stödprocesserna. 2.3.2 Kartläggning av processer Processkartläggning innebär arbetet med att kartlägga processer. Genom att rita upp verksamhetens processer kan man enkelt förklara verksamhetens helhet och hur olika avdelningar av verksamheten hänger ihop med varandra. För att kartlägga processer anser Ljungberg och Larsson [6] att det finns fyra olika metoder. Den första metoden är en som kallas processprome- nad vilket går ut på att man promenerar igenom processen och inter- vjuar personer som utför processen. Den andra metoden liknar den första men den här kallas virtuell processpromenad. Här samlar man ihop representanter för hela processen och sedan låter de beskriva sin del. Med den här metoden får fler möjlighet att förstå processen. Den tredje metoden är att ha ett kartläggningsteam där teamets alla med- lemmar får kartlägga processen, nackdelen med denna metod är att den kräver resurser och tid. Den sista metoden är kallad processdesign och den används när det inte finns någon formell process att kartlägga. 2.4 Microsoft Thermoprodukter har använt sig av Microsoft i när- mare 10 år. Sedan 1983 har Microsoft levererat funktionalitet, prestanda och användarvänlighet. Microsoft är utfor- mat för att förenkla och effektivisera affärsprocesser i hela organisation- en och för att hjälpa företaget att få bättre kontroll och öka dess lönsam- het. Idag använder mer än 300 000 företag i 42 länder Microsoft Dyna- mics NAV [7]. 13
Metod 3 Metod I det här kapitlet beskrivs den valda arbetsmetoden samt tillvägagångssättet vid utförandet av arbetet. 3.1 Arbetsmetod Arbetet är upplagt enligt vattenfallsmodellen. Tanken med vattenfalls- modellen är att göra klart en fas i taget innan man går vidare med nästa fas. Denna modell passar det här arbetet bra då det är fyra väl strukture- rade faser att genomföra och varje fas ska vara klar innan nästa påbör- jas. Figur 2 Arbetsmetod (Egen modell) 3.2 Tillvägagångssätt 3.2.1 Planering Planeringsfasen var den kortaste perioden då tanken för den här fasen var att boka in eventuella möten. 3.2.2 Förstudie I förstudien analyserades Microsofts processer för inköp, försäljning samt lager. Dessa processer är omfattande eftersom de skall täcka upp alla tänkbara möjligheter hos små till medelstora företag. En textbe- skrivning av dessa processer som författaren själv har sammanställt finns i kapitel 4.5 4.7 Microsoft Process Flows och flödes- schemana som är utgångspunkten finns i Bilaga A: Microsoft Dynamics NAV Process Flows Purchasing, Bilaga B: Microsoft Process Flows Sales och Bilaga C: Microsoft Process Flows Ware- housing. I den här fasen lästes även litteratur som var passande för teoridelen och som utgjorde en grund för arbetet. Litteraturen söktes på Linnéuniversi- tetets universitetsbibliotek. 14
Metod 3.2.3 Utförande I utförandefasen var det möten med respektive person för inköp, försäljning och lager på Thermoprodukter för att identifiera och kart- lägga deras processer. Under dessa möten fick de beskriva och visa i systemet hur de arbetade steg för steg. Under dessa möten framkom även tips på problem och förbättringar som Thermoprodukter önskade. Detta beskrivs i kapitel 4.4 Funderingar från Thermoprodukter. När processerna var identifierade och hade ritats upp i ett flödesschema, mailades processkartan till respektive person på Thermoprodukter. Detta för att få feedback om något behövde ändras. 3.2.4 Dokumentation I den sista fasen sammanställdes det som gjorts i utförandet och skrevs ner i rapporten. En jämförelse mellan processerna genomfördes och ett resultat kom fram. 3.3 Verktyg För att rita upp Thermoprodukters processer har ett flödesschema i Microsoft Office Visio 2007 använts. Notationen som Microsoft Dyna- mics Process Flows är ritade i har även använts för Thermoprodukters processer för att enklare kunna jämföra processerna. Symbolerna är enligt ANSI- standarden och finns i Visio för grundläggande flödes- scheman [8]. Visio är ett program som används bland annat för att skapa processer. Att visualisera processer gör det enklare att förstå vad som händer i processerna inom en verksamhet då man får en enkel helhetsbild. Symbolerna nedan är de symboler som använts i Visio. Figur 3 Symboler enligt ANSI- standarden som använts i Microsoft Office Visio 15
Konstruktion 4 Konstruktion I det här kapitlet kommer kartläggningen av Thermoprodukters processer och Microsoft Process Flows att beskrivas. Textbeskrivningen av Thermoprodukters processer samt de kartlagda processerna visas först. I Bilaga D: Processkarta över Thermoprodukters processer visas flödesschemat för inköps-, försäljnings- och lagerproces- serna på en sida för att få en tydlig helhetsbild. Efter det kommer en textbeskrivning av Microsoft Process Flows för inköp, försäljning och lager samt översiktsbilder på dessa processer. För att se djupare i Microsoft s inköps-, försäljnings- och lagerprocesser så finns de i Bilaga A: Microsoft Dynamics NAV Process Flows Purchasing, Bilaga B: Microsoft Process Flows Sales och Bilaga C: Microsoft Process Flows Ware- housing. 4.1 Thermoprodukters inköpsprocess Första steget för Thermoprodukter i inköpsprocessen är att skapa en behovsrapport för att se vad som behöver köpas in. Rapporten gås igenom för att se hur mycket som finns på lagret och hur mycket systemet föreslår att de skall köpa in. En bedömning av inköpsansvarige görs för att bestämma hur mycket som ska köpas in. Behovsrapporten är en specialbyggd rapport för Thermoprodukter. Efter en bedömning av hur mycket som ska köpas in skapas ett plane- ringsförslag, i förslaget bockar de för vilka artiklar som ska beställas. När detta är klart skapas en inköpsorder med de artiklar som valdes att beställas i planeringsförslaget, inköpsordern mailas till leverantören. I de flesta fall får Thermoprodukter en bekräftelse från leverantören att ordern är mottagen. Då kan Thermoprodukter bocka i rutan bekräf- telse mottagen i inköpsordern. Om leverantören inte skickar någon bekräftelse bockas bekräftelse mottagen helt enkelt inte i. 16
Konstruktion När godset kommer till Thermoprodukter görs en kontroll mot följese- deln och en inleverans i systemet. Om det är några artiklar som saknas måste leverantören kontaktas. Fakturan skickas till ekonomiavdelningen. Figur 4 Inköpsprocessen (Egen modell) Ifall returnering av någon artikel skulle behövas, till exempel om den skulle vara defekt måste detta dokumenteras med ett foto samt kontakta leverantören. Inköpsansvarige skapar en returorder, leverantören skickar ett svar om godkännande samt ett returnummer att skriva på artikeln. Sedan skickas artikeln tillbaka och Thermoprodukter väntar på en ny artikel. Figur 5 Inköpsprocessen vid retur av defekt artikel (Egen modell) 4.2 Thermoprodukters försäljningsprocess En kund ringer, mailar eller faxar in sin order. Försäljaren tar emot denna order och skapar en offert som han skriver ut, scannar in och sedan mailar till kunden. Om kunden godkänner offerten eller en del av offerten så skapar försäljaren en order. Försäljaren kontrollerar att försäljningsordern stämmer och skriver ut denna och skickar till lagret. I de fall kunden inte hör av sig, ångrar sig eller något liknande så ligger offerten kvar i systemet. 17
Konstruktion Figur 6 Försäljningsprocessen (Egen modell) 4.3 Thermoprodukters lagerprocess Inom lagret finns fyra olika moment som kan hanteras. Det första momentet är när en leverans kommer. Då kontrolleras godset mot följesedeln, stämmer allting så görs en inleverans i systemet på antal artiklar samt att hyllplats för artiklarna bestäms. Sedan packas artiklar- na upp på den hyllplats som angetts i systemet när artiklarna blev lagerförda. Ifall någon artikel saknas i leveransen kontaktas leverantören och om det är något som behöver returneras så kontaktas också leverantören men detta behandlas i inköpsprocessen. Figur 7 Lagerprocessen, gods inkommer från inköpsprocessen (Egen modell) Det andra momentet är när en försäljare har skapat en försäljningsorder. Då tas kundordern fram i systemet och en plocklista skapas utifrån kundordern. Detta för att veta vart artiklarna finns på lagret. Vid vissa tillfällen behöver Thermoprodukter sätta ihop ett antal kom- ponenter för att få ihop en viss artikel innan den kan skickas iväg till kunden. Då finns en specialbyggd modul i systemet där ett arbetskort skapas utifrån kundordern. Detta arbetskort skrivs ut samtidigt som 18
Konstruktion plocklistan. Artikeln sätts ihop enligt arbetskortet, i systemet inlevereras artikeln för att sedan kunna utlevereras. Efter att plocklistan har skrivits ut, plockas kundordern ihop och paketeras. För att skicka gods måste fraktinformation fyllas i, bland annat om det är kolli, pall eller paket samt vikt eller volym. Sedan skrivs fraktsedel samt adresslapp ut och godset skickas iväg via LogTrade. I systemet görs en utleverans med utlevererat antal artiklar. Följesedeln skickas tillsammans med godset och fakturan skickas till ekonomiav- delningen. Det tredje momentet är när artiklarna som skall plockas inte finns i lager. Då läggs plocklistan som en restorder och man väntar på att artiklarna ska komma in i lager igen. Sist men inte minst, det fjärde momentet, är när en kund har beställt med förskottsbetalning. Då plockas ordern ihop och paketeras, sedan ställs paketet undan och betalning från kunden inväntas innan det kan levereras. Men eftersom artiklarna inte är utlevererade i systemet så ser det fortfarande ut som de har artiklarna i lagret. Detta kan vara ett problem och skapa förvirring då det ser ut som artiklarna finns på lager men i själva verket står de paketerade och väntar på att bli ivägskickade. 19
Konstruktion Figur 8 Lagerprocessen, en kundorder har inkommit (Egen modell) 4.4 Funderingar från Thermoprodukter Under mötet på Thermoprodukter kom följande frågeställningar och förslag på förbättringar upp. Ett förslag på lösningar presenteras i kapitel 5.4 Lösningsförslag på Thermoprodukters funderingar. Inom försäljning kom följande punkt upp. 1. Man skulle vilja ha möjligheten att spara försäljningsofferten som ett PDF dokument direkt i Microsoft för att se- dan skicka dokumentet till kunden. Inom inköp kom följande punkter upp. 2. Om man inte beställer alla artiklar som hamnar i planeringsför- slaget så kommer dessa som man inte har beställt att ligga kvar till nästa gång man skapat ett nytt planeringsförslag. Dessa artik- lar måste man alltså komma ihåg att ta bort för att inte bli förvir- rad nästa gång man ska göra ett nytt planeringsförslag. 3. Eventuellt översättningsproblem i inköpsorderhuvudet. Ifall man ändrar förväntat inleveransdatum så ändras orderdatum till da- gen innan man satte på förväntat inleveransdatum. 20
Konstruktion 4. När man har returnerat en artikel på grund av att den till exem- pel har varit felaktig så skulle de vilja ha möjligheten att lägga in en bevakning på att de väntar på en ny artikel från leverantören. 4.5 Microsoft Process Flows Purchasing Ta gärna fram Bilaga A: Microsoft Process Flows Purchasing för att följa med i flödesschemat. 1.0 Planning 2.0 Drop Shipment Processing 3.0 Quote Entry 4.0 Blanket Order Entry 4.1 Process Blanket Orders 5.0 Purchase Order Entry 6.0 Return Order Entry 7.0 Periodic Activities 8.0 Reports 9.0 History Figur 9 Översikt inköpsprocessen (Källa: Microsoft Process Flows Purchasing, bilaga A) Inom Microsoft Process Flows finns det en funktion man kan lägga till ifall dokument behöver godkännas innan de skickas vidare till nästa etapp. Denna funktion finns med i nästan alla moment så för att det inte ska bli för mycket upprepning skriver jag här vad funktionen går ut på. Ifall dokumentet behöver attesteras innan det skickas vidare till nästa etapp sätter man statusen till väntar på godkännande och om den inte behöver attesteras sätter man statusen till släppt. Med ordet släppt menas att dokumentet skickas vidare till nästa etapp. 1.0 Planering öppna fönstret för inköpsförslag. Inköpsförslaget beräknas sedan mot de försäljningsorderna som finns i systemet för att se vad som behöver köpas in. När inköpsförslaget är be- 21
Konstruktion räknat kommer ett dokument upp med verksamhetens artiklar och olika åtgärdsmeddelanden med vad som bör göras. De tre al- ternativen är ny, ändra antal eller ta bort. 2.0 Direktutleverans öppna fönstret med inköpsförslaget, använd sedan funktionen direktutleverans - hämta försäljningsorder. Där anges eller verifieras leverantör samt att åtgärdsmeddelanden ac- cepteras. Inköpsordern skapas. (Med direktutleverans menas att man tar emot en kundorder men istället för att själv köpa in artiklar till lag- ret så skickar man vidare kundordern till sin tillverkare för att de sedan ska skicka leveransen direkt till kunden.) 3.0 Offert öppna fönstret för inköpsofferter. Skapa en ny offert och skriv ut den, skicka offerten till leverantören och invänta att leve- rantören ska bekräfta offerten. När offerten bekräftats av leveran- tören välj funktionen skapa order. 4.0 Inköpsavropsorder öppna fönstret för inköpsavropsorder. Skapa en ny avropsorder, i huvudet på ordern fylls specifikt antal artiklar i som önskas samt vilket datum artiklarna förväntas leve- reras. Släpp ordern och skriv ut för att sedan skicka den till leve- rantören. Invänta bekräftelse. (En inköpsavropsorder utgör ett avtal mellan företaget som köper in och leverantören, avropsorder är bra att använda när man skall köpa in stora kvantiteter av en artikel som skall inlevereras i flera mindre leveranser under en viss tidsperiod.) 4.1 Processen för inköpsavropsorder när bekräftelsen från le- verantören kommit fyll i antal artiklar som ska inlevereras. Välj funktionen skapa order och en inköpsorder skapas. 5.0 Inköpsorder öppna fönstret med inköpsorder, fyll i information om ordern, släpp och skriv ut en orderbekräftelse som sedan skickas till kunden. 6.0 Returorder öppna fönstret för returorder, skapa en ny retur- order, fyll i orderhuvudet och ange orsakskod. Godset skickas tillbaka. 22
Konstruktion 4.6 Microsoft Process Flows Sales Ta gärna fram Bilaga B: Microsoft Process Flows Sales för att följa med i flödesschemat. 1.0 Quote Entry 2.0 Blanket Order Entry 2.1 Process Blanket Orders 3.0 Sales Order Entry 4.0 Return Order Entry 5.0 Periodic Activities 6.0 Reports 7.0 History Figur 10 Översikt försäljningsprocessen (Källa: Microsoft Process Flows Sales, bilaga C) 1.0 Offert öppna fönstret med försäljningsofferter. Skapa en ny och fyll i information i offerten, släpp. Skriv ut offerten och skicka till kunden för ett godkännande. När offerten är godkänd av kunden välj funktionen skapa order. 2.0 Försäljningsavropsorder öppna fönstret för försäljningsav- ropsorder. Fyll i orderhuvudet och ange specifikt antal artiklar samt datum som artiklarna ska levereras. Skriv ut och skicka till kunden. När kunden har godkänt fortsätter man i punkt 2.1 Pro- cessen för försäljningsavropsorder. (Man kan använda sig av avropsor- der om en kund har ett avtal att köpa stora antal som skall levereras i flera mindre leveranser under en bestämt tidsperiod.) 2.1 Processen för försäljningsavropsorder när kunden har godkänt avropsordern, fyll i det antal som kommer levereras och välj funktionen skapa order, en försäljningsorder skapas. 23
Konstruktion 3.0 Försäljningsorder öppna fönstret med försäljningsordern. Fyll i ordern och kontrollera om det är en direktleverans. Är det en di- rektleverans fyll i detta i inköpskoden och släpp sedan ordern. Om det inte är en direktleverans släpp ordern. Skriv sedan ut or- derbekräftelsen och skicka till kunden. 4.0 Returorder öppna fönstret med returorder, skapa en ny och fyll i orderhuvudet och orsakskod. Släpp ordern. Ett godkännande om att det är okej att skicka tillbaka artiklarna skickas till kunden. 4.7 Microsoft Process Flows Warehousing Ta gärna fram Bilaga C: Microsoft Process Flows Ware- housing för att följa med i flödesschemat. Inventory Setup Require Receive = NO Require Shipment = NO Require Put-away = NO Require Pick = NO 1.0 Receiving BASIC Inventory 1.1 Picking 1.2 Shipping Inventory Setup Require Receive = NO Require Shipment = NO Require Put-away = YES Require Pick = YES 2.0 Receiving 2.1 Inventory Put-away Advanced - 1 Inventory 2.2 Schedule Inventory Pick 2.3 Execute Inventory Pick 2.4 Ship Inventory Setup Require Receive = YES Require Shipment = YES Require Put-away = YES Require Pick = YES 3.0 Warehouse Receipt 3.1 Warehouse Put-away Advanced - 2 Inventory 3.2 Schedule Warehouse Pick 3.3 Execute Warehouse Pick 3.4 Ship 4.0 Managing Transfers 5.0 Physical Inventory 6.0 Periodic Activities 7.0 Reports 8.0 History Figur 11 Översikt lagerprocessen (Källa: Microsoft Process Flows Warehousing, bilaga B) Som ni ser på bilden ovanför finns det tre olika modeller välja mellan och dessa är grundläggande, avancerad 1 och avancerad 2. Grundläggande 1.0 Godsmottagning öppna fönstret med order, väljer vilken order som har inkommit och registrera antalet artiklar. Registrera också 24
Konstruktion serienummer eller partinummer ifall det behövs. Bokför sedan in- leveransen i systemet och lagret uppdateras. Avancerad 1 1.1 Plocka öppna fönstret med order, välj vilken order som ska plockas, skriv ut plocklistan på ordern och plocka ihop or- dern. 1.2 Utleverans öppna fönstret med order, välj aktuell order och registrera vad och hur mycket som ska skickas utifrån plock- listdokumentet och eventuella serienummer eller parti- nummer. Sedan skickas godset och lagret uppdateras med aktuellt antal. 2.0 Godsmottagning välj vilken order som tas emot, det vill säga om det är en försäljningsorder, inköpsorder eller inkommande överföring. Ange antal artiklar som tas emot och använd funkt- ionen skapa lagerinförsel/plockning, då skapas ett lagerinförseldo- kument. 2.1 Lagerinförsel välj det aktuella lagerinförseldokumentet, det dokument som skapades i 2.0 Godsmottagning, och skriv ut dokumentet. Utifrån lagerinförseldokumentet läggs artiklar- na fysiskt in i lagret. Faktiska kvantiteter och fack skrivs ner på dokumentet och skickas till kontoret. På kontoret läggs ar- tiklar in i systemet och lagerartiklarna ökar. 2.2 Schemalägga lagerplock börja med att välja vilken typ av order det gäller, det vill säga om det är en returorder, försälj- ningsorder eller utgående överföring. Registrera hur mycket som ska skickas. Använd sedan funktionen skapa lagerplock- ning och ett lagerplockningsdokument skapas för orden som senare ska plockas. 2.3 Utför lagerplock välj det lagerplocksdokument som ska plockas och skriv ut dokumentet. Artiklarna plockas fysiskt från lagret och flyttas till lagringsutrymmet för utleveranser. Lagerplockningsdokumentet skickas tillbaka till kontoret. 2.4 Frakta Lagerplocksdokumentet uppdateras med antal och fack. Detta bokförs och ordern skickas. 25