Оценка рисков проекта SAP: практическая версия

Оценка рисков проекта SAP перечисляет то, что может сорвать программу, и оценивает каждый риск по вероятности и влиянию. У каждого риска есть один назначенный владелец и ответные меры, согласованные до того, как риск наступит, а список пересматривают каждую неделю. Риски, которые топят программы SAP, редко бывают сюрпризами: миграция данных, интеграция, доступность людей, расползание объёма и принятие системы пользователями. Это руководство для руководителей программ и спонсоров, которым нужен реестр рисков, меняющий решения, а не лежащий в папке. В нём вы найдёте матрицу с баллами, шаблон реестра, три публичных провала как разобранные примеры и риски, которые добавляют RISE with SAP и Clean Core. Начните с того, чтобы назначить владельца каждому риску, который у вас уже есть.

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

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

Эти риски не были сюрпризами. Они были задокументированы. Никто по ним не действовал.

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

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

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

Сроки. Поздно утверждённая концепция (blueprint) сжимает тестирование, но дата go-live остаётся прежней. UAT, обучение и подготовку данных делают в спешке. Один и тот же сценарий повторяется почти на каждой программе, которая пропускает контрольную точку этапа и не сдвигает последующий план.

Принятие системы. Люди отвергают то, чего не понимают. Слабое или позднее обучение рождает обходные пути, обходные пути портят данные, а систему обвиняют в провале управления изменениями.

Эти случаи публичны и хорошо задокументированы. Закономерности повторяются на любом масштабе.

Lidl: около €500 млн за семь лет

Lidl начала проект eLWIS на SAP for Retail в 2011 году, запустила его в некоторых небольших странах и отказалась от него в 2018 году при заявленных затратах около €500 млн. Одна из широко обсуждаемых причин: Lidl оценивала запасы по закупочным ценам, а стандартная розничная модель SAP использует розничные цены. Lidl предпочла дорабатывать систему, а не менять практику, и заявила, что исходные цели не могут быть достигнуты при разумных усилиях.

Урок: несоответствие вашей модели данных стандарту SAP относится к рискам первой недели, а не к открытиям пятого года.

HP: около $400 млн потерянной выручки

В 2004 году HP перевела часть серверного бизнеса на консолидированную систему заказов и цепочки поставок на основе SAP. Заказы терялись между прежним фронтендом и SAP и требовали ручной обработки, а объём невыполненных заказов удвоился. Гендиректор HP заявил, что из-за проблем группа серверов и систем хранения данных потеряла около $400 млн выручки и $275 млн операционной прибыли, а портфель невыполненных заказов составил $120 млн. Позже CIO HP говорил, что команда планировала три недели сбоев, а должна была заложить резерв на четыре-шесть.

Урок: закладывайте резерв под плохой cutover, а не под средний, и создавайте запасы или буферы в каналах сбыта до переключения.

Nike: более $100 млн потерянных продаж

В 2000 году Nike запустила программу планирования спроса i2 до программы SAP ERP. Программу сильно доработали под унаследованные системы Nike, она работала медленно и падала под объёмом номенклатуры. Она заказывала слишком много одних моделей обуви и слишком мало других. Nike потеряла более $100 млн продаж, а её акции упали примерно на 20 %. Позже Nike перенесла краткосрочное и среднесрочное планирование в SAP.

Урок: никогда не считайте, что интеграция работает, пока она не отработала на промышленном объёме с реальными данными.

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

1. Документация по объёму: устав, утверждённый объём и подписанные требования. Если их нет, риск по объёму уже высок.
2. Обязательства по ресурсам: письменные обязательства руководителей подразделений, матрица навыков для критичных ролей и назначенная замена для каждой ключевой позиции.
3. Бюджет и сроки: утверждённый бюджет с резервом и график, сверенный с аналогичными программами. Шесть месяцев и минимальное финансирование на полный запуск: риск, о котором нужно сказать сейчас.
4. Обязательства вендоров: контракты с уровнями сервиса и штрафами. При RISE: ответственность SAP и путь эскалации.
5. Технический ландшафт: совместимость с унаследованными системами, сложность миграции данных, модель развёртывания и план Clean Core для любой кастомной разработки.
6. Журналы прошлых проектов: реестры рисков, журналы проблем и разборы итогов предыдущих программ SAP или ERP. Большинство рисков не новы.

Оцените каждый риск по вероятности и влиянию от 1 до 5 и перемножьте. Пример ниже даёт типичную отправную точку для программы S/4HANA; ваши оценки будут другими.

Риск	Вероятность (1-5)	Влияние (1-5)	Балл	Приоритет
Сбой миграции данных	4	5	20	Высокий
Задержки интеграции	4	4	16	Высокий
Нехватка ресурсов	4	4	16	Высокий
Перерасход бюджета	3	5	15	Средний
Кастомный код в ядре, блокирующий обновления	3	5	15	Средний
Расползание объёма	4	3	12	Средний
Пробелы в покрытии тестами	3	4	12	Средний
Производительность при пиковой нагрузке	3	4	12	Средний
Пробелы в соответствии требованиям	2	5	10	Средний
Нет пути эскалации в SAP (RISE)	2	5	10	Средний
Низкое принятие системы пользователями	3	3	9	Средний
Риск роста затрат на подписку или лицензии	2	4	8	Средний
KPI не отслеживаются	3	2	6	Низкий

Баллы от 16 и выше требуют назначенного владельца и действий сейчас. Баллы от 8 до 15 требуют наблюдения с определённым триггером эскалации. Ниже 8 оставьте риск в реестре, не тратя на него приоритетное время. Баллы дают отправную точку, а не выносят приговор: пробел в соответствии требованиям с оценкой 10 в регулируемой отрасли может превратиться в 25.

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

Поле	Что писать	Пример
Риск	Событие в одном предложении	Основные данные поставщиков не очищены до mock load 2
Владелец	Один назначенный человек	Руководитель кредиторской задолженности
Балл	Вероятность × влияние	4 × 5 = 20
Триггер	Измеримая точка, в которой вы действуете	Доля дубликатов выше 5 % в выгрузке mock 1
Реакция	Избежать, снизить, передать или принять, с описанием действия	Снизить: два аналитика по кредиторской задолженности на очистку данных на три недели
Следующая проверка	Дата	Обзор рисков в ближайший понедельник
Статус	Открыт, в работе, закрыт	В работе

Выражайте стоимость в реальных величинах, где можете. «Высокий риск» звучит расплывчато. «Задержка UAT на неделю обходится примерно в шестизначную сумму затрат команды и может сдвинуть go-live на три недели» привлекает внимание.

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

RISE меняет того, кто отвечает за доступность. SAP эксплуатирует инфраструктуру, поэтому риск смещается с «за доступность отвечает наша команда» на «за неё отвечает SAP, и нам нужен быстрый путь к ней, когда что-то ломается». Зафиксируйте названных контактов SAP, путь эскалации и уровни сервиса, а также план реагирования на инциденты, согласованный до go-live. Без них проблемы, которые должны уходить в SAP, слишком долго остаются внутри проектной команды.

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

1. Выявите риски во всех пяти категориях. Проведите воркшопы с ИТ, бизнесом и вендорами; каждый видит разные риски. При RISE включите контакты SAP как минимум в один воркшоп. Риски, которые команды обычно упускают: ИТ и бизнес ожидают разного, плохо определённые внешние интеграции, владельцы UAT, которые недоступны, и неформальные изменения объёма.
2. Оцените каждый риск по вероятности и влиянию, по возможности с реальными цифрами.
3. Назначьте одного владельца на риск. Человека, а не команду. Нет владельца, нет отслеживания и нет решения.
4. Определите реакцию до того, как риск наступит. Избежать, снизить, передать или принять. «Наблюдать и реагировать» это не план. Это отложенное решение.
5. Пересматривайте каждую неделю. Проверяйте открытые риски, добавляйте новые, пересчитывайте оценку там, где условия изменились, и эскалируйте всё, что приблизилось к триггеру. Выносите главные риски на управляющий комитет вместе с предлагаемым решением, а не просто с цветом статуса.

1. 01ВыявитьВсе пять категорий
2. 02ОценитьВероятность × влияние, от 1 до 5
3. 03Назначить владельцаОдин человек, а не команда
4. 04Определить реакциюИзбежать, снизить, передать или принять
5. 05Пересматривать еженедельноПересчитать баллы, эскалировать при приближении к триггерам

16 и выше: назначенный владелец и действие на этой неделе

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

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

Как построить матрицу рисков для проекта SAP?

Перечислите риски по объёму, ресурсам, техническим вопросам, срокам и принятию системы, а при RISE ещё по Clean Core и эскалации в SAP. Оцените каждый по вероятности и влиянию от 1 до 5 и перемножьте. Считайте 16 и выше высоким приоритетом, от 8 до 15 средним, а ниже 8 низким. Дайте каждому среднему и высокому риску владельца и измеримый триггер, например «если к 16-й неделе завершено менее 80 % UAT, дата go-live идёт на пересмотр». Пересчитывайте баллы каждую неделю и на каждой контрольной точке этапа.

Какие самые частые риски при внедрении SAP?

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

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

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

Кто должен отвечать за риски в программе SAP?

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

Что происходит, если пропустить оценку рисков ERP?

В большом масштабе получаются случаи вроде Lidl, которая в 2018 году отказалась от своего проекта SAP для ритейла после расходов около €500 млн. Или HP, чья миграция на систему заказов SAP в 2004 году стоила её серверной группе около $400 млн выручки. В меньшем масштабе механизм тот же: несоответствие модели данных, найденное поздно, интеграции, которые ломаются при промышленном объёме, и провалы принятия системы из-за слабого обучения. Риски можно было выявить до того, как они стали проблемами.