Slik bygger du en lagerstyringsapp for en liten bedrift

For å bygge en lagerstyringsapp starter du med fire ting: en liste over varer, mengden av hver vare på hver lokasjon, en logg over hver lagerbevegelse (inn, ut, justert, med en begrunnelse), og varsler ved lav beholdning basert på en bestillingsgrense. En AI-appbygger kan lage databasen, skjermene og varslene fra en enkel beskrivelse. Designvalget som betyr mest er å registrere bevegelser i stedet for bare å overskrive en telling, fordi den historikken er det som gjør at du kan stole på tallene.

Hvorfor små bedrifter bygger sitt eget

De fleste små bedrifter begynner å følge lager i et regneark, og det fungerer til det ikke gjør det. De vanlige bruddpunktene:

• Flere personer oppdaterer arket og overskriver hverandre
• Ingen kan se hvorfor en telling endret seg, eller hvem som endret den
• Noe går tomt før noen merker det
• Lager ligger på mer enn ett sted (butikkgulv, lagerrom, bil, et andre sted)
• Arket har fått instruksjoner om hvordan det brukes

Ferdig lagerprogramvare finnes og er ofte det riktige svaret (se slutten av denne guiden). Folk bygger sitt eget når lageret deres er uvanlig (partier med utløpsdato, varer laget av andre varer, utleie som kommer tilbake), når de bare trenger en brøkdel av et stort produkt, eller når de vil at det skal passe nøyaktig til hvordan teamet arbeider. Hvis du kommer fra et regneark, er slik gjør du et regneark om til en app et nyttig følgeskriv.

Hva appen trenger

Kjernedata

Nøkkelidéen: lagerbeholdningen er resultatet av bevegelser. Hver endring går gjennom en bevegelsespost, og antallet på hylla oppdateres fra den. Det gir deg et revisjonsspor gratis og gjør feil enkle å spore og reversere.

Kjerneskjermer

• Varelisten med søk, kategorifilter og et filter for «lav beholdning»
• Varesiden som viser antall per lokasjon og nylige bevegelser
• Rask justering: motta lager, fjern lager, flytt mellom lokasjoner, registrer en telling
• Visning for lav beholdning: alt på eller under bestillingsgrensen, gruppert etter leverandør
• Tellemodus for periodiske tellinger, som registrerer forskjellen som en justering

Senere, hvis du trenger dem

• Innkjøpsordrer: opprett en ordre til en leverandør, og motta mot den
• Partier og utløpsdatoer for mat, kosmetikk og legemidler
• Stykkliste: et ferdig produkt laget av komponenter, slik at salg av ett reduserer flere
• Rapporter: lagerverdi, varer som beveger seg sakte, bruk over tid (se slik bygger du et dashbord)
• Strekkodeskanning med telefonens kamera

Beslutninger du må ta før du bygger

Hvem er sannhetskilden

Hvis du selger gjennom en nettbutikk eller et kassesystem som allerede sporer lager, bestem hvilket system som eier tellingen. To systemer som begge redigerer de samme tallene vil drive fra hverandre. Alternativer:

1. Appen din er bare for ting butikken ikke sporer (råvarer, forbruksvarer, lager i lagerrommet).
2. Butikken er kilden; appen din leser fra den for rapporter og varsler gjennom API-en.
3. Appen din er kilden og sender tellinger til butikken. Den kraftigste, og den mest arbeidskrevende å få riktig.

Å starte med alternativ 1 eller 2 er mye tryggere.

Hvem kan gjøre hva

Å skjule innkjøpspriser for noen ansatte er et vanlig krav; si det i den første prompten. Ekte tilganger krever app-innlogging, som dekkes i slik legger du til innlogging i appen din.

Telefon eller datamaskin

Lagerarbeid skjer stående: i varemottaket, ved leveransedøra, i bilen. Design justerings- og telleskjermene for telefon først, med store knapper og så lite skriving som mulig. Rapporter og redigering av varer kan være datamaskin-først.

Bygg det steg for steg

Steg 1: Rydd opp i dataene dine

Eksporter regnearket og rydd det før import: én rad per vare, konsistente enheter, unike SKU-er, ingen sammenslåtte celler. Dette tar lengre tid enn folk tror, og sparer mye problemer senere.

Steg 2: Skriv den første prompten

Beskriv virksomheten, lageret, folkene og bevegelsene:

Bygg en lagerapp for Fern & Stone, en plantebutikk med et butikkgulv, et lagerrom og en leveringsbil. Varer har navn, SKU, strekkode, kategori, enhet, innkjøpspris, salgspris, leverandør og en bestillingsgrense. Følg antall per lokasjon. Hver endring er en lagerbevegelse med type (mottatt, solgt, skadet, telt, flyttet), mengde, notat, bruker og tidspunkt — rediger aldri mengder direkte. Skjermer: søkbar varteliste med filter for lav beholdning, varside med lager per lokasjon og bevegelseshistorikk, en telefonvennlig skjerm for rask justering, og en side for lav beholdning gruppert etter leverandør. Ansatte kan ikke se innkjøpspriser; ledere kan. Bruk en database, enkelt og raskt design. La meg importere varer fra en CSV-fil.

Steg 3: Importer og kontroller

Importer den rensede CSV-filen, og sjekk ti varer mot virkeligheten. Feil startbeholdninger vil undergrave tilliten til appen fra første dag, så tell et utvalg av de viktigste varene på den dagen du bytter over.

Steg 4: Test bevegelsene

Motta lager, selg noe, skad en vare, flytt noe til bilen, og gjør en telling som finner to manglende. Kontroller at hver vares historikk forteller riktig historie og at antallet stemmer. Prøv å få antallet under null, og bestem om det skal blokkeres eller flagges.

Steg 5: Legg til varsler og rapporter

En e-post ved lav beholdning eller et daglig sammendrag til lederen er vanligvis det første folk ber om når grunnfunksjonene fungerer. Det krever en e-postleverandør og en planlagt jobb. Deretter en enkel rapport over lagerverdi og en liste over varer som ikke har beveget seg på 90 dager.

Steg 6: Rull det ut på én lokasjon først

Bruk det på ett sted i et par uker, fiks det som er tungvint, og utvid deretter. Den største risikoen er ikke en feil; det er at de ansatte går tilbake til regnearket fordi appen er tregere.

Vanlige feil

• Å bare lagre gjeldende antall. Uten bevegelser kan du ikke svare på «hvorfor er dette feil?»
• La hvem som helst redigere alt. En skrivefeil i en bestillingsgrense eller en slettet vare kan gå ubemerket i ukevis.
• Ignorere enheter. Å kjøpe i esker på 12 og selge enkeltstykker krever en klar regel, ellers blir tellingene feil med en faktor på 12.
• For mange felt på justeringsskjermen. Hvis det å registrere en leveranse tar et minutt, gjør ikke folk det.
• Å bygge toveis butikksynkronisering først. Få appen tillit på egen hånd før du kobler den til noe.
• Behandle den som regnskap. Verdsetting av lager til skatteformål (FIFO, vektet gjennomsnitt) har regler; sjekk med regnskapsfører før du stoler på appens tall i regnskapet ditt.

Når et ferdig produkt er det bedre valget

• Du selger hovedsakelig gjennom én plattform, for eksempel Shopify eller Square. Deres innebygde lagerfunksjoner kan dekke det du trenger, koblet til salget ditt.
• Du trenger lager tett knyttet til regnskap. Regnskapsprogramvare og lagerprodukter bygget for å integreres med den sparer mye avstemming.
• Du har en lageroperasjon med plukking, pakking, fraktetiketter og flere salgskanaler. Dedikerte lager- og varehussystemer er bygget for det.

Bygg selv når lageret ditt ikke passer i disse produktene, når du ville betalt for et stort system for å bruke en liten del av det, eller når prosessen rundt lageret (godkjenninger, jobbskjemaer, utleieretur) egentlig er det du trenger å styre. Vår guide om å bygge eller kjøpe programvare for små bedrifter gjennomgår avveiningen.

Bygge den med Mythex

Mythex er en AI-appbygger: du beskriver lageret, lokasjonene og folkene, og den bygger appen i en live-forhåndsvisning, og legger til en database i prosjektet for varer, lokasjoner og bevegelser. Du kan legge ved et skjermbilde av regnearket du bruker i dag, slik at den ser kolonnene dine, og be om en CSV-import. Varebilder bruker prosjektets fillagring. Hvis butikken eller kassesystemet ditt har et API, kan du lagre nøkkelen i prosjekthemmeligheter og be Mythex lese fra det. Det finnes ikke et innebygd innloggingssystem for de ansatte dine, så app-kontoer og roller bruker et autentiseringsbibliotek eller en leverandør du velger. Dokumentasjonens sider om å bygge et internt verktøy og å bygge en CRUD-app er gode startpunkter.

Til en første prompt du kan redigere, åpne lagersporings-malen, eller les den bredere guiden om slik bygger du et internt verktøy.

Spørsmål