Почему ERP-внедрения проваливаются: паттерн
Aidar O.8 мин чтения
Каждый постмортем звучит одинаково. Вендор обвиняет клиента. Клиент обвиняет интегратора. Интегратор обвиняет скоуп. А где-то на руинах многомиллионной программы Руководящий комитет тихо перестаёт собираться.
ERP-внедрения проваливаются потому, что организации ведут их как IT-проекты, хотя это проекты бизнес-трансформации — систему строят вокруг процессов, которые никто не хочет менять, силами людей, которых никто не хочет слушать, под руководством, которое отключается после kickoff.
«Best practice» становится врагом адаптации
Каждый крупный ERP-вендор продаёт версию одного и того же обещания: примите наши стандартизированные процессы и унаследуйте десятилетия отраслевого best practice. В продажном цикле это звучит как зрелость. На внедрении это сталкивается с реальностью: ни один бизнес искренне не хочет менять то, как он признаёт выручку, закрывает месяц или управляет запасами — пока кто-то старший не продавит решение.
Дальше всё предсказуемо. Бизнес-подразделения требуют кастомизацию, чтобы сохранить уже привычные процессы. Интегратор соглашается — change orders это экономический двигатель проекта. За шесть месяцев «коробочное» внедрение превращается во что-то подозрительно похожее на легаси-систему, которую оно должно было заменить, только дороже в сопровождении. По данным Panorama Consulting за 2024 год, 41% организаций кастомизируют ERP сверх рекомендаций вендора — и эти же организации показывают самые низкие оценки удовлетворённости после запуска. Причина провала не в кастомизации. Причина — в отказе решить, какие процессы действительно дифференцируют бизнес.
Размытие скоупа зашито в процесс продажи
Структурная проблема большинства ERP-внедрений — коммерческий треугольник из трёх сторон: вендор софта, системный интегратор, клиент. У каждой стороны свои стимулы, которые другие видят не полностью. Вендор фиксирует лицензионную выручку при подписании. Интегратор зарабатывает маржу на часах time-and-materials. Клиент, обычно в лице CIO или CFO, получил бизнес-кейс в рамках конкретного бюджета.
Эта схема вознаграждает оптимизм на этапе скоупинга и наказывает честность. Gartner показывает, что 60-75% ERP-внедрений превышают изначальный бюджет, часто на 50% и более. Перерасход не случайный — он структурно заложен заранее. Требовательные воркшопы вскрывают новые модули, интеграции и edge-кейсы, которых не было в первоначальном SOW. Интегратор их приветствует. Вендор допродаёт лицензии. Клиент утверждает, потому что остановить проект сейчас значит признать, что изначальный план был неверным. К моменту, когда кто-то честно считает, ROI-модель, оправдывавшая программу, уже тихо растворилась.
Миграцию данных воспринимают как задачу на выходные
В каждом плане ERP-программы есть строчка «миграция данных». Её обычно ставят ближе к концу, выделяют долю бюджета и отдают той IT-команде, у которой меньше всего политических защитников. Именно в этот момент проект начинает проваливаться — за месяцы до того, как это кто-то заметит.
Мастер-данные предприятия почти всегда хуже, чем кто-либо готов признать. Карточки клиентов дублируются между системами. Коды материалов означают разное на разных площадках. Маппинги плана счетов несогласованы между юрлицами. Исследования Forrester раз за разом показывают, что проблемы качества данных — главная причина сбоев после запуска, но меньше 20% ERP-программ финансируют отдельное направление data governance до миграции. Когда грязные данные втекают в чистую систему, чистая система производит грязный выход — и пользователи теряют к ней доверие в первом же отчётном цикле. Никакая сложность SAP, Oracle или 1C не переживает встречу с мастер-данными, которые никто не чистил десять лет.
Change management режут первым
Когда ERP-программа выходит за бюджет — а большинство выходит — сокращения следуют предсказуемому паттерну. Лицензии софта уменьшить нельзя: контракты подписаны. Часы интегратора трогать политически сложно: программа от них зависит. Железо и облако фиксированы. Поэтому сокращения падают на единственную строку без контрактных защитников: change management.
Обучение сокращают. Программы супер-пользователей опускают по приоритету. Воркшопы по редизайну процессов сжимают до одной недели. Коучинг по адаптации исчезает полностью. Исследования McKinsey по крупным трансформациям показывают, что программы, инвестирующие в change management менее 10% общего бюджета, успешны примерно вдвое реже, чем программы с 15% и выше. Логика прямая: ERP — это набор инструкций о том, как тысячи людей должны завтра работать иначе, чем вчера. Сократить инвестицию, которая учит их как — значит гарантировать, что запуск станет началом падения производительности, а не окончанием проекта.
Исполнительные спонсоры отключаются после kickoff
Самый устойчивый предиктор провала ERP — не техническая сложность, не выбор вендора и даже не качество данных. Это календарь исполнительного спонсора. Опросы KPMG по крупным трансформационным программам раз за разом показывают: устойчивая вовлечённость C-suite — главный фактор, отличающий программы, которые приносят бизнес-ценность, от программ, которые приносят рабочую систему, которой никто не доверяет.
Паттерн знакомый. CEO произносит речь на kickoff. Steering Committee собирается еженедельно в течение первого квартала. Потом внимание спонсора уходит к следующему стратегическому приоритету. Встречи Steering переходят на месячные, потом квартальные, потом «по необходимости». Решения, требующие прикрытия на уровне первого лица — закрыть запрос на кастомизацию, отменить решение руководителя подразделения, снять недорабатывающего тимлида — начинают копиться в очереди, которую никто не уполномочен расчищать. Программа уплывает под IT-владение — а это то место, где ERP-трансформации умирают. Софт работает. Бизнес не изменился. И все участники учатся описывать результат как «успешное техническое внедрение с трудностями адаптации».
Контраргумент
Самый частый контраргумент: провал ERP на самом деле про выбор вендора — выберете SAP там, где нужно было Oracle, выберете облако вместо on-premise, и программа обречена независимо от управления.
Но данные не подтверждают выбор вендора как главный драйвер. Многолетний анализ Deloitte по корпоративным трансформациям связывает примерно 15% вариации успеха с выбором платформы и вендора. Остальные 85% распределяются между подходом к внедрению, готовностью данных, исполнительным управлением и организационной дисциплиной. Предприятия, которые успешны с SAP, успешны и с Oracle, и с Microsoft, и всё чаще с 1C и облачными платформами. Предприятия, которые проваливаются, как правило, проваливаются на разных платформах подряд. Паттерн — в организации, а не в софте. Винить вендора эмоционально приятно и стратегически бесполезно — это объясняет прошлогодний провал, гарантируя следующий.
Что это значит
Для предприятий, планирующих ERP-программу в ближайшие восемнадцать месяцев, вывод неудобный, но применимый. Воспринимайте программу как 70% change management и 30% технологии — и бюджетируйте соответственно. Счета за лицензии и интеграторов займут любой доступный объём; дисциплина в том, чтобы финансировать работу без контрактных защитников. Постройте устойчивый ритм исполнительного управления, который переживёт первый квартал — Steering Committee, который встречается всё время программы, с закреплёнными правами принятия решений и путями эскалации, не требующими календаря CEO.
Инвестируйте в очистку данных за шесть-двенадцать месяцев до запуска первого миграционного скрипта, а не в выходные перед go-live. Откажитесь от кастомизации процессов, которые не дифференцируют бизнес по-настоящему — order-to-cash, procure-to-pay и record-to-report редко к ним относятся. На казахстанском рынке, где 1C доминирует в среднем сегменте, а SAP и Oracle закрепились в крупнейших предприятиях, паттерн провала тот же, что и везде: кастомизация ради сохранения легаси-процессов, недофинансированная миграция данных и исполнительные спонсоры, отключающиеся при переходе от стратегии к исполнению. Платформы не являются проблемой. Платформы никогда не были проблемой. Назовите реальный паттерн — и программа получит шанс доставить то, что обещала на kickoff.
Часто задаваемые вопросы
Отстранённое исполнительное спонсорство — самый сильный предиктор во всех крупных консалтинговых исследованиях. Технические проблемы преодолимы; программа, теряющая C-suite прикрытие после kickoff, как правило, нет. За ним следуют готовность данных и инвестиции в change management.
Исследования McKinsey и Prosci указывают на 15-20% общего бюджета программы — включая обучение, редизайн процессов, подготовку супер-пользователей и устойчивый коучинг адаптации минимум полгода после запуска. Программы с финансированием ниже 10% успешны примерно вдвое реже.
По данным Deloitte, выбор платформы объясняет около 15% вариации успеха. Остальные 85% — дисциплина внедрения, управление, готовность данных и организационная способность к изменениям. Предприятия, успешные с SAP, как правило успешны и с Oracle, Microsoft или 1C. Паттерн живёт в организации, а не в софте.
За шесть-двенадцать месяцев до запуска первого миграционного скрипта в тестовой среде. Очистка мастер-данных, дедубликация, выравнивание таксономий между юрлицами и структуры governance должны быть на месте задолго до cutover. Восприятие миграции как задачи конца проекта — главная причина, по которой чистые системы производят грязный выход и теряют доверие пользователей в первом отчётном цикле.
Нет — но её стоит ограничивать процессами, которые действительно дифференцируют бизнес и создают реальное конкурентное преимущество. Order-to-cash, procure-to-pay и record-to-report почти никогда сюда не попадают. Дисциплина в том, чтобы явно решить, какие процессы дифференцированы, до того как начнут поступать запросы на кастомизацию — и наделить управление правом отказывать по остальным.
Если вы готовите ERP-программу или восстанавливаете ту, что ушла с траектории, opengate проводит enterprise readiness оценки, которые проверяют управление, готовность данных и способность к изменениям до подписания первой лицензии. Начните разговор с нашей командой.
Хотите работать вместе? Свяжитесь с нами