Управление уровнем ИТ-услуг. Часть 2. Каталог ИТ-услуг и процессы

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

Определение целей проекта

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

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

Сервисные отношения и организационная структура ИТ-подразделения

Рисунок 1.Схема взаимодействия на основе доменной оргструктуры	Рисунок 2.Схема взаимодействия на основе функциональной оргструктуры

Доменная оргструктура

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

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

Функциональная оргструктура

Более часто, однако, в организациях встречается схема взаимодействия, основанная на функциональной оргструктуре, представленная на рисунке «Рисунок 2». В этом случае в составе ИТ-подразделения существуют две относительно автономные функции – разработки и эксплуатации, каждая из которых имеет свои точки контакта и подходы к управлению. Легко видеть, что, в отличие от сервисной схемы взаимодействия, схема на основе функциональной оргструктуры без дополнительных организационных мер единой точки ответственности и контактов по вопросам предоставления ИТ-услуг заказчику не обеспечивает. Каждая функция отвечает за реализацию своей фазы жизненного цикла ИТ-услуги, обеспечивая лишь часть целостного бизнес-результата. Поэтому при прочих равных условиях объем организационных изменений, необходимых для реализации целостного сервисного подхода, в организации с функциональной структурой будет выше.

Влияние оргструктуры на дизайн каталога ИТ-услуг и процессов

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

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

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

Сервисные отношения и разработка программного обеспечения

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

Сервисные отношения между группами в пределах поставщика ИТ-услуг

Следующим шагом является определение целесообразности формирования внутреннего каталога поддерживающих (supporting) ИТ-услуг и организации сервисных отношений между группами в составе поставщика ИТ-услуг.

Изучение книг ITIL и общедоступных материалов по ITSM может создать у читателя впечатление, что это общеупотребительная практика: каталог ИТ-услуг обязательно состоит из двух частей – бизнес-каталога и каталога поддерживающих услуг. По первому каталогу с заказчиками заключены SLA, по второму – с внутренними поставщиками заключены OLA. Действительно, это неплохая идея – зафиксировать обязательства внутренних групп в части обеспечения работоспособности оборудования и ПО, выполнения тех или иных операций в заданное время и так далее (именно эти вопросы обычно являются предметом регулирования в OLA). Однако введение каталога поддерживающих услуг и OLA приносит не только плюсы, но и специфичные организационные риски, иногда значительные.

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

Переход от первой ко второй модели – это переход от модели управления (management) к руководству (governance), и эта тема великолепно раскрыта в стандарте ISO/IEC 20000-1:2011 «Information technology – Service management». Важно понимать, что сервисный подход означает принципиально более высокую автономность поставщика от потребителя – он сам (хотя возможно и с некоторыми ограничениями) принимает решения по организации своей деятельности, и главным критерием является лишь надежное получение требуемого результата, то есть качество ИТ-услуг.

Теперь рассмотрим Рисунок 3, на котором оба варианта – процессный и сервисный – представлены на примере двух подразделений в составе ИТ-организации.

Рисунок 3. Процессы и услуги во внутренних взаимодействиях ИТ-подразделений

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

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

Идентификация услуг

Для коммерческих поставщиков выбор структуры и состава продуктов и услуг является одним из стратегических вопросов, непосредственно влияющим на конкурентоспособность и перспективы развития компании. Стратегическому маркетингу посвящено множество исследований и публикаций, базовые знания можно почерпнуть из книги «ITIL Service Strategy 2011 Edition» (ISBN 978-0113313044). Однако в некоммерческих сценариях определение состава услуг чаще всего выполняется для фиксации уже сложившихся отношений между поставщиком и потребителями. То есть речь идет не о создании новых услуг, востребованных рынком, а об идентификации существующих (хоть и не формализованных) услуг. Инструментарий стратегического маркетинга для решения этой задачи применим весьма ограниченно. Какие же рекомендации здесь можно дать?

Во-первых, определять услуги на языке потребителя, максимально близко к его интересам. Если вы обеспечиваете базовые информационные технологии в холдинговой структуре или в территориально-распределенной организации, и потребителями ваших услуг являются ИТ-службы предприятий или территориальных подразделений, услуги могут идентифицироваться на основании списка соответствующих ИТ-систем и решений (Active Directory, аренда серверов, подключение к централизованным системам по VPN и так далее). Но если потребителями ваших услуг являются бизнес-подразделения, которые используют ИТ для выполнения своих процессов, логично идентифицировать ИТ-услуги на основании перечня бизнес-процессов, анализируя их зависимость от информационных технологий. Мне могут возразить, что у многих компаний процессы не формализованы. Это правда, но для каталога ИТ-услуг и не требуется полная формализация бизнес-процессов – требуется лишь определение их перечня и содержания. Для решения этой задачи можно использовать отраслевые процессные модели, такие как eTOM или Process Classification Framework. Эта непростая работа окупится сторицей – построенный таким образом каталог будет больше соответствовать интересам бизнеса, позволит назначить реальных, а не номинальных заказчиков ИТ-услуг, выбрать значимые для заказчиков метрики для контроля качества ИТ-услуг.

Во-вторых, стремиться минимизировать количество услуг с несколькими заказчиками (не путать с потребителями – их может быть много!) за счет дробления услуг или укрупнения организационных границ заказчиков. Чем больше услуг с одним заказчиком, тем легче будет переговорный процесс о содержании и критериях качества ИТ-услуг, тем проще в будущем окажутся алгоритмы разнесения стоимости услуг.

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

В-четвертых (в противовес третьей рекомендации), стремиться к минимально возможному количеству услуг в каталоге. У каждой организации свои ориентиры, но даже в крупных организациях я бы стремился к каталогу из 100-150 услуг, не больше. Мой опыт показывает, что это вполне достижимо. Чем больше будет каталог ИТ-услуг, тем больше сил и ресурсов потребуется для управления услугами.

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

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

Каталог ИТ-услуг

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

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

Разберем эти случаи подробнее.

Каталог для заказа услуг

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

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

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

Каталог как справочник по предоставляемым ИТ-услугам

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

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

Каталог для фиксации стандартных условий предоставления ИТ-услуг

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

Выбор оптимального варианта

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

Структура соглашений об уровне ИТ-услуг

Книга «ITIL Service Design 2011 Edition» (ISBN 978-0113313051) описывает несколько типичных структур соглашений об уровне ИТ-услуг (SLA):

Мое личное мнение: в крупных компаниях больше применима многоуровневая структура SLA, в средних и небольших – индивидуальные SLA (в каждом из которых определены условия предоставления одной услуги одному потребителю). Такой подход обеспечивает наиболее простые процессы согласования при заключении и продлении SLA.

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

Процесс управления уровнем ИТ-услуг

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

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

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

Основные виды деятельности в составе процесса:

При проектировании процесса необходимо уделить внимание следующим критическим факторам успеха:

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

Заключение

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

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

Сноски

1. См., например, раздел 3.7 книги «ITIL Service Design 2011 Edition» (ISBN 978-0113313051).
2. Роман Журавлев. ITSM с точки зрения бизнеса. 
3. Colleen M. Young. Effective IT Organizational Design. Gartner, Inc. 2008.

Автор: Дмитрий Исайченко