FoodTech проект Достаевский: как мы автоматизировали работу кухонь по всей Москве
Объем FoodTech рынка России растет семимильными шагами и уже считается одним из самых перспективных. Существующий подход к предоставлению услуг уже заметно поменял отношение к удовлетворению базовой потребности: все больше людей выбирают сторонние сервисы вместо того, чтобы тратить время на приготовление еды и покупку продуктов питания в магазинах.
Становится очевидным, что залог успешного бизнеса, так или иначе связанного с доставкой/приготовлением еды, зависит от качества решения и его высокотехнологичности.
Наш клиент-Сервис доставки еды «Достаевский» с развитой сетью производств в Москве и Санкт-Петербурге обратился к нам за автоматизацией бизнеса: заказы обрабатывались вручную. Заявка поступала в колл-центр (с веб-сайта или мобильного приложения), после этого сотрудник выбирал производство, на которое следовало ее отправить. Оператор обзванивал кухни и выяснял, имеются ли все необходимые продукты.
Данный подход содержит в себе множество недостатков:
-
Ручной труд, который мог привести к ошибке и, как результат, к потерям бизнеса;
-
Увеличение времени с момента заказа до его получения клиентом;
-
Необходимость постоянного увеличения количества работников колл-центра.
На руках у заказчика был лишь список требований производительности и базовая концепция оптимизации данного процесса. С таким набором мы приступили к работе.
Решение. Как мы это сделали
Сервис обработки заказов должен работать бесперебойно 24/7. От надежности нашего сервиса зависит скорость развития бизнеса нашего Клиента. Он должен справляться с нагрузками, атаками и отказом оборудования. Поэтому для реализации системы была выбрана микросервисная архитектура. Этот подход позволяет легко масштабировать решение в зависимости от потребностей бизнеса.
Для реализации сервиса был выбран .NET Core 2.0 из-за его быстродействия и кроссплатформенности. Для создания удобного и отзывчивого интерфейса был использован React.
Система состоит из панели администрирования и, собственно, сервиса маршрутизации заказов.
Решение. Как работает распределение заказов
Чтобы обработать заказ быстро и правильно, необходимо учитывать множество факторов:
- Время заказа: при выборе производства нужно учесть расписание работы производств, форс-мажорные закрытия, праздничные дни и выходные и т.д.
- Адрес доставки: необходимо выбирать наиболее близкую к месту доставки кухню, чтобы минимизировать время доставки курьером.
- Состав заказа: выбрать именно то производство, которое в полном объеме удовлетворит заказ клиента.
- Загруженность: иногда лучше перекинуть заказ на соседнюю кухню, если текущая уже загружена.
На основании вышеперечисленных факторов система выбирает производство с минимальным временем доставки!
Решение. Как построено управление
Для управления работой производств мы создали административную панель. Она дает возможность персоналу наблюдать за работой кухонь. Также предусмотрено отключение того или иного производства в связи с какой-либо технической неполадкой, а также настраивание расписания работы.
Важным условием создания панели управления было разделение прав пользователей на Администраторов и Менеджеров, имеющих доступы к различным функциям сервиса. К примеру, Администратор может создавать производство, подключать кухни, настраивать график работ, управлять списками клиентов, что недоступно Менеджеру, однако не может включать-выключать кухни.
Каждая кухня имеет индивидуальные настройки пропускной способности и не примет больше заказов, чем может выполнить в час, что исключает появление очереди. Благодаря этому срок выполнения заказа всегда соблюдается. Если в данный момент кухня не может выполнять заказы, то менеджер отключает ее до решения проблемы, однако само производство продолжает работу в штатном режиме.
Специально под потребности заказчика мы разработали гибкую систему «Режим работы».
Для реализации гибкого графика понадобилось ряд вычислений и нормализации дат и времени. Например, на фронтенде время вычислялось в миллисекундах, без учета даты. При этом основной загвоздкой было пересечение временных отрезков, так как производства работали не только в пределах 1 дня, но иногда и ночью с переходом в другие сутки. Была реализована и валидация дат и ее фиксация относительно таймзоны производства. Обычно даты создаются относительно пользовательского времени и таймзоны, которые могут не совпадать с теми же данными производства. Мы же приняли UTC в качестве точки отсчета и при создании расписания считали, что заданное время в UTC есть время во временной зоне производства. Это позволило зафиксировать расписание в таймзоне производства и игнорировать таймзону пользователя. Такой подход позволил сделать гибкую и масштабируемую систему расписаний (таймзона производства хранится отдельно, что без труда позволяет вычислить как UTC, так и текущее состояние производства относительно таймзоны пользователя, который смотрит на производство).
Также был создан стенд с отображением зон доставки. Каждая зона отмечена соответствующим цветом. На боковых панелях отображены названия, их цветовой маркер, а также цена доставки, которая рассчитывается автоматически. Если по каким-то причинам, зона не может быть обслужена своим производством, для него будет выбрано замещающее производство из ближайших соседних.
Администратор имеет возможность управления списками, в которые может попасть клиент, например, нарушив условия оплаты товара. Также имеется список vip-клиентов, которые не привязаны к области доставки производства (проверяется автоматически) и список сотрудников.
Результат
Автоматизированная система, созданная SimbirSoft для «Достаевский», в первый же месяц позволила увеличить скорость обработки заказов, уменьшить количество ошибок на 40%. Внедрение решения продолжается и в других городах присутствия сети.
