Портал №1 по управлению цифровыми
и информационными технологиями

Что и зачем можно измерять в системе управления ИТ

У меня сложилась простая, полная и непротиворечивая картина мира. Опять. На этот раз – мира оценки процессов. Посмотрим, сколько продержится. Вот она.

Оценка процессов выполняется для того, чтобы получить представление либо о потенциале процессов (что они могут), либо о фактической успешности (что они смогли). 

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

Оценку Capability и Maturity можно выполнять методами диагностики и/или аудита. Основная аудитория такой оценки – руководители ИТ и представители заказчиков, т.е. те, кому важно быть уверенными в дееспособности ИТ-службы в условиях постоянного изменения требований и вообще среды. 

Фактическая успешность оценивается также в двух направлениях, вполне традиционных: результативности и рациональности (effectiveness и efficiency соответственно). Первое позволяет оценить степень выполнения поставленных перед процессом целей (не путать с назначением – соответствие назначению меряется через оценку capability). Второе – стоимость достижения целей в терминах расхода ресурсов и числа ошибок. 

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

 

Оценка capability и effectiveness дает ответ на вопросы типа "что?": "что процесс может?" и "что процесс сделал?"

Оценка maturity и efficiency – ответы на вопросы типа "как?": "Как процесс управляется?" и "Как он поработал?"

Вот. Такая структура помогает ответить на множество модных вопросов: кому, что и зачем оценивать? Откуда брать критерии оценки? Чем cpability отличается от maturity? для чего применять ISO20000, для чего – COBIT и т.п.?

Критика и комментарии – приветствуются. 

Комментариев: 15

  • Leonid

    «Это уму не растяжимо» (с)
    А можно на примере, ну скажем процесса управления конфигурациями, показать как «Такая структура помогает ответить на множество модных вопросов: кому, что и зачем оценивать? Откуда брать критерии оценки? Чем cpability отличается от maturity? для чего применять ISO20000, для чего — COBIT и т.п.»?

  • Мне, как человеку с глубоко техническим образованием, а потому с загнутым в сторону систематизации подходом к описанию реальности, – мне картинка понравилась.

    Красиво, системно, изъянов не видно.

    Осталось придумать аббревиатуру – IDEal, CMMI, COBIT уже заняты, но что-то хорошее ещё наверняка осталось.

  • Анатолий Павлюченко

    Я бы немного переформулировал Success и Realized. Например, в Result и Achieved. Это расширяет модель для работы с результатами, которые выходят за рамки ожидаемых. Т.е. позволяет учитывать как недостигнутые, так перевыполненные результаты.

    • Да, действительно, так точнее. Спасибо!

      А вместо Capability и Maturity надо написать Utility и Warranty. Процессов, конечно.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM