2026 — год внедрения XLA: как перестать «красить арбуз в зеленый» и начать измерять реальный опыт сотрудников

Привет, на связи Авдей Мартынович, руководитель подразделения по работе с СМБ ALP ITSM. Уже 30 лет мы помогаем компаниям наводить порядок в ИТ‑инфраструктуре: от аудита и восстановления после сбоев до управления ИТ как сервисом для бизнеса. В этой статье — прикладной разбор для собственников и ИТ-руководителей: чем XLA отличается от SLA, почему переход к метрикам опыта стал необходимостью именно сейчас и как внедрять XLA.

SLA больше не «волшебная таблетка»

SLA (Service Level Agreement) — это соглашение об уровне сервиса между бизнесом и ИТ. В нем зафиксированы требования к доступности сервисов (те самые 99,9%), время реакции на заявку и скорость работы каналов связи. В случае, если SLA выполнены — ИТ молодцы.

Главная проблема SLA в том, что он оценивает состояние «железа» и ПО, но слеп к проблемам людей. Мы называем это «эффектом арбуза». Снаружи отчет выглядит идеально зеленым, но внутри все «красное». По бумагам сервер доступен, а в реальности бухгалтерия теряет часы из-за микрозависаний 1С, а менеджеры по 20 секунд ждут отклика CRM. Формально условия контракта соблюдены, но бизнес при этом страдает.

Что такое XLA и как он дополняет SLA

XLA (Experience Level Agreement) — это соглашение об уровне опыта сотрудников и заказчика. Его задача — измерять не только «работает/не работает», а то, насколько удобно и продуктивно работать с ИТ-сервисами.

Ключевое различие:

Если по простому, то

• SLA спрашивает: «Сервис доступен? Пакеты ходят? Ответ уложился в регламент?»
• XLA спрашивает: «Доволен ли сотрудник работой с ИТ-инструментами и насколько они помогают ему делать свою работу?»

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

Сравним в чем разница между SLA vs XLA

Как возникла тема XLA

Первые точечные упоминания XLA появились еще в 2018–2019 годах, но последние годы публикаций на тему стало больше. Это создает ощущение, что XLA это что-то новое. Но по сути XLA опирается на давно известную практику работы с обратной связью.

Новое здесь не в идее «слушать людей», а в том как это делать. Если раньше компании основывали свои действия на разовых опросах, то сегодня обратную связь можно собирать в моменте и видеть настроения сразу связывая их с конкретными сервисами и бизнес-показателями. Современные сервис-дески умеют по тексту заявок «считывать» настроение пользователей. XLA — это по сути формализованная работа с опытом и обратной связью.

Давайте разберем примеры метрик XLA:

Оценка удовлетворенности пользователей (End-user satisfaction score)

• CSAT по ИТ‑сервисам (например, «поставьте оценку от 1 до 5, насколько вам помогло решение»);
• средний балл по опросам после обращения или по регулярным пульс‑опросам.

Индекс готовности рекомендовать (Net Promoter Score (NPS))

• «Насколько вы готовы порекомендовать наш ИТ‑сервис/службу коллеге?» (0–10);
• рассчитывается как % промоутеров минус % критиков, дает интегральную оценку лояльности к ИТ‑сервисам.

Интегральный индекс цифрового опыта (Digital Experience Score (DEX))

Он может включать:

• технические показатели на уровне рабочего места (скорость приложений, число ошибок, время входа);
• субъективные оценки удобства работы с основными системами;
• частоту/характер жалоб и негативных комментариев.

Дополнительно в XLA могут могут считать:

• Время, которое пользователь реально тратит на выполнение типовых задач (например, «от открытия формы до оформления договора — не более X минут»).
• Количество «болезненных» сценариев в месяц (повторяющиеся жалобы на конкретный сервис или шаг процесса).
• Индекс фрустрации (частота негативных слов в заявках и чатах по конкретному сервису).

Проблемы плохого цифрового опыта

Проблемы плохого цифрового опыта (DEX) в результаты превращаются в реальные потери:

• Потери рабочего времени из‑за медленных систем и неудобного ИТ измеряются месяцами на одного сотрудника в год.
• Низкий цифровой опыт напрямую связан с выгоранием и снижением вовлеченности, что бьет по выручке и клиентскому сервису.
• Часть сотрудников, особенно в дефицитных профессиях, готовы увольняться, если ежедневно сталкиваются с тормозящими инструментами и хаосом в ИТ.

Руководителю больше нельзя ограничиваться вопросом: «Сколько тикетов закрыто в срок?». Важнее другое: «Сколько продуктивных часов мы теряем каждую неделю из‑за ИТ и как это отражается в P&L?»

Три уровня внедрения XLA

Не нужно ломать работающую систему и переписывать все контракты за один день. Безопаснее внедрять XLA поэтапно, используя его как надстройку над привычным SLA.

Уровень 1. Научиться слушать

Перестаньте спрашивать: «Вы довольны работой инженера?». Спросите: «Насколько легко вам было решить свою задачу?».

Начните анализировать текст заявок. Негативные слова и жалобы в чатах — это сигнал к действию, даже если формально SLA не нарушен.

Уровень 2. Связать технику и эмоции

Наложите технические отчеты на карту жалоб. Если 1С «летает» по приборам, но пользователи массово жалуются — проблема есть. Используйте реальные границы терпения сотрудников, чтобы корректировать пороги SLA.

Уровень 3. Персонализировать подход

Универсальные метрики плохо работают для всех сразу. Разделите сотрудников на группы: бухгалтерия, продажи, топ-менеджмент, «поля». Для каждой группы выделите критичные сервисы. Что важно для колл-центра (звук без помех), может быть неважно для бухгалтера (доступ к тяжелым базам).

С чего начать: сценарий пилотного проекта

Не пытайтесь внедрить XLA сразу во всей компании. Возьмите один массовый и понятный процесс, например, выход нового сотрудника, и отработайте механику на нем.

План действий:

1. Определите цель. Сформулируйте идеальный результат в терминах опыта: «Новичок в первый же день получает ноутбук, все доступы и может сразу приступить к работе».
2. Сместите фокус. Оставьте SLA для контроля сроков (создание учетки за 2 часа), но главной метрикой сделайте успешный старт сотрудника. Считайте, сколько людей реально начали работать без простоев.
3. Анализируйте сбои. Раз в неделю проводите летучку с ИТ, HR и бизнесом. Обсуждайте не цифры отчетов, а конкретные кейсы: где процесс споткнулся и что именно помешало человеку начать работу.

Смена культуры: от штрафов к партнерству

Самый сложный переход — не в метриках, а в головах. Традиционный SLA — это почти всегда история про наказание. В контракте с внешним подрядчиком нарушение сроков автоматически выливается в штрафы. Для внутренней ИТ-команды «красный» отчет означает невыполненный KPI, лишение премии и демотивацию.

В такой системе у сотрудников одна цель — «прикрыться» отчетом. ИТ-отдел начинает работать не на бизнес, а на показатели, формально закрывая заявки, чтобы не получить по шапке.

Подход XLA меняет эту логику. Это история про работу с людьми, а не с цифрами.

Если команда ошибается и нарушает сроки, нужно не спешить выписывать штраф, а искать причину. Почему это случилось? Не хватило ресурсов? Сломался процесс? Устарел инструмент? Цель — найти и устранить корневую проблему, а не наказать исполнителя.

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

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

Поделимся историей одного регионального банка, которая иллюстрирует применение подхода. По данным мониторинга все системы работали штатно. Мониторинг доступности — зеленый, 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 сотрудников вырос. И как следствие удобства работы — снижение текучки кадров.

Ещё один пример: как «вал заявок на смену пароля» превратили в метрику

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

На определенное число месяца была запланирована смена паролей. Все пароли в один день — 20-30 штук. Кто не работал в этот день, меняет пароль позже. По SLA все заявки закрывались вовремя, время взятия в работу и отработки в пределах установленных. Формально все в порядке. Реально, для пользователей — чуть ли не полдня потеряно. Хорошо, если твою заявку рассмотрели в числе первых, а если нет? Это вызывало не то, чтобы критичный, но все же негатив с накоплением эффекта.

Включив XLA-логику, мы предложили ответственному у клиента посмотреть на картину:

• количество заявок на смену пароля в день;
• время на отработку одной заявки первой линией поддержки;
• реальные потери рабочего времени от требования смены пароля до получения нового пароля у каждого пользователя и в среднем по компании.

Посмотрели, прониклись и поменяли процесс:

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

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

XLA — не мода, а следующий шаг эволюции SLA

В 2026 году мерить только аптайм и скорость реакции уже недостаточно. SLA по‑прежнему нужен, но он отвечает лишь на вопрос «ничего не сломали?». XLA добавляет более важный слой: «помогает ли ИТ людям работать лучше и быстрее».

Если резюмировать:

• SLA — про здоровье систем.
• XLA — про здоровье бизнеса и продуктивность людей.

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

Как найти тех, кто готов работать по-новому?

Построить отношения, где подрядчик отвечает не за «закрытие тикетов», а за реальный комфорт ваших сотрудников — задача непростая. На рынке много предложений, но далеко не все компании дозревали до партнерского подхода.

Чтобы вы не тратили время на бесконечные эксперименты, мы собрали главные критерии отбора в один документ. Это не просто теория, а фильтр, который поможет отсеять тех, кто работает «по старинке».

Скачать: Что на самом деле входит в ИТ-аутсорсинг: чек-лист для собственника и финдиректора

Используйте этот чек-лист на переговорах — он поможет задать правильные вопросы и сразу понять, готов ли потенциальный партнер брать ответственность за результат, или вы получите очередной «зеленый отчет» при тормозящей 1С.