Сервиране на вкусна храна (и данни) – Модел на данни за ресторанти

Каква роля играе дизайнът на база данни при управлението на ресторант? Как може да изглежда моделът на данни за база данни на ресторанти? Разберете в тази статия.

Ресторант обслужва хора с готови ястия. Това е вид бизнес, който процъфтява по целия свят и често с много блясък. Хората се чувстват много комфортно да ходят на ресторанти и започват да очакват широка гама от опции, когато става въпрос за следващото им хранене.

Само в Ню Йорк има повече от 24 000 заведения за хранене. Те включват заведения за вкъщи (т.е. пица, подмагазини, китайска храна за вкъщи), деликатеси, кафенета и изискани ресторанти. Следната поговорка пасва много добре на ресторантьорската индустрия; това на практика е тяхната универсална мисия:

Правете това, което правите толкова добре, че те ще искат да го видят отново и да доведат своите приятели и семейство.

Уолт Дисни

Защо ресторантите се нуждаят от бази данни?

Управлението на ресторантьорството не е лесна задача. Когато става въпрос за проследяване и изпълнение на ежедневни задачи, дори и най-опитният ресторантьор може да има повече, отколкото лесно може да управлява. Управлението на печеливш ресторант изисква управление на инвентара/запасите, минимизиране на отпадъците, управление на масите (особено в пиковите часове), поддържане на удобно за клиентите меню, ефективно изпълнение на поръчките и наблюдение на персонала на ресторанта. Това е много!

Системата за управление на ресторанти трябва да изпълнява повечето от тези дейности с минимална ръчна намеса. Тя трябва да предоставя на мениджърите точна информация, за да могат да поддържат клиентите доволни. Това може да означава извършване на подходящи промени в менюто и дори в начина на функциониране на ресторанта.

Моделът на данни за ресторант

Тази статия е свързана с проектиране на пълноправен модел на данни за ресторант (за хранене или за вкъщи). Ще разгледаме и два големи проблема, с които хората в ресторантьорския бизнес се сблъскват в ежедневните си дейности. И накрая, ще помислим за промените, необходими за вграждането на тези възможности в съществуваща система.

Докато се потапяме в модела на данните, ще спомена някои потребителски роли. Тези роли всъщност са за членове на персонала, като например:

• Мениджър – Управлява инвентара, заплатите, графика на служителите и показателите за ресторанта
• Хост – Настанява гостите и присвоява сървъри на маси
• Сервитьор (известен също като сървър) – Отвежда поръчките на клиентите в кухнята и доставя подготвената поръчка на клиента
• Надзорник (известен също като готвач или главен готвач) – Наблюдава задачите в кухнята и възлага задачи на готвачи
• Готвене – чете подробностите за поръчката, получени от надзора, приготвя храната и информира надзора, когато е готова
• Busboy – Следи кои таблици се използват; почиства таблици и актуализира състоянието им, ако е необходимо

Моделът на данни за ресторантьорски бизнес трябва да има следните елементарни характеристики:

• Управление на KOT (Token за поръчка в кухня)
• Управление на KOD (доставка на поръчки в кухнята)
• Управление на менютата

Нека разгледаме подробно всяка от тези функции.

Управление на KOT (Token за поръчка в кухня)

Това е най-важната част от нашия модел на данни:става въпрос за събиране на подробности за поръчки от клиенти чрез различни канали. Защо различни канали? Защото има няколко начина, по които могат да се правят поръчки – онлайн или чрез мобилно приложение, чрез телефонни обаждания или чрез сервитьори или други служители. Всеки път, когато се направи поръчка от клиент, се генерира KOT (Kitchen Order Token). В крайна сметка KOT ще бъде приготвен от кухненския персонал.

Ще създам таблица, kot , за съхраняване на данните за предварителната поръчка. Тази таблица има следните колони:

Бих искал да отбележа, че поръчка, събрана от една маса наведнъж, е маркирана под един kot_id . Ако същата таблица по-късно поръча още артикули, системата ще генерира друг kot_id и ще маркира всички тези нови артикули под този идентификатор. В крайна сметка всички kot_ids за една и съща таблица ще бъдат събрани в окончателната сметка.

Управлението на KOT изисква допълнителни статични и транзакционни таблици, които са:

• order_channel – Тази таблица съдържа подробности за каналите, които ресторантът използва за приемане на поръчки. Често срещаните примери включват онлайн, вечеря, отнемане (изнасяне) и т.н.

• dine_in_table_sitting – Това е транзакционна таблица, която съхранява данни за заетостта на таблицата. Неговите колони включват dine_in_table_id , dine_in_time , dine_out_time , num_person_sitting и customer_id . Веднага щом хостът присвои клиент към таблица и въведе информацията в системата, в тази таблица се вмъква запис. За да извлечете текущото състояние на заетост на масите във всеки даден момент, това е таблицата, която ще се използва.

  Да предположим, че искате да изградите тази функция. Ето SQL, който ще ви каже текущото състояние на заетост за всички маси в ресторанта:

  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 – Тази таблица съдържа всички възможни състояния за KOT:получена поръчка , поръчката в процес , поръчката е доставена и др.
• kot_menu_item – Тази транзакционна таблица съхранява подробностите за всички артикули в KOT. Той също така дефинира връзката между KOT и menu_item . menu_item_id и quantity полета срещу kot_id обозначава артикула по поръчка и колко от него е необходимо.

Управление на KOD (доставка на поръчки в кухня)

Голяма част от това колко добре се представя ресторантът се свежда до управлението на KOT в кухнята. Обикновено ръководителят събира KOT от сервитьори, други служители или онлайн система. След това ръководителят възлага елементите от менюто на един или повече готвачи. Готвачът приготвя продуктите и ги предава на ръководителя. След това сервитьорът или друг служител събира поръчката и я доставя на клиента.

Но това не е всичко, което включва управлението на KOD. Управлението на ресурси, складирането на съставките, редовното актуализиране на оставащия инвентар и изискването на нов инвентар при необходимост също е част от ежедневната работа на кухнята. Супервайзерът играе важна роля в безпроблемното функциониране на кухнята, особено в пиковите часове. Една система се счита за „интелигентна“ или „интелигентна“, ако може да възпроизведе работните функции на ръководителя – което е почти невъзможно на повечето места.

За да създам модел за тази сложна част от управлението, ще създам друга таблица, наречена KOD . Тази таблица се състои от следните колони:

Управление на менютата

Този компонент е толкова важен, колкото управлението на KOT и KOD. Менюто – както във визуалното си представяне, така и в ястията, които предлага – е едно от първите неща, които привличат клиентите. Така че всеки ресторантьор се опитва да поддържа менюто си възможно най-примамливо.

Нека създадем друга таблица, която да съдържа подробности от менюто. Ще добавя колони за всички подробности, които обикновено виждаме в менюто:

Решаване на проблеми с ресторантите в реалния свят с данни

Някои проблеми са изключително често срещани в света на хранителните услуги. По-специално, имам предвид дългите времена на чакане, както за сядане на маса, така и за храна. Тези проблеми често могат да бъдат решени поне частично чрез по-добро организиране и използване на данни за ресторантите.

В обстановка за вечеря малко неща са по-досадни за клиентите от това да се налага да чакат дълго време за маса. Намаляването на времето за чакане на клиентите в пиковите часове изисква внимателно наблюдение на състоянието на отделните маси. Ако няма правилно управление на масите и персонала, времето за чакане на клиентите започва да расте. Ако времето за изчакване е твърде дълго, клиентите може да напуснат и да потърсят друг ресторант, който да ги обслужи бързо.

Човек може да се справи с този проблем чрез въвеждане на определени промени в този модел на данни. Тези промени биха:

1. Добавете управление на таблици в реално време, дигитализиран начин за управление на наличността на таблицата, проследяване на състоянието и степента на използване.
2. Намалете времето за изпълнение на масата, като измервате ефективността на персонала и позволявате ефективно планиране на работната сила – например чрез събиране на екипаж за почистване и назначаване на персонал на маса или група маси.
3. Публикувайте състоянието в реално време на отделните таблици на екраните на мениджърите, така че те да могат да следят всички предстоящи дейности.

Друг проблем е да кара клиентите да чакат храната си. И за клиентите за вечеря и за вкъщи, това може да бъде подпомогнато чрез предоставяне на актуализации на състоянието директно на закусвалнята. Мониторингът на състоянието на отделните KOT е жизненоважен тук. С напредването на KOT в кухнята състоянието му се актуализира в KOT маса. Този механизъм предоставя актуализация в реално време на клиентите за състоянието на техните поръчки.

Как можем да направим този модел на данни за ресторанта по-добър?

Има толкова много иновативни идеи, които собствениците и операторите на ресторанти измислят, за да привлекат и задържат своите клиенти. Например:

• Много изпълняват програми за лоялност на клиентите. Те поддържат акаунт за лоялност за клиентите и дават на гостите точки за всяко посещение, покупка и т.н. Гостите могат да осребрят тези точки, когато пожелаят, за различни награди (обикновено някаква безплатна храна, процент от чека им или безплатно хранене) .
• Някои заведения за хранене правят елементите от менюто си възможно най-персонализирани. Те позволяват на своите посетители да избират съставки за салати или тестени изделия или заменят храни, за да отговорят на определени диетични ограничения.

Управлението на инвентара е друга област, която играе важна роля за печелившите на ресторанта.

Можем ли да вградим тези възможности в този модел на данни? Споделете вашите мисли в секцията за коментари по-долу.