WMS для склада: что это, как работает и когда нужна

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

WMS — система управления складом, которая связывает места хранения, задания сотрудникам и фактическое выполнение складских операций. Название расшифровывается как Warehouse Management System; в русской записи встречается «ВМС». Она помогает организовать путь товара от приёмки до отгрузки, но результат зависит от правил работы и качества исходных данных. Если склад перемещает товар без подтверждения, одна установка программы этого не исправит.

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

Система управления складом WMS нужна там, где важно управлять исполнением операций: определить место для товара, выдать задание на перемещение или отбор, получить подтверждение и зафиксировать результат. Это класс систем, а не название одной программы. Набор функций и способы работы зависят от конкретного продукта и настройки.

Например, в официальном описании «1С:WMS Логистика. Управление складом» выделено управление складской грузообработкой. В описании возможностей решения перечислены приёмка, размещение, перемещение, отбор, отгрузка и пересчёт. В этом решении сотрудники работают с задачами через терминалы сбора данных — ТСД, а диспетчер контролирует исполнение и разбирает нестандартные ситуации.

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

Дальше будем рассматривать именно этот сценарий как модель требуемого процесса, а не инструкцию к определённой WMS. Конкретные документы, статусы и порядок подтверждения нужно проверить при выборе продукта.

Перед запуском системе нужны однозначные данные о товаре и складе. Номенклатура отвечает на вопрос «что это», упаковка — «в каких единицах принимаем и отбираем», партия — «какую именно поставку или группу товара учитываем». Зона описывает участок работы, а ячейка — конкретное место внутри склада. Адресное хранение связывает товар с таким местом, чтобы его можно было найти и проверить.

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

В таблице ниже — требования к нашему условному процессу. На начало товара нет, других поступлений и отгрузок за время примера не происходит. Все количества показаны в штуках; адреса А-01 и Б-01 условные.

В таблице показано физическое наличие. Доступное количество для других заказов нужно считать отдельно с учётом резервов: уже выделенные покупателю 24 штуки нельзя одновременно обещать ещё одному заказу.

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

В «1С:WMS» предусмотрены настраиваемые стратегии размещения и задачи пересчёта; адресный учёт может учитывать упаковки, партии и другие свойства товара. Это возможности конкретного решения, описанные в каталоге 1С. Для своего склада нужно проверить именно нужный набор: например, допустимо ли смешивать партии в ячейке, когда пополнять зону отбора и кто принимает решение при недостаче.

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

Основания для предметного сравнения появляются, когда:

Это диагностические признаки, а не обещание, что WMS устранит их автоматически. В каждом случае нужно назвать причину: не настроено адресное хранение, неверно заведены упаковки, отсутствует подтверждение перемещения или текущая система действительно не поддерживает требуемый порядок работы.

Адресное хранение само по себе не требует отдельной WMS. В публикации Руслана Шарипова о плавном переходе с УПП на ERP описан конкретный проект, где для запуска адресного хранения выбрали складской контур ERP, а отдельную WMS сочли нецелесообразной. Это пример решения в определённых условиях, а не рекомендация заменить любую WMS на ERP.

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

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

Если отдельная WMS выбрана, можно спроектировать такую схему: заказ и согласованная потребность поступают из основного контура, WMS организует складские задания, затем возвращает подтверждённый результат. Похожее разделение операционной работы и передачи документов в учётную систему приведено в статье о плавном переходе. Это принцип архитектуры; состав обмена для своего проекта нужно определить отдельно.

Для нашего заказа на 24 фильтра важно договориться о четырёх вещах:

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

Формулировка «нужна современная WMS» не помогает сравнивать предложения. Полезнее записать сбой, требуемое поведение и способ проверки. Тогда демонстрация системы превращается в проверку вашей работы, а не в просмотр удобных для поставщика экранов.

Какие варианты WMS сравнивать. Сначала разделите способ размещения и состав решения. Локальные, облачные и встроенные в ERP варианты встречаются, например, в обзоре производителя SAP. Это не взаимоисключающие признаки: связь с ERP и место размещения отвечают на разные вопросы.

Так сравниваются конкретные условия работы, а не условные названия «видов WMS». После этого каждый вариант можно проверить на одних и тех же требованиях.

Начните с шести требований, адаптировав их к своему складу:

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

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

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

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

Для нашего условного примера результат можно проверить без сложного отчёта: приняли 120, отгрузили 24, осталось 96. Но одной этой арифметики недостаточно. По завершении прогона нужно подтвердить:

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

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

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