В прошлом году к нам пришел дистрибутор расходников: склад около 1800 м², номенклатура - 7 тыс. SKU. Картина знакомая: в 1С остаток есть, палету ищут по звонкам и памяти смены, срочные отгрузки собирают вручную. Запрос был прямой - «ставим WMS», но я в таких случаях сначала смотрю на другое: складу действительно нужна система управления или просто еще один экран, который аккуратнее опишет тот же беспорядок.
Эта развилка обычно экономит больше, чем торг по лицензии. Если заранее понять, где заканчивается учет, который у вас уже есть, и начинается управление складом в реальном времени, многие лишние затраты отпадают сами.
Проблема начинается не на росте, а на потере управляемости
Склад редко ломается в тот день, когда выросла выручка. Обычно это происходит в момент, когда люди перестают понимать, где что лежит, кто чем занят и какой заказ сейчас важнее. Остатки в системе могут сходиться, но пользы от этого немного, если комплектовщик идет через весь склад за одной позицией, а подпитка держится на звонке старшему кладовщику.
На практике тревожный порог часто начинается с 300-500 заказов в день при ассортименте 5-10 тыс. SKU. Если товар ищут по памяти, а приоритеты меняются в чате, цена ошибки уже выше, чем базовая автоматизация с ТСД на Android, адресным хранением и обязательным сканированием.
Здесь полезно разделить три слоя:
- учет - что приняли, что отгрузили, какой остаток в системе
- исполнение - куда положить, откуда брать, кому выдать задание
- контроль - что именно отсканировали и на каком шаге возникла ошибка
1С и ERP обычно закрывают первый слой. Склад живет во втором и третьем.
WMS полезна там, где складу нужен диспетчер
Я не люблю продавать WMS как «богатый функционал». Ее ценность в другом: система выдает задания, задает маршрут, проверяет ячейку и товар, заранее создает подпитку и не дает закрыть операцию с пропуском шага. Это особенно заметно в e-commerce и дистрибуции, где есть волны отгрузки и много коротких заказов.
На одном проекте мы оставили 1С в учетном контуре, а сверху сделали слой исполнения. Стек был простой: PostgreSQL 16, Node.js 20 для обменов, сама WMS - коробочная, ТСД Zebra на Android. Запустили адреса, штрихкоды, обязательное сканирование, wave picking и batch picking для пиковых окон. Через 8 недель время сборки сократилось на 27%, точность остатков выросла с 94% до 98,7%.
| Что нужно складу | 1С / ERP | Точечная автоматизация | WMS |
|---|---|---|---|
| Учет остатков | Да | Частично | Да |
| Задания в реальном времени | Слабо | Частично | Да |
| Адресное хранение | Ограниченно | Да | Да |
| Работа с ТСД | Через доработки | Да | Да |
| Маршрут и приоритеты | Нет | Ограниченно | Да |
| Работа на пике | Средне | Средне | Высокая |
если заказ срочный -> приоритет 1
если SKU в зоне fast pick -> отбор из fast pick
если остаток ниже порога -> создать задание на подпитку
если товар маркируемый -> сканировать DataMatrix обязательно
Самая дорогая часть проекта - не лицензия, а слабые правила склада
Мы сами когда-то шли от системы и довольно быстро увидели, где ошиблись. Если до внедрения не описаны правила размещения, подпитки, отбора и приоритетов, автоматизация просто ускоряет плохой процесс.
Был проект у поставщика бытовой химии, где сначала доработали 1С, выдали сканеры и повесили экраны статусов. Через 2 месяца жалобы остались прежними: пересорт, ручные звонки по смене, срочные отгрузки в режиме пожара. Причина оказалась простой: адресного хранения не было, ходовые SKU лежали вперемешку с редкими, правила подпитки отсутствовали. Система работала исправно, склад - нет.
Частая ошибка - купить коробку и ждать, что она сама наведет порядок. Правильная последовательность другая: сначала за 1-2 недели собрать карту потоков, пики, профиль заказов и ABC/XYZ-анализ, потом запускать только те операции, где правила уже понятны.
Если 20% SKU дают до 80% движений, их надо переносить ближе к отбору и упаковке. Иначе комплектовщик просто начнет быстрее ходить по плохому маршруту.
Бюджет проекта считают целиком, а запуск - по этапам
Когда собственник спрашивает, сколько стоит WMS, я обычно уточняю: сколько складов, есть ли маркировка, сроки годности, маркетплейсы, EDI, серийный учет, сколько юрлиц участвует в обменах. На практике цену определяет не размер бизнеса, а сложность правил и интеграций.
Для склада среднего масштаба проект обычно выходит в 2,5-6 млн ₽. Сюда входят обследование, проектирование, интеграции с 1С, ТСД, принтеры этикеток, Wi‑Fi, обучение, опытный запуск и поддержка. Нередко обмены с 1С и маркировкой занимают больше времени, чем сама складская логика.
Можно ли начать без полной WMS?
Да, часто это разумнее. У нас были проекты, где сначала запускали приемку, размещение, сборку и контроль отгрузки, а остальное добавляли уже после стабилизации. Такой этап занимает 8-10 недель и дает понятный эффект без лишнего объема работ.
Когда коробки уже мало?
Когда исключений становится слишком много: разные типы отбора, сложная маркировка, нестандартные зоны, особые правила подпитки, несколько каналов продаж с разными SLA. В этом случае коробка обычно остается базой, а ценность дают точечные доработки.
Окупаемость лучше считать в рублях и часах
У нас был проект по NDA в B2B-дистрибуции автокомпонентов - 420 заказов в день, коробочная WMS и Laravel 11 на интеграционном слое. Собственник сначала хотел «полный функционал», но мы убрали половину пожеланий и оставили только ключевые операции. За 10 недель ошибки комплектации упали на 63%, сезонный найм сократился на 18%.
Смотреть стоит на простые показатели: сколько времени уходит на сборку заказа, сколько ошибок дает пересорт, сколько часов тратится на поиск и ручные уточнения, насколько сильно смена зависит от одного опытного человека. В этом и есть окупаемость, а не в ощущении, что интерфейс стал удобнее.
Если хотите быстро понять, пора ли вам в WMS, разберите не месяц, а один проблемный день отгрузки. Тот самый, где палета «временно стояла не там». Обычно именно в этом дне уже видны и бюджет проекта, и цена бездействия.
