ved hjelp av APPS
LAGER OG
FORSENDELSER

Business Central ekspert
Dette er nr. 5 av 8 artikler om hvordan du kan dekke hele virksomheten din med BUSINESS CENTRAL
– uten kundeutvidelser
– bruker bare APPS
Oppfyll alle dine behov for å administrere WAREHOUSE og SHIPMENTS i BUSINESS CENTRAL.
I denne artikkelen forklarer vi hva du bør kreve, hvordan du unngår tilpasninger, og hvilke APPS du bør bruke.
Lagerstyring handler i bunn og grunn om å administrere prosessene på lageret. Generelt handler lagerstyring i ERP om å administrere varer, varianter, mengder og lokasjoner, og når vi introduserer Warehouse Management, handler det også om forsendelses- og mottaksdokumenter og lagerbeholdere.
Normalt vet vi bare at vi har 10 varer på lager, men med Warehouse Management vet vi at det er 4 varer på hylle A og 6 varer på hylle B.
» Målsettinger for WMS

Det er viktig å vite forskjellen mellom en lokasjon og en søppelkasse i Business Central. En lokasjon er et geografisk sted, for eksempel et stoff eller et anlegg. Den spesifikke lokasjonen er delt inn i mange bins.
Det imponerende med å ta i bruk en Warehouse Management-løsning er hvor raskt alt faller på plass. Vi møter jevnlig bedrifter som ønsker å innføre en lagerløsning, og som kommer fra en situasjon uten beholdere. Når de først kommer i gang, holder systemet styr på alt.
Vi må bare rydde opp i terminologien, for lagerstyring betyr flere ting i ERP-verdenen.
NIVÅ 1: FINANSIELL VARELAGERSTYRING
Å holde oversikt over mengden og verdien av hver enkelt vare er den tradisjonelle finansielle og kvantitative måten å se på lagerstyring på. Det er grunnlaget for at vi kan holde oversikt over varene i ERP-systemet vårt. Det gjør det mulig for oss å kjøpe en vare og legge den på lager, og vi kan også selge den og ta den ut av lageret.
NIVÅ 2: VARELAGERSTYRING MED KASSER
Med et Warehouse Management System – kommer varer per kasse inn i bildet. I tillegg til å kjenne antallet, holder systemet også oversikt over hvilke hyller en vare er plassert i. Det kan være tolv enheter på én hylle og tre på en annen; hver gang vi flytter varen – fysisk – må vi si ifra til ERP-systemet med en gang, slik at alt forblir under kontroll. Det kreves et helt nytt nivå av registrering, noe som krever en skannerløsning.
» Registreringsløsning
Interne lagerprosesser
Vi har en mottakssone, en plukkesone, en forsendelsessone og en backend-sone. Når en lastebil ankommer, får vi raskt varene inn i mottakssonen og får dem registrert, men vi har ikke tid til å sette dem på plass ennå. Da trenger vi smart logikk som kan hjelpe oss med hvor varene skal plasseres.
Vi plasserer hele paller i backend-sonen, og så fyller vi på plukksonen, der vi tar fra backend og flytter ut i plukksonen. Det kan også være at vi flytter varer fra høylageret til plukksonen.
Vi må kunne gjennomføre varetellinger og regulere lagerbeholdningen. Hvis varer mangler eller er ødelagte, må vi redusere lageret. Lagerstyring krever telling per kasse, og dette er en jobb vi må kunne gjøre med en skanner.
Når varene skal sendes, klargjør vi en lagerforsendelse og plukker varene for forsendelse.
Forsendelser – eksterne prosesser
Forsendelser handler om å håndtere den delen av forsendelsen som foregår utenfor lageret. Vi har kvitteringer som ankommer lageret, og forsendelser som forlater lageret.
Vi må styre hvilke varer vi forventer å motta, og planlegge hvordan vi skal sende varene til kundene. Vi må håndtere fraktbrev og speditører.

Hvis det er en hel container med varer vi mottar på lageret, vil vi gjerne ha verktøy for å ta imot varene på en enkel måte. Vi må vite hvilke varer som skal være i containeren, og vi må kunne verifisere at vi har mottatt det vi forventer.

Plukk og forsendelse
Varene kan plukkes til salgsordrer eller til produksjonsordrer. Vi oppretter et plukk slik at de ansatte kan plukke varene på lageret, og i pakkesonen pakker vi varene i de optimale eskene og sender dem med speditøren.

Vi må holde styr på antall, volum og vekt, og vi må skrive ut etiketter til eskene. Det er i denne prosessen vi går fra å fokusere på varer og mengde – til esker som skal sendes, og vi må holde styr på hva alle eskene inneholder.
Vi må kunne planlegge forsendelser slik at speditørene kommer på forskjellige tidspunkter og henter forsendelsene, og vi må kunne planlegge plukking og pakking slik at det passer med forsendelsene. Når vi har plukket og pakket varene, skal de plasseres i forsendelsessonen i den rekkefølgen de blir hentet av speditøren.


Plukk er sannsynligvis den største matematiske utfordringen. Vi må plukke de ordrene der vi har alle varene på lager. Salgsordrene må prioriteres, både i forhold til kundene og i forhold til forsendelsen, og samtidig må vi planlegge en effektiv rute på lageret for plukkingen, og vi må beregne hvilke esker varene skal pakkes i.
Ofte plukkes varene på en tralle, men det smarteste er å plukke direkte i esken. Dette forutsetter at Business Central kan fortelle hvilken størrelse eske plukkeren må velge.
3PL og konsignasjonslager
Vi kan også ha lager plassert andre steder, for eksempel hos forhandlere som har varer i konsignasjon, så når vi ønsker å fylle opp lageret deres, må vi kunne gjøre det med omløpsordre.
Det kan også være i et lagerhotell, som er ansvarlig for lagerstyringen og utsendelsen av varene våre til kundene. Det krever mye integrasjon.

MÅL FOR WMS
Vi har fire fordeler som vi ønsker å oppnå med Warehouse Management, og de er
- Økonomisk forutsigbarhet
- Høyere servicenivå
- Minimert lagerbinding
- Optimalisert plukking
Hvis du ikke allerede har en lagerløsning, bør du forberede deg grundig. Du bør for eksempel se på følgende:
- hvor stort lageret ditt er
- hvor mange valg du har
- hvilken type plekter du trenger
- om du ønsker å plukke for flere kunder samtidig
- om du vil plukke for en kunde på tvers av salgsordrer eller ikke
- om du ønsker å administrere volumet og dimensjonene på varene
- om du vil ha muligheten til å velge varer i ulike måleenheter
- om varene kommer i pakker med ulike mengder, og om de har ulik merking og ID
- om du har ukurante størrelser, for eksempel en 2 meter lang kost som ikke kan være i en pappeske
- om du har strekkoder overalt der det er behov for dem
Det er mye arbeid forbundet med å gå fra papir til en IT-løsning for lagerstyring. La oss gå gjennom de fire fordelene vi bør sørge for å oppnå når vi innfører en lagerløsning.
Fordel 1: Økonomisk forutsigbarhet
Den første fordelen er at lagerbeholdningen vår alltid stemmer – i motsetning til den tradisjonelle modellen der vi må gjennomføre en varetelling flere ganger i året, noe som krever at vi må sette av flere dager i kalenderen for å summere alle varene våre … bare for å finne et svært stort avvik.
Med en lagerløsning er det enklere å holde lageret kontinuerlig oppdatert, slik at vi aldri bygger opp et stort avvik.
Det fine er at dette er en fordel som kommer av seg selv. Når vi skal plukke en vare og den ikke er der, registrerer vi ganske enkelt en justering. På denne måten fortsetter tellingen kontinuerlig per kasse, i stedet for med jevne mellomrom per vare.
Den første fordelen er altså økonomisk forutsigbarhet.
I den tradisjonelle situasjonen, der vi teller lagerbeholdningen flere ganger i året, holder alle pusten i flere dager når vi teller, fordi ingen vet om avviket vil bli positivt eller negativt.
Hvor store er avvikene på lageret i dag? Og hva er målet med innføringen av en lagerløsning?
Hvis vi plutselig får en differanse i millionklassen, vil det få direkte innvirkning på driftsresultatet og gi opphav til en del bekymrede miner i økonomiavdelingen.
Fordel 2: Høyere servicenivå
Når lagerbeholdningen er mer nøyaktig, blir det også lettere å heve servicenivået og den perfekte ordreoppfyllingsgraden vi tilbyr kundene.
Hvis en vare er ødelagt, kan vi skrote den med en gang. Når noe ikke stemmer, kan vi justere det med en gang i stedet for å vente på en opptelling.
Perfekt ordreoppfyllelse handler om hvor mange salgsordrer vi leverer til kundene på en perfekt måte, til avtalt tid, til avtalt pris og uten reklamasjoner. Vi ønsker selvsagt at kundene våre skal være fornøyde – og det blir de hvis de får det de vil ha, når de vil ha det. Det er selve symbolet på et høyt servicenivå.
Det er faktisk ikke nok å levere til bekreftet tid. Hvis du bruker SCOR (Supply Chain Operations Reference), bør det “sanne” servicenivået måles opp mot hva kundene ønsker å få. Hvis vi kan levere det, er vi gode på det vi gjør.
Hvis servicegraden er for lav, er det sannsynligvis snakk om varer som vi har problemer med å få tak i i tide, fordi planleggingen ikke er grundig nok, eller fordi vi har kort leveringstid ut og lang leveringstid inn, for eksempel hvis vi kjøper varer i Kina og leveringen tar seks måneder, men kunden forventer å kunne kjøpe varen på én dags varsel.
Så vi har en utfordring. I denne situasjonen må vi ha god kontroll på planleggingen vår.
Men … i tillegg til denne tradisjonelle utfordringen må vi også tenke på lagerstyring.
Hvis vi tror at varen er på lager og selger den, men lageret viser seg å være tomt, har vi en stor utfordring.
For å oppnå en god servicegrad er det avgjørende at varelageret går opp. Derfor trenger vi lagerstyring med sanntidsoppdatering.
Fordel 3: Minimert lagerbinding
Samtidig gjør en lagerløsning det mulig for oss å redusere kapitalbindingen i varelageret.
Det er et evig spørsmål om prioritering: skal man øke servicegraden ved å øke lagernivået eller minimere kapitalbindingen og leve med lavere servicegrad eller høyere etterbestillingskostnader?
Detaljert lagerstyring gir oss større sjanse til å få viljen vår på begge fronter.
Hvis lagerstyringen vår er i uorden og vi ikke kan være sikre på om det er avvik på lageret, må vi kjøpe inn større kvanta for å være sikre på å ha nok på lager – og dermed øker likviditetsbindingen.
Når vi kan styre varelageret med større presisjon, kan vi kjøpe inn mer smart og dermed redusere lagerværdien uten at det går ut over servicenivået.
Fordel 4: Optimalisert plukk
Noe av det bedriftene legger mest vekt på når de innfører en lagerløsning, er plukk av salgsordre – muligheten til å plukke på lageret og bli guidet rundt på lageret i en optimal plukkrute. Et optimalt plukk handler om den korteste og smarteste ruten.
Det finnes mange ulike modeller for strukturering av plukk. Vi må derfor ha klart for oss hvilke krav ERP-løsningen skal ta hensyn til når plukk organiseres. Det er vanligvis mange ulike scenarier å ta hensyn til.
Hvis vi har mange salgsordrer, mange av dem for samme kunde – for eksempel hvis vi leverer til en stor detaljhandelskjede og har ti forskjellige åpne salgsordrer for dem, hvorav noen er restordrer, noen er for i morgen og noen var for i går – bør lagerløsningen på en intelligent måte sette sammen et plukk på tvers av salgsordrene.
Kanskje vi ønsker å gjøre et “bulkplukk”, dvs. plukke 20 ulike salgsordrer til forskjellige kunder på én gang, fordi det er relativt små ordrer. Når vi ankommer ekspedisjonsområdet, skiller vi varene og legger dem i esker. Dette kalles “bulkplukk”.
Det kan også være at vi ønsker å jobbe med “kasseplukk”, der vi plukker direkte i forsendelsesemballasjen. Hvis vi skal plukke til fire salgsordrer, vil lagerløsningen be oss om å plukke i fire forskjellige esker.
Systemet må holde styr på volumet og må på forhånd ha regnet ut hvor store eskene må være. På den måten slipper vi å pakke om varene i ekspedisjonsområdet, fordi vi har plukket rett fra hyllen og inn i forsendelsesemballasjen. Dette kalles “eskeplukk” eller “palleplukk”, avhengig av hvilken type pakning det er snakk om.
I tillegg kan det være lurt å plukke alt som skal til utlandet før kl. 09.00, fordi det er da transportøren kommer for å hente forsendelsene til utlandet. Lagerløsningen må derfor sørge for å organisere plukkingen slik at vi ikke plukker alle ordrene til lokale adresser, som så tar opp plass på lasterampen når lastebilen som skal til utlandet, ankommer.
Når det gjelder plukk, er det mange ulike krav som er avgjørende for vår evne til å optimalisere lageret. Plukkeren trenger selvfølgelig ikke å bekymre seg for alt dette. Håndterminalen skal bare veilede plukkeren langs den beste ruten.
“Ta en tralle med to esker i størrelse 3 og 5. Plukk varene på denne ruten. Systemet skal organisere alt dette for plukkeren.
Når en ordre er plukket, skal lagerløsningen opprette fraktdokumentene og integrere med transportørene.
Det viktige er at løsningen tar seg av bestillingen av transportøren som skal komme, og at den overfører alle nødvendige data slik at det ikke er nødvendig med manuell behandling.

REGISTRERINGSLØSNING
Noen bedrifter kan klare seg uten skannerterminaler, men bare fordi de har et lite lager og jobber med faste beholdere.
Det første paradigmet i en lagerløsning er altså at vi må registrere alt som skjer på lageret, og i praksis er dette ofte bare mulig med en skannerregistreringsløsning.
De fleste bedrifter trenger enheter for å utføre registreringer på lageret. Det kan være dyre håndterminaler, truckskannere eller bare smarttelefoner som kjører en mobilversjon av ERP-systemet Business Central.
Hvis vi har et lite lager, kan dette gjøres ganske enkelt, rett fra en mobilklient og inn på Business Central. Men en eller annen form for registreringsløsning er et must.
Online eller offline
Og den første avgjørelsen som må tas, er om vi skal jobbe online i ERP-systemet eller offline. Med andre ord, om vi ønsker at registreringene våre skal oppdateres i ERP-systemet uten forsinkelse (online) eller i batchmodus (offline).
Hvis alt er oppdatert online i ERP-systemet, kan en selger opprette en salgsordre som umiddelbart sendes til lageret, der ordren kan plukkes med en gang.
I mange lagerløsninger genereres plukk om morgenen, når en batchjobb i systemet regner ut hvor mye vi skal plukke i løpet av dagen. Deretter opprettes alle plukkene, og vi får et jobbseddel som viser hva vi skal gjøre i dag.
Nyere systemer lager ett plukk om gangen. Når plukkeren er ledig eller ferdig med plukkingen, trykker han på en knapp på terminalen for å få informasjon om neste plukk, hvorpå systemet oppretter det neste plukket for ham. Det betyr at hvis det nettopp har kommet inn en ny salgsordre med topp prioritet, vil den være den neste som skal plukkes.
Det kan også hende at varer har kommet inn i ankomster for bare et øyeblikk siden, og systemet kan nå se at denne varen er tilgjengelig og begynne å tillate at den inkluderes i plukk. Debatten om hvorvidt registreringen skal foregå online eller offline, er svært viktig. Sanntidsplanlegging av plukk har selvsagt noen fordeler, men det betyr ikke at det alltid er den beste løsningen.
Vi må for eksempel vurdere hvor god nettverksdekningen vår er. Online krever naturligvis uavbrutt internettilgang. Aksesspunkter settes vanligvis opp rundt omkring på lageret, og det er enkelt så lenge vi befinner oss i et vanlig innendørs lager.
Vi anbefaler normalt å jobbe online så mye som mulig, men hvis vi ikke har uavbrutt internettdekning, må vi jobbe offline.
Utstyr
Valgene som er diskutert ovenfor, kan avgjøre hvilken type håndterminalutstyr vi trenger, men ellers:
Hvis vi har mange plukk og mange plukkere på et stort lager, er det som regel et godt forretningsargument for å velge skikkelige skannerterminaler med mange funksjoner – som tåler kontinuerlig bruk og å bli overkjørt av en gaffeltruck.
Hvis vi har et relativt lite lager og bare ønsker å foreta sporadiske registreringer, kan vi kanskje nøye oss med et nettbrett eller en mobiltelefon som er direkte koblet til ERP-systemet. Disse er mye billigere, men også betydelig mer sårbare.
Volumet er det som i hovedsak avgjør valg av utstyr.

PAKNINGER, STREKKODER OG STYKKGODS
La oss se nærmere på noen av de funksjonskravene som ofte skaper utfordringer i en ny lagerløsning.
Pakker
Vi selger en vare, for eksempel cola, stykkvis, og det er en strekkode på hver colaboks, men de er pakket seks i en pakke.
Skal vi derfor ha en annen strekkode på utsiden av pakningen, eller skal det være den samme strekkoden – og må vi i så fall huske å registrere 6 enheter når vi skanner en pakke?
Hvis 6-pakningene pakkes i en eske med totalt 24 pakker, har denne esken også en ny strekkode?
Hvis det er forskjellige strekkoder på colaen, og systemet kan gjenkjenne mengden, gjelder det samme prinsippet for alle andre varer. Ellers vil det uunngåelig oppstå feilplukk. Hvis vi skal kunne håndtere denne utfordringen på en god måte i ERP-systemet, må systemet støtte en varestruktur med pakninger i ulike mengder.
Ellers blir det vanskelig å håndtere – enten i varestrukturen i ERP-systemet eller i skanningssituasjonen på lageret. Vi må ha god oversikt over pakningene og mengdene vi plukker inn.
Strekkoder
Når vi innfører en ny lagerløsning, er det mest tidkrevende å legge strekkodene inn i ERP-systemet vårt, sette opp kassene og feste etiketter på alle hyllene på lageret der vi ønsker å bruke håndterminaler til skanning.
Det har ikke så mye med selve ERP-løsningen å gjøre; det er en lavteknologisk jobb som må gjøres. Dessverre er det mange bedrifter som ikke har strekkoder på alle sine varer og alle sine biter og deler.
Hvis vi for eksempel er et næringsmiddelfirma og kjøper et parti blomkål, vil det ikke bli levert med en strekkode på hvert blomkålhode. Så hvordan registrerer vi dem? Må vi ha koden for en blomkål i hodet, eller må vi gå bort til en tavle et sted og bla oss frem til bildet av en blomkål slik at vi kan skanne en strekkode?
Dette problemet er ikke begrenset til næringsmiddelindustrien. Strekkodeskanning er en utfordring i mange bransjer.
Alternative ikke-lineære måleenheter
Det er en annen stor utfordring for ERP-systemer på lageret: ulike måleenheter. De fleste ERP-systemer håndterer enhetskoder helt fint. Vi lagerfører hermetisk cola i stykk, men vi har den også i 6-pakninger og 24-pakninger.
Vi håndterer dette ved å opprette relasjoner mellom enhetskoder i ERP-systemet. Vi har altså enheter, pakker, rammer, esker, kolli og så videre. De fleste ERP-systemer håndterer dette på en god måte.
Det vanskelige er ikke-lineære måleenheter.
Et klassisk eksempel kan være frosne kyllinger. Vi selger frosne kyllinger i esker med 20 stk. Det er 20 i en eske når vi kjøper dem også, men avregningen, både ved salg og kjøp, skjer etter reell vekt.
Vi bestiller en pall, som er 40 esker, fra leverandøren vår. Så kommer de; vi registrerer mottak av 40 esker på innkjøpslinjen i ERP-systemet, og det regner seg selv ut at dette utgjør 800 enheter.
I praksis kan det imidlertid hende at når vi skanner dem inn på lageret, skanner vi hver kasse for seg og registrerer vekten, noe som kan vise seg å være færre kilo enn innkjøperen trodde. Kyllinger kan variere mye i vekt, og vi ønsker å håndtere dette i ERP også.
Til syvende og sist må alt avregnes etter vekt, så ERP-systemet må holde styr på flere ikke-lineære måleenheter for samme vare. Vi kaller dette alternative enhetskoder, eller “andre måleenhet” i ERP-terminologi.
Hvis vi importerer skinker fra Italia og kjøper dem i kvantum, kan det være store variasjoner. Skinkene veier mellom 1,2 og 3,5 kilo hver. Kunden vår bestiller 3 skinker og får 3 levert, men betalingen må skje etter vekt. I denne situasjonen er det avgjørende at ERP-systemet vårt holder styr på enhetene.
Utfordringen for ERP-systemet er som regel ikke at måleenhetene endres mellom kjøp og salg. Det er ganske enkelt å håndtere så lenge måleenhetene er lineære, slik at 1 kg tilsvarer for eksempel 8 enheter.
ERP-systemet vil arbeide med en grunnenhet, typisk den som brukes til lagerføring og den som varene lagerføres i, økonomisk sett. Selv om vi kjøper 100 kg, vil systemet lagerføre det i form av basisenheten, som en mengde på 800.
Men når forholdet ikke er lineært, finnes det ikke alltid en naturlig baseenhet, og da begynner det å bli vanskelig i ERP-systemet.
Det er ikke så gøy å ha 100 meter planker på lager hvis alle er bare 20 cm lange fordi de er avkapp fra tømmer som er saget i lengder til kunder. Hvilken enhet skal vi telle planker i hvis vi skal gjøre en varetelling? “Flere” er sannsynligvis det beste svaret.
ERP-messig kreves det et eget system for å administrere de ulike enhetskodene bak kulissene.
Vi ønsker ikke at dette skal spesialutvikles i ERP-systemet vårt, da det er en stor oppgave. Vi ønsker at lagerstyringsløsningen skal håndtere det.
Breakbulk
Kanskje vi også har behov for å håndtere stykkgods på lageret. Vi kan se at vi har 10 000 colabokser på lager, men vi kan kanskje ikke se hvilken stykkgods de ligger i. Hvor mange er pakket i 6-pakninger eller i esker med 24 stk?
I skinkeeksempelet ovenfor kan en kunde bestille tre skinker, som hver skal veie minst 2,8 kilo. Bør systemet vårt kunne fortelle oss om vi kan levere? Det kan godt være at vi kan levere 3 enheter, og at vi også kan levere 8,4 kilo, men det betyr ikke nødvendigvis at vi kan levere 3 enheter på minst 2,8 kilo hver.
Hvis vi driver et trelastlager og kjøper inn planker i faste lengder, hvor mange detaljer må ERP-systemet holde styr på? Vi kan kanskje se at vi har 400 meter på lager, fordelt på 200 planker, men ikke hvilke lengder det dreier seg om.
Hvis en kunde bestiller 100 planker på 3 meter, kan det hende at vi har nok på lager både i lengde og antall, men hvis mange av dem kappes opp i små biter, er det ikke sikkert at vi har 100 lengder på 3 meter.
Hvis vi vil vite hvilke planker vi faktisk kan plukke, må ERP-systemet ha full kontroll på både stykkgods og enhetskoder.
SPORING AV VARER
Varesporing – enten det gjelder håndtering av utløpsdatoer eller vanlige parti- eller serienumre – er en klassisk problemstilling. Business Central må støtte dette på en elegant måte (og ja, det finnes mange uelegante måter å håndtere dette på).
Det finnes mange bransjer der sporing av varer nå enten er relevant eller et absolutt krav.
Partienumre og serienumre
I hovedsak finnes det sporing av partinummer (også kalt batchnummer) og serienummer.
Forskjellen er at serienummeret er unikt for enheten. Det er alltid en mengde på 1 enhet som har et unikt serienummer. Serienumre er svært vanlige i for eksempel elektronikkbransjen.
Lotnummer brukes når en vare produseres i et parti, og alle enhetene i dette partiet får et lotnummer slik at de kan gjenkjennes. Dette kan gjelde flytende produkter som kan tappes av, eller vanlige varer som kan plukkes. Det kan også gjelde varer som produseres i kvantum, men som får et partinummer fordi de produseres i batcher.
Du kan for eksempel få produsert 5000 brett med paté på én gang og derfor få samme partinummer. Eller en kubikkmeter plastdingser osv.
Et av kriteriene for å velge serienummerhåndtering er at serienummeret må stå på den enkelte varen. Ellers gir det ingen mening.
Det finnes også noen bransjer som setter både partinummer og serienummer på samme vare, for å vise at et bestemt serienummer ble produsert i en bestemt serieproduksjon.
Business Central vet hvordan man håndterer parti- og serienumre. Når en vare har blitt satt opp til å vise om den har et parti- eller serienummer, håndterer Business Central dette på en god måte gjennom hele hierarkiet.
Hvis vi for eksempel skal produsere 5000 brett med paté, og vi kjøper inn kjøtt og melk, registrerer vi et partinummer på de innkjøpte varene i kvitteringene.
Og hvis vi ikke mottar et partinummer fra leverandøren, kan vi opprette vårt eget, som består av en dato og et ID-nummer. På denne måten vet vi når den enkelte råvaren ble mottatt, og fra hvilken leverandør.
Hver gang vi håndterer råvarene på lageret, angir vi partinummeret på varene du tar ut. Når råvarene inngår i en produksjon av et ferdig produkt eller kanskje et halvfabrikat, registrerer vi hvilke partinumre som inngår, og resultatet av produksjonsordren får et nytt, sporbart partinummer.
Et brett med paté ender dermed opp som et hierarki av partinumre, noe som gjør det mulig for oss å gå ned i hierarkiet og spore alle råvarene som inngår i et bestemt brett med paté.
Hvis vi identifiserer en råvare som er et problem, kan vi navigere oss oppover i hierarkiet og spore alle de ferdige produktene som inneholder det problematiske råvarepartienummeret.
Dette er tradisjonell varesporing, noe ERP-systemet kan støtte på en enkel måte.
Varesporing krever helt klart flere registreringer på lageret og i produksjonen, men vi må sørge for at strukturen i ERP-systemet ikke gjør det enda vanskeligere. Vi bør alltid kunne “skanne oss ut”. Vi bør minimere manuelle registreringer.
Ingen manuell inntasting
Normalt vil vi enten ha partinummeret på råvarene våre eller skrive ut etiketter med partinummeret på når vi produserer varen.
Hvis vi for eksempel produserer en vare som systemet automatisk tildeler et partinummer, må systemet kunne skrive det ut slik at det vises på en etikett med strekkode og dermed enkelt kan skannes.
Ingenting skal måtte tastes inn manuelt. Vi skal kunne håndtere varen utelukkende ved hjelp av skannerterminalen. Dette kan settes opp i de fleste lagerløsninger.
Det kan godt hende at vi har noen varer som spores og andre som ikke spores. Melken og kjøttet til patéen spores med partinummer, men salt og pepper gjør det kanskje ikke. De fleste systemer kan håndtere dette.
HÅNDTERING AV UTLØPSDATO
Håndtering av utløpsdato
På Business Central oppstår det vanligvis utfordringer når det gjelder håndtering av utløpsdatoer. Når vi kjøper en vare, vil det stå på den når den går ut på dato, og vi må kunne registrere dette i ERP-systemet.
Og når vi produserer en vare, må vi kunne velge en formel for utløpsdato på varekortet, slik at systemet beregner en dato, f.eks. 1 år fra produksjonsdatoen, og stempler den spesifikke utløpsdatoen i systemet.
Dette er i seg selv rimelig enkelt for de fleste ERP-systemer
Det blir litt vanskeligere når vi ser på “gjenværende holdbarhetstid” (RSL).
Gjenværende holdbarhetstid
Når kunden vår kjøper en vare som går ut ett år etter produksjonsdatoen, kan kunden stille krav til hvor lang holdbarhetstid som gjenstår. Når varen når butikkhyllene, kan supermarkedet kreve at den gjenværende holdbarheten skal være minst 75 %.
Kravet til gjenværende holdbarhetstid er ikke alltid uttrykt i dager, men kan være en prosentandel av varens totale holdbarhetstid.
Kundene våre vil normalt ha ulike krav til gjenværende holdbarhetstid, og det kan være svært vanskelig å håndtere dette og få ERP-systemet til å ta hensyn til det ved beregning av lagerplukk.
Til å begynne med bør plukkalgoritmen være smart nok til å plukke varer til de kundene som har de minst restriktive kravene, slik at de får de eldste varene. På denne måten kan vi være sikre på å kunne oppfylle kravene til gjenværende holdbarhetstid på så mange bestillinger som mulig.
Kundene våre kan også gjøre det litt mer komplisert ved å stille krav om “single batch”, det vil si at kunden insisterer på at hele forsendelsen skal ha samme partinummer, eller “single layer batch”, der alle lagene i en pall skal ha samme partinummer.
Mange kunder stiller slike krav fordi de ikke ønsker å skanne mange forskjellige varenumre med ulike mengder i ankomstområdet.
“Single batch” gjør det mye enklere for kunden – men mer komplekst for ERP-systemet vårt.
Hvis vi har en kunde som legger inn en stor ordre med krav om “single batch”, vil ERP-systemet sannsynligvis måtte plukke for denne kunden først for å være sikker på å kunne levere. Men dette kan føre til konflikter.
Hvis en annen kunde bare krever 50 % gjenværende holdbarhet, ønsker vi å plukke til denne kunden først, for da kan vi ta den eldste varen. Men hvis dette plukkingen splitter et parti, er det ikke sikkert at vi klarer å levere den store “single batch”-ordren i det hele tatt.
I realiteten må vi derfor ofte vurdere de med de mest restriktive “single order”-kravene først, og vurdere gjenværende holdbarhetstid etterpå.
Dette blir fort en matematisk øvelse der ERP-systemet må sjonglere med alle kravene og kombinere varer slik at flest mulig ordrer blir plukket.
Om ikke annet krever dette at varelageret er 100 % korrekt.
Og det krever en Warehouse Management-løsning som er god til å planlegge plukk i henhold til alle kriteriene som kundene setter.