Kravspecifikation för nytt affärssystem - En fallstudie på Spaljisten AB

Transkript

1 School of Mathematics and Systems Engineering Reports from MSI - Rapporter från MSI Kravspecifikation för nytt affärssystem - En fallstudie på Spaljisten AB Anders Johansson Jun 2004 MSI Report Växjö University ISSN SE VÄXJÖ ISRN VXU/MSI/ME/E/ /--SE

2 2 Sammanfattning Syftet med rapporten är att ta fram en kravspecifikation för ett nytt affärssystem för Spaljisten. Denna kravspecifikation är en sammanställning av de krav som användarna ställer på ett nytt affärssystem och de nya krav som kommer att ställas vid eventuellt byte av affärssystem. Resultatet av denna rapport är alltså denna kravspecifikation som kan användas både vid avgörandet om företaget ska byta affärssystem och vilket det i så fall kommer att bli. Det finns två typer av användare, maskinoperatörer och övriga användare. Maskinoperatörerna använder systemet från återrapporteringsdatorerna och dessa användare ser endast en begränsad del av systemet. Med dessa användare har jag genomfört en enkel enkätundersökning där målet var att få fram vilken information i befintligt system som de måste kunna se och vilken övrig information som skulle vara intressant. Övriga användare är de användare som använder flera bilder dagligen inom deras arbetsområde. Dessa användare har jag intervjuat flera gånger och slutliga dokumentationen av varje användares rutiner har kontrollerats och bekräftats av användaren. Att göra flera intervjuer med varje användare var även nödvändigt för att reda ut oklarheter och för att något absolut krav inte skulle missas. Tack vare att jag fått mycket tid med användarna har jag kunna titta på hur deras område hanteras i andra system och frågat användarna vilka av dessa funktioner som bör ställas som krav på ett nytt affärssystem.

3 3 Innehållsförteckning Sammanfattning...2 Innehållsförteckning Inledning Syfte Problemformulering Avgränsningar Affärssystem Underhållsprogram Ekonomi Metod Verksamhetsbeskrivning Historia Tillverkning Storlek IT-beskrivning Beskrivning av nuvarande arbetssätt Ordermottagning från IKEA Beskrivning av nuvarande arbetssätt Brist Krav Utleverans till IKEA Beskrivning av nuvarande arbetssätt Brist Krav Önskvärda funktioner Tillverkningsorder Beskrivning av nuvarande arbetssätt Brist Krav Önskvärda funktioner Inköpsorder Beskrivning av nuvarande arbetssätt Brist Krav Önskvärda funktioner Inleverans / mottagningskontroll Beskrivning av nuvarande arbetssätt Brist Krav Närvaro Beskrivning av nuvarande arbetssätt Brist Krav Önskvärda funktioner... 15

4 14. Återrapportering och kassationsrapportering Beskrivning av nuvarande arbetssätt Enkätundersökning Brist Krav Önskvärda funktioner Kontroll produktivitet / Beläggning Beskrivning av nuvarande arbetssätt Frekvent använda bilder Brist Krav Önskvärda funktioner Beläggningsplanering Beskrivning av nuvarande arbetssätt Frekvent använda bilder Brist Krav Ekonomi Beskrivning av nuvarande arbetssätt Förkalkyl och efterkalkyl Brist Krav Lager Beskrivning av nuvarande arbetssätt Brist Krav Underhållsprogram Beskrivning av nuvarande arbetssätt Resultat Kravspecifikation Slutsatser och reflektioner Efterarbete och förslag till fortsatt arbete Besök hos Allt i Plåt Fortsatt arbete Källförteckning Bilagor

5 5 1. Inledning Denna uppsats utgör ett examensarbete på programmet Datavetenskap och medieteknologi vid Växjö universitet, Matematiska och systemtekniska institutionen (MSI). Examensarbetet är gjort på Spaljisten AB och omfattar dokumentering av företagets rutiner i befintligt affärssystem och sammanställning av kravspecifikation för nytt affärssystem. Spaljisten har ett affärssystem som installerades i början av Affärssystemet är ett DOS-baserat system som utvecklades i slutet av 80-talet. Det har troligen inte skett någon nyförsäljning av systemet under de senaste åren och det finns endast ett 30-tal kunder som betalar licensavgifter. Spaljisten är troligtvis den största kunden och upplever att framtida utveckling är oviss. 2. Syfte Rapportens syfte är att ta fram en kravspecifikation för ett nytt affärssystem för Spaljisten. Denna kommer att användas vid eventuell investering av nytt affärssystem. 3. Problemformulering Vilka krav ställer Spaljisten på ett nytt affärssystem? För att kunna göra en utredning av vilket nytt affärssystem som ska väljas måste det finnas en sammanställning av de krav som ställs på det nya affärssystemet. Resultatet av denna rapport blir den kravspecifikation som kan användas både vid avgörandet om företaget ska byta affärssystem och vilket det i så fall kommer att bli. 4. Avgränsningar En kravspecifikation omfattar ofta alla funktioner som ska finnas med i det nya systemet. Jag har dock valt att inte ta med funktioner som jag anser vara självklara. Detta eftersom denna kravspecifikation inte kommer att användas för utveckling av ett nytt affärssystem. Kraven kan dock vara sådana att dessa funktioner inte finns i alla affärssystem och utvecklarna av systemet kan behöva utveckla dessa för att uppfylla kraven. Jag blev redan från början informerad att Spaljisten inte kommer att avgöra om de ska byta system förrän strax innan semestern. Därför har jag inte kunnat vara med vid avgörandet vilket system det kommer att bli.

6 6 4.1 Affärssystem Med affärssystem menar jag programvara för hantering av order, lager, fakturering, produktion, ekonomi, närvaro och produktivitetsuppföljning. Ett affärssystem kan sakna någon del och kan även innehålla fler funktioner. 4.2 Underhållsprogram Företaget har ingen utarbetad underhållningsstrategi vilket innebär att jag inte kan utfärda en kravspecifikation innehållande krav för underhåll. Företaget inser dock vikten av att utfärda en sådan policy. 4.3 Ekonomi Vid byte av affärssystem i ett produktionsföretag är det ofta viktigt om detta byte är ekonomiskt försvarbart. Det är dock svårt eller troligen omöjligt att kunna dokumentera vilken effektivisering affärssystem med en sådan exakthet att det går att jämför olika alternativ utifrån detta. Jag har istället valt att utgå ifrån användarnas krav och låtit detta vara till grund för kravspecifikationen. Kravspecifikationen är tänkt vara till grund för avgörandet för eventuellt byte av affärssystem men jag har valt att avgränsa arbetet genom att inte ta med någon ekonomi. 5. Metod Jag har använt mig av en bok som jag har erfarenhet från tidigare. Boken heter UML and the unified process (Arlow & Neustadt, 2002) och det är framförallt kapitlet om Use case modeling som jag har använt mig av. Boken beskriver att det är viktigt att identifiera alla användare till systemet. Jag började gå igenom vilka användare som fanns. För att få reda på vad som är bra respektive dåligt med befintligt system, samt få information om hur användarna använder systemet började jag intervjua användarna. Bokens metod är bra för att hitta exakt alla Use-cases och detta är ett måste vid produktutveckling. Mitt arbete går dock inte ut på att finna alla händelser utan att specificera krav på vilken information systemet ska visa och på vilket sätt. Hur informationen lagras, hur beräkningar sker och liknande är ointressant. Det viktiga är att systemet är utformat så att användaren förstår systemet och att erforderlig information går att filtrera och sammanställa. Jag har använt mig av två olika metoder för att få fram krav. Dels har jag intervjuat användare av systemet och dels har jag gjort en enkätundersökning. Detta eftersom det finns olika typer av användare. Den ena typen användare är maskinoperatörerna som endast har tillgång till en begränsad del av systemet och till dessa har jag använt mig av enkätundersökningen. Den andra typen av användare är de som större delen av dagen arbetar mot systemet. Exempel på områden som denna typ användare arbetar med är inköp och tillverkningsorder. Dessa personer har jag intervjuat flera gånger för att den slutliga dokumentationen av varje användares rutiner skulle kunna kontrolleras och bekräftas av

7 7 användaren. Att göra flera intervjuer med varje användare var även nödvändigt för att reda ut oklarheter och för att något absolut krav inte skulle missas. Tack vare att jag fått mycket tid med användarna har jag kunna titta på hur deras område hanteras i andra system och frågat användarna vilka av dessa funktioner som bör ställas som krav på ett nytt affärssystem. För att få med krav på nya funktioner måste jag söka information om vilka funktioner som moderna affärssystem innehåller. För att få denna information har jag utnyttjat de tillfällen som givits. Jag har exempelvis varit på en IT-mässa som Internetcity anordnade den 22 april Där fanns flera företag som levererade affärssystem och jag kunde skaffa mig mer information om vad jag bör ha med som krav. Jag har även varit med vid möte med leverantörer där företagets krav och funktionerna i leverantörens affärssystem diskuterats. För att skapa en grund för fortsatt arbete har jag varit på besök hos Allt i plåt och genom intervjuer med personalen har jag fått reda på vad de tycker om systemet som de använder. 6. Verksamhetsbeskrivning 6.1 Historia 1975 startades Spaljisten och tillverkade till en början spaljeer och lister. Dessa bestod av skivmaterial i foljerat utförande och såldes till husindustrin, men även till den svenska byggmarknaden i övrigt. På 80-talet var IKEA en stor kund och på slutet av 80-talet gick hälften av omsättningen till denna kund. I början av 90-talet var omsättningen ca 40 mkr och nästan alla leveranser gick till IKEA. 6.2 Tillverkning Spaljisten är en träindustri fast någon bearbetning av massivträ görs inte utan all tillverkning görs med skivmaterial och med foliering som ytbehandlingen. Folien viks runt kanten på produktens långsida vilket kallas ommantling och är företagets specialitet. Ommantling ger möjligheten att runda kanten på olika sätt och att få samma färg/mönster på kanten och sidorna. Detta till skillnad från planfoliering där alla kanter kantlistas. Spaljisten är en av sveriges största leverantörer till IKEA av folierade planmöbler. Konkurenter finns i Danmark, Frankrike, Spanien och i viss mån Italien. 6.3 Storlek Företaget har en budgeterad omsättning på 250 mkr år 2004 och bedriver verksamhet både i Åseda och Ruda. Antalet anställda i Åseda är cirka 60 och i Ruda cirka 20. Totala fastighetsytorna är cirka kvm. In- och utleverans motsvarar 6-7 fulla lastbilar med släp per dag. 6.4 IT-beskrivning Nätverkssystemet är PC-baserat och har 25 användare varav 15 är återrapporteringsdatorer. Operativsystemet på servern är Windows NT4 och övriga PCdatorer har Windows 98 eller Windows Det nuvarande affärssystemet heter IT-

8 8 Industri och lönesystemet som användas heter Kontec. Kommunikationen mellan Åseda och Ruda sker med ADSL och programvaran pcanywhere. Till IKEA finnes en EDIkoppling via ett X.25-nät. På denna förbindelse överförs framför allt dagligen order till Spaljisten och fakturor till IKEA. 7. Beskrivning av nuvarande arbetssätt I kapitel 8 19 har jag dokumenterat nuvarande arbetssätt. De brister och krav som finns med i dokumenteringen är baserade på de intervjuer jag gjort med användaren vid respektive område. I kapitel 14, som handlar om återrapportering och kassationsrapportering, har jag även med en kort redogörelse för resultatet av vad maskinoperatörerna svarade i den enkätundersökning som genomförts. Jag vill inledningsvis nämna de typer av order som finns med i denna dokumentation. Vid ordermottagning är det kundorder som Spaljisten får in i sitt nuvarande affärssystem. Tillverkningsorder är de order som produktionsansvarig synliggör för maskinoperatörerna vid återrapporteringsdatorerna. Slutligen finns det inköpsorder som görs av inköpsansvarig. Spaljisten arbetar inte mot kundorder utan inköpsorder och tillverkningsorder görs utifrån IKEAs prognoser. De artiklar som kunden beställt i kundordern levereras istället från färdiglager eller från halvfarikatlager. Halvfabrikat är i Spaljistens fall färdig artikel som inte har packats. Kundorder kan därför resultera i en tillverkningsorder för packning av artiklar i halvfabrikatlager. 8. Ordermottagning från IKEA 8.1 Beskrivning av nuvarande arbetssätt IKEA skickar dagligen order via ett X.25-nät som läses in i ett kommunikationsprogram som heter ODEX. Informationen skickas sedan vidare till Polaris. Överföringen från IKEA till affärssystemet sker automatiskt. För att kontrollera detta går användaren in i serverrummet och öppnar programmet ODEX och klicka på inbox för att få alla transaktioner. För att få information om en order klickar användaren på ordens datum. Om datumfältet är tomt betyder det att ordern inte är överförd till affärssystemet. Det går att påskynda denna order genom att utföra en rutin. Efter detta kan användaren titta i inbox och ordern har nu fått ett datum. Användaren återgår nu till arbetsplatsen och anger att programmet ska läsa in order från servern. Ordernummer skapas automatiskt vid inläsning. Användaren anger dagens datum och skriver ut listan på alla dessa order (se bilaga 1). Listan kontrolleras att det inte finns dubbla order och att det går att leverera varorna enligt i ordern angivet datum. Orderbilden används för att avgöra om detta är möjligt (se bilaga 2A). Om det inte går att leverera enligt detta datum skrivs ett nytt datum in i systemet och denna information skickas sedan till IKEA som en bekräftelse. De order vars leveransdatum har ändrats får en markering och detta används vid utleverans där dessa order prioriteras. Leveransförändring är möjlig och görs genom att sända en ny orderbekräftelse.

9 9 Den vanliga typen order som kommer varje dag är B- order, men det finns även C-, F- och S- order som betyder olika saker. Ordertypen finns med vid ordermottagning där även artikelnummer och radidentitet finns med. Det finns en kopplingstabell i systemet som innehåller kundnummer, kundens artikelnummer och Spaljistens artikelnummer (se bilaga 2B). Denna kopplingstabell översätter IKEAs artikelnummer till Spaljistens och det är detta som sedan visas. Radidentitet anges av IKEA per pall för B- och C- order och detta följer med hela vägen till bilplanering, följesedel och avisering (se bilaga 1). Fakturavilkor för leveranser till IKEA är "fritt fabrikat" vilket innehär att kunden står för transporten och leveransdatumet blir den dag leveransen hämtas. 8.2 Brist När ett ordersvar är skickat lagras det som en fil på servern och denna ligger kvar här ett tag innan den skickas och raderas. Nytt ordersvar kan inte göras förrän systemet har skickat denna fil, eftersom den nya ordern då skriver över den gamla. 8.3 Krav Det måste finnas ett fält där ordertyp kan anges. Fält för radidentitet måste finnas för alla bilder som hanterar kundorder. Kopplingstabell mellan kunds artikelnummer och det egna artikelnummret måste finnas, eller att annan funktion löser detta på lämpligt sätt. Systemet måste skapa fellista vid saknat artikelnummer, felaktigt pris eller om kundens kod för leveransadress saknas. 9. Utleverans till IKEA 9.1 Beskrivning av nuvarande arbetssätt Dag före utleverans kontrolleras leveransläget och eventuella ändringar av leveransinnehåll görs så att detta är klart när leverans ska ske. Ändringar görs om tillverkningen av en artikel inte gått som beräknat vilken medför att en annan artikel skickas med transporten för att få full bil. Det går att få ut utleveranslistor både per artikel och per kund (se bilaga 3A och 4) Utleveranslista per artikel visar lagersaldot efter varje kund (se bilaga 5). Detta gör att användaren har möjlighet att kvotera ut det tillgängliga saldot på olika kunder så att ingen riskerar att bli helt utan. Order som inte är B- order kan innehålla flera pallar och dessa kan vid behov delas upp på olika leveranser. Vid fakturering räknas saldot på utleveranslista ned. När användaren gör en bilplanering skapas en följesedel med ett nytt följesedelsnummer. Alla kundens order presenteras på skärmen. Användaren kan nu markera vilka order som kommer att levereras. Detta görs med hjälp av kundorderlistan och/eller artikelorderlista och flakritningar för de olika lastbilarna. Artiklarna väljs med tanke på leveransdag och

10 10 flakritning. Programmet summerar automatiskt vikten på varje pall som läggs till, denna summa kontrolleras så att den inte överskrider maximala vikten. När bilplaneringen är klar skrivs den ut, granskas och godkänns. Därefter skickas denna till IKEA som begäran av transportbokning (se bilaga 3B och 6). Leveransen får ett shippmentsid vilket är transportföretagets identitet på leveransen (se bilaga 7). Användaren kan sedan via systemet hämta bokningsbekräftelse. För närvarande har inte Spaljisten egna program för hantering av tullhandlingar, men detta måste lösas under året. Eventuellt kan tullhandlingar skapas via Internet, men troligen måste programvara anskaffas. 9.2 Brist Utleveransarbetet är mycket tidskrävande, eftersom varje leverans måste hanteras separat. Transportkontorist måste hela tiden vara tillgänglig. Om dagens samtliga leveranser kunde hanteras sammantaget med förberedda utskrifter av följesedlar, fraktsedlar och tullhandlingar kunde tidsåtgången reduceras väsentligt. När en order skickas skapas en fil som läggs i en katalog i systemet där den stannar ett tag innan den skickas vidare. Det går inte att skicka en ny order förrän denna är skickad, eftersom filen då skrivs över. 9.3 Krav Det måste gå att skicka om en order för att ersätta felaktig order. Det måste också finnas ett fält för fritext där meddelanden, exempelvis information om samlastning, kan lämnas. Order som inte är B- order ska kunna delas. Exempelvis om det är 24 pallar av en viss typ ska det gå att skicka tolv av dem. Det ska även gå att ändra detta antal till exempelvis tio. Resterande pallar i order ska finnas kvar i systemet för senare leverans. Flera order ska gå att skickas utan att användaren måste vänta på att den första skickats vidare. Det ska gå att skicka interna följesedlar så att rätt underlag finns för beräkning av resultat för respektive enhet. Systemet ska kunna hantera tulldeklarationer. 9.4 Önskvärda funktioner Det vore bra om användaren får kvittens på att IKEA har fått en bilplanering eller transportbokning. CMR fraktsedlar används för utlandsfrakter och dessa är önskvärda att kunna skriva ut på vanligt papper.

11 Tillverkningsorder 10.1 Beskrivning av nuvarande arbetssätt Innan tillverkningsorder kan skapas måste alla mottagna order vara inlästa och bekräftade. Tillverkningsorder för färdigartiklar skapas utifrån färdiglager och kundorder. Tillverkningsorder för halvfabrikat skapas utifrån lagernivå och IKEAs rullande prognoser månadsvis som bryts ned till veckoprognoser. Behovsberäkning finns men används inte eftersom användarna upplever att funktionen inte är tillfredställande. Istället måste användaren manuellt kontrollera alla ingående material via operationslistan och orderbilden. I orderbilden får användaren en lista på bildskärmen innehållande alla artiklar (se bilaga 2A). Användaren kontrollerar listan och avgör om artikeln kommer att bli brist. Kundorder markeras med K och tillverkningsorder markeras med T. I denna bild kan användaren se disponibelt antal i färdiglager för varje vecka. Företagets målsättning är att ha ett säkerhetslager på cirka 5 veckor, fast detta är ofta svårt att klara. Orderbilden är en bild som används mest både för tillverkningsorder och inköpsorder. Denna bild ser lite olika ut beroende på om användaren angivit råmaterial, halvfabrikat eller färdig artikel. Råmaterial vilket även innefattar artikel som bearbetas har ett nummer mellan och Artikel som ännu inte har packats kallas halvfabrikat och har ett nummer mellan och Färdig artikel har ett nummer mellan och Där orderbilden för färdig artikel indikerar att disponibelt saldo är under gränsvärde bestämmer användaren att lägga in en ny tillverkningsorder. Orderbilden för råvaror används för att kontrollera om ingående material för tillverkningsordern finns tillgängliga. Vid en råvara finns beteckningen "R" för reserverad för tillverkningsorder och "I" för inköpsorder (se bilaga 8A). För att skapa en tillverkningsorder går användaren in under registrera tillverkningsorder (se bilaga 8B). Ingående material kontrolleras manuellt via operationsbild eller operationslista (se bilaga 9A och 10). När användaren skapar tillverkningsorder måste val av lämplig resurs och kontroll av resursens beläggning ske. Det går att kontrollera beläggningen på en viss resurs i systemet och det går även att få fram en grafisk beskrivning av beläggningen på resursen. För att det inte ska bli rörigt i återrapporteringsstationerna släpps inte ordern från beläggningsbilden förrän en vecka innan tillverkningen börjar. Vid utskrift av tillverkningsordern frisläpps denna automatiskt. (Frisläppt innebär att den läggs ut på körplan/resurs som finns åtkomlig för maskinoperatörerna.) Utskriften av tillverkningsorder ger även följekort, arbetskort och lageruttag (se bilaga 9B, 11 och 12). Det är viktigt att raderna för respektive resurs, signatur, tidsåtgång, startdag, färdigdag och artikelbenämning finns med. Följekort är detsamma som pallkort och det skrivs ut ett pallkort för varje pall och följer med genom produktionen tills packning då de kastas. Tillverkningsordern skickas med sista pallen till efterföljande maskin. Det finns ett arbetskort för varje bearbetning och efter avslutad körning sparas arbetskortet en vecka vid arbetsstationen och kastas sedan. Lageruttag används innan tillverkningen startar då ingående material kan kontrolleras.

12 12 Halvfabrikat planeras vara färdigställt en vecka innan orderns leveransdag. Tillverkningsorder på packning styrs av kundorder och får färdigdatum en dag före leverans. Det kan ibland vara nödvändigt att flytta tillverkningen av vissa eller alla artiklar från en maskinlinje till en annan. Denna omplanering görs av kapacitetsskäl och vid exempelvis försening av material måste omplanering göras. Systemet signalerar att en process har börjat sedan får maskinoperatören vid återrapporteringsstationen rapportera att processen avslutas. Maskinoperatören kan rapportera avbrott eller klar och båda dessa fall uppdaterar lagret. Utskrift av etiketter sker i förväg med hjälp av en fristående dator, men det anses att det vore bättre om det gick att skriva ut etiketterna direkt från återrapporteringsstationen. Produktionsansvarig använder orderbild, orderregistrering, lagerloggningar, utleveranslista, operationslista, körplan per resurs, beläggning, inleveranser, inköpsorder och bevakning tillverkningsorder. Utleveranslistan används för att avgöra när brist uppstår och bevakning tillverkningsorder visar tillverkningsorder som inte är frisläppta, frisläppta och ej startade Brist Användaren måste manuellt kontrollera saldot via orderbilden vilket är ett tidsödande moment. Behovsberäkning finns, men körningen anses vara alltför komplicerad. Det finns flera listor för att kontrollera lagersaldo utifrån kundorder, men ingen av dessa tar hänsyn till redan inlagda tillverkningsorder som också påverkar framtida lagersaldo. Bristlistan som finns innehåller inte heller planerade tillverkningsorder. Det går inte att skriva ut från orderbilden Krav För att kunna rätta felaktiga återrapporteringar måste det gå att modifiera produktionsstatistiken. Pallkort (Följekort) måste innehålla all information enligt bilaga 11 och ska skrivas ut för varje tillverkningsorder. För order som inte är B-order ska antalet utskrivna pallkort stämma överens med antalet pallar i ordern. Tillverkningsstatusen påbörjad, avbrottsrapporterad eller klarrapporterad för pågående tillverkningsorder ska visas av systemet. Systemet ska kunna visa en bristlista som inkluderar tillverkningsorder där urval kan göras för artiklar med lagernivå under vald beställningspunkt Önskvärda funktioner Företaget vill ha en kontroll av lagersaldo och planerade inleveranser för ingående råmaterial innan frisläppning av tillverkningsorder.

13 Inköpsorder 11.1 Beskrivning av nuvarande arbetssätt Inköpsansvarig får ett mail från produktionsansvarig att nya tillverkningsorder är inlagda i systemet. Efter detta kollar inköpsansvarig via operationslistan vilka material som ingår (se bilaga 10). Inköpsbehovet bedöms manuellt utifrån orderbilden eftersom det är få artiklar och stora inköp (se bilaga 8A). Nettobehovsberäkning finns men detta är en tung process och kräver en mängd detaljuppgifter för att bli tillförlitligt. Spånskivor och emballage levereras med full lastbil och övriga artiklar levereras med relativt stor kvantitet. Inköpsorder sker genom att skriva ut inköpsordern och faxa över den till leverantören. Befintligt system kan skicka inköpsorder via mail och omläggning till detta pågår. När sedan leverantörens bekräftelse anländer hanteras denna av transportkontorist som vid större avvikelser samråder med inköparen. Något som är bra i systemet är att det går att ändra flera datum i en lista. Detta är önskvärt då flera order i en lista ska ändras till samma datum. Användaren får ange från och till vilken order i listan och det nya datumet. Listan periodkontroll inköp visar inköp per artikel. Listan visar även konto och kostnadsställe 1 för Åseda och 2 för Ruda (se bilaga 13). Frekvent använda menyer är artikelregister, resursregister, mätpunkt, leverantörsregister, operationer, grupper, orderbild och registrera inköpsorder Brist Nettobehovsberäkning går inte att göra för en enskild produkt utan detta sker för alla produkter och detta tar lång tid. Om leverantören bekräftar en annan leveranstid än vad inköparen begärt och detta läggs in i systemet finns ingen indikering på att denna inte är den ursprungliga Krav Det ska gå att få ut en lista på ej bekräftade inköpsorder. Systemet ska kunna visa en lista på alla leverantörer för en viss råvara vid angivande av artikelnummer. Det ska gå att få ut statistik på genomsnittligt inköpspris och hur stort inköp som är gjort av en viss råvara (se bilaga 14) Önskvärda funktioner Det är önskvärt att kunna göra en separat nettobehovsberäkning för varje produktgrupp i de fall dessa inte påverkar varandra. Det vore bra om inköpsorder kunde skickas via mail.

14 Inleverans / mottagningskontroll 12.1 Beskrivning av nuvarande arbetssätt Vid inleverans kontrolleras antal och kvalité. Efter godkännande registreras inleverans av transportkontorist (se bilaga 15A). Inleverans identifieras av inköpsordernummer. I nuvarande system finns möjlighet att skriva ut etiketter för uppmärkning av ankommande gods, men detta användes inte eftersom det anses ta för mycket tid. Företaget har hemtagningstillstånd från Tullverket, vilket innebär att ankommande gods anmäls vid tullstation utan komplett tulldeklaration. Inom tio dagar ska komplett tulldeklaration insändas till tullverket Brist Spaljisten har inte egen programvara för att skicka tulldeklaration till tullverket utan anlitar för närvarande speditör för detta Krav Systemet ska kunna hantera insändning av komplett tulldeklaration till tullverket. 13. Närvaro 13.1 Beskrivning av nuvarande arbetssätt Alla anställda läggs upp med personliga kalendrar i systemet så att arbetad tid, övertid, ledighet, skiftersättning kan beräknas. Alla anställda registrerar via terminaler vid arbetstidens början och arbetstidens slut varje dag. Vid övertid, frånvaro, kompledighet, övertidsersättning finns det olika koder (se bilaga 15B). Vid månadsskifte körs detta ut på listor för varje anställd och dessa listor är till underlag för löneberäkning. Lönekontoristen registrerar manuellt informationen i det separata programmet Kontek Brist Frånvaroredovisning sker med externt Exceldokument (se bilaga 16) Krav Systemet ska erbjuda en enkel frånvarohantering för ett antal månader framåt i tiden genom registrering av anställningsnummer, orsak och beräknad frånvarotid. Det ska finnas en skärmbild som visar närvaro vid varje tillfälle utifrån vald grupp. Frånvarostatistik ska gå att få ut från systemet.

15 Önskvärda funktioner Vid eventuell automatisk överföring av närvarofil direkt till löneprogrammet ska kontroll av informationen kunna ske i ett vänteregister innan överföringen till löneprogrammet sker. 14. Återrapportering och kassationsrapportering 14.1 Beskrivning av nuvarande arbetssätt Alla order finns i systemet och all produktion sker utifrån dessa order eftersom inga sidorutiner finns. Vid varje större maskinlinje finns en återrapporteringsdator som är kopplad till nätverket, men har en begränsad behörighet i affärssystemet. Startbilden körplan per resurs visar alla frisläppta order per resurs (se bilaga 17A). I startbilden finns även koder som anger om föregående operation är avbruten, under arbete eller klar. En kontrollista kan skrivas ut på all återrapportering som visar om återrapporterad tid stämmer mot närvarotid. Det som registreras är anställningsnummer, ordernummer, instämplad och utstämplad tid (se bilaga 17B). Vid behov kan korrigering göras i separata menyer (se bilaga 18A). Det finns möjlighet att stämpla in flera mindre tillverkningsorder samtidigt och köra dess efter varandra med en gemensam klarrapportering. Maskinoperatör har möjlighet att stämpla in på flera körningar samtidigt vilket ger möjlighet att en person kan hjälpa till där det behövs. Vid packning rapporterar packare avbrott eller klar. Färdiglagersaldo uppdateras dock inte av denna rapportering utan manuell uppdatering av färdiglager sker. Befintligt system ger möjligheten att rapportering uppdaterar lager, men Spaljisten har valt att uppdatering av färdiglager ska ske i efterhand. Bilden körplan per resurs ger maskinoperatören mycket väsentlig information, men det finns även mycket information i systemet som inte går att nå från denna bild. Körplan per resurs är gjord utifrån önskad produktionsplanering, men verkligheten kan påverkas av färdiglagerbrist, varför det ibland blir tvunget att bryta pågående körning och starta en annan. När ny tillverkningsorder ska köras är det kundorder, nästföljande operation och färdiglager som avgör vilken körning som ska påbörjas. Kassationsrapportering innebär att maskinoperatörerna rapporterar antal kasserade artiklar. Detta görs i samband med återrapportering och det går sedan att får en lista på alla kassationsrapporteringar (se bilaga 19). Sammanställning på lista görs i externt Exceldokument (se bilaga 20) Enkätundersökning Huvudsyftet med att göra en enkätundersökningen var att det skulle framgå om maskinoperatörerna saknade någon information. Enkäten delades ut vid varje återrapporteringsdator och såg ut enligt bilaga 36. Jag kommer inte att redogöra för vad varje produktionsanvändare har svarat utan kommer endast att sammanfatta resultatet av

16 16 den. Flera av frågorna besvarades inte och jag anser detta vara ett tecken på att användaren inte hade någon åsikt på denna fråga. Maskinoperatörerna behöver alla uppgifter i bilden (se bilaga 36). Flera anmärkte på att det inte finns någon körordning. Genomsnittsbetyg för funktionalitet blev 3,3 vilket bör ses som ett godkänt betyg. Snabbhet och smidighet fick betyget 2,8 och det bör tilläggas att dessa svar hade stora avvikelser med flera mycket låga betyg Brist Maskinoperatören kan inte se vilken tillverkningsorder som ska köras först och måste ringa till produktionsansvarig för att få reda på detta. Maskinoperatörerna måste i nuvarande system fysiskt kontrollera att aktuellt råmaterial finns. Vid rättning av antal klarrapporterade enheter rättas inte den felaktiga nedräkningen av lagersaldo. Det finns ingen bild som visar alla instämplade maskinoperatörer utifrån vald tillverkningsorder. Detta är önskvärt att ha vid exempelvis avbrott i återrapporteringen då rätt maskinoperatör ska läggas in på rätt tillverkningsorder i efterhand Krav Systemet ska vara anpassat för självstyrande grupper och vara utformat så att det uppmuntrar egna initiativ. Produktionsansvarig ska kunna lägga in en prioritet som finns på varje tillverkningsorder. Maskinoperatören skulle då kunna se vilken tillverkningsorder som ska köras först och slipper ringa till produktionsansvarig för att få reda på detta. Denna prioritet skulle bland annat sättas med tanke på lagersaldo och efterföljande operationer. Det ska gå att få ut en lista på sammanställning av kassationsrapporteringen. Systemet ska ha en enkel bild, kopplad till varje tillverkningsorder som visar tillgängligt råmaterialsaldo. Vid klarrapportering ska förbrukat råmaterialsaldo räknas ned från lagersaldo. Vid eventuell rättning av antal klarrapporterade enheter ska den felaktiga nedräkningen av lagersaldo automatiskt rättas. Det ska finnas möjlighet att stämpla in flera mindre tillverkningsorder samtidigt och köra dessa efter varandra med en gemensam klarrapportering. Maskinoperatör ska kunna stämpla in på flera körningar samtidigt och tiden ska fördelas lika på dessa körningar Önskvärda funktioner Det bör finnas en bild som visar alla instämplade maskinoperatörer utifrån vald tillverkningsorder.

17 Kontroll produktivitet / Beläggning 15.1 Beskrivning av nuvarande arbetssätt All tillverkning sker mot tillverkningsorder som är inlagda i systemet. Återrapportering görs efter varje operation och omfattar tidsåtgång, antal godkända och antal kasserade. I operationslistan finns för varje artikel anslagen ställtid och operationstid. Produktivitetskontrollistan visar för varje tillverkningsorder ställtid och körtid i jämförelse med anslagna tider (se bilaga 21). Utifrån den totala verkliga tidsåtgången och den anslagna tidsåtgången beräknas ett produktivitetstal. Listan går att sortera på veckonummer, resursnummer, tillverkningsnummer, artikelnummer, grupp och total (se bilaga 18B). Varje lista avslutas med en summering. Den finns även en bild på den totala produktivitetsmätningen per vecka, mätpunkt och grupp (se bilaga 22A och 23). Beläggningen för respektive resurs kan följas upp enligt lista resursuppföljning (se bilaga 24). Listan visar endast enskilda maskinlinjer Frekvent använda bilder Kontroll återrapportering (se bilaga 25), kontroll av underlag, kontroll av order, produktivitetsberäkning och modifieringar av produktionsstatistik Brist Det går inte att se hur länge halvfabrikaten har legat i vila mellan operationerna. Det finns ingen beläggningslista som visar utnyttjandet för samtliga maskinlinjer totalt för vald period Krav Produktivitetskontrollistan ska se ut enligt bilaga 21. Varje lista ska avslutas med en summering. Det ska även gå att få en sammanfattande lista på produktivitetsmätningen (se bilaga 23). Systemet bör kunna visa en beläggningslista som visar utnyttjandet för samtliga maskinlinjer totalt för vald period Önskvärda funktioner Det är önskvärt att produktivitetstal visas på återrapporteringsdatorns bildskärm med automatik i samband med återrapportering. Det är önskvärt att se hur länge halvfabrikaten har legat i vila mellan operationerna.

18 Beläggningsplanering 16.1 Beskrivning av nuvarande arbetssätt Det finns menyalternativ för Beläggning/Resurs som visar beläggning på vald vecka (se bilaga 22B). Här visas leveransvecka, referensnummer, operationsnummer, tillverkningsorder, artikel, antal och tid för alla order som bearbetas på resursen den valda veckan. Det visas även sammanställning av kapacitet, planerad tidsåtgång och totalt antal timmar resursen är belagd. Vid grafisk beläggning/resurs går det att dubbelklicka på en resurs och få fram en grafisk sammanställning beläggning/resurs (se bilaga 26A och 26B). Dessa tre alternativ finns även för grupp och detta innebär att det går att kolla en grupp maskiner under en viss tid. För att detta ska fungera bra krävs det att bemanningen uppgår till den angivna för respektive resurs. Detta är inte alltid fallet eftersom vid exempelvis sjukdom finns inte tillräcklig bemanning för att planerad kapacitet ska uppnås. Beläggningsplanering av bemanning görs i externa Exceldokument (se bilaga 27). Vid återrapportering finns alternativen avbrottsrapportering och delrapport. Avbrottsrapportering betyder att användaren försvinner från tillverkningsordern och får stämpla in på ny tillverkningsorder. Delrapportering betyder att användaren inte försvinner från tillverkningsordern. I detta fall räknas beläggningsrapporteringen ned med verklig körd tid. Operatörerna vid Spaljisten vill enbart använda avbrottsapportering eftersom de vill kunna registrera sig på ny tillverkningsorder vid nästföljande skifts början. I detta fall räknas inte beläggningsrapporteringen ned. Systemet är alltså inte konsekvent i dessa båda fall. Beläggningen bygger på kapaciteten vid varje resurs utan att ta hänsyn till bemanningen Frekvent använda bilder Beläggning per resurs, grafisk beläggning och grafisk sammanslagen beläggning Brist Beläggningen bygger på kapaciteten vid varje resurs utan att ta hänsyn till bemanningen. Beläggningsrapporteringen räknas inte ned vid avbrottsrapportering Krav Det ska finnas en separat bemanningsplanering utöver beläggningsplaneringen. Beläggningsrapporteringen ska räknas ned vid avbrottsrapportering.

19 Ekonomi 17.1 Beskrivning av nuvarande arbetssätt När en faktura ankommer görs en fakturakontroll, vilket innebär att fakturan kontrolleras mot inköpsorder och inleverans (se bilaga 28A). Avstämning för överföring från reskontra till huvudbok finns (se bilaga 29). Effekten av prisförändring för vald period kan beräknas med fakturastatistik prisändring (se bilaga 30). Kontroll av kalkyler och inleveranspris görs genom att en fil skapas i systemet innehållande förkalkylerade värden för alla artiklar. Denna förs i komprimeras form (en rad för varje artikel) över till Excel där en lätt överblickbar lista erhålles som gör det möjligt att kontrollera att alla kalkyler och inventeringspriser är rätt beräknade. Listan skrivs sedan ut (se bilaga 31) Förkalkyl och efterkalkyl För varje artikel i operationslistan anges ingående material och vilka maskinoperationer som ingår. Ställtid och beräknad körtid anslås och utifrån detta kan systemet utföra en förkalkyl (se bilaga 32). För varje färdig orders körning kan efterkalkyl beräknas. På efterkalkylen redovisas jämförelse mellan förkalkyl och efterkalkyl. Verklig maskintid, verklig mantid samt planerat antal körda i respektive resurs och verkligt antal körda i respektive resurs (se bilaga 33). Summerad efterkalkyl kan bland annat redovisa samtliga tillverkningsorder för angivet artikelnummer, men även direkt material, direkt lön, fasta kostnader, avskrivning och total självkostnad. Även försäljningspris redovisas och resultatet det vill säga försäljningspris minus självkostnad för artikeln. Det erhållna resultatet enligt redovisning kan härledas till respektive produkt genom summerad efterkalkyl (se bilaga 34) Brist Systemet kan bara arbeta med innevarande års kalkylparametrar Krav All information om respektive artikel måste finnas enligt bilaga 28B. Det måste gå att skapa SIE-fil (se bilaga 35). Det ska gå att kunna växla till nästföljande års kalkylparametrar med ett gemensamt kommando. Det ska gå att få fram en summerad efterkalkyl där resultatet från redovisningen kan härledas till respektive produkt. Försäljningspris ska vara baserat på verkligt pris vid respektive leveranstillfälle.

20 Lager 18.1 Beskrivning av nuvarande arbetssätt Rutinerna för lagerinventering fungerar i stort mycket bra. Inventeringslistor, lagervärderingslistor, differenslistor mm fungerar på helt normalt sätt. Företaget har lager av råmaterial, halvfabrikat och färdiglager dels i Åseda och dels i Ruda. I redovisningen har dessa lager olika kostnadställen. Detta innebär att vid inleverans i Åseda kodas alla inleveranser med kostnadsställe 1 och i Ruda kodas inleveranser med kostnadställe 2. Detta sker redan i samband med registrering av följesedeln och denna uppgift följer med till fakturakontrollen. Fysisk inventering görs tre gånger per år. Alla artiklar kodas med lagerplatsnummer beroende på typ av material. All fysisk inventering registreras manuellt på inventeringslista som är uppdelad per sortiment. Leverantörens etiketter innehåller normalt företagets artikelnummer Brist PIA-lista(produkter i arbete) är mycket komprimerad och går ej att få tillräckligt detaljerad varför den är svår att stämma av mot fysiskt lager av produkter i arbete Krav Det ska gå att skriva ut komprimerad artikellista som visar självkostnad, inventeringspris och försäljningspris enligt bilaga 31. Systemet ska vara anpassat för användning av streckkoder. 19. Underhållsprogram 19.1 Beskrivning av nuvarande arbetssätt Spaljisten har ett enkelt kortregister för viktiga maskinlinjer som visar anskaffningsår, leverantör och tekniska data. En övergång till någon form av databaserat underhållsprogram har beslutats. Det kommer dock inte ställas krav på att detta finns med i affärssystemet. I det befintliga affärssystemet finns möjlighet att även lägga in uppgifter om planerat och genomfört underhåll. Detta är dock kopplat till resurs vilket innebär att programmet ser en resurs som en maskin. I Spaljistens fall har de en maskinlinje som en resurs och med maskinlinje menas en rad av sammankopplade maskiner som utför olika operationer. För att underhållsuppgifterna ska kunna vara till nytta måste det gå att härleda underhåll till en specifik maskin.