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

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

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

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

• Доменная оргструктура
• Функциональная оргструктура

Рис. 1. Схема взаимодействия на основе                    Рис. 2. Схема взаимодействия на основе  

            доменной оргструктуры                                                 функциональной оргструктуры    

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

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

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

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

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

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

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

Таблица 1. Базовые модели реализации управления ИТ-услугами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• определять, какие услуги могут заказывать ваши клиенты;
• предоставлять консолидированную информацию о предоставляемых услугах и их основных характеристиках (классификации, кратком описании, заказчиках…);
• фиксировать стандартные условия предоставления услуг, принятые на уровне всей организации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Дмитрий Исайченко (d.isaychenko@cleverics.ru) — директор по консалтингу компании Cleverics, ITIL Expert, член экспертного совета itSMF России