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

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

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

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

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

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

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

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

 

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

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

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

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

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 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