Срыв поставки редко начинается в день, когда материал не приехал. Обычно признаки появляются раньше: поставщик не подтвердил заказ, перенес дату в письме, частично изменил количество, задержал отгрузку, не прислал документы или дал расплывчатый ответ менеджеру. Если эти сигналы остаются в переписке, закупки узнают о проблеме слишком поздно, а производство, склад и продажи работают по устаревшему плану.
Контроль сроков поставки нужен, чтобы обещанные даты, изменения, риски и фактическое исполнение были видны в системе. Это не отдельный календарь для закупщика, а часть общего контура: потребность возникла в ERP или плане закупок, заказ ушел поставщику, поставщик подтвердил дату, система отслеживает приближение срока, предупреждает о риске и сохраняет историю выполнения.
Какие даты нужно различать
В закупках часто путаются несколько дат. Есть дата потребности: когда материал нужен производству, складу или клиентскому заказу. Есть плановая дата заказа: когда закупка должна быть размещена с учетом срока поставки. Есть обещанная дата поставщика. Есть дата отгрузки, дата прибытия, дата приемки и дата закрытия документов. Если в системе хранится только одна дата, контролировать процесс невозможно.
Для управляемой закупки важно видеть цепочку. Поставщик может отгрузить вовремя, но груз застрянет в логистике. Или материал приедет, но не пройдет входной контроль. Или заказ будет подтвержден частично, и критичная позиция останется без срока. Поэтому контроль сроков должен учитывать не только факт прихода, а состояние каждой позиции заказа.
Где появляется срок поставки
Срок поставки начинается не с письма поставщика. Он связан с потребностью, номенклатурой, страховым запасом, производственным планом, минимальной партией, условиями договора и историей конкретного поставщика. В статье о планировании закупок эта логика рассматривается шире: дата заказа должна считаться от реальной потребности, а не от момента, когда менеджер вспомнил о позиции.
После размещения заказа появляется второй слой — подтверждение поставщика. Если поставщик не подтвердил дату, система должна считать заказ рискованным. Если подтвердил, но позже изменил срок, нужно сохранить старую и новую дату, причину переноса и ответственного. Это позволяет не спорить в конце месяца, кто виноват, а видеть историю решений по каждой поставке.
Почему переписка не подходит
Email и мессенджеры удобны для общения, но плохо работают как источник управленческого контроля. В письме сложно увидеть все поставки на ближайшую неделю, быстро найти просрочки по критичным материалам, построить рейтинг поставщиков, связать перенос даты с производственным заказом или передать задачу другому сотруднику.
Когда сроки живут в переписке, закупщик становится единственным носителем статуса. Если он заболел, ушел в отпуск или ведет слишком много заказов, компания теряет видимость. Автоматизация нужна не для замены общения, а для того, чтобы каждое подтверждение, перенос и риск попадали в общий контур.
Роль SRM и ERP
ERP-система обычно хранит потребности, заказы, остатки, складские операции, финансы и документы. Но поставщик не всегда работает внутри ERP компании. Для взаимодействия с поставщиками удобен SRM-контур: подтверждение заказов, обмен сроками, документы, статусы, претензии, рейтинг и история коммуникаций.
Хорошая схема не заставляет закупщика вручную переносить данные между системами. ERP формирует заказ и потребность, SRM получает его для взаимодействия с поставщиком, поставщик подтверждает или предлагает новую дату, а результат возвращается в ERP, план закупок и производственный контур. Тогда плановик видит риск раньше, чем материал не приехал на склад.
Какие события контролировать
- Нет подтверждения. Заказ отправлен, но поставщик не подтвердил дату и количество.
- Дата приближается. До обещанной поставки осталось мало времени, а отгрузка не подтверждена.
- Перенос срока. Поставщик изменил дату, и система должна оценить влияние на потребность.
- Частичная поставка. Часть позиций пришла, но критичный материал остается открытым.
- Просрочка приемки. Груз пришел, но не принят складом или качеством.
- Повторяющаяся задержка. Один поставщик регулярно переносит сроки по похожим позициям.
Для каждого события нужны правила уведомления и эскалации. Не все отклонения одинаково опасны. Перенос канцелярии на два дня не равен задержке комплектующего, без которого остановится линия. Поэтому система должна учитывать критичность позиции, остаток, альтернативных поставщиков, срок производства и влияние на клиентские обязательства.
История поставщика
Контроль сроков поставки полезен еще и тем, что формирует историю надежности. Если поставщик регулярно подтверждает оптимистичные даты, а потом переносит их, это должно влиять на оценку. Если поставщик честно предупреждает о задержке заранее, у компании остается время перестроить план. Если задержки связаны с конкретной группой материалов, можно пересмотреть страховой запас или условия договора.
Такой подход связан с управлением поставщиками. Цена остается важной, но для производства не менее важны стабильность сроков, качество коммуникации, готовность подтверждать изменения и точность документов. Система должна показывать эту картину на фактах, а не на впечатлениях закупщика.
Как внедрять контроль
- Разделить даты потребности, заказа, подтверждения, отгрузки, прибытия и приемки.
- Определить критичные позиции, где просрочка влияет на производство или клиента.
- Настроить обязательное подтверждение даты и количества поставщиком.
- Сохранять все изменения сроков с причиной и автором изменения.
- Настроить уведомления до наступления риска, а не после фактической просрочки.
- Связать историю поставок с рейтингом поставщика и планированием закупок.
Что получает бизнес
После внедрения контроля сроки перестают быть набором обещаний в письмах. Руководитель закупок видит очередь рисков, производство видит потенциальные задержки, склад понимает ожидаемые приходы, финансы могут планировать платежи, а менеджеры не тратят время на ручной сбор статусов. Важнее всего то, что компания начинает реагировать до срыва, а не после него.
Если сейчас сроки поставок контролируются вручную, стоит начать с инвентаризации открытых заказов: где хранится дата потребности, кто получает подтверждение, как фиксируются переносы и кто узнает о риске первым. Такой разбор быстро показывает, какой минимум автоматизации нужен: единый реестр поставок, портал поставщика, интеграция с ERP или более широкий SRM-процесс.