Качественная услуга в SLA не нуждается. Точнее — никого не интересует, какой SLA у услуги, которая устраивает и потребителя, и исполнителя. А если еще точнее, то наличие SLA, а тем более его постоянное совершенствование — это признак тлеющего конфликта и недовольства, нежели артефакт качества.
Представьте интернет-провайдера. Вам все равно, как быстро он отвечает на звонки, если интернет работает стабильно. Но если соединение рвется ежедневно, вы начинаете требовать: фиксированное время ответа оператора, выезд инженера в течение часа, вежливость персонала. SLA растет пропорционально вашему недовольству. Однако ни один из этих пунктов не решает настоящую проблему — нестабильную связь. Они лишь формализуют ваши страдания.
Я 14 лет занимаюсь аудитами ИТ-отделов. За этой услугой обычно приходят, как за средством последней надежды — когда перепробовали все методы управленческого воздействия и они не дали результата. Один из таких инструментов — как раз SLA. В одних случаях он использовался как инструмент давления на ИТ-службу, в других — как инструмент сдерживания запросов со стороны бизнеса. Но во всех случаях он только маскировал исходную проблему и мешал ее решению.
Когда SLA работает против себя
Вот фрагмент SLA из одного аудита:
«Сбой телефона на рабочем месте должен устраняться за 10 минут»
«Организация рабочего места для нового сотрудника – 30 минут максимум»
Такие сроки — это высший уровень для любой службы технической поддержки. Но что стоит за этими цифрами?
10-минутный норматив на сбои появился потому, что телефония падала ежедневно. Единственный способ поддерживать ее работу — тушить каждый инцидент максимально быстро. Когда удалось устранить первопричину, про норматив просто забыли: такие ситуации стали редкостью, и SLA потерял смысл вместе с проблемой, которую закрывал.
30-минутный норматив на рабочее место появился потому, что о выходе нового сотрудника ИТ-служба узнавала уже после того, как тот полдня просидел в офисе без доступа. Проблема была не в скорости ИТ — HR просто не сообщал о новом сотруднике заранее. Когда процессы перестроились — HR начал передавать данные на этапе найма — необходимость в этом пункте отпала как класс.
Оба кейса объединяет одно: SLA фиксировал симптом, а не болезнь. И это не ошибка конкретного менеджера, а системный паттерн.
SLA как симптом, а не решение
Такие ситуации встречаются чуть ли не в каждом втором аудите. Мне регулярно приходится видеть, как SLA используют для компенсации структурных проблем: нехватки ресурсов, несогласованности процессов, низкой компетентности. Документ заменяет разговор, который никто не хочет вести.
Например, дифференцированный SLA — разные условия для разных групп пользователей — почти всегда означает, что ресурсов не хватает на всех. Так называемая «VIP-поддержка» часто говорит не об особой важности топ-менеджеров, а о том, что обслуживать всех одинаково хорошо уже не получается.
Еще один классический пример — SLA «90% заявок закрываются в срок». Такой показатель выглядит как целевой, но, по сути, означает: «мы делаем вид, что работаем, а вы делаете вид, что нам платите». Все понимают, что ИТ-служба не справляется, но формально фиксируют показатель, изначально предполагающий часть незакрытых в срок заявок. Строгий SLA — это конкретное обязательство. Нечеткие договоренности, основанные на вероятностях, не дают информации для принятия управленческих решений.
В ITSM есть такой термин — «арбузный SLA»: снаружи зеленый, внутри красный. Это когда метрики выполнены, но пользователи недовольны. ИТ-служба рапортует об успехах, пока бизнес теряет деньги на простоях, о которых формально никто не обязан отчитываться.
Как SLA с KPI убивает мотивацию
Основная проблема таких SLA в том, что они лишь временно снимают напряженность, оттягивая внимание со стратегических вопросов на ежедневную рутину — и тем самым только все ухудшают.
Когда SLA не решает проблему, следующий шаг — добавить к нему KPI. Логика понятна: если обязательство не выполняется, нужно привязать к нему стимул. Но именно здесь включается механизм, который британский экономист Чарльз Гудхарт описал еще в 1970-х: как только показатель становится целью, он перестает быть хорошим показателем.
Механизм разрушения всегда одинаков. Сначала неудовлетворенность закрывают через SLA, не устраняя первопричину. Первое время все держится на энтузиазме команды. После первых нарушений появляется KPI — и система переходит на страх. Когда и это перестает помогать, руководитель берет ситуацию под личный контроль и пытается в режиме ручного управления заставить работать «этих лентяев». Итог: руководитель ИТ-службы занимается постоянной операционкой, видя в ней основной смысл своего существования, и теряет стратегический горизонт.
Приведу два примера из практики. В первом бизнес спросил: «сколько нужно денег, чтобы этот ужас прекратился?» — но руководитель уже был «в туннеле SLA» и ничего, кроме найма людей, не придумал. За три года ИТ-служба выросла с пяти до восемнадцати специалистов, но лавина заявок росла быстрее. Во втором бизнес решил «стимулировать» специалистов задержками зарплаты, посчитав, что раз те не выполняют свою часть договора, то и он не будет выполнять свою. Система вошла в разрушительный цикл — и закончилось плачевно для всех.
Но чаще ситуация с SLA в привязке к KPI заканчивается не так трагично — обычной имитацией бурной деятельности. Нужно закрыть 90% заявок в срок? Создадим кучу мелких обращений и компенсируем ими те, что не успели. Важна средняя оценка пользователей? Не будем закрывать заявки с очевидно низкой оценкой. Нужно выдержать SLA по всем заявкам? Будем регистрировать их в системе только после выполнения.
Можно нанять внешних операторов для фиксации обращений, выделить сотрудника, который слушает разговоры и выставляет оценку — еще один KPI. Но на любой изысканный метод контроля найдется не менее изысканный метод его обхода. Эту сказку можно продолжать бесконечно, все дальше уходя от вопроса «как сделать нормальный сервис» к вопросу «как выполнить норматив».
Что нужно принять, прежде чем составлять SLA
Первая истина. SLA — не про высокое качество. В рамках ITIL этот инструмент появился с оптимизационной целью: соотнести качество услуги с ее стоимостью. SLA — про «качество, которое можно гарантировать за эти деньги». Если текущий уровень сервиса не устраивает, — его, скорее всего, не улучшить без изменения либо числа рук, либо компетенций, либо процессов, либо технических решений. И обычно это упирается в деньги.
Вторая истина. Уровень качества определяется не средними показателями, а худшим сценарием. Положим, завести нового пользователя занимает три минуты. Но чтобы это сделать, специалист должен быть на работе, не иметь других более срочных задач и не ошибиться в этой. Если иногда это растягивается на три дня — вот реальный SLA.
Третья истина. SLA может быть только строгим. Я видел документы, где написано «90% обращений решаются за 10 минут» — и это выглядит как высокая планка. Но что происходит с оставшимися 10%? Документ молчит. Именно в этом молчании живут самые неприятные разговоры с бизнесом. «100% обращений решаются в течение двух рабочих дней» звучит скромнее, но честнее: бизнес знает, чего ждать в худшем случае, и не получает сюрпризов.
Четвертая истина. Если вы не можете зафиксировать строгий SLA потому что худшие сценарии выходят из вашей зоны контроля (отключение единственного интернет-канала, сбой электроснабжения, отказ единственного сервера) — все эти события можно и нужно описать как исключения, при которых SLA может быть нарушен. Это снимает необоснованные претензии и дает бизнесу ясную картину рисков, с которыми он работает.
Пятая истина. Прежде, чем прописывать частности, измерьте ключевые показатели. Я встречал компании, где в SLA было прописано все — от времени ответа на звонок до расположения бейджика у специалиста, — но никто не знал RTO и RPO даже у самого критичного бизнес-приложения. Понятное дело, что самые большие разочарования бизнес испытывал в этих компаниях не от того, что бейджик висел как-то не так.
Как выглядит рабочий SLA
Рабочий SLA — это тот, который позволяет ИТ-службе работать спокойно, без суеты и постоянного тушения пожаров. Он строится на крепкой почве текущих возможностей ИТ-службы, а не на том, что хотелось бы показать. И да, он не понравится и даже напугает бизнес. Но именно понимание разрыва между ожиданиями и реальностью позволяет вывести сервис на нужный уровень — не за счет оптимизации SLA, а за счет реальных изменений.
Ожидания бизнеса
«Фиктивный» SLA
Рабочий SLA
Как закрыть ожидание
Колл-центр обслуживает клиентов без перебоев
Сбой телефона устраняется за 10 минут
Восстановление телефонии — 4 часа. Исключения: сбой оператора связи, отказ АТС, отключение электроснабжения — в этих случаях сроки зависят от внешних подрядчиков
Дополнительные инвестиции в инфраструктуру для повышения стабильности и снижения числа сбоев. Резервирование на рабочих местах. Готовые обходные решения на случай форс-мажора
Новый сотрудник выходит на работу с готовым рабочим местом
Рабочее место организуется за 30 минут
Рабочее место организуется за 3 рабочих дня
Уведомление ИТ-службы об открытии вакансии заранее, до выхода сотрудника. Формирование резерва оборудования для организации рабочего места
Печать на критичных участках не останавливается из-за расходников
Замена картриджа — 15 минут
Картридж заменяется в течение четырех часов
Замена картриджа при остатке 15% — до того, как печать встала
Реальный SLA может показаться совершенно не клиентоориентированным. Фиктивный выглядит красиво — амбициозные сроки, высокие планки. Реальный на его фоне кажется «ленивым».
Но именно принятие реальности и позволяет задать стратегические вопросы:
- «Что мы можем сделать, чтобы, меняя картриджи за 4 часа, бизнес не испытывал сложностей с печатью?»
- «Зная, что на устранение аварии за 4 часа неприемлемо, что мы можем сделать, чтобы аварий не возникало?»
И ответы на эти вопросы создают иную ценность, которую никакими SLA не описать.
В итоге «реальный» SLA:
- никак не отрицает достижение результатов «фиктивного»;
- продается хуже «фиктивного»;
- дает бизнесу честную картину текущих возможностей и рисков ИТ;
- позволяет заранее обдумать плохие сценарии;
- долгосрочно работает лучше, чем «фиктивный».
Вывод
В начале я написал, что «хорошая услуга в SLA не нуждается». Это не значит, что SLA не нужен вовсе — это значит, что он не делает сервис качественным сам по себе. Хорошая услуга стабильно удовлетворяет потребности клиента. SLA лишь описывает границы деградации. И чем шире они расписаны — тем хуже, как правило, услуга. Зачастую развернутый и детализированный SLA — это тревожный сигнал.
Задача SLA — не давать обещания, а донести реальность: насколько могут деградировать те или иные услуги исходя из текущего положения дел. Бизнес, который понимает реальные риски своей инфраструктуры, может осознанно выбирать — инвестировать в их снижение, перестроить процессы или принять как есть. Бизнесу, которому показывают зеленые метрики, такой выбор недоступен.
Поэтому SLA — не про успокоение сторон, а про честный разговор о том, что есть на самом деле. И если этот разговор состоялся, со временем уже никто не вспомнит, каким был исходный SLA.
Именно в этот момент сервис обычно начинает работать по-настоящему хорошо.