Документирование соглашений об уровне сервиса

Документ – SLA – должен быть в простом и легком для понимания формате, он должен быть разработан таким образом, чтобы все заинтересованные стороны могли легко рассмотреть его и ознакомиться с требованиями, указанными в нем.

Приложение D в этом руководстве содержит шаблон SLA. SLA должно включать:

· Стороны. Для SLA: ИТ и бизнес; для OLA: ИТ и ИТ.

· Сроки. Срок, в течение которого SLA будет действовать, например, один или два года. Очевидно, что срок может обновляться и при необходимости. Например, если бизнес работает на проектном основании, а проект не работает больше, чем один год, то один год - разумный срок для SLA.

· Диапазон. Охватываемые сервисы и бизнес-области.

· Ограничения. Рассмотрите предоставляемые услуги. Могут существовать ограничения, например, количество пользователей в режиме онлайн или разумные часы использования, которые могут затронуть SLA. Эти ограничения должны быть отмечены, чтобы ожидание сервиса было практичным.

· Целевые параметры уровня сервиса. Эти параметры должны быть простыми и в относительно небольшом количестве, чтобы сосредоточиться на самых важных целях.

· Индикаторы. Что определяет успех или неудачу цели? Убедитесь, что вы используете бизнес-терминологию для этого, даже если вовлечена технология,например, количество переданных пакетов – ничего не означает для менеджера по финансам..

· Исключения. Все, что не включено, например, скоростной цветной принтер может быть включен в SLA, а принтер для чеков – нет.

· Отчетность. Какие отчеты будут создаваться для поддержки SLA, когда, кем, как отчеты будут раздаваться, и какие метрики будут измерены?

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