Сроки внедрения SAP: длительность фаз и 5 ошибок

По моему опыту, внедрение SAP занимает от 6 до 9 месяцев на GROW with SAP и от 9 до 18 месяцев на RISE with SAP. Переход с SAP ECC занимает от 12 до 18 месяцев при конвертации brownfield или выборочном переносе данных и от 18 до 24 месяцев при внедрении greenfield.

Короткий ответ: фиксируйте дату в конце фазы Explore, а не на старте, и закладывайте запас от 15 до 20 процентов сверх оценки поставщика. Начинайте работу с данными на фазе Discover, потому что миграция данных занимает от 30 до 40 процентов трудозатрат на внедрение. Каждый лишний месяц задержки обходится как минимум в шестизначную сумму только на гонорарах консультантов.

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

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

Его слова: «Чёткие фазы с конкретными результатами всё изменили. Мы всегда точно знали, что нужно делать дальше».

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

Исходная точка и цель	Типичный срок	Что задаёт темп
GROW with SAP (SAP Cloud ERP, публичная редакция)	от 6 до 9 месяцев	Только стандартные процессы; расширения на выпущенных API
RISE with SAP (SAP Cloud ERP Private)	от 9 до 18 месяцев	Объём, число расширений, объём данных
Конвертация ECC по пути brownfield	от 12 до 18 месяцев	Собственный код, simplification items, тестирование
Внедрение greenfield с ECC	от 18 до 24 месяцев	Перепроектирование процессов, нагрузка изменений на пользователей
Выборочный перенос данных	от 12 до 18 месяцев	Определение объёма данных и специализированные инструменты

Для сравнения: продуктовый эксперт SAP, проанализировавший сотни проектов на публичной редакции, оценивает типичный go-live в пять–семь месяцев. Предложение SAP GROW Fast, запущенное в начале 2026 года, рассчитано на два–четыре месяца при фиксированном объёме. Программы GROW я планирую на срок от 6 до 9 месяцев, потому что данные, решения и обучение требуют времени, которого не требует программное обеспечение.

На RISE инфраструктурой управляет SAP, и это снимает часть работы фазы Prepare. Работу с данными, тестированием и изменениями это не снимает. Руководство по миграции с ECC на S/4HANA объясняет, как выбрать между brownfield, greenfield и selective.

SAP Concur, продукт для командировок и расходов, является отдельным облачным продуктом со своим проектом. Планируйте его как отдельное направление со своей интеграцией с финансами S/4HANA, а не внутри плана фаз S/4HANA.

Где ломаются бюджеты и сроки

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

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

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

Ошибка 1: назначать сроки до того, как понятен объём

На программе в рознице в странах GCC в 2023 году клиент пообещал совету директоров внедрение за девять месяцев без запаса. Когда миграция данных затянулась сильнее ожидаемого, они пропустили срок на три месяца, и руководство потеряло доверие к команде. Я сказал им прямо: этот график был слишком агрессивным.

Решение: фиксируйте сроки после фазы Explore, а не на старте, и скажите об этом совету директоров заранее. Закладывайте запас от 15 до 20 процентов сверх оценки поставщика.

Ошибка 2: считать миграцию данных направлением, которое начинается поздно

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

Решение: начинайте профилирование данных на фазе Discover, а не Realize. Проведите полную пробную миграцию на фазе Realize до начала интеграционного тестирования. Мой материал о том, почему миграция данных SAP проваливается, подробно разбирает цикл пробных миграций.

Ошибка 3: пропускать контрольные рубежи качества под давлением сроков

Рубеж между Realize и Deploy команды пропускают чаще всего, потому что давление «просто выйти в go-live» достигает там пика. Пропуск рубежей качества ради того, чтобы «уложиться в график», позже приводит к ещё большим задержкам.

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

Ошибка 4: обучать пользователей за два месяца до go-live

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

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

Ошибка 5: назначать go-live на пик делового цикла

Hershey запустила свою систему на SAP R/3, Siebel и Manugistics в июле 1999 года, на три месяца позже плана и прямо в сезон заказов к Хэллоуину. Её CEO сообщил аналитикам, что из-за проблем Hershey не сможет выполнить заказы к Хэллоуину на $100 млн.

Решение: нанесите на карту пиковые периоды для каждого затронутого подразделения, включая закрытие месяца и квартала. Выходите в go-live в период низкой нагрузки, даже если это означает сдвиг на шесть недель. Сдвиг можно наверстать, а провальный go-live в пиковый сезон уже нет.

SAP Activate состоит из шести фаз, и они образуют каркас любого плана S/4HANA, в облаке или on-premise. Указанная ниже длительность служит отправной точкой для планирования одной программы, а не обещанием.

1. 1Discover2–4 недели. Выход: подписанные границы и критерии успеха
2. 2Prepare3–6 недель. Выход: устав утверждён, ресурсы закреплены письменно
3. 3Explore4–8 недель. Выход: у решений по разрывам есть владельцы, сроки зафиксированы
4. 4Realize8–16 недель. Выход: пробная миграция пройдена, интеграционные тесты закрыты
5. 5Deploy2–4 недели. Выход: подписание UAT, репетиция закрытия, go/no-go
6. 6Run4–8 недель hypercare. Выход: дефекты ниже порога, передача в поддержку подписана

С этой таблицы фаз я начинаю каждый план:

Фаза	Типичная длительность	Что происходит	Рубеж выхода перед переходом
Discover	от 2 до 4 недель	Бизнес-обоснование, объём, выбор модели развёртывания (публичное облако, частное облако или on-premise)	Подписанные границы проекта и измеримые критерии успеха
Prepare	от 3 до 6 недель	Подключение команды, управление, системный ландшафт, базовый план, реестр рисков	Устав утверждён, по каждому модулю названы лица, принимающие решения, ресурсы закреплены письменно
Explore	от 4 до 8 недель	Воркшопы Fit-to-Standard, журнал разрывов, перечень WRICEF	Решения по разрывам записаны с владельцами; сроки зафиксированы
Realize	от 8 до 16 недель	Настройка, разработка, модульное и интеграционное тестирование, пробные миграции	Пробная миграция пройдена; интеграционные тесты закрыты
Deploy	от 2 до 4 недель	Приёмочное тестирование пользователями, репетиция cutover, обучение конечных пользователей, финальная загрузка	Подписание UAT, репетиция закрытия пройдена, go/no-go
Run	от 4 до 8 недель hypercare	Поддержка на местах, ежедневная сортировка инцидентов, передача в поддержку	Открытые дефекты ниже согласованного порога; передача в поддержку подписана

Куда на самом деле уходит время

Discover проходят наспех. Команды назначают срок, не понимая объёма, и пропускают измеримые критерии успеха, например «сократить закрытие месяца на три дня».

Prepare становится точкой, где начинаются технические задержки в on-premise, потому что инфраструктуру строят клиент и партнёр. Закрепляйте ресурсы письменно. Устные обещания доступности испаряются.

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

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

Deploy требует плана cutover с точными шагами, временем и ответственными. «Перенести данные» не является шагом.

На программе в американском здравоохранении в 2023 году клиент отставал от графика на три месяца и столкнулся с перерасходом бюджета на $2 млн. Мы перезапустились с помощью воркшопов Fit-to-Standard из SAP Activate. Команда нашла 28 процессов, которые можно было вести без каких-либо доработок.

Слова их руководителя проекта: «Мы потратили месяцы на проектирование того, что в SAP уже было». Через шесть недель они вернулись в график.

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

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

Отрасль добавляет собственное торможение. Эти диапазоны относятся к полной корпоративной программе S/4HANA на нескольких площадках, поэтому они длиннее, чем одно развёртывание RISE сроком от 9 до 18 месяцев:

Отрасль	Диапазон планирования	Что растягивает сроки
Производство	от 14 до 20 месяцев	Качество спецификаций и маршрутов, настройка MRP, требования QM
Розница и потребительские товары	от 12 до 18 месяцев	Интеграция POS, объём основных данных, окна пикового сезона
Фармацевтика	от 16 до 22 месяцев	Валидация GxP, прослеживаемость партий, сериализация
Коммунальные услуги	от 15 до 20 месяцев	Управление приборами учёта, тарифные структуры для выставления счетов, интеграция GIS и SCADA
Государственный сектор	от 18 до 24 месяцев	Учёт фондов, регулирование закупок, нагрузка согласований, локализация данных
Автомобилестроение	от 16 до 22 месяцев	Цепочка поставок just-in-time, контроль инженерных изменений
Авиакосмическая и оборонная отрасль	от 20 до 26 месяцев	Отчётность перед государством, учёт по программам, защищённые цепочки поставок
Нефть и газ	от 18 до 24 месяцев	Учёт совместных предприятий, капиталоёмкие операции
Финансовые услуги	от 14 до 20 месяцев	Проектирование ролей с разделением полномочий, регуляторная валидация

Что меняют инструменты AI, а что нет

SAP Joule for Consultants стал общедоступным в 2025 году. Он отвечает на вопросы по настройке на основе собственной базы знаний SAP, включая SAP Notes, и объясняет код ABAP. SAP Build Code, общедоступный с марта 2024 года, генерирует с помощью Joule код расширений на Java и JavaScript на SAP BTP.

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

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

1. Поздние изменения объёма. Фиксируйте объём в конце фазы Explore. После этого совет по управлению изменениями утверждает каждое изменение с приложенной оценкой влияния на сроки и бюджет.
2. Качество данных. Большинство компаний пропускают оценку данных на этапе планирования. Плохие данные являются самой устойчивой причиной провала пробных миграций.
3. Узкие места в ресурсах. Получите от руководителей подразделений письменные обязательства по конкретным людям и датам. Подготовьте замену для каждой критической роли.
4. Задержки решений. Эскалируйте разногласия по объёму в течение 48 часов. Не позволяйте решениям ждать ежемесячных обзоров.
5. Позднее управление изменениями. Начинайте общаться с конечными пользователями на фазе Prepare, а не за две недели до go-live.

Что касается инструментов, SAP Cloud ALM служит платформой SAP для управления внедрением. Основная поддержка SAP Solution Manager 7.2 заканчивается в конце 2027 года, а расширенная поддержка отдельных функций продлится до 2030 года. SAP Best Practices Explorer выведен из эксплуатации в 2023 году, и его процессный контент теперь находится в SAP Signavio Process Navigator.

Это руководство входит в мой обзор внедрения SAP, где собраны ссылки на все темы, от бизнес-обоснования до запуска.

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

По моему опыту, от 6 до 9 месяцев на GROW with SAP (публичная редакция) и от 9 до 18 месяцев на RISE with SAP (частная редакция). С ECC конвертация brownfield или выборочный перенос данных занимает от 12 до 18 месяцев, а внедрение greenfield от 18 до 24 месяцев.

Сколько длится каждая фаза SAP Activate?

Как отправная точка для планирования: Discover от 2 до 4 недель, Prepare от 3 до 6 недель, Explore от 4 до 8 недель, Realize от 8 до 16 недель, Deploy от 2 до 4 недель и Run от 4 до 8 недель hypercare. На крупных программах сильнее всего растягивается Realize.

Как RISE with SAP влияет на сроки?

RISE передаёт ответственность за инфраструктуру SAP, и это снимает часть работы фазы Prepare. Он не сокращает миграцию данных, тестирование, обучение и принятие решений, а именно на них уходит большая часть времени. Дисциплина clean core может сократить Realize, если она останавливает собственную разработку до того, как та начнётся.

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

Закладывайте запас от 15 до 20 процентов сверх оценки поставщика. Фиксируйте дату в конце фазы Explore, когда объём и разрывы известны, и скажите об этом совету директоров до старта.

Как сократить сроки внедрения SAP?

Проводите Fit-to-Standard строго, потому что каждая доработка, которой удалось избежать, экономит недели. Начинайте очистку данных на фазе Discover и выделяйте сотрудников бизнеса на полный день, а не одалживайте их на часть времени. Готовьте план cutover во время Realize, а не после неё.

Что выбрать: внедрение SAP по принципу big bang или поэтапное?

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

Каковы самые частые причины задержек проектов SAP?

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

Сколько длится hypercare после go-live SAP?

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