Как мы ускоряли время разгрузки товара на складе

    image
    Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки).

    На протяжении нескольких лет мы очень быстро открывали магазины и росли. Закончилось это тем, что сейчас наши склады принимают и отправляют порядка 20 тысяч паллет в день. Естественно, сегодня у нас уже больше складов: два больших в Москве — 100 и 140 тысяч квадратных метров, но есть и небольшие в других городах.

    Каждая сэкономленная секунда в процессах приёмки, сборки или отправки товара в таких масштабах — это возможность сберечь время на операции. А ещё это огромная экономия.

    Именно поэтому два главных множителя эффективности — это продуманный алгоритм действий (процесс) и настроенные ИТ-системы. Желательно «как часы», но «работающие чуть менее, чем идеально» тоже вполне подойдёт. Всё же мы в реальном мире.

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

    image

    Приёмка товара


    Как мы уже говорили, наша компания на тот момент (как, в принципе, и сейчас) стремилась открыть много магазинов, поэтому пришлось оптимизировать складские процессы для увеличения пропускной способности (больше товаров за меньшее количество времени). Это непростая задача, и решить её, просто увеличив персонал, было нельзя хотя бы потому, что все эти люди будут друг другу мешать. Таким образом, мы начали думать о внедрении информационной системы WMS (warehouse management system). Как и полагается, мы начали с описания целевых складских процессов и уже в самом начале обнаружили непаханое поле для улучшений в процессе приёмки товара. Нужно было отработать процессы на одном из складов, чтобы потом накатить их на остальные.

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

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

    Какие были потери? Их было море. Во-первых, работники склада получали бумажные документы. Они ориентировались и принимали решения, что делать с поставкой, по ним. Во-вторых, они считали паллеты вручную и в этих же товарных накладных отмечали количество. Потом заполненные бланки приёмки относились к компьютеру, где данные забивались в XLS-файл. Данные из этого файла затем импортировались в ERP, и только тогда наше ИТ-ядро по факту видело товар. Мы имели очень мало метаданных о заказе вроде времени прибытия транспорта, либо эти данные были неточными.

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

    Стало так:

    1. Поставщик сам заполняет данные о том, что отправляет к нам и когда. Для этого есть связка из SWP и EDI-порталов. То есть магазин публикует заказ, а поставщики берутся выполнить заявку и поставить товар в нужном количестве. Они же при отправке товара указывают состав паллет в фуре и всю необходимую информацию логистического характера.
    2. Когда машина уехала от поставщика к нам, мы уже знаем, какой товар к нам идёт; более того, с поставщиками налажен электронный документооборот, поэтому мы знаем, что УПД уже подписан. Готовится схема оптимального перемещения этого товара: если это кросс-докинг, то мы уже заказали транспорт со склада, рассчитывая на товар, а также для всех логистических потоков мы уже определили, какое количество складских ресурсов нам понадобится для обработки поставок. В деталях для кросс-докинга предварительный план по транспорту со склада делается на более раннем этапе, когда поставщик только зарезервировал слот на поставку в системе управления складскими воротами (YMS — yard management system), которая интегрирована с порталом поставщика. Информация приходит в YMS сразу.
    3. YMS получает номер грузовика (если быть точнее, то номер отгрузки из SWP) и записывает водителя на приёмку, то есть отводит ему необходимый слот времени. То есть теперь водителю, который приехал вовремя, не нужно ждать живой очереди, а под него отведены его законное время и док разгрузки. Это позволило нам, кроме всего прочего, оптимально распределять грузовики по территории и эффективнее использовать разгрузочные слоты. А ещё, поскольку мы заранее составляем график, кто, куда и когда приедет, то знаем, сколько людей и где нужно. То есть это ещё связано с рабочими графиками сотрудников склада.
    4. В итоге этой магии грузчики уже не нуждаются в дополнительной маршрутизации, а лишь ожидают машины для их разгрузки. Фактически их инструмент — терминал — говорит им, что делать и когда. На уровне абстракции это как API грузчика, но в human-computer interaction-модели. Момент сканирования первой паллеты с грузовика — это ещё запись метаданных по поставке.
    5. Разгрузка пока делается всё так же руками, но по каждой паллете грузчик проводит сканером штрихкодов и подтверждает, что данные этикетки в порядке. Система контролирует, чтобы это была правильная паллета, которую мы ожидаем. К концу разгрузки в системе будет точный пересчёт всех грузовых мест. На этой стадии ещё отсеивается брак: если есть явные повреждения транспортной тары, то достаточно просто отметить это в процессе разгрузки или вовсе не принять этот товар, если он совсем негодный.
    6. Раньше паллеты пересчитывались в зоне разгрузки после того, как все будут выгружены из машины. Сейчас уже процесс физической выгрузки является пересчётом. Брак мы возвращаем сразу же, если он очевидный. Если он неочевидный и обнаруживается потом, то мы накапливаем его в специальный буфер на складе. Гораздо быстрее прокинуть паллету дальше в процесс, собрать с десяток таких и дать возможность поставщику забрать всё сразу за один отдельный приезд. Некоторые виды брака переводятся в зону утилизации (это часто касается зарубежных поставщиков, которым проще получить фотографии и прислать новый товар, чем принимать его обратно через границу).
    7. В конце разгрузки подписываются документы, и водитель уезжает дальше по своим делам.

    В старом процессе паллеты перемещались зачастую в специальную буферную зону, где уже с ними работали: считали, регистрировали брак и так далее. Нужно было это для того, чтобы освободить док для следующей машины. Сейчас все процессы настроены так, что эта буферная зона просто не нужна. Есть выборочные пересчёты (один из примеров — процесс выборочного внутритарного пересчёта для кросс-докинга на складе, реализованный в проекте «Светофор»), но большая часть товара обрабатывается сразу по факту приёмки и именно из дока едет на оптимальное место на складе или сразу в другой док для погрузки, если транспорт на отгрузку со склада уже прибыл. Знаю, для вас это звучит немного обыденно, но пять лет назад на огромном складе возможность обработать поставку сразу на конечные точки вроде дока погрузки для другого грузовика — это нам казалось чем-то вроде космической программы.

    image

    Что дальше происходит с товаром?


    Дальше, если это не кросс-докинг (и товар уже не уехал в буфер перед отправкой или прямо в док), то его нужно положить в сток на хранение.

    Нужно определить, куда этот товар пойдёт, в какую ячейку хранения. В старом процессе нужно было зрительно определить, в какой зоне мы храним товары данного типа, и потом выбрать там место и отвезти, положить, записать, что положили. Сейчас у нас настроены маршруты размещения по каждому товару по топологии. Мы знаем, какой товар в какую зону и в какую ячейку должен попасть, знаем, сколько ячеек занять дополнительно рядом, если это негабарит. Человек подходит к паллете и сканирует её SSCC с помощью ТСД. Сканер показывает: «Вези в А101-0001-002». Дальше он везёт туда и отмечает, что положил, тыкая сканером в код на месте. Система проверяет, что всё правильно, и отмечает. Ничего писать не нужно.

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

    Итак, в системе сток обновляется в момент приёмки заказа. А запас ячейки — в момент постановки паллеты в неё. То есть мы всегда знаем, сколько товара есть на складе итого и где какой лежит конкретно.

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

    Обратные потоки брака тоже слегка оптимизированы: если товар на кросс-докинге, то поставщик может забрать его со склада в Москве. Если брак вскрылся уже после открытия транспортной упаковки (и снаружи это было непонятно, то есть он появился не по вине транспортников), то есть зоны возврата в каждом магазине. Брак можно забросить на федеральный склад, а можно отдавать поставщику прямо из магазина. Второе случается чаще.

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

    За пять лет мы сократили время приёмки товара (разгрузку машины) в четыре раза и ускорили ряд других процессов, что в общей сложности улучшило оборачиваемость кросс-докинга чуть больше, чем вдвое. Наша задача — оптимизация, чтобы снизить запас и не «замораживать» деньги на складе. И дали возможность магазинам получать нужный товар чуть более вовремя.

    По складским процессам большие улучшения заключались в том, чтобы автоматизировать то, что раньше было бумагой, избавиться от лишних этапов в процессе за счёт оборудования и правильно настроенных процессов и соединить все ИТ-системы компании в единое целое, чтобы заказ из ERP (например, в магазине чего-то не хватает на третьей полке слева) в конечном итоге превращался в конкретные действия в системе складского хранения, заказа транспорта и так далее. Сейчас оптимизация больше касается тех процессов, до которых мы ещё не добирались, и математики прогнозирования. То есть эпоха бурного внедрения закончилась, мы сделали те 30 % работы, которые дали 60 % результата, и дальше надо постепенно покрывать всё остальное. Либо двигаться на другие участки, если там можно сделать больше.

    Ну и если считать в спасённых деревьях, то переход поставщиков на EDI-порталы тоже очень много дал. Сейчас практически все поставщики не звонят и не общаются с менеджером, а сами в личном кабинете смотрят заказы, подтверждают их и везут товар. По возможности отказываемся от бумаги, с 2014 года уже 98 % поставщиков — на электронном документообороте. В общей сложности это сохранённые 3 000 деревьев за год только на отказе от распечатки всех нужных бумаг. Но это без учёта тепла от процессоров, но и без учёта сэкономленного рабочего времени людей вроде тех же менеджеров на телефоне.

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

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

    В прошлом году мы открыли крупнейший распределительный центр в Европе — 140 тыс. кв. м — и взялись за его механизацию. Об этом я расскажу в другой статье.
    Леруа Мерлен
    Ритейлер — технологическая компания платформа.

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

      0
      Круто. Но такой вопрос — как часто делается инвентаризация склада? Человек может ошибиться и палету положить на другое место. А далее ошибки будут только накапливаться. Или есть какая система автоматической инвентаризации? Например радиометки на палеты.
        +2
        Я не автор, но попробую ответить цитатой из статьи.
        Человек подходит к паллете и сканирует её SSCC с помощью ТСД. Сканер показывает: «Вези в А101-0001-002». Дальше он везёт туда и отмечает, что положил, тыкая сканером в код на месте. Система проверяет, что всё правильно, и отмечает. Ничего писать не нужно.


        В итоге, если ты положил не туда, система тебе сразу об этом скажет. А специально, целенаправленно класть паллету в одну ячейку, а потом идти к той, которую выдавала система, и пикать ее — это уже вредительство, и такое очень быстро вычисляется, и наказывается.
          +3
          Да, абсолютно верно, бывает такое, что человек может положить не туда, но:

          1. Если он сканирует адрес другой ячейки, то естественно, WMS система покажет ему ошибку и не даст системно установить паллету.

          2. Если человек просканировал адрес верной ячейки, но положил целенаправленно не туда, то да это проблема.

          Но для таких случаев, как вы и написали есть процесс инвентаризации. Если мы говорим про инвентаризацию хранящегося запаса стока на складе, то у нас проводится циклическая инвентаризация (каждый день мы считаем n-ое количество ячеек на складе), за квартал, как правило происходит полный просчет всех ячеек. Ну и раз в год существует фискальная инвентаризация, где мы отправляем в учетную систему весь складской запас. Раньше, когда у нас не было циклической инвентаризации нам приходилось останавливать операции на складах на 3-4 дня, для того, чтобы полностью его просчитать, теперь такого огромного количества времени не требуется.

          Также, проводили просчет нескольких ячеек в тестовом режиме дронами, но пока это не легло в основные инструменты.
            0
            А можно поподробней о подсчете дронами, очень интересно =)
          –3
          Автоматизация склада — это всё конечно хорошо, но уважаемый товарищ «копирайтер» — попробуйте воспользоваться вашим сайтом.
          Он реально неудобен.
          Доказательства?
          Найдите-ка мне быстренько трубу канализационную 110мм.

          К сожалению оставить свой вопрос в профильном посте habr.com/ru/company/leroy_merlin/blog/455710 я не успел, поэтому пишу здесь.
            +2
            Найдите-ка мне быстренько трубу канализационную 110мм.
            А в чём проблема? На сайте ищется просто (в топ-5 запрошенный товар я всегда нахожу), в магазине тоже.
              0
              [deleted]
                –2
                image
                  +2
                  В поиске вбито 2 первых слова из названия товара, при этом на 1 месте поиска внезапно счётчик воды! Это конечно нормально.

                  Поиск действительно странный.
                  Пример «утеплитель рулонный» на первой странице поиска вообще нет ни одного утеплителя в рулонах, есть напыляемый, есть листовой, есть клей для листового, потом идут подушки и одеяла.
                  Как ПОДУШКА попала в выдачу утеплителя?
              +1
              У меня к Вам два вопроса:
              1. как Вы заставили поставщиков, особенно, региональных перейти на EDI?
              2. Неудобно же с кольцом на пальце, да и травмоопасно может быть, тоже долго думали как улучшить, но так и остались на обычных ТСДах с клавиатурой. Хотя, в сторону очков посматриваем.
                +3
                1. В основном убеждениями.

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

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

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

                Преимущества:

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

                Недостатки:

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

                Если это кольцо без провода, то иногда шалит связь.

                На фотографии старая модель Зебры, она нам очень нравится, кольцо очень легкое, надевается на один палец, на практике не мешает сотрудникам. А вот новые беспроводные кольца (Bluetooth) от той же зебры немного тяжелые, особенно те которые, надеваются сразу на 2 пальца. Их мы тоже тестировали.
                  +1
                  Целая пачка вопросов :-)
                  Народ не жалуется на «увесистость» терминалов?
                  На какой ОС Зебра? Нет проблем с взаимодействием с WMS? Особенно восстановление рабочей сессии после сбоя связи?
                  Пришлось ли строить бесшовную (а следовательно и более дорогую) Wi-Fi?
                    0
                    Народ не жалуется на «увесистость» терминалов? — это зависит от модели, которую ты выберешь, в основном, нет. Коллеги не жаловались на это. «Увесистость» напрямую зависит от выбора модели терминала. Тот который у нас — весит 300 грамм и закреплен на предплечье.

                    На какой ОС Зебра? — старые модельки (на фото)- на винде, а вот когда мы покупаем новые модели, они уже идут на Android и настраиваются через Velocity.

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

                    Пришлось ли строить бесшовную (а следовательно и более дорогую) Wi-Fi? — да, именно такое требование мы предъявляли к БЛВС сети.
                      0
                      Классная стори, спасибо что делитесь опытом!
                      Софт вы сами писали для Зебры? WMS построена на какой платформе и софте?
                        0
                        А можно поподробней о подсчете дронами, очень интересно =)

                        Я, к сожалению, не смогу ответить. Мы только тестировали подобное использование дронов. У нас эта технология не прижилась и мы ее не используем. Лучше про нее могут рассказать поставщики этого оборудования.
                          0
                          1.Для Зебры мы не писали софт, он стандартный: Velocity для Android и Wavelink для Windows.
                          2. По WMS ОС — AS400.
                  0
                  А если на приехавшей паллете разные артикулы, и в вашей системе они должны в разных ячейках храниться?
                    0

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

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

                      Если это поток BBXD (логистический поток Break Bulk Cross Docking), и к нам приходит паллета для приемки с разными артикулами, то мы принимаем мульти SKU паллеты. В таком случае, можно принять мультиSKU паллету, так как она не пойдет в сток склада и WMS нам это также позволяет.
                        0
                        Для от поставщика, когда пикнул паллету, получил SSCC код. А как система по SSCC понимает место на складе? Откуда артикульный состав паллета берется? Поставщик предоставляет в электронном виде?

                        Для мульти-SKU как же вы обходитесь без буферной зоны? Где происходит рассортировка на монопаллеты, прямо у ворот?
                          0
                          Как я указал в посте, при отгрузке с портала поставщик указывает все необходимые логистические параметры состава отгрузки и, когда жмёт кнопочку отгрузить, информация с составом (в том числе кодом SSCC и его содержимым) передается к нам WMSинтерфейсным сообщением. Поэтому, к приезду машины WMS уже знает, что мы ожидаем. Лишние артикулы или SSCC, WMS не позволит принять.

                          Здесь нет ничего сложного, у нас количество ворот и доков приемки позволяет произвести подобную операцию непосредственно на доке (особенно на федеральных складах). А также, повторюсь, поток сток занимает относительно небольшой процент от общих поставок товара. В основном мы прогоняем через склад сквозные потоки.
                      0
                      Здесь интересно было бы послушать рассказ поставщиков товара и водителей которые привозят необходимое.
                        +1
                        Не знаю как у вас там все автоматизированно. Пример из Украины. Заказ товара в онлайн магазине. Указали доставку в поселок (бывает, что 2 поселка с одинаковым названием в одной области.) Вычислили нужный по названию улицы. Все равно отправили в другой. На звонки в службе поддержки, ни чем не могут помочь -«мы передадим информацию», «Вы не одни такие». Пока не нашли телефон одного из менеджера и не позвонили напрямую, реакции никакой. Куча негативных отзывов в инете на ваш магазин.
                          +1
                          Эффективно работать на складском комплексе без WMS можно лишь до определенного объема, условно, когда коммуникации можно разделить на 2-3 группы по 8-12 человек. Пока работают простые правила, берем там где много, складываем туда где обычно лежит, выполняем прямые указания оператора и система работает. С дальнейшим ростом можно пытаться разделять систему на изолированные части, но число ошибок неуклонно растет. Требования к квалификации комплектовшиков и водителей погрузчиков высокие. Нужен опыт работы именно на этом комплексе и знание номенклатуры. WMS система лишает свободы и требует порядка. Все должно быть на своих местах и в свое время. Комплектовщик становится лишь исполнителем. Система прямо диктует что и когда делать. Система знает все твои шаги и ошибки, буквально превращает людей в роботов. Не самое приятное чувство. Оттого, организации работающие без WMS при попытке автоматизации сталкиваются с серьезным противостоянием вплоть до саботажа. Как вы преодалевали споротивление персонала?
                            0
                            Спасибо за хороший вопрос! Чтобы на него полноценно ответить, необходимо развернуть немаленькую дискуссию. Если кратко, то:

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

                            Но у проектной команды есть возможность снизить градус болезненности перехода:

                            1. Это хорошее качество и системность обучения персонала с последующим экзаменационным тестированием сотрудников.
                            2. Подготовка понятных инструкций (и даже это не всегда спасает).
                            3. Круглосуточная поддержка проектной команды (на период запуска), в особенности консультантами системы, которые совмещают знания складских операций и техническую составляющую системы.
                            4. Ну и конечно, чего уж греха таить, прямое поручение руководства и работа непосредственно с персоналом. Саботаж вычисляется очень легко, когда у каждого сотрудника свой логин в системе и отлажена система логирования. Это хорошо работает, когда на складе свои операции (поясню: сотрудники компании производят складские операции).

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

                            Когда мы запускали WMS систему на первом нашем складе, операциями управлял 3PL оператор, и сложностей/споров было действительно много, потому как с внедрением WMS прозрачность процессов становится гораздо лучше для сотрудников компании и в каких то спорных вопросах у нас появляется аргументация. Но в последствии, все решалось поиском компромиссов и принятии адекватных решений. Если найденная проблема (не саботаж) 3PL операторами была действительно проблемой, то мы всегда рады перенять опыт и пойти на встречу.
                            0
                            1. г.Новосибирск ТЦ Мегас организуйте там круглосуточный прием товаров от поставщиков. Длиномеры поставщиков утром блокируют и без них узкую дорогу в ожидании открытия магазина, зимой вообще пробки образуются.
                            А то как-то жутко пафосный сказ получается как быстро принимаете товары, но при этом блокируете город.
                            2. Ваш дизайнер сайта наверно срок долго отбывал и жизнь в понятия перешла? Постоянно всплывающая кнопка «Понятно», уберите ее, нельзя так общаться с клиентом.
                              0
                              Не удержался — своё видение процесса автоматизации работы склада написал: nikitayev.livejournal.com/107414.html
                                0
                                Есть вопросы по WMS:
                                1. какую выбрали? Чем руководствовались при выборе?
                                2. каков штат поддержки и доработки WMS?
                                  0
                                  1. Выбрали WMS Generix. Подробно рассказать не смогу, это было очень давно, но в тендере было не меньше 4-ёх контрагентов, в том числе очень крупных. Одними из ключевых показателей были стоимость и скорость внедрения, а также возможность оперативного внедрения смежных систем логистики о того же контрагента на перспективу, что мы в последствии и сделали. По остальным преимуществам не подскажу.

                                  2. Штат поддержки WMS полностью определяют контрагенты на основании договоренностей по SLA, количесвту инцидентов, складских объемах, и т.д., которые у нас описаны в сервисном договоре. Мы же со своей стороны занимаемся функциональной поддержкой процессов по системе, на каждый склад у нас, как минимум 1 ключевой пользователь.

                                  3. Доработки системы WMS нам также производят контрагенты, но естественно, для реализации доработок/проектов у нас присутствует плотная совместная работа и четкие границы ответственности. Что касается штата: штат менялся в зависимости от наших потребностей и методологии работы. В одно время мы работали, придерживаясь принципов waterfall и тогда штат сотрудников у подрядчиков под нас не был фиксированный и был относительно небольшой (2-3 консультанта не full time- по запросу, для технического анализа и передачи в разработку (количеством разработчиков в этом случае управлял контрагент самостоятельно). В какой- то период объем задач/идей возрос до небес, и мы перестроили нашу работу отталкиваясь от принципов Agile: Scrum, тогда мы сформировали команду, состоящую из аналитиков (2-3) с нашей стороны, продакт менеджера, а также договорились с контрагентами выделить отдельную команду под нас, в которой находилось несколько консультантов, разработчиков).
                                  0
                                  Прекрасное достижение в качестве фундамента для дальнейшей оптимизации. Аплодирую стоя. Хотелось бы узнать подробнее о внедрении: как боролись с сопротивлением? В какие сроки внедрили полный цикл?
                                    0
                                    Про сопротивление подробно упоминал ранее.
                                    Сроки внедрения полного цикла у нас составили до года.
                                    0
                                    За пять лет у нас стало в четыре раза больше магазинов, в три раза больше различных документов, и, если бы не было EDI, у нас было бы в три раза больше бухгалтеров.

                                    А откуда такая прямая корреляция между наличием системы ЭДО и не увеличением штата бухгалтерии при увеличении количества документов, разве в системе ЭДО бухгалтерам проверять документы уже не надо?
                                      0
                                      Если смотреть с точки зрения нагрузки на бухгалтеров, то ЭДО дало возможность значительно сократить время на обработку документов на прием, за счёт автоматической передачи данных в систему, организации проверок в системе до начала приема и единого процесса подписания документов, оптимизация этих функций и параллельное развитие автоматизации внутри компании позволило не увеличивать бухгалтерский ресурс в магазинах.

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

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