Каждый клиент любой компании хочет получать ожидаемый им уровень обслуживания: он ждёт, чтобы его проблемы решали быстро и качественно. Чтобы не возникало конфликтных ситуаций с клиентом, компании составляют соглашение об уровне сервиса — SLA.
636 просмотров
В соглашении документируют все условия обслуживания, которые гарантируют клиенту определённый уровень сервиса. Рассказываем, для чего компании составляют SLA, и как они могут автоматизировать соблюдение пунктов соглашения с помощью Service Desk.
Что представляет из себя SLA?
SLA — это соглашение, в котором документирует, что в каком количестве и в когда будет предоставлять компания-поставщик. Документ может быть составлен как в бумажном, так и в электронном виде. Его можно выдавать по запросу или держать в открытом доступе для всех. Также его составляют как для отдельных клиентов, так и для всех.
Впервые подобный документ использовали именно в IT-сфере. Она и сейчас является основной областью, где используют SLA, но его также им пользуются и в других сферах, где предоставляют услуги.
Например, соглашение об уровне сервиса могут применять в сфере обслуживания оборудования.
Соглашение ставит определённые рамки, в которых и будет предоставляться сервис, например, максимальное время ответа на обращение. Так как документ может иметь юридическую значимость, с его помощью быстро решаются различные конфликты между заказчиком и поставщиком.
В SLA прописывается также время реакции на различные ситуации, которые могут произойти у клиента, и время их решения. Кстати, в прошлый раз мы писали о том, как измерить эффективность технической поддержки, рекомендуем прочитать этот материал.
Например, у клиента перестало работать оборудование. Он оставит обращение и будет ждать ответа. Время реакции может составлять, например, 1 час, а время решения — до 1 рабочего дня. Если вы успеваете в эти сроки, то вы выполнили обслуживание клиента в соответствии с SLA.
Для того, чтобы выполнять условия соглашения компании составляют и другой документ — OLA. О нём мы поговорим дальше.
Отличие SLA и OLA
Эти два документа, хоть и похожи, но различаются по своему назначению.
SLA — это внешний документ, который нужен, чтобы продемонстрировать клиентам условия, на которых они будут получать обслуживания.
OLA — это аналогичный, но внутренний документ. Он составляется для самих сотрудников и подразделений компании, которые несут ответственность за соблюдение всех условий SLA.
В OLA большее внимание уделяется средствам достижения договорённостей с клиентом. Также этот документ обычно составляют более простым и понятным языком, чем соглашение для клиентов.
Соблюдение требований, указанных в обоих документах, можно автоматизировать с помощью программ для организации технической поддержки — сервис-десков. Одной из таких программ является Admin24 – Service Desk, в которой есть возможность настройки времени реагирования на заявку и времени её выполнения.
Как составить соглашение
Так как этот документ является регулирующим, его нужно составлять правильно и достаточно подробно. Важно, чтобы все метрики, используемые в соглашении, можно было легко измерить.
Избегайте формулировок, которые будут иметь двоякое значение. Также в отдельной части нужно описать процедуру устранению инцидентов.
Например, компания может задокументировать, что при несоблюдении сроков реагирования на заявку, она будет предоставлять скидку клиенту на свой продукт.
Вы можете воспользоваться типовой структурой документа. В данном случае она будет включать всю основную информацию.
- Вступительная часть.
Обычно эта часть содержит 2 раздела: «Предмет Соглашения» и «Термины и определения».
Сюда могут входить разделы «Порядок и сроки оказания услуг, а также показатели их уровня доступности», «Разрешение разногласий» и «Уровень технической поддержки и порядок расчётов».
Мы подготовили удобный чек-лист по составлению соглашения об уровне сервиса. Мы включили в него 7 ключевых параметров, которые должны содержаться в SLA. Наличие этих параметров свидетельствует об установленных стандартах SLA для обслуживания клиентов.
Можно ли автоматизировать соблюдение SLA?
Чем больше у компании клиентов, которых нужно обслуживать, тем сложнее становится следить за соблюдением соглашения об уровне сервиса. Решить эту проблему можно с помощью автоматизации.
Для этого компании используют системы Service Desk — программы для автоматизации поддержки.
Российская система для автоматизации обращений клиентов и сотрудников Admin24 – Service Desk позволяет настраивать параметры SLA, например, время реагирования на заявку и время её выполнения. Для разных компаний, форм и услуг можно устанавливать разные параметры и назначать разных руководителей.
Настраивайте SLA, работайте с заявками и автоматизируйте поддержку вместе.
Admin24 – Service Desk — это российская система для автоматизации обработки обращений клиентов и сотрудников. Переходите по ссылке и тестируйте возможности Админ24 для внутренней поддержки бесплатно 30 дней!
Систему можно интегрировать с Битрикс24, Telegram, Вконтакте и Одноклассниками.
Подписывайтесь на Admin24 – Service Desk в TenChat. Там ещё больше интересного.
Узнать больше о настройках Admin24 – Service Desk на YouTube.
Источник: vc.ru
Что такое SLA в управлении?
Service Level Agreement или SLA (соглашение об уровне сервиса) — три слова, определяющие подходы компании к организации ИТ-процессов. Согласно ITIL (IT Infrastructure Library) SLA — это мини-договор, устанавливающий параметры качества предоставляемых бизнесу ИТ-услуг.
В SLA описываются условия предоставления услуг (сервисов), устанавливается перечень таких услуг, а также правила, по которым заказчик будет пользоваться этими сервисами. В то же время SLA — один из основных механизмов, позволяющих управлять качеством ИТ-услуг и управлять ожиданиями пользователей.
Что должно быть в SLA?
- Описание сервисов или услуг, которые предоставляются по данному SLA (какая-то часть каталога сервисов, предоставляемых ИТ-службой)
- Описание условий предоставления услуг, вплоть до порядка работы с заявкой на предоставление конкретных сервисов.
- Измеримые параметры качества ИТ услуг. Эти параметры качества безусловно должны соотноситься с бизнес-целями организации и быть отражением потребностей бизнес-пользователей в том числе в способах оказания им ИТ-услуг. Такими параметрами качества могут быть время устранения инцидентов, время, в течение которого сервис должен быть восстановлен и т.п. Так, например, создание почтового ящика для нового сотрудника должно занимать у ИТ-службы не более 4 часов.
Говоря иными словами, для ИТ-подразделения SLA — это набор параметров ключевых ИТ-процессов, а соблюдение SLA — основной ключевой показатель эффективности (KPI) ИТ-отдела.
Целью любого SLA является закрепление правил игры с определенной категорией бизнес-пользователей, по которым ИТ-служба будет с ними играть. При этом важно понимать, что SLA — это не внутренний документ ИТ, а договор, который заключается совместно с представителями бизнеса, и о котором проинформированы все пользователи.
SLA: с чего начать
Чаще всего к разработке SLA приходят в контексте внедрения Service Desk-системы. Начиная внедрять у себя управление уровнем качества обслуживания пользователей, не стоит пытаться объять необъятное, начните двигаться вперед небольшими шагами.
- Группируем пользователей, начинаем с 2-3 групп.
Начните с 2-3 групп, например, VIP-пользователи и Обычные пользователи - Определяем критические ИТ сервисы, не больше 4
Определите несколько критических сервисов, управление качеством которых не требует отлагательств. Например, в торговой организации одним из таких сервисов станет подключение к crm-системе менеджеров по продажам. В любом случае, это будет какая-то часть вашего каталога сервисов, предоставляемых ИТ-службой - Устанавливаем реальные нормы качества для SLA, с учетом наших возможностей и целевые показатели
Определите параметры качества предоставления сервисов и установите для них реальные нормативы. Эти параметры должны соотноситься с бизнес-целями организации и быть отражением потребностей бизнес-пользователей, в том числе в способах оказания им ИТ-услуг. Такими параметрами могут быть:
- время устранения инцидентов,
- время, в течение которого сервис должен быть восстановлен, и т.п.Важно знать, от каких процессов зависит качество этих ИТ-сервисов. Эти процессы будут служить ограничивающим фактором при установлении сроков в SLA (правда, оптимизация этих процессов — уже совсем другая история). Например, при создании нового рабочего места производится закупка нового оборудования, поэтому сроки подготовки рабочего места не могут быть меньше, чем сроки закупки.И, как бы всем участникам процесса не хотелось, чтобы все заявки по какому-то сервису закрывались за 5 минут, если традиционно они закрываются по 10 дней — значит от 10 дней и надо начинать плясать.
Ищите способы оптимизации процессов, чтобы постепенно приближать, например, сроки в SLA к тем, которые нужны бизнесу. Этот процесс называется — Service Level Management, SLM.
Источник: gruzdevv.ru
SLA или доверие? Чем укрепим отношения…
Тема SLA – предмет обсуждения не только при определении требований к услуге, но и злободневный вопрос, обсуждаемый на учебных курсах. И интересуют специалистов далеко не только функциональные и не функциональные требования, отражаемые в соглашении. “Арбузный” эффект, операционные и бизнес-метрики мы тоже, конечно же, обсуждаем, но сегодня речь пойдет не об этом.
SLA – это что?
ITIL 4 определяет SLA как:
“Соглашение об уровне услуги (Service level agreement, SLA) — документированное соглашение между поставщиком и заказчиком, которое определяет и требования к услуге, и ожидаемый уровень”
Соглашение между поставщиком и заказчиком, т.е. между двумя субъектами сервисных отношений. Заказчик должен определить свои требования и ожидания относительно потребляемой услуги, а также требования и ожидания других стейкхолдеров (регуляторов, например). Все логично и понятно. Надеюсь, никто не будет спорить, что должны быть выработаны общие с заказчиком видение и целевые показатели. Все это прекрасно, если бы не одно НО…
Очень часто бывает (особенно, если ИТ – внутренний поставщик услуг) когда услуга есть, а SLA нет. Знакомая ведь ситуация? Это приводит к тому, что:
- Качество предоставляемых услуг со стороны бизнеса субъективно и очень размыто, т.к. показатели качества услуги не определены и в чем их измерять – не понятно (может в попугаях?)
- Бизнес-результаты могут быть не достигнуты. (А знают ли в ИТ вообще на что ориентирован бизнес?)
- Бизнес не доволен работой ИТ, и это повод для постоянных обвинений. (А откуда будет удовлетворенность, если ни о чем не договаривались и ни с чем не определялись…)
- Доверие к деятельности ИТ может снижаться, но другого поставщика все равно нет и сервисные отношения превращаются в отношения соседей по коммунальной квартире.
А SLA – это об услугах или отношениях?
На мой взгляд, ответ будет зависеть от типа сервисных отношений. В курсе ITIL 4 Specialist: Drive Stakeholder Value есть таблица, описывающая три вида сервисных отношений и их характеристики:
Обратите внимание, в партнерстве контракты могут быть основаны на результатах или быть без соглашений. Т.е. речь идет о человеческом взаимодействии и о способе построения и поддержания успешных сервисных отношений. Главный критерий для партнерских отношений – высокий уровень доверия между поставщиком и заказчиком.
Нужны ли SLA в семейных отношениях?
На мой взгляд, отношения намного важнее, чем SLA и те KPI, которые в нем могут быть определены. Мы часто фокусируемся на достижении SLA и совсем забываем о человеческой стороне вопроса. Именно в партнерских отношениях можно не формализовать всё в SLA, если у вас общие стратегические цели, ценности, общие риски и общая ответственность.
Вспомните, есть ли у вас SLA в ваших семейных отношениях? Хочется услышать отрицательный ответ.
Отношения делают успешными не контракты. Их успех зависит от взаимной вовлеченности, вашего взаимного доверия, сотрудничества и общих разделяемых целей. Проблемы и риски тоже должны быть общими, а не приводить к прекращению отношений.
Что это может означать для ITSM?
Наряду с практикой управления уровнем услуг, в ITIL4 есть практика управления взаимоотношениями, управления поставщиками. Все эти практики затрагивают тему взаимоотношений. Любые отношения: будь то с внутренними и внешними заказчиками или партнерами – везде, в основе должны быть на первом плане человеческие отношения.
Еще больше про SLA и не только на курсе «ITIL® 4 Foundation» от соавторов ITIL®4 Cleverics. Учитесь у тех кто создает, а не пересказывает.
Я вовсе не агитирую за отказ от SLA. Ведь надо видеть картину целостно: каков уровень зрелости в организации, каков тип сервисных отношений между поставщиком и заказчиком, каково культурное соответствие.
- отражать потребности заказчика,
- получать регулярно обратную связь,
- правильно формировать сервисный опыт.
Это всегда повод для регулярных встреч, обсуждения бизнес-целей или улучшения услуг. Важно, чтобы такие встречи были пространством для решения вопросов, а не обвинений и поиска виноватых.
Я за то, чтобы построение взаимоотношений не ушло на второй план в погоне за подписанием SLA. Все же долгосрочные сервисные отношения намного важнее, а SLA это лишь инструмент для их создания, а не самоцель.
А что вы думаете на этот счет? Рад буду увидеть ваши комментарии.
Также по теме:
- Доверие как основа успешной реализации ИТ-инициатив
- Сo-creation: так все же, кто должен создать ценность или как не причинить помощь?
- Размышления на тему сервисного подхода
- SLA или.
- Value network и сервисный подход
Источник: cleverics.ru
