Hver restaurant drives af tre systemer, der hver holder et stykke af det samme billede: kassesystemet for, hvad der er solgt, regnskabssystemet for, hvad der er betalt, og varelagersystemet for, hvad der faktisk er brugt. Hvert system er præcist inden for sin egen grænse, og hvert system er næsten ubrugeligt alene, når spørgsmålet er, hvor marginen forsvinder hen.
De restauratører, der holder stramme varekostprocenter, har fundet ud af, hvordan man integrerer kassesystem, varelager og regnskab, så de tre systemer taler med hinanden. Når salg, indkøb og forbrug kan krydstjekkes ét sted, holder leverandørprisstigninger op med at glide igennem, og overportering holder op med at akkumulere et kvartal, før nogen opdager det.
Denne artikel gennemgår, hvad hvert system indeholder, hvor hullerne mellem dem typisk opstår, og hvordan et forbundet flow faktisk ser ud, fra det øjeblik en ret sælges til det øjeblik, dens ingrediensomkostning afstemmes mod den faktura, der betalte for den.
Hvad kassesystemet indeholder, og hvor det stopper
Kassesystemet er systemet for salgsregistrering. Hver ordre, hvert tillæg, hver annullering, hver kompensation, hver gang en tjener sendte en ret til køkkenet, alt dette lever i kassesystemets data. Samlet omsætning pr. dag, pr. kategori, pr. time, pr. tjener, pr. lokation. Gennemsnitlig bonbeløb. Salgshastighed på vareniveau. Kassesystemet ved med høj præcision, hvad restauranten solgte og til hvilken pris.
Hvad kassesystemet ikke ved, er, hvad hvert af disse salg faktisk kostede at producere. Det kan gemme en opskriftslinket menu, men medmindre opskrifterne holdes ajour og ingrediensomkostningerne bag dem opdateres, når leverandørpriserne bevæger sig, er kostprissiden af kassesystemets rapport et øjebliksbillede af en gammel virkelighed. De fleste kasserapporter viser en teoretisk varekostprocent baseret på de opskriftsomkostninger, der var indlæst ved opsætning. Det tal driver længere fra virkeligheden for hver uge, opskrifterne ikke opdateres.
Kassesystemet stopper også ved salgsøjeblikket. Det ser ikke, hvad der kom ind ad bagdøren, hvad der blev klargjort og spildt, hvad der forsvandt, eller hvad der lå i køleskabet, til det var fordærvet. Alt, der sker mellem leverandørens faktura og kundens ordre, er usynligt for kassesystemet.
Hvad regnskabssystemet indeholder, og hvor det stopper
Regnskabssystemet er systemet for penge ind og penge ud. Det indeholder leverandørfakturaer, linjeposter, betalinger, moms, løn, husleje og forsyninger. Det ved præcist, hvad der er brugt, og hvad der er faktureret.
Detaljeniveauet varierer afhængigt af, hvordan fakturaer behandles. I en drift, hvor fakturaer indlæses som én samlet sum, viser regnskabssystemet, at der blev betalt 34.000 kr. til en kødleverandør sidste uge. I en drift, hvor fakturaer behandles linje for linje, viser det samme regnskabssystem, at der blev købt 90 kg hakket oksekød til 87 kr./kg, kyllingelår til 44 kr./kg og så videre ned gennem fakturaen.
Linjeniveaudata fra fakturaer er, hvor den reelle synlighed starter, og det er præcis, hvad de fleste restauranter ikke registrerer. Uden det kan regnskabssystemet fortælle dig vareforbruget som en procentdel af omsætningen, men det kan ikke fortælle dig, hvilke ingredienser der steg i pris, hvilke leverandører der hævede prisen lydløst, eller hvilke kategorier der drev stigningen. Regnskabssystemet stopper ved totaler, og spørgsmålet om, hvorfor disse totaler bevægede sig, ligger ét lag dybere, end regnskabet alene kan se.
Hvad varelageret indeholder, og hvad kun det kan se
Varelagersystemet, når det drives ordentligt, holder det tredje stykke: hvad der fysisk blev talt som beholdning ved periodens start og ved dens afslutning. Kombineret med, hvad der blev indkøbt imellem, er det dette, der fortæller dig, hvad der faktisk blev brugt.
Faktisk forbrug er det eneste tal, der lukker løkken. Kassesystemet siger, at restauranten burde have brugt 78 kg oksekød baseret på, hvad der er solgt. Regnskabsdataene siger, at der blev indkøbt 90 kg. Varetællingen siger, at der er 4 kg tilbage på hylden, da der var 6 kg ved starten. Det betyder, at der faktisk blev brugt 92 kg, mod et teoretisk forbrug på 78 kg. Det 14 kg store hul er afvigelse, og afvigelse er, hvor marginhistorien faktisk finder sted. Det er overportering, spild, fordærvelse, tyveri, forkerte opskrifter eller en kombination af dem alle. Intet af det er synligt uden varetællingen.
Varelager er også det eneste sted, hvor leverandørprisændringer afstemmes mod, hvad retterne faktisk koster i dag. Når ingrediensomkostninger slår korrekt igennem til opskrifter, kan systemet vise faktisk vareforbrug på rettens niveau, ikke kun på det kategoriniveau, som regnskabssoftwaren producerer.
Problemet er, at varelagersystemet kun er så præcist som de data, der strømmer ind i det. Hvis det ikke er forbundet til kassesystemet, kan det ikke beregne teoretisk forbrug. Hvis det ikke er forbundet til regnskabet, kan det ikke holde ingrediensomkostningerne ajour. Uden disse forbindelser producerer selv en velgennemført varetælling afvigelsestal, som ingen kan handle på, fordi ingen kan spore, hvorfra afvigelsen stammer.
Hullet mellem systemer, og hvad der går tabt der
Hullet mellem disse tre systemer er, hvor det meste af det uforklarede marginspild befinder sig. En leverandør hæver prisen på fisk med 8 %. Fakturaen clearer regnskabet og betales. Kassesystemet fortsætter med at rapportere den samme teoretiske kostpris pr. ret, fordi opskriften aldrig blev opdateret. Varelager viser afvigelse ved periodens afslutning, men afvigelsen registreres som “høj” uden at nogen sporer den tilbage til prisudviklingen. Tre måneder senere har fiskekategorien lydløst absorberet tusindvis af kroner, som ingen så bevæge sig.
Det samme hul forklarer, hvorfor varekostoverraskelser typisk dukker op ved månedsskiftet frem for i løbet af måneden. Dataene eksisterer i alle tre systemer hele tiden. Det, der ikke eksisterer, er integrationen, der lader én person se, i én visning, at prisen på fisk steg den 8., at opskriftsomkostningen ikke blev opdateret, at kassesalg af fiskeretter fortsatte med den gamle marginsantagelse, og at den resulterende afvigelse er strukturel frem for tilfældig.
Et forbundet flow er det eneste, der bringer dette frem i tide til at handle. Elementer som leverandørprissporing, analyse af lagerafvigelser og benchmarks for varekostprocent bliver kun operationelle, når de underliggende systemer er integrerede. Uden forbindelsen er hvert af dem en rapport, der forklarer, hvad der skete uger efter, det havde nogen betydning.
Hvordan et forbundet flow ser ud fra ende til anden
Når de tre systemer er integrerede, kan et enkelt salg spores rent igennem hvert lag i driften.
1. Det første lag er kassesystemet. En gæst bestiller en fiskeret. Salget registrerer retten, prisen, tidspunktet og lokationen.
2. Det andet er opskriften. Retten er knyttet til en opskrift med definerede mængder fisk, olie, krydderurter, garniture og tilbehør. Hver ingrediens bærer en aktuel kostpris, som stammer fra fakturadata frem for et opsætningsbillede.
3. Det tredje er forbruget. Ganget over hvert salg af den pågældende ret i perioden definerer opskriften et teoretisk ingrediensforbrug. Kassesystemet leverer salgsmængden, opskriften leverer mængden pr. portion, og tilsammen producerer de det tal, der siger: “baseret på, hvad der er solgt, er dette, hvad der burde være brugt.”
4. Det fjerde er fakturaen. Leverandørfakturaer ankommer i regnskabet og behandles linje for linje. Hver linjepost opdaterer kostprisen på den ingrediens, den repræsenterer, og den opdaterede kostpris slår igennem til alle opskrifter, der bruger den. Hvis prisen på fisk steg tirsdag, afspejler rettens kostpris det onsdag.
5. Det femte er varetællingen. Ved periodens afslutning tælles den fysiske beholdning. Forskellen mellem, hvad der var på lager ved starten, hvad der blev indkøbt, og hvad der er på lager ved afslutningen, giver det faktiske forbrug. Faktisk forbrug sammenlignes med teoretisk forbrug fra kassesystem-opskriftssiden, og afvigelsen er synlig på ingrediensniveau. Fiskehullet er ikke længere gemt inde i varekostprocenten. Det er et konkret tal på en konkret ingrediens med en konkret årsag.
Det er det system til sporing af varekostprocent, som restauratører med stramme marginer arbejder ud fra. Ingen af komponenterne er eksotiske. Arbejdet ligger i at få data til at bevæge sig mellem dem.
Hvilke integrationer der vejer tungest
Tre integrationer bærer det meste af vægten, når du beslutter, hvor du skal investere først.
-
Den første er kassesystem til opskrift og varelager. Uden at salgsdata automatisk flyder ind i varelagersystemet skal det teoretiske forbrug beregnes manuelt, hvilket betyder, at det beregnes sjældent, og afvigelsen mister sin mening. Dette er fundamentet. Uden det kan resten af stacken ikke gøre sit arbejde.
-
Den anden er regnskab til opskrift. Leverandørfakturaer skal flyde ind i det system, der indeholder opskrifterne, og de skal flyde ind med linjeniveaudetaljer frem for som samlede summer. Det er det, der holder opskriftsomkostninger ajour, når leverandørpriser bevæger sig, og det er det, der bringer prisstigninger frem i tide til at stille spørgsmål ved dem. Arbejdet med at opdage fejl i leverandørfakturaer og prisdrift er i store træk automatiseret, når denne integration er på plads.
-
Den tredje er varelagersystemet til begge de ovenstående. Varelager er det lag, hvor alt afstemmes. Det har brug for kassesystemets data for at beregne teoretisk forbrug og regnskabsdataene for at holde kostpriser ajour. Hvis varelager kun forbinder til den ene side, er de afvigelsestal, det producerer, ufuldstændige.
For restaurantgrupper med flere lokationer er disse tre integrationer endnu vigtigere, fordi kaskaddfejlen ved en forældet opskrift multipliceres på tværs af alle steder, der kører den samme menu.
Sådan evaluerer du en integration, når du vælger software
Leverandørdemonstationer er designet til at vise, hvad der er muligt. De spørgsmål, der er værd at stille, handler om, hvad der er automatisk kontra manuelt.
En kort liste til at stille enhver leverandør, når integration er på bordet:
1. Hvilke kassesystemer og regnskabssystemer understøtter I nativt, og hvilke kræver workarounds?
- Native integrationer holdes ajour, når det opstrøms værktøj opdateres. Workarounds har en tendens til at bryde lydløst.
2. Hvad sker der med opskriftsomkostningen, når en leverandørpris ændres på en faktura?
- Hvis svaret involverer et manuelt gennemgangstrin, lukker integrationen ikke løkken.
3. Hvordan registreres linjeniveaudata fra fakturaer?
- Hvis svaret er OCR plus manuel gennemgang, skal du spørge, hvilken procentdel af fakturaer der kræver menneskelig korrektion. Det tal har betydning.
4. Hvad viser afvigelsesrapporten på ingrediensniveau, ikke kategoriniveau?
- Hvis systemet ikke kan vise afvigelse pr. ingrediens med prisudviklingen og forbrugsgabet vedhæftet, er den underliggende integration ikke dyb nok.
5. Hvordan håndterer systemet flere lokationer?
- Kaskade af opskriftsomkostninger på tværs af steder er, hvor de fleste integrationer svækkes, fordi den samme menu udrulet på tværs af fem lokationer kræver, at kostprisopdateringen udbredes overalt uden en manuel synkronisering.
Stockifi sidder i denne stak som integrationslaget mellem kassesystemet, regnskabssystemet og lagerdriften. Arbejdet kan også udføres med en kombination af andre værktøjer og et disciplineret driftsteam. Pointen er, at integrationen skal eksistere et sted. De restauranter, der holder deres margin år efter år, er dem, hvor den gør det, og dem, der mister to eller tre procentpoint af vareforbruget om året, er næsten altid dem, hvor den ikke gør.
Når du ser på din egen drift, kan du spore en enkelt ret fra salg til faktura til faktisk forbrug uden at forlade et af de tre systemer og sy dataene sammen manuelt?