Внешний CTO для автоматизации: сначала карта объёма, потом затраты

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

Большинство команд оценивает только типовой сценарий.

Форма отправляется, правило её проверяет, кто-то утверждает, и задача движется дальше. На бумаге это выглядит просто и дёшево.

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

Откат — это не мелочь. Если команде нужно отменить согласование, открыть запись заново или исправить неправильный статус, системе часто нужны дополнительные экраны, правила, уведомления, журналы аудита и тесты. Одно «простое исправление» может удвоить объём работ на этом шаге.

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

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

Хороший внешний CTO часто замечает это раньше, потому что он меньше привязан к исходной схеме. Он задаёт неудобные, но полезные вопросы. Что происходит, если кто-то нажмёт «утвердить» по ошибке? Кто может обойти правило? Как часто люди возвращают работу назад? Что делает финансовый отдел, если цифры не сходятся?

Такие вопросы меняют оценку с «автоматизируем этот процесс» на «автоматизируем этот процесс, его откаты и исключения». Такой вариант менее красивый, зато ближе к реальности.

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

Что считается исключением

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

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

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

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

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

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

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

Несколько формулировок обычно указывают на скрытые исключения. «Мы это делаем вручную» — одна из них. «Это нужно только этому клиенту» — другая. Или любая отдельная таблица, которая живёт вне основной системы.

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

Где проявляется скрытый объём работ

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

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

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

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

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

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

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

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

Как оценить реальный объём

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

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

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

Несколько вопросов обычно помогают увидеть реальный объём:

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

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

Для каждой ветки запишите, кто её утверждает и почему. Роли важнее имён. «Финансовый менеджер утверждает заказы выше 10 000 долларов» — полезно. «Руководство смотрит крупные заказы» — слишком расплывчато для оценки. Важна и причина, потому что она показывает, правило фиксированное, политическое или скоро, вероятно, изменится.

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

Ветка, которая срабатывает только в 5% случаев, всё равно может удвоить число тестов. Поэтому карта исключений — это не бумажная работа. Это контроль объёма.

Как оценить риск для бюджета

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

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

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

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

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

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

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

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

Простой пример на согласовании счетов

Согласование счета выглядит просто, пока не появляется первое исключение.

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

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

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

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

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

Именно поэтому рабочий процесс, который выглядел как «один поток согласования», превращается в четыре или пять реальных сценариев. Первая оценка могла бы предусматривать 40 часов. Когда команда посчитает откаты, обходы правил и ручную проверку, тот же объём может вырасти до 90 или 120 часов.

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

Ошибки, которые скрывают объём работ

Команды часто оценивают автоматизацию, просто копируя текущий экран. Они перечисляют поля, кнопки и статусы и думают, что этим уже всё учли. Но это не так.

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

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

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

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

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

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

Перед утверждением бюджета задайте три простых вопроса:

• Какие случаи всё ещё требуют решения человеком?
• Какие редкие случаи могут заблокировать выручку, платежи или комплаенс?
• Какие правила существуют на практике, но не описаны в политике?

Если команда не может ответить на них чётко, объём работ всё ещё скрыт.

Проверки перед утверждением бюджета

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

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

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

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

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

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

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

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

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

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

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

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

Если объём всё ещё кажется подозрительно маленьким, попросите вторую проверку до старта разработки. Олег Сотников из oleg.is делает такую работу для стартапов и небольших компаний в роли внешнего CTO и консультанта, особенно когда автоматизация, процессы на базе ИИ или кастомное ПО могут выйти далеко за рамки первого черновика. Цель проста: заранее найти скрытые ветки, честно их оценить и начать с той части, которая выдержит ежедневную работу.