Восстановление проекта SAP: как спасти программу, сбившуюся с курса

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

Коротко: если эти три проверки согласуются друг с другом и с планом, программе нужен рывок, а не спасение. Если не согласуются, никакие дополнительные усилия по текущему плану её не исправят, и вам нужно формальное восстановление с новым базовым планом.

Эта статья об этой диагностике и о том, что следует за ней. Она одна из частей моего руководства по миграции с ECC на S/4HANA, где разобраны пути, сроки и дедлайны. Здесь вопрос уже: ваша программа в беде, что теперь?

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

Спасение это другое. Признаки дают те же три проверки, которые я провожу в первую неделю, и сигнал простой: статус, дизайн и развёрнутое не согласуются друг с другом или с планом.

Некоторые закономерности я бы считал сигналами к спасению:

1. Статус зелёный, система нет. Отчёты говорят, что большая часть разработки готова, но тестовая система не может выполнить базовый order to cash.
2. Дизайн подписан, разработка его игнорирует. Настройку делали по заметкам с воркшопов, а не по утверждённому дизайну.
3. В плане есть дата go-live, но никто не может объяснить путь к ней. Для тестирования, загрузки данных и репетиций cutover нет реалистичного места.
4. Объём только растёт. Список WRICEF (отчёты, интерфейсы, конвертации, расширения, формы и workflows) продолжает расти спустя долгое время после фазы Explore.

Любой из этих признаков по отдельности можно исправить рывком. Два и больше одновременно обычно нельзя.

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

Вот что покрывает каждая проверка и о чём говорит расхождение:

Проверка	На что я смотрю	На какой вопрос она отвечает	Если она расходится с остальными
Статус программы	План, отчёты о статусе, журнал RAID, открытые запросы на изменения, расходы относительно бюджета	Что программа думает о себе?	Отчётность излишне оптимистична или оторвана от выполнения работ
Дизайн	Дизайн бизнес-процессов, результаты Fit-to-Standard, список WRICEF, открытые проектные решения	Что пообещали бизнесу?	Разработка отошла от согласованного, или дизайн так и не был завершён
Что развёрнуто	Системы разработки и тестирования, настройка, транспорты, собственный код, проведённые загрузки данных	Что реально существует сегодня?	Прогресс отражён в отчётах по работе, которой нет в системе

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

Отчёты о статусе и проектные документы это утверждения. Система это доказательство.

Кто должен проводить проверки

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

Я бы поручил первую неделю человеку, независимому от партнёра по внедрению, с полным доступом к системам и правом говорить с любым участником программы. Если это невозможно, как минимум заставьте партнёра показать вам развёрнутую систему вживую, а не на слайдах.

В 2018 году я работал над восстановлением программы в авиации. Модули были развёрнуты, но ничего не было настроено на основе бизнес-требований.

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

Авиакомпании тесно связывают техническое обслуживание, закупки и финансы, поэтому пробел в одной области распространяется дальше. О том, как SAP вписывается в эту отрасль, я пишу на странице о SAP для авиации.

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

Две другие причины повторяются снова и снова:

1. Объём контролирует поставщик. Когда системный интегратор пишет объём работ, он описывает то, что интегратор планирует поставить. Пробелы появляются позже как запросы на изменения, оценённые тем же поставщиком.
2. Собственный код выходит за рамки. По моему опыту, собственный код это фаза миграции, которая чаще всего выходит за сроки, и это же скрытая статья затрат, о которой забывают чаще всего.

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

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

Когда вы знаете правду, у восстановления появляется понятная последовательность. Пропуск шага обычно означает, что спасать придётся дважды.

Последовательность восстановления программы SAP

1. 01

   Диагностика

   Статус, дизайн и развёрнутое, сверенные друг с другом.

2. 02

   Возврат объёма

   Объём во владении клиента, замороженный, с оценкой каждого изменения.

3. 03

   Новый базовый план

   Один новый план, построенный на фактах, с резервом на вашей стороне.

4. 04

   Контроль фаз

   Контрольная точка качества в конце каждой оставшейся фазы.

5. 05

   Репетиция и cutover

   Полные репетиции до подтверждения даты go-live.

1. Верните себе владение объёмом

Прежде чем кто-либо начнёт перепланировать, решите, кто владеет объёмом работ. Если ответ по-прежнему поставщик, новый план провалится так же, как старый.

Опишите объём на стороне клиента, сравните его с тем, что развёрнуто, и заморозьте. С этого момента каждое изменение это оценённое решение с ответственным.

2. Пересмотрите базовый план один раз, на основе фактов

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

Сначала переоцените собственный код, потому что перерасход чаще всего возникает именно там. Затем данные, поскольку миграция данных составляет 30–40% трудозатрат и в проблемной программе обычно отстаёт.

Держите резерв 10–20% на своей стороне и расходуйте его только на названные риски. Моя статья о стоимости миграции на S/4HANA объясняет, что определяет эти цифры.

3. Поставьте контрольную точку качества в конце каждой фазы

Проблемные программы обычно переходили от фазы к фазе по датам, а не по фактам. Исправьте это.

В SAP Activate фаза Explore проводит воркшопы Fit-to-Standard, а утверждённые дельта-требования попадают в бэклог продукта для Realize. Если программа вышла из Explore без завершённого дизайна, вернитесь и завершите его. SAP Cloud ALM поддерживает контрольные точки качества с чек-листами, которые отображаются в обзоре проекта, поэтому контрольная точка не обязана жить в электронной таблице.

4. Репетируйте, прежде чем брать обязательство по дате

При конвертации brownfield я планирую три пробные конвертации до cutover. Проблемные программы часто сокращают репетиции ради экономии времени, а это переносит риск на выходные go-live.

Простой при cutover, который я видел, длился от одних выходных до недели. Спасённая программа должна знать свою цифру по репетиции, а не по оценке.

5. Проверьте, к какому сроку вы на самом деле работаете

Для SAP ERP 6.0 на enhancement packages 6–8 основная поддержка заканчивается 31 декабря 2027 года, а дополнительная расширенная поддержка до конца 2030 года стоит надбавку в два процентных пункта (SAP News). Восстановление, которое сдвигает миграцию ECC за 2027 год, должно открыто заложить в бюджет расширенную поддержку.

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

Спасение часто поднимает вопрос, оставлять ли текущего системного интегратора. Иногда сменить партнёра правильно. Часто более серьёзная проблема в том, как была выстроена программа, и новый партнёр её унаследует.

Вот вопросы, которые я бы задал до принятия решения:

1. Можете ли вы показать нам развёрнутую систему вживую в сравнении с подписанным дизайном? Не демо-среду и не слайды.
2. Какие объекты WRICEF разработаны, протестированы и перенесены транспортом, а какие только отмечены в отчётах как готовые?
3. Каков ваш high-level design для завершения и по каким рекомендациям мы можем позвонить там, где вы восстанавливали программу, похожую на нашу? Рекомендации и high-level design это две вещи, которые я прошу у любого партнёра до подписания.
4. Что вам нужно от нас, чего вы не получаете? Недостающие решения и ключевые пользователи с частичной занятостью часто составляют половину истории.
5. Для клиентов RISE with SAP: какие проблемы относятся к SAP, а не к партнёру, и кто их эскалирует?

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

Если в программе никогда не было нормальной оценки исходной системы, проведите её сейчас. SAP Readiness Check анализирует вашу существующую систему, и SAP рекомендует запускать его в продуктивной системе, чтобы получить точную картину реального использования. Моя статья о SAP Readiness Check и оценке миграции объясняет, что он упускает, начиная с собственных объектов.

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

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

Что такое восстановление проекта SAP?

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

Как понять, что моему проекту SAP нужно спасение?

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

Что должно происходить в первую неделю восстановления внедрения SAP?

Только диагностика. Оцените статус программы, проверьте дизайн и оцените то, что реально развёрнуто, в идеале под руководством человека, независимого от партнёра по внедрению. Не пишите новый план, пока эти три проверки не завершены.

Нужно ли менять партнёра по внедрению SAP во время восстановления?

Не автоматически. Попросите партнёра показать развёрнутую систему в сравнении с подписанным дизайном и дать вам high-level design для завершения с рекомендациями по похожим восстановлениям.

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

Почему миграции на SAP S/4HANA сбиваются с курса?

Самая частая коренная причина, которую я вижу, это отсутствие нормального планирования в начале внедрения. Другая причина в контроле поставщика над объёмом работ, а собственный код это фаза, которая чаще всего выходит за сроки. Миграция данных, на которую приходится 30–40% трудозатрат, обычно тоже отстаёт.

Сдвинет ли восстановление нашу миграцию ECC за срок 2027 года?

Может сдвинуть. Основная поддержка SAP ERP 6.0 на enhancement packages 6–8 заканчивается 31 декабря 2027 года, а дополнительная расширенная поддержка действует до конца 2030 года с надбавкой в два пункта. Заложите в бюджет расширенную поддержку, а не форсируйте go-live, который не подтверждают ваши репетиции.