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

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

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

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

Альтернатива: каталог сервисов

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

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

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

Внедрение каталога позволяет бизнесу оценить валовые и удельные затраты на ИТ-сервисы и сопоставить их с бизнес-приоритетами сервисов. В результате бизнес получает возможность сопоставить результат и затраты на ИТ. Оценка результата при этом неизбежно будет качественной, а не стоимостной [3], но на данном этапе такой оценки, как правило, достаточно. Наряду с этим бизнес-заказчик получает возможность сравнивать фактические затраты на ИТ-сервисы с предло­жениями внешних и внутренних провайдеров. Тем самым возникает объективная основа для сравнения разных вариантов сорсинга ИТ-сервисов. Далее, бизнес на основании каталога сервисов может оценить объем потребления сервисов в различных подразделениях и филиалах и при необходимости рассмотреть его обоснованность. Наконец, бизнес получает возможность сопоставить приоритеты сервисов с фактическими расходами на них.

Каталог сервисов не менее полезен и ИТ-службе – прежде всего, он позволяет «спрямить» процесс обсуждения ИТ-бюджета, дополнить неизбежный торг обсуждением количественной связи между текущими и будущими требованиями к объему и качеству ИТ-сервисов, с одной стороны, и ресурсов, необходимых для этого ИТ-службе – с другой. В результате в ответ на требование сократить операционный бюджет ИТ-служба получает возможность задать отрезвляющий вопрос: «хорошо, поддержку каких сервисов мы теперь можем сократить или прекратить вовсе?» [3]. Следует обратить внимание, что такое использование каталога в обязательном порядке предполагает его согласование с бизнесом в процессе внедрения, в противном случае трудно обеспечить необходимый уровень доверия.

При необходимости пересмотра бюджета каталог позволяет распределить сокращение на поддерживаемые сервисы. При этом снижение затрат на сервис может идти по линии снижения уровня сервиса (например, сокращение времени обслуживания до 8×5), объема (например, сокращение числа пользователей), либо накопления рисков (например, отказ от технической поддержки). Сокращение проводится с обязательным учетом приоритетов бизнеса, также зафиксированных в каталоге сервисов. Далее, по результатам сокращения из каталога вновь «собирается» сервисный бюджет.

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

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

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

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

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

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

Слагаемые успеха каталога сервисов

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

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

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

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

Далее, в ходе проекта необходима реалистичная корректировка ожиданий, которая может привести как к уменьшению функционального объема каталога, так и к росту. Если заказчик выделяет в проект компетентных специалистов, если они проводят в проекте достаточно много времени, если в организации существуют надежные и качественные базы Service Desk и управления конфигурациями, то ожидания вполне могут быть увеличены. Напротив, недостаточное участие заказчика в проекте, трудности обмена информацией с подразделениями/филиалами, отсутствие необходимых данных могут привести к снижению реального объема проекта, конечно, в том случае, если они не будут скорректированы. Естественно, что причиной неувязок в проекте может быть не только заказчик, но и исполнитель: нереалистичные планы, недостаточные ресурсы, отсутствие шаблонов или методик для конкретной ситуации – самые распространенные проблемы.

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

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

И последнее – необходимо использовать адекватные инструменты автоматизации. В крупной многофилиальной организации каталог может включать в себя 100-200 сервисов, несколько сот объектов затрат и десятки тысяч записей аллокации. Подобный масштаб требует автоматизации, но, к сожалению, в большинстве средств автоматизации, таких как HP Service Manager, BMC Remedy или Axios Assyst, присутствует только собственно список сервисов, не включающий функциональность расчета затрат на них. Для этой ситуации можно предложить расчетную систему, ориентированную на поддержку аллокационной модели и включающую функциональность сбора данных, расчета затрат по аллокационной модели и базовый набор отчетов: по затратам на сервисы, по аллокации договоров и сотрудников, по составу и структуре объектов затрат.

***

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

Литература

  1. Implementing ITIL v.3: Theory Versus Reality, Gartner research ID G00171788, 29 октября 2009.
  2. Hank Marquis. Effective Project Management, ITIL and BSM. CIO Update, June 09, 2010.
  3. И. Баринов, С. Растопшина, К. Скрипкин. Основание: каталог услуг в управлении ИТ-службой. ITSM-альманах, 2010.
  4. Е. Аксенов, И. Альтшулер. Аутсорсинг: 10 заповедей и 21 инструмент. СПб: Питер, 2009.

Кирилл Скрипкин (k.skripkin@gmail.com)  – доцент кафедры экономической информатики экономического факультета МГУ.

Структура аллокационной модели затрат ИТ-службы