Петр Шпис Автор работы Номинации: Фриланс-команда года, Digital и технологии, Лучший отраслевой проект

Автоматическое кафе — когда software управляет уже не заказом, а самой точкой

Фриланс-команда года Digital и технологии Лучший отраслевой проект
Автоматическое кафе — когда software управляет уже не заказом, а самой точкой

Задача

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

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

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

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

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

Решение

Для гостя мы построили полностью self-service сценарий. Пользователь выбирает позиции, оплачивает заказ и дальше только следит за его состоянием. Касса, официант или бариста в основном пользовательском пути не участвуют.

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

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

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

Интеграция с китайским оборудованием

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

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

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

Особенно важным было согласовать пограничные сценарии. Что происходит, если устройство получило команду, но не начало приготовление? Если связь оборвалась? Если backend считает заказ отправленным, а оборудование его не приняло? В обычном веб-сервисе такая ошибка заканчивается сообщением на экране. Здесь она может означать оплаченный, но физически не приготовленный заказ.

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

Разработка

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

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

Отдельно прорабатывается обработка ошибок. Устройство может быть недоступно, не принять команду или вернуть неожиданный статус. Поэтому система должна не просто знать идеальный happy path, а понимать десятки состояний между «заказ оплачен» и «блюдо можно забрать».

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

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

Результат

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

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

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

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

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