Как понять, что бизнес-процесс пора автоматизировать

Ручной труд — ещё не диагноз

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

Самый быстрый ответ — открыть каталог систем. Самый полезный — сначала спросить, что именно происходит в процессе. Где он начинается и заканчивается? Как выглядит правильный результат? Сколько операций проходит без вмешательства руководителя? Какие исключения повторяются? Кто отвечает за итог после того, как исполнителя заменит правило или программный сценарий?

Жалоба на ручной труд показывает боль, но не готовность. Если участники по-разному понимают результат, правила меняются от случая к случаю, а исключения живут в переписке, автоматизация закрепит эту неопределённость. Очередь не исчезнет: она просто переместится внутрь системы и станет хуже видна.

Поэтому первый объект решения — не программа, а кандидат на обследование. Российский национальный стандарт ГОСТ Р 56407-2023 рассматривает стандартизацию повторяемой работы через описание последовательности действий, времени выполнения и способов предупреждения ошибок. А ГОСТ Р ИСО 9001-2015 требует определять и управлять процессами и их взаимодействием, учитывать риски и опираться на свидетельства. Для операционного директора это практическая последовательность: сначала доказать управляемость процесса, затем выбирать способ автоматизации.

Что считать готовым процессом

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

В российском ГОСТ Р ИСО 9001-2015 процессный подход связывает ожидаемый результат с ответственностью, ресурсами, рисками, контролем и оценкой результативности. ГОСТ Р 56407-2023 дополняет эту оптику требованиями к стандартизации повторяемой работы: нужно видеть последовательность, время выполнения, потребителя результата и способы предупреждения ошибок.

Для автоматизации это даёт шесть проверочных вопросов:

1. Нагрузка. Мы знаем частоту операций, очередь и фактическое ручное время?
2. Правила. Основной путь повторяется, а решение можно объяснить без фразы «опытный сотрудник и так понимает»?
3. Исключения. Типы отклонений посчитаны, и для каждого понятно, кто принимает решение?
4. Данные. Источники, качество, права доступа и чувствительность данных известны?
5. Эффект и риск. Видна цена ручной работы, ожидания и ошибки — без выдуманного процента экономии?
6. Ответственность. Есть владелец результата и показатель, который должен улучшиться после запуска?

Эти вопросы не выбирают RPA, BPM, low-code или интеграцию. Они отвечают на более ранний вопрос: есть ли у команды достаточно фактов, чтобы не автоматизировать догадки.

Матрица готовности по шести критериям

Ниже — диагностическая рекомендация НТА, а не отраслевой стандарт. Для каждого критерия поставьте 0, 1 или 2 и приложите короткое доказательство. Балл без факта не считается.

• Нагрузка и повторяемость. 0 — объём и ручное время неизвестны; 1 — есть оценки или данные за отдельные периоды; 2 — есть фактический объём, очередь, время цикла и повторяемый основной путь.
• Правила и стабильность. 0 — решения зависят от человека и не объяснены; 1 — часть правил описана, но они часто меняются; 2 — основной путь и основания решений описаны, изменения управляются.
• Исключения. 0 — отклонения не учитываются; 1 — известны типовые исключения, но нет частоты или маршрута; 2 — исключения классифицированы, посчитаны и передаются конкретной роли.
• Данные и системы. 0 — источники, качество или права неизвестны; 1 — данные доступны, но требуют ручной очистки либо уточнения прав; 2 — источники, поля, качество, права и ограничения использования подтверждены.
• Эффект и цена ошибки. 0 — нет базовой метрики; 1 — видна одна сторона эффекта: время, очередь или ошибки; 2 — есть базовая линия по времени, стоимости обслуживания, ошибкам и последствиям.
• Владелец и контроль. 0 — никто не отвечает за результат целиком; 1 — владелец назван, но метрика или полномочия не закреплены; 2 — владелец принимает правила, метрику, границы пилота и порядок остановки.

Матрица специально ставит рядом технологические и управленческие условия. Российские стандарты подтверждают необходимость описать повторяемую работу, ответственность, риски, измерение и предупреждение ошибок, но не устанавливают порог готовности к автоматизации. Поэтому шесть критериев, шкала 0–2 и правила остановки выше — практическая методика НТА для первичной диагностики конкретной компании, а не пересказ стандарта.

Как поставить баллы без самообмана

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

Затем проведите короткую встречу владельца процесса с двумя исполнителями. Если один и тот же шаг они объясняют по-разному, правило ещё не определено. Если исключение называют «редким», но не могут показать журнал или выборку, частота неизвестна. Если экономию считают только из зарплаты исполнителя, но не учитывают контроль, поддержку и цену ошибки, бизнес-эффект пока не доказан.

Полезны четыре правила оценки:

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

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

Три решения после диагностики

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

• 10–12 баллов — детально обследовать для пилота. Основные условия видны, но команда всё равно проверяет архитектуру, безопасность, нагрузку и экономику.
• 7–9 баллов — сначала закрыть пробелы. Кандидат перспективен, однако одно-два условия ещё основаны на предположениях.
• 0–6 баллов — не автоматизировать сейчас. Сначала определить процесс, убрать лишние шаги или собрать данные.

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

После оценки у каждого кандидата должна появиться одна из трёх формулировок:

1. Автоматизировать: факты достаточны для подробного обследования и ограниченного пилота.
2. Обследовать: потенциал есть, но нужно определить правила, данные, исключения или базовую метрику.
3. Не трогать сейчас: проблема реальна, однако автоматизация не является первым разумным действием.

Как выбрать первый кандидат

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

Сравните три-пять кандидатов по одной матрице. При равных баллах отдайте приоритет процессу, где:

• есть доступный владелец с полномочиями менять правила;
• основной путь занимает заметную долю объёма;
• исключения можно безопасно оставить человеку;
• данные доступны без создания нового неуправляемого хранилища;
• результат измеряется одной-двумя понятными метриками;
• существует безопасный способ остановить пилот и вернуться к ручному маршруту.

Не требуется сразу автоматизировать процесс целиком. Часто разумнее выбрать один повторяемый участок: зарегистрировать обращение, проверить комплектность, сформировать документ, передать задачу по правилу или собрать данные для решения человека. Граница пилота должна уменьшать риск, а не скрывать его.

Что делать после выбора

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

На сайте НТА можно посмотреть каталог корпоративных решений и возможности BPMSoft Конструктора, но платформа не должна определять проблему задним числом. Сначала нужно подтвердить, какой результат процесса меняется и как компания это увидит.

Если нужен внешний взгляд, подготовьте заполненные матрицы и обсудите с командой НТА диагностику одного приоритетного процесса. Предмет разговора — не «какую систему купить», а какие факты ещё нужны для безопасного решения.

Тест понедельником

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

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

Будущее должно выдержать понедельник. В данном случае — не демонстрацию красивого сценария, а обычную очередь, спорное исключение, ошибку в данных и вопрос руководителя: «Мы действительно получили тот результат, ради которого всё начинали?»

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.