Servering av läcker mat (och data) – En datamodell för restauranger

Vilken roll spelar databasdesign för att driva en restaurang? Hur kan datamodellen för en restaurangdatabas se ut? Ta reda på det i den här artikeln.

En restaurang serverar folk med färdiglagad mat. Det här är en typ av verksamhet som blomstrar över hela världen, och ofta med mycket bloss. Människor känner sig väldigt bekväma med att gå till restauranger och de börjar förvänta sig ett brett utbud av alternativ när det kommer till deras nästa måltid.

Bara i New York City finns det mer än 24 000 restauranger. Dessa inkluderar hämtmat (t.ex. pizza, sub-butiker, kinesisk avhämtning), delikatessbutiker, kaféer och fina restauranger. Följande talesätt passar restaurangbranschen väldigt bra; det är praktiskt taget deras universella mission statement:

Gör det du gör så bra att de kommer att vilja se det igen och ta med sina vänner och familj.

Walt Disney

Varför behöver restauranger databaser?

Restauranghantering är ingen lätt uppgift. När det gäller att hålla reda på och lösa de dagliga uppgifterna kan även den mest erfarna krögaren ha mer än vad de lätt kan hantera. Att driva en lönsam restaurang kräver hantering av inventarier/lager, minimera avfall, hantering av bord (särskilt under rusningstid), upprätthålla en kundvänlig meny, utföra beställningar effektivt och övervaka restaurangpersonal. Det är ganska mycket!

Ett restaurangledningssystem måste utföra de flesta av dessa aktiviteter med minimala manuella ingrepp. Den måste ge cheferna korrekt information så att de kan hålla kunderna nöjda. Detta kan innebära att man gör lämpliga ändringar i menyn och till och med hur restaurangen fungerar.

Restaurangdatamodellen

Den här artikeln handlar om att designa en fullfjädrad datamodell för en restaurang (dine-in eller takeaway). Vi kommer också att ta upp två stora problem som människor i restaurangbranschen stöter på i sina dagliga aktiviteter. Slutligen kommer vi att tänka på de förändringar som behövs för att bygga in dessa funktioner i ett befintligt system.

När vi dyker in i datamodellen kommer jag att nämna vissa användarroller. Dessa roller är faktiskt för personalmedlemmar, såsom:

• Manager – Hanterar lager, löner, schemaläggning av anställda och statistik för restaurangen
• Värd – Sätter gäster och tilldelar servrar till bord
• Servitör (även känd som server) – Tar kunders beställningar till köket och levererar den förberedda beställningen till kunden
• Handledare (även känd som kock eller köksmästare) – Övervakar uppgifter i köket och tilldelar uppgifter till kockar
• Kock – läser beställningsinformationen från handledaren, förbereder maten och informerar handledaren när den är klar
• Busboy – Håller reda på vilka tabeller som används; rensar tabeller och uppdaterar deras status vid behov

En datamodell för en restaurangverksamhet måste ha följande elementära funktioner:

• KOT-hantering (Kitchen Order Token)
• KOD-hantering (Kitchen Order Delivery)
• Menyhantering

Låt oss titta på var och en av dessa funktioner i detalj.

KOT-hantering (Kitchen Order Token)

Detta är den viktigaste delen av vår datamodell:det handlar om att samla in orderdetaljer från kunder genom olika kanaler. Varför olika kanaler? För det finns flera sätt som beställningar kan göras – online eller via mobilapp, via telefonsamtal eller genom servitörer eller andra anställda. Närhelst en beställning görs av en kund genereras en KOT (Kitchen Order Token). Så småningom kommer KOT att förberedas av kökspersonalen.

Jag skapar en tabell, kot , för att hålla de preliminära orderuppgifterna. Den här tabellen har följande kolumner:

Jag vill påpeka att en beställning som samlas in från ett bord åt gången är taggad under en kot_id . Om samma tabell senare beställer fler artiklar kommer systemet att generera ett annat kot_id och tagga alla dessa nya artiklar under det ID:t. I slutändan, alla kot_ids för samma tabell kommer att läggas ihop i den slutliga notan.

KOT-hantering kräver ytterligare statiska och transaktionstabeller, som är:

• order_channel – Den här tabellen innehåller information om de kanaler en restaurang använder för att ta emot beställningar. Vanliga exempel är online, äta middag, take away (utföra) etc.

• dine_in_table_sitting – Det här är en transaktionstabell som lagrar data om bordsbeläggning. Dess kolumner inkluderar dine_in_table_id , dine_in_time , dine_out_time , num_person_sitting och customer_id . Så snart värden tilldelar en kund till en tabell och matar in informationen i systemet, infogas en post i denna tabell. För att hämta aktuell beläggningsstatus för tabeller vid en given tidpunkt, är detta den tabell som kommer att användas.

  Anta att du vill bygga den här funktionen. Här är SQL-koden som talar om för dig aktuell beläggningsstatus för alla restaurangbord:

  SELECT 
    b.id as table_id,
    c.area_desc,
    CASE 
      WHEN a.dine_in_table_id IS NULL THEN ‘VACANT’ 
      ELSE ‘OCCUPIED’
    END AS current_table_status
  FROM dine_in_table_sitting a, dine_in_table b, dine_in_table_area
  WHERE a.dine_in_table_id (+) = b.id
  	AND b.dine_in_table_area = c.id
  	AND a.dine_out_time IS NULL;
  

• kot_status – Den här tabellen innehåller alla möjliga statusar för en KOT:order mottagen , beställning pågår , beställning levererad osv.
• kot_menu_item – Den här transaktionstabellen lagrar detaljerna för alla artiklar i en KOT. Den definierar också förhållandet mellan KOT och en menu_item . menu_item_id och quantity fält mot ett kot_id ange varan vid beställning och hur mycket av den som behövs.

KOD (Kitchen Order Delivery) Hantering

En stor del av hur väl en restaurang presterar handlar om att hantera KOT inne i köket. Vanligtvis samlar en handledare in KOT från servitörer, andra anställda eller ett onlinesystem. Därefter tilldelar handledaren menyalternativen till en eller flera kockar. Kocken förbereder föremålen och lämnar över dem till handledaren. Sedan hämtar servitören eller annan personal beställningen och levererar den till kunden.

Men det är inte allt som KOD-ledningen inkluderar. Att hantera resurser, lagra ingredienser, regelbundet uppdatera återstående lager och begära nytt lager vid behov är också en del av den dagliga driften av köket. Arbetsledaren spelar en framträdande roll i kökets sömlösa drift, särskilt under rusningstid. Ett system anses vara "smart" eller "intelligent" om det kan replikera en arbetsledares arbetsfunktioner – vilket är nästan omöjligt på de flesta ställen.

För att bygga en modell för denna komplexa ledning skapar jag en annan tabell med namnet KOD . Denna tabell består av följande kolumner:

Menyhantering

Denna komponent är lika viktig som KOT- och KOD-hantering. Menyn – både i sin visuella presentation och i rätterna den erbjuder – är något av det första som lockar kunder. Så varje krögare försöker hålla sin meny så lockande som möjligt.

Låt oss skapa ett annat bord för menydetaljer. Jag kommer att lägga till kolumner för alla detaljer vi vanligtvis ser på en meny:

Lösa verkliga restaurangproblem med data

Vissa problem är extremt vanliga i matservicevärlden. Särskilt tänker jag på långa väntetider, både för att sitta vid ett bord och för att få mat. Dessa problem kan ofta åtminstone delvis lösas genom att bättre organisera och använda restaurangdata.

I en middagsmiljö är det få saker som är mer irriterande för kunderna än att behöva vänta länge på ett bord. Att minimera kundernas väntetider under rusningstid kräver att man håller en noggrann koll på statusen för enskilda bord. Om det inte finns någon ordentlig hantering av bord och personal börjar kundernas väntetider att växa. Om väntetiderna är för långa kan kunderna gå och leta efter en annan restaurang som kommer att servera dem snabbt.

Man kan ta itu med denna oro genom att införa vissa förändringar i denna datamodell. Dessa ändringar skulle:

1. Lägg till tabellhantering i realtid, ett digitaliserat sätt att hantera tabelltillgänglighet, statusspårning och utnyttjandegrad.
2. Minska handläggningstiden för bord genom att mäta personalens effektivitet och möjliggöra effektiv planering av personalstyrkan – till exempel genom att sammanställa ett städteam och tilldela personal till ett bord eller en grupp bord.
3. Publicera realtidsstatusen för enskilda tabeller på chefernas skärmar, så att de kan hålla ett öga på alla pågående aktiviteter.

Ett annat problem är att få kunderna att vänta på sin mat. För både dining-in och takeaway-kunder kan detta underlättas genom att ge statusuppdateringar direkt till matgästen. Övervakning av statusen för enskilda KOT:er är avgörande här. När KOT fortskrider i köket uppdateras dess status i KOT tabell. Denna mekanism ger en realtidsuppdatering till kunder om statusen för deras beställningar.

Hur kan vi göra denna restaurangdatamodell bättre?

Det finns så många innovativa idéer som restaurangägare och operatörer kommer på för att attrahera och behålla sina kunder. Till exempel:

• Många kör kundlojalitetsprogram. Dessa upprätthåller ett lojalitetskonto för kunder och ger gästerna poäng för varje besök, köp etc. Matgäster kan lösa in dessa poäng när och när de vill för olika belöningar (vanligtvis lite gratis mat, en procentsats på deras check eller en gratis måltid) .
• Vissa restauranger gör sina menyalternativ så anpassningsbara som möjligt. De låter sina middagsgäster välja ingredienser till sallader eller pasta, eller så ersätter de mat för att uppfylla vissa dietrestriktioner.

Lagerhantering är ett annat område som spelar en framträdande roll för att göra en restaurang lönsam.

Kan vi bygga in dessa förmågor i denna datamodell? Dela dina tankar i kommentarsfältet nedan.