Портал №1 по управлению цифровыми
и информационными технологиями

Что писать в 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 работают.

Комментариев: 7

  • Любопытно, что нет срока действия. Или это считаетсся частью пункта 16?

    Не менее любопытно, что в SLA не указаны потребители услуги. Даже и не знаю, что думать на этот счет 😉

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

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

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

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

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

        Ага. В отдельной. Со всеми удобствами.

         

  • Grigory Kornilov

    🙂 и погромисту и его высокой крыше интересны пункты 9, 11, 15, 18.

    Вообще-то если брать PMBOK, то в ней затрагиваются многие пункты.

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

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

      • Grigory Kornilov

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

        вместо "Ответственный за услугу" – Первичный контакт для эскалации, так как я не понимаю чем\перед_кем указанная персона будет ответственна.

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

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

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM