Как создать бизнес по доставке продуктов, имея под рукой 1С, Битрикс и логистическую систему

• Перспективы foodtech и доставки
• За что идет битва между сервисами
• Что нужно было сделать
• Как работает сервис доставки и где искать «свободные» ресурсы времени
• Структура и роли систем в проекте
• Интересные задачи и решения

Доставка готовой еды из ресторанов и продуктов из магазинов – направление на российском рынке, которое развивается как-то односторонне, в основном за счет ресурсов крупных компаний. Да, они способны инвестировать большие средства в создание и поддержку самостоятельных (не тиражируемых) ИТ-систем. А как быть малому и среднему бизнесу у которого нет таких ресурсов? На примере бренда Cooker показываем, что задача может быть решена путем интеграции типовых бизнес-приложений.

Это выгодно, потому что не требует разработки с нуля и быстро, потому что мы это уже сделали.

Перспективы foodtech и доставки

Ряд экспертов считает, что «золотой век» доставки почти закончился, а крупные игроки фудтеха окончательно поделили рынок. Но правда в том, что рынок, как вселенная, расширяется. По прогнозам SberSIB, объем рынка e-grocery (товары повседневного спроса) в 2023 году составит 660 млрд руб, а к 2026 – уже 1,2 трлн. Локомотивы – доставка готовой еды и продуктов питания, одежды, обуви и средств личной гигиены. На доставке питания бизнес заработал 186 млрд. руб. в 2022 г. И заработает еще больше в ближайшем будущем.

Раскрывая кухню нашего проекта приведем несколько цифр:

• Через неделю после запуска проект получал, в среднем, 10 заказов в день по 350 рублей;

• Через 3 месяца ≈ 100 заказов в день по 550 рублей;

• Через 6 месяцев ≈ 800 заказов в день по 600 рублей;

• Через 9 месяцев ≈ 2000 в день по 900 рублей.

За что идет битва между сервисами

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

Путей сокращения срока доставки несколько:

• размещение дополнительных складов для сокращения маршрутов курьеров;

• оптимизация работы склада с точки зрения внутренней логистики: эффективная выкладка товара для уменьшения «пробега» сотрудников и хаотичности сборки;

• автоматизация максимально возможного количества операций для снижения доли человеческого фактора при сборке и доставке заказов;

• повышение скорости обмена данными в связанных ИТ-системах.

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

Самым логичным вариантом всегда кажется покупка готовых решений. Однако на рынке сейчас нет «чистых» систем доставки еды и продуктов питания. По понятным причинам никто не берется за создание универсального решения.  С одной стороны, их разработка сильно зависит от особенностей бизнес-процессов и внешнего окружения компаний, с другой – количество заказчиков из среднего и малого бизнеса невелико из-за сильной конкуренции со стороны лидеров отрасли. У них давно есть собственные платформы с искусственным интеллектом и большими командами разработки, штатом аналитиков, сборщиков, курьеров и т.д.

Сегменты рынка приложений и сервисов доставки

Из наиболее распространенных и доступных по цене решений – это средства автоматизации общепита, которые заточены под продажи с собственной кухни, имеют встроенные модули доставки или интегрируются с популярными сервисами-лидерами. Но им тоже бывает нужна интеграция с сайтом, бухгалтерией, поставщиками, логистикой, SMS-шлюзами, платежной системой, ОФД, Честным знаком и т.д.

Так как на рынке пока нет готовых ИТ-систем доставки еды и продуктов, приходится интегрировать между собой типовые решения по управлению торговлей (например на платформе 1С:Предприятие 8) и разное специализированное ПО с нужными функциями (ЭДО, CRM, логистика и маршрутизация, прием платежей и т.д.).

По такому пути пошли наши клиенты – MYBOX и Cooker.

MYBOX работает на «1С-Битрикс: Управление сайтом» (1C:БУС) и собственной ERP. Платформа Cooker объединяет «1С:Управление нашей фирмой» (1С:УНФ), 1C:БУС, CRM и логистический сервис.

• Как обработать 13 тысяч заказов в сутки: новая архитектура, RabbitMQ, PHP7 и Кластер;
• Интеграция ИТ-системы и бизнеса доставки еды (видеозапись семинара с участием представителей компании Mybox);
  
• Foodtech-разработка: интерфейсы для касс MYBOX;
  
• Интеграция и настройка бизнес-процессов компании Mybox.
  

Что нужно было сделать

Имеющийся у ИНТЕРВОЛГИ опыт интеграции систем, в том числе на общей шине, лег в основу сотрудничества по проекту, который запустил один из крупнейших иностранных мясопереработчиков. В ассортименте его онлайн-супермаркета представлено более 2500 позиций разных категорий, среди которых более 200 товаров собственного производства. Оферта звучала заманчиво: «Доставим свежие продукты за 15 минут!». 

Задача ИНТЕРВОЛГИ состояла в том, чтобы интегрировать интернет-магазин на платформе «Битрикс: Управление сайтом» с курьерским сервисом, мобильным приложением и 1С:УНФ. Интеграция должна была работать быстро, без сбоев, гарантируя доставку в отведенное время. Как в Сбермаркете с его искусственным интеллектом и ML, только с гораздо меньшим объемом ресурсов.

Запуститься нужно было как можно скорее, но итогового видения системы у заказчика не было, поэтому работали по Agile. Так, например, в ходе доработки процесса создания заказа 2 раза менялись требования к идентификации товара при обмене данными о нем и его количестве между 1С:БУС и 1С. Логичнее и проще учитывать товар по артикулам (так он хранится в номенклатуре). Но этот способ хранения может создавать дубли. Чтобы исключить дублирование, перевели обмен на уникальные ID. Затем … вновь вернулись к идентификации по артикулам.

Как работает сервис доставки и где искать «свободные» ресурсы времени

После того как вы на сайте нажали «Оплатить», сборщик начинает собирать заказ. Подробности заказа отображаются на терминале сбора данных сотрудника склада. Обходя с корзинкой стеллажи он сканирует штрих-коды продуктов и добавляет их в заказ. Если штрихкод не тот, устройство сообщит об этом и не будет добавлять продукт в список. Далее собранный заказ кладут в пакет и пишут на нём номер. Сборка занимает не более пары минут. Заказчик получает уведомления о каждом изменении статуса.

• Автоматизация склада в 1С:УТ: 1001-й способ экономии нервов, времени и денег.

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

Это в идеальном варианте. В реальности требуются запасы времени на уточнения деталей, исправление ошибок, задержки в пути и др. Здесь каждая минута становится критически важна.

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

Что впустую растрачивает время и замедляет доставку?

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

Структура и роли систем в проекте

Состав систем и направления обмена данными между ними представлены на схеме.

LIQPAY – web-интерфейс, электронный кошелёк, который позволяет принимать платежи и переводить деньги с помощью мобильного телефона, Интернета и платёжных карт.

TOCAN WMS – система управления складскими процессами (автоматизация склада).

TOCAN TMS – решение для автоматизации и управления процессами в транспортной логистике, планирования и мониторинга транспорта и перевозок. 

Attika – написанная под проект система логистики, работавшая с координатами курьеров: принимала координаты доставки из заказа в 1С и передавала их в TMS Tocan.

ИНТЕРВОЛГА давно работает с Битрикс, поэтому мы хорошо знаем его API. То же самое можно сказать про REST 1C. А вот с обменом с другими ИТ-системами пришлось повозиться, тем более что стояла цель – увеличить скорость обмена.

Интересные задачи и решения

Проект был интересен по многим причинам. Основная – это, конечно, попытка создать сложную систему с высокой скоростью работы на интеграции ряда независимых приложений. Такая «независимость» порождала комплекс задач по синхронизации и актуализации данных. Задач было много, наиболее интересные собрали в таблицу.

Рассмотрим пару задач подробнее.

1. Проблема расхождения между первичным заказом и фактической отгрузкой

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

Красным выделены планируемые доработки. Остальное – рабочая на тот момент конфигурация.

Рабочая схема изменений, вносимых в обмен.

Плюсы:

1. Механизм обмена работает, в него не потребуется вносить изменений;

2. В 1С и на сайте будет измененный заказ, который отгрузили клиенту и первичный вариант заказа, для статистики и анализа;

3. В 1С данные в заказе и расходных накладных идентичны;

4. Процедура резервирования не потребует переработки.

Минусы:

1. На сайте нет актуального документа отгрузки с действительно отгруженными данными (кажется не критичным);

2. Потребовалась доработка на стороне сайта.

Протестировав варианты, окончательно согласовали схему работы с заказами/документами отгрузки в 1С и на сайте, а также их обмена.

Новая схема обмена заказами

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

2. Оптимизация обменов или как «успеть за 60 секунд»

Более трудоемкой стала задача повышения скорости обмена данными между 1С и сайтом.

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

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

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

Чтобы сервис выстоял в очередной «шторм заказов», провели большую реформу обменов:

1. Для разгрузки модуля обмена разделили потоки данных. Обычно сайт и 1С обмениваются всем и сразу. Но это тяжело и долго. Пока синхронизируется весь пакет, на сайте могут появиться десятки новых заказов с неактуальной информацией по остаткам. Поэтому мы сначала развели товары с остатками и цены: остатки передавались самостоятельно, а карточка товара и его свойства – вместе с ценами (обмен ценами происходит реже). Позже, в ходе экспериментов по ослаблению нагрузки на сайт, развели обмены уже на три отдельных узла: товары, цены, остатки. Остатки можно синхронизировать хоть каждую минуту, а товары – раз в сутки.

Хорошей практикой является объединение в одном потоке того, что меняется часто (заказы, остатки, резервы), а в другом – того, что редко (цены, картинки, описания товаров).

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

3. Чтобы потоки данных не пересекались, часть объектов перевели на обмен по событию (новый заказ на сайте), а полные обмены остались на расписании (cron). Например, было принято решение отказаться от автоматической синхронизации стоимости товара в 1С с сайтом, заменив его на ручное обновление и по обновление по расписанию.

4. Реализовали обмен заказами и товарами как отдельные http-сервисы. Они имеют ряд преимуществ по сравнению со стандартным REST-интерфейсом 1С: снимают ограничения стандартного модуля, просты в части программирования, меньше по объему и требуют меньшей вычислительной нагрузки. А это важно для мобильных приложений и устройств.

Такой подход обеспечивал всегда актуальную информацию по остаткам – наиболее критичным для foodtech данным.

К сожалению, сотрудничество было прервано из-за геополитических причин. Проект был большим и интересным, как и бэклог задач, которые мы могли бы решить:

• Перевести обмен ценами и деревом групп на http-сервис;

• Создать контроль первичного заказа с удобным интерфейсом;

• Выделить обмен остатками в отдельный сервис 

• Разработать автоматический функционал передачи данных для категории «акции» и др.

Несмотря на активный рост e-commerce, интерес бизнеса к сфере доставки определяется не только сложившейся структурой рынка и объемами инвестиций, но и возможностями цифровых платформ. Зачастую именно их выбор и объединение в одну эффективно работающую систему определяет конкурентную позицию игрока. Там, где речь идет о борьбе за каждую секунду, шаблонных решений быть не может.