Провалившийся проект автоматизации редко выглядит как катастрофа. Сервер работает, лицензии продлеваются, в отчёте подрядчика всё зелёное. Просто менеджеры снова ведут сделки в таблице, кладовщик держит вторую тетрадь, а бухгалтер вбивает счета руками — как и два года назад. Формально система есть. Фактически её нет.
Мы регулярно заходим в такие проекты вторым подрядчиком: разобрать, что осталось, и решить — чинить или сносить. Причины повторяются с неприличной регулярностью, и почти ни одна из них не техническая. Модель распознала накладную, интеграция отдала данные, робот дозвонился. Сломалось всё вокруг.
Ниже — семь причин, по которым проекты останавливаются. По каждой: как это выглядит изнутри компании, по каким признакам видно ещё до подписания договора и что с этим делать. В конце — что делать, если деньги уже потрачены.
Провал редко объявляют вслух
Проект не закрывают приказом. Он просто перестаёт двигаться: релиз переносится на после отпуска, потом на после отчётного периода, потом ответственный увольняется. Через год система формально в эксплуатации, ей пользуются два человека из двадцати, а на вопрос «что дало внедрение» никто не может ответить цифрой.
Состояние дорогое, потому что расходы продолжают идти. Самая крупная статья — не платёж подрядчику, а параллельная работа: люди ведут и старый учёт, и новый. Ниже модельный расчёт для компании на 80 человек, которая год назад запустила CRM и не довела дело до конца.
Причины 1–3: проект был обречён до первой строчки кода
Причина 1. Автоматизировали хаос вместо того, чтобы сначала его убрать. Выглядит так: на вопрос «как у вас проходит согласование заказа» три сотрудника дают три разных ответа, и все три — правда. Подрядчик получает техзадание, написанное со слов одного из них, и переносит в систему один вариант. Через месяц выясняется, что остальные два тоже нужны. В системе появляются исключения, затем исключения из исключений. Логика становится сложнее исходного беспорядка — беспорядок хотя бы допускал живую договорённость в коридоре.
Распознаётся заранее одним упражнением: попросите описать процесс на одной странице, от входа до результата, без слов «обычно», «по ситуации» и «зависит от менеджера». Если страница не получается за два подхода — автоматизировать рано. Что делать: неделя-две на описание и сокращение шагов вручную. По нашей практике на этом этапе из процесса выпадает четверть-треть действий: согласования, которые никто не читает, поля, которые никто не заполняет, отчёты, которые никто не открывает. Автоматизировать нужно то, что осталось — каждый лишний шаг стоит денег дважды, на разработке и потом на поддержке.
Причина 2. У процесса нет владельца со стороны заказчика. Выглядит так: со стороны подрядчика есть аналитик, разработчик и руководитель проекта, со стороны компании — генеральный директор с сорока минутами в месяц и ответственный без полномочий. Любой спорный вопрос (кто закрывает сделку — менеджер или руководитель отдела, что делать с заявкой без телефона) уходит в переписку и живёт там неделями. За два месяца таких вопросов набирается тридцать, и проект стоит на всех тридцати сразу.
Владелец сам работает в процессе или руководит теми, кто работает. Ему нужны три вещи: 4–6 часов в неделю в календаре на время проекта, право менять регламент без совещания с собственником и персональная ответственность за результат в цифрах. Если ни у кого в компании этих трёх вещей нет, проект стоит отложить. Подрядчик не может быть владельцем вашего процесса — он может только его собрать.
Причина 3. Данных нет или они грязные. Выглядит так: одна и та же позиция записана в справочнике четырьмя способами, у трети контрагентов не заполнен ИНН, а история заказов начинается с даты последнего переезда учётной системы. Аналитика на таких данных даёт результат, который сотрудники отказываются принимать, — и они правы. Прогноз спроса, скоринг, рекомендации требуют не просто данных, а данных за 12–24 месяца с понятной структурой.
Распознаётся до старта за один вечер: выгрузите справочники в таблицу и посчитайте дубли, пустые обязательные поля и глубину истории. Что делать: чистку данных выносить в отдельный этап с отдельным сроком и отдельной приёмкой, до начала основной разработки. Меньше двух-трёх недель она занимает редко и почти всегда требует человека со стороны заказчика — только он знает, что «Труба 20х2» и «труба ВГП 20» это одно и то же. Автоматическое сопоставление снимает основную массу, но хвост в 200–500 спорных позиций по нашей практике всегда разбирается руками.
Причины 4–5: не тот первый участок и нечем доказать эффект
Причина 4. Первым взяли самый сложный участок. Логика понятна: болит сильнее всего там, значит, туда и идём. На практике самый больной участок обычно и самый запутанный: больше всего исключений, участвуют три отдела, цена ошибки высокая. Проект уходит в согласования на полгода, за это время у компании меняется приоритет, и всё останавливается, не показав ни одного результата. Внутри складывается вывод: автоматизация — это долго и без толку. Второй проект после такого не продать даже с хорошим обоснованием.
| Признак участка | Плохой первый выбор | Хороший первый выбор |
|---|---|---|
| Объём операций | 20 сделок в месяц, каждая уникальна | от 300 однотипных операций в месяц |
| Правила | решение зависит от опыта конкретного человека | правило умещается на одной странице |
| Данные | лежат в почте, мессенджерах и головах | уже в системе, история от 6 месяцев |
| Цена ошибки | ошибка стоит контракта или лицензии | ошибка видна сразу и правится за 5 минут |
| Ответственность | процесс делят три отдела поровну | у процесса один руководитель |
Что делать: первым берут участок, который даёт видимый результат за 4–8 недель, даже если экономия там скромнее. Обработка входящих счетов и накладных — почти эталон: объём большой, правила простые, ошибка стоит пяти минут проверки. Такой проект окупается сам и, что важнее, покупает доверие команды и право на второй, сложный шаг. Порядок «сначала показать, потом усложнять» экономит больше, чем любая оптимизация архитектуры.
Причина 5. Не сделали начальный замер. Через полгода после запуска собственник спрашивает, что дало внедрение, и никто не может ответить. Не потому, что эффекта нет, а потому, что не с чем сравнивать: сколько часов уходило на обработку заявки раньше, никто не считал, а память сотрудников тут бесполезна — она подстраивается под текущее положение дел. Восстановить показатели задним числом нельзя. Проект без доказанного эффекта режут первым при любом сокращении бюджета, независимо от того, работает он или нет. Замер занимает одну-две недели до начала работ и стоит копейки на фоне проекта. Минимальный набор:
- время цикла: сколько часов и календарных дней проходит от входа заявки или документа до результата — на выборке в 30–50 случаев
- объём: сколько операций в месяц, с разбивкой по типам и по пикам внутри месяца
- трудозатраты: сколько человеко-часов в неделю уходит на участок — по хронометражу, а не по ощущениям руководителя
- доля ошибок и переделок: сколько документов возвращается на исправление, сколько заявок обрабатывается повторно
- потери на выходе: сколько заявок осталось без ответа, звонков пропущено, счетов оплачено с опозданием
- стоимость часа сотрудников участка с налогами — без неё остальные цифры не переводятся в деньги
Причины 6–7: команда и жизнь системы после запуска
Причина 6. Команду не предупредили, и она защищается. Выглядит так: в понедельник сотрудникам сообщают, что с сегодняшнего дня заявки ведутся в новой системе. Формулировка «теперь всё будет прозрачно» читается однозначно: меня считают, а следующим шагом сократят. Дальше начинается тихое сопротивление, и оно эффективнее открытого спора. Данные вносятся с задержкой и с ошибками, параллельно ведётся привычная таблица, на каждом разборе звучит «система неудобная». Формально никто не отказывается работать. Фактически система не наполняется, а без данных она бесполезна.
Система, которую внедрили без тех, кто в ней работает, всегда проигрывает таблице. Таблицу никто не навязывал.
Распознаётся до старта: спросите трёх линейных сотрудников, что они знают о проекте. Ответ «что-то там внедряют» означает, что вы уже в зоне риска. Что делать: за месяц до запуска объяснить конкретно — что меняется в рабочем дне, какая рутина уходит, как это влияет на премию. Взять двух-трёх человек в рабочую группу и принять хотя бы часть их правок: люди защищают то, что помогали строить. И отдельно договориться, что первые два месяца показатели системы не используются для наказаний. Если данные сразу становятся поводом для штрафа, их качество падает на следующий же день.
Причина 7. Систему запустили и бросили. Автоматизация — не бетонная конструкция, а живая: меняется прайс, появляется новый склад, поставщик переделывает форму накладной, площадка меняет API, приходит сотрудник, которого никто не обучил. По нашей практике без сопровождения решение начинает деградировать через 3–4 месяца: точность распознавания падает, часть сценариев перестаёт срабатывать, люди возвращаются к ручному обходу. Ещё через полгода дешевле списать, чем чинить.
Что делать: закладывать сопровождение в первоначальный расчёт, а не искать бюджет потом. Ориентир — 15–25% стоимости внедрения в год, и это не страховка от поломок, а деньги на изменения: обновление базы знаний и правил, разбор пограничных случаев, новые сценарии. Второе условие — измеримая ответственность. Кто-то раз в неделю смотрит на 3–5 показателей: долю автоматически обработанных документов, число ручных правок, время цикла, — и реагирует, когда цифра поехала. Без этого деградацию замечают, когда ей уже полгода.
Что делать, если проект уже провален
Списывать целиком стоит реже, чем кажется. В остановившемся проекте почти всегда есть годная часть: описанный процесс, настроенные интеграции, вычищенный справочник. Задача — отделить её от неработающего и принять решение на цифрах, а не на обиде.
- 1Остановить расходы, которые идут вхолостую. Лицензии, облако и подписки на сервисы, которыми никто не пользуется, — это обычно 20–60 тысяч рублей в месяц, списывающихся по инерции.
- 2Разобрать, что реально работает. Пройти по системе с двумя-тремя пользователями и разметить: работает и используется, работает и не используется, не работает. Третья категория чаще всего меньше, чем считает руководство.
- 3Найти причину, а не виноватого. Обычно сразу обнаруживаются две-три причины из семи выше. Если они организационные, смена подрядчика ничего не изменит: новый упрётся ровно в то же самое.
- 4Сузить задачу до одного участка. Не чинить всю систему, а выбрать один процесс с понятным объёмом и живым владельцем, довести до рабочего состояния за 4–6 недель и показать команде результат. Один работающий участок восстанавливает доверие лучше любой презентации.
- 5Замерить текущее состояние сейчас. Если начального замера не было, замерьте сегодняшние цифры — они станут базой для второй попытки. Это единственная позиция из прошлого проекта, которую нельзя восстановить, но можно завести заново.
- 6Честно посчитать вариант с выключением. Иногда правильный ответ — вернуться к ручному процессу, забрать данные и закрыть тему. Если участок даёт 30 операций в месяц, а сопровождение стоит 40 000 ₽, ручная работа дешевле. Это нормальное инженерное решение, а не поражение.
Закономерность простая: почти все провалы автоматизации — это провалы подготовки, а не технологий. Порядок в процессе, живой владелец, чистые данные, скромный первый шаг и начальный замер стоят двух-трёх недель работы до старта. Проект без них обходится на порядок дороже и обычно всё равно не доезжает.
