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

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

Определенность результата

Уровень ИТ-услуги измеряется параметрами качества и объема услуг, которые подробно рассматриваются в [1].

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

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

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

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

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

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

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

Путь к SLA как развитие ИТ-службы

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

Барьер первый: знание фактических уровней услуг

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

Усложняет задачу учета то, что один инцидент может повлиять на множество услуг сразу, например, выход из строя RAID-массива сказывается на всех услугах, данные для которых хранятся на нем. Проставление признаков множества услуг в записи одного инцидента может оказаться чрезмерно трудоемким для оператора Service Desk, обрабатывающего десятки и сотни обращений в день. Для упрощения учета инцидентов необходимо ввести понятие группы услуг и связывать такую группу с каждым критически важным устройством или приложением.

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

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

Таким образом, для корректного учета фактических уровней услуг необходимы функция Service Desk, процесс управления инцидентами и процесс управления изменениями. Появление последнего, в свою очередь, влечет за собой внедрение процесса управления конфигурациями (о взаимосвязи управления инцидентами и управления конфигурациями в модели ITIL/ITSM см. [2]).

Барьер второй: реакция на изменения

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

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

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

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

Барьер третий: управление затратами

Управление затратами и — шире — ресурсами ИТ-службы, также критически важно для действенности SLA в организации. Взаимные обязательства заказчика и ИТ-службы должны уравновешивать требования к уровням обслуживания и ресурсы, выделяемые ИТ-службе. Ключевой ресурс — бюджет, роль которого возрастает по мере роста потребления внешних услуг. Этот ресурс в модели ITIL/ITSM контролирует процесс управления финансами.

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

Рассмотрим поясняющие примеры. Допустим, компания X основывает филиал в г. Новосибирске. В связи с разницей во времени (три часа между Новосибирском и Москвой), время обслуживания электронной почты увеличивается с 8*5 до 11*5. Это означает появление дополнительной смены операторов Service Desk, а также дежурство инженеров ИТ-службы, поддерживающих электронную почту. Форма дежурства может быть различной и определяется требованиями к доступности услуги, с одной стороны, и развитостью инфраструктуры ИТ (например, наличием средств удаленного администрирования), но та или иная форма дежурства необходима.

Другой пример. Компания Y внедряет систему SAP R/3. По завершении проекта ей потребуется команда специалистов, способных в дальнейшем поддерживать систему. Основных направлений три: администрирование и безопасность, функциональный блок (доработка внедренной функциональности системы, в частности, отчетов), ведение нормативно-справочной информации. Расходы на этих специалистов следует учесть при планировании бюджета соответствующих услуг.

Барьер четвертый: политика в организации

Переход к SLA делает ИТ-службу равноправным партнером бизнес-подразделений, связанным с ними рыночными или квазирыночными отношениями (см., например, хозрасчет ИТ-департамента в статье А. Авакяна «От центра затрат к центру прибыли», Директор ИС, № 8, 2005). Такая роль ИТ-службы резко отличается от роли обслуживающего подразделения, до сих пор характерной для многих российских организаций.

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

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

Не только барьеры: путь к SLA и развитие ИТ-службы

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

Дальнейшее движение

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

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

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

Литература:
  1. Service Delivery, London: the Stationary Office, 2001.
  2. Service Support, London: the Stationary Office, 2000.
Параметры качества ИТ-услуги в модели ITIL/ITSM:
  • содержание услуги — выполняемая задача;
  • время обслуживания — период времени (8*5, 24*7 и т. д.), в течение которого служба ИС отвечает за сопровождение ИТ-услуги;
  • доступность — процент времени обслуживания, в течение которого услуга фактически доступна пользователю (т. е. исключая время простоя);
  • надежность — количество инцидентов за определенный срок в течение согласованного времени обслуживания;
  • производительность — число бизнес-операций (т. е. введенных документов, полученных отчетов и т. д.) в единицу времени;
  • устойчивость — время восстановления услуги (полного или частичного) в случае повреждения или уничтожения инфраструктуры ИТ;
  • конфиденциальность — уровень защиты данных и требования к разделению доступа к нормативно-справочной информации, документам и операциям.
Параметры объема ИТ-услуги:
  • число пользователей услуги;
  • число обслуживаемых рабочих мест, причем стационарные и мобильные рабочие места могут рассматриваться раздельно;
  • число рабочих мест распределенной ИС, например, SAP R/3 или Oracle Business Suite;
  • общее число часов обслуживания (например, для такой услуги, как видеоконференц-связь);
  • объем трафика и др.