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

Термины и определения

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

Управление ИТ-услугами — IT Service Management (ITSM) Внедрение и управление качественными ИТ-услугами, которые соответствуют потребностям бизнеса. Управление ИТ-услугами реализуется поставщиками ИТ-услуг путём использования наиболее оптимального сочетания людей, процессов и информационных технологий. 

Служба Поддержки Пользователей — (Служба Service Desk) Service Desk (ITIL Service Operation) Единая точка контакта между поставщиком услуг и пользователями. Типичная служба поддержки пользователей управляет инцидентами, запросами на обслуживание, а также осуществляет коммуникации с пользователями.

Соглашение об Уровне Услуг — (SLA) Service Level Agreement (SLA) (ITIL Service Design) (ITIL Continual Service Improvement) Соглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон – поставщика ИТ-услуг и заказчика. Одно соглашение об уровне услуг может распространяться на множество ИТ-услуг или множество Заказчиков.  

База Данных Управления Конфигурациями — (CMDB) Configuration Management Database — (CMDB) (ITIL Service Transition) База данных, используемая для хранения конфигурационных записей на всем протяжении их жизненного цикла. Система управления конфигурациями поддерживает одну или несколько баз данных управления конфигурациями, каждая база данных хранит атрибуты конфигурационных единиц и взаимоотношения с другими конфигурационными единицами.

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

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

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

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

Существует множество определений услуги. В частности, библиотека ITIL, один из источников знаний в области ITSM, определяет термин «услуга» следующим образом: 

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

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

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

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

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

Основные принципы ITSM можно выразить в двух предложениях:

1. Формой предоставления ценности заказчикам являются услуги.

2. Формой управления услугами являются процессы. 

Используя вышеприведённое определение услуги, ITIL так определяет ИТ-услугу:

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

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

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

Вроде бы получается, что ИТ-услуги и ИТ-системы — суть одно и то же. Однако нет, ИТ-услуга — гораздо более широкое понятие! В случае с внутренним ИТ-подразделением — это всё, что нужно для работы конечного бизнес-пользователя: и программа, и АРМ, и сеть, и поддержка Service Desk... 

Только такой взгляд на ИТ-инфраструктуру и деятельность ИТ-персонала позволяет, к примеру, определить сквозные (end-to-end) требования к доступности ИТ-услуг, от рабочего места пользователя через всю широкую и сложную инфраструктуру до последнего сектора на жёстком диске сервера.

Прошлое, настоящее и будущее сервисного подхода к управлению

Компонентный подход

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

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

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

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

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

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

Сервисный подход

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

Перспектива

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

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

Так, COBIT не рассматривает предоставление услуг в качестве цели деятельности ИТ.

ITIL как практика управления услугами

Библиотека ITIL (IT Infrastructure Library) является частью обширных знаний, на которые опирается управление услугами. Этот банк знаний создан по инициативе и контролируется правительством Великобритании. Хотя часть функций по управлению, в частности — развитие сертификации специалистов, организаций и программного обеспечения, отданы в аутсорсинг коммерческой организации AXELOS.Во многом на базе ITIL был разработан и в 2002 году утверждён британский стандарт в области управления ИТ услугами — BS 15000. В декабре 2005 года он, почти не претерпев изменений, стал основой для международного стандарта ISO/IEC 20000:2005, с тех пор он обновлялся и дополнялся. ISO/IEC 20000 предоставляет формализованный универсальный стандарт для организаций, которым необходим аудит и сертификация своих управленческих способностей.

Библиотека ITIL включает в себя следующие компоненты:

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

Центральными книгами ITIL являются пять публикаций, которые совпадают с пятью фазами жизненного цикла сервисов (Рис. 1).

Рис. 1. Пять фаз жизненного цикла сервиса.

Заметим, что в области управления ИТ-услугами сформировалось и несколько проприетарных сводов знаний – адаптаций общих практик под инструменты, которые предлагает конкретный разработчик – Microsoft Operation Framework, HP ITSM Reference Model. Среди источников знаний и рекомендаций в области управления ИТ-услугами стоит также упомянуть FITS (Framework for Information Technology Support), USMBOK (Universal Service Management Body). Стратегия услуг:

• Проектирование услуг.
• Преобразование услуг.
• Эксплуатация услуг.
• Постоянное совершенствование услуг.

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

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

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

Общая картина

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

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

Главное о процессах

Процесс — это комплекс взаимосвязанных видов деятельности, выполняемых совместно или последовательно, направленный на повторяемое получение определённого измеримого результата.

Процесс выстраивает деятельность в логичную, результативную и рациональную последовательность, обеспечивающую достижение запланированного результата. Можно сказать, что процесс — это последовательность действий, формирующих результат (output, а затем и outcome), на основе входящей информации (input). Действия в процессе можно разделить на производственные, то есть формирующие результат (throughput activities) и контрольные (control activities). На введённой здесь терминологии основана простейшая модель процесса — ITOCO (Input — Throughput — Output — Control — Outcome) (Рис. 2):

Рис. 2. Процесс ITOCO.

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

Оценка результатов (output, а лучше — outcome) позволяет сделать выводы о результативности процесса. Если результаты соответствуют предопределённым критериям качества, процесс считается результативным. Важно определить такие критерии на этапе проектирования процесса. Управление процессами подразумевает также, что результаты получаются максимально рациональным образом. Для оценки и обеспечения рациональности также используются контрольные действия и определяемые в рамках планирования процесса критерии и стандарты.

Процедуры и рабочие инструкции

Процессы отвечают на вопрос «что мы делаем?». Для ответов на вопросы «кто, когда и как выполняет работу?» и «как при этом используются инструменты?» создаются процедуры и рабочие инструкции. 

Процедура — это определённый способ выполнения деятельности.

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

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

Главное о функциях

Функции — это объединения людей (в том числе и виртуальные) и используемый ими инструментарий, включая знания, методы, средства автоматизации и т.п., специализированные для выполнения определённой деятельности и отвечающие за получение определённых результатов.

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

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

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

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

Своды знаний по управлению ИТ-услугами уделяют функциям ITSM ничтожно мало внимания. Так, в предыдущей, второй версии библиотеки ITIL была описана всего одна функция — Service Desk. В ITIL v3 число сущностей, описанных как функции, достигает четырёх. Помимо Service Desk, функциями названы Operations Management (Управление эксплуатацией), Technical Management (Управление технической поддержкой) и Application Management (Управление приложениями). Практически число описанных функций больше, поскольку многие из них рассматриваются в ITIL под заголовком «Процессы».

Основные компоненты системы управления ИТ услугами

Рассмотрим основные процессы и функции системы управления ИТ услугами, согласно ITIL.

Управление уровнем услуг (Service Level Management)

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

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

Доступность — это характеристика, позволяющая определить временные и пространственные границы предоставления услуги, то есть ответить на вопрос «где и когда предоставляется услуга?». И наконец, цена — это основной критерий для оценки полезности предоставляемой услуги или принятия решения о её проектировании и передаче в эксплуатацию.

На Рис. 3 приведена общая схема деятельности по управлению уровнем услуг.

Рис. 3. Общая схема деятельности по управлению уровнем услуг.

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

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

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

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

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

Данные мониторинга анализируются для оценки соответствия фактического качества услуги согласованным на этапе проектирования целевым значениям (5.1). Выявленные отклонения становятся основой для планирования корректировок (6). Кроме устранения отклонений от целей в области качества, корректировки могут планироваться для того, чтобы обеспечить соответствие качества услуги ожидаемым новым требованиям — например, в случае, когда прогнозируется рост нагрузки на инфраструктуру в связи с увеличением числа потребителей. Разумеется, работа по оценке фактического качества услуги и планированию улучшений не может проводиться без участия представителей заказчика. Они не только получают отчётность о качестве услуг (5.2), но и активно участвуют в планировании улучшений — в особенности тех, что направлены не на исправление недостатков, а на повышение «планки качества». Анализ информации о фактическом качестве услуг и управление улучшением услуг — основные составляющие деятельности по управлению уровнем качества предоставляемых услуг.

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

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

Управление поставщиками (Supplier Management)

Процесс выстраивания отношений с поставщиками – один из ключевых процессов в деятельности CIO, поэтому вопросу Управления отношениями, в том числе и с поставщиками, в Учебнике отведена отдельная глава 2.5 «Управление отношениями». Поэтому здесь рассмотрим только суть данного процесса.

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

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

Управление изменениями (Change Management) и управление релизами (Release Management)

Процесс управления изменениями осуществляет общую координацию всех планируемых и проводимых изменений.

Изменение — это добавление, модификация или удаление чего-либо, способного оказать влияние на ИТ-услуги.

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

Результаты построения и тестирования согласуются с комитетом по изменениям или назначенными комитетом лицами, и по результатам согласования принимается решение о передаче результатов построения в эксплуатацию. После завершения развёртывания и проведения оценки начального этапа эксплуатации принимается решение о признании изменения успешным и закрытии.

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

Рис. 4. Общая схема деятельности по управлению изменениями.

Контроль операционного управления ИТ (IT Operations control)

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

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

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

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

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

Служба поддержки пользователей (Help Desk, Service Desk)

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

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

Георгий Ованесян

Управление запросами на обслуживание (Request Fulfilment)

Часть работ по эксплуатации — обработка запросов на обслуживание.

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

Эти запросы можно условно разделить на две группы:

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

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

Управление инцидентами (Incident Management)

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

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

Для достижения этой цели в рамках процесса решаются следующие задачи:

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

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

На Рис. 5 приведена общая схема деятельности по управлению инцидентами.

Рис. 5. Общая схема деятельности по управлению инцидентами.

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

Управление конфигурациями (Configuration Management)

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

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

Важнейшим понятием управления конфигурациями является конфигурационная единица. Конфигурационные единицы — это все значимые для предоставляемых услуг компоненты инфраструктуры ИТ.

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

На Рис. 6 приведена общая схема деятельности по управлению конфигурациями.

Рис. 6. Общая схема деятельности по управлению конфигурациями.

Управление проблемами (Problem Management)

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

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

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

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

На Рис. 7 приведена общая схема деятельности по управлению проблемами.

Рис. 7. Общая схема деятельности по управлению проблемами.

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

Границы применения модели управления ИТ услугами (ITSM)

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

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

ITSM – модель «покупатель —продавец»

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

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

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

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

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

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

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

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

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

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

• спецификация ИТ-сервиса;
• деньги (ресурсы);
• угроза конкурентного выбора поставщика ИТ-сервиса (приобретения ИТ-сервиса у сторонней организации). 

Что получает ИТ-служба от внедрения модели ITSM?

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

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

3. С выводом ИТ-службы на аутсорсинг у неё появляется возможность получения прибыли и создания полноценного бизнеса. Последовательное внедрение модели ITSM создаёт мощные стимулы для обеих сторон в:

• повышении уровня ИТ-сервиса до уровня лидеров рынка;
• снижении объёма затрат на ИТ.

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

Если у обеих сторон от внедрения ITSM-модели появляются такие большие выгоды, то почему она так трудно внедряется? Дело в том, что у модели ITSM есть серьёзные объективные ограничения:

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

Способность к использованию модели «покупатель — продавец»

Для того, чтобы понять, при каких условиях бизнес готов к построению отношений со своей ИТ-службой на рыночных принципах «покупатель — продавец», нужно ответить на вопрос: «При каких условиях бизнес готов поделиться управленческой властью со своим подчинённым подразделением?».

Рассмотрим такую аналогию. Пользуясь мобильным телефоном, я покупаю телекоммуникационные услуги у оператора. С ним я договариваюсь, и мы в прямом соглашении определяем взаимные обязательства. Он создаёт для меня определённую ценность — гарантию мобильной связи с определённым уровнем качества в любой точке России и мира. Представим, что в моем аппарате мобильного телефона работает команда человечков, которая каким-то образом обеспечивает работу этого аппарата. Аппарат — мой, я его купил. Команду я нанял для того, чтобы они выполняли свои функции. Если что-то будет работать не так, я не буду с ней договариваться, я буду ей командовать. При каких условиях эта команда человечков может создавать для меня какую-то дополнительную ценность, чтобы у меня появилась необходимость с ней договариваться?

Факторы, подталкивающие бизнес к модели ITSM, формируются с обеих сторон: как в бизнесе, так и в самих ИТ. Далее для обеих сторон рассмотрены группы факторов, с которыми встречался автор.

Факторы со стороны бизнеса

1. Где бизнес начинает стандартизацию своих бизнес процессов, там появляются унифицированные и широко используемые бизнес-задачи. Здесь большое значение имеет масштаб использования унифицированных операций и степень изменчивости бизнеса. Нет унификации задач – все ИТ-решения будут уникальными. Например, в холдинге есть небольшое предприятие мелкосерийного производства, обладающее специфической технологией. Для поддержки MES-системы своей собственной разработки предприятие держит свою ИТ-службу, и никаких ИТ-услуг в этой области нет. У этого предприятия есть планы внедрения покупной, более унифицированной MES-системы, но при этом ИТ служба останется на предприятии в том же статусе функционального подразделения. Никому в холдинге, кроме этого предприятия, такая локальная задача не нужна. Другое дело в торговой сети, где, например, кассовое обслуживание — задача не только унифицированная, но массово используемая. Там под неё сделана корпоративная ИТ-услуга и вся специфика кассового обслуживания «уложена» в различные уровни этой услуги. Кстати, в ходе кризиса, когда многие компании начали искать новые продукты, технологии и рынки, они начали бурно перестраивать свой бизнес и стали отказываться от многих корпоративных ИТ-сервисов, загружая свои функциональные ИТ-службы. В этих компаниях остались только те корпоративные ИТ сервисы, где сохранились унифицированные задачи, например, такие как интернет, электронная почта или корпоративный документооборот.

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

3. Некоторые крупные компании выбирают бизнес-стратегию кооперации своих дивизионов, построенной по принципу рынка «покупатель — продавец». В рамках этой стратегии происходит централизация вспомогательных служб и превращение их в корпоративные сервисные центры. В этом случае бизнес сам вынуждает ИТ-службы внедрять ITSM. Например, именно это произошло в РАО ЕС и РЖД.

Факторы со стороны ИТ

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

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

Способность к ИТ-сервисам в различных ИТ-архитектурах

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

В целом можно выделить четыре сценария развития отношений между ИТ-службой и бизнесом.

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

2. «Серый кардинал». Сценарий часто возникает, например, при масштабном внедрении ERP-системы в организации, в которой реально появились лишь фрагментарные бизнес-процессы, и вся основная деятельность так и осталась построена на личных отношениях и прецедентах. Это — внедрение «на вырост». Удачный запуск системы в эксплуатацию заслуженно приближает руководителя ИТ-службы к первым лицам бизнеса. При этом все руководители бизнес-подразделений обнаруживают новый центр влияния в отношениях, который базируется на экспертном знании ИТ-специалистов и близостью к первым лицам. Иногда это становится сюрпризом и для самих первых лиц. Если в этой ситуации бизнес оказывается не готов к движению в направлении построения модели отношений с ИТ-службой «покупатель — продавец», то «серый кардинал» быстро эволюционирует в «пожарную команду» с последующей эволюцией ИТ-архитектуры к типу «лоскутное одеяло».

3. «Центр компетенции». К этому сценарию ИТ-служба приходит часто с масштабным внедрением сильно интегрированной ERP-системы в организации, в процессе которого бизнес сам систематически регламентирует свою основную деятельность в виде бизнес-процессов. В архитектуре «сильной интеграции» высокая эффективность оплачивается высокой сложностью системы. Ценой высокой сложности всегда становится высокая квалификация тех, кто умеет работать с этой сложностью. Работу такой команды необходимо хорошо оплачивать, да ещё и суметь удержать, так как после завершения проекта они оказываются нарасхват на ИТ-рынке. Это одна из скользких сторон крупных и даже успешных проектов по созданию сильно интегрированных корпоративных систем. Если бизнес в такой ситуации не готов делиться полномочиями с ИТ-службой, то «центр компетенции» начинает балансировать на грани «серого кардинала». Для того, чтобы не сорваться в этот сценарий, бизнес должен отчётливо понимать те выгоды, которые он получает от архитектуры «сильной интеграции», и те полномочия ИТ-службы, на которые ему лучше не покушаться. В этом сценарии в ИТ-службе можно встретить большинство процессов ITSM, но полноценная модель ITSM все равно не формируется. Связано это с тем, что функциональность сильно интегрированной ERP-системы не может быть разделена на независимые ИТ-услуги. В результате весь каталог услуг сворачивается до одной большой монолитной услуги, называемой, к примеру, «доступ к ERP-системе». В этом случае бизнес и ИТ-служба могут выстраивать отношения по типу «покупатель – продавец», но только продаются не ИТ-услуги, а компетенции команды.

4. «Сервисный центр». Именно этот сценарий идеально ложится на модель ITSM и хорошо описывается ITIL. Он имеет свои небольшие модификации. В архитектуре «слабой интеграции» каталог услуг может точно соответствовать прикладным услугам (почта, групповая работа, поиск, регистрация документов, согласование, хранение и так далее). В архитектуре «лоскутное одеяло» каталог услуг выстраивается вокруг бизнес-приложений (лоскутов). В любом каталоге услуги должны быть независимы друг от друга. Это принципиально отличает данный сценарий от сценария «центр компетенции».

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

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

Видимо, с этим связаны и реальные масштабы использования модели ITSM. И это нормально. Наличие ограничений применения — это свойство любой практически значимой методологии. Если мы не понимаем её ограничений, то мы, соответственно, не понимаем, как эффективно её использовать. Универсальны только неработающие методологии.

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

Авторы: Олег Скрынник, Роман Журавлёв, Владимир Ананьин

Источник: Учебник 4CIO. Настольная книга ИТ-директора

© Клуб Топ-менеджеров России 4CIO