Когда в компании начинают гордо вещать о наличии SLA, это звучит примерно так же убедительно, как когда сосед хвастается новым пылесосом — вроде и вещь полезная, но сразу не понятно, почему от этого жизнь должна стать лучше. В ИТ-мире SLA — это такой волшебный документ с кучей сроков реакции, приоритетов и ответственности, который должен сделать жизнь бизнеса проще.
Ну а бизнес в ответ думает: «Отлично, теперь у нас есть чёткие правила игры!» Однако на практике начинается что-то вроде классической семейной драмы: ИТ говорит — мы всё сделали по регламенту, а бизнес отвечает — да ладно, у меня всё равно убытки и головная боль.
Я видел эту комедию ошибок столько раз, что уже почти могу написать сценарий для ситкома. Представьте: ИТ-специалист с гордостью показывает протоколы и отчёты, где написано «всё решено в рамках SLA». А бизнес тем временем морщит лоб и говорит: «Ну да, вы по вашим бумажкам молодцы, а я тут клиента потерял». И обе стороны абсолютно правы!
Это как если бы официант сказал вам: «Ваш заказ готов через 10 минут», а вы получили холодную похлёбку через полчаса. Вот только официант будет показывать часы и говорить: «Я сказал 10 минут!»
Проблема тут в том, что обе стороны изначально говорили на одном языке слов, но понимали разные вещи.
Это как если бы один говорил про «поддержку CRM», а другой ждал поддержки процесса продаж. Первый видит цифры и системы, второй — живых клиентов и деньги.
SLA часто воспринимается как формальный документ из ITIL или просто бюрократическая бумажка для helpdesk’а. Но на самом деле это должен быть рабочий договор между ИТ и бизнесом — своего рода брачный контракт с обещаниями заботиться друг о друге.
Пока этот договор не подписан (пусть даже виртуально), каталог услуг остаётся внутренним справочником для айтишников и источником раздражения для всех остальных.
ИТшники любят думать категориями систем: поддержка CRM тут, обслуживание 1С там… Для них это нормально — они управляют серверами, каналами связи и обновлениями. Но бизнесу глубоко плевать на эти технические детали! Ему важно другое: чтобы заявка клиента не исчезала в чёрной дыре системы поддержки; чтобы заказ прошёл по цепочке без приключений; чтобы документы закрывались вовремя; чтобы отчётность была готова к дедлайну без нервных срывов.
Это напоминает ситуацию из анекдота про двух программистов.
Один говорит другому: «Ты знаешь, мы сделали код идеальным! Он компилируется без ошибок!» Второй отвечает: «А он работает?» Так вот SLA часто описывает именно компиляцию кода (технические параметры), а бизнес ждёт работающего приложения (результат).
Когда одна сторона говорит о системе с её 99.5% доступности (что звучит как священное число), а другая жалуется на срыв процессов — начинается конфликт.
Потому что система может работать почти идеально с технической точки зрения, но процесс бизнеса при этом тонет в хаосе.
Для меня услуга начинается там, где появляется понятный бизнес-результат. Если назвать её просто «поддержка CRM» — это как сказать «я кормлю курицу».
А если назвать так: «обеспечение непрерывной обработки клиентских заявок» — тогда становится ясно зачем вообще эта курица нужна.
То же самое касается других сервисов: вместо скучного «поддержка 1С» лучше говорить «поддержка процесса закрытия месяца и бухгалтерского учёта». Звучит уже серьёзнее и ближе к реальной жизни финансового директора.
Наличие SLA в ИТ-компании часто воспринимается как гарантия качества, но на практике это не всегда решает реальные проблемы бизнеса, ведь документ фиксирует сроки и процессы, а не результаты и эмоции клиентов. Конфликт возникает из-за разницы в понимании: ИТ специалисты сосредоточены на технических показателях и регламентах, а бизнес — на конечном результате и удовлетворённости клиентов. Чтобы избежать таких недоразумений, важно выстраивать диалог, где обе стороны говорят на одном языке, учитывая и технические требования, и бизнес-цели.