Внедрение WMS: проектирование

Определение задачи

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

Далее - к решению сменить WMS привели вполне конкретные практические проблемы.

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

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

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

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

• Чего мы стремимся достичь?
• Чего мы хотим избежать?
• Что мы стремимся поддержать и сохранить?
• Что мы стремимся устранить?

При этом важно все время помнить, что решаются конкретные практические задачи.

Примерами задач могут быть:

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

Задачами не могут быть:

внедрить зону комплектации, внедрить приемку с ТСД, внедрить волновую сборку, внедрить управление двором и т. д.

Плохо мыслить рекламными картинками, и пытаться обязательно как-то использовать все,

что умеет система. Это не нужно и более того – вредно.

Все вышесказанное очевидно? Это так. Но, как показывает практика, именно такие простые и очевидные вещи часто остаются за кадром.

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

Меняете конфигурацию зон? Ок.

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

Кстати, у консультантов «Корус-консалтинг» в методологии на эту тему есть стадии прототипирования и тестирования с возвратом в проектирование в случае неудовлетворительного результата. Подробнее на эту тему будет в посте про «управление проектом».

Проиллюстрируем на примере из практики

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

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

Однако при запуске это изменение чуть не привело к тому, что отгрузка встала.

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

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

Управление сложностью

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

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

Почему-то стремление к излишнему усложнению – достаточно частое явление среди менеджеров.