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

Что включать в отчет о PIR?

Опубликовано 15 февраля 2015
Рубрики: Управление изменениями
Комментарии

Все чаще на курсах, когда разбираем процесс управления изменениями, слушатели интересуются Post-Implementation Review в целом и форматом отчета с итогами оценки в частности. На основании рекомендаций ITIL, открытых источников и проектного опыта видится приблизительно следующая картина:

1. Введение

1.1 Состав группы оценщиков

1.2 Охват и критерии оценки

2. Результаты оценки

2.1 Достижение целей, стоявших перед изменением (например, сократить затраты на обслуживание, сократить ресурсные или временные затраты на те или иные операции, предоставить новую функциональность, повысить производительность, сократить количество инцидентов, повысить безопасность и т.д.)

Цель

Что было

Что хотелось

Что получилось

Отметка о достижении

2.2 Параметры качества (если целью изменения было воздействие на уровни услуги, например, в рамках реализации инициатив SIP, то пункт стоит объединить с предыдущим)

Параметр качества

Целевое значение (согласно

До изменения

После изменения

Заключение

2.3 Затраты

Статья расходов

Плановое значение

Фактическое значение

Причины отклонения 

(если применимо)

2.4 Сроки

Веха/этап

Плановая дата завершения

Фактическая дата завершения

Причины отклонения 

(если применимо)

2.5 Связанные проблемы, риски и т.д. (особенно если изменение было инициировано с целью структурного решения проблемы или внедрения контроля в рамках реализации плана снижения рисков)

2.6 Побочные эффекты (возникшие по ходу и в результате проведения изменения)

2.7 Результаты опроса заказчиков и пользователей (удовлетворенность, соответствие ожиданиям)

3. Выводы

3.1 Заключение об успешности изменения

3.2 Рекомендации

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

  • Критериями изменений, в отношении которых будет осуществляться оценка. Граница может проходить по конкретным категориям изменений и/или по степени влияния изменения на бизнес.
  • Порядком определения состава оценщиков и их привлечения к PIR (может отличаться для разных категорий изменений).
  • Порядком принятия решений и разрешения спорных ситуаций.

Коллеги, поделитесь собственным взглядом на вопрос и практическим опытом. Что лишнее? Чего не хватает? Какие подводные камни?

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

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

  • Мария

    Спасибо за статью. Применю полученные знания при разработки процедуры PIR

  • Сколько же времени будет занимать проведение такого PIR'а? И, как следствие, для какой части изменений его удастся провести?

    • В полном объеме такой шаблон применим только для крупных изменений, согласен (наверное, никак не больше 3-5%). Для изменений не столь масштабных, но которые также хочется оценивать, список можно ограничить самым важным. Самое важное, полагаю, будет отличаться в зависимости от целей изменения.

      • В полном объеме такой шаблон применим только для крупных изменений

        Вот. Мне тоже кажется, что это больше походит на lessons learned по проектам. Причём, тоже не по всем 100%. Для изменений отчёт надо упрощать. Да и нужен ли отчёт как таковой? Заключения менеджера процесса в соотв. поле RFC по итогам обработки отзывов заинтересованных лиц не достаточно?

        • поле RFC по итогам обработки отзывов заинтересованных лиц не достаточно?

          В каких-то случаях — вполне. Тогда пункты в разделе 2 послужат дополнительным чеклистом, на что еще менеджеру можно обратить внимание. А стоит ли обращать — решит по факту конкретного изменения.

  • Павел

    Мне кажется, важны пункты PIRа те, которые мы сможем затем использовать. Например:

    – Риски, которые мы предотвратили внедрением, по возможности оценить потери при наступлени риска;

    – Что мы улучшили и на сколько, включая нематериальные бенефиты;

    – Что мы сэкономили (персонал, увеличение производительности, и т.д.) и сколько.

    Важно при этом все эти выводы складировать куда-то в ИС с целью получения отчётов в интересующих нас разрезах. Это сильно может пригодиться для обоснования ценности ИТ, её численности, важности процессов, связанных с изменениями (чтобы бизнес больше доверял и не тотально контролировал и т.д.) и прочие метрики, которые нас как ИТ интересуют в первую очередь для борьбы за комфортное существование 🙂


Добавить комментарий для Павел ДёминОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM