Модернизация ERP в 2026 году: облако, ИИ и Clean Core

Модернизация ERP в 2026 году означает три решения, принятых по порядку: что ваш ERP должен перестать делать, насколько чистым вы сохраните его ядро и достаточно ли хороши ваши данные, чтобы ИИ был полезен. Для клиентов SAP за всеми тремя стоит жёсткая дата: основная поддержка ECC заканчивается 31 декабря 2027 года, с платной расширенной поддержкой до конца 2030 года.

Материал для CIO, CFO и корпоративных архитекторов, которые закончили анализ и теперь должны действовать. В нём разобраны силы, подталкивающие к действию, архитектура «основа плюс спутники», Clean Core, пробел в управлении, готовность к ИИ и таблица рисков на ближайшие 18 месяцев.

В 2024 году большинство руководителей всё ещё выигрывали время: изучали сроки по ECC, спорили о гибридном и полном переходе, гоняли песочницы, ни к чему не обязываясь. Это окно закрылось. Технический долг в ландшафтах ECC и Oracle E-Business Suite больше не теоретический. Он проявляется в проваленных регрессионных тестах после обновлений, в замечаниях аудита по заказному коду, у которого нет владельца, и в данных, которые перемещаются между системами планирования и исполнения 12 часов.

Срок. После 2027 года клиенты ECC смогут купить расширенную поддержку до конца 2030 года по более высокой цене. Дальше SAP предлагает вариант перехода на частную редакцию ERP на 2031-2033 годы, но только через RISE, и SAP прямо говорит, что это платное предложение для перехода, а не продление поддержки. Между тем исследование Gartner, о котором писал The Register, показало, что к концу 2024 года лишь около 39 % из примерно 35 000 клиентов SAP на ECC купили лицензии на S/4HANA или оформили подписку. Лицензия не равна миграции. Рынок партнёров будет напряжённым.

Бюджетная модель. Облачный ERP переносит расходы с капитальных лицензий на подписки. Звучит аккуратнее. На практике CFO обнаруживают, что облачные затраты менее предсказуемы: в RISE with SAP и SAP GROW рост Full User Equivalent (FUE), дополнительные сервисы и накладные расходы на интеграцию добавляют затраты, которых не было в исходном бизнес-кейсе.

Фрагментация в финансах и цепочках поставок. Финансовые команды применяют ИИ к кредиторской и дебиторской задолженности, а аудиторские процедуры всё ещё опираются на шаблоны, созданные для другой эпохи. Цепочки поставок модернизированы частично: SAP IBP для планирования, старое управление складом для исполнения, Ariba для закупок, но ручная приёмка товара. Узкое место не в технологии. Оно в стыках между системами.

ERP лишь один слой, а не весь стек. Во многих компаниях ServiceNow оркестрирует процессы, Salesforce ведёт клиентские рабочие процессы, Workday или SuccessFactors ведут жизненный цикл сотрудника. ERP стал финансовой основой, а не универсальным центром процессов, каким его продавали в 1990-х.

Большинство корпоративных архитекторов сегодня работают с такой моделью: финансовая основа (SAP S/4HANA или Oracle Fusion), окружённая специализированными платформами.

Слой	Что здесь находится	Чего здесь нет
Финансовая основа	Главная книга, контроллинг, закупки, запасы, исполнение производства, обязательное закрытие периода	Согласования рабочих процессов, CRM, управление персоналом, аналитика
Рабочие процессы	ServiceNow для ИТ- и операционных процессов, согласований, управления изменениями	Транзакционный учёт
Взаимодействие с клиентами	Salesforce или SAP Sales and Service Cloud	Финансовая обработка
Персонал	Workday или SAP SuccessFactors	Операционные транзакции
Аналитика	SAP Business Data Cloud, SAP Analytics Cloud, Power BI, Snowflake	Первичная система учёта

Разделение сделано намеренно. Если вернуть всё в SAP, растёт трение, обновления замедляются, а границы владения размываются. Именно попытка втиснуть CRM, рабочие процессы, аналитику и EHS в одну систему сделала прежние программы такими мучительными.

Вопрос, который нужно задать: за что ERP больше не должен отвечать? Пропустите его, и вы построите тот же монолит на более новой лицензии. Один из вариантов такого разделения разобран в моей статье о модернизации ERP с SAP и ServiceNow.

В августе 2025 года SAP заменила трёхуровневую модель расширяемости на четыре уровня Clean Core. Уровень A использует только опубликованные стабильные API, side by side на SAP BTP или внутри системы на ABAP Cloud. Уровень B использует классические API и технологии, которые SAP по-прежнему считает чистыми. Уровень C обращается к внутренним объектам и требует особых мер. Уровень D не чистый.

Публичная редакция (SAP Cloud ERP, продаётся как SAP GROW) допускает только уровень A, поэтому платформа сама обеспечивает Clean Core и принимает два крупных релиза в год. Частная редакция (SAP Cloud ERP Private, в составе RISE) и on-premise по-прежнему допускают классические расширения, так что Clean Core там зависит от того, как выстроено управление. В любом случае сильно кастомизированная система превращает каждое обновление в проект, а каждый регрессионный тест в кризис.

Чего Clean Core требует от вас:

1. Уберите неиспользуемый заказной код из ядра. Каждую заказную программу, которую вы оставляете, придётся тестировать при каждом обновлении.
2. Создавайте новые расширения на уровне A, где это возможно: на SAP BTP, с SAP Build или внутри системы на ABAP Cloud.
3. Используйте стандартные процессы везде, где SAP их поставляет, и кастомизируйте только там, где этого требуют регулирование или реальное конкурентное отличие.

Сопротивление носит культурный, а не технический характер. Руководители бизнеса, 15 лет полагавшиеся на заказной код, по-прежнему ждут, что его «просто реализуют заново». Это ожидание родом из 2012 года.

В типичном ландшафте ECC от 1 500 до 3 000 заказных объектов, судя по оценкам, которые я проводил в производстве и сфере услуг, и лишь около четверти из них показывают активное использование в бизнесе. Остальное: исторический балласт, который раздувает стоимость миграции и создаёт риски при аудите.

Практический шаг: запустите сканирование использования уже сейчас. Выведите из обращения то, что неактивно. Опубликуйте список на сокращение до начала проектирования. У команд, которые планируют Clean Core с первой недели, обновления проходят намного лучше, чем у команд, которые видят в нём ограничение, которое нужно обходить. Метод разбирает моя статья о стратегии Clean Core.

Когда ERP лишь один из многих слоёв, вопросы владения становятся критичными. Кто отвечает за:

1. API между Salesforce и ERP?
2. Рабочий процесс, который охватывает SAP и ServiceNow?
3. Конфликтующие приоритеты изменений, когда обновления нужны обеим системам одновременно?

Я видел, как из-за этого go-live откладывался на месяцы. Команды не понимают, что застряли, пока интеграционное тестирование не вскрывает пересечение.

В одном случае пять систем обращались к одной и той же основной записи поставщика. Пять. Ни у кого не было документа о владении основными данными, и никто не продумал, кто что может менять и в какой системе. Это не сбой технологии. Это сбой управления, который обнажила технология.

Польза от ИИ в ERP реальна, но зависит от качества данных и чистой архитектуры. Joule теперь охватывает S/4HANA, SuccessFactors, Ariba и другие продукты SAP, а агенты SAP работают под ассистентами Joule. Агентные сценарии на SAP BTP уже поставляются клиентам, а не остаются слайдами. Все они зависят от чистых, согласованных, структурированных данных.

Если ваши данные дублируются, закодированы непоследовательно или лежат в заказных таблицах, которые S/4HANA не распознаёт, ИИ не на что опереться. Финансовые команды, запускающие ИИ на кредиторской задолженности, быстро это обнаруживают, когда счета сопоставляются не с тем поставщиком, потому что основные данные поставщиков так и не почистили.

Работает такая последовательность: сначала Clean Core, затем управление данными, затем аналитика, затем ИИ. Пропуск шагов ничего не ускоряет. Он переносит проблему на потом.

1. 01Определите границуРешите, что ERP должен перестать делать
2. 02Очистите ядроВыведите неиспользуемый код, новое стройте на уровне A
3. 03Возьмите данные под управлениеОдин владелец на каждый объект данных
4. 04Постройте аналитикуSAP Business Data Cloud, SAC или Power BI на управляемых данных
5. 05Добавьте ИИJoule и агенты на надёжной базе

ИИ с надёжной основой для работы

Риск	Сигнал	Практический ответ
Давление срока по ECC	Основная поддержка заканчивается в декабре 2027 года; к концу 2024 года большинство клиентов ECC не лицензировали S/4HANA	Зафиксируйте планы ресурсов партнёров сейчас; дневные ставки старших специалистов в США уже составляют от $1 800 до $3 500
Долг по заказному коду	От 1 500 до 3 000 заказных объектов, около четверти в активном использовании	Запустите сканирование использования, опубликуйте список на сокращение, начните спринты по выводу из эксплуатации
Сбои из-за релизов	Релизы совпадают с финансовым закрытием и пиками в цепочке поставок	Назначайте окна релизов вдали от закрытия; автоматизируйте регрессионные тесты
Риск миграции данных	Поздняя гармонизация порождает дефекты, которые команды ошибочно считают багами	Ранняя оценка объёма; проверки банковских, налоговых данных и данных по комплаенсу до заморозки дизайна
Пробелы во владении интеграциями	Пять и более систем затрагивают общие основные данные	Опубликуйте матрицу полномочий; один владелец на каждый объект данных
Два инструмента жизненного цикла	В гибридных ландшафтах параллельно работают Solution Manager и SAP Cloud ALM	Cloud ALM по умолчанию для облачных программ; основная поддержка Solution Manager 7.2 заканчивается в конце 2027 года

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

Что такое Clean Core в SAP S/4HANA?

Это когда S/4HANA остаётся как можно ближе к стандарту, а расширения размещаются там, где обновления их не сломают. С августа 2025 года SAP оценивает расширения от уровня A (только опубликованные API, на SAP BTP или внутри системы на ABAP Cloud) до уровня D (не чистый). Деловая причина в защите обновлений: чистая система принимает релизы за дни, а сильно кастомизированная превращает каждый релиз в проект.

Что такое архитектура ERP «основа плюс спутники»?

ERP (SAP S/4HANA или Oracle Fusion) занимается тем, для чего создан: финансовым учётом, запасами, закупками, производственными транзакциями и обязательной отчётностью. Остальным занимаются специализированные платформы: ServiceNow для рабочих процессов, Salesforce для работы с клиентами, Workday или SuccessFactors для HR и аналитические платформы для получения выводов. Если загнать всё это в ERP, получится монолит, который медленно обновляется и сильно кастомизируется.

Как компаниям подходить к сроку 2027 года для SAP ECC?

Начните с SAP Readiness Check. Он показывает объёмы заказного кода, зависимости от дополнений и оценку объёма данных, то есть три фактора, которые определяют, пойдёте ли вы по пути brownfield, greenfield или selective. Сложные корпоративные миграции обычно занимают от 18 до 24 месяцев от оценки до go-live, поэтому если вы до сих пор не выбрали подход и не начали разговоры с партнёрами, go-live в 2027 году уже впритык. Расширенная поддержка до 2030 года стоит дороже и даёт время, а не инновации.

Когда ИИ полезен при модернизации ERP, а когда нет?

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

Какие самые серьёзные ошибки компании допускают при модернизации ERP?

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

Сколько стоит модернизация ERP?

Конверсия brownfield с ECC на S/4HANA для компании среднего бизнеса обычно обходится в $2-8 млн затрат на внедрение плюс текущая подписка. Корпоративные программы с глобальным охватом, значительной кастомизацией и множеством юридических лиц могут стоить от $20 млн до $100 млн и выше. Закладывайте в модель интеграцию, тестирование и эксплуатационную поддержку, а не только лицензии, а в RISE и SAP GROW моделируйте рост FUE на весь срок договора.