10 ошибок модернизации ERP, которых стоит избежать

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

Эта статья для CIO, CFO и директоров программ, которые планируют или спасают модернизацию S/4HANA или другой ERP. К каждой ошибке ниже приложено, как она выглядит на практике, и способ исправления, а затем идут чек-лист раннего предупреждения на одну страницу и объяснение, что значат изменения SAP 2026 года.

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

1. Считать go-live финишем

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

Я видел проекты, где управляющий комитет распускают сразу после go-live. Через шесть месяцев принятие системы стоит на месте, и бэклогом никто не владеет.

Решение: профинансируйте период управления после go-live на срок от 6 до 12 месяцев. Продлите мандат управляющего комитета. Отслеживайте принятие процессов, а не только доступность системы. Установите контрольные точки качества после go-live с названными владельцами.

2. Переносить устаревшие процессы, не переосмыслив их

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

Вариант этого для S/4HANA: пользовательские пакетные задания, перенесённые из ECC как есть, хотя они построены на структурах таблиц, которых больше нет. Миграция технически чистая. Бизнес-логика сломана.

Решение: перепроектируйте процессы до разработки. Пройдите с командами операций, финансов и поставки по каждому процессу вместе и ставьте под сомнение каждый шаг.

Область наследия	Что часто идёт не так	Что делать вместо этого
Пользовательский код из ECC	Неиспользуемый пользовательский код переносят в S/4HANA	Проведите анализ использования и проверки пользовательского кода SAP; выведите неиспользуемый код из эксплуатации
Старые процессы	Потоки согласования воссоздают, хотя теперь возможна автоматизация	Пересмотрите вместе с владельцами бизнеса; используйте стандартные приложения Fiori или SAP Build Process Automation
Нестандартные основные данные	Гибкие унаследованные схемы не проходят проверки S/4HANA	Очистите и согласуйте до миграции, с SAP MDG там, где он подходит
Отчёты на унаследованных таблицах	Прямой доступ к таблицам не соответствует модели данных S/4HANA	Перестройте на CDS-представлениях
Скрытые ручные обходные пути	Параллельные процессы возвращаются после go-live	Используйте process mining до миграции и оцифруйте пробелы

3. Слишком поздно начинать миграцию данных

Переносить плохие данные в новую ERP всё равно что переезжать, ничего не выбросив. Хлам переезжает вместе с вами, и разгребать его труднее, когда он уже внутри структурированной системы.

Однажды я видел, как go-live провалился, потому что никто не заметил: в ключевом наборе данных были записи пяти разных бизнес-подразделений, у каждого своя логика кодирования. Техническая миграция прошла корректно. Данные были непригодны. Отчёты ломались, пользователи теряли доверие, а наведение порядка в работающей системе заняло месяцы.

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

4. Относиться к управлению изменениями как к побочной задаче

Обычный вариант: управление изменениями «уже закрыто», то есть несколько слайдов, демо и одно обучение перед go-live.

Люди сопротивляются не потому, что не любят перемены. Они сопротивляются, когда никто не объясняет, почему всё меняется и чем это поможет им. Они пользуются системой ровно настолько, чтобы пройти чек-лист, а потом возвращаются к таблицам.

Обычный спусковой крючок: давление сроков. Обучение сжимают, чтобы выиграть время, пользователи теряются на go-live, а дополнительный hypercare обходится дороже, чем урезанное обучение.

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

5. Строить планы вокруг дорожных карт вендора

Я видел команды, которые строили интеграционную стратегию на будущем релизе вендора, а потом релиз сдвигался на 12 месяцев. Тем временем им приходилось делать временные обходные решения, и они становились постоянными.

Вендоры строят дорожные карты для широких групп клиентов. Ваш бизнес редко находится в центре такого замысла.

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

6. Нет плана вывода из эксплуатации устаревших систем

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

Решение: включите вывод из эксплуатации в устав проекта с первого дня, с участием юристов, службы соответствия требованиям и управления данными, а не только ИТ. Согласуйте сроки хранения и подход к архивированию до go-live, опишите и отключите каждый интерфейс к старой системе и поручите одной команде выключить её.

7. Недооценивать сложность интеграции

Когда интеграция даёт сбой, бизнес замечает это раньше ИТ, потому что процессы останавливаются на полпути в продуктивной системе, а не в тестовой.

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

Решение: начинайте проектирование интеграции на этапе blueprint. Определите каждый сценарий, middleware, сопоставление и объёмы сообщений и уточните вместе с бизнесом по каждому интерфейсу, нужен режим реального времени или пакетный. Назначьте владельца интерфейса с SLA до go-live. В новых программах SAP в роли middleware выступает SAP Integration Suite; SAP PI/PO выходит из основной поддержки в конце 2027 года.

8. Считать, что ERP справится со всем

Я работал на проектах, где команды заталкивали в ERP сложные сервисные процессы (ИТ-заявки, запросы на активы, маршрутизацию эскалаций), потому что не хотели привлекать внешние системы вроде ServiceNow. В результате везде появились пользовательские поля и ручные обходные пути, а пользователи застряли в процессе, который так и не подошёл.

ERP хороша в структурированных, транзакционных процессах, привязанных к финансам. Запросы ИТ-сервиса, оркестрацию процессов и управление знаниями лучше делают специализированные платформы.

Решение: сознательно решите, что не нужно строить в ERP. Для исключений используйте расширения side-by-side на SAP BTP, а для оркестрации за пределами транзакционного ядра ServiceNow или аналог. Это разделение разобрано в моей статье про модернизацию ERP с SAP и ServiceNow.

9. Недооценивать долгосрочную стоимость лицензий

Я знаю команду, которая удвоила расходы на лицензии на втором году, потому что ей понадобилась одна функция, доступная только по лицензии более высокого уровня. В бизнес-кейсе моделировали стоимость только на момент go-live.

Лицензии ERP начисляются за пользователей, модули, транзакции и использование API, и стоимость растёт вместе с бизнесом, планировали вы это или нет. В SAP модель Digital Access означает, что документы, созданные сторонними системами, могут нести лицензионную стоимость, которой не было в исходной коммерческой модели. В RISE и SAP GROW количество Full User Equivalent (FUE) растёт по мере принятия системы.

Решение: до подписания постройте лицензионную модель на срок от трёх до пяти лет. Сопоставьте роли с типами лицензий, смоделируйте рост FUE на реалистичной кривой принятия, разберитесь с косвенным доступом до подключения внешних систем и проверьте неактивных пользователей после go-live.

10. Воспринимать ERP как ИТ-проект

Самая частая и самая разрушительная закономерность. Планирование начинается в ИТ, ведётся ИТ и решает проблемы ИТ.

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

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

Используйте его на каждом управляющем комитете. Если признак присутствует, названный владелец докладывает по нему, пока он не исчезнет.

1. УставОтветственность и стоимостьНет руководителя операций или финансов, нет пятилетней лицензионной модели, нет даты вывода из эксплуатации
2. BlueprintПроектирование процессов и интеграцииСегодняшний процесс скопирован, интерфейсы ещё не спроектированы
3. Первая тестовая загрузкаДанныеОтчёта о качестве данных пока нет
4. Go-liveЧто происходит дальшеНет финансируемого управления на следующие 12 месяцев

Ошибка	Ранний признак	Владелец
1. Go-live как финиш	Нет финансируемого плана управления на 12 месяцев после go-live	Спонсор
2. Скопированные устаревшие процессы	Дизайн-воркшопы начинаются с экранов «как мы делаем сегодня»	Владельцы процессов
3. Поздняя работа с данными	Нет отчёта о качестве данных перед первой тестовой загрузкой	Руководитель миграции данных
4. Изменения как побочная задача	План изменений сводится к календарю обучения	Руководитель по изменениям
5. Зависимость от дорожной карты	Проектное решение ждёт функцию, которая ещё не выпущена	Архитектор решения
6. Нет вывода из эксплуатации	В уставе нет даты вывода ни одной устаревшей системы	PMO
7. Недооценка интеграции	К концу blueprint интерфейсы не спроектированы	Руководитель интеграции
8. ERP для всего	Пользовательские объекты для нетранзакционных процессов	Корпоративный архитектор
9. Лицензирование	В бизнес-кейсе нет пятилетней лицензионной модели	CFO
10. Программа только для ИТ	В управляющем комитете нет руководителя операций или финансов	Спонсор

Развёртывание. Для новых программ SAP по умолчанию выбирают RISE with SAP на SAP Cloud ERP Private или SAP GROW на публичной редакции (SAP Cloud ERP) для компаний среднего размера. Новые развёртывания on-premise встречаются редко. Клиенты ECC сталкиваются с тем, что основная поддержка заканчивается 31 декабря 2027 года, и это сокращает время на исправление ошибок 2, 3 и 7.

Clean Core. SAP теперь оценивает расширения по четырём уровням Clean Core, от A (только released API, side-by-side на BTP или внутри системы с ABAP Cloud) до D (не чисто). Публичная редакция допускает только уровень A, и это заставляет вести разговор, стоящий за ошибкой 2. Приватная редакция по-прежнему допускает классические расширения, поэтому дисциплина должна идти от управления. Именно классический пользовательский код превращает каждое обновление в проект. Подробнее в моей статье про стратегию Clean Core.

ИИ в инструментах реализации. Joule теперь встроен в SAP Cloud ALM и SAP Activate Roadmap Viewer, а SAP Build Code использует Joule для разработки расширений. Спросите у партнёров, как инструменты ИИ отражены в их прейскуранте. Если не отражены, то либо цена завышена, либо экономия уходит в их маржу.

Инструменты жизненного цикла. Для облачных программ инструментом управления жизненным циклом служит SAP Cloud ALM. Solution Manager 7.2 выходит из основной поддержки в конце 2027 года, поэтому ландшафтам, где работают оба, нужен план перехода.

Десять ошибок не изменились. Изменилась цена ошибки. В программе RISE решение по Clean Core, модель развёртывания и модель FUE определяются в первые недели мобилизации. Окно, в котором на них можно повлиять, короткое.

Почему модернизация ERP не оправдывает ожиданий после go-live?

Большинство команд планируют до go-live и на этом останавливаются. Никто не отвечает за доработки, обратную связь, корректировку процессов и бэклог. Самый надёжный признак беды: управляющий комитет распускают на go-live. С первого дня профинансируйте от 6 до 12 месяцев управления после go-live.

В чём риск копирования устаревших процессов в новую ERP?

Новая система наследует старую неэффективность, но дороже. В миграциях на S/4HANA в частности пользовательский код и пакетные задания, созданные под таблицы ECC, часто не работают, поэтому миграция может быть технически чистой, а бизнес-логика при этом сломана.

Как плохое качество данных вредит модернизации ERP?

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

Почему управление изменениями так часто недооценивают в проектах ERP?

Потому что в плане проекта оно не так заметно, как настройка. Руководители считают, что нескольких обучающих сессий достаточно. Управление изменениями означает подготовку людей к тому, что на самом деле изменится в их ежедневной работе, до go-live. Инструменты цифровой адаптации, такие как WalkMe (теперь принадлежит SAP), помогают подсказками внутри приложения, но не заменяют объяснение того, зачем всё это.

Почему устаревшие системы продолжают работать годами после go-live ERP?

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

Как RISE with SAP и Clean Core меняют эти ошибки?

В публичной редакции правила Clean Core делают глубокую кастомизацию невозможной, и это заставляет вести разговор о процессах, стоящий за ошибкой 2. В приватной редакции классические расширения по-прежнему разрешены, поэтому Clean Core зависит от управления. Интеграция переходит на SAP Integration Suite, так как поддержка PI/PO заканчивается. Лицензирование превращается в вопрос роста FUE. Вывод из эксплуатации становится более срочным, потому что параллельная работа устаревших систем добавляет затраты к многолетней подписке.