«70% внедрений ERP проваливаются». Я дошёл до первоисточника — там написано совсем другое

У каждого, кто продаёт внедрение ERP, есть любимое число. Вы все, наверняка, его видели. Но откуда же оно взялось и какое отношение имеет к реальности?

Слайд номер три. «70% внедрений заканчиваются провалом». Пауза. Продавец смотрит, как собственник бледнеет. Дальше на этот страх можно продать что угодно: методологию, «авторский подход», ещё одного консультанта за 4 500 рублей в час. Вы ведь покупаете уже не программу. Вы покупаете место среди трёх выживших.

Я больше двадцати лет живу внутри таких проектов, с обеих сторон стола. И однажды решил проверить, откуда взялись эти семьдесят.

Вывод неприятный для всех. Цифра не выдумана. Выдуман её смысл.

Что на самом деле написал Gartner

Вот дословно. К 2027 году более 70% недавно внедрённых ERP-инициатив не смогут полностью достичь исходных целей бизнес-кейса. Так пишет Gartner в отчёте «What IT Leaders Must Do to Avoid Disappointing ERP Initiatives»: оценка на основе более чем 6 000 взаимодействий с клиентами, до четверти этих случаев могут закончиться катастрофически.

Вся подмена спрятана в двух словах: «не полностью».

Компания обещала совету директоров сократить запас на 20%, закрывать месяц за три дня вместо семи, отключить четыре старые системы и вдвое уменьшить ручной ввод. ERP запустили. Документы проводятся, отчёты формируются. Но запас упал только на 8%, месяц закрывается за пять дней, две старые системы живы, а отдел продаж частично вернулся в Excel.

Система работает. Компания работает. Бизнес-кейс выполнен не полностью. В статистике Gartner это неуспешная инициатива.

На слайде продавца та же строчка превращается в «семь из десяти внедрений рушатся». Разница примерно как между «не выполнил годовой план на сто процентов» и «обанкротился».

У Gartner в том же отчёте есть цифра полезнее: почти 75% опрошенных организаций признали, что их ERP-стратегия не была тесно связана со стратегией бизнеса. Опрос небольшой, 253 руководителя из компаний с выручкой от $50 млн, и сам отчёт предупреждает, что на весь рынок это не переносится.

Но механизм узнаваем без всякой статистики: сначала покупают систему, потом придумывают, какую управленческую проблему она должна была решить.

Откуда взялась легенда

До Gartner главной страшилкой был отчёт CHAOS 1994 года от Standish Group. Успешных проектов 16,2%, «проблемных» 52,7%, отменённых 31,1%.

Три вещи, которые продавец не покажет.

Первое: это не про ERP. 365 руководителей описали 8 380 программных проектов любого типа, от базы водительских удостоверений до систем бронирования.

Второе: успех определён жёстко. Полный объём, точный срок, согласованный бюджет. Система, запущенная на месяц позже и десять лет работающая на всю компанию, идёт в «проблемные».

Третье: чтобы получить «около 70%», надо сложить «проблемные» с отменёнными. То есть приравнять задержку к похоронам.

Свежий CHAOS 2020 говорит о базе более чем из 50 000 профилей проектов, но исходные данные закрыты для независимой проверки. И там наверху причин снова не марка программы, а спонсор, команда и среда.

Так тридцатилетняя статистика по чужой отрасли стала законом природы для любого ERP-проекта. Она живёт в презентациях, потому что «19% реально провалились» пугает слабо, а «70%» продаёт.

Скучная правда: примерно треть выходит за бюджет или срок

Panorama Consulting в отчёте 2024 года опросила 131 организацию, у 96,9% из них хотя бы одна фаза проекта работала не меньше года. Медианная компания: 750 сотрудников, $200,5 млн выручки. Медианный проект: $450 тысяч и 15,5 месяца.

Это выборка enterprise-проектов, не портрет российского МСБ. Но там хотя бы разведены бюджет, срок и результат (разбор отчёта в Accounting Today):

• 32,8% проектов вышли за бюджет;

• 31,3% закончили позже срока;

• 55% уложились в бюджет, 58% в срок.

Треть проектов едет по деньгам или времени. Серьёзно, но это не «семь из десяти легли». И главное: самая частая причина перерасхода не «плохая система», а неожиданная потребность в дополнительной технологии. Самая частая причина задержки - нехватка людей.

В обычной компании это выглядит так.

Понедельник. Начальник склада Сергей не может принять партию: терминалы не поддерживают протокол новой системы. Интегратор предлагает «небольшой дополнительный сервис», 340 тысяч. Главбух должна проверить обмены, но у неё квартальная отчётность, и она физически не в проекте до пятнадцатого числа. Коммерческий директор спрашивает, почему нельзя оставить старый Excel ещё на месяц. Очистку справочников не заложил никто: в ТЗ её нет, в бюджете нет, а мусор в номенклатуре есть.

Пятница. Руководитель проекта обновляет план. Срок уехал, бюджет вырос, виноватых четверо. Цифра «70%» не объяснила ни одной из этих причин.

И ни одна из них не лечится скидкой на лицензии.

ERP не проваливается в серверной

Исследователи двадцать лет находят один и тот же механизм.

Обзор 55 научных статей за 2000-2022 годы: на первых местах отсутствие поддержки высшего руководства, недостаточное обучение, несоответствие системы стратегии бизнеса, слабое проектное управление и нежелание людей работать в системе. Обзор 272 публикаций: поддержка руководства, соответствие ERP организации, обучение пользователей. Большинство значимых факторов авторы прямо называют организационными.

В списке нет пункта «купили недостаточно дорогую систему». Нет и пункта «интегратор оказался слабым».

Потому что корпоративная система меняет не экраны. Она закрепляет, кто имеет право создать заказ, кто может поменять цену, в какой момент товар считается зарезервированным, чьи цифры признаются верными, когда склад и бухгалтерия разошлись. Это вопросы власти. Программист может реализовать правило. Он не может выбрать его вместо собственника.

Если правило не выбрано, неопределённость прячут в доработку. Каждому отделу сохраняют его вариант процесса. Для исключений добавляют флажки. Между системами строят обмены. Excel остаётся «временно». Через год у компании новая ERP и старый способ управления, только теперь он стоит дороже.

Почему виноват не только подрядчик

Интегратор оптимизируется под то, что заказчик согласился принимать.

Написано «реализовать 38 функций» - будет 38 функций. Приёмка проверяет экраны и печатные формы - покажут экраны и формы. Последний платёж привязан к акту - проект закончится актом.

Бизнес при этом ждёт другого: меньше ручной работы, быстрее отгрузка, прозрачный остаток, управляемая себестоимость, независимость от конкретного человека. Ничего из этого нет ни в договоре, ни в плане, ни в протоколе приёмки. Это живёт в презентации и в голове собственника.

Подрядчик не невинен. Профессионал обязан проговорить разрыв между функцией и результатом, потребовать владельца процесса и отказаться обещать эффект, который не контролирует. Но удобнее иначе. Заказчик делает вид, что купил изменение бизнеса. Подрядчик делает вид, что может поставить его коробкой. Оба подписывают договор, который измеряет третье.

Пять вопросов вместо страшной цифры

Спрашивать интегратора «какой у вас процент успешных внедрений» бессмысленно: без определения успеха ответ ничего не значит. Спросите другое. Себя.

1. Какой показатель должен измениться?

Не «повысить прозрачность». Срок закрытия месяца: с семи дней до четырёх. Доля заказов с ручным переносом: с 60% до 10%. Расхождение факта и учёта по складу: с 8% до 2%. Замерить до внедрения. Иначе после запуска любой результат можно объявить успехом.

1. Кто отвечает за процесс целиком?

Не за модуль «Закупки». За путь от потребности до оплаты поставщику, с правом менять правила между отделами. Если такого человека нет, решения примет тот, кто громче, ближе к собственнику или лучше знает систему. Обычно это подрядчик.

1. Что компания перестанет делать после запуска?

Список таблиц, старых систем, ручных сверок и отчётов, которые будут закрыты. Если новый инструмент ничего не отменяет, он не автоматизирует. Он добавляет слой.

1. Как сотрудники докажут, что умеют работать без интегратора?

Перед последним платежом подрядчик выходит из комнаты. Команда сама принимает заказ, исправляет ошибку, закрывает период, восстанавливает упавший обмен, собирает управленческий отчёт. Не рассказывает, куда нажать, а нажимает. На копии базы, по сценарию, с таймером. Если без Вити из интегратора компания встаёт, система установлена, но не внедрена.

1. Что измеряем через три месяца после запуска?

Go-live не финиш. Gartner прямо пишет, что ценность создаётся после запуска и нужна команда, которая продолжает работу с показателями. Значит, заранее нужны дата контрольного замера, ответственный за цифру и решение, что делать, если эффект не появился.

Как выглядит настоящий провал

Для собственника провал - не строка в отраслевом отчёте.

Это когда акт подписан, деньги ушли, а компания по-прежнему сводит данные вручную. Старые системы не отключены. Критичная операция держится на одном консультанте. Стоимость процесса после внедрения никто не измерил. Сотрудники научились обходить систему быстрее, чем работать в ней. И любой спор о результате заканчивается фразой «зато всё по ТЗ».

Такой проект может быть сдан вовремя и в бюджете. В кейсе интегратора он успешный. Для бизнеса - нет.

И наоборот. Проект может задержаться на месяц, потому что команда нашла ошибку в исходном процессе, переделала роли и отказалась от половины кастомизации. По жёсткой статистике он «проблемный». По экономике компании - лучший из возможных.

Поэтому «70%» не помогает оценить риск. Эта цифра заменяет диагностику эмоцией. Страшное число нужно тем, кто продаёт спасение от него.

Когда в следующий раз вам покажут этот слайд, задайте один вопрос: провал - это что? Ответа не будет. Зато будет скидка, если подписать сегодня.

А правильный вопрос звучит иначе: что именно должно измениться в работе компании, и кто отвечает за это изменение? Без этого ответа система уже выбрана слишком рано.

В канале «ИТ-нигилист» я разбираю такие истории на примерах ERP, 1С, подрядчиков, регламентов и зависимости от одного Вити. Без рейтингов интеграторов и обещаний волшебной платформы.