Ошибки при внедрении ERP-систем: что реально губит проекты

Большинство ERP-проектов проваливается не из-за качества программного продукта, а из-за управленческих решений, принятых задолго до появления первого документа в системе — по данным российских консультантов, до 60% внедрений не достигают заявленных целей, а 74% проектов превышают изначальный бюджет. Классическая ловушка — воспринимать ERP как ИТ-проект, который можно делегировать техническому отделу, тогда как на практике это изменение правил работы всего бизнеса, требующее постоянного участия первых лиц компании.

Краткий вывод

Три ошибки повторяются в подавляющем большинстве провальных проектов независимо от отрасли и масштаба компании: отсутствие описанных бизнес-процессов (система автоматизирует существующий хаос вместо порядка), недостаточная вовлечённость первого лица компании (по данным «Эксперт РА», 40% провалов связаны именно с этим) и попытка охватить всё сразу вместо поэтапного запуска с MVP. Экономия на предпроектной аналитике — самая коварная ошибка, поскольку её последствия проявляются не сразу: недостаточное описание процессов на старте приводит к недоиспользованию функционала системы на 60–70% уже после запуска. Ошибки миграции данных и качество нормативно-справочной информации (НСИ) отдельно выделяются практиками как зона, где до 30% времени проекта, вышедшего за рамки графика, тратится именно на исправление проблем с переносом данных.

Статистика провалов ERP-проектов

Ошибки, закладываемые до старта проекта

Отсутствие чёткой бизнес-цели или её подмена

Одна из самых распространённых ошибок — ставить задачу просто «внедрить ERP-систему» вместо конкретной измеримой цели в формате «метрика → базовое значение → целевое значение → срок», привязанной к владельцам конкретных процессов: склад, финансы, продажи, закупки. Основной целью ERP-системы должно быть улучшение бизнес-процессов, приносящих компании основной доход, а не автоматизация как таковая.

Проектирование системы без учёта стратегии развития компании

Классическая ошибка — начинать проект с технологий, а не с бизнес-процессов, а также проектировать систему «снизу-вверх», без учёта стратегии развития компании и без корректного нисходящего анализа требований от верхнего управленческого уровня к операционному.

Отсутствие описанных бизнес-процессов — «автоматизация хаоса»

Если компания не может за одну-две рабочие сессии разложить путь от заказа до отгрузки, проект уже находится под риском — это означает, что процесс живёт в головах сотрудников, в переписке и в личных привычках, а не в формализованном виде. Критическая ошибка — пытаться автоматизировать хаотичное производство без предварительной оптимизации процессов: если процессы не описаны, ERP автоматизирует хаос, если данные не очищены — ERP лишь масштабирует существующие ошибки.

Недооценка бюджета и сроков

Типичная ошибка — ориентироваться только на стоимость лицензий или коробочного решения, тогда как многие компании ошибочно считают, что 80% стоимости проекта приходится именно на лицензии. Правильный подход — формировать полную стоимость владения (TCO) на несколько лет вперёд, включая внедрение, интеграции, сопровождение, доработки, лицензирование серверов и рабочих мест, а также стоимость внутренних ресурсов, закладывая резерв минимум 25–30% на непредвиденные работы. Оптимистичные сроки без учёта буфера — ещё одна распространённая проблема: рекомендуется закладывать буфер не менее 20% по срокам и фиксировать контрольные вехи проекта.

Выбор системы раньше описания требований

Частый сценарий: компания посмотрела демо-версию, решение понравилось, систему купили — а затем оказывается, что 40% нужных функций в ней отсутствует. Правильная последовательность действий — сначала описать требования, затем составить запрос предложений (RFP), и только после этого выбирать из систем, которые действительно соответствуют требованиям, а не наоборот.

Неправильный выбор подрядчика

Выбор исполнителя только по цене — распространённая и дорогая ошибка; правильный подход — оценивать подрядчика по трём критериям: опыт именно в отрасли заказчика, применяемая методология внедрения и состав проектной команды. За формулировкой «неправильный выбор подрядчика» часто скрывается ситуация, когда исполнитель не имеет релевантного опыта и команды, либо заказчик и подрядчик просто плохо совместимы в работе.

Ошибки в ходе внедрения

Попытка охватить всё сразу вместо поэтапного запуска

Внедрение за один раз десяти модулей на всю компанию — максимальный риск проекта: при любой проблеме встаёт вся система целиком. Правильная стратегия — MVP (минимально жизнеспособный продукт), затем пилот на одном отделе или юридическом лице, и только затем постепенное расширение, при котором ошибки обнаруживаются раньше и исправляются существенно дешевле.

Гиперкастомизация и постоянные изменения системы без контроля

Массовые доработки системы под старые схемы работы, а также частые бесконтрольные корректировки уже разработанной системы приводят к накоплению хаотичных решений, которые усложняют управление и дальнейшее развитие ERP. Одна из типичных причин срыва — расширение объёма доработок без пересмотра сроков проекта: слишком быстрый переход к программированию до того, как компания договорилась о базовой логике процессов, приводит к автоматизации не порядка, а текущего хаоса в более дорогой форме.

Перенос старой лоскутной логики в новую систему

Распространённая ловушка — переносить в новую ERP таблицы, ручные схемы, неформальные согласования, дублирующие справочники и разные трактовки одного и того же показателя вместо пересмотра логики процессов — вся эта сложность просто «переезжает» в новую систему, но уже в более дорогой форме.

Плохое качество нормативно-справочной информации и миграции данных

Самая болезненная зона проекта — НСИ: номенклатура, единицы измерения, склады, контрагенты, статьи движения денежных средств. Перенос данных «как есть», без очистки дублей, ошибок и некорректных остатков, — критическая ошибка, поскольку исправление проблем с миграцией данных может занимать до 30% времени проекта, вышедшего за график.

Недостаточное тестирование и отсутствие плана отката

Многие проекты недооценивают важность полноценного тестирования перед запуском, а также не готовят план действий на случай, если система не заработает как надо в день переключения. Правильная практика — вести параллельную работу в старой системе 2–4 недели после запуска, делать резервные копии данных и заранее зафиксировать чёткий критерий, что именно будет считаться провалом.

Слабое участие ключевых сотрудников заказчика

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

Ошибки после запуска системы

Экономия на обучении пользователей

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

Отсутствие постпроектного контроля

Ошибочно считать проект завершённым в день запуска системы — первые 6–12 месяцев требуют постоянного контроля фактического использования функционала, достижения заявленных KPI и корректировки процессов по мере накопления реального опыта работы пользователей.

Ожидание, что система «сама заработает» и наведёт порядок

Распространённое заблуждение — рассчитывать, что ERP автоматически наведёт порядок в компании без активного управленческого участия; на практике система лишь отражает и масштабирует те процессы и данные, которые в неё заложены на этапе внедрения.

Кто чаще виноват — заказчик или подрядчик

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

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

Как предотвратить провал проекта

Назначьте одного владельца результата со стороны бизнеса

Ответственность за результат должна быть закреплена за одним человеком с правом принимать решения, а не только согласовывать их — желательно операционным или финансовым директором, а не ИТ-руководителем, поскольку ERP — управленческий инструмент, а не технический проект.

Выделите на предпроектное обследование не менее 15% бюджета времени

Качественное обследование бизнес-процессов должно занимать не менее 15% времени всего проекта, с вовлечением всех ключевых пользователей и фиксацией не только модели «как есть», но и целевой модели «как должно быть» — экономия на этом этапе почти всегда оборачивается недоиспользованием функционала на 60–70% после запуска.

Разбейте проект на MVP и поэтапные фазы

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

Заложите реалистичный бюджет с резервом 25–30%

Считайте полную стоимость владения на несколько лет вперёд, а не только стоимость лицензий, и обязательно закладывайте резерв на непредвиденные доработки и превышение сроков — большинство проектов, по данным Panorama Consulting, всё равно выходят за рамки первоначального бюджета.

Очистите нормативно-справочную информацию до старта миграции

Прежде чем переносить данные в новую систему, очистите ключевые справочники — номенклатуру, контрагентов, склады, статьи ДДС — от дублей и исторических ошибок, поскольку перенос данных «как есть» лишь масштабирует накопленный хаос в новой, более дорогой системе.

Инвестируйте в обучение как в непрерывный процесс, а не разовое событие

Постройте систему обучения из видеоинструкций, базы знаний и постоянной поддержки пользователей в первые месяцы после запуска, а также регулярно обновляйте материалы — однократное обучение перед запуском забывается уже через месяц.

Чек-лист перед запуском ERP-проекта:

• Сформулирована конкретная измеримая бизнес-цель с привязкой к KPI, а не абстрактная задача «внедрить ERP»
• Назначен владелец результата со стороны бизнеса с полномочиями принимать решения, а не только согласовывать
• Проведено полноценное предпроектное обследование (не менее 15% времени проекта) с описанием процессов «как есть» и «как должно быть»
• Очищены ключевые справочники (НСИ) перед началом миграции данных
• Проект разбит на MVP и поэтапные фазы, а не запускается единовременно на всю компанию сразу
• Заложен резерв бюджета 25–30% и буфер по срокам не менее 20% сверх первоначального плана
• Подготовлен план отката и параллельная работа в старой системе на 2–4 недели после запуска
• Организовано непрерывное обучение пользователей, а не разовая тренировка перед стартом

Часто задаваемые вопросы

Какая ошибка при внедрении ERP считается самой дорогой?
Самая дорогая ошибка — запустить проект автоматизации без предварительного описания и оптимизации бизнес-процессов: в результате получается автоматизированный хаос, который работает быстрее прежнего, но остаётся столь же неправильным по сути.

Почему проекты 1С:ERP чаще срываются по срокам, чем внедрение других категорий корпоративного ПО?
Основные причины срыва графика — неучтённый объём доработок без пересмотра сроков, миграция данных без предварительного тестового прогона и слабое участие ключевых сотрудников заказчика, поскольку 1С:ERP охватывает производство, склад, финансы и регламентированный учёт одновременно, что усиливает масштаб рисков.

Можно ли доверить управление ERP-проектом полностью ИТ-отделу?
Нет, передача проекта только ИТ-отделу или технической поддержке без вовлечения бизнес-руководства — распространённая фатальная ошибка, так как ERP — это инструмент управления бизнесом, а не чисто техническое решение, и стратегические компромиссы по приоритетам и бюджету должен принимать операционный или финансовый директор, а не ИТ-специалист.

Сколько времени нужно закладывать на обследование процессов перед внедрением ERP?
Практики рекомендуют выделять не менее 15% общего времени проекта на качественное предпроектное обследование с вовлечением всех ключевых пользователей — экономия на этом этапе почти всегда приводит к недоиспользованию функционала системы на 60–70% после запуска.

Что делать, если проект ERP уже забуксовал и обрастает бесконтрольными доработками?
Нужно вернуть проект в управляемое состояние: зафиксировать понятную управленческую цель, проверить, соответствует ли текущая архитектура системы реальным процессам предприятия, и определить, кто на самом деле управляет проектом — часто выясняется, что решение фактически отдано на сторону подрядчика и внутренней ИТ-команды без реального участия руководства.

Ссылки и следующий шаг

Изучите обзоры российских ERP-систем, отраслевых решений на базе 1С:ERP и импортозамещения ERP в разделе «ERP и операционное управление» на Цифровом маркетплейсе, чтобы заранее выстроить проект внедрения с учётом типичных рисков и избежать самых дорогих ошибок.