SLA в ИТ-аутсорсинге: как закрепить сроки реакции, приоритеты и отчётность

SLA в ИТ-аутсорсинге нужен, чтобы поддержка была управляемой. Это не просто таблица сроков, а правила работы: как классифицируются заявки, кто принимает обращение, когда начинается реакция, как идёт эскалация и что видит руководитель в отчёте.

Если вы только выбираете модель, начните с материала что такое ИТ-аутсорсинг.

Что фиксирует SLA

Минимальный SLA должен отвечать на вопросы:

• какие системы поддерживаются;
• какие каналы обращения используются;
• как определяются приоритеты;
• что считается временем реакции;
• что считается временем решения;
• кто отвечает за согласование работ;
• как оформляются исключения;
• какие отчёты получает клиент.

Без этих пунктов SLA легко превращается в обещание “быстро реагируем”, которое трудно проверить.

Классы заявок

Обычно заявки делят по влиянию на бизнес:

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

Класс заявки должен зависеть от влияния на бизнес, а не от эмоциональности сообщения.

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

Время реакции и время решения

Время реакции — когда подрядчик взял заявку в работу и начал диагностику. Время решения — когда восстановлена работа или выполнена задача.

В договоре важно разделять эти показатели. Быстрая реакция не всегда означает мгновенное решение: часть инцидентов зависит от оборудования, провайдера, стороннего сервиса, лицензий или согласования клиента.

Эскалация

SLA должен описывать, что происходит, если первая линия не решает проблему:

• когда подключается L2/L3;
• кто уведомляет руководителя;
• как фиксируется причина задержки;
• когда подключаются внешние поставщики;
• кто принимает временный обходной вариант.

Эскалация особенно важна для 1С, серверов, сети и безопасности.

Отчётность

Хороший отчёт показывает не только количество заявок. Руководителю нужны выводы:

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

Такие выводы появляются только при разборе всего массива заявок в ИТ-поддержку за длинный период — что видно на тысяче заявок и не видно на одной.

Если отчёт не помогает принимать решения, это статистика ради статистики. Отдельная ловушка — оценка качества по одной анкете после заявки: в разборе потока заявок группы компаний 98% оценок были «Отлично» при покрытии 20%, и цифра не измеряла ничего, кроме состава отвечающих. Как измерять на самом деле — три уровня опроса и правила расчёта.

Исключения

В SLA нужно честно описывать исключения: авария у провайдера, отсутствие доступа, неисправность оборудования без запчастей, задержка согласования, неподдерживаемое ПО, проектные изменения вне договора.

Это защищает обе стороны: клиент понимает границы услуги, подрядчик не обещает невозможное.

Как внедрять SLA

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

Коммерческий формат описан на странице SLA-договоры.