Servering af lækker mad (og data) – en datamodel for restauranter

Hvilken rolle spiller databasedesign i at drive en restaurant? Hvordan kan datamodellen for en restaurantdatabase se ud? Find ud af det i denne artikel.

En restaurant serverer folk med færdiglavet mad. Dette er en type virksomhed, der blomstrer over hele verden, og ofte med en masse blus. Folk føler sig meget trygge ved at gå på restauranter, og de begynder at forvente en bred vifte af muligheder, når det kommer til deres næste måltid.

Alene i New York City er der mere end 24.000 spisesteder. Disse omfatter takeaways (dvs. pizza, underbutikker, kinesisk takeaway), delikatesseforretninger, caféer og fine restauranter. Følgende ordsprog passer rigtig godt til restaurationsbranchen; det er praktisk talt deres universelle mission:

Gør det, du gør, så godt, at de vil se det igen og tage deres venner og familie med.

Walt Disney

Hvorfor har restauranter brug for databaser?

Restaurantledelse er ikke en nem opgave. Når det kommer til at holde styr på og løse daglige opgaver, kan selv den mest erfarne restauratør godt have mere, end de nemt kan klare. At drive en rentabel restaurant kræver styring af inventar/lager, minimering af spild, styring af borde (især i spidsbelastningstider), opretholdelse af en kundevenlig menu, eksekvering af ordrer effektivt og tilsyn med restaurantpersonale. Det er ret meget!

Et restaurantstyringssystem skal udføre de fleste af disse aktiviteter med minimal manuel indgriben. Det skal præsentere lederne for præcis information, så de kan holde kunderne glade. Dette kan betyde, at der foretages passende ændringer i menuen og endda måden, restauranten fungerer på.

Restaurantdatamodellen

Denne artikel handler om at designe en fuldgyldig datamodel til en restaurant (dine-in eller takeaway). Vi vil også behandle to store problemer, som folk i restaurationsbranchen støder på i deres daglige aktiviteter. Til sidst vil vi tænke på de ændringer, der er nødvendige for at indbygge disse muligheder i et eksisterende system.

Når vi dykker ned i datamodellen, vil jeg nævne visse brugerroller. Disse roller er faktisk for medarbejdere, såsom:

• Manager – administrerer lagerbeholdning, løn, medarbejderplanlægning og metrics for restauranten
• Vært – Sæder gæster og tildeler servere til borde
• Tjener (også kendt som server) – Tager kunders ordrer til køkkenet og leverer den forberedte ordre til kunden
• Supervisor (også kendt som kok eller køkkenchef) – Overvåger opgaver i køkkenet og tildeler opgaver til kokke
• Tilbered – læser ordreoplysningerne modtaget fra supervisoren, tilbereder maden og informerer supervisoren, når den er klar
• Busboy – Holder styr på, hvilke tabeller der bruges; renser tabeller og opdaterer deres status efter behov

En datamodel for en restaurationsvirksomhed skal have følgende elementære funktioner:

• KOT-styring (køkkenordretoken)
• KOD-styring (køkkenordrelevering)
• Menustyring

Lad os se nærmere på hver af disse funktioner.

KOT-styring (køkkenbestillingstoken)

Dette er den vigtigste del af vores datamodel:Det handler om at indsamle ordredetaljer fra kunder gennem forskellige kanaler. Hvorfor forskellige kanaler? For der er flere måder at bestille bestillinger på – online eller via mobilapp, ved telefonopkald eller gennem tjenere eller andre medarbejdere. Hver gang en ordre afgives af en kunde, genereres en KOT (Køkkenordretoken). Til sidst vil KOT'en blive udarbejdet af køkkenpersonalet.

Jeg opretter en tabel, kot , for at opbevare de foreløbige ordredetaljer. Denne tabel har følgende kolonner:

Jeg vil gerne påpege, at en ordre indsamlet fra ét bord ad gangen er tagget under én kot_id . Hvis den samme tabel senere bestiller flere varer, vil systemet generere endnu et kot_id og tagge alle disse nye varer under dette ID. I sidste ende alle kot_ids for samme tabel vil blive lagt sammen i den endelige regning.

KOT-styring kræver yderligere statiske og transaktionstabeller, som er:

• order_channel – Denne tabel indeholder detaljer om de kanaler, en restaurant bruger til at modtage ordrer. Almindelige eksempler omfatter online, spise middag, take away (udføre) osv.

• dine_in_table_sitting – Dette er en transaktionstabel, der gemmer data om bordbelægning. Dens kolonner inkluderer dine_in_table_id , dine_in_time , dine_out_time , num_person_sitting og customer_id . Så snart værten tildeler en kunde til en tabel og indtaster informationen i systemet, indsættes en post i denne tabel. For at hente den aktuelle belægningsstatus for borde på et givet tidspunkt, er dette den tabel, der vil blive brugt.

  Antag, at du vil bygge denne funktion. Her er SQL'en, der fortæller dig den aktuelle belægningsstatus for alle restaurantborde:

  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 – Denne tabel indeholder alle mulige statusser for en KOT:ordre modtaget , ordre under behandling , ordre leveret osv.
• kot_menu_item – Denne transaktionstabel gemmer detaljerne for alle elementerne i en KOT. Det definerer også forholdet mellem KOT'en og en menu_item . menu_item_id og quantity felter mod en kot_id angive varen på bestilling, og hvor meget af den er nødvendig.

KOD (Køkkenordrelevering) Management

En stor del af, hvor godt en restaurant præsterer, bunder i at styre KOT inde i køkkenet. Normalt indsamler en supervisor KOT'er fra tjenere, andre medarbejdere eller et online system. Derefter tildeler vejlederen menupunkterne til en eller flere kokke. Kokken tilbereder tingene og afleverer dem til vejlederen. Så afhenter tjeneren eller en anden medarbejder ordren og leverer den til kunden.

Men det er ikke alt, som KOD-ledelsen omfatter. Håndtering af ressourcer, oplagring af ingredienser, løbende opdatering af resterende varebeholdning og anmodning om nyt inventar efter behov er også en del af den daglige drift af køkkenet. Vejlederen spiller en fremtrædende rolle i køkkenets problemfri drift, især i myldretiden. Et system betragtes som 'smart' eller 'intelligent', hvis det kan replikere en supervisors jobfunktioner - hvilket er tæt på umuligt de fleste steder.

For at bygge en model for dette komplekse stykke ledelse, vil jeg oprette en anden tabel ved navn KOD . Denne tabel består af følgende kolonner:

Menustyring

Denne komponent er lige så vigtig som KOT- og KOD-styring. Menuen – både i sin visuelle præsentation og i de retter, den byder på – er noget af det første, der tiltrækker kunder. Så enhver restauratør forsøger at holde deres menu så lokkende som muligt.

Lad os oprette en anden tabel til at indeholde menudetaljer. Jeg vil tilføje kolonner for alle de detaljer, vi normalt ser på en menu:

Løsning af virkelige restaurantproblemer med data

Nogle problemer er ekstremt almindelige i madserviceverdenen. Jeg tænker især på lange ventetider, både for at sidde ved et bord og for at få din mad. Disse problemer kan ofte i det mindste delvist løses ved bedre at organisere og bruge restaurantdata.

I et spisested er få ting mere irriterende for kunderne end at skulle vente længe på et bord. At minimere kundernes ventetider i myldretiden kræver, at man holder nøje øje med de enkelte bordes status. Hvis der ikke er nogen ordentlig styring af borde og personale, begynder kundernes ventetider at vokse. Hvis ventetiderne er for lange, kan kunderne gå og lede efter en anden restaurant, der vil servere dem hurtigt.

Man kan løse denne bekymring ved at indføre visse ændringer i denne datamodel. Disse ændringer ville:

1. Tilføj tabelstyring i realtid, en digitaliseret måde at administrere tabeltilgængelighed, statussporing og udnyttelsesgrad på.
2. Reducer bordgennemløbstiden ved at måle personaleeffektiviteten og muliggøre effektiv planlægning af arbejdsstyrken – for eksempel ved at samle et rengøringshold og tildele personale til et bord eller en gruppe af borde.
3. Offentliggør realtidsstatus for individuelle tabeller på ledernes skærme, så de kan holde øje med eventuelle langvarige aktiviteter.

Et andet problem er at få kunderne til at vente på deres mad. For både dine-in- og takeaway-kunder kan dette hjælpes ved at give statusopdateringer direkte til dineren. Overvågning af status for individuelle KOT'er er afgørende her. Efterhånden som KOT'en skrider frem i køkkenet, bliver dens status opdateret i KOT bord. Denne mekanisme giver en opdatering i realtid til kunder om status for deres ordrer.

Hvordan kan vi gøre denne restaurantdatamodel bedre?

Der er så mange innovative ideer, som restaurantejere og -operatører kommer med for at tiltrække og fastholde deres kunder. For eksempel:

• Mange kører kundeloyalitetsprogrammer. Disse opretholder en loyalitetskonto for kunderne og giver gæster point for hvert besøg, køb osv. Dine gæster kan indløse disse point, når og når de har lyst til forskellige belønninger (normalt noget gratis mad, en procentdel rabat på deres check eller et gratis måltid). .
• Nogle spisesteder gør deres menupunkter så tilpassede som muligt. De giver deres gæster mulighed for at vælge ingredienser til salater eller pastaer, eller de erstatter fødevarer for at overholde visse diætrestriktioner.

Lagerstyring er et andet område, der spiller en fremtrædende rolle i at gøre en restaurant rentabel.

Kan vi bygge disse muligheder ind i denne datamodel? Del dine tanker i kommentarfeltet nedenfor.