Руководящий комитет при внедрении SAP S/4HANA: состав и задачи

Узнайте, как руководящий комитет по SAP S/4HANA управляет ключевыми решениями и рисками.

Даже при продуманной архитектуре, опытном партнере и реалистичном плане внедрение SAP S/4HANA может застопориться из-за несогласованных решений. Например, два подразделения настаивают на разных процессах, региональная команда просит изменить корпоративный шаблон, а исправление ошибок в данных требует перенести запуск. Такие вопросы затрагивают сразу несколько участников проекта, и договориться на рабочем уровне удается не всегда.

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

Работа комитета может продолжаться и после первого запуска. По данным исследования SAPinsider «ERP Migration and Transformation 2026», 55 % респондентов уже внедрили SAP S/4HANA или SAP S/4HANA Cloud, но только 34 % считают переход полностью завершенным. Если компания использует несколько ERP-систем, проводит пилотные внедрения или переводит подразделения поэтапно, первый запуск становится лишь частью общей программы. На следующих этапах ей по-прежнему нужно согласовывать изменения и распределять ресурсы.

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

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

Чем занимается руководящий комитет

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

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

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

На практике комитету передают:

• Существенные изменения объема работ, бюджета и ключевых сроков;
• Споры о бизнес-процессах, по которым подразделения не смогли договориться;
• Нехватку сотрудников или других ресурсов, угрожающую выполнению проекта;
• Изменения архитектуры, затрагивающие несколько направлений или всю программу.
• Риски, которые проектная команда не уполномочена принимать;
• Значительные отступления от согласованных правил стандартизации;
• Решения о запуске системы.

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

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

Как распределяются полномочия в руководящем комитете

В крупных программах SAP решения принимают на нескольких уровнях. Помимо руководящего комитета, в работе участвуют офис управления программой (PMO), владельцы бизнес-процессов и данных, архитекторы, совет по стандартизации решений (SSB), а также команды внедрения и подготовки сотрудников. Чтобы вопросы решались вовремя, каждый участник должен знать, что он вправе согласовать самостоятельно и в каких случаях нужно обратиться к руководству. Иначе одно решение могут одновременно обсуждать несколько групп — или откладывать, ожидая действий друг от друга.

Ответственность обычно распределяется следующим образом:

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

• Офис управления проектами (PMO) координирует выполнение работ, следит за сроками и зависимостями между задачами, готовит отчетность и вопросы для рассмотрения комитетом;
• Владельцы бизнес-процессов отвечают за результат процесса целиком, в том числе когда в нем участвуют несколько подразделений;
• Совет по стандартизации решений или архитекторы рассматривают изменения процессов, интеграций и доработок, проверяют их соответствие согласованным принципам и принимают решения в пределах своих полномочий;
• Владельцы данных согласовывают определения и правила ведения данных, отвечают за их качество;
• Команда управления изменениями информирует сотрудников, организует обучение и готовит подразделения к новому порядку работы.

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

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

Кто должен входить в состав руководящего комитета проекта

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

Кто принимает решения в комитете

Куратор проекта со стороны руководства следит за тем, чтобы внедрение отвечало целям бизнеса, и помогает согласовать приоритеты, когда интересы подразделений расходятся. Эту роль может выполнять финансовый директор (CFO), операционный директор (COO), ИТ-директор (CIO) или другой руководитель с необходимыми полномочиями.

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

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

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

Постоянные участники

Руководитель трансформации или директор PMO предоставляет комитету обзор с точки зрения руководства, касающийся графика, объема работ, зависимостей, рисков и решений, требующих внимания. Эта роль, как правило, структурирует информацию и способствует принятию решений, а не заменяет ответственность руководства.

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

Приглашенные эксперты

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

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

Что стоит закрепить в уставе руководящего комитета

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

Устав должен определять:

• Задачи и состав комитета: за какие вопросы он отвечает, кто входит в постоянный состав и кто регулярно участвует в заседаниях; 

• Порядок принятия решений: какой состав необходим для кворума, требуется ли общее согласие и за кем остается окончательное решение при разногласиях;

• Полномочия проектных команд: что они могут решать самостоятельно и при каких условиях обязаны обращаться к комитету;

• Срочные вопросы: кто и как принимает решения между плановыми заседаниями;

• Подготовку и фиксацию решений: какие сведения участники получают заранее, где записываются принятые решения и кто отвечает за их выполнение;

• Принятие рисков: кто вправе согласовать продолжение работ, если после принятых мер часть риска сохраняется.

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

Также важно закрепить задачи, которые остаются у PMO, владельцев бизнес-процессов, совета по стандартизации решений (SSB), архитекторов, ответственных за данные и команд внедрения. Такое распределение помогает участникам сразу обращаться к нужным людям и избегать повторных согласований.

Заранее определите, когда нужно обращаться к руководящему комитету

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

Участие комитета может потребоваться, если:

• Изменения бюджета, объема работ или ключевых сроков выходят за пределы полномочий команды;

• Подразделения, регионы или юридические лица не могут согласовать общее решение;

• Возникает существенный риск для безопасности, соблюдения нормативных требований или работы компании;

• Предлагаемое решение серьезно меняет архитектуру или нарушает согласованные принципы стандартизации;

• Команда не может самостоятельно устранить нехватку ресурсов или проблему, угрожающую запуску.

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

Как подготовить вопрос для руководящего комитета

Сначала команда, обнаружившая проблему, описывает, что произошло и как это влияет на проект. Затем вопрос рассматривает ответственный за него участник: владелец бизнес-процесса, архитектор, совет по стандартизации решений (SSB), владелец данных или PMO. Он проверяет, можно ли решить проблему в рамках согласованных правил и своих полномочий.

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

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

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

Как меняются задачи руководства на разных этапах SAP Activate

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

В SAP Activate проект внедрения официально начинается с этапа Prepare. До него, на этапе Discover, решения обычно принимает руководитель, курирующий проект, или орган, отвечающий за предварительную подготовку. Если руководящий комитет уже сформирован, эти вопросы могут входить в его полномочия.

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

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

Как комитету принимать решения об объеме работ, бюджете, ресурсах и рисках

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

Поэтому к каждому существенному изменению команда готовит обоснование:

• Что предлагается изменить и какую задачу бизнеса это решит;

• Какие другие варианты рассмотрены;

• Сколько времени, денег и специалистов потребуется;

• Какие риски появятся, а какие удастся снизить;

• Что произойдет, если отказаться от изменения.

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

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

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

Как комитету контролировать доработки и соблюдение принципов Clean Core

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

Масштаб проблемы отражен в исследовании SAPinsider «ERP Migration and Transformation 2026». Среди респондентов 38% сообщили, что пересматривают процессы с собственными доработками или отказываются от них, чтобы упростить переход и последующие обновления. Еще 32% внедряют стандартные сквозные процессы для основных задач ERP. При этом адаптация и исправление собственного кода названы главной сложностью при внедрении SAP S/4HANA.

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

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

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

Оценивайте исключения, имеющие значение для руководства

Один «процент соответствия Clean Core» не даст руководству полной картины проекта. За ним могут скрываться разные проблемы: существенные отклонения от согласованных процессов, расширения, архитектуру которых нужно пересмотреть, несогласованные способы интеграции или нарушения стандартов разработки. Некоторые из них могут осложнить будущие обновления системы.

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

Опыт LeverX: как сократить число запросов на доработки

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

Наши специалисты провели рабочие встречи по согласованию процессов и сопоставили стандартные возможности SAP с запрашиваемыми доработками. Для оценки они использовали расчеты совокупной стоимости владения (TCO) и анализ рисков при обновлении системы. К обсуждению также привлекли сотрудников, которые помогали коллегам освоить новый порядок работы. За шесть месяцев клиент отказался более чем от 70% запросов на доработки.

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

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

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

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

Учитывайте состояние данных при оценке готовности к запуску

Качество данных и работа интеграций напрямую влияют на возможность перехода. В исследовании SAPinsider 82% респондентов назвали обязательным условием интеграцию ERP с отраслевыми приложениями, 78% — минимальные перебои в работе, а 75% — очищенные и согласованные данные во всех системах.

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

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

За подготовку сотрудников отвечают профильные команды

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

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

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

Как руководящему комитету принимать решение о запуске системы

К запуску в проекте могут оставаться сотни незавершенных задач. Чтобы решить, можно ли начинать работу в SAP S/4HANA, комитету нужна сводная оценка готовности с указанием проблем, которые могут повлиять на бизнес. Подготовить ее должны команды, отвечающие за соответствующие направления.

В оценку следует включить:

• Готовность системы и плана перехода;

• Критические ошибки и результаты проверки интеграций;

• Результаты переноса и сверки данных;

• Выполнение требований безопасности и нормативных требований;

• Готовность подразделений, пользователей и службы поддержки;

•  

  Незавершенные работы, от которых зависит запуск, и оставшиеся существенные риски.

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

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

Решение о принятии оставшегося риска нужно зафиксировать

Если к запуску выполнены не все критерии готовности, команда должна подготовить для руководства обоснование решения. В нем нужно указать:

• Что остается нерешенным;

• Какие последствия возможны для бизнеса и системы и насколько они вероятны;

• Как команда планирует снизить риск или временно обойти проблему;

• Кто отвечает за исправление и в какой срок;

• Кто вправе разрешить запуск с учетом оставшегося риска.

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

Как часто должен собираться руководящий комитет

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

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

Что обсуждается на заседании

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

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

Готовьте краткое обоснование решения

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

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

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

Ведите журнал решений

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

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

Какие инструменты помогают руководящему комитету принимать решения

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

SAP Cloud ALM помогает отслеживать выполнение работ, результаты тестирования и обнаруженные проблемы. SAP Signavio позволяет следить за изменениями бизнес-процессов, согласовывать приоритеты и определять, какие направления требуют внимания.

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

Какие показатели нужны руководящему комитету

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

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

Что может помешать эффективной работе комитета

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

Решения регулярно запаздывают

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

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

Команды по-разному понимают свои полномочия

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

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

Партнеры и регионы согласовывают решения по разным правилам

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

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

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

Решения остаются на бумаге

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

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

Матрица ответственности руководящего комитета

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

Для каких проектов SAP подходит эта модель управления

Эти принципы можно применять при внедрении SAP Cloud ERP, SAP Cloud ERP Private и локальной SAP S/4HANA. Распределение полномочий зависит от способа перехода, масштаба программы, существующих доработок, структуры компании и нормативных требований.

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

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

Как LeverX помогает организовать управление SAP-проектом

LeverX сопровождает переход на SAP S/4HANA от первоначальной оценки до поддержки и развития системы после запуска. Наши специалисты работают с процессами, данными, архитектурой и интеграциями, выполняют миграцию и помогают сотрудникам освоить новый порядок работы. Этот опыт позволяет учитывать при распределении ответственности реальные задачи проекта и зависимости между ними.

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

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

Часто задаваемые вопросы