Управления инцидентами в ITIL

Как известно, большинство ИТ служб, начинающих применять рекомендации ITIL® и других подобных источников для управления ИТ сервисами, первым делом систематизируют именно деятельность по поддержке – как будто сервисов, а чаще все же пользователей. Организация службы поддержки и организация процесса управления инцидентами обещают пользователям, заказчикам и руководству ИТ службы так называемые «быстрые победы». Если через несколько месяцев посмотреть на полученные на практике выгоды и преимущества, может случиться разочарование разной степени тяжести – и известны случаи, когда это разочарование распространялось на всю систему управления ИТ сервисами, на ITSM как идею и на ITIL® как источник знаний.

Какие же преимущества от работы процесса управления инцидентами обещает ITIL®, и что надо знать, чтобы не обмануться в связанных с ними ожиданиях?

Что написано в ITIL®

В ITIL® второй версии приводится следующий список преимуществ, даруемых процессом управления инцидентами:

Для бизнеса в целом:

• Снижение негативного влияния инцидентов благодаря их своевременному разрешению, как следствие – повышение результативности
• Проактивное определение возможных полезных изменений и добавлений в системах
• Доступность бизнес-ориентированной информации, соотносимой с SLA

Для ИТ организации:

• Улучшение мониторинга, возможность соотносить данные с требованиями SLA
• Улучшенная отчетность для руководства о качестве сервисов
• Повышение рациональности за счет лучшей загрузки персонала
• Устранение потерь и искажений информации при работе с запросами и инцидентами
• Более точная информация в CMDB (за счет проверок при регистрации инцидентов)
• Повышение удовлетворенности пользователей и заказчиков

Третья версия добавляет к списку выгод для бизнеса еще два пункта:

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

Вот этот список инициатор проекта по «внедрению управления инцидентами» и «продает» спонсорам – высшему руководству ИТ и заказчикам.

Чтобы сказка стала былью…

Пройдемся еще раз по приведенному списку – теперь с комментариями. Итак:

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

«Улучшенная отчетность о качестве сервисов» подразумевает, что информация, накапливаемая при регистрации инцидентов (включая действия по обработке и применяемые решения) может быть использована при оценке выполнения обязательств, взятых поставщиком сервисов при подписании SLA. Самое иллюзорное из преимуществ. На практике «автоматически» это работает только для оценки обязательств по поддержке (время поддержки, время реакции, время решения, процедуры обратной связи с пользователем). Для контроля качества поддерживаемых сервисов надо научиться соотносить инциденты с сервисами и SLA, отличать инциденты доступности от инцидентов производительности, безопасности, функциональности… Кроме того, оценить выполнение SLA на основании данных управления инцидентами можно только в тех случаях, когда обращения, связанные с одним и тем же сбоем в инфраструктуре, корректно учитываются, «привязываются» и трактуются с точки зрения влияния на бизнес. Для организаций, только-только начинающих систематизацию управления сервисами, эти опции, мягко говоря, не очень типичны.

«Проактивное определение возможных полезных изменений и добавлений в системах» возможно, если в процессе работает механизм (Major) Incident review – «разбора полетов» по инцидентам, в первую очередь – крупным. Такая работа действительно может не только помочь выявить «слабые места» предоставляемых сервисов, но и определить области и лиц, в которых и которым необходимо дополнительное обучение – как на стороне заказчика, так и на стороне ИТ. Эти обзоры могут стать началом будущего процесса управления проблемами, компенсируя на первых порах его формальное отсутствие. Поскольку они не входят в нарисованную в ITIL® схему процесса, о возможности их проведения осведомлены только те руководители и консультанты, которые читали ITIL®. Возможно, именно поэтому в жизни практику проведения таких review нельзя назвать общеупотребительной.

«Улучшение мониторинга» означает, что поставщик услуг, во-первых, интегрирует управление инцидентами с тем, что в третьей версии названо управлением событиями, а во-вторых, организует мониторинг наиболее критичных для бизнеса участков инфраструктуры (а не всего подряд и не того, что умеет контролировать навязанное вендором средство мониторинга). Требует ресурсов и понимания влияния работы ИТ компонентов на бизнес. Надо сделать вне зависимости от управления инцидентами и чтения ITIL®, но если «внедряем управление инцидентами» - важно не забыть соединить две эти важные функции управления ИТ.

«Повышение рациональности за счет лучшей загрузки персонала» можно обеспечить, во-вторых, настройкой выделения ресурсов в зависимости от назначенного приоритета, а во-первых – построением ясных, полных и корректных схем функциональной эскалации для каждого сервиса. Если для каждого сервиса не получается (на этом этапе мы, скорее всего, еще не имеем полного каталога сервисов) – тогда для каждой категории. Что в свою очередь предполагает корректное, полное, ясное дерево категорий. Одним только разделением персонала поддержки на три (или n) неструктурированных слоя – service desk, специалисты, эксперты – повышения рациональности не добиться.

«Более точная информация в CMDB» как преимущество интересна тем, у кого есть CMDB. У тех, кто начинает с управления инцидентами ее, как правило, еще нет. Однако можно предусмотреть процедуры операционной проверки данных управления активами, инвентарного учета, связей «пользователь-оборудование» и т.п. Причем не только при регистрации обращений, но и при работе по анализу и устранению инцидентов. «Повышение удовлетворенности заказчиков и пользователей» наступает, если поставщик сервисов организовал эффективный интерфейс (service desk – вежливый, доступный, компетентный, удобный…) и обеспечил реализацию хотя бы половины преимуществ из приведенного выше списка.

Ставьте реальные цели

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

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

• Формируйте свои списки ожидаемых преимуществ;

• Формируйте эти списки на основе анализа текущей ситуации и в связи с целями проекта (цели проекта, в свою очередь, соотносите с интересами заказчика. Цель «внедрить процесс управления инцидентами» не выглядит ни понятно, ни привлекательно.);

• Начинайте с малого. Процессы – развивающиеся системы, первичное внедрение должно обеспечить возможность развития, а не «все и сразу» возможные опции.