Автоматизация бизнес-процессов: что автоматизировать, как внедрить и посчитать эффект

Главная ошибка - измерять только активную работу

Возьмём условный пример оформления договора. Менеджер тратит 12 минут на подготовку данных, юрист - 18 минут на проверку, бухгалтер - 5 минут на реквизиты. Активной работы всего 35 минут, но клиент получает договор через два дня: документ лежит в очереди, ждёт уточнений, переходит между отделами и возвращается из-за незаполненного поля

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

Доля активной работы = активное время / полное время цикла × 100%

В другом условном примере цикл занимает 16 рабочих часов, а активная работа - 40 минут. Получается 40 / (16 × 60) × 100% ≈ 4%. Время нужно считать в одинаковых единицах и в одной временной шкале: не смешивать рабочие и календарные часы. Если несколько сотрудников работают параллельно, сумма их трудозатрат уже не равна длительности активных этапов

При такой доле ожидания сокращение отдельной операции с 10 минут до 5 почти не изменит срок для клиента. Сначала стоит разобраться, почему работа так долго лежит между этапами

Что именно считать бизнес-процессом

Бизнес-процесс удобно определять как путь от конкретного события до проверяемого результата. «Работа бухгалтерии» слишком широка для одного проекта, а следующие формулировки уже задают границы

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

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

Если нужно выбирать не один процесс, а портфель изменений по всей компании, используйте материал «Автоматизация бизнеса: что можно автоматизировать и с чего начать»

Четыре уровня автоматизации процесса

Ниже - рабочая классификация по масштабу изменений, а не отраслевой стандарт

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

Семь признаков хорошего кандидата

1. Большой повторяемый объём. Небольшое улучшение на одной операции становится заметнее, когда таких операций сотни или тысячи
2. Много ручных действий. Сотрудники копируют данные, создают однотипные задачи, проверяют обязательные поля и ищут информацию
3. Долгое ожидание. Задача большую часть времени лежит между действиями
4. Возвраты и переделки. Ошибку обнаруживают на следующем этапе, после чего работа возвращается назад
5. Рост объёма требует сопоставимого роста штата. Например, при увеличении входящего потока на 30% компания вынуждена почти на 30% увеличивать команду. Это условный пример зависимости, не норматив
6. Понятный типовой поток. Основные случаи проходят по нескольким устойчивым маршрутам
7. Измеримый результат. Можно посчитать обработанные заявки, документы, заказы, платежи, обращения или отчёты

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

Карта процесса на одном листе

Для первого разбора достаточно таблицы шагов. Ниже - условный маршрут подготовки ответа клиенту; времена выбраны для примера, а не взяты из клиентского проекта

В этой таблице активная работа занимает 28 минут, а ожидание - 315 минут, то есть 5 часов 15 минут. Самые длинные очереди находятся перед согласованием и расчётом условий. Их и стоит разбирать первыми, одновременно проверяя, где можно убрать ручной перенос данных. Из таблицы пока не следует, что сами проверки не нужны

Карта потерь процесса: метки для разбора

Отметьте характер работы на каждом шаге. Это авторская рабочая разметка; у одного этапа может быть несколько меток

Например, пять минут с метками Р и Д указывают на ручной повторный ввод - стоит проверить возможность интеграции. Три часа с метками О, П и К означают ожидание при передаче и согласовании: здесь полезнее разбирать маршрут и полномочия. Десять минут с метками И и Н могут быть задачей для ИИ, если сотрудник ищет сведения и интерпретирует нестандартный запрос

Числа в этих примерах условные. Метки помогают выбрать направление проверки, но не заменяют расчёт затрат и цены ошибки

Этап 1 - зафиксировать результат и границы

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

Этап 2 - измерить исходное состояние

Американский центр производительности и качества, APQC, рекомендует четыре группы показателей: стоимость, производительность сотрудников, эффективность процесса и время цикла [1]. Для первого разбора можно выбрать следующие шесть показателей

1. Объём операций за период

2. Полное время цикла

3. Активные ручные минуты

4. Доля ошибок или возвратов

5. Стоимость одной единицы результата

6. Пропускная способность

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

Этап 3 - найти ограничение

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

Допустим, этап А занимает 20 минут ручной работы, но имеет свободную мощность. Этап Б требует только 5 минут, однако задач туда поступает больше, чем команда успевает обработать. Очередь растёт перед Б. Автоматизация А может сократить трудозатраты, но сама по себе не увеличит выпуск всего процесса: для этого нужно снять ограничение на Б

Этап 4 - удалить лишнее до автоматизации

Проверяйте каждый шаг

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

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

Этап 5 - выбрать правильный механизм

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

Этап 6 - спроектировать процесс после изменений

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

Письмо → менеджер читает → ищет клиента → копирует данные → ставит задачу → ожидание специалиста → подготовка ответа → согласование руководителем → отправка клиенту

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

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

Этап 7 - провести ограниченный пилот

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

• Только один канал входа
• Только одна категория клиентов
• Только типовые документы
• Только один регион
• Только суммы ниже установленного порога

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

Формула стоимости ручного процесса

Для предварительной оценки разделите расходы на три части

Стоимость ручного процесса в месяц = стоимость активного труда + стоимость ошибок и переделок + известные потери от задержек

Стоимость активного труда за месяц = число операций за месяц × активные минуты на операцию / 60 × полная стоимость часа

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

Условный расчёт: компания обрабатывает 1 500 документов в месяц, на каждый уходит 7 минут, полная стоимость часа сотрудника - 700 ₽

До автоматизации: 1 500 × 7 / 60 × 700 = 122 500 ₽ в месяц

Предположим, после внедрения на документ остаётся 2 минуты ручного контроля

После автоматизации: 1 500 × 2 / 60 × 700 = 35 000 ₽ в месяц

Разница в стоимости труда - 87 500 ₽ в месяц. Это результат расчёта на условных данных, не обещанная экономия. Если сотрудники остаются в штате, расходы не сокращаются, а время никак не используется, соответствующего прироста прибыли не будет. Финансовый результат нужно связать с конкретным изменением

• Убрали переработки
• Отложили найм
• Обработали дополнительный объём
• Перенаправили людей на более ценную работу
• Снизили оплачиваемые ошибки или возвраты

Эту связь отдельно разбираем в материале как превратить экономию времени в деньги

Формула окупаемости

Простой срок окупаемости показывает, за сколько месяцев положительный эффект покроет разовые вложения, если ежемесячный результат остаётся устойчивым

Срок окупаемости в месяцах = разовые затраты / ежемесячный финансовый эффект после регулярных расходов

Отдельный условный пример: внедрение стоит 300 000 ₽, финансовый эффект до расходов на систему составляет 90 000 ₽ в месяц, поддержка и инфраструктура - 20 000 ₽

Эффект после регулярных расходов: 90 000 − 20 000 = 70 000 ₽ в месяц
Срок окупаемости: 300 000 / 70 000 ≈ 4,3 месяца

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

Как измерить качество, а не только скорость

Рядом с основной целью задайте защитную метрику - показатель, который не должен ухудшиться ради ускорения или снижения затрат. Например

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

Почему локальное ускорение иногда ничего не меняет

Бостонская консалтинговая группа в материале 2026 года связывает больший эффект в своих проектах с перепроектированием работы целиком, а не только с добавлением ИИ в отдельные задачи [2]. Это наблюдение консультантов на собственных внедрениях, не гарантия результата для любого процесса

Представим, что договор теперь готовится за 5 минут вместо 15, но по-прежнему два дня ждёт подписи директора. Клиент почти не заметит ускорения. А если после улучшения первого этапа следующий отдел получает больше задач, чем способен обработать, очередь вырастет уже у него. Поэтому после изменения повторно проверьте, где теперь находится ограничение

Где автоматизация чаще всего ломается

Автоматизировали лишнюю работу. Команда поддерживает операцию, результат которой никому не нужен

Не разделили типовой поток и исключения. Редкие случаи усложняют первую версию и задерживают запуск основных сценариев

Не измерили исходное состояние. После запуска невозможно отделить результат внедрения от впечатлений и других изменений

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

Сохранили двойной учёт. Система работает, но старая таблица продолжает жить «для надёжности». Данные приходится вводить и сверять в обоих местах

Не назначили владельца процесса. Техническая команда отвечает за работу решения, а за бизнес-результат не отвечает никто

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

Чек-лист руководителя до разработки

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

Источники и проверка фактов

1. Американский центр производительности и качества - показатели эффективности процессов - подход к стоимости, производительности, эффективности и времени цикла

2. Бостонская консалтинговая группа - перестройка рабочих процессов с ИИ. 15 июня 2026 года. Практический материал консультантов о собственных проектах. Числовые примеры времени, стоимости труда и окупаемости в этой статье - отдельные авторские расчёты, не результаты проектов БКГ или студии