En restaurantgruppe med fem afdelinger i 2018 så meget anderledes ud i sin administration end den samme gruppe gør i dag. For fem år siden var standardopsætningen en samling systemer, der hver løste ét problem for sig selv. Et kassesystem i restauranten. Regnskabssoftware på kontoret. Et regneark til varelager. En eller to leverandørportaler til bestillinger. Måske et separat opskriftsberegningsværktøj, som nogen opdaterede, når der var tid. Ingen af dem kommunikerede med hinanden, og arbejdet med at sy dem sammen faldt på den, der sad tættest på dataene.
Den opsætning er ved at blive nedlagt. På tværs af Europa ombygger restaurantgrupper deres restaurant tech stack omkring et mindre antal systemer, der deler data automatisk. Tendensen er konsolidering: færre systemer, dybere integration, mindre manuel afstemning. Motivationen er enkel. Den gamle model skaber margintab på steder, ingen kigger på, og prisen på fragmentering er blevet sværere at retfærdiggøre, efterhånden som integrationsmulighederne er modnet.
Den back office, de fleste grupper stadig har
En typisk operatør med flere afdelinger kører stadig fem eller seks systemer, der ikke er forbundet: et kassesystem til salg, regnskabssoftware til fakturaer og rapportering, en varetællingproces der lever i et regneark eller en separat app, en opskriftsberegningsopsætning der ofte er manuel og forældet, et leverandørbestillingslag opdelt mellem portaler og e-mail, og et rapporteringslag der typisk er bygget i Excel af den, der har tålmodighed til det.
Hvert system fungerer på egne præmisser. Problemet er i sømmene imellem dem. Salgsdata fra kassesystemet flyder ikke ind i opskriftssystemet, så billedet af hvad der faktisk er forbrugt stemmer aldrig helt overens med hvad der er solgt. Fakturalinjer lever i regnskabssoftwaren, men når aldrig frem til opskriftsomkostningsberegningen, så når en leverandør hæver priserne, viser opskriftskortet stadig forrige kvartals tal. Varetællinger producerer et afvigelsestal, men tallet kan ikke spores tilbage til den specifikke ret eller leverandør, der drev det. Operatøren ender med fem sandhedskilder og ingen samlet overblik.
Det er den hospitality tech stack, som de fleste grupper har arvet fra et årtis adoption af punktløsninger. Det fungerede, da restauranter kørte én afdeling, og ejeren holdt hullerne sammen via hukommelsen. Det fungerer ikke på tværs af fem eller femten afdelinger.
Hvad god integration ser ud som
Det mønster, der tegner sig hos operatører, der har ombygget deres stack, er konsekvent. De beholder to ankerpunkter og forbinder alt andet omkring dem. Kassesystemet bliver. Regnskabssystemet bliver. Varelager, opskriftsberegning, leverandørprisdata og rapportering flyttes ind i et lag, der læser fra begge ankerpunkter og skriver tilbage, hvor det er nødvendigt.
Skiftet handler om at lukke hullerne mellem ankerpunkterne, så data flyder i én retning frem for at blive tastet ind tre gange. Ankerpunkterne selv forbliver, hvor de er. Operatørerne har allerede investeret årevis af processer omkring kassesystemet og regnskabssystemet, og ombygningen lader begge blive stående, mens det forbindende lag kobles op nedenunder.
En sammenhængende stack betyder, at en faktura behandlet i regnskabssystemet også opdaterer opskriftsomkostningerne. Et salg registreret i kassesystemet trækker også på det teoretiske varelager. En varetælling producerer et afvigelsestal, der kan spores til en specifik ingrediens, en specifik leverandør og en specifik ret. Restaurant software-konsolidering er den operationelle udtryksform for den idé: færre systemer, flere forbindelser, mindre manuel afstemning.
Hvorfor kassesystem og regnskab bliver
Begge ankerpunkter fortjener deres plads af samme grund. De er dybe, modne systemer, der håndterer transaktionsdata i store mængder pålideligt, og de befinder sig der, hvor penge kommer ind og forlader virksomheden.
Kassesystemet er der, hvor omsætningen registreres, og hvor personalet allerede arbejder hver vagt. Det er rimeligt at bede et køkkenteam om at tælle varelager i et separat system. Det er ikke rimeligt at bede dem registrere salg i et andet system end det, de allerede kender. Kassesystemet er ikke til forhandling, og det smarte træk er at integrere rundt om det frem for at erstatte det.
Regnskabssoftware er det samme argument fra den anden side. Fakturaer, betalinger, løn og momsrapportering lever allerede der, og økonomiafdelinger har årevis af processer bygget op om den valgte platform. Arbejdet med at flytte regnskabet fuldstændigt til et restaurantspecifikt system er sjældent besværet værd, især når kassesystem- og regnskabsintegration kan levere det meste af den operationelle gevinst uden at tvinge det igennem.
Det, der ændrer sig, er hvad der befinder sig imellem dem. Det forbindende lag er der, hvor konsolideringen faktisk sker.
Hvorfor varelager er det bindevæv, der holder det hele sammen
Varelager er det lag, der rører alle andre dele af stacken. Det afhænger af opskrifter, som afhænger af leverandørpriser, der ankommer via regnskabet. Det producerer afvigelser, som kun giver mening, når de sammenholdes med salg, der kommer fra kassesystemet. Byg varelager rigtigt, og det trækker resten af restaurantens varelager-softwarestack ind i ét samlet overblik næsten af sig selv.
Tre ting får det til at fungere. Den første er automatisk fakturabehandling, så leverandørpriser og indkøbte mængder flyder ind i systemet uden at blive tastet ind manuelt. Den anden er kassesystemintegration, så det teoretiske forbrug kan beregnes op mod det faktiske salg. Den tredje er opskriftsberegning, der opdaterer sig løbende, efterhånden som leverandørpriserne bevæger sig, frem for at stå stille, indtil nogen har tid til at revidere den.
Når de tre dele forbindes, får operatøren et overblik, som den gamle stack aldrig kunne levere. De kan se, hvad der er købt, hvad der er solgt, hvad der burde være forbrugt, og hvad der faktisk er talt op. Hullet mellem de tal er der, hvor marginerne lækker, og for første gang bliver det muligt at spore.
Det er grunden til, at så mange grupper nu behandler varelager som integrationsknudepunktet frem for en sideproces. Når varelager forbinder sig ordentligt til kassesystem og regnskab, klarer resten af rapporteringslaget sig stort set selv. Du kan læse mere om, hvordan dette udspiller sig på tværs af flere afdelinger, i vores guide om varekostadministration for restaurantgrupper.
Hvad der droppes
De dele, der falder fra den moderne stack, er dem, der kun eksisterer, fordi de andre systemer nægtede at tale med hinanden.
Manuel afstemning er den største del. Arbejdet med at tage fakturatotaler fra regnskabet, sammenligne dem med et regneark over forventede ingrediensomkostninger og derefter opdatere opskriftskort ét ad gangen plejede at tage nogen en halv dag om ugen. Med restaurantteknologiintegration mellem regnskab og opskriftslaget forsvinder det arbejde fuldstændigt.
Separate regneark pr. afdeling er den anden del. En gruppe med otte afdelinger plejede at vedligeholde otte versioner af det samme omkostningsark, hver opdateret af en anden leder i forskelligt tempo. Når varelagerelaget trækker fra én sandhedskilde, holder de regneark op med at blive oprettet. Konsolideret rapportering bliver en sideeffekt af integrationen frem for et projekt i sig selv. Operatører, der ønsker at komme helt væk fra regnearkbaseret kalkulering, kan se vores gennemgang af hvorfor varelager-software erstatter Excel.
Leverandørportalskift er den tredje del. Operatørerne plejede at logge ind på tre eller fire leverandørportaler hver uge for at tjekke priser og derefter overføre det fundne til et sporingark. Når fakturadata automatisk flyder ind i varelagerelaget, bliver portalerne en backup frem for en daglig destination. Leverandørprishistorien fortæller sig selv, og arbejdet med at spore leverandørprisændringer skifter fra dataindsamling til at handle på det.
Dobbelt dataindtastning er den fjerde og den mest stille dyre. På tværs af den gamle stack skulle en enkelt oplysning ofte tastes ind to eller tre steder: i kassesystemet, i varelagerarket, i opskriftsværktøjet. Hver indtastning var en mulighed for fejl. En konsolideret stack fjerner de muligheder ved design.
Hvad det betyder for grupper, der stadig bruger den gamle stack
Tendensen betyder mindre som en benchmark og mere som et signal om, hvor det operationelle gab udvider sig. Grupper, der har ombygget deres stack, får renere afvigelsestal, hurtigere reaktioner på leverandørprisændringer og mindre tid brugt på at afstemme data. Grupper, der ikke har, udfører stadig det samme manuelle arbejde, som deres teams gjorde for fem år siden, og absorberer den samme margindrif de samme steder.
Ombygningen er sjældent ét enkelt projekt. De fleste operatører når dertil trinvis. De starter med at forbinde regnskab med varelager, tilføjer derefter kassesystemintegration og flytter så opskriftsberegning ind i samme lag. Et nyttigt første skridt for grupper, der overvejer dette, er at se på, hvordan deres nuværende system til sporing af varekostomkostninger overfører data mellem systemer, og identificere de sømme, hvor information tastes ind to gange eller kopieres mellem ark.
Sømmene er der, hvor lækagen lever. At lukke dem er, hvad den moderne stack er bygget til at gøre.
Hvor i din stack skifter du stadig mellem systemer, der burde tale med hinanden?