Программа для планирования закупок: как она устроена и что считает

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

Главное отличие от учётной системы — в направлении взгляда. Учёт отвечает на вопрос «что уже произошло»: сколько осталось, что отгрузили, что списали. Планирование отвечает на вопрос «что будет и что с этим делать». Это разные задачи, и путаница между ними — самая частая причина, по которой компания годами считает закупки в Excel рядом с полноценной ERP.

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

На что смотреть при выборе

Список программ найдётся в любом каталоге, а способ их проверить — нет. Ниже восемь требований и то, что просить на демо-расчёте своих данных.

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

Чем система планирования отличается от 1С и ERP

Вопрос «зачем нам ещё одна программа, если есть 1С» — первый, который возникает у закупщика и у финансового директора. Планирование закупок в 1С или в ERP формально возможно: там есть и остатки, и минимальный запас, и отчёты. Ответ не в том, что 1С плохая, а в том, что речь о другом классе задач.

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

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

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

Три взгляда на будущее состояние запаса

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

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

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

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

От разового расчёта к календарю поставок

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

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

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

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

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

На этом же уровне планирование закупок смыкается с планированием продаж. Если коммерция готовит запуск линейки или сезонную акцию, а закупка узнаёт об этом по факту роста спроса, никакой расчёт не спасёт: срок поставки уже потрачен. Регулярная сверка плана продаж с планом закупок — отдельная управленческая практика (её называют S&OP), и начинается она с того, что обе стороны смотрят в один календарь, а не в свои таблицы.

Из чего складывается программа для планирования закупок

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

1. Учёт остатков и движения товара. Фундамент: точный остаток по каждой позиции и достоверная история движений. Обычно это данные из учётной системы, а не отдельный контур.

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

Так выглядит разнесение ассортимента по группам одновременно по вкладу в прибыль и по объёму продаж:

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

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

Ценность не в отдельном блоке, а в связке: остаток с шага 1 сразу учитывается в прогнозе на шаге 3, а группа с шага 2 определяет, по каким правилам шаг 4 соберёт заказ.

Когда и сколько заказывать: две базовые модели

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

По точке заказа

Система сверяет доступный запас с рассчитанным порогом и формирует заказ, как только запас опускается до этой отметки, независимо от календаря. Логика для позиций с нестабильным спросом, где заранее назвать день закупки нельзя.

По расписанию

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

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

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

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

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

Так эти правила выглядят в разрезе товарных групп:

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

Данные, без которых расчёт не работает

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

Пример: прогноз спроса до следующей поставки — 150 единиц. В системе остаток числится как 60, и программа заказывает 90. Но 20 из этих 60 зарезервированы под оформленный заказ клиента и физически недоступны. Реальный свободный остаток — 40, заказать надо было 110. Двадцать единиц будущего дефицита, которых на бумаге не видно: прогноз был точен, ошиблось число остатка. Страховой запас в этом примере опущен для наглядности — в реальном расчёте он прибавляется сверху.

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

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

• Остатки на дату, а не только текущие. Расчёт оперирует остатком на момент прихода поставки, а не сегодняшним.
• Резервы и товар в пути. Зарезервированное под клиента вычитается, уже размещённые заказы прибавляются. Иначе система либо не закажет вовремя, либо закажет второй раз то, что уже едет.
• Фактические сроки поставки. Не норматив из договора, а факт по прошлым приёмкам. Договорные десять дней при фактических четырнадцати дают регулярный дефицит при формально честном расчёте. Разброс срока закладывают один раз — в страховой запас, отдельно от разброса спроса. В саму формулу потребности подставляют средний фактический срок: если взять верхнюю границу приёмок и вдобавок заложить разброс в запас, худший срок будет посчитан дважды, а одна аномальная поставка задерёт норматив по всему поставщику.
• История без дней дефицита. Продажи за периоды, когда товара не было на полке, занижены не потому, что спрос упал, а потому, что покупать было нечего. Если их не исключить, расчёт закрепит дефицит вместо того, чтобы его убрать.

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

Чем программа для планирования закупок отличается от программы для учёта склада?

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

Нужна ли отдельная программа, если уже есть 1С?

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

Что такое календарный план закупок?

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

С какого объёма ассортимента нужна такая программа?

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

Можно ли обойтись бесплатной программой?

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

Когда автоматизация не поможет?

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

Кому такая программа не подойдёт

Там, где спрос определяется не рынком, а разовыми договорённостями: проектные B2B-поставки, работа под конкретный заказ клиента, продажи через дистрибьюторов со сверкой объёмов. Признак простой. Если на продажи влияют факторы, которые трудно описать математически, и закупщик всё равно правит расчёт руками почти по каждой позиции — автоматический прогноз будет с ним спорить, а не помогать. Сверка прогнозов нескольких дистрибьюторов, ожидание подтверждённого объёма от клиента, сдвиг сроков по проекту — это работа с договорённостями, а не со статистикой. Тут автоматизировать стоит не сам заказ, а данные под него: единый реестр клиентских заказов, сроков и подтверждённых объёмов.

С чего начать

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

Протокол действий:

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

Другой масштаб — дистрибьютор и производитель сантехники SKL Group: шесть складов и два распределительных центра, собственные производства, бренды IDDIS и Milardo. До внедрения заказы считали четыре человека раз в месяц, у каждого на это уходил рабочий день; после внедрения Forecast NOW! расчёт и анализ тех же заказов занимает час. Внедрение шло поэтапно: лицензия и обучение — август 2021, автоматизация обмена данными — ноябрь, прогнозирование — март 2022; к маю 2022 в системе считалось около 60% заказов. «Мы искали программу, которая автоматизирует расчёты и избавит нас от большого количества ручного труда», — говорит руководитель отдела закупок компании.