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

SLA — что это такое?

SLA (Service Level Agreement — соглашение об уровне обслуживания) — внешний документ (существующий между заказчиком и исполнителем), описывающий параметры предоставляемой услуги. «Соответствие SLA» эквивалентно тому, что сервис работает так, что реальные параметры не выходят за пределы заявленных в соглашении диапазонов метрик.

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

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

Что такое OLA

Для исполнения SLA с внешним клиентом сервисной компании необходимо следить за процессом оказания услуги внутри — устанавливать сроки ответа на обращения и т.п. Для этого формируется OLA — Operational Level Agreement — аналогичный SLA внутренний документ компании, определяющий зоны ответственности подразделений.

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

Условия OLA должны соответствовать SLA или быть более жесткими, чтобы выступать гарантией соблюдения последнего, поэтому для формирования SLA сначала лучше продумать OLA, согласовав его с исполнителями. Если инженер физически не сможет добраться на объект быстрее, чем за 2 часа, вы не должны обещать клиенту, что решите его проблему за час.

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

Основное различие SLA и OLA в том, что первый документ описывает взаимодействие с внешним клиентом, а второй — работу подразделений внутри компании. И если SLA говорит на языке клиента и важных для него параметров сервиса («мы обеспечиваем доступность сервиса 99,8% времени»), то OLA погружается в технические детали и подробности взаимодействия отдельных подразделений и специалистов («диспетчер регистрирует заявку в течение 10 минут, инженер реагирует на нее в течение 2 часов, механик выезжает в течение 5 часов»).

15 000+ подписчиков. Присоединиться к рассылке

Подписаться

Что должно быть в договоре SLA

SLA должен содержать описание предлагаемой услуги и определять границы ответственности.

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

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

Также в SLA должно быть прописано, при каких условиях услуга считается оказанной (когда ответственность исполнителя прекращается).

Параметры, от которых зависит SLA

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

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

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

В сервисном бизнесе самый распространенный параметр — время. Это может быть:

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

При упоминании того или иного параметра в SLA указывается конкретный показатель и при необходимости допустимые отклонения.

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

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

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

Договор SLA

Раз уж SLA определяет взаимодействие двух сторон — клиента и исполнителя — разберем, как соглашение работает для каждой из них.

Глазами клиента

В рамках SLA заказчик получает метрики предоставления услуги — четкое описание того, за что именно он платит.

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

Параметры качества, заложенные в SLA, позволяют сверять ожидания от услуги с реальностью. А кроме того заказчику важна ответственность исполнителя за несоблюдение заявленных параметров (вплоть до штрафов). SLA, в котором ответственности не прописано, — лишь декларация о намерениях. А заявленная ответственность повышает доверие Заказчика к поставщику услуг.

Глазами сервисной компании

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

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

Во взаимодействии с клиентом SLA помогает ограничить зону ответственности.

Как написать хороший SLA

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

Пройдемся по основным положениям, которые стоит добавить в SLA.

Как и любой официальный документ, SLA должен четко определять, что входит в само понятие «услуга», кто именно ее оказывает и в чем она заключается. Поэтому начать стоит с определений услуг, ролей и спецтерминов. Эта часть должна отвечать на следующие вопросы:

• Какую услугу предоставляет исполнитель — что, когда и где делает? К примеру, мы говорим об обслуживании сантехники в коммерческой недвижимости. Описываем, что услуга подразумевает ремонт и обслуживание сетей водопровода и водоотведения от вентиля жилищно-коммунальной службы на входе в здание. И указываем, что обслуживание осуществляется на территории заказчика в будние дни с 9 до 18 по Московскому времени.
• Какие предусмотрены ограничения услуги — географические, временные? Предположим, обслуживание и ремонт не производится в праздники и с 20:00 до 7:00 по Московскому времени.
• Есть ли какие-то приоритеты? К примеру, если речь про сантехнику и слегка подтекает кран, то это обращение обычного приоритета. А если прорвало стояк и заливает уже 3 этажа здания, то это явно аварийная ситуация. Если в рамках услуги такие ситуации должны обрабатываться по-разному, надо прописать, что такое обычное обращение, а какая ситуация будет рассматриваться, как аварийная.
• Какое подразделение (или несколько подразделений) исполнителя участвует, в чем его (их) роль?
• Каковы функции сотрудников подразделения? Если упоминаем диспетчеров, объясняем, что их функции — ответ на звонки, регистрация обращения и передача его профильному специалисту.

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

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

Метрики должны быть реалистичными. Если в примере с кассой установить в SLA скорость ремонта в 10 минут, скорее всего соглашение просто не будет работать. Более реалистичное, но короткое время, заставит привлекать опытных специалистов, которые в среднем работают с задачами быстрее. А это стоит денег. В этом смысле SLA — это поиск баланса между интересами клиента, который хочет «вчера», и исполнителя, который не может быстрее (или может, но в ущерб другим клиентам).

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

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

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

Ниже представлен пример договора SLA реальной IT-компании.

I. Предоставляемые услуги

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

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

• <Инсталляция 1>
• <Инсталляция 2>

Период оказания услуг — с «___» _______ ____ г. — «___» _______ ____ г.

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

* Время часового пояса Москвы.

** Плановые часы — часы на выполнение модификации, включая постановку задачи, кодирование, тестирование и перенос модификации на рабочее приложение; плановые часы являются оценкой Исполнителя, в обязательном порядке согласуются с ответственным представителем ИТ-службы Заказчика. Риск превышения фактического времени над плановым находится на стороне Исполнителя. Время на модификации не переносится из периода в период.

В перечень услуг, оказываемых Исполнителем, не входят следующие задачи:

• Поддержка оборудования и инфраструктуры системы (сервера, каналы связи, системное ПО, включая подсистему печати, сервер базы данных), лицензионные ключи на ПО
• Администрирование базы данных, в т.ч. обеспечение сохранности данных (резервное копирование).

Способы взаимодействия пользователей Заказчика и Исполнителя:

• E-mail
• Телефон
• Система Service Desk Исполнителя

Конкретные почтовые адреса, телефоны и учетные записи для Service Desk определяются в регламенте взаимодействия.

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

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

Заказчик обязуется:

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

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

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

III. Приоритеты и нормативное время решения заявок

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

Приоритет заявок определяется дежурным специалистом Исполнителя, исходя из бизнес-процесса, по которому поступила заявка от пользователя ПО, и характера заявки. Нормативное среднее время выполнения заявок и максимально допустимая доля заявок, время выполнения которых не уложилось в нормативное время, представлена в таблице:

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

Время решения заявки рассчитывается как разница между датой/временем решения заявки и датой/временем регистрации заявки в ServiceDesk, за вычетом периодов нерабочего времени (в соответствии с графиком предоставления услуг в разделе I) и за вычетом времени нахождения заявки на стороне пользователя:

• Уточнение у заказчика
• Согласование заказчиком
• Тестирование заказчиком
• Передано сторонней службе

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

IV. Отчетность по услугам

Раздел определяет формат и частоту предоставления отчетов для Заказчика

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

Отчеты по количественным показателям (раздел III) содержат следующую информацию, в разбивке по приоритетам:

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

Отчеты по количественным показателям предоставляются Исполнителем ежемесячно до 5 числа каждого месяца. Указанные отчеты оформляются как приложения к актам выполненных услуг, подписываются Исполнителем и Заказчиком.

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

• Удовлетворенность скоростью решения проблемы
• Удовлетворенность вежливостью специалистов поддержки
• Удовлетворенность фактом решения проблем

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

Отчеты по качественным показателям предоставляются Исполнителем дважды в год, до 20 июня и до 20 декабря.

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

V. Методика оценки качества сервиса

В этом разделе мы определяем то, как мы измеряем качество сервиса. Мы приводим перечень метрик качества, как количественных, так и качественных, и определяем вес (важность) каждой метрики, исходя из бизнеса клиента

Исполнитель обязуется ежемесячно рассчитывать итоговый показатель качества сервиса (QoS), на основании следующего расчета:

* По данным последнего проведенного опроса пользователей

Итоговый показатель качества (QoS) рассчитывается как сумма весов по тем метрикам, которые были выполнены в периоде.

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

VI. Стоимость услуг, штрафные санкции и условия оплаты

Основной пункт в этом разделе — это расчет штрафных санкций, которые «IT-консалт» применяет к месячному акту в том случае, если нарушаем метрики качества.

Стоимость услуг Исполнителя составляет ________ (___________) рублей в месяц, без учета НДС.

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

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

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

Стоимость дополнительного сервиса, оказываемого по требованию Заказчика:

• При превышении указанного в разделе I объема заявок, стоимость каждой заявки сверх указанного объема, составит ______ (_______) руб, без учета НДС, за одну заявку.
• При необходимости выполнения доработок сверх указанного в разделе I объема, стоимость одного человеко-часа будет составлять ______ (_______) руб, без учета НДС. Подписание Сторонами Акта приема-передачи услуг по результатам выполненных доработок осуществляется по факту завершения пользовательского тестирования.
• Стоимость работы поддержки в выходные и праздничные дни — ______ (_______) руб./день, без учета НДС, вне зависимости от количества специалистов поддержки. Основанием для начисления стоимости является запрос на услуги поддержки в выходной день, направленный Исполнителю по электронной почте Координатором.

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

Оплата услуг производится Заказчиком путем перечисления денежных средств на расчетный счет Исполнителя в течение 10 (десяти) рабочих дней, исчисляемых с первого числа месяца, следующего за месяцем, в котором Сторонами был подписан без замечаний Акт приема-передачи услуг.

Источник: Компания «ФТО».

Как работать по SLA?

Схема работы по готовому соглашению предельно понятна:

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

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