Кому и зачем нужны договоры SLA?

Дмитрий Миронов — руководитель департамента сопровождения корпоративных клиентов Первого Бита. Он ответил на «стыдные» вопросы и рассказал, как договоры SLA помогают бизнесу получать качественные услуги.

Что такое SLA

Аббревиатура SLA расшифровывается как Service Level Agreement, а переводится — как соглашение об уровне сервиса. То есть, это некий пакт между заказчиком и исполнителем, в котором проговаривается:

• какие именно сервисы будут оказываться;

• по каким метрикам оценивается качество, предоставляемых сервисов;

• как именно эти метрики должны рассчитываться.

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

Какие метрики контролируются в SLA?

Основными метриками в SLA обычно являются время реакции и время выполнения обращения.

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

Время выполнения — то, как быстро должно быть предоставлено временное или постоянное решение проблемы.

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

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

Для каких задач и ситуаций подходит SLA?

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

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

А для каких не подходит?

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

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

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

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

Единственная метрика, которую можно применять к таким сложным задачам — это время реакции.

Как понять, нужен вам SLA или нет?

SLA становится нужен, когда: либо вся система, либо какие-то функции системы становятся для работы бизнеса критичными.

Если есть какая-то вспомогательная ИС, работоспособность которой на бизнес практически никак не влияет (если она может быть недоступна неделю, и ничего страшного не произойдет), то SLA для нее не нужен.

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

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

Кто составляет SLA — заказчик или исполнитель?

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

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

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

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

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

Исполнитель со своей стороны оценивает, насколько он в состоянии эти требования выполнить. Может оказаться, что из-за большого объема восстановление системы из бэкапа чисто физически займет не меньше 4 часов.

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

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

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

Что такое период «взятия на поддержку»?

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

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

Во время такого подготовительного периода подрядчик:

• анализирует информационную систему заказчика;

• актуализирует или создает документацию;

• актуализирует или создает автоматизированные тесты доработанного функционала.

Чтобы составить и исполнять SLA, нужно понимать, с чем придется работать. Время, которое требуется, чтобы эти знания получить, может сильно разниться — от получаса до нескольких месяцев. Все зависит от того, насколько сильно используемое ПО отличается от типового решения (поставляемого компанией-разработчиком).

От чего зависит удовлетворенность

Ощущение удовлетворенности в первую очередь зависит от эмоционального фона. 90% обращений в команду поддержки происходят, когда клиенту кажется, что что-то не работает. Это всегда сопряжено с раздражением и недовольством, и перекрыть эти эмоции хорошо выполненной работой практически невозможно.

Даже если отбросить этот аспект, SLA — это довольно формальный документ, а не какая-то волшебная пилюля. Представим пару ситуаций.

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

Во втором случае заказчик сообщает об инциденте, команда поддержки обнаруживает глубинную проблему и «лечит» ее. В итоге в SLA не уложились, потому что это заняло больше времени, чем планировалось, но зато такие ошибки больше никогда не повторяются.

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

Мы, например, при работе с заказчиками стараемся делать так, чтобы никакие проблемы не повторялись в будущем. Здесь нам очень помогают автоматизированные тесты. Если проблема возникла, то мы под нее написали тест, который проверяет, что она больше не воспроизводится.

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

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

Это очень полезный инструмент, который ни в коем случае не является панацеей.