Navision & Business Central lagerstyringssystem

Indledning

Har du et lager? Men ikke noget lagerstyringssystem? Så kender du sikkert disse hovedpiner:

  • Vi skulle stadig have 20 stk. af automaterne! Hvor er de?
  • Vi kan ikke finde lagrene, chef, ham som lagrede dem har fri i dag / er gået på pension
  • Hvor har I stillet pallen med overskud af køkkenruller?
  • Hvorfor skal jeg hente gaffeltrucken hver gang jeg skal plukke vare xx?
  • Hvem har sat disse varer hernede i plukkehøjde?
  • Hvem har stillet fødevareemballagen lige ved siden af rengøringsmidlerne?

Osv. osv.

Et typisk lager, som for eksempel fungerer helt uden lagerpladstildelinger eller med faste lagerpladser til hver vare, ser næsten altid sådan her ud:

Et billede skabt med Microsoft AI af et kaotisk eller usorteret, og dermed meget rodet lager

Hvad ser vi på et lager uden lagerpladstildeling / med fast lagerpladstildeling?

  • Enkelte lagerpladser er helt overfyldte, mens andre lagerpladser er næsten tomme.
  • Åbenbart ligger varerne sammen på en måde, der medfører lang søgetid.
  • Lagre af denne type er ofte også rodede lagre, da der altid er for lidt plads til bestemte varer. Til dette formål skal der så findes ekstra plads et eller andet sted... men disse placeringer er ikke kendt af IT... og heller ikke af alle medarbejdere.
  • Af tidsnød, som opstår på grund af de utroligt lange søgetider, bliver kartoner flyttet rundt igen og igen... eller rettere sagt, sorteret igen, unødigt revet op, restpartier bliver ikke lagt pænt tilbage på deres plads efter udtagning.
  • Ikke direkte relateret til lagerstyring, men snarere til den medfølgende databehandling i EDB: Af og til sendes “pakkevarer“ som enkelte stykker og “enkelte varer“ i hele kasser (“pakker“). Mens kunderne i det første tilfælde henvender sig med en ubehagelig klage, vil der i det andet tilfælde kun være en dyr fejlbeholdning, som ikke kan forklares efterfølgende – Højere lageromkostninger på grund af “svind“.
  • Lagerpladserne er ujævnt fyldte. Nogle lagre er håbløst overfyldte, mens andre lagre/lagerpladser er gabende tomme. Konsekvensen heraf: Lageret er altid “for lille“. Hvilket det sjældent er i virkeligheden. Der lagres bare for meget luft.

I modsætning til et “kaotisk lager“:

Et billede skabt med Microsoft AI af et kaotisk, men alligevel meget organiseret lager

Hvad ser vi på et “kaotisk lager“?

  • Man kan ikke se ud fra kasserne, hvilken vare der er i dem. Det er med vilje!
  • Lageret virker ensartet, man kan ikke orientere sig efter temaer (som spiritus, julemænd, skruer eller lim osv.). Men det er meningen!
  • Lageret bliver væsentligt mere kompakt udnyttet, der bliver lagret mindre “luft“.

For at forstå dette bedre, skal vi først definere eller forklare begrebet “kaotisk lager“ eller “kaotisk lagerstyring“. Under “kaotisk“ tænker man først på et meget rodet lager, og ikke ligefrem det modsatte, et førsteklasses organiseret lager uden lang søgning og uden spild, og dertil med lidt “luft“ på lageret.

Kaotisk kommer her fra det ældre EDB. For uden det moderne EDB findes der slet ikke noget kaotisk lager… det kunne, eller rettere sagt, det kunne ikke eksistere, da den manuelle administrationsbyrde ville have overskredet alle grænser.

“Før“ var det, det eneste rigtige, at tildele en bestemt vare en bestemt lagerplads. Det ser man stadig i dag hos Aldi og Lidl i kundeområdet (og kun der!!): Opvaskemiddel står altid bagerst til højre i den sidste gang hen til kassen, og alle opvaskemidler står ved siden af eller under hinanden. Det samme gælder toiletpapir eller juice (men så i indgangsområdet).
Det er meget kundevenligt, og egentlig også meget medarbejdervenligt. Enhver kunde og enhver medarbejder ved efter et par “udtagninger“ (= pluk), hvor vedkommende finder ost, brød, chokolade eller toiletrens. Og når man først har fundet chokoladen, finder man også hurtigt Tobleronen.

Lige så nem var den datamæssige kobling: For hver vare var der reserveret et felt i databasen med “lagersted“. Og så kunne man nemt og bekvemt printe lagerlister eller plukordrer ud: Det var blot at udskrive ordren eller lagerlisten sorteret efter lagersted: Færdig!

Dette var allerede en enorm forbedring i lagerstyringen! På denne måde kunne selv meget uerfarne vikarer hurtigt orientere sig på lageret, og finde et bestemt lagersted (med meningsfuld sortering) og der (forhåbentlig...) tage den rigtige vare.

Det er jo kun fordele! Hvorfor så ikke altid gøre det på den måde? Hvorfor skal man bruge “kaotisk“, når det kan gøres så ordentligt?

Hvad er ulemperne ved et lager med faste lagersteder/lagerpladser pr. vare?

  • Fordefinerede lagersteder er altid for små eller for store.
    For store: Lagerpladser optimeres f.eks. i forhold til ordrelotsstørrelsen eller den maksimale lagerbeholdning. Efterhånden som lagerbeholdningen af en vare falder, lagres “luft“ i samme omfang. På et tidspunkt er varen næsten opbrugt, og lagerpladsen indeholder så 90% luft.
    For små: Hvis lagerpladsen f.eks. indrettes efter Ø lagerbeholdning (gennemsnitlig lagerbeholdning), og der så kommer et halvt års lager ind, kan det være, at alle varer ikke kan være på den tildelte lagerplads. Endnu værre: Hvis der - f.eks. på grund af en truende mangelsituation, på grund af en pandemi eller gunstige betingelser - leveres en markant større mængde end oprindeligt planlagt, så er den tildelte lagerplads helt sikkert alt for lille.
  • Hvis en vareleverance ikke kan være på den tilgængelige plads, bliver der fundet en plads “et eller andet sted“ til resten. Ofte er det på pladser over den pågældende vare, som er svære at plukke fra, men selv der er der nogle gange ikke plads, og så bliver tingene stående et helt andet sted ... eventuelt også et sted, hvor det står i vejen eller i omgivelser, der ikke passer til varen (i køleområdet, i ikke-køleområdet, i direkte sollys osv. osv.).
  • Der bliver ALTID ved et sådant lager lagt diverse varer et eller andet sted, hvor kun en meget kompetent lagermedarbejder kan finde dem igen… eller måske ikke kan finde dem igen, “fordi Erhardt lige har ferie“.
  • Således konverteres omkostningseffektive storindkøb gennem “svind“(da varerne ikke kan findes igen) til det modsatte: I stedet for det billige indkøb har man varemangler. Disse kan muligvis opklares senere, men så har man allerede i panik genbestilt, eller efter 3 år fundet gummiet, der nu er så porøst, at det ikke længere kan sælges.
  • Søgetid: På et tidspunkt er varerne på den oprindelige lagerplads opbrugt, og jagten efter de overskydende varer begynder. Ofte, desværre alt for ofte, når man har fundet dem efter lang tids søgen (tid = penge!), bliver der plukket fra dette lager, uden at flytte dette lager til den korrekte plads, der er registreret i IT'en (“omlagre“). Dermed bliver ethvert FIFO-princip (First IN, First OUT, ældste varer leveres først) ødelagt. Gennemsnitspriser repræsenterer så ikke længere den reelle lagerbeholdning, ældre varer bliver beskidte eller fordærvet (også gummipakninger hærder på et tidspunkt...), emballage bliver beskadiget af konstant skubben frem og tilbage... Du kender det! Jeg opfinder intet her, det er trist praksis. Og hvis du har fundet denne artikel her og har læst med hertil, er det muligvis også trist praksis på dit lager. TIdligst, når man står med den friske mælk før den ældre mælk i køledisken i REWE, forstår man dette dilemma.
  • Status tager meget længere tid end nødvendigt på grund af de netop beskrevne søgetider (“Her MÅ der ligge et lastbilbatteri et eller andet sted! Det siger EDB!“), og medfører desuden stadig arbejdskrævende efterarbejde (“Du! Jeg har nu alligevel lige fundet det nedskrevne lastbilbatteri! Det stod på toilettet bag raviolidåserne“).
  • Ved kun lige for små lagerpladser bliver emballager beskadiget af “jeg er nødt til at mase det hele herind“, hvilket kan reducere salgsværdien eller i værste fald gøre en vare usalgsdygtig -> yderligere tab.
AI-genereret billede af rodede hylder med beskadigede yderemballager på grund af et uhensigtsmæssigt lagersystem

Hvad gør et kaotisk lager, et kaotisk lagerstyringssystem så meget bedre?

I et kaotisk organiseret lager tildeles hver varemodtagelse en ny lagerplads, der bedst muligt passer til dens aktuelle størrelse. Opvaskemiddel Blå står således ved siden af messing kuglelejer og under lommetørklæder. Derfor betegnelsen “Kaotisk“, fordi det virker så kaotisk for os mennesker inde på lagret. “Ordentligt“ bliver det kun og først ved hjælp af IT. En varemodtagelse på 1000 tændrør (f.eks. palleopbevaring, bufferopbevaring) kan placeres et helt andet sted end en varemodtagelse med 25 tændrør (A-zone, plukrobot, manuelt lager).

Nem opbevaring, også af uforudset store leveringsmængder

Store varemængder brydes dynamisk ned til pakkeenheder (f.eks. papkasser eller standardkasser). Dermed kan en specifik vare som afbrydere ligge flere forskellige steder på lageret.

Et ordentligt lager gennem implementering af kaotisk lagerstyring med Navision Dynamics eller Business Central 365. Lyder det mærkeligt? Læs med!

Automatisk lagerredundans

Dette resulterer også automatisk i redundans! Hvis f.eks. et lille automatisk delelager, en reolbetjeningsenhed eller en plukrobot fejler, kan en bestemt vare med stor sandsynlighed stadig findes et andet sted på lageret. Dette kan styres målrettet allerede under modtagelsen, f.eks. for bevidst at opdele varer på forskellige lagerzoner. I en reolbetjeningsenhed kunne dette også udnyttes til at lagre dags- eller ugentlige forsyninger helt forrest i reolbetjeningsenheden, og overskydende lager bagerst. På den måde blokerer overskydende lager ikke de dyrebare (fordi de er hurtige) A-pladser, og kan så f.eks. under natlige optimeringskørsler flyttes lager for lager, uge for uge, til fronten. Dette kan naturligvis også gøres på manuelle lagre, hvis man f.eks. opbevarer overskydende lager i svært tilgængelige reoler, og derefter (forhåbentlig i tide, hjælper mitlagerstyringssystem dem med det...) efter behov flyttes f.eks. en uges forbrug derfra til A-zonerne (let tilgængelige) hylder.

Sandsynligheden for fejlvalg på grund af lignende varer reduceres

Med kaotiske lagersystemer forsøger man bevidst at placere lignende varer, f.eks. skruer M3x6, M3x8, M3x10, langt fra hinanden. Ikke enhver studiemedhjælper kan skelne en M3x6 fra en M3x8... men stort set alle hjælpere (også her kan der være overraskelser...) kan skelne en M3x6 skrue fra en 10er møtrik eller et lysstofrør.

Chargenummer, bedst før dato, serienummer beholdninger

Hver varemodtagelse behandles som en enkelt lagerbeholdning med sin egen lagerplads. Dette giver Navision/Business Central mulighed for at rapportere om hver enkelt af de lagrede beholdninger,

  • Hvornår
  • Af hvem
  • Hvorhen (Indlagringsprocessen er først afsluttet, når medarbejderen har scannet destinationslagerpladsen)

Denne beholdning er blevet lagret. Alle metadata for varemodtagelsen (leverandørens følgeseddelnummer, vores ordrenummer, mindste holdbarhedsdato (hvis registreret), serienummer, chargenummer osv.) forbliver knyttet til denne beholdning, indtil den er fjernet (fuldstændig udleveret). Disse data “overlever“ også en omplacering. Som standard forhindrer systemet blanding af beholdninger med forskellige metadata.

Optimeret plukkerækkefølge

Ved målrettet simplificering af FIFO-reglerne, kan der skabes en genvej ved plukning ved at foretrække et mere gunstigt beliggende lager i stedet for et ældre lager, eller f.eks. at bruge et lager med en mængde, der passer præcist til plukkeantallet, i stedet for at åbne større beholdere eller samle flere mindre beholdere. Her kommer virksomhedsspecifikke lagerregler ind, da f.eks. netop med fødevarer, den beskrevne optimering muligvis slet ikke er ønskelig for visse varer.
Lagerets nummerering spiller også en stor rolle ... en så stor rolle, at jeg vil skrive en ekstra artikel om lagernummerering, lagerpladsnummerering, reolnummerering osv. Man kan næsten ikke tro, hvor mange meningsfulde tanker man kan have om det! Når jeg er færdig med denne artikel om lagernummerering (lagerpladsnummerering), vil jeg linke til den her. Hvis du er i gang med planlægningen, og f.eks. skal til at tildele numre til et nyt lager, så kontakt mig, så fremskynder jeg det.

Optimeret lagerpladsudnyttelse

Da et varelager kan opdeles i individuelle beholdninger, kan standardiserede lagerpladser eller standardbeholdere (“eurobeholdere“) anvendes. Dermed kan varemodtagelsen adskilles fra den efterfølgende reelle fysiske, meget enklere modtagelse på lageret, hvilket tillader en mere udførlig kvalitetskontrol og præcis optælling (kræver bedre uddannet personale!). Desuden kan beholdninger på denne måde flyttes til optimale beholdere/optimale lagerpladser, hvilket drastisk reducerer opbevaring af “luft“.

Efterfølgende lageroptimering & ABC-analyser

Hvis en vares levetid medfører et mindre pladsbehov (beholdningen er reduceret) eller sjældnere adgang (A-varer bliver til B- eller C-varer), kan computeren oprette simple flytteordrer ved brug af f.eks. euro-kasser, standardkasser eller paller, og eksisterende lagre kan flyttes uden tab af metadata (“bedst før dato“, chargenumre) fra f.eks. en meget let tilgængelig A-plukkeplads til en mindre let tilgængelig C-plukkeplads.

Automatisk genbestilling

Også her kan IT'en igen hjælpe ved at generere automatiserede genbestillingslister for at flytte overskudslagre fra forrådslageret til A-zonerne.

Drastisk reducerede eller helt undladte lageroptællinger

Da Navision / Business Central kender den forventede mængde for enhver kasse, ethvert fag og enhver beholdning, er mange pluk samtidigt også nulgennemgangsbeholdninger.
Sender Business Central/Navision f.eks. en plukker hen til kasse 0815/4711 og giver vedkommende besked om at tage de resterende 23 stk. ud af denne kasse, vil det under plukningen automatisk blive kontrolleret, om de 23 stk. stadig var der (ellers reducerer medarbejderen plukmængden ved plukning = lagerfejl), og om kassen nu er tom (forespørgsel til plukkeren, om kassen er tom -> muligvis lageroverskud). Normalt vil revisorer vurdere denne proces som løbende status, således at en egentlig status slet ikke er nødvendig.

Udførlig forklaring af nulgennemgangsstatus („Zero crossing“)

En nulgennemgang på lageret forekommer, når
A) En vare, der fjernes (“plukkes“) planmæssigt, går ned til et lager på 0, eller
B) En vare (f.eks. på grund af et underskud/en manglende mængde) har en mindre beholdning end den påkrævede plukning af denne vare, eller
C) Beholdningen af en vare efter plukning burde være nul, men der er stadig varer på denne placering/dette lager.
En planlagt nulgennemgang (eksempel A) er optimalt: Her blev det fuldstændig uden nogen tælleomkostninger fastslået, at lagerstyringen og opbevaringen fungerer! Bare fordi opbevaringsstedet er tomt efter plukningen.

Lagermedarbejder står foran en tom lagerplads og skal egentlig plukke noget derfra.


Ved B) blev der automatisk registreret en mangel, uden at varen skulle tælles ekstra (plukkeren kan ikke udføre sin opgave og bekræfter f.eks. kun 9 i stedet for 10 stk. til lagerstyringssystemet). Dermed er plukmængdekorrektionen straks og uden ekstra besvær en form for “mini-status“.
Mit lagerstyringssystem forsøger naturligvis straks at foretage en ny reservation for at få plukkeren til at hente den manglende mængde fra et andet lager, selv før ordren er afsluttet. På denne måde kan kundeordren, på trods af en manglende mængde, stadig opfyldes uden væsentlig meromkostning.
Ved C) udføres ligeledes en “mini-status“, denne mængde står straks til rådighed for andre eller det aktuelle ordrestykke, således at yderligere kundeemner umiddelbart kan opfyldes af denne “mini-status“.

Den automatiske lagerkorrektion til B) og C) bliver naturligvis logget og kan for eksempel efterfølgende afsløre fejl ved modtagelse eller i forbindelse med andre kundeordrer.

Hvorfor er ethvert større lager så ikke "kaotisk" organiseret?

Dette stammer faktisk fra den spæde start med computerstyret lagerstyring! Som beskrevet ovenfor var den faste lagerpladstildeling, som allerede var mulig på kartotekskort og let kunne afbildes i de første ERP-systemer, en enorm komfortgevinst og en enorm arbejdslettelse sammenlignet med “kun chefen ved, hvor tingene ligger“ fra tidligere tider.

Og denne løsning var så god og let at forstå, at den bare blev anset for at være “god nok“! Men som vi alle ved, har IT gjort enorme fremskridt siden da. Problemet er bare, at beslutningstagernes tanker endnu ikke har fulgt med disse fremskridt.

Dagens IT-løsninger, såsom f.eks. Navision Financials (ja, jeg har også et lagerstyringssystem til den!) eller nyere Business Central, har ikke længere problemer med datamængden, hvis den vel at mærke administreres korrekt programteknisk!

Hvordan adskiller min lagerstyringsløsning sig fra den oprindelige lagerstyring, der er inkluderet i Business Central eller Navision?

Egentlig alt... især betjeningen, (om)bookingen, den separate lagerstyring... Se venligst på disse opgavebeskrivelser her.

  • Databehandling – varelagrene administreres meget anderledes end i det “normale“ Navision / Business Central. Flow-field princippet, som er genialt, er her helt forsvundet. Af hastighedsgrunde og andre grunde er dette uundgåeligt.
  • Omplaceringer og protokoller – også disse opbevares helt anderledes, meget hurtigere og mere kompakt.
  • Beholdninger – Mit lagerstyringssystem “tænker“ fra starten af i beholdninger, ikke i bevægelser, som Navision / BC365 jo – og med god grund! – gør.
  • Mandatseparation – Ofte tjener et stort fysisk lager flere herrer. Måske har individuelle brugere af dette samlede lager forskellige Navision/Business Central 365 (BC365) versioner... eller slet ingen Navision? Eller forskellige mandater af en ERP-installation skal have adgang til et helt lager med alle beholdninger uden at disse mandaner kan se ind i hinandens data. Alt dette understøtter mit lagerstyringssystem uden nogen “mandatovergribende“ logik i standard Navision-tabellerne!
  • Spærrede beholdninger... I Navision/Business Central 365 (BC365) bliver disse ofte afbildet via separate lagerlokationer med flere vareoverførsler. Hos mig bliver en beholdning simpelthen spærret med en kommentar og en fejlkode... og lige så hurtigt genåbnet. Efter ønske, men ikke obligatorisk, med feedback til det overordnede ERP. Selvfølgelig kan du også styre mit Navision/Business Central 365 (BC365) lagerstyringssystem med helt andre ERP'er... men Navision/Business Central 365 (BC365) er altså federe...

Jeg arbejder lige nu på illustrerede eksempler på alle typiske lagerprocesser, kontakt mig venligst eller kig forbi igen senere. Denne artikel bliver i øjeblikket løbende udviklet.