Как составить устав проекта внедрения SAP

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

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

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

На каждой крупной программе SAP путают три документа. Они решают разные задачи.

Документ	Назначение	Кто готовит	Когда
Предложение по проекту	Обосновать, почему проект нужен	Бизнес-спонсор	До утверждения
Устав проекта	Утвердить проект; зафиксировать объём работ, цели, назначенных владельцев и порядок управления	Спонсор вместе с руководителем программы	На старте
План проекта	Определить, как будет выполняться работа: задачи, ресурсы, зависимости	Руководитель программы	После утверждения устава

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

Цели, привязанные к бизнес-результату

Не «модернизация системы». У каждой цели должно быть число. Проверка: можете ли вы объяснить замысел члену совета директоров за 30 секунд без слайдов?

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

Сравните с розничным клиентом, которого я сопровождал. В его уставе KPI были определены с первого дня. Они показали снижение затрат на обработку заказов на 32 %, и этап 2 утвердили сразу.

Объём работ с явными исключениями

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

Я работал с компанией из сферы здравоохранения, которая сохранила фокус внедрения SAP именно так. Руководитель маркетинга захотел добавить аналитику для отслеживания кампаний во время приёмочного тестирования пользователями (UAT). В уставе для этого не нашлось места, и управляющий комитет сразу обратил на это внимание. Одно это решение сэкономило 850 000 долларов и позволило избежать задержки на шесть недель.

Конкретные люди, а не отделы

«Финансовая команда: даёт вводные по отчётности» не делает ответственным никого. А «Руководитель финансов, [имя]: определяет требования к отчётности, подписывает конфигурацию FI/CO, утверждает готовность к миграции данных» делает.

Вехи как обязательства

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

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

Бюджет, риски и зависимости

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

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

1. Цель и предпосылки: почему сейчас, что сломано, что будет, если ничего не делать.
2. Цели и показатели успеха: каждая цель с исходным значением, целевым значением и сроком.
3. Объём работ: модули, процессы, юридические лица, страны, площадки, интеграции и данные, входящие в объём.
4. Вне объёма: написано так же тщательно, как и объём, с указанием этапа, на который отложен каждый исключённый пункт.
5. Модель развёртывания и правила расширений: S/4HANA Cloud Public Edition, Private Edition в рамках RISE или on-premise, и как будут утверждаться индивидуальные разработки.
6. Управление: спонсор, управляющий комитет, совет по дизайну решения, контроль изменений, путь эскалации, с названными людьми.
7. Роли и ответственность: конкретные люди по каждой области процессов, данным, тестированию, изменениям и cutover.
8. Вехи: контрольные точки этапов с датами и критериями их прохождения. Примеры есть в моём руководстве по контрольным точкам качества.
9. Бюджет и резерв: общая сумма, резерв и кто может его освободить.
10. Риски, допущения и зависимости: включая параллельные программы и регуляторные сроки.
11. Требования соответствия: например, HIPAA в здравоохранении США, GxP в фармацевтике, SOX для компаний, чьи акции торгуются в США.
12. Подписание: спонсор и бизнес-руководители, с номером версии и датой.

1. 01Спросите тех, кто знает работуСпонсоры, бизнес-руководители и конечные пользователи
2. 02Отделите обязательное от желательногоВвод в эксплуатацию, этап 2 или не в этом проекте
3. 03Начните с шаблонаЗатем добавьте интеграцию, данные и соответствие требованиям
4. 04Будьте конкретны настолько, чтобы разрешать спорыМожете ли вы доказать, что каждая цель достигнута?
5. 05Добейтесь настоящего подписанияПрочитан, оспорен и принят, раздел за разделом

Устав, на который можно сослаться, когда на третьем месяце оспаривают объём

1. Спросите тех, кто знает работу

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

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

2. Отделите обязательное от желательного до написания объёма

Отнесите каждый запрос к одной из категорий: нужно для ввода в эксплуатацию, этап 2 или не в этом проекте. Один мой клиент из сферы профессиональных услуг превысил бюджет на 40 %, потому что требования лежали в трёх разных местах и их «открывали заново» спустя месяцы после старта проекта. На этом шаге поможет моё руководство по шаблону объёма работ.

3. Начните с шаблона, затем добавьте специфику SAP

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

4. Будьте достаточно конкретны, чтобы разрешать споры

Я вёл внедрение для розничного клиента в Сингапуре, в уставе которого было написано «модернизировать управление запасами». Половина команды решила, что это значит более быструю обработку. Другая половина сосредоточилась на прогнозировании. В итоге потрачено 1,8 млн долларов, а единого понимания, что такое успех, так и не появилось. По каждой цели спрашивайте: смогу ли я доказать, что это выполнено?

5. Добейтесь настоящего подписания

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

Ошибка	К чему приводит	Что делать вместо этого
Расплывчатые цели («повысить эффективность»)	Команды тянут в разные стороны	Поставьте число на каждую цель
Нет исключений	Объём тихо растёт	Пишите список «вне объёма» так же тщательно, как объём
Владельцы названы только должностью или отделом	Решения откладываются	Называйте конкретных людей
Нет показателей успеха	Ввод в эксплуатацию празднуют, ценность так и не показана	Определите KPI до старта
Параллельные программы не учтены	Столкновение ресурсов и бюджетов	Записывайте зависимости в обоих уставах
Устав написан партнёром по внедрению	Объём отражает то, что партнёр хочет поставить	Клиент владеет уставом, партнёр добавляет детали

По последнему пункту я тверд. Ваш партнёр по внедрению не должен писать ваш устав. У него стимул один: начать проект. У вас другой: определить его объём.

В RISE with SAP (Private Edition) добавьте в раздел об управлении два пункта. Первый: форум утверждения Clean Core. SAP теперь классифицирует расширения от уровня A, только released API, до уровня D, модификации (SAP News, август 2025). Private Edition по-прежнему позволяет изменять ядро, поэтому именно форум не даёт накапливаться техническому долгу. Второй: путь эскалации в SAP. В RISE SAP отвечает за инфраструктуру и техническую эксплуатацию. ИТ-директору (CIO) нужно знать, кому звонить в SAP, когда что-то ломается на уровне платформы, а не только у партнёра.

В GROW with SAP (Public Edition) устав становится короче. Расширения ограничены released-интерфейсами, поэтому платформа сама обеспечивает Clean Core, а возможности интеграции уже. Видение, показатели успеха, названные владельцы и исключения важны не меньше.

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

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

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

Что должен включать устав проекта SAP?

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

Чем устав проекта отличается от плана проекта?

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

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

Владеет им спонсор со стороны клиента, а черновик готовит руководитель программы; детали дают руководители финансов, ИТ и операций. Я не рекомендую поручать это партнёру по внедрению. Его стимул: начать проект, а не защитить вас от объёма, который вам не нужен.

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

Добавьте форум утверждения Clean Core, который решает, какие расширения допустимы и на каком уровне. Добавьте путь эскалации в SAP для проблем на уровне платформы, поскольку в RISE инфраструктурой занимается SAP. В GROW with SAP устав легче, потому что Public Edition обеспечивает Clean Core технически.

Может ли устав проекта меняться во время внедрения?

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