Внедрение процесса управления проблемами: осознанный выбор

Многие компании выстраивают свою систему управления ИТ-процессами постепенно, эволюционно наращивая со временем свои компетенции и повышая уровень зрелости внедренных процессов. Зачастую первыми шагами в построении системы управления ИТ являются мероприятия по внедрению операционных процессов – управления инцидентами и управления запросами на обслуживание. Такой выбор не случаен. Во-первых, внедрение этих процессов приносит максимальную мгновенную выгоду заказчикам и потребителям ИТ-услуг, позволяет сформировать представление о качестве предоставляемых услуг. Во-вторых, поставщики ИТ-услуг упорядочивают с помощью этих процессов работу специалистов, занимающихся непосредственным предоставлением ИТ-услуг.

Вдохновленные успехами руководители ИТ-подразделений приступают к внедрению других процессов, например к внедрению процесса управления проблемами, и неожиданно для себя терпят фиаско!

Процесс управления проблемами отторгается ИТ-специалистами. Неприятие процесса управления проблемами проявляется в следующем.

• Специалисты, ранее прекрасно принявшие процесс управления инцидентами, относятся к проблемам как к инцидентам, не придают значимости работам по диагностике и детальному документированию. В некоторых случаях специалисты вообще игнорируют новый процесс и осуществляют все мероприятия по расследованию и устранению корневых причин инцидентов исключительно в рамках процесса управления инцидентами.
• Специалисты не понимают значимости и назначения нового процесса и дистанцируются от участия в процессе. Выявление и регистрация проблемы не может быть вменена жесткими регламентами. Регистрация проблемы осуществляется и рассматривается исключительно как внутренняя активность поставщика ИТ-услуг без возникновения инициирующего запроса со стороны заказчиков и потребителей услуг;
• Процесс кажется важным только руководителям, инициировавшим внедрение.

Процесс управления проблемами является одним из классических операционных процессов библиотеки ITIL. Процесс направлен на идентификацию и устранение проблем, которые являются причинами возникновения инцидентов в инфраструктуре, участвующей в оказании ИТ-услуг. Существенное отличие этого процесса от процесса управления инцидентами заключается в природе его триггеров. В большинстве случаев триггерами процесса управления инцидентами являются зарегистрированные обращения пользователей или отфильтрованные специальным образом события систем мониторинга. Эти триггеры практически никогда не инициируются персоналом профильных ИТ-подразделений. Триггером процесса управления проблемами является внутренняя потребность ИТ-персонала в уменьшении числа обрабатываемых инцидентов, выраженная либо в регистрации «точек боли», их диагностике, локализации и организации мер по предотвращению их появления, либо в превентивных работах по предотвращению инцидентов. В соответствии с каноническим подходом к процессу он берет свое начало в ИТ-службе, выполняется силами ИТ-службы и завершается там же. За метрики и менеджмент этого операционного процесса тоже отвечает ИТ-департамент.

В чем состоят основные сложности внедрения процесса управления проблемами? Почему внедрение затягивается или не дает значительных результатов? Почему качественно спроектированный процесс не работает эффективно даже при надлежащем обучении участников процесса и достаточной административной поддержке?

Выявление ключевых заинтересованных лиц

Одну из ключевых сложностей и ошибок можно описать довольно просто: руководители, ратующие за применение сервисного подхода к управлению ИТ и его пропагандирующие, увлеклись модной «механикой» процессов из фреймворков и проигнорировали саму суть этого подхода. Классическое определение услуги выделяет двух участников отношений: заказчик услуги и её поставщик. В ходе подготовки к внедрению процесса управления проблемами были неверно определены его заинтересованные лица. Главная сложность внедрения состоит в том, что зачастую в роли владельца и заказчика процесса выступает руководитель ИТ-службы, который позиционирует такой процесс исключительно как внутренний для ИТ.

Однако это не так, управление проблемами не является полностью внутренним процессом ИТ-блока организации.

Когда мы говорим о предоставлении услуг, мы не должны забывать о заказчиках этих услуг. Именно они в первую очередь заинтересованы в их качестве. Назначение процесса управления проблемами состоит именно в улучшении качества предоставляемых услуг путем минимизации числа возникающих инцидентов и ущерба от них.

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

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

Перечислим наиболее частые бизнес-требования, генерирующие спрос на процесс управления проблемами и его результаты.

• Обеспечение достаточного уровня ИТ-услуг, поддерживающих основные бизнес-процессы компании.
• Минимизация или недопустимость остановок бизнес-процессов организации и поддерживающих их ИТ-услуг для обеспечения непрерывности бизнеса.
• Уменьшение доли неэффективных эксплуатационных затрат ИТ-бюджета в средне- и долгосрочной перспективе.

Качественная идентификация лиц, заинтересованных в результатах процесса, и привлечение их к внедрению и улучшению процесса управления проблемами, имеют большое значение. Такие заинтересованные сотрудники вместе с руководителем ИТ-блока выступают в руководящей роли: будучи информированными о результатах, достижениях и эффективности процесса, они совокупно определяют приоритеты развития процесса управления проблемами, оценивают его.

Такое взаимодействие с заинтересованными лицами решает сразу несколько задач.

• Регулярное информирование демонстрирует заинтересованность поставщика ИТ-услуг в повышении качества предоставляемых услуг. Показывает, что поставщик не только занимается устранением инцидентов, а целенаправленно уменьшает их количество и среднее время их разрешения, инвестируя в это свои ресурсы.
• Периодически запрашиваемая обратная связь, получаемая от заказчиков ИТ-услуг, может и должна быть использована при разработке плана улучшения процесса в рамках мероприятий по непрерывному улучшению услуг. Такая информация является важной внешней оценкой эффективности ИТ-процесса.
• Представляемая информация позволяет обосновывать значимость и стоимость выявления, диагностики и устранения проблем. У заказчиков ИТ-услуг формируется понимание важности для них этого процесса, поддерживается спрос на него.

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

Внедрение процесса управления проблемами – это организационное изменение

Еще одной причиной, осложняющей внедрение процесса управления проблемами, является внутреннее сопротивление изменениям. Внедрение любого процесса управления в организации – это организационное изменение. Изменение, происходящее в первую очередь в головах людей, меняющее шаблоны их поведения, схемы ответственности и взаимоотношений. Сопротивление персонала внедрению процесса управления проблемами может быть достаточно сильным и выражаться в виде следующих факторов:

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

В мировой практике есть множество подходов и методик для успешного проведения организационных изменений. Одним из таких подходов является модель организационных изменений Курта Левина, которая предполагает выполнение трех последовательных этапов.

1. «Размораживание» — этап, на котором все участники и заинтересованные лица должны ощутить и признать необходимость изменений.
2. «Движение» — этап непосредственного осуществления изменения.
3. «Замораживание» — этап, на котором закрепляются полученные результаты и непосредственно приобретаются целевые выгоды выполненного изменения.

Для внедрения процесса управления проблемами все эти этапы очень важны. Зачастую события и мероприятия второго и третьего этапа детально описываются в плане проектных работ по внедрению процесса и передаче его в промышленную эксплуатацию. Мероприятиям первого этапа организационного изменения редко уделяют достаточное внимание, поэтому организация может не достичь состояния готовности к внедрению процесса управления проблемами.

На этапе подготовки к внедрению процесса («размораживание») очень важно сформировать ясное понимание необходимости скорейшего разрешения сложившейся ситуации с количеством и качеством инцидентов. Число приверженцев идеи полезности внедрения процесса управления проблемами должно быть доведено до максимума.

Для формирования у сотрудников правильно видения процесса, их эффективного вовлечения и мотивации к участию в процессе можно рекомендовать следующее.

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

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

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

В противном случае даже назначение «идеального» менеджера процесса управления проблемами может быть недостаточным для качественного внедрения и последующей эффективной эксплуатации процесса, так как участники процесса будут отторгать или игнорировать его, не признавать его важность для организации.

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

Заключение

Резюмируя вышесказанное, можно сделать следующие выводы:

1. Процесс управления проблемами не является внутренним для поставщика ИТ-услуг. Для процесса управления проблемами должны быть определены его целевые потребители, генерирующие постоянный спрос на результаты процесса. Эти люди должны как минимум быть проинформированы о качестве исполнения процесса и его результатах.
2. Не всегда процесс управления проблемами воспринимается столь же необходимым, как и процесс управления инцидентами. Перед внедрением необходимо провести ряд подготовительных мероприятий по распространению понимания его ценности, формированию спроса на процесс.
3. Попытки внедрить процесс управления проблемами с формальным отношением к определению и вовлечению заинтересованных лиц имеют значительный риск оказаться нежизнеспособными и невостребованными, даже при высочайшем качестве реализации остальных компонентов процесса и проведенных во время внедрения мероприятий.

Автор: Андрей Труфанов