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

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

В начале карьеры я работал на программе SAP, которая отлично выглядела на бумаге. Графики, реестры рисков, журналы изменений, всё, что положено. Никто этому не следовал. Управляющий комитет собирался редко. Финансы ждали миграции данных. ИТ ещё не начинали. Никто не отслеживал зависимости. Все считали, что кто-то другой держит ситуацию под контролем.

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

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

Планирование охватывает объём, сроки, бюджет, ресурсы, реестр рисков и обязательства по вехам. Большинство команд это делает. Вопрос в том, пользуется ли этим кто-нибудь из недели в неделю.

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

1. 01Отслеживание прогрессаФакт относительно плана по пакетам работ
2. 02Выявление отклоненийЛюбая задача с опозданием в три дня
3. 03Проверка зависимостейКто блокируется, если это сорвётся
4. 04ЭскалацияПо заранее согласованному пути
5. 05Оценка измененийСначала время, стоимость и ресурсы
6. 06Пересмотр базового планаТолько после официального изменения

Каждую неделю, с назначенными владельцами

Вот что ломается, когда контроля нет:

Что ломается без контроля	Почему это происходит
Сроки сдвигаются незаметно	Никто не проверяет между обзорами вех
Допущения остаются непроверенными	Каждая команда ждёт, что зависимость возьмёт на себя другая
Объём растёт неформально	Изменения утверждают на совещаниях без оценки влияния
Риски игнорируют, пока они не реализуются	Журнал рисков обновляют раз в квартал, а не раз в неделю
Затраты выходят за бюджет	Трудозатраты лежат в табелях, но не привязаны к пакетам работ
Команды перестают общаться	Статус-встречи превращаются в обновления без действий

Это публичные случаи, а не истории клиентов. Их первопричины я постоянно вижу в консультационной работе.

Lidl: около семи лет, примерно €500 млн, и проект остановлен

Lidl начала проект eLWIS на SAP Retail в 2011 году. Её практика оценки запасов отличалась от стандартной модели SAP, и Lidl решила адаптировать программное обеспечение, а не практику. К 2018 году система работала в Австрии, Северной Ирландии и США, но совет директоров пришёл к выводу, что исходные цели недостижимы при разумных затратах. Lidl остановила проект и вернулась к развитию собственной системы. Отраслевая пресса оценила затраты примерно в €500 млн, а член правления, отвечавший за ИТ, ушёл в 2017 году. Heise сообщил о решении в июле 2018 года. Урок такой: годы кастомизации ради сохранения унаследованной практики были провалом контроля, а не провалом программного обеспечения.

Hershey: заказы к Хэллоуину примерно на $100 млн не доставлены

Новую систему Hershey на SAP, Siebel и Manugistics планировали запустить в апреле 1999 года, в тихий для кондитерской отрасли месяц. Запуск сдвинулся на три месяца и состоялся в июле, как раз когда начали поступать заказы к Хэллоуину. Заказы не доходили из системы до складов. Генеральный директор сообщил аналитикам, что из-за этих проблем Hershey не доставит около $100 млн продукции к Хэллоуину, а продажи третьего квартала упали на 12,4 %. Материал журнала CIO относит настоящую причину провала к выбору момента. Контроль графика, защищающий пиковый сезон, заставил бы выбрать другую дату go-live.

Revlon: сбой на заводе и существенный недостаток внутреннего контроля

Revlon запустила SAP на заводе в Оксфорде, Северная Каролина, своей крупнейшей производственной площадке, в феврале 2018 года. Сбои затронули производство и отгрузки крупным розничным сетям США. В марте 2019 года Revlon раскрыла существенный недостаток внутреннего контроля (material weakness), связанный с внедрением, сославшись на отсутствие эффективной непрерывной оценки рисков и нехватку обученных людей в затронутых подразделениях. Инвесторы подали в суд; TechTarget рассказал об этом иске, в котором утверждалось, что отгрузки примерно на $64 млн остались невыполненными.

Ни один из этих проектов не провалился из-за того, что SAP оказалась неверным выбором. Они провалились на основах планирования и контроля, известных десятилетиями.

Структура декомпозиции работ

Структура декомпозиции работ (WBS) разбивает весь объём на результаты с понятными владельцами. Без неё работа невидима, пока не опоздает. Для программы SAP она охватывает проектирование процессов, настройку, миграцию данных, интеграцию, тестирование, обучение и cutover, и каждый из этих блоков разбит на задачи с владельцем и сроком.

Ценность не в документе. Он заставляет вести разговор о том, что должно произойти, кто это делает и от чего зависит. Зависимости убивают проекты. Задержка в миграции данных блокирует интеграционное тестирование, а оно блокирует приёмочное тестирование пользователями (UAT), которое сжимает окно cutover. WBS делает эту цепочку видимой.

Управление графиком

Графики ломаются по предсказуемым причинам. Людей забирают на другие задачи. Оценки оказались неверными. Решения принимаются дольше, чем планировалось. Закладывайте резерв с первого дня: как явный буфер рядом с задачами, которым он скорее всего понадобится, а не как запас, размазанный по всему плану.

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

Относитесь к выбору момента go-live как к отдельному решению. Никогда не запускайтесь в пик деловой активности. Урок Hershey применим к любой компании.

Контроль бюджета

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

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

Управление рисками

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

Один клиент потерял три месяца, когда поставщик услуг по миграции данных срывал срок за сроком. Мы раз за разом слышали «ещё две недели», пока не стало слишком поздно менять поставщика без выхода за бюджет. Риск с владельцем и датой срабатывания заставил бы принять это решение на месяцы раньше. Шаблон для оценки и закрепления таких рисков даёт моя матрица оценки рисков SAP.

Коммуникация и эскалация

Руководителям нужны главные выводы. Командам реализации нужны детали. Руководителям проектов нужны данные об отклонениях. Одно сообщение для всех не помогает никому.

Задокументируйте пути эскалации и отрепетируйте их до кризиса. На одном внедрении SAP ИТ считали, что конфигурацию проверяют финансы, а финансы считали, что её проверяет ИТ. Никто не поднял вопрос, пока до go-live не осталось три месяца, а критически важные согласования отсутствовали; исправление превратилось в аврал в последнюю минуту, дополнительные затраты и сдвиг запуска. Другая компания сделала всё правильно: отчётность была структурирована и привязана к действиям, поэтому, когда возникала проблема, все знали, кто за неё отвечает, каково влияние и как её будут решать.

Именно на объёме эскалация оправдывает своё существование. Я работал с авиакомпанией, которая начала с простого обновления системы бронирования. Через шесть месяцев она добавила изменения в программе лояльности, планирование экипажей и финансовые модули. Ничто из этого не было срочным. Никто не сказал «нет». Сроки удвоились, а затраты выросли на 70 %.

Сценарий для on-premise не переживает RISE with SAP без изменений. Три вещи стали другими.

RISE меняет то, кому вы эскалируете

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

Clean Core даёт контролю объёма техническую страховку

Теперь по каждому разрыву нужно решение: настроить его, расширить через released API (on-stack с ABAP Cloud или side-by-side на SAP BTP) или отклонить. В S/4HANA Cloud Public Edition изменение ядра невозможно. В частной редакции и on-premise оно возможно, но рекомендации SAP по Clean Core считают его крайней мерой, потому что каждая модификация добавляет работы при обновлении.

Это помогает контролировать объём. Просьба «просто немного подправить стандартный процесс order-to-cash» перестаёт быть непринуждённым разговором о настройке и превращается в расширение, требующее проектирования, разработки и тестирования. Создайте под управляющим комитетом небольшой форум по рассмотрению расширений, где один архитектор вправе одобрять или отклонять. Без него каждый спор о кастомизации доходит до управляющего комитета.

ИИ готовит отчёты, решения принимают люди

ИИ теперь помогает с бумажной стороной контроля. SAP Cloud ALM, инструмент SAP для управления жизненным циклом приложений, хранит задачи проекта, требования и статус тестирования и умеет формировать черновики требований по расшифровкам воркшопов. Microsoft Copilot готовит черновики сводок по отклонениям для материалов управляющего комитета на основе дашбордов и отчётов о статусе. Обнаружение аномалий в Power BI или SAP Analytics Cloud отмечает KPI, которые отклоняются от привычной картины. Это полезно для загрузки ресурсов, числа запросов на изменение и обращений в поддержку, и меньше для метрик, которые естественно колеблются.

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

Это минимальный ритм для программы на активной стадии реализации. Если какой-то строки нет, добавьте её прежде всего остального.

Контроль	Минимальная практика	Владелец	Частота
Структура декомпозиции работ	У каждой задачи есть владелец, срок и зависимости	Руководитель PMO	Обновляется еженедельно
Обзор графика	Отмечать любую задачу с опозданием более трёх дней; проверять критический путь	Руководитель программы	Еженедельно
Отслеживание бюджета	Факт относительно плана по пакетам работ	Финансовый руководитель программы	Еженедельно, отчёт ежемесячно
Обзор рисков	У каждого активного риска есть владелец, триггер и ответная мера	Руководители рабочих направлений	Еженедельно
Контроль изменений	Оценка влияния на время, стоимость и ресурсы до утверждения	Председатель совета по изменениям	Еженедельно или по мере поступления запросов
Обзор расширений (RISE и GROW)	Решение «настроить, расширить или отклонить» по каждому разрыву	Архитектор решения	Раз в две недели
Управляющий комитет	Решения, а не статусы; материалы рассылаются заранее	Спонсор от высшего руководства	Раз в две недели; еженедельно при cutover и hypercare

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

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

Планирование создаёт дорожную карту: объём, сроки, бюджет, ресурсы и риски. Оно задаёт направление в начале.

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

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

Почему проекты SAP проваливаются, несмотря на наличие плана?

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

У Lidl, Hershey и Revlon планы были. Им не хватило активного контроля: честного отслеживания, ранней эскалации и реальной реакции, когда появились тревожные признаки.

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

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

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

Руководители должны это поддержать. Когда CFO или COO публично поддерживает контроль изменений, неформальные запросы быстро сокращаются. В программах RISE и GROW решение о расширении по каждому разрыву добавляет сверху техническую проверку.

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

WBS разбивает весь объём на результаты, у каждого из которых есть владелец и срок. В программе SAP это проектирование процессов, настройка, миграция данных, интеграция, тестирование, обучение и cutover, всё разбито до уровня задач.

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

Как RISE with SAP меняет планирование и контроль проекта?

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

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

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

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

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