Шаблоны внедрения SAP: руководство по фазам

SAP Activate поставляется с шаблоном почти для каждого результата программы S/4HANA. Вы найдёте их в SAP Activate Roadmap Viewer, а в облачных программах ещё и внутри SAP Cloud ALM. Найти их легко. Трудно понять, к каким из них относиться всерьёз.

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

Закономерность в программах ECC и S/4HANA, где я работал в производстве, ритейле и финансовых услугах, одна и та же. Команды, которые следуют шаблонам, ловят проблемы раньше. Команды, которые считают их необязательной бумажной работой, обнаруживают посреди проекта, что каждое незаписанное решение превратилось в спор об объёме.

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

Фаза	Шаблон	Владелец	Утверждается до
Prepare	Документ определения объёма проекта	Руководитель программы (утверждает спонсор)	начала Explore
Prepare	Бизнес-кейс	CFO или владелец бизнеса	выделения финансирования
Prepare	Матрица заинтересованных сторон	Руководитель программы	назначения семинаров Explore
Explore	Таблица требований и fit-gap	Архитектор решения вместе с владельцами процессов	начала Realize
Realize	Журнал конфигурации	Функциональные руководители	перемещения каждого транспорта в QA
Realize	Реестр кастомной разработки	Руководитель разработки	начала разработки любого объекта
Realize	Стратегия тестирования	Руководитель тестирования	начала системного интеграционного тестирования
Realize	План миграции данных	Руководитель миграции данных	первой пробной загрузки
Deploy	План cutover	Менеджер cutover	финальной генеральной репетиции
Deploy	Оценка готовности к go-live	Директор программы (подписывает спонсор)	совещания go/no-go
Run	Модель поддержки hypercare	Руководитель по предоставлению сервисов	go-live
Run	Таблица мониторинга производительности	Руководитель Basis	go-live

Activate состоит из шести фаз: Discover, Prepare, Explore, Realize, Deploy и Run. Он объединяет содержимое SAP Best Practices, управляемую настройку и гибкий подход к поставке. У большинства заказчиков Discover проходит до подписания контракта, поэтому шаблоны ниже начинаются с Prepare.

1. 01DiscoverОбычно до подписания контракта
2. 02PrepareДокумент определения объёма, бизнес-кейс, матрица заинтересованных сторон
3. 03ExploreТаблица требований и fit-gap
4. 04RealizeЖурнал конфигурации, реестр разработки, стратегия тестирования, план миграции
5. 05DeployПлан cutover, готовность к go-live
6. 06RunМодель hypercare, мониторинг производительности

Каждый шаблон подписан до своей контрольной точки

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

Адаптируя шаблоны, сохраняйте около 80% стандартной структуры. Меняйте только то, что отражает ваш контекст: отраслевые требования, регуляторные контроли, региональную специфику. Если переписать всё, смысл теряется.

Что изменилось в инструментах в 2026 году

Структура Activate прежняя. Изменились инструменты вокруг неё.

1. SAP Cloud ALM хранит шаблоны в облачных программах. Это преемник Solution Manager, он входит в SAP Enterprise Support и в облачные подписки, такие как RISE with SAP. Определение объёма, требования, планы тестирования и задачи cutover могут жить там со сквозной прослеживаемостью. Solution Manager 7.2 выходит из основной поддержки в конце 2027 года, а для некоторых функций расширенная поддержка идёт до 2030 года, так что у действующих on-premise-ландшафтов есть несколько лет, а не десятилетие.
2. Joule теперь встроен в инструменты методологии. SAP сделала Joule доступным в Activate Roadmap Viewer в 2025 году и в SAP Cloud ALM, так что команда может запросить подсказки по задачам или черновик содержимого из дорожной карты. Это ускоряет первый черновик. Человека, который подписывает fit-gap, оно не заменяет.
3. Clean Core теперь стал правилом проектирования, и у него есть уровни. В августе 2025 года SAP заменила трёхуровневую модель расширяемости четырьмя уровнями Clean Core, от A до D. Уровень A использует только выпущенные API, либо на SAP BTP, либо внутри системы с ABAP Cloud. Уровень D совсем не чистый. В шаблоне fit-gap нужен столбец, в который попадёт каждый разрыв.
4. Public Edition сужает fit-gap. SAP теперь продаёт S/4HANA Cloud Public Edition как SAP Cloud ERP, а компаниям среднего размера под названием SAP GROW. Те же шесть фаз применяются с более лёгкими артефактами, а разрешены только расширения через выпущенные API, поэтому в столбце «Gap» меньше возможных ответов.

Проекты, которые пропускают эту основу, расплачиваются за это в Explore и Realize.

Шаблон определения объёма проекта

Определяет, что входит в проект, а что нет. Когда кто-то пытается добавить объём через три месяца (а так и будет), этот документ служит точкой отсчёта. Выше него стоит устав проекта SAP, в котором содержатся детали управления.

Раздел	Содержание
Название, спонсор, PM	Внедрение SAP S/4HANA Finance; CFO; назначенный старший PM
Предпосылки	Текущее состояние и причина перемен
Цели	Сократить цикл закрытия с 14 до 5 дней; исключить ручные сверки
В объёме	FI/CO, интеграция MM/SD, миграция данных, UAT, go-live
Вне объёма	Модули HR, миграция устаревших отчётов, интеграции со сторонними системами за пределами ERP
Допущения	Исполнительный спонсор доступен на ежемесячном SteerCo; тестовые данные согласованы к 6-й неделе
Ограничения	Фиксированная дата go-live; для настройки только внутренние ресурсы
Результаты	Настроенная система, планы тестирования, план cutover, учебные материалы
Сроки	Prepare: недели 1-4; Explore: недели 5-10; Realize: недели 11-26
Утверждение	Перед началом Explore требуется подпись спонсора проекта и PMO

Шаблон бизнес-кейса

Проводит через анализ затрат и выгод в формате, понятном финансовой команде. У меня бывало, что клиенты получали одобрение программы с первой подачи по этой структуре: цифры понятны, а допущения записаны.

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

Раздел	Содержание
Владелец и резюме	CFO или директор программы; почему сейчас, что меняется, что остаётся прежним
Описание проблемы	Конкретные операционные проблемы (длительность цикла закрытия, ручные обходные решения, возраст системы)
Предлагаемый подход	Greenfield / brownfield / selective, с кратким описанием объёма
Выгоды	В цифрах: дни, снятые с цикла закрытия, экономия FTE, снижение доли ошибок, снижение аудиторского риска
Затраты и финансирование	Внедрение, лицензия или подписка, время внутренних ресурсов, резерв; источник бюджета
Риски	Три главных, с вероятностью и влиянием
Рекомендация	Продолжать / продолжать с условиями / отложить, с обоснованием

Матрица заинтересованных сторон

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

Заинтересованная сторона	Роль	Интерес	Влияние	Вовлечение
Финансовый директор группы	Исполнительный спонсор	ROI программы, улучшение закрытия периода	Высокое	Ежемесячный SteerCo, еженедельный письменный отчёт
ИТ-директор	Технический владелец	Стабильность системы, интеграция, безопасность	Высокое	Еженедельный совет программы, ежедневно в Realize
Директор по финансам	Ключевой владелец процесса	Дизайн FI/CO, процесс закрытия	Высокое	Семинары в Explore, подпись UAT
Руководители заводов	Затронутые пользователи	Изменения процессов MM/PP	Среднее	Ежемесячные сообщения об изменениях, участие в UAT
Конечные пользователи (AP/AR)	Операторы	Изменения на уровне транзакций	Низкое	Обучение, поддержка в hypercare
Внутренний аудит	Управление	Прослеживаемость, контроли, соответствие требованиям	Среднее	Проверки артефактов на quality gate

Используйте ту же матрицу, чтобы спланировать семинары Prepare, на которых фиксируются требования верхнего уровня по подразделениям. Нумеруйте эти требования в формате, который вы будете использовать в Explore (REQ-001 и так далее), чтобы позже ничего не пришлось перенумеровывать, а связь с исходным запросом сохранилась.

Explore это фаза, где внедрение обретает форму. Эти шаблоны показывают разрыв между тем, что SAP делает из коробки, и тем, что нужно бизнесу.

Шаблон сопоставления требований и fit-gap

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

Затем fit-gap-анализ показывает, где стандартный SAP закрывает каждую потребность, а где нет. Для большинства моих клиентов это настоящее откровение. Мне нравится наблюдать момент, когда команда понимает, что может использовать стандартную функциональность вместо дорогого кастомного кода.

Я веду оба в одной таблице, с отдельным столбцом для пути решения. В S/4HANA каждый разрыв требует явного ответа: стандартная настройка, расширение ключевым пользователем, расширение разработчиком внутри системы или внешнее (side-by-side) расширение на SAP BTP. Классические модификации кода SAP это самый дорогой ответ, и для них должен быть назван утверждающий.

Req ID	Требование	Компонент SAP	Fit / Gap	Путь решения	Тест
REQ-001	Автоматические проводки закрытия месяца	FI-GL, закрытие периода	Fit	Настроить шаблоны повторяющихся документов	TC-001
REQ-002	Согласование заказа на закупку через Fiori	Закупки MM, приложение согласования Fiori	Gap (нет в ECC)	Стандартное приложение S/4HANA и настройка workflow	TC-003
REQ-003	Автоматизация внутригруппового выставления счетов	Счета SD, интеграция с FI	Gap	Настройка внутригруппового выставления счетов	TC-010
REQ-004	Мониторинг фоновых заданий	Приложение Application Jobs	Fit	Стандартное приложение	TC-015
REQ-005	Портал самообслуживания поставщиков	SAP Ariba или портал поставщиков	Gap	Интеграция с Ariba	TC-020
REQ-006	Архивирование данных в соответствии с GDPR	ILM, архивирование данных	Gap	Настройка политики ILM	TC-025
REQ-007	Отчётность по центрам затрат в реальном времени	CO, embedded analytics или SAC	Gap	Embedded analytics или живое подключение SAC	TC-030
REQ-008	Поддержка 500 одновременных пользователей	Сайзинг HANA	Gap (протестировано 300)	Пересмотр сайзинга и усиление инфраструктуры	TC-035

Это фаза разработки. Эти шаблоны служат аудиторским следом для каждого решения по настройке, каждой разработки и каждого результата тестирования.

Шаблон учёта конфигурации

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

1. ID конфигурации и модуль: [например, MM-CONF-001, MM]
2. Путь в IMG и объект конфигурации: [например, таблица T161, типы документов заказа на закупку]
3. Назначение и затронутый бизнес-процесс
4. Кто настроил и дата
5. Номер запроса на транспорт: [например, DEVK900123]
6. Ключевые значения: до и после
7. Связанные тестовые сценарии
8. Статус проверки и утверждения

Реестр кастомной разработки

Каждый кастомный объект получает строку, прежде чем кто-либо напишет код. Один мой клиент сократил кастомный код на 30%, потому что реестр показал, где стандартного SAP вполне достаточно.

Dev ID	Объект	Описание	Разработчик	Трудозатраты (ч)	Статус	Тип расширения
CD-001	Плитка Fiori: обзор центров затрат	Плитка отчётности CO в реальном времени для финансов	Разработчик Fiori	12	Завершено	Расширение разработчиком
CD-002	Отчёт по внутригрупповому выставлению счетов	Отчёт для сверки внутригрупповых операций	Разработчик ABAP	20	В работе	Расширение разработчиком
CD-004	Приложение статуса платежей поставщикам	Приложение Fiori для запросов по платежам AP	Разработчик BTP	10	Ожидает QA	Side-by-side на BTP
CD-005	Уведомление о поступлении товара	Отправка email при проводке поступления товара	Разработчик интеграций	24	Запланировано	На основе событий, на BTP

Шаблон стратегии тестирования

Собирает все планы тестирования в одном месте: кто что тестирует, когда, в какой среде и по какому стандарту.

Раздел	Содержание
Объём	Функциональное, интеграционное, регрессионное тестирование, тестирование производительности и UAT по модулям в объёме (тестирование на проникновение остаётся за InfoSec)
Среды	DEV, QA, UAT (предпродуктивная), staging для финальной проверки
Инструменты	Управление тестированием в SAP Cloud ALM или Jira/Xray; автоматизация с Tricentis Tosca или аналогом; производительность с JMeter или LoadRunner
Жизненный цикл дефекта	Новый, В работе, Решён, Проверен, Закрыт; серьёзность и приоритет задаются при триаже
Критерии выхода	Все критические дефекты закрыты; подпись UAT получена; доля пройденных регрессионных тестов не менее 95%; целевые показатели производительности достигнуты

Шаблон планирования миграции данных

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

Раздел	Содержание
Объём	Основные данные клиентов, основные данные поставщиков, открытые позиции, основные данные материалов, складские остатки, иерархии центров затрат
Системы-источники	ECC 6.0 EHP 7 (основная); устаревшая система HR (назначения сотрудников на центры затрат)
Целевая система	S/4HANA (текущий релиз)
Сопоставление и правила	Клиенты и поставщики в Business Partner; центры затрат в новую иерархию; удаление недействительных банковских реквизитов; слияние дубликатов
Инструменты миграции	SAP S/4HANA Migration Cockpit (основной); Migration Object Modeler для кастомных объектов; скрипты для предварительной обработки
Стратегия загрузки	Пробная загрузка в QA; дельта-миграция и сверка; продуктивный cutover
Подход к проверке	Количество записей в источнике и в целевой системе; выборочная проверка 10%; отчёты сверки остатков
План отката	Резервная копия перед cutover; устаревшая система в резерве 48 часов

Фаза Deploy это момент запуска. Эти шаблоны превращают хаотичные выходные в управляемое событие.

Шаблон планирования cutover

Раскладывает окно простоя по часам. Каждая задача, каждый владелец, каждое время начала. Ваша команда никогда не должна стоять в 2 часа ночи и гадать, что делать дальше.

Договоритесь о четырёх вещах, прежде чем писать список задач: окно (например, с пятницы 22:00 до субботы 06:00), триггер отката, как быстро можно снова включить устаревшую систему и дымовые тесты, которые подтверждают, что новая система работает. Затем последовательность задач:

Шаг	Описание	Владелец	Время начала	Статус
1	Заморозка системы ECC (без проводок)	Basis	22:00	Ожидает
2	Финальное извлечение данных и сверка	Руководитель миграции данных	22:30	Ожидает
3	Запуск продуктивной загрузки миграции	DBA	23:00	Ожидает
4	Импорт оставшихся транспортов в продуктив	Basis	00:30	Ожидает
5	Переключение DNS и балансировщика нагрузки на S/4HANA	Сеть	01:30	Ожидает
6	Дымовой тест: проводка FI, поступление товара, заказ на продажу	Руководитель QA	02:00	Ожидает
7	Подтверждение бизнеса и решение go/no-go	Директор программы	03:00	Ожидает
8	Открытие системы для бизнес-пользователей	Basis	06:00	Ожидает

Оценка готовности к go-live

Решает, действительно ли вы готовы переключаться. У меня бывало, что клиенты откладывали go-live по итогам этой оценки, и потом они меня благодарили.

Область	Проверки (на каждую ответ да или нет, с подтверждением)
Функциональная	Ключевые процессы протестированы; межмодульные сценарии завершены; открытые дефекты P1/P2 перечислены; ключевые пользователи подтверждают готовность
Данные	Загрузки основных данных завершены; данные транзакций проверены; отчёты сверки утверждены; заморозка устаревшей системы подтверждена
Техническая	План cutover утверждён; транспорты в продуктиве; фоновые задания запланированы; мониторинг настроен
Люди	Охват обучением в процентах; роли доступа проверены; команда hypercare укомплектована; план поддержки доведён до сведения
Решение	Критические риски и меры их снижения перечислены; Go / No-go / Условно; утверждено с указанием имени, роли и даты

После go-live работа меняет форму. Эти шаблоны ведут систему и команду через hypercare к устойчивому режиму.

Шаблон поддержки после внедрения

Организует работу с проблемами после запуска. Без него каждая проблема превращается в P1.

Раздел	Содержание
Окно hypercare	Недели 1-4 после go-live: круглосуточное покрытие (24/7)
Каналы поддержки	Очередь инцидентов ServiceNow (основная); отдельный чат; телефонный мост для проблем P1
Уровни поддержки	1: служба поддержки (пароли, навигация, известные проблемы); 2: функциональные консультанты (вопросы по процессам, небольшие настройки); 3: Basis и разработка (системные ошибки, производительность, интерфейсы)
SLA (реакция / решение)	Критический 15 мин / 2 ч; Высокий 30 мин / 4 ч; Средний 4 ч / 1 день; Низкий 1 день / 3 дня
Мониторинг	SAP Cloud ALM или Solution Manager; ежедневная проверка журнала ошибок
Критерии выхода	Нет открытых проблем P1/P2; все инциденты задокументированы; подписан финальный акт передачи

Шаблон мониторинга производительности

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

Метрика	Цель	Инструмент	Порог оповещения	Владелец
Время отклика диалога (95-й процентиль)	Менее 1 секунды	ST03 / SAP Cloud ALM	2 секунды	Команда Basis
Завершение фоновых заданий	100% по расписанию	SM37 / Application Jobs	Любое упавшее задание	Руководитель эксплуатации
Время запроса к базе данных	Менее 200 мс	SAP HANA cockpit	500 мс	DBA
Доступность системы	Более 99,5%	SAP Cloud ALM	Менее 99%	Инфраструктура
Доля ошибок интерфейсов	Менее 1%	Мониторинг SAP Integration Suite	2%	Руководитель middleware
Доля успешных входов	Более 98%	Журнал аудита безопасности	Менее 95%	Руководитель по безопасности
Время выполнения задания закрытия месяца	В пределах согласованного окна	Планировщик заданий	Более чем на 30% выше базового уровня	Финансовые операции

Quality gates не дают проблеме одной фазы превратиться в дорогую переделку в следующей. О том, как их настроить, рассказывает мой гайд по SAP quality gates. А здесь о том, почему они важны.

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

Задайте критерии «пройдено / не пройдено» для каждой контрольной точки. «95% регрессионных тестов должны пройти». «Все интеграционные сценарии FI зелёные». Такие критерии дают вам обоснованную позицию, чтобы держать линию, когда бизнес хочет запуститься в назначенную дату независимо от качества.

На одном из моих проектов quality gate остановил нас, когда прошли только 75% интеграционных тестов. Мы сначала исправили проблемы, а не стали спешить вперёд. Это сэкономило клиенту около €100 000 на аварийных исправлениях после запуска.

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

Что такое методология SAP Activate?

SAP Activate является методологией внедрения SAP для S/4HANA и других облачных продуктов. Она состоит из шести фаз (Discover, Prepare, Explore, Realize, Deploy, Run) и объединяет содержимое SAP Best Practices, управляемую настройку и гибкую поставку.

Списки задач и шаблоны результатов для каждого сценария развёртывания опубликованы в SAP Activate Roadmap Viewer.

В какой фазе SAP Activate самые важные шаблоны?

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

На втором месте Explore. Пробелы в документах fit-gap и сопоставления требований всплывают как дефекты UAT через месяцы, когда их исправление стоит намного дороже, чем стоило бы на 3-й неделе Explore.

Можно ли настраивать шаблоны SAP Activate под себя?

Да. Сохраняйте около 80% стандартной структуры и меняйте только то, что специфично для вашего контекста: фармацевтическая валидация, правила госзакупок, контроли SOX. Добавляйте это в начале Prepare, а не в Deploy.

Не изменяйте структуру quality gate, последовательность фаз и обязательные артефакты (документ определения объёма, бизнес-кейс, оценка готовности к go-live).

Подходят ли шаблоны SAP Activate и для greenfield, и для brownfield?

Да. Главное различие в Explore. Brownfield-конверсия переносит существующую конфигурацию, поэтому fit-gap сосредоточен на том, что нужно изменить, какой кастомный код стандартный S/4HANA теперь может заменить и какая очистка данных нужна до конверсии. Greenfield-программа начинает с SAP Best Practices и подтверждает, какие стандартные процессы подходят.

План cutover тоже отличается. Системная конверсия brownfield идёт в иной последовательности, чем go-live greenfield с полной миграцией данных.

Насколько подробным должен быть план cutover?

Минимум по часам, а для окна простоя ещё детальнее. У каждой задачи должны быть время начала, владелец и зависимость.

Договоритесь о критериях отката до начала cutover: какие условия запускают возврат к устаревшей системе, кто принимает это решение и к какому часу. Решения об откате в 4 часа ночи без заранее согласованных критериев это то, с чего начинаются катастрофы после go-live.