Планирование распределения ресурсов в проектах SAP

Планирование распределения ресурсов в проекте SAP означает решить, какие роли вам нужны, в какой фазе SAP Activate и на сколько часов в неделю, а потом каждую неделю проверять, совпадает ли реальность с планом. Закладывайте людей по ролям, а не обезличенную численность. Подгоняйте план под кривую фаз: функциональные специалисты в Explore, технические в Realize, данные, Basis и управление изменениями в Deploy. Подтверждайте доступность в письменном виде с линейными руководителями. Это руководство для директоров программ, PMO и CIO, которые строят или спасают план ресурсов для S/4HANA. Таблицы FTE и диапазоны дневных ставок ниже используйте как исходные ориентиры.

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

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

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

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

1. Численность по ролям и по фазам Activate. Не плоское распределение. Explore совсем не похож на Realize.
2. Часы в неделю, подтверждённые линейным руководителем. В письменном виде, а не по предположению.
3. Параллельные обязательства каждого человека. Тот, кто записан на 100%, но ещё и закрывает поддержку продуктивной системы, отдаст намного меньше.
4. Замена для каждой роли на критическом пути. Перекрёстное обучение не опция в программе на 18 месяцев.
5. Зависимости между потоками работ. У каждой есть названный владелец, срок и путь эскалации, и срыв виден в тот же день.
6. Периодичность обновления. Еженедельно в активных фазах. План на старте: это только первая версия.

Планы ломаются, когда планировщик использует обобщённые ИТ-роли. SAP требует конкретной функциональной и технической специализации. Стандартный набор для программы S/4HANA:

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

Функциональные консультанты. По одному ведущему на каждый модуль в объёме проекта: финансовый учёт (FI), контроллинг (CO), управление материальными потоками (MM), продажи и дистрибуция (SD), планирование производства (PP), расширенное управление складом (EWM), а также управление персоналом (HCM), техническое обслуживание и ремонт (PM) и система проектов (PS), если они входят в объём. Если вы всё ещё работаете на классическом управлении складом (WM), планируйте переход: право использовать его в рамках compatibility pack в S/4HANA on-premise закончилось в конце 2025 года.

Технические консультанты. Разработчики ABAP для отчётов, интерфейсов, конверсий, расширений, форм и workflow (RICEFW), а также для расширений по принципу Clean Core на released API или SAP BTP. Специалисты по интеграции для SAP Integration Suite (Cloud Integration, ранее CPI), для SAP Process Orchestration там, где он ещё работает, и для любого стороннего middleware.

Платформа. Консультанты Basis для HANA, патчей ядра, транспортов, копирования систем и настройки производительности. Консультанты по безопасности для проектирования ролей, анализа разделения обязанностей и SAP GRC Access Control, если он входит в объём.

Данные. Специалисты по миграции, работающие с приложением «Migrate Your Data» в SAP S/4HANA Migration Cockpit (старая транзакция LTMC признана устаревшей), с Migration Object Modeler для пользовательских объектов и с SAP Data Services для сложных преобразований. В моём руководстве о том, почему миграция данных SAP терпит неудачу, объясняется, почему этой команде нужно стартовать раньше, чем допускает большинство планов.

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

Сторона заказчика. Бизнес-аналитики (по одному на крупный модуль), владельцы процессов (по одному на процессную область) и тестировщики из операционных подразделений для UAT.

Самая частая ошибка планирования: относиться к этим ролям как к взаимозаменяемым ячейкам. Старший консультант по FI не проведёт дизайн-сессию по SD. Младший разработчик ABAP не спроектирует интеграцию. Обязанности по каждой роли разобраны в моём списке ключевых ролей команды внедрения SAP.

Потребность в ресурсах не постоянна. Фазы Activate создают предсказуемые кривые, которые плоское распределение упускает.

Prepare (обычно недели с 1 по 4). Лёгкая нагрузка. Руководитель программы, архитектор и по одному ведущему на модуль для определения объёма. Бизнес-пользователи подтверждают объём. Basis и безопасность начинают настройку сред.

Explore (обычно месяцы со 2 по 5). Высокая нагрузка на функциональных консультантов и бизнес-пользователей, график задают дизайн-воркшопы. ABAP и интеграция работают вполсилы, пока не приняты проектные решения. Basis готовит песочницу и системы качества.

Realize (обычно месяцы с 5 по 12). Высокая нагрузка на технических специалистов: настройка, разработка, модульное и интеграционное тестирование. Нагрузка на ABAP достигает пика. Бизнес-пользователи подключаются к циклам тестирования. Команда данных строит объекты миграции и проводит пробные прогоны.

Deploy (обычно месяцы с 12 по 14). Высокая нагрузка на миграцию данных, Basis, безопасность, изменения и обучение. UAT съедает ресурс бизнеса. Репетиции cutover требуют команд, работающих в одном месте. Начинается планирование hypercare.

Run (с 14-го месяца; hypercare обычно длится от 30 до 90 дней). Небольшая основная команда и плотное покрытие поддержкой. Basis и сопровождение приложений наращивают нагрузку, а консультанты её снижают.

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

1. PrepareОколо 11 FTEНедели с 1 по 4. Ведущие определяют объём, Basis настраивает среды
2. ExploreОколо 36 FTEМесяцы со 2 по 5. Функциональные специалисты и бизнес-пользователи
3. RealizeОколо 56 FTE, пикМесяцы с 5 по 12. Разработка, пик нагрузки на ABAP
4. DeployОколо 42 FTEМесяцы с 12 по 14. Данные, Basis, безопасность, изменения
5. RunОколо 12 FTEС 14-го месяца. Hypercare обычно от 30 до 90 дней

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

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

Технические специалисты размазаны слишком тонко. По оценке Джеральда Вайнберга из его работ об управлении разработкой программного обеспечения, человек, поделённый между тремя проектами, выдаёт около 60% своей полной мощности, а остальное теряется на переключения. Обзор исследований переключения между задачами от Американской психологической ассоциации говорит о потерях того же порядка: короткие умственные блоки при переходе между задачами могут стоить до 40% продуктивного времени. План выглядит эффективным. А вот отдача эффективной не выглядит.

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

1. Фиктивная доступность. Человек записан на 100%, но ещё ведёт закрытие месяца и поддержку продуктивной системы. Спросите, сколько часов в неделю он выделяет, над чем ещё работает и подтвердил ли это в письменном виде его линейный руководитель.
2. Общие роли без границ. Один человек одновременно занимается проектированием решения, тестированием и управлением изменениями. Делите ответственность по задачам, а не по должностям, и никогда не делайте одного человека критически важным в двух местах сразу.
3. Нет времени бизнес-пользователей. Воркшопы сдвигаются, а подписание UAT затягивается на недели. Закрепите время письменно с подписью руководителя подразделения, отслеживайте посещаемость и эскалируйте повторяющиеся случаи заранее.
4. Нет запаса. Одно отсутствие останавливает поток работ. Закладывайте запас на уровне задач, а не только на уровне фаз, и обучайте как минимум одного человека на каждой ключевой роли.
5. План, который никогда не обновляют. Составлен на старте и не пересматривался. Пересматривайте его еженедельно в активной поставке, привязывайте к контрольным точкам фаз и обновляйте, когда реальность меняется.

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

Стройте план по фазам. Нагрузка разработчика ABAP в Explore отличается от нагрузки в Realize. У бизнес-пользователей пики приходятся на Explore (дизайн) и на Deploy (UAT). Плоское распределение выглядит сбалансированным на бумаге и не работает на практике.

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

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

Обновляйте план каждую неделю. План, который не трогали две недели, скорее всего неверен. Отслеживайте фактическую загрузку в сравнении с плановой. Если кто-то две недели подряд загружен на 120%, это сигнал: либо он перегружен, либо план неверен.

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

Brownfield для среднего рынка (от $5 млн до $15 млн, около 12 месяцев)

Типичный объём: одно юридическое лицо или небольшая группа, три или четыре модуля (обычно FI, CO, MM, SD), стандартные процессы и ограниченная кастомная разработка.

Поток работ	Prepare	Explore	Realize	Deploy	Run
Руководитель программы	1	1	1	1	0,5
Архитектор решения	1	1	1	0,5	0
Функциональные консультанты (FI/CO, MM, SD и ещё один)	1	4	4	2	1
ABAP и технические специалисты	0	1	3	1	0,5
Интеграция	0	0,5	2	1	0,5
Basis	0,5	0,5	1	2	1
Безопасность и полномочия	0	0,5	1	1,5	0,5
Миграция данных	0	1	2	3	0
Руководитель тестирования	0	0,5	1	1	0
Изменения и обучение	0,5	1	1	2	0,5
Бизнес-аналитики заказчика	1	4	3	2	1
Пиковый итог FTE	5	14	20	17	5

Корпоративный brownfield (от $30 млн до $80 млн, от 15 до 18 месяцев)

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

Поток работ	Prepare	Explore	Realize	Deploy	Run
Руководитель программы и PMO	2	2	3	3	1
Архитекторы решения (ведущий и по модулям)	2	3	3	1,5	0,5
Функциональные консультанты (все модули в объёме)	2	10	12	5	2
ABAP и технические специалисты	0	3	8	3	1
Интеграция и middleware	0,5	2	5	2	1
Fiori и UI5	0	1	3	1	0,5
Basis	1	1	2	4	2
Безопасность и GRC	0,5	1,5	2	3	1
Миграция данных	0	2	5	6	0,5
Тестирование	0,5	1	3	4	0
Изменения и обучение	1	2	3	5	1
Бизнес-аналитики заказчика	2	8	7	5	2
Пиковый итог FTE	11	36	56	42	12

Дневные ставки по ролям и регионам (2024 и 2025 годы)

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

Роль	Onshore (США, Великобритания, Германия)	GCC (ОАЭ, КСА)	Nearshore (Латинская Америка, Восточная Европа)	Offshore (Индия)
Архитектор решения (старший)	от $2 000 до $3 500	от $1 500 до $2 500	от $900 до $1 500	от $500 до $1 000
Функциональный консультант (старший)	от $1 500 до $2 800	от $1 200 до $2 000	от $700 до $1 400	от $300 до $700
Функциональный консультант (среднего уровня)	от $1 000 до $1 800	от $800 до $1 400	от $500 до $900	от $200 до $500
ABAP и технические специалисты (старшие)	от $1 400 до $2 500	от $1 000 до $1 800	от $600 до $1 200	от $300 до $700
Специалист по интеграции	от $1 500 до $2 800	от $1 100 до $1 900	от $700 до $1 300	от $350 до $800
Basis	от $1 400 до $2 200	от $1 000 до $1 800	от $600 до $1 100	от $300 до $700
Безопасность и GRC	от $1 500 до $2 500	от $1 100 до $1 900	от $700 до $1 300	от $350 до $800
Миграция данных	от $1 300 до $2 200	от $1 000 до $1 700	от $600 до $1 100	от $300 до $700
Руководитель по изменениям и обучению	от $1 200 до $2 000	от $900 до $1 500	от $500 до $1 000	от $250 до $600
Младший консультант (любая роль)	от $800 до $1 400	от $500 до $900	от $400 до $700	от $150 до $350

Распределение между onshore, nearshore и offshore

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

В программах частного сектора США на onshore обычно приходится от 30 до 60% по FTE. Onshore сосредоточен в архитектуре, управлении изменениями, бизнес-анализе и старших функциональных ролях, где важна близость к бизнесу. Offshore сосредоточен в ABAP, разработке интеграции и выполнении миграции данных, где работу проще чётко описать. Федеральные программы США часто целиком выполняются onshore с ограничениями US-person, в зависимости от нагрузки.

В программах GCC на onshore обычно приходится от 60 до 70%, потому что правила местного найма и требования к арабскому языку поднимают эту долю. Offshore-работа смещается в центры Южной Азии из-за пересечения часовых поясов. В Европе картина разная: в производстве onshore часто составляет около 50%, а в госсекторе и регулируемых отраслях доля выше из-за требований к размещению данных.

Частая ошибка: оптимизировать это соотношение только по стоимости. Команда, на 80% состоящая из offshore и на 20% из архитекторов onshore, в таблице выглядит дёшево. Скрытые затраты: ежедневный цикл передачи работы и более медленные дизайн-воркшопы без бизнес-контекста. Самая дешёвая команда редко даёт самую дешёвую программу. Если вы сравниваете партнёров, в моём руководстве по партнёрам по внедрению SAP по уровням разобрано, чем отличаются их ставки и состав команд.

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

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

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

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

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

Через зависимости. Ведущего по настройке в Realize переводят на другой проект. Его работа встаёт, это задерживает интеграционное тестирование, затем UAT, затем готовность к cutover. Двухнедельное отсутствие на восьмой неделе может вылиться в шестинедельный срыв к go-live.

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

Как обеспечить участие бизнес-пользователей в проекте SAP, если у них есть основная работа?

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

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

Как действовать, если ключевой человек уходит посреди проекта?

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

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

Когда нужно эскалировать проблему с ресурсами?

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

Цена слишком ранней эскалации: неловкий разговор. Цена слишком поздней: недели срыва.

Как работать с ресурсами, которые разделены между несколькими проектами?

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

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