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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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

Андрей Труфанов (info@omniway.ru) — консультант по управлению ИТ, OmniWay (Москва).