Как составить соглашение об уровне сервиса (SLA)

Сегодня мы с вами поговорим о Соглашении об уровне сервиса или SLA. Основная задача документа – это вытащить все ожидания по качеству услуг от бизнеса, примерить их на возможности ИТ-службы или подрядчика, сбалансировать со стоимостью и договориться по итогу. Можно назвать его конституцией сервиса, на которую потом нанизываются законы (вспомогательные регламенты, памятки и прочие документы).

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

Кому же нужен SLA? Всем, для кого критична стабильность сервиса

1. В первую очередь, это предприятия, где остановка системы влияет на критичные процессы (отгрузка, приемка, логистика, закрытие, казначейство). Поддерживать такой процесс «на коленке» чревато остановкой процесса и потерей денег. Зрелый процесс поддержки минимизирует риск остановки процессов.
2. Это ОЦО (объединенные центры обслуживания) – технологичные подразделения, которые с основным бизнесом работают по SLA, и как следствие, этом должна соответствовать качественная ИТ поддержка как субподрядчик.
3. Наконец, это случаи, когда система обеспечивает деятельность большого количества подразделений компании. SLA в таком случае служит важным регулятором, задающим приоритеты между конкурирующими запросами разных бизнес-функций (а конкуренция эта всегда будет, поскольку ресурс ИТ поддержки ограничен).

Что писать внутри SLA?

1. База – это каталог услуг. Что же должен делать для вас внутренний или внешний подрядчик? Включите сюда все работы, которые вы ожидаете от сервиса. Как реактивные, например, консультации пользователей, выдача прав или исправление дефектов в программном коде, так и менее очевидные проактивные работы – мониторинг работоспособности системы, поддержание пользовательской документации в актуальном состоянии или регулярная деятельность по управлению проблемами (обобщение повторяющихся инцидентов и планирование мер по их сокращению). Инвентаризация всех возможных работ поможет с одной стороны лучше контролировать действия подрядчика, а с другой стороны доносить до каждого бизнес-заказчика понимание глубины работы сервисной службы (часто еще встречается понимание на уровне «да что там делать…»).

2. Хорошей практикой будет кроме позитивного списка составить и негативный список (что сервис не делает). Например, если вы делите оперативную поддержку и управление кодом ПО между разными службами, имеет смысл подсветить в документе то, что служба поддержки пользователей не занимается исправлением дефектов в системе. Это уменьшит домысливание у бизнес-заказчиков и снизит риск конфликта.
3. Не забудьте по каждому виду услуг отметить график оказания (часть сервисов требуют круглосуточного режима работы, часть может оказываться в рабочее время) и ограничения по объему услуг, если они появились как следствие ограничения бюджета.
4. Раздел, который нельзя пропустить – приоритеты. Он выстраивает у исполнителя и у разных бизнес-заказчиков понимание, какой инцидент является срочным, а какой нет. Приоритеты могут быть выстроены как по бизнес-процессам/сервисам (например, процесс отгрузки и связанные с ним блоки системы – это приоритет 1, а учет материалов – приоритет 3), так и по уровню влияния на бизнес-процесс (когда приемка поставки не работает у одного пользователя – это одна история, а когда во всей компании – совсем другая). Это можно комбинировать, выстраивая матрицу сервис/влияние и задавая приоритеты по каждой ячейке матрицы. Бывает и так, что приоритет зависит от периода. Например, если в компании есть процесс быстрого закрытия, то заявки по учету в период закрытия могут подниматься из среднего в высокий приоритет.

Типичная ошибка начинающего – попытаться впихнуть всё в первый приоритет («у нас нет неважных вопросов»). Но если все задачи важны, то ни одна из них не важна в итоге. Специалисты исполнителя теряют фокус и в нужный момент не смогут выявить ту заявку, которую действительно надо решать. Разумным балансом выглядит не более 5% заявок критического приоритета, и не более 20% высокого. Также это негативно влияет и на стоимость – любой приоритет стоит денег.

5. Следующим шагом определяем, какие ожидания у бизнеса по времени решения заявок. По каждому приоритету это должно быть зафиксировано. Важно, что это не время реакции (когда исполнитель подтвердил получение заявки и приступил к решению), а именно – время решения.

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

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

6. Из приоритетов и нормативов вытекают метрики качества и расчет качества сервиса. Типичные метрики, которые включаются в соглашение – это среднее время закрытия инцидентов по каждому приоритету («не более чем»), доля просроченных заявок («не более чем»). Они подлежат анализу и обсуждению на регулярных встречах по качеству сервиса.

Важный момент – не фокусируйтесь только на количественных метриках. Добавьте в сводный показатель качества обратную связь от пользователей. Некоторые собирают ее через кнопки «доволен» и «не доволен» в системе service desk, мы проводим опросы пользователей раз в полгода. На самом деле неважно, как вы собираете обратную связь. Важна ее регулярность и регулярность отработки негативной обратной связи. Мы часто сталкивались со случаями, когда формально метрики не нарушены, но конечные пользователи недовольны. Это не только сигнал к принятию мер «прямой сейчас», но и повод скорректировать SLA в будущем, чтобы он лучше отражал жизнь.

7. Удивительно такое писать, но мы видели SLA с подрядчиками без штрафных санкций, не забудьте про них. Здесь также возможны различные варианты. Мы, например, считаем интегральный показатель качества сервиса (QoS), в зависимости от которого рассчитывается сетка штрафов. Но есть и контракты, в которых особый фокус нацелен на инциденты высокого приоритета, и в таком случае даже одна метрика влияет на штраф напрямую.
8. Наконец, раздел, который не содержит цифр, но должен присутствовать в каждом SLA – это коммуникационная карта. Здесь имеет смысл собрать все вопросы, которые отражают точки и порядок взаимодействия:

• Способы обращения в поддержку для пользователей, ее контакты.
• Контакты основных бизнес-экспертов. Кто от бизнеса принимает те или иные решения и за какие решения они отвечают (например, согласование выдачи прав или операции, связанные с закрытие периода).
• Эскалационная схема по критичным инцидентам. Надо ли оповещать руководство бизнеса и ИТ, если бизнес-критичный инцидент решается больше определенного времени, и когда? Надо договориться по ответу на этот вопрос и записать в документ.
• Смежные с сервисом службы (инфраструктура, смежные программные продукты, с которыми интегрирована поддерживаемая система) и порядок эскалации.