Состав SLA

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

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

Третье. Решение инцидентов. Описываются параметры реакции сотрудников ИТ на недоступность функционала из первой группы. Чаще всего — в зависимости от приоритета и влияния инцидента.
В принципе, достаточно нескольких цифр. например — Критичный Инцидент — 2 часа, остальные — 8 часов. Определение уровня критичности лучше вынести в отдельный процесс — Управление Инцидентами, а из SLA ссылаться на него.

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

И очень рекомендую — всю «водяную» (договорную) часть выделить в отдельный документ. И превратить SLA в «Приложение», содержащее 1-2 страницы (4 вышеперечисленные таблицы). В некоторых организациях это позволит сократить сроки согласования в десятки раз.

И, чтобы не быть голословным, вот пример такого приложения к SLA (обезличенный кусок документа с одного очень старого проекта): _[Приложение] Параметры SLA ШАБЛОН (1.0)

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

Ваш e-mail не будет опубликован.