Sla что это такое в управлении
Что такое SLA в управлении?
Service Level Agreement или SLA (соглашение об уровне сервиса) — три слова, определяющие подходы компании к организации ИТ-процессов. Согласно ITIL (IT Infrastructure Library) SLA — это мини-договор, устанавливающий параметры качества предоставляемых бизнесу ИТ-услуг.
В SLA описываются условия предоставления услуг (сервисов), устанавливается перечень таких услуг, а также правила, по которым заказчик будет пользоваться этими сервисами. В то же время SLA — один из основных механизмов, позволяющих управлять качеством ИТ-услуг и управлять ожиданиями пользователей.
Что должно быть в SLA?
Говоря иными словами, для ИТ-подразделения SLA — это набор параметров ключевых ИТ-процессов, а соблюдение SLA — основной ключевой показатель эффективности (KPI) ИТ-отдела.
Целью любого SLA является закрепление правил игры с определенной категорией бизнес-пользователей, по которым ИТ-служба будет с ними играть. При этом важно понимать, что SLA — это не внутренний документ ИТ, а договор, который заключается совместно с представителями бизнеса, и о котором проинформированы все пользователи.
SLA: с чего начать
Чаще всего к разработке SLA приходят в контексте внедрения Service Desk-системы. Начиная внедрять у себя управление уровнем качества обслуживания пользователей, не стоит пытаться объять необъятное, начните двигаться вперед небольшими шагами.
Ищите способы оптимизации процессов, чтобы постепенно приближать, например, сроки в SLA к тем, которые нужны бизнесу. Этот процесс называется — Service Level Management, SLM.
4 главных вопроса об SLA-соглашении
Что такое SLA, для чего оно нужно IT-компаниям и как его составить, чтобы наладить эффективное сотрудничество с заказчиками.
Что это такое – SLA
SLA (англ. Service Level Agreement – соглашение об уровне сервиса) – это соглашение между заказчиком и исполнителем о том, какие, когда и как будут предоставляться услуги. Также в него входят права и обязанности сторон. Используется SLA в IT и сфере телекоммуникаций.
Этот термин относится к методологии ITIL (англ. IT Infrastructure Library – библиотека инфраструктуры информационных технологий), в которой описываются лучшие способы организации работы компаний, предоставляющих IT-услуги.
Для чего нужно SLA
Простыми словами, SLA – это договор, в котором подробно описаны предоставляемые услуги, их качество, время реагирования на заявку и ее исполнение.
Допустим, существует провайдер, который предоставляет услуги по IT-аутсорсингу. Клиенты таких компаний не всегда понимают, как работает аутсорсинговая компания и чем занимаются ее сотрудники – из-за этого может возникнуть недопонимание.
Например, главбух клиента может быть недоволен, что админ со стороны провайдера поднимает какой-то там сервер (делов-то на 5 минут, а он уже 2 часа возится), вместо того чтобы заправить картриджи в бухгалтерии.
И чтобы избежать таких моментов и сохранить хорошие отношения, аутсорсинговая компания может составить SLA, в котором:
И теперь клиенты будут знать, что если разом перестали работать 20 тонких клиентов из 30, то сотрудник сможет заняться этим через 15–30 минут, а на устранение уйдет от 1 до 5 часов. А если проблема с принтером, то отклик будет только через час, хотя решение проблемы займет всего 10 минут.
Как составить SLA
Существует типовая структура, которой следует придерживаться, чтобы составить договор аутсорсинга на оказание услуг:
Все эти пункты должны быть прописаны очень подробно. Так, например, описывая уровень качества, нужно учесть такие параметры, как:
Если речь об оплате, то указывается валюта и стоимость. Например, может быть фиксированная абонентская плата или тарифы на устранение разных неполадок. Также указывается размер компенсации, которую выплачивает исполнитель в случае долгой реакции или если проблема не решена надлежащим образом.
Все важные моменты должны быть измеримыми, то есть иметь цифровой эквивалент – максимальное время простоя в минутах, доступность в среднем числе сбоев за определенный период и так далее.
Наиболее полную информацию о SLA можно встретить в описаниях стандартов ITIL и COBIT (от англ. Control Objectives for Information and Related Technologies – «Задачи управления для информационных и смежных технологий»).
Рекомендации от экспертов. Блог Okdesk
В условиях всё нарастающей конкуренции работа над качеством услуг — неотъемлемая часть сервисного бизнеса. Поскольку какие-то усовершенствования невозможно себе представить без метрик и соглашений относительно этих метрик, мы приходим к идее 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 часов»).
Что должно быть в договоре SLA
SLA должен содержать описание предлагаемой услуги и определять границы ответственности.
Содержание 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 должен четко определять, что входит в само понятие «услуга», кто именно ее оказывает и в чем она заключается. Поэтому начать стоит с определений услуг, ролей и спецтерминов. Эта часть должна отвечать на следующие вопросы:
SLA должен содержать понятные клиенту метрики услуги, характеризующие ее качество. Конкретные примеры метрик зависят от сферы деятельности компании. В сервисном бизнесе зачастую берут за основу время решения проблемы.
Важно, чтобы исполнитель полностью определял соответствие услуги этим метрикам (имел на них влияние). Если вы обслуживаете только кассы, нельзя привязываться в SLA простой всей ИТ-инфраструктуры магазина, потому что в нее входят компоненты вне вашей зоны ответственности. Кассу-то, может, вы и запустили, но если при этом в помещении отключено электричество, сделать ничего нельзя. Поэтому лучше сосредоточиться на конкретных метриках, определяющих именно вашу услугу — скорость восстановления работы кассы после остановки.
Метрики должны быть реалистичными. Если в примере с кассой установить в SLA скорость ремонта в 10 минут, скорее всего соглашение просто не будет работать. Более реалистичное, но короткое время, заставит привлекать опытных специалистов, которые в среднем работают с задачами быстрее. А это стоит денег. В этом смысле SLA — это поиск баланса между интересами клиента, который хочет «вчера», и исполнителя, который не может быстрее (или может, но в ущерб другим клиентам).
Метрик не нужно много. Большое количество метрик запутает исполнителя, он не сможет нормально расставить приоритеты в своей собственной работе, боясь выйти за рамки по какой-то из метрик.
Если в оказании услуги участвует несколько отделов и хочется прописать метрики для каждого, это можно сделать в OLA, задав в SLA только один общий параметр, в который уложится вся последовательность действий. Или задать несколько версий этой метрики в SLA, в зависимости от подключения к решению проблемы новых участников (условно говоря, если проблема уходит на третий уровень поддержки, то допустимое время реакции увеличивается на сутки).
Пример договора SLA
Ниже представлен пример договора SLA реальной IT-компании.
I. Предоставляемые услуги
В этом разделе мы описываем все работы, которые «IT-консалт» выполняет для Заказчика, и системы, которые находятся у нас на поддержке. По каждому виду работ определяется график и ограничения объема услуг, если они есть. Отдельно оговариваются те работы, которые не входят в нашу зону ответственности.
Исполнитель обязуется оказывать Заказчику услуги по сопровождению программного обеспечения 1С 8 ERP, установленного у Заказчика, на следующих инсталляциях:
Период оказания услуг — с «___» _______ ____ г. — «___» _______ ____ г.
Перечень услуг по сопровождению, время предоставления и ограничения по объему оказываемых услуг указан в таблице:
| Услуга | Время предоставления* | Объем услуг |
| Консультации пользователей по работе с ПО, помощь в решении проблем в части бизнес-процессов: — Приемка на склад — Отгрузка готовой продукции | 24/7 | Не ограничен |
| Консультации пользователей по работе с ПО, помощь в решении проблем в части прочих бизнес-процессов | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Контроль выполнения регулярных процедур по согласованным регламентам | 24/7 | Не ограничен |
| Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций | 24/7 | Не ограничен |
| Мониторинг и поддержание работоспособности сервера приложений | 24/7 | Не ограничен |
| Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ») | Ежемесячно | Не ограничен |
| Выдача и изменение пользовательских прав, ролей (по заявкам ключевых пользователей или службы безопасности) | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД) | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Исправление ошибок в программном коде ПО | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Доработка ПО в соответствии с бизнес-требованиями Заказчика | С 9:00 по 18:00 в рабочие дни | Не более 40 плановых часов в месяц ** |
| Обновление систем на новые версии, поставляемые производителем ПО | С 9:00 по 18:00 в рабочие дни | Не более 2 раз в год |
* Время часового пояса Москвы.
** Плановые часы — часы на выполнение модификации, включая постановку задачи, кодирование, тестирование и перенос модификации на рабочее приложение; плановые часы являются оценкой Исполнителя, в обязательном порядке согласуются с ответственным представителем ИТ-службы Заказчика. Риск превышения фактического времени над плановым находится на стороне Исполнителя. Время на модификации не переносится из периода в период.
В перечень услуг, оказываемых Исполнителем, не входят следующие задачи:
Способы взаимодействия пользователей Заказчика и Исполнителя:
Конкретные почтовые адреса, телефоны и учетные записи для Service Desk определяются в регламенте взаимодействия.
II. Ответственность Заказчика
Здесь мы описываем то, что нам нужно для эффективного выполнения работы — доступы, координатор со стороны заказчика, и так далее. Самое важное в этом разделе — монопольный доступ к коду системы с нашей стороны. Если монопольного доступа нет, после возникновения каких-то проблем можно «не найти концов». Если мы отвечаем за приложение, к нам в дальнейшем все вопросы, но мы должны его контролировать.
Заказчик имеет право:
III. Приоритеты и нормативное время решения заявок
В этом разделе мы описываем принципы очередности выполнения заявок поддержкой, включая разбивку бизнес-процессов Заказчика по степени критичности. Здесь же описывается нормативное среднее время решения заявок и предельная доля тех заявок, которые не уложились в нормативное время.
Приоритет заявок определяется дежурным специалистом Исполнителя, исходя из бизнес-процесса, по которому поступила заявка от пользователя ПО, и характера заявки. Нормативное среднее время выполнения заявок и максимально допустимая доля заявок, время выполнения которых не уложилось в нормативное время, представлена в таблице:
| № | Приоритет | Среднее время решения заявки | Доля просроч. заявок | Виды заявок |
| 1 | Критический | Не более 2 рабочих часов | Не более 20% | Нарушения в работе ПО, которые приводят к неработоспособности одной или нескольких инсталляций в целом. |
Мониторинг и поддержание работоспособности сервера приложений
— Отгрузка готовой продукции
Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД)
Контроль выполнения регулярных процедур по согласованным регламентам
Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций
Выдача и изменение пользовательских прав, ролей
Обновление систем на новые версии, поставляемые производителем ПО
Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ»)
По взаимному соглашению сторон приоритет заявки может быть изменен как в большую, так и в меньшую стороны.
Время решения заявки рассчитывается как разница между датой/временем решения заявки и датой/временем регистрации заявки в ServiceDesk, за вычетом периодов нерабочего времени (в соответствии с графиком предоставления услуг в разделе I) и за вычетом времени нахождения заявки на стороне пользователя:
Доля просроченных заявок рассчитывается как отношение количества заявок данного приоритета, время решения которых больше нормативного, к общему количеству заявок данного приоритета.
IV. Отчетность по услугам
Раздел определяет формат и частоту предоставления отчетов для Заказчика
Отчеты предоставляются Исполнителем Заказчику в табличном формате, в электронном виде и используются Заказчиком для оценки качества предоставляемых услуг.
Отчеты по количественным показателям (раздел III) содержат следующую информацию, в разбивке по приоритетам:
Отчеты по количественным показателям предоставляются Исполнителем ежемесячно до 5 числа каждого месяца. Указанные отчеты оформляются как приложения к актам выполненных услуг, подписываются Исполнителем и Заказчиком.
Дополнительно к количественным показателям Исполнитель собирает информацию о качественном восприятии сервиса. Дважды в год Исполнитель проводит опрос пользователей на предмет удовлетворенности следующими факторами:
Отчеты по качественным показателям содержат информацию по удовлетворенности пользователей, в разбивке по ролям пользователей, а также описание принимаемых мер по улучшению показателей.
Отчеты по качественным показателям предоставляются Исполнителем дважды в год, до 20 июня и до 20 декабря.
Координатор самостоятельно проводит анализ полученной отчетности. В случае необходимости, Координатор может инициировать проведение совещания рабочей группы с представителями Исполнителя услуг по анализу отчетности.
V. Методика оценки качества сервиса
В этом разделе мы определяем то, как мы измеряем качество сервиса. Мы приводим перечень метрик качества, как количественных, так и качественных, и определяем вес (важность) каждой метрики, исходя из бизнеса клиента
Исполнитель обязуется ежемесячно рассчитывать итоговый показатель качества сервиса (QoS), на основании следующего расчета:
| Метрика | Вес метрики |
| Среднее время выполнения заявок 1 приоритета меньше нормативного | 0,1 |
| Доля просроченных заявок 1 приоритета меньше нормативной | 0,1 |
| Среднее время выполнения заявок 2 приоритета меньше нормативного | 0,15 |
| Доля просроченных заявок 2 приоритета меньше нормативной | 0,15 |
| Среднее время выполнения заявок 3 приоритета меньше нормативного | 0,05 |
| Доля просроченных заявок 3 приоритета меньше нормативной | 0,05 |
| Среднее время выполнения заявок 4 приоритета меньше нормативного | 0,05 |
| Доля просроченных заявок 4 приоритета меньше нормативной | 0,05 |
| Доля ответов «Быстрее, чем рассчитывал», «Как и рассчитывал» на вопрос анкеты «Насколько быстро, по Вашему мнению, решаются Ваши проблемы» больше 70% * | 0,1 |
| Доля ответов «Да», «Чаще да» на вопрос анкеты «Снимаются ли Ваши проблемы в работе с системой службой поддержки?» больше 80% * | 0,1 |
| Доля ответов «Да», «Чаще да» на вопрос анкеты «Было ли обращение сотрудников службы поддержки с Вами вежливым?» больше 90% * | 0,1 |
* По данным последнего проведенного опроса пользователей
Итоговый показатель качества (QoS) рассчитывается как сумма весов по тем метрикам, которые были выполнены в периоде.
Исполнитель самостоятельно, без согласования с Заказчиком, определяет необходимый трудовой ресурс специалистов поддержки, консультантов и разработчиков для выполнения указанных метрик.
VI. Стоимость услуг, штрафные санкции и условия оплаты
Основной пункт в этом разделе — это расчет штрафных санкций, которые «IT-консалт» применяет к месячному акту в том случае, если нарушаем метрики качества.
Стоимость услуг Исполнителя составляет ________ (___________) рублей в месяц, без учета НДС.
В случае нарушения показателей качества стоимость услуг уменьшается пропорционально штрафным санкциям, согласно следующей таблице:
| QoS от | QoS до | Штрафные санкции, в % от стоимости услуг |
| 0,8 | 1 | 0% |
| 0,6 | 0,79 | 5% |
| 0,4 | 0,59 | 10% |
| 0 | 0,39 | 20% |
Штрафные санкции могут быть начислены начиная с 3-го месяца оказания услуг. Первые два месяца являются ознакомительным периодом, в котором Исполнитель нарабатывает компетенцию в приложении Заказчика.
В случае изменения объема услуг и/или количества инсталляций, стоимость договора может быть пересмотрена как в большую, так и меньшую сторону.
Стоимость дополнительного сервиса, оказываемого по требованию Заказчика:
Стоимость дополнительного сервиса будет включаться в месячный акт отдельными строками.
Оплата услуг производится Заказчиком путем перечисления денежных средств на расчетный счет Исполнителя в течение 10 (десяти) рабочих дней, исчисляемых с первого числа месяца, следующего за месяцем, в котором Сторонами был подписан без замечаний Акт приема-передачи услуг.
Как работать по SLA?
Схема работы по готовому соглашению предельно понятна:
Отметим, что соблюдать SLA проще, если процессы в сервисной компании отлажены. Помогают этому различные инструменты автоматизации, в частности, Help Desk.