"Попаразитирую" немного, фактически используя блог в качестве форума. Коллеги, поделитесь, пожалуйста, практикой – как у вас (или у ваших заказчиков) организован PIR в управлении изменениями. Как это устроено организационно? Как PIR поддерживает система автоматизации процессов управления услугами? Что в этой практике вам кажется полезной или наоборот – вредно-бесполезным?
Головы здесь порой собираются приличные. У таких и совета не грех попросить 🙂
Это мне тоже понятно, только не очень полезно 🙂 Мне интересны детали реализации – как проходит PIR, кто и почему в нем заинтересован, как используются его результаты? По-моему, это очень малоизведанная область, как в открытых публикациях (ITIL, MOF), так и в вендорских моделях (BMC, HP).
А нужно ли 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.
А слова, попавшие под комментарий – просто в моем наборе проектов это обычно не самая критичная процедура, оценка важнее, сложнее и чаще “ломается”.
Если совсем про практику, то, например, сейчас так: инициатору и заказчику изменения вместе с оповещением о его проведении приходит предложение прислать оценку (текстом). Эта информация ложится в запрос и анализируется менеджером изменения. Отдельно существует интегральная оценка запроса, которая складывается из ряда факторов – качество подготовки, соблюдение различных сроков при подготовке и проведении, доступные признаки успешности/неуспешности и считается автоматически. Еще есть жесткий способ – фаза согласования после проведения, где подтверждение качества запрашивается обязательно у соответствующих согласующих (стандартный функционал известной 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’а.
Но точку зрения понял, спасибо.
Основная идея, которой можно придерживаться: PIR полезен, если без фанатизма.
В некоторых случаях достаточно принимать и контролировать результаты выполнения каждого шага реализации изменения.