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

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

Когда бизнесу необходимо кастомное ПО для ТСД

Производители терминалов сбора данных (Zebra, Honeywell, Datalogic, Urovo и другие) поставляют устройства с предустановленным базовым ПО. В ряде случаев этого достаточно — например, для простейших операций сканирования штрихкодов с последующей выгрузкой данных. Однако реальные бизнес-процессы значительно сложнее, и стандартное ПО начинает буксовать уже на этапе масштабирования.

Рассмотрим типичные ситуации, в которых компании принимают решение о разработке собственного программного обеспечения для терминалов сбора данных:

• Нестандартные бизнес-процессы. Если ваша компания работает с уникальной номенклатурой, использует специфические схемы хранения или имеет нестандартный документооборот, стандартное ПО не сможет это учесть. Например, фармацевтические дистрибьюторы в Беларуси и России обязаны работать с системой маркировки «Честный знак», что требует специализированной поддержки на уровне ТСД.
• Глубокая интеграция с учётной системой. Простая выгрузка файлов — это вчерашний день. Современный бизнес требует онлайн-обмена данными с 1С, SAP, или другими ERP-системами в реальном времени. Без кастомного ПО реализовать это корректно невозможно.
• Работа в офлайн-режиме. Склады с плохим покрытием Wi-Fi, уличные инвентаризации, работа в металлических ангарах — во всех этих сценариях ПО должно корректно работать без подключения к сети, накапливая данные и синхронизируя их при восстановлении связи.
• Сложная логика обработки данных. Когда терминал должен не просто сканировать штрихкод, а выполнять проверки, принимать решения на основе заданных правил, отображать справочную информацию о товаре, формировать задания для сотрудника — это уже задача для кастомного ПО.
• Мультиплатформенность. Если в компании используются ТСД на разных операционных системах (Android, Windows CE/Embedded Handheld), единое приложение с общей логикой значительно упрощает поддержку и обучение персонала.
• Требования законодательства. В Беларуси и России действуют специфические требования к электронному документообороту, маркировке товаров, работе с ЕГАИС и другим системам. Кастомное ПО позволяет учесть все нормативные требования.

По нашему опыту работы с компаниями в Минске, Москве, Гомеле, Бресте, Витебске и других городах, примерно в 60–70% случаев для среднего и крупного бизнеса кастомная разработка ПО для ТСД окупается в течение первого года эксплуатации за счёт снижения трудозатрат и минимизации ошибок учёта.

Этапы разработки ПО для ТСД

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

Этап 1. Аудит бизнес-процессов и сбор требований

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

В рамках аудита выполняются следующие работы:

1. Интервьюирование ключевых пользователей. Это кладовщики, операторы, руководители складов, ИТ-специалисты. Каждый из них видит процесс со своей стороны, и важно собрать полную картину.
2. Анализ текущего ПО и оборудования. Какие ТСД используются? Какая версия ОС? Какое ПО установлено? Какие интеграции настроены? Есть ли известные проблемы?
3. Обследование инфраструктуры. Покрытие Wi-Fi на складе, расположение серверов, пропускная способность сети, наличие серверов 1С и ERP.
4. Анализ документооборота. Какие документы формируются в процессе работы? Как они передаются в учётную систему? Какие проверки выполняются?
5. Выявление «узких мест». Где сотрудники теряют больше всего времени? Где чаще всего возникают ошибки? Какие операции выполняются вручную, хотя могли бы быть автоматизированы?

Результатом этапа является отчёт с описанием текущего состояния, выявленных проблем и рекомендаций. На основе этого отчёта принимается решение о целесообразности разработки и формируется высокоуровневое видение будущего решения. Срок проведения аудита — от 1 до 3 недель в зависимости от масштаба бизнеса.

Этап 2. Формирование технического задания (ТЗ)

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

Структура ТЗ на разработку ПО для ТСД обычно включает:

• Описание целевой платформы (Android, Windows CE, обе платформы)
• Перечень функциональных модулей (приёмка, размещение, инвентаризация, отбор, отгрузка и т.д.)
• Описание бизнес-логики каждого модуля с учётом специфики предприятия
• Требования к интеграции с учётной системой (протоколы, форматы данных, режим обмена)
• Требования к работе в офлайн-режиме и механизму синхронизации
• Требования к интерфейсу пользователя (UX/UI) с учётом условий эксплуатации
• Требования к безопасности и разграничению прав доступа
• Требования к производительности и отказоустойчивости
• Требования к оборудованию (модели ТСД, типы сканеров, принтеров этикеток)

На формирование полного ТЗ обычно уходит от 2 до 4 недель. Этот этап включает согласование с заказчиком, прототипирование ключевых экранов и утверждение архитектурных решений.

Этап 3. Разработка

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

Разработка включает несколько параллельных направлений:

• Серверная часть. Мiddleware-слой, который обеспечивает обмен данными между ТСД и учётной системой. Это может быть веб-сервис, REST API или отдельное серверное приложение.
• Клиентское приложение для ТСД. Основное приложение, которое работает непосредственно на терминале. Реализует пользовательский интерфейс, бизнес-логику, локальное хранение данных и обмен с сервером.
• Модуль интеграции. Компонент, отвечающий за взаимодействие с 1С или ERP-системой. Формирует документы, запрашивает справочные данные, обрабатывает ответы.
• Административная панель. Веб-интерфейс для управления настройками, мониторинга состояния устройств, просмотра логов и статистики.

Разработка ведётся итерациями (спринтами) длительностью 2–3 недели. По итогам каждого спринта заказчику демонстрируется промежуточный результат, что позволяет оперативно вносить корректировки. Общая длительность этапа разработки — от 2 до 6 месяцев в зависимости от объёма функционала.

Этап 4. Тестирование

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

Программа тестирования включает:

• Функциональное тестирование. Проверка каждого сценария работы в соответствии с ТЗ. Все ли операции выполняются корректно? Правильно ли обрабатываются граничные случаи?
• Тестирование интеграции. Проверка обмена данными с учётной системой. Корректность формирования документов, обработка ошибок связи, целостность данных.
• Тестирование офлайн-режима. Имитация потери связи, проверка корректности накопления данных и последующей синхронизации. Тестирование конфликтных ситуаций (когда один и тот же товар был изменён на ТСД и в учётной системе).
• Тестирование на различных моделях ТСД. ПО должно корректно работать на всех моделях терминалов, которые используются в компании.
• Нагрузочное тестирование. Как ведёт себя система при одновременной работе десятков или сотен терминалов? Выдерживает ли сервер нагрузку?
• Юзабилити-тестирование. Оценка удобства интерфейса реальными пользователями — кладовщиками и операторами. Это критически важно, поскольку интерфейс ТСД должен быть максимально простым и понятным.

На тестирование обычно закладывается 2–4 недели. Для крупных проектов с высокими требованиями к надёжности этот этап может быть длиннее.

Этап 5. Внедрение и запуск в эксплуатацию

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

Мы рекомендуем использовать поэтапное внедрение:

1. Пилотная зона. ПО развёртывается на ограниченном количестве ТСД (5–10 устройств) в рамках одного склада или одного бизнес-процесса. Это позволяет выявить проблемы в реальных условиях без риска остановки всего бизнеса.
2. Расширение. После успешного пилота ПО развёртывается на всех устройствах. Параллельно может вестись работа по старому ПО для страховки.
3. Полный переход. После подтверждения стабильности работы компания полностью переходит на новое ПО. Старое ПО выводится из эксплуатации.
4. Стабилизация. В течение 2–4 недель после полного перехода наша команда обеспечивает усиленную поддержку: оперативное исправление выявленных проблем, дополнительное обучение персонала, тонкая настройка параметров.

Технологический стек: Android и Windows CE

Выбор платформы для разработки ПО для ТСД — одно из ключевых архитектурных решений. На сегодняшний день доминируют две операционные системы: Android и Windows CE (включая варианты Windows Embedded Handheld и Windows Mobile). Каждая из них имеет свои преимущества и ограничения.

Android — современный стандарт

Android является основной платформой для новых терминалов сбора данных. Большинство производителей (Zebra, Honeywell, Urovo, Datalogic) выпускают устройства на Android версий от 7 до 13. Преимущества Android для разработки ПО очевидны:

• Современная среда разработки (Android Studio, Kotlin, Java)
• Богатая экосистема библиотек и инструментов
• Поддержка Material Design и современных UI-компонентов
• Встроенные механизмы работы с сетью, базами данных, камерой
• Регулярные обновления безопасности (для устройств с Android 8+)
• Поддержка корпоративных функций через Android Enterprise
• Возможность использования Xamarin, Flutter, React Native для кросс-платформенной разработки

Для разработки на Android мы используем преимущественно Kotlin как основной язык программирования. Для работы с данными — Room (локальная база данных), Retrofit (HTTP-клиент), Coroutines (асинхронные операции). Архитектура приложения строится по паттерну MVVM с использованием Android Architecture Components.

Windows CE — проверенная классика

Несмотря на то что Microsoft прекратила поддержку Windows CE (последнее обновление было выпущено в 2013 году), огромное количество устройств на этой платформе продолжает эксплуатироваться. В Беларуси и России многие компании до сих пор используют ТСД на Windows CE — это устройства серий Motorola MC9090, MC9200, Honeywell Dolphin 6000 и другие.

Разработка для Windows CE ведётся с использованием:

• Compact Framework (.NET CF 3.5) — основная платформа разработки
• C# — основной язык программирования
• Visual Studio 2008 — единственная поддерживаемая среда разработки
• SQL Server Compact — встраиваемая база данных
• Web Services / WCF — для интеграции с серверной частью

Кросс-платформенная разработка

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

Для кросс-платформенной разработки мы рассматриваем следующие технологии:

• Flutter — позволяет создавать приложения для Android с единой кодовой базой. Поддержка Windows CE невозможна, но для Android-устройств это отличный выбор.
• Xamarin / .NET MAUI — позволяет использовать C# и .NET для разработки мобильных приложений. Исторически имела лучшую поддержку устаревших платформ.
• React Native — подходит для Android-устройств, обеспечивает быструю разработку и лёгкую поддержку.

Интеграция ТСД с 1С и ERP-системами

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

В Беларуси и России абсолютное большинство компаний используют 1С:Предприятие в качестве основной учётной системы. Наиболее распространённые конфигурации: «1С:Управление торговлей», «1С:ERP Управление предприятием», «1С:Комплексная автоматизация», «1С:Бухгалтерия». Каждая конфигурация имеет свои особенности в плане документооборота и структуры данных.

Архитектура интеграции

Существует несколько подходов к организации обмена данными между ТСД и 1С:

• Прямой обмен через COM-соединение. Устаревший подход, при котором мобильное приложение напрямую обращается к базе 1С через COM-объект. Работает только в локальной сети, имеет ограничения по производительности и безопасности. Применяется преимущественно с Windows CE-устройствами.
• Обмен через промежуточный сервер (middleware). Наиболее современный и рекомендуемый подход. Мобильное приложение обменивается данными с промежуточным сервером (REST API или веб-сервис), который, в свою очередь, взаимодействует с 1С. Это обеспечивает гибкость, масштабируемость и безопасность.
• Обмен через XML/JSON-файлы. Простой, но ограниченный подход. ТСД формирует файлы с данными, которые затем загружаются в 1С. Подходит для небольших объёмов данных и простых сценариев.
• Обмен через веб-сервисы 1С. 1С предоставляет данные через собственные веб-сервисы, а мобильное приложение обращается к ним напрямую. Требует публикации базы 1С на веб-сервере.

Мы в iOFFiCE отдаём предпочтение архитектуре с промежуточным сервером. Это позволяет:

• Обеспечить работу ТСД в офлайн-режиме с последующей синхронизацией
• Снизить нагрузку на сервер 1С
• Реализовать сложную логику обработки данных на стороне сервера
• Обеспечить безопасность (1С не выставляется «наружу»)
• Легко масштабировать систему при увеличении количества ТСД

Подробнее о нюансах интеграции ТСД с различными конфигурациями 1С вы можете узнать в нашем отдельном руководстве: Интеграция ТСД с 1С: полное руководство.

Типовые документы для интеграции

При разработке ПО для ТСД с интеграцией в 1С необходимо обеспечить корректное формирование следующих типов документов:

Интеграция с ERP-системами

Для крупных предприятий, использующих SAP, Oracle ERP, Microsoft Dynamics или другие корпоративные системы, интеграция ТСД строится по аналогичным принципам, но с использованием специфических протоколов и интерфейсов. SAP, например, предоставляет специализированный модуль SAP EWM (Extended Warehouse Management) с собственными протоколами взаимодействия с мобильными устройствами. Интеграция с SAP обычно требует участия специалистов, знакомых с архитектурой SAP и протоколами RFC/BAPI.

Оценка стоимости и сроки разработки

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

Факторы, влияющие на стоимость

• Количество бизнес-процессов. Приложение только для инвентаризации стоит значительно дешевле, чем комплексное решение для всех складских операций.
• Количество платформ. Разработка для Android и Windows CE одновременно увеличивает бюджет на 40–60% по сравнению с одной платформой.
• Сложность интеграции. Простой обмен файлами — это одно, а полноценная интеграция с 1С через промежуточный сервер с поддержкой офлайн-режима — совсем другое.
• Количество одновременно работающих ТСД. 10 устройств или 200 — разница в требованиях к серверной инфраструктуре и нагрузочному тестированию.
• Требования к интерфейсу. Стандартный интерфейс на основе системных компонентов или кастомный дизайн с анимациями и адаптивной вёрсткой.
• Необходимость серверной инфраструктуры. Требуется ли выделенный сервер, облачная инфраструктура, настройка балансировщиков?

Ориентировочные бюджеты

Как оптимизировать бюджет

Если бюджет ограничен, вот несколько стратегий, которые помогут снизить стоимость без критической потери качества:

1. Начните с MVP. Разработайте минимально жизнеспособный продукт для одного-двух ключевых процессов. Запустите его в эксплуатацию, соберите обратную связь и постепенно расширяйте функционал.
2. Используйте одну платформу. Если возможно, переведите все ТСД на Android. Это значительно упрощает разработку и поддержку.
3. Упростите интеграцию. На первом этапе можно использовать обмен файлами вместо полноценного middleware. Это не идеально, но работает.
4. Стандартизируйте процессы. Чем больше исключений и особых случаев в ваших бизнес-процессах, тем дороже разработка. Иногда дешевле адаптировать процессы под типовое решение, чем адаптировать решение под процессы.

Также рекомендуем ознакомиться с типичными ошибками при выборе и внедрении ТСД, которые могут существенно увеличить бюджет: 10 ошибок при выборе и внедрении ТСД.

Типичные ошибки при разработке ПО для ТСД

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

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