Рано или поздно при организации технической поддержки в более или менее крупной организации приходится иметь дело вот с этим: с SLA. И тут возникает ряд задач, успешно решив которые можно сильно упростить себе жизнь.
Итак предположим, что в нашей организации есть следующие подразделения, помимо ИТ: И пусть у нас есть каталог сервисов из 11 позиций: Так вот, если хочется сделать все по науке, но не особо вдаваться в суть процессов организации поддержки, то придётся заключить достаточно много SLA т.к. каждому подразделению нужен свой набор сервисов со своими в общем-то условиями поддержки, которых минимум бывает два: VIP и стандарт, но возможны и другие варианты, особенно если компания расположена в нескольких часовых поясах. И становится видно, что даже такое небольшое количество базовых параметров способно легко породить порядка 60 SLA. То есть, конечно соглашений с подразделениями будет 7, но в каждом по 7-10 сервисов с различными опциями по реагированию и срокам устранения. Что будет, если опереться на статистику и правило Парето и меньше слушать фантазии требования заказчиков на тему качества и срочности и недовольство начальства при объяснениях, что для удовлетворения всех хотелок бизнеса надо либо ещё 3-4 человека?
А то, что замерив сроки исполнения заявок и удовлетворённость заказчиков можно определить для каждого сервиса следующие параметры: Это позволит свести количество вариантов предоставления каждого сервиса к 1-3 вариантам и, пользуясь набранной статистикой по срокам и удовлетворённости, опровергать слишком уж завышенные ожидания к срокам реагирования. Что это даёт — типовой SLA, которых вместо 60 уже может вполне оказаться 25-30 штук, что заметно меньше, особенно если структура SLA будет иметь форму рамочного договора, состоящего из основного тела и набора приложений -SLA. Но эти SLA всё ещё пока надо заключать. Виду того, что статистикой мы уже располагаем и умеем отличать VIP от "не VIP", то можно подумать о следующем моменте: "сотрудник компании обращаясь за конкретным сервисом, соглашается тем самым с условиями его предоставления, опубликованными публично".
Что практически сразу приводит нас к выводу о том, что SLA по сути может заключаться в момент обращения за сервисом, если он изложен в форме Оферты.  При таком подходе возникают следующие тонкости в части отражения ответственности ИТ и представителей бизнеса в SLA : Приведенный выше подход позволит в принципе отказаться от заключения SLA в большинстве случаев, ограничившись: При этом "классические" SLA в форме соглашения сохраняются, но не в массе, а для особых случаев, не покрываемых офертой. Например круглосуточная доступность по телефону/интернету администраторов серверов и системы видеонаблюдения, и это будут именно объективно повышенные требования к качеству сервиса т.к. они "не ложатся" ни на один из стандартных уровней оферты.  Данный подход разработан в одном довольно крупном банке (top-15) в 2010-2011гг.
Текст оферты и пример описания сервиса можно взять тут. Если у кого будут вопросы — по формулировкам, использованным в соглашении — пишите — готов пояснять почему написано таким образом.  Благодарности и привет коллегам: Новиков Олег, Александр Никулин, Анатолий Малыхин, Санина Ирина, Юрий Салихов, Рустем Еникеев. Математик