Рынок доставки готовой еды и продуктов в России продолжает активно развиваться, но делает это, в основном, за счет усилий крупных игроков. У них есть ресурсы для создания собственных, зачастую уникальных ИТ-решений, которые невозможно масштабировать или адаптировать без серьезных вложений. Но что делать малому и среднему бизнесу, у которого таких возможностей нет? Опыт бренда Cooker показывает: задачу можно успешно решить с помощью интеграции готовых, типовых бизнес-приложений.
Это решение выгодно – не требует затрат на разработку с нуля. И это быстро – потому что мы уже прошли этот путь.
Перспективы foodtech и рынка доставки
Некоторые эксперты считают, что «золотой век» доставки подходит к концу, а крупные игроки уже поделили между собой рынок. Однако реальность выглядит иначе: рынок продолжает расти, словно расширяющаяся вселенная. По оценке SberSIB, объем рынка e-grocery (доставка товаров повседневного спроса) достиг 660 млрд рублей в 2023 году и может вырасти до 1,2 трлн к 2026 году.
Основные драйверы роста – доставка готовой еды и продуктов, а также сопутствующих товаров: одежды, обуви, товаров личной гигиены. В 2022 году рынок доставки питания принес бизнесу 186 млрд рублей, и потенциал дальнейшего роста остается высоким.
В рамках одного из наших проектов мы наблюдали следующий рост:
Через неделю после запуска – около 10 заказов в день по 350 рублей;
Через 3 месяца – порядка 100 заказов по 550 рублей;
Через 6 месяцев – уже 800 заказов ежедневно по 600 рублей;
Через 9 месяцев – около 2000 заказов в день по 900 рублей.
Эти цифры иллюстрируют, как грамотная ИТ-инфраструктура и правильный подход могут привести к масштабируемому успеху.
Конкуренция в доставке: не только цена
Рынок доставки продуктов и еды отличается высокой конкуренцией. Компании вынуждены постоянно работать над улучшением ключевых факторов: стоимостью и сроками доставки. Снижать цены – задача непростая, особенно в условиях высокой себестоимости. А вот ускорение доставки – реальный инструмент для укрепления позиций на рынке.
Среди наиболее эффективных стратегий сокращения времени доставки:
открытие дополнительных складов, чтобы сократить маршруты курьеров;
оптимизация логистики на складе: грамотное размещение товаров и организация процессов;
автоматизация всех возможных операций, чтобы минимизировать влияние человеческого фактора;
ускорение обмена данными между ИТ-системами.
На первый взгляд, логично выбрать готовое решение. Однако универсальных систем для доставки еды и продуктов на рынке просто нет. Причин несколько:
Слишком большое разнообразие бизнес-процессов;
Высокая степень зависимости от внешних факторов;
Ограниченный спрос со стороны малого и среднего бизнеса из-за доминирования крупных игроков.
Крупные компании уже имеют собственные платформы: с элементами ИИ, большими командами разработчиков, аналитиков, логистов и курьеров. А вот для малого и среднего бизнеса остается другой путь – создание индивидуальной архитектуры на базе готовых компонентов.
Сегодня на рынке доступны различные решения, прежде всего для автоматизации ресторанного бизнеса. Многие из них заточены под работу с собственной кухней и включают встроенные модули доставки или возможность интеграции с крупными сервисами. Но даже они требуют подключения к внешним системам: сайтам, бухгалтерии, логистике, SMS- и платежным шлюзам, ОФД, системам маркировки и т.д.
Так как готовых «коробок» для доставки нет, приходится комбинировать типовые решения: системы управления торговлей (например, на базе «1С:Предприятие 8») с профильным ПО – для ЭДО, CRM, логистики, маршрутизации, приема платежей и т.д.
Наши клиенты выбрали путь интеграции:
MYBOX использует «1С-Битрикс: Управление сайтом» и собственную ERP-систему.
Cooker построил архитектуру на базе «1С:Управление нашей фирмой», 1С-Битрикс, CRM и логистического модуля.
Такой подход позволяет даже небольшим компаниям эффективно конкурировать на насыщенном рынке доставки, опираясь на проверенные инструменты и быструю адаптацию под свои бизнес-задачи.
Подробнее об опыте MYBOX:
Как обработать 13 тысяч заказов в сутки: новая архитектура, RabbitMQ, PHP7 и Кластер;
Интеграция ИТ-системы и бизнеса доставки еды (видеозапись семинара с участием представителей компании Mybox);
Что нужно было реализовать
Опыт ИНТЕРВОЛГИ в построении интеграционных решений, включая использование общей шины данных, стал основой для сотрудничества с одним из крупнейших иностранных производителей мясной продукции. Он запустил онлайн-супермаркет с внушительным ассортиментом – более 2500 товаров разных категорий, включая свыше 200 наименований собственного производства. Заявленное предложение звучало амбициозно: «Доставим свежие продукты за 15 минут».
Наша задача заключалась в том, чтобы связать интернет-магазин на платформе «Битрикс: Управление сайтом» с курьерским сервисом, мобильным приложением и системой 1С:УНФ. Интеграция должна была быть не просто стабильной, но и максимально быстрой — ведь речь шла о жестком SLA на доставку, сравнимом с уровнем маркетплейсов вроде Сбермаркета, но с гораздо более ограниченными ресурсами.
Проект запускался в сжатые сроки, причем без четко сформулированного технического задания со стороны заказчика. Поэтому мы выбрали гибкую методологию Agile. В процессе адаптации бизнес-логики пришлось оперативно реагировать на изменения. Например, дважды менялись требования к идентификации товаров между 1С:БУС и 1С:УНФ. Сначала предполагалось использовать артикулы, как наиболее очевидный способ, но это создавало риск дублирования. Впоследствии систему перевели на уникальные ID — и в какой-то момент вернулись обратно к артикулам, отточив при этом логику фильтрации дублей.
Как работает сервис доставки
После того как пользователь нажимает кнопку «Оплатить», заказ автоматически передается сборщику на складе. Его терминал отображает все позиции, и сотрудник, проходя по стеллажам с корзиной, сканирует каждый товар. В случае ошибки (неверный штрихкод или несоответствие) устройство сразу же подает сигнал и не добавляет товар в заказ. После сборки заказ упаковывается, маркируется номером, и клиент получает уведомления обо всех статусах в реальном времени. На всё — считанные минуты.
Прочитайте о том, как упростить ордерную систему:
Пока заказ собирается, логистика рассчитывает оптимальный маршрут и направляет его ближайшему свободному курьеру. Благодаря сети компактных складов, равномерно распределенных по городу, радиус доставки составляет всего 5–7 минут езды. Курьер получает уведомление, забирает упакованный заказ и направляется к покупателю.
Это — идеальная модель. Но в реальности неизбежны форс-мажоры: ошибки, опечатки, уточнения, задержки на дорогах. В условиях ультрабыстрой доставки каждая минута на счету. Поэтому мы уделили особое внимание выявлению хронофагов — процессов, съедающих драгоценное время.
Чтобы гарантировать выполнение обещанных сроков, нужно не только скоординировать людей и процессы, но и найти скрытые резервы времени. Вот основные источники потерь, которые мы выявили:
ошибки и неточности в адресах;
необходимость согласования замены товаров (в случае отсутствия, порчи или истекшего срока годности);
изменение состава заказа или способа оплаты после оформления;
несвоевременное обновление статусов и информации об остатках;
ручная обработка ошибок в обмене данными;
неэффективные маршруты доставки, просчитанные логистической системой.
Архитектура проекта и взаимодействие систем
Проект включал в себя множество компонентов, каждый из которых выполнял свою функцию и участвовал в цепочке обработки заказа:
LIQPAY — платёжная система с web-интерфейсом, обеспечивающая приём онлайн-платежей через карты и мобильные устройства.
TOCAN WMS — система автоматизации складских операций.
TOCAN TMS — решение для управления транспортной логистикой, маршрутизацией и мониторингом перевозок.
Attika — кастомная логистическая система, получающая координаты доставки из заказов в 1С и передающая их в TMS.
ИНТЕРВОЛГА давно работает с Битрикс, поэтому мы хорошо знаем его API. То же самое можно сказать про REST 1C. А вот с обменом с другими ИТ-системами пришлось повозиться, тем более что стояла цель – увеличить скорость обмена.
Интересные задачи и нестандартные решения
Что требовало внимания | Как решили |
Два языковых каталога (в т.ч. русский) мешали друг другу при обмене остатками и оплатами. Проблемы с вложенностью категорий. | Объединили обмен остатками для обоих каталогов и донастроили структуру категорий. |
Покупатель мог изменить заказ после сборки или указать один способ оплаты, а использовать другой. | Настроили возможность изменения заказа до оплаты с автоматическим уведомлением всех подключенных систем. |
Несоответствие остатков: в 1С — 12 шт, на сайте — 10 шт. После покупки — несогласованность. | Оптимизировали формы сборки заказов, автоматизировали проведение документов, устранили «зависшие резервы». |
Каждый новый розничный заказ создавал нового контрагента в 1С, что раздувало базу. | Ввели универсального обезличенного контрагента «Розничный покупатель» для всех заказов без договора. |
Скидки и промокоды приводили к пересчёту суммы в 1С, отличной от сайта. | Интеграцию переписали: теперь в заказ передаётся цена с сайта, скидка выделяется отдельной строкой. |
Резервирование товара происходило только после отгрузки (с задержкой до часа). | Перевели обмен остатками на интервал в 1 минуту и внедрили моментальное резервирование при заказе. |
Из 20 заказов из 1С в систему Attika попадали только 3 — из-за расхождения статусов. | Настроили сопоставление статусов и добавили новые в Attika — обмен стал стабильным. |
Нельзя было редактировать заказы с включенным резервом в 1С. | Разработали механизм, позволяющий редактировать зарезервированные позиции без потери данных. |
Нужно было разделять заказы с подакцизными товарами (алкоголь) для безналичной оплаты. | Настроили автоматическое разделение заказов по организациям и созданию отдельных документов поступления. |
Модуль синхронизации каталога тормозил при большом количестве товаров и заказов. | Вынесли часть логики в микросервисы, значительно ускорив обмен. |
Невозможно было массово загружать товары в 1С через Excel. | Разработали парсер и структуру обработки .xls-файлов для загрузки номенклатуры. |
Требовалась интеграция мобильного приложения с 1С. | Настроили двухсторонний обмен между мобильным приложением и 1С: позиции, остатки, цены. |
При отмене заказа вручную приходилось распроводить расходные накладные и снимать резервы. | Реализовали автоматическую групповую обработку для распроведения документов и снятия резервов. |
Нужно было видеть «первоначальный» заказ после правок покупателя или сборщика. | Добавили «Заказ намерений» — слепок исходного заказа с сохранением всей ключевой информации. |
Рассмотрим пару задач подробнее.
Проблема: расхождение между исходным заказом и фактической отгрузкой
Такая ситуация возникала, если заказ менялся после оформления: например, товар оказался испорченным, закончился или у него подходил к концу срок годности. В результате клиент получал не тот состав заказа, который изначально оформил. Чтобы в таких случаях можно было разобраться, что произошло и на каком этапе произошли изменения, было решено сохранять первоначальный вариант заказа.
Красным в схеме выделены элементы, которые планировалось доработать, остальное — действующая конфигурация.
Преимущества:
Механизм обмена продолжает работать без изменений;
И в 1С, и на сайте отображается актуальный заказ (с учётом всех изменений) и его исходная версия — для статистики и аналитики;
В 1С информация в заказе и в расходных накладных полностью совпадает;
Процесс резервирования остаётся прежним, без необходимости переработки.
Недостатки:
На сайте нет документа отгрузки с фактическими данными (на момент реализации посчитали это некритичным);
Потребовалась дополнительная доработка на стороне сайта.
После тестирования разных сценариев команда согласовала финальную схему работы с заказами, отгрузочными документами и их обменом между 1С и сайтом.
На этой задаче мы пополнили копилку опыта, который теперь используем в новых проектах. Например, учитываем функционал рабочего места сборщика – инструменты контроля и управления системой сборки, которая влияет на механизм резервирования и учета остатков.
Оптимизация обменов: как «успеть за 60 секунд»
Одной из самых трудозатратных задач в проекте стала работа над ускорением обмена данными между сайтом и 1С.
Изначально обмен строился на стандартных модулях с минимальными доработками — это было оправдано сжатыми сроками запуска. В течение первого года система работала стабильно, но с ростом количества заказов и подключением новых сервисов стало заметно: производительности начальной конфигурации больше не хватает.
Когда заказов стало слишком много, модуль начал «захлебываться». Особенно это стало критично в пиковые периоды — например, перед майскими праздниками. Тогда модуль просто не справился с потоком, и начались сбои.
Основой обмена служил формат CommerceML — XML-стандарт для передачи информации о товарах, заказах, документах. Он хорошо структурирован, но для высоконагруженных систем оказался тяжеловат: вместе с каждым заказом отправлялись карточки товаров, их свойства, остатки и т.д. Это серьёзно замедляло работу.
Чтобы сервис выстоял в очередной шторм заказов, мы провели большую реформу обменов:
Разделили потоки обмена: раньше сайт и 1С обменивались «всем и сразу», теперь — отдельно по остаткам, ценам и товарам. Остатки стали обновляться чаще (каждую минуту), а цены и описания — реже (раз в сутки).
Разгрузили поток: исключили из обмена завершённые заказы, товары с нулевыми остатками и остатки на складах, с которых не идёт отгрузка (транзитных и бракованных).
Выделили критичное в отдельные процессы: всё, что изменяется часто (остатки, резервы, заказы) — отправляется в одном потоке, редко меняющееся (цены, картинки, описание) — в другом.
Ушли от синхронизации «по расписанию» в сторону событийной модели: часть обменов теперь запускается при наступлении события (например, новый заказ), остальное — по cron.
Перевели обмены на http-сервисы: это решение оказалось проще и легче стандартного REST API 1С. Оно требует меньше ресурсов, быстрее работает и подходит для мобильных приложений.
Этот подход позволил обеспечить постоянную актуальность остатков — а это особенно важно в сегменте быстрой доставки продуктов.
К сожалению, проект был приостановлен из-за внешнеполитических обстоятельств. Но за время работы мы наметили интересный вектор дальнейшего развития:
перевести обмен ценами и деревом групп в отдельный http-сервис;
реализовать интерфейс контроля первичного заказа;
выделить остатки в отдельный микросервис;
автоматизировать выгрузку акций и спецпредложений.
Опыт показал: в быстрой доставке важна каждая секунда. И когда речь идёт о высокой конкуренции, нет места шаблонам — выигрывают те, кто умеет создавать умные и гибкие цифровые экосистемы.
ИНТЕРВОЛГА имеет большой опыт разработки и интеграции торговых платформ (интернет-магазинов и маркетплейсов) с учетными и бухгалтерскими системами от 1С, SAP, Юнико и других вендоров. Теперь в нашем портфолио есть сервисы доставки. Если вам нужно объединить возможности имеющихся бизнес-систем, но вы не знаете как это сделать наилучшим образом – оставьте контакты на нашем сайте. Мы перезвоним и организуем онлайн-встречу, на которой уточним детали, предложим варианты решения и дадим оценку стоимости работ.
