Что такое управление уровнем услуг и почему SLA выполняется, а заказчик недоволен

Зачем управление уровнем услуг

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

Пять слов, без которых дальше не обойтись

Услуга (service) — то, что поставщик делает для заказчика, чтобы тот получил нужный результат без всей технической работы.

Поставщик, заказчик и пользователь. Поставщик (service provider) услугу делает, заказчик (customer) решает, что ему нужно, и платит, пользователь (user) услугой пользуется.

Уровень услуги (service level) — один или несколько показателей того, насколько хорошо услуга должна работать или работала: например, доля времени, когда система доступна, или срок ответа поддержки 1.

Соглашение об уровне услугСоглашение об уровне услугЗаписанная договорённость поставщика и заказчика: что услуга должна уметь, насколько надёжно работать и как это проверить.ITIL 4: практическое руководство Service Level Management и книга ITIL Foundation, 5.2.15.1; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.16, 3.2.20, 3.2.21, 7.5.4, 8.3.2–8.3.4; FitSM-0, FitSM-1 (PR2), FitSM-2 (PR2), шаблон и образец SLA из FitSM-4; MOF 4.0, глоссарий; itSMF, «Введение в ИТ Сервис-менеджмент», 2003; Ami Nahari, «Secrets of Service Level Management», TSO, 2013; Молоткова, Сахаров, «Качество услуг ИТ-аутсорсинга», 2008; «Аутсорсинг в стратегии современного бизнеса», 2019; альманах itSMF России, 2015; «Свободный ITIL» Елхимова; Брукс, «Метрики для управления ИТ-услугами» (service level agreement, SLA) — записанная договорённость поставщика и заказчика: какие услуги нужны и какого уровня от них ждут 1 2.

ИнцидентИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами (incident) — незапланированный перерыв в работе услуги или ухудшение её качества: приложение не открывается, не работает оплата.

Как это выглядит в жизни. Условная компания-разработчик на 60 человек делает мобильное приложение для сети фитнес-клубов: запись на тренировки, оплата абонементов, уведомления. Сеть — заказчик, она платит за разработку и сопровождение. Посетители клубов — клиенты сети и пользователи приложения.

К договору приложили SLA на полстраницы: приложение доступно 99,5 % времени в месяц, поддержка отвечает на обращение в течение часа.

Через три месяца Марина, менеджер по уровню услуг, собирает отчёт: все строки зелёные.

А руководитель цифровых сервисов заказчика на встрече перечисляет своё. С вечера пятницы клиенты не могли оплатить абонементы: исправление написали за час, выпустили через два дня. Запись на тренировку бросают на середине. В январскую распродажу приложение грузилось по минуте.

В SLA не было ни слова о том, что важно бизнесу заказчика: проходит ли оплата, удобна ли запись, выдержит ли система наплыв покупателей. Отчёт ежемесячно уходил по почте, а обсудили его впервые, когда заказчик уже был недоволен. Управление уровнем услуг не даёт до этого дойти.

Цель практикиПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 ITIL — самый известный свод советов об организации работы ИТ — формулирует так: задать цели по уровню услуг, понятные бизнесу, и следить, чтобы предоставление услуг оценивали по этим целям и подстраивали под них 1.

ГОСТ Р ИСО/МЭК 20000-1 — российский стандарт управления услугами, идентичный ISO/IEC 20000-1:2018, — требует по каждой предоставляемой услуге одно или несколько SLA 2. Он включает в них цели, предельную рабочую нагрузку и исключения — случаи, на которые обещание не распространяется. Цель задают целевым показателем уровня сервиса — измеримой характеристикой, которой организация обязуется соответствовать 2.

Главная трудность. Измеримый уровень всегда охватывает лишь часть качества услуги 1. Поэтому показатели дополняют обратной связью от людей, а не заменяют её.

Эффект арбуза: снаружи все показатели зелёные, а внутри арбуз красный — так услугу видят те, кто ею пользуется 1.

Когда практика работает

Три признака, и проверять их нужно глазами заказчика, а не изнутри ИТ.

Заказчик знает, чего ждать, и это записано. Как проверить: по каждой значимой услуге есть SLA с целями, предельной нагрузкой и исключениями 2.

Отчёт читают, а не подшивают. Как проверить: последний отчёт обсуждали с заказчиком, и обсуждение закончилось решением, что менять.

Удовлетворённость меряют отдельно от показателей. Как проверить: данные опросов и жалоб сравнивают с зелёными цифрами отчёта 1 2. В примере жалобы из системы поддержки сводят в таблицу рядом с процентами доступности.

Что входит и что рядом

Полезность и гарантия: почему уровень услуги не только про сбои

У услуги две стороны 1.

Полезность (utility) — что услуга делает и годится ли она для задачи. Приложение умеет записать на тренировку и принять оплату.

Гарантия (warranty) — как услуга работает: доступность, мощность, безопасность, непрерывность. Система не тормозит в час пик и не теряет данные карт.

Привычка сводить соглашение к одной гарантии пришла из разделения труда: одни разрабатывают, другие эксплуатируют. ITIL называет этот раскол причиной формального понимания качества: уровень услуги должен покрывать обе стороны 1.

Если в SLA есть проценты доступности и нет ни строки о том, что услуга должна уметь, договорились только о половине.

Что на входе и что на выходе

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

Наружу уходят согласованные цели для поддержки, разработки и соседних практик.

Своих измерений у практики нет. Данные собирают системы наблюдения и отчётность, а практика извлекает из этих данных смысл и обсуждает его с заказчиком 1.

Из чего состоит соглашение

ГОСТ Р ИСО/МЭК 20000-1 задаёт обязательный минимум: цели, предельная рабочая нагрузка и исключения 2. ITIL перечисляет стороны качества, по которым ставят цели 1.

Предельная рабочая нагрузка и исключения обязательны по ГОСТ 2. Без записанного предела SLA обещает одно и то же и в обычный день, и при десятикратном наплыве. Отсюда спор после январской распродажи: заказчик винил систему, а поставщик отвечал, что о таком наплыве не договаривались.

Без исключений тот же спор возникает о плановых работах.

Соглашение под заказчика и «из коробки»

ITIL различает два сценария 1.

Услуга под заказчика. Цели обсуждают до начала работы: заказчик рассказывает об ожиданиях, стороны договариваются о требованиях, поставщик описывает уровень, за который готов отвечать. Ожидания шире требований, требования шире записанного уровня 1. Бизнес заказчика ждёт, что «всё работает всегда», требование звучит как «оплата проходит круглосуточно», а в SLA попадает «99 % оплат проходят с первой попытки».

Услуга «из коробки». Уровни заданы заранее, иногда под именами вроде золотого, серебряного и бронзового, и заказчик выбирает из готовых 1. Практика тут не ведёт переговоры, а изучает, чего ждут люди, и честно объявляет, что им дают.

Для посетителей приложение — именно такая услуга.

SLA, OLA и договор с подрядчиком — три документа, которые путают

SLA выполнимо ровно настолько, насколько его обеспечивают два других документа.

Если платёжный сервис по договору может лежать шесть часов в месяц, обещание «оплата не прервётся больше чем на час» некому выполнять. Поэтому «Свободный ITIL» С. В. Елхимова советует перед созданием нового SLA или изменением действующего пересмотреть OLA 6.

ГОСТ Р ИСО/МЭК 20000-1 велит сверять цели договора с подрядчиком с тем, что обещано заказчику 2.

Как это работает

В ITIL у практики два процесса: работа с соглашениями и надзор за уровнем и качеством услуг 1. Справочник раскладывает их на семь шагов.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение работа с людьми и сторонами

Шаги 1–5 и 7 — процесс согласования SLA и работы с ним, шаг 6 — надзор, пока SLA действует 1. У ITIL есть и восьмое действие: когда услуга больше не нужна, соглашение закрывают 1.

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

Шестой шаг ведут с трёх сторон: достигнутый уровень против согласованного, удовлетворённость пользователей, удовлетворённость заказчика 1. Данные о достигнутом уровне дают системы наблюдения, оценки пользователей — опросы после обращений, мнение заказчика — обзоры.

Сюда же сводят информацию об инцидентах и о том, как они сказались на бизнесе.

Седьмой шаг — тот, ради которого всё затевалось. Обзоры реже раза в три месяца работают плохо, а чаще раза в месяц их обычно не проводят 1. Внеочередной обзор нужен после крупного инцидента, заметного изменения услуги или при новых потребностях заказчика 1. Пятница без оплаты — как раз такой повод.

Что с чем путают

Соглашение и договор. Договор имеет юридическую силу: его можно защищать в суде. SLA может входить в договор, а может быть внутренней договорённостью без юридической силы 1. ГОСТ Р ИСО/МЭК 20000-1 признаёт соглашением даже устную договорённость, записанную в протоколе совещания, или договорённость в письме 2.

SLA и срок по обращению. В рабочем разговоре «SLA» чаще всего называют счётчик в системе поддержки: сколько осталось до нарушения срока. Это одна строка соглашения.

У Питера Брукса нарушением SLA считается всё, что вышло за согласованные рамки: инцидент, запрос, любой показатель 7. SLA нарушается и тогда, когда таймеры в порядке, а клиенты не могут оплатить абонемент. Как сроки соблюдают, разобрано в INCУправление инцидентами и REQУправление запросами на обслуживание.

Управление уровнем услуг и управление отношениями. Стратегический разговор с руководством заказчика — работа RELУправление отношениями, разговоры о качестве конкретных услуг — этой практики 1.

Отчёт и обзор. Отчёт — документ с цифрами, обзор — разговор, где стороны делают выводы. Кто рассылает отчёты без обзоров, ведёт переписку, а не практику.

Кто участвует

В ITIL за всю практику отвечает владелец услуги 1. Отдельного подразделения обычно не заводят: где услуги продают наружу, работу делят с теми, кто ведёт отношения с заказчиком 1.

«Свободный ITIL» называет процесс точкой взаимодействия: он представляет поставщика бизнесу и бизнес — поставщику 6. Менеджера по уровню услуг должны понимать обе стороны, и он не становится адвокатом одной из них.

Как измерять

Две меры всегда держат рядом: достижение целей и удовлетворённость. Их расхождение — самый ценный сигнал практики: либо меряют не то, что важно людям, либо люди ждали не того, о чём договорились.

Мерить стоит и случаи, когда до нарушения SLA оставался шаг. У Брукса это обращения, по которым до нарушения осталось полчаса или меньше; порог можно задать и долей израсходованного времени, 80 % 7. Цель — 10 случаев за период, порог тревоги — 25, как и у самих нарушений 7.

Разница двух чисел — случаи, которые успели спасти: отчёт о выполнении их не покажет, а усталость команды покажет.

Значения Брукса — образцы, а не отраслевая норма. Переносить стоит привычку держать у показателя две границы: цель и порог, после которого нужно решение.

Остальные меры Брукса, цель и порог тревоги 7:

• степень удовлетворённости клиентов по шкале 0–5 — 4 и ниже 3;
• доля SLA, изменённых вне планового пересмотра, — 2 % и 4 %;
• пересмотры вовремя — 95 % и 90 %;
• время от требований к уровню услуг (service level requirements, SLR) до подписанного SLA — 30 и 60 дней;
• несогласованные OLA и UC — 25 и 40;
• услуги без SLA — 10 и 15.

Время до подписания показывает, как идёт процесс согласования SLA, то есть умеют ли стороны договариваться 7.

Затраты показывают индексом. Цель принимают за 100 в любой валюте, опасное значение — 102 7. Так стоимость обслуживания попадает в отчёт без сумм.

Зрелость управления уровнем услуг

✕

Компания из примера — на втором уровне: ожидания заказчика проговорены, но записаны только доступность и срок ответа. Шаг на третий — SLA с оплатой, нагрузкой и исключениями.

Где ломается чаще всего

Соглашение подписали и забыли. Услуга дважды изменилась, цели прежние, хотя ГОСТ Р ИСО/МЭК 20000-1 требует регулярного мониторинга, анализа и отчётности по целям 2.

В соглашении только гарантия. Проценты доступности есть, а о том, что услуга должна уметь, ни строки 1.

Обещали больше, чем держат внутренние договорённости. SLA есть, OLA и договоров под него нет 3.

Отчёт вместо разговора. Цифры рассылают, обзоры не проводят. ITIL связывает качество обзоров с удовлетворённостью 1.

Удовлетворённость не меряют. Остаётся технический взгляд, и появляется арбуз 1. Жалобы оседают в почте поддержки и в отчёт не попадают.

Нет предельной нагрузки и исключений. Спор о плановых работах возникает на первом же отчёте 2.

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ГОСТ Р ИСО/МЭК 20000-1 в пункте 8.3.3 требует SLA по каждой услуге с целями, нагрузкой и исключениями, регулярной отчётности, а при недостижении целей — поиска возможностей для улучшения; удовлетворённость и жалобы — в пункте 8.3.2 2.

FitSM, лёгкий стандарт управления услугами, требует соглашений по всем услугам, их пересмотра в установленные сроки и связки с OLA и договорами поставщиков 3.

MOF (Microsoft Operations Framework) даёт русские определения трёх договорённостей, в том числе соглашения об уровне обслуживания. Управление уровнями услуг он определяет через мониторинг, отчётность и проверку соблюдения уровня и относит к выравниванию бизнеса и ИТ 4.

COBIT держит соглашения об услугах в цели APO09, в домене планирования 5.

Расхождений по существу нет. ITIL называет три участка вклада практики: планирование, работу с заказчиком и улучшение 1. Отсюда вывод: практика, отданная дежурной смене, вырождается в рассылку отчётов.

Тем, кто столкнулся с арбузом, полезны XLA — соглашение об уровне впечатления (experience level agreement) — и SRE, подход Google к надёжности с целевыми показателями (service level objectives).

Где описано

Что почитать дальше

Три соседние практики, без которых соглашение не выполняется: SCMУправление каталогом услуг — что есть в перечне услуг, AVLУправление доступностью — откуда берутся цели по доступности, REPИзмерение и отчётность — как отчёт превращается в разговор.