CPQ и сроки поставки: как называть реальную дату отгрузки уже в коммерческом предложении

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

Почему дата отгрузки — такой же параметр расчёта, как цена?

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

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

Дальше начинается арифметика потерь: пеня по договору, простой у клиента, возврат предоплаты, испорченная репутация у дилера, который пообещал дату своему заказчику. Отдельная статья расходов — время: менеджер тратит по 15–20 минут на согласование срока по каждому КП. При 30 предложениях в месяц это около 10 часов работы только на то, чтобы узнать дату, которая уже где-то существует.

Откуда CPQ берёт дату отгрузки?

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

К этому добавляются календарь (рабочие дни, смены, праздники) и логистика до склада клиента. Но ядро — именно эти три величины, и каждая из них имеет свой источник данных и свою степень неопределённости.

Производственный календарь: считаем в рабочих днях, показываем в календарных

Цех работает в рабочих днях, клиент думает в календарных. Если складывать «12 дней изготовления» с календарной датой, ошибка накапливается на каждом празднике и каждом выходном.

Поэтому в расчёте должна быть явная календарная сетка: рабочие дни, сокращённые смены, плановые остановки, декабрьский пик. Клиенту при этом показывается уже переведённая календарная дата — например, «отгрузка 24 ноября», а не «27-й рабочий день».

Очередь и загрузка: почему «мощностей нет» — не ответ

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

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

Сроки компонентов: длинная позиция определяет всю дату

Комплект готов тогда, когда готова последняя позиция. Если импортный узел идёт 45 календарных дней, а собственное производство — 12 рабочих, дата отгрузки определяется компонентом, а не цехом.

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

Пример расчёта на одном заказе

Заказ попадает в очередь через 15 рабочих дней, изготовление занимает 12 рабочих дней. Итого 27 рабочих дней — это примерно 5,4 недели, или около 38 календарных дней.

Если по одной позиции импортный компонент идёт 45 календарных дней, дата сдвигается и определяется уже компонентом. Именно такие заказы чаще всего и срываются: менеджер посчитал цех, но не посчитал закупку.

Как считать дату, когда в заказе позиции с разными сроками?

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

Дата готовности комплекта и дата первой отгрузки — разные вещи

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

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

Частичные отгрузки: показываем график, а не одну дату

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

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

Где в CPQ появляется буфер и сколько его ставить?

Буфер — не «запас на всякий случай», а компенсация известной неопределённости: контроль качества, доукомплектация, погрузка, транспорт, человеческий фактор на стыках. Без него расчёт будет красивым и регулярно неточным.

Размер буфера зависит от категории. Для серийной продукции, которая идёт со склада, хватает 5%. Для заказного изготовления разумно 15%: те самые 27 рабочих дней превращаются в 31. Для импортных позиций и нестандартных комплектаций — до 25%, потому что там больше внешних событий.

Важно, чтобы буфер был виден в расчёте, а не прятался в цифрах. Когда менеджер понимает, из чего сложилась дата, он может осознанно её обсуждать с клиентом, а не «согласовывать» каждую сделку заново.

Что писать в КП, чтобы срок не стал штрафом?

Формулировка важнее точности. «Ориентировочная дата отгрузки» и «подтверждённая дата отгрузки» — два разных обязательства, и путать их дорого.

Рабочая схема: в КП указывается расчётная дата с пометкой «ориентировочно», а подтверждённая фиксируется после проверки обеспеченности и поступления предоплаты. Это не уловка — так работают почти все производители сложной техники, и клиенты это принимают, если правило названо заранее.

Стоит отдельно прописать, что происходит при задержке оплаты: срок отсчитывается от поступления предоплаты, а не от даты КП. Иначе простой по вине клиента превращается в вашу просрочку.

Цена ошибки измерима. Если договор на 4 800 000 ₽ предусматривает пеню 0,1% за каждый день просрочки, это 4 800 ₽ в день; десять дней просрочки — 48 000 ₽, и это без учёта репутации. Один такой случай обычно дороже, чем настройка расчёта сроков.

Как связать срок с конфигурацией и ценой?

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

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

Технически это работает, когда правила конфигурации и расчёт срока живут в одном движке. Логика та же, что и в правилах совместимости: неверная комбинация не считается, а «долгая» комбинация считается, но честно показывает последствия.

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

Как внедрить расчёт сроков в CPQ без остановки продаж?

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

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

Проверка делается на истории: берутся 20 закрытых сделок и сравниваются обещанная и фактическая даты. Если расхождение стабильно в одну сторону, значит, не хватает буфера или не учтён этап, а не «производство подводит».

Запускать можно поэтапно: сначала цена и конфигурация, потом срок. Цена и срок считаются в одном месте, но не обязаны появляться в один день — общая логика системы описана в материале о том, что такое CPQ-система.

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

Какие ошибки чаще всего ломают расчёт сроков?

Первая и самая частая — ручная правка даты менеджером без следа. Одна правка не страшна, систематические правки означают, что модель неверна и её никто не чинит.

Вторая — одна дата на весь заказ при разнородных позициях. Третья — календарные дни вместо рабочих, из-за чего сроки «плывут» на праздниках. Четвёртая — обещание точной даты до проверки обеспеченности компонентами.

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

Частые вопросы