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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура рынка ПО для доставки.jpg

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

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

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

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

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

Узнайте подробнее об опыте MYBOX:

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

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

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

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

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

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

Прочитайте о том, как упростить ордерную систему:

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

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

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

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

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

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

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

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

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

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

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

Схема обменов cooker.ua.jpg

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

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

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

Что требовало внимания

Как решили

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

Создали общий обмен остатками на обоих каталогах.

Покупатели могли изменить заказ после его сборки или в процессе доставки. Способ оплаты могли указать как «наличные», а платили картой.

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

Если это была оплата наличными, или картой при получении, то курьер брал сумму указанную в системе (в сборке заказа/в накладной). Если была предоплата банковской картой, то могли сделать возврат излишне уплаченной суммы.

Возникали различия в остатках в 1С и на складах.

Например:

В 1С – 12шт.

На сайте – 10шт.

Покупают 1шт.

В 1С становится 11 шт, на сайте 10 шт.

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

При создании нового заказа в 1С автоматически создавался и новый контрагент. Но розничный покупатель не является контрагентом, т.к. сделка совершается без договора. Когда ежедневно на сайте проводится более 1000 покупок, то и база «контрагентов» может расти до бесконечности. Вторая причина – особенности работы с платежной системой, которой нужен был обезличенный клиент.

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

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

Переписали интеграцию заказов, чтобы в заказ в 1С попадали товары с ценой на сайте, а не с пересчитанной ценой из заказа (при применении промокода или бонусов). Скидка заходит в заказ отдельно от стоимости товара, поэтому при изменении заказа, не будет проблем с пересчётом скидки клиенту.

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

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

Ошибки интеграции 1С и логистической системы Attika. Обмен работал нестабильно, из 20 заказов в 1С в Attika попадало 3.

Была проблема в сопоставлении статусов. Сделали сопоставление, со стороны Attika добавили новые статусы и проблема была решена.

Отсутствие возможности изменять, добавлять, удалять товары при включенном резерве в 1С (по умолчанию механизм резерва не поддерживает автоматических изменений над товарами).

Разработали специальный механизм, который позволил редактировать зарезервированные товары.

Разделение заказов на заказы с подакцизными товарами (для безналичной оплаты) и без них.

Доработали формирование документа «Поступление на счет» с разделением на две организации. В одном документе сумма по алкогольной продукции, во втором – по всем остальным товарам.

Из-за роста объема каталога и количества заказов функционал «Модуль синхронизации» работал медленно и с ошибками.

Решили с помощью создания микросервисов.

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

Создали структуру обмена, обработку и парсер .xls для их добавления.

Требовалась интеграция мобильного приложения с 1С.

Сделали интеграцию 1С с мобильным приложением, которое написала сторонняя команда разработчиков. Настроили обмен позициями каталога и ценами.

Чтобы не возникали зависающие резервы нужно было автоматически распроводить расходные накладные при отмене заказа.

Был реализован механизм (групповая обработка по удалению зависших резервов, перемещение резервов при изменении склада), который смотрит все связанные расходки в заказе, автоматически сбрасывает резервы и распроводит их.

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

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


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

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

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

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

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

Плюсы:

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

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

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

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

Минусы:

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

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

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

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

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

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

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

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

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

Обмен был построен на CommerceML – унифицированном стандарте обмена коммерческой информацией в XML-формате. Стандарт предполагает передачу в согласованном структурированном формате информации о каталогах товаров, заказах, документах. Но если речь идет о скорости обмена, то формат является избыточным и тяжелым с точки зрения объема передаваемой информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИНТЕРВОЛГА имеет большой опыт разработки и интеграции торговых платформ (интернет-магазинов и маркетплейсов) с учетными и бухгалтерскими системами от 1С, SAP, Юнико и других вендоров. Теперь в нашем портфолио есть сервисы доставки. Если вам нужно объединить возможности имеющихся бизнес-систем, но вы не знаете как это сделать наилучшим образом – оставьте контакты в форме ниже. Мы перезвоним и организуем онлайн-встречу, на которой уточним детали, предложим варианты решения и дадим оценку стоимости работ.
Оцените статью
05.09.2023
Понравилась статья?
Поделитесь ссылкой с друзьями и коллегами!

Статьи по теме

Разработка календаря бронирования для сайта на Битрикс авиационного учебного центраЧтобы пилоты авиакомпаний могли бронировать время своих тренировок в учебном центре, мы разработали для них удобный модуль бронирования времени. Рассказываем по...
Продавайте больше через индивидуальные скидки и персональные цены для оптовиковВ статье рассказываем, как с помощью функционала работы с ценами и скидками можно привлекать новых b2b-клиентов и удерживать старых, создавая долгосрочные и вза...
Биллинг ИТ-компании на laravelОбычно мы рассказываем, как принесли пользу клиенту. Но сегодня у нас будет особый разговор, ведь заказчиком биллинговой системы ИТ-компании была… ИНТЕРВОЛГА! ...
Почему мы рекомендуем начинать с внедрения базовой версии b2b-платформыК нам в компанию ИНТЕРВОЛГА часто обращаются клиенты с заявками на внедрение личного кабинета дилера с длинным списком желаемых функций. Однако мы рекомендуем н...
Функция b2b-платформы — отправка рекламаций в CRMОптовые покупатели — ключевой сегмент экономики торгово-производственного предприятия, и их удовлетворённость напрямую влияет на успех бизнеса. Новый функционал...
Как b2b-платформа передает в 1С данные по новым контрагентам В этой статье мы расскажем, что происходит после того, как клиент зарегистрировал в б2б-кабинете новое юридическое лицо и сделал заказ, а также покажем, как...
Мы работаем по одному из двух форматов:
  • аренда команды (от 2 человек, не менее 3 месяцев);
  • итерации с фиксированной ценой (1-3 месяца длительностью).
ИНТЕРВОЛГА предоставляет:
  • регулярные онлайн-планерки с заказчиком;
  • квалифицированных специалистов;
  • организованную команду (находятся в одном помещении, что упрощает решение рабочих вопросов);
  • полную прозрачность и регулярность отчетов о результатах.
Ключевые услуги:
  • нагруженный интернет-магазин;
  • личный кабинет;
  • оптовые продажи — B2B-платформа;
  • маркетплейс;
  • технический аудит сайта;
  • Битрикс24 — корпоративные HR-порталы;
  • Битрикс24 — построение CRM-системы;
  • Битрикс24 — личные кабинеты сотрудников;
  • Битрикс24 — аудит портала;
  • 1С — интеграция с другими системами;
  • 1С — доработка системы;
  • маркетинг — комплексное интернет-продвижение;
  • маркетинг — продвижение для B2B.
Хотите получать лучшие статьи от INTERVOLGA раз в месяц?
Подпишитесь на рассылку — спамить не будем