Мы свяжемся с Вами и ответим на Ваши вопросы об RPA, нашей платформе и практике ее применения
Логистика — одна из самых чувствительных к ИТ-сбоям отраслей. По данным Monq Digital Lab, в IV квартале 2024 года количество сбоев ПО в логистике выросло на 28% по сравнению с аналогичным периодом 2023 года. На отрасль пришлось 14% всех зарегистрированных инцидентов — больше только в ритейле и финансовом секторе. Для логистических компаний это означает, что сбои — не исключение, а типичная ситуация, которая влияет на сроки поставок, затраты и качество сервиса.
При этом проблемы далеко не всегда выглядят как полностью недоступная система. Чаще перестаёт работать отдельная операция: заявка на перевозку не уходит в обработку, ТСД зависает после сканирования ячейки, курьер не может закрыть доставку, а клиент видит неверный статус груза. Даже такой локальный сбой способен нарушить работу всей цепочки поставок.
Поэтому компаниям важно контролировать не только состояние инфраструктуры, но и выполнение ключевых бизнес-процессов. Классический мониторинг показывает, что сервис доступен, однако не отвечает на вопрос, может ли сотрудник или клиент действительно выполнить нужную операцию.
Эту задачу решает синтетический мониторинг. Цифровые агенты по расписанию проходят критически важные пользовательские сценарии так же, как это делает реальный сотрудник или клиент, и сразу фиксируют сбой, если процесс прерывается. Подробнее о работе этого подхода в Primo ART мы рассказывали в статье «Как ИТ узнаёт о сбое раньше пользователей».
В этой статье вы узнаете, какие задачи синтетический мониторинг помогает решать в логистике и какие новые возможности для этого открывает мобильный агент для Android.
Самый понятный сценарий для склада — регулярно проверять ключевые операции в WMS и мобильном интерфейсе. Так команда сразу узнает о сбоях и успеет устранить их до того, как они повлияют на работу склада.
Например, каждые 10–15 минут агент авторизуется в WMS, открывает тестовое задание на приёмку, проверяет создание задания на размещение, проходит экран отбора, имитирует сканирование ячейки и товара, а затем фиксирует, что операция дошла до ожидаемого статуса. Если после релиза сломалась кнопка подтверждения, изменилась логика прав или ТСД-клиент зависает после сканирования, команда узнает об этом ещё до того, как проблема начнёт влиять на работу склада.
Для бизнеса это не просто ранний алерт. Это возможность сократить простои, когда поставщик ждёт разгрузки, транспорт стоит в слоте, а сотрудники не могут продолжить работу из-за сбоя.
Для многих 3PL-операторов личный кабинет — основная точка взаимодействия с клиентом. Здесь оформляют заявки, рассчитывают стоимость перевозки, отслеживают груз и скачивают документы. Если один из этих сценариев не работает, клиенты обращаются в поддержку, а у компании возникают репутационные риски.
Синтетический мониторинг для 3PL-портала может проходить путь от входа до создания тестовой заявки: выбрать тип груза, направление, склад отправления, тариф, дату забора, проверить сохранение черновика, открыть карточку отправления и убедиться, что документ доступен для скачивания. Такой сценарий особенно полезен после обновлений тарифного модуля, изменений в личном кабинете и работ у внешних провайдеров.
Для сервисов доставки продуктов и товаров важен не только сайт или приложение целиком, а весь путь оформления заказа. Пользователь может без проблем найти товар и добавить его в корзину, но столкнуться с ошибкой при выборе времени доставки, оплате или подтверждении заказа. Такие проблемы часто обнаруживаются уже после обращения первого клиента.
Синтетический мониторинг регулярно воспроизводит весь путь оформления заказа и проверяет, что каждый этап завершается успешно. При необходимости можно настроить отдельные сценарии для разных способов оплаты, программ лояльности, зон или времени доставки. Такой подход помогает обнаружить ошибки после релизов и изменений во внешних сервисах ещё до того, как они повлияют на покупателей.
После релиза важно проверить не только доступность системы, но и ключевые бизнес-процессы. Личный кабинет может открываться, авторизация работать, а базовые проверки не показывать ошибок. Например, не создаются заказы, неверно рассчитывается стоимость доставки или не формируются документы для отгрузки.
Поэтому синтетический мониторинг удобно использовать как контрольную сетку до и после выкладки. До релиза робот проходит набор эталонных сценариев и фиксирует время выполнения. После релиза эти же сценарии запускаются снова: приёмка, отбор, создание перевозки, расчёт тарифа, выдача заказа, закрытие доставки, выгрузка документов. Команда видит не только факт ошибки, но и изменение времени на конкретных шагах.
Такой подход особенно полезен для ночных релизов и распределённых команд, где утром первыми проблему увидят сотрудники в другом часовом поясе или на удалённой площадке. Робот проходит сценарии сразу после изменений, поэтому ИТ не ждёт начала смены и получает данные для отката или исправления раньше операционного пика.
Для федеральной логистики средняя доступность по стране мало что говорит о реальной работе конкретного распределительного центра. Система может быть доступна из центрального офиса, но плохо работать из склада в регионе из-за канала связи, сетевых правил, локального оборудования или особенностей маршрутизации.
Геораспределённый синтетический мониторинг позволяет запускать один и тот же сценарий из разных точек: центральный склад, региональный распределительный центр, сортировочный центр, офис транспортного подразделения, зона работы курьеров. Если сценарий проходит в Москве и не проходит в Екатеринбурге, команда сразу видит, что проблема связана не со всей системой, а с конкретной локацией или сетевым сегментом.
Логистика давно живёт не только в веб-интерфейсах. Основная работа часто происходит на устройстве в руках сотрудника: ТСД у кладовщика, смартфон курьера, планшет водителя, мобильное приложение экспедитора. Для таких сценариев в Primo ART появился Android-агент.
Для ИТ это даёт понимание там, где раньше оставались только сообщения: «у нас зависают терминалы», «курьеры не могут закрыть доставку», «после обновления приложение странно работает на части устройств». Для операционного руководителя это означает меньше ручных обходов, меньше звонков в поддержку и меньше ситуаций, когда проблема всплывает уже на маршруте.
Не стоит пытаться сразу охватить весь ИТ-ландшафт. Начните с нескольких сценариев, остановка которых сразу отражается на работе бизнеса:
Для первых шагов обычно достаточно 5—15 сценариев и 1—3 точек запуска: например, центрального контура, одного склада и одной региональной площадки.