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

Избежать расползания объёма при внедрении SAP можно, если сделать каждое изменение видимым и дорогим для одобрения. Записывайте то, что находится вне объёма, так же тщательно, как и то, что входит в него. Пропускайте каждый запрос через контроль изменений с оценкой влияния на сроки, стоимость и качество. Требуйте компромисса за каждое добавление. Назначьте дату заморозки объёма при поддержке руководства и вносите ту же дисциплину в договор с системным интегратором (SI). Это руководство для директоров программ, спонсоров и PMO в программах на S/4HANA. Таблицу стоимости изменений и пункты договора ниже используйте в ближайшем пакете для управляющего комитета.

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

Один фармацевтический клиент начинал с чёткого графика на 18 месяцев. Три года спустя он всё ещё внедрял систему, а затраты удвоились. ИТ-директор (CIO) производственной компании рассказал мне, что его команда выбросила целые модули, которые месяцами настраивала, потому что требования постоянно менялись. Объём вырос настолько, что исходный план никто не узнавал.

Это не исключения. Именно так чаще всего проваливаются программы SAP.

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

Я работал с розничным клиентом, где мы начали чисто: базовые финансы и базовое управление материальными потоками (MM). Через полгода директор по маркетингу (CMO) захотел аналитику по клиентам. Затем операционному директору (COO) понадобились расширенные складские функции. Исходный девятимесячный график оказался под угрозой. Я возразил и отклонил оба запроса. Такая дисциплина и есть моя работа.

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

Один производственный клиент начал с 10 индивидуальных отчётов и закончил 47, и каждый добавлял время на проектирование, разработку и тестирование. Один только рабочий поток по отчётности превысил бюджет на 200 %.

200 %

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

Источник: Программа производственного клиента

Тревожные признаки

Вот признаки, за которыми я слежу, и ответ на каждый:

Тревожный признак	Глубинная причина	Реакция
«Ещё одна мелочь» становится повседневной фразой	Неясные границы объёма	Заново согласовать базовый план с руководителями бизнеса; ввести формальный контроль изменений
Руководители бизнеса добавляют функции неформально	Нет понимания влияния на смежные области	Пропускать каждый запрос через оценку влияния; показывать стоимость
Срок растягивается без формального перепланирования	Скрытое расширение объёма	Проводить контрольные точки по объёму; перепланировать с одобрения совета по изменениям
Документация не совпадает с тем, что построено	Неформальная работа с объёмом, нет контроля версий	Обновлять спецификации и планы при каждом одобренном изменении
Расход бюджета опережает прогресс	Скрытые трудозатраты от недокументированных изменений	Отслеживать трудозатраты по пакетам работ; разбирать отклонения
Команда работает ночами и по выходным, чтобы догнать график	Объём превышает возможности	Эскалировать совету по изменениям; добиться решения по объёму
Взаимные обвинения бизнеса, ИТ и партнёра	Объём уже вышел из-под контроля	Заморозить объём, провести анализ первопричин, заново зафиксировать базовый план

Всё связано

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

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

Давление «раз в десятилетие»

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

Что меняет Clean Core

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

Полезный побочный эффект: дисциплина объёма. Запрос «просто добавить этот шаг согласования в стандартный процесс от заказа до оплаты» перестаёт быть неформальным разговором о настройке и становится расширением со своими затратами на проектирование, разработку и тестирование. Создайте форум по проверке расширений ниже уровня управляющего комитета, с одним архитектором, который вправе одобрять или отклонять, и многие такие запросы остановятся ещё до попадания в базовый план. Программы on-premise без такого форума скатываются к старым привычкам. Моё руководство по Clean Core объясняет, как его организовать.

1. Определяйте объём с явными исключениями. Документируйте то, что вне объёма, так же тщательно, как и то, что входит в него, и получайте подпись под обоими списками. Споры начинаются именно там, где есть двусмысленность.
2. Ведите формальный контроль изменений с последствиями. Каждое изменение требует оценки влияния на стоимость, сроки и качество, и эта оценка видна тому, кто его одобряет.
3. Сообщайте границы объёма на каждом заседании управляющего комитета. Показывайте статус объёма в простом виде «красный, жёлтый, зелёный». Значительная часть дрейфа возникает из недопонимания.
4. Напишите план управления объёмом. Опишите, как изменения оцениваются, одобряются, эскалируются и отслеживаются, чтобы каждый рабочий поток обращался с ними одинаково. Мой шаблон объёма проекта SAP даёт отправную структуру.
5. Приоритизируйте по методу MoSCoW. Обязательно, желательно, возможно, не в этот раз. Настойчиво держите список «обязательного» коротким.
6. Ведите контроль версий для каждого решения. Каждое одобренное изменение обновляет базовый план. Каждое отклонённое изменение записывается с указанием причины.
7. Требуйте компромиссов. Если приходит новое требование, что-то другое уходит. «Обязательное» быстро становится необязательным, когда за него приходится платить.

Закрепить всё это помогают три приёма, которые я использовал.

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

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

Показывайте стоимость изменения. Изменение на этапе проектирования может стоить 5 000 долларов. То же изменение на этапе тестирования может стоить 50 000 долларов. Положите перед людьми простую диаграмму этого, и необдуманные запросы замедлятся.

Это ориентировочные диапазоны стоимости изменений для программ S/4HANA на рынке США. Они зависят от сложности и партнёра. Используйте их как ориентиры, а не как коммерческие предложения.

Фаза	Типичная стоимость небольшого изменения	Типичная стоимость среднего изменения
Explore (проектирование)	от 2 до 10 тыс. долларов	от 10 до 30 тыс. долларов
Начало Realize	от 5 до 20 тыс. долларов	от 20 до 80 тыс. долларов
Середина Realize (разработка)	от 15 до 50 тыс. долларов	от 50 до 200 тыс. долларов
Конец Realize (тестирование)	от 30 до 100 тыс. долларов	от 100 до 400 тыс. долларов
Deploy и переключение (cutover)	от 80 до 300 тыс. долларов	от 300 тыс. до 1 млн долларов и более
Hypercare (после go-live)	от 150 до 500 тыс. долларов	от 500 тыс. до 2 млн долларов и более

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

Пункты договора, которые важны

Расплывчатые договоры создают дорогие проблемы. Я видел, как клиент подписал договор, где было сказано лишь «внедрить S/4HANA». Позже партнёр заявил, что определённые процессы являются дополнениями, требующими доплаты, и клиент заплатил вдвое. Эти пункты такое предотвращают:

Пункт	Назначение
Объём с явными исключениями	Ограничивает то, что покрывает фиксированная цена, и снимает неопределённость насчёт дополнений
Заранее согласованные ставки на типовые изменения	Фиксирует цены на отчёты, интерфейсы и изменения конфигурации до того, как появится давление
Преемственность консультантов	Не даёт новым консультантам пересматривать принятые решения и расширять объём
Полномочия на одобрение с обеих сторон	Не даёт младшим консультантам обещать функции, которые никто не санкционировал
Оплата по вехам	Привязывает платежи к принятым результатам, а не к прошедшему времени
Критерии приёмки по каждому результату	Определяет, что значит «готово», до того как начнутся споры
Пункт о расширениях по Clean Core	Требует, чтобы расширения использовали выпущенные API или SAP BTP; экономит переделки при первом крупном обновлении

Мои заметки о переговорах по договору на внедрение ERP рассказывают, как добиться согласования этих пунктов.

Совет по контролю изменений

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

1. 01Запрос поданВ письменном виде, а не за кофе
2. 02Оценка влиянияВремя, стоимость и качество, до любого одобрения
3. 03Компромисс названЧто-то другое уходит, чтобы освободить место
4. 04Совет решаетБизнес, проект и финансы за одним столом
5. 05Базовый план обновлёнОтклонённые изменения записываются с причиной

Объём меняется только через совет

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

Большинство решений должны оставаться на уровне совета. Спонсору передаются только настоящие споры, что сохраняет его вовлечённость и не заваливает его. Проводите обзор объёма с руководителями рабочих потоков каждые две недели и сообщайте, сколько запросов подано, одобрено и отклонено. Когда люди видят в отчёте о статусе «рост объёма на 15 % за месяц», поведение меняется.

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

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

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

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

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

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

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

Что такое расползание объёма в проекте SAP?

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

Законные изменения объёма проходят через процесс и сопровождаются корректировкой сроков и бюджета. Расползание объёма приходит неформально и обходит контроль изменений.

Каковы самые частые причины расползания объёма в проектах SAP?

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

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

Как Clean Core меняет риск расползания объёма?

Он добавляет технический тормоз. В S/4HANA Cloud Public Edition ядро нельзя изменять, поэтому каждый пробел становится расширением со своими затратами на проектирование, разработку и тестирование. В Private Edition и on-premise модификация возможна, но добавляет работы при обновлении, поэтому рекомендации SAP её не поощряют.

Форум по проверке расширений с одним архитектором, наделённым правом решения, останавливает многие запросы до попадания в базовый план. Без такого форума программы on-premise возвращаются к старым привычкам.

Чем расползание объёма отличается от «позолоты»?

Расползание объёма идёт от бизнеса: запросы сверх согласованного. «Позолота» идёт от команды поставки: сложность, о которой никто не просил.

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

Как построить процесс контроля изменений, который действительно работает?

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

Одно это последнее правило отсеивает запросы, которые на самом деле не критичны.

Можно ли полностью избежать расползания объёма?

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

Цель в контроле, а не в искоренении. Контролируемое изменение идёт по задокументированному процессу, получает оценку влияния и обновляет базовый план. Неконтролируемое изменение обходит процесс и проявляется при тестировании или после go-live как затраты, которых никто не планировал.

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

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

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