Оценка ROI автоматизации: считайте повторы и исправления

Почему оценки автоматизации не видят реальную работу

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

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

Часто эта работа прячется у всех на виду. Команды говорят: «бот обрабатывает 95% случаев» — и воспринимают остальные 5% как мелкий шум. На практике эти 5% могут занимать больше всего времени, потому что люди в итоге разбирают самые грязные случаи уже после того, как автоматизация остановилась.

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

Именно поэтому стоимость обработки исключений так важна. Бот может экономить часы на рутинных случаях, но сотрудники всё равно берут на себя крайние ситуации, а крайние ситуации не остаются маленькими по мере роста объёма. Если вы выполняете 5 000 задач в месяц и 2% из них сбоят, это 100 исключений. Если на разбор каждого исключения уходит 12 минут, вы только что вернули в месяц ещё 20 часов ручной работы.

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

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

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

Как обычно выглядит работа с исключениями

В оценке автоматизации сбои часто считают погрешностью. Реальная работа начинается, когда ломается идеальный сценарий. Автоматизация может сама завершать 95% случаев, но остальные 5% способны съедать удивительно много времени.

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

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

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

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

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

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

Что нужно учесть, прежде чем обещать экономию

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

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

Потом посчитайте время обнаружения. Кому-то нужно заметить проблему, прежде чем кто-то сможет её исправить. Во многих командах это занимает больше времени, чем ожидают. Задача может сломаться в 9:03, но никто не увидит это до 9:20, потому что уведомление лежит в почте или очереди.

Это ожидание тоже труд. Если один человек проверяет очередь, а другой подтверждает проблему, учитывайте обе части.

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

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

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

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

Обычно достаточно простой таблицы из пяти столбцов:

• тип сбоя
• как часто он случается
• время на обнаружение
• время на исправление, откат или повторный запуск
• время на проверку

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

Как оценить работу с исключениями шаг за шагом

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

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

2. Возьмите свежие данные из реальной работы, а не догадки. Обычно 8–12 недель достаточно, чтобы увидеть закономерности. Посчитайте общий объём, затем посчитайте каждый тип ошибки отдельно. 2% отказов в высокообъёмном процессе могут стоить дороже, чем 10% в малом.

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

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

5. Добавьте запас, прежде чем считать цифру окончательной. Стоимость обработки исключений почти никогда не остаётся стабильной. Акции, авралы в конце месяца, сбои у поставщиков и изменения правил могут быстро поднять процент ошибок. Запас в 15–30% — разумная точка старта, а новым автоматизациям часто нужно ещё больше, пока правила не устаканятся.

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

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

Простой пример из процесса обработки заказов

Магазин автоматизирует обработку заказов. Когда клиент оформляет заказ, система сразу создаёт счёт и резервирует товар на складе. Если всё идёт хорошо, команда вообще не трогает этот заказ.

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

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

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

Используйте простые цифры:

• 1 200 заказов в месяц
• 4 минуты экономии на каждом чистом заказе
• 2% заказов сбоят после резерва товара
• 8 минут работы сотрудника на каждый сбойный заказ
• половина этих клиентов повторяет попытку позже, добавляя ещё по 4 минуты

На бумаге автоматизация экономит 4 800 минут в месяц, или 80 часов.

Но 2% от 1 200 заказов — это 24 сбойных случая. При 8 минутах на каждый очистка занимает 192 минуты, или 3,2 часа. Если 12 из этих клиентов попробуют снова позже, это добавляет ещё 48 минут, или 0,8 часа.

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

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

Вот почему стоимость обработки исключений должна быть в каждой оценке ROI автоматизации. Чистый путь продаёт проект. Грязный путь решает, реальна ли экономия.

Ошибки, которые делают цифры лучше, чем реальность

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

Первая ошибка — использовать тестовые данные вместо реальных записей. Демонстрационные заказы, тестовые счета и чистые таблицы скрывают неприятные вещи: пустые поля, дубли, просроченные способы оплаты и несовпадающие имена. Если за прошлый квартал команда обработала 180 сломанных случаев, эта история важнее, чем идеально отполированный proof of concept.

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

В оценку нужно включать и время поддержки клиентов. Когда автоматизация ломается, пользователи не исчезают. Они пишут письма, звонят, открывают чаты и спрашивают обновления. Даже короткий ответ может занять 5–10 минут, если сначала нужно проверить заказ, подтвердить проблему и объяснить, что будет дальше.

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

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

Ещё одна ловушка — ранняя очистка после запуска. Сразу после внедрения люди часто латают крайние случаи, исправляют старые записи, объединяют дубли и переписывают правила. Некоторые команды называют это временным и считают бесплатным. Это не бесплатно. Это часть стоимости того, чтобы автоматизация стала реально пригодной для использования.

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

Быстрая проверка перед утверждением проекта

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

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

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

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

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

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

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

Что делать дальше

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

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

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

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

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

Если вам нужен второй взгляд перед разработкой, Oleg Sotnikov на oleg.is может оценить процесс, архитектуру и предположения по стоимости в роли Fractional CTO. Такой разбор особенно полезен, когда в одном процессе смешаны софт, операционная работа и автоматизация с AI. Цель не в том, чтобы раздуть оценку. Цель в том, чтобы сделать её достаточно честной, чтобы проект всё равно имел смысл после того, как появятся повторы, откаты и очистка.