Как мы решили комплексные проблемы склада Lamoda всего одним приложением

Один из основных способов взаимодействия сотрудников склада Lamoda с системой WMS (Warehouse Management System) — считывание штрихкодов сканером с мобильным приложением. Совсем недавно мы разработали новое внутреннее приложение для сканеров, а сам переход постарались сделать комфортным для пользователей. В итоге старая система отправилась в музей, а новую активно используют сотрудники.

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

Склад Lamoda — это 40 000 квадратных метров, где хранятся 10 миллионов товаров. Каждый день на смену выходит более 500 сотрудников, которые отправляют и пакуют около 200 000 товаров. Работа кипит круглые сутки, а единственный выходной в году — 1 января.

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

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

Почему мы отказались от старого приложения

Старая версия приложения для сканеров Lamoda была реализована в 2012 году и с тех пор принципиально не менялась. Как говорится: если работает — не трогай. Вот и не трогали ее практически 10 лет.

За это время технологии сильно устарели. Например, JavaServer Faces еще 10 лет назад казался оптимальным фреймворком, который сохраняет равновесие между функциональностью и скоростью. Сегодня новые разработчики его не изучают — есть куда более современные, удобные и функциональные фреймворки. А найти специалистов, которые разбираются в технических «динозаврах» на высоком уровне, практически нереально.

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

Алексей Баранов, системный архитектор в команде разработки склада

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

Все, создаем новую систему: как это было

Первое и самое главное изменение — мы перешли с Java и «костылей» веб-технологий на Kotlin и Android-приложение. Это самое логичное решение, потому что в работе склада мы используем сканеры на базе Android.

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

Сканер в действии

Сканер — это специфический смартфон на Android. Вместо камеры встроен сканер, а стандартная батарея заменена промышленной — ее хватает на 12 часов непрерывной работы устройства.

Часто их делают в форме пистолета, чтобы ускорить процесс сканирования. Но по прошивке они действительно напоминают обычный смартфон.

Концерн Google, который контролирует всю экосистему Android, рекомендует использовать Kotlin при разработке Android-приложений. С этим языком мы раньше не работали, но возможности и плюсы явно перевешивали. В дальнейшем не пожалели об этом решении ни на секунду.

Разработка сразу пошла быстрее, чем на Java. По субъективным ощущениям — примерно в 1,5–2 раза.

При этом одной из основных целей было сохранить интерфейс программы для сотрудников, которые уже к ней привыкли. За 10 лет специалисты приноровились к UI, определенным реакциям клиента и его особенностям, поэтому перед разработчиками стояла задача переписать систему так, чтобы внешне изменения были минимальными.

Сканер на руке сборщика

Любопытно, что на разработку новых фич и максимальную оптимизацию работы клиента, разработчиков подтолкнули сами сотрудники склада.

Мы были очень удивлены, когда узнали, что у нас работают супергерои, которые способны сканировать по 5 товаров в секунду — 0,2 секунды на один товар. Это практически вплотную подбирается к техническим возможностям сканера.

Изначально мы не планировали настолько сильно улучшать скорость отклика. Но 5 товаров в секунду — это очень сильно. Мы до сих пор не представляем, как это возможно в реальной работе. Чтобы лишь примерно повторить такую скорость при тестировании, нам приходилось просто класть коды товаров рядом и «пролетать» по ним сканером.

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

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

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

Постепенно мы закрыли основные функции компоновки заказов. В последнюю очередь добавляли процессы, которые используются наименьшим числом сотрудников вроде кросс-докинга (процесс приёмки и отгрузки товаров от поставщиков напрямую до склада) или поиска потерянных товаров.

Полностью процесс разработки был закрыт в конце 2020 года, и около полугода мы тестировали приложение уже в работе. Тесты затянулись неспроста: на складе используется около 20 различных операционных процессов, внедрение которых шло постепенно. Основная цель — не нарушить работу склада и обучить персонал работе с новым приложением.

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

Как все работает сейчас и планы на будущее складского приложения Lamoda

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

Процесс сборки заказов

Это было стартовое требование, заложенное в самом начале разработки. Сейчас с программой работает более 500 человек в сумме и около 200 одномоментно. И они даже не почувствовали, что что-то поменялось. KPI остался на прежнем уровне. Разве что стало удобнее из-за новых видов оповещений и ускоренного отклика.

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

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

Возможность автономной работы сканера снижает важность стабильной интернет-связи. По сути хороший сигнал нужен только в ключевых точках, а не по всему складу. Устройство накапливает отсканированные товары и отправляет на облако пулом данных, когда находит сеть. Для этого подойдет протокол JSON-RPC Over HTTP.

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

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

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

  • Сделать работу со сканером максимально интуитивно понятной. Это позволит новым сотрудникам обучаться всем особенностям работы с системой на протяжении нескольких дней.
  • Упростить ряд часто используемых процессов (сборка заказов, размещение товаров), сделать их более быстрыми и простыми.
  • Добавить абсолютно новые фичи. Например, меню, основанное на участке пользования, чтобы сотруднику не приходилось долго искать свой участок для сборки или размещения товаров. Всего таких участков 5, и каждый размером с футбольное поле, где много-много полок, в которых легко заблудиться. Таким образом, система сама проведет расчет и построит максимально короткий путь — уже только с этой фичей мы планируем снизить затраты времени на поиск участка минимум на 15–20%.

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

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

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

Интересно, что масштабировать систему будет элементарно. Фактически она уже готова к использованию на новом складе в Софьино.

Краткая выжимка опыта разработки складской системы Lamoda

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

  1. Даже идеально откалиброванная система потребует полной переделки через 10 лет. Просто потому что технологии и инструменты разработки не стоят на месте, а активно развиваются. Когда мы завершили создание старой системы в 2012 году, про Kotlin слышали только его создатели, а сейчас это топовый язык для написания Android-приложений.
  2. Не стоит бояться использовать актуальные технологии, которыми вы не владеете. Ни один из наших разработчиков не использовал Kotlin ранее. Во всем приходилось разбираться по ходу дела. Но результат получился отличным.
  3. Использование всех технических возможностей устройств. Наша предыдущая версия системы складского учета не использовала даже половины возможностей сканеров. В новой мы реализовали ряд фич, о которых раньше могли только мечтать: оповещения вибрацией и звуком или время отклика сканера меньше 0,2 секунды.
  4. Не стоит недооценивать своих сотрудников. Если честно, мы не ожидали, что среди работников склада есть супергерои, которые сканируют по 5 товаров в секунду. Из-за этого пришлось совершенствовать систему на ходу.
  5. Простота и интуитивность приложения. В идеале сотрудник, который впервые видит сканер, должен научиться им пользоваться уже в первый рабочий день.
  6. Четкое разграничение функций на обязательные, второстепенные и полезные. К обязательным относятся базовые функции склада: размещение товара, компоновка заказов, учет полок и наименований. К второстепенным — все более редкие, но нужные, вроде кросс-докинга и поиска пропавших товаров. К просто полезным — все остальные, которые улучшают работу, но не влияют на основную функциональность.
  7. UX и UI крайне важны, но только когда базовая функциональность работает как часы. Мы приступили к улучшению пользовательского опыта только после длительных тестов новой системы. До этого мы просто скопировали интерфейс со старой версии. И только сейчас, спустя полгода тестов, начинаем его улучшать.
  8. Необязательно нанимать новых разработчиков — все возможно и своими силами. Разработкой нашего приложения занимались два специалиста на фуллтайм примерно год. Время от времени мы привлекали сторонних специалистов, но не закладывали на это чрезмерные бюджеты.

Есть вопросы по специфике разработки или результатам? Задавайте их в комментариях. Постараемся на все ответить и поделиться своим опытом.

0
59 комментариев
Написать комментарий...
Вася Пражкин
 И они даже не почувствовали, что что-то поменялось. KPI остался на прежнем уровне.

Ну я даже не знаю. Улучшать систему спустя 10 лет и даже никак не поднять KPI? У вас технический директор зачем на работу ходит, можно узнать?

Ответить
Развернуть ветку
Медный кот

Зачем, зачем! За зарплатой и премией конечно же))

Ответить
Развернуть ветку
Lamoda
Автор

Вы правы в том, что KPI должен изменяться. На тот момент у нас было две задачи: сохранить качество проделанной работы и удобство использования программы сотрудниками. Как и описано в тексте: «в идеале сотрудник, который впервые видит сканер, должен научиться им пользоваться уже в первый рабочий день».

Когда же у нас появится более расширенный функционал, позволяющий повысить эффективность — тогда будем ещё раз внимательно смотреть на KPI.

Ответить
Развернуть ветку
12 комментариев
Сергей Силин

Наверно измерения остались, а показатели должны вырасти, иначе зачем все затевать? 

Ответить
Развернуть ветку
Ground Zero

Ахахаха, ну это у вас сарказм такой, конечно. Но, по ходу, вопрос оценили всерьез)))
5 (ска, 5!!!) сканирований в секунду, пхахахаха!!!
П*ц.
Они теперь послушают вас и сделают показатель на 3 в секунду базовым))

Ответить
Развернуть ветку
СлавалС

"Разработка сразу пошла быстрее, чем на Java. По субъективным ощущениям — примерно в 1,5–2 раза." - откровенная брехня.
Да синтаксис Kotlin более краток, есть своя реализация стримов. Но 70% времени разработчик тратит на понимание того, как его решение повлияет на работу системы, дизайн, чтение кода, понимание зависимостей, тестирования и т.д.

"Для этого подойдет протокол JSON-RPC Over HTTP." - вообще непонятно для чего такое тут писать. Транспорт в системе в обещем случае должен быть абстрагирован и что там гоняется под капотом интересовать должно максимум архитектора.
"Возможность автономной работы сканера снижает важность стабильной интернет-связи.
"По сути хороший сигнал нужен только в ключевых точках, а не по всему складу." А почему бы не натыкать вай фай точек? они же не стоят как-то дорого.
Конечно оффлайн работа нужна, но этому подходу 100 лет в обед.

даже в пиковых нагрузках как 500*5=2500 запросов в секунду, не такая уж и большая цифра. Тем более, что средняя скорее всего будет сильно меньше.
200 000 товаров, если по каждому товару отправляется даже по 100 сообщений(что завышено скорее всего на  порядок), то пик как раз и будет в ~2500 в секунду, реально с 200к товаров, апдейтов наверное 2-3млн.

Вся система in-house, клиенту можно выставить любой дубовый gateway, а внутри заиспользовать бинарные протоколы, которые вполне переваривают такие данные.
Кроме того оперативных данных не так много и заказы сделанные даже пол года назад, можно сложить в архив и забыть про них.

Ответить
Развернуть ветку
Vyacheslav Teplyakov

Какая в итоге основная wms на складе? С которой общаются терминалы. Тоже самописная?

Ответить
Развернуть ветку
Lamoda
Автор

Да, основная WMS тоже самописная :)

Ответить
Развернуть ветку
8 комментариев
Восточный цвет

Я люблю Ламоду, удобно и выбор неплохой. Но пару косяков испортило впечатление.

Один раз не смог купить пуховик — на складе забыли приклеить qr-код. Никакого способа, кроме перезаказа не было, а пуховик был последним. 

Второй раз положил вещь со скидкой в корзину, а приехала она без скидки. Обратил на это внимание после покупки только. Поддержка не помогла. 

Ну и коробки от обуви у вас почти всегда раздраконенные в хлам. 

Ответить
Развернуть ветку
Вася Пражкин
 Ну и коробки от обуви у вас почти всегда раздраконенные в хлам.

Зато на Котлине переписали сканеры. У Вас свои проблемы - у разработчиков свои.

Ответить
Развернуть ветку
Lamoda
Автор

Роман, спасибо за комментарий и за любовь, иногда вопреки неприятным ситуациям, которые случаются, как бы нам не хотелось обратного. Главное то, как мы их со своей стороны решаем. В вашем случае видно, что специалисты поддержки не сделали все, что должны были, но мы работаем, чтобы сотрудники могли всегда найти и предложить подходящее решение. Если скидка по какой-то причине не применилась, а вы это заметили после оплаты, компенсировать разницу между ценой со скидкой и заплаченной вами, было бы корректно.

Что касается QR-кодов: когда система только запускалась, к сожалению, не все сразу работало идеально. Сейчас система налажена и ошибки бывают крайне редко.

А на случай, если оригинальная коробка от обуви потеряла свой вид, у нас есть коробки Lamoda, сотрудники склада должны их своевременно заменять, но почему-то в вашем случае этого не сделали. Очень жаль, что не решили все это в моменте!

Проверьте, пожалуйста, вашу почту, на которую оформляете заказы 😊

Ответить
Развернуть ветку
Valeriy Dik

Ламода ИТ молодцы, как всегда. 

Пара комментариев все же есть.

Даже идеально откалиброванная система потребует полной переделки через 10 лет

Это решается через Application Lifecycle Management. С ним подобные вещи перейдут в разряд плановых бытовых процессов.

 Не стоит недооценивать своих сотрудников. Если честно, мы не ожидали, что среди работников склада есть супергерои, которые сканируют по 5 товаров в секунду. Из-за этого пришлось совершенствовать систему на ходу.

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

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

Ответить
Развернуть ветку
Артур Гаврончук

Назвать статью надо было "Как потратить 5 миллионов на зп двум разработчикам за год и нихрена по сути не изменить".

Лучше бы эти 5 млн премиями на склад закинули, хотя бы 1 месяц работники бы работали быстрее)

Ответить
Развернуть ветку
Vyacheslav Rubanyuk

Вопрос про автономную работу сканеров - если часть времени сканер недоступен, то как потом происходит синхронизация остатков в реальном времени ?

Ответить
Развернуть ветку
Lamoda
Автор

Сейчас сканеры работают только онлайн. «Остатки» и прочее хранятся на уровне сервера

Ответить
Развернуть ветку
6 комментариев
Vyacheslav Rubanyuk

Где можно посмотреть ваше приложение ?)

Ответить
Развернуть ветку
Lamoda
Автор

Исходниками поделиться не готовы

Ответить
Развернуть ветку
2 комментария
Yan

Про Котлин было странно. Ну типа в чем проблема на нем написать новое приложение было?

В штате точно есть разработчики которые на нем писали.

Ответить
Развернуть ветку
Вася Пражкин

Пишут, что не было разрабов:

 С этим языком мы раньше не работали

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

Ответить
Развернуть ветку
1 комментарий
Lamoda
Автор

До этого у нас не было потребности в том, чтобы писать приложения на Kotlin. Поэтому в штате не было разработчиков, которые писали бы на этом языке. Когда мы поняли, что Kotlin для этой задачи подходит лучше всего — подтянули экспертизу. А нанимать новых котлинистов не было необходимости, так как основная разработка и поддержка ведется на Java :)

Ответить
Развернуть ветку
3 комментария

Комментарий удален модератором

Развернуть ветку
Yan

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

Ответить
Развернуть ветку
Вася Пражкин

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

Ответить
Развернуть ветку
1 комментарий
Lamoda
Автор

У нас есть полное покрытие сетью склада. Проблемы нет :)

Ответить
Развернуть ветку
Vasiliy Leytman

видимо такая же проблема, как и внимательно прочитать текст, в котором написано что это покрытие уже есть)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Yan

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

Ответить
Развернуть ветку
Lamoda
Автор

Спасибо за комментарий! ☺ В новой версии приложения используются оповещения вибрацией и звуком, так как сотрудники склада почти не смотрят на экран в момент работы. 

Ответить
Развернуть ветку
Читать все 59 комментариев
null