Как мы решили комплексные проблемы склада 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
В конце хотим поделиться краткими выводами, которые могут быть полезны компаниям, собирающимся разрабатывать собственную систему складского учета.
- Даже идеально откалиброванная система потребует полной переделки через 10 лет. Просто потому что технологии и инструменты разработки не стоят на месте, а активно развиваются. Когда мы завершили создание старой системы в 2012 году, про Kotlin слышали только его создатели, а сейчас это топовый язык для написания Android-приложений.
- Не стоит бояться использовать актуальные технологии, которыми вы не владеете. Ни один из наших разработчиков не использовал Kotlin ранее. Во всем приходилось разбираться по ходу дела. Но результат получился отличным.
- Использование всех технических возможностей устройств. Наша предыдущая версия системы складского учета не использовала даже половины возможностей сканеров. В новой мы реализовали ряд фич, о которых раньше могли только мечтать: оповещения вибрацией и звуком или время отклика сканера меньше 0,2 секунды.
- Не стоит недооценивать своих сотрудников. Если честно, мы не ожидали, что среди работников склада есть супергерои, которые сканируют по 5 товаров в секунду. Из-за этого пришлось совершенствовать систему на ходу.
- Простота и интуитивность приложения. В идеале сотрудник, который впервые видит сканер, должен научиться им пользоваться уже в первый рабочий день.
- Четкое разграничение функций на обязательные, второстепенные и полезные. К обязательным относятся базовые функции склада: размещение товара, компоновка заказов, учет полок и наименований. К второстепенным — все более редкие, но нужные, вроде кросс-докинга и поиска пропавших товаров. К просто полезным — все остальные, которые улучшают работу, но не влияют на основную функциональность.
- UX и UI крайне важны, но только когда базовая функциональность работает как часы. Мы приступили к улучшению пользовательского опыта только после длительных тестов новой системы. До этого мы просто скопировали интерфейс со старой версии. И только сейчас, спустя полгода тестов, начинаем его улучшать.
- Необязательно нанимать новых разработчиков — все возможно и своими силами. Разработкой нашего приложения занимались два специалиста на фуллтайм примерно год. Время от времени мы привлекали сторонних специалистов, но не закладывали на это чрезмерные бюджеты.
Есть вопросы по специфике разработки или результатам? Задавайте их в комментариях. Постараемся на все ответить и поделиться своим опытом.
И они даже не почувствовали, что что-то поменялось. KPI остался на прежнем уровне.Ну я даже не знаю. Улучшать систему спустя 10 лет и даже никак не поднять KPI? У вас технический директор зачем на работу ходит, можно узнать?
Зачем, зачем! За зарплатой и премией конечно же))
Вы правы в том, что KPI должен изменяться. На тот момент у нас было две задачи: сохранить качество проделанной работы и удобство использования программы сотрудниками. Как и описано в тексте: «в идеале сотрудник, который впервые видит сканер, должен научиться им пользоваться уже в первый рабочий день».
Когда же у нас появится более расширенный функционал, позволяющий повысить эффективность — тогда будем ещё раз внимательно смотреть на KPI.
Наверно измерения остались, а показатели должны вырасти, иначе зачем все затевать?
Ахахаха, ну это у вас сарказм такой, конечно. Но, по ходу, вопрос оценили всерьез)))
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, а внутри заиспользовать бинарные протоколы, которые вполне переваривают такие данные.
Кроме того оперативных данных не так много и заказы сделанные даже пол года назад, можно сложить в архив и забыть про них.
Какая в итоге основная wms на складе? С которой общаются терминалы. Тоже самописная?