KPI внедрения ERP: 30 метрик, которые действительно важны

Важных KPI внедрения ERP немного: их анализируют еженедельно во время реализации и ежедневно в hypercare, и у каждого есть назначенный владелец. Это соблюдение графика, отклонение по стоимости, изменение объёма работ, доля пройденных тестов, точность миграции данных и, прежде всего, принятие системы пользователями. Ниже 30 показателей, которые использую я, разделённые на реализацию и период после go-live, с формулами и порогами, при которых нужно действовать.

Материал для директоров программ, руководителей PMO и спонсоров, которым нужен пакет для управляющего комитета, ловящий проблемы на 8-й неделе, а не на 18-м месяце.

Однажды клиент добавил в проект SAP 73 «небольших» изменения. Ни одно по отдельности не выглядело существенным. Вместе они вызвали задержку на пять месяцев. Никто не отслеживал объём изменений. (Если это звучит знакомо, в моём руководстве о том, как избежать расползания объёма работ в проектах SAP, описаны механизмы контроля.)

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

Это не исключительные провалы. Так бывает, когда команды отслеживают не то или не отслеживают ничего.

#	KPI	Что измеряет	Почему это важно
1	Соблюдение графика	Фактическое и плановое выполнение задач	Первый сигнал каскадных задержек
2	Отклонение по стоимости	Фактические расходы и бюджет по фазам	Выявляет перерасход, пока он не начал нарастать
3	Количество изменений объёма работ	Число и влияние утверждённых изменений	Неконтролируемые изменения самая частая причина перерасхода
4	Загрузка ресурсов	Отработанные часы и плановые; баланс нагрузки	Перегруженные люди выгорают или уходят посреди проекта
5	Уровень принятия системы	Доля целевых пользователей, активно работающих в системе	Единственный показатель, который говорит, что система работает на бизнес
6	Эффективность обучения	Баллы оценки; доля обученных пользователей	Предсказывает провал принятия системы до go-live
7	Точность миграции данных	Доля чисто перенесённых записей; доля ошибок	Плохие данные в новой системе приходится чистить месяцами
8	Простой тестовых сред	Часы незапланированного простоя тестовых систем	Нестабильность в тесте предвещает нестабильность на go-live
9	Показатель вовлечённости	Результаты опросов; посещаемость ключевых сессий	Раннее предупреждение о сопротивлении, пока оно не проявилось открыто
10	Скорость закрытия рисков	Доля открытых рисков, закрытых в срок	Измеряйте закрытие, а не только выявление
11	Результаты партнёра	Качество результатов; доля выполненных вех	Партнёры, срывающие ранние результаты, почти всегда срывают и поздние
12	Доля пройденных тестов	Доля тест-кейсов, пройденных с первого раза	Ниже 85 % в SIT обычно означает системные проблемы, а не случайные ошибки
13	Срок обработки запросов на изменение	Дни от запроса до решения	Длинные очереди сигнализируют о сбое управления
14	Скорость расходования бюджета	Расходы и общий бюджет в сопоставлении с выполненной работой	Показывает, идут ли деньги и прогресс вместе
15	Ход настройки	Доля выполненных запланированных пунктов настройки	Отставание здесь сдвигает тестирование и обучение дальше по цепочке

#	KPI	Что измеряет	Порог или примечание
16	Доступность системы	Аптайм после go-live	Выше 99,9 % хорошо; ниже 99 % превращается в проблему доверия пользователей
17	Скорость отчётов и дашбордов	Время загрузки; частота обновления	Если руководители выгружают данные в Excel, система не выполняет свою задачу
18	Производительность сотрудников	Время на задачу в сравнении с базовым уровнем до go-live	Клиент-дистрибьютор, автоматизировавший согласования, после go-live обрабатывал на 25 % больше транзакций в день
19	Решение с первого обращения	Тикеты, закрытые с первого обращения	Измеряет эффективность hypercare
20	Число обращений в поддержку	Открытые тикеты; среднее время решения	Всплеск около 30-го дня обычно сигнализирует о пробелах в обучении, а не об ошибках системы
21	Длительность циклов процессов	Обработка заказов, согласование счетов, цикл закрытия	Результат, который на самом деле волнует руководителей
22	Точность учёта запасов	Физические остатки и системные	Самый заметный показатель качества данных после go-live
23	Доля выполненных заказов	Заказы, выполненные в срок в новой системе	Прямое влияние на операции
24	Атрибуция выручки	Изменения выручки, связанные с новыми возможностями	Долгосрочное доказательство бизнес-обоснования
25	Соответствие требованиям	Замечания аудита; нормативные проблемы	Важнее всего в финансах, фармацевтике и регулируемых отраслях
26	Точность прогноза	Прогноз и фактический спрос	Показывает, пользуются ли планированием и доверяют ли ему
27	Удовлетворённость пользователей	Опрос об удобстве; NPS ключевых пользователей	Пользователи, которые ненавидят систему, создают обходные пути
28	Эффективность процессов	Время и затраты на процесс в сравнении с базовым уровнем	Обосновывает инвестиции перед советом директоров
29	Достигнутая экономия	Фактическая экономия и бизнес-обоснование	Финансовый директор спросит об этом через 6 и 12 месяцев
30	Возврат инвестиций	Чистые выгоды, делённые на общие затраты	Обычно измеряется через 12 и 24 месяца

Именно о них спрашивают чаще всего.

1. Индекс выполнения графика (SPI) = освоенный объём ÷ плановый объём. Выше 1,0: опережение графика; 1,0: в срок; ниже 1,0: задержка.
2. Индекс выполнения по стоимости (CPI) = освоенный объём ÷ фактические затраты. Выше 1,0: эффективно; ниже 1,0: перерасход бюджета.
3. Доля изменений объёма работ = (утверждённые изменения ÷ исходные позиции объёма) × 100. Менее 10 %: минимальное влияние; более 20 %: высокое влияние.
4. Уровень принятия системы = (активные пользователи ÷ целевые пользователи) × 100. Выше 80 % за первые 90 дней: сильный результат; ниже 60 % требует вмешательства.
5. Точность миграции данных = (чисто перенесённые записи ÷ записи, взятые в перенос) × 100. Выше 98 % до go-live; ниже 95 % должно отложить cutover.

SPI и CPI берутся из управления освоенным объёмом. Они работают, только если «освоенный объём» измеряется честно: задача, выполненная на 90 % и стоящая так три недели, не равна 90 % своей стоимости.

KPI без ритма обзора превращается в украшение. Вот график, который стоит установить.

1. РеализацияЕженедельный совет программыГрафик, стоимость, риски, доля пройденных тестов, изменения объёма работ. KPI контрольных точек идут в управляющий комитет
2. Дни 1-30Ежедневный обзор hypercareДоступность, число обращений, принятие системы по подразделениям
3. До 90-го дняЕженедельный обзор принятия системыПринятие системы, длительность циклов процессов, категории обращений
4. Месяцы 6 и 12Обзор спонсором и финансовым директоромПроизводительность, достигнутая экономия, ROI

Когда	KPI	Кто анализирует	Какое решение это определяет
Еженедельно во время реализации	Соблюдение графика, отклонение по стоимости, закрытие рисков, доля пройденных тестов, количество изменений объёма работ	Совет программы	Перепланировать, эскалировать или удержать объём
На каждой контрольной точке фазы	Ход настройки, эффективность обучения, точность миграции данных, результаты партнёра	Управляющий комитет	Пройти, пройти условно или остановить
Ежедневно в первые 30 дней после go-live	Доступность, число обращений и динамика, принятие системы по подразделениям	Руководитель hypercare	Куда направить поддержку на местах и исправления
Еженедельно до 90-го дня	Принятие системы, длительность циклов процессов, категории обращений	Совет программы	Повторное обучение, исправления настройки
Через 6 и 12 месяцев	Производительность, достигнутая экономия, ROI, удовлетворённость	Спонсор и финансовый директор	Утверждение бизнес-обоснования, объём фазы 2

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

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

Программы RISE with SAP и SAP GROW добавляют вопросы управления, которых нет в традиционном списке. Помогают три дополнительных показателя.

Структура расширений по уровням Clean Core

SAP теперь оценивает расширения по четырём уровням Clean Core, от A до D. Уровень A использует только выпущенные API; уровень D не соответствует Clean Core. Отслеживайте долю расширений на каждом уровне, используя проверки ABAP test cockpit, которые рекомендует SAP.

В public edition всё по конструкции относится к уровню A. В private edition и on-premise любое расширение уровня C или D это долг, который проявится при следующем обновлении. Сверяйте новые запросы на расширения с этим показателем еженедельно на фазе Realize и назначьте ответственного за каждое утверждение уровня C или D.

Размещение расширений определено

Формула: (расширения с согласованными уровнем и местом размещения ÷ все расширения в бэклоге) × 100. Цель: 100 % к концу Explore. Расширение, которому ещё не нашли место, как раз и превращается в классическую модификацию под давлением сроков.

Состояние отношений с SAP

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

ИИ полезен в работе по отчётности вокруг метрик. Обзор он не заменяет.

1. Joule с SAP Cloud ALM. SAP добавила Joule в Cloud ALM, поэтому команды могут запрашивать данные проекта и эксплуатации обычным языком, а не собирать каждую статусную выгрузку вручную.
2. Copilot в Power BI. Готовит черновик текстового резюме для пакета управляющего комитета на основе дашборда. Лучше всего работает при чистой модели данных.
3. Обнаружение аномалий. Power BI, Tableau и SAP Analytics Cloud могут отмечать KPI, отклоняющиеся от привычной картины. Стоит использовать для загрузки ресурсов, числа обращений и частоты изменений объёма работ. Не стоит использовать для метрик с большой естественной вариативностью, например дневного числа заказов.

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

Самый значимый KPI: принятие системы пользователями. Большинство команд измеряют его последним.

У меня был клиент из производства, чьи руководители выгружали всё в Excel. Огромный тревожный сигнал. Данные в системе были, а нужных им дашбордов не было. Мы исправили дашборды и вдвое сократили время принятия решений.

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

Лучший дашборд KPI не самый полный. Это самый маленький набор, на который управляющий комитет будет смотреть, с владельцем у каждой строки и последствиями, если красный цвет держится два цикла. Большинство программ KPI терпят неудачу потому, что нужное отслеживают, а потом игнорируют. О том, что делать, когда цифры уже красные, читайте в материале как вернуть проекты SAP в график.

Какой KPI внедрения ERP самый важный?

Уровень принятия системы пользователями. Технически успешное внедрение, которым никто не пользуется, не даёт бизнес-ценности. Остальные KPI (график, бюджет, тестирование) защищают условия для принятия системы. А принятие показывает, состоялось ли оно на самом деле.

Отслеживайте его с первой недели после go-live, по подразделениям. Низкое принятие в одной команде обычно указывает на пробел в обучении или проблему проектирования процесса, которые ещё можно исправить в hypercare.

Как часто нужно анализировать KPI внедрения ERP?

График, стоимость и риски еженедельно во время реализации, а не раз в месяц на управляющем комитете. KPI контрольных точек на каждой контрольной точке. Операционные KPI ежедневно в первые 30 дней после go-live, затем еженедельно до 90-го дня.

Какая доля пройденных тестов считается здоровой для UAT в SAP?

Выше 85 % прохождения с первого раза в системном интеграционном тестировании считается здоровым результатом. Если ниже, это обычно означает пробелы в проектировании процессов или ошибки настройки, а не отдельные дефекты.

Если вы входите в UAT с результатом ниже 85 %, остановитесь и устраните первопричину. UAT почти никогда не вычищает то, что пропустило SIT.

Что означает доля изменений объёма работ выше 20 % для проекта ERP?

Проект перепроектируется на ходу. Перерасход и задержки становятся вероятными.

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

Какие KPI специфичны для программ RISE with SAP?

Три сверх стандартных 30: структура расширений по уровням Clean Core (от A до D), доля расширений с согласованными уровнем и местом размещения и квартальный обзор состояния отношений с SAP (эскалации, уровни сервиса, качество обзоров успеха от SAP).

Как рассчитать ROI внедрения ERP?

ROI = (чистые выгоды ÷ общие инвестиции) × 100. Чистые выгоды: измеримая экономия и прирост выручки, которые можно отнести на счёт системы, за вычетом эксплуатационных затрат новой среды. Общие инвестиции включают программное обеспечение, внедрение, внутреннее время, обучение, миграцию данных и постоянную поддержку.

Будьте консервативны. Полные выгоды редко приходят в первый год. Постройте модель наращивания: 50 % выгод установившегося режима в первый год, 80 % во второй, 100 % начиная с третьего.

Каковы основные причины превышения бюджета внедрения ERP?

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

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