Контроль просроченных согласований договоров с подрядчиками без ручного хаоса

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

Где ломается процесс

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

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

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

Базовая архитектура

Основа системы — реестр договоров с подрядчиками. Не папка в почте и не список в чате, а таблица или карточки в учетной среде, где каждая строка отвечает на восемь вопросов: кто инициатор, кто подрядчик, какой предмет, на какой стадии договор, кто держатель текущего шага, когда документ попал на этап, какой срок этапа, почему возникла задержка. Этого достаточно, чтобы увидеть картину без длинных разбирательств.

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

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

Критично назначить владельца этапа. Не подразделение, не роль в целом, а конкретного человека. Формулировка у юристов или у финансистов снимает ответственность. Формулировка у Анны Петровой или у Сергея Иванова делает просрочку наблюдаемой. При смене ответственного запись в реестре обновляется в тот же день, иначе система ломается на первой же отпускной неделе.

Правило дедлайна

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

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

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

Сигналы и эскалация

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

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

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

Метрики без самообмана

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

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

Отдельная зона риска — средний срок без распределения. Он скрывает крайности. Десять быстрых договоров могут замаскировать два провальных. Поэтому рядом со средним сроком я смотрю долю критических просрочек и список самых старых незавершенных кейсов. Именно они бьют по отношениям с подрядчиками и по внутреннему доверию к процессу.

Порядок запуска

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

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

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

Что закрепить приказом

Нужен короткий внутренний документ с пятью блоками. Состав обязательных данных на входе. Перечень статусов. Нормативы сроков по типам договоров. Роли и владельцы этапов. Порядок эскалации просрочки. Без этого любая система останется договоренностью между отдельными людьми и развалится при первой смене состава команды.

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

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

Роль собственника

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

Хороший ритм для собственника — короткий еженедельный срез по отклонениям. Сколько договоров в работе. Сколько в просрочке. Где узкое место. Какие три кейса критичны для денег или запуска. Этого достаточно, чтобы держать процесс в тонусе без микроменеджмента.

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