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

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

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

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


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

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

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

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

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

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

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

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

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

 

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

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

  • Альберт

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

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

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

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

    Change-> Incidents-> Problem-> Change

    Change-> Major Incident-> Problem-> Change

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

     

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

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

    • Илья Рунов

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

      • Альберт

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;