Портал №1 по управлению цифровыми
и информационными технологиями

SLA – корень зла?

little-devilИнтересную точку зрения на уровни услуг и SLA изложил в своей заметке Гэрри Джонстон (Garry Johnston), по его мнению, SLA это ответ на проблемы, уровни услуг не направлены на поиск возможностей, не предназначены для формирования положительного впечатления заказчика. Почему же «в наш век клиентоориентированности и сверхскоростных инноваций уровни услуг больше похожи на отголосок забытой корпоративной истории, чем на портал в будущее»?

Гэрри Джонстон рассматривает три проблемы, связанные с уровнем обслуживания, на примере звонка в службу поддержки.

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

Как клиенту, мне не интересно, когда я звоню, что на 90% звонков отвечают в течение 30 секунд, а мой шанс, что мне не ответят, равен 10%. Как клиенту, мне важно, чтобы то, зачем я звоню, было сделано и получить при этом положительные эмоции.

Вторая проблема – SLA намеренно «убивают» инновации и совершенствования. Причина в том, что SLA – это контракт, а основная функция контракта состоит в исполнении обязательств.

SLA – это гарантия безопасности в трудные времена: когда что-то пойдет не так, проблема будет решена согласно условиям контракта. Да и кто в здравом уме подпишет контракт на инновации и совершенствования?

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

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

Гэрри Джонстон поделился советами из собственного опыта, как можно решить подобные проблемы:

  1. Измените язык общения с клиентами, начните измерять показатели, отражающие реальный клиентский опыт, поймите кто ваши клиенты, что они хотят получить и какого ждут к себе отношения
  2. «Выбросьте контракт», или хотя бы перестаньте следовать только букве контракта. Найдите возможность для вашей команды раз в день улучшать что-нибудь, неважно будет это большое или маленькое улучшение, попробуйте измерить количество улучшений, вы удивитесь!
  3. Дайте первой линии достаточные полномочия и ответственность, например, приостановить изменение, если оно приведет к негативным последствиям для клиента, сделайте их ответственными за проведение улучшений процессов клиентского обслуживания, не в крупных проектах, а в текущей деятельности
«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

Комментариев: 7

  • Особенно п.3!!!

  • Sergey Kustov

    Sergey Kustov

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

  • Нуу, довольно фаталистический взгляд. Немного творчества вдохнет жизнь в любую линию. Кстати, влияние эмоций намного выше влияния рационального расчета 🙂

    • Довольно реалистичный взгляд, я бы сказал. А "творчество" в среде эксплуатации не приветствуется.

  • Алексей

    Хм… По мне, так у нас давно SLA является "полупроводником" – критерии и нормы работают когда что-либо сломалось и нужно пожурить Исполителя. А когда Заказчику нужно что-нибудь быстро сделать и скоренько переписать пол системы, чтоб к утру работало, то тут как раз и отменяются все табу от SLA.

    • Напоминает описание полупроницаемой мембраны.

    • Ну и айтишники, со своей стороны, тоже не уступают. Определяют услуги на яыке систем, выстраивают заборы ограничений. Такой Service Level Antagonism получается. Двусторонний 🙂


Добавить комментарий для Денис ДенисовОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM