ТСД для «МойСклад» как мы сократили сборку заказов с 1 дня до 7 минут и заставили 1С работать в реальном времени
Проблема
- Сборщики работали по распечатанным листам. Это породило частые ошибки выбора — неверные SKU попадали в отгрузки, приходилось делать возвраты и разбирательства.
- Маркировка ЧестныйЗнак сканировалась отдельно — уже после сборки, отдельным сотрудником, только перед передачей клиенту. Это добавляло этап и задержку.
- Проблемы с расположением товара: фактическое количество в ячейке чаще всего не совпадало с данными в МойСклад — из-за неправильной укладки и перекладываний.
- Ручное заполнение всех полей в МойСклад (смена статусов, назначение ответственных) тормозило последующую бизнес-логику.
- Никакой прозрачности по работе склада: KPI считались через печатные формы в МС — это мешало оптимизации персонала и распределению задач.
Почему не взяли готовое решение?
Когда к нам пришли с запросом автоматизации склада, первый логичный вопрос звучал так: «А разве на рынке нет готовых ТСД-решений?» Конечно, есть. Существуют коробочные продукты, модули к МС и тд.
Мы изучили несколько вариантов. И вот к каким выводам пришли.
1. Гибкость против шаблона
Большинство готовых решений работают по типовой логике, но наш процесс отличался большим количеством нюансов.
Коробочные решения либо:
- не поддерживали такую глубину интеграции,
- либо требовали серьёзной доработки (по сути — переписывания половины системы).
В итоге мы поняли, что будем либо подстраивать бизнес под программу, либо писать бесконечные запросы на доработку. Нам это не подходило.
2. Скорость изменений
Склад — живой организм.
Сегодня меняется схема ячеек, завтра — логика комплектовки, послезавтра — требования к маркировке.
В готовом продукте любые изменения — это:
- тикет в поддержку,
- ожидание ответа,
- дополнительная оплата,
- релиз по графику вендора.
Когда система своя, изменение бизнес-логики — это управляемый процесс. Мы могли внедрять улучшения за дни, а не за месяцы. Это оказалось критично в первые месяцы запуска, когда процессы «шлифовались».
Цель проекта
- Убрать бумагу и ручной ввод.
- Сделать сборки быстрыми и простыми.
- Оптимизировать процесс доставки товара от поставщика к покупателю.
- Ввести прозрачные KPI по сборщикам.
Что было сделано
1. Нативное приложение для ТСД (Android - терминал).
2. Интеграция с API МойСклад: получение отгрузок на сборку, комплектация заказов, корректировка остатков, печать ячеек.
3. Отправка маркировок в 1С (после завершения сборки отгрузки).
4. Система подсчёта KPI: время от «взять отгрузку» до «отгрузка завершена», кол-во пиков, товаров, отгрузок.
5. Панель оператора с мониторингом в реальном времени.
Как работает приложение ТСД на практике
Чтобы было понятнее — опишу обычный рабочий день сборщика.
1. Сотрудник заходит в систему

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

Сборщик видит, где лежит товар и сколько нужно собрать
Сотрудник нажимает «Начать сборку».
На экране появляется список позиций с указанием количества и ячейки хранения.
Теперь вместо того чтобы искать товар глазами, он видит конкретное место хранения. Это уже сокращает время хождения по складу.
---
3. Сканирование товара
Сотрудник подходит к ячейке и сканирует товар.
Если это маркированная продукция, система сразу проверяет код маркировки.

Если всё корректно — позиция закрывается.
Если сканируется не тот товар — система сразу предупреждает.
Это ключевой момент: ошибка ловится сразу, а не после отгрузки клиенту.
---
4. Автоматическая синхронизация
После завершения сборки:
- заказ автоматически меняет статус в МойСклад,
- марки передаются в 1С,
- фиксируется ответственный сотрудник,
- рассчитывается время выполнения.

После закрытия данные сразу уходят в МойСклад
---
5. Контроль руководителя
Руководитель в любой момент может открыть статистику сборки сотрудника и увидеть:
- сколько отгрузок собрано,
- Кол-во пиков на ТСД,
- среднее время сборки

«Мониторинг работы склада в реальном времени»
---
Как мы добились 7 минут вместо 1 дня
- Устранение ручных шагов: нет необходимости бежать до принтера, печатать палетки (наклейки на коробки), после завершения сборки программа сама отправляет файл на принтер.
- Параллелизм: задания распределяются между сборщиками автоматически.
- Мгновенная проверка: система не даёт собрать неправильную позицию (валидность марки/количество) — это экономит время на возвратах и исправлениях.
- Статистика сотрудника мотивирует оператора работать быстрее и аккуратнее.
Результаты
- Раньше среднее время сборки одного заказа доходило почти до рабочего дня: проверка содержимого, отдельное сканирование маркировки, комплектация, ручные изменения в учёте — всё это растягивало процесс. При объёме около 4 000 отгрузок в месяц (примерно 130+ заказов ежедневно) склад работал на пределе, и клиентам приходилось обозначать срок отгрузки в один-два дня.
- После внедрения ТСД процесс стал короче и последовательнее. Сборка и фиксация данных происходят одновременно, без дополнительных этапов и ожиданий. В результате время обработки заказа сократилось до нескольких минут, а большинство отгрузок выполняются в день оформления или на следующий рабочий день, если заказ поступил вечером.
- При этом удалось сократить количество задействованных сотрудников на операциях сборки и обработки — нагрузка перераспределилась, а часть рутинных действий просто исчезла из процесса.
- Процент ошибок по позициям: упал с ~6–8% до <1.5% (в первые месяцы после релиза).
- Количество возвратов/ошибочных отгрузок резко снизилось (на 70–80%).
Сложности которые встретили
- Маркировка разного формата: GS1, DataMatrix, QR — потребовалось долгое тестирование и работа с клиентом.
- Интеграция с 1С: у клиента 1С настроена по-своему; сделали двустороннюю связь между сервисами.
- Сопротивление персонала: Решили через пилотную зону и обучение.
Лучшие практики, которые я бы рекомендовал
- Стартовать с пилота на 1–2 сборщика, собрать фидбек и адаптировать UX.
- Логировать всё: каждый скан и каждое нажатие в дальнейшем повод для разбирательств.
- План по миграции персонала: обучающие сессии + небольшая мотивация от руководителя.
Заключение
Если честно, в какой-то момент стало понятно: проблема не в людях и не в скорости их работы. Проблема была в количестве лишних действий вокруг самой сборки. Бумага, повторное сканирование, ручная смена статусов, перенос данных в учёт — всё это съедало часы.
В итоге процесс стал короче сам по себе. Не потому что кто-то начал бегать быстрее, а потому что исчезли задержки между этапами. Там, где раньше заказ мог жить целый день — переходить из рук в руки и ждать, пока его отразят в системе, — теперь всё закрывается за несколько минут.