Владелец магазина строительных материалов перед сезоном решает, сколько закупить плитки: заказать мало — потерять продажи, заказать много — заморозить деньги на складе до следующего года. Руководитель небольшого производства думает, нанимать ли ещё двух человек в смену. Директор доставки еды планирует, сколько курьеров выводить в пятницу вечером. Все три решения упираются в один вопрос: сколько будет продаж. Разберём, что ИИ умеет в прогнозировании на самом деле, какие методы работают для компаний без отдела аналитики и где прогноз лучше не строить вовсе.
Для чего малому бизнесу прогноз
Прогноз сам по себе ничего не стоит, ценность появляется, когда он меняет конкретное решение. В небольших компаниях таких решений три группы:
- Закупки и запасы. Сколько и чего заказать у поставщика, чтобы не было ни дефицита, ни неликвида. Самый частый и самый окупаемый сценарий.
- Люди и смены. Сколько сотрудников нужно в конкретный день или неделю: кухня, курьеры, администраторы, операторы.
- Деньги. Хватит ли поступлений на зарплату и аренду через месяц, можно ли сейчас вкладываться в рекламу.
Если ни одно из этих решений в компании не принимается регулярно, прогноз будет красивой кривой на дашборде без практического эффекта. Сначала стоит понять, какое решение он должен поддерживать.
Три уровня методов: от простого к сложному
Слово «ИИ» в прогнозировании часто вводит в заблуждение. На практике работают три уровня, и для многих компаний достаточно первого.
Уровень 1. Статистика и сезонность
Скользящее среднее, учёт дня недели и месяца, тренд. Это не ИИ, но для стабильного бизнеса с историей от года такие методы дают разумную точность и, что важно, понятны владельцу. Если продажи плитки каждый апрель выше марта на 30–40%, об этом скажет и простая таблица.
Уровень 2. Модели машинного обучения
Алгоритмы, которые учитывают одновременно много факторов: сезонность, праздники, погоду, рекламные расходы, цены конкурентов, остатки. Они требуют подготовленных данных и специалиста для настройки, зато заметно точнее на нестабильных рядах. Для малого бизнеса такой уровень оправдан, когда речь о сотнях товарных позиций, по каждой из которых нужен свой прогноз, — руками такое не посчитать.
Уровень 3. Языковые модели как интерпретатор
GPT-5, Claude или Gemini плохо предсказывают числа сами по себе — это не их задача. Зато они хорошо объясняют результат: «прогноз на ноябрь ниже прошлогоднего, потому что в этом году нет промо в начале месяца, а тренд последних трёх месяцев отрицательный». Разумная архитектура: числа считает статистическая или ML-модель, а языковая модель переводит их в понятный текст и отвечает на уточняющие вопросы.
Ошибка, которую мы часто видим: загрузить таблицу продаж в чат и попросить «спрогнозируй следующий месяц». Ответ будет выглядеть убедительно и может оказаться случайным. Числовой прогноз должен делать инструмент, предназначенный для чисел.
Какие данные нужны и сколько истории
Качество прогноза почти целиком определяется входными данными, а не алгоритмом.
- История продаж по дням (не по месяцам) с разбивкой по товарам или категориям. Для сезонного бизнеса — минимум два полных года, чтобы отделить сезон от случайности. Для бизнеса без выраженной сезонности хватит шести-девяти месяцев для первых оценок.
- Остатки и дефициты. Если товара не было на складе две недели, нулевые продажи в эти дни — не отсутствие спроса. Без этой информации модель занизит прогноз.
- Акции и цены. Всплеск продаж во время скидки не должен учитываться как обычный спрос.
- Внешние факторы, если они реально влияют: праздники, погода для сезонных товаров, расходы на рекламу.
Если данные разбросаны по кассе, 1С и таблицам, их сначала нужно собрать в одно место. Как это делается, подробно описано в статье о сборе данных из разных источников.
Три разных задачи, которые называют одним словом
«Прогноз продаж» означает разные вещи для розницы, для B2B и для сервиса, и методы для них разные.
Прогноз спроса по товарам — розница, доставка, производство. Много позиций, много продаж, стабильная статистика. Здесь работают методы первого и второго уровней, результат — рекомендация по закупке на каждую позицию.
Прогноз выручки компании — нужен для планирования денег. Это агрегированный ряд, он обычно спокойнее, чем отдельные товары, и часто достаточно сезонной статистики с поправкой на тренд.
Прогноз закрытия сделок в CRM — B2B с длинным циклом. Здесь нет сотен продаж в день, зато есть сделки на разных этапах с историей. Модель оценивает вероятность закрытия каждой сделки по признакам: сколько дней на этапе, сколько касаний было, из какого источника пришёл клиент, сумма. Это ближе к ИИ в CRM, чем к классическому прогнозированию, и там же разобраны детали.
Где прогноз не сработает
Честнее сказать об этом до проекта, чем после.
- Новый бизнес без истории. Полгода продаж — слишком мало для чего-либо, кроме грубых оценок. Лучше потратить это время на аккуратный сбор данных.
- Редкие дорогие сделки. Если компания закрывает пять контрактов в квартал, статистика не работает: один сорвавшийся контракт — это минус 20%. Здесь полезнее сценарное планирование, чем модель.
- Резкие изменения. Смена ассортимента, переезд, выход на новый рынок, изменение закупочных цен вдвое. Модель, обученная на прошлом, этого не знает. После таких событий прогноз нужно перестраивать и первые месяцы относиться к нему с осторожностью.
- Данные с пробелами. Если касса полгода не фиксировала возвраты, а часть продаж шла «мимо» учёта, прогноз унаследует все эти искажения.
Как понять, что прогнозу можно верить
Прогноз всегда ошибается, вопрос в размере ошибки. Простой способ проверки, доступный без специалиста: построить прогноз на уже прошедший период и сравнить с фактом. Если модель «предсказывает» прошлый месяц с ошибкой в 10%, примерно такой точности стоит ожидать и на следующий.
Ориентиры для оценки: для агрегированной выручки стабильного бизнеса ошибка около 5–15% на месяц вперёд считается рабочей; для отдельных товаров она закономерно выше, 20–40% по позициям с небольшими продажами — обычное дело, и это нормально, потому что решение о закупке принимается с запасом.
Полезное правило: прогноз должен выдаваться не одним числом, а диапазоном. «Продадим 180–240 упаковок» честнее и полезнее для закупщика, чем «продадим 207». И ещё одно: модель нужно переобучать по мере поступления новых данных, а не настроить один раз и забыть.
Пример: доставка еды и планирование смен
Служба доставки в городе с населением около полумиллиона, два года истории заказов по часам, данные в учётной системе и в сервисе доставки. Боль — то не хватает курьеров в пиковые часы и заказы опаздывают, то курьеры простаивают.
Что сделали: собрали заказы по часам в одну базу, добавили погоду и праздники, построили модель второго уровня, которая прогнозирует количество заказов по часам на неделю вперёд. Поверх — короткая сводка в Telegram для управляющего каждый вечер: прогноз на завтра по часам и рекомендация по числу курьеров на смену. Языковая модель формулирует объяснение: «пятница, прогнозируется дождь, ожидаем на 25–35% больше заказов в 19–21 час».
Что не получилось сразу: первые недели модель промахивалась в дни крупных футбольных матчей, их добавили как отдельный фактор. Точность на неделю вперёд в итоге стала достаточной, чтобы составлять график смен по прогнозу, а не по ощущениям.
С чего начать
- Назовите решение, которое должен поддерживать прогноз: закупка, смены или деньги. Одно, не три.
- Проверьте, есть ли история продаж по дням хотя бы за год и учтены ли дефициты и акции.
- Начните с первого уровня: сезонность и тренд в таблице. Сравните с фактом за прошлые месяцы. Если точность достаточна для решения, останавливайтесь здесь.
- Если позиций много или ошибка неприемлема, переходите к моделям второго уровня и добавляйте внешние факторы.
- Выводите прогноз туда, где принимается решение: в сводку для закупщика, в дашборд собственника, в задачу управляющему. Прогноз в отдельном файле, который никто не открывает, не работает.
Мы в AiKrok в таких проектах обычно начинаем с двухнедельной версии: одна база, один прогноз для одного решения и сводка в Telegram. Этого достаточно, чтобы увидеть, повышает ли прогноз качество решений, и уже потом усложнять.