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

"Попаразитирую" немного, фактически используя блог в качестве форума. Коллеги, поделитесь, пожалуйста, практикой — как у вас (или у ваших заказчиков) организован 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. Дмитрий Исайченко Автор

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

      0
      0
  1. old fuddy-duddy

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

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

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

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

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

    0
    0
  2. Максим

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

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

    0
    0
      1. Максим

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

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

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

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

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

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

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

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

          0
          0
          1. Максим

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

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

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

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

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

              0
              0
              1. Максим

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

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

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

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

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

    Примеры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            0
            0
  4. andys

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

              0
              0

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

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

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

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

ОКТ
23
ОКТ
26
Учебный курс:
Основы DevOps