Sådan bygger du en lagerstyringsapp til en lille virksomhed

For at bygge en lagerstyringsapp skal du starte med fire ting: en liste over varer, mængden af hver vare på hver lokation, en log over hver lagerbevægelse (ind, ud, justeret, med en begrundelse) og advarsler ved lav beholdning baseret på et genbestillingsniveau. En AI-appbygger kan lave databasen, skærmene og advarslerne ud fra en almindelig beskrivelse. Det designvalg, der betyder mest, er at registrere bevægelser i stedet for bare at overskrive en optælling, for netop historikken gør, at du kan stole på tallene.

Hvorfor små virksomheder bygger deres egen

De fleste små virksomheder begynder med at følge lageret i et regneark, og det fungerer, indtil det ikke gør. De typiske knækpunkter:

• Flere personer opdaterer arket og overskriver hinanden
• Ingen kan se, hvorfor en optælling ændrede sig, eller hvem der ændrede den
• Noget løber tør, før nogen opdager det
• Lageret står flere steder (butiksgulv, lagerrum, varevogn, en anden afdeling)
• Arket har fået instruktioner om, hvordan man bruger det

Færdig lagersoftware findes og er ofte det rigtige svar (se slutningen af denne guide). Folk bygger selv, når deres lager er usædvanligt (partier med udløbsdatoer, varer lavet af andre varer, udlejning der kommer retur), når de kun har brug for en brøkdel af et stort produkt, eller når de vil have det til at passe præcis til, hvordan deres team arbejder. Hvis du kommer fra et regneark, er sådan gør du et regneark til en app en nyttig følgesvend.

Hvad appen skal kunne

Kernedata

Den centrale idé: lagerbeholdningen er resultatet af bevægelserne. Hver ændring går gennem en bevægelsespost, og antallet på hylden opdateres ud fra den. Det giver dig et revisionsspor gratis og gør fejl lette at spore og rette.

Kerneskærme

• Varelisten med søgning, kategorifilter og et filter for "lav beholdning"
• Varesiden med antal pr. lokation og de seneste bevægelser
• Hurtig justering: modtag varer, fjern varer, flyt mellem lokationer, registrér en optælling
• Visning for lav beholdning: alt ved eller under sit genbestillingsniveau, grupperet efter leverandør
• Optællingstilstand til periodiske optællinger, der registrerer forskellen som en justering

Senere, hvis du får brug for dem

• Indkøbsordrer: opret en ordre til en leverandør, og modtag mod den
• Partier og udløbsdatoer til mad, kosmetik og medicin
• Stykliste: et færdigt produkt lavet af komponenter, så salg af ét reducerer flere
• Rapporter: lagerværdi, varer der bevæger sig langsomt, forbrug over tid (se sådan bygger du et dashboard)
• Stregkodescanning med telefonens kamera

Beslutninger, du skal tage, før du bygger

Hvem er den primære kilde

Hvis du sælger via en webshop eller et kassesystem, der allerede styrer lageret, så beslut, hvilket system der ejer optællingen. To systemer, der begge redigerer de samme tal, vil glide fra hinanden. Muligheder:

1. Din app er kun til ting, butikken ikke holder styr på (råvarer, forbrugsvarer, lager i baglokalet).
2. Butikken er kilden; din app læser fra den til rapporter og advarsler via dens API.
3. Din app er kilden og sender optællinger til butikken. Den kraftigste løsning, og den mest arbejde at få rigtig.

At starte med mulighed 1 eller 2 er langt mere sikkert.

Hvem må gøre hvad

At skjule kostpriser for nogle medarbejdere er et almindeligt krav; sig det i din første prompt. Rigtige rettigheder kræver app-login, som dækkes i sådan tilføjer du login til din app.

Telefon eller computer

Lagerarbejde foregår stående: i lagerrummet, ved leveringsdøren, i varevognen. Design justerings- og optællingsskærmene til telefon først, med store knapper og så lidt indtastning som muligt. Rapporter og redigering af varer kan være computerorienteret.

Byg det trin for trin

Trin 1: Ryd op i dine nuværende data

Eksportér dit regneark og gør det ryddeligt, før du importerer: én række pr. vare, ensartede enheder, unikke SKU'er, ingen sammenlagte celler. Det tager længere tid, end folk regner med, og sparer meget besvær senere.

Trin 2: Skriv den første prompt

Beskriv virksomheden, lageret, folkene og bevægelserne:

Byg en lagerapp til Fern & Stone, en planteforretning med et butiksgulv, et lagerrum og en leveringsvarevogn. Varer har navn, SKU, stregkode, kategori, enhed, kostpris, salgspris, leverandør og et genbestillingsniveau. Registrér antal pr. lokation. Hver ændring er en lagerbevægelse med type (modtaget, solgt, beskadiget, optalt, flyttet), antal, note, bruger og tidspunkt – redigér aldrig antal direkte. Skærme: en søgbar liste med filter for lav beholdning, varesiden med lager pr. lokation og bevægelseshistorik, en telefonvenlig skærm til hurtig justering og en side for lav beholdning grupperet efter leverandør. Medarbejdere kan ikke se kostpriser; ledere kan. Brug en database, enkelt og hurtigt design. Lad mig importere varer fra en CSV-fil.

Trin 3: Importér og kontrollér

Importér din oprensede CSV-fil, og tjek ti varer mod virkeligheden. Forkerte startbeholdninger underminerer tilliden til appen fra dag ét, så lav en rigtig optælling af dine vigtigste varer den dag, du skifter over.

Trin 4: Test bevægelserne

Modtag varer, sælg nogle, beskadig én, flyt nogle til varevognen, lav en optælling der finder to manglende. Kontrollér, at hver vares historik fortæller historien korrekt, og at antallet passer. Prøv at få antallet under nul, og beslut, om det skal blokeres eller markeres.

Trin 5: Tilføj advarsler og rapporter

En e-mail om lav beholdning eller en daglig oversigt til lederen er typisk det første, folk beder om, når det grundlæggende virker. Det kræver en e-mailudbyder og et planlagt job. Derefter en simpel rapport over lagerværdi og en liste over varer, der ikke har bevæget sig i 90 dage.

Trin 6: Rul det ud til én lokation først

Brug det ét sted i et par uger, ret det, der er besværligt, og udvid derefter. Den største risiko er ikke en fejl; det er, at medarbejdere går tilbage til regnearket, fordi appen er langsommere.

Almindelige fejl

• Kun at gemme det aktuelle antal. Uden bevægelser kan du ikke svare på "hvorfor er det her forkert?"
• At lade alle redigere alt. En tastefejl i et genbestillingsniveau eller en slettet vare kan gå ubemærket hen i flere uger.
• At ignorere enheder. At købe i kasser à 12 og sælge enkeltvis kræver en klar regel, ellers passer optællingerne ikke med en faktor 12.
• For mange felter på justeringsskærmen. Hvis det tager et minut at registrere en leverance, gør folk det ikke.
• At bygge tovejssynkronisering først. Få appen tillid på egen hånd, før du forbinder den til noget andet.
• At behandle den som regnskab. Lagerværdiansættelse til skatteformål (FIFO, vægtet gennemsnit) har regler; tjek med din revisor, før du stoler på appens tal i dit regnskab.

Hvornår er et færdigt produkt det bedre valg

• Du sælger hovedsageligt via én platform som Shopify eller Square. Deres indbyggede lagerfunktioner kan dække det, du har brug for, og er allerede koblet til dit salg.
• Du har brug for lager tæt koblet til regnskab. Regnskabssoftware og lagerprodukter bygget til at integrere med den sparer meget afstemning.
• Du har en lagerdrift med plukning, pakning, forsendelsesetiketter og flere salgskanaler. Dedikerede lager- og lagersystemer er bygget til det.

Byg selv, når dit lager ikke passer til de produkter, når du ville betale for et stort system til at bruge en lille del af det, eller når processen omkring lageret (godkendelser, jobsedler, udlejningsreturer) er det, du egentlig har brug for at styre. Vores guide om build vs. buy software til små virksomheder gennemgår afvejningen.

Sådan bygger du den med Mythex

Mythex er en AI-appbygger: du beskriver lageret, lokationerne og folkene, og den bygger appen i en live-preview og tilføjer en database til projektet for varer, lokationer og bevægelser. Du kan vedhæfte et skærmbillede af det regneark, du bruger i dag, så den kan se dine kolonner, og bede om en CSV-import. Varefotos bruger projektets fillager. Hvis din butik eller dit kassesystem har en API, kan du gemme dens nøgle i projekthemmeligheder og bede Mythex læse fra den. Der er ingen indbygget loginløsning til dine medarbejdere, så appkonti og roller bruger et autentificeringsbibliotek eller en udbyder, du vælger. Dokumentationens sider om byggning af et internt værktøj og byggning af en CRUD-app er gode udgangspunkter.

Til en første prompt, du kan redigere, kan du åbne lagersporings-skabelonen, eller læse den bredere guide om sådan bygger du et internt værktøj.

Spørgsmål