Недавно заново для себя открыл структуру описания фактора влияния из COBIT 5[1]. У каждого фактора влияния заданы универсальные атрибуты. Вот они:

Источник: COBIT 5: Бизнес-модель по руководству и управлению ИТ на предприятии

Причем, не важно речь о процессе, услуге или, скажем, информации, набор атрибутов не изменится. Утверждается, что единая структура позволяет:

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

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

Возьмем в качестве примера всем знакомый процесс управления изменениями.

Заинтересованные стороны

Кто является заинтересованными сторонами (ЗС) процесса управления изменениями?

• Руководители разных уровней вплоть до совета директоров: неспособность ИТ поддержать развитие бизнеса может привести потере конкурентных преимуществ и недополученной прибыли.
• Сервис-менеджеры, которые отвечают за качество услуги, которому угрожает каждое изменение.
• Менеджеры и участники других процессов, обменивающиеся информацией с процессом управления изменениями,– в первую очередь, управление релизами, управление конфигурациями, управление инцидентами.
• …

Заинтересованные стороны бывают внешние и внутренние, их интересы транслируются в бизнес-цели, затем в ИТ-цели и, наконец, в цели процесса. 

Цели

Список целей всех процессов и соответствующих им метрик сформулирован в публикации COBIT 5 Enabling Processes, но, к сожалению, без разнесения на прямое и контекстуальное качество, а здесь, на мой взгляд, есть интересные детали. 

• Прямое качество – дает ли процесс необходимые результаты? Исходя из назначения (из ITIL или COBIT), процесс управление изменениями должен обеспечивать контроль изменений таким образом, чтобы достигалась польза (от изменений) и минимизировалось негативное влияние (от изменений). Метрики, отражающие прямое качество процесса, в «Руководстве по измерению» и в ITIL Practitioner Guidance названы метриками результативности. Это – своевременность реализации изменений; доля изменений, приведших к значительным/повторяющимся инцидентам; удовлетворенность потребителей услуг качеством реализации изменений. Так как назначение процесса универсально, не слишком изменчив и набор метрик, которые должны подтверждать, что оно (назначение) реализуется. Это прямое качество.
• Контекстуальное качество – адаптирован ли процесс к условиям организации? Насколько рационально он организован? Какой ценой достигаются необходимые результаты? Доля стандартных изменений; доля экстренных изменений; доля изменений, которые реализуются с первого раза; доля изменений, проходящих через CAB; доля изменений, проходящих через PIR – все это метрики рациональности, отражающие то, как организован процесс. В отличие от качества прямого цели и соответствующие им метрики по качеству контекстуальному довольно специфичны для организации, и зависят в первую очередь от зрелости системы менеджмента.
• Доступность (здесь «accessibility») и конфиденциальность – все, кому положено, должны иметь доступ к документации и записям по процессу, системе автоматизации; для остальных – доступ должен быть ограничен/закрыт. Учитывая корни COBIT и исторически сильный крен в сторону аудита, пункт специфичный (видится, что его можно отнести к контекстуальному качеству), но понятный и важный.

Хорошие практики

Хорошие практики – набор задач, факторов успеха, достижение которых необходимо для реализации назначения процесса. Список хороших практик можно взять из любой общедоступной референтной модели (COBIT, ITIL, ISO20000), или построить свою.

Список ключевых практик BAI06 Manage Changes в COBIT 5 такой:

• Оценка, определение приоритетов, авторизация запросов на изменения
• Управление экстренными изменениями
• Отслеживание статуса изменения и предоставление отчетности
• Документирование и закрытие изменений

И вот у нас появляются метрики соответствия внешним или внутренним требованиям: наличие/отсутствие/полнота реализации набора практик из референтной модели.

Жизненный цикл

В COBIT5 приведен такой перечень состояний жизненного цикла процесса: планирование, приобретение, построение/приобретение/создание/внедрение, использование/эксплуатация, оценка/мониторинг, обновление/утилизация. Думаю, этот список можно упростить без потери смысла до PDCA, за которым будут скрываться такие дела, как:

• Постановка целей процесса
• Создание/обновление плана процесса
• Проведение измерений и подготовка отчетности
• Проведение встреч по оценке процесса
• Планирование совершенствования процесса
• …

Все те дела, благодаря которым процесс будет приносить пользу не только сейчас, но и в будущем. В отличие от хороших практик, которые специфичны для каждого процесса, задачи по управлению жизненным циклом универсальны. Полнота реализации цикла Деминга фактически свидетельствует о том, на каком уровне зрелости пребывает процесс – именно это проверяется в таких подходах, как CMMI-SVC и (основанных на ISO15504) COBIT PAM и TIPA (с уровня 2 и выше).

Получается очень компактная и емкая картинка с правильными и важными акцентами:

PDF, кликабельно

1. Явно указана необходимость определить заинтересованных сторон (о чем нередко забывают, считая ответ очевидным), а, следовательно, приобрести понимание, чьи требования должны быть учтены при проектировании процесса, или, например, кто нуждается в отчетности о работе процесса.
2. Есть разделение на прямое и контекстуальное качество. Для процесса прямым качеством является соответствие назначению, косвенным – рациональность его организации. Понятия нередко смешивают, расставляя неверные акценты в системе измерений.
3. Есть явное разнесение на хорошие практики процесса и управление жизненным циклом процесса – это важно и с точки зрения разработки регламента процесса, и с точки зрения «подключения» референтных моделей, и с точки зрения понимания, что является предметом разнообразных оценок и аудитов.
4. Четыре вопроса в нижнем блоке определяют четыре взгляда на процесс, каждому из которых может соответствовать свой набор метрик.

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом