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

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

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

С чего начать

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

Дальше делю поток на 3–4 категории по смыслу. Простой вариант:

базовый прайс с полным циклом проверки,

оперативное изменение в рамках заранее утвержденного коридора,

временное ценовое решение до даты окончания.

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

Маршрут и роли

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

Для каждой роли задаю один вопрос:

по каким правилам он согласует или отклоняет,

кому уходит документ после его решения.

Если на один вопрос нет точного ответа, роль из маршрута исключаю или переписываю регламент.

Рабочая схема выглядит так:

инициатор создает запрос на новый прайс или изменение,

система присваивает номер, категорию, дедлайн и текущего владельца шага,

каждый согласующий получает задачу с датой и основанием решения,

при отклонении документ не пропадает, а возвращается на доработку с причиной,

после утверждения финальная версия автоматически помечается как действующая.

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

Правила вместо споров

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

Я выношу спорные места в короткую матрицу решений. В ней фиксирую:

Матрица не должна превращаться в толстый документ. Ее задача — снять 80% типовых споров. Все, что выходит за рамки, уходит на отдельный уровень решения с понятным сроком.

Прозрачность статусов

Собственнику не нужен поток файлов в почте. Нужна одна таблица, панель или реестр, где по каждому ценовому листу видны:

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

Отдельно добавляю признак версии. Если сотрудники пересылают файл с названиями прайс_новый, прайс_новый 2, прайс_финал, контроль рассыпается. Действующая версия должна быть одна. Архивные версии — доступны, но не путаются с текущей.

Эскалация

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

Хорошо работает трехступенчатый порядок:

в день просрочки — автоматическое напоминание исполнителю,

через один рабочий день — уведомление его руководителю,

через два рабочих дня — включение владельца процесса или собственника по критичным прайсам.

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

Метрики

Я смотрю на пять показателей.

Первый — доля прайсов, согласованных в срок. Он показывает дисциплину процесса в целом.

Второй — средний срок по категориям прайсов. По нему видно, где маршрут раздут или правила неясны.

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

Четвертый — просрочка по ролям. Здесь быстро вскрывается узкое место: финансы, коммерция, юристы, продуктовая команда.

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

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

Что ломает систему

Самый частый сбой — попытка внедрить инструмент без договоренности о правилах. Таблица, CRM, ERP или task manager (система задач) не исправят хаос, если маршрут спорный.

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

Третий сбой — нет дедлайна по шагу. Формально документ в работе, фактически лежит без движения.

Четвертый сбой — собственник сам периодически ломает порядок, когда просит провести срочный прайс вне системы. После двух-трех таких случаев команда делает вывод, что регламент существует для удобных дней.

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

Как внедрить без перегруза

Я запускаю систему в три шага.

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

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

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

Точка контроля собственника

Собственнику не нужен микроменеджмент. Достаточно держать три вопроса на еженедельном цикле:

Если ответы расплывчатые, контроля нет. Если по каждому просроченному прайсу видно имя, этап, срок и основание задержки, система работает.

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