Контрольные точки качества SAP: как их настроить и где они дают сбой

Контрольная точка качества (quality gate) задаёт формальный рубеж между фазами проекта. Прежде чем двигаться дальше, команда должна показать, что согласованные критерии выполнены. Прошли: двигаетесь вперёд. Не прошли: сначала исправляете проблемы. В программе SAP контрольные точки стоят на переходах между фазами SAP Activate, и у каждой есть назначенный владелец с правом сказать «не готово».

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

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

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

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

В SAP Activate шесть фаз: Discover, Prepare, Explore, Realize, Deploy и Run. Каждый переход между ними естественным образом становится контрольной точкой. Вот что я жду от проверки на каждой из них.

Контрольная точка фазы	Предмет проверки	Какие доказательства нужны	Условие прохождения
Discover	Бизнес-кейс, согласованность позиций руководства	Бизнес-кейс, укрупнённая дорожная карта	Бизнес-кейс подписан, спонсор подтвердил участие
Prepare	Управление, команда, риски	Устав проекта, модель управления, реестр рисков	Устав утверждён, владельцы рисков назначены, команда подключена
Explore	Fit-to-Standard, проектирование, подход к интеграции	Решения по fit-gap, проекты процессов, архитектура интеграции	Владельцы процессов подписали; по каждому разрыву есть решение
Realize	Настройка, интеграционное тестирование	Отчёты о выполнении тестов, журнал дефектов	Пороги тестирования достигнуты, критические дефекты закрыты
Deploy	Данные, обучение, готовность к cutover	Сверка миграции, записи об обучении, план cutover	Генеральная репетиция проведена, план отката согласован
Run	Стабилизация и передача	Журнал инцидентов, отчёты о производительности	Инциденты в согласованных пределах, передача в поддержку подписана

На практике больше всего рисков несут Explore, Realize и Deploy. Проблема, проскочившая через любую из этих трёх точек, обходится дороже всего, когда обнаруживается после go-live.

1. 01DiscoverБизнес-кейс подписан, спонсор подтвердил участие
2. 02PrepareУстав утверждён, владельцы рисков назначены
3. 03ExploreПо каждому разрыву есть решение
4. 04RealizeПороги тестов достигнуты, критические дефекты закрыты
5. 05DeployГенеральная репетиция проведена, откат согласован
6. 06RunИнциденты в пределах нормы, передача подписана

Каждую контрольную точку подписывает один владелец с правом сказать «не готово»

Критерии входа и выхода для каждой контрольной точки нужно прописать в уставе проекта до начала настройки. Критерии, написанные под давлением сроков, описывают то, что команда может показать сейчас, а не то, что нужно проекту. Один клиент попытался объединить фазы, чтобы «сэкономить время». В итоге ему пришлось переделывать работу нескольких недель.

Критерии, дающие ответ «да» или «нет»

«Тестирование завершено» не критерий. Это начало споров. Я работал с ритейл-клиентом, у которого в контрольной точке было написано просто «UAT завершено». Половина команды читала это как «все тесты выполнены», другая половина как «все дефекты исправлены».

«Выполнено 95 % тест-кейсов, все дефекты приоритета 1 устранены, нет открытых дефектов приоритета 2 старше пяти дней»: вот это критерий. Он даёт ответ.

У одного производственного клиента контрольные точки не работали, потому что критерии были слишком расплывчатыми. Никто не знал, прошли ли они на самом деле. Когда критерии стали измеримыми порогами, споры при переходах между фазами прекратились.

Один владелец с правом отложить проект

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

Обратный подход работает. Один ритейл-клиент назначил владельцем контрольной точки старшего директора. Когда он говорил «не готово», слушали все. Закрепите эти полномочия в уставе.

Поддержка руководства до того, как начнётся давление

Руководители любят контрольные точки до тех пор, пока одна из них не ставит под угрозу срок. Один CIO отменил решение непройденной контрольной точки ради квартального показателя. Возникшие проблемы обошлись вдвое дороже, чем стоила бы задержка. Я много раз видел, как это повторяется, поэтому теперь прошу руководство утвердить рамки контрольных точек до старта проекта.

Доказательства из первичной системы учёта

Для решения по контрольной точке нужны доказательства: отчёты о выполнении тестов, журналы дефектов, подписи владельцев процессов, сверки миграции. Берите их из инструмента, а не из слов о том, что всё сделано. Один из моих клиентов обнаружил по отчётам Solution Manager, что 40 % «завершённых» тест-кейсов ни разу не выполнялись. Он поймал это до контрольной точки, а не после.

1. Привяжите контрольные точки к переходам между фазами. В SAP Activate как минимум после Prepare, Explore, Realize и Deploy. Один энергетический клиент создал между ними случайные проверки и получил неразбериху.
2. Определите критерии входа и выхода до начала настройки. Согласуйте покрытие тестами, пороги по дефектам и владельцев процессов, которые должны подписать. Внесите их в устав и получите подпись спонсора.
3. Планируйте контрольные точки с запасом. Поставьте каждую в календарь как работу, а не просто как веху. Один мой ритейл-клиент резервировал полную неделю перед каждой контрольной точкой только под наведение порядка.
4. Выбирайте проверяющих, которые могут принять решение. Руководители бизнеса подписывают процессы. Технические руководители подписывают настройку и интеграцию. Консультанты никогда не подписывают за бизнес.
5. Храните доказательства в одном месте. Через полгода аудитор спросит, кто подписал миграцию данных. Ответ должен находиться за минуты.
6. Сделайте результаты видимыми. Один клиент повесил дашборд контрольных точек на стену проектной комнаты. Его невозможно было не замечать.

Примеры критериев выхода для двух самых важных контрольных точек

Контрольная точка Realize:

1. Выполнение тестов на уровне согласованного порога или выше, результаты хранятся в инструменте тестирования.
2. Нет открытых дефектов приоритета 1; дефекты приоритета 2 не старше согласованного срока.
3. Каждый критический процесс подписан назначенным владельцем процесса.
4. Интеграционные тесты прогнаны по полным цепочкам процессов, результаты задокументированы.
5. Каждая индивидуальная разработка согласована на соответствие правилам Clean Core для программы.

Контрольная точка Deploy:

1. Генеральная репетиция миграции данных проведена, сверка подписана руководителем по данным.
2. Прохождение обучения по ролям на уровне согласованного порога или выше.
3. План cutover отрепетирован, с таймингами и точками принятия решения go/no-go.
4. План отката задокументирован и проверен.
5. Команда hypercare назначена, пути эскалации и определения уровней критичности согласованы.

Если на контрольной точке Deploy остаются неустранённые расхождения при сверке или необученные пользователи, а бизнес всё равно хочет двигаться дальше, оформите это как документированное решение с именем подписавшего. А не как решение по умолчанию, потому что никто не захотел сказать «нет».

Две вещи изменили то, как я проектирую контрольные точки в текущих программах.

Clean Core теперь критерий контрольной точки. SAP классифицирует расширения от уровня A (только выпущенные интерфейсы) до уровня D (модификации и прямая запись в таблицы). На контрольной точке Explore по каждому разрыву должно быть решение: настроить, построить как расширение на выпущенном API или отклонить. На контрольной точке Realize проверьте, что не просочились новые объекты уровня D. Public Edition обеспечивает это технически. Private Edition и on-premise нет, поэтому соблюдение обеспечивает сама контрольная точка.

SAP Cloud ALM: инструмент по умолчанию. Он входит в облачные подписки SAP с Enterprise Support, cloud edition, и в SAP Enterprise Support для клиентов on-premise (SAP Support). Он охватывает Fit-to-Standard, назначение задач, оркестрацию тестов и сквозную прослеживаемость. Основная поддержка SAP Solution Manager 7.2 заканчивается в конце 2027 года, и SAP рекомендует перейти на Cloud ALM до этого срока (SAP Support). Если вы в середине программы на Solution Manager, завершайте её там. Новые программы стройте вокруг Cloud ALM.

Инструменты для управления контрольными точками

Инструмент важен меньше, чем дисциплина. Один ритейл-клиент построил аккуратный процесс контрольных точек на SharePoint, и он отлично работал на внедрении среднего масштаба. Я видел и обратное: контрольные точки не работали при полной настройке Solution Manager, потому что команда вела параллельные таблицы.

Инструмент	Роль в управлении контрольными точками	Лучше всего подходит
SAP Cloud ALM	Fit-to-Standard, задачи, тесты, прослеживаемость	Новые программы S/4HANA, облачные и on-premise
SAP Solution Manager 7.2	Отслеживание проекта, управление тестами и дефектами	Программы, которые уже работают на нём
Jira и Confluence	Задачи, дефекты, критерии контрольных точек и доказательства	Команды, которые уже используют инструменты Atlassian
Tricentis Tosca	Автоматизация тестирования и отчёты о покрытии	Программы с интенсивной автоматизацией тестирования
ServiceNow	Процессы согласования и журнал аудита	Компании, которые уже работают на ServiceNow

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

Пропуск под давлением графика. Когда проект срывает сроки, контрольные точки режут первыми. На одном проекте проверки превратились в формальность, и go-live стал кошмаром: системы падали, заказы застревали, и пришлось полностью откатываться. Три недели, которые они «сэкономили», обошлись в три месяца восстановления.

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

У проверяющих нет времени. Когда ключевые проверяющие разрываются между несколькими проектами, проверка превращается в расстановку галочек. Проверка контрольной точки Realize на программе среднего размера должна занимать не меньше полдня, причём доказательства нужно прочитать заранее.

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

Три показателя, которые показывают, работают ли контрольные точки

Отслеживайте их, чтобы понять, защищают ли контрольные точки проект или только делают вид.

1. Утечка дефектов: доля дефектов, найденных после контрольной точки, которые она должна была выявить.
2. Доля прохождения с первой попытки: если каждая контрольная точка проходит с первого раза, у критериев, скорее всего, нет зубов.
3. Инциденты после go-live: инциденты высокого приоритета в первые 30 дней прямо оценивают контрольную точку Deploy.

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

Что такое контрольная точка качества в проектах SAP?

Формальный рубеж между фазами проекта. Прежде чем идти дальше, команда должна показать, что конкретные измеримые критерии выполнены. У каждой контрольной точки есть назначенный владелец с правом отложить проект. В SAP Activate контрольные точки стоят на переходах между фазами, особенно после Explore, Realize и Deploy.

Какие контрольные точки качества есть в SAP Activate?

В SAP Activate шесть фаз (Discover, Prepare, Explore, Realize, Deploy и Run), и каждый переход между ними служит контрольной точкой. Discover проверяет бизнес-кейс. Prepare проверяет управление и устав. Explore проверяет утверждение проектных решений и решения по разрывам. Realize проверяет результаты тестов и дефекты. Deploy проверяет данные, обучение и готовность к cutover. Run проверяет стабилизацию и передачу.

Что должны включать критерии контрольных точек качества SAP?

Критерии, которые дают ответ «да» или «нет». Для Realize: пороги выполнения тестов, открытые дефекты по приоритетам, подписи владельцев процессов и результаты интеграционных тестов. Для Deploy: сверка миграции, прохождение обучения по ролям, отрепетированный план cutover, проверенный план отката и укомплектованная команда hypercare. У каждого критерия должен быть владелец, который предоставляет доказательства.

Почему контрольные точки качества не работают при внедрении SAP?

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

Какой инструмент использовать для управления контрольными точками качества SAP?

Для новых программ SAP Cloud ALM. Он входит в облачные подписки SAP и Enterprise Support и поддерживает Fit-to-Standard, тестирование и прослеживаемость. Основная поддержка SAP Solution Manager 7.2 заканчивается в конце 2027 года. Jira, Tricentis Tosca и ServiceNow хорошо работают там, где компания уже ими пользуется. Правило одно: единый источник достоверной информации.

Как оценить готовность к go-live на последней контрольной точке качества?

Проверьте пять вещей по доказательствам: миграция данных отрепетирована и сверена, обучение завершено для каждой роли, план cutover отрепетирован с точками go/no-go, план отката проверен, а hypercare укомплектован и имеет пути эскалации. Если хотя бы один пункт не выполнен, а бизнес всё равно хочет продолжать, зафиксируйте это как подписанное бизнес-решение.