Как построить бизнес-технологию планирования продаж в единой системе

В данной статье я бы хотел поделиться опытом построения системы планирования продаж и рассказать о практических шагах по ее внедрению.

Проблема разрозненного планирования

Зачастую в компаниях складывается следующая ситуация: У каждого подразделения возникает своя, уникальная версия плана продаж. Такие планы используют в работе, например, отделы маркетинга, продаж, финансисты и логистика.

Эти планы имеют разные формат, разную степень детализации, и, что самое важное, разные и противоречащие друг другу цифры.

Возникает закономерный вопрос, как выстроить в компании систему интегрированного планирования и что для этого нужно.

Выстраивание бизнес-процесса

Думаю важно подходить к вопросу с позиции создания отлаженной бизнес-технологии.

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

(Часто используют термины: S&OP — Sales and Operations Planning, IBP — Integrated Business Planning).

В процессе планирования должны быть четко определены участники и их роли, конкретные задачи и сроки. Например, продавцы предоставляют планы клиентов (или каналов). Маркетинг проверяет ассортимент и сообщает о новинках и т.д.

Для процесса планирования и его участников должны быть определены KPI и разработаны отчеты, по которым станет возможно контролировать качество результатов. Например, полнота данных, точность планирования, оборачиваемость запасов и уровень сервиса.

Организационные сложности процесса

Дисциплина участников

Планирование требует вовлеченности разных сотрудников компании, а также предоставление ими качественных данных в требуемый срок. (ИТ-система частично может компенсировать эти проблемы, применяя расчеты в автоматическом режиме.)

Корректность и полнота справочников (мастер данных)

Необходимо обеспечить своевременную актуализацию справочников в учетной системе. Например, для товара должны быть определены текущий статус, даты начала/окончания продаж, категория и др. поля, которые будут использоваться при планировании и анализе.

“Top-down” корректировки

При согласовании планов на верхнем уровне, неминуемо могут происходить корректировки “Сверху-вниз” в автоматическом режиме. В этом случае, у исполнителей размывается ответственность за планирование, т.к. цифры были “скорректированы сверху”.

В любом случае, необходимо наладить отслеживание/аудит правок и версий планирования.

Высокая степень неопределенности

Изменения на рынке и действия конкурентов могут сводить “на нет” все усилия по планированию. Полезным будет внедрить метод сравнения с “Наивным прогнозом”. Т.е. например, насколько результат работы процесса лучше, чем простое скользящее среднее или иной несложный метод прогнозирования. (К сожалению, на практике может оказаться, что наивный прогноз сопоставим по качеству с результатом работы процесса).

Аналитическое хранилище данных

Сейчас трудно найти компанию, которая не имеет свою систему аналитической отчетности и единого хранилища аналитических данных.

Тем не менее, такая система является необходимым условием для построения системы планирования.

Статистика фактических продаж, цен, дополнительная внешняя аналитика, Складские поставки, Оборачиваемость, Товар в транзите — все это необходимо как для составления плана продаж, так и для его последующего анализа.

Поэтому, возможно, что перед построением системы планирования придется построить хранилище данных и систему бизнес-аналитики.

Тут существует множество подходов и решений, но я хочу остановиться на нескольких ключевых пунктах:

Качество данных

Т.к. хранилище данных является отдельной системой, то думаю, неизбежным являются расхождения в цифрах с основными учетными системами, из которых данные загружаются в хранилище. Существенная часть усилий может быть потрачена на очистку, проверку и перепроверку загруженных данных. Чтобы это не стало неожиданностью для руководства, стоит заложить эти задачи в план/бюджет проекта.

Визуализация данных (дашборды)

В целом, дашборды полезны для внутреннего маркетинга проекта и для его эффективного представления руководству компании. Однако, существенным минусом является довольно высокая стоимость их создания и недостаточная гибкость в настройке на стороне конечного пользователя. По сути (по моему мнению) дашборд скорее является ИТ-продуктом и большинство даже продвинутых пользователей не готовы осваивать какие-либо системы визуализации данных, кроме Excel.

Быстродействие

Быстродействие может стать большой проблемой, которая будет сильно влиять на отношение пользователей к системе и их готовность с ней работать. Хороший способ повысить быстродействие — это использовать технологию OLAP, минимизируя при этом кол-во расчетов выполняемых “на лету”.

Машинное обучение

Безусловно данная тема является ключевым “хайпом” и вокруг нее существует много информации рекламного характера.

Давайте посмотрим, что может дать машинное обучение нам на практике и с чем предстоит столкнуться.

На мой взгляд, машинное обучение в сфере планирования, как правило, не дает более высокую точность, чем ручное планирование (хотя возможно это лишь вопрос времени).

Важной выгодой от его внедрения является упрощение рутинных операций, особенно для товаров, которые относятся по ABC-классификации к B и C.

Существенный выигрыш может быть достигнут, если процесс планирования требует большой степени детализации и объем сочетаний товаров/каналов/магазинов/периодов и т.д. исчисляется миллионами записей.

Теперь о трудностях:

90% усилий тратится не на построение алгоритма, а на очистку и подготовку данных

Как и в вопросе построения бизнес-аналитики, данные, подаваемые на вход машинному алгоритму должны быть выверены и преобразованы в “фичи” (или предикторы). На мой взгляд, на этой стадии наиболее высок риск как логических ошибок, так и багов. Бороться с проблемой можно проводя визуализацию и проверку данных на промежуточных стадиях.

Результат и стоимость работы сложно прогнозировать

На мой взгляд, это самая большая проблема. Построение алгоритмов прогнозирования это процесс близкий по своей сути к научному исследованию. Его легко сделать бесконечным и высок риск провала при низком качестве прогноза. Причиной является бесконечное количество вариантов предикторов и моделей, которые можно попробовать для улучшения качества прогноза.

Дистанцированность от бизнеса

В проектах data science, на мой взгляд, высок риск непонимания бизнес-пользователями языка, на котором говорят специалисты data science.

Для совместной работы важно уметь доносить простыми словами результаты и ход выполнения работы. Избегать математических и других сложных терминов, интерпретировать результаты моделей с позиций здравого смысла.

Для снижения рисков и увеличения управляемости проекта Data science, хорошо подходят технологии проектного управления по Agile.

Существенным является итерационный подход, частая демонстрация результатов заказчику и запуск в продуктив “минимально полезных” частей решения.

Автор: Павел Соболев

Источник ^[1]