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

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

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

Для этого и существует соглашение об уровне услуг — по-английски service level agreement, отсюда и SLAСоглашение об уровне услугЗаписанная договорённость поставщика и заказчика: что даёт услуга, когда доступна и как быстро её восстановят.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» Елхимова; Брукс, «Метрики для управления ИТ-услугами». ITIL определяет SLA как документированную договорённость: в ней названы нужные заказчику услуги и уровень, которого от них ждут 1. ГОСТ Р ИСО/МЭК 20000-1 определяет его почти так же 2.

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

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

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

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

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

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

Три признака. Проверяются они со стороны заказчика, а не изнутри ИТ.

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

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

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

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

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

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

Полезность — что услуга делает: годится ли она для той задачи, ради которой её взяли.

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

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

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

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

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

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

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

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

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

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

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

Сценария два, и они требуют разной работы 1.

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

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

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

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

Три соглашения, которые путают

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

Ту же связку требует FitSM. Под договорённости с заказчиками заключают операционные соглашения и договоры с поставщиками, и все три вида документов пересматривают в заранее установленные сроки. Работу поддерживающих услуг тоже сверяют с целями — только уже с теми, что записаны в этих соглашениях и договорах, а не в SLA 3.

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

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

Процессов два: работа с соглашениями и надзор за уровнем и качеством услуг 1.

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

Шаги с первого по пятый и седьмой — про сам документ, шестой — про то, что происходит с услугой, пока он действует 1.

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

Три места стоит объяснить отдельно.

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

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

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

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

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

SLA и срок на заявке. В рабочем разговоре словом «SLA» чаще всего называют счётчик в системе: сколько осталось до нарушения срока по обращению. Это одна строка соглашения, а не соглашение. У Брукса нарушением SLA считается всё, что вышло за согласованные рамки: инцидент, заявка, любой из согласованных показателей 7. Срок по обращению — лишь одно из оснований считать соглашение нарушенным. Как эти сроки соблюдают, разобрано в INCУправление инцидентами и REQУправление запросами на обслуживание; здесь заказчик и поставщик договариваются, какими они должны быть.

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

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

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

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

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

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

Как измерять

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

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

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

У удовлетворённости тоже есть числа. Брукс меряет её по шкале от нуля до пяти: цель — четвёрка, тревога — всё, что ниже тройки 7. Шкала из шести делений здесь и нужна: она переводит субъективную оценку в число, которое кладётся на панель рядом с процентами.

Соглашение, которое приходится часто править, — плохое соглашение. Доля SLA, изменённых вне планового пересмотра: цель 2%, тревога 4% 7. Различение здесь тонкое и важное: перезаключить соглашение, условия которого не выполняются, — правильно; плохо, что до этого дошло. Рядом — время от первых записанных требований к уровню услуг (service level requirements, SLR) до подписанного SLA: цель 30 дней, тревога 60 7. Показатель говорит не о скорости оформления бумаг, а о способности двух сторон договариваться, и со временем должен сокращаться 7.

Обещание без подпорок не держится. Число ещё не согласованных операционных соглашений (OLA) и внешних договоров (UC) — цель 25, тревога 40 7. Показатель ловит тот самый случай, когда заказчику уровень уже обещан, а договорённости с внутренними командами и поставщиками, которыми это обещание обеспечивается, всё ещё обсуждаются. Услуги совсем без соглашения считаются отдельно: цель 10, тревога 15, а конечная цель — ноль.

Затраты сравнивают индексом, а не деньгами. Целевое значение принимается за 100 вне зависимости от валюты, а превышение этого значения на два процента считается опасным 7. Приём стоит запомнить: он выводит стоимость услуги на ту же панель, где сроки и доступность, не раскрывая сумм и не привязываясь ни к валюте, ни к масштабу организации.

Один показатель Брукс отдаёт соседней практике. Нарушения по вине внешних подрядчиков он относит сюда, но оговаривает: для управления доступностью это число значит больше, чем для управления уровнем услуг 7. Такие пограничные меры полезно закреплять явно — иначе показатель либо считают дважды, либо не считает никто: договорные обязательства разбираются в SUPУправление поставщиками, последствия простоя — в AVLУправление доступностью.

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

✕

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

Шесть мест.

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

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

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

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

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

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

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

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

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

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

FitSM укладывается в пять требований и добавляет обязательную связку с операционными соглашениями и договорами поставщиков 3.

MOF даёт русские определения трёх видов договорённостей и относит работу к выравниванию бизнеса и ИТ 4.

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

Расхождений по существу нет; полезно другое — место практики. У ГОСТ Р ИСО/МЭК 20000-1 требования к ней стоят в разделе «Отношения и соглашения» 2, у COBIT — в домене планирования 5, у MOF — в выравнивании бизнеса и ИТ 4. ITIL называет три главных участка её вклада: планирование, взаимодействие с заказчиком и улучшение 1. Практика, отданная дежурной смене, вырождается в рассылку отчётов.

Где описано

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

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