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

Все чаще на курсах, когда разбираем процесс управления изменениями, слушатели интересуются 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 (может отличаться для разных категорий изменений).
  • Порядком принятия решений и разрешения спорных ситуаций.

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

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

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

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

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

    1. Павел Дёмин Автор

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

      0
      0
      1. Дмитрий Исайченко

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

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

        0
        0
        1. Павел Дёмин Автор

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

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

          0
          0
  1. Павел

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

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

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

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

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

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)