Суммируя соображения в предыдущих двух частях (первая, вторая), я прихожу к матричному представлению четырех процессов проектирования услуг:

В каждой ячейке таблицы – «модель» деятельности (ну как в ITIL модель изменений, например):

• Ответственный (это могут быть разные люди: ответственный за классификацию – аналитик, ответственный за разработку – инженер и т.д.)
• Шаги и методика выполнения (ясно, что они будут очень различаться для безопасности и доступности)
• Ресурсы (инструменты моделирования, расчетов, мониторинга и т.д.)
• Эскалация (то есть механизмы передачи решения «наверх» в случае конфликта ресурсов или отклонения от плановых значений)

Ключевым здесь является лишь синхронное выполнение всех пяти видов деятельности управления рисками. Количество строчек может варьироваться.

А теперь ход конем.

На эту таблицу наложим и третье измерение – ИТ-услуги. Простите скромные возможности рисования:

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

Вот так, мне кажется, удобно и уж точно более структурно, чем в ITIL, можно представлять себе проектирование или доставку (delivery) услуг.

Я раньше заявлял нулевую прикладную ценность модели, но всё же можно сформулировать простые и очевидные правила, делая «плоские срезы» в каждой паре измерений:

1. На этапе проектирования управление услугами означает обязательный контроль над проработкой четырех параметров качества.
2. Выходом каждого процесса является ожидаемое значение одноименного параметра качества для всех услуг сразу. Это мне кажется крайне важным.
3. Этапы управления рисками в реальной организации будут работать только при вовлечении всех заинтересованных лиц. Например, выявление рисков может сработать, только если к нему привлечены все владельцы услуг и все менеджеры параметров качества, с очевидными конфликтами как внутри контуров управления, так и между ними.

А еще у этого кубика есть и четвертое измерение – компоненты услуги: АО, ПО, сеть, люди и тому подобные технические мелочи. Но нарисовать это, к счастью, не представляется возможным.

В комментарии призывается идеолог этой модели, Роман Журавлев, для уточнений и корректировок.

ОБУЧЕНИЕ

IT Service Management

Учебные курсы от соавторов ITIL 4