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