En restaurantkjede med fem steder i 2018 så svært annerledes ut på kontoret enn den samme kjeden gjør i dag. For noen år siden var standardoppsettet en samling verktøy der hvert enkelt løste ett problem på egenhånd. Et kassesystem i salen. Regnskapsprogram på kontoret. Et regneark for varetellingen. En eller to leverandørportaler for bestillinger. Kanskje et separat verktøy for oppskriftskalkylering som noen oppdaterte når det var tid til det. Ingen av dem snakket med hverandre, og jobben med å sy dem sammen falt på den som satt nærmest dataene.
Det oppsettet er nå i ferd med å forsvinne. Restaurantkjeder i hele Europa bygger teknologistakken sin opp rundt et mindre antall systemer som deler data automatisk. Trenden er konsolidering: færre verktøy, dypere integrasjon, mindre manuell samkjøring. Motivasjonen er enkel. Den gamle modellen skaper margintap på steder ingen ser etter, og kostnadene ved fragmentering har blitt stadig vanskeligere å forsvare etter hvert som integrasjonsmulighetene har modnet.
Det typiske backoffice de fleste kjeder fremdeles har
En typisk flerlokasjonskjede kjører fortsatt fem eller seks systemer som ikke er koblet sammen: et kassesystem for salg, regnskapsprogram for fakturaer og rapportering, en varetellingsrutine som lever i et regneark eller en separat app, en oppskriftskalkylering som gjerne er manuell og utdatert, et leverandørbestillingslag delt mellom portaler og e-post, og et rapporteringslag som vanligvis er bygd i Excel av den som har tålmodighet til det.
Hvert verktøy fungerer på egne premisser. Problemet er sømmene mellom dem. Salgsdata fra kassesystemet flyter ikke inn i oppskriftssystemet, så bildet av hva som faktisk ble forbrukt stemmer aldri helt med hva som ble solgt. Fakturalinjer ligger i regnskapsprogrammet, men når aldri frem til oppskriftskalkylen. Når en leverandør øker prisene, viser oppskriftskortet fortsatt fjorårets tall. Varetellinger gir et avvikstall, men det kan ikke spores tilbake til den konkrete retten eller leverandøren som forårsaket det. Operatøren ender opp med fem ulike sannhetskilder og ingen samlet oversikt.
Dette er teknologistakken de fleste kjeder har arvet fra et tiår med anskaffelse av enkeltløsninger. Den fungerte da restauranten hadde ett sted og eieren holdt hullene tette gjennom personlig oversikt. Den fungerer ikke på tvers av fem eller femten lokasjoner.
Hva god integrasjon ser ut som
Mønsteret som tegner seg blant operatører som har bygd opp stakken på nytt, er konsistent. De beholder to ankerpunkter og kobler resten rundt dem. Kassesystemet blir værende. Regnskapsprogrammet blir værende. Varelager, oppskriftskalkylering, leverandørprisdata og rapportering flyttes inn i et lag som leser fra begge ankerpunkter og skriver tilbake der det trengs.
Skiftet handler om å tette hullene mellom ankerpunktene, slik at data flyter i én retning i stedet for å bli tastet inn tre ganger. Ankerpunktene selv blir stående der de er. Operatørene har allerede brukt år på å bygge prosesser rundt kassesystemet og regnskapsprogrammet, og nybyggingen lar begge stå mens det knyttes et sammenbindende lag under dem.
En koblet stakk betyr at en faktura behandlet i regnskapssystemet også oppdaterer oppskriftskostnaden. Et salg registrert i kassen trekker også ned det teoretiske varelageret. En varetelling gir et avvikstall som kan spores til en konkret ingrediens, en konkret leverandør og en konkret rett. Konsolidering av restaurantprogramvare er det operative uttrykket for denne ideen: færre systemer, flere koblinger, mindre manuell samkjøring.
Hvorfor kassesystem og regnskap blir stående
Begge ankerpunktene fortjener plassen sin av samme grunn. De er dype, modne systemer som håndterer transaksjonsdatavolumer pålitelig, og de sitter på punktene der penger kommer inn og ut av virksomheten.
Kassesystemet er der inntektene registreres og der de ansatte allerede jobber gjennom hele vakta. Det er greit å be kjøkkenteamet om å telle varer i et separat system. Det er ikke greit å be dem om å registrere salg i et annet system enn det de allerede kan. Kassesystemet er ikke til forhandling, og det smarte grepet er å integrere rundt det, ikke erstatte det.
Regnskapsprogrammet er det samme tilfellet fra den andre siden. Fakturaer, betalinger, lønn og skatterapportering ligger allerede der, og økonomiavdelingene har bygd år med prosesser rundt plattformen de bruker. Jobben med å flytte regnskapsføringen til et restaurantspesifikt verktøy er sjelden verdt forstyrrelsene, særlig når integrasjon mellom kassesystem og regnskap kan levere det meste av den operative gevinsten uten å tvinge frem et slikt bytte.
Det som endrer seg, er det som sitter mellom dem. Det sammenbindende laget er der konsolideringen faktisk skjer.
Hvorfor varelageret er bindevevet
Varelageret er laget som berører alle andre deler av stakken. Det avhenger av oppskrifter, som avhenger av leverandørpriser, som kommer inn via regnskapet. Det produserer avvik, som bare gir mening når de matches mot salg fra kassesystemet. Bygg varelageret riktig, og det trekker resten av stakken inn i en samlet oversikt nesten av seg selv.
Tre ting gjør dette mulig. Det første er automatisk fakturabehandling, slik at leverandørpriser og innkjøpte mengder flyter inn i systemet uten å bli tastet inn manuelt. Det andre er kassesystemintegrasjon, slik at teoretisk forbruk kan beregnes mot faktisk salg. Det tredje er oppskriftskalkylering som oppdateres løpende når leverandørprisene beveger seg, i stedet for å stå frossent til noen har tid til å ta tak i det.
Når disse tre delene kobles sammen, får operatøren en oversikt den gamle stakken aldri kunne gi. De kan se hva som ble kjøpt, hva som ble solgt, hva som burde ha blitt brukt, og hva som faktisk ble telt. Gapet mellom disse tallene er der marginen lekker, og for første gang blir det mulig å spore kilden.
Det er derfor så mange kjeder nå behandler varelageret som integrasjonshub i stedet for som en sideoppgave. Når varelageret kobles skikkelig til kassesystem og regnskap, tar resten av rapporteringslaget i stor grad vare på seg selv. Du kan lese mer om hvordan dette spiller seg ut på tvers av flere lokasjoner i vår guide om varekostadministrasjon for restaurantkjeder.
Hva som faller bort
Det som faller bort fra den moderne stakken, er delene som bare eksisterer fordi de andre verktøyene nektet å snakke med hverandre.
Manuell samkjøring er den største delen. Jobben med å hente fakturatotaler fra regnskapet, sammenligne dem med et regneark over forventede ingredienskostnader og deretter oppdatere oppskriftskort ett om gangen, pleide å ta noen en halv arbeidsdag i uka. Med integrasjon mellom regnskap og oppskriftslaget forsvinner den jobben helt.
Separate regneark per lokasjon er den andre delen. En kjede med åtte steder pleide å vedlikeholde åtte versjoner av det samme kostnadsskjemaet, der hvert sted ble oppdatert av en annen leder i ulikt tempo. Når varelageringslaget henter fra én felles kilde, slutter de regnearket å bli laget. Konsolidert rapportering blir en bieffekt av integrasjonen i stedet for et eget prosjekt. Operatører som ønsker å gå helt bort fra regnearksbasert kalkylering, kan se vår gjennomgang av hvorfor programvare for varelagerstyring erstatter Excel.
Leverandørportalbytte er den tredje. Operatørene pleide å logge inn i tre eller fire leverandørportaler hver uke for å sjekke priser og deretter overføre det de fant til et regneark. Når fakturadata flyter automatisk inn i varelageringslaget, blir portalene en backup fremfor en daglig destinasjon. Leverandørprishistorikken forteller seg selv, og jobben med å spore leverandørprisendringer skifter fra datainnsamling til handling.
Dobbel dataregistrering er den fjerde og den stilleste kostnadsdriveren. I den gamle stakken måtte en enkelt opplysning ofte registreres på to eller tre steder: i kassesystemet, i varetellingsarket, i oppskriftsverktøyet. Hver registrering var en mulighet for feil. En konsolidert stakk fjerner disse mulighetene by design.
Hva dette betyr for kjeder som fortsatt bruker den gamle stakken
Trenden betyr mindre som et sammenligningspunkt og mer som et signal om at det operative gapet er i ferd med å øke. Kjeder som har bygd stakken på nytt, får renere avvikstall, raskere reaksjoner på leverandørprisendringer og mindre tid brukt på datakjøring. Kjeder som ikke har gjort det, gjør fremdeles det samme manuelle arbeidet teamene deres gjorde for noen år siden, og absorberer den samme margindriften på de samme stedene.
Nybyggingen er sjelden ett enkelt prosjekt. De fleste operatører kommer dit trinnvis. De starter med å koble regnskap til varelager, legger deretter til kassesystemintegrasjon og flytter oppskriftskalkylen inn i det samme laget. Et nyttig første steg for kjeder som tenker på dette, er å se på hvordan det nåværende varekostregistreringssystemet sender data mellom verktøy, og å identifisere sømmene der informasjon tastes inn to ganger eller kopieres mellom ark.
Sømmene er der lekkasjen skjer. Å tette dem er det den moderne stakken er bygd for å gjøre.
Hvor i stakken din bytter du fortsatt mellom verktøy som burde snakket med hverandre?