Heerlijk eten (en gegevens) serveren - een gegevensmodel voor restaurants

Welke rol speelt databaseontwerp bij het runnen van een restaurant? Hoe zou het datamodel voor een restaurantdatabase eruit kunnen zien? Ontdek het in dit artikel.

Een restaurant serveert mensen met kant-en-klaar eten. Dit is een type bedrijf dat over de hele wereld bloeit, en vaak met veel flair. Mensen voelen zich erg op hun gemak als ze naar restaurants gaan en ze beginnen een breed scala aan opties te verwachten als het gaat om hun volgende maaltijd.

Alleen al in New York City zijn er meer dan 24.000 eetgelegenheden. Deze omvatten afhaalrestaurants (d.w.z. pizza, subwinkels, Chinese afhaalmaaltijden), delicatessenwinkels, cafés en uitstekende restaurants. Het volgende gezegde past heel goed in de horeca; het is praktisch hun universele missie:

Doe wat je doet zo goed dat ze het nog een keer willen zien en hun vrienden en familie mee willen nemen.

Walt Disney

Waarom hebben restaurants databases nodig?

Restaurantbeheer is geen gemakkelijke taak. Als het gaat om het bijhouden en uitvoeren van dagelijkse taken, heeft zelfs de meest ervaren restaurateur misschien meer dan ze gemakkelijk aankunnen. Het runnen van een winstgevend restaurant vereist het beheren van inventaris/voorraad, het minimaliseren van verspilling, het beheren van tafels (vooral tijdens piekuren), het onderhouden van een klantvriendelijk menu, het efficiënt uitvoeren van bestellingen en het toezicht houden op het restaurantpersoneel. Dat is best veel!

Een restaurantbeheersysteem moet de meeste van deze activiteiten uitvoeren met minimale handmatige tussenkomst. Het moet de managers nauwkeurige informatie bieden, zodat ze klanten tevreden kunnen houden. Dit kan betekenen dat u de menukaart en zelfs de manier waarop het restaurant functioneert op de juiste manier moet wijzigen.

Het restaurantgegevensmodel

Dit artikel gaat over het ontwerpen van een volwaardig datamodel voor een restaurant (dine-in of takeaway). We zullen ook twee grote problemen aanpakken die mensen in de restaurantsector tegenkomen in hun dagelijkse activiteiten. Ten slotte zullen we nadenken over de veranderingen die nodig zijn om die mogelijkheden in een bestaand systeem in te bouwen.

Terwijl we in het datamodel duiken, zal ik bepaalde gebruikersrollen noemen. Deze rollen zijn eigenlijk voor medewerkers, zoals:

• Manager – Beheert inventaris, salarisadministratie, personeelsplanning en statistieken voor het restaurant
• Host - Zet gasten neer en wijst servers toe aan tafels
• Ober (ook bekend als server) - Brengt de bestellingen van klanten naar de keuken en bezorgt de voorbereide bestelling aan de klant
• Supervisor (ook bekend als chef-kok of chef-kok) - Houdt toezicht op taken in de keuken en wijst taken toe aan koks
• Koken - Leest de bestelgegevens die van de supervisor zijn ontvangen, bereidt het eten en informeert de supervisor wanneer het klaar is
• Busboy – Houdt bij welke tabellen worden gebruikt; maakt tabellen schoon en werkt hun status indien nodig bij

Een datamodel voor een restaurantbedrijf moet de volgende elementaire kenmerken hebben:

• KOT (Kitchen Order Token) Beheer
• KOD (Kitchen Order Delivery)-beheer
• Menubeheer

Laten we elk van deze functies in detail bekijken.

KOT (Kitchen Order Token) Beheer

Dit is het belangrijkste onderdeel van ons datamodel:het gaat om het verzamelen van ordergegevens van klanten via verschillende kanalen. Waarom verschillende zenders? Omdat er verschillende manieren zijn waarop bestellingen kunnen worden gedaan - online of via de mobiele app, door te bellen, of via obers of andere medewerkers. Telkens wanneer een bestelling door een klant wordt geplaatst, wordt een KOT (Kitchen Order Token) gegenereerd. Uiteindelijk wordt het KOT door het keukenpersoneel klaargemaakt.

Ik zal een tabel maken, kot , om de details van de voorlopige bestelling vast te houden. Deze tabel heeft de volgende kolommen:

Ik wil u erop wijzen dat een bestelling die aan één tafel tegelijk wordt verzameld, is getagd onder één kot_id . Als dezelfde tafel later meer items bestelt, zal het systeem een ​​andere kot_id genereren en al deze nieuwe items onder die ID taggen. Uiteindelijk zijn alle kot_ids voor dezelfde tafel worden bij elkaar opgeteld in de eindafrekening.

KOT-beheer vereist aanvullende statische en transactietabellen, namelijk:

• order_channel – Deze tabel bevat details over de kanalen die een restaurant gebruikt om bestellingen te accepteren. Veelvoorkomende voorbeelden zijn online, dineren, afhalen (afhalen), enz.

• dine_in_table_sitting – Dit is een transactietabel waarin tafelbezettingsgegevens worden opgeslagen. De kolommen bevatten dine_in_table_id , dine_in_time , dine_out_time , num_person_sitting , en customer_id . Zodra de host een klant aan een tafel toewijst en de informatie in het systeem invoert, wordt een record in deze tabel ingevoegd. Om de huidige bezettingsstatus van tafels op een bepaald moment op te halen, is dit de tafel die zal worden gebruikt.

  Stel dat u deze functie wilt bouwen. Hier is de SQL die u de huidige bezettingsstatus voor alle restauranttafels vertelt:

  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 – Deze tabel bevat alle mogelijke statussen voor een KOT:bestelling ontvangen , bestelling in behandeling , bestelling afgeleverd , enz.
• kot_menu_item – Deze transactietabel slaat de details op van alle items in een KOT. Het definieert ook de relatie tussen de KOT en een menu_item . De menu_item_id en quantity velden tegen een kot_id geef het item in bestelling aan en hoeveel ervan nodig is.

KOD (Kitchen Order Delivery) Beheer

Een groot deel van hoe goed een restaurant presteert, komt neer op het beheren van KOT in de keuken. Meestal verzamelt een supervisor KOT's van obers, andere werknemers of een online systeem. Vervolgens wijst de supervisor de menu-items toe aan een of meerdere koks. De kok maakt de gerechten klaar en overhandigt deze aan de begeleider. Vervolgens haalt de ober of een andere medewerker de bestelling op en levert deze af bij de klant.

Maar dat is niet alles wat KOD-beheer omvat. Het beheren van middelen, het opslaan van ingrediënten, het regelmatig bijwerken van de resterende voorraad en het aanvragen van nieuwe voorraad indien nodig, maakt ook deel uit van de dagelijkse werking van de keuken. De supervisor speelt een prominente rol in de naadloze werking van de keuken, vooral tijdens de piekuren. Een systeem wordt als 'slim' of 'intelligent' beschouwd als het de functies van een supervisor kan repliceren - wat op de meeste plaatsen bijna onmogelijk is.

Om een ​​model te bouwen voor dit complexe stuk management, zal ik een andere tabel maken, genaamd KOD . Deze tabel bestaat uit de volgende kolommen:

Menubeheer

Dit onderdeel is net zo belangrijk als KOT- en KOD-beheer. Het menu – zowel in de visuele presentatie als in de gerechten die het aanbiedt – is een van de eerste dingen die klanten aantrekt. Dus elke restauranthouder probeert zijn menu zo aantrekkelijk mogelijk te houden.

Laten we een andere tabel maken met menudetails. Ik zal kolommen toevoegen voor alle details die we gewoonlijk in een menu zien:

Realistische restaurantproblemen oplossen met gegevens

Sommige problemen komen heel vaak voor in de foodservicewereld. Ik denk daarbij vooral aan lange wachttijden, zowel om aan een tafel te zitten als om je eten te halen. Deze problemen kunnen vaak ten minste gedeeltelijk worden opgelost door restaurantgegevens beter te organiseren en te gebruiken.

In een dine-in setting zijn weinig dingen vervelender voor klanten dan lang moeten wachten op een tafel. Om de wachttijden van klanten tijdens piekuren te minimaliseren, moet u de status van afzonderlijke tafels nauwlettend in de gaten houden. Als er geen goed beheer van tafels en personeel is, beginnen de wachttijden voor klanten te groeien. Als de wachttijden te lang zijn, kunnen klanten vertrekken en op zoek gaan naar een ander restaurant dat hen snel van dienst is.

Men kan deze zorg wegnemen door bepaalde wijzigingen in dit datamodel door te voeren. Deze wijzigingen zouden:

1. Voeg realtime tafelbeheer toe, een gedigitaliseerde manier om tafelbeschikbaarheid, statusregistratie en gebruikspercentages te beheren.
2. Verkort de doorlooptijd van tafels door de efficiëntie van het personeel te meten en een effectieve personeelsplanning mogelijk te maken, bijvoorbeeld door een schoonmaakploeg samen te stellen en personeel toe te wijzen aan een tafel of een groep tafels.
3. Publiceer de realtime status van individuele tabellen op de schermen van de managers, zodat ze een oogje kunnen houden op langlopende activiteiten.

Een ander probleem is dat klanten op hun eten moeten wachten. Voor zowel diner- als afhaalklanten kan dit worden geholpen door statusupdates rechtstreeks aan het diner te verstrekken. Het monitoren van de status van individuele KOT's is hierbij essentieel. Naarmate de KOT vordert in de keuken, wordt de status bijgewerkt in de KOT tafel. Dit mechanisme geeft klanten realtime een update over de status van hun bestellingen.

Hoe kunnen we dit restaurantgegevensmodel verbeteren?

Er zijn zoveel innovatieve ideeën die restauranteigenaren en -exploitanten bedenken om hun klanten aan te trekken en te behouden. Bijvoorbeeld:

• Velen voeren klantloyaliteitsprogramma's uit. Deze houden een loyaliteitsaccount bij voor klanten en geven gasten punten voor elk bezoek, elke aankoop, enz. Diners kunnen deze punten verzilveren wanneer ze maar willen voor verschillende beloningen (meestal wat gratis eten, een percentage van hun cheque of een gratis maaltijd) .
• Sommige eetgelegenheden maken hun menu-items zo aanpasbaar mogelijk. Ze laten hun gasten ingrediënten kiezen voor salades of pasta's, of ze vervangen voedsel om aan bepaalde dieetbeperkingen te voldoen.

Voorraadbeheer is een ander gebied dat een prominente rol speelt bij het winstgevend maken van een restaurant.

Kunnen we deze mogelijkheden inbouwen in dit datamodel? Deel uw mening in het commentaargedeelte hieronder.