Ключ к качественному управлению уровнем услуг

В методологии ITIL имеется четкое определение процесса управления уровнем услуг, и подробно описывается сам процесс, его внедрение и содержание ключевого понятия, а именно Соглашения об Уровнях Сервиса (SLA). Вопрос в том, действительно ли SLA является ключевым понятием?

ITIL не описывает так подробно ни одно из других понятий управления уровнями уервиса, как, например, Требования к Уровням Сервиса (SLRs), Соглашения об Уровнях Функционирования (OLAs), Контракты со Сторонними Поставщиками (UCs) или сервис-каталог.

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

Соглашения об уровнях сервиса

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

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

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

Oбщий недостаток многих организаций- неспособность создавать простые и краткие соглашения. SLA не должен состоять более, чем из 3-х– 4-х страниц, а уж тем более 20-ти, как это часто бывает.

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

Используйте простые, достижимые правила в процессе содания показателей, относящихся к SLA, OLA and UC. Большинство организаций тратят много времени на создание SLA, которые на самом деле неизмеримы и не дают понимания того, каким образом предоставляется услуга. Время, потраченное на создание таких документов, потрачено впустую.

Требования к уровням сервиса

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

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

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

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

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

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

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

Соглашения по уровням функционирования

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

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

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

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

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

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

Контракты со сторонними поставщиками

Контракты со сторонними поставщиками (UCs)- это контракты со сторонними организациями по ИТ поддержке вашей организации. Важно постоянно обновлять их и подтверждать, что сторонняя компания предоставляет требуемый уровень услуг. Эти документы отличаются от соглашений типа OLA и SLA, потому что UC-cоглашения являются контрактами. Единожды прописанные в контракте и подписанные, поставленные цели должны быть выполнены, так как невыполнение их может привести к юридическим санкциям.

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

Сервис-каталог

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

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

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

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

Сервис-каталог может быть оформлен по-разному (Word, Excel и т.п.). ITIL предлагает руководство по типу информации, отражаемой в сервис-каталоге; но, возможно, вам пригодятся такие дополнительные пункты для придания большей ценности каталогу внутри ИТ организации:

  • Название сервиса
  • Краткое описание сервиса
  • Основные бизнес-пользователи
  • Важность сервиса
  • Основные области поддержки
  • Планируемая поддержка/отсутствие поддержки
  • SLA (в наличии и там, где он расположен)

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

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

    Заключение

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

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

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

    Если SLA- это ключ к успешному внедрению управления уровнем услуг, то понятия, описанные выше, подобны мастеру, который подгоняет этот ключ под замок самого процесса.

    Карстен Смэт изучал ИТ и управление бизнесом в Лидсе и закончив ее с отличием начал свою карьеру в компании British Airways в качестве специалиста ИТ. В этой компании он занимался поддержкой приложений, системным дизайном и управлением сервисом.

    В последнее время Карстен занимается вопросами внедрения процессов ITIL и разработкой интегрированного руководства по управлению сервисом.Он работает одним из двух консультантов по управлению сервисом в British Airways.

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

    Karsten Smet, 15 августа 2005. Перевод Виталия Фролова
    URL: http://www.itsmwatch.com/itil/article.php/3319041

  • Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

    Комментарии закрыты.