Проекты автоматизации проваливаются по семи повторяющимся причинам: автоматизируется не тот процесс, у процесса нет владельца, данные грязнее, чем считали на старте, объём работ растёт быстрее команды, интеграции собраны без обработки сбоев, людей не предупредили, а метрики «до» никто не снял. Ни одна из семи не техническая — модель распознаёт документ, робот дозванивается, обмен с 1С работает. Ломается всё вокруг них.
Важнее другое: каждая из семи причин видна задолго до того, как кончатся деньги. У проекта на 14 недель самая ранняя причина проявляется на первой неделе обследования, самая поздняя — в день приёмки. Между появлением признака и остановкой проекта обычно проходит от трёх до восьми недель — этого хватает, чтобы вмешаться, если знать, на что смотреть.
Отдельный разбор тех же семи причин с точки зрения выбора — как распознать риск до подписания договора — у нас есть в статье «Семь причин, по которым проекты автоматизации проваливаются». Здесь другая задача: договор подписан, деньги идут, команда работает. Ниже — карта ранних признаков по неделям, разбор каждой причины, светофор из 12 вопросов для статус-встречи, таблица зон ответственности и расчёт того, что остаётся у компании после остановки на середине.
Провал проекта и неверно выбранная задача — разные болезни
Первое, что нужно сделать при первых признаках беды, — понять, какая из двух ситуаций перед вами. Их лечат по-разному, а путают почти всегда, и из-за этого меняют подрядчика там, где надо менять участок, или наоборот — годами чинят задачу, которую вообще не стоило брать.
Задача выбрана верно: объём операций есть, правило формализуется, эффект посчитан и подтверждается замером. Но проект не доезжает из-за управления — решения зависают, объём растёт, данные не готовят, людей не готовят. Лечится перезапуском управления: назначением владельца, заморозкой объёма, письменным журналом решений. Обычно это 2–3 недели и 10–15 % остатка бюджета.
Управление в порядке, команда работает, сроки держатся — а смысла нет. Операций меньше, чем нужно для окупаемости; правило не формализуется, потому что каждое решение зависит от опыта конкретного человека; поток исчезает через полгода вместе с сезоном или контрактом. Здесь перезапуск управления не поможет: сколько ни улучшай проект, экономика не сойдётся. Лечится только сменой участка.
| Что смотрим | Провал проекта | Неверно выбранная задача |
|---|---|---|
| Объём операций на участке | есть и стабилен: от 300 однотипных операций в месяц | меньше 100 операций в месяц или объём падает |
| Правило | формализуется, но его никто не утвердил | не формализуется: три эксперта дают три разных ответа и все правы |
| Кто тормозит | решения, доступы, данные, приоритеты | никто, работа идёт по плану |
| Что говорит расчёт окупаемости | сходится, если довести проект | не сходится даже при идеальном исполнении |
| Что делать | перезапустить управление: владелец, заморозка объёма, журнал решений | остановиться и выбрать другой участок, забрав данные и описание |
| Помогает ли смена подрядчика | нет: новый упрётся в те же зависшие решения | нет: он добросовестно сделает то, что не нужно |
Практический признак: если на вопрос «что мешает» команда называет людей и решения — это провал проекта. Если называет саму задачу («тут каждый случай уникальный», «в этом месяце заявок почти не было») — это неверный выбор участка, и разбираться надо не с проектом, а с методикой выбора. Как выбирают первый участок и что считают до старта, мы разбирали в материале о том, с чего начинать автоматизацию.
Карта ранних признаков: где какая причина всплывает
Дальше в статье разбирается модельный проект: компания на 140 человек, автоматизация обработки входящих заявок и первичных документов, бюджет 900 000 ₽, срок 14 недель, пять этапов, со стороны заказчика — владелец процесса и трое сотрудников участка. Недели в таблице привязаны к этому графику; если ваш проект длиннее или короче, пересчитайте пропорционально — важна не конкретная неделя, а этап, на котором признак становится наблюдаемым.
| Причина | Когда видно | Наблюдаемый признак | Что ещё можно сделать |
|---|---|---|---|
| 1. Автоматизируется не тот процесс | недели 1–2, обследование | процесс не описывается на одной странице без слов «обычно» и «по ситуации»; три сотрудника дают три разные схемы | остановить обследование на неделю, сократить шаги вручную, вернуться к выбору участка |
| 2. У процесса нет владельца | недели 2–3 | три и больше открытых вопросов старше 10 рабочих дней; на встречу приходит каждый раз новый заместитель | назначить владельца письменно, передать три полномочия, поставить час в календарь на весь проект |
| 3. Данные грязнее, чем считали | недели 3–4, первая боевая выгрузка | дубли в справочнике больше 10 %, пустые обязательные поля, история короче требуемой | вынести чистку в отдельный этап с отдельной приёмкой до начала разработки |
| 4. Переусложнение: объём растёт быстрее команды | недели 4–6, согласование прототипа | число сценариев выросло больше чем на 50 % от стартового, ни одно требование не снято | заморозить объём, ввести размен «новое требование вместо старого», остальное — в ручную очередь |
| 5. Интеграции без обработки сбоев | недели 6–9, стыковка систем | в техническом задании нет слов «очередь», «повтор», «журнал отказов»; не назван человек, который разбирает застрявшее | добавить очередь, повторы, журнал и адресата алерта — 3–5 дней работы, дешевле, чем потом |
| 6. Сопротивление людей | недели 8–12, пилот | доля заявок, заведённых в системе, ниже 20 % на третьей неделе пилота; рядом живёт актуальная таблица | две недели на объяснение и правки от пользователей, запрет использовать данные системы для наказаний |
| 7. Нет метрик до старта | недели 13–14, приёмка | на вопрос «что изменилось» никто не отвечает цифрой; сравнивать не с чем | снять показатели сегодня — они станут базой для второй попытки; задним числом не восстанавливаются |
Обратите внимание на плотность первой половины: четыре причины из семи видны до шестой недели, то есть до того, как потрачена половина бюджета. Это и есть главный практический вывод — контроль проекта имеет смысл ровно до середины, потому что дальше остаётся только выбирать между тремя развилками из последнего раздела.
Недели 1–3: не тот процесс и отсутствие владельца
Причина 1 проявляется на обследовании и выглядит безобидно: аналитик третью встречу подряд уточняет, как именно проходит согласование, и каждый раз получает новую схему. Признак, по которому это отличается от нормальной детализации, — рост числа исключений. Если на первой встрече исключений было четыре, на второй девять, а на третьей четырнадцать и они продолжают появляться, то описывается не процесс, а сумма личных договорённостей. Автоматизировать её можно, но система получится сложнее исходного беспорядка, а беспорядок хотя бы допускал живую договорённость в коридоре.
Что делать на этой неделе, пока не начата разработка: остановить обследование на 5–7 рабочих дней и сократить процесс руками. По нашей практике на этом шаге из процесса выпадает от четверти до трети действий — согласования, которые никто не читает, поля, которые заполняются формально, отчёты, которые не открывают. Каждый лишний шаг оплачивается дважды: на разработке и потом ежемесячно на поддержке. Если после сокращения процесс всё равно не ложится на одну страницу — это уже не провал проекта, а неверно выбранный участок, и надо возвращаться на шаг назад.
Причина 2 — отсутствие владельца процесса — самая частая и самая дешёвая в лечении, если поймать её на третьей неделе. Признак измеряемый: заведите журнал открытых вопросов с датами. Три и больше вопросов старше 10 рабочих дней означают, что решения принимать некому. Второй признак — состав статус-встречи: если на неё третий раз подряд приходит другой человек «за» ответственного, значит, ответственного нет, а есть очередь дежурных.
Утверждение правил без повторного согласования с собственником, право сказать «не в этот проект» новому требованию и право подписать приёмку этапа. Без всех трёх это не владелец, а передатчик вопросов. Роль, нагрузка в часах и что делать, если единственный владелец — собственник, разобраны в отдельной статье кластера.
Недели 3–5: данные и растущий объём
Причина 3 всплывает в момент первой боевой выгрузки, и почти всегда неожиданно для заказчика — потому что до этого о данных говорили в общих словах. В модельном проекте выгрузка выглядела так: справочник номенклатуры на 4 800 позиций, из них 620 дублей (13 %), у 34 % контрагентов не заполнен ИНН, история заказов — 7 месяцев вместо 18–24, нужных для прогнозной части. На таких данных можно построить обработку документов, но нельзя построить аналитику, и это выясняется на четвёртой неделе, когда аналитика уже в договоре.
Признак, по которому проблему видно раньше выгрузки: подрядчик не просил боевую выгрузку до подписания договора, а работал с подготовленными примерами. Подготовленные примеры всегда чистые — их готовит человек, который знает, как надо. Что делать на четвёртой неделе: выносить чистку в отдельный этап с отдельным сроком и отдельной приёмкой, до начала основной разработки. Автоматическая склейка в модельном проекте закрыла 4 100 позиций из 4 800, оставшиеся 700 разбирали руками: три человека по 6 часов в неделю в течение трёх недель — только сотрудник компании знает, что «Труба 20х2» и «труба ВГП 20» это одна позиция.
Причина 4 — переусложнение — начинается на согласовании прототипа и почти всегда исходит от заказчика, а не от подрядчика. Механика одинаковая: прототип показали, он понравился, и каждый участник встречи принёс по два пожелания. В модельном проекте стартовый объём был 18 сценариев, через пять недель согласований в списке оказалось 47, при этом не было снято ни одного. Каждый дополнительный сценарий — это 15 000–40 000 ₽ разработки и 1 000–2 000 ₽ в месяц последующей поддержки, потому что его придётся тестировать после каждого обновления.
Формулировка для протокола встречи: «требование принимается в текущий этап, если владелец процесса называет требование, которое из этапа выходит». Без размена объём растёт линейно со временем согласований, а бюджет и срок — нет. По нашей практике 80 % реального потока закрывается 6–8 сценариями; всё остальное дешевле оставить в ручной очереди и вернуться к нему через полгода, посмотрев на статистику, а не на предположения.
Недели 6–10: сбои интеграций и люди
Причина 5 — интеграции, собранные без обработки сбоев. Это единственная в списке причина, которая выглядит технической, но и она управленческая: сбои будут всегда, вопрос только в том, назначен ли человек, который их разбирает. Учётная система уходит на обслуживание, у площадки меняется формат ответа, сеть моргает, документ приходит с пустым обязательным полем. В модельном проекте при потоке 6 000 сообщений в месяц отказов было от 40 до 120 — от 0,7 до 2 %. Если такой отказ просто теряется, через месяц у компании расхождение в учёте, которое ищут неделю.
Признак, который видно в документах ещё до разработки: в техническом задании нет слов «очередь», «повтор», «журнал отказов» и не назван адресат уведомления. Что должно быть в рабочей схеме: входящее сообщение сначала попадает в очередь и только потом обрабатывается; при ошибке повтор идёт с нарастающей паузой — через 1, 5 и 30 минут; после третьей неудачи документ уходит в «ящик разбора», а ответственному приходит уведомление. Добавить это в уже начатую разработку — 3–5 рабочих дней. Добавлять после первого расхождения в учёте — те же 3–5 дней плюс неделя разбора и потерянное доверие к системе. Как связываются между собой учёт, сайт и каналы обращений, мы описываем в разделе «Интеграции».
Причина 6 — сопротивление — появляется на пилоте и почти никогда не выглядит как отказ работать. Люди не спорят: они заводят заявки с задержкой, заполняют обязательные поля формально, а рядом ведут привычную таблицу, которая остаётся актуальнее системы. Метрика, по которой это ловится за неделю: доля заявок участка, заведённых в системе в день поступления. На третьей неделе пилота нормальным считается 40 % и выше; ниже 20 % — это не «люди привыкают», а сигнал, что система в работе не участвует.
Лечится это не приказом. Работает три вещи: объяснить конкретно, что меняется в рабочем дне каждого и какая рутина уходит; взять двух-трёх будущих пользователей в рабочую группу и принять хотя бы часть их правок; письменно договориться, что первые два месяца данные системы не используются для наказаний. Последний пункт важнее первых двух: если показатели сразу становятся поводом для разбора, качество данных падает на следующий же день, и восстановить его дороже, чем разработать модуль.
Система, которую внедрили без тех, кто в ней работает, проигрывает таблице. Таблицу никто не навязывал, и она всегда актуальнее.
День приёмки: сравнивать не с чем
Причина 7 — единственная, которую нельзя исправить в момент обнаружения. Система работает, документы обрабатываются, менеджеры пользуются, а на вопрос собственника «что это дало» никто не отвечает цифрой. Не потому, что эффекта нет, а потому, что не с чем сравнивать: сколько часов уходило на обработку заявки до внедрения, никто не считал. Память сотрудников здесь бесполезна — она подстраивается под текущее положение дел, и через три месяца человек искренне помнит, что «всегда было примерно так же».
Проект без доказанного эффекта режут первым при любом сокращении бюджета — независимо от того, работает он или нет. Замер занимает 1–2 недели до старта работ и стоит на фоне проекта копейки; методику мы подробно разбирали в материале о том, как измерить эффект автоматизации. Минимальный набор — шесть показателей:
- время цикла: часы и календарные дни от входа заявки или документа до результата, на выборке в 30–50 случаев
- объём: операций в месяц, с разбивкой по типам и с указанием пиков внутри месяца
- трудозатраты: человеко-часов в неделю на участок, по хронометражу, а не по оценке руководителя
- доля переделок: сколько документов возвращается на исправление и сколько заявок обрабатывается повторно
- потери на выходе: заявки без ответа, пропущенные звонки, счета, оплаченные с опозданием
- полная стоимость часа сотрудников участка с налогами — без неё остальные пять цифр не переводятся в деньги
Если проект уже идёт, а замера нет, снимайте показатели сегодня. Они не докажут эффект текущего внедрения, но станут базой для второй попытки — и это единственная вещь из провалившегося проекта, которую нельзя восстановить задним числом, но можно завести заново за неделю.
Светофор: 12 вопросов для еженедельной статус-встречи
Все семь причин раскладываются в набор вопросов, которые задаются раз в неделю и требуют ответа цифрой или фактом, а не оценкой. Список ниже занимает на встрече 10–12 минут и заменяет отчёт о статусе, который обычно состоит из слова «работаем». Ответы записываются, потому что смысл не в одном срезе, а в динамике: два одинаковых красных ответа две недели подряд значат больше, чем четыре разных красных за месяц.
| Вопрос недели | Зелёный ответ | Красный ответ |
|---|---|---|
| 1. Сколько открытых вопросов старше 10 рабочих дней? | 0–1 | 3 и больше |
| 2. Владелец процесса был на встрече лично? | да, третью неделю подряд | прислал заместителя или пропустил |
| 3. Что изменилось в объёме работ за неделю? | ничего или размен: новое вместо старого | добавлено, ничего не снято |
| 4. Сколько сценариев сейчас против стартового числа? | рост меньше 20 % | рост больше 50 % |
| 5. Есть рабочий кусок, который можно показать? | да, крутится на боевых данных | только презентация или демостенд |
| 6. На чьих данных работал прототип на этой неделе? | на боевой выгрузке | на подготовленных примерах |
| 7. Сколько справочника вычищено от плана? | 80 % и больше | меньше половины |
| 8. Что происходит с документом, если интеграция вернула ошибку? | назван механизм повторов и человек, который разбирает | «такого не будет» или «посмотрим на эксплуатации» |
| 9. Сколько будущих пользователей видели систему своими глазами? | трое и больше | никто, кроме ИТ-специалиста |
| 10. Замер «до» лежит в письменном виде? | да, шесть показателей с датой снятия | «примерно помним» или «снимем потом» |
| 11. Дата запуска двигалась на этой неделе? | не двигалась или сдвинута вместе с новым планом | сдвинута второй раз без объяснения причины |
| 12. Какая доля реального потока идёт через систему? | 40 % и выше к третьей неделе пилота | ниже 20 % |
Правило реагирования: два красных ответа на одной встрече — предупреждение и запись в протокол. Те же два красных две недели подряд — останавливать разработку и разбираться, потому что дальше вы платите за код, который придётся переделывать. Четыре красных одновременно — созывать развилку из последнего раздела, не дожидаясь конца этапа. Отдельно стоит вопрос 12: он единственный измеряет не проект, а результат, и именно по нему потом отличают работающую систему от той, которой никто не пользуется.
Зоны ответственности: что обязан заказчик, а что подрядчик
Половина зависших проектов держится на честном непонимании, кто что должен. Заказчик считает, что купил результат «под ключ» и участие не требуется; подрядчик считает, что его дело — разработка, а данные и решения приносит клиент. Обе позиции разумны по отдельности и вместе дают стоящий проект. Таблица ниже — не философия, а список пунктов, которые имеет смысл перенести в договор дословно.
| Зона | Обязан обеспечить заказчик | Обязан обеспечить подрядчик |
|---|---|---|
| Решения по спорным правилам | принять решение в течение 5 рабочих дней | сформулировать вопрос с 2–3 вариантами и ценой каждого |
| Данные | дать боевую выгрузку и человека, который знает справочник | проверить пригодность данных до начала разработки и письменно сказать, если их мало |
| Доступы и среды | выдать тестовый контур и учётные записи за 5 рабочих дней | назвать полный список доступов на первой неделе, а не по мере надобности |
| Замер «до» | организовать хронометраж и дать ставки сотрудников | задать перечень показателей и форму, в которой они снимаются |
| Объём работ | не добавлять требования без размена | вести журнал изменений и называть цену каждой правки до её принятия |
| Люди | предупредить команду за месяц, выделить 2–3 человек в рабочую группу | обучить, записать короткие инструкции, снять возражения на пилоте |
| Сбои интеграций | назначить сотрудника, который разбирает застрявшие документы | построить очередь, повторы, журнал отказов и уведомления |
| Приёмка | подписывать по заранее записанному критерию, а не по впечатлению | сдавать на доле реального потока, а не на демонстрации |
Строчки левой колонки стоит проверить до подписания договора: если ни одну из них компания сейчас обеспечить не может, проект надо не начинать, а готовить. Что именно из этого имеет смысл записывать в договор и как формулировать приёмку, разобрано в статье о договоре на разработку; наши собственные обязательства и порядок работы описаны на страницах «Как мы работаем» и «Гарантии».
Сколько остаётся, если остановить проект на четвёртом месяце
Остановка на середине — не самый плохой исход, но считать его надо честно, потому что решение «доводить или сворачивать» принимается именно на этих цифрах. Расчёт ниже — для модельного проекта на 900 000 ₽ и 14 недель, остановленного в конце четвёртого месяца: оплачены три этапа из пяти, разработка сценариев начата, пилот не начинался. Ставка часа сотрудников заказчика — 1 100 ₽ с налогами.
Оговорка про полгода не формальная. Вычищенный справочник расходится обратно за 6–9 месяцев, если чистка не встроена в ежедневную работу; описание процесса устаревает вместе с регламентом и составом отдела; настроенный обмен ломается на первом же обновлении конфигурации или изменении формата у площадки. Через год от 360 000 ₽ переиспользуемого остаётся в лучшем случае половина, и это единственный аргумент в пользу того, чтобы принимать решение сейчас, а не «после отчётного периода».
Три развилки: спасать, сузить, остановить
Когда светофор показал четыре красных или проект стоит второй месяц, решений ровно три. Выбор между ними делается по двум входным данным: сколько красных ответов держится две недели подряд и какая из двух болезней перед вами — провал проекта или неверно выбранная задача.
- 1Спасать целиком
Условия: красных ответов три и меньше, задача выбрана верно, данные пригодны, владелец есть или назначаем на этой неделе. Содержание: перезапуск управления — письменный журнал решений со сроком 5 рабочих дней, заморозка объёма, размен требований, пересмотр плана с новыми датами. Занимает 2–3 недели и 10–15 % остатка бюджета. Работает примерно в трети случаев — реже, чем хочется, но это самый дешёвый из трёх вариантов.
- 2Сузить до одного сценария
Самый частый разумный исход. Из 47 сценариев выбирается один с наибольшим потоком и простым правилом, остальное официально выносится за границы проекта. Срок 4–6 недель, обычно 150 000–250 000 ₽ из остатка. Критерий приёмки записывается сразу и в потоке: через систему проходит не меньше 60 % операций этого сценария за 20 рабочих дней. Один работающий участок восстанавливает доверие команды лучше любой презентации, и второй заход после него продаётся внутри компании гораздо легче.
- 3Остановить и забрать активы
Правильный ответ, если перед вами неверно выбранная задача: операций меньше 100 в месяц, правило не формализуется, поток сезонный. Порядок действий: отключить лицензии и подписки, которыми никто не пользуется, выгрузить и сохранить данные, забрать описание процесса и карту данных, снять сегодняшние показатели как базу для будущего замера. Это инженерное решение, а не поражение: остановка на 877 700 ₽ дешевле, чем те же деньги плюс ещё 300 000 ₽ и система, которой не будут пользоваться.
Когда проект лучше не начинать
Часть провалов не лечится ни управлением, ни сужением, потому что решение о старте было принято в неподходящий момент. Пять ситуаций, в которых мы сами советуем перенести проект, а не искать подрядчика подешевле.
- На участке меньше 100 однотипных операций в месяц. Стоимость проекта почти не зависит от объёма, а экономия зависит прямо: при 80 операциях цена одной обработанной единицы получается выше, чем ручная работа. Уверенно окупается участок от 300 операций в месяц, промежуток 100–300 считается отдельно по своим ставкам, а ниже 100 браться не стоит.
- Ни у кого в компании нет 4–6 часов в неделю на проект. Не «в принципе нет времени», а буквально: посмотрите календарь предполагаемого владельца на ближайшие три месяца. Если там нет пустого часа в одно и то же время недели, проект встанет на второй неделе.
- Учётная система переезжает или меняется конфигурация. Автоматизация поверх системы, которая сама в процессе изменения, означает двойную работу: интеграции придётся переписывать после переезда. Разумный порядок — сначала переезд и стабилизация, потом автоматизация.
- Старт пилота приходится на пик сезона. Пилот требует внимания людей, а в пик у них его нет; в результате система получает худшие данные и худшее отношение именно тогда, когда формируется привычка. Сдвиг старта на 4–6 недель стоит дешевле, чем повторный запуск.
- Бюджета хватает ровно на внедрение и ничего не остаётся на первый год сопровождения. Решение без сопровождения начинает деградировать через 3–4 месяца вместе с прайсом, регламентами и форматами внешних систем. Стоимость и содержание сопровождения мы разбирали отдельно — если этой строки в бюджете нет, лучше уменьшить объём проекта, чем убрать поддержку.
Общая закономерность из всех семи причин: провалы автоматизации — это провалы подготовки и управления, а не технологий. Порядок в процессе, назначенный владелец, проверенные данные, замер «до» и заморожённый объём стоят двух-трёх недель работы до старта и одного часа в неделю во время проекта. Проект без них обходится в среднем вдвое дороже и обычно всё равно не доезжает до эксплуатации.
Проект не умирает в день остановки. Он умирает на той неделе, когда первый красный ответ записали и не стали обсуждать.
