Как создать эффективный управляющий комитет проекта SAP

Управляющий комитет проекта SAP состоит из небольшой группы руководителей, которые принимают решения, недоступные команде проекта: бюджет, изменения объёма, конфликты между подразделениями и итоговое go/no-go. Он работает, когда у его членов есть реальные полномочия, когда он собирается достаточно часто, чтобы решать прямо на заседании, и когда готовность оценивается по фактам, а не по календарю. Это руководство для спонсоров и директоров программ, которые создают комитет или чинят тот, что превратился в аудиторию для отчётов о статусе. В нём разобрано, что комитет обязан решать, какой состав нужен проектам разного размера, как должны приниматься решения, чек-лист go/no-go и что меняют RISE with SAP и ИИ-инструменты.

Я ни разу не видел, чтобы проект SAP удался со слабым управляющим комитетом. Именно в комитете принимаются трудные решения. Либо они принимаются в реальном времени, либо копятся, пока не взорвутся при cutover.

На одном внедрении SAP комитет собирался раз в месяц. Команда проекта сообщила о сломанных процессах согласования, неполном тестировании и нехватке обучения. Руководство ответило, что «рассмотрит это». Этого так и не случилось. Проект запустили, а финансам потом полгода пришлось разгребать последствия.

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

Один комитет вёл. Другой сидел на заседаниях.

Если комитет только получает отчёты о статусе, он уже не справляется. Таблица показывает разницу на практике.

Функция	Как выглядит хорошо	Как выглядит слабо
Крупные решения	Изучает обоснование и решает на месте	«Обсудим отдельно»; вопрос возвращается в следующем месяце
Препятствия	HR затягивает тестирование? Председатель звонит руководителю подразделения напрямую	Признаёт проблему и записывает её в журнал
Объём	Сверяет каждый запрос на изменение с планом	Штампует то, что громче всего эскалируется
Риск	Видит, что вендор буксует, и готовит запасной вариант до того, как начнутся задержки	Ждёт, не решится ли само
Бюджет	Одобряет дополнительные 2 млн долларов на продление на три месяца, потому что сбой обойдётся дороже	Откладывает на следующий месяц
Go/no-go	Откладывает go-live на шесть недель из-за незавершённого тестирования и держится этой линии	Одобряет go-live, потому что дата стоит в календаре

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

Слишком много членов, и комитет не может решать. Слишком мало, и не хватает важных голосов.

Размер проекта	Бюджет и объём	Члены	Кто должен быть в комнате
Малый	До 0,5 млн долларов, одно подразделение, до 6 месяцев	От 3 до 5	Руководитель подразделения, ИТ-руководитель, представитель финансов
Средний	От 0,5 до 5 млн долларов, несколько подразделений, от 6 до 18 месяцев	От 5 до 8	Бизнес-руководители затронутых подразделений, ИТ-руководство, финансы
Корпоративный	Более 5 млн долларов, в масштабе всего предприятия, 18 месяцев и более	От 8 до 12	Топ-менеджеры (C-level) по финансам, HR, операциям и ИТ; руководитель программы; руководитель по изменениям

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

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

На основе фактов. Я работал с производственным клиентом, чья ИТ-команда сказала, что изменение процесса добавит три месяца. Бизнес настаивал, что оно «простое». Комитет отказался решать, пока не увидел оценки трудозатрат, анализ зависимостей и планирование мощностей. ИТ оказались правы. Комитет решил верно, потому что потребовал доказательств, а не встал на сторону самого громкого голоса.

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

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

По объёму, избирательно. У одного из моих клиентов подразделение вдруг потребовало 20 дополнительных отчётов. Комитет спросил, нужен ли каждый из них сейчас и не сорвёт ли он график. Он одобрил пять критически важных отчётов, а остальные перенёс на время после go-live. Это решение, вероятно, спасло дату запуска.

Держите заседания в пределах от 60 до 90 минут. Главные риски, конкретные решения, которые нужны, и действия с владельцами и сроками. Никаких технических обновлений, которые можно прочитать заранее. Если один и тот же вопрос появляется три заседания подряд без решения, у вас проблема управления, а не сложности.

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

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

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

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

Календарное давление не должно быть основанием для одобрения go-live. Перед голосованием комитет должен увидеть подтверждения по каждому из этих пунктов:

1. Интеграционное и приёмочное тестирование пользователями завершено, открытых критических дефектов нет
2. Финальная пробная миграция данных сверена и подписана финансами
3. Репетиция cutover завершена в рамках запланированного окна
4. Ключевые пользователи обучены, поддержка на местах и памятки готовы
5. Готовность бизнеса подтверждена письменно каждым владельцем процесса
6. План отката протестирован и согласован
7. Команда hypercare, путь эскалации и поддержка при первом закрытии периода готовы

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

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

Форум по clean core размещайте ниже комитета. В программах на RISE создайте орган архитектурного надзора (design authority), который утверждает или отклоняет запросы на кастомизацию с позиции принципов clean core. В комитет вопрос уходит, только когда блокируется критически важный для бизнеса запрос. Без этого слоя каждая кастомизация превращается в борьбу на уровне комитета. В on-premise по-прежнему действует традиционная модель, и SAP там вендор, а не участник.

1. Управляющий комитетПредседатель: спонсор. Бюджет, объём, конфликты, go/no-go
   Специалисты SAP по поставкеПриглашаются по вопросам платформы, а не идут через партнёра

• Офис управления программой (PMO)Ежедневное исполнение, журнал рисков, координация
• Design authority по clean coreРешает по кастомизации, эскалирует только заблокированные критические запросы

ИИ экономит время на бумажной работе. Microsoft 365 Copilot составляет протоколы по записи заседания. Работа сводится к проверке черновика, а не к написанию с нуля, и решения берутся из расшифровки. Atlassian Rovo может превращать заметки с заседаний в структурированные записи журнала решений, когда шаблон построен. Ассистенты на базе Joule в SAP Cloud ALM могут составить первую оценку влияния запроса на изменение объёма, так что комитет сможет решить прямо на заседании, а не откладывать.

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

Какова роль управляющего комитета в проекте SAP?

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

Сколько человек должно быть в управляющем комитете SAP?

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

Как RISE with SAP меняет управляющий комитет?

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

Чем управляющий комитет отличается от PMO?

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

Что должно быть в повестке управляющего комитета?

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

Когда управляющему комитету стоит отложить go-live?

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