Сегодня мы закончили пилотное чтение нового курса. Новый курс называется “Оценка процессов управления ИТ”, и условно его можно разделить на две части: “Оценка процессов снаружи” и “Оценка процессов внутри”. Первая часть – про оценку дизайна ИТ-процессов, состава реализованных практик и организации управления, контроля и совершенствования: ISO 15504, COBIT PAM, TIPA и наши собственные инструменты для диагностики процессов. А вторая – про метрики и показатели, используемые для управления: показатели результативности, рациональности/эффективности и другие доступные менеджерам различного уровня линейки и градусники. В пилоте участвовали слушатели, искренне интересующиеся темой оценки процессов и отлично подготовленные, поэтому вести курс было непросто, но чрезвычайно интересно.
Пользуясь случаем, благодарю всех, кто был с нами эти два дня, за внимание, интересные вопросы, дельные комментарии и полезные рекомендации по улучшению материалов и программы тренинга. Спасибо вам!
И про курс, и про оценку процессов я еще непременно напишу подробно, а пока предлагаю читателям задачку, решение которой мы сегодня искали и обсуждали долго, громко и весело:
Считается, что процесс управления изменениями должен минимизировать негативное влияние изменений на работу услуг в среде эксплуатации и в конечном счёте на бизнес. Интересно было бы это негативное влияние измерять, оценивать и снижать. Так вот, вопрос в том, как измерять.
Очевидно, что вред от изменений можно измерять разный: от проводимых изменений (мы так организовали работы, что они привели к инцидентам) и от проведённых изменений (мы так изменили инфраструктуру, что она когда-то сломается).
В первом случае вполне реально выделить инциденты, случившиеся в результате некорректно организованных работ по внедрению изменений, и оценить их негативное влияние на бизнес. А вот второй случай – сложнее: связать инциденты, ставшие следствием когда-то (вчера или полгода назад) проведённых изменений, с этими изменениями – давно закрытыми и, весьма вероятно, признанными успешными, – не так-то просто. Процесс управления проблемами может выявлять такие связи, но нет уверенности ни в полноте такого выявления, ни в том, что струдники, выполняющие диагностику проблем, захотят фиксировать обнаруженную связь. Процесс управления инцидентами не занимается расследованием причин нарушений в работе услуг и обычно не имеет инструментов связи инцидентов с их источниками. В самом процессе управления изменениями анализ отложенного негативного вляиния изменений обычно не проводится.
В то же время обеспечение безвредности проводимых изменений – задача, которую трудно считать второстепенной. Повторюсь, измерять и оценивать вред от изменений очень бы хотелось.
Итак, вопросы к практикующим менеджерам изменений/релизов и теоретикам управления услугами:
Как оценивать негативное влияние проведённых изменений на бизнес, в особенности – отложенное негативное влияние?
Что и как для этого можно/нужно измерять?
Спасибо за ваши идеи!
Влияние и риски оценивать лучше до внедрения изменений. Так же следует учитывать влияние и риски от невнедрения изменений. По результатам анализа принимать решение о необходимости внедрения изменений. Все это в рамках управления изменениями. (извиняюсь за тафтологию)
Если что-то не учли в рамках управления изменениями или начальные условия изменились и сервис не работает так как нужно то оценка делается в рамках управления проблемами.
Обычно CMDB является связующим звеном. Если это так, то далее уже дело техники как отобразить информацию для лучшего понимания картины. По-хорошему при выборе соответствующего объекта должны быть отображены все связанные изменения, инциденты, проблемы и другие объекты с которыми данный объект связан.
Упрощено все выглядит так:
Change-> Incidents-> Problem-> Change
Change-> Major Incident-> Problem-> Change
В отношении приложений могут быть более развернутые схемы.
Это вопрос культуры и организации процесса.