Некоторым нашим потенциальным клиентам стали присылать документ с недостатками и проблемами, которые якобы возникают при использовании программы 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, фактический и прогнозный
- Категорийный менеджмент
- Расчет показателей эффективности управления товарными запасами
- Анализ динамики изменения показателей эффективности
- Анализ ассортимента (поиск неликвидных позиций и пр.)
- Анализ ситуаций неслучайного отсутствия спроса
- Поиск оптимального поставщика
- Поиск оптимального периода заказа
Помимо этого , новые блоки аналитики добавляются по мере потребностей пользователей.
