Yandex.Метрика

Прогнозирование, шаг 1: история продаж

Пункт первый – «корректная история продаж».
Очистка от ошибок и инаутов

Для того, чтобы построить прогноз, основанный на истории продаж, данная история продаж должна быть корректно подготовлена. Она не должна содержать никаких ошибок, пустых строк, некорректной информации. Это самый основной этап подготовки. Если история продаж, грубо говоря, состоит только из одной SKU на одного клиента – всеми остальными этапами можно пренебречь.

Однако, для более крупных объемов данных, для больших предприятий с большой активной клиентской базой, мы переходим к другим этапам. Для начала, история продаж обязательно должна быть очищена от in-out’ов.

 In-out (инаут, ин-аут) – ввод позиции в ассортимент клиента со скидкой, на время проведения промо-акции, с последующим ее выводом. В некоторых случаях, клиент может рассматривать in-out, как «тест продаж», для оценки динамики продаж акционной позиции и ее доходности, для последующего включения в регулярные продажи.

Очистку от in-out’ов можно выполнить и после построения всех прогнозов, если история продаж не будет содержать никаких консолидаций/группировок, о чем я расскажу чуть позже.

Очистка от позиций, выведенных из ассортимента для определенных клиентов + консолидация информации (группировка)

В тот отдел, где я работаю, от представителей отдела продаж поступает информация о том, что из некоторых магазинов или РЦ выводят из ассортимента какую-либо позицию. История продаж должна быть очищена от этих позиций. Да, справедливым будет утверждение, что такую очистку можно выполнить после построения всех прогнозов – просто взять и обнулить или очистить строки с этими магазинами и SKU, но только при условии, что мы пропустим такой шаг, как «консолидация информации».

В некоторых предприятиях предпочитают прогнозировать продажи не по отдельным РЦ или клиентам, а консолидируя их в какую-то определенную группу по схожим характеристикам. Либо вовсе объединяя все-все продажи вместе, даже не группируя, просто суммируя общие объемы по каждой SKU.  Например, очень часто объемы для всех Перекрестков объединяют под одной группой – Х5. Именно здесь можно вернуться к разговору об in-out’ах: если в одном из Перекрестков он был, а мы все объемы сконсолидировали — общий объем будет завышен и, естественно, прогноз будет некорректным.

История продаж - консолидация

И именно поэтому, перед этой группировкой необходимо предварительно корректно почистить историю продаж – чтобы не было завышения объемов в общей картине после группировки. Если группировки не будет – не имеет значения, будет ли очищена история продаж перед построением прогноза, либо обнулять по этим клиентам прогноз после построения (как раз об этом я и говорил в этапе с очисткой in-out’ов).

Консолидировать можно что угодно и как угодно – это все зависит от клиентов, каналов продаж, продаваемого товара, размера АКБ, количества категорий (номенклатурных групп), заданных KPI и т.д., поэтому на этом нет смысла заострять внимание.

История продаж: синхронизация

Также, важной частью подготовки корректной истории продаж является ее синхронизация. Что подразумевается под синхронизацией?

Простейший пример: существовала позиция, которая в базе данных поставщика называлась «Масло подсолнечное, 1 литр, 10шт», т.е. в коробе было 10 бутылок. Затем было принято решение заменить количество вложений в коробе на 6 бутылок, и позиция стала называться «Масло подсолнечное, 1 литр, 6шт». Для клиента, по сути, ничего не меняется. Артикул у позиции остался прежним, объемы заказов тоже примерно такие же, поменялся только короб, в котором поставляют эту позицию, и поменялось наименование позиции в БД поставщика.

Возникает вопрос: каким образом обновлялась данная позиция в БД поставщика?
Если переименовали старую позицию, то все будет работать, как и прежде. Но такое бывает не всегда. Чаще всего, в БД заводят новую позицию с новым названием. Поэтому, прогнозируя по ней объемы, можно «потерять» историю продаж, так как объемы продаж предыдущих периодов будут «подтягиваться» к позиции со старым названием: а особенно это будет заметно, когда в рамках одного периода отгружались обе позиции (например в начале месяца отгрузили позицию с одним названием, а в конце месяца оно уже изменилось). В таком случае, при месячном прогнозировании мы точно потеряем «кусок» объемов.

Конечно, можно прогнозировать объемы новой позиции ориентируясь на старые названия и объемы, выдумывая какие-то хитрые изощрения, но может возникнуть большая путаница: в какой-то момент, построится прогноз и по старому названию SKU и по новому – придется долго все исправлять, чтобы объемы были корректными и адекватными. Поэтому более простым решением будет создание справочников, вшитых в инструмент прогнозирования: при подготовке истории продаж старые названия автоматически будут изменяться на новые, согласно справочнику, а их объемы нигде не потеряются.

История продаж - синхронизация

Существует более серьезная проблема синхронизации данных. Возникает она тогда, когда у поставщика имеется несколько баз данных – 2, 3, а то и больше – и в каждой из баз названия одних и тех же SKU, контрагентов, категорий продуктов и т.д. могут отличаться. Создание справочников может решить эту проблему, но надо понимать, что они всегда должны поддерживаться в актуальном состоянии, но даже в этом случае есть очень большая вероятность возникновения ошибок.

Есть несколько вариантов решения проблемы. Первый вариант — создание единой БД. На это потребуется большое количество времени и ресурсов, как финансовых, так и трудовых.  Второй вариант — внедрение MDM-проекта (Master Data Management). И это более эффективно. Подробнее о внедрении MDM-проекта можно почитать здесь.

История продаж: проверка на активность

Не менее важный пункт для формирования корректной истории продаж — проверка ее на активность. Что это значит? Необходимо проверить, когда в последний раз были заказы по прогнозируемой позиции на какого-либо клиента. И если с момента ее последнего заказа прошло слишком много времени — необходимо либо ее удалить из истории продаж, либо поставить флаг/отметку, для исключения построения прогноза на этого клиента, т.к. вероятнее всего клиент перестал ее заказывать.

В месячном прогнозировании, например, я обычно проверяю 2-3 последних периода — если в это время по позиции на клиента никаких заказов не было, то отмечаю данные позиции флагом «Не прогнозировать», после чего при автоматическом построении прогноза объемы данных позиций не учитываются.

В общем-то и все, корректная история продаж подготовлена и мы смело можем переходить к следующему, очень важному шагу «Очистка от промо-активностей или сглаживание промо».

Оставить комментарий