Привет, на связи Дмитрий Бессольцев, руководитель ALP ITSM. Уже 30 лет мы помогаем компаниям наводить порядок в ИТ‑инфраструктуре: от аудита и восстановления после сбоев до управления ИТ как сервисом для бизнеса. В этой статье — прикладной разбор для руководителей и ИТ-директоров: чем XLA отличается от SLA, почему переход к метрикам опыта стал необходимостью именно сейчас и как внедрять XLA без революций и завала Service Desk.
Что такое SLA и почему оно устарело
SLA (Service Level Agreement) — это соглашение об уровне услуг. По сути, технический контракт между ИТ и бизнесом с набором формальных метрик: доступность сервера, время реакции на инцидент, скорость отклика системы.
Что измеряет SLA:
Доступность сервиса (например, 99,9% в месяц).
Время реакции и время решения инцидента.
Технические параметры работы приложений и каналов связи.
Как это работает: если показатели в норме — отчеты зеленые, подрядчик и ИТ‑отдел получают премию. Если нет — штрафы, разбор полетов и новые регламенты.
Проблема в том, что SLA смотрит только на «железо и софт», но не видит людей. На практике возникает «эффект арбуза»: снаружи всё зеленое, внутри — красное. Или другой пример, доступность сервиса может быть 99,9%, но рабочие сценарии неудобны, пользователи тратят лишнее время на то, чтобы пробраться среди дебрей интерфейса к нужной функции, и постоянно испытывают ощущение, что ИТ «тормозит бизнес», хотя и доступность высокая, и время реакции при возникновении проблем быстрое. Что такое XLA
XLA (Experience Level Agreement) — это соглашение об уровне опыта сотрудников и заказчика. Его задача — измерять не только «работает/не работает», а реальную продуктивность и удобство работы с ИТ-сервисами.
Ключевое различие:
SLA спрашивает: «Сервис доступен? Пакеты ходят? Ответ уложился в регламент?»
XLA спрашивает: «Может ли сотрудник спокойно и продуктивно делать свою работу?»
Важно: XLA не заменяет SLA и не отменяет техническую гигиену. SLA остается фундаментом, который гарантирует базовую стабильность. XLA становится надстройкой, которая показывает, какую ценность эта стабильность приносит бизнесу через опыт пользователей.
SLA vs XLA: в чем принципиальная разница
Критерий | SLA (Service Level Agreement) | XLA (Experience Level Agreement) |
Объект измерения | Технические показатели и выполнение процессов | Опыт пользователей и бизнес-результат |
Вопрос, на который отвечает | «Работает ли система в рамках регламента?» | «Могут ли люди эффективно работать с этой системой?» |
Тип результата | Output: аптайм, скорость, количество тикетов | Outcome: продуктивность, удовлетворенность, вовлеченность |
Логика мотивации | Штрафы за нарушение параметров | Бонусы за улучшение опыта и эффективности |
Работа с метриками | Фиксированные пороги | Постоянный пересмотр целевых уровней под бизнес‑цели |
Почему внедрять XLA нужно именно сейчас
До недавнего времени XLA выглядело как красивая концепция для крупных западных корпораций. В последние годы ситуация изменилась: появились доступные инструменты и накопилась критическая усталость от «зеленых отчетов при красных лицах пользователей».
Сработали два фактора:
Технологии: AI‑аналитика в Service Desk и мониторинге позволяет дешево и регулярно измерять настроение пользователей по тону обращений и количеству жалоб, а не только по формальным оценкам.
Зрелость рынка: по данным опроса Version1, 55% респондентов планируют внедрение XLA в ближайший год, а обсуждение в сообществах Gartner сместилось из плоскости «что это такое» в плоскость «как это делать в наших процессах».
Для российских компаний дополнительный триггер — давление на производительность: саппорта меньше, бизнес‑целей больше, а терпимость к «тормозящему ИТ» у сотрудников и собственников падает.
Цена игнорирования опыта сотрудников
Отношение к цифровому опыту сотрудников (DEX — Digital Employee Experience) перестало быть «мягкой темой». Есть цифры:
Потери рабочего времени из‑за медленных систем и неудобного ИТ измеряются целыми месяцами на одного сотрудника в год.
Низкий цифровой опыт напрямую связан с выгоранием и снижением вовлеченности, что бьет по выручке и клиентскому сервису.
Часть сотрудников, особенно в дефицитных профессиях, готовы увольняться, если ежедневно сталкиваются с тормозящими инструментами и хаосом в ИТ.
Руководителю больше нельзя ограничиваться вопросом: «Сколько тикетов закрыто в срок?». Важнее другое: «Сколько продуктивных часов мы теряем каждую неделю из‑за ИТ и где это отражается в P&L?»
Как подойти к XLA: три уровня зрелости
Не обязательно сразу переписывать все договоры и KPI. Практичный подход — двигаться по уровням зрелости XLA и использовать их как надстройку над существующим SLA.
Уровень 1. XLA 1.0: начать слушать пользователей
Замените формальную «оценку работы» на вопрос о том, насколько легко было решить проблему или выполнить задачу.
Добавьте отслеживание жалоб и негативных формулировок в тикетах и чатах как сигнал к разбору, даже если SLA соблюден.
Уровень 2. XLA 2.0: связать «технику» с опытом
Сопоставляйте технические метрики с жалобами и опросами по конкретным сервисам (1С, CRM, VPN, видеосвязь).
Фактические «границы терпимости» пользователей используйте для пересмотра SLA‑порогов и приоритизации задач ИТ.
Уровень 3. XLA 3.0: работать с разными типами пользователей
Разделите сотрудников на 4–6 ключевых персон: бухгалтерия, продажи, полевые сотрудники, топ‑менеджмент, кол‑центр и так далее.
Для каждой персоны определите свои критичные сервисы и метрики опыта: скорость, удобство, доступность поддержки.
Пилот XLA: с чего начать в реальной компании
Вместо попытки «перепрошить» все ИТ‑отношения сразу, начните с короткого пилота.
Практичный сценарий:
Выберите один короткий, но массовый процесс, например, «выход нового сотрудника».
Опишите целевой опыт в формате XLA: «в первый рабочий час (ну или хотя бы день) у сотрудника есть ноутбук, доступы, почта и основные сервисы, он может выполнить свою первую задачу».
Оставьте SLA как технический фон (сроки создания учеток, настроек и так далее), но замерьте, сколько людей реально стартуют без задержек и что им мешает.
Раз в неделю собирайте ИТ, HR и представителя бизнеса на короткий разбор: где люди споткнулись и что можно изменить в процессе.
Смена культуры: от штрафов к совместному результату
Самый сложный переход — не про метрики, а про мотивацию. Пока ИТ живет в логике «не нарушить SLA, чтобы не прилетел штраф», опыт пользователей всегда будет на втором плане.
XLA предлагает иную модель:
Сохранить базовые штрафы за грубое нарушение SLA (аварии, длительные простои).
Дополнительно ввести бонусы за улучшение опыта и роста продуктивных часов сотрудников (например, сокращение времени простоя на ключевых ИТ‑процессах).
Так ИТ‑отдел и подрядчик перестают быть «расходным центром», а становятся партнером, который напрямую участвует в росте бизнеса.
История из практики: как региональный банк научился видеть скорость глазами сотрудников
Поделимся историей одного регионального банка, которая иллюстрирует применение подхода. По данным мониторинга все системы работали штатно. Мониторинг доступности — зеленый, SLA соблюден, система доступна. Но сотрудники жаловались, что системы работают медленно. Стояла задача решить эту проблему.
Шаг 1. Собрали обратную связь — и обнаружили правду
ИТ-команда поехала в несколько офисов и просто посмотрела как работают менеджеры.
Картина оказалась печальной:
При заполнении карточки клиента — каждый переход от экрана к экрану – 10-15 секунд ожидания. Менеджер сидит, смотрит на экран, клиент напротив тоже ждёт.
Проверка кредитной истории — минуты. Чтобы занять паузу, менеджер начинает диалог с клиентом.
Распечатка договора… Это можно продолжать вечно.
Умножьте на 10-15 клиентов в день — получается 20-30 минут на каждого сотрудника. А теперь умножьте на 2000 сотрудников — масштаб потерь становится колоссальным.
Плюс психологический момент — медленная работа напрягает как сотрудника, так и клиента. В итоге у клиента складывается впечатление, что «в этом банке всё медленно и неудобно».
Шаг 2. Оцифровали проблему через APDEX
Банк решил внедрить методику APDEX (Application Performance Index) — способ измерить производительность системы с точки зрения пользовательского опыта.
Как работает APDEX:
Определяются пороговые значения для каждого действия: удовлетворительное время (T) и приемлемое время (4T).
Если действие выполняется быстрее T — пользователь доволен.
Если от T до 4T — терпимо, но уже напрягает.
Если дольше 4T — пользователь откровенно недоволен.
Шаг 3. Установили метки на действия в информационных системах
Следующий шаг — встроили в систему автоматический сбор данных. На каждое ключевое действие в CRM и банковской системе поставили метки времени:
Начало операции.
Конец операции.
Фиксация задержек на каждом этапе.
Данные стали стекаться в единый дашборд. И здесь началось самое интересное.
Шаг 4. Научились видеть деградацию до того, как она стала проблемой
Через месяц наблюдений обнаружили паттерн: по понедельникам утром (с 9:00 до 11:00) скорость работы падала в 1,5-2 раза. Формально система работала, мониторинг не показывал критических проблем. Но по метрикам APDEX было видно: пользовательский опыт в эти часы проваливался в красную зону.
Начали разбираться. Выяснилось, что в понедельник утром запускались автоматические синхронизации данных между всеми точками и головным офисом. Нагрузка на базу данных возрастала многократно, и пользовательские запросы обрабатывались значительно медленнее.
Решением стал перенос синхронизации на воскресенье вечером и ночь с понедельника на вторник. Результат: скорость работы в понедельник утром выросла, APDEX вернулся в зелёную зону.
По результатам работ средний APDEX вырос, время обслуживания сократилось. Пользователи перестали жаловаться на медленную работу систем, а индекс удовлетворенности NPS сотрудников вырос. И как следствие удобства работы — снижение текучки кадров.
Итог: XLA — не мода, а следующий шаг эволюции SLA
В 2026 году мерить только аптайм и скорость реакции уже недостаточно. SLA по‑прежнему нужен, но он отвечает лишь на вопрос «ничего не сломали?». XLA добавляет более важный слой: «помогает ли ИТ людям работать лучше и быстрее».
Если резюмировать:
SLA — про здоровье систем.
XLA — про здоровье бизнеса и продуктивность людей.
Начать можно без революций: добавьте измерение опыта сотрудников к существующим SLA, протестируйте XLA на одном процессе, посмотрите на динамику и только потом закрепляйте изменения в договорах и KPI. Именно так XLA перестанет быть модным словом и превратится в рабочий инструмент, который отделяет компании будущего от тех, кто всё еще красит арбуз в зелёный цвет на дашбордах.
Где искать тех, кто готов работать по-новому?
Построить отношения, где подрядчик отвечает не за «закрытие тикетов», а за реальный комфорт сотрудников — задача непростая. О том, как бизнесу выстраивать прозрачную работу с ИТ и не переплачивать за «воздух», мы рассказываем в статьях на Клерк и нашем Telegram-канале.
Например, недавно в телеграм-канале делились готовым чек-листом для собственников и финдиректоров. Это фильтр, который помогает на этапе переговоров отсеять тех, кто работает «по старинке», и найти партнеров, готовых отвечать за результат, а не просто слать «зеленые отчеты» при тормозящей 1С.
Подписаться на канал ALP ITSM в Клерк и телеграм ALP ITSM: ИТ-аутсорсинг.
Начать дискуссию