SLA как рабочий договор. Почему ИТ и бизнес не понимают друг друга и как это исправить

Я много раз видел одну и ту же ситуацию. ИТ показывает, что инцидент отработан в рамках SLA. Бизнес отвечает, что проблема все равно нанесла ущерб. И каждая сторона по-своему права. ИТ действительно выполнило формальное обязательство. Бизнес действительно не получил нужный ему результат. Значит, проблема не в дисциплине исполнения. Проблема в том, что стороны изначально договорились о разном, хотя использовали одни и те же слова.

Именно поэтому хороший SLA нужно рассматривать не как приложение к helpdesk и не как упражнение в ITIL, а как рабочий договор между ИТ и бизнесом. Пока этого договора нет, каталог услуг превращается в внутренний справочник ИТ, а SLA становится источником раздражения, а не инструментом управления.

С чего обычно начинается недопонимание

Самая частая ошибка возникает уже в тот момент, когда компания пытается описать, что именно ИТ предоставляет бизнесу.

Для ИТ естественно мыслить через системы. Поддержка CRM, обслуживание 1С, сопровождение документооборота, администрирование рабочих мест, мониторинг инфраструктуры. Это нормальный язык для ИТ-службы, потому что она действительно управляет системами, каналами, правами, резервным копированием, отказами и обновлениями.

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

И когда одна сторона говорит о системе, а другая о результате, формально они вроде бы обсуждают одну услугу, а по факту две разные реальности.

Я обычно замечаю это уже на первых интервью. ИТ говорит: «мы обеспечиваем доступность системы». Бизнес говорит: «у нас из-за этого срывается процесс». На этом стыке и рождается конфликт. Потому что система для ИТ может быть доступна на 99,5%, а процесс для бизнеса при этом может быть неуправляем.

Что на самом деле считать услугой

На мой взгляд, услуга начинается не там, где стоит конкретная платформа, а там, где есть понятный бизнес-результат.

Если говорить проще, «поддержка CRM» сама по себе не является хорошим названием услуги. Это название технической зоны ответственности. Для бизнеса гораздо понятнее и полезнее звучит «обеспечение непрерывной обработки клиентских заявок» или «поддержка процесса продаж». В первом случае ИТ описывает свой инструмент. Во втором случае оно описывает, что именно помогает бизнесу выполнять.

То же самое работает и в других сценариях. «Поддержка 1С» звучит привычно, но почти ничего не говорит финансовому директору. А вот «поддержка процесса закрытия месяца и бухгалтерского учета» уже задает другой уровень разговора. «Поддержка service desk» звучит нейтрально. «Поддержка процесса обработки обращений с соблюдением приоритетов и сроков» уже заставляет думать о клиенте, а не о тикете.

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

Почему каталог услуг на техническом языке не работает

У ИТ есть естественное искушение писать аккуратно и технически. «Доступность сервиса не ниже 99,5% в рабочее время». «Время реакции на инцидент P2 не более 30 минут». «Регламентное обслуживание по графику». Все это формально правильно, но очень редко по-настоящему понятно бизнесу.

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

Читайте также

ИИ снижает стоимость кода, но повышает требования к разработке

ИИ заметно удешевил вход в разработку. Теперь не нужно неделями ждать первого результата. Модель помогает разобрать ТЗ, разложить задачу на блоки, набросать интерфейс, подготовить предварительную оценку и список рисков. Особенно полезен ранний прототип: заказчик видит не абстрактное описание, а будущий экран, быстрее включается в обсуждение и точнее формулирует, что ему нужно.

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

Такие ситуации очень полезны. Они быстро показывают, что язык SLA должен быть переведен из технической метрики в управленческую. Не «доступность CRM 99,5%», а «обработка входящих заявок не должна останавливаться в рабочее время дольше согласованного окна». Не «реакция на P1 15 минут», а «критичные сбои в процессах продаж, отгрузки или закрытия месяца эскалируются немедленно и имеют отдельный порядок восстановления».

Как только в формулировке появляется процесс, разговор резко становится осмысленнее.

Где SLA ломается в реальной работе

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

Например, для ИТ поломка системы отчетности и остановка обработки заказов могут жить в одной шкале приоритетов, потому что обе относятся к корпоративным приложениям. Но для бизнеса это совершенно разные события. Одно неприятно, второе бьет по деньгам прямо сейчас.

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

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

Зачем нужны разные уровни сервиса

Еще одна ошибка, которую компании часто совершают из лучших побуждений, это попытка сделать единый SLA для всех. С логикой здесь все понятно: хочется единых правил, единых сроков, единых приоритетов. На практике это почти всегда приводит к искажению. Бизнес-процессы имеют разную стоимость простоя. Обработка заказов, закрытие месяца, сервисная поддержка ключевых клиентов, HR-процессы и корпоративный портал не могут жить под одним и тем же уровнем чувствительности. Даже если технически они используют похожие платформы, цена отклонения у них разная.

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

Когда это не разделено, ИТ тонет в ложной срочности, а бизнес живет в ощущении, что по-настоящему важные вещи для ИТ мало отличаются от второстепенных.

Где возникают серые зоны ответственности

Самые неприятные конфликты начинаются там, где зона ответственности не определена до конца.

Очень типичный пример: система работает, но данные в ней некорректны. ИТ говорит: доступ есть, платформа доступна, интеграция не упала, инцидента нет. Бизнес говорит: мы не можем работать, потому что цифры неверные. Формально виноватых как будто нет, а проблема реальна.

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

Поэтому хороший SLA обязательно должен фиксировать не только обязанности ИТ, но и обязательства бизнеса. Кто предоставляет входные данные. Кто отвечает за корректность справочников. Кто утверждает критичность процесса. Кто должен участвовать в приемке изменений. Кто принимает решение по временному обходному сценарию, если сервис работает частично.

Обычно именно эти вещи сначала кажутся избыточными. Но потом именно они спасают от самых токсичных споров.

Читайте также

Сквозная видимость запасов. Почему цифры сходятся, а товара на полке нет

Когда в компании говорят, что у них есть сквозная видимость запасов, обычно это звучит весьма уверенно. ERP показывает остатки, WMS видит склад, магазины работают в своей системе, логистика отслеживает перемещения, BI собирает все это в понятные отчеты.

Как SLA влияет на инциденты, приоритеты и развитие

Мне кажется, самое полезное, что дает зрелый SLA, это не красивые цифры, а более честная приоритизация.

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

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

Именно здесь SLA перестает быть документом про helpdesk и становится частью системы управления изменениями.

Какие метрики работают, а какие только успокаивают

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

Метрики вроде времени первого ответа, количества тикетов, средней загрузки команды или общей доступности платформы полезны, но в отрыве от процесса они мало что объясняют. Они описывают работу ИТ внутри себя, но не обязательно показывают, что происходит с бизнес-результатом.

Гораздо полезнее показатели другого типа. Например:

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

Такие метрики неприятнее. Зато они честнее. Они не дают спрятаться за формальное выполнение и лучше показывают, где договоренность действительно работает, а где только выглядит красиво.

Почему каталог услуг быстро устаревает

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

Появляются новые каналы, меняются процессы продаж, перестраивается логистика, вырастают требования к скорости, добавляются новые роли, меняется архитектура. А каталог услуг остается таким, каким его однажды согласовали.

В этот момент начинается привычная история. Формально документ есть, но в реальной жизни им уже никто не пользуется как актуальной моделью. Бизнес живет по новым ожиданиям, ИТ поддерживает старый контур, а конфликт снова уходит в ручной режим.

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

Заключение

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

Читайте также

В чьи сети мы попали? Рейтинг розничных игроков от основателя DNS

Рейтинг, традиционно составляемый основателем DNS Дмитрием Алексеевым, ранжирует по числу точек игроков абсолютно разных сегментов отечественной розницы. Такой подход позволяет взглянуть на рыночные тенденции под новым углом. Экспансия рынка за счет расширения инфраструктуры неизбежно уйдет в прошлое. Бизнес-стратегии лидеров, построивших сети с удобным физическим доступом практически для каждого потребителей, сменят фокус на комфорт для клиента, качество обслуживания и расширение спектра услуг.

Для меня в этом и состоит главный смысл темы. SLA не должен быть описанием того, как ИТ удобно мерить само себя. Он должен быть рабочим договором, в котором обе стороны понимают, что именно считается услугой, где проходит граница ответственности и что именно нужно восстановить, если что-то пошло не так.

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

Именно тогда ИТ перестает «поддерживать системы» и начинает обеспечивать работоспособность бизнеса.