itSMF Russia :: Ассоциации организаций и специалистов в сфере управления информационными технологиями «ИТ сервис-менеджмент форум» баннер
НОВОСТИ УЧАСТИЕ В АССОЦИАЦИИ ОБ АССОЦИАЦИИ БИБЛИОТЕКА СОБЫТИЯ ДЛЯ УЧАСТНИКОВ ТРЕБУЮТСЯ СПЕЦИАЛИСТЫ БЛОГИ

баннер

 

баннер

 

поделиться

 

поделиться

Присоединиться к ITSM сообществу


Состав itSMF Russia

 


книжный магазин itSMF



Подпишитесь на новости ITSM-сообщества

* обязательные поля
Архив рассылок >>>



facebook linkedin баннер twitter



Реестр аккредитованных учебных центров, работающих в Российской Федерации и имеющих право проводить обучение по утвержденному списку курсов ITIL®


Manager’s Certificate in IT Service Management Список ITIL Expert'ов и сервис-менеджеров России и стран СНГ



Список российских профессионалов сервис-менеджмента, обладателей сертификатов priSM




Работа для Вас: актуальные вакансии


Практический опыт написания SLA
Untitled Document

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

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

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

Структура документов была выбрана на основе следующих источников:
1. Как правильно составить SLA в ИТ?
2. How to establish and maintain service level agreements
2. Sample SLA templates
3. Типовой состав SLA (от R-Style)
4. Описание контракта SLA от IBS

А также множества других примеров в основном заграничных каталогов, найденных на просторах интернета.

И вот что получилось:

Соглашение об уровне предоставляемых услуг

Версия: 1.1
Дата создания: 19.05.2009
Дата последнего изменения: 21.06.2009


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

2.Субъекты действия соглашения
   Данное соглашение распространяется на все ИТ-сервисы, предоставляемые службой, в соответствии с Каталогом сервисов.

3.Условия функционирования
   Время работы. График работы службы поддержки пользователей:
понедельник-пятница 9:00-18:00.
   Дополнительные рабочие часы. Вне графика рабочих часов персонал службы устраняет инциденты только в периоды проведения специальных работ. Временные изменения графика дежурств согласовываются руководителем подразделения, которому необходима поддержка сервисов в дополнительное время, с руководителем службы.
   Обработка неподдерживаемых заявок. В случае если в службу поддержки пользователей поступает заявка на устранение проблемы с сервисом, не входящим в список ИТ-сервисов, перечисленных в Сервисном каталоге, персонал службы постарается дать контакты лица, который мог бы помочь с решение проблемы.

4.Установка приоритетов и классов заявок
   Заявки имеют 5 уровней срочности (приоритетов), определяющих время реагирования на них сотрудников службы:
   Уровень 5 (наивысший) – Проблема затрагивает большую часть сотрудников организации, либо ключевых сотрудников компании. Например, возникла проблема в серверной комнате, затрагивающая несколько основных серверов.
   Уровень 4 (высокий) – Проблема, затрагивающая группу сотрудников. Например, нет связи с филиалом, нет связи с сервером.
   Уровень 3 (средний) – Проблема, затрагивающая одного сотрудника. Например, неработоспособность компьютера, сетевого принтера.
   Уровень 2 (низкий) – Проблема, возникающая у пользователей временно. Например, неработоспособность некритичного оборудования.
   Уровень 1 (минимальный) – Проблема, возникшая единовременно и не связанная с основными производственными процессами компании.
   Кроме того, время реагирования на заявку должно отличаться для различных групп ИТ-сервисов, поэтому на этапе регистрации заявки необходимо классифицировать поступившую заявку по типу ИТ-сервиса, который она затрагивает. Для этого все ИТ-сервисы, представленные в Сервис Каталоге, были разделены на следующие классы по степени важности:
   Класс 0 – Сервисы, критические для работы большинства сотрудников компании. К ним относятся коммуникационная инфраструктура (непосредственно локальная сеть). Проблемы с сервисами этого класса приводят к невозможности взаимодействия одного или нескольких компьютеров в сети с другими компьютерами сети компании.
   Класс 1 – Сервисы, критические для работы групп пользователей. К ним относятся все заказные сервисы и подписные, за исключением интернета и электронной почты. Проблемы с сервисами этого класса приводят к невозможности выполнения специальных задач пользователем.
   Класс 2 – Сервисы, критические для работы одного пользователя. К ним относятся все базовые сервисы за исключением коммуникационной инфраструктуры, а так же интернет и электронная почта. Проблемы с сервисами этого класса влияют на работу одного пользователя.
   Время реагирования для заявок с различными приоритетами и классами представлено в Приложении. При превышении заданного времени происходит уведомление менеджера инцидентов и руководителя службы, которые предпринимают все возможные действия для скорейшего устранения инцидента: привлечение дополнительных или более квалифицированных специалистов для устранения инцидента (иерархическая и функциональная эскалация), привлечение специалистов сторонних организаций, принятие решения о необходимости инициирования изменения или проблемы и другое.

5. Целевые уровни качества сервиса
   В разделе приведены определения и величины основных целевых уровней качества предоставляемых сервисов. При необходимости возможно введение дополнительных показателей.
   a)доступность сервиса – число сбоев в период обслуживания;
Для сервисов 0 класса – минимально. Не более 1 в год.
Для сервисов 1 класса – не более 2 в год.
Для сервисов 2 класса – не более 3 в год.
   b)средняя длительность сбоя сервиса – длительность времени, в течение которого он недоступен потребителю;
Для сервисов 0 класса – минимально. Не более 1 часа.
Для сервисов 1 класса – не более 3 часов.
Для сервисов 2 класса – не более 5 часов.
   c)время отклика сервиса – время ожидания, прошедшее после вызова сервиса;
Для сервисов 0 класса – минимально. Должно быть незаметно пользователем.
Для сервисов 1 класса – Не более 1 секунды. Заметно, но не мешает работе.
Для сервисов 2 класса – Не более 2 секунд. Заметно, но пользователь может продолжать работу.
   d)текущая пропускная способность – пропускная способность канала, оцененная в данный момент. Используется для сравнения со средней пропускной способностью;
   Отчеты по данным целевым показателям готовятся по требованию пользователя. При необходимости инициируется заявка на устранение инцидента, который снижает уровень предоставляемых услуг.
   Кроме того, так же могут быть рассчитаны показатели качества работы службы поддержки. К ним относятся:
a)Количество заявок, поступивших за контрольный интервал времени;
b)Распределение полученных заявок по сервисам, которые они затронули, по классам заявок, подразделениям, уровням срочности;
c)Процент успешно выполненных заявок;
d)Соотношение инцидентов и запросов на изменения в заявках;
e)Среднее время выполнения заявки, полученное для различных классов заявок и уровней их срочности;
f)другие по необходимости.
   Данное Соглашение призвано обеспечить разрешение возникающих инцидентов с заданным уровнем качества в установленные сроки сотрудниками службы. Отчеты по качеству и объемам работы Службы поддержки пользователей готовятся по необходимости и позволяют оптимизировать процесс устранения инцидентов.

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

   Приложение. Выделенное время решения инцидентов
   Разделение по классам предусмотрено, но не организовано. Время, выделенное на решение инцидентов с различными степенями срочности, представлено в таблице.
  Наивысший уровень срочности Высокий уровень срочности Средний уровень срочности Низкий уровень срочности Минимальный уровень срочности
Время, выделенное на решение инцидента 4 часа 8 часов 1 рабочий день 5 рабочих дней 10 рабочих дней

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

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

На основе этого документа были сделаны настройки системы – заданы времена реакции в зависимости срочности инцидента. Наличие четко определенных параметров устранения инцидентов позволяет обращать внимание на узкие места системы и четко выделять их в отчетности.

Упрощенное содержание SLA стало приложением к регламенту использования системы.

Как и в случае с каталогом сервисов после написания SLA вышло довольно много интересных и полезных статей. Среди них можно отметить:

1. Redefining SLAs in the Midmarket, Michael Singer в internetevolution.com
2. The service level agreement is a living document, John Cusimano на ITSMPortal.com

 

Источник: itil-ist.livejournal.com



Помогите своим коллегам быть в курсе интересных новостей! Поделитесь!
Документ без названия


 

Приглашаем принять участие
в воркшопе ITSM Labs
баннер


баннер


баннер


Партнеры itSMF России



 Директор информационной службы
 

Information Management

Открытые системы



Московское отделение ISACA

ABPMP Russian Chapter

GlobalCIO

СоДИТ

SPb CIO Club — партнер itSMF России

Высшая школа бизнес-информатики Государственного университета – Высшей школы экономики (ВШБИ)

МИИТ

ГУУ

Московский государственный университет экономики, статистики и информатики (МЭСИ)

Факультет ВМК МГУ имени М.В. Ломоносова

Московский институт электроники и математики (МИЭМ)

Институт информационных бизнес систем



Блоги: