Об измерении вреда

Сегодня мы закончили пилотное чтение нового курса. Новый курс называется «Оценка процессов управления ИТ», и условно его можно разделить на две части: «Оценка процессов снаружи» и «Оценка процессов внутри». Первая часть — про оценку дизайна ИТ-процессов, состава реализованных практик и организации управления, контроля и совершенствования: ISO 15504, COBIT PAM, TIPA и наши собственные инструменты для диагностики процессов. А вторая — про метрики и показатели, используемые для управления: показатели результативности, рациональности/эффективности и другие доступные менеджерам различного уровня линейки и градусники. В пилоте участвовали слушатели, искренне интересующиеся темой оценки процессов и отлично подготовленные, поэтому вести курс было непросто, но чрезвычайно интересно.

Пользуясь случаем, благодарю всех, кто был с нами эти два дня, за внимание, интересные вопросы, дельные комментарии и полезные рекомендации по улучшению материалов и программы тренинга. Спасибо вам! 


И про курс, и про оценку процессов я еще непременно напишу подробно, а пока предлагаю читателям задачку, решение которой мы сегодня искали и обсуждали долго, громко и весело:

Считается, что процесс управления изменениями должен минимизировать негативное влияние изменений на работу услуг в среде эксплуатации и в конечном счёте на бизнес. Интересно было бы это негативное влияние измерять, оценивать и снижать. Так вот, вопрос в том, как измерять. 

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

В первом случае вполне реально выделить инциденты, случившиеся в результате некорректно организованных работ по внедрению изменений, и оценить их негативное влияние на бизнес. А вот второй случай — сложнее: связать инциденты, ставшие следствием когда-то (вчера или полгода назад) проведённых изменений, с этими изменениями — давно закрытыми и, весьма вероятно, признанными успешными, — не так-то просто. Процесс управления проблемами может выявлять такие связи, но нет уверенности ни в полноте такого выявления, ни в том, что струдники, выполняющие диагностику проблем, захотят фиксировать обнаруженную связь. Процесс управления инцидентами не занимается расследованием причин нарушений в работе услуг и обычно не имеет инструментов связи инцидентов с их источниками. В самом процессе управления изменениями анализ отложенного негативного вляиния изменений обычно не проводится.

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

Итак, вопросы к практикующим менеджерам изменений/релизов и теоретикам управления услугами: 

Как оценивать негативное влияние проведённых изменений на бизнес, в особенности — отложенное негативное влияние?

Что и как для этого можно/нужно измерять?

Спасибо за ваши идеи!

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

CleverKPI Сбалансированная система управления информационными технологиями по KPI

Измерение и оценка эффективности ИТ-процессов, проектов и услуг.
 

Узнайте больше!

Комментарии и мнения

  1. Альберт

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

    Если что-то не учли в рамках управления изменениями или начальные условия изменились и сервис не работает так как нужно то оценка делается в рамках управления проблемами.

    Обычно CMDB является связующим звеном. Если это так, то далее уже дело техники как отобразить информацию для лучшего понимания картины. По-хорошему при выборе соответствующего объекта должны быть отображены все связанные изменения, инциденты, проблемы и другие объекты с которыми данный объект связан.

    Упрощено все выглядит так:

    Change-> Incidents-> Problem-> Change

    Change-> Major Incident-> Problem-> Change

    В отношении приложений могут быть более развернутые схемы.

     

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

    Это вопрос культуры и организации процесса.

    1. Илья Рунов

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

      1. Альберт

        Если говорить о триггерах то это обычно стандартные входы для процесса Управления проблемами. Но это только триггеры, после которых начинается детальный анализ. Универсального метода измерения пользы или вреда, тем более в долгосрочной перспективе у нас нет и задачи такой не стоит. Есть задача предотвращения рисков с помощью Управления проблемами и Управления изменениями.

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

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

Empty