AI-система управления рестораном: что она реально делает

Четыре разных продукта носят одно название

Словосочетание «AI-система управления рестораном» прицеплено минимум к четырём вещам, и общего у них почти ничего нет.

Производитель касс называет так POS с графиком продаж. Производитель бронирований — виджет столиков, который сам отправляет гостю подтверждение. Производитель бэк-офиса — складскую картотеку с флажком «остаток кончается». А четвёртая группа называет так нечто действительно другое: слой, который читает первых трёх, пересчитывает рабочие показатели заведения и говорит, когда один из них ушёл достаточно далеко, чтобы под него потребовалось решение.

Управленческий слой — только четвёртое. Первые три — операционные системы, которые обзавелись графиком, а график управлением не является. Эта страница про четвёртое, и написана она затем, чтобы ты мог отличить одно от другого в разговоре с продавцом, — потому что путаница дорого стоит именно там.

Размывание термина не случайно. И «система управления», и «ИИ» — слова, за которыми в этом рынке никто не следит, и у любого операционного поставщика есть коммерческая причина к ним тянуться. Единственный надёжный выход — перестать спрашивать, как продукт называется, и начать спрашивать, на какой вопрос он отвечает и кто первым начинает разговор.

Управленческий слой ресторана — программа, которая потребляет данные операционных систем и производит решения, цели и исключения, а не транзакции.

Заметь, что в этом определении нет ни слова про интеллект. Слой может быть полностью безмодельным и остаться управленческим; слой может быть набит моделями и остаться операционным. Признак — направление работы, а не начинка.

Три слоя ресторанного стека: касса, учёт и управление

Почти каждое заведение, которое торгует не первый месяц, уже держит два слоя. Путаница с третьим начинается ровно оттого, что первые два никто не назвал по именам.

Важная строка тут последняя, а важная ячейка в ней — «ничего своего». Управленческий слой, который завёл собственные транзакции, тихо превратился во вторую кассу, и теперь у тебя две версии вчерашней выручки, которые никогда не сойдутся. Слой оправдывает своё место именно тем, что производный: он владеет интерпретацией, а не записями.

Это ровно тот же разговор, что про добавление CRM или ERP: вопрос никогда не звучит как «хороший ли это софт», он звучит как «какого слоя в моём стеке нет». Рассуждение переносится почти без потерь и разобрано подробно в статье какой слой системы добавлять следующим.

Практическое следствие, о котором редко предупреждают: слои покупаются в разном порядке, но работают только снизу вверх. Управленческий слой поверх пустоты не даёт ничего, кроме красивого экрана, — и это не фигура речи, а буквальное описание того, что произойдёт.

Чем управленческий слой отличается от кассы

Любая касса, которую стоит покупать, приезжает с отчётами. Именно поэтому различие и теряется.

Отчёт кассы — это запрос к её собственным таблицам. Она знает продажи, позиции, время и сотрудников, потому что именно это она и записала. Она не знает, сколько ты заплатил за продукты в этом блюде, потому что счёт поставщика ушёл в другую систему. Она не знает, что кухня на самом деле израсходовала, потому что инвентаризация живёт третьим местом. Она не знает, во сколько обошлась смена, потому что табель — четвёртая система.

Значит, касса умеет сказать, что ты продал двести порций блюда. Она не умеет сказать, заработал ли ты на них. Каждая цифра, которая что-то значит на уровне решения, — это цифра, пересекающая системы, и касса структурно неподходящее место для её вычисления. Не потому, что она плохо сделана, а потому, что ей видна только её половина арифметики.

Второе различие — кто начинает. Отчёт кассы существует в тот момент, когда ты его открыл. У него нет мнения о том, стоит ли сегодняшний день твоего внимания.

POS (касса) — система, записывающая транзакции. Это первичный источник данных о продажах и позициях, а не инструмент анализа.

Из этого следует простое правило разговора с продавцом: если на демонстрации показывают отчёт, спроси, откуда взялась в нём стоимость. Если стоимость из той же системы, что и выручка, — тебе показывают операционный слой. Ту же дисциплину, только про выбор небольшого набора цифр, которые владелец правда открывает, разбирает страница аналитики ресторана.

Чем он отличается от BI-дашборда

Это различие труднее, потому что дашборд тоже пересекает системы, а хороший дашборд считает те же самые числа.

Разница в направлении. Дашборд — это поверхность, к которой ты идёшь. Он спроектирован из допущения, что человек посмотрит, и он честен в этом: всё, что на нём есть, показано всегда и с одинаковым весом. А значит, он наименее полезен ровно тогда, когда ты занят больше всего, — а в ресторане «занят» это и есть состояние, которое порождает проблемы, достойные поимки.

Последняя строка и разводит категории. У дашборда нет памяти о том, отреагировал ли ты. Управленческий слой считает неотвеченное исключение открытым пунктом, а значит, цифра не может тихо пролежать непрочитанной три недели — самый распространённый способ превратить настоящую проблему в дорогую.

Ничего из этого не делает дашборды неправильными. Слою, который поднимает исключения, всё равно нужна поверхность, чтобы показать подробности за одним из них, и эта поверхность — дашборд. Ошибка в том, чтобы купить поверхность и ждать, что она будет следить. Смежная дисциплина — решить, на какие несколько цифр владелец правда смотрит, а не какие можно нарисовать, — разобрана в статье про автоматизацию отчётности.

Управление по отклонениям — сердцевина всей идеи

Управление по отклонениям — рабочая дисциплина, при которой обычные значения не сообщаются вовсе, а наверх поднимаются только отклонения за порог.

Идея старше софта на десятилетия и растёт из простого наблюдения про внимание: человек, которому показали всё, не видит ничего. Если в твоём утреннем отчёте сорок цифр и тридцать восемь из них нормальные, то две ненормальные замаскированы тридцатью восемью. Отчёт одновременно полный и бесполезный.

Управление по отклонениям переворачивает умолчание. Норма — это тишина. Всё, что приходит, по построению уже сдвинулось. У этой дисциплины есть своя цена, и платится она одним конкретным способом: если порог выставлен плохо, ты получаешь либо ничего (и перестаёшь ему верить), либо всё (и перестаёшь читать). Поэтому порог — не деталь реализации. Порог и есть продукт.

Есть и второе следствие, менее очевидное. При управлении по отклонениям тишина несёт информацию — она означает, что каждая наблюдаемая цифра внутри своего диапазона. Но это верно, только пока подключения живы. Источник, который перестал отдавать данные три дня назад, производит ровно ту же тишину, что и безупречно работающее заведение. Поэтому серьёзный слой следит за собственными входами и поднимает отсутствие данных как отдельный вид исключения, а вопрос «что происходит, когда связь рвётся» — законный вопрос продавцу, а не придирка.

Тишина, которой нельзя доверять, хуже шума: шум ты хотя бы читаешь.

Где здесь ИИ, а где обычная арифметика

Этот раздел существует потому, что отрасль его не напишет, и потому, что страница со словом «AI» в заголовке должна читателю прямой ответ.

Большая часть того, что делает управленческий слой ресторана, — это не искусственный интеллект. Это арифметика и статистика, обе старше самого термина, и ни одна из них не становится ИИ оттого, что выполняется быстро.

Что здесь обычная арифметика, названная своими именами

Prime cost, food cost, доля труда. Это деления. Затраты, поделённые на выручку за период. Модели тут нет и не нужно. Трудность в этих числах никогда не была вычислительной — трудность в том, чтобы оба входа относились к одному периоду и к одному набору позиций, а это задача про сантехнику данных, а не про интеллект. Всё дерево этих показателей разложено на странице про KPI ресторана, а состав самой затратной пары — на странице про prime cost.

Отклонение от цели. Вычитание и деление. Формула ниже, целиком.

Анализ меню. Сортировка позиций по двум осям — как часто каждая продаётся и сколько маржи приносит одна порция — и чтение четырёх квадрантов, которые из этого получаются. Это сортировка и сравнение с посчитанной отсечкой. Метод из восьмидесятых, он работает, и моделью он не является. Разобран на странице про меню-инжиниринг.

Прогноз спроса. Вот здесь стоит быть особенно аккуратным, потому что это самое часто переименовываемое место. Прогноз числа гостей — прикладная статистика: раскладываешь ряд на недельный и годовой рисунок, обрабатываешь известные календарные эффекты, подгоняешь кривую к остатку и честно меряешь ошибку. Современные реализации могут использовать градиентный бустинг или нейросеть на шаге подгонки, и вот это законно называется машинным обучением, — но существо работы лежит в сезонности, календаре и замере ошибки, а хорошо построенная статистическая модель регулярно обыгрывает плохо накормленную нейросеть на истории одного заведения. Назвать сезонное среднее «искусственным интеллектом» — самое частое преувеличение во всей категории. Метод и способ мерить его точность — на странице про прогнозирование спроса, а как это выглядит рабочим инструментом — на странице услуги прогноза.

Пороговые тревоги. Сравнение числа с диапазоном. Диапазон посчитан по твоей собственной истории. Это статистика, и формула напечатана ниже полностью, чтобы её можно было проверить.

Где языковая модель правда делает работу

Чтение документов, которые никто никогда не структурировал. Счёт поставщика приезжает PDF-ом или фотографией, и вёрстка у него меняется от поставщика к поставщику, а иногда от месяца к месяцу. Вытащить оттуда строки, количества и цены — задача, на которой модели зарабатывают своё место, потому что альтернатива это либо человек, перебивающий вручную, либо хрупкий шаблон под каждого поставщика. Это настоящее, это измеримо, и это самый ценный модельный шаг во всём стеке.

Превращение свободного текста в структуру. Тексты отзывов, жалобы, заметки, которые управляющий набрал в конце смены. Разложить их на то, что касается кухни, что зала и что сервиса, и делать это одинаково на разных языках — модельная работа. Ресторан в Варшаве получает отзывы по-польски, по-английски и по-украински, и список ключевых слов такого не переживает.

Ответ на вопрос, заданный словами. «Почему вторник хуже прошлого вторника?» — не тот запрос, который кто-нибудь захочет писать руками. Перевести его в правильное сравнение по твоим же данным, выполнить и вернуть ответ фразой — правда задача для модели. А арифметика под ней при этом остаётся арифметикой.

Объяснение отклонения словами. Сама тревога — это сравнение. А абзац, который говорит, какие три позиции сдвинулись, что на прошлой неделе был выходной день по календарю и что стоит проверить первым, пишет модель, читающая те же самые числа. Это то же ремесло, которым описывается разница между AI-агентом и чат-ботом: первый переводит данные в предложение и берётся за инструменты, второй отвечает заученной фразой.

Почему фраза модели обязана стоять рядом с числом, которое она объясняет

Свойство, которое делает модель полезной на грязном входе, — ровно то же, которое делает её опасной на выходе: она пишет гладкую фразу независимо от того, подкреплена фраза или нет, а уверенный неверный ответ выглядит в точности как уверенный верный.

Это измеримо, и это уже измерили — не в нашей отрасли.

Те системы делали другую работу на другом типе входа, и сами числа на ресторан не переносятся. Переносится характер поломки. Именно поэтому управленческий слой не имеет права показывать абзац модели отдельно: фраза, объясняющая отклонение, обязана стоять рядом с арифметикой, которую она объясняет, с видимыми слагаемыми, — чтобы неверное объяснение ловилось числом, а не принималось на веру за то, что гладко читается. Поставщик, у которого на экране рассказ, а расчёт спрятан, перевернул безопасный порядок.

Проверить это на демонстрации проще всего одной просьбой: покажи настоящую тревогу целиком. Не скриншот дашборда, а то самое письмо или сообщение, которое приходит человеку, — и посмотри, можно ли из него дойти до чисел, не переспрашивая.

Черта, проведённая один раз

Модель очень хороша в том, чтобы читать неструктурированное и писать про структурированное. Она не решает, каким будет твой порог, она не знает про твоё заведение ничего сверх подключённых данных и она не компенсирует источник, который никто не подключил. Если поставщик не может сказать, к какому из двух списков выше относится конкретная функция, — это само по себе ответ.

Поиск аномалий — выявление значений, которые расходятся с ожидаемым рисунком. Это не то же самое, что пробитие фиксированного порога, и различие существенно: фиксированный порог помечает каждую субботу в заведении, у которого субботы законно другие.

Порог тревоги: формула, которая принадлежит этой странице

Все остальные страницы кластера ссылаются за порогом сюда, поэтому здесь он выписан целиком.

Считать надо две разные вещи, и путать их — стандартная ошибка.

Первая — обычное отклонение от цели, которую ты сам себе поставил:

Отклонение % = (Факт − Цель) ÷ Цель × 100

• Факт — измеренное значение за период, в собственной единице показателя (PLN, гости, порции, часы);
• Цель — значение, которое ты решил держать, в той же единице и за период той же длины;
• Отклонение % — проценты.

Разбор размерности: разность двух величин одной единицы, делённая на величину той же единицы, безразмерна; умноженная на сто, она становится процентами. Формула определена, только пока Цель не равна нулю, и осмысленна, только пока обе величины покрывают период одинаковой длины — сравнение четырёхнедельного месяца с пятинедельным через эту формулу даёт отклонение, которое является артефактом календаря, а не событием в заведении.

Обратная проверка: 36 000 × 0,95 = 34 200 PLN. Сходится. Числа здесь условные и взяты только для проверки арифметики.

Вторая формула — та, что решает, поднимется ли вообще что-нибудь. Она не в процентах:

Тревога, когда |Факт − Ожидаемое| > k × σ

• Факт — измеренное значение, в единице показателя;
• Ожидаемое — значение, которое этот же день недели и этот же отрезок дня обычно даёт, в той же единице;
• σ (сигма) — стандартное отклонение остатков, в той же единице;
• k — безразмерный множитель, который выбираешь ты;
• Остаток — для каждого прошлого периода это Факт − Ожидаемое за тот период, в единице показателя.

Разбор размерности: слева разность двух величин в единице показателя, значит, слева величина в этой единице. Справа безразмерное число, умноженное на величину в той же единице, значит, справа тоже величина в этой единице. Сравнение законно.

Обрати внимание, что Ожидаемое стоит в формуле явно. Порог — это УРОВЕНЬ, а не ширина, и запись без центра просто неверна: если центра нет, ширину не от чего отмерять. Это не педантизм — это разница между работающим правилом и правилом, которое сработает на любой субботе.

Прогон руками: Ожидаемое для вторника вечером = 210 гостей, σ остатков = 24 гостя, k = 2. Порог: 2 × 24 = 48 гостей. Тревога поднимается, если факт вышел за 210 ± 48, то есть ниже 162 или выше 258. Факт 150 гостей: |150 − 210| = 60 > 48 — тревога. Факт 190 гостей: |190 − 210| = 20 < 48 — тишина. Числа условные.

Почему σ считается на остатках, а не на сырой выручке

Это ровно то место, которое обычно пропускают, и от пропуска весь механизм становится бесполезным.

Если посчитать стандартное отклонение сырой дневной выручки ресторана, то ты измеришь разницу между вторником и субботой. В нормальном здоровом заведении эта разница огромна, и она не проблема — она и есть бизнес. Порог, построенный на таком разбросе, пометит аномалией каждую субботу и не заметит рухнувшего вторника, потому что рухнувший вторник всё ещё хорошо внутри диапазона, достаточно широкого, чтобы вмещать субботы.

Значит, сезонный рисунок снимается первым. Ожидаемое — это то, что обычно дают этот день недели и этот отрезок дня; остаток — то, что осталось после вычитания ожидания; и σ меряет разброс именно остатков. Теперь плохой вторник громкий, а большая суббота тихая — ровно то поведение, которого ты и хотел.

Самое простое защитимое Ожидаемое — медиана того же дня недели и того же отрезка дня по недавним сопоставимым периодам. Медиана вместо среднего выбрана намеренно: одно катастрофическое закрытие или одна свадьба сдвигают среднее и оставляют медиану на месте, а тебе не нужно, чтобы один дикий день расширил твой диапазон тревог на месяц вперёд.

Как выбирается k, и почему не по таблице

k не берётся из таблицы нормального распределения, и это второе место, где стандартное изложение уезжает не туда.

Ресторанные ряды не распределены нормально. У них недельная сезонность, тяжёлые хвосты на выходных и праздниках, закрытые дни — структурные нули, а не плохие дни, — и одиночные всплески от разовых событий. Фраза «два сигма это девяносто пять процентов», сказанная про такой ряд, — арифметика поверх допущения, которое не выполняется.

Вместо этого k подбирается опытным путём, против единственного ограничения, которое здесь правда связывает: сколько тревог живой человек согласится прочитать.

Доля периодов с тревогой = (Периодов, где |Факт − Ожидаемое| > k × σ) ÷ Периодов наблюдений

• Периодов, где … — счётчик периодов, безразмерный;
• Периодов наблюдений — счётчик периодов, безразмерный;
• Доля периодов с тревогой — безразмерная доля от нуля до единицы.

Скобки здесь несущие. Делится весь счётчик сработавших периодов, а не одна σ: без скобок по старшинству действий ÷ привязывается к σ, и справа остаётся не доля, а k × σ ÷ число периодов. При σ = 24 гостя и k = 2 из прогона выше это 2 × 24 ÷ 180 = 0,27 гостя: величина в гостях, а не доля периодов, и сравнивать её со счётом периодов не с чем.

Разбор размерности: счётчик, делённый на счётчик, безразмерен; единица «период» сокращается. Величина по построению лежит между нулём и единицей, потому что числитель — подмножество знаменателя.

Обратная проверка: 180 × 0,078 = 14,0. Сходится. Числа условные.

Ты прогоняешь этот расчёт назад по своей собственной истории при нескольких значениях k и смотришь, какой объём тревог каждое из них дало бы. Потом выбираешь то k, чей объём человек правда способен разобрать, и записываешь, какое значение выбрано и почему. Порог, происхождение которого никто не может назвать, — это порог, который никто не станет защищать, когда он сработает в неудобный момент.

Два свойства этой конструкции стоит проговорить вслух. Поднятие k не делает заведение стабильнее, оно делает тебя слепее, и изнутри эти два состояния ощущаются одинаково. И показатель, у которого слишком мало исторических периодов, имеет ненадёжную σ, а значит, за ним надо следить плоским пределом, выбранным человеком, пока истории не накопится, — честный фиксированный предел лучше посчитанного из шести наблюдений.

Что система обязана уметь читать: минимальный набор источников

Управленческий слой стоит ровно столько, сколько стоят его входы. Вот что открывает каждый источник и что без него просто не вычисляется.

Готовность данных — состояние, в котором нужные источники существуют, подключены и согласованы между собой по периоду и по кодам позиций.

Именно последняя часть и подводит. Две системы могут быть обе подключены и всё равно не сходиться, потому что касса называет блюдо одним словом, счёт называет ингредиент другим, и никто между ними не сопоставил. Связь, которая приносит данные в чужих кодах позиций, — не частичный успех; для целей вычисления себестоимости это провал, выглядящий как успех. Ровно поэтому «процент готовности данных» — вводящий в заблуждение способ описывать готовность: два источника с несведёнными кодами дают тот же процент, что два работающих. Как это устроено на уровне подключений, разобрано на странице про интеграции.

Две крупнейшие затратные строки польского сектора в наборе Eurostat sbs_ovw_act в кассе не появляются вовсе

У того, что самые трудные для подключения источники одновременно самые нужные, есть причина, и она видна в официальной статистике по сектору целиком.

Читать их полагается с оговорками — это бухгалтерия предприятия, а не отчёт о прибылях и убытках ресторана; в «закупки» входят аренда, коммуналка и услуги подрядчиков; строка персонала покрывает только наёмных; складывать эти две доли и звать сумму prime cost нельзя, — и разбор этих оговорок вместе со сравнением с ЕС-27 принадлежит странице про prime cost, где та же таблица стоит целиком. Здесь мы её не перепечатываем: одна таблица в двух местах со временем начинает расходиться.

Что переживает эти оговорки — это форма, и форма как раз и есть предмет разговора. Подавляющая часть денег, покидающих заведение общепита, уходит через закупку и через фонд оплаты труда, и ни то ни другое касса не записывает. Это и есть весь практический аргумент за то, чтобы подключать счета и график смен раньше, чем что-нибудь более удобное: касса держит доходную сторону, ту половину, за которой ты и так следишь, а две половины, решающие исход, живут в системах, которые труднее всего подключить.

Интеграция — поддерживаемая связь с системой-источником, у которой названы интервал обновления и поведение при отказе.

Обе половины этого определения несущие. «Мы интегрируемся с твоей кассой» без интервала обновления может означать и живой поток, и ручную выгрузку раз в месяц, а от этого зависит, успеет ли слой поднять что-нибудь в тот же день, когда оно произошло.

Что он делает с отклонением: кто об этом узнаёт и как

Обнаружить отклонение — лёгкая половина. Полезность решается тем, что происходит дальше.

Решений надо принять четыре, и поставщик обязан уметь назвать свой ответ на каждое.

Маршрутизация: кому именно сказали

Отклонение по себестоимости принадлежит тому, кто закупает, и тому, кто готовит. Отклонение по труду принадлежит тому, кто пишет график. Отклонение по выручке принадлежит владельцу. Разослать все три всем троим — это и есть способ, которым управление по отклонениям деградирует обратно в отчёт, который никто не читает. Маршрутизация по показателю — весь смысл того, что показатели вообще были названы по именам и получили владельцев; как это раскладывается по ролям и сменам, разобрано на странице про команду.

Второе решение — через какой канал. Тревога, которая приходит туда, где человек уже находится, будет прочитана. Тревога, ради которой надо открывать отдельное приложение, конкурирует со всем остальным, что этот человек делает во время сервиса. Это практическое ограничение, а не вкусовщина.

Контекст, без которого тревога бесполезна

Третье решение — с каким контекстом. «Food cost выше цели» — не повод к действию. «Food cost выше цели; три позиции, дающие основной вклад, вот эти; у двух из них закупочная цена выросла в последней поставке» — повод. Разрыв между этими двумя фразами и есть место, где слой либо оправдывает себя, либо нет, — и, как сказано выше, вторую фразу правда пишет модель.

Четвёртое решение — чем это закрывается. Исключение должно быть закрываемым, и должно быть видно, когда оно не закрыто. Это тот механизм, который не даёт пролистнуть настоящую проблему, — и, без всякой романтики, это функция рабочего процесса, а не аналитики. Дисциплина здесь ровно та же, что в любой другой системе задач и напоминаний, только применённая к цифрам вместо поручений.

Для сети точек вопрос маршрутизации получает лишнее измерение: одно и то же отклонение может быть нормальным на одной точке и тревожным на другой, потому что базы у них разные. Сравнивать точки можно только после нормализации, и это отдельный разговор — три заведения на одном экране.

Чего этот слой не делает и знать не может

Покупатель будет предполагать почти всё из перечисленного, пока это не сказано вслух.

Он не знает ничего, чего ты не подключил. Если счета лежат бумагой в ящике, слой не видит закупочных цен, и никакое количество интеллекта не заменит отсутствующий вход.

Он не знает «почему». Он знает, что число гостей во вторник было далеко ниже того, что дают вторники. Он не знает, что улицу перекопали, — если только это не записал какой-нибудь подключённый источник. Модель может выдвинуть гипотезу; гипотеза причиной не является.

Он не заменяет суждения о реакции. Знание того, что food cost сдвинулся, не говорит, менять ли поставщика, менять ли рецептуру, менять ли цену или принять это на сезон. В этих разменах участвуют твои гости, твоя репутация и твоя готовность к риску, а ничего из этого в данных нет.

Он не чинит первичный учёт. Слой, построенный на инвентаризации два раза в год, будет выдавать цифру расхождения два раза в год. Он отражает дисциплину, которую ему дали; он её не создаёт.

На него нельзя опираться в самом начале его собственной жизни. Каждый порог на этой странице считается по истории. У свежеподключённого показателя истории нет, и ведёт он себя соответственно. Поставщик, обещающий немедленную точность на свежей связи, описывает что-то другое, а не механизм, описанный здесь.

Он не управляет людьми. График по-прежнему пишет человек, который знает, кто надёжен в пятницу. Слой может сказать, что стоимость труда высока; мнения о том, кого отправить домой, у него нет.

Есть более широкая версия этого же рассуждения — где автоматизация в ресторане правда помогает, а где её продают в кредит доверия, — в статье про то, что в ресторане автоматизируется на самом деле.

Условия подключения: что должно быть правдой до следующего источника

Добавление источников в неправильном порядке даёт слой, который впечатляюще подключён и не считает ничего нового. Правило порядка простое: подключай тот источник, который открывает цифру, которую ты сейчас произвести не можешь, и не подключай ничего другого.

Прежде чем добавлять любой источник, должны быть верны три вещи.

Цифра, которую он открывает, — та, по которой ты будешь действовать. Не та, которую было бы интересно посмотреть. Если ты не можешь назвать, какое решение меняется, когда цифра сдвигается, — интеграция декоративна.

Его коды позиций сопоставимы с тем, что у тебя уже есть. Это та проверка, которую пропускают чаще всего и которая потом дороже всех обходится, потому что отказ здесь беззвучный: данные приезжают, а арифметика неверна.

У гигиены источника есть хозяин. Инвентаризации надо делать. Графики надо заводить. Если за вход никто не отвечает, выход тихо деградирует, пока тревоги не станут неверными и их не начнут игнорировать, — а это хуже, чем не иметь их вовсе.

Есть и порядок, который в ресторане обычно оказывается правильным: касса первой, потому что без неё не работает ничего; табель вторым, потому что он уже цифровой и закрывает трудовую сторону prime cost; склад и счета третьими, потому что они самые трудные и открывают больше всего. Бронирования и площадки доставки идут следом, и что из них раньше — зависит от того, оборачиваемость столов или маржа доставки для тебя сейчас важнее. Этот порядок — умолчание, а не закон; цифра, которую ты сейчас произвести не можешь, всегда побеждает.

Этот список стоит перечитать ещё раз через призму ошибок, которые при таких внедрениях повторяются чаще всего, — они собраны в материале про ошибки при внедрении автоматизации.

Как рассуждать про отдачу — в своих числах

В этом разделе намеренно нет ни одной цифры и ни одного разобранного примера.

Причину стоит проговорить: расчёт отдачи на такой софт держит в числителе нашу собственную цену, а в знаменателе — величину, которую невозможно измерить, пока ты его не купил. Получилось бы выдуманное число, выраженное длиной времени, а ни того, ни другого этот кластер не публикует. Честно сказать можно другое: откуда эффект взялся бы и как ты проверил бы его в своих собственных данных.

Два честных предупреждения о том, как эту таблицу читать. Эффекты пересекаются — food cost и труд оба сидят внутри prime cost, — поэтому их нельзя складывать; сложение считает один и тот же злотый дважды, и это ровно та арифметическая ошибка, которой поставщики раздувают свою собственную ценность. И каждая строка — это сравнение с твоей собственной базой, а значит, база должна существовать ДО изменения, а не восстанавливаться задним числом.

Если хочется порассуждать про денежную сторону своей операции, ничего пока не покупая, — для этого есть финансовая модель и сравнение сценариев «что если».

Отдельный вопрос, которого эта таблица не решает: строить своё или брать готовое. Счёт там другой — в одном случае платишь абонентскую плату, в другом время своей команды, — и он разобран в материале про собственную автоматизацию против готового SaaS.

Как выбирать: пять требований к поставщику, ответ на которые можно сверить

Это пять вещей, о которых надо спросить, и ответы на них ты можешь сверить со своими собственными системами, а не принять на веру.

Третий и пятый вопрос несут больше всего информации. Поставщик, который не показывает порог, просит довериться числу, которое будет тебя будить; поставщик, который не разделяет модельную работу и арифметику, либо сам не знает, либо предпочёл бы, чтобы не знал ты.

Две проверки, которые делаются вне разговора с продавцом

Первая: попроси показать настоящую тревогу с её абзацем контекста, а не скриншот дашборда. Разница между этими двумя предметами показа больше, чем между двумя продуктами.

Вторая: спроси, что слой делает в день, когда один из твоих источников лёг. Ответ скажет, можно ли доверять тишине, которую этот слой производит, — а вся ценность управления по отклонениям держится ровно на этом.

Когда этот слой не нужен вовсе

Есть положения, в которых честная рекомендация — не покупать, и они достаточно распространены, чтобы их назвать.

Когда данных не существует. Ресторану, у которого счета на бумаге, а запас считают глазами, не хватает не управленческого слоя. Ему не хватает записей, и слой просто отразит их отсутствие обратно. Сперва чинится вход.

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

Когда ничего не изменилось бы, даже узнай ты. Если ответ на вопрос «что ты сделаешь, если food cost сдвинется на два пункта» — «ничего, на таком масштабе», то у тревоги нет потребителя. Покупай то, что закрывает решение, которое ты правда принимаешь.

Когда отсутствует операционный слой. Если системы бронирования нет, добавлять слой, который её читал бы, — не тот порядок. Сперва пол, потом крыша, — а что именно относится к полу, кто обновляет данные заведения в Google, на сайте и на порталах, это отдельный вопрос со своим ответом.

Когда настоящая беда выше по течению, чем цифры. Заведение, теряющее брони оттого, что никто не берёт трубку, страдает не от нехватки аналитики. Оно страдает от неотвеченного телефона, и это измеримо само по себе — арифметика лежит в статье про стоимость пропущенных звонков, и никакой управленческий слой не поднимет трубку вместо человека.

Общая форма этого рассуждения — перечень положений, в которых правильный совет «не внедряй ничего», — самая некоммерческая вещь, которую можно опубликовать про собственную категорию, и именно её стоит перечитать дважды.

Часто задаваемые вопросы

Что такое AI-система управления рестораном?

Это программный слой, который стоит над кассой, складским учётом и бухгалтерией заведения, а не заменяет их. Он читает их данные, пересчитывает рабочие показатели, сравнивает каждый с целью или с ожидаемым диапазоном и поднимает только те отклонения, под которые нужно решение. Модель в нём используется на чтении неструктурированных документов, на разборе свободного текста, на ответах на вопросы, заданные словами, и на написании объяснения к отклонению; сами расчёты — это арифметика и статистика.

Чем это отличается от кассовой системы?

Касса записывает транзакции и умеет отчитаться о том, что записала. Она не может посчитать ничего, что пересекает системы, потому что держит только свою половину арифметики: она знает, за сколько продано блюдо, но не знает, во что обошлись ингредиенты, во что обошлась смена и что кухня израсходовала на самом деле. Управленческий слой не держит собственных транзакций и существует именно затем, чтобы соединять источники. Второе отличие — направление: отчёт кассы случается, когда ты его запустил, а управленческий слой начинает разговор сам.

Чем это отличается от BI-дашборда?

Дашборд — поверхность, к которой ты идёшь; он показывает всё с одинаковым весом и наименее полезен ровно тогда, когда ты занят больше всего. К управленческому слою не обращаются вовсе: он следит непрерывно и связывается с названным человеком, когда цифра вышла за ожидаемый диапазон. У дашборда, кроме того, нет памяти о том, отреагировал ли ты, тогда как исключение остаётся открытым, пока его не закроют. Друг друга они не отменяют: дашборд — правильное место, чтобы показать подробности за поднятым исключением.

Какие данные нужны, чтобы это работало?

Минимум — продажи по позициям с отметками времени из кассы, потому что без них не считается ничего. Табель или график смен закрывает трудовую сторону. Инвентаризации и поставки открывают фактическую себестоимость и расхождение с теоретической. Счета поставщиков открывают движение закупочных цен и на практике являются самым трудным источником. Бронирования открывают оборачиваемость столов и заполненность. Записи площадок доставки открывают маржу заказов доставки. Кроме того, что источники должны существовать, они обязаны быть согласованы по периодам и по кодам позиций.

Этот ИИ — правда искусственный интеллект или арифметика под красивым названием?

И то и другое, и честный поставщик назовёт по каждой функции, что из этого где. Модель правда делает работу в четырёх местах: читает накладные поставщиков, у которых вёрстка меняется от поставщика к поставщику; разбирает свободный текст — отзывы и заметки смены — сразу на нескольких языках; отвечает на вопрос, заданный словами; и пишет абзац, который объясняет отклонение. Всё остальное — food cost, prime cost, квадранты меню, сезонный прогноз спроса и сам порог тревоги — это арифметика и статистика, и она не становится искусственным интеллектом оттого, что считается быстро. Надёжная проверка — не название продукта: спроси, какие функции лежат по какую сторону этой черты, и неумение ответить считай ответом.

Что такое управление по отклонениям в ресторане?

Это дисциплина, при которой нормальные значения не сообщаются вовсе, а наверх поднимаются только отклонения за порог. Смысл её — беречь внимание: отчёт из сорока цифр, тридцать восемь из которых нормальные, маскирует две ненормальные. При этой дисциплине тишина означает, что всё наблюдаемое внутри своего диапазона, — а это верно, только пока подключения живы, поэтому серьёзная реализация поднимает отсутствие данных как отдельное исключение и не даёт оборванному каналу выглядеть спокойным днём.

Может ли это заменить управляющего рестораном?

Нет, и граница здесь конкретная. Слой умеет сказать, что цифра сдвинулась и какие слагаемые сдвинулись вместе с ней. Он не знает почему, если причина не была записана в подключённом источнике; он не выбирает между сменой поставщика, сменой рецептуры, сменой цены и принятием движения как есть; и мнения о том, кого ставить в смену в пятницу, у него нет. В этих решениях участвуют гости, репутация и готовность к риску, а ничего из этого в данных не лежит.

Когда ресторану это не нужно вовсе?

Когда первичных записей не существует, потому что слой отражает их отсутствие, а не чинит его. Когда один человек каждый день в зале, сам закупает и сам пишет график, так что исключения и так видны. Когда ничего не изменилось бы, даже узнай ты, — тревога без потребителя это отходы. Когда отсутствует сама операционная система, которую слой читал бы. И когда настоящая беда выше по течению, чем цифры, — например неотвеченный телефон, которого никакой аналитический слой не заменит.

Если хочется понять, какого слоя не хватает именно твоему стеку, честная отправная точка — не демонстрация, а собственные цифры: дерево KPI показывает, какие из них опираются на данные, которые у тебя уже есть, а ресторанный раздел собирает остальной кластер. Как решающий слой выглядит в работе — это движок решений, отклонения из которого приезжают автоматическими отчётами, а внешние факторы, за которыми он следит, описаны в внешних сигналах. А если проще начать с разбора своей ситуации на собственных числах — это страница отбора.