Анализ автоматизации рабочих потоков

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

Автоматизировать нужно не то, что проще всего технически, а то, что даёт наибольший эффект для бизнеса.

Происхождение и исследовательская база

Анализ автоматизации рабочих потоков опирается на принципы приоритизации в интеллектуальной автоматизации процессов (Robotic Process Automation, Business Process Automation), систематизированные в матрицах оценки кандидатов на автоматизацию по объёму, повторяемости, правилообразности и стоимости ошибок — практика также включает пост-внедренческую проверку: работает ли автоматизация как задумано, или создаёт новые виды ошибок и скрытых ручных обходов.

Разделение «технически просто» и «даёт наибольший эффект» имеет узнаваемый исторический источник: PICK-диаграмму (Possible, Implement, Challenge, Kill — «возможно, внедрить, поспорить, отклонить») разработала компания Lockheed Martin для приоритизации собственных инициатив по улучшению процессов, и с тех пор она стала стандартным инструментом Lean Six Sigma. Матрица сопоставляет две оси — сложность внедрения и размер выигрыша: «Implement» (легко и большой эффект) — очевидные кандидаты в первую очередь; «Possible» (легко, но малый эффект) — второстепенные; «Challenge» (сложно, но большой эффект) — требуют отдельного обоснования ресурсов; «Kill» (сложно и малый эффект) — не стоят усилий вовсе. Именно эта логика, а не интуитивная оценка «что проще сделать», лежит в основе принципа приоритизации по бизнес-эффекту, а не по технической простоте.

Современную, куда более систематическую версию того же анализа даёт дисциплина process mining («интеллектуальный анализ процессов») — её в 1999 году как отдельное научное направление сформулировал нидерландский учёный Вил ван дер Аальст (университет Эйндховена, сегодня — главный научный сотрудник компании Celonis). В отличие от ручной инвентаризации кандидатов на автоматизацию, process mining восстанавливает реальную карту процесса напрямую из журналов событий информационных систем (кто, что и когда сделал) — то есть показывает, как процесс работает НА САМОМ ДЕЛЕ, а не как он описан в регламенте, включая именно те скрытые ручные обходы и отклонения, которые эта методика ищет отдельным принципом ниже. Задокументированные результаты применения на практике: Siemens повысила долю автоматизации в цикле «заказ-оплата» на 24% и сократила количество ручных операций на 10 миллионов в год; Uber снизила количество ошибок в платежах на 62%; Vodafone сэкономила свыше 70 000 часов в год за счёт сокращения цикла активации тарифных линий на 22%.

Ключевые идеи и принципы

1. Принцип: Приоритизация по объёму, повторяемости и правилообразности

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

2. Принцип: Оценка не только технической простоты, но и бизнес-эффекта

   Анализ явно разделяет "легко автоматизировать технически" и "даёт наибольший эффект для бизнеса" — эти два критерия часто не совпадают, и приоритет должен отдаваться реальному эффекту, а не удобству реализации.

3. Принцип: Проверка работы уже внедрённой автоматизации

   Анализ не ограничивается выбором новых кандидатов на автоматизацию — он также проверяет, работает ли уже существующая автоматизация корректно, не создаёт ли скрытых ошибок и не привела ли к появлению теневых ручных обходов (shadow workarounds), которые сотрудники используют, когда автоматизированная система не справляется с реальными случаями.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: кандидаты на автоматизацию выбираются по технической простоте, а не по бизнес-эффекту.

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

   Как избежать

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

2. Ошибка 2: внедрённая автоматизация не проверяется на появление теневых ручных обходов.

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

   Масштаб проблемы задокументирован количественно вне контекста этой конкретной методики: по данным исследования Gartner (2023), 69% сотрудников намеренно обходили утверждённые корпоративные инструменты и процедуры безопасности в течение года — не по злому умыслу, а потому что официально одобренный инструмент оказался слишком медленным, негибким или сложным для реальной задачи. Тот же механизм действует и в отношении автоматизации рабочих потоков: формальное «внедрение завершено» и фактическое повсеместное использование — разные вещи, которые нужно проверять раздельно.

   Как избежать

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

3. Ошибка 3: сопротивление сотрудников автоматизации не прорабатывается заранее.

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

   Опасение не беспочвенно статистически, но и не так однозначно, как кажется на уровне ощущений. По данным Pew Research Center, 52% работников обеспокоены будущим влиянием автоматизации и ИИ на их работу, а по данным Mercer, доля сотрудников, тревожащихся именно из-за риска потери работы, выросла с 28% в 2024 году до 40% в 2026-м. При этом, по тем же обзорам, лишь 2% американцев когда-либо реально теряли работу именно из-за замены их позиции автоматизацией или программой — то есть тревога систематически опережает фактический масштаб увольнений на порядок. Для разговора с командой это означает: отрицать саму тревогу бессмысленно и контрпродуктивно, но полезно явно показывать разницу между реальной статистикой замещения ролей и статистикой замещения конкретных рутинных операций внутри роли — именно на этом различии строится принцип 1 данной методики.

   Как избежать

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

4. Ошибка 4: приоритет отдаётся объёму операций без учёта устойчивости процесса во времени.

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

   Как избежать

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

   Практическая проверка устойчивости процесса не требует сложного инструментария: достаточно спросить владельца процесса, запланированы ли на ближайшие 6-12 месяцев изменения регламента, системы или оргструктуры, которые затронут именно этот процесс, — и явно задокументировать ответ рядом с оценкой объёма и повторяемости в общем списке кандидатов, а не полагаться на то, что этот риск «и так всем очевиден».

5. Ошибка 5: эффект автоматизации не перепроверяется через несколько месяцев после внедрения.

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

   Как избежать

   повторно проверять работу автоматизации через несколько месяцев после внедрения, а не считать разовую проверку на старте достаточной.

План внедрения

1. Неделя 1: список кандидатов

   составить список кандидатов на автоматизацию с оценкой объёма и повторяемости.

2. Неделя 2: оценка стоимости ошибок

   оценить стоимость ошибок и правилообразность для каждого кандидата.

3. Неделя 3: проверка существующей автоматизации

   проверить уже внедрённую автоматизацию на наличие скрытых ручных обходов.

4. Неделя 4: приоритизированный план

   составить приоритизированный план новой автоматизации и исправлений существующей.

5. Далее: регулярный пересмотр списка

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

Как реализовать этот план с помощью фрейма «Анализ автоматизации рабочих потоков» в OrgDevTools

Фрейм устроен как четыре карточки со свободным списком записей на каждой — Кандидаты на автоматизацию, Проверка существующей автоматизации, Управление изменениями, План приоритетов.

Неделя 3 — карточка «Проверка существующей автоматизации». Подсказка прямо спрашивает, «работает ли как задумано, нет ли теневых обходов» — не даёт остановиться на разовой проверке при внедрении (защита от ошибки 2 и 5).

Карточка «Управление изменениями». Отдельная карточка с подсказкой про «сопротивление сотрудников, план коммуникации» — прямая структурная защита от ошибки 3, не даёт проекту автоматизации обойтись без проработки человеческого фактора.

Книги по теме

Виллар А.С., Хан Н. — «Robotic process automation in banking industry: a case study on Deutsche Bank» (Journal of Banking and Financial Technology, 2021). Практический кейс внедрения RPA в Deutsche Bank и проверки его реального эффекта после запуска.