Что писать в SLA?

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

  1. Описание услуги. Автоматизируемая деятельность предприятия.
  2. Охват. Территория, организационные подразделения, типы автоматизируемых операций. Охват содержит разграничение ответственности предприятия и поставщика услуги. «Стрижку сделает парикмахерская, укладку каждый день – клиент».
  3. Режим предоставления услуги.
  4. Функциональность, включая допустимое количество ошибок. Используется для определения доступности.
  5. Доступность.
  6. Надежность.
  7. Мощность (время отклика, толщина канала связи, квота данных, скорость вычислений, количество пользователей и т.д. и т.п., насколько хватает фантазии и способов измерения).
  8. Непрерывность. Здесь ссылка на планы поведения в чрезвычайных ситуациях.
  9. Безопасность. Ссылка на правила, политики, и разграничение ответственности сторон.
  10. Поддержка пользователей. Режим работы поддержки, время реакции, время решения – вот это вот всё.
  11. Контактные данные ответственных за услугу.
  12. Управление изменениями в услуге. Ссылка на соответствующие процессы и модели.
  13. Управление документацией по услуге (оно в ITIL экзотично названо «Печать», видимо, рудимент с царских времен).
  14. Обязанности сторон. Поставщика услуги, заказчика, пользователей.
  15. Оплата. Формулы, штрафы, частота оплаты, предоплата и т. д.
  16. Отчетность и порядок пересмотра услуги, включая расписание встреч по пересмотру или продлению SLA.
  17. Лист исправлений.
  18. Подписи сторон.

Мне сейчас, после прочтения множества статьей, дискуссий и интервью на тему SLA, хочется записать количество пунктов в ответе на вопрос «Что должно быть зафиксировано в SLA на ИТ-услугу?», по которому можно угадать «точку зрения» собеседника на ITSM:

  • До трех пунктов: погромист, технарь или высо-окий руководитель. Им интересны проекты, SLA к проектам отношения не имеет. «Сервис – он и есть автосервис», «услуги не предлагать».
  • 4-6 пунктов: методолог, консультант, владеет картиной мира ITSM. «Ценность – это полезность плюс таки гарантия!».
  • 7 и более пунктов: Прикладник. Опытный консультант. CIO. Можно и нужно слушать такого. На практике при создании контракта на услугу он, правда, ограничивается только двумя-тремя пунктами, но, как ни странно, его SLA работают.

CleverKPI Сбалансированная система управления информационными технологиями по KPI

Измерение и оценка эффективности ИТ-процессов, проектов и услуг.
 

Узнайте больше!

Комментарии и мнения

    1. Константин Нарыжный Автор

      Срок — ну там еще шапка есть типа "данное соглашение заключается сроком на 12 месяцев, с ежегодным пересмотром". Но я, формально в п. 16 конечно же поместил.

      Потребители — частный случай п. 2, а может быть и п. 9. А может быть и п. 14. Зависит от услуги.

      Даже и не знаю, что думать на этот счет ;)

      Наводит на мысли о том, что вы в четвертой группе собеседников, которым глупые вопросы задавать не надо.

    1. Константин Нарыжный Автор

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

      PMBOK вообще оч. крут. но вот там про инциденты как раз чуть меньше, зато пункт 12 во весь рост.

        1. Константин Нарыжный Автор

          имхо штрафы являются неотъемлемой частью SLA.

          Ну да, 15 пункт.

          вместо "Ответственный за услугу" — Первичный контакт для эскалации

          Соглашусь. А еще может быть ответственный за подписание и оценку SLA. Перед своей организацией, очевидно.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26