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

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

В начале 2003 года департамент информационных технологий корпорации «Инком-недвижимость» заинтересовался методологией Microsoft Operations Framework, и этот интерес был не праздным. Начавшийся в 2001 году рост компании был достаточно существенным: расширялась сеть филиалов, информационная инфраструктура, увеличивалось количество рабочих мест, используемых приложений и обращений за технической поддержкой. Перед отделом технической поддержки, одним из структурных подразделений департамента информационных технологий, встала задача эффективного обслуживания пользователей.

После изучения MOF и попыток реализации некоторых изложенных там идей было решено обратиться к первоисточнику — ITIL. От открывшихся перспектив буквально захватило дух. У вас есть вопросы относительно организации «горячей линии»? Пожалуйста, в разделе о Service Desk достаточно подробно описываются варианты организации, методы совершенствования, требования к персоналу и инструментарию, даже возможные проблемы. Вы стремитесь к стандартизации используемых средств вычислительной техники? Нет проблем, многое уже придумано и изложено в разделе об управлении релизами. Используемые в компании механизмы учета оборудования и программного обеспечения работают не так эффективно, как хотелось бы? Откройте главу об управлении конфигурациями. Ну а если после очередного обновления сервера остановилось важное приложение, что же — в ITIL подробно рассматривается процесс управления изменениями.

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

Сложности

После прочтения двух основных книг (Best practice for Service Support и Best practice for Service Delivery), а также книги IT Service Management Introduction и анализа условно-полезной информации на эту тему, почерпнутой из Internet, был разработан небольшой план внедрения на уровне «сначала этот процесс, затем тот, а потом вот тот». Однако впоследствии, при сравнении первоначального плана внедрения процессов с тем, что получилось, обнаружилась масса расхождений — и в том, какие процессы были реализованы, и в детальности их реализации, да и в очередности внедрения. Почему они возникли?

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

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

Промежуточный итог

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

  • Время решения вопросов по обращению пользователя было негарантированным. На обработку одной и той же заявки разные исполнители затрачивали разное время, хотя существенная часть работ была типовой и постоянно повторялась.
  • Сроки обработки заявок, зафиксированные в корпоративных нормативных документах, уже мало устраивали бизнес-подразделения. Требовался качественный «подъем», обеспечить который старыми методами было затруднительно.
  • Работа каждого из сотрудников, задействованных в поддержке пользователей и отработке заявок, оценивалась субъективно. Более того, оценка работы групп поддержки, отделов департамента, да и департамента информационных технологий в целом тоже была субъективной.
  • Обучать новый персонал технической поддержки принятым правилам работы было тяжело. В каждой ситуации результат обучения отличался, причем выявить зависимости, например от затраченных на обучение времени или усилий, было невозможно.
  • Планирование ресурсов поддержки (скажем, на время отпусков или болезней, а то и просто при открытии нового филиала) было нетривиальной задачей.
  • Внутри ИТ-департамента постоянно возникали конфликты и вопросы: кто и что именно делает, в какие сроки, за что отвечает и перед кем отчитывается? Помимо нездоровой психологической обстановки выяснения отношений неизбежно влекут за собой срыв сроков выполнения работ, особенно если решение вопросов по заявке выходит за рамки компетенции одного отдела.

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

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

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

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

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

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

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

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

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

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

Каталог услуг является основой для разнесения затрат, ведь без реестра услуг весьма затруднительно соотнести расходы на ИТ с его пользой для бизнеса.

Интересным «побочным» результатом разработки каталога услуг оказалось то, что в процессе выполнения работ стало возможным выделение так называемых «пакетов услуг» — более высокого уровня группировки сервисов. Кроме того, для некоторых услуг удалось «затвердить статус» — обозначить в виде документа ситуации, в которых сама услуга есть, но поддерживать ее в полном объеме ИТ-департамент не должен. Ярким примером такой услуги является использование служб мгновенной передачи сообщений (ICQ): программа устанавливается пользователям по их многочисленным постоянным просьбам, но ни для одного бизнес-процесса необходимой не является.

Когда нужно остановиться?

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

Уровень зрелости ИТ-подразделения. Процессы, описываемые в ITIL, неравнозначны с точки зрения потенциальных изменений в работе ИТ и требований к текущему состоянию ИТ-инфраструктуры. В качестве примера можно рассмотреть пятиуровневую модель зрелости процессов управления ИТ, разработанную Gartner: хаотичный, реактивный, проактивный, сервисный и значимый уровни. Если управление находится, предположим, на уровне «хаотичный», то внедрять процессы группы предоставления услуг (такие как управление уровнем сервиса или финансами для ИТ-услуг), скорее всего, преждевременно. Перескочить через два уровня непросто, а то и невозможно — изменения должны выполняться постепенно.

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

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

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

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

Олег Скрынник (itsm@incom.ru) — сертифицированный IT Service Manager, начальник технологического отдела корпорации «Инком-недвижимость» (Москва).

Библиотека ITIL

Библиотеку составляют следующие книги:

  • Service Support (из-за цвета обложки ее зачастую называют «Синей книгой»);
  • Service Delivery («Красная книга»);
  • Software Asset Management;
  • Planning to Implement Service Management;
  • ICT Infrastructure Management;
  • Application Management;
  • Security Management;
  • The Business Perspective.

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