Серьёзный сервис: как правильно составить SLA
Сегодня всё больше компаний переходит от продаж продуктов к сервисной модели. В таких условиях на первый план выходит качество предоставляемых услуг, которое определяется в SLA – соглашении об уровне сервиса. Директор по сервисной поддержке, аутсорсинговым решениям и ИТ Konica Minolta Business Solutions Russia Станислав Парфёнов рассказывает, для чего нужен SLA и как его подготовить, чтобы все остались довольны результатом.
Разберёмся с термином
SLA (Service Level Agreement) – это соглашение, которое заключается между заказчиком и поставщиком услуги. Чаще всего такой документ составляется между внешними контрагентами, однако может быть разработан и для внутреннего заказчика в компании. SLA помогает управлять ожиданиями обеих сторон и включает требования к качеству сервиса. Он также подробно описывает и регулирует весь процесс, позволяя эффективно его контролировать.
Сам термин пришёл из ITSM и ITIL — руководств по управлению ИТ-услугами, содержащих лучшие практики отрасли. Однако сегодня он широко распространился и во многих других сферах. Сейчас SLA может применяться к любому виду сервиса: где есть услуга, там должно быть и соответствующее соглашение.
Но несмотря на то, что соглашение должно охватывать широкий список критериев, ему важно оставаться простым. Любой сотрудник (неважно, со стороны заказчика или поставщика) должен понять из SLA, как оказывается услуга и как оценивается её эффективность, даже если он плохо знаком с процессом. В документе четко прописано, что выполняется и что не выполняется в составе сервиса. Благодаря такому подходу процесс оказания услуги становится чётким, измеримым и понятным любому человеку, даже плохо знакомому с предметом соглашения.
На следующем шаге нужно определить уровень сервиса: каким именно образом определяется качество в зависимости от состава услуги. Скажем, для дата-центра, в котором хранятся данные компании, критерии качества будут совершенно иными, чем, например, для аутсорсинга производства маркетинговых материалов. Показатели, которые применяются для контроля и определения качества работы сервиса, должны чётко соответствовать своей предметной области.
Также SLA может быть не только внешним, направленным на взаимодействие с поставщиками, но и внутренним. В таком случае он помогает организовать комплексную работу внутри компании, а также обеспечить слаженную работу всех отделов и направлений.
Составляем SLA – с чего начать?
Несмотря на то, что SLA будет разным в зависимости от состава самой услуги, документ составляется по одним и тем же общим принципам. Начать логичнее всего со справочника используемых терминов или глоссария. Здесь важно перечислить все компоненты сервиса и понятия, которые могут его описывать. Такой шаг является оптимальным, так как, прежде чем описывать принципы работы, необходимо проанализировать сам предмет.
После вводной части нужно определить, в каких границах действует сервис – они могут быть функциональными, временными и территориальными. Это позволит определить область действия и зону ответственности.
Например, компания имеет развитую структуру подконтрольных организаций. Требования в таком случае будут применимы только к головному офису или также к дочерним компаниям? И будет ли соглашение об уровне сервиса относиться к сотрудникам, которые перешли на работу в формате home office? Указание чётких границ действия SLA позволит избежать двойственности в понимании. На этом уровне также должны быть прописаны временные рамки – то есть определено по каким дням и в какие рабочие часы будет оказываться сервис.
После этого в документе перечисляются все услуги, которые предлагает поставщик. Они могут делиться на основные – как правило, это регистрация инцидентов, их разрешение, устранение первичных и вторичных ошибок, доступ к данным; а также дополнительные – к примеру, это разработка новых решений. Услуги должны быть прописаны детально, вплоть до того, какие именно ошибки должны устраняться, а какие нет.
Реагируем на инциденты
На следующем шаге важно определить, из чего состоит сам сервис. Он может быть многосоставным: к примеру, часто поддержка представлена несколькими линиями, которые относятся к разным офисам и подразделениям. На первой линии регистрируются инциденты, на второй – работают более квалифицированные эксперты, которые могут разрешить ситуацию удалённо; на третьей – специалисты, которые приезжают к заказчику, когда инцидент не может быть «закрыт» удаленно, и в экстренных случаях.
Также здесь определяется уровень важности сервиса – критичный, нормальный или низкий. В зависимости от этого определяется время реакции и восстановления, расставляются приоритеты.
Например, сервис критичный, от него зависит работа всей компании. Тогда поставщик сервиса должен отреагировать в течение одного рабочего часа, а уже через четыре часа устранить проблему. А вот если важность низкая, то реакция может поступить в течение 4 рабочих часов, а процесс восстановления занять до 16 рабочих часов. Независимо от критичности инцидент будет решен, разным будет лишь время устранения проблемы.
Затем можно перейти к следующей части SLA – распределению ролей и построению лестницы эскалации. Это позволит четко определить обязанности в рамках многостадийной услуги, в которой есть несколько линий поддержки и инженеры. В таком случае текст документа разбивается на параграфы с разными метриками для каждого подразделения, участвующего в оказании сервиса. Далее четко прописываются условия, при которых запрос эскалируется на следующую линию. Это позволяет эффективно решать «пограничные» вопросы, требующие компетенций сотрудников нескольких линий поддержки. В некоторых случаях система реагирования на чрезвычайные ситуации может быть автоматической: оператору поступает сигнал, и над проблемой начинают работать соответствующие специалисты.
Те самые KPI
Время реакции на инциденты может входить в состав KPI – ключевых показателей эффективности. Заказчику хочется не просто услышать вопрос «Как вам наш сервис?», а провайдеру услуг – не просто получить ответ «хорошо» или «плохо». Обеим сторонам нужны измеримые результаты в виде количественных и качественных показателей. Если показателей много, то должно быть четко определено, какой из них наиболее важный, и какие «веса» присваиваются каждому из них.
Эти показатели должны быть прописаны с учётом всех уровней работы и отчётных периодов, а также измеряться по согласованной сторонами шкале. Только тогда взаимодействие партнёров перейдёт из плоскости субъективных эмоциональных отношений в область бизнеса.
Однако важно определить не только сами показатели, но и их минимально возможные значения, после достижения которых качество сервиса будет считаться хорошим или даже отличным.
При этом требования к провайдеру услуг не должны быть излишними. Если вся система работы может быть описана при помощи 1-2 параметров, нет смысла искусственно расширять список метрик, добавляя туда дополнительные, просто потому что так принято. В результате это может оказаться не измерением эффективности сервиса, а упражнениями в фантазии – или соревнованием в знании показателей. К тому же, сложно расставить приоритеты параметров, если все они недостаточно важные. У каждого сотрудника должно быть четкое понимание того, насколько он сможет уменьшить время оказания сервиса с момента поступления заявки.
По этой же причине лучше не вводить в SLA слишком много количественных показателей, ведь это может слишком усложнить оценку. Если компания хочет усилить контроль над сервисом, то лучше разбить его на отдельные услуги и составлять показатели для каждой из них – большинство сервисов оказываются многосоставными. В сложных случаях можно даже разработать отдельные соглашения для каждой составляющей. Большинство сервисов работают именно по такому принципу.
Конечно, SLA – это дополнение к договору оказания услуг и далеко не единственный документ, который регламентирует качество сервиса. Однако именно он является основой отношений и в наиболее полной мере описывает процесс взаимодействия поставщика и заказчика. Поэтому документ должен быть «живым»: периодически обновляться с сохранением истории версий. Эти изменения должны быть синхронизированы с обновлением существующих бизнес-процессов, практик и политик заказчика. Тогда SLA становится инструментом, который помогает сервис-провайдеру гибко реагировать на меняющиеся потребности бизнеса.
