Рано или поздно при организации технической поддержки в более или менее крупной организации приходится иметь дело вот с этим: с 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гг.
Текст оферты и пример описания сервиса можно взять тут. Если у кого будут вопросы — по формулировкам, использованным в соглашении — пишите — готов пояснять почему написано таким образом.
Благодарности и привет коллегам: Новиков Олег, Александр Никулин, Анатолий Малыхин, Санина Ирина, Юрий Салихов, Рустем Еникеев.