Склад на 5 000 паллет: WMS по подписке за терминал против своей системы

MAATRIX

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

Почему тариф "за терминал" бьёт по кошельку именно на складе

Модель тарификации по терминалам логична с точки зрения поставщика услуги: чем больше устройств одновременно подключено к его облаку, тем больше нагрузки на его инфраструктуру, тем выше цена. Для офисного ПО это работает предсказуемо — число рабочих мест меняется редко. На складе всё иначе: количество одновременно работающих ТСД плавает в разы в течение одного дня.

Утром, пока идёт приёмка одной-двух фур, терминалов занято немного — приёмщик, кладовщик на размещении. К обеду, когда параллельно идёт отбор заказов на отгрузку, подключаются сборщики с ТСД на каждой тележке, водители погрузчиков с планшетами на борту, контролёр на упаковке. В пересчёте на склад такого масштаба (условно, 5 000 паллет-мест — не маленькая подсобка, а объект с несколькими зонами и постоянным потоком) число одновременно активных терминалов в пиковую смену заметно выше, чем в среднем за день. Проблема тарифа "за терминал" в том, что платить приходится по пиковому потреблению, даже если оно держится пару часов в сутки, а не по среднему.

Похожая логика тарификации "по подписке за рабочее место" встречается и в других отраслях — например, в CRM для автосервиса счёт растёт вместе с числом мастеров-приёмщиков точно так же, как на складе он растёт вместе с числом терминалов.

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

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

Как выглядит счёт по подписке на конкретном масштабе

Возьмём для примера склад на 5 000 паллет-мест — это ориентир из заголовка, иллюстрация масштаба, а не измеренная величина. На объекте такого размера обычно есть зона приёмки, зона хранения, зона комплектации (пикинга) и зона отгрузки, и в разгар смены на этих зонах параллельно работает не один десяток человек с терминалами.

Если тариф считается "за одновременно подключённый терминал", счёт за месяц складывается фактически из пиковой нагрузки, помноженной на цену лицензии, независимо от того, что вне пика половина терминалов простаивает. Дальше к базовому тарифу почти всегда добавляются платные модули — интеграция с учётной системой (тем же 1С), API для сайта или маркетплейса, отчётность сверх базового набора, иногда отдельная плата за хранение истории операций дольше определённого срока. Каждый такой модуль по отдельности выглядит некритично, а вместе ощутимо увеличивает итоговую сумму по сравнению с тем, что казалось "базовым тарифом" при подписании договора.

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

Что значит "своя WMS-система" технически

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

Здесь два реалистичных пути. Первый — взять готовую систему с открытым кодом, которая умеет складской учёт (управление ячейками, приёмку, отбор по заданию, штрихкодирование), и развернуть её на своём сервере. Второй, который на складах в России встречается чаще, — конфигурация склада в 1С (например, "1С:Управление складом" или складской контур в "1С:ERP") на собственном сервере, а не в облачной аренде. Для компании, у которой учётная система и так на 1С, это логичный путь: не нужно городить интеграцию между двумя системами, склад и остальной учёт живут в одной базе.

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

Сеть терминалов и сервер: что нужно на площадке

Терминалы сбора данных работают по Wi-Fi, и на складе такого размера сеть — не менее важный элемент, чем сам сервер. Несколько практических моментов, которые обычно всплывают при переходе на собственную систему:

• Покрытие без слепых зон. Металлические стеллажи и паллеты с товаром экранируют сигнал сильнее, чем кажется на бумаге. На складах с высокими стеллажными рядами точки доступа ставят с шагом, который перекрывает соседние ряды, а не рассчитывают на одну точку в центре зала.
• Роуминг между точками доступа. Кладовщик с ТСД перемещается по складу непрерывно, и разрыв сессии при переключении между точками доступа означает подвисшее задание. Точки доступа одного производителя с поддержкой быстрого роуминга (802.11r) снимают эту проблему заметно лучше, чем разнородный набор бытовых роутеров.
• Отдельный VLAN для складского Wi-Fi. Терминалы, гостевой Wi-Fi офиса и остальная сеть компании — разные сегменты: это и вопрос безопасности, и вопрос предсказуемой задержки.
• Сервер физически на площадке или рядом. Если сервер в серверной того же здания, задержка между терминалом и сервером — единицы миллисекунд. Если используется арендованный сервер в дата-центре, локальную сеть терминалов подключают к нему через VPN-туннель (например, WireGuard) — это даёт постоянное защищённое соединение без публичных адресов у самого сервера учёта.

Если склад зависит от связи с удалённым сервером, а не с локальным, обрыв единственного провайдера останавливает отгрузки — резервный канал через 4G-модем с автопереключением здесь не роскошь, а часть базовой отказоустойчивости.

База данных, резервные копии и что будет, если сервер откажет

Остатки на складе — это данные, потерю которых нельзя компенсировать звонком в поддержку. Если база данных WMS повреждена или сервер вышел из строя без резервной копии, склад не знает, что и где лежит, пока пересчёт вручную не восстановит картину — а это дни простоя на объекте с несколькими тысячами паллето-мест.

Практический минимум для собственной системы:

1. Регулярные резервные копии базы данных — для PostgreSQL или MS SQL (если система построена на 1С) это настраиваемая задача, которая выгружает дамп базы по расписанию, обычно несколько раз в сутки, с учётом интенсивности операций на складе.

Подробный разбор самой процедуры — какие инструменты использовать и как настроить расписание — см. в статье про резервное копирование баз данных.

1. Копии вне сервера. Резервная копия, которая лежит на том же диске, что и рабочая база, не спасает при отказе диска или сервера целиком — копии должны уезжать на отдельное хранилище, в идеале географически в другом месте.
2. Проверка восстановления. Бэкап, который никогда не разворачивали тестово, не бэкап, а предположение. Раз в квартал имеет смысл реально поднять копию на тестовом сервере и убедиться, что база открывается и данные консистентны.
3. План на отказ сервера. Здесь работает та же логика, что и для любой критичной инфраструктуры: либо резервный сервер, на который можно быстро переключиться, либо снапшоты виртуальной машины у арендодателя, которые разворачиваются за минуты, а не часы. Если база строится на PostgreSQL, а не на 1С, пошаговая установка и настройка описана в статье про развёртывание PostgreSQL на Ubuntu 24.04.

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

Миграция с подписки на свою систему без остановки склада

Переход не делается одним днём — склад не может встать на "техническое окно" на неделю. Рабочая последовательность, снижающая риск простоя:

1. Разворачиваете сервер и тестовую копию системы параллельно с работающей подпиской. На этом этапе ничего не переключается, вы просто проверяете, что сервер справляется с нагрузкой и терминалы к нему подключаются.
2. Переносите справочники — товары, ячейки, контрагентов, единицы измерения. Это самая объёмная, но механическая часть: структура склада (зоны, ряды, ячейки) должна быть описана в новой системе так же, как в старой, иначе адреса хранения не совпадут.
3. Синхронизируете текущие остатки на дату "Х". Здесь важно выбрать момент с минимальным движением товара — например, ночь или выходной, — провести контрольный пересчёт по ключевым позициям и зафиксировать остатки в новой системе.
4. Переключаете часть терминалов на новую систему, оставляя остальные на старой на короткий переходный период. Это позволяет проверить процессы отбора и приёмки в бою на ограниченном участке, прежде чем переводить весь персонал.
5. Обучаете персонал на реальных операциях, а не на демо-стенде — интерфейс новой системы может отличаться расположением кнопок и порядком сканирования, и кладовщики привыкают быстрее на своих привычных задачах.
6. Отключаете подписку только после того, как новая система отработала полный цикл — приёмку, размещение, отбор, отгрузку, инвентаризацию — без критичных сбоев хотя бы одну-две недели.

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

Экономика: фиксированная цена сервера против растущей платы за терминал

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

Если сравнивать не абстрактно, а по структуре затрат:

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

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

Частые вопросы