SLA для внутренних служб предприятия: метрики и эскалации

Зачем внутренним службам общий SLA, а не три разных

Когда ИТ, ТОиР и АХО работают по разным правилам, бизнес видит одно и то же: заявку перекидывают между службами, сроки плавают, а приоритет у каждого свой. Единый SLA помогает договориться не о том, кто виноват, а о том, что считается результатом и за какое время он должен быть достигнут.

Причина проста: многие инциденты и запросы сквозные. В учебном классе не включается рабочее место. ИТ смотрит на ОС и учетную запись, ТОиР - на питание и кабель, АХО - на доступ в помещение и ключи. Если у каждой службы свои сроки и своя шкала срочности, пользователь получит три разных ответа и ни одной понятной даты восстановления.

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

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

Перед тем как писать SLA, полезно ответить на вопросы:

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

Определяем услуги и границы: что именно обещаем

Сначала стоит описать не «все на свете», а конкретные услуги. Тогда сотрудникам понятно, куда обращаться, а командам - за что они отвечают и что можно измерить.

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

Дальше нужен короткий каталог услуг: 10-20 типовых позиций вместо сотен частных случаев. Удобнее описывать услугу как результат (что человек получает), а не как перечень работ.

Пример базового каталога:

• ИТ: учетная запись и доступы, рабочее место, сеть/интернет, печать, бизнес-приложения.
• ТОиР: ремонт оборудования, аварийный выезд, плановое ТО, диагностика.
• АХО: пропуск/доступ, климат и освещение, рабочие места и мебель, мелкий ремонт помещений.

После этого фиксируются границы ответственности. Например, ИТ отвечает за сервер и ОС, ТОиР - за питание и стойки в помещении, АХО - за кондиционирование. Отдельно пропишите «стыки»: кто принимает первичный инцидент и кто ведет коммуникации, если причина еще неизвестна.

Чтобы не спорить о терминах, закрепите простые определения:

• Запрос - нужна услуга без сбоя (установить ПО, выдать доступ).
• Инцидент - что-то перестало работать или работает хуже нормы.
• Плановая работа - согласованное заранее изменение или обслуживание.

И еще два обязательных пункта: часы работы и каналы обращений. Например, сервис-деск 8:00-20:00, аварии 24/7 по телефону дежурного, а «не срочно» - через портал или почту. Это снимает половину конфликтов: люди знают, что им обещали и как правильно обратиться.

Приоритеты и уровни сервиса: как договориться о срочности

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

Базовый набор приоритетов - P1-P4. Критерии лучше задавать через проверяемые вопросы:

• Есть ли риск для безопасности людей или нарушения требований.
• Остановлен ли критичный процесс (производство, прием пациентов, платежи, связь).
• Сколько людей или рабочих мест затронуто.
• Есть ли обходной путь и насколько он приемлем.
• Какой ожидаемый ущерб: простой, штрафы, срыв сроков.

Чтобы приоритет не превращался в спор, заранее закрепите правило: приоритет = влияние x срочность, при этом влияние важнее. «Не печатает один принтер» обычно не P1, даже если «нужно срочно». А «не работает сеть на участке» может быть P1, даже если заявка пришла ночью.

Полезный инструмент - матрица «услуга x приоритет x время реакции x срок решения». Она позволяет говорить на одном языке и сравнивать ожидания по разным службам.

Разные нормы допустимы, если отличается контекст: критичный объект и офис, удаленный филиал и головная площадка, сменная работа и стандартный график. Главное - чтобы различия были описаны заранее (например, «для производственных площадок P1 быстрее, чем для офисов») и подтверждались ресурсами. Иначе SLA станет обещанием, которое невозможно выполнить.

Пример 5 измеримых метрик, которые реально собирать

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

Пять метрик, которые обычно можно собирать без сложных систем и которые подходят сразу для ИТ, ТОиР и АХО:

• Время первой реакции (FRT): от регистрации заявки до первого подтвержденного действия (например, комментарий + назначение ответственного или смена статуса на «В работе»).
• Время восстановления сервиса (TTR/MTTR): от регистрации инцидента до восстановления работоспособности (важно: не до «закрыто», а до «работает»).
• Доля заявок, выполненных в срок SLA: количество заявок, выполненных в целевой срок, деленное на все заявки, попадающие под SLA. Сразу пропишите, какие статусы «останавливают часы».
• Количество просрочек по эскалации: сколько раз не сработало правило «эскалировать через X минут/часов при риске срыва».
• Повторные обращения по одной причине (reopen/recurrence): доля заявок, которые открыли снова, например, в течение 7 дней по той же услуге/объекту.

Лучше не включать метрики, которые нельзя проверить: «качество отличное», «решили навсегда», «пользователь доволен» без короткого опроса с понятной шкалой.

Мини-пример: если в офисе не работает турникет, АХО фиксирует заявку и время выезда, ТОиР - время восстановления узла, ИТ - если проблема в сети/контроллере. Все три команды считают одинаковые FRT и TTR, поэтому спорить о фактах почти не приходится.

Как формулировать метрики так, чтобы их нельзя было трактовать по-разному

Хорошая метрика отвечает на один вопрос: кто, что, когда и как измеряет. Если этого нет, спор начнется не из-за результата, а из-за слов.

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

То же с качеством. «Повторное обращение» должно иметь окно времени и критерий совпадения. Например: повторным считается обращение по той же категории и месту в течение 7 дней после закрытия.

Если считаете доступность и простой объектов (лифтов, кондиционеров, рабочих мест), зафиксируйте формулу: какие периоды входят в простой (включая ожидание запчастей или только активные работы) и какие часы учитываются (24/7 или рабочее время).

Шаблон, который хорошо убирает двусмысленность:

• Объект метрики: услуга, объект, тип заявки.
• Старт и финиш: события, которые включают и выключают счетчик.
• Календарь: 24/7 или рабочие часы, правила пауз.
• Источник данных: тикет-система, журнал дежурных, датчики.
• Ответственный и исключения: кто подтверждает факт и что не считается нарушением.

Следите, чтобы метрики не конфликтовали между службами. Если у ТОиР цель «быстрее восстановить», а у ИТ - «минимум повторов», появится соблазн закрывать заявки формально. Обычно работает связка из двух обязательных показателей для всех участников цепочки: один про скорость (например, время восстановления) и один про качество (например, доля возвратов в работу).

Исключения из SLA: как описать честно и без лазеек

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

Типовые исключения обычно относятся к трем группам: форс-мажор (пожар, наводнение, аварии на инфраструктуре), сбои у внешних поставщиков (электричество, связь, облачные сервисы), инциденты безопасности (вирусная атака, расследование утечки, изъятие оборудования на проверку). Важно заранее прописать, что именно считается таким случаем, а что нет.

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

Сложнее всего - ожидание запчастей, подрядчиков и согласований. Рабочая формула обычно такая: SLA на время реакции и диагностики действует всегда, а пауза возможна только после документированного стоп-фактора. Например, «ожидание поставки блока питания по заявке в закупку» или «ожидание допуска в помещение от службы безопасности».

Чтобы исключения не стали лазейкой, помогает простое правило: исключение применяется только при наличии всех трех пунктов:

• четкий триггер (что случилось и как это определяется)
• запись в тикете с временем начала и окончания паузы
• уведомление заказчика и следующий шаг (когда вернемся к работе)

Если хотя бы один пункт не выполнен, время продолжает идти по SLA.

Эскалации и коммуникации: чтобы проблемы не зависали

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

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

Роли удобно описать так:

• Диспетчер (единое окно): принимает заявку, задает уточняющие вопросы, запускает таймеры SLA и фиксирует статусы.
• Руководитель смены: решает конфликты приоритетов, перераспределяет ресурсы, подтверждает эскалацию.
• Владелец сервиса: принимает решения о временных обходных мерах и согласует отклонения от стандартов.
• ИБ (при необходимости): подключается при признаках утечки, подозрительных действиях, влиянии на критичные системы.

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

• что случилось и с какого времени
• кого и что затронуло
• что уже сделано и что нужно от адресата
• следующий шаг и время следующего статуса
• риски, если ничего не менять

С бизнесом лучше заранее договориться о частоте статусов: например, каждые 30 минут для критичного инцидента и раз в 2 часа для среднего, всегда в одном канале, без параллельных чатов.

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

Пошагово: как внедрить SLA в ИТ, ТОиР и АХО без перегруза

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

Минимальный план на 2-4 недели

1. Соберите 20-30 типовых кейсов обращений за последние 1-2 месяца. Не берите редкие аварии. Нужны повседневные вещи: не работает принтер, перегорела лампа, протечка, отказ кондиционера, заявка на доступ, замена расходников.

2. По этим кейсам опишите короткий каталог услуг и границы ответственности. Для каждой услуги задайте 2-3 приоритета и базовые сроки: когда берем в работу и когда должны восстановить. Отдельно зафиксируйте, что считается началом отсчета (например, заявка зарегистрирована с обязательными данными).

3. Выберите 5-8 метрик и проверьте, что данные реально есть. Если ИТ ведет заявки в сервис-деске, а АХО - в чатах, сначала договоритесь о едином канале фиксации или хотя бы о ежедневном переносе в таблицу. Метрика, которую нельзя собирать без ручной боли, быстро станет формальностью.

4. Согласуйте исключения и ответственность за простои заранее: нет доступа к помещению, нет утвержденного окна работ, нет запчастей на складе, подрядчик не на связи. Запишите, кто и за сколько времени должен убрать блокировку.

5. Запустите пилот на одном объекте (цех, офис, филиал) на 2-3 недели и поправьте формулировки. Часто выясняется, что проблема не в сроках, а в том, что заявки создают без адреса, контакта и фото, и время уходит на уточнения.

Частые ошибки, из-за которых SLA не работает

SLA проваливается, когда становится красивым документом, но не рабочим правилом. Обычно причина в том, что обещания нельзя проверить, а ответственность за данные размыта.

Ошибка 1: метрик много, а владельца данных нет

Если описали 15 показателей, но не назначили, кто и откуда берет цифры, SLA превращается в спор. Лучше 3-5 метрик, но с понятным источником (заявки, журнал выездов, CMMS, учет пропусков) и одним ответственным за ежемесячный отчет.

Ошибка 2: сроки есть, а точки отсчета нет

Фраза «реакция 30 минут» ничего не значит без определения, от какого момента идет отсчет: от создания заявки, от подтверждения классификации, от звонка в диспетчерскую. Так же заранее договоритесь о правилах паузы таймера (ожидание доступа в серверную, ожидание запчасти, ожидание ответа инициатора) и о том, как это фиксируется.

Помогает короткая формула:

• старт: заявка зарегистрирована и получила приоритет
• пауза: причина указана и подтверждена второй стороной
• финиш: услуга восстановлена или предоставлено согласованное обходное решение

Ошибка 3: нет каталога услуг, поэтому все заявки «нестандартные»

Без каталога ИТ, ТОиР и АХО обсуждают каждый запрос заново: что это за услуга, какой приоритет, какие исключения. Сроки в SLA формально есть, но применить их нельзя.

Ошибка 4: плановые работы и инциденты в одной очереди

Когда профилактика, улучшения и аварии попадают в общий поток, приоритеты ломаются. Для инцидентов нужны другие правила срочности и эскалации, чем для плановых работ.

Ошибка 5: эскалация только «в конце», когда уже поздно

Если руководитель узнает о проблеме в момент нарушения SLA, это не эскалация, а отчет о провале. Эскалация должна быть ранней: по времени (например, 50% от лимита) и по риску (простои, безопасность, регуляторные требования).

Быстрая проверка SLA и следующие шаги

Проверьте SLA за 10 минут: можно ли по нему понять, кто что делает, как измеряется результат и что происходит, когда что-то пошло не так. Если хотя бы один ответ размытый, документ будет спорным и в реальной работе не поможет.

Чек-лист перед запуском:

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

Дальше посмотрите, дает ли отчетность эффект. Хороший признак: регулярный отчет по SLA приводит к 1-2 конкретным улучшениям в месяц (убрали узкое место в согласовании доступа, пересобрали склад ЗИП, ввели дежурство на критичное оборудование), а не просто «отчитались и забыли».

Практичные следующие шаги:

1. Выберите единый инструмент учета заявок и работ (или согласуйте интеграцию, если систем несколько).

2. Назначьте владельцев услуг по каждой службе и владельца сквозного SLA, который решает спорные случаи.

3. Зафиксируйте правила записи данных: когда ставим «начало работ», что считается «восстановлением», где храним причины исключений.

4. Запустите пилот на 2-3 самых частых услугах и пересмотрите метрики через 4 недели по фактическим данным.

Пример из практики: один инцидент, три службы, один SLA

Утро понедельника. У бухгалтера не включается рабочее место, в серверной растет температура, а на этаже выше обнаружили протечку. Если у ИТ, ТОиР и АХО разные правила срочности, начинается спор: что важнее - «один компьютер» или «вся серверная».

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

Пример того, как это можно записать в SLA простыми измеримыми фразами:

P1 (критично): риск простоя ключевых систем/безопасности.
- Реакция: 10 минут (подтверждение, назначен ответственный, старт работ).
- Восстановление: 2 часа до временного решения (обходной путь/резерв), 8 часов до постоянного.
- Исключения: плановые работы по согласованному окну; доступ в помещения только при наличии допуска.

Эскалация выглядит одинаково, даже если задачи разные. Через 15 минут без подтверждения тикет уходит руководителю смены; через 60 минут без понятного плана - руководителям ИТ, ТОиР и АХО одновременно; через 2 часа без временного восстановления подключается руководство объекта и принимается решение «снижаем риск прямо сейчас» (например, отключаем питание в зоне протечки и переносим критичные сервисы на резерв).

Чтобы это работало без ручного контроля, достаточно минимальной автоматизации: единый сервис-деск, связка тикетов «родитель-дочерние» для ИТ/ТОиР/АХО и простые сигналы мониторинга (температура в серверной, питание, доступ). Тогда SLA измеряется по фактам: кто когда принял тикет, когда начались работы и когда появился временный обходной вариант, а не по воспоминаниям в конце месяца.

Как закрепить результат: процесс, инструменты и поддержка

Чтобы SLA не остался файлом в папке, закрепите его в трех вещах: процесс (кто и что делает), инструменты (где фиксируется работа) и регулярная проверка (как видим, что все работает).

Начните с минимального набора документов. Их должно быть достаточно, чтобы одинаково понимали ИТ, ТОиР и АХО, но не настолько много, чтобы никто ничего не обновлял:

• Каталог услуг: короткие описания и что не входит (например, «ремонт офисной мебели» vs «перестановка рабочих мест»).
• Матрица сроков: приоритеты, целевые времена реакции и восстановления, окно поддержки.
• Правила исключений: плановые работы, доступ в помещения, зависимость от поставщиков, форс-мажор.
• Роли и контакты: владелец услуги, дежурный, ответственный за согласование исключений.
• Шаблон отчета по SLA: 5-10 показателей и короткие комментарии по отклонениям.

Дальше нужен единый центр учета заявок. Не так важно, будет ли это Service Desk, EAM/CMMS, ITSM или простая система для заявок. Важно, чтобы все обращения попадали в одно место и имели одинаковые поля: услуга, приоритет, время создания, время реакции, время закрытия, причина задержки. Тогда отчетность становится автоматической: еженедельно для руководителей служб и ежемесячно для бизнеса, с разбором топ-3 причин просрочек.

Интегратора обычно имеет смысл подключать, когда вы упираетесь не в формулировки, а в настройку процесса и данных: маршрутизация между службами, единые справочники, интеграции с мониторингом, учет активов, дежурства и уведомления. Например, GSE.kz (gse.kz) как системный интегратор и производитель оборудования в Казахстане может помочь с внедрением инфраструктуры и поддержкой рабочих мест и серверов, если вы выстраиваете SLA одновременно «на процесс» и «на железо».

План на 30 дней помогает не растянуть внедрение на полгода:

• Дни 1-7: пилот на 3-5 услугах и одном объекте, сбор базовых данных.
• Дни 8-14: корректировка приоритетов, исключений и маршрутов, настройка отчетов.
• Дни 15-21: утверждение SLA и ролей, запуск коммуникаций, шаблоны сообщений.
• Дни 22-30: обучение исполнителей и заказчиков, первая еженедельная сверка, фиксация улучшений.