PIR в управлении изменениями

"Попаразитирую" немного, фактически используя блог в качестве форума. Коллеги, поделитесь, пожалуйста, практикой — как у вас (или у ваших заказчиков) организован PIR в управлении изменениями. Как это устроено организационно? Как PIR поддерживает система автоматизации процессов управления услугами? Что в этой практике вам кажется полезной или наоборот — вредно-бесполезным?

Головы здесь порой собираются приличные. У таких и совета не грех попросить 🙂

ITIL ITIL Intermediate: Release Control and Validation

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

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

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

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

      Это мне тоже понятно, только не очень полезно 🙂 Мне интересны детали реализации — как проходит PIR, кто и почему в нем заинтересован, как используются его результаты? По-моему, это очень малоизведанная область, как в открытых публикациях (ITIL, MOF), так и в вендорских моделях (BMC, HP).

  1. old fuddy-duddy

    А нужно ли PIR вообще?! В умных книжках пишут, что такая оценка нужна для ответа на следующие основные вопросы:

    • Привело ли изменение к достижению намеченной цели?

    • Удовлетворены ли пользователи результатом?

    Но по логике (моей) эти вопросы должны задаваться там, откуда пришел запрос на изменение. Например, если при расследовании проблемы с неким ПО пришли к заключению что решением проблемы является увеличение объема оперативки на сервере и инициировали соответствующий RFC, то не вина изменения (успешно реализованного), что с его помощью так и не удалось решить проблему (это проверяется в процессе управления проблемами).

    Если под PIR понимать просто тестирование изменения, то смысла в выделении его в отдельный этап процесса тоже нет, так как тестирование это лишь задачи по изменению.

  2. Максим

    Наверное, я слишком просто подхожу к этому вопросу:

    PIR = “работа над ошибками”. Если изменение прошло согласно планам и не вызвало сбоев, то нет и повода для PIR. Если нет, то PIR становится памятником на могиле изменения – в назидание потомкам (PIR = RIP).

      1. Максим

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

        Если интересно, то конкретный пример того, что я считаю PIRом могу выслать на почту (публикация не желательна).

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

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

          «В любом ИТ (не зависимо от уровня зрелости) есть сотрудник, который отвечает за функционирование конкретной системы. По его инициативе и будет проведен PIR...»

          С другой стороны, он же, скорее всего, будет являться координатором изменений по данной системе. Нет ли в этом риска, что PIR будет порождаться только как способ свалить вину на других?

          «Если интересно, то конкретный пример того, что я считаю PIRом могу выслать на почту (публикация не желательна).»

          Интересно. Обещаю не публиковать никаких цитат и выдержек, но хочу попросить разрешения использовать в обсуждении те идеи, которые содержатся в Вашем примере. Без имен, фамилий и прочей конкретики. Можно?

          1. Максим

            «С другой стороны, он же, скорее всего, будет являться координатором изменений по данной системе. Нет ли в этом риска, что PIR будет порождаться только как способ свалить вину на других?»

            Тут мне кажется важным переводить PIR из плоскости поиска виноватых, в плоскость поиска причин сбоев/нарушений планов и способов их устранения.

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

              Максим, посмотрел на присланный Вами материал, спасибо. Если это — работа менеджера по изменению, заочно жму ему руку. Здорово. Уважаю.

              И все-таки уточню: кто инициатор этого PIR'а и как процесс управления изменениями гарантирует, что этот PIR действительно будет проведен?

              1. Максим

                Инициатором был функциональный руководитель. В его зоне ответственности находится система, изменение которой прошло не так, как планировалось.

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

  3. Александр Жилинский

    В комментариях слишком узко подходим к сути PIR.

    PIR может быть использован неожиданно.

    Примеры.

    В одной компании основной вариант использования — ответ на вопрос, а было ли (за приличный срок) востребовано изменение.

    В одной компании туда отлично встроена деятельность QA самого оформления изменения (формальный контроль качества, в основном для будущих аудитов).

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

      «В комментариях слишком узко подходим к сути PIR.»

      Согласен. Расширь нас, пожалуйста 🙂

      «В одной компании основной вариант использования — ответ на вопрос, а было ли (за приличный срок) востребовано изменение.»

      Интересный пример. А зачем проводится такой PIR? На что влияет ответ на этот вопрос? И какие изменения проходят через такой PIR?

      «В одной компании туда отлично встроена деятельность QA самого оформления изменения»

      Опять же вопрос — кто выполняет? Мое мнение, PIR — это привлечение к оценке изменения какой-то группы людей — инициатора изменения, членов CAB и так далее. Что касается проверки оформления, то по идее это — прямая обязанность менеджера процесса, т.е. по моей логике эти действия не требуют проведения PIR.

      1. Александр Жилинский

        Да я просто примеры привожу.

        В первом — потому что куча дорогих неиспользуемых изменений. Во втором — потому что куча ошибок в оформлении (могут вылезти на аудите).

        А если в общем, у меня мнение по PIR всегда отличалось от itil, с самого начала. Просто не самая критичная процедура, поэтому лень подробно расписывать. Сейчас доступ восстановлю к блогу, попробую написать подробнее.

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

          «Просто не самая критичная процедура, поэтому лень подробно расписывать»

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

          1. Александр Жилинский

            Да я именно об этом.

            У меня пока трудноформализуемые проблемы с блогом 🙂 Так что временно пишу тут.

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

            А слова, попавшие под комментарий — просто в моем наборе проектов это обычно не самая критичная процедура, оценка важнее, сложнее и чаще «ломается».

  4. andys

    Если совсем про практику, то, например, сейчас так: инициатору и заказчику изменения вместе с оповещением о его проведении приходит предложение прислать оценку (текстом). Эта информация ложится в запрос и анализируется менеджером изменения. Отдельно существует интегральная оценка запроса, которая складывается из ряда факторов — качество подготовки, соблюдение различных сроков при подготовке и проведении, доступные признаки успешности/неуспешности и считается автоматически. Еще есть жесткий способ — фаза согласования после проведения, где подтверждение качества запрашивается обязательно у соответствующих согласующих (стандартный функционал известной ITSM системы). По всем этим параметрам — [пока только планируется] система отчетности. А насчет существующих сложностей с оценкой качества проведения и величины негативных последствий соглашусь с тобой. Не получилось пока мотивировать инженеров групп поддержки привязывать инциденты, возникшие вследствие неудачного изменения, к изменению, которое выполнили/подготовили эти же инженеры... Но у нас уже есть альтернативные задумки на этот счет.

  5. Лялеко Владимир

    Ещё из примеров:

    Оценку результатов выполнения RFC осуществляет Менеджер Услуг или другой участник процесса отвечающий за затронутую услугу(Ведь все RFC связаны с какой либо услугой? Или нет ?:) ). С точки зрения системы автоматизации, это отдельное уведомление \ анкета. В дальнейшем результаты подобного «Анкетирования» аккумулируются и являются частью материалов для SIP.

    Соответственно анализ PIRов, ещё один инструмент для инициации улучшений.

      1. Лялеко Владимир

        Менеджер услуги — сотрудник ИТ, ответственный за качество предоставления ИТ-услуги и являющийся единым контактным лицом от ИТ по данной услуге. КСПД такая-же инфраструктурная услуга, как и любая другая со своим менеджером или несколькими менеджерами (Тема подобных «КЭ» уже обсуждалась: www.realitsm.ru/2011/02/k...icy-kotoryx-net/). Вот как то... так...

        Почему с большой? Вообще вопрос меня в тупик поставил 🙂 Наверно заразился описанием ролевых моделей на английском, там все роли так расписаны Service Owner, Service Level Manager и т.д. 🙂

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

          «КСПД такая-же инфраструктурная услуга, как и любая другая со своим менеджером или несколькими менеджерами»

          Та-а-ак, интересно. Т.е. если с точки зрения сетевиков, проводящих PIR, работы проведены в срок и технически корректно, то изменение — ОК (ничего для SIP копить не надо). Если при этом по какой-то причине отрубились несколько приложений, то это ничего? Нормально? Как быть с влиянием на смежников?

          Кроме того, «ответственные за инфраструктурную услугу КСПД» скорее всего и будут организовывать проведение соответствующего изменения. Опять (уже в который раз) возвращаемся к вопросу: почему системно процесс управления изменениями не разводит ответственность за организацию изменения и проведение PIR'а?

          1. Лялеко Владимир

            Как быть с влиянием на смежников?

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

            работы проведены в срок и технически корректно, то изменение — ОК (ничего для SIP копить не надо).

            Положительные «Пиры» копить надо, причём обязательно. Так как эти отчёты сопостовляются с аналитикой от системы мониторинга из которой определяются качественные показатели состояния той или иной услуги. Участники SIP получаются материал для анализа из которого можно определить, когда люди «недоговаривают» 🙂

            почему системно процесс управления изменениями не разводит ответственность за организацию изменения и проведение PIR'а?

            Считаю, разводить ответственность в данном случае не целесообразно.

            Техническую корректность изменения сможет оценить, только специалист той же узкой специализации, фактически из той же группы.

            Просто в этой группе нужно найти специалиста, готового расти за «рамки». Дать ему полномочия рулить вопросом на уровне смежных услуг (контролировать влияние) и привилегию учавствовать в SIP.

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

              «Считаю, разводить ответственность в данном случае не целесообразно.»

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

              Но точку зрения понял, спасибо.

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

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

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

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

ИЮЛ
3
Учебный курс:
Основы ITIL (очно)