У провальной автоматизации есть свойство, о котором не пишут в коммерческих предложениях: она редко возвращает компанию в исходную точку. Она возвращает ее в точку похуже. Появляется параллельный ручной процесс «на всякий случай» — теперь работы две. Ошибки, которые раньше делали люди и замечали соседи, теперь делает система — тихо и уверенно. А главное, сгорает доверие: следующий разговор про автоматизацию в этой компании начнется со слов «мы уже пробовали», и начнется он года через два.
Поэтому ноль — далеко не худший исход попытки. Худший — минус: компания, у которой автоматизация «не пошла», на пару лет закрывает тему, продолжает платить за ручную рутину по полной ставке и смотрит, как конкурент, у которого пошло, отвечает клиентам за минуты. Цена провала складывается из бюджета проекта, стоимости ухудшенного процесса и этих потерянных лет — и третья часть обычно самая крупная.
За провалами почти всегда стоят повторяющиеся конструкции — их видно на обломках чужих проектов, которые приносят нам на разбор. Ниже восемь самых частых, каждый по одной сетке: как выглядит, чем именно становится хуже, по какому раннему признаку ловится до старта и чем лечится. Ошибки выбора инструмента — отдельный жанр, мы разобрали его в статье про границу между ИИ и скриптом; здесь речь о том, как хоронят проекты с правильно выбранным инструментом.
1. Большой взрыв
Как выглядит. Проект начинается со слова «комплексный»: все отделы, единая платформа, дорожная карта на полтора года, управляющий комитет из десяти человек. Первые месяцы уходят на схемы процессов всего предприятия, следующие — на согласование схем, дальше — на пересогласование, потому что за это время процессы успели измениться.
Чем хуже. Механика провала — в скорости обратной связи. При работе с одним процессом ошибку видно через месяц и она стоит недели. При большом взрыве первая обратная связь приходит через год, когда бюджет израсходован, а менять курс поздно. Компания получает не работающую систему, а выставку схем — и стойкую аллергию на тему у всех, кто в комитете сидел.
Есть и вторая механика, менее заметная: за полтора года мишень уезжает. Спонсор проекта уходит на другую должность — проект сиротеет на уровне совета директоров. Меняются приоритеты, люди, сами процессы: схемы, согласованные в январе, к декабрю описывают компанию, которой больше нет. Большой проект целится в точку, где мишень висела на старте, — и чем он больше, тем дальше она успевает уехать.
Ранний признак. В плане проекта нет процесса, который заработает первым. Есть «этап обследования» на квартал — а строки «через шесть недель документы потока X заводятся без человека» нет.
Лечение. Один процесс, шесть недель, цифры «до и после», решение о следующем. Тираж — по факту эффекта, платформа — как итог серии работающих процессов, если она вообще понадобится.
2. Забетонированный хаос
Как выглядит. Процесс исторически ходит через семь окон, три перекладывания в Excel и одно устное согласование у Веры из бухгалтерии. Его автоматизируют «как есть» — со всеми семью окнами, потому что перестраивать некогда.
Чем хуже. Кривой маршрут был плох, но оставался мягким: люди могли его обойти, сократить, договориться. После автоматизации он застывает: обходной путь теперь означает «сломать систему», а каждое искривление обросло кодом, который его поддерживает. Через год спрямить процесс стоит дороже, чем стоило до автоматизации, потому что теперь надо переделывать и процесс, и систему. Хаос не исчез — он стал быстрым, дорогим и официальным.
Ранний признак. На вопрос «почему этот шаг устроен так» звучит ответ «исторически сложилось». Каждый такой ответ — это искривление, которое вы собираетесь залить бетоном.
Лечение. Спрямление до автоматизации. Убрать лишние шаги — бесплатно; убрать их из работающей системы — проект. Полезное правило: автоматизируется процесс, который вы готовы показать новому сотруднику как образец. Остальные сначала чинятся.
3. Внедрение втайне от тех, кто работает
Как выглядит. О системе команда узнает в день запуска. Иногда это осознанная тактика — «чтобы не пугать людей раньше времени». Вопрос «что будет с нами» повисает без ответа, и каждый отвечает на него себе сам, обычно худшим вариантом.
Чем хуже. Люди, которые видят в системе угрозу, топят ее не митингами, а тишиной. Спорные случаи не разбираются — «система же умная, пусть сама». Кривой вход не поправляется. Параллельно возрождается старый ручной процесс «для надежности», и теперь работа делается дважды: системой и втихую руками. По отчетам автоматизация работает, по факту компания платит за оба процесса сразу — это дороже, чем было до старта.
Ранний признак. В проекте нет ни одного человека из тех, кто делает процесс руками. Требования собраны с руководителей, приемку подписывает директор, исполнители узнают о системе из рассылки.
Лечение. Владелец процесса из исполнителей — с первого дня и с реальным правом влиять. Замер объявлен заранее вместе с судьбой освободившихся часов: куда они пойдут, названо письменно до запуска. Люди саботируют неизвестность гораздо охотнее, чем перемены.
И отдельное внимание — среднему звену. Самое упорное сопротивление обычно идет от руководителя, чья ежедневная ценность состояла в ручном контроле потока: он распределял, проверял, держал в голове. Система забирает именно эту роль, и без новой — владелец очереди спорных, хозяин метрик процесса, арбитр сложных случаев — человек будет защищать старую всеми доступными способами, и позиция позволит ему делать это эффективно.
4. Все или ничего
Как выглядит. Система спроектирована так, что обязана обработать сто процентов потока. Очереди спорных случаев нет: либо конвейер полностью автоматический, либо «зачем мы вообще платили».
Чем хуже. Стопроцентная обработка вариативного входа достигается единственным способом — система перестает сомневаться. Нестандартное письмо, кривой скан, незнакомый формат — все проходит по ближайшему похожему маршруту. До автоматизации ошибки делали люди: громко, с вопросами коллегам, с возможностью поймать. Теперь их делает система — молча, уверенно и однообразно, и всплывают они через месяц в закрытии периода. Ошибка сменила характер с громкой на тихую, и это чистое ухудшение.
Ранний признак. В архитектуре нет ответа на вопрос «что происходит, когда система не уверена». Подрядчик на этот вопрос отвечает «она будет уверена».
Лечение. Очередь спорных как элемент архитектуры, а в договоре — честная доля потока, уходящая человеку. Система, которая умеет сказать «не знаю», надежнее системы, которая не умеет. Три четверти потока без человека — рабочая цифра, от которой стоит отталкиваться в ожиданиях.
5. Вечный пилот
Как выглядит. Тест начался в марте. Сейчас август, статус прежний: «наблюдаем». Ручной процесс не выключен, система работает параллельно, решение о полном переходе откладывается до «еще одной контрольной недели» — восьмой по счету.
Чем хуже. Все это время компания оплачивает оба процесса: ручной полностью и автоматический полностью. Двойная работа и двойная стоимость — дороже, чем было до старта, причем каждый месяц. Причина всегда одна: на старте никто не записал, при каких цифрах пилот считается успешным, поэтому любое значение метрик можно трактовать как «надо еще посмотреть». Решение без критерия по определению бесконечно.
Держится конструкция на том, что в моменте она удобна всем. Подрядчику капает сопровождение пилота. Менеджеру проекта не нужно подписываться под решением, за которое потом отвечать. Команде привычно: старый процесс жив, новый «тестируется», ничего не меняется. Неудобна она только владельцу денег — но именно он узнает о положении дел последним, из статуса «наблюдаем» в квартальной презентации.
Ранний признак. В договоре пилота нет числовых критериев приемки и нет даты решения. Какие пары метрик фиксировать и как не обмануться при замере — разобрано в статье про цифры процессов с LLM.
Лечение. Теневой режим — недели, а не кварталы; метрики приемки — в договоре числом; в календаре — дата, когда по этим числам принимается одно из двух решений: переключаемся или закрываем. Обе развязки лучше вечной середины.
6. Система-сирота
Как выглядит. Проект сдан, акт подписан, подрядчик ушел, все довольны. Через три месяца у банка сменился формат выгрузки, очередь спорных не разбиралась с июня, у поставщиков появились новые шаблоны счетов. Система работает все хуже, и никто в компании не знает, чья она.
Чем хуже. Деградация тихая — медленное сползание качества вместо честной поломки, и замечают его, когда цифры уже плохие. К этому моменту процесс перестроен под систему — людей, которые делали его руками, перевели на другие задачи, и возврат назад стоит дороже, чем стоил запуск. Компания застревает между полурабочей системой и утраченным ручным навыком — положение хуже любой из исходных точек.
Ранний признак. В бюджете проекта нет строки сопровождения, в штатном расписании — часа в день на разбор спорных, а на вопрос «кто оператор системы» отвечают «она же автоматическая».
Лечение. Роль оператора процесса назначается до запуска: час в день на очередь спорных и связь с подрядчиком. Сопровождение — в бюджете с первого дня, регулярный прогон на эталонной выборке — в регламенте. Автоматизация сокращает рутину, но не отменяет владение процессом.
7. Экономия на скучном
Как выглядит. Из сметы вычеркивают самые унылые строки: журнал решений, мониторинг, алерты, валидацию входа, права доступа. Логика знакомая: «модель же умная, зачем вокруг нее столько бюрократии». Смета худеет на треть, все довольны.
Чем хуже. Первые недели разницы нет — скучные строки незаметны, пока все хорошо. Потом случается первое тихое расхождение, и выясняется, что без журнала вопрос «почему документ ушел туда» превращается в неделю археологии; без алертов о смене формата система месяц складывала мусор; без прав доступа непонятно, кто вообще мог вмешаться. До автоматизации у ошибки был автор и объяснение. Теперь есть только результат. Разбирательство стоит дороже всей сэкономленной трети.
Ранний признак. В КП нет слов «журнал», «очередь спорных», «мониторинг» — или они вычеркнуты на торге. Как устроен контур проверки, который ловит проблемы до последствий, — в разборе eval как дисциплины.
Лечение. Обвязка — страховка с известной ценой, как бы ее ни называли на торге: она стоит доли сметы и окупается первым же инцидентом. Резать смету честнее сужением охвата пилота — меньше типов документов, один источник — при полном контуре вокруг того, что осталось.
8. Заложник подрядчика
Как выглядит. Система работает, но код в чужом репозитории, промпты — «ноу-хау исполнителя», документации нет, настройки знает один человек с той стороны. Через год подрядчик удваивает ставку сопровождения, отвечает неделями или просто исчезает вместе с ООО.
Чем хуже. До автоматизации компания зависела от своих сотрудников — с их отпусками и увольнениями, но своих: их можно было мотивировать, страховать, дублировать. Теперь критический процесс зависит от чужого юрлица, на которое нет рычагов. Смена подрядчика без кода и документации равна повторной разработке — и это положение слабее исходного, где процесс хотя бы целиком принадлежал компании.
Ранний признак. В договоре нет пункта о переходе прав на код, промпты и настроенные модели. На просьбу показать документацию отвечают «у нас все в головах, зато быстро».
Лечение. Права переходят заказчику после оплаты этапа — пунктом договора; репозиторий — ваш или с вашим доступом; документация и передача знаний — отдельный пункт приемки. Нормальный подрядчик на это соглашается спокойно: он удерживает клиента качеством, слабый — заложничеством, и по реакции на этот пункт их видно заранее.
Проверка на заложничество занимает пять минут и делается до подписания: попросите показать, как выглядит передача, — выгрузка репозитория, перечень настроек, инструкция развертывания на чистом сервере. У подрядчика, который передает проекты регулярно, эти артефакты готовы и он показывает их без пауз. Пауза длиной в «э-э-э» — это и есть ответ.
Сводная таблица: признак и лечение
| Антипаттерн | Ранний признак | Лечение |
|---|---|---|
| Большой взрыв | В плане нет процесса, работающего через 6 недель | Один процесс, цифры, потом тираж |
| Забетонированный хаос | «Исторически сложилось» в ответах | Спрямить маршрут до автоматизации |
| Внедрение втайне | Исполнителей нет в проекте | Владелец из исполнителей, судьба часов объявлена |
| Все или ничего | Нет ответа «что, когда система не уверена» | Очередь спорных как архитектура |
| Вечный пилот | Нет критериев числом и даты решения | Метрики в договоре, дата развязки |
| Система-сирота | Нет строки сопровождения и оператора | Оператор с часом в день, прогоны по регламенту |
| Экономия на скучном | Из КП вычеркнуты журнал и мониторинг | Полный контур на суженном охвате |
| Заложник подрядчика | Нет пункта о правах и документации | Права после оплаты этапа, передача знаний |
Общий знаменатель
Если сжать восемь пунктов до одного: автоматизация — это изменение процесса и людей вокруг него, и ломается она в организационной части, там, где нет обратной связи, владельца и заранее записанных правил. Восемь признаков из таблицы проверяются за час чтения плана и договора — час, который страхует бюджет всего проекта.
Осторожность по этому чек-листу дешева — восемь вопросов, каждый закрывает свой антипаттерн:
- Какой процесс работает через шесть недель и что он делает?
- Что в маршруте процесса мы спрямляем до автоматизации?
- Кто из исполнителей входит в проект и куда пойдут освободившиеся часы?
- Что происходит, когда система не уверена, и какая доля потока уйдет человеку?
- Какие числа означают успех пилота и в какую дату принимается решение?
- Кто оператор системы после запуска и что входит в сопровождение?
- Где в смете журнал решений, мониторинг и очередь спорных?
- Когда и как права на код, промпты и модели переходят к нам?
Подрядчик, у которого на все восемь есть спокойные ответы, скорее всего уже наступал на эти грабли за чужой счет — это самый полезный опыт, который можно купить.
Что сделать до старта
Если проект еще не начат — порядок такой. Выберите один процесс по цифрам; когда кандидатов несколько и мнения расходятся, спор закрывает ИИ-аудит процессов — две недели, и у каждого кандидата появляется расчет вместо лоббиста, а список «что не трогать» страхует от половины описанного выше. Дальше — пилот ИИ-автоматизации одного процесса: с теневым режимом, очередью спорных, журналом, метриками приемки в договоре и переходом прав — устройство пилота само по себе закрывает антипаттерны с четвертого по восьмой, потому что выросло из них.
А если какой-то из восьми узнался в уже идущем проекте — чинить не поздно почти никогда: критерии дописываются, оператор назначается, очередь спорных достраивается. Дороже всего обходится продолжать как шло — по расчету двойной работы из пятого пункта, каждый месяц ожидания стоит двух.