Ett kalkylblad är ett fullt rimligt sätt att hantera lager på, ända fram till den punkt då det inte längre är det.
Övergången märks sällan när den sker. Det som oftast händer är att ett kalkylblad fungerar bra i ett år, verksamheten växer, och filen slutar i tysthet att vara tillförlitlig – men eftersom den alltid har funnits där och alla vet hur den fungerar, fortsätter den att användas långt efter att felen börjat kosta mer än vad ett programvarusystem skulle ha gjort.
Den här guiden går igenom hur du bygger ett kalkylblad som fungerar, och lika viktigt, hur du känner igen när du har vuxit ifrån det.
När ett kalkylblad är rätt verktyg
Ett kalkylblad passar dig om de flesta av dessa påståenden stämmer:
- En person sköter det. I samma ögonblick som två personer redigerar samma fil börjar versionerna att divergera.
- Du säljer via en kanal. Försäljning via flera kanaler innebär att en lagersiffra ska räcka till flera ställen, och ett kalkylblad kan inte uppdatera en marknadsplatsannons när något säljs via din webbplats.
- Under cirka några hundra SKU. Utöver det blir det ett heltidsjobb att bara hitta och uppdatera rader.
- Lagerförflyttningar går att räkna för hand — tiotals per dag snarare än hundratals.
- Du behöver inte spåra batch, serienummer eller utgångsdatum. Dessa är nästintill omöjliga att hantera manuellt med någon form av säkerhet.
- Konsekvensen av ett fel är hanterbar. Om ett lagerfel innebär en ursäkt är det okej. Om det innebär ett brott mot regelefterlevnad är det inte det.
Det är också rätt verktyg när du håller på att utvärdera vad du faktiskt behöver. Att bygga ett kalkylblad tvingar dig att bestämma vad som ska spåras, och den tydligheten gör ett senare val av programvara betydligt mer välinformerat.
Kolumnerna ditt kalkylblad behöver
Börja med dessa. Undvik att lägga till fler förrän du har använt det i en månad.
Identifiering
- SKU — din unika kod. En per säljbar variant. Det är kolumnen som allt annat hänger på, så bestäm formatet innan du börjar istället för att låta det växa fram organiskt.
- Produktnamn — en beskrivning som är lätt att läsa för människor.
- Kategori — för gruppering och filtrering.
- Streckkod — om dina produkter har en, så att du kan söka genom att skanna.
- Plats — var den finns. Även i ett litet lager är “Hylla C3” bättre än “någonstans där bak”.
Kvantiteter
- Lagersaldo — nuvarande fysiskt lager.
- Allokerat antal — reserverat för ordrar som ännu inte skickats.
- Tillgängligt antal — lagersaldo minus allokerat. Detta är siffran som betyder något för försäljningen, och den som de flesta kalkylblad utelämnar.
- Antal i beställning — lagt hos leverantörer, ännu ej mottaget.
Återbeställning
- Återbeställningspunkt — nivån som utlöser en ny beställning.
- Återbeställningskvantitet — hur mycket som ska beställas när det väl sker.
- Ledtid i dagar — uppmätt, inte uppskattad.
- Leverantör — vem du köper den ifrån.
Ekonomi
- Enhetskostnad — landad kostnad inklusive frakt och tull, inte bara fakturapriset.
- Försäljningspris.
- Lagervärde — lagersaldo multiplicerat med enhetskostnad.
Administration
- Datum för senaste inventering — så att du kan se vad som inte har verifierats nyligen.
- Datum för senaste rörelse — för att identifiera dött lager.
- Anteckningar — för allt som inte passar in någon annanstans.
Två formler som gör det användbart
Ett kalkylblad som bara registrerar siffror är bara en lista. Dessa två förvandlar det till ett verktyg.
Tillgängligt lager:
= [Lagersaldo] – [Allokerat antal]
Enkelt, och den enskilt mest användbara beräknade kolumnen. Att sälja utifrån lagersaldo istället för tillgängligt antal är hur du råkar lova bort lager som redan är reserverat för någon annan.
Markering för lågt lager:
= OM([Tillgängligt antal] + [Antal i beställning] <= [Återbeställningspunkt]; "BESTÄLL"; "")
Tillägget av antal i beställning är det som hindrar den från att be dig beställa något du redan beställde förra veckan. Utan den termen förblir markeringen aktiv tills leveransen anländer, och folk lär sig att ignorera den.
Två till som är värda att lägga till när grunderna fungerar.
Lagervärde:
= [Lagersaldo] * [Enhetskostnad]
Summerat över hela arket är detta din lagerinvestering — en siffra många småföretag aldrig faktiskt har räknat ut.
Täckningsdagar:
= [Tillgängligt antal] / [Genomsnittlig daglig förbrukning]
Mer informativt än en rå kvantitet, eftersom 40 enheter betyder något helt annat för en produkt som säljer två i veckan än för en som säljer tjugo om dagen.
Lägg till villkorsstyrd formatering så att rader med lågt lager färgar sig själva, och sortera eller filtrera arket så att markerade rader hamnar högst upp. En markering som ingen ser är ingen markering.
Hur du håller det korrekt
Detta är delen som avgör om kalkylbladet är användbart eller aktivt missvisande.
Uppdatera vid tidpunkten för rörelsen. Inte i slutet av dagen, inte från ett anteckningsblock. Varje timmes fördröjning ökar risken för fel, och att uppdatera från minnet i slutet av dagen är den enskilt största källan till felaktigheter i lagerhantering baserad på kalkylblad.
En person äger det. Om flera personer behöver uppdatera det, använd ett molnbaserat ark med äkta stöd för flera användare istället för att mejla en fil fram och tillbaka. Versioner av en lagerfil som lever i olika inkorgar är det klassiska misslyckandet.
Inventera regelbundet. Rullande inventering av en del varje vecka — en hylla eller en kategori — istället för att försöka göra allt på en gång. Registrera datumet i kolumnen för senaste inventering så att luckor blir synliga.
Logga justeringar separat. Ha en andra flik som registrerar varje korrigering med datum och orsak. Mönstret i dessa orsaker är där dina processfel finns, och att skriva över en cell förstör den informationen permanent.
Skydda formelcellerna. Det vanligaste sättet ett fungerande kalkylblad går sönder på är att någon skriver ett nummer ovanpå en formel. Lås dem.
Säkerhetskopiera automatiskt. Molnlagring med versionshistorik, så att en oavsiktlig radering eller en felaktig inklistring kan ångras. Lokala filer utan historik är hur ett års arbete försvinner.
Sortera aldrig utan att markera allt. Att sortera en kolumn och lämna de andra på plats blandar ihop varje rad, och det är skrämmande lätt att göra utan att märka det.
Strukturera filen korrekt
De flesta kalkylblad misslyckas strukturellt snarare än genom dåliga formler. Fyra flikar, var och en med en uppgift, undviker nästan allt detta.
Flik 1 — Produkter. En rad per SKU, som innehåller det som sällan ändras: namn, kategori, streckkod, leverantör, enhetskostnad, försäljningspris, återbeställningspunkt, återbeställningskvantitet, ledtid. Detta är din referensdata, och inget här bör redigeras under daglig användning.
Flik 2 — Lager. Aktuell position per SKU: lagersaldo, allokerat, tillgängligt, i beställning, plats, senast inventerad. Detta är fliken folk tittar på.
Flik 3 — Rörelser. Varje mottagning, försäljning, justering och överföring, en rad vardera, med datum, SKU, kvantitet, riktning och orsak. Endast tillägg — redigera eller radera aldrig en rad.
Flik 4 — Leverantörer. Kontaktuppgifter, ledtider, minsta orderkvantitet, betalningsvillkor.
Fliken för rörelser är den som folk utelämnar, och det är den mest värdefulla. Utan den har du en aktuell position och ingen historik, så när en siffra är fel finns det inget att undersöka. Med den kan du spåra hur en siffra blev vad den är, och du kan beräkna genomsnittlig förbrukning för återbeställningspunkter från faktiska data istället för från någons intryck.
Det ändrar också hur lagerfliken fungerar. Istället för att skriva över kvantiteten varje gång något rör sig, blir lagersaldot en beräkning:
= SUMMA.OM(Rörelser[SKU]; [@SKU]; Rörelser[Kvantitet])
med mottagningar som positiva och försäljningar som negativa. Ingen skriver över någonting, varje ändring registreras, och den aktuella positionen härleds istället för att underhållas. Det enskilda strukturella beslutet eliminerar den vanligaste orsaken till att lagerhantering i kalkylblad blir otillförlitlig.
Två stödjande vanor: använd ordentliga namngivna tabeller istället för råa cellområden, så att formler fortsätter fungera när rader läggs till; och använd datavalidering på SKU-kolumnen i rörelsefliken, så att ett skrivfel inte kan skapa en spökprodukt.
Ett praktiskt exempel
Anta att du lagerför en produkt med följande status:
- Antal i lager: 240
- Allokerat till ej levererade order: 55
- Beställt från leverantör: 0
- Genomsnittlig daglig förbrukning: 12
- Leverantörens ledtid, uppmätt: 9 dagar
- Säkerhetslager: 45
Tillgängligt lager är 240 − 55 = 185 enheter. Det är vad du faktiskt kan lova, inte 240.
Beställningspunkt är (12 × 9) + 45 = 153 enheter.
Täckningsdagar är 185 ÷ 12 = cirka 15 dagar.
Du ligger alltså över din beställningspunkt med ungefär två veckors täckning, och flaggan för lågt lagersaldo förblir korrekt inaktiverad. Sälj nu 40 enheter: tillgängligt antal sjunker till 145, vilket är under beställningspunkten på 153, och flaggan aktiveras. Du skapar en inköpsorder för din beställningskvantitet, anger den i kolumnen för beställt antal, och flaggan försvinner – eftersom formeln inkluderar beställt lager kommer den inte att fortsätta varna medan leveransen är under transport.
Poängen med att gå igenom detta är att de fyra kolumnerna samverkar. Verksamheter som bara spårar antal i lager ser 240 enheter och inga problem, trots att 55 av dessa redan är sålda och den verkliga situationen är betydligt mer ansträngd än vad den ser ut att vara.
Ett enkelt arbetsflöde för inventering och räkning
Ett kalkylblad förblir bara korrekt om något regelbundet kontrollerar det mot hyllan. Här är ett arbetsflöde som tar under en timme i veckan och fångar upp nästan allt.
Lägg till tre kolumner i ditt ark: Räknat antal, Datum för räkning och Avvikelse (en formel: räknat antal minus det antal som ditt ark anger att du har).
Välj vad som ska räknas denna vecka. Inte allt. Ta dina 20 främsta artiklar baserat på värde eller försäljning och räkna dem varje vecka. Ta resten och räkna ett roterande urval – en tiondel i veckan innebär att allt kontrolleras ungefär kvartalsvis, vilket räcker för lagervaror med låg omsättningshastighet.
Skriv ut en blind inventeringslista. Filtrera fram de rader du räknar och skriv ut eller exportera endast produkt, beskrivning och plats – aldrig det förväntade antalet. Människor bekräftar det de visas, så en blind räkning är den enskilt största vinsten i noggrannhet som finns tillgänglig och den kostar ingenting.
Räkna per plats, inte per produkt. Gå längs hyllorna i ordning och räkna vad som finns på varje plats. Om en produkt förvaras på två platser, registrera två rader. Att räkna per produkt inbjuder den som räknar att sluta leta så fort siffran stämmer.
Ange antalen och titta sedan på avvikelsekolumnen istället för att justera löpande.
Räkna om allt med en betydande avvikelse innan du ändrar en siffra. Den andra räkningen avviker tillräckligt ofta från den första för att justeringar baserade på en enda räkning skapar fel snarare än åtgärdar dem.
Utred innan du justerar. Kontrollera nästa hyllsektion, returhögen, packbordet och de senaste transaktionerna. En stor del av de skenbara förlusterna är varor som hamnat på fel plats.
Uppdatera sedan antalet och notera varför i en anteckningskolumn – plockfel, mottagningsfel, skada, oregistrerad försäljning eller okänt. Två veckors orsaks-koder pekar oftast rakt på en process som behöver åtgärdas.
Stämpla datumet. En kolumn för datum för räkning visar dig med en blick vad som inte har kontrollerats på månader, vilket är där nästa fel gömmer sig.
En fullständig inventering av allt, en eller två gånger om året, har fortfarande sin plats för bokföringen. Den veckovisa rutinen är det som håller siffrorna användbara däremellan, och den gör den årliga inventeringen betydligt mindre smärtsam eftersom de stora överraskningarna redan har hittats.
För- och nackdelar med att hantera lager i ett kalkylblad
En ärlig bedömning, eftersom kalkylblad både översäljs och orättvist avfärdas.
Fördelarna.
- Det kostar ingenting, och du vet redan hur man använder det.
- Det är helt flexibelt. Vilken kolumn du vill, vilken beräkning som helst, ingen väntan på att en leverantör ska lägga till en funktion.
- Det är omedelbart. Du kan ha ett fungerande lagerark i eftermiddag, medan mjukvara tar veckor.
- Det tvingar dig att förstå dina egna siffror. Att bygga beställningsformeln själv lär dig mer om ditt lager än någon instrumentpanel någonsin kommer att göra.
- Det är portabelt. Din data är din, i ett format som alla kan läsa, utan kontrakt och utan migrering om du lämnar.
- Det är genuint tillräckligt i liten skala. Några hundra rader, en plats, en eller två personer – ett välskött ark kommer inte att hålla dig tillbaka.
Nackdelarna.
- Realistiskt sett en person åt gången. Delade molnark hjälper, men två personer som redigerar samma rader under en hektisk period orsakar fortfarande förluster.
- Ingen riktig granskningslogg. Du kan se att en siffra ändrades. Du kan oftast inte se vem som ändrade den, när, eller vad den var innan.
- Tysta fel. En formel som dragits en rad för kort, en kolumn som sorterats utan sina grannar, ett värde som skrivits över en formel. Ingenting varnar dig, och arket fortsätter att producera självsäkra, felaktiga svar.
- Ingen koppling till var du säljer. Varje försäljning måste matas in för hand, vilket innebär att arket alltid är något inaktuellt och översäljning är bara en tidsfråga.
- Det skalar inte. Prestandan försämras, och ännu viktigare: den manuella inmatningsbördan växer i direkt proportion till din ordervolym, vilket är precis fel riktning när du växer.
- Ingen streckkodsskanning vid rörelsetillfället, vilket är där de flesta lagerfel faktiskt förhindras.
- Det förlitar sig helt på disciplin. Arket är bara korrekt så länge varje person uppdaterar det varje gång, och hektiska veckor är precis när det slutar hända.
Den rättvisa sammanfattningen: ett kalkylblad är rätt svar i början och en belastning efter en viss punkt, och brytpunkten kommer tidigare än de flesta förväntar sig – vanligtvis första gången du lägger till en försäljningskanal eller en andra person som behöver samma siffror.
Begränsningarna med ett kalkylblad
Värt att känna till innan du når dem:
Ingen synkronisering i realtid mellan flera kanaler. Om du säljer på din egen webbplats och en marknadsplats uppdateras ingenting när det säljs på den andra. Översäljning följer.
Ingen transaktionshistorik. En cell visar vad siffran är nu, inte hur den blev det. När en siffra är fel kan du inte se när eller varför.
Ingen streckkodsskanning. Varje rörelse skrivs in, och det är vid inmatning som fel uppstår.
Inga användarbehörigheter eller granskningslogg. Alla med filen kan ändra vad som helst, och ingenting registrerar vem som gjorde det.
Inga automatiserade varningar. Flaggan för lågt lagersaldo fungerar bara om någon öppnar filen och tittar.
Skört i stor skala. Stora ark med många formler blir långsamma, och risken för en felaktig sortering eller en överskriven formel ökar med storleken och antalet inblandade personer.
Ingen spårning av batch, serienummer eller utgångsdatum på ett sätt som du kan lita på.
När man bör gå över till mjukvara
Signalerna, ungefär i den ordning de dyker upp:
- Du säljer i mer än en kanal. Detta är oftast den avgörande punkten, eftersom manuell synkronisering inte skalar bortom ett fåtal artiklar.
- Mer än en person behöver uppdatera lagret.
- Du har översålt, och särskilt om det har hänt mer än en gång.
- Du lägger mer än en timme om dagen på kalkylbladet. Vid den punkten är abonnemanget billigare än din tid.
- Du kan inte svara på “vad hade vi i lager i tisdags?” eftersom det inte finns någon historik.
- Du behöver spårning av batch eller utgångsdatum av regulatoriska skäl.
- Inventering har blivit en omfattande övning eftersom sortimentet har vuxit.
Att byta system innebär inte att arbetet med kalkylbladet var förgäves. Ett rent, välstrukturerat ark är precis vad en migrering behöver, och disciplinen att ha underhållit ett gör det nya systemet lättare att konfigurera eftersom du redan vet vad du spårar och varför.
Att byta till programvara utan att förlora något
När kalkylarket har gjort sitt går övergången smidigare om arket har underhållits korrekt – och sämre om det inte har gjorts, eftersom allt som är felaktigt importeras.
Städa innan du migrerar. Dubbletter av SKU, produkter som utgick för två år sedan, rader utan kostnad eller leverantör, inkonsekventa kategorinamn. Att migrera detta innebär att du återskapar det i ett system du nu betalar för. Detta är steget som tar tid, och det är oundvikligt.
Standardisera SKU-formatet först. Om koder har vuxit organiskt – vissa med bindestreck, vissa med mellanslag, vissa med avslutande tecken som ingen kan förklara – fixa det i kalkylarket där sök-och-ersätt är trivialt, snarare än efter importen där det inte är det.
Fyll i dimensioner och vikter. De flesta system kräver dem, de flesta kalkylark saknar dem, och att samla in dem tar tid. Att börja innan du väljer ett system eliminerar den vanligaste orsaken till en försenad driftsättning.
Inventera omedelbart före övergången. Att importera kvantiteter som du inte litar på garanterar att det nya systemet är felaktigt från dag ett, och teamet kommer att dra slutsatsen att det är programvaran det är fel på.
Behåll kalkylarket skrivskyddat i en månad. Inte som ett parallellt system – det skapar dubbelregistrering och avvikelser – utan som en referens för att kontrollera allt som ser fel ut i det nya systemet.
Importera rörelsehistorik om du kan. Många system accepterar en transaktionsimport, och att ha tolv månaders användningshistorik från dag ett innebär att beställningspunkter och prognoser fungerar omedelbart snarare än efter ett år av datainsamling.
Ett välskött kalkylark är en bra källa för migrering. Kolumnerna i den här guiden motsvarar nästan direkt de fält som alla lagersystem kommer att efterfråga, vilket inte är en slump – samma information behövs oavsett, och skillnaden ligger i vem som sköter beräkningarna.
Fördjupning
- Hur man hanterar lager – processen som kalkylarket stöder.
- Lagerhantering för småföretag – helhetsbilden i denna skala.
- Molnbaserad lagerhantering – det vanliga nästa steget.
- Vad är en beställningspunkt – beräkningen bakom flaggan.
- Hur man spårar lager – metoder utöver ett kalkylark.
- Vad är ett SKU – få rätt på identifieraren innan du bygger.
Kärnan i ett nötskal
Ett kalkylark fungerar för en verksamhet med en försäljningskanal, några hundra SKU och en person som underhåller det – bygg det kring tillgängligt lager snarare än lager i handen, uppdatera vid varje rörelse, och byt till programvara när du börjar sälja via en andra kanal.
Vanliga frågor
Kan jag hantera lager med ett kalkylark? Ja, för ett företag med en försäljningskanal, ett blygsamt sortiment och en person som underhåller filen. Det slutar vara hållbart när flera kanaler, flera användare eller regulatoriska spårbarhetskrav tillkommer.
Vad bör ett lagerkalkylark innehålla? SKU, produktnamn, kategori, lagerplats, kvantitet i lager, reserverad kvantitet, tillgänglig kvantitet, kvantitet i beställning, beställningspunkt, beställningskvantitet, ledtid, leverantör, enhetskostnad, försäljningspris och lagervärde, samt datum för senaste inventering och senaste rörelse.
Vad är formeln för en varning om lågt lagersaldo? =IF([Tillgängligt] + [I beställning] <= [Beställningspunkt], "BESTÄLL", ""). Att inkludera kvantitet i beställning förhindrar att systemet flaggar artiklar du redan har beställt, vilket är det som gör att folk slutar lita på varningen.
Hur förhindrar jag att mitt lagerkalkylark blir felaktigt? Uppdatera vid varje rörelse snarare än i efterhand, ha en ansvarig, gör rullande inventering av en del varje vecka, logga justeringar med orsaker på en separat flik, skrivskydda formelceller och säkerhetskopiera med versionshistorik.
När bör jag byta från ett kalkylark till lagersystem? När du säljer via mer än en kanal, när fler än en person behöver uppdatera lagret, när du har sålt slut på lager du inte hade, eller när underhållet av arket tar mer än ungefär en timme om dagen.
Är Excel eller Google Sheets bättre för lager? Google Sheets hanterar äkta fleranvändarredigering och automatisk versionshistorik bättre, vilket löser två av de främsta felkällorna. Excel är snabbare med stora datamängder och har starkare formel- och makrokapacitet. För de flesta små lagerbehov väger samarbetet tyngre.
Hur många SKU kan ett kalkylark hantera? Tekniskt sett tusentals, praktiskt taget några hundra innan underhållet blir själva jobbet snarare än en uppgift inom det. Begränsningen är sällan programvaran – det är tiden som läggs på att hitta rader, den ökande risken för sorteringsfel och svårigheten att inventera ett så stort sortiment för hand.
Kan ett kalkylark hantera flera lagerplatser? Tekniskt sett ja, med en kolumn för lagerplats eller en flik per anläggning, men det blir snabbt otympligt och det finns inget sätt att överföra lager mellan platser med en revisionsspårning. Flera lagerplatser är oftast ett tecken på att du har vuxit ur metoden.
Warehouse Wise är ett kostnadsfritt, oberoende bibliotek med guider om lagerhantering, logistik och orderhantering, skrivet för de som faktiskt utför arbetet — nyanställda inom lager och inventering, små och växande detaljhandels- och e-handelsföretag samt alla som hanterar lager och vill förstå det på djupet. Varje guide förklarar begreppen, visar konkreta exempel med verkliga siffror där det behövs, och håller sig till saken. Vi är oberoende: vi säljer varken programvara eller utrustning, vi tar ingen provision på hänvisningar och våra guider rangordnas inte efter betalning.