Ошибки внедрения ERP-систем: 10 проблем, которых стоит избежать
Крупный производственный холдинг начинает внедрять SAP, чтобы получить единую себестоимость по всем площадкам и повысить контроль над закупками. Но внедрение ERP – это не установка новой ИТ-системы, а трансформация процессов, данных, ролей и операционной модели бизнеса. Спустя полтора года бюджет проекта может вырасти, а руководители заводов продолжат вести собственные таблицы, потому что цифрам в системе они не доверяют.
По данным ERP Report 2026 от Panorama Consulting Group, более четверти компаний завершили ERP-проекты с превышением бюджета. Среди проектов, вышедших за график, наиболее распространенной причиной стали организационные проблемы – управление, сопротивление изменениям и пересмотр процессов. При этом только 23,5% компаний сообщили об интенсивном фокусе на управлении организационными изменениями.
Для внедрения SAP в Казахстане к этим рискам добавляется локальная специфика: необходимость интеграции с государственными информационными системами, адаптация к изменениям регулирования и ограниченное количество команд с опытом полного цикла проектов SAP S/4HANA.
О чем расскажем в статье:
Главные выводы
- Результат ERP-проекта зависит не только от технологий: критическую роль играют управление, процессы, данные и готовность пользователей к изменениям.
- Предпроектное обследование и грамотный спонсор со стороны бизнеса стоят дешевле, чем исправление архитектуры после запуска.
- Нестандартная доработка Z-кода может увеличивать расходы дважды: сначала при разработке и сопровождении, затем при модернизации или переходе на SAP S/4HANA
- Обучение пользователей и Hypercare входят в проект, а не идут отдельными расходами после него.
Стратегические ошибки и методология проекта
Первые три ошибки компания совершает еще до выбора вендора, когда экономит на подготовке и поручает проект куратору без полномочий менять порядок работы. Сюда же относится перенос в SAP тех процессов, которые никто не пересматривал годами.
Ошибка 1. Отсутствие предпроектного обследования
Когда компания считает бюджет проекта, удобнее всего сэкономить на предпроектном обследовании, потому что оно не дает ни одной работающей функции. В итоге команда начинает настройку SAP на базе общих требований, а описывать процессы приходится уже по ходу проекта, когда любое изменение стоит дороже.
Рассмотрим пример. Холдинг с несколькими производственными площадками разворачивает систему SAP по шаблону головного предприятия и на интеграционном тестировании выясняет, что заводы считают незавершенное производство по разным методикам. В итоге, сроки проекта сдвигаются, а исправление архитектуры на этой стадии обходится намного дороже, чем ее анализ в начале проекта.
Чтобы избежать этой ошибки, до старта руководителю стоит проверить два пункта:
1/ Описаны ли сквозные процессы, например, от заявки на закупку до платежа и от заказа клиента до отгрузки, с ответственным за каждый шаг.
2/ Составлен ли перечень отклонений от стандартной функциональности SAP с оценкой трудозатрат.
Ошибка 2. Отсутствие спонсора проекта со стороны топ-менеджмента
Спонсор проекта — это руководитель, который отвечает за результат перед собственниками и может изменить порядок работы в любом подразделении. Такой человек нужен, потому что в SAP все подразделения работают по одним и тем же правилам. Это значит, что в системе останется только одна схема, и кому-то придется отказаться от привычного для них процесса.
ИТ-директор такой спор решить не может, потому что коммерческая служба ему не подчиняется, а CEO или CFO в роли спонсора могут. Но пока вопрос дойдет до руководителя, пройдет две-три недели, и все это время проект будет стоять на паузе.
Спонсора видно по двум признакам:
1/ Он сам ведет управляющий комитет и принимает решения по спорным процессам, а не подписывает готовые протоколы.
2/ Он освободил ключевых экспертов бизнеса от части текущей работы на время проекта.
Ошибка 3. Перенос неописанных процессов из старых систем
Компания просит интегратора повторить в SAP то, как работала прежняя система, чтобы сотрудникам не пришлось переучиваться. Экономия здесь мнимая, потому что вместе с привычным порядком работы в новую систему переезжают дублирующие согласования и нестандартные схемы взаиморасчетов, а поддерживать все это придется годами.
Например, в торговой компании заявку на закупку последовательно согласовывают пять человек, потому что так сложилось исторически. Эту цепочку переносят в SAP как есть, и в результате компания платит за дорогую систему, а заявка идет к поставщику ровно столько же, сколько шла раньше. При этом в стандартной функциональности SAP есть отраслевые сценарии, которые вендор собрал на тысячах предприятий, и в них та же заявка проходит по регламенту с автоматической проверкой лимитов.
Чтобы избежать этой ошибки, порядок работы над проектом стоит выстроить обратный: компания сначала пересматривает процессы под стандарт SAP, а потом отвечает на два вопроса по каждому отклонению:
1/ Что компания получит от этого отклонения, если считать в деньгах или в сроках.
2/ Сколько будет стоить его поддержка на всем сроке жизни системы.
Технологические ловушки и архитектура SAP
Вторая группа ошибок автоматизации бизнеса связана с архитектурой. Такие решения редко очевидны в начале проекта, но определяют стоимость владения системой в долгосрочной перспективе и возможность развивать ландшафт без полной перестройки.
Ошибка 4. Избыточная кастомизация вместо концепции Clean Core
Кастомизация SAP ERP под привычки пользователей начинается с простых запросов вроде дополнительного поля в форме заказа. Через два года ландшафт содержит сотни объектов Z-кода, то есть заказных программ и доработок стандартных транзакций, после чего каждое обновление SAP будет требовать регрессионного тестирования. Цена таких доработок будет видна позже, когда миграция на SAP S/4HANA потребует переписать значительную часть Z-кода под новую модель данных, и оценка проекта значительно вырастает.
Концепция Clean Core предлагает максимально сохранять стандартный функционал. Ядро SAP остается неизменным и обновляется штатно, а специфические сценарии компания реализует либо внутри системы, на опубликованных вендором интерфейсах, либо отдельными сервисами на SAP BTP, облачной платформе SAP для расширений и интеграций.
Чтобы удержать систему в обновляемом состоянии, стоит следовать двум правилам:
1/ Каждую доработку команда защищает перед архитектурным советом и сразу считает стоимость ее поддержки.
2/ Расширения компания делает на опубликованных интерфейсах SAP или на SAP Business Technology Platform, а стандартный код не трогает.
Ошибка 5. Затягивание миграции с SAP ECC на SAP S/4HANA
Окончание поддержки SAP ECC перестало быть отдаленной перспективой. Основная поддержка SAP ERP 6.0 заканчивается 31 декабря 2027 года, а расширенная доступна за дополнительную плату до конца 2030 года. Компании, которые откладывают решение по миграции, столкнутся с двумя вопросами.
- Стоимость сопровождения устаревшего ландшафта растет.
- Свободных консультантов становится меньше, потому что крупные заказчики начинают проекты миграции примерно в одно и тоже время.
Для Казахстана дефицит команд ощущается сильнее, поэтому разумный сроки планирования составляют два года и больше. Начинать стоит с оценки ландшафта и выбора сценария перехода, о чем подробнее в статье о миграции на SAP S/4HANA.
Чтобы избежать этой ошибки, руководителю стоит заранее проверить два пункта:
1/ Оценен ли объем доработок и интеграций, которые придется переделать при переходе на SAP S/4HANA.
2/ Назначена ли дата ухода с SAP ECC и зарезервированы ли под нее бюджет и команда проекта.
Ошибка 6. Проект без учета интеграций с государственными системами
ERP-система не работает изолированно. Возьмем для примера Казахстан. Компания выписывает электронные счета-фактуры в ИС ЭСФ, оформляет сопроводительные накладные, ведет остатки в модуле “Виртуальный склад” и проставляет коды по Национальному каталогу, а импортеры работают еще и с таможенной системой АСТАНА-1.
Если интеграцию оставили на последние недели проекта, то к запуску системы она может не работать. Тогда обмен с государственными системами приходится вести руками. Бухгалтер выгружает данные из SAP, заносит их в кабинет налогоплательщика и повторяет это по каждой отгрузке. При десятках документов в день компания перестает укладываться в сроки выписки, а за нарушение этих сроков предусмотрен штраф.
Чтобы избежать этой ошибки, до начала настройки стоит проверить два пункта:
- Зафиксирован ли перечень государственных и внешних систем, с которыми SAP будет обмениваться данными.
- Запланировано ли интеграционное тестирование отдельным этапом, а не вместе с приемочным.
Данные и человеческий фактор
Даже точно спроектированная инфраструктура не даст нужного результата, если система работает на некорректных данных, а сотрудники избегают пользоваться ей. Именно из-за этого чаще всего ERP-проекты не достигают успехов.
Ошибка 7. Миграция некорректных мастер-данных
Компании считают миграцию данных технической задачей, хотя вся сложность заключается в самих справочниках. Одного и того же контрагента менеджеры могли внести несколько раз, номенклатуру в подразделениях вести по своим правилам, а остатки в системе давно отличаться от того, что лежит на складе.
Рассмотрим пример. После запуска ERP отчет о продажах показывает по клиенту половину оборота, потому что вторая половина проходит по дублирующей карточке этого же контрагента. Проходит месяц, руководители перестают верить отчетам из SAP и возвращаются к своим таблицам, а компания получает дорогую систему и прежний ручной учет рядом с ней.
Чтобы избежать этой ошибки, необходимо:
1/ Поручить чистку справочников бизнес-подразделениям и начать ее за несколько месяцев до миграции.
2/ Провести минимум две пробные загрузки данных и сверить суммы по остаткам и взаиморасчетам.
Ошибка 8. Экономия на обучении пользователей и поддержке после запуска
Обучение пользователей SAP приходится на конец проекта, когда бюджет исчерпан, а сроки сдвинуты, и программу сокращают до двухчасовой презентации. В итоге кладовщик не понимает, почему система не дает провести отгрузку, звонит знакомому из ИТ и запоминает временное решение как рабочую схему. Дальше весь склад работает по этому обходному пути, остатки в системе перестают сходиться с фактическими, и первая же инвентаризация показывает расхождения, которые никто не может объяснить.
Запуск в промышленную эксплуатацию не завершает проект. В первые недели после старта работает режим SAP Hypercare, то есть усиленная поддержка, когда консультанты находятся рядом с пользователями и ежедневно разбирают ошибки. Дальше компания переходит на регулярную поддержку после запуска ERP с согласованным SLA, и модель сопровождения стоит выбирать до старта проекта, о чем мы писали в материале про уровни поддержки SAP.
В плане проекта обучение и поддержка должны стоять отдельными строками с бюджетом:
1/ Программа обучения по ролям, с практикой на тестовой системе и проверкой знаний перед запуском.
2/ Формат Hypercare и условия дальнейшего сопровождения, согласованные с партнером до старта.
Игнорирование инноваций и будущего SAP-ландшафта
Последняя группа ошибок связана со сроками планирования, когда компания проектирует систему под задачи сегодняшнего дня и получает инфраструктуру, устаревшую моменту запуска.
Ошибка 9. Фокус только на on-premise без учета облачной стратегии
Локальную установку компании часто выбирают по инерции, ссылаясь на требования безопасности. Вместе с ней компания берет на себя расходы на оборудование и его администрирование, а новые функции получает с задержкой, потому что они выходят в очередном релизе SAP, а до пользователей доходят только после того, как ИТ-служба обновит систему. Преимущества облачных решений, например, SAP Cloud ERP, в обратном, то есть в предсказуемой стоимости владения и в том, что новые возможности платформы приходят вместе с регулярными релизами.
Перейти в облако SAP предлагает по двум программам, каждая из которых включает не только лицензии, но и инфраструктуру вместе с услугами перехода.
- RISE with SAP рассчитана на компании, которые уже работают в SAP и переводят систему на SAP S/4HANA в частном облаке.
- GROW with SAP рассчитана на тех, кто внедряет облачное решение с нуля и хочет быстро начать работу на стандартных процессах.
Обе программы стоит оценить при выборе архитектуры, даже если компания в итоге останется на локальной установке.
При выборе между локальной установкой и облаком стоит сравнить два показателя:
1/ Полная стоимость владения в перспективе пяти лет, включая оборудование, лицензии и работу администраторов.
2/ Срок, за который компания получит новую функциональность после того, как вендор выпустит ее в релизе.
Ошибка 10. Дорожная карта без искусственного интеллекта и предиктивной аналитики
ИИ-функции все глубже встраиваются в облачные решения SAP: Joule используется как пользовательский ИИ-ассистент, а SAP Business AI применяется в сценариях финансов, закупок, планирования и других бизнес-процессов. Это значит, что предприятие с классическим ландшафтом узнает о поломке насоса в момент остановки линии, а предиктивная модель позволяет выявить признаки потенциального отказа заранее и запланировать обслуживание до незапланированной остановки оборудования
Чтобы избежать этой ошибки, нужно учесть два пункта:
1/ Дорожная карта развития ландшафта описана на два года вперед и включает сценарии работы с данными.
2/ Архитектура данных спроектирована с учетом аналитических нагрузок, даже если ИИ-сервисы запустят позже.
Почему сертифицированный партнер SAP помогает избежать этих ошибок
Все эти ошибки дешевле предотвратить, чем исправлять после запуска. Компания, которая внедряет SAP впервые, замечает проблему поздно, когда переделывать нужно уже архитектуру. Поэтому такие проекты и доверяют опытному партнеру, который уже видел эти ошибки и знает, как их избежать.
IBA Group работает на рынке Казахстана более 13 лет и входит в число сертифицированных партнеров SAP. Наша команда провела десятки проектов в промышленности, энергетике, финансах и ритейле, от обследования до сопровождения системы, с учетом требований казахстанского учета. Об этапах внедрения SAP ERP и стоимости проекта мы рассказали отдельно, а возможности платформы разобрали в материале о SAP для крупного бизнеса.
Если вы планируете внедрение SAP в Казахстане или переход на SAP S/4HANA, начните с оценки процессов и рисков. Свяжитесь с экспертами IBA Group, и мы обсудим задачу и предложим план цифровой трансформации бизнеса.
Десять ошибок внедрения ERP
| Ошибка | Суть | Как избежать |
|---|---|---|
| 1. Отсутствие предпроектного обследования | Настройку начинают по общим требованиям, процессы описывают по ходу проекта | Описать сквозные процессы и перечень отклонений от стандарта до старта |
| 2. Нет спонсора со стороны топ-менеджмента | Спорные процессы некому решать, проект неделями стоит на паузе | Назначить спонсора уровня CEO или CFO с правом менять порядок работы |
| 3. Перенос неописанных процессов из старых систем | В SAP переезжают дублирующие согласования и нестандартные схемы | Сначала пересмотреть процессы под стандарт SAP, потом считать каждое отклонение |
| 4. Избыточная кастомизация вместо Clean Core | Сотни объектов Z-кода удорожают обновления и миграцию | Ядро оставить в стандарте, расширения делать на интерфейсах SAP или SAP BTP |
| 5. Затягивание миграции с SAP ECC | Поддержка заканчивается, консультанты в дефиците, цена перехода растет | Назначить дату ухода с SAP ECC и заложить на переход два года |
| 6. Проект без учета интеграций с государственными системами | ЭСФ и накладные оформляют вручную, компания получает штрафы | Зафиксировать перечень систем обмена и вынести интеграционное тестирование в отдельный этап |
| 7. Миграция некорректных мастер-данных | Дубли контрагентов и расхождения остатков ломают отчетность | Чистить справочники силами бизнеса заранее и делать пробные загрузки |
| 8. Экономия на обучении и поддержке | Пользователи работают обходными путями, данные расходятся с фактом | Заложить обучение по ролям и Hypercare в план и бюджет проекта |
| 9. Фокус только на on-premise | Расходы на оборудование и задержка новых функций | Сравнить стоимость владения на пять лет и оценить RISE with SAP и GROW with SAP |
| 10. Дорожная карта без ИИ и предиктивной аналитики | Ландшафт устаревает уже к моменту запуска | Расписать дорожную карту на два года и заложить аналитическую нагрузку в архитектуру |
Частые вопросы о внедрении SAP
Формально да, но экономия окажется временной. Без описанных процессов команда настраивает систему по общим требованиям, а расхождения между подразделениями всплывают на интеграционном тестировании, когда исправление стоит в разы дороже. Обследование фиксирует, как компания работает сейчас и как будет работать в SAP, и на этом же этапе становится понятен реальный объем проекта.
Основная поддержка SAP ERP 6.0 заканчивается 31 декабря 2027 года. Расширенная поддержка доступна за дополнительную плату до конца 2030 года. Планировать переход стоит минимум за два года, потому что к дедлайну свободных консультантов на рынке становится меньше, а стоимость проектов миграции растет.
Clean Core означает, что компания не переписывает стандартный код SAP, а добавляет свою специфику только теми способами, которые переживают обновление системы. Часть расширений делают внутри системы, на опубликованных вендором интерфейсах, часть выносят на SAP BTP. Бизнесу это дает возможность обновлять систему штатно и переходить на новые версии без многомиллионных доработок.
RISE with SAP рассчитана на компании, которые уже работают в SAP и переводят систему на SAP S/4HANA в частном облаке. GROW with SAP предназначена для тех, кто внедряет облачное решение с нуля и хочет быстро начать работу на стандартных процессах. Обе программы включают не только лицензии, но и инфраструктуру вместе с услугами перехода.
Hypercare — это режим усиленной поддержки в первые недели после запуска, когда консультанты находятся рядом с пользователями и ежедневно разбирают ошибки. Обычно он длится от двух недель до трех месяцев в зависимости от масштаба системы и числа пользователей. После Hypercare компания переходит на регулярную поддержку с согласованным SLA.
Чаще всего не из-за лицензий, а из-за недооцененных работ. Основные статьи перерасхода — доработки под привычки пользователей, миграция и чистка справочников, интеграции с внешними системами и обучение пользователей. Эти работы попадают в смету последними, а по факту занимают заметную часть проекта.