Когда в компании нет SLA, поддержка почти всегда выглядит для бизнеса одинаково: чинят как получится, а приоритеты определяет тот, кто громче кричит. Снаружи это похоже на проблему ИТ. На практике это проблема управления

SLA - это не формальность и не бумага для аудитора. Это договоренность бизнеса и ИТ о том, что считать критичной проблемой, за сколько нужно отреагировать, за сколько решить, в какие часы работает поддержка, какие есть исключения и кто персонально отвечает за сервис. В рабочем SLA обычно фиксируются измеряемые показатели, матрица приоритетов, сроки по разным сервисам, расписание поддержки, владелец сервиса и ФИО ответственного. Примеры того, как это выглядит на практике, лучше показать на скриншотах к статье.

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

Самое важное, что обычно недооценивают собственники и CEO: процент выполнения SLA в срок напрямую определяет стоимость поддержки. Чем выше нужен уровень сервиса, тем больше компании приходится покупать людей, резерв мощности, более сильную маршрутизацию, дежурства и управленческую дисциплину. И вот здесь начинается взрослый разговор: не «почему ИТ не успевает», а «сколько бизнес готов платить за снижение своих потерь». Требовать SLA 95% при бюджете на SLA 65% - это не управление, а самообман.

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

У меня был кейс, когда после такой приоритизации вскрылась неприятная правда. Больше всего негатива вызывали не самые критичные инциденты, а заявки с низким уровнем сервиса. Их долго обсуждали, по ним шли эскалации, переписка, звонки и бесконечные «ну когда уже?». В итоге компания теряла не только время поддержки, но и часы руководителей бизнеса, ИТ и смежных подразделений. Когда SLA зафиксировали, эмоциональных споров стало в разы меньше. Недовольство останавливалось уже на первом руководителе, потому что у него перед глазами были согласованные сроки, логика приоритета и понятный владелец сервиса. А если бизнес хотел быстрее, это уже был не скандал, а пересмотр уровня сервиса, ресурсов и бюджета.

Пересматривать SLA тоже нужно регулярно. Первый раз - вскоре после запуска, когда уже виден реальный поток обращений. Дальше - раз в квартал или при заметном изменении нагрузки, процессов или критичности сервиса. SLA не высечен в камне. Это рабочий инструмент управления стоимостью сервиса.

Именно поэтому сильный SLA нужен не ИТ. Он нужен бизнесу, чтобы перевести хаос ожиданий в управляемую экономику. Пока SLA нет, компания спорит эмоциями. Когда SLA есть, компания управляет деньгами, потерями и скоростью сервиса.

В следующей статье я отдельно покажу на цифрах, как один и тот же сервис может стоить бизнесу в разы дороже только из-за неправильно выбранного уровня SLA.

#SLA  #ServiceDesk #CIO #CEO #операционноеуправление #техподдержка #цифроваятрансформация