Прогноз спроса и дозаказ: когда таблицы перестают справляться

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

Почему таблица перестаёт справляться примерно на 50 SKU

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

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

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

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

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

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

Формула в таблице не ошибается. Ошибается предположение, что у человека хватит внимания на пятьсот исключений подряд.

Из чего складывается дозаказ: спрос, срок поставки, страховой запас

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

Базовая конструкция — точка заказа. Это уровень остатка, при пересечении которого пора заказывать:

Точка заказа = средний дневной спрос × срок поставки в днях + страховой запас

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

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

Объём заказа = спрос за (срок поставки + интервал между заказами) + страховой запас − текущий остаток − товар в пути

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

Теперь страховой запас. Он покрывает не средний спрос, а разброс вокруг него за время, пока идёт поставка:

Страховой запас = z × σ спроса за срок поставки

Здесь σ — стандартное отклонение спроса за период поставки, то есть мера того, насколько сильно недельные продажи гуляют вокруг своего среднего. z — коэффициент уровня сервиса, квантиль нормального распределения: примерно 1,28 для уровня 90%, 1,65 для 95%, 2,33 для 99%. Это математическая константа, а не отраслевой норматив: она говорит только, какую долю случаев вы хотите закрыть запасом. Обратите внимание на форму зависимости — переход с 95% на 99% поднимает коэффициент почти в полтора раза, а вместе с ним и замороженные деньги. Уровень сервиса — экономическое решение, и принимать его надо по цене ошибки, а не ставить 95% по умолчанию всем позициям.

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

σ за срок поставки = √(срок × σ²днев. спроса + средний днев. спрос² × σ²срока)

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

Пример расчёта. Средний дневной спрос — 12 штук, стандартное отклонение дневного спроса — 5 штук, срок поставки — 16 дней, разброс срока — 3 дня, уровень сервиса 95% (z = 1,65). Спрос за срок поставки: 12 × 16 = 192 штуки. Вклад спроса: 16 × 5² = 400. Вклад срока: 12² × 3² = 1296. Сумма 1696, корень ≈ 41,2. Страховой запас: 1,65 × 41,2 ≈ 68 штук. Точка заказа: 192 + 68 = 260 штук. Числа взяты для иллюстрации механики, это не замер по клиенту. Важно в нём другое: вклад нестабильного поставщика (1296) втрое больше вклада колебаний спроса (400). Сократив разброс срока с трёх дней до одного, вы уменьшили бы страховой запас примерно до 37 штук — вдвое, ничего не трогая в прогнозе.

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

Тренд и сезонность: что формула в Excel не видит

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

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

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

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

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

И самое неприятное искажение — дни без остатка. Ноль продаж в день, когда товара не было, попадает в среднее как ноль спроса. Модель учится на собственном дефиците: занижает прогноз, значит, занижает заказ, значит, дефицит повторяется, значит, следующий прогноз ещё ниже. Это воронка, из которой позиция не выходит сама. Лечится тем, что дни без остатка либо выбрасываются из расчёта среднего, либо спрос в них восстанавливается по соседним дням с остатком. В статистике это называется цензурированным спросом, и по-русски идея ровно такая: вы видите не спрос, а продажи, а продажи ограничены сверху тем, что было на полке.

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

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

Как проверить прогноз на своих данных: ошибка, смещение, бэктест

Любой подрядчик покажет вам точность своей модели. Единственный способ узнать, относится ли эта точность к вашему ассортименту, — прогнать модель на вашей истории. Это называется бэктестом, и он устроен так: берёте историю, отрезаете последние 8–12 недель, строите прогноз, используя только данные до точки отреза, и сравниваете с тем, что произошло на самом деле. Ключевое условие — модель не должна ни в каком виде видеть будущее относительно точки отреза, включая справочники, которые обновлялись задним числом.

Мерить ошибку удобно тремя величинами, и каждая отвечает на свой вопрос.

MAPE — средняя абсолютная ошибка в процентах. Считается как среднее по всем позициям от |факт − прогноз| / факт. Отвечает на вопрос «насколько в среднем промахиваемся по каждой позиции». У MAPE есть известная беда: на позициях с редкими продажами знаменатель маленький, и одна ошибка в две штуки при факте в одну даёт 200%, которые перевешивают всё остальное. На хвосте ассортимента MAPE превращается в шум.

WAPE — взвешенная ошибка: сумма |факт − прогноз| по всем позициям / сумма факта. Отвечает на вопрос «какую долю от общего объёма мы промахиваем». Она устойчива к редким позициям и ближе к деньгам, потому что крупные позиции дают в неё больший вклад — как и в вашу выручку. Если считать WAPE не в штуках, а в рублях выручки, получится прямая оценка того, сколько стоит неточность.

Bias — смещение: сумма (прогноз − факт) / сумма факта. Отвечает на вопрос «мы систематически заказываем больше или меньше нужного». Это самая недооценённая метрика. Прогноз с WAPE 30% и нулевым смещением живёт нормально: страховой запас гасит разброс. Прогноз с WAPE 20%, но смещением −15% гарантированно сушит склад и даёт постоянный дефицит, потому что ошибается всегда в одну сторону. Смещение смотрят отдельно по группам: по категориям, по сезонным и несезонным позициям, по новинкам.

Пример расчёта. Три позиции за неделю. Первая: прогноз 100, факт 120. Вторая: прогноз 50, факт 40. Третья: прогноз 10, факт 2. MAPE = (20/120 + 10/40 + 8/2) / 3 = (0,167 + 0,25 + 4,0) / 3 ≈ 1,47, то есть 147% — и это целиком заслуга третьей позиции с двумя продажами. WAPE = (20 + 10 + 8) / (120 + 40 + 2) = 38/162 ≈ 0,235, то есть 23,5%. Bias = (100+50+10 − 162) / 162 = −2/162 ≈ −1,2%: суммарно прогноз почти не смещён. Одни и те же три строки, три разных вывода. Числа условные, показывают поведение метрик, а не качество какой-либо модели.

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

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

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

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

Дефицит и избыток в деньгах: как считать цену ошибки

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

Цена дефицита за единицу — это прежде всего упущенная маржа. Продали бы за 1 500, закупка 900, значит, каждая непроданная единица стоит 600 рублей неполученной прибыли. Но этим не ограничивается. Часть покупателей уходит к конкуренту и не возвращается — это потеря не одной продажи, а клиента. На маркетплейсах к этому добавляется механика площадки: карточка без остатка теряет позиции в выдаче и накопленную статистику, и после возврата товара продажи восстанавливаются не мгновенно. Точную величину этого эффекта я считать не берусь — она зависит от площадки и категории, и любой, кто называет вам универсальный процент, называет его от потолка. Но знак известен, и в решении его надо учитывать: дефицит по ходовой позиции стоит дороже, чем упущенная маржа за те дни, что товара не было.

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

Пример расчёта. Маржа 600 рублей с единицы, закупка 900, хранение 15 рублей за единицу в месяц, стоимость денег 2% в месяц (это 18 рублей на закупочную цену), риска уценки нет. Держать лишнюю единицу лишний месяц стоит 33 рубля. Не иметь единицы, когда за ней пришли, стоит 600 рублей. Отношение — примерно 1 к 18: лишний месяц запаса в восемнадцать раз дешевле одной потерянной продажи. Для такой позиции высокий уровень сервиса очевидно оправдан. Теперь замените маржу на 120 рублей, а хранение на 90 (крупногабарит), и отношение перевернётся: дешевле иногда не иметь, чем всегда держать. Обе строчки — арифметика на подставленных числах, а не замер по клиенту; подставьте свои, ответ по вашим позициям может оказаться любым из двух.

Отсюда прямой вывод: единого уровня сервиса на весь ассортимент не бывает. Он назначается группами, и группы удобно нарезать двумя разрезами сразу.

ABC делит позиции по вкладу в выручку или маржу: A — верхние, дающие основную часть денег, C — длинный хвост. XYZ делит по предсказуемости спроса: X — ровный спрос, Z — рваный, который плохо прогнозируется в принципе. Пересечение даёт девять групп, и внимание к ним разное.

Смысл этого разреза — не в красивой классификации, а в распределении ограниченного ресурса. Данных, времени аналитика и качества прогноза всегда конечное количество. Тратить их надо там, где ошибка стоит дороже всего, то есть в строке AX и AZ, а по CZ честно признать, что прогнозировать нечего, и перестать заказывать туда деньги.

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

Что решает человек, а что считает система

Граница здесь проходит не по сложности задачи, а по тому, кто отвечает деньгами. Система считает то, что выводится из данных. Человек решает то, что данными не описано, и подписывает то, что стоит денег.

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

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

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

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

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

Система снимает с закупщика счёт. Ответственность за деньги она не снимает и снимать не должна.

Внедрение по шагам: от выгрузки до первого дозаказа

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

Шаг 0. Цель и метрика. До любых выгрузок — одна фраза о том, что должно измениться, и число, которым вы это померите. Например: сократить дни без остатка по группе A и не увеличить при этом замороженные в запасе деньги. Здесь же фиксируется условие остановки. Это общий для нас метод, он описан на странице «Как мы работаем», и в закупках он работает особенно наглядно: без базы «как сейчас» любое изменение остатков можно объяснить сезоном.

Шаг 1. Выгрузка. Минимальный набор: продажи по дням по каждой позиции за максимально доступный период; остатки по дням (именно по дням, а не текущий срез — иначе вы не восстановите дни без остатка); история поставок с датами заказа, отгрузки и приёмки; закупочные и розничные цены с историей изменений; календарь промо и участия в акциях; отмены и возвраты. Отдельно — справочники: кратность короба, минимальная партия, поставщик по каждой позиции.

Шаг 2. Чистка. Разметить дни без остатка и решить, выбрасывать их или восстанавливать спрос. Убрать возвраты и отменённые заказы из продаж. Разметить промо-периоды. Найти разовые крупные заказы и решить по каждому, спрос это или разовый эпизод. Этот шаг всегда занимает больше времени, чем планировали, и почти всегда вскрывает проблемы учёта, о которых никто не знал.

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

Шаг 4. Бэктест против наивного. Отрезать последние 8–12 недель, посчитать WAPE, bias, долю недель с дефицитом и средний остаток в деньгах — для наивного прогноза и для модели. Результат либо даёт зелёный свет, либо честно закрывает тему. Смотреть отдельно по группам ABC/XYZ: выигрыш на хвосте не стоит ничего, выигрыш на группе A стоит всего.

Шаг 5. Пилот в параллель. Четыре-шесть недель расчёт работает рядом с текущей таблицей по ограниченной группе позиций — обычно по A и B одной категории. Заказы по-прежнему делает человек, но каждое расхождение между рекомендацией и решением фиксируется с причиной. Это дешёвый способ узнать, чего модель не знает, не заплатив за это складом.

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

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

Шаг, который чаще всего пропускают, — третий. Он скучный, он не требует моделей, и в нём обычно лежат самые быстрые деньги.

Когда прогноз не нужен

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

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

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

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