Как правильно начать проект внедрения SAP

Чтобы правильно начать внедрение SAP, решите пять вопросов до того, как кто-либо настроит хотя бы одну транзакцию. Выберите модель развёртывания. Подпишите устав с объёмом работ и правами принятия решений. Назначьте бизнес-владельцев, которые будут ходить на воркшопы по проектированию. Рано начните работу с данными и cutover. Составьте график с реальным запасом. Если сделать это в первый месяц, большинства дорогостоящих сбоев не случится.

Я всегда думал, что если систему настроить правильно, внедрение SAP пройдёт нормально. Проектирование, настройка, тестирование, go-live. Такой была моя модель на протяжении многих лет.

Я внедряю ERP, в том числе SAP, уже 25 лет на Ближнем Востоке, в Юго-Восточной Азии и Европе. Даже когда команды шаг за шагом следовали SAP Activate, проекты всё равно попадали в беду. Причины почти никогда не были техническими. Размытая ответственность. Допущения, которые никто не проверил. Планирование cutover, начатое слишком поздно. Вначале эти трещины выглядят безобидно. Когда они расходятся, поздние усилия не исправят то, что предотвратила бы ранняя прозрачность.

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

Команды, которые считают внедрение упражнением по настройке, недофинансируют всё, что настройкой не является. Это самая устойчивая причина сложных go-live из тех, что я вижу.

Для программы, которая стартует сейчас, сначала нужно определиться ещё с одним потоком: моделью развёртывания. S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) или on-premise. От этого выбора зависит, как работает каждый другой поток.

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

Фаза	Что происходит	Что я проверяю
Discover	Бизнес-обоснование, укрупнённый объём работ, модель развёртывания	Реалистичные стоимость и сроки, а не оптимистичные
Prepare	Управление, устав, команда, реестр рисков, среды	Назначенные лица, принимающие решения, с реальными полномочиями
Explore	Воркшопы fit-to-standard, решения по разрывам (gap), утверждение дизайна	Бизнес-владельцы в комнате, а не только ИТ
Realize	Настройка, разработка, интеграция, системное тестирование	Планирование cutover уже идёт
Deploy	Приёмочное тестирование пользователей, загрузка данных, обучение, cutover	Хотя бы одна полная генеральная репетиция
Run	Go-live, hypercare, передача в поддержку	Hypercare с полным составом команды до первого закрытия месяца включительно

Самый частый сбой графика: медленная фаза Explore. Она сжимает Realize, а та сжимает Deploy. Приёмочное тестирование пользователей (UAT) сокращают, репетицию данных пропускают, а go-live всё равно происходит, потому что дата уже объявлена. Расплачиваются за это первые 90 дней после go-live.

1. 01Explore затягиваетсяFit-to-standard и утверждение дизайна сдвигаются
2. 02Realize сжимаетсяМеньше времени на сборку и тесты
3. 03Deploy сжимаетсяМеньше времени на UAT, загрузку данных и обучение
4. 04Тестирование сокращаетсяUAT сокращают, репетицию данных пропускают
5. 05Go-live в объявленную датуПотому что дату уже объявили

Цена проявляется в hypercare, в первые 90 дней

1. Утверждение дизайна без бизнеса

Explore даёт дизайн. Его качество зависит от того, понимали ли владельцы процессов, подписавшие его, что именно они подписывают. Когда на воркшопах присутствуют только ИТ и консультанты, дизайн может быть технически верным и всё равно неузнаваемым для тех, кто будет им пользоваться. Тогда UAT превращается в открытие, а не в проверку.

Простой тест: через три месяца после утверждения попросите владельца процесса рассказать, как будет работать заказ на закупку после go-live. Если он не может, утверждение было ненастоящим.

2. Управление, которое существует только на бумаге

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

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

3. Позднее планирование cutover

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

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

4. Интеграционное тестирование, которое выдавливают

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

Модульные тесты доказывают, что транзакция работает сама по себе. Сбои, которые бьют после go-live, проявляются, когда полный процесс идёт через несколько модулей. Поступление товара, заблокированное статусом заказа на закупку. Запуск выставления счетов, остановленный из-за отсутствующего определения счетов. Тестируйте полные цепочки, от заказа до оплаты и от закупки до оплаты, и не позволяйте им сползти на последние недели перед UAT.

5. Недооценённая миграция данных

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

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

6. Управление изменениями как опция

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

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

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

Сначала модель развёртывания. Public Edition даёт самые узкие возможности доработки, а систему эксплуатирует SAP. Private Edition в рамках RISE даёт больше свободы, а инфраструктуру эксплуатирует SAP. On-premise даёт больше всего контроля и больше всего ответственности. Решайте на фазе Discover. Программы, которые откладывают выбор, тратят Explore на споры о нём.

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

Инструменты ИИ должны быть в методологии с первого дня. Joule доступен в SAP Activate Roadmap Viewer. Joule для консультантов отвечает на вопросы по настройке, а Joule для разработчиков генерирует код ABAP Cloud. Это может ускорить подготовку черновиков и задачи сборки. Бизнес-решения, работу с данными и усилия по управлению изменениями они не отменяют. Спросите у своего партнёра, где он их использует и как это отражается в плане.

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

Подход	Что он означает	Для кого подходит
Big bang	Все модули и юридические лица запускаются одновременно	Небольшие организации со стандартным объёмом, готовые принять повышенный риск go-live
Поэтапно по модулям	Сначала финансы, затем цепочка поставок, затем HR	Модули с малым числом перекрёстных зависимостей; позволяет команде учиться между этапами
Поэтапно по странам или юридическим лицам	Шаблон запускается в одном юридическом лице, затем тиражируется	Группы с глобальным шаблоном
Brownfield-конверсия	Существующая система ECC конвертируется в S/4HANA	Зрелая ECC со стабильными процессами
Greenfield	Новое внедрение S/4HANA	Устаревшая система не от SAP или ECC с большим техническим долгом
Выборочный перенос данных	Выбранные юридические лица или данные переносятся в переработанную систему	Слияния, выделение бизнеса, частичное повторное использование

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

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

1. Исполнительный спонсор: модель развёртывания выбрана и зафиксирована вместе с причинами.
2. Директор программы: устав подписан и охватывает объём работ, явные исключения, критерии успеха, права принятия решений и управление изменениями. Устные договорённости об объёме испаряются. В моём руководстве по уставу проекта есть шаблон.
3. Бизнес-лидеры: назначен владелец процесса по каждой области, у которого реально освобождено время на воркшопы.
4. Архитектор решения: согласованы целевой уровень Clean Core и форум утверждения расширений.
5. Руководитель по данным: профилирование данных начато в Prepare, а не после утверждения дизайна.
6. Руководитель cutover: назначен в Realize, дата репетиции уже есть в плане.
7. Руководитель тестирования: перечислены сценарии тестирования полных цепочек процессов, включая согласования вплоть до проводок в финансах.
8. Финансовый директор: график сверен с сопоставимыми программами, с запасом на медленный Explore и дополнительные циклы работы с данными. План, который исходит из того, что всё пойдёт как надо, планом не является.

Что такое проект внедрения SAP?

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

Из каких фаз состоит внедрение SAP?

В SAP Activate шесть фаз: Discover, Prepare, Explore, Realize, Deploy и Run. Discover задаёт бизнес-обоснование и объём работ. Prepare организует управление и команду. Explore проводит воркшопы fit-to-standard и подтверждает дизайн. Realize строит и тестирует. Deploy охватывает UAT, загрузку данных, обучение и cutover. Run означает go-live и hypercare. Каждая фаза заканчивается контрольной точкой качества.

Сколько длится внедрение SAP?

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

Почему внедрения SAP чаще всего проваливаются?

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

Что должно быть в уставе проекта SAP?

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

Что такое hypercare после go-live SAP?

Hypercare означает период усиленной поддержки после go-live, обычно от 30 до 90 дней. Команда проекта и бизнес работают бок о бок, исправляя проблемы и стабилизируя операции. Держите его укомплектованным как минимум на один полный бизнес-цикл, включая первое закрытие месяца, потому что именно тогда многие проблемы проявляются впервые.