Собственник, который задумался о системе управления производством, почти наверняка слышал страшные истории: «внедряли два года, потратили миллионы, работают по-старому». Такие случаи бывают. Чтобы отделить реальный риск от страшных историй, полезно смотреть на размер проекта, метод исследования и решения, которые привели к срыву.
Что говорит статистика
Статистика крупных ИТ-проектов показывает масштаб риска, но не прогнозирует результат небольшого производства. Самое масштабное исследование провели McKinsey и Центр управления крупными программами Оксфордского университета (2012). Анализ более 5 400 проектов показал:
- в среднем крупные проекты превышают бюджет на 45%, срок на 7% и приносят на 56% меньше ценности, чем прогнозировалось;
- 17% проектов проваливаются настолько, что угрожают существованию компании;
- каждый дополнительный год проекта добавляет около 15% к перерасходу.
Отчёты Standish Group (CHAOS) за 2020 год показывают похожую картину: 31% проектов успешны, 50% проблемны, 19% провальны. Методику критикуют за слишком формальное определение успеха, но главный вывод подтверждается и другими данными: маленькие проекты успешны значительно чаще больших.
ERP-проекты за 15 лет
Panorama Consulting ежегодно опрашивает компании, внедрявшие ERP. Выборки и методики меняются, поэтому полезнее смотреть на динамику, чем на абсолютные цифры.
Сравнивать эти опросы как одну временную серию нельзя. При разборе собственного проекта полезнее смотреть на причины отклонений, чем на общую долю успешных внедрений. В отчёте 2026 года технические проблемы упоминаются лишь в 43% проектов с превышением бюджета и в 50% опоздавших проектов. Наряду с техническими причинами в отчёте рассматриваются расширение объёма и организационные проблемы.
При этом «уложиться в бюджет» и «получить ценность» не одно и то же. Gartner в 2024 году прогнозировал, что более 70% недавно начатых ERP-инициатив к 2027 году не достигнут в полной мере целей исходного бизнес-кейса. Типичные причины: после запуска никто из руководства не отвечает за выгоды, фокус остаётся на «внедрении», а не на результате, слишком много доработок, слабая работа с данными и с людьми.
Даёт ли ERP эффект в принципе
Да, но не сразу. Hitt, Wu и Zhou (2002) проанализировали более 24 000 наблюдений по публичным американским компаниям. У компаний, внедривших ERP, выручка на сотрудника в среднем была выше на 26,7%, оборачиваемость запасов лучше на 7,8%. Но исследователи обнаружили просадку после внедрения: рост показателей во время проекта частично исчезал после запуска. Позднее экономисты описали это как J-кривую цифровых инвестиций: сначала показатели ухудшаются, пока люди осваивают новые процессы, и только потом растут.
Ключевая мысль. Просадку после запуска нужно планировать заранее: заложить её в график отгрузок, не запускать систему в пиковый сезон, держать резерв запасов и людей на период освоения.
Малый и средний бизнес: другая статистика
Страшные цифры относятся в основном к крупным проектам. У небольших производств главный риск другой: систему купили, а ей не пользуются. Анализ 70 опубликованных кейсов облачной MRP-системы для малых производителей (медиана 15 сотрудников) показал медианный срок внедрения 2 месяца: 1 месяц для компаний до 10 человек и 6 месяцев для компаний больше 50. Главные причины внедрения: нет видимости операций (74%), компания «переросла» таблицы (54%), административная нагрузка (52%).
Кейсы опубликованы самим поставщиком, поэтому выборка смещена в сторону успеха. Но вывод совпадает с другими данными: чем меньше и короче проект, тем выше шанс. Сложность растёт быстрее численности. Типичный провал небольшой компании выглядит не как потеря сотен миллионов, а как «двойной учёт»: в системе одно, в тетради мастера другое, и люди постепенно возвращаются к тетради.
Восемь разборов: что пошло не так
Это кейсы крупных зарубежных компаний. Их бюджеты и последствия нельзя переносить на российское небольшое производство. Полезны конкретные механизмы срыва: запуск перед пиком, грязные справочники, недостаточное тестирование и попытка изменить всё сразу.
FoxMeyer Drug, США, 1993-1996
Дистрибьютор лекарств с выручкой около 5 млрд долларов внедрял SAP R/3 и одновременно автоматизированный склад. Бюджет вырос с 65 до более чем 100 млн долларов, система не справлялась с объёмами. В 1996 году компания подала на банкротство.
Урок: одновременное изменение бизнеса, ИТ и инфраструктуры без резервного плана означает ставку на всё.
Hershey, США, 1999
Три системы сразу (SAP, Manugistics, Siebel) и запуск «большим взрывом» в июле, перед пиковым сезоном Хеллоуина. Компания не смогла выполнить заказы примерно на 100 млн долларов, акции упали примерно на 8%.
Урок: не запускайтесь перед пиком. Сокращать нужно объём, а не тестирование.
Nike, США, 2000-2001
Система планирования i2 работала медленно и выдала фабрикам неверные объёмы по моделям. Потерянные продажи около 100 млн долларов. Nike восстановилась: поэтапное внедрение и 140-180 часов обучения на сотрудника.
Урок: провал внедрения не означает провала стратегии. Обучение измеряется десятками часов.
Target Canada, 2013-2015
Новая система за 18 месяцев. По многочисленным публикациям, точными оказались лишь около 30% записей о товарах против примерно 98% в американских операциях. Склады переполнены, полки пусты, бизнес закрыт, около 17 600 человек уволены.
Урок: результат работы алгоритмов зависит от исходных данных. За качество справочников должны совместно отвечать владельцы данных и участники проекта.
Lidl, Германия, 2011-2018
Семь лет и около 500 млн евро. Lidl учитывала запасы по закупочным ценам, а стандартная логика системы строилась на розничных. Вместо изменения процесса выбрали масштабные доработки, проект остановлен.
Урок: заранее решите, где меняете процесс, а где систему.
Revlon, США, 2018
После запуска SAP на крупном заводе компания не могла производить часть продукции. Потеря продаж около 64 млн долларов, падение акций на 6,4%, иск инвесторов.
Урок: перед запуском нужны сквозные тесты «заказ, производство, отгрузка» на реальных объёмах и план отката.
Haribo, Германия, 2018
После перехода на SAP S/4HANA начались проблемы с учётом и поставками, продажи в отдельных каналах упали примерно на 25%. Panorama связывает это с недостаточным описанием процессов до настройки.
Урок: процессы описывают до выбора и настройки системы.
National Grid, США, 2009-2012
Запуск в спешке, ошибки в зарплате, запасах и платежах. Исправление заняло около двух лет и около 850 подрядчиков, потери оцениваются примерно в 585 млн долларов.
Урок: спешка с запуском обходится дороже любой задержки.
| Причина | Где проявилась |
|---|---|
| Сжатые сроки, спешка | FoxMeyer, Hershey, Target Canada, National Grid |
| Сокращённое тестирование | FoxMeyer, Hershey, Revlon |
| Запуск всего сразу | FoxMeyer, Hershey, Target Canada |
| Плохие данные | Target Canada, FoxMeyer |
| Запуск в неудачный момент | Hershey, FoxMeyer |
| Избыточные доработки, разрыв требований | Lidl, Haribo |
| Слабое управление, смена руководства | FoxMeyer, Lidl |
| Недостаточное обучение | Nike |
Ключевая мысль. SAP, i2 и другие системы успешно работают в тысячах компаний. В разобранных случаях проваливались не программы, а решения людей: сроки, объём, данные, тестирование, момент запуска, готовность менять процессы.
Та же технология, противоположный результат
Сопоставление FoxMeyer и Dow Corning показывает, как различия в организации проекта могут влиять на результат. Обе компании внедряли одну и ту же SAP R/3 в одни и те же годы. Dow Corning, производитель силиконов с выручкой около 2,5 млрд долларов, работала в тяжёлых условиях (судебные иски на миллиарды), но завершила проект в срок и в бюджет к декабрю 1998 года. Отличия, которые описали Скотт и Весси (2002): сильное руководство, открытая культура обсуждения проблем, гибкое управление объёмом, пилот на отдельной площадке, ясная бизнес-цель и проект, которым владела сама компания, а не консультанты.
Десять факторов, которыми можно управлять
Если свести исследования критических факторов успеха (Holland и Light, 1999; Somers и Nelson, 2001; Ngai, Law и Wat, 2008; Muscatello, Small и Chen, 2003), статистику и кейсы воедино, получится десять факторов. Все они организационные, а не технические.
- Личное участие первого лица в ключевых решениях и конфликтах между службами. Фактор номер один почти во всех исследованиях.
- Цель в цифрах: «сократить срок выполнения заказа с 25 до 12 дней при поставке вовремя не ниже 90%», а не «внедрить ERP».
- Ограниченный объём и этапы. Лучше пять этапов по три месяца, чем один на пятнадцать.
- Решение о процессах до решения о системе. Где меняем процесс, а где настраиваем систему.
- Качество данных как отдельный проект с владельцами справочников.
- Сильная команда со стороны компании: лучшие люди, частично освобождённые от текущей работы. Внешний интегратор не может быть владельцем проекта.
- Тестирование на реальных сценариях и объёмах, включая исключения.
- Обучение и работа с людьми: каждый должен понимать зачем и получать личную пользу.
- Продуманный момент запуска: не в пик, с планом отката и запасом на период освоения.
- Ответственный за выгоды после запуска. Проект не заканчивается в день запуска.
Почему люди сопротивляются и что с этим делать
Сопротивление закономерно, если выгоду от системы получает директор, а цену ввода данных платит рабочий. Для руководителя отметка операции - источник информации. Для рабочего это дополнительное действие, которое должно быть оправдано пользой. Решение: дать каждой роли личную выгоду. Рабочему не искать чертёж и видеть своё задание, мастеру не бегать по цеху, снабженцу получать ранний сигнал о потребности.
Второй фактор: прозрачность меняет баланс власти. Если за каждое зафиксированное отклонение наказывают, люди быстро учатся отклонения скрывать, и система наполняется «правильными» и бесполезными данными. Система должна быть безопасной для правды: сообщение о проблеме служит поводом разобрать причину, а не искать виноватого.
Пример. Лишние 8 секунд на одну отметку, повторённые 40 раз в смену 50 сотрудниками 250 дней в году, дают около 1 100 человеко-часов в год. Каждое поле и каждый клик должны быть обоснованы.
Карта рисков: ранние признаки беды
| Риск | Ранний признак | Что делать |
|---|---|---|
| Размытая цель | нет числовых целевых показателей | бизнес-кейс с базовой линией и целями |
| Разрастание объёма | список требований растёт быстрее, чем выполняется | приоритеты, контроль изменений, этапы |
| Разрыв требований | поставщик на ключевые сценарии отвечает «доработаем» | демонстрация на ваших данных |
| Плохие данные | разные ответы на вопрос «сколько у нас на складе» | очистка данных с владельцами и метриками |
| Сопротивление | система и тетрадь ведутся параллельно | личная польза пользователю, участие в проектировании |
| Перегрузка ключевых людей | одни и те же люди в проекте и в оперативке | освобождение части времени, замещение |
| Сбой при запуске | нет сквозных тестов на объёме | тестирование, пилот, план отката |
| «Внедрили и забыли» | никто не отвечает за показатели после запуска | владелец выгод, ежемесячный обзор |
Что сделать на своём производстве
- Сформулируйте 3-5 целей проекта в цифрах и измерьте текущие значения за 2-3 месяца до старта.
- Разбейте проект на этапы по 2-4 месяца, каждый с работающим результатом.
- Проверьте точность данных: пересчитайте 50 позиций склада и сверьте 20 спецификаций. Если совпадений меньше 80%, начните с данных.
- Назначьте владельца проекта внутри компании и освободите ему время.
- Выберите дату запуска вне пикового сезона и заранее создайте запас на период освоения.
- Назначьте ответственного за показатели после запуска и сверяйте факт с планом через 3, 6 и 12 месяцев.
Вопросы и ответы
Правда ли, что большинство внедрений ERP проваливаются?
Мы небольшая компания. Это про нас?
Как понять заранее, что проект идёт к провалу?
Виноват ли обычно подрядчик?
Сколько времени закладывать на обучение?
Статья основана на книге «Управление производством»
В книге главы 14-17 разобраны подробнее: с формулами, примерами, шаблонами и полным списком источников.
Источники
- McKinsey & Company, University of Oxford. Delivering large-scale IT projects on time, on budget, and on value. 2012.
- Gartner. What IT Leaders Must Do to Avoid Disappointing ERP Initiatives. 2024.
- Panorama Consulting. ERP Report 2010, 2012, 2026.
- Standish Group. CHAOS Report 2020.
- Hitt L., Wu D. J., Zhou X. Investment in Enterprise Resource Planning. Journal of Management Information Systems, 2002.
- Scott J., Vessey I. Managing Risks in Enterprise Systems Implementations. Communications of the ACM, 2002.
- Ngai E., Law C., Wat F. Examining the critical success factors in the adoption of ERP. Computers in Industry, 2008.
- MRPeasy. Manufacturing ERP Implementation Statistics: Insights From 70 Case Studies.
Опубликовано 7 октября 2026 г. Цифры о рынке и технологиях приведены по состоянию на 2025-2026 годы.