Управление заинтересованными сторонами в SAP: остановите конфликты до их начала

Управление заинтересованными сторонами в SAP решает, завершится ли программа в срок или последний квартал уйдёт на споры. Оно сводится к четырём привычкам. Определите, кто важен и что волнует каждую группу. Запишите, кто имеет право принимать какие решения. Выстройте ритм коммуникаций, который соответствует фазе SAP Activate. Фиксируйте каждое значимое решение вместе с альтернативами. Это руководство для директоров программ, PMO и исполнительных спонсоров программ S/4HANA. Используйте таблицу ролей и ритм по фазам ниже, чтобы составить план взаимодействия до первого воркшопа.

Однажды я работал над внедрением SAP, где ИТ-блок хотел жёсткого контроля над системой, а финансовому блоку нужна была большая гибкость. К тому времени, когда пришли мы, команды перестали разговаривать. Финансовый блок был раздражён. ИТ-блок занял оборону. Руководство хотело понять, почему никто не общается.

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

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

У участников программы SAP разные заботы и разное влияние. Если относиться к ним как к одной аудитории, вы рассылаете неактуальные обновления и упускаете настоящие риски.

Роль	Что их волнует	Как с ними работать
Исполнительный спонсор (CEO, COO, финансовый директор группы)	Отдача, бизнес-риск, репутация программы	Напрямую, регулярно, коротко
Управляющий комитет (CIO, CFO, руководители бизнес-единиц)	Сроки, бюджет, объём работ	Структурированные обзоры с принятием решений
Руководство финансового блока (CFO, контроллеры)	Признание выручки, целостность отчётности, контроль	Раннее участие в проектировании; утверждение объёма FI/CO
Руководители операций и бизнеса	Непрерывность процессов, обучение, удобство использования	Воркшопы по проектированию; ответственность за приёмочное тестирование пользователями (UAT)
Руководство ИТ (CIO, руководитель архитектуры)	Архитектура, безопасность, интеграция, поддержка	Утверждение технического проекта
Владельцы бизнес-процессов	Точность процессов, исключения, пограничные случаи	Ведут воркшопы по проектированию; утверждают конфигурацию
Конечные пользователи	Кривая обучения, повседневная работа, изменения в должностях	Обучение и управление изменениями
Системный интегратор (SI)	Объём поставки, запросы на изменение, ресурсы	Формальное управление и документы по объёму работ
HR и управление изменениями	Влияние на людей, изменения ролей, коммуникация	Параллельный поток работ рядом с реализацией

Матрица «влияние и интерес» подсказывает, куда направлять усилия. CIO, CFO и спонсор находятся высоко по обеим осям: они утверждают изменения, откладывают go-live и выделяют людей, и если они теряют вовлечённость, программа лишается прикрытия. У владельцев процессов, контроллеров и архитекторов высокий интерес и меньше формальной власти, но их знание того, как бизнес работает на самом деле, делает их незаменимыми при проектировании. Членам совета директоров и руководителям вне программы нужны брифинги по вехам, а не еженедельные обновления. У конечных пользователей мало влияния и самая высокая степень затронутости: их принятие системы при go-live определяет, будет ли она работать на практике.

Влияние на результатВысокоеСреднееНизкое

• Совет директоров, внешние руководители

• Спонсор, CFO, CIO

• Владельцы процессов
• Контроллеры, архитекторы

• Конечные пользователи

СлабоУмеренноСильноНасколько программа их затрагивает

Самое эффективное взаимодействие происходит до того, как у кого-либо появятся претензии. Зафиксируйте на старте три вещи.

Права на принятие решений

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

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

Ритм коммуникаций

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

Базовый объём работ

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

По мере прохождения программой фаз SAP Activate меняются и потребности во взаимодействии. То, что работает в Explore, не работает в Deploy. Используйте это как основу плана взаимодействия:

Фаза	Фокус взаимодействия	Ритм	Кто ведёт
Discover и Prepare	Карта ролей, структура управления, брифинги спонсора, первые согласовательные сессии с финансами, операциями и ИТ	Брифинг спонсора на старте; организован управляющий комитет	Директор программы
Explore	Воркшопы Fit-to-Standard с руководителями бизнеса и владельцами процессов; решения по fit-gap рассматриваются до утверждения	Еженедельные рабочие сессии; управляющий комитет в конце фазы	Архитектор решения и владельцы процессов
Realize	Подготовка UAT; защита времени руководителей бизнеса для тестирования; статус дефектов и миграции данных	Управляющий комитет раз в две недели; руководители потоков еженедельно	Руководитель программы
Deploy	Готовность к cutover, критерии go/no-go согласованы до начала cutover	Ежедневные стендапы по cutover; брифинг руководства по go/no-go	Руководитель бизнес-операций при поддержке ИТ и SI
Run	Коммуникация в период hypercare, каналы обращений, обзоры стабилизации	Ежедневно в течение двух недель, затем еженедельно; обзоры на 30-й, 60-й и 90-й день	Руководитель поддержки и владельцы процессов

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

В традиционной модели было три стороны: клиент, SI и спонсоры. В RISE with SAP компания SAP становится участником реализации. Она отвечает за инфраструктуру и техническую эксплуатацию, а её команда customer success отслеживает освоение решения и получаемую ценность. Отсюда три изменения в управлении.

1. Форум по проверке расширений. По каждому пробелу нужно решение: настроить его, расширить через выпущенные API (on-stack с ABAP Cloud или side-by-side на SAP BTP) или отклонить. В S/4HANA Cloud Public Edition модификация ядра невозможна. В Private Edition возможна, но каждая модификация добавляет работы при обновлении. Небольшой форум ниже управляющего комитета, где один архитектор уполномочен решать, не даёт каждому спору о кастомизации попадать в управляющий комитет. Если его пропустить, технический долг всплывёт при первом крупном обновлении.
2. Ритм customer success с SAP. Команда SAP занимается освоением решения, использованием BTP и дорожной картой. Эта работа идёт параллельно с управлением реализацией и продолжается после go-live. Включите её в своё управление, а не ведите отдельно.
3. Путь эскалации в SAP. Когда что-то ломается на уровне платформы, CIO должен знать, кому звонить в SAP, а не только у партнёра. Подтвердите контакты и уровни сервиса до подписания.

Программам GROW with SAP на Public Edition нужны те же три элемента, но в облегчённом виде: меньше решений о расширениях, потому что возможностей для расширения меньше, более стандартизированный ритм customer success и эскалация, которая обычно сначала идёт через партнёра. Программы on-premise сохраняют традиционную модель, где SAP выступает поставщиком, а не участником.

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

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

Журналы решений на втором месте. ИИ-функции Confluence, которые теперь выходят под брендом Atlassian Rovo, умеют превращать заметки со встреч в структурированные записи журнала решений, когда шаблон уже создан.

Черновики требований помогают в Explore. SAP Cloud ALM умеет составлять черновики требований по расшифровкам воркшопов Fit-to-Standard. Каждую строку всё равно должен проверить человек.

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

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

«Нам нужна эта кастомизация»

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

«Мы не готовы к go-live»

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

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

«Нас не предупредили об этом изменении»

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

Когда конфликт выходит за рабочий уровень, важны три вещи.

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

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

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

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

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

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

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

Что такое управление заинтересованными сторонами во внедрении SAP?

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

SAP затрагивает финансы, HR, закупки, операции и ИТ одновременно, и у каждого свои приоритеты и своё влияние. Если управлять ими как одной аудиторией, получаются шаблонные обновления, а заботы, из которых растёт сопротивление, остаются без внимания. SAP Activate встраивает это в каждую фазу: воркшопы в Explore, ответственность за UAT в Realize и обзоры готовности в Deploy зависят от подготовленных участников со стороны бизнеса.

Как построить карту ролей для проекта SAP?

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

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

Что должен включать план взаимодействия по SAP?

Реестр ролей (имя, функция, влияние, интерес, основные заботы), план коммуникаций (канал, частота и содержание для каждой группы), права на решения по изменениям объёма, решениям по проектированию и готовности к go-live, мероприятия для каждой фазы Activate, путь эскалации для спорных решений и способ формально заявить о проблемах.

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

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

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

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

Как разрешать конфликты между финансовым блоком и ИТ в программе SAP?

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

Назовите противоречие точно. «Финансовый блок хочет, чтобы у контроллеров был доступ на чтение к производственным заказам для отчётности, а ИТ считает, что это нарушает разделение обязанностей» решить можно; «финансовому блоку нужна гибкость» нельзя. Вынесите его на управляющий комитет с вариантами и их рисками. Затем запишите решение и альтернативы, потому что такие споры возвращаются, когда люди меняются. Если управляющий комитет не может разрешить спор, он уходит к спонсору. Так управление и должно работать.

Как RISE with SAP меняет управление заинтересованными сторонами?

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