Lagerstyring og availability

Her kan du læse, hvad Lene, Anders og Sune fortæller om i denne video:

Anders, når du snakker med kunder, så må der være en problematik også omkring noget lager, og antal af varer på lager, som man gerne vil fremstille. Hvad hører du typisk?

Det er et rigtig interessant spørgsmål, og det er noget, vi snakker med rigtig mange kunder om. Det har jeg gjort i alle de 20 år, jeg har bygget e-handelsløsninger. Der er sket en ændring, men det første, jeg altid spørger ind til, er om det passer. De fleste har noget lager inde i deres økonomisystem, men det næste spørgsmål er, om det passer.

Hvad er svaret typisk på det?

Folk svarer meget ofte bare, at det gør det, men når man så begynder at bore lidt i det, så passer det måske ikke helt så meget.

For 20 år siden, der lavede vi sådan nogle trafiklys, når vi lavede lagerstatus, rød, gul og grøn, hvor for at den skulle være grøn, så kunne der godt skulle være 10 på lager, fordi der passede lageret måske kun lige. Der var nogle, der var gået i stykker, og nogle, der var ved at blive plukket, og nogle, der var taget til side, som ikke lige var blevet reguleret. Men nu til dags, der passer det ofte rigtig godt, eller i hvert fald meget bedre.

Så jeg tænker, hvad er dine erfaringer med lager i forhold til dem, der er udstillet på en webshop?

Det er blandt andet, at man måske ikke ønsker at udstille sit fulde lager, så man dedikerer nogle varer, der skal være på webshoppen, så man kan være sikker på at kunne levere til tiden, eller til den aftalte tid, man har med kunderne, fordi er der noget, der kan give en dårlig anmeldelse, og virkelig kan skade ens ry, så er det, man har lovet levering på fredag for eksempel, og der måske går flere uger, fordi man i mellemtiden måtte sælge varerne til nogen andre.

Så noget af det, vi ser, det er at lave et reservationslager, hvor man dedikerer varerne. Jeg ved ikke, om man nogle gange også gør det fysisk, altså flytter varerne væk, så folk ikke bare tager det, fordi det, man også nogle gange ser, når man kører lager, det er at det hele er blandet sammen, og så tager medarbejdere bare lidt hvad de har brug for, og hvis det skal virke, så er man nødt til at skille varerne fra hinanden.

Jeg har i hvert fald set en kunde engang have et indhegnet område i deres lager, hvor de flyttede varerne ind til deres webshop, og sørgede for, at det var en forretning for sig selv i den forstand, at når det først var der, så måtte man ikke tage det. Der har jeg i hvert fald set det der med at virkelig gøre noget ud af at sikre, at de kunne levere ordrerne, når de kom ind på webshoppen.

Ja, og ikke bare snuppe noget for at gøre en kunde glad, som i virkeligheden kunne gøre, at du ødelægger noget for nogen andre.

Og så handler det jo om, at man har styr på, at man får bogført sin pluk hurtigt, og man får flyttet sine varer rundt og sådan noget, så man hele tiden er opdateret på, hvad der sker i systemet.

Ja, fordi i virkeligheden så kan Business Central og mange andre systemer sagtens rent teknisk det her med lagerstyring og lager, hvor meget vi har på lager og hvor meget vi har til rådighed osv., fordi det teknisk set ikke er så svært en opgave.

Det er det ikke. Det er jo ikke nyt. Det her har man kunne altid, men det er måske nyt, at man har behov for at styre det på samme måde, fordi før i tiden kunne det være, at når man lagde varer på lager, så bogførte man det ned på en lagerkonto, hvor det kan være, at nu har man behov for at se varerne. Så ændrer man det ved, at man køber varer til et varenummer, lægger varerne på lager, der sker måske nogle plukkørsler og der sker nogle andre ting.

Det er jo meget mere detaljeorienteret, og det kræver, at man har nogle mennesker, der også kan tage hånd om de her processer, for ellers er det ligegyldigt. Så kan man køre sit ERP-system som et finansbogholderi. Det kan sagtens lade sig gøre, men så kan du heller ikke give de samme svar.

Nej, og det er lige netop det der er jo interessant i det her med lager. Det handler jo i virkeligheden ikke så meget om teknikken.

Tidligere, så ringede man jo ind og spurgte om man kunne få to af den her varer, og så sagde Berit eller Jens, “ja det kan du godt”, eller “vent, jeg går lige ud og tjekker på lageret, om de er der”.

Lige nu, når vi snakker e-handel, så sidder folk derhjemme udenfor åbningstid, eller i åbningstiden, og bestiller varerne. Og det er ligesom, når noget er på skrift, så gælder det lidt mere, end når vi har snakket med folk på telefonen.

Plus at når du kun snakker med folk over internettet, og du ikke har snakket med en fysisk person, så har du bare en tendens til at være mere hård i spyttet, end du er, hvis du har snakket med dem, fordi de lød faktisk rigtig rare, og det var faktisk et rigtigt menneske, der var i den anden end. Så man er også hurtigere på aftrækkerne til at synes, at noget ikke er godt.

Så derfor skal man have styr på sit lager, og have styr på sit lagerantal ude på webshoppen. En måde at gøre det på, er at have en lokationskode, eller et eller andet, man kan flytte det over på.

Man kan jo også i nogle systemer simpelthen have det i e-handelsløsningen, men så kan det godt være, at du kommer i problemer, fordi det næste er så, hvis varerne ikke er på lager, så vil man måske også gerne vise, hvornår det så kan komme.

Og så er du tilbage igen, hvor du så er ovre i købsmodulet, der skal vi måske fortælle, hvor lang tid den her leverandør er om at levere, eller i bedste fald har vi allerede bestilt varerne, og vi kan fortælle, hvornår de kommer ind på hylden, og så har vi igen behov for data fra vores økonomisystem.

Hvorimod den simple løsning med at fortælle et antal, det kan man nogle gange godt taste ind ude i e- handelsløsningen manuelt, men det kræver jo igen, at der er nogen, der sidder og vedligeholder det. Så man kommer ganske hurtigt til at ville have det andet behov. Hvad har vi på lager, og næste, hvornår kan vi så levere tingene? Og igen, vi leverer ikke bedre data, end du giver dem.

Nej, det falder tilbage på de mennesker, der sidder internt i virksomheden, og skal holde styr på det, at de rent faktisk gør det rettidigt, og sørger for at opdatere tingene.

Ja, så teknikken er der, men det kræver noget af din organisation.

Og så er vi jo også begyndt at se på nogle kunder i vores forretning, som sælger noget, de producerer. Altså, hvor de ikke har det på lager egentlig, men de har en bill of materials, samleorder, eller hvad det nu hedder, de her begreber, men hvor de først, når du trykker bestil, går i gang med at male kaffen, eller samle maskinen.

Ja, og der kan man sige, at egentlig har man måske uanede lager, fordi man har adgang til et eller andet råstof, som man har uanede af, men hvis det kræver, at du skal bruge noget maskine tid på 10 minutter, så kan du ikke tage imod uanede, så du er stadig nødt til at sige, at så skal du bruge lidt længere tid.

Så der kan komme noget tidsfaktor ind i budget også, hvor du er nødt til at tage udgangspunkt i, jamen okay, jeg bestiller så mange, og hvor lang tid vil det så tage? Så der skal du begynde at regne baglæns lige pludselig, og så kunne sige, at så kan jeg cirka levere det hertil. Så det er jo en helt anden måde at se det på.

Vi kan først fortælle, hvornår du kan få det, når du fortæller os, hvor meget du skal bruge.

Er der andet, du tænker omkring lager, som er vigtigt, når man begynder at snakke e-handelsløsninger?

Man skal have styr på sin arbejdsgang, og så bruge systemet til det, det kan. Det kan rent faktisk godt gå ud og lave de her MRP-planlægning, hvilket vil sige, at den kan godt regne for dig, hvad du skal bruge, hvis du sætter sådan nogle genbestillingspunkter ind på dine varer, eller du bestiller måske kun til ordre, eller du gør nogle andre ting, men det kræver, at du har sat det hele op.

Hvis du gør det, så kan den faktisk beregne hele tiden, hvad du står og mangler, og hvis du har sat det sådan 100% op, så kan du faktisk også få den til at sende en ordre til din leverandør uden at der egentlig har været menneskehænder på. Så det er ikke den del, der er den svære.

Jeg har været med til at lave et system, hvor man tog nogle varer, der blev brugt af teknikere, og de afskrev da man brugte dele. Om natten, eller faktisk om aftenen, der blev der beregnet, hvad de så manglede, så blev der sendt en ordre afsted ned til et stort lag i Tyskland, og så næste morgen, der stod varerne faktisk i systemet.

Der var ikke nogen, der var på arbejde om natten, men det kan systemet altså godt, og det er faktisk standard, det meste af det.

Så hvis vi skal have en webshop til både B2B og B2C, men især B2B-shopsne, som jo ofte har det her krav med, at hvis det ikke er på lager, så skal de vide, hvornår de kan få det, eller det kan være kampangevarer til julehandlen, hvor de skal vide, hvor mange der egentlig er til rådighed, og hvor mange af dem jeg så kan få lov til at købe til den der kampagne, og det høre jeg dig sige, at systemerne godt kan.

Men jeg hører dig også sige, som jeg selv har oplevet gennem 20 år, at det stiller enormt store krav til menneskerne ude bag ved systemerne, at de får nogle arbejdsgange, nogle processer, og får øvelse i det her.

Så budskabet er vel i virkeligheden, at det kan godt lade sig gøre, men prøv lige at kigge indad og se hvad i egentlig er klar til, inden jeg siger, hvad I skal have.

Og så at folks rolle har ændre sig. Altså det kan godt være, at indkøberens rolle ikke længere bliver at sidde og lave indkøbsordre, men i stedet bliver i højere grad at sidde og vedligeholde varestamdata, så indkøbsordren kan blive dannet automatisk, for eksempel. Og det er jo en rolleændring, man også skal være klar på.

Nu vil Sune gerne hoppe ind i Business Central og vise noget lagerstyring og tage nogle af de emner op, som er vigtige, når du har en e-commerce shop.

Så når man skal til at lave en webshop, så er noget af det, som vi jo altid hører fra kunderne at de vil med deres webshop, det er jo sådan noget med disponibel beholdning.

Altså når jeg går på en e-commerce-shop, og skal købe en cykel eller et par bukser, så skal jeg vide, om den er på lager, om jeg kan forvente at få den, eller hvornår jeg kan forvente at få den.

Og når man står som kunde og er inde på en webshop, og det har vi alle sammen prøvet og skulle købe noget, så er det faktisk ret nemt, for det er et meget simpelt spørgsmål. Er den der? Er den der ikke? Og hvis ikke den er der, hvornår kan jeg få den? Det er faktisk bare det, kunden gerne vil have. Så det er sådan kun tre spørgsmål. Det er meget nemt.

Men i virkeligheden er det mega kompliceret. Jeg skal vise jer inde i Business Central, hvorfor den kompleksitet opstår. Før jeg viser det, så vil jeg prøve at forklare lidt om, hvad det handler om.

Lad os forestille os, at vi har både en B2C-shop og en B2B-shop, og vi har måske lager liggende i nogle af de store detailkæder rundt i området. Og vi har også sælgere, som sælger direkte, og som tager telefonkald.

Så vi har varer på lagret, som vi distribuerer ud via mange kanaler, eller distributionskanalen er den samme, men ordrerne kommer ind via mange kanaler.

Det vi typisk oplever, det er at kunden, altså os, vil sige at vi har behov for, at når det er B2B-shoppen, så skal den gøre sådan her, og når det er B2C-shoppen, så skal den gøre sådan her. Der er altså forskellige krav til, hvad man må inkludere.

Lad os sige, at jeg går ind og køber et par bukser på en hjemmeside. De er ikke på lagret, men der står forventet på lager om 14 dage. Det er nok til, at jeg køber og tænker, at det kan jeg godt leve med. Så jeg lægger min ordre.

Men det, det i virkeligheden betyder, er, at den ikke ligger på lagret, hvor de skal sende den fra. Så de må jo forvente at få den hjem om 14 dage. Ergo må der ligge en købsordre, en overflytningsordre eller en produktionsordre, hvis de selv laver dem, i hvert fald en eller anden tilgang på lagret, som de forventer.

Og i virkeligheden er det jo nok ikke om 14 dage, fordi hvis jeg skal have den om 14 dage, eller de skal sende den om 14 dage, så er det jo nok om 11 dage, eller om 5 dage, afhængig af om det er fra Kina, og om hvor meget usikkerhed de har på deres levering.

Så når man kigger ind i systemet, så er hele den der kompleksitet omkring, hvad skal jeg tage med i min beregning af beholdning, og hvad jeg ikke skal tage med, den er rigtig, rigtig stor.

Så den nemme måde, vi ser mange løse det på, det er simpelthen at allokere lagre. Altså man fysisk siger, der er 800 på lagret. Vi rykker nogle ud på en lokation, som vi har allokeret til vores web.

I mange hensigter er det en dårlig løsning, og jeg skal nok sige hvorfor, men jeg rykker det ud på en lokation, som er allokeret til min B2C shop. Så ligger der 50, som jeg har rykket derud. Det betyder, når du køber på nettet, så er der enten 50, eller også er der ikke. Så enten er den der, eller også er den der ikke. Og det gælder både B2C og B2B, fordi så har jeg allokeret varen til det her behov.

Problemet er, at jeg løber tør og ingen når at opdage det, og jeg sidder med en kunde, der gerne vil købe den, og den er ikke på lagret, men på den anden lokation, jeg havde lagt varer over på, der er der masser af dem. Så er det lidt ærgerligt at tabe det køb, fordi jeg ikke kan finde ud af at lave den simple matematik inde i ERP-systemet.

Så i princippet vil vi gerne have det hele til at ligge på samme lokation i ERP-systemet, men regne forskelligt i forhold til hvor jeg spørger fra, så jeg kan styre usikkerhederne i forhold til den forespørgsel, jeg får.

Det næste problem er nemlig det med at lægge varen i kurven. Altså når jeg på shoppen lægger varen i kurven, er den så allokeret til mig, eller er den ikke? For i princippet kan jeg jo sidde og bygge en kurve op. Hvis nu jeg handler hos et firma, der leverer dagligvarer, og som kører dagligvarer hjem, så lukker jeg jo måske kurven en gang om ugen, og det vil sige om onsdagen har jeg puttet noget i min kurve, som faktisk ikke er røget over i det ERP-system. Det kommer først på fredag. Når jeg siger, yes sir, luk den der, og så er den vare for længst røget ud af lagret, og ikke disponibel mere, så får jeg at vide på fredag, at alle de her 17 varer, jeg havde bestilt, de var der altså ikke mere. Så den konflikt vil vi også gerne håndtere.

Lad os lige prøve at kigge ind i Business Central, hvordan det foregår. Så skal jeg komme med nogle eksempler.

Det I ser her, det er en salgsordre, som jeg har åbnet, og jeg bare lige har oprettet, eller jeg har lavet en ny salgsordre til en eller anden kunde med en eller anden vare. Jeg har ikke tastet et antal endnu, og hvis jeg kigger herude til højre, så kan jeg se, at den jeg har bestilt, den skal kunne leveres den 21/11-21. Så det er den forventning, jeg sidder med her, hvis jeg kigger på varens lagerprofil, og jeg skal finde ud af, om jeg kan levere den her vare, eller om jeg ikke kan. Og vi har jo selvfølgelig nogle apps til det her, og der er også noget standard funktionalitet i Business Central availability til det.

Så den nemmeste beregning, det er simpelthen bare at sige, er der nogen til rådighed på lageret, eller er der ikke? Hvis ja, og man kan lave en simpel behovsberegning, tag alt, hvad der er på behovsordre, altså salgsordre, udgående overflytningsordre, produktionsordre, komponenter osv., minus det, der er på lager. Hvis det er et positivt tal, så må jeg gerne spise den. Det er den meget nemme beregning.

Nu skal vi se på, hvad vi ser i praksis. Jeg åbner lige en app, der hedder Grafisk Lagerprofil. Den ligger herude, Graphical Inventory Profile. Det er en app, som er gratis, så man kan bare hente den på AppSource, og det den kan, det er, at den kan tegne en profil over den her vare. Så her kan jeg se, med alle de her prikker her, der kan jeg se, hvad min lagerbeholdning er, og den er 43. Så kommer der på et eller andet tidspunkt her, den 30. oktober, der kommer der 8 mere på lager, så ryger jeg på 51. Så herude ligger der en salgsordre, så ryger jeg ned på 41. Så her kan jeg se alle mine ordre. Og nu er det her en meget kompleks vare, men bare for at give billedet.

Så det interessante er her, at den 26. august, der ryger jeg faktisk ned på minus 36, så hvis jeg skal levere den der salgsordre, det kan jeg ikke. Så alt det hernede, det ryger nu teoretisk i minus. Til gengæld så kommer der en købsordre hjem her, den 19. november 2021, og så ryger jeg op på 26. Så ud fra en availability betragtning, burde jeg nemt kunne sælge 20 på den her dato, som var den 21. november.

Så hvis jeg ser på den grafiske lagerprofil nu, så vil jeg derovre i november, i stedet for at ryge op på det, jeg gjorde før, 46 eller hvad der var, så ryger jeg op på 26 i stedet for. Så jeg kan altså matematisk styre det her.

Men virkeligheden er jo, at da jeg skød den her beregning afsted, der havde jeg jo bedt den om, hvad den skal tage med. Så det billede, vi ser her nu, der er altså en ultimo lagerbeholdning på minus 26. Og i virkeligheden det jeg gjorde, hvis jeg lige kører beregningen igen, så kan I se her, at det er faktisk alle de hakker, jeg sætter. Hvad vil jeg gerne tage med? Må jeg tage indgående overflytningsordre med?

Så hvis nu der på onsdag kommer nogen hjem, som bliver overført fra en anden lokation, jeg har, må jeg tage dem med i betragtning i den her beregning, eller er det for usikkert? Må jeg tage købsordre med? I så fald må jeg tage alle købsordre med? Eller må jeg kun tage dem med, der er frigivende?

Må jeg altså købstilbud med endda? Det ville jeg jo nok ikke vælge i det scenario her. Hvad for nogle købsordredatoer skal jeg regne med? Skal jeg regne med det, som vi har bestilt hos leverandøren? Eller skal jeg regne med bekræftede dato? Eller skal jeg, hvis ikke der er nogen bekræftet dato, skal jeg så skubbe den til enden af den periode, jeg sidder og regner på?

Inde i min omsætning, og det er så til den her app, der hedder Graphical Inventory Profile, og I kan se på listen her, der er også andre apps, som bruger den samme algoritme, altså den vi her kalder Assign Quantity (tildel antal), den bruger faktisk samme algoritme til at kunne regne forskelligt, så jeg kan altså regne på forskellige måder til forskellige segmenter.

Så hvis jeg nu tager den her Grafisk Lagerprofil og kigger ind i den, hvad er det for nogle hakker, der kan sættes her? Så alt det her, det er faktisk hakker, som afgør, hvordan du vil regne availability for den her bruger, eller med den her omsætning.

Må du tage, som sagt, transferordre med? Hvordan vil du beregne med dato? Vil du tage alle salgsordene med i din beregning? Hvis du bruger Assign Quantity, altså tildel antal på salgsordre, skal den så kun regne med det, der er tildelt, eller skal den regne med hele mængden? osv.

Så hver gang jeg kører den her grafiske ting, som vil være den samme regnemotor, som jeg bruger på webshoppen, så vil jeg gå ud fra, at min lagerprofil ser noget anderledes ud.

Så faktisk, hvis jeg kun sælger det, jeg har lovet mine kunder, så havner jeg altså på et slutlager på 62. Hvorimod hvis jeg sælger alt det, som kunderne rent faktisk har tastet på ordren, så ryger jeg altså ned på det her lager, vi havde før på minus 26.

Så kompleksiteten, det er faktisk ikke matematikken, fordi det her er der jo bygget software til, det er jo bare at sætte plusser og minusser på.

Kompleksiteten er, når vi spørger sælgeren eller indkøberen ude i butikken, hvad de gerne vil have, den skal gøre, så kan de ikke svare. Så vil de sige, at den selvfølgelig skal tage købsordner med. “Altid?” “ja ja, også dem fra Italien. Eller når nej, ikke dem fra Italien, fordi det er noget helt skidt, og der er noget galt i Nord-Italien, så dem må I ikke regne med. Men altså alle de købsordre, som er fra hele verden, bortset fra Italien og bortset fra dem, der kommer hjem med lastbil, og bortset fra varer, som er grønne osv..”

Det er jo det, vi ofte oplever, at man sidder med i den rigtige virkelighed og gerne vil forholde sig til. Det er altså ikke systemet, der sætter begrænsninger, det er faktisk virkeligheden, altså de folk, der sidder med det, som tænker, hvad det er egentlig, de gerne vil kunne love kunderne.

Så øvelsen her, det er faktisk at tage en tavle og en tusch, og så dem af jer, der skal beslutte det her, tag et segment ad gangen. Vores B2B-shop, hvad skal den? Og så tegner i simpelthen bare. Må den kun regne med eksisterende lagerbeholdning, og skal alt, hvad der ligger af demands i forvejen, altså af afgangen, være taget med i betragtning? Det er den nemmeste beregning. Der er 100 på lager, der er så mange salgsordre, så mange udgående transporter, så mange osv. plus minus, så har du dit disponible lager.

Eller, hvad må den tage med af forventede tilgange, og hvad må den regne med af datoer? For næste problem er også, at der er 100 på lager, der er 80 salgsordrer, så er der kun 20 tilbage. Men det er der ikke helt, fordi ud af de 80 salgsorder, så ligger de 60 af dem først om et halvt år, og der kan vi rigeligt nå at få dem hjem igen.

Okay, så hvor lang tid skal den så regne frem, for hver af de her behovstyper, altså salgsordre, transferorders osv.?

Så det er faktisk det svære af det her, det er faktisk at blive enige og tegne på tavlen. Når først du er blevet enig, så kan man tage fat i sin ERP-konsulent og sige, at nu har vi fundet ud af, hvad den skal gøre.

Og så kan man få webshoppen til at, kalde ind i ERP-systemet, lave den beregning, skyde tilbage igen.

Så, altså, to ting.

Bliv enig om, hvad I gerne vil have, den skal gøre. Det er den første vigtige ting.

Og den anden ting er den her kurv-betragtning, hvor hvis man skal være rigtig smart, når man laver det her, og man virkelig gerne vil have, at når folk har puttet noget i kurven, så skal det virke, så anbefaler vi, at man simpelthen laver en salgstilbudlinje i ERP-systemet, så vi har data til rådighed.

Så i det øjeblik nogen har puttet den her vare i deres kurv, 20 stykker, og vi inkluderer salgstilbud i vores beregning her, så når der bagefter er en, der putter noget i kurven med 5 stykker, så vil den med det samme kunne regne og sige, nix, det kan du ikke få, fordi der er lige blevet spist af de 20.

Men det er klart, når jeg så ikke committer min kurv og siger, at jeg dropper det her alligevel, så skal det salgstilbud selvfølgelig slettes igen.

Det er den ultimative løsning, det er også den, der kræver mest online-dialog hele tiden mellem webshoppen og ERP-systemet, så oftest vil man finde mere pragmatiske løsninger og sørge for, at man har vare nok, og sørge for at allokere det på bestemte måder.

Men diskussionen, den starter oppe på tavlen med en whiteboard-tusch.

Take it away, held og lykke med at få lavet en rigtig fin beslutning, som passer lige præcis til jeres e-commerce løsninger.