Как собственнику выстроить контроль не выставленных штрафов по sla

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

Первый шаг я начинаю не с поиска виноватых, а с карты движения данных. Нужно понять, где возникает право на штраф, кто фиксирует нарушение, кто подтверждает факт, кто считает сумму, кто готовит документ, кто отправляет контрагенту и кто контролирует принятие к учету. Пока у штрафа нет маршрута, он неуправляем. В большинстве компаний потеря возникает на стыке функций. Операции считают, что финансы сами увидят сбой. Финансы ждут письменного основания. Юристы подключаются поздно. Аккаунт-менеджер тянет паузу, чтобы не портить отношения с клиентом или подрядчиком. В результате право на взыскание есть, а действия нет.

Чтобы убрать размытость, я ввожу единицу контроля — событие SLA. У события есть дата, договор, метрика, факт отклонения, источник данных, расчет суммы, ответственный за проверку и крайний срок выставления. Пока событие не закрыто статусом, оно остается в реестре. Не в переписке, не в памяти сотрудника, не в заметке руководителя, а в общем контуре учета. Для собственника ценность реестра не в удобстве, а в управляемости. Он показывает не только сумму потерь, но и место сбоя.

Где теряются штрафы

Есть пять типовых причин, из-за которых штрафы не доходят до выставления.

Первая причина — SLA описан так, что нарушение трудно доказать. Формулировки расплывчаты, метод расчета не закреплен, нет источника времени, нет порога отклонения, нет документа-основания. При таком договоре сотрудники спорят не о факте нарушения, а о трактовке текста.

Вторая причина — нет единого владельца процесса. Когда за сбор фактов отвечает одна функция, за расчет другая, за документ третья, а за контакт с контрагентом четвертая, без назначенного владельца штраф остается ничьим. Ничейная задача почти всегда зависает.

Третья причина — данные о нарушении приходят слишком поздно. Если нарушение фиксируется вручную раз в месяц, часть случаев уже не восстановить. Теряются логи, смены, комментарии, подтверждения. Контрагент оспаривает удержание, потому что компания не собрала доказательную базу в срок.

Четвертая причина — мотивационный конфликт. Коммерческий блок хочет сохранить выручку и не поднимает тему удержаний. Операционный блок не хочет показывать, что контроль качества слабый. Финансовый блок не хочет брать на себя спорный расчет. Пока собственник не снимет конфликт интересов, процесс будет буксовать.

Пятая причина — нет управленческой отчетности. Если в отчете видны только выставленные штрафы, а не полный объем выявленных нарушений, руководство видит маленький фрагмент картины. Главный показатель для контроля — разрыв между начисленным и выставленным.

Контур контроля

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

На уровне договора я проверяю четыре узла. Первый — измеримость метрики. Нужно ясно определить, что считается нарушением и по какому источнику данных. Второй — формула суммы. Она не должна зависеть от устных договоренностей. Третий — срок уведомления и пакет подтверждающих материалов. Четвертый — порядок выставления и зачета. Если в контракте нет этих опор, операционная дисциплина не спасет.

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

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

На уровне управленческого контроля я вывожу для собственника пять показателей. Первый — сумма выявленных штрафов за период. Второй — сумма выставленных. Третий — процент доведения до выставления. Четвертый — средний срок от выявления до отправки. Пятый — сумма утраченных штрафов с расшифровкой причин: пропуск срока, спор по доказательствам, решение не выставлять, ошибка в договоре, ручной сбой. Такая панель снимает иллюзию порядка. Она показывает не только деньги, но и качество процесса.

Роли и дисциплина

Когда я внедряю контроль, я не раздаю задачу всем понемногу. Я назначаю владельца процесса. Чаще всего роль находится между финансами и операциями, в зависимости от модели бизнеса. У владельца одна цель: каждое подтвержденное нарушение довести до развилки — выставлено, оспорено, списано по решению. Без этой роли реестр превратится в архив.

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

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

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

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

Что внедрить первым

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

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

Хороший признак зрелости — когда собственник видит три суммы без ручных уточнений: сколько штрафов выявлено, сколько выставлено, сколько потеряно и почему. После этого разговор о SLA перестает быть спором мнений. Он становится разговором о конкретных деньгах, сроках и фамилиях.