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

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

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

Руководителю больше нельзя ограничиваться вопросом: «Сколько тикетов закрыто в срок?». Важнее другое: «Сколько продуктивных часов мы теряем каждую неделю из‑за ИТ и как это отражается в 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 ключевых персон: бухгалтерия, продажи, полевые сотрудники, топ‑менеджмент, кол‑центр и так далее.
• Для каждой персоны определите свои критичные сервисы и метрики опыта: скорость, удобство, доступность поддержки.

C чего начать внедрение XLA

Вместо попытки «перепрошить» все ИТ‑отношения сразу, начните с короткого пилота.

Практичный сценарий:

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

Как XLA меняет культуру компании

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

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

Другой показательный случай был у крупного клиента с распределенной инфраструктурой: часть сотрудников работала в офисе, часть — на площадках их заказчиков, часть — на удаленке. Многие машины были не в домене, все заходили на общую терминальную ферму, по сути, как с тонких клиентов.

Раз в месяц, в строго определенный день, на первую линию обрушивался вал обращений «смена пароля». Мы уже могли по календарю сказать: «послезавтра прилетит двадцать—тридцать заявок только по этому поводу». Формально ничего страшного: каждая заявка закрывается, SLA по времени реакции выполняется. Но для пользователей это выглядело как «каждый месяц мы внезапно перестаем работать, звоним в поддержку и полдня меняем пароли».

Здесь XLA‑логика как раз и сработала. Мы принесли эти данные менеджеру клиента в виде простой картины:
— сколько заявок по паролям прилетает в один день;
— сколько времени уходит у первой линии на обработку каждой;
— сколько рабочего времени теряют пользователи, пока пытаются «пробиться» в систему.

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

В результате пик «боли» размазался по времени, объем заявок в один день заметно упал, а для пользователей эта история перестала быть ежемесячным стрессом. Формально SLA можно было бы оставить тем же, но XLA‑подход позволил увидеть реальный опыт людей и убрать системный источник раздражения.

Заключение: SLA и XLA без практики — просто слова

В 2026 году успех ИТ-директора измеряется не количеством закрытых заявок в срок, а количеством продуктивных часов компании. SLA по‑прежнему нужен как фундамент — без него всё просто развалится. Но если останавливаться только на нём, вы будете бесконечно подкрашивать дашборды, не понимая, как живётся людям внутри этих зелёных графиков.

XLA для меня — не модный термин и не попытка продать услуги подороже. Это признание простого факта, что цифры сама по себе ничего не дают. Можно поставить инженеру KPI «получать только пятерки», но без разбора каждой сложной оценки мы будем работать не на качество, а на отчет. Да, разбирать одну «тройку» по часу впятером — дорого и местами неприятно. Но без этого XLA превращается в ещё одну метрику, за которую всех ругают, а не в инструмент улучшения опыта.

Меряете ли вы «счастье» сотрудников или ограничиваетесь аптаймом и SLA? За что вас чаще всего ругают пользователи, когда в отчетах «всё работает»? И что для вас в XLA выглядит как реальная польза?

Как найти надежного ИТ-партнера, который уже живет по этим принципам? Выбор подрядчика — это не просто сравнение цен. Это выбор союзника, который разделит ответственность за результат. Мы подготовили чек-лист с рекомендациями по выбору ИТ-аутсорсера, чтобы вы могли избежать ошибок на старте.

📌 Забрать рекомендации по выбору подрядчика в нашем Telegram-канале. Без заполнения форм, ПД и других сложностей.