Завершая внедрение функции Service Desk и процесса управления инцидентами, ИТ-подразделения компаний зачастую переходят к разработке и внедрению процесса управления проблемами.

Завершая внедрение функции Service Desk и процесса управления инцидентами, ИТ-подразделения компаний зачастую переходят к разработке и внедрению процесса управления проблемами. Такой порядок понятен: если есть процесс «тушения пожаров», то разумно иметь и процесс «анализа причин возгорания».

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

Недостоверная база данных сбоев

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

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

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

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

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

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

Совмещение ролей

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

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

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

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

Отсутствие смежных процессов

Очередность внедрения процессов в корпорации была выбрана следующая: сначала развертывался процесс управления проблемами (так как процесс управления инцидентами, равно как и функция Service Desk, уже внедрен), затем процесс управления конфигурациями и, наконец, процесс управления изменениями. При этом планировалось достаточно четко разделить во времени внедрение процессов, выполняя его последовательно.

Однако, как и предсказывалось в рамках учебного курса «Основы ITIL», который читался нашим сотрудникам в компании IT Expert, работа процесса управления проблемами оказалась тесно связана со смежными процессами управления конфигурациями и изменениями.

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

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

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

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

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

Для процесса управления изменениями были приняты правила, по которым подавать запрос на изменение может только менеджер проблем. Временно, до выделения достаточного количества ресурсов для полного внедрения процесса управления изменениями, внешние запросы на изменение не принимались. Кроме того, было ограничено членство в консультативных комитетах по изменениям (CAB). Чтобы более оперативно рассматривать подобные заявки, мы старались составить их таким образом, чтобы в их решении были задействованы только самые необходимые сотрудники.

Итак, работа процесса управления проблемами в отсутствие смежных процессов сильно затруднена. Следует запланировать внедрение таких процессов (пусть и не в полном объеме) до или одновременно с внедрением процесса управления проблемами.

Неверно выбранные KPI

Без измерения основных (ключевых) показателей эффективности невозможно управлять работающим процессом. Для каждого внедряемого процесса следует выработать набор метрик, определяющих состояние процесса, успехи и неудачи, узкие места. Метрики должны количественно демонстрировать степень продвижения к цели процесса.

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

  • снижение количества инцидентов по сравнению с предыдущим отчетным периодом;
  • снижение суммарного ущерба от инцидентов, также по сравнению с предыдущим отчетным периодом.

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

Мы были вынуждены в срочном порядке пересмотреть ключевые показатели эффективности процесса управления проблемами, теперь уже с учетом кратко- и долгосрочной перспективы. С точки зрения KPI, мы условно разделили внедрение процесса на два этапа. На первом этапе мы используем следующие ключевые показатели:

  • количество зарегистрированных (открытых) проблем с разбивкой на реактивную и проактивную составляющие, а также по категориям, услугам и ущербу;
  • количество поданных запросов на изменение;
  • количество закрытых проблем;

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

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

Переоценка собственных возможностей

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

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

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

Как мы убедились на собственном опыте, все возникающие трудности вполне преодолимы. Мы боролись с ними сами, «набивая себе шишки». Оглядываясь назад, становится очевидно, что многих проблем удалось бы избежать, более внимательно изучая литературу, опыт коллег, используя экспертов из консалтинговых компаний.

Олег Скрынник — начальник технологического отдела корпорации «Инком-Недвижимость», itsm@incom.ru

Смежные процессы ИТ-подразделения

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

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

Процесс управления проблемами

Этот процесс имеет две составляющие — реактивную и проактивную. Реактивная составляющая направлена на анализ сбоев по мере их возникновения.

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

  • анализ тенденций;
  • оказание поддержки;
  • предоставление информации организации.

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