Ключевые роли в команде внедрения SAP и их ответственность

Для внедрения SAP нужны восемь ролей с назначенными, полностью выделенными владельцами: исполнительный спонсор, руководитель проекта, функциональные лидеры, ИТ-руководитель, руководитель миграции данных, руководитель по управлению изменениями, партнёр по внедрению и независимый советник по программе. RISE with SAP добавляет собственных контактных лиц SAP по поставке и делает владение Clean Core явным. Это руководство для спонсоров и директоров программ, которые собирают команду или чинят уже существующую. Здесь описано, за что отвечает каждая роль, что ломается без неё, каков размер команды в зависимости от размера компании и как создать Центр компетенций (CoE) до запуска. Начните с проверки того, какую из восьми ролей занимает человек, у которого есть ещё и основная работа. Это ваш самый большой риск.

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

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

В любом внедрении SAP эти роли должны быть заняты. Название должности важно меньше, чем ответственность.

1. Исполнительный спонсорРешения, финансирование, эскалация
   Советник по ERP-программеНезависимый надзор, риски, согласование с руководством
2. Руководитель проектаСроки, бюджет, координация

• Функциональные лидеры и эксперты предметной областиПроектирование процессов, настройка модулей
• ИТ-руководитель и командаИнтеграция, разработка, безопасность
• Руководитель миграции данныхКачество данных, очерёдность загрузки, переход на новую систему
• Руководитель по управлению изменениямиОбучение, внедрение у пользователей, коммуникации
• Партнёр по внедрениюАрхитектура, проектирование интеграции, реализация

Роль	Основная ответственность	Что ломается без неё
Исполнительный спонсор	Стратегические решения, финансирование, полномочия по эскалации	Дрейф, споры об объёме, никто не разрешает тупики
Руководитель проекта	Сроки, бюджет, координация между командами	Задержки, неразрешённые блокеры, перерасход бюджета
Функциональные лидеры и эксперты предметной области	Проектирование бизнес-процессов, настройка модулей	Неверная конфигурация, обходные пути после запуска
ИТ-руководитель и команда	Интеграция, разработка, безопасность, производительность	Технический долг, сломанные интерфейсы, нестабильность
Руководитель миграции данных	Качество данных, очерёдность загрузки, точность перехода	Непригодные данные, сорванный запуск, месяцы очистки
Руководитель по управлению изменениями	Обучение, внедрение у пользователей, коммуникации	Сопротивление пользователей, параллельные таблицы
Партнёр по внедрению	Архитектура, проектирование интеграции, реализация	Избыточная разработка, сбои интеграции
Советник по ERP-программе	Независимый надзор, риски, согласование с руководством	Решения, принятые в изоляции, избежимые ошибки

Исполнительный спонсор

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

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

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

Руководитель проекта

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

Я видел, как клиент потерял ведущего разработчика посреди внедрения. Весь проект встал на несколько недель, пока искали замену.

Обратная проблема не менее разрушительна. Я работал с компанией, у которой в команде было больше 30 человек. Никто не знал, кому принадлежат решения. Для простых изменений требовалось пять совещаний. Сроки растянулись с 12 до 18 месяцев только из-за коммуникационных издержек.

Функциональные лидеры и эксперты предметной области

Эти люди переводят бизнес-операции в конфигурацию SAP. Им нужно знать бизнес настолько, чтобы оспаривать плохие процессы, и SAP настолько, чтобы понимать, что возможно.

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

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

ИТ-руководитель и команда

ИТ-команда отвечает за техническую основу: разработку, Basis, безопасность, интеграцию и производительность. В S/4HANA она также отвечает за дисциплину Clean Core, не допуская пользовательский код в ядро.

Интеграцию недооценивает большинство команд. Каждое подключение к внешней системе нужно спроектировать, построить, протестировать и закрепить за владельцем. Интерфейсы ломаются на UAT, когда никто не описал потоки данных. Включайте ИТ в сессии по разработке концепции (blueprint), а не после того, как решения приняты.

Руководитель миграции данных

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

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

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

Руководитель по управлению изменениями

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

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

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

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

Советник по ERP-программе

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

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

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

Модель из восьми ролей остаётся в силе. В 2026 году в неё нужно встроить три вещи.

Собственные контактные лица SAP в RISE

В частном облаке RISE with SAP инфраструктурой и технической эксплуатацией занимается SAP. В её документе о ролях и ответственности клиенты согласуют услуги с SAP Cloud Architect Advisor, Client Delivery Manager или командой центра поддержки клиентов частного облака SAP. Внесите тех, кого назначит SAP, в ваш список рядом с командой партнёра и назовите человека на вашей стороне, который отвечает за эти отношения. В on-premise SAP выступает как поставщик ПО, и это не применяется.

Clean Core и владение расширениями

В S/4HANA Cloud Public Edition принцип Clean Core обеспечивается самой конструкцией: расширения проходят через выпущенные API, инструменты ключевого пользователя или SAP BTP. В частном облаке и on-premise модификации по-прежнему возможны, но каждая из них усложняет обновления. Кто-то должен отвечать за эту границу.

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

ИИ меняет производительность, а не ответственность

SAP Joule for Consultants (общедоступен с 2025 года) отвечает на вопросы по конфигурации на основе собственной базы знаний SAP и объясняет код ABAP. SAP Build Code генерирует код расширений на Java и JavaScript в SAP BTP. Microsoft Copilot составляет черновики записок для управляющего комитета и отчётов о статусе.

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

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

В таблице показаны типичные размеры каждой роли в зависимости от масштаба компании. Считайте её отправной точкой и корректируйте с учётом объёма и географии. О том же вопросе за пределами SAP читайте в моём руководстве по команде внедрения ERP.

Роль	Малое предприятие	Средний сегмент	Крупное предприятие
Исполнительный спонсор	Старший директор	CIO или CFO	C-level с управляющим комитетом
Руководитель проекта	1 на полную занятость	1-2 на полную занятость	Руководитель программы и руководители рабочих потоков
Функциональные лидеры	1-2 на модуль	Выделенный на каждый модуль	Несколько на модуль
ИТ-команда	2-3 (общие)	4-6 (выделенные)	8+ специалистов
Миграция данных	1 руководитель	1 руководитель и аналитики	Выделенный рабочий поток
Управление изменениями	Минимум 1	Минимум 2	3-5 выделенных
Руководитель по Clean Core или расширениям на BTP	Архитектор решения	Архитектор решения	Выделенная роль
Контакты SAP (RISE)	Назначенный контакт	Назначенный контакт	Назначенные контакты с ежеквартальными обзорами
Партнёр по внедрению	5-10 консультантов	15-25 консультантов	30+ с директором программы

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

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

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

Ответ на вопрос «сотрудники или консультанты?» почти всегда: и те, и другие.

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

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

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

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

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

1. Соберите команду до выбора ПО. Один клиент купил модули, которые его команда не могла поддерживать, и за этим последовали полгода хаоса.
2. Выделяйте людей полностью. Неполная занятость означает, что при давлении побеждает основная работа. Я видел, как критичная настройка ждала неделями, потому что кто-то был слишком занят.
3. Размещайте команду вместе, где возможно. Один производственный клиент сэкономил недели бесконечных согласований, собрав команду в одном помещении три дня в неделю.
4. Определите пути эскалации заранее. У одного розничного клиента был одностраничный документ, точно показывающий, как решения поднимаются по цепочке. Он избавил от бесчисленных задержек.
5. Записывайте решения вместе с обоснованием. Я работал с компанией, которая фиксировала, что решила и почему. Это избавило от бесконечных пересмотров, когда в середине проекта пришли новые руководители.
6. Отмечайте вехи по ходу. Производственный клиент проводил ежемесячные церемонии признания заслуг. Мелочь, но она поддерживала моральный дух на протяжении изматывающего 18-месячного внедрения.

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

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

Вот роли CoE, которые стоит планировать с первых месяцев внедрения.

Роль в CoE	Основная ответственность
Директор CoE	Стратегия SAP, согласование с бизнес-целями, работа CoE
Архитектор решения	Архитектура, проектирование интеграции, управление Clean Core
Руководитель по Clean Core или расширениям на BTP	Каталог расширений, анализ влияния обновлений
Функциональные консультанты	Оптимизация модулей, улучшение процессов
Технические консультанты	Разработка, Basis, производительность, безопасность
Руководитель по изменениям и обучению	Внедрение у пользователей, обучение, рост компетенций
Руководитель по управлению данными	Качество основных данных и стандарты
Руководитель по интеграции	Middleware, API, межсистемные потоки данных
Руководитель поддержки	Решение инцидентов, непрерывное улучшение
Владелец отношений с SAP (RISE)	Эскалации в SAP, обзоры сервисов, согласование дорожной карты

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

Один клиент вложил 10 % бюджета CoE в непрерывное обучение. Через три года он внедрял новые функции, к которым его конкуренты не могли даже подступиться. Так выглядит работающий CoE.

Почему команды внедрения SAP терпят неудачу, даже когда план выглядит надёжным?

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

Какие роли обязательны в любом внедрении SAP?

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

Что меняется в структуре команды для RISE with SAP?

SAP занимается инфраструктурой и технической эксплуатацией, поэтому вы работаете с назначенными SAP контактными лицами, такими как Client Delivery Manager или Cloud Architect Advisor. Внесите их в список и назовите собственного владельца этих отношений. Владение Clean Core тоже должно быть явным: выделенный архитектор в крупных программах или архитектор решения в программах среднего сегмента.

Кого привлекать в команду проекта SAP: сотрудников или консультантов?

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

Когда начинать создавать CoE для SAP?

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

Как ИИ меняет структуру команды SAP в 2026 году?

Инструменты вроде SAP Joule for Consultants, SAP Build Code и Microsoft Copilot повышают производительность в ролях с большим объёмом рабочих процессов, когда люди пользуются ими последовательно. Команда несколько меньше, чем требовалась для того же объёма до появления этих инструментов, но не радикально. Встройте инструменты в описания ролей и оставьте ответственность за людьми: ИИ готовит черновик быстрее, а за его содержание по-прежнему отвечают люди.