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

SLA или доверие? Чем укрепим отношения…

Тема SLA – предмет обсуждения не только при определении требований к услуге, но и злободневный вопрос, обсуждаемый на учебных курсах. И интересуют специалистов далеко не только функциональные и не функциональные требования, отражаемые в соглашении. “Арбузный” эффект, операционные и бизнес-метрики мы тоже, конечно же, обсуждаем, но сегодня речь пойдет не об этом.

 

SLA – это что?

ITIL 4 определяет SLA как:

Соглашение об уровне услуги (Service level agreement, SLA) — документированное соглашение между поставщиком и заказчиком, которое определяет и требования к услуге, и ожидаемый уровень”

Соглашение между поставщиком и заказчиком, т.е. между двумя субъектами сервисных отношений. Заказчик должен определить свои требования и ожидания относительно потребляемой услуги, а также требования и ожидания других стейкхолдеров (регуляторов, например). Все логично и понятно. Надеюсь, никто не будет спорить, что должны быть выработаны общие с заказчиком видение и целевые показатели. Все это прекрасно, если бы не одно НО…

Очень часто бывает (особенно, если ИТ – внутренний поставщик услуг) когда услуга есть, а SLA нет. Знакомая ведь ситуация? Это приводит к тому, что:

  1. Качество предоставляемых услуг со стороны бизнеса субъективно и очень размыто, т.к. показатели качества услуги не определены и в чем их измерять – не понятно (может в попугаях?)
  2. Бизнес-результаты могут быть не достигнуты. (А знают ли в ИТ вообще на что ориентирован бизнес?)
  3. Бизнес не доволен работой ИТ, и это повод для постоянных обвинений. (А откуда будет удовлетворенность, если ни о чем не договаривались и ни с чем не определялись…)
  4. Доверие к деятельности ИТ может снижаться, но другого поставщика все равно нет и сервисные отношения превращаются в отношения соседей по коммунальной квартире.

 

А 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. Все же долгосрочные сервисные отношения намного важнее, а SLA это лишь инструмент для их создания, а не самоцель.

 

А что вы думаете на этот счет? Рад буду увидеть ваши комментарии.

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от соавторов ITIL 4

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

  • Лилия

    Доброго дня!

    SLA прекрасно отвечает на вопрос «А каким у нас является уровень сервиса? Вот прям конкретика». Например, инцидент-менеджмент: скорость обработки заявок ожидается 96% в согласованные сроки (какие), прописывается формула, как должен считаться показатель (чтобы понимать, от чего он зависит, а не просто на голую цифру смотреть). Если голая цель — можно не париться, в конце концов «хакнуть» метрику.

    Если ориентир, а уж тем более с другими метриками — дело пойдет иначе (если не лень, конечно). Можно уже спокойно работать над практиками, чтобы улучшить показатели. И не будет катастрофой, если вдруг 94% (а не 96%), но при этом мы понимаем, почему так, и какой план совершенствования. При всем при этом уж тем более «не бить» за низкие цифры, иначе мотивации работать в таком ключе не будет.

    • Лилия, Вы правы в том, что часто SLA отвечает на вопрос «А каким у нас является уровень сервиса? Т.е. фокус на нас (на провайдере). А ведь при этом надо помнить, что это «... документированное соглашение между поставщиком и заказчиком, которое определяет и требования к услуге, и ожидаемый уровень». Требование определяет заказчик, ожидаемый уровень — заказчик и регуляторы, например (сторона потребителя). «Хакнуть» метрику — тоже жизненно... Но зачем? Метрика ради метрики? Или «арбузный» эффект в отчетности развиваем? 🙂

      А как же наш потребитель в лице заказчика? Как его ожидания, бизнес-задачи? Помогает ли ИТ в этом бизнесу? Опять бизнес оказался за бортом, и разговор ИТ с бизнесом с разных сторон баррикад. А когда же будет ориентир на долгосрочные сервисные отношения, сотрудничество, партнерство? Чтобы звучало чаще «Мы», «Наше»... Или с внутренним поставщиком так не бывает? Как сделать, чтобы ИТ был для бизнеса не чемодан без ручки, а партнер? Неужели только цифровая трансформация (не к ночи будет помянута) поможет ИТ и бизнес объединить?


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

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM