Шаблон объёма проекта SAP: что определить и что исключить

Шаблон объёма проекта SAP определяет, что программа поставит, что она намеренно не поставит, кто отвечает за каждую часть и как объём может меняться. Девять разделов ниже охватывают всё это. Два самых важных раздела как раз те, которые команды пропускают: явные исключения и объём миграции данных. Заполните шаблон до начала конфигурации и подпишите его у спонсора и владельцев процессов.

Бывает, что команды заполняют шаблон объёма и идут дальше. Эта часть кажется лёгкой. Через несколько недель, на этапе проектирования или сборки, кто-то замечает процесс, который «подразумевался в объёме». Разговор становится неприятным. Никто этого не записал. Никто не собирался это опускать. Я видел такое слишком часто. Несколько непроверенных допущений в начале незаметно сдвигают проект на недели.

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

Вот девять разделов и то, на что должен отвечать каждый из них.

1. Цели

Зачем делается эта работа и что увидит бизнес, когда она закончится? Привяжите каждую цель к измеримому результату: сократить закрытие месяца на три дня, убрать ручные сверки по трём юридическим лицам, получить единую картину запасов по всем заводам. Расплывчатые цели дают расплывчатые критерии успеха, а разногласия всплывают на приёмочном тестировании (UAT).

2. Определение объёма

Модули, юридические лица, заводы, страны, языки, интеграции и модель развёртывания. Будьте конкретны. «Финансы» ещё не объём. А вот это объём: «Финансовый учёт и контроллинг (FI/CO): кредиторская и дебиторская задолженность, главная книга и учёт по центрам затрат для юридического лица в ОАЭ на S/4HANA Cloud Private Edition».

3. Исключения

Здесь не справляется большинство шаблонов объёма. Если что-то не записано как исключённое, кто-нибудь решит, что оно включено. Исключения, которые нужно записать поимённо:

1. Страны или юридические лица, перенесённые на более позднюю фазу.
2. Устаревшие интеграции, которые пока остаются как есть.
3. Исторические данные до определённой даты отсечки.
4. Отчёты, перенесённые в список доработок после go-live.
5. Регуляторные требования, отложенные до юридического подтверждения.

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

4. Объём миграции данных

Постоянное слепое пятно. Ответьте письменно на три вопроса:

1. Что переносится? Только открытые позиции или и история тоже? Все клиенты и поставщики или только активные? Материалы по каждому заводу или только по заводам, которые запускаются в go-live?
2. Каковы правила отсечки? Дата, на которую фиксируются открытые заказы на закупку, продажу и производственные заказы, и что происходит с позициями в работе в момент cutover.
3. Что вместо этого архивируется? Правовые требования к хранению истории и срок, в течение которого прежняя система остаётся доступной для чтения.

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

5. Нефункциональный объём

Эти требования выпадают при планировании и всплывают как блокеры в конце тестирования. Включите их в объём:

1. Доступность и окно обслуживания. В RISE сверяйтесь с условиями доступности в вашем контракте.
2. Производительность при пиковой нагрузке, например при закрытии месяца.
3. Журналирование для аудита: какие транзакции и как долго хранятся журналы.
4. Безопасность и контроль доступа по ролям.
5. Задержка отчётности: в реальном времени, почти в реальном времени или раз в сутки.

Это не функции. Это ограничения, которым система обязана соответствовать. Если их нет в объёме, никто не станет под них проектировать.

6. Роли и ответственность

У каждого направления работ должен быть руководитель со стороны консультантов и бизнес-партнёр с полномочиями принимать решения, оба названы поимённо. Чаще всего я вижу пробел в ответственности за UAT: кто вправе подтвердить, что процесс протестирован и принят? Решите это до начала сборки, а не за две недели до go-live.

7. Управление изменениями

Не «изменения требуют формального согласования», а конкретный процесс: что запускает запрос на изменение, кто оценивает влияние на сроки и бюджет, кто утверждает и что фиксируется. Без него вопрос «а можем мы добавить вот это?» превращается в «мы думали, это уже включено», а затем в трёхнедельное продление, которое никто не планировал.

8. Правила расширений

Как будет утверждаться кастомная разработка. SAP теперь классифицирует расширения от уровня A, только выпущенные API, до уровня D, модификации ядра (SAP News, август 2025). В Public Edition в рамках GROW система допускает только выпущенные интерфейсы. В Private Edition в рамках RISE и в on-premise ядро по-прежнему можно модифицировать, поэтому в объёме нужно указать целевой уровень и того, кто утверждает исключения. Уровни я объясняю в руководстве по Clean Core.

9. Допущения и ограничения

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

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

Классифицируйте каждый запрос, прежде чем что-либо утверждать:

Категория	Проверка	Что делать
Необходимая	Процесс не может работать юридически или операционно без неё	Утвердить, выбрав самое дешёвое расширение, безопасное при обновлении
Важная, но не критичная	Повышает эффективность, но не блокирует запуск	Утверждать только при чётком обосновании выгод и затрат
Лишняя	Предпочтение или копия того, как работала старая система	Оспорить, затем отклонить или отложить

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

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

1. 01Запрос поданЧто считается изменением, определяется заранее
2. 02КлассификацияНеобходимое, важное или лишнее
3. 03Оценка влиянияСроки и бюджет, оценивает назначенный специалист
4. 04РешениеНазначенный утверждающий одобряет, отклоняет или откладывает
5. 05Новая версия объёмаНовый номер версии и список изменений

После заморозки изменений новые запросы попадают в бэклог после go-live

Именно вокруг аналитики разговоры об объёме становятся жаркими. Все хотят отчёты, и никто не говорит, сколько их.

Согласуйте фиксированный список отчётов на этапе проектирования. Спрашивайте, что людям нужно, а не что им могло бы понадобиться. Отметьте каждый отчёт как стандартный вывод SAP или кастомную разработку и подпишите список вместе с остальным объёмом. Стандартные отчёты стоят долю от стоимости кастомных. Тогда же определите источники данных для каждого отчёта: отчёт, который берёт данные из трёх систем, это требование к интеграции. Если в объём входят дашборды и планирование, в моём руководстве по SAP Analytics Cloud описано, что нужно решить в первую очередь.

Ошибка	К чему приводит	Как избежать
Цели не измеримы	Споры на UAT о том, что значит «работает»	Задайте измеримые результаты в самом начале
Исключения не записаны	Работа принимается без согласования	Перечислите поимённо, что выходит за рамки
Объём миграции данных расплывчат	Неверные объёмы, сорванный cutover, переделки	Определите, что переносится, правила отсечки и архивирование
Нет нефункциональных требований	Проблемы с аудитом и производительностью при go-live	Включите в объём доступность, производительность, журналирование и безопасность
Не названы владельцы UAT	Тестирование затягивается, подписать некому	Назовите конкретных людей с полномочиями
Нет управления изменениями	Неформальные добавления, сжатое тестирование	Впишите процесс изменений в объём
Нет подписи	Объём оспаривают позже без ответственности	Подписывают спонсор и владельцы процессов
Аналитика оставлена на потом	Запросы на отчёты за две недели до go-live	Согласуйте список отчётов на этапе проектирования
Не решены модель развёртывания и правила расширений	Спор тянется в фазу сборки	Решите и то и другое до подписания объёма

Пересматривайте объём на каждом пороге фаз SAP Activate и после каждого утверждённого изменения, указывая номер версии и список изменений. Объём должен входить в устав проекта по ссылке, чтобы оба документа рассказывали одну и ту же историю.

Что должен включать шаблон объёма проекта SAP?

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

Как предотвратить расползание объёма в проектах SAP?

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

Что такое объём миграции данных в проекте SAP?

Это определение того, какие данные переносятся в SAP и по каким правилам: какие объекты (клиенты, поставщики, материалы, открытые заказы, история), даты отсечки и что архивируется вместо миграции. От него зависят трудозатраты и сроки, и он определяет, как долго прежние системы должны оставаться доступными.

Что такое нефункциональный объём в проектах SAP?

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

Как учитывать кастомизации в объёме?

Классифицируйте каждый запрос как необходимый, важный или лишний. Для каждого утверждённого запроса зафиксируйте требование, почему стандартный SAP его не закрывает, трудозатраты, влияние на тестирование, стоимость сопровождения и подход к расширению. В Private Edition и on-premise укажите целевой уровень Clean Core и того, кто утверждает исключения.

Когда нужно пересматривать объём проекта SAP?

На каждом пороге фаз SAP Activate, после каждого утверждённого запроса на изменение и всякий раз, когда меняются бюджет, ресурсы или сроки. Храните каждую версию с датой, номером версии и кратким описанием изменений. Эта история защищает команду, когда объём оспаривают позже.