Что такое внедрение SAP? Пошаговое руководство

Внедрение SAP это программа, которая переводит финансы, закупки, цепочку поставок, продажи и HR компании в одну систему SAP, обычно S/4HANA. Она проходит в шесть фаз по методологии SAP Activate, а успех или провал определяет работа, сделанная до того, как кто-либо начнёт настройку: проектирование процессов, качество данных и подходящая команда.

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

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

S/4HANA это текущая ERP-система SAP, она работает на in-memory базе данных SAP HANA. Во многих компаниях всё ещё работают старые системы ECC, но основная поддержка ECC заканчивается 31 декабря 2027 года, с возможной расширенной поддержкой до конца 2030 года за повышенную плату.

Основные модули, с которых в большинстве внедрений начинают:

Модуль	Что он охватывает
FI (финансовый учёт)	Главная книга, кредиторская задолженность, дебиторская задолженность, учёт основных средств
CO (контроллинг)	Места возникновения затрат, центры прибыли, внутренние заказы, управленческая отчётность
MM (управление материальными потоками)	Закупки, запасы, движения товаров, управление поставщиками
SD (продажи и дистрибуция)	Цикл от заказа до оплаты, ценообразование, отгрузка, выставление счетов
PP (планирование производства)	Производственные заказы, планирование мощностей, MRP
HCM (управление персоналом)	Основные данные персонала, расчёт заработной платы, учёт рабочего времени

Большинство компаний начинает с FI/CO и одного-двух операционных модулей. Остальное достраивается на следующих этапах.

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

Шесть фаз SAP Activate

1. 01

   Discover

   Подтвердить бизнес-обоснование и проверить приоритетные процессы на пробной или демонстрационной системе.

2. 02

   Prepare

   Мобилизация: команда, управление, документ об объёме работ, план и доступ к системам.

3. 03

   Explore

   Воркшопы Fit-to-standard с владельцами процессов. Формирование бэклога настроек, интеграций и расширений.

4. 04

   Realize

   Настройка, расширения, миграция данных и тестирование. Самая длинная фаза. Для выхода нужен чистый регрессионный прогон.

5. 05

   Deploy

   Обучение пользователей на реальных процессах, репетиция cutover, go-live со штабом запуска.

6. 06

   Run

   Hypercare, оптимизация и передача центру компетенций.

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

Фаза	Результат	Ответственный	Барьер для перехода дальше
Discover	Бизнес-обоснование, целевой объём работ, выбор варианта развёртывания	Спонсор и финансовый директор	Финансирование утверждено
Prepare	Документ об объёме работ, план, управление, сформированная команда	Директор программы	Спонсор подписывает объём работ
Explore	Результаты Fit-to-standard, бэклог, решения по расширениям	Архитектор решения с владельцами процессов	Нет нерешённых разрывов
Realize	Настроенная и протестированная система, мигрированные тестовые данные	Функциональные и технические руководители	Чистый регрессионный прогон; данные сходятся
Deploy	Обученные пользователи, отрепетированный cutover, пакет для решения go/no-go	Руководитель cutover	Пройдена трёхдневная репетиция закрытия
Run	Журнал hypercare, передача центру компетенций, бэклог второй очереди	Руководитель сервисной поддержки	Нет открытых P1/P2; центр компетенций принимает

Шаблоны для каждой фазы собраны в моём руководстве по шаблонам SAP Activate.

Барьер: трёхдневная репетиция закрытия

Барьер между Realize и Deploy команды чаще всего пропускают под давлением графика. Я советую провести трёхдневную репетицию закрытия до самого go-live. Если финансисты не могут закрыть книги на новой системе, миграция данных не готова, что бы ни говорил ИТ-отдел. Пропуск этого барьера обходится дороже, чем задержка, которую он мог бы вызвать.

Порядок важен. Четыре вещи нужно сделать, прежде чем принято хоть одно решение по настройке.

1. 01Описать текущие процессыКак они реально работают, с обходными путями
2. 02Выбрать стандарт или расширениеСтандарт почти всегда быстрее
3. 03Проверить качество данныхДо начала миграции данных
4. 04Собрать команду, затем зафиксировать объёмКто доступен, то и можно поставить

Только теперь начинается настройка

Опишите текущие процессы такими, как они реально работают

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

Решите для каждого процесса: стандарт или расширение

Определите, какие процессы покрывает стандартная функциональность SAP, а какие нужно расширять. Стандарт почти всегда быстрее. Каждое расширение добавляет циклы тестирования, риск при обновлении и затраты на сопровождение. По рекомендациям SAP по clean core каждое расширение ещё и нужно разместить в продуманном месте, и это делает решение более значимым, а не менее.

Проверьте качество данных до начала миграции данных

Самое недооценённое направление работ. Я видел компании, которые месяцами исправляли отчёты, потому что устаревшие записи клиентов загрузили без проверки. У одного клиента было больше 18 000 дубликатов записей о клиентах, и их исправление после go-live на несколько недель нарушило выставление счетов.

Сначала соберите команду, потом фиксируйте объём

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

Трудность	Как это выглядит	Что делать
Расползание объёма работ (scope creep)	Копятся просьбы «раз уж мы всё равно там, давайте добавим...»	Формальный контроль изменений с первого дня; для каждого запроса оценка влияния
Качество данных	Миграция вскрывает несоответствия, о которых никто не знал	Профилировать данные за шесть месяцев до go-live; чистить в исходной системе
Сопротивление пользователей	Через две недели после go-live пользователи возвращаются в Excel	Привлекать конечных пользователей к проектированию начиная с Explore; нужно участие, а не только обучение
Сбои интеграций	Подключения сторонних систем ломаются в UAT	Описать интерфейсы в Explore; рано тестировать на реалистичных объёмах
Урезанные циклы тестирования	Регрессию сократили, чтобы уложиться в дату	Защищать фазы тестирования; задержка в разработке не должна сжимать тестирование
Усталость команды	Настроение падает, число дефектов растёт на финальном отрезке	Отслеживать усталость простым еженедельным индексом настроения; по моему опыту, когда он переходит 25%, число дефектов в тестах резко растёт

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

До, во время и после go-live

До go-live: проведите репетицию закрытия, проверьте мигрированные данные по сверочным отчётам, обучайте на реальных процессах, а не на демонстрационных сценариях, и протестируйте план отката. Пройдите с руководящим комитетом критерии go/no-go и получите явное согласие, а не молчаливые кивки.

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

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

Производитель среднего размера постоянно сталкивался с нехваткой сырья. Закупщики винили планировщиков, планировщики винили таблицы, которым никто не доверял. Мы заменили эту схему на S/4HANA и сделали основную ставку на SAP PP с правильно настроенным MRP. Уровни запасов перешли от догадок к данным в реальном времени, заказы поставщикам стали запускаться по потребности, и через шесть месяцев дефицит сократился более чем на 50 процентов. Это удивило даже скептиков. Результат дало перепроектирование процессов, которое предшествовало настройке. PP без работы над процессами выдавал бы более быстрые неверные ответы. Выиграли и финансы: закрытие месяца ускорилось, а финансовый директор сказал, что цифрам наконец-то «можно верить», чего давно не было.

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

Руководство, написанное для 2022 года, не выдержит встречи с покупателем 2026 года. Четыре изменения нужно закладывать с самого старта.

Облачные редакции стали вариантом по умолчанию

Сейчас SAP продаёт две облачные редакции ERP: SAP Cloud ERP (публичная редакция, прежде S/4HANA Cloud Public Edition) и SAP Cloud ERP Private (частная редакция). RISE with SAP объединяет частную редакцию с эксплуатацией силами SAP и набором инструментов трансформации, в который входят SAP Signavio, SAP LeanIX и SAP Cloud ALM. SAP GROW это пакет для компаний среднего размера на публичной редакции.

Выбор редакции теперь стоит выше прежних споров о способе запуска. Big bang или поэтапно, greenfield, brownfield или selective: это выбор внутри редакции, а не вместо неё. Если вы всё ещё на ECC и вам нужно больше времени, SAP продаёт вариант перехода на частную редакцию ERP на период с 2031 по 2033 год, но SAP прямо говорит, что это платное предложение для перехода, а не продление поддержки.

Clean core оценивается по шкале, а не по принципу «да или нет»

В августе 2025 года SAP представила четыре уровня clean core, от A до D. Уровень A использует только выпущенные стабильные API, либо рядом с системой на SAP BTP, либо внутри системы с помощью ABAP Cloud. Уровень B допускает классические API и технологии, которые всё ещё считаются чистыми. Уровень C требует особых мер. Уровень D чистым не является.

Публичная редакция допускает только расширения уровня A. Частная редакция и локальная установка допускают классические расширения, поэтому дисциплина там держится на управлении, а не на том, что платформа вас блокирует. Практический вывод для программы: определите уровень и место каждого расширения в Explore и назначьте человека, который может сказать «нет». Партнёры без опыта работы с SAP BTP и ABAP Cloud создают долг уровней C и D с первой недели.

Joule и SAP Build Code в команде внедрения

Joule теперь встроен в SAP Activate Roadmap Viewer и SAP Cloud ALM, где отвечает на вопросы по задачам и готовит черновики по материалам методологии. SAP Build Code, общедоступный с 2024 года, использует Joule для генерации логики приложений, моделей данных и тестов для расширений на Java и JavaScript на SAP BTP. SAP добавила аналогичную помощь на базе генеративного ИИ и для ABAP-разработчиков.

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

Что это значит для программы, стартующей сейчас

Методика по-прежнему работает. Фазы по-прежнему применимы, и порядок работ по-прежнему важен. Изменились выбор редакции, дисциплина расширений и инструменты для команды. Программа, которая учитывает всё это на старте, воспринимает перечисленное как ограничения проекта. Та, что игнорирует, тратит первые три месяца на выяснение того, что изменилось, обычно по запросам на изменение от партнёра.

О стоимостной стороне тех же решений читайте мой разбор стоимости внедрения SAP. Если вы всё ещё на ECC, руководство по миграции с ECC на S/4HANA описывает пути конвертации.

Для чего используется SAP?

SAP ведёт основные бизнес-функции (финансы, закупки, цепочку поставок, HR, продажи) в одной системе с единой моделью данных.

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

Сколько времени занимает внедрение SAP?

Больше всего на сроки влияют два фактора: объём работ и команда. Сфокусированное внедрение S/4HANA с FI/CO и одним операционным модулем для одной компании может занять от 6 до 9 месяцев. Глобальный запуск по множеству юридических лиц, модулей и языков занимает от 18 до 36 месяцев.

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

Каковы шесть фаз SAP Activate?

Discover (бизнес-обоснование и соответствие), Prepare (команда, управление, план), Explore (воркшопы Fit-to-standard и бэклог), Realize (настройка, расширения, миграция, тестирование), Deploy (обучение, репетиция cutover, go-live) и Run (hypercare и передача центру компетенций).

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

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

Четвёртая причина новее: партнёр, который строит расширения без плана clean core и оставляет долг, всплывающий при первом крупном обновлении.

Как выбрать подходящего партнёра по внедрению SAP?

Опыт в вашей отрасли и в вашем масштабе, и рекомендации, по которым действительно можно позвонить. Названное имя старшего специалиста, который будет участвовать: тот, кто выступал на презентации, должен вести программу. Независимость: партнёры, зарабатывающие на продаже лицензий или подписок, заинтересованы рекомендовать больше объёма. Опыт clean core: спросите, сколько расширений на SAP BTP и ABAP Cloud они построили, и попросите их показать.

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

Что происходит после go-live?

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

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

Что такое RISE with SAP и подходит ли он моей организации?

RISE with SAP это подписочный пакет SAP для SAP Cloud ERP Private: программное обеспечение, инфраструктура и эксплуатация силами SAP и набор инструментов для анализа процессов, архитектуры и управления жизненным циклом. Внедрение по-прежнему выполняет ваш партнёр.

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