Прогноз продаж в 1С с ИИ: как подготовить данные и проверить результат до закупки
Модель может продолжить историю продаж, но будущая закупка зависит ещё от остатков, поставок и ограничений бизнеса. Разбираем путь от исходных данных до проверенного плана.
Товар две недели отсутствовал на складе. В отчёте за этот период — нулевые продажи. Если передать ряд без пояснений, модель может решить, что интерес покупателей исчез. Снабжение уменьшит заказ, и нехватка товара повторится. Прогноз оказался построен на реальных цифрах, но их смысл был потерян.
Поэтому интеграция ИИ с 1С для прогнозирования начинается с определения показателя и подготовки истории. Рассмотрим, как организовать этот процесс и оценить результат на прошлых периодах до того, как он повлияет на закупки.
Проверьте готовый сервис прежде собственной модели #
В описании искусственного интеллекта в 1С:ERP фирма 1С показывает маршрут работы сервиса прогнозирования: передача истории, расчёт и возвращение результата в систему планирования. Это основание проверить готовую возможность своей конфигурации, а не обещание одинакового функционала во всех приложениях 1С.
Другой вариант — интеграция с внешним сервисом временных рядов. В материале о 1С:Универсальном прогнозировании описан REST-доступ. Для конкретного приложения отдельно уточняют поддерживаемый сценарий, условия подключения и форматы. Не стоит переносить статус анонса или пилота из публикации в обещание готового запуска.
Собственная модель оправдана, если требуются особые факторы, ограничения размещения данных или методы, которых нет в доступном решении. Но сначала нужен простой контрольный прогноз: без него сложно понять, что дала более сложная система.
Выберите уровень, на котором принимается решение #
Прогноз общей выручки и прогноз количества товара на определённом складе решают разные задачи. Рост цены способен увеличить выручку при сокращении физического спроса. А хорошее совпадение общих продаж компании может скрывать ошибки по конкретным позициям.
Зафиксируйте единицу анализа: товар или группа, характеристика, склад или регион, день или неделя. Горизонт должен соответствовать действию. Если поставка занимает несколько недель, точный прогноз на завтра не заменяет оценку потребности на период ожидания.
Данные
Что уточнить перед выгрузкой
Как ошибка влияет на прогноз
Продажи
Количество, единица, дата операции
Смешиваются разные события и масштабы
Возвраты
Отдельное событие или корректировка ряда
Отрицательные значения трактуются неверно
Наличие
Периоды дефицита и ограничения отгрузки
Потерянные продажи выглядят падением спроса
Акции
Даты, товары и характер изменения
Разовый всплеск принимается за постоянный рост
Ассортимент
Новинки, замены и снятые позиции
Несопоставимая история объединяется в один ряд
Отделите отсутствие спроса от невозможности купить #
Нулевое значение может означать отсутствие покупателей, закрытый магазин, технический сбой или отсутствие товара. Эти ситуации не следует заполнять одним и тем же способом. Для каждой причины определяют, можно ли использовать наблюдение для обучения и нужны ли дополнительные признаки.
История изменений важна не меньше истории продаж. Если в середине периода товару поменяли единицу или объединили карточки, ряд нужно привести к согласованному виду. Нельзя просто склеить числа под новым названием. Для заменяемых товаров отдельно решают, анализировать их вместе или сохранять отличия.
Будущие акции можно учитывать только в той мере, в какой их условия известны на момент расчёта. При проверке прошлой модели нельзя подмешивать сведения, которые появились позднее. Иначе эксперимент покажет качество, недоступное в реальном использовании.
Проверяйте на периоде, которого модель не видела #
Выберите несколько прошлых дат расчёта. Для каждой используйте только предшествующую историю, стройте прогноз на нужный горизонт и сравнивайте с последующим фактом. Такая проверка показывает, как система вела бы себя при последовательной работе.
Рядом посчитайте простой вариант: например, продажи аналогичного периода или среднее за согласованное окно. Сравнивать нужно одинаковые товары, периоды и доступные исходные данные. Если сложная модель не улучшила полезный показатель, дополнительную интеграцию ещё нечем обосновать.
Для агрегированной оценки можно использовать WAPE — сумму абсолютных ошибок, делённую на сумму фактических количеств. Учебный пример: факт за три периода равен 100, 120 и 80 единицам, прогноз — 90, 130 и 100. Абсолютные ошибки — 10, 10 и 20; их сумма 40. При суммарном факте 300 WAPE составляет около 13,3%.
Этот показатель не раскрывает направление ошибки. Отдельно посмотрите, не завышает ли модель прогноз систематически, и что происходит с критичными товарами. При нулевом суммарном факте WAPE не определён; такую группу нельзя представлять как прогноз с нулевой ошибкой.
После прогноза начинается задача обеспечения. Планировщику нужны доступные остатки, уже размещённые поставки, сроки, минимальная партия и ограничения хранения. Учебный пример: на период требуется 100 единиц, доступно 30, ещё 20 подтверждены к поступлению до возникновения потребности. При допущении, что другие потребности и резервы уже учтены, необеспеченная часть равна 50 единицам.
Но если поставка придёт после нужной даты, вычитать её из своевременного обеспечения нельзя. И если поставщик продаёт только упаковками, количество заказа может отличаться от расчётной нехватки. Эти правила относятся к планированию, а не к способности модели продолжать ряд.
Результат полезно сначала сохранять как отдельную версию плана с датой расчёта и параметрами. Ответственный сравнивает его с фактом и ограничениями. Автоматическое формирование заказов требует отдельного решения и тестов, включая отмены и повторный расчёт.
В исходной выгрузке нужны устойчивые идентификаторы рядов, интервалы, единицы и согласованные признаки. В ответе — горизонт, значения, дата расчёта и идентификатор версии. Если сервис возвращает интервальную оценку, показать её вместе с центральным прогнозом; не рисовать собственный «доверительный коридор» без основания.
Ошибку загрузки следует отличать от малого спроса. Пропавший ответ сервиса не должен обнулять существующий план. При повторном получении результата обновляют известную версию, сохраняя возможность понять, на какой информации было принято решение о закупке.
Чат может объяснить расчёт или помочь составить требования. Для регулярного прогноза нужна воспроизводимая процедура работы с временными рядами и проверка на истории. Наличие нейросети или разговорного интерфейса само по себе не подтверждает качество прогноза.
Можно начать с согласованного аналога, группы товаров или экспертного плана, явно сохранив эти допущения. После появления факта сравнить прогноз и скорректировать подход. Нельзя выдавать перенесённую историю другого товара за собственную статистику новинки.
NetLabCS поможет подготовить ряды из 1С, выбрать способ интеграции и сравнить прогноз с простым базовым вариантом. Если результат нужен для пополнения запаса, отдельно связываем его с расчётом потребности и закупками в 1С . При обсуждении проекта определим горизонт решения, источник остатков и показатели, по которым можно оценить пользу для планировщика.
