Shokava — система учёта и автоматизации для кафе

01Обзор проекта

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

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

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

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

02Контекст и задача

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

• Заказы в блокноте. Официант записывает позиции на бумаге или держит в памяти, передаёт на кухню устно. Ошибки, забытые позиции, споры «я этого не заказывал» — всё это норма, а не исключение.
• Себестоимость неизвестна. Никто не считает, из каких ингредиентов и в каком количестве состоит блюдо. Цена в меню ставится «на глаз», а реальная маржа остаётся загадкой до тех пор, пока заведение не уходит в минус.
• Склад живёт отдельно от продаж. Остатки продуктов считают вручную и редко, списания не привязаны к проданным блюдам. В итоге то «внезапно» заканчивается ключевой ингредиент в час пик, то портятся забытые запасы.
• Смена непрозрачна. В конце дня сложно сказать, сколько выручки прошло, какие позиции продавались, что списано и сходится ли касса. Контроль персонала держится на доверии, а не на данных.
• Нет разграничения прав. Либо у всех есть доступ ко всему, либо всё завязано на одном человеке. И то и другое опасно: первое — для денег и данных, второе — для непрерывности работы.

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

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

03Цели проекта

Из задачи выросли конкретные продуктовые и инженерные цели, которые мы держали в голове на каждом этапе:

• Единый источник правды. Заказы, меню, склад, себестоимость и отчёты живут в одной базе и связаны между собой, а не разнесены по тетрадям и файлам.
• Контроль себестоимости. Каждое блюдо разложено на ингредиенты с нормами расхода, поэтому система всегда знает реальную стоимость порции и маржу по ней.
• Автоматические списания. Продажа блюда уменьшает остатки ингредиентов на складе автоматически — без отдельной ручной операции.
• Роли и доступы. Официант, повар, менеджер и администратор видят и могут ровно то, что нужно их роли. Чувствительные функции — под защитой.
• Скорость обслуживания. Приём заказа и работа со счётом должны быть быстрыми и устойчивыми к спешке, без лишних шагов и ожиданий.
• Прозрачность смен. В любой момент видно, что продано, что списано, сколько выручки и какие остатки — без ручного сведения в конце дня.
• Доступность из браузера. Никакой установки тяжёлого софта: вход в кабинет по логину, работа с любого устройства в заведении.

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

04Что мы сделали

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

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

05Архитектура решения

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

• Слой данных. Единая модель, где описаны заведение, сотрудники и их роли, меню и категории, ингредиенты и нормы расхода, заказы и их позиции, движения по складу. Всё связано ссылками, поэтому система всегда знает, как одно влияет на другое.
• Слой операций. Бизнес-логика заказа и счёта, расчёт себестоимости из ингредиентов, автоматические списания при продаже, агрегация данных в отчёты. Здесь живут правила, по которым работает кафе.
• Слой доступа. Авторизация и разграничение прав: какая роль что видит и что может делать. Чувствительные операции — изменение цен, доступ к отчётам, управление складом — закрыты от тех, кому они не нужны.
• Слой интерфейсов. Разные рабочие экраны под разные роли: быстрый приём заказа для официанта, очередь блюд для кухни, аналитика и настройки для менеджера и администратора.

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

06Как проходит заказ

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

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

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

07Ключевые возможности

Разберём то, что делает Shokava не «электронным меню», а именно системой учёта и автоматизации заведения.

Приём и ведение заказов

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

Счета и чеки

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

Меню и позиции

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

Склад и калькуляции

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

Роли и доступы

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

Кабинет управления и отчёты

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

08Себестоимость и калькуляции

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

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

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

09Склад и автоматические списания

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

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

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

10Роли, доступы и безопасность

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

Роли отражают реальную структуру заведения:

• Официант — принимает и ведёт заказы, формирует счета. Видит то, что нужно на линии, и не имеет доступа к складу, ценообразованию и отчётам.
• Повар — видит очередь блюд и состав заказов, работает с кухонной частью процесса.
• Менеджер — управляет меню, складом и калькуляциями, видит отчёты по выручке и остаткам, контролирует смену.
• Администратор — настраивает заведение и сотрудников, управляет ролями и доступами, имеет полную картину.

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

11Кабинет управления и отчёты

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

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

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

12Скорость обслуживания

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

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

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

13Технологический стек и инфраструктура

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

• Бэкенд — серверная логика заказов, счетов, калькуляций и складских движений, агрегация данных в отчёты, авторизация и проверка прав на каждое действие.
• Данные — связанная модель заведения: сотрудники и роли, меню и категории, ингредиенты и нормы расхода, заказы и их позиции, движения склада.
• Интерфейсы — рабочие экраны под роли: быстрый приём заказа, кухонная очередь, управление меню и складом, кабинет и отчёты.
• Инфраструктура — изолированная среда за Cloudflare с DNS, TLS и защитой периметра; доступ в кабинет только по логину.

14Дизайн и UX

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

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

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

15Как мы работали

Проект вели последовательными этапами, на каждом из которых был осязаемый результат:

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

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

16Результат

Получился не «электронный блокнот для официанта», а самостоятельная система учёта и автоматизации кафе, в которой заказы, склад, себестоимость и отчётность связаны в единое целое и работают на владельца.

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

17Выводы

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

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