En restaurangkedja med fem restauranger 2018 såg väldigt annorlunda ut i sin backoffice än samma kedja gör i dag. För fem år sedan var standardupplägget en samling verktyg som var och ett löste ett problem på egen hand. Ett kassasystem i matsalen. Bokföringsprogram på kontoret. Ett kalkylblad för inventeringen. En eller två leverantörsportaler för beställningar. Kanske ett separat verktyg för receptkalkylering som någon uppdaterade när det fanns tid. Inget av dem kommunicerade med varandra, och jobbet med att sy ihop dem föll på den som råkade stå närmast datan.
Det upplägget håller på att monteras ned. Över hela Europa bygger restaurangkedjor om sin tekniska plattform kring ett mindre antal system som delar data automatiskt. Trenden är konsolidering: färre verktyg, djupare integration, mindre manuell avstämning. Drivkraften är enkel. Den gamla modellen skapar marginalläckage på ställen ingen bevakar, och kostnaden för fragmentering har blivit svårare att motivera i takt med att integrationsmöjligheterna mognat.
Backoffice som de flesta kedjor fortfarande har
En typisk operatör med flera restauranger kör fortfarande fem eller sex system som inte är kopplade till varandra: ett kassasystem för försäljning, bokföringsprogram för fakturor och rapportering, en inventeringsprocess som lever i ett kalkylblad eller en separat app, ett receptkalkyleringsupplägg som ofta är manuellt och inaktuellt, ett leverantörslager uppdelat mellan portaler och e-post, och ett rapportlager som vanligtvis byggs i Excel av den som har tålamodet.
Varje verktyg fungerar på sina egna villkor. Problemet är fogarna mellan dem. Försäljningsdata från kassasystemet flödar inte in i receptsystemet, så bilden av vad som faktiskt förbrukades stämmer aldrig riktigt med vad som såldes. Fakturaraderna finns i bokföringsprogrammet men når aldrig receptkostnadsberäkningen, så när en leverantör höjer priserna fortsätter receptkortet att visa förra kvartalets siffra. Inventeringen producerar en avvikelsesiffra, men siffran går inte att spåra tillbaka till den specifika rätten eller leverantören som orsakade den. Operatören slutar med fem sanningskällor och ingen samlad bild.
Det är den tekniska plattformen inom restaurangbranschen som de flesta kedjor ärvt från ett decennium av punktlösningsadoption. Det fungerade när restaurangen drev ett enda ställe och ägaren höll ihop luckorna med minnet. Det fungerar inte över fem eller femton restauranger.
Hur en bra integration ser ut
Mönstret som framträder hos operatörer som byggt om sin plattform är konsekvent. De behåller två ankare och kopplar allt annat runt dem. Kassasystemet stannar. Bokföringsprogrammet stannar. Varulager, receptkalkylering, leverantörsprisdata och rapportering flyttar in i ett lager som läser från båda ankarna och skriver tillbaka dit det behövs.
Förändringen handlar om att stänga luckorna mellan ankarna så att data flödar i en riktning snarare än att matas in tre gånger. Ankarna stannar på plats. Operatörerna har redan investerat år av processer runt kassasystemet och bokföringsprogrammet, och ombyggnaden lämnar båda kvar medan det sammankopplande lagret kopplas in under dem.
En sammankopplad plattform innebär att en faktura som behandlas i bokföringsprogrammet också uppdaterar receptkostnaden. En försäljning som registreras i kassasystemet drar också ned det teoretiska varulagret. En inventering producerar en avvikelsesiffra som kan spåras till en specifik ingrediens, en specifik leverantör och en specifik rätt. Konsolidering av restaurangsystem är det operativa uttrycket för den idén: färre system, fler kopplingar, mindre manuell avstämning.
Varför kassasystem och bokföring stannar
Båda ankarna motiverar sin plats av samma skäl. De är djupa, mogna system som hanterar transaktionsdata i hög volym tillförlitligt, och de sitter vid de punkter där pengar kommer in och lämnar verksamheten.
Kassasystemet är där intäkterna registreras och där personalen redan arbetar varje skift. Att be ett köksteam att också inventera i ett separat system är rimligt. Att be dem slå in försäljning i ett annat system än det de redan känner till är det inte. Kassasystemet är icke-förhandlingsbart, och det smarta draget är att integrera runt det snarare än att ersätta det.
Bokföringsprogrammet är samma resonemang från andra sidan. Fakturor, betalningar, löneredovisning och skatterapportering finns redan där, och ekonomiteamen har år av processer byggda runt sin valda plattform. Arbetet med att flytta hela bokföringen till ett restaurangspecifikt verktyg är sällan värt störningarna, särskilt när integration mellan kassasystem och bokföring kan leverera det mesta av den operativa nyttan utan att tvinga fram den flytten.
Det som förändras är vad som sitter mellan dem. Det sammankopplande lagret är där konsolideringen faktiskt sker.
Varför varulagret är bindväven
Varulagret är det lager som berör alla andra delar av plattformen. Det är beroende av recept, som är beroende av leverantörspriser, som ankommer via bokföringen. Det producerar avvikelser, som bara är meningsfulla när de matchas mot försäljning, som kommer från kassasystemet. Bygg varulagret ordentligt och det drar in resten av restaurangens inventeringsprogramvara i en samlad bild nästan automatiskt.
Tre saker får detta att fungera. Det första är automatiserad fakturabehandling, så att leverantörspriser och inköpta kvantiteter flödar in i systemet utan att matas in manuellt. Det andra är kassasystemsintegration, så att teoretisk förbrukning kan beräknas mot faktisk försäljning. Det tredje är receptkalkylering som uppdateras i realtid när leverantörspriser rör sig, snarare än att stå fryst tills någon har tid att gå igenom det.
När de tre delarna kopplas ihop får operatören en bild som den gamla plattformen aldrig kunde producera. De kan se vad som köptes, vad som såldes, vad som borde ha förbrukats och vad som faktiskt räknades. Skillnaden mellan de siffrorna är där marginalen läcker, och för första gången går den att spåra.
Det är därför så många kedjor nu behandlar varulagret som integrationshubben snarare än som en sidoprocess. När varulagret kopplas ordentligt till kassasystemet och bokföringen sköter sig resten av rapportlagret långt till stor del självt. Du kan läsa mer om hur det fungerar över flera restauranger i vår guide om kostnadshantering för restaurangkedjor.
Vad som fasas ut
De delar som försvinner från den moderna plattformen är de som bara finns för att de andra verktygen vägrade kommunicera med varandra.
Manuell avstämning är den största delen. Arbetet med att hämta fakturasummor från bokföringen, jämföra dem med ett kalkylblad med förväntade ingredienskostnader och sedan uppdatera receptkort ett i taget brukade ta någon en halv dag varje vecka. Med systemintegration mellan bokföringen och receptlagret försvinner det arbetet helt.
Separata kalkylblad per restaurang är den andra delen. En kedja med åtta ställen brukade underhålla åtta versioner av samma kostnadstabell, var och en uppdaterad av en annan chef i ett annat tempo. När inventeringslagret hämtar från en enda sanningskälla slutar de kalkylbladen att skapas. Konsoliderad rapportering blir en bieffekt av integrationen snarare än ett eget projekt. Operatörer som vill lämna kalkylbladsbaserad kalkylering helt kan se vår genomgång av varför inventeringsprogramvara ersätter Excel.
Leverantörsportalbyte är den tredje. Operatörer brukade logga in på tre eller fyra leverantörsportaler varje vecka för att kolla priser, sedan transkribera vad de hittade till ett spårningsblad. Med fakturaflöde som automatiskt rör sig in i inventeringslagret blir portalerna en reserv snarare än ett dagligt mål. Leverantörsprisbilden berättar sig själv, och arbetet med att spåra leverantörsprisförändringar skiftar från datainsamling till att agera på den.
Dubbelinmatning är den fjärde, och den tystast kostsamma. I den gamla plattformen behövde ett enskilt uppgiftspaket ofta matas in på två eller tre ställen: i kassasystemet, i inventeringsbladet, i receptverktyget. Varje inmatning var en möjlighet till fel. En konsoliderad plattform tar bort de möjligheterna by design.
Vad det betyder för kedjor som fortfarande kör den gamla plattformen
Trenden är mindre intressant som ett riktmärke och mer som en signal om var det operativa gapet vidgas. Kedjor som byggt om sin plattform får renare avvikelsesiffror, snabbare reaktioner på leverantörsprisförändringar och mindre tid åt att stämma av data. Kedjor som inte gjort det utför fortfarande samma manuella arbete som deras team gjorde för fem år sedan, och absorberar samma marginaldrift på samma ställen.
Ombyggnaden är sällan ett enda projekt. De flesta operatörer kommer dit stegvis. De börjar med att koppla bokföringen till varulagret, lägger sedan till kassasystemsintegration och flyttar sedan receptkalkyleringsverktyget in i samma lager. Ett användbart första steg för kedjor som funderar på detta är att titta på hur deras nuvarande system för varukostnadsspårning lämnar data mellan verktyg, och att identifiera fogarna där information matas in två gånger eller kopieras mellan blad.
Fogarna är där läckaget bor. Att stänga dem är vad den moderna plattformen är byggd för att göra.
Var i din plattform byter du fortfarande mellan verktyg som borde kommunicera med varandra?