Что такое SLA

Повысить эффективность работы IT-компании или подразделения можно разными способами. Один из наиболее популярных – упорядочивание бизнес-процессов. Помимо модернизации технической базы, это направление включает внедрение соглашения об уровне услуг (многим привычнее его англоязычное наименование: SLA, Service Level Agreement). Оно считается базовым инструментом непрерывной оценки и управления качеством услуг.

Что такое SLA

Изначально термин «SLA» стали употреблять в ИТ-отрасли. Понятие пришло из методологии ITIL (IT Infrastructure Library), но сейчас его трактуют шире. Под соглашением об уровне обслуживания понимают документ с правилами, которые обязан соблюдать исполнитель при заключении договора сотрудничества. Например, оговаривается скорость реакции на инциденты, уровень доступности сервисов, иные детали.

Основные критерии договора SLA:

  1. Прозрачность. Исключаются расплывчатые формулировки. Обе стороны общаются «на одном языке», с применением одной и той же терминологии.
  2. Четкое распределение обязанностей. Оговариваются конкретные рамки ответственности как исполнителя, так и заказчика, их взаимодействие.
  3. Ограничения завышенных требований. Сервисы предоставляются с учетом времени суток, праздников, иных условий, когда неизбежны задержки и пр.

Соглашением SLA обычно предусматриваются штрафы за метрики, не соответствующие договору.

Одновременно исполнитель защищен от возникновения новых требований со стороны заказчика в рамках действующих обязательств.

Стороны вправе заключить дополнительное соглашение, чтобы «перекрыть» потребность в услугах, например, при расширении IT-инфраструктуры, при изменении технического обеспечения.

Для чего нужно SLA

Благодаря соглашению SLA потребитель однозначно понимает, какой уровень сервиса ему будет предоставлен при заключении договора. В нем прописывают инциденты, которые исполнитель обязан оперативно устранять, не допускать, если имеются технические возможности. Формально технология пригодна для всех компаний, оказывающих услуги, особенно, в формате аутсорсинга (IT, телекоммуникации и т.д.).

Типовые моменты, какие оговариваются договором:

  • Период времени, в течение которого исполнитель обязан отреагировать на инцидент.
  • Порядок урегулирования спорных ситуаций, требующих отдельного внимания.
  • Правила подачи/обработки заявок, при соблюдении которых гарантируется качество.
  • Ответственность сторон за вероятные убытки заказчика или доп. расходы исполнителя.
  • Перечень, характеристики аппаратного и программного обеспечения у клиента.

Также оговариваются сроки и порядок оплаты услуг.

Механизм формирования стоимости заведомо согласован и ни у кого не вызывает вопросов. Если простои возникают по вине исполнителя, то он, как минимум, частично компенсирует их клиенту. По договору каждый заказчик закреплен за конкретным менеджером. Такой подход дополнительно упрощает взаимодействие, т.к. нет затрат времени на изучение специфики обращений.

Типовой договор

Важно учитывать, что соглашение SLA может выступать как приложение к основному договору, так и в качестве самостоятельного документа. Все зависит от типа оказываемых услуг, какие именно задачи берет на себя исполнитель. Например, полный цикл обслуживания IT-инфраструктуры или только мониторинг «облачной части», вопросы поддержания работоспособности сервиса для клиентов, внутренних служб.

Типовой состав договора:

  • Процессы оказания и использования услуг.
  • Меры по восстановлению после технических сбоев.
  • Зоны ответственности Заказчика и Исполнителя.
  • Сроки действия заключенного соглашения.

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

Чем подробнее разобран пошаговый алгоритм взаимодействия, тем эффективнее внедрение SLA. Отдельное внимание рекомендуется уделять критериям оценки, так называемым KPI, Key Performance Indicators (ключевым показателям).

Характеристика SLA

Простота, измеримость метрик, отражающих уровень качества услуг – это суть SLA.

Их легко перенести в цифровой вид, рассчитывать автоматически на базе непрерывно поступающих данных из доступных источников IT-инфраструктуры. Такой результат объективен и не оспариваем. В соглашении можно определить, как абсолютные значения показателей, так и относительные, в виде тех же коэффициентов.

Особенности определения критериев:

  • Разные отрасли требуют разных KPI (и разного количества) для оценки уровня качества.
  • Важно заранее определить приоритеты инцидентов, особенно, при большом объеме заявок.
  • Наиболее критичны во всех отраслях доступность услуги, время реакции и оценка работы.

Так, для пользователей интернета важно постоянство доступа в сеть на оговоренной скорости. Если речь идет о хостинг-провайдере, критичной будет стабильность работы сайта, облачного сервиса. И их пропускная способность, надежность при пиковых значениях количества пользователей. Чтобы избежать недоразумений, рекомендуется хотя бы 1 раз в год актуализировать условия соглашения и задавать параметры, соответствующие действительности.

Параметры SLA

Выбор метрик, оптимальных в конкретной ситуации, требует понимания предметной области. При отсутствии профильных специалистов заказчику рекомендуется привлекать к работе сторонних, на мнении которых можно составить объективную картину. Наиболее востребованным считают время реакции и период решения проблемы, но надо учитывать и объективные «ограничения». Например, обновление программного обеспечения лучше проводить ночью.

Независимо от отрасли хорошо работает составление метрик по схеме SMART:

  1. S (Specific) – конкретность.
  2. M (Measurable) – измеримость.
  3. A (Achievable) – достижимость.
  4. R (Relevant) – значимость.
  5. T (Time-bound) – ограниченность по времени.

Всё просто.

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

Преимущества SLA

Первое, к чему стремятся при переходе на SLA при обслуживании, это гарантии качества. Клиенту важно понимать, за что он платит, какие услуги он сможет получить через полгода… Исполнитель же получает конкурентные преимущества, лояльность заказчиков. Результаты деятельности можно

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

Есть еще преимущества:

  • Простой контроль исполнения заказчиком, руководством исполнителя, сторонним лицом, если оно приглашено в качестве независимого эксперта.
  • Быстрое масштабирование услуг при расширении компании, например, открытии филиалов или увеличении производственных мощностей.
  • Минимальные затраты на упорядочивание спорных вопросов, финансовую ответственность стороны оговаривают заранее, как и порядок ее применения.

Если бизнес-процессы позволяют, можно договориться об оплате «по результату» и согласовать ряд промежуточных параметров, при достижении которых сумма будет умножаться на повышающий или понижающий коэффициент. Соглашение SLA упорядочивает и процессы внутри организации-исполнителя, позволяет ввести объективную систему мотивации персонала. Например, наконец-то ввести уровни предоставления услуг, разделить обращения по срочности и т.п.

Как правильно составить SLA

Текст соглашения обычно начинается с вводной части. К ней относится глоссарий, определяющий, объясняющий используемые далее термины. Там же рекомендуется указать тип программного обеспечения, данные лиц, участвующих во взаимодействии: в том числе ключевых пользователей, работников различных уровней поддержки (1-го, 2-го и т.д.). На следующем этапе надо определить ограничения SLA, что поможет заранее установить сроки реагирования/исполнения.

Задачу составления соглашения упростят рекомендации:

  • Ведите историю версий, заполняйте лист согласования изменений с фиксацией причин.
  • Четко указывайте границы предоставления услуг вплоть до адреса офисов (удаленно).
  • То же относится к графику, доступности сервисов в течение суток, дней недели.
  • Составляйте подробный перечень услуг с типовым наименованием каждой.
  • Выставляйте приоритетность (низкая, нормальная, высокая, высшая).

Будет полезным приводить примеры услуг, на которых показывать, что входит в них, а что нет. При указании ряда критериев лучше использовать нумерованные списки, их легче воспринимать, чем «сплошной текст». Чем меньше вопросов возникает при прочтении итогового текста, тем проще будет работать в дальнейшем. Форс-мажоры нужно стараться спрогнозировать заранее вместе с действиями, нацеленными на ликвидацию последствий.

Пример договора

Кратко рассмотрим вариант соглашения SLA, предлагаемого условным исполнителем «IT-аутсорс». Отдельно оговариваются услуги по инсталляции/обновлению софта, его технической поддержке. По каждому виду работ определяется «относительный» график в виде количества дней/часов от момента подачи заявки.

Пример:

Исполнитель обязуется оказывать Заказчику услуги сопровождения программного обеспечения 1С «Управление производства» 8.3, инсталлированного у Заказчика на следующих компьютерах:

  1. Сервер №1 (характеристики).
  2. Рабочая станция №1 (характеристики).
  3. Рабочая станция №2 (характеристики).

Период оказания услуг – от «___» ______ ___г. до «___» ______ ___г. Перечень услуг с временем исполнения и ограничением по объему указаны в нижеприведенной таблице.

Наименование услуги Время предоставления* Объем
Консультации пользователей по вопросам использования модулей «Приемка на склад», «Отгрузка со склада» 24/7 Без ограничения
Консультации пользователей по остальным вопросам, касающихся применения ПО С 9:00 до 19:00, только в рабочие дни Без ограничения
Контроль регулярных процедур, предусмотренных регламентом обслуживания 24/7 Без ограничения
Мониторинг работоспособности интеграций ПО со складским оборудованием 24/7 Без ограничения
Мониторинг, поддержание работоспособности сервера 24/7 Без ограничения
Корректировка прав доступа к программному обеспечению С 9:00 до 19:00, только в рабочие дни Без ограничения
Исправление ошибок программного кода, доработки по техническому заданию Заказчика С 9:00 до 19:00, только в рабочие дни Без ограничения
Обновление программного обеспечения С 9:00 до 19:00, только в рабочие дни Не более 3 раз в год
Разрешение вопросов, не относящихся к согласованному перечню услуг С 9:00 до 19:00, только в рабочие дни Не более 40 часов в месяц

* Время указано по часовому поясу МСК.

В перечень не поддерживаемых Исполнителем задач входит:

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

Способы взаимодействия Исполнителя и Заказчика: система Service Desk, телефон 8(ХХХ)ХХХ-ХХ-ХХ, электронная почта mail@domen.ru. Конкретные учетные данные для доступа в программу создания/обработки тикетов согласуются регламентом.

Ответственность Заказчика

Заказчик обязан:

  • Заказчик предоставляет Исполнителю доступ к серверу, где инсталлировано программное обеспечение, которое предстоит обслуживать.
  • Заказчик предоставляет Исполнителю копию обслуживаемого программного обеспечения для моделирования ситуаций, какие требуют вмешательства специалистов.
  • Заказчик предоставляет Исполнителю серверные ресурсы, необходимые для развертывания окружения при доработках программного обеспечения.
  • Исполнитель получает доступ к контролю редактируемого кода программы для переноса ответственности за работоспособность ПО на Исполнителя (с блокированием функционала самостоятельного внесения изменений Заказчиком).
  • Взаимодействие в рамках услуг, указанных в настоящем соглашении, будет происходить через назначенного Координатора (ФИО, контакты).

Заказчик имеет право:

  • Запрашивать у Исполнителя сведения по статусу открытых заявок.
  • Письменно сообщать Исполнителю о выявленных недочетах в его работе.
  • Согласовывать с Исполнителем нововведения в договоре SLA.

Приоритеты

Приоритет заявок определяет специалист Исполнителя, исходя из сложности/срочности задачи. Норматив исполнения указан в таблице.

Приоритет Время решения Доля просроченных заявок Вид заявки
Критический Не более 1 часа Не более 15% Сбои в ПО или в работе сервера, мешающие нормальной эксплуатации системы
Высокий Не более 3 часов Не более 20% Консультации Исполнителя в рамках бизнес-процессов, переданных Исполнителю на обслуживание.

Мониторинг интеграций программного обеспечения с оборудованием, их восстановление при сбое.

Контроль выполнения регламентных процедур, направленных на профилактику технических сбоев.

Средний Не более 14 часов Не более 20% Консультации Исполнителя по эксплуатации программного обеспечения, по вопросам, выходящим за рамки настоящего соглашения.

Изменение прав/ролей пользователей по заявке Заказчика

Низкий Не более 36 часов Не более 20% Исправление недочетов в программном коде.

Внесение доработок согласно технического задания Заказчика.

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

По отдельному соглашению сторон приоритет определенного вида заявок может быть изменен на любой из имеющихся. Время решения заявки начинается с момента ее регистрации в Service Desk и получения соответствующего уведомления. Из общего периода вычитается нерабочее время и время, пока заявка находится на стороне пользователя:

  1. Ожидание уточнений.
  2. Согласование проводимых работ.
  3. Тестирование Заказчиком результата.

Просроченные заявки фиксируются для определения соблюдения согласованных KPI. Расчет их доли осуществляется как определение отношения «проблемных» к общему количеству.

Отчетность

Отчеты предоставляются Заказчику в электронном виде и предназначены для оценки качества услуг за отчетный период. Для удобства восприятия показатели представлены в виде таблицы с разбивкой по приоритету:

  • Общее количество заявок.
  • Среднее время их исполнения.
  • Доля просроченных.
  • Полный перечень закрытых заявок.
  • Остатки открытых заявок на следующий период.

Отчет предоставляется ежемесячно до 5 числа каждого последующего месяца. Они оформляются как приложение к акту выполненных услуг, подписываются Исполнителем и Заказчиком. В случае выявления несоответствия KPI согласованным, Исполнитель выплачивает штраф в соответствии со следующей таблицей.

Исполнение от Исполнение до Штраф (% от стоимости услуги)
0,8 1 0
0,6 0,79 5
0,4 0,59 10
0 0,39 20

Штрафы могут начисляться только со второго месяца сотрудничества. Первый месяц признается сторонами ознакомительным, когда Исполнитель нарабатывает компетенции с учетом специфики IT-инфраструктуры Заказчика.

Разница между SLA и SLO

При заключении соглашения об уровне услуг придется столкнуться с термином SLO, Service Level Objectives. Он представляет собой отдельный договор по конкретному показателю. На основании таких дополнительных соглашений и формируется ожидания клиентов, цели, каких надо достичь и на какие показатели ориентироваться в своей работе. Здесь также важно соблюдать правило четкого формулирования, изложения простым языком.

Заключение

Соглашение SLA, об уровне обслуживания, дает гарантии получения конкретного перечня услуг в согласованные сроки, в заранее оговоренном объеме. Это намного больше, чем просто договор на техническую поддержку сервисов. Конкретизация KPI, приоритетности подаваемых заявок, иных условий позволяет автоматизировать процесс и минимизировать влияние человеческого фактора, сокращает затраты на рутинные процессы.

Оставьте комментарий

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

Прокрутить вверх