Как внедрить sla между отделами и не поссорить команду
Когда собственник вводит SLA между отделами, проблема почти никогда не в таблице с сроками. Конфликт рождается раньше: один отдел считает себя внутренним сервисом, другой — заказчиком с правом срочного запроса, третий — последней инстанцией, которая исправляет чужие ошибки. Пока роли не названы прямо, SLA воспринимают как способ переложить вину. Я начинаю не с документа, а с разборки маршрута работы между подразделениями.
Сначала я выбираю 2–3 процесса, где потери уже видны в деньгах, сроках или перегрузке людей. Не беру сразу весь бизнес. Если пытаться описать каждый внутренний запрос, команда устанет до запуска. Подход с узким контуром дает проверку без лишнего шума. Обычно в первый контур попадают передача лида из маркетинга в продажи, передача заказа из продаж в производство или запуск закупки по заявке от операционного блока.
Точка старта
Перед формулировкой SLA я фиксирую четыре вещи. Первая — кто и что передает. Не отдел в целом, а конкретный результат: заполненную карточку клиента, согласованную заявку, комплект документов, задачу с набором полей. Вторая — что считается принятым в работу. Третья — в какой срок исполнитель отвечает и завершает операцию. Четвертая — что происходит, если входные данные неполные или приоритет спорный.
На этой стадии всплывает главный источник споров: у отделов разное понимание слова «готово». Продажи думают, что передали заказ, если клиент устно подтвердил покупку. Производство считает, что заказ принят после предоплаты, точной спецификации и сроков поставки. Обе стороны по-своему правы, пока нет общей формулировки. SLA нужен не для наказания, а для устранения двойного толкования.
Я прошу руководителей отделов описать путь задачи в простых действиях. Без схем на десять экранов и без попытки охватить исключения. Достаточно ответить на вопросы: что поступает на вход, кто проверяет полноту, сколько минут или часов уходит на первичную реакцию, сколько времени занимает исполнение, при каких условиях задача возвращается инициатору. После этого я убираю обороты вроде «в кратчайший срок» и «по мере загрузки». У таких слов нет цены и нет смысла.
Состав SLA между отделами простой. Предмет соглашения. Список услуг или операций. Формат входа. Критерии качества входа. Срок первой реакции. Срок исполнения. Канал передачи. Правила приоритета. Основания для возврата. Способ учета и период сверки. Этого достаточно, чтобы началась дисциплина.
Правила без войны
Самая частая ошибка собственника — спустить SLA сверху как приказ. Бумага появится, доверие исчезнет. Я делаю иначе: собираю руководителей смежных функций на короткую рабочую сессию и веду разговор по данным, а не по жалобам. Если маркетинг передает 100 лидов, а продажи берут в работу 40, вопрос не в личной ответственности директора по продажам. Вопрос в критериях качества лида, времени обработки и причине отклонения остальных 60.
На встрече я запрещаю обсуждать характер людей и стиль общения. Разбираем только операции. Полезный прием — разделить спор на три слоя. Первый слой: качество входа. Второй: срок реакции. Третий: срок завершения. Когда стороны спорят сразу обо всем, разговор уходит в эмоции. Когда предмет разложен, каждая сторона видит свою часть обязательствательств.
SLA без измерения быстро превращается в формальность. Поэтому я заранее определяю, откуда берутся цифры. Если в компании нет CRM или таск-системы, на первом этапе хватает простой таблицы учета. В ней фиксируются дата и время передачи, статус принятия, причина возврата, дата завершения. Ручной учет неудобен, но он лучше споров по памяти. Позже данные переводятся в систему, где виден цикл выполнения, или lead time (полное время прохождения задачи от передачи до завершения).
Еще один критичный вопрос — срочные задачи. Если не описать исключения, SLA разрушится в первую неделю. Я ввожу отдельное правило: что считается срочным, кто присваивает приоритет, сколько срочных задач отдел принимает в день без срыва плановой нагрузки. Иначе слово «срочно» начнет означать «я опоздал, разберитесь за меня».
Нельзя включать в SLA пункты, на которые отдел не влияет. Если закупка зависит от оплаты поставщику, а финансы переводят деньги по своему графику, винить закупку за просрочку бессмысленно. Внутреннее соглашение работает только на управляемом участке. Все внешние зависимости я выношу в отдельный список ограничений. Тогда отчет по SLA показывает реальную причину провала, а не удобного виноватого.
Роль собственника
Собственник нужен не как арбитр по каждой заявке, а как автор правил игры. Я задаю рамку: SLA — не инструмент давления, а форма договора между внутренними поставщиками и внутренними заказчиками. Если руководители ждут, что я в ручном режиме решу каждую стычку, внедрение провалится. Если у них есть право согласовать условия, измерять выполнение и разбирать отклоненияя по единому формату, система держится без постоянного вмешательства.
После запуска я смотрю не только на процент соблюдения SLA. Меня интересуют три вопроса. Какие пункты возвращают задачи назад. Где срок реакции соблюдена срок исполнения сорван. Какие подразделения перегружены из-за кривого входа от соседей. Такая картина быстро показывает, где проблема в дисциплине, где в мощности, где в самом процессе.
Первая версия SLA почти никогда не остается финальной. Иначе говоря, документ живет вместе с процессом. Но менять его каждую неделю нельзя. Я ставлю короткий цикл пересмотра: сначала накопить массив наблюдений, потом пересобрать спорные нормы. Если команда видит, что цифры корректируются по фактам, а не по настроению, сопротивление снижается.
Хороший признак — отделы перестают спорить общими фразами и начинают говорить языком входов, сроков и причин возврата. Плохой признак — SLA висит в регламенте, а задачи по-прежнему передают в личных сообщениях без фиксации. В таком случае проблема не в формулировках, а в отсутствии управленческой воли закрыть обходные пути.
Я не привязываю премию к SLA на старте. Иначе люди начнут защищать показатель, а не работу. Сначала нужна чистая статистика и устойчивая привычка вести задачи по правилам. Когда данные стали надежными, а спорные зоны разобраны, метрика входит в систему оценки без лишней нервозности.
Если внедрять SLA поэтапно, на понятных процессах и с прозрачным учетом, межфункциональное трение снижается. У отделов появляется ясный договор: что передаем, в каком виде, за сколько времени, по каким основаниям возвращаем и какк разбираем сбой. Для собственника ценность не в самом документе. Ценность в предсказуемой передаче работы между командами без скрытых потерь и затяжных конфликтов.
