Платформенный подход: как связать автоматизацию с управлением процессами

22 октября 2026 года в ITWeek вышла статья Ивана Лашкова, руководителя отдела маркетинга STAQ, о платформенном подходе к управлению процессами. В материале разобраны связь корпоративных систем, контроль исполнения задач, применение ИИ и проверка эффекта на конкретных проектах.

Компания может использовать ERP, CRM, SCADA и сервис-деск, но передавать задачи между подразделениями по телефону и электронной почте. Например, датчик сообщает об отклонении, предупреждение появляется на экране, а ремонтная служба получает информацию только после остановки оборудования. Для бизнеса важен весь путь: от обнаружения события до подтверждённого выполнения работы.

Как устроено сквозное управление процессом

Чтобы организовать ремонт, нужно собрать историю оборудования, проверить запчасти, назначить инженера и согласовать время. Когда эти действия связывает ручная переписка, задержка может возникнуть до начала работы специалиста. По мере роста числа объектов, подрядчиков и приложений становится сложнее определить причину ожидания и менять интеграции.

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

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

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

Что меняется в работе компаний

Результаты ниже приведены в публикации ITWeek от 22 октября 2026 года и относятся к описанным проектам. Их нельзя переносить на любое внедрение без проверки исходных условий.

Обслуживание микромаркетов

Заявки и чек-листы связали с торговыми объектами, посещения мерчендайзеров стали подтверждать разовыми QR-кодами, а расчёт заработной платы автоматизировали. Руководители получили возможность сопоставлять присутствие сотрудника с выполненными работами и оценивать качество обслуживания каждой точки.

Обращения сотрудников продуктового ритейлера

Почту, веб-портал и мессенджер объединили в общей системе. Карточка заявки стала хранить переписку и контекст решения, база знаний сократила повторные уточнения. Показатель контроля исполнения заявок вырос на 98% относительно исходного уровня заказчика, время уточнения деталей сократилось на 45%, потери обращений были исключены. Рост на 98% здесь означает изменение показателя относительно исходного уровня, а не абсолютную долю выполненных заявок.

Обходы промышленного оборудования

На предприятии оборудование обозначили NFC-метками, бумажные записи заменили мобильными маршрутами и цифровыми чек-листами. Сведения о дефектах стали передаваться с места осмотра и сразу связываться с нужным объектом. Проект охватил 1 700 единиц оборудования на площади 17 000 м². Время реакции на дефекты сократилось в 2–3 раза, просрочки устранения практически исчезли.

Непрерывный температурный контроль

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

Потери продукции из-за нарушения температурного режима хранения сократились на 90%, среднее время реакции персонала — на 43%. Более 90% отклонений система автоматически фиксирует и передаёт ответственным без участия диспетчера. Неисправности устраняет персонал: автоматическая регистрация и маршрутизация не означают автоматический ремонт.

Где полезен ИИ и какие ограничения нужно учитывать

В описанном сервисном проекте компания заменила Jira Service Desk и организовала управление инцидентами для 60 клиентов. ИИ классифицирует обращения, выполняет первичную оценку и направляет заявки между командами. Система обрабатывает более 100 заявок в день. Время реакции сократилось втрое, первичный анализ ускорился в 3–4 раза. Это результат всего внедрения, включая изменение процесса обработки, а не отдельно измеренный эффект ИИ.

При доступе к истории оборудования, предыдущим инцидентам и базе знаний ИИ может находить похожие случаи, кратко описывать проблему и предлагать следующий шаг. Качество анализа зависит от полноты и актуальности данных. Если один объект записан под разными названиями, а результаты ремонтов отсутствуют, возможности такой помощи ограничены.

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

Как выбрать первый процесс для пилота

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

1. Выбрать такую задачу и определить, какие потери требуется проверить.
2. Проследить передачу данных между участниками и найти места задержек.
3. Зафиксировать исходные показатели, целевой результат и источники данных.
4. Провести пилот на одном объекте или в одном подразделении.
5. Подтвердить эффект и оценить условия его повторения на других площадках.

Как измерить результат внедрения

Оценку удобно разделить на четыре группы:

• Скорость: время от события до регистрации задачи, назначения исполнителя и завершения работы.
• Надёжность: доля просрочек, соблюдение SLA и число повторных инцидентов.
• Трудозатраты: часы на диспетчеризацию, согласования и подготовку отчётности.
• Экономика: стоимость процесса, потери от простоев, брака и внеплановых ремонтов.

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

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

О связи событий, задач и результата также рассказываем в материале «Логика процесса».

Материал подготовлен по статье Ивана Лашкова в ITWeek, опубликованной 22 октября 2026 года. Автор — руководитель отдела маркетинга STAQ.