Семь консалтинговых фреймворков для внедрения SAP и ИИ

Когда программа SAP или ИИ буксует, причина обычно структурная, и найти её помогают семь простых фреймворков. Опишите текущее состояние. Договоритесь через RACI, кто что решает. Привяжите работу к бизнес-возможностям. Найдите первопричины с помощью метода «пять почему». Расставьте приоритеты требований по MoSCoW. Ранжируйте риски по тому, что действительно способно остановить программу. После каждого этапа проводите настоящий post-mortem. Руководство написано для руководителей программ, консультантов и спонсоров проектов SAP и ИИ. Начните с таблицы ниже: найдите свой симптом и сначала примените подходящий фреймворк.

Медиакомпания среднего размера в Катаре внедряла SAP в нескольких регионах. Финансы и закупки должны были запуститься в первой фазе. Кроме того, в отчётность компания хотела встроить модели прогнозирования на основе ИИ.

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

Это была та самая промежуточная фаза. Слишком рано называть это провалом. Слишком поздно делать вид, что всё наладится само.

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

Версии всех семи я применял за 23 года работы на программах SAP, Oracle и ИИ в странах Залива, Европе и не только. Ни один из них не экзотичен. Все работают, если применять их дисциплинированно, а не как упражнение по подготовке документации.

Сопоставьте симптом с фреймворком:

Симптом, который вы наблюдаете	Фреймворк	Что получается на выходе	Типичные трудозатраты
Пользователи утвердили требования, но по-прежнему путаются	1. Карта текущего состояния	Общая карта того, как работа устроена сегодня на самом деле	От 3 до 5 дней воркшопов
Решения кочуют от встречи к встрече	2. RACI для ключевых решений	Назначенные владельцы для 20-30 ключевых решений	Один воркшоп, затем контроль исполнения
Спонсоры отстранились от «ИТ-проекта»	3. Карта бизнес-возможностей	Прогресс в отчётах выражен в бизнес-возможностях	Встроена в fit-to-standard
Один и тот же тип дефектов возвращается	4. Пять почему	Первопричина, которую можно изменить	Одна фасилитируемая сессия на проблему
Всё помечено высоким приоритетом	5. MoSCoW	Ранжированный объём с реалистичным списком Must Have	Одна совместная сессия бизнеса и ИТ
Реестр рисков выглядит нормально, но команда на нервах	6. Ранжирование рисков	Отдельные списки рисков, способных остановить программу, и просто неприятных	Еженедельный 30-минутный разбор
Одни и те же ошибки повторяются от этапа к этапу	7. Post-mortem	От трёх до пяти изменений с владельцами	Полдня после каждого этапа

Самая распространённая ошибка в начале программы: перескочить к решению, не описав то, что есть. Документация процессов обычно устарела. Люди описывают, как должно работать, а не как работает. Разрыв между этими двумя картинами и есть то место, где живут проблемы внедрения.

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

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

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

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

Чаще всего в проектах SAP и ИИ не хватает именно прав на принятие решений. Мнение есть у каждого. Кто принимает окончательное решение, не знает никто. Решения откладываются до следующей встречи, та отсылает к руководящему комитету, а он возвращает их рабочей группе.

Матрица RACI (Responsible, Accountable, Consulted, Informed: исполняет, отвечает, консультирует, информируется) закрепляет за каждым решением и результатом владельца. Accountable один: он может быть также исполнителем (Responsible) либо делегировать исполнение. Консультируемые дают вводные. Информируемые узнают результат.

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

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

Программы SAP и ИИ порождают много технической активности, которой бизнес не видит. Связь между тем, что строится, и результатом, который это должно дать, становится абстрактной. Спонсоры отдаляются, а «ИТ-проект» обвиняют в задержках, которые на деле объясняются бизнес-решениями.

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

В SAP Activate это ложится на воркшопы fit-to-standard в фазе Explore. Каждый процесс в рамках объёма представляет собой бизнес-возможность, а каждый разрыв между стандартом SAP и требуемой возможностью оборачивается решением: принять стандарт, настроить вариант или расширить. Разговор на уровне бизнес-возможностей удерживает внимание бизнеса на протяжении сборки и выявляет возможности, которые все считали входящими в объём, но которые никто не подтвердил.

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

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

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

1. 01Ошибки пробной загрузкиСимптом
2. 02Неверные сопоставления полейПочему загрузка не удалась?
3. 03Спецификация не проверенаПочему сопоставления оказались неверными?
4. 04Владельца назначили поздноПочему спецификацию не проверили?
5. 05План упустил зависимостьПочему владельца назначили поздно?

Первопричина: управленческое решение, а не правка данных

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

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

MoSCoW (Must have, Should have, Could have, Won't have this time: обязательно, желательно, возможно, не в этот раз) заставляет сделать выбор. Must Have: минимум, необходимый для go-live. Should Have: важно, но не блокирует запуск. Could Have: желательно, если позволят время и бюджет. Won't Have: прямо отложено.

Вся дисциплина держится на границе Must Have. В первом заходе MoSCoW в Must Have обычно попадает слишком много. Руководство DSDM от Agile Business Consortium, откуда MoSCoW и происходит, задаёт потолок в 60% трудозатрат на Must Have и предупреждает, что превышение ставит под угрозу поставку. Разрыв между первым заходом и реалистичным списком в основном состоит из непроверенных допущений.

Проводите MoSCoW с бизнесом и технологиями в одной комнате. Если проводить отдельно, списки Must Have у ИТ и у бизнеса оказываются несовместимыми, и никто не согласует их до начала конфигурации.

В большинстве реестров рисков длинные списки оцениваются по вероятности и влиянию, пересматриваются раз в месяц, а RAG-статусы редко меняются. Такие реестры фиксируют риск, но не побуждают к действию.

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

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

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

Post-mortem после этапа или go-live не даёт тем же ошибкам повториться на следующем этапе. Но именно его первым вычёркивают, когда график поджимает.

Полезный post-mortem задаёт четыре вопроса. Что мы планировали достичь и что достигли? Что получилось хорошо и стоит повторить? Что пошло плохо и в чём причина? Что мы сделали бы иначе? Он должен заканчиваться тремя-пятью конкретными действиями с владельцами, а не документом, пересказывающим, что произошло.

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

В Катаре post-mortem провели сразу после go-live, и он был нацелен на действия, а не на поиск виноватых. Во многом поэтому вторая фаза началась на более твёрдой почве.

Фреймворки остались прежними. Изменилось то, как их применяют, и тремя способами.

Черновики пишутся быстрее, слушать быстрее не стали. Инструменты ИИ превращают расшифровки воркшопов и документы по процессам в первичную карту за считаные минуты, а SAP Cloud ALM умеет составлять черновики требований по расшифровкам fit-to-standard. Сами воркшопы занимают столько же времени, сколько всегда, потому что смысл именно в том, чтобы слушать. Время, сэкономленное на черновиках, стоит вложить в проверку карты вместе с людьми.

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

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

Суждение, которое наслаивается на эти фреймворки, сегодня ценится выше, а не ниже. Если вы развиваете эти навыки как консультант, карьерные пути SAPopedia показывают, какие из них важны на каждом этапе карьеры в SAP.

Что такое консалтинговые фреймворки и зачем их используют в проектах SAP?

Это структурированные подходы к анализу, принятию решений и решению проблем. В программах SAP и ИИ они дают бизнес-руководителям, архитекторам, руководителям проектов, интеграторам и спонсорам общий метод.

Без него каждая группа по умолчанию полагается на собственную ментальную модель: результаты процессов, архитектуру либо сроки и ресурсы. Фреймворки вроде карты текущего состояния, RACI и MoSCoW делают разногласия явными и разрешимыми. SAP Activate сам является фреймворком для фаз, гейтов и результатов; эти семь работают внутри него и закрывают структурные и человеческие вопросы, которые одна методология не решает.

Как работает карта текущего состояния при внедрении SAP?

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

Она питает воркшопы fit-to-standard в фазе Explore в SAP Activate, где текущее состояние становится базой для сравнения со стандартными процессами SAP. Завершите её до начала этих воркшопов, иначе анализ разрывов будет опираться на допущения.

Что такое приоритизация MoSCoW и когда её применяют в программах SAP?

MoSCoW раскладывает требования на Must have, Should have, Could have и Won't have this time. Must Have: минимум для go-live; Won't Have явно исключены, чтобы они не просочились обратно.

Больше всего пользы она приносит в Explore, когда результаты fit-gap определяют решения по расширениям, и в Realize, когда дефекты и доработки конкурируют за время разработки. Обычная проблема: слишком много Must Have при первом заходе. DSDM рекомендует тратить на Must Have не больше 60% трудозатрат; фасилитатор, который оспаривает каждый пункт, при бизнесе и ИТ на одной сессии приведёт вас к этому.

Как провести эффективный разбор рисков в проекте SAP?

Как разговор, а не как отчёт о статусе. Начните с открытых вопросов вроде «Что вас больше всего беспокоит на этой неделе и не отражено в реестре?», прежде чем идти по реестру.

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

Что делает post-mortem после go-live SAP полезным?

Конкретные, выполнимые изменения на следующий этап. Пересказ случившегося: это запись, а не post-mortem.

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

Как консалтинговые фреймворки помогают при внедрении ИИ в средах SAP?

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

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