Мария Ханова, руководитель по запуску производственных объектов Ozon, объясняет, почему система управления складом (WMS) за последние годы стала ключевой частью логистической инфраструктуры и какие ошибки чаще всего возникают при её внедрении. В статье — о том, из-за чего проекты WMS сталкиваются с проблемами и как бизнесу их избежать.
Система управления складом, или WMS (Warehouse Management System), за последние годы превратилась из вспомогательной программы в основу операционной платформы бизнеса. Руководители запускают проекты, рассчитывают ускорить приёмку, размещение, сборку и отгрузку, обещают выйти на стабильную работу за один-два месяца и быстро повысить точность остатков.
Но всё чаще сценарий выглядит иначе. По оценкам вендоров, внедряющих системы WMS, до 70% проектов сталкиваются с серьёзными проблемами: сроки сдвигаются, бюджет растёт, команда вносит доработки уже после запуска. Вместо нескольких недель стабилизации склад выходит на устойчивый режим за два-четыре месяца, а иногда и дольше. Сотрудники сканируют товар, задания формируются, процессы идут, но показатели точности и производительности не достигают плановых значений.
Проблема не в том, что система не работает. Проблема в том, что бизнес недооценивает масштаб изменений.
Рынок изменился быстрее, чем архитектура складов
К концу 2025 года доля электронной торговли в российской рознице приблизилась к 20 процентам. Это означает взрывной рост мелкоштучных заказов и возвратов. Если раньше склад отгружал паллетами, то теперь он собирает тысячи заказов по одной-две позиции. В одежде, электронике и косметике возвраты достигают 25–30%.
Каждый возврат сотрудники принимают, проверяют, переводят в новый статус, иногда переупаковывают и снова ставят на учёт. Количество операций растёт кратно. WMS должна фиксировать каждое движение на уровне единицы товара, а не только партии. Если архитектура системы изначально не рассчитана на такой уровень детализации, она начинает «захлёбываться».
Поэтому, чтобы не «захлебнуться» на запуске, заранее посчитайте будущую нагрузку (поштучные отборы, возвраты, перемещения) и проверьте, что WMS и модель данных рассчитаны на этот уровень детализации с запасом.
Логика операций против логики учёта
На старте внедрения команды часто описывают последовательность действий: как принять товар, как собрать заказ, как отгрузить. Но они не всегда формализуют правила учёта. Они не закрепляют, что считается единицей хранения, как меняется статус товара, какие ограничения действуют на остатки.
В результате система знает, как выполнять операцию, но не понимает, что именно она учитывает. Например, часть товара хранится коробками, часть — поштучно. Если в модели данных не прописать коэффициенты пересчёта и правила перехода между уровнями, программа покажет один остаток, а фактически сотрудники найдут другой. Расхождения накапливаются, и бизнес начинает терять доверие к цифрам.
Чтобы остатки не «расходились», до настройки системы письменно зафиксируйте учётную модель: единицы хранения, статусы, правила пересчёта и кто имеет право менять эти правила.
Интеграции множатся, понимание исчезает
Современный склад взаимодействует не только с WMS. Он обменивается данными с:
- ERP (Enterprise Resource Planning — системой учёта ресурсов предприятия),
- OMS (Order Management System — системой управления заказами),
- TMS (Transportation Management System — системой управления перевозками),
- BI (Business Intelligence — системой аналитики),
- WCS (Warehouse Control System — системой управления оборудованием),
- оператором маркировки через EDI (Electronic Data Interchange — электронный обмен данными).
Бывает, что каждая система начинает жить на своей копии данных (остатка/статуса/карточки товара), и эти копии расходятся.
Даже если в компании формально есть «главная» система, её роль нужно закрепить по типам данных: где мастерятся остатки, где — статусы, где — карточки товара и кто имеет право их менять.
Иначе одна будет показывать сто единиц товара, другая — девяносто пять. Тогда сотрудники начинают вручную корректировать остатки, сверять таблицы, пересылать отчёты. Ручное вмешательство растёт: правки делаются под давлением времени, часто — вне регламентов и встроенных проверок системы, а результаты нужно повторно переносить между контурами. Поэтому ошибки не только возникают чаще, но и быстрее «разъезжаются» по всем связанным системам.
Чтобы не жить в бесконечных сверках, назначьте мастер‑систему по каждому типу данных (остатки, статусы, карточки товара) и заранее опишите правила синхронизации и разрешения конфликтов.
Слабое звено — данные
Отдельная зона риска — справочники товаров. Даже 1-3% ошибочных карточек создают серьёзную нагрузку. При пятидесяти тысячах позиций это до полутора тысяч записей с неверной упаковкой, коэффициентом пересчёта или сроком годности.
В первые недели до половины инцидентов связаны именно с такими неточностями. Один неверный коэффициент приводит к десяткам неправильных операций, и система начинает воспроизводить ошибку автоматически. Компания тратит время не на развитие, а на исправление.
Введите «входной контроль» справочников до запуска: валидации, выборочную инвентаризацию и запрет на загрузку карточек без ключевых полей.
Маркировка усиливает давление
Обязательная маркировка делает каждый экземпляр товара отдельной учётной единицей: у каждой упаковки появляется уникальный код, который нужно принять, переместить, отобрать и отгрузить уже не «коробкой», а поштучно. Это означает больше сканирований и больше событий учёта на каждом шаге движения товара.
Если WMS изначально не проектировали под поштучный учёт, разработчики начинают внедрять временные решения. Они добавляют дополнительные записи, обходные схемы, вспомогательные объекты. Склад замедляет работу, сотрудники чаще вмешиваются вручную, а производительность падает.
Чтобы маркировка не превратилась в «костыли», проектируйте поштучный контур сразу: хранение/перемещения/отгрузку с учётом уникального кода на каждой единице.
Организационный фактор бьёт сильнее технологий
Если руководство не пересматривает показатели эффективности и не закрепляет обязательное использование системы, часть работников продолжает работать по старым привычкам. Они записывают данные на бумаге, передают задания устно или через чаты. Формально WMS запущена, но фактически склад живёт в двух реальностях. Раздвоенность быстро разрушает эффект автоматизации.
Даже технически готовая система не спасает проект, если компания не меняет операционную дисциплину: работа ведётся только через WMS, операции подтверждаются сканированием/статусами, а исключения разбираются по регламенту — без параллельного «учёта в тетради».
Подсчитано, что в первые недели после запуска производительность часто снижается на 10–25%. Сотрудники привыкают к терминалам, осваивают новые правила, учатся фиксировать каждое движение.
Чтобы склад не жил в двух реальностях, закрепите правило: операция считается выполненной только после подтверждения в WMS, и под это правило настройте KPI, контроль и разбор исключений.
Что выбрать: готовое решение или собственная разработка
Выбор между готовым продуктом и собственной разработкой влияет на сроки и бюджет. Готовую систему компания обычно внедряет за три-шесть месяцев. Поставщик уже протестировал её на других проектах и обеспечивает поддержку. Однако при серьёзных изменениях процессов доработки могут оказаться сложными и затратными.
Собственную систему компания создаёт 6-12 месяцев, формирует команду специалистов и вкладывает больше средств на старте. Зато она легче адаптирует программу под уникальные процессы. Окупаемость у готовых решений обычно наступает через 2-4 года, у собственных — через 3-5 лет, поскольку первоначальные инвестиции выше.
IT-специалисты Ozon Tech самостоятельно разработали WMS для логистических объектов маркетплейса в собственной робототехнической лаборатории в Иннополисе. Система координирует и оптимизирует складские процессы: инвентаризацию, учет поступлений и отгрузок товаров, планирование маршрутов перемещения внутри склада, а также управление складскими работниками и автоматизированным оборудованием.
Это помогло сократить ручную обработку данных и упростить инвентарные процедуры — экономия достигает 20–30% рабочей силы в административных и логистических подразделениях склада.
Похожие решения развивают и другие маркетплейсы. Например, Wildberries и «Яндекс Маркет» также внедряют собственные системы управления складом для обработки десятков миллионов заказов в день. Последний, например, параллельно с разработкой WMS проектирует другие системы в «Яндекс Роботикс». Для управления и синхронизации роботов у компании есть отдельная система RMS.
В условиях, когда маркетплейсы ежедневно выполняют десятки миллионов складских операций, собственные WMS-системы становятся ключевым элементом инфраструктуры: они управляют перемещением товаров, распределением задач между сотрудниками и роботизированным оборудованием, а также позволяют масштабировать логистику без пропорционального роста штата.
Когда проект требует срочного пересмотра
Если стабилизация длится больше трёх месяцев, если точность остатков не превышает 97%, если доля ручных корректировок превышает 3–5% операций, если учёт маркировки или контроль качества ведут вне системы, значит заложенная логика не совпадает с реальной работой склада.
В такой ситуации компания должна пересмотреть модель данных, очистить справочники, уточнить статусы и ограничения, усилить контроль дисциплины и повторно протестировать ключевые сценарии.
Автоматизация как зрелость управления
К 2026 году WMS стала показателем зрелости управления. Система не исправляет хаосом — она его масштабирует. Если бизнес заранее не формализует правила учёта, не синхронизирует данные и не обучает персонал, программа лишь ускоряет распространение ошибок.
Автоматизация склада сегодня требует не только технологии, но и управленческой дисциплины. Компании, которые понимают это на старте, получают рост точности и скорости. Компании, которые недооценивают масштаб изменений, получают затянувшийся проект и растущие издержки.
