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

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

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

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

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

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

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

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

  • old fuddy-duddy

    А нужно ли PIR вообще?! В умных книжках пишут, что такая оценка нужна для ответа на следующие основные вопросы:
    • Привело ли изменение к достижению намеченной цели?
    • Удовлетворены ли пользователи результатом?
    Но по логике (моей) эти вопросы должны задаваться там, откуда пришел запрос на изменение. Например, если при расследовании проблемы с неким ПО пришли к заключению что решением проблемы является увеличение объема оперативки на сервере и инициировали соответствующий RFC, то не вина изменения (успешно реализованного), что с его помощью так и не удалось решить проблему (это проверяется в процессе управления проблемами).
    Если под PIR понимать просто тестирование изменения, то смысла в выделении его в отдельный этап процесса тоже нет, так как тестирование это лишь задачи по изменению.

  • Максим

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

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

    • Тогда в чем заключается PIR – кто-то собирается и обсуждает, что и почему было плохо? Кто собирается? Кто отвечает за инициацию этого сбора? Почему ему это выгодно или почему он не может обойти эту процедуру?

      • Максим

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

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

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

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

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

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

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

          • Максим

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

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

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

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

              • Максим

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • andys

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

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

    • Изменения на КСПД “пирят” все ответственные за услуги? И кто такой Менеджер Услуг в организации, о которой Вы говорите? И почему с больших букв – это имя и фамилия? 😉

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM