2010/05/17 17:15:29

SLA - Service Level Agreement
Соглашение об уровне качества

Service Level Agreement (SLA) — определяет взаимную ответственность провайдера ИТ-сервиса и пользователей этого сервиса. В соответствии с рекомендациями ITIL Information Technology Infrastructure Library, SLA – это основной документ, регламентирующий взаимоотношения ИТ и клиентов. Цель документа – дать качественное и количественное описание сервисов, как с точки зрения провайдера, так и с точки зрения пользователя.

Содержание

Существенной частью SLA является каталог сервисов.

Service Level Agreement – SLA – это соглашение между заказчиком и исполнителем, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. Соглашение SLA четко прописывает временные рамки для устранения проблем, определяет штрафные санкции, накладываемые на нашу компанию в том случае, если качество услуг оказалось ниже прописанного в договоре уровня. Это позволит минимизировать ваши убытки. Таким образом, заказчик получает удобный способ контролировать услуги, быть уверенным в их полноте и качестве. Уникальность услуги в том, что SLA дает понятный ответ на вопрос «Хорошо или плохо работает служба поддержки?».

Структура

Из чего состоит SLA?

Типовая модель SLA должно включать следующие разделы:

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

В идеале, SLA определяется как особый сервис. Это позволяет сконфигурировать аппаратное и программное для максимизации способности удовлетворять SLA.

Что обязательно стоит включить в SLA?

  • Перечень предоставляемых услуг
  • Предоставляемый объем и время выполнения услуг
  • Приоритеты и нормативное время решения заявок
  • Требования к отчетности и метрики оценки качества сервиса
  • Стоимость услуг, штрафные санкции и условия оплаты

На что еще обратить внимание?

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

  • Назначить координатора со стороны заказчика
  • Прописать взаимную ответственность
  • Ежемесячно мониторить метрики
  • Получать обратную связь от бизнес-экспертов
  • Не забывать о коммуникации с конечными пользователями
  • Фиксировать взаимодействие в Service Desk

От чего зависит стоимость и как не переплатить?

  • Набор, сложность и степень кастомизации приложений
  • Критичность бизнес-процессов
  • Требуемый график работы
  • Орг. структура и территориальная структура заказчика
  • Количество и компетенция пользователей
  • Объем и сложность документооборота
  • Структура отчетности
  • Состояние пользовательской и технической документации

Как еще можно снизить стоимость?

  • Актуализация документации, FAQ
  • Обработка повторяющихся ошибок через обучение или доработку системы
  • Документирование всех изменений в системе
  • Меньше доработок
  • Сбалансированный подход к SLA

Зачем нужны SLA

Вспомним теорию. По ITIL, SLA (Service Level Agreement) – соглашение между поставщиком ИТ-услуг и заказчиком (по умолчанию – между ИТ-подразделением и основным бизнесом компании). В SLA описаны обязательства поставщика и условия предоставления услуг, а также обязанности и возможности заказчика по потреблению услуг. Заключая SLA с бизнес-структурой, ИТ-служба гарантирует предоставление услуги с уровнем качества не ниже согласованного[1].

Из чего состоит SLA?

  • Описание сервисов / услуг, предоставляемых в рамках SLA (часть или весь каталог сервисов, предоставляемых ИТ-службой )
  • Описание условий предоставления сервисов / услуг (вплоть до порядка обработки запросов на определенные услуги)


Фиксируя в SLA условия оказания услуг, мы упорядочиваем наши взаимоотношения с пользователями, определяя – кто, когда и в какой форме подает нам запрос. Невозможно ожидать быстрого выставления счета на поставку, если на входе мы получим запрос «Поставьте нам что-нибудь, желательно в праздничной упаковке». Мы совершенно точно потратим много времени на детализацию запроса. И таким образом, ни о какой оперативности выполнения запросов мы говорить уже не сможем - и не по нашей вине! Так и в области ИТ-услуг: чтобы предоставить доступ к общей папке, нужно знать – к какой именно общей папке нужен доступ; на основании чего мы будем выполнять этот запрос (в соответствие с политикой информационной безопасности) и т.п.Как зародилась масштабная коррупционная схема при внедрении ИТ в ПФР при участии «Техносерва» и «Редсис». Подробности 38.6 т

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


Внедрение Service Desk, безусловно, тесно связано как с определением каталога сервисов, так и с разработкой SLA. Поскольку:

  • без каталога сервисов невозможно очертить зону ответственности ИТ-службы – а значит, грамотно подобрать ресурсы и организовать процессы работы
  • без SLA невозможно задать ориентиры работы ИТ-службы (причем такие ориентиры, которые бы коррелировали с целями бизнеса). А без этого не будет понимания, движемся мы или стоим на месте, то есть насколько мы близки к соблюдению SLA. Куда приложить дополнительные усилия в первую очередь и т.п.

Ошибки

Отсутствие правил расставания

  • Будет ли известно о расторжении заранее?
  • Хватит ли суммы компенсации?

Невнимательность к санкциям

  • Как будет компенсировано нарушение?
  • Является ли ответственность соразмерной?

Нет механизма приостановления / возобновления работы

Неточность условий

  • Какие запросы я буду получать?
  • На какой результат я могу рассчитывать?

Как это сделать?

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

  • Начните с одного / двух SLA для всей компании.
  • Выделите группы пользователей, для которых вы будете предоставлять услуги разного качества, например:
  • SLA для VIP-пользователей:
  • SLA для всех остальных:
  • Выделите критические сервисы, по которым вы считаете необходимым управлять качеством – то есть брать на себя обязательства и выполнять их. НО никогда не беритесь за разработку SLA по всем возможным направлениям сразу.
  • Определите сроки для выделенных SLA. Как это сделать? Вообще, выбор целевых значений критических показателей качества работы (а это и есть разработка SLA!) – действие, изначально вытекающее из процессного подхода к управлению. Господа основоположники такого подхода (например, д-р Э.Деминг) завещают при выборе значений показателей отталкиваться от текущего состояния процесса. Нельзя ставить себе цель – выполнять работу за 20 минут – если текущее состояние процессов дает нам все 20 часов. Все, на что мы можем надеяться в ближайшем будущем – это сокращение на проценты, но не на порядок (так же, как сложно ожидать, что 9 женщин за 1 месяц родят целого ребенка). Другой вопрос, если из 20 часов 19 проходит в ожидании своей очереди. Тогда мы можем кардинально повлиять на изменение процесса.

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

  • Начните измерять фактическое соблюдение параметров качества.
  • Когда станет очевидно, что заявленные в SLA сроки работают не всегда и в 50% случаев нарушаются или бизнес ставит новые задачи, выделяя новые критические сервисы – начинайте детализировать услуги и корректировать условияSLA.

Иногда разговаривая с клиентами, мы слышим: «нет, мы еще не приступили к внедрению Service Desk – сначала разрабатываем SLA. Уже пару месяцев как…». Такой подход имеет безусловное право на существование, но в том случае, если ИТ-подразделение в состоянии установить сколько-нибудь правдоподобные параметры качества для услуг, включенных в SLA. Однако часто мы не можем установить время, за которое готовы отвечать. Для примера: при подготовке нового рабочего места иногда мы тратим неделю, потому что нам нужно что-то покупать, а иногда один день - мы передаем оборудование со склада и пр. Или ключевыми для нас являются новые сервисы, по которым мы пока не можем предположить, сколько времени займет их обслуживание. В этих случаях целесообразно сначала запустить в работу Service Desk без SLA, чтобы получить статистические данные по срокам обслуживания тех или иных сервисов из каталога.

Резюме: при разработке SLA необходимо учитывать несколько ключевых моментов

  • Параметры качества, определяющие, как должны функционировать сервисы – то есть как измерить, достигнута ли ИТ-службой поставленная цель – должны быть измеримы.
  • Установленные параметры должны быть достижимы в текущей жизни ИТ-службы. Такая организация работы само по себе мотивирует персонал. А вот если задача понятна, но недостижима – от нее нет никакого толку.
  • Не всем пользователям должны быть доступны все сервисы и услуги (например, запросить услугу по созданию нового почтового ящика могут только руководители бизнес-единиц; а сообщить об инциденте могут все пользователи). Соответственно, необходимо планировать разработку нескольких SLA с разными группами пользователей
  • Разные сотрудники компании требуют разных условий оказания одних и тех же услуг. Например, допустимо устранять сбой в работе ПК на рабочем месте секретаря за 4 часа. А рабочий ПК директора не может простаивать более получаса. И правила, от чего зависит характер обработки запроса, мы тоже должны учесть в SLA. Стрелочки.PNG
  • Для любого обращения в ИТ-службу важным является набор входящей информации. Таким образом, в SLA должны включаться параметры входящей информации, являющиеся обязательным условием, обеспечивающим выполнение ИТ-службой своих обязательств.
  • Предусмотреть способы измерения фактических параметров качества.

Постепенно двигаясь вперед (всегда - по необходимости бизнеса, не по собственной фантазии), вы достигнете того баланса, когда:

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

Примечания