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

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

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

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

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

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

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

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

 

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

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

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

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

  • Leonid

    «Это уму не растяжимо» ©

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

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

      Хорошо?

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

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

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

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

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

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

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


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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT