К чему готовиться компании после миграции на SAP S/4HANA
Переход на SAP S/4HANA обновляет ERP-систему, но сам по себе не меняет бизнес-процессы компании. Поэтому запуск системы в продуктив (go-live) завершает только проект внедрения, а основная работа для компании начинается после него.
В день go-live проектная команда передает систему ИТ-службе и бизнесу. Дальше они эксплуатируют систему и проверяют, подходит ли она для ежедневной работы. Первый раз они проверяют систему при закрытии отчетного месяца и в период пиковой нагрузки, второй — при обновлении релиза. Готовиться к этим проверкам ИТ-службе и бизнесу нужно еще до запуска, потому что после go-live времени на подготовку у них не останется.
Поскольку процессы после запуска меняет сама компания, руководству стоит рассматривать SAP S/4HANA как основу новой операционной модели. Ценность системы для бизнеса зависит от того, насколько быстро и безопасно компания сможет менять процессы после запуска.
Окончание поддержки SAP ECC объясняет причину перехода, но не определяет его цель
Основная поддержка (mainstream maintenance) для SAP Business Suite 7, включая SAP ECC 6.0 с пакетами расширений EHP 6–8, заканчивается 31 декабря 2027 года. После этой даты компания, которая продолжает работать на SAP ECC, выбирает один из нескольких вариантов:
- Она может купить расширенную поддержку (extended maintenance) до конца 2030 года и платить за нее на два процентных пункта больше базовой ставки поддержки.
- Если компания не покупает расширенную поддержку, она переходит в режим customer-specific maintenance, в котором SAP не выпускает обновления под изменения законодательства (legal changes) и не гарантирует сроки исправления ошибок.
- Для части крупных клиентов SAP также предлагает отдельный вариант перехода (transition option) по программе RISE with SAP.
Каждый из этих вариантов либо откладывает переход, либо делает работу на SAP ECC дороже и рискованнее. Поэтому условия поддержки объясняют, почему компании нужно уходить с SAP ECC, однако не отвечают на вопрос, какие новые возможности бизнес получит после перехода.
От ответа на этот вопрос зависит, как компания сформулирует цель программы перехода. Цель «уйти с SAP ECC до конца 2027 года» задает только срок, и компания достигает ее в день go-live. Цель «закрывать месяц быстрее и устанавливать новые релизы без остановки бизнеса» описывает новую возможность компании, и работа над ней с go-live только начинается.
Какие показатели успеха важны после запуска SAP S/4HANA
До запуска руководство оценивает успех проекта по его срокам и бюджету, объему перенесенных данных, результатам перехода на новую систему (cutover) и числу найденных ошибок. Все эти показатели относятся к проекту внедрения, поэтому после внедрения в промышленную эксплуатацию руководителей бизнеса интересует, как система работает в ежедневных операциях. Эту работу описывают другие показатели:
- за сколько дней бухгалтерия закрывает отчетный период и сколько ручных корректировок она при этом вносит;
- сколько заказов клиентов, заказов поставщикам, отгрузок и платежей система останавливает из-за ошибок интеграции или незаполненных основных данных;
- сколько времени проходит с момента, когда бизнес согласовал изменение, до момента, когда ИТ-служба безопасно переносит его в продуктивную систему;
- какая доля пользователей работает в системе и какая доля продолжает работать с выгрузками и локальными файлами.
По этим показателям руководство понимает, изменилась ли работа компании после перехода. Если через полгода после запуска сотрудники по-прежнему собирают ключевые отчеты в MS Excel, а любая доработка процесса снова требует отдельного проекта, значит, компания выполнила техническую миграцию, но сохранила прежнюю операционную модель. На тот же результат указывает ситуация, когда команда перенесла в SAP S/4HANA все доработки из SAP ECC без изменений.
Чтобы после технической миграции компания изменила и операционную модель, ей нужно вести работу по семи направлениям. Они охватывают стабилизацию системы и управление доработками, вывод SAP ECC из эксплуатации и управление данными, регулярные обновления релизов и регуляторные требования, а также подготовку к внедрению ИИ. Рассмотрим их подробнее.
1. Стабилизация системы
После go-live мониторинг может показывать, что система работает нормально. Однако в это же время система блокирует заказы, интерфейсы не передают данные, а пользователи обрабатывают операции вручную в обход системы. Поэтому в первые дни после запуска команда эксплуатации фиксирует базовые значения по критичным бизнес-процессам, например, длительность закрытия периода и число исключений в процессе order-to-cash, количество ошибок интеграций и ручных проводок. В гибридном ландшафте SAP Cloud ALM сопоставляет технические события с их последствиями для бизнеса. С его помощью команда обнаруживает проблему раньше, чем она сорвет закрытие периода или работу производства и склада.
Первые недели после запуска компания работает в режиме усиленной поддержки (hypercare). Завершать этот режим команде стоит только тогда, когда система и процессы работают стабильно. Например, если бухгалтерия закрыла первый месяц без эскалаций, владельцы процессов принимают решения без проектной команды, а повторяющиеся инциденты команда перенесла в бэклог улучшений. Первое условие часто сложно выполнить из-за договора с интегратором. Поддержка интегратора нередко заканчивается через несколько недель после запуска, а первое полноценное закрытие бухгалтерия проводит позже. Поэтому руководителю программы стоит еще при подписании договора согласовать срок поддержки так, чтобы он охватывал первое закрытие периода.
2. Следование принципу clean core
Принцип clean core («чистое ядро») требует, чтобы стандартное ядро SAP S/4HANA оставалось готовым к обновлениям. Уникальную логику компании команда разработки выносит в контролируемые расширения и стабильные интерфейсы. Собственный код (Z-код) и доработки clean core не запрещает, однако у каждой доработки должны быть владелец и обоснование. По каждой доработке команда принимает одно из четырех решений: удалить доработку, заменить ее стандартной функцией, переписать на ABAP Cloud или в виде отдельного приложения на SAP BTP (side-by-side) либо оставить на ограниченный срок с датой пересмотра.
Перенос доработки на платформу SAP BTP не делает ядро автоматически чище. Сервис на SAP BTP без владельца и с плохой архитектурой остается тем же техническим долгом. Разница только в том, что этот долг находится за пределами ERP-системы, а за ресурсы платформы компания платит отдельно. Чистоту ядра поддерживают простые правила разработки: использование официальных API от SAP, проверка кода на соответствие clean core в ABAP Test Cockpit (ATC) и соблюдение стандартов интеграций. Каждое исключение из этих правил команда согласует по отдельной процедуре, в которой указаны ответственный, срок исключения и дата пересмотра.
После go-live эта процедура особенно нужна, хотя при планировании руководители программ часто об этом забывают. После запуска пользователи сравнивают новую систему с прежней, замечают отличия в привычных операциях и просят больше доработок. Если команда не может обоснованно отказать в доработке, за несколько релизов она снова наполняет ядро собственным кодом, и компания теряет преимущества clean core.
3. Вывод из эксплуатации старой системы SAP ECC
После запуска SAP S/4HANA компании обычно сохраняют SAP ECC в работе еще один-два года, чтобы сотрудники имели доступ к историческим данным. Все это время компания платит за инфраструктуру и сопровождение старой системы, обслуживает интерфейсы в режиме параллельной работы двух систем (dual-run) и проходит аудит по обеим системам. Пользователи при этом могут в любой момент вернуться к привычным отчетам в старой системе и медленнее переходят на работу в SAP S/4HANA.
Чтобы прекратить эти расходы, компании нужен план вывода SAP ECC из эксплуатации с датами и назначенным владельцем. Владелец плана определяет, какие данные команда архивирует и в каком виде исторические данные останутся доступны для налоговых и аудиторских запросов. Он также решает, какие требования к срокам хранения данных команда выполнит с помощью SAP Information Lifecycle Management (ILM) и в каком порядке отключит интерфейсы. Вместе с интерфейсами компания выводит из использования теневые решения, которые сотрудники создали для работы с SAP ECC, например, локальные базы данных и макросы, а также самодельные выгрузки. Особое значение в плане имеет дата отключения SAP ECC. Если владелец плана ее не назначит, старая система продолжит работать, потому что ни одно подразделение не заинтересовано назначать такую дату самостоятельно.
4. Управление данными, интеграциями и полномочиями
Сам переход на SAP S/4HANA не делает данные полными и согласованными. Чтобы добиться этого, компании нужно назначить владельцев данных и ввести единые определения показателей, отслеживать происхождение данных и контролировать их качество.
Отдельный риск создают точечные интеграции. Если команда подключает системы по одной и не знает всех зависимостей между ними, данные в разных системах перестают совпадать, причем быстрее, чем из-за любой ошибки в коде. Часть этих задач решает SAP Business Data Cloud, который объединяет данные из SAP и внешних источников и сохраняет их бизнес-семантику. Но продукт не заменяет владельцев данных, единые определения и контроль качества, поэтому выбор продукта здесь вторичен.
Отдельно компании стоит проверить роли пользователей. В первые месяцы после запуска команда поддержки срочно устраняет инциденты и выдает пользователям «временные» роли с широкими правами. Потом эти роли остаются в системе и создают конфликты разделения полномочий (SoD), которые аудиторы обнаружат на ближайшей проверке. Поэтому команде стоит пересмотреть роли между 60-м и 90-м днем после запуска.
5. Переход от больших проектов к регулярным обновлениям релизов
Начиная с 2023 года SAP выпускает новые версии SAP S/4HANA раз в два года и поддерживает каждую из них семь лет. Актуальная версия SAP S/4HANA 2025 доступна с октября 2025 года, и SAP поддерживает ее до конца 2032 года. Следующую версию SAP планирует выпустить в четвертом квартале 2027 года. Между выходом новых версий SAP выпускает пакеты функций (feature package stacks, FPS), поэтому компания обновляет систему регулярно. Техническую часть обновления выполняет SAP или партнер, однако оценку влияния обновления на процессы, тестирование и освоение новых функций компания проводит сама.
Чтобы проходить обновления без остановки бизнеса, к первому обновлению компании нужно подготовить четыре элемента:
- автоматизированный набор регрессионных тестов по критичным сквозным процессам, без которого каждый пакет FPS превращается в отдельный проект тестирования;
- календарь релизов, который ИТ-служба согласовала с календарем бизнеса;
- владельца релиза с полномочиями менять его состав;
- бюджет на изменения, который компания выделяет отдельно от бюджета на сопровождение.
Последний пункт руководители часто недооценивают. Если компания не заложила в модель поддержки деньги на развитие, команда не может выполнить улучшения из бэклога, и бэклог остается списком пожеланий.
Когда деньги на развитие есть, команде нужно решить, какие улучшения из бэклога выполнить в первую очередь. Приоритеты команда определяет по эффекту для бизнеса. Для этого она выбирает несколько сквозных процессов и находит в каждом ограничение, которое можно выразить в цифрах. Метод process mining показывает узкие места в процессах по фактическим записям системы, поэтому участникам не приходится о них спорить. Затем команда ранжирует изменения по их влиянию на KPI, и настойчивость отдельного подразделения на очередность изменений не влияет.
6. Учет регуляторных требований в архитектуре платформы
Кроме бизнес-приоритетов, на развитие платформы SAP влияют требования регуляторов. В Казахстане, Узбекистане и Азербайджане эти требования касаются хранения персональных данных и кибербезопасности, а также использования ИИ:
- Казахстан. Закон «О персональных данных и их защите» требует хранить базы персональных данных граждан на серверах в Казахстане. Поэтому компании нужно заранее решить, где будет работать SAP S/4HANA и где будут храниться данные о клиентах и сотрудниках, особенно если компания выбирает облачную модель RISE with SAP. Об утечке персональных данных компания обязана уведомить уполномоченный орган в течение одного рабочего дня, и за такой срок служба безопасности успеет отреагировать, только если мониторинг SAP сразу передает ей информацию об инцидентах. Закон «Об искусственном интеллекте», который действует с 18 января 2026 года, касается и ИИ-функций SAP, например Joule. Если такая функция принимает решения о правах клиентов или сотрудников, компания сообщает пользователям о работе ИИ и должна уметь объяснить его решение.
- Узбекистан. В марте 2026 года президент подписал поправки, которые смягчили требования к хранению персональных данных. Теперь компания обязана хранить в стране только биометрические и генетические данные, а также данные абонентов телекоммуникационных сетей. Остальные данные из SAP S/4HANA компания может обрабатывать в облаке за рубежом, если выполняет условия закона, например подписывает с провайдером утвержденные типовые условия договора. Биометрические данные, например из систем контроля доступа, которые интегрированы с SAP, компании по-прежнему нужно хранить в Узбекистане. Правила этики ИИ, которые Минюст зарегистрировал в марте 2026 года, запрещают принимать юридически значимые решения о правах человека только на основе ИИ. Поэтому если компания использует ИИ-функции SAP, например в HR-процессах, окончательное решение принимает сотрудник.
- Азербайджан. Закон «О персональных данных» разрешает передавать персональные данные третьим лицам только с письменного согласия субъекта, если закон не предусматривает исключений. В SAP-ландшафте это требование касается интеграций, по которым SAP передает данные клиентов и сотрудников внешним сервисам и провайдерам. По каждой такой интеграции компании нужно подтвердить, что у нее есть согласие субъектов или другое законное основание для передачи. Кроме того, 7 июля 2026 года Милли Меджлис в первом чтении принял поправки к закону «Об информации, информатизации и защите информации». Если парламент примет их окончательно, владельцы информационной инфраструктуры, в том числе систем SAP, будут обязаны выявлять киберинциденты и сообщать о них.
Во всех трех странах требования к платформе SAP похожи, поэтому компания выполняет их с помощью одного набора документов и настроек:
- реестр интеграций, поставщиков и мест хранения персональных данных;
- минимально необходимые права пользователей и разделение полномочий;
- тесты восстановления с зафиксированными показателями RTO (допустимое время восстановления) и RPO (допустимый объем потери данных);
- журналы безопасности, прослеживаемость изменений и порядок уведомления регулятора об инцидентах.
Для сценариев с ИИ компания дополнительно классифицирует риск, описывает сценарий использования и определяет точку, в которой человек может вмешаться в работу системы. Этого требуют и казахстанский закон об ИИ, и узбекские правила этики ИИ.
7. Внедрение ИИ как проверка зрелости платформы SAP
ИИ-функции уже есть в решениях SAP. Например, ИИ-ассистент Joule работает в бизнес-процессах, а функции ABAP AI помогают разработчикам переписывать код. SAP предоставляет их в том числе клиентам SAP S/4HANA Cloud Private Edition начиная с релиза 2021. Поэтому руководству уже не нужно решать, внедрять ли ИИ. Ему нужно решить, на каких данных будет работать ИИ и кто отвечает за его результаты.
Данные здесь важны, потому что ИИ работает так же хорошо или так же плохо, как процесс, в который его встроили. Если процесс стандартный и данные достоверные, ИИ его ускоряет. Если сотрудники в конце месяца вручную исправляют ошибки и обходят систему, ИИ повторит эти ошибки, только быстрее и в большем объеме. Поэтому к ИИ готова компания, у которой «чистое ядро», понятные данные и зафиксированные полномочия, то есть компания, которая провела работы после go-live.
Начинать компании стоит с одного сценария. В нем должны быть владелец результата и данные приемлемого качества, а объем ручной работы, которую заменит ИИ, компания должна уметь посчитать. Сотрудник в таком сценарии может отменить решение ИИ. Стоимость сценария финансовой службе нужно считать с первого дня, потому что SAP тарифицирует ИИ-функции в AI units и расходы растут вместе с использованием.
Как компании оценивать успех перехода на SAP S/4HANA
Руководству бизнеса не нужно разбираться в перечне функций SAP, чтобы контролировать все описанные направления работ. Достаточно, чтобы ИТ-служба давала руководству внятные ответы на пять вопросов:
- Какие бизнес-KPI изменились после go-live и на сколько?
- Сколько времени проходит от идеи изменения до его безопасного запуска в продуктивной системе?
- Какие расширения и интеграции усложнят следующее обновление и какое решение по ним приняла команда?
- Какие данные компания считает эталонными и кто персонально отвечает за их качество?
- Может ли компания документально подтвердить, что контролирует доступ, изменения, устойчивость систем и решения ИИ?
Если в компании нет сотрудников, которые отвечают за эти вопросы, значит, компания завершила техническую миграцию на SAP S/4HANA, но трансформацию бизнеса еще не провела.
Рабочий план на первые 90 дней после go-live
Таблица распределяет работы первых трех месяцев после запуска по трем периодам и называет ответственного за каждый результат.
Какие выводы стоит сделать руководству
Если компания рассматривает SAP S/4HANA только как замену SAP ECC, она сохраняет прежнюю операционную модель и работает с ней на более дорогой платформе. Другой результат получает компания, которая после миграции системно развивает процессы, данные, архитектуру и компетенции сотрудников. Такая компания может менять бизнес-процессы, не запуская каждый раз новый большой проект.
Какой из двух результатов получила компания, руководство может проверить по одному признаку. Если компания меняет процесс и устанавливает новый релиз, не нарушая стабильность ядра системы и не собирая проектный офис заново, значит, после миграции она достигла зрелости. Такой результат компания получает только после go-live, потому что миграция на SAP S/4HANA заканчивается в день запуска, а работа с ERP-системой после этого дня продолжается.