Облегчаем жизнь с заключением SLA

в 14:33, , рубрики: ITIL, itsm, service desk, sla, бизнес-модели, бизнес-процессы, оферта, Терминология IT, техподдержка, Управление продуктом, шаблоны документов

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

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

  • администрация-руководство и девушки-секретари им всячески помогающие,
  • продавцы — желающие работать удалённо, "бо волка ноги кормят",
  • логисты — ведающие закупками/складом/поставками/транспортом, и желающие жить неплохо,
  • бухгалтерия — учёт всего в денежном выражении,
  • кадры — решение всех вопросов с наймами, отпусками, отсутвиями и здоровьем персонала,
  • безопасность — чтобы ничего не спёрли,
  • маркетологи — как же сайту без них.

И пусть у нас есть каталог сервисов из 11 позиций:

  • рабочие места,
  • печать,
  • 1С склад,
  • 1С бухгалтерия и кадры,
  • Office-софт,
  • сайт,
  • Интернет,
  • Внутренняя сеть,
  • Телефония,
  • Видеонаблюдение и СКУД,
  • VPN — удалённые рабочие места.

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

И становится видно, что даже такое небольшое количество базовых параметров способно легко породить порядка 60 SLA. То есть, конечно соглашений с подразделениями будет 7, но в каждом по 7-10 сервисов с различными опциями по реагированию и срокам устранения.

Оптимизируй это — типовые SLA

Что будет, если опереться на статистику и правило Парето и меньше слушать фантазии требования заказчиков на тему качества и срочности и недовольство начальства при объяснениях, что для удовлетворения всех хотелок бизнеса надо либо ещё 3-4 человека?
А то, что замерив сроки исполнения заявок и удовлетворённость заказчиков можно определить для каждого сервиса следующие параметры:

  • уровень устраивающий 80% заказчиков, что позволит для большинства претензий занять подкреплённую статистикой позицию о том, что оказываемые конкретному подразделению услуги в целом имеют высокое качество и сильно не хуже чем в среднем по компании,
  • кому (может быть и персонально) стоит оказывать VIP сервис.

Это позволит свести количество вариантов предоставления каждого сервиса к 1-3 вариантам и, пользуясь набранной статистикой по срокам и удовлетворённости, опровергать слишком уж завышенные ожидания к срокам реагирования. Что это даёт — типовой SLA, которых вместо 60 уже может вполне оказаться 25-30 штук, что заметно меньше, особенно если структура SLA будет иметь форму рамочного договора, состоящего из основного тела и набора приложений -SLA. Но эти SLA всё ещё пока надо заключать.

Оптимизируем дальше — SLA-оферта

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

При таком подходе возникают следующие тонкости в части отражения ответственности ИТ и представителей бизнеса в SLA :

  • момент акцепта оферты должен быть чётко прописан в части сроков и перехода ответственности на ИТ и обратно на того, кто обратился за сервисом,
  • явная ответственность ИТ за просрочку, выраженная, например, в выдаче статуса VIP на несколько последующих заявок при фиксации задержек исполнения или дисконте на объём потреблённого сервиса,

  • требования к качеству сервиса, выраженные не только в абсолютных величинах, но и позволяющие отклониться от заданных сроков в оговоренных соглашением случаях но тоже в заданных рамках, например: "96% обращений должно быть выполнено в период до 2-х часов, не более 3% обращений допускается выполнять в период не более 4-х часов, не более 1% обращений допускается выполнять в период не более 6-и часов",

  • правила отзыва и изменения оферты и правила изменения какого-либо из сервисов каталога — с предварительным оповещением всех заинтересованных сторон и публикации изменений на интернет портале службы ИТ.

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

  • согласованием каталога сервисов и текста оферты с руководством,
  • выкладыванием указанных выше документов на внутреннем портале ИТ-службы,
  • оповещением, всех, включая свеженанимающихся о данных правилах.

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

Данный подход разработан в одном довольно крупном банке (top-15) в 2010-2011гг.
Текст оферты и пример описания сервиса можно взять тут.
Если у кого будут вопросы — по формулировкам, использованным в соглашении — пишите — готов пояснять почему написано таким образом.

Благодарности и привет коллегам: Новиков Олег, Александр Никулин, Анатолий Малыхин, Санина Ирина, Юрий Саликов, Рустем Еникеев.

Автор: Алексей

Источник

Поделиться

* - обязательные к заполнению поля