EN

SLA: советы по составлению для ServiceDesk и Helpdesk

Соглашение об уровне обслуживания (Service Level Agreement, или SLA) — договор между поставщиком ИТ-услуги и заказчиком. Появившись когда-то в ITIL как одна из рекомендаций, SLA стал незаменимым практическим инструментом. Сейчас именно на основе SLA в большинстве случаев выстраивается взаимодействие поставщика и заказчика.

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

  • Описание, или определение, услуги, вовлеченные стороны, сроки действия SLA;
  • Даты и время, в которые услуга будет предоставляться;
  • Количество пользователей (сервиса), экземпляров оборудования или ПО;
  • Регламент обработки запросов, инцидентов, а также подготовки отчетов о проблемах;
  • Целевые показатели: согласованное время работоспособности, согласованное время поддержки, время реакции, доступность сервиса и т. д.;
  • Расценки и график платежей за услугу;
  • Компенсации за несоблюдение SLA и процедура разрешения спорных ситуаций.

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

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

Внедрение ServiceDesk

Периодически проверяйте и корректируйте SLA

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

Вы сервис-провайдер, который взял на поддержку виртуальную инфраструктуру клиента. Одна из ключевых метрик вашего SLA — параметр производительности системы хранения на HDD-дисках. Допустим, производительность СХД по SLA составляет 2000 IOPS.

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

Анализируя отчеты Service Desk, вы можете действовать на опережение — пообщаться с клиентом и выяснить причины проблемы. Как вариант, можно перевести клиентскую базу данных на SSD-хранилище с производительностью 10 000 IOPS и предложить клиенту SLA с новыми метриками. Так, своевременный апгрейд инфраструктуры и пересмотр метрик поможет избежать конфликтной ситуации.

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

Добавьте ограничения и исключения

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

Время реакции. Если у вас проводится регулярное плановое техобслуживание систем мониторинга, когда вы не можете оперативно ответить на запрос, укажите это в SLA в качестве ограничения. Например: «Гарантированное время реакции на запрос — до 1,5 часов, кроме каждой второй среды месяца в период с 1.00 до 4.00». Добавьте детальное объяснение причины.

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

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

Время поддержки. Учтите период, в который вы не сможете поддерживать сервис, — к примеру, в нерабочее время и в выходные. Тогда согласованное время поддержи можно указать так: «8×5 (10:00-18:00, Пн-Пт)».

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

Сделайте SLA измеримыми

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

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

Сделайте отдельные метрики для каждого уровня поддержки

Help Desk и Service Desk обычно многоуровневые службы. У каждого уровня определенные специфика, сложность задач и KPI. Это нужно учитывать при согласовании в SLA времени реакции и времени решения проблем.

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

Первая линия обрабатывает запросы пользователей и решает простые проблемы — ей на это требуется в среднем один-два часа.

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

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

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

Учитывайте ожидания клиента

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

Если уровень гарантированной доступности сервиса 99,9%, ему позволено «лежать» суммарно 43 минуты в месяц. Сценарии могут быть разными. Например — четыре некритичных инцидента ночью с простоем по 10 минут каждый. Либо 40 минут днем, в час пиковой нагрузки, когда простой сервиса приведет к многомиллионным убыткам. Формально поставщик не нарушит SLA, но вряд ли клиент будет удовлетворен качеством услуги.

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

Избегайте общего SLA для клиентов с географически распределенной структурой

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

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

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

Оставайтесь в курсе событий

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

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