Факторы успешного внедрения ТСД на складе: насколько важен первичный выбор и как сохранить гибкость

5.11.2026

Статья о том, почему при внедрении ТСД на складе важнее гибкость, чем первичный выбор конкретной модели. Рассматриваются поэтапное внедрение по процессам, аппаратная независимость, офлайн-режим, пересмотр старых процессов и типичные ошибки. Приводится классификация складов и обзор решения «Склад 15».

Поэтапное внедрение ТСД на действующем складе

Зачем складу ТСД и почему нельзя внедрять всё сразу

Внедрение терминалов сбора данных (ТСД) автоматизирует складские и торговые операции, снижает влияние человеческого фактора и ускоряет работу персонала в 2–3 раза. Но цель внедрения шире, чем просто «поставить сканеры»: навести порядок на складе, повысить точность и прозрачность учёта. И здесь возникает ключевой вопрос — менять всё сразу или двигаться по процессам и отделам.

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

Почему «всё сразу» не работает

Резкий запуск ТСД по всем процессам создаёт три группы рисков, которые накладываются друг на друга.

Саботаж персонала. Люди сталкиваются с путаницей, скорость работы падает до нуля, и появляются требования вернуть бумагу. Если сотрудник не освоил устройство на простой операции, на сложной он тем более не будет ему доверять.
Технические сбои. Wi-Fi не добивает до дальних зон, зависает документ обмена в 1С, рвётся цепочка передачи данных. Когда автоматизировано всё, каждый сбой останавливает склад целиком.
Потеря контроля. При массовом внедрении непонятно, где именно возникла ошибка — в софте или у кладовщика. Диагностика превращается в угадывание.

Главное правило: внедрять по одному процессу. Запустили приёмку — дайте 1–2 недели поработать только на ней, затем подключайте адресное размещение, потом отгрузку.

Переходный период — это нормально

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

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

Мобильная автоматизация склада

Узнать больше

Классификация складов: какой подход к внедрению выбрать

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

Склады селлеров маркетплейсов (FBS/FBO)

Для этой категории характерна экстремально высокая скорость операций и жёсткие штрафы со стороны Wildberries, Ozon и Яндекс Маркета. Поток мелких заказов огромен, сборка ведётся поштучно, а этикетку маркетплейса нужно печатать мгновенно под конкретный заказ. Дополнительно требуется контроль сроков годности или кодов Честного Знака.

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

Фулфилменты и 3PL-операторы

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

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

Классические оптовые компании (дистрибьюторы, B2B)

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

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

Производственные склады (сырьё и готовая продукция)

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

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

Сводная таблица по категориям складов

Категория	Болевая точка	С чего начинать	Скорость внедрения
Селлеры маркетплейсов	Скорость сборки и штрафы за пересорт	Сборка и комплектация	Очень быстрая (дни/недели)
Фулфилмент / 3PL	Хаос в чужих товарах, биллинг	Тестовый клиент с полным циклом	Средняя, поэтапно по клиентам
Оптовые компании	Пересорт на входе, долгий поиск товара	Приёмка → адресное хранение → отгрузка	Плавная (месяцы)
Производство	Потеря остатков между цехом и складом	Выход готовой продукции с конвейера	Поэтапная по контурам

Гибкость вместо привязки к железу: как выбрать софт и оборудование

Жёсткая привязка складского ПО к конкретной модели терминала сбора данных (ТСД) — это стратегический риск, а не техническая деталь. Модель могут снять с производства, бренд — уйти с рынка из-за санкций, партия оборудования — застрять на таможне. В любом из этих случаев склад остаётся с софтом, который не на чем запустить. Поэтому зрелый подход сегодня — аппаратная независимость (Hardware Agnostic): программное обеспечение выбирается отдельно от железа, а железо — под конкретные задачи склада.

Почему одной модели ТСД недостаточно

Разные складские операции предъявляют разные требования к устройству. Для приёмки крупногабаритного товара нужен тяжёлый ТСД пистолетного типа с дальнобойным 2D-сканером — им удобно считывать штрихкоды на верхних ярусах стеллажей или на палетах, не слезая с погрузчика. Для комплектации мелких заказов в e-commerce лучше подходят носимые терминалы на предплечье со сканером-кольцом на пальце или лёгкие компактные ТСД формата «защищённый смартфон». В морозильной камере необходимо устройство с подогревом экрана и клавиатуры. Кроме того, реальные характеристики надёжности — ресурс курков, поведение аккумуляторов, достаточность яркости экрана — проявляются только через полгода-год жёсткой эксплуатации. Ставка на единственную модель лишает склад манёвра при изменении задач или условий поставок.

Архитектура: логика на сервере, терминал как умный монитор

Ключевой принцип аппаратной независимости — перенос бизнес-логики с ТСД на сервер. На самом терминале не должно быть уникальной логики и баз данных: он работает как «умный монитор со сканером». Вся бизнес-логика выполняется на сервере — в товароучётной системе (например, 1С) или в специализированном складском софте («Клеверенс», Mobile SMARTS). Приложение на ТСД лишь отображает задание («Иди в ячейку А-5») и ждёт штрихкод: сканирование отправляется на сервер, сервер определяет следующий шаг. В результате складу безразлично, какое устройство используется — Android-смартфон, ТСД за 20 тысяч или за 150 тысяч рублей.

Для этого софт должен быть кроссплатформенным (Middleware): нельзя писать мобильное приложение под конкретную модель, нужно брать промышленное решение с поддержкой сотен устройств из коробки. Android стал фактическим стандартом — 99% рынка ТСД работает на нём, а Windows CE/Mobile уходит в прошлое; софт под Android 10–13+ запустится на любом китайском, российском или американском терминале. Профессиональные продукты (Клеверенс) интегрируются со встроенными сканирующими модулями Zebra, Honeywell, Newland, SEIKO на уровне ОС: при смене бренда ТСД достаточно выбрать в настройках профиль нового устройства.

Матрица оборудования под задачи склада

Зона / задача	Рекомендуемый формат устройства
Приёмка, крупногабаритный товар	Тяжёлый ТСД с рукояткой пистолетного типа и дальнобойным 2D-сканером
Комплектация мелких заказов, e-commerce	Носимый терминал на предплечье со сканером-кольцом или лёгкий компактный ТСД
Экспресс-задачи, подработчики в высокий сезон	Личные Android-смартфоны с тем же рабочим приложением и сканированием через камеру

Сканирование камерой смартфона современные алгоритмы выполняют достойно, хотя и чуть медленнее лазера. Это делает реальным привлечение временного персонала без закупки дополнительного парка ТСД.

Автономная работа и два режима эксплуатации

Полное покрытие Wi-Fi на складе — дорогая и часто недостижимая задача: сигнал не проходит через железобетонные конструкции, между высокими стеллажами с металлом или жидкостями, а сместившаяся палета может оборвать связь. Поэтому софту необходима гибридная архитектура с локальным кэшированием: логика остаётся на сервере, но ТСД не обращается к нему за каждым «пиком». В зоне Wi-Fi терминал скачивает конкретный документ («Задание на приёмку №123») и справочник только по этой приёмке, а в глухом офлайне хранит задачу в локальной базе данных Android-приложения, сканирует и проверяет по заданию, выдавая ошибку при несоответствии. Вернувшись в зону связи (или вставив устройство в крэдл, подключив по проводу), сотрудник нажатием кнопки отправляет документ на сервер, и 1С обновляет остатки. Гибкость при этом сохраняется: локальную базу и логику проверки обрабатывает мобильное приложение, которому безразлично, на каком Android-устройстве оно запущено.

Отсюда вытекают два режима работы ТСД:

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

Практические рекомендации

В техническое задание к софту стоит закладывать гибридный режим — Mobile SMARTS от «Клеверенс» умеют его из коробки. Следует отказаться от решений, работающих только через веб-браузер ТСД (RDP, 1С-Web-клиент): они умирают при малейшем разрыве связи. Полезно выбирать ТСД со слотами для SIM-карт (4G) на случай падения Wi-Fi или долгой настройки в дальних углах — китайские производители Urovo, Chainway, iWaylink ставят 4G-модули почти во все стандартные модели. Начинать же разумно с «пакетного» процесса: запустить приёмку в чистом офлайне и протестировать софт на разных ТСД, не думая о качестве Wi-Fi. Для проверки выбрать софт «на вырост» с поддержкой динамического изменения экранов — чтобы менять кнопки и поля в мобильном приложении без программирования под конкретное железо, — и купить на тест 2–3 принципиально разных терминала от разных китайских и российских брендов (Urovo, Newland, ATOL, M3 Mobile), настроив на них один и тот же процесс приёмки: это покажет, насколько легко софт «сел» на разные устройства и какое из них удобнее людям.

Пересмотр процессов, типичные ошибки и следующие шаги

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

Что переписать под цифровую логику

От «памяти кладовщика» — к топологии склада. На бумаге допустима формулировка «синие коробки лежат где-то в дальнем левом углу за трубой». ТСД требует чёткой координаты: Зона — Ряд — Стеллаж — Ярус — Ячейка. Система не выдаст задание без указания места, поэтому процесс «иди найди» скопировать невозможно — его приходится заменять адресным хранением.

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

От «накладных» — к «заданиям». На бумаге менеджер выписывает накладную под клиента, и кладовщик собирает заказ от начала до конца. С ТСД задачи делятся оптимально: десять мелких заказов объединяются в одно задание на сборку (волновое пикирование), кладовщик за один проход собирает 50 единиц для разных клиентов, а софт подсказывает, в какую ячейку и в какую коробку на тележке положить каждую штуку. Экономия — в километрах пробега. Если скопировать бумажный процесс, кладовщик будет бегать за каждым мелким заказом отдельно.

Перед внедрением необходимо привести в порядок три вещи. Во-первых, стандартизировать единицы измерения: товар приходит в палетах, хранится в коробках, отгружается в штуках — в системе должны быть коэффициенты пересчёта и штрихкоды для каждого типа упаковки, а ТСД должен понимать, что сканирование палеты — это +100 штук. Во-вторых, узаконить правила работы с браком и излишками: на бумаге дописывали карандашом «пришло 11 вместо 10, одна помятая», для ТСД нужен цифровой бизнес-процесс — блокировать ввод или разрешать приёмку сверх заказа, бракованный товар направлять на виртуальный склад «Зона брака». В-третьих, оптимизировать маршруты: ходовые позиции (А-класс по АВС-анализу) размещаются ближе к зоне отгрузки, ТСД ведёт по самому короткому пути без возвратов в один и тот же проход.

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

Частые ошибки внедрения

Помимо «автоматизации бардака» и привязки к бренду железа, практика выделяет пять типичных провалов.

Штрихкодовый хаос. В базе 1С у половины товаров нет ШК, у другой половины один ШК привязан к разным цветам и размерам (пересорт в базе), поставщики присылают товар с замятыми или глянцевыми бликующими наклейками. Кладовщик пикает — «Товар не найден», откладывает ТСД и берёт бумагу. Правильно: до покупки ТСД провести аудит базы, обязать поставщиков маркировать по вашим правилам или организовать зону оклейки и перемаркировки на входе (принтер этикеток на приёмке).

Забытый фактор ИТ-инфраструктуры. Запуск ТСД на старом «уставшем» сервере 1С, покупка софта без учёта нагрузки: десять ТСД одновременно проводят тяжёлые документы — сервер падает. Экран «думает» по 10–15 секунд перед каждым действием, и терминал начинает раздражать людей. Правильно: ИТ-специалист заранее замеряет скорость отклика базы данных; возможно, потребуется поднять отдельную промежуточную базу для ТСД или настроить веб-сервер (IIS/Apache) для быстрой отдачи пакетов данных.

Отсутствие контроля свободного ввода. В настройках софта остаётся возможность вводить количество вручную с клавиатуры без фактического сканирования каждой единицы. Кладовщик видит палету, сканирует одну коробку и нажимает «х50» — пересорт и недостача остаются, просто занесены через дорогой терминал. Правильно: на этапе внедрения запретить свободный ввод количества для критичных процессов — хочешь принять 10 штук, пикни 10 раз (исключение — монопалеты от проверенных поставщиков с агрегированным ШК).

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

Саботаж персонала и отсутствие «кнута и пряника». Кладовщики воспринимают ТСД как «цифровой ошейник», лишающий возможности скрыть косяки или работать «как привыкли». Выдать ТСД со словами «теперь работаем так» и уйти, не изменив систему мотивации и не назначив ответственного, — значит получить намеренно «потерянную» связь, разряженные батареи и заявления, что «программа всё путает», лишь бы вернуться к бумажным накладным. Правильно: найти среди кладовщиков самого лояльного или сообразительного, обучить первым и сделать «лидером мнений»; перевязать KPI и зарплату к данным из ТСД — например, сборка по бумаге больше не засчитывается в премию, а за скорость и точность сборки по ТСД начисляется бонус.

Как выглядит готовое решение на примере «Склад 15»

Продукт «Склад 15» от Клеверенс — популярное готовое ПО для ТСД, создававшееся под гибкость, независимость от железа, работу в офлайне и защиту от ошибок. Решение поддерживает более 1000 моделей ТСД из коробки (Zebra/Honeywell, Urovo, Chainway, Newland, АТОЛ): при снятии модели с производства или санкционных ограничениях можно купить любой другой Android-терминал, установить приложение — и оно работает так же.

Гибридный режим (умный офлайн) устроен следующим образом: документ скачивается в память ТСД, работа идёт в железобетонном подвале или дальнем углу ангара без Wi-Fi, пикание и проверка выполняются по локальной базе мгновенно, а выгрузка в 1С происходит автоматически при возвращении в зону Wi-Fi или при вставке в крэдл. Готовая логика процессов закрывает ключевые точки контроля: приёмка отслеживает пересорт и не даёт принять то, чего нет в заказе поставщика; сборка строит оптимальный маршрут; ручной ввод отключается одной галочкой. Интеграция с 1С (УТ, УНФ, ERP, Комплексная автоматизация, 7.7) выполняется через готовую обработку и обмен пакетами, что минимизирует нагрузку на сервер. Настройка в расширенных версиях ведётся визуальным редактором без программирования, изменения вносятся на стороне сервера, а экраны на всех ТСД обновляются автоматически.

Есть и подводный камень: лицензирование привязано к конкретному ТСД (серийному номеру или ID). Пять лицензий жёстко закреплены за пятью терминалами; при поломке лицензию можно перенести через техподдержку, но «поделиться» с телефоном подработчика на день без специальной плавающей лицензии (которая дороже) не получится.

Следующие шаги

Последовательность действий при внедрении выглядит так:

определить тип склада и болевую точку;
выбрать первый процесс для внедрения (обычно приёмка);
провести аудит базы штрихкодов;
проверить ИТ-инфраструктуру — сервер 1С и Wi-Fi;
выбрать гибкий софт с поддержкой офлайн-режима и разных устройств;
протестировать 2–3 модели ТСД;
пересмотреть процессы под цифровую логику;
заложить аксессуары и запасные аккумуляторы;
продумать мотивацию персонала.

Часто задаваемые вопросы

Можно ли внедрять ТСД поэтапно, по отдельным процессам, а не сразу на всём складе?

Да, и для действующего склада это единственный рабочий способ. Ситуация «приёмка по ТСД, отгрузка по бумаге» — нормальный переходный период: вы уже исключаете ошибки на входе, а остатки в учётной системе становятся точными. Резкий запуск «всё и сразу» грозит саботажем персонала, техническими сбоями и остановкой отгрузок. Запустили приёмку — дайте 1–2 недели на автоматизм, затем подключайте адресное хранение, инвентаризацию и только потом сборку/отгрузку.

С чего начинать внедрение на складе — с приёмки или со сборки заказов?

Зависит от типа склада. Классический оптовый склад идёт по цепочке: приёмка → адресное хранение → инвентаризация → отгрузка. Селлерам маркетплейсов (FBS/FBO) часто важнее сразу закрыть сборку и отгрузку — там штрафы за пересорт и возвраты бьют по рейтингу. Фулфилменты обкатывают полный цикл на одном тестовом клиенте, производственные склады начинают с выпуска готовой продукции из цеха. Общее правило одно: сначала наводите порядок на «болевой точке», а не там, где проще.

Насколько важно, какую именно модель ТСД выбрать на старте?

Модель вторична — первична гибкость архитектуры. Любое конкретное устройство может уйти с рынка, сменить комплектацию или разочаровать после года жёсткой эксплуатации. Поэтому бизнес-логика должна жить на сервере (в 1С или складском софте), а ТСД — работать как «умный монитор со сканером». Тогда вы покупаете разные устройства под разные операции: пистолетный ТСД с дальнобойным сканером для приёмки палет, носимый терминал со сканером-кольцом для комплектации, обычный Android-смартфон для временных сотрудников в высокий сезон.

Как обеспечить работу ТСД при плохом Wi-Fi на складе?

Через гибридный режим: документ (задание) скачивается в память ТСД в зоне уверенного приёма, сотрудник работает в полном офлайне — терминал проверяет штрихкоды по локальной базе, — а результат выгружается при возврате в зону связи или через крэдл. Пакетный режим подходит для приёмки, инвентаризации и сборки крупных заказов; онлайн/полуонлайн нужен там, где важна динамика (адресное хранение, сборка под маркетплейсы). Решения, работающие только через веб-клиент или RDP, при разрыве связи отказывают — их сразу исключайте. Дополнительно стоит брать ТСД со слотом SIM (4G) как резервный канал.

Нужно ли пересматривать процессы или можно просто перенести бумажные в ТСД?

Переносить бумажную логику в терминал — типовая и дорогая ошибка: получится «автоматизированный бардак». ТСД требует адресного хранения (координаты вместо «где-то за трубой»), переносит контроль в момент сканирования (отдельный контролёр отгрузки часто становится не нужен) и позволяет объединять заказы в волновую сборку вместо беготни за каждым заказом отдельно. Пересматривать процессы нужно прагматично — по принципу минимально необходимой перестройки, а не строить «склад будущего» на бумаге.

Какие ошибки чаще всего проваливают внедрение ТСД?

Пять критичных: штрихкодовый хаос (у части товаров нет ШК, один код привязан к разным цветам/размерам); недооценка ИТ-инфраструктуры (слабый сервер 1С, терминал «думает» по 10–15 секунд); свободный ручной ввод количества (кладовщик сканирует одну коробку и ставит «х50»); экономия на аксессуарах (нет ремешков, кобур, запасных аккумуляторов — терминалы бьются и разряжаются в смену); саботаж персонала без изменения мотивации (KPI и премия должны быть привязаны к данным из ТСД, а среди кладовщиков нужен «лидер мнений»).