Организация сборки заказов с помощью мобильной платформы

 

 

Меня зовут Алексей Матюшкин. Я руководитель проектов в компании «Автомакон». Уже больше 20 лет занимаюсь ИТ. Работал программистом, аналитиком, руководителем проектов, ИТ-директором.

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

 

Что за проект

 

 

Нашего партнера, наверное, многие знают, это ВкусВиллл – один из лидеров продуктового ритейла, одна из самых быстроразвивающихся компаний по онлайн-доставке продуктов питания.

На текущий момент у ВкусВилла более 1300 офлайн магазинов, свыше 100 дарксторов, а количество заказов в сутки уже пробило 150 тысяч. Все это обеспечивается работой нескольких тысяч людей – курьеров и сборщиков.

 

 

Если посмотреть на показатели первого полугодия 2021 года, ВкусВилл – самая динамично развивающаяся компания в сфере онлайн-доставки продуктов.

 

 

С нашей стороны проект по автоматизации «ВкусВилла» (мы его условно назвали «Доставка») поддерживает порядка 40 человек.

Эти люди разбиты на несколько команд, каждая отвечает за тот или иной сервис. Так, есть команды:

• ГЕО;

• каталога;

• покупательской корзины;

• лояльности;

• доставки;

• кассового оборудования;

• сайта;

• и команда сборки, которой руковожу я.

 

Ситуация на момент старта проекта

 

 

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

Пандемия заставила компанию пересмотреть свои позиции. В марте 2020 года был выбран курс развития онлайн-продаж, на нашей стороне сформировались перечисленные выше команды и практически два месяца мы работали в режиме 24/7. За это время:

• было полностью переработано клиентское приложение;

• был разработан стабильный платежный сервис;

• появился ГЕО-сервис;

• была сделана надежная интеграция с сервисами такси;

 

 

В части сборки на тот момент ничего автоматизировано не было.

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

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

 

 

Поскольку магазины маленькие (в среднем 100-150 кв.м.), на такой площади организовать сборку большого количества заказов невозможно – товары в ассортименте не разместишь, запасов тоже никаких не создашь.

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

 

 

Осознавая все эти сложности, ВкусВилл решили попробовать такой формат, как даркстор – работа с онлайн-заказами.

Даркстор – это что-то среднее между супермаркетом и распределительным центром (РЦ), в котором нет покупателей, там обслуживаются только интернет заказы. На Западе это довольно распространенная вещь.

В среднем один даркстор занимает у ВкусВилла площадь 1000-1500 кв.м. В нем работает 25-30 сборщиков смену. Ассортимент в некоторых дарксторах достигает 10 тысяч SKU (единиц складского учета). Клиент может заказать онлайн не только товары марки ВкусВилла, но и любой другой товар, который доступен в обычном супермаркете.

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

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

 

MVP и мобильная платформа 1С нас спасет

 

 

Когда у проекта высокая степень неопределенности, а результат нужно сдать в сжатые сроки, спасает подход Lean Startup.

 

 

Смысл подхода Lean Startup в том, чтобы максимально быстро и с минимальными затратами протестировать какую-то гипотезу, идею, процесс.

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

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

 

Почему мобильная платформа 1С

 

 

Почему я решил использовать в этом проекте мобильную платформу 1С?

• Во-первых, мы компания франчайзи, 1С-ники у нас есть, они смогут в ней разобраться.

• Во-вторых, достаточно просто интегрироваться с нашей большой 1С, не надо заморачиваться на фронт и бэк, привлекать кучу народа.

• Кроме того, никаких дополнительных лицензий покупать не нужно, все уже есть.

В общем, получается довольно быстро и относительно недорого.

 

Ход проекта

 

 

Проект стартовал в середине декабря 2020 года:

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

• Продумали инструменты навигации и маршрутизации пути сборщиков.

• Продумали, как выкладку обеспечить и как все разместить.

• Постарались максимально оптимизировать процесс для сборщиков.

 

 

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

Это подкреплялось еще и тем, что первый даркстор был открыт на базе одного РЦ. Фактически я сходил в соседнюю комнату, притащил несколько комплектов оборудования, в течение 2-3 недель мы сделали рабочий прототип и стали тестировать уже на новогодних каникулах.

Мы увидели, что в целом процесс выстроен правильно. Но начались проблемы с оборудованием.

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

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

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

Поэтому мы пришли к выводу, что это оборудование не подходит.

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

 

Переход на ТСД

 

 

В итоге мы перешли на другой вариант. В магазинах уже были внедрены терминалы сбора данных (ТСД) и использовалось свое мобильное приложение – тоже на мобильной платформе 1С.

Мы взяли ТСД и перенесли в это мобильное приложение то, что разработали для даркстора, серьезно переработали интерфейсы и стали тестировать.

 

 

К середине февраля 2021 года у нас уже появилась новая рабочая версия мобильного приложения и удобное оборудование.

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

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

Подключив мобильные принтеры к ТСД, мы стали маркировать собранные пакеты и привязывать их к ячейкам в зоне выдачи.

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

Дарксторы стали открываться как грибы, и нам пришлось стремительно масштабироваться.

 

Повышаем эффективность

 

 

Появился поток всяких идей, пожеланий, доработок для дальнейшего удобства и развития.

Параллельно с этим мы начали думать, как повысить эффективность, стали пробовать различные варианты сборки заказов. Исторически сложилось 3 варианта сборки:

• параллельная;

• последовательная;

• зональная (конвейерная).

 

 

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

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

 

 

Стали экспериментировать с параллельной сборкой.

Сделали сборочный лист, в который объединяются заказы по определенным правилам. Так как каждый даркстор уникален – своя топология, свой состав персонала (где-то больше стажеров, где-то – больше опытных сотрудников), был разработан специальный конструктор настроек, по которым происходит объединение сборочных листов в зависимости от времени суток, очереди, веса, пересечения товаров и других параметров.

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

 

 

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

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

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

Что нам это дало? Пробег сборщика снизился, а количество заказов увеличилось на 30-40 процентов в зависимости от даркстора.

У этого механизма тоже есть определенные минусы, особенности:

• нужно тщательно настраивать правила для каждого даркстора;

• новичкам сложно работать – нужна стажировка или, может быть, на первом этапе не стоит им давать сложные параллельные заказы;

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

 

 

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

В чем его необычность? Обычно даркстор – это плоская поверхность, где установлены стеллажи, сборщик бегает, собирает товары. А этот оказался двухэтажным и разбитым на закутки. Бегать с товаром по лестнице весьма сложно, люди быстрее уставали, меньше собирали. Поэтому мы решили попробовать конвейерную сборку.

Это выглядит примерно так. По всей территории дакстора протянуты конвейерные ленты во все закутки, что виртуально разбило даркстор на 7 зон. Если в предыдущем случае мы в сборочный лист объединяем заказы, здесь, наоборот, заказ разбивается на составные части, получаются сборочные листы по зонам.

 

 

У нас выделились 3 функциональные роли.

• Если в остальных случаях сборщик выполняет все роли – собирает, комплектует, проверяет, оплачивает, передает в зону выдачи, то здесь сборщик приходит в конкретную зону, авторизуется, и ему на ТСД начинают прилетать сборочные листы, касающееся именно этой зоны. Он их собирает, упаковывает в сборочный пакет, стикерует сборочной этикеткой, кладет на конвейер, на котором заказ едет в зону комплектации, в накопитель.

• В зоне комплектации работают комплектовщики. Они берут этот пакет, сканируют его. Если есть уже какие-то части заказа, ТСД говорит, в какой ячейке зоны комплектации они лежат. Таким образом все части заказа собираются в ячейке комплектации в зоне комплектации.

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

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

 

 

В итоге мы наладили процесс. И выяснили, что:

• У такого типа сборки значительно выше качество, значительно меньше ошибок за счет двойного контроля. Сборщик нигде не бегает, он хорошо знает свою зону, знает, где что лежит, что в тех или иных случаях делать. Второе звено контроля – на кассе. Кассир проверяет заказ дополнительно и только потом его оплачивает.

• Но основной плюс – возможность использовать такие схемы на нестандартных дарксторах.

Минусы этого способа:

• более высокие инвестиции при старте;

• затраты на конвейерную ленту и различное допоборудование в виде специальных холодильников и т.п.;

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

• еще одно узкое место – кассы. Сборка осуществляется очень быстро, если сравнить с другими способами. Но кассы – это тормозящее узкое горлышко. Потому что надо прийти на кассу, загрузить данные о заказе в ТСД, проверить все, что собрано, оплатить. Это происходит медленно.

Но сам процесс рабочий. Этим вариантом можно пользоваться для организации сборки на нестандартных дарксторах.

 

Инфраструктура – это очень важно

 

 

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

Вы можете написать суперкрутое приложение, но если у вас на конечной точке 100 раз в день будет падать WiFi, а люди вместо использования по назначению ТСД будут им ковыряться в ухе, это будет полный провал.

Так как у нас очень много устройств, очень много дарксторов, в магазинах тоже используют сборку и ТСД, у нас организованы:

• отдельная линия по поддержке оборудования ТСД;

• на каждом дарксторе организованы зоны зарядки и обслуживания ТСД, подменный фонд;

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

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

 

Использование пушей

 

 

Хорошо зашло в проект использование пушей для мобильной платформы. Мы используем пуши в части получения уведомлений о назначении сборщика и об отмене заказа.

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

Загрузка дарксторов имеет четко выраженные пики и падения в разные моменты времени. В ситуациях, когда заказов мало, сборщики начинают конфликтовать за возможность их обслужить. Мы сделали механизм ожидания, который, честно скажу, я подсмотрел у каршеринговых компаний. Когда нет машины поблизости, ты запускаешь радар, и когда появится свободная машина, ты ее бронируешь. Здесь аналогичная история. Когда нет заказов, люди на своих ТСД встают в виртуальную очередь, ждут, когда появятся заказы. Когда заказ прилетает, он отправляется первому в очереди сборщику, раздается через пуш. Это нивелировало конфликтные ситуации.

 

Дальнейшее развитие

 

 

У нас много планов на будущее. Я слышал, что бизнес планирует выполнять миллион заказов в сутки.

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

• Также у нас активно добавляются новые сервисы – рестораны, дарккитчены.

• Мы планируем начать эксперименты по оптимизации выкладки, оптимизации путей сборщика.

 

Выводы

 

 

Основной вывод – мобильная платформа опять помогла быстро стартануть.

Из всех 40 человек, которые задействованы в обслуживании ВкусВилла, у меня самая маленькая команда:

• один SQL-разработчик, который занимается взаимодействием с большим SQL, где вертится весь этот проект доставки;

• и один 1С-разработчик;

• еще мы привлекаем архитектора, и все.

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

 

Вопросы

 

Как у вас организованы обмены между мобильными приложениями и центральной базой? Как часто они выполняются, какая технология?

 

 

На слайде показана архитектура. Мобильное приложение сборщика через веб-сервис подключается к 1С, а дальше либо забирает что-то из 1С, либо записывает информацию в большой SQL, где вертятся данные по доставке и заказам. Сейчас такая схема.

Общая НСИ-информация грузится фоново, изменения поступают с определенной периодичностью.

А все остальное – по событию. Например, чтобы взять заказ, сканируешь свой бэйджик, тебе прилетает заказ. В этот момент идет обращение через 1С к SQL-серверу и все. Когда завершаешь заказ, то же самое.

У нас больших онлайн-обменов нет, у нас либо сеансово в фоне, либо по событию.

Насколько мощные нужны ТСД для реализации такой схемы?

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

Никакой сверхнагрузки на ТСД нет. В устройствах важны хорошие и удобные интерфейсы. Плюс логика работы. А большие мощности не нужны.

Главное – чтобы WiFi был хороший.

Вы используете мобильное приложение или мобильный клиент?

Мобильное приложение, apk-шники формируем.

Как обновляется ТСД?

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere.