В большинстве складов (более 80%), на которых внедрены WMS, в основном Системы используют в очень ограниченном функционале, сопоставимом с возможностями учетных систем, при этом затраты на приобретение и внедрение были существенно большими. В основном функционал Систем, внедренных у этой доли предприятий, сводится к следующему: учетные функции по приходу и отгрузкам, документационное сопровождение указанных операций, поддержка адресной системы хранения и максимум — поддержка штрихового кодирования на операциях размещения и комплектации. И это все.

При этом такие оптимизационные функции WMS, как:

• автоматическое планирование и распределение ресурсов (персонала, ПТО, технологических участков и пр.);

• слоттинг;

• автоматическое распределение поступившей продукции по местам хранения в соответствии с заданными стратегиями или правилами;

• автоматическое формирование и использование результатов АВС-, XYZ-, DEF-аналитик;

• «волновая» или комплексная система комплектации;

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

• а также другие функции не используются.

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

Вместе с тем с появлением требований регуляторов, связанных с развитием логистических процессов (например, требований к маркировке продукции), изменением требований бизнеса по развитию e-commerce каналов, работе с торговыми сетями, полноценное внедрение системы управления складом или хотя бы учетной системы стало абсолютной необходимостью. Сложность процессов возрастает, появляются обязательные операции, учитывать и контролировать их при помощи «амбарных книг» становится все более и более затратно, а цена ошибки слишком высока, чтобы полагаться на «ответственного сотрудника». Если 5–7 лет назад о WMS компании задумывались на этапе масштабирования, то сейчас это стало такой же неотъемлемой частью бюджета логистики, как,например, покупка стеллажного оборудования.

Различие между системой управления складом (WMS) и учетными системами регламентируется соответствующим ГОСТом, при этом на уровне логики их вполне можно отличить по следующим определениям:

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

Система помощи/ассистирования (WAS, Warehouse Assistance System) — выдает сотруднику полезную информацию, на основании которой он самостоятельно принимает решения и регистрирует в системе производимые со своей стороны действия;

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

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

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

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

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

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

Однако конкретный сотрудник не способен оценить весь комплекс событий и параметров, влияющих на ход каждого складского процесса, поэтому после формализации алгоритма Ивана Михайловича надо провести его реинжиниринг и показать, как именно система управления складом сможет комплексно улучшить этот процесс, и в каких конкретно частях (собственно, это и есть вариант «как будет» — «to be»). Если не иметь зафиксированного процесса «как есть» («as is») — не с чем будет сравнивать «как будет» (прошедший реинжиниринг процесс), а если не с чем сравнивать — результат можно будет определить только через имитационное моделирование (что позволит не проводить опытов на работающем складе), либо непосредственно попробовав запустить систему на складе, что по возможным потерям может многократно превышать сумму всех вложений в проект внедрения.

Теперь давайте обратим свое пристальное внимание на понятие «процесс», или «бизнес-процесс». Как мы с вами понимаем, просто прийти на склад и «автоматизировать» его не получится. Кстати, такой абстрактный подход получил большое развитие в начале 2000-х годов, когда качество автоматизации в большей мере зависело от конкретного сотрудника компании, внедряющей WMS, и способности заказчика точно описать желаемый результат, нежели чем от системного подхода и контролируемого, понятного всем сторонам, плана действий. Давайте сразу определимся, что существует всего 2 базовых подхода к автоматизации:

• Системный подход — когда мы описываем наше текущее состояние, затем проектируем и описываем целевое состояние, и лишь после этого формируем план: как перейти от текущего к целевому состоянию;

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

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

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

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