Внедрение процесса управления проблемами: практические моменты и сложности внедрения

Synopsis

В статье описаны основные трудности, встретившиеся на пути внедрения процесса управления проблемами в Корпорации <Инком-Недвижимость>, а также выбранные методы преодоления означенных трудностей. Статья рассчитана на подготовленного читателя: в идеальном случае - участника проекта внедрения процесса управления проблемами, в минимальном - знакомого с предметом в объеме курса <Основы ITIL®>.

Введение

Завершая внедрение функции Service Desk и процесса управления инцидентами, ИТ-подразделения компаний зачастую следующим шагом начинают разработку и внедрение процесса управления проблемами. Такой порядок традиционен - выделяя процесс <тушения пожаров> вполне рационально также выделить процесс <расстановки огнетушителей>. Сложности, возникающие при внедрении процесса управления проблемами, описаны в книге <Поддержка услуг>, входящей в библиотеку ITIL®. Опыт внедрения этого процесса в Корпорации <Инком-Недвижимость> показал, что, во-первых, описанные в книге трудности действительно существуют, и решать их следует еще до внедрения процесса, а во-вторых, трудностей несколько больше, чем описано в первоисточнике.

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

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

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

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

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

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

Совмещение ролей менеджера процесса и аналитика

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

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

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

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

Отсутствие процессов управления конфигурациями и изменениями

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

Однако, как и предсказывалось еще на курсе <Основы ITIL®>, работа процесса управления проблемами сильно завязана на смежные процессы управления конфигурациями и изменениями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во-вторых, делая всё самостоятельно, никогда нельзя быть уверенным в правильности выстраиваемого процесса, особенно в деталях и мелочах, коих немало. Для получения гарантий относительно качества проведения работ пришлось отступить от принципа самостоятельности. На заключительной фазе разработки процесса управления проблемами для проведения аудита были привлечены консультанты компании <ИТ Эксперт>. Итог их работы - около десятка существенных замечаний по нашей реализации процесса, причем без устранения нескольких из них процесс однозначно бы не заработал. Итак, свежий взгляд эксперта позволяет избежать ошибок и значительно экономит время при внедрении процесса. Все последующие процессы ITIL®, внедряющиеся в Корпорации, в обязательном порядке проходят аудит специалистов <ИТ Эксперта>.

Заключение

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