Некоторым нашим потенциальным клиентам стали присылать документ с недостатками и проблемами, которые якобы возникают при использовании программы Forecast NOW!
Мы подробно разобрали каждый пункт в этой статье и объяснили, почему все эти недостатки и проблемы не соответствуют действительности.
A. Высокая трудоемкость работ по настройке заказов:
- Проблема – не поддерживается многозвенная цепочка поставок (Производство, Федеральный РЦ, Региональный РЦ, Магазины)
Как на самом деле:
Поддерживается как при заказе на разные звенья сети, так и при распределении, в том числе многоуровневом
Настройка самой структуры: help.fnow.ru/dokuwiki/настройка параметров
- Проблема – нет настройки автозакрытия заказов, что приводит к недозаказу, если висят неактуальные заказы.
Как на самом деле:
Наша позиция: основным источником данных должна быть учетная система, в которой хранятся все необходимые данные. Сначала нужно закрыть заказ в ней, после этого подать на вход программе актуальную информацию.
- Проблема – функционала заказов несколько раз в день (волнами возможен только через разработку скриптов по выгрузке заказов в разные папки.
Как на самом деле:
Наш продукт развивается исходя из потребностей клиентов. На текущий момент такой потребности не было.
В случае, если она возникнет у клиента, добавим ID заказа в имя (чтобы по 1 поставщику в 1 день могли получаться заказы с разными именами). Легко можно будет поддерживать логику заказов по одному товару волнами.
- Проблема – в графиках изначальный выбор товаров возможен по товарным группам, но в итоге формируется конкретный перечень товаров с конкретными параметрами. При изменении ассортимента поставщика или товарной группы график становится неактуальным, и его необходимо править вручную. Это как минимум приводит к запоздалой, несвоевременной актуализации графиков. А в худшем случае графики так и остаются неактуальными, считая заказы по тем товарам, по которым считать уже не нужно, и не считая заказы по товарам, по которым считать нужно.
Как на самом деле:
Расписание заказов можно привязать к поставщику при помощи правил автоматической установки параметров.
У товара меняется поставщик в учетной системе – срабатывает правило, и товар заказывается по новому графику.
- Проблема – нет возможности автоутверждать или закрывать заказы в выбранное время по выбранным графикам.
Как на самом деле:
На текущий момент такого функционала нет, так как администрирование заказов не является основной задачей программы (основная – расчет оптимального заказа поставщику и внутренних перемещений). Добавление подобного рода функционала есть в плане на разработку.
- Проблема – нет разбиения заказов по автомобилям или контейнерам, только по субассортименту.
Как на самом деле:
Есть функция разбивки заказа по транспортным средствам: http://help.fnow.ru/dokuwiki/Разбивка заказа по транспортным средствам
B. Плохой автозаказ в ряде случаев:
- Проблема – не поддерживается многозвенная цепочка поставок (Производство, Федеральный РЦ, Региональный РЦ, Магазины).
Как на самом деле:
Спрогнозированные коэффициенты влияния промоакций используются не отдельно, а внутри механизма вероятностного моделирования. Такой подход к промоакциям, по нашим исследованиям, подходит для большинства товаров, включая редкий и гладкий спрос. Алгоритм учета акций для товаров с очень редким спросом (очень низкими регулярными и нерегулярными продажами) сейчас находится в разработке.
- Проблема – сезонное прогнозирование выполняется через коэффициенты, что не пригодно для сезонных товаров типа черешни.
Как на самом деле:
Такие товары все равно подвержены общим месячным сезонным колебаниям, привязку спроса к другим факторам, влияющим на него (погода и прочее), можно установить при помощи механизма событий.
- Проблема – нет учета даты ввода/вывода товара в ассортимент.
Как на самом деле:
Сейчас поддерживается логика работы с новым товаром по числу дней с момента его первой продажи (можно настраивать отдельно для разных групп товаров). То есть задается то число дней, сколько товар будет считаться новым и по нему будут применяться отдельные правила заказа. При выводе товара из ассортимента ему или загружается параметр «Не заказывать товар»=«Да» или задается аналог, вводимый вместо него в ассортимент. Работа с новым товаром (видео).
Даты ввода-вывода ассортимент в плане разработки.
- Проблема – недопоставки увеличивают уровень страхового запаса, что может привести к перетарке, а также скрывает проблему от пользователей.
Как на самом деле:
Если недопоставки приводят к дефициту, то дефицитные продажи не учитываются при моделировании (на наш взгляд, это самый стабильный подход к расчету). Недопоставки от поставщика можно контролировать при помощи реестра заказов: http://help.fnow.ru/dokuwiki/Реестр
- Проблема – нет порога округления. Даже если понадобится, нельзя настроить, чтобы при потребности в 30% от коробки округлить в большую сторону.
Как на самом деле:
Есть несколько логик округления:
- По задаваемому порогу: help.fnow.ru/Правило округления с выбранным порогом округления
- По правилам математики
- Подбор упаковки для округления: help.fnow.ru/Правило округления по упаковкам
- Особые случаи работы с первой кратность товара: help.fnow.ru/Правило округления - половина кратности
- Проблема – варианты расчетов заказа ограничены: только прогнозный метод, через уровень сервиса.
Как на самом деле:
Для каждого товара строится его уникальное вероятностное распределение спроса, исходя из его продаж с учетом влияющих на него факторов (сезонность, акции и прочее). Индивидуальный подход к каждому товару – вероятностное распределение спроса конкретного товара + оптимизация уровня сервиса через финансово-рисковую модель с учетом особенностей конкретного товара (наценка, зона хранения и прочее).
Отдельно учитывается известный подзаказной спрос, акции клиентов с гарантией выбранного объема товара, витринная выкладка и палетная выкладка под маркетинговую акцию.
Используемые модели заказа подробнее описаны в статье «Модели заказа Forecast NOW! Выбираем оптимальную для каждого SKU».
С. Аналитика бедная и негибкая:
- Проблема – нет учета списаний товаров на магазине, что не позволяет анализировать такие потери.
Как на самом деле:
Риск списаний учитывается при расчете оптимального уровня сервиса. Для каждого возможного объема запаса определяются потери от разных факторов, включая риск списания.
- Проблема – нет возможности иметь свои дополнительные отчеты. Имеющиеся нельзя кастомизировать.
Как на самом деле:
В программе широкий инструментарий аналитики. Виды анализов:
- ABC, XYZ и кросс ABC, фактический и прогнозный
- Категорийный менеджмент
- Расчет показателей эффективности управления товарными запасами
- Анализ динамики изменения показателей эффективности
- Анализ ассортимента (поиск неликвидных позиций и пр.)
- Анализ ситуаций неслучайного отсутствия спроса
- Поиск оптимального поставщика
- Поиск оптимального периода заказа
Помимо этого, новые блоки аналитики добавляются по мере потребностей пользователей.
