На рисунке 30.4 показано, как организованы ОКР для каждого блока, а также поэтапное достижение ожидаемых ключевых результатов и конечных целей улучшения. Здесь также показаны основные предположения о том, как решение позволит снизить количество отказов от заявок и увеличить число участников.
Сформулировать эти предположения может быть непросто. Трудно заранее определить, насколько снизится процент отказов от услуг благодаря упрощенному приложению и заранее заполненным данным о сотрудниках. Это требует суждения. Поэтому очень важно поэтапно получить ключевые результаты и проследить, как версия 1 решения влияет на показатели отказа от услуг, что позволит убедиться в необходимости продолжения усилий в версии 2 и, в конечном итоге, в версии 3, или переключиться на более перспективные направления.
Разработка дерева драйверов и отслеживание соответствующих KPI является основополагающим фактором для общего успеха цифровой трансформации. Оно обеспечивает четкую "Северную звезду", позволяет сосредоточиться на создании стоимости и создает четкую систему подотчетности.
Оценка здоровья стручков
Подразделение - это "боевая единица" в цифровой трансформации и трансформации с помощью ИИ. Невозможно успешно провести цифровую трансформацию без здоровых, зрелых стручков.
Многие цифровые преобразования продвигаются медленнее, чем планировалось изначально, потому что их подразделения плохо сконфигурированы (например, члены подразделения работают неполный рабочий день, не обладают достаточными навыками), не внедрили современные методы работы (например, agile, DevOps) или не имеют критически важных возможностей (например, управление производством, дизайн пользовательского опыта). По нашему опыту, разница в производительности между низкоэффективным и высокоэффективным подразделением может составлять 5× и более. Измерение и управление состоянием капсулы действительно имеет значение.
Оценка здоровья капсул производится с помощью трех линз:
Метрики конфигурации бодов. Это позволяет ответить на простой вопрос: Правильно ли укомплектована капсула? Это кажется достаточно очевидным, но каждая компания имеет ограничения по ресурсам, и капсулы могут работать долгое время без надлежащего обеспечения ресурсами. Вы действительно хотите ответить на два основных вопроса: Выделены ли ресурсы капсулы? И заполнена ли каждая роль человеком, обладающим необходимыми навыками? Эту оценку лучше всего проводить владельцу стручка и лидеру домена. QBR - отличная возможность оценить это в рамках отчетности QBR.
Бизнес/операционные KPI, связанные с под OKR
Пример из практики: Составление карты OKR - стимулирование привлечения клиентов к пенсионному страхованию
Экономическое обоснование решения
400 000Решение позволит сократить
заброшенный заявление
Уровень оставленных заявоксравнению с прошлым годом и 20% до 5% дополнительному набору 300 000 человек.
NPS из 10 приложений и промышленности
Ведущий NPS 50
2/3 заполненных заявок обычно зачисляются, что позволяет получить 200 000
дополнительные слушатели
Средняя маржа млн на участникаEBITDA
$500
NPS = 50
ЦелиКлючевые результаты
V1 - год 1V2 - год 2
Цель путешествия V3 - год 3
Под 1
Сократите время заполнения заявки на 60 %.
Ключевой результат 1.1:
Сократите количество необходимых документов
8
5
5
2
2
Ключевой результат 1.2:
40
30
30
20
10
Сократите количество этапов применения
Под 2
Включение функции предварительного заполнения данных о сотрудниках для 50% планов
ПРИЛОЖЕНИЕ 30.4
Ключевой результат 2.1:
% планов с API-связью с системой управления персоналом
0
30
30
50
50
Ключевой результат 2.2:
Информация о супруге и иждивенцах
Информация о предыдущем плане
Основная информация о сотрудниках
Предварительно заполненная информация о типе сотрудника
Показатели производительности стручка. Здесь речь идет о функционировании стручка. Эти показатели обычно извлекаются из инструментов управления бэклогом, например, Jira, Azure DevOps, Digital.ai (поэтому важно обучать подгруппы последовательному использованию этих инструментов). Хотя в отрасли ведутся споры о том, какие показатели лучше отслеживать, мы рекомендуем отслеживать следующие показатели. Первые четыре известны как стандартные метрики DORA (DevOps Research and Assessment). (Рисунок 30.5):
Частота развертывания - измерение среднего времени между успешными выпусками кода в производство для каждого приложения. Если релизы ограничены бизнес-причинами, то в качестве косвенного показателя можно использовать частоту развертывания до приемочного тестирования (UAT).
Время подготовки к изменениям - время от окончания цикла разработки до развертывания в производстве. Эта метрика показывает, насколько эффективен (и автоматизирован) процесс от момента проверки кода до момента интеграции, тестирования и развертывания нового решения.
