Решение прекратить проект принимается позже, чем следовало бы, почти всегда. Причина не в упрямстве, а в понятном человеческом свойстве: чем больше уже потрачено, тем труднее остановиться.
Логика при этом обратная правильной. Потраченное не вернётся ни при каком решении — оно не должно влиять на выбор. Значение имеет только одно: окупятся ли деньги, которые вы потратите дальше.
Это единственный критерий, и он редко произносится вслух.
Признаки, что пора остановиться
Достижимость не подтвердилась на ваших данных
Самый честный и самый ранний признак. Проверка на архиве реальных случаев показала, что система закрывает существенно меньшую долю, чем нужно для окупаемости.
Что делать: пересчитать окупаемость по фактической доле. Если проект перестаёт сходиться — останавливаться здесь дёшево.
Материалов нет, и написать их некому
Выяснилось, что значительная часть знаний нигде не записана, а выделить людей на их написание компания не может.
Это не техническая проблема, и техникой она не решается. Проект не отменяется, а откладывается — до момента, когда материалы появятся.
Процесс меняется быстрее, чем автоматизируется
Пока идёт разработка, бизнес перестроил процесс. Такое случается, и продолжать автоматизировать то, чего скоро не будет, бессмысленно.
Расчёт не сходится по фактическим числам
Реальный поток оказался вдвое меньше ожидаемого, стоимость эксплуатации вдвое выше, доля автоматизации ниже. Любое из трёх может обнулить окупаемость.
Некому сопровождать
Владельца материалов так и не назначили, ответственного нет. Система, запущенная в таких условиях, деградирует за месяцы, и запуск лишь отсрочит признание проблемы.
Ушёл заказчик проекта внутри компании
Тот, кому это было нужно, сменил должность или ушёл. Проект без внутреннего владельца не доходит до эксплуатации, даже если технически готов.
Прошли все сроки, а результата нет
Не «отстаём на месяц», а «третий перенос и непонятно, что осталось». Обычно означает, что задача была понята неверно с самого начала.
Признаки, которые кажутся поводом, но не являются
Симметрично важно: не останавливать то, что можно починить.
Качество ниже ожидаемого на первом прогоне. Нормально. Первый результат почти всегда хуже финального — вопрос в том, есть ли понятный путь к улучшению.
Часть случаев уходит человеку. Так и должно быть. Полная автоматизация — не цель, а признак того, что система перестала сомневаться.
Сотрудники недовольны. Организационная проблема, решаемая объяснением и участием, а не техническая — «Политика использования ИИ в компании».
Система ошибается. Вопрос в частоте и в цене ошибки, а не в самом факте. Ошибаются и люди.
Дороже, чем планировали. Смотрите на окупаемость по новым числам, а не на отклонение от плана. Проект, подорожавший на треть и всё равно окупающийся за год, останавливать не нужно.
Как отличить починимое от непочинимого — «Что делать, если ИИ не работает».
Точки выхода: где их ставить
Решение остановиться дёшево тогда, когда оно предусмотрено заранее.
| Точка | Потрачено | Что известно |
|---|---|---|
| После разбора процесса | ~5% | что автоматизируем, есть ли доступы, состояние материалов |
| После проверки достижимости | ~10% | какую долю система реально закроет |
| После пилота на одном сценарии | ~35% | как ведёт себя на реальном потоке |
| После первого месяца эксплуатации | ~70% | фактические показатели |
Вторая строка — главная. Проверка достижимости на архиве реальных случаев стоит около десятой части бюджета и отвечает на вопрос, ради которого затевается всё остальное.
Это стоит зафиксировать в договоре как этап с правом прекращения — «Договор на разработку ИИ».
Без таких точек решение принимается тогда, когда потрачено всё, и остановка ощущается как полная потеря — хотя фактически это признание того, что стало известно раньше.
Что забрать из остановленного проекта
Даже прекращённый проект оставляет то, что стоит сохранить — иначе следующая попытка начнётся с нуля.
Разбор процесса. Описание того, как всё устроено на самом деле, включая негласные правила. Это ценность сама по себе: часто такого описания в компании не существовало.
Подготовленные материалы. Сведённые и вычищенные документы полезны и без системы — людям тоже.
Проверочный набор случаев. Пригодится при следующей попытке.
Понимание, почему не получилось. Записанное, а не оставшееся в памяти участников.
Обнаруженные проблемы процесса. Проекты автоматизации регулярно вскрывают то, что не работало и без них: расхождения между документами и практикой, потерянные заявки, дублирующиеся операции.
Иногда это оказывается ценнее самой системы: проблему нашли, она чинится организационно, и автоматизация становится не нужна.
Как останавливать
Назовите причину прямо. «Достижимая доля оказалась 30% вместо необходимых 55%, окупаемость не подтверждается» — это результат, а не провал.
Зафиксируйте, что сделано и что забираете.
Определите условие возврата. «Вернёмся, когда будут записаны регламенты» или «когда поток вырастет вдвое» — часто проект не отменяется, а откладывается.
Не ищите виноватого. Отрицательный результат проверки — это то, ради чего проверка и делалась.
Скажите команде. Проект, тихо заглохший, отравляет отношение к следующему сильнее, чем честно закрытый.
Частые вопросы
Когда нужно остановить ИИ-проект?
Когда достижимость не подтвердилась на ваших данных, когда материалов нет и написать их некому, когда процесс меняется быстрее, чем автоматизируется, когда расчёт не сходится по фактическим числам или когда некому сопровождать систему после запуска.
Стоит ли учитывать уже потраченное?
Нет. Потраченное не вернётся ни при каком решении и не должно влиять на выбор. Единственный критерий — окупятся ли деньги, которые вы потратите дальше. Учёт уже вложенного — самая частая причина, по которой проекты доводят до конца вопреки расчёту.
Как понять, что проблема починима?
По наличию понятного пути к улучшению. Низкое качество на первом прогоне, часть случаев, уходящая человеку, недовольство сотрудников и превышение бюджета — обычно не повод останавливаться. Отсутствие материалов, несходящийся расчёт по фактическим числам и отсутствие ответственного — повод.
Где ставить точки выхода?
Главная — после проверки достижимости на реальных данных: потрачено около десятой части бюджета, а ответ на ключевой вопрос уже есть. Дополнительно — после разбора процесса, после пилота и после первого месяца эксплуатации. Их стоит зафиксировать в договоре как этапы с правом прекращения.
Что остаётся после остановленного проекта?
Описание процесса с негласными правилами, подготовленные и вычищенные материалы, набор проверочных случаев, зафиксированная причина неудачи и обнаруженные проблемы процесса. Последнее нередко оказывается ценнее самой системы: проблема находится и решается организационно.
Как правильно закрыть проект?
Назвать причину прямо и в цифрах, зафиксировать сделанное, определить условие возврата, если проект откладывается, а не отменяется, и сообщить команде. Тихо заглохший проект вредит отношению к следующим сильнее, чем честно закрытый.
Что дальше
Как считать до старта, чтобы не дойти до остановки — «ROI ИИ-проекта до старта». Где закрепить точки выхода — «Договор на разработку ИИ». Как отличить починимое — «Что делать, если ИИ не работает». Как заложить резерв и этапы — «Распределение бюджета на ИИ».
Проверка достижимости на ваших данных до основных вложений — часть аудита, с которого начинается работа по внедрению ИИ.