Система контроля просроченных согласований новых подрядчиков

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

С чего начать

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

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

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

Правило сроков

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

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

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

Что должно быть в карточке заявки

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

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

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

Видимость статуса

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

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

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

Эскалация без шума

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

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

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

Метрики

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

Полезно считать возраст открытых заявок по коридорам: до 3 дней, 4–7, 8–14, больше 14. Тогда видно не среднюю температуру, а реальный хвост зависаний. Именно он бьет по операционке и репутации процесса.

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

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

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

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

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

Как внедрять без саботажа

Я не запускаю такую систему сразу на все категории подрядчиков. Сначала беру ограниченный контур: самый частый тип договоров или подразделение с заметным объемом заявок. На пилоте быстро видно, где лишние поля, где нереальный срок, где согласующий получает задачи без права решения.

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

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