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

Кирилл Скрипкин

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

Сегодня среди российских менеджеров в сфере ИТ едва ли найдется много людей, отрицающих ценность библиотеки ITIL и процессов ITSM, однако приверженность принципам ITSM лишь ограниченно подтверждается повседневной практикой ИТ-служб. Если посмотреть на то, какие процессы реально внедрены, мы во многих случаях обнаружим управление инцидентами и управление конфигурациями, реже – каталог сервисов, управление изменениями и проблемами, еще реже – управление уровнем сервиса. Наконец, совсем редко встречаются процессы управления доступностью, мощностями или финансами, а также управление портфелем сервисов. Между тем, согласно идеологии ITSM, именно процесс управления уровнем сервиса рассматривается как ключевой, поскольку задает требования и количественные метрики для остальных процессов. Возникает естественный вопрос: что же определяет подобный состав внедряемых процессов? Следует ли считать его случайным? Идет ли речь о недостаточной осведомленности менеджеров ИТ-служб, о недостаточной зрелости самих ИТ-служб? Или же есть и другие причины (хотя оба эти фактора, несомненно, имеют место)?
Для ответа обратимся к исследованию внедрения процессов модели ITSM в Австралии [1], компании которой начали внедрять модель ITSM существенно раньше российских, да и уровень проникновения ИТ в общество там выше. Так, в Network Readiness Index, ежегодно публикуемом совместно с бизнес-школой INSEAD и Всемирным экономическим форумом, Россия в 2012 году занимала 56-е место в общем рейтинге, находясь на 130-м месте по использованию ИТ в бизнесе и на 65-м – по использованию ИТ органами власти, тогда как Австралия – на 17-м, 19-м и 28-м соответственно. В основе исследования лежал опрос, проведенный на конференции itSMF Австралии в 2005 году, в котором предлагалось оценить глубину внедрения процессов ITSM, мотивацию к внедрению, бюджет программы, факторы успеха и оценку эффективности ITSM. Глубина внедрения оценивалась по пяти бальной следующей шкале от «0» – нет планов, до «5» – полностью внедрен. В качестве факторов успеха предлагались конкретные организационные практики с вариантами ответа от «совершенно не согласен» (0 баллов) до «полностью согласен» (5 баллов). Наконец, эффективность измерялась как соответствие результатов внедрения ожиданиям в начале внедрения, от «Разочарованы» до «Превзошла ожидания». Допускались также ответы «Не уверен» и «Слишком рано говорить».
Среди процессов операционного уровня с большим отрывом лидируют (балл выше 3) три процесса: управление инцидентами, Service Desk и управление изменениями, а для остальных процессов средний балл находится в диапазоне 2,17-2,64. Среди процессов тактического уровня лидером оказался процесс управления уровнем сервиса (2,31), при этом его средний балл оказался на уровне наименее популярных процессов операционного уровня. Пятью наиболее важными факторами успеха оказались поддержка высшего руководства и способность ИТ-персонала адаптироваться к изменениям. Среди организационных факторов, влияющих на масштабы внедрения ITSM, наиболее важными оказались размер организации в целом и размер ее ИТ-службы, причем частный сектор оказался значительно впереди государственного в области внедрения ITSM. Внедрение ITSM оказалось не связанным с внедрением других моделей управления ИТ (COBIT, MOF и др.). Наконец, удовлетворенность внедрением ITSM оказалась не связанной с масштабами внедрения процессов модели. Более того, косвенно подтвердилась гипотеза о том, что удовлетворенность ITSM оказалась обратной глубине внедрения.
Особо следует выделить следующие результаты. Во-первых, глубина внедрения ITSM в Австралии принципиально не отличается от таковой в России. То же можно сказать о составе внедряемых процессов, особенно о соотношении процессов операционного и тактического уровня. Также следует отметить, что удовлетворенность ITSM не стимулирует предприятие повышать глубину внедрения. Иными словами, существующий состав внедренных процессов, а равно и глубина внедрения, вероятнее всего, удовлетворяет австралийские фирмы. Таким образом, значительное продвижение Австралии в области использования ИТ по сравнению с Россией не ведет ни к более обширному набору процессов ITSM, ни к большей глубине их внедрения. Напротив, начиная с определенного уровня, предприятие не проявляет заинтересованности в дальнейшем внедрении процессов ITSM, несмотря на удовлетворенность существующим внедрением.
0.Экономика ITSM
Получается, что операционные процессы ITSM внедряются значительно лучше тактических, причем причина не в низкой зрелости ИТ. А в чем? Ответ следует искать в экономике процессов ITSM, проанализировав ее по четырем срезам.

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

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

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

Рис.2. Зависимость характеристик распределения от объема выборки

0.0 Срез третий: уровень зрелости и его стоимость
Напомним, что в моделях зрелости процессов ИТ-службы, таких, как COBIT, выделяют пять уровней зрелости: 0 – отсутствует, то есть данный процесс не существует (не рассматривается как уровень); 1 – начальный, процесс осуществляется хаотически, руководство процессом не организовано; 2 – повторяемый, опыт исполнения процесса накапливается и используется, однако, не формализуется; 3 – определенный, процесс стандартизирован и документирован; 4 – управляемый и измеримый, существуют инструменты измерения объема, качества и стоимости процесса, в том числе и автоматизированные; 5 – оптимизируемый, процесс не только удовлетворяет текущие потребности заказчика, но и постоянно совершенствуется. Переход на новый уровень, как правило, связан с издержками. При переходе от первого уровня ко второму эти издержки связаны с неформальным обменом опытом между участниками процесса и, следовательно, невелики. При переходе от второго уровня к третьему они серьезно возрастают, прежде всего, за счет формализации процесса (что, как правило, представляет собой проект) и накладных расходов на ведение самого процесса. К ним относится регистрация инцидентов и обращений, ведение соответствующих баз, процедуры закрытия инцидента или изменения и т.д. Часто на этом уровне появляется и необходимость в автоматизации процесса, например, в части ведения необходимых баз данных. Переход к четвертому уровню зрелости требует создания развитой системы измерений, отслеживающей затраты и результаты по всей цепочке бизнес-процесса. Эта система сама по себе требует уже значительных затрат как на ее создание, так и на эксплуатацию, включая и необходимые средства автоматизации. Наконец, переход к пятому уровню требует не только дальнейшего развития формализации процесса и системы измерений, но и дополнения их соответствующей корпоративной культурой. Это бесспорно наиболее длительная и, вероятно, наиболее дорогостоящая часть процесса. Таким образом, переход от уровня к уровню ведет к росту накладных расходов, связанных с функционированием процесса. Более того, есть основания полагать, что по мере продвижения к более высоким уровням эти расходы растут опережающими темпами.
Что же получает бизнес от инвестиций в уровень зрелости ИТ-службы? По большому счету, только одно -- своеобразную «страховку» от все более широкого круга рисков, связанных с ИТ. Для примера рассмотрим ситуацию, когда на предприятии внедрена неудачная прикладная система, порождающая большое количество инцидентов. Если процесс управления инцидентами находится на третьем уровне, будет выявлен рост количества инцидентов. Если же внедрен также процесс управления изменениями, вероятно, что данная система внедрена в рамках пилотного проекта и по результатам такого проекта внедрение будет остановлено. Таким образом, ошибочный выбор приложения при более высоком уровне зрелости процессов будет раньше обнаружен и приведет к значительно меньшим потерям для предприятия.
Есть и еще одна причина повышения уровня зрелости процессов ITSM, несмотря на затраты – влияние ИТ на основной бизнес предприятия. Чем больше такое влияние, тем выше потери от простоев или иных сбоев функционирования ИТ, тем ценнее для бизнеса возможность снизить вероятность таких сбоев. Соответственно, у таких предприятий существуют значительно более серьезные стимулы внедрять процессы ITSM.

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

0.Предварительные выводы
Предлагаемая система взглядов на экономику ITSM объясняет большинство результатов, полученных в эмпирическом исследовании для австралийских компаний:
- для крупных предприятий и ИТ-организаций ITSM предпочтительнее, чем для мелких, что вытекает из анализа безубыточности и необходимых резервов;
- процессы операционного уровня внедряются чаще и с более высоким уровнем зрелости, чем процессы тактического уровня, что вполне объяснимо их более сильным влиянием на бизнес и, следовательно, более высокими требованиями к масштабу выгод. Определенным исключением предстает процесс управления изменениями, однако следует помнить, что средний балл «3,1» означает по шкале, принятой исследователями, «внедрен наполовину». Между тем, процесс управления изменениями включает такую часть, как регистрация изменений, которая вполне может быть внедрена в данном случае. Аналогичным образом, в процессе управления уровнем сервиса присутствует такая часть, как каталог сервисов (в версии ITIL 2.0 процесс управления каталогом сервисов входил в состав процесса управления уровнем сервиса, тогда как в ITIL 3.0 – это отдельный процесс), который тоже влияет на бизнес слабее, нежели SLA;
- рост затрат с повышением уровня зрелости ограничивает усилия по расширению и углублению внедрения, в том числе и у предприятий, вполне удовлетворенных работающими у них процессами;
- вовлечение высшего руководства в проект внедрения – важнейшее условие успеха проекта, что связано как с возможными изменениями условий функционирования основного бизнеса, так и с балансированием выгод и затрат.

0.И снова к процессам
Что же из всего это следует? Прежде всего, мы видим, что процессы ITSM, вообще говоря, подходят не для всех организаций – малый объем задач ИТ-службы и малая значимость ИТ для бизнеса снижают ценность процессов ITSM. Это, впрочем, касается процессов как таковых и не исключает использования ITSM как подхода. Рассмотрим процессы по отдельности, руководствуясь моделью процессов второй версии библиотеки ITIL. Это связано с тем, что третья версия предлагает значительно более дробную разбивку процессов, которые часто неразличимы с точки зрения предлагаемого аппарата. Единственным исключением будет каталог сервисов, который выделен в отдельный процесс только в третьей версии и заслуживает отдельного анализа. Это связано с тем, что управление каталогом сервисов сильно отличается от процесса управления уровнем обслуживания в целом (понимаемым, прежде всего, как создание и поддержание SLA) по воздействию на основной бизнес предприятия. Соответственно, и экономика этого процесса тоже иная.
Говоря о процессах операционного уровня, отметим в первую очередь Service Desk и управление инцидентами. Эта пара тесно связанных процессов представляет собой классический пример quick win – быстрый выигрыш, понятный бизнесу и демонстрирующий ценность ITSM в целом. Кроме того, процесс управления инцидентами – это своеобразный «сборочный конвейер» ИТ-службы, на котором видны все успехи и все провалы. Наконец, именно в рамках процесса управления инцидентами определяется целый ряд метрик других процессов ITSM. Не случайно эти два процесса входят в число самых популярных в австралийском исследовании и, похоже, в России. В то же время, они не универсальны и прежде всего надо оценить возможность реализации процесса без повышения эксплуатационных затрат на ИТ. Если такие дополнительные затраты все же потребуются, необходимо четко согласовать с бизнесом, какие выгоды он получит за эти деньги. Это ограничение становится еще более важным в ходе последующего развития процесса в сторону повышения его уровня зрелости. В частности, речь идет о привязке инцидентов к конфигурационным единицам, оценке потерь от простоя и т.д.
Пара процессов «управление конфигурациями» – «управление изменениями» тесно связаны и не могут работать по отдельности. Впрочем, следует уточнить, что для процесса управления конфигурациями необходима только часть процесса управления изменениями – регистрация изменений. Авторизация и реализация изменений не имеют прямой связи с процессом управления конфигурациями. Ключевой параметр, определяющий необходимость процесса – объем изменений, а также относительная значимость работ по реализации изменений и устранению последствий некорректных изменений. Если речь идет об управлении изменениями, то дополнительным фактором является воздействие на бизнес, который теперь может вносить изменения только в рамках формализованной процедуры. В обмен на это бизнес получает более высокий процент успешных изменений и более устойчивую работу ИТ-сервисов. Что касается процесса управления конфигурациями, он обеспечивает информационную поддержку и, следовательно, более производительную работу процессов управления инцидентами и изменениями. В то же время, процесс управления конфигурациями требует значительных единовременных затрат по инвентаризации ИТ-активов и внедрению соответствующей базы данных, поэтому в отношении него вполне применима модель точки безубыточности.
Процесс управления проблемами – еще один инструмент повышения производительности процессов управления инцидентами и изменениями. Соответственно, к нему тоже применим подход точки безубыточности. Наконец, необходимость процесса управления релизами определяется регулярностью применения сложных пакетов изменений. Обычно это имеет место при значительном объеме собственных разработок.
Среди процессов тактического уровня ограничимся рассмотрением управления уровнем сервиса, особо выделив управление каталогом сервисов. Соответственно, под управлением уровнем сервиса в узком смысле будем понимать создание и дальнейшее управление SLA, а также OLA (соглашением об уровне операционной поддержки, Operational Level Agreement) и другими необходимыми контрактами.
Экономическая сущность SLA между предприятием и его ИТ-службой – внутренний аутсорсинг ИТ, поэтому вопрос о целесообразности заключения SLA и, соответственно, процесса управления уровнем сервиса в узком смысле – это вопрос о целесообразности аутсорсинга или постепенного движения к нему. На этом пути есть множество гибридных форм, включая общие центры обслуживания, наличие внутреннего ИТ-провайдера в рамках бизнес-группы и др. В большинстве таких форм SLA целесообразно, более того, необходимо, однако необходимо четко понимать ряд моментов:
? пока не идет речь о полном аутсорсинге, SLA не отменяет прямых поручений и должностных обязанностей, хотя то и другое следует учитывать тем или иным образом;
? работающее SLA означает для ИТ-служб значительный объем накладных расходов по планированию объемов услуг, тарификации, биллингу и т.д. Как следствие, если у бизнеса нет желания двигаться в сторону аутсорсинга, управление уровнем сервиса неизбежно деградирует. Напротив, если бизнес заинтересован в той или иной форме аутсорсинга, SLA необходим и выгоден;
- SLA делает затраты ИТ-службы более прозрачными, сопоставимыми с предложениями внешних провайдеров, что может усилить конкурентное давление на ИТ-службу;
- SLA на уникальные сервисы, специфичные для данного бизнеса, – это terra incognita с высокими рисками как для бизнеса, так и для ИТ-службы.

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

Литература
1. A.Carter-Steel, Wu-Gee Tan, Implementation of IT Infrastructure Library (ITIL) in Australia: Progress and Success Factors, доступна по адресу http://eprints.usq.edu.au/998/.
2. К.Скрипкин, И.Баринов, С.Растопшина, Основание. Каталог ИТ-сервисов в управлении ИТ-службой // Альманах ITSMf Россия. Избранные статьи. М.: ITSM форум, 2010, 140 с.

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