9 кругов автоматизации склада Lamoda

    Наш склад размером с две Красные площади и высотой в 5 этажей работает круглый год и никогда не спит — 24/7 364 дня в году (единственный выходной — 1 января). У нас хранится и обслуживается более 8 000 000 товаров, каждый день на смену выходит более 300 операторов. Они работают с товаром, поступающим со всего мира, и собирают заказы для пользователей из четырех стран: России, Украины, Белоруссии и Казахстана. На таких масштабах бизнес требует безупречной автоматизации.

    Под катом я, Паша Финкельштейн — тимлид команды разработки и автоматизации склада — расскажу, во что может вырасти open source решение, если к нему приложить хорошую команду разработки и вполне конкретную бизнес-задачу.



    Базовая логика работы


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

    WMS (Warehouse Management System) контролирует жизненный цикл каждого товара, находящегося на складе, с момента прибытия грузовика с товарами поставщика на склад и до отгрузки товара клиенту.



    Специфика автоматизации fashion


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



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

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

    Open source и путь к собственной разработке


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



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

    Для начала взяли open source решение на Java и после решили собрать собственную команду разработки, тем более, что уже есть подходящая основа. Мы наращивали функциональность, затем взялись и за ядро системы: избавлялись от legacy и толстого клиента, проводили рефакторинг, разрабатывали новые сервисы для поддержки операционных процессов.

    Этапы автоматизации


    Основные изменения выполнялись «волнами», вместе с перестройкой самих процессов.

    На сегодняшний день он пережил девять этапов модернизации, и останавливаться на этом мы не планируем.

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

    Реализация


    Наши основные технологии: Java, Postgres, Wildfly, Redis, ActiveMQ.

    WMS написана на Java 8. Но не так давно мы поправили последний модуль, который мешал переходу на Java 11, обновимся в ближайшей перспективе.

    Под WMS отведена серверная стойка, установленная прямо на складе. Это даёт нам гораздо больше уверенности в том, что WMS будет работать даже в том случае, если электричество и/или интернет отключат. Единственное, что пострадает — сообщения в товароучетную систему придут с задержкой. В качестве сервера приложений используется WildFly, правда, пока не последней версии. Миграция на последнюю также в планах. Для переезда всё уже написано, но не успели пока провести функциональное и нагрузочное тестирование, да и перед новым годом загрузка относительно высокая. Также используется проверенный ActiveMQ.


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

    Большую часть места там занимают даже не товары, а аудит действий работников склада. Будучи критичной для бизнеса системой, склад должен знать, почему что-то появилось в системе или пропало — мы не можем допустить не трассируемых изменений. Как раз сейчас мы думаем над тем, чтобы вынести эту часть базы в отдельную сущность в MongoDB.

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



    Есть на нашем складе и интересная «экзотика». Например, упомянутый в Технорадаре Haskell, на котором написан бэкенд визуализации item-сортера (это такая машина, которая может составлять товары из одной посылки вместе и отдавать их оператору на сборку). Там чисто вычислительная задача, которую удобно решать в функциональном стиле. Естественно, никто не собирается использовать Haskell для каких-то крупномасштабных проектов.

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

    Оборудование для автоматизации


    Какая же автоматизация без оборудования! Весь склад опутан целой сетью конвейеров.

    Упомянутый выше item-сортер работает на этапе отгрузки, позволяя раскладывать десятки тысяч единиц собранного со стока товара по конкретным заказам. В свое время сортер избавил наших операторов от необходимости путешествовать с тележкой по всему складу, чтобы собрать нужные товары. Заказы дробятся, каждый оператор собирает товары только со своего этажа (экономя время на перемещениях), а сортер заботится о том, чтобы товары с разных этажей попали в нужные заказы автоматически. Изменение операционного процесса в 4 раза ускорило сборку заказа и существенно сократило количество ошибок.

    Все автоматизированное оборудование нам предоставляет партнер. За управление конкретными агрегатами у них отвечает собственная система, которая размещена в серверной стойке по соседству с нашей WMS. Между системами настроена интеграция на довольно высокоуровневом протоколе  — общаемся по SOAP. Из своих операционных процессов внутри WMS мы обращаемся к их системе, когда нам, например, нужно переместить контейнер с товаром из точки A в точку B. Т.е. с точки зрения нашей системы вся эта автоматика выглядит довольно просто, несмотря на ее реальную внутреннюю сложность.

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

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

    Команда и scrumban


    Развитием всей этой системы сейчас занимается команда из 12 человек. На одном из последних этапов в пиках модернизации, когда отдельно автоматизированные процессы должны были объединиться в нечто целое, участвовало до 20 одних только разработчиков (тот этап потребовал 132 человеко-месяца и включал более 1500 коммитов). Но по мере окончания масштабных преобразований некоторые люди решили изучить Go или Python и перешли в другие команды разработки.

    В команде у нас есть «классические» проджект менеджеры, совмещающие в себе функции продакта и проджекта со стороны ИТ (в среднем, один ПМ на 5-6 человек). В его задачи входит общение с нашим основным заказчиком — складом в лице его директора и отдела развития операционных процессов. Со своей стороны мы в большей степени заботимся о технической модернизации — выборе подходящего стека, обновлениях и т.п. — а ребята со стороны склада думают об оптимизации процессов.

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

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

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

    Хотя взаимоотношения между ролями в команде у нас вполне классическое, методологию разработки мы выбрали cкрамбан (scrumban).

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

    Так что scrumban — это компромисс, который устроил всех. Мы используем итеративный процесс, но спринт для нас и есть релиз. Раз в месяц встречаемся с заказчиком и занимаемся релизным планированием: обсуждаем, что и на какой неделе мы выкатываем. Внутри спринта реализован канбан — с бэклогом задач, прогрессом и т.п. Правда, и этот процесс постепенно меняется — например, канбан доски у нас нет. Просто когда один разработчик заканчивает свою задачу, ему выдают следующую из пула в соответствии с планами на ближайший релиз и компетенциями самого разработчика.

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

    Не как у всех — на примере инвентаризации и мониторинга


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

    Хороший пример — инвентаризация. По закону ее необходимо выполнять на складе раз в год, но наши бизнес-требования определяют более пристальное наблюдение за стоком. Во-первых, мы хотим отражать на сайте актуальную информацию о наличии товаров, и во-вторых, той же актуальной информации требуют наши B2B партнеры, fashion-бренды. Поэтому инвентаризация у нас происходит ежедневно, 364 дня в году, полка за полкой во всем 5-этажном комплексе из нескольких зданий. И этот процесс целиком поддерживается нашей WMS — на готовом решении реализовать такое было бы тяжело.

    Сейчас инвентаризация находится в процессе очередного обновления для повышения эффективности этого процесса.



    Еще один пример собственной разработки — мониторинг. Он реализован через веб-клиент и позволяет отображать и отслеживать очень интересные метрики. Более того, для нас важно визуальное представление этих метрик. По сути мониторинг — это отрисованный в простенькой графике склад, где мы наглядно видим, в каких местах все работает хорошо, а где наблюдаются проблемы (вплоть до конкретного оператора). Главное, с таким представлением мы можем понять, почему возникают эти проблемы.



    KPI складских работников и Redis


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

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

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

    На этом сюрпризы от складского персонала не закончились. Почти сразу после релиза сессии у нас начал падать PostgreSQL. Причины неожиданной деградации базы мы искали несколько дней, пока не обнаружили, что дело, опять же, в находчивости. Одна девушка часто ходила курить. Когда она покидала рабочее место, ее выбивало из сессии, а чтобы залогиниться обратно, необходимо найти старшего смены и просканировать его бейдж. Сокращая себе блуждания по складу, она просто оторвала штрих-код с одной из тележек и зафиксировала скотчем кнопку сканера, устанавливая на постоянное сканирование этого штрих-кода. И это могло бы долго оставаться незамеченным, если бы штрих-код не был с тележки, в которой лежало 800 единиц товара. При каждом сканировании генерировался огромный SQL-запрос для валидации товаров, который «убивал» базу таким «внутренним DDoS». Пришлось позаботиться и об ограничениях на количество сканирований в единицу времени и на количество товаров в тележке.

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



    Куда мы движемся дальше?


    Оптимизацию процессов и автоматизацию склада, как кажется, невозможно завершить. Она длится в компании уже 5 лет, и, как я сказал выше, даже после 9 этапа мы не собираемся останавливаться. Компания продолжает расширяться и в B2C, и в B2B, так что уже в ближайшем будущем у нас планируется очередной большой проект — открытие еще одного склада, это потребует либо масштабного переписывания существующей системы, либо создания аналогичной с нуля на новом месте. И это новый интересный челлендж на стыке бизнеса, физических объектов, операционных процессов и технических решений.
    Lamoda
    79,00
    Russian Fashion Tech
    Поделиться публикацией

    Комментарии 65

      +1
      Для начала взяли open source решение на Java и после решили собрать собственную команду разработки, тем более, что уже есть подходящая основа.

      Название open source решения можно как-то узнать?
        +1
        К сожалению, эту информацию я из-под NDA вытащить не могу. Что могу сказать — это что у исходного решения двойное лицензирование и у нас коммерческая версия приобретена.

        Что важно — сейчас от него и правда почти ничего кроме базовых сущностей не осталось, так что информация о конкретном решении уже и не так важна в разрезе нашей компании.
          0
          Жаль, было бы интересно :)
            +1

            Open source для красивого словца добавили видимо. Казалось бы при чем тут свобода, если NDA и нельзя говорить про то что открыто миру

              0
              Ну мы скорее имели сказать что даже 7 лет назад на рынке было нечто опенсорсное, с чем можно было начинать. Сейчас наверняка выбор больше и лучше.
                0
                Я не силен в лицензиях и прочем подобном. Знаю лишь, что некоторые open source решения лежат на github под какой-то интересной лицензией. Ты можешь на базе этого проекта делать что угодно. Но потом ты обязуешься все свои решения и продукты тоже выложить в open source. Могу предположить, что отсюда и NDA
                  0
                  Не совсем. У нас под NDA всё, что может дать преимущество конкурентам. И когда мы не уверены, даст ли им преимущество знание конкретного решения — мы не берём на себя риски. А тут был опенсурс под двойной лицензией, как Qt. Если пользуешься бесплатной — обязан опенсорсить, если покупаешь платную — получаешь саппорт и опенсурсить не обязаны. Мы воспользовались второй опцией.
            0
            Рассматривали возможность голосового управления? Если да, то почему отказались?
            И ещё, картинки интерфейсов терминалов можно где-нибудь посмотреть?
              +2
              Насколько мне известно, такая возможность не рассматривалась. Когда мы говорим о голосовом управлении у меня сразу возникает два вопроса:
              1. Управление чем?
              2. Как?

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

              А насчёт «Как» — надо учитывать что как-никак на складе достаточно шумно. Распознавание речи в наше время и так оставляет желать лучшего, а уж когда вокруг много таких же говорящих и всякой не очень тихой техники шансы на правильное распознавание снижаются ещё сильнее.

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

                Голосовое управления хорошо работает там, где нужно чтобы руки были свободны, а не для скорости.
                  0
                  Ну мы не рассматривали, но это не значит что и не будем! Поделитесь success story?
                    0
                    Так тут делиться особо нечем. Мы взяли готовый движок для распознавания. На входе голосовые команды преобразуются в текст и в зависимости от текста транслируются в команды системы. Т.е. в системе для этого даже ничего менять не пришлось.
                    По сути, эта мулька просто переводит голос в текст и надо на эти текстовые сообщения замапить команды. И обратно, вместо выдачи формочек, система диктовала что нужно делать.
                      0
                      На вопрос «Как» вы ответили, но я всё ещё не совсем понимаю чем именно командовать. Ручным сканером?
                        0
                        Командовать терминалом. Сканер в такой схеме не нужен. Да и то, терминала тоже нет. Терминалом становится сам рабочий, ему выдаются команды через наушник и принимаются от него запросы через микрофон.
                          0
                          А, вы про навигацию в помещении говорите? Если да — то у нас просто так построены процессы что ориентироваться очень просто. Все справляются. А вот сканировать товары, контейнеры и т.д. надо почти во всех процессах.
                            0
                            Нет, я не про навигацию. Я как раз про отборы, приемку и пр. Вместо сканирования, так же, можно проговорить код с этикетки, это не проблема.
                              +1
                              Вариант 1: пик
                              Вариант 2: четырэ шэст ноль три два адин четыре блин сбился четыре шесть ноль…

                              Сомнительно пока выглядит :)
                                0
                                Видел в работе на относительно большом складе, там сотрудник мог выбрать работать с терминалом или голосом, 70% таки выбирали терминал. Свободные руки позволяют работать быстрее, но вероятность ошибки выше, это да.
                                  0
                                  Когда руки заняты, вариантов, как бы, немного. :) Используется такая штука редко, но решение рабочее.
                              0
                              Какие устройства вы использовали для связи сотрудников? Если это гарнитуры, то как решали вопрос личной гигиены?
                                0
                                Вопросы личной гигиены решал клиент на месте. Это его работники и его склад. Поэтому по данному вопросу ничего не могу сказать.
                            0
                            А что за движок, если не секрет? Можно в личку. Интересно как раз попробовать при значительном уровне внешнего шума.
                              0
                              Движок от уровня внешнего шума не зависит. Для этого нужно хорошие гарнитуры.
                                0
                                Какие гарнитуры вы использовали? Мне казалось что движок в том числе должен обрабатывать входной сигнал с определенной долей искажений в т.ч. шумом.
                                  0
                                  По моделям гарнитур не подскажу. Про движок написал в личку.
                        0
                        Управление сотрудниками. Бегают с гарнитурой, система им говорит-возьми 3 штуки товара из ячейки номер такой-то. Но да, при здравом размышлении так как у вас индивидуальная маркировка каждой единицы товара, вам это не очень подходит.
                        Скрины хочу посмотреть, так как тоже занимаюсь WMS, не такого масштаба, конечно. И интересно, как что реализовано в других системах…
                      +1
                      Спасибо за интересную статью и отдельное спасибо за серверную стойку прямо на складе :)

                      У меня такой вопрос:
                      Для начала взяли open source решение на Java и после решили собрать собственную команду разработки, тем более, что уже есть подходящая основа.

                      Скажите, а вы вообще рассматривали подобные системы на 1С? Делали какой-то сравнительный анализ? Как вообще пришли к пониманию, что вам, по сути нужна уникальная разработка практически с нуля своим собственным штатом, нежели купить готовое решение, которое возможно уже потом доработать, если бы оно Вас не устроило где-то? Я не розжига ради, мне правда интересно. Судя по вторичным признакам (не более чем вакухи на хх), ваши коллеги-конкуренты автоматизируют свои склады на 1С (по крайне мере ищут людей, в требованиях к которым указаны соответствующие решения/подсистемы типовых).
                        0
                        1С хороша для небольших и средних складов, без роботов. И с отчетами и мониторингом при размере данных 2ТБ будет грустно.
                          0
                          Да нормально все будет на 1С. У нас пока без роботов, но в целом на 1С все работает.
                          1Тб, 30 складов, 500 сотрудников, сотни тысяч SKU.
                            0
                            Автозапчасти? Сколько строк заказов в день? Какое железо? До 100 тыс. строк заказов в день да, потянет. Уровень Ламоды и Озона — сомнительно, скорее всего будут проблемы на уровне платформы.
                              0
                              У нас больше SKU в один момент времени на складе и, вероятно (не знаю), выше скорость оборота этих SKU.
                            0
                            Как вы поняли из статьи сначала мы ка раз думали что можем работать с готовым решением. Жизнь показала что мы ошиблись. И хорошо что решение было написано на популярном языке — постепенно заточили под себя настолько, что от исходного решения по сути ничего не осталось кроме набора доменных классов (и то далеко не полного). Про 1С сказать не могу, но вот зато комментатор выше ответил, вполне вероятно что он разбирается лучше меня.
                            0
                            Я строил похожую систему на идентификации единицы учета, чтобы сразу предотвратить возможные хитрости пользователей с многократным сканированием, что исключило возможность «внутреннего DDos» Postgres'а. Для обработки действий пользователя использовал конечный автомат. Для каждой единицы учета определен базовый набор состояний с меткой времени перехода, месторасположением и кодом исполнителя. Среди состояний есть «перемещение» и «инвентаризация». По состоянию «перемещение» можно строить аналитику по внутренней логистике. По «инвентаризации» можно проводить инвентаризацию в произвольный момент времени. Вот только клиент — толстый. А сама система используется для учета сырья, материалов и готовой продукции на производстве и конечно не такая масштабная, как в вашем случае(у меня «колхозный» вариант из подручных материалов). Почитать Ваш статью было интересно. Не часто попадается интересная информация по этой теме.
                              0
                              Спасибо большое за ваш комментарий. Сейчас у нас система достаточно сильно похожа на вашу, однако даже частыми проверками состояния (например, каждые 10 мс) гипотетически систему можно уложить — происходят же и другие процессы, в том числе тяжёлые.Но да, стараемся как можно раньше запускать лёгкие проверки, чтобы быстро откидывать «паразитные» запросы.

                              Товароучётка в Lamoda — это отдельная система, с которой мы активно взаимодействуем.

                              В товароучётке есть много специфики — отчёты и всё такое, не хотелось бы нагружать WMS ещё сильнее.
                                0
                                У меня основная часть запросов клиента построена на легких проверках, поэтому даже при самом тяжелом запросе учетной системы — «Отчет цеха за смену», на клиенте это не сильно сказывается. Но у меня всего 20 клиентов, на большем количестве проверить не довелось.
                                  0
                                  Да, мы тоже идём к такой концепции. Одна из задач, которые я перед собой ставлю.
                                    0
                                    А какие самые тяжелые запросы на клиенте? При выполнении какой операции?
                                      0
                                      Самые тяжёлые редко выполняются. Самая жесть где-то на стыке тяжести, частоты и неправильного использования ORM.
                              0

                              asm0dey какой PG используете? Base или Code First? Секционирование самописное или не требуется?

                                0
                                9.4, Code first (привет ОРМ), но это ненадолго. Секционирование самописное, на наследовании. Но, надеюсь с переездом на новый постгрес возьмём встроенное.
                                0
                                Скажите, а вы не рассматривали кубическую складскую систему от Autostore? Имхо под ваши задачи самое оно. Экономия на площадях и персонале…
                                Если рассматривали — то в чем причина отказа?
                                  0
                                  К сожалению, я не знаю, рассматривали ли мы эту систему. У нас тоже есть адача трёхмерной упаковки, мы её для себя удовлетворительно решили. Нам относительно просто потому что
                                  1. У нас ограниченное количество формфакторов товаров
                                  2. У нас не все товары кубические — некоторые мягкие и круглые (условно пледы)
                                  3. Мы разделили всё хранение по типам
                                  4. Для остального мы написали эвристику трёхмерной упаковки

                                  Это про экономию площади. А каким образом достигается экономия на персонале?
                                  0
                                  интересный проект и странно как туда не пролез SAP со своим EWM
                                    +3
                                    Спасибо!
                                    Когда ты стартап — тебе рано думать о САПе. Когда ты не стартап — тебе уже поздно о нём думать. Проекты полного успешного внедрения САП в России можно пересчитать по пальцам, к сожалению. А у нас система уже работает и работает, как нам кажется, хорошо.
                                      0
                                      Я как понял Ламода вообще заморачивается по поводу ИТ и своих разработок, а не покупает непонятные решения типо SAP, MS Ax, ultimate (не дай Господи).
                                        0
                                        У нас много своего/развитого чужого, но есть и полностью стороннее. Например как и многие в России мы используем 1С для бухгалтерии. И MS Ax тоже, кстати — он у нас в качестве товароучётки.
                                          0
                                          1с в России это стандарт. странно что реально SAP не влез к вам. И не пропихнул Hybris
                                            0
                                            Если бы решение зависело от меня — на ценнике Hybris'а я бы сказал «Спасибо, очень интересно, но мы пока не готовы».
                                              0

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

                                                0
                                                Меня звали когда-то работать с ним. Я сказал примерно то же самое, что постом выше :)
                                    0
                                    Мне кажется, от сканирования кодов вручную персоналом (как девушка на фото с ручным сканером) можно и отказаться. Можно автоматизировать сканирование кода товара при перемещении с места на место (с полки на тележку, или на ленту транспортёра). Можно использовать RFID-метки.

                                    Вообще, склад такое место, что его можно автоматизировать полностью: от приёмки товара до выгрузки упакованных товаров на выходе. Внутри — человеку делать нечего, ну кроме техников, смотрящих за роботизированными системами.
                                      0
                                      А сможете примерно прикинуть ценник на десятки миллионов RFID-меток и сотни пространственных RFID-сканеров? У меня немного не хватает знаний, хотя подход мне кажется очень интересным.

                                      Как мы писали в статье — полная автоматизация сейчас кажется нерентабельной. Пока что люди обходятся немного дешевле. Однако я с радостью почитаю ваши предложения и пеедам их коллегам.
                                        0
                                        Мои рассуждения чисто теоретические, основанные на новостях об автоматизации в Amazon и проч. Но я уверен рано или поздно к этому придут все [выжившие в этой гонке]. Не нашёл в статье, что вы уже просчитывали полную автоматизацию.
                                          0
                                          Когда мы с вами говорим об Амазоне важно понимать, что у них есть один полностью автоматизированный склад и сотни обычных неавтоматизированных. У такого явления есть какие-то причины, которые мне пока что неизвестны.
                                          0
                                          В России тоже есть полностью автоматизированные склады, вполне себе рентабельно. Все зависит от оборота и того что хранится. А так, склады без людей под WMS, которая управляет всем, существуют.
                                            0
                                            Да, конечно. В фармацевтике это Очень выгодно потому что контейнеры маленькие и однотипные. Люди бы их роняли или теряли, а роботы точно работают. Вопрос в том, как это работает в fashion-сегменте.
                                              0
                                              Прекрасно работает. Лучше, чем в фармацевтике, где упаковка очень маленькая.
                                                0
                                                А у вас пример какой отрасли, если не секрет?
                                                  0
                                                  У меня примеры из наших клиентов.
                                                0
                                                За лишние 0,1 секунды открытия «ворот» на сборке заказа в коробку улетит несколько лишних упаковок лекарства. Если умножить на количество позиций в заказе, количество заказов и стоимость пачки лекарств — лучше бы человек уронил ту дурацкую коробку.
                                                ЗЫ: я не настоящий сварщик, фармацевтический конвеер только видел, не налаживал.
                                                  0
                                                  Прекрасный комментарий! Безусловно, бывают склады где цена ошибки очень высока и проблемы с возвратом существуют. В том числе к таким отраслям относится формацевтика. С одеждой тут всё немножко проще.
                                                    0
                                                    С возвратами точно проще. Особенно у вас. Ну положит робот две кофты вместо одной — на это ваш же курьер / сотрудник пункт выдачи обратит внимание. Да и клиент может сообщить.
                                                    А приедет в аптеку на 5% больше всех позиций — «какая пересортится? Нет никакой пересортицы, хорошо собрали»
                                                      0
                                                      Абсолютно верно! И вот с учётом отсутствия рисков тут нам выгоднее люди пока что.
                                          0

                                          Как насчёт Искусственного Интеллекта для автоматизации склада?

                                            0
                                            Мы всегда открыты к предложениям! Но вообще-то я надеюсь что наш вплне алгоритмический софт справляется не хуже :)

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

                                          Самое читаемое