Большинство обоснований автоматизации выглядит одинаково. Кто-то оценивает часы, которые съедает задача, умножает на зарплату, сравнивает со стоимостью проекта и получает срок окупаемости.
Эта цифра почти всегда неверна, обычно оптимистична и не учитывает расходы, от которых как раз и зависит, стоило ли всё затевать.
Что упускает стандартный расчёт
Стоимость эксплуатации. Инфраструктура, вызовы API, инференс модели, мониторинг. Для AI-автоматизации это может быть заметная сумма, и она растёт вместе с объёмом — ровно с тем показателем, рост которого обоснование и закладывает.
Поддержка. API вендоров меняются. Зависимости надо обновлять. Всплывают пограничные случаи. Разумно закладывать, что система требует внимания каждый год и постоянно. Автоматизация — не покупка, а обязательство.
Путь исключений. Автоматизация редко закрывает 100% случаев. Если она закрывает 85%, оставшиеся 15% всё равно кто-то обрабатывает — и это теперь самые сложные 15%, потому что лёгкие ушли. Оставшаяся работа медленнее в расчёте на случай, чем была средняя.
Стоимость изменений. Обучение, документация, период параллельной работы, когда люди не доверяют ни старому процессу, ни новому. Всё это реально и регулярно опускается.
Стоимость оценки качества — отдельно для AI. Нужно собрать и поддерживать тестовый набор, следить за качеством и ловить деградацию. Пропустите — получите неподдерживаемую систему, которую выключат после первого заметного сбоя.
Освободившееся время — это не сэкономленные деньги
Именно это допущение тихо обесценивает большинство расчётов.
Если автоматизация убирает сорок минут в день у одиннадцати человек, компания не сэкономила ставку. Она перераспределила 7,3 часа в день между одиннадцатью сотрудниками, которые заполнят их другой работой — возможно, полезной, но не той, что фигурирует в расчёте.
Экономия реальна только если верно одно из:
- Наём действительно не состоялся, хотя должен был. Не «возможно, кто-то понадобится», а утверждённая вакансия.
- Объём вырос без роста штата. Часто самый сильный аргумент: процесс перестал масштабироваться линейно.
- Освободившееся время ушло на что-то с понятной ценностью, которое вы можете назвать.
- Команда уже работала за пределами возможностей, и альтернативой были переработки или увольнения.
Если ничего из этого не выполняется, польза может быть настоящей — меньше ошибок, быстрее ответы, ниже зависимость от конкретного человека, — но это не экономия расходов, и выдавать её за экономию значит подорвать доверие к следующему обоснованию.
Считайте пользу, которая не измеряется временем
Несколько реальных эффектов вообще не попадают в расчёт по часам:
Снижение ошибок. Если ручной перенос данных даёт фоновый уровень ошибок, а каждая ошибка чего-то стоит в обнаружении и исправлении, это считается — обычно точнее, чем экономия времени.
Скорость как выручка. Более быстрый ответ может повышать конверсию. Это измеримо, но только если разметка была до изменений, — что само по себе довод сначала измерить.
Устойчивость к пикам. Всплески объёма, которые раньше требовали переработок или роняли качество сервиса, перестают это делать. Реальная ценность, плохо заметная в средних значениях.
Снижение зависимости от человека. Когда процесс существует только в чьей-то голове, его отсутствие — операционный риск. Автоматизация превращает неявное знание в записанные и проверяемые правила. Часто это самый ценный результат, и его никогда нет в таблице.
Сначала измерьте текущий процесс
Самая частая практическая ошибка — отсутствие точки отсчёта.
Если вы не знаете сегодня, сколько занимает процесс, сколько случаев он обрабатывает и какова доля ошибок, вы не сможете показать улучшение потом. Останется спорить на уровне ощущений — а это то место, где проекты автоматизации тихо теряют приоритет.
Померяйте несколько недель до разработки. Это недорого, это улучшает оценку и иногда выясняется, что проблема совсем не там, где все думали.
Когда честный ответ — «не делайте»
Есть несколько ситуаций, где отказаться правильно:
- Процесс скоро изменится. Автоматизировать то, что вот-вот перепроектируют, — потратить деньги дважды.
- Слишком малый объём. Настройка и поддержка обойдутся дороже выигрыша. Для AI-систем это встречается чаще, чем ожидают.
- Процесс неверен. Точная автоматизация плохого процесса закрепляет его и усложняет изменения. Иногда правильно сначала перепроектировать.
- Владельца не будет. Автоматизация без владельца деградирует, пока её не выключат. Если со стороны клиента её никто не возьмёт, проект уже провалился.
Мы говорим это клиентам регулярно, и дело не в альтруизме. Продать работу, которой не должно быть, — самый быстрый способ навсегда потерять клиента.
Защитимый расчёт
Расходы: разработка + эксплуатация за первый год + предполагаемая годовая поддержка + оценка качества (для AI) + управление изменениями.
Польза: несостоявшийся наём, который был реально запланирован + измеренное снижение ошибок + измеренный эффект скорости + запас по пикам + задокументированное снижение рисков.
Сравнивать с: измеренным текущим процессом, а не с тем, каким его помнят.
Итоговая цифра будет менее впечатляющей, чем в стандартном расчёте. Зато она выдержит проверку и покажет, какие проекты действительно стоит делать, — а ради этого расчёт и затевается.