Да, согласен. В таких системах главная сложность действительно не в том, чтобы найти отклонение, а в том, чтобы не превратить работу людей в поток тревог.
Если менеджер получает 20 сигналов в день и половина из них оказывается шумом, он очень быстро перестаёт реагировать вообще. Поэтому для Operational Radar важнее не количество сигналов, а доверие к ним.
На старте я решаю это несколькими принципами.
Во-первых, сигнал не должен рождаться из одного случайного скачка. Обычно нужно сочетание признаков: например, спрос растёт, покрытие остатком падает, пополнение не успевает, и это повторяется не один день.
Во-вторых, у сигнала есть уровень доверия. Не всё подозрительное должно сразу попадать в основную ленту. Слабые отклонения лучше держать отдельно как “зоны наблюдения” — без красного статуса и без требования немедленной реакции.
Математически это не один жёсткий порог “продажи выросли на X%”. Скорее используется набор признаков с весами: отклонение от собственной истории объекта, повторяемость, скорость изменения, согласованность нескольких источников данных и уровень доверия к самим данным.
Если признака нет, он не ломает модель, а просто получает нулевой или низкий вес. Например, без данных по закупкам сигнал дефицита возможен, но его уверенность ниже.
В-третьих, первые недели — это период калибровки. Важна обратная связь от бизнеса: подтвердилось, шум, в наблюдение, принято в работу, подтвердилось позже. Пороги и чувствительность уточняются не только от статистики, но и от реакции людей, которые знают реальный бизнес.
И ещё важный момент: норму лучше строить не по средней температуре компании, а по привычному поведению конкретного объекта — SKU, клиента, склада, региона или категории.
Хороший результат здесь — не больше сигналов. Хороший результат — меньше лишних сигналов и выше доверие к тем, которые остаются.
Поэтому Radar для меня начинается не с “найти всё необычное”, а с вопроса: какие отклонения действительно заслуживают внимания бизнеса.
Да, согласен. В таких системах главная сложность действительно не в том, чтобы найти отклонение, а в том, чтобы не превратить работу людей в поток тревог.
Если менеджер получает 20 сигналов в день и половина из них оказывается шумом, он очень быстро перестаёт реагировать вообще. Поэтому для Operational Radar важнее не количество сигналов, а доверие к ним.
На старте я решаю это несколькими принципами.
Во-первых, сигнал не должен рождаться из одного случайного скачка. Обычно нужно сочетание признаков: например, спрос растёт, покрытие остатком падает, пополнение не успевает, и это повторяется не один день.
Во-вторых, у сигнала есть уровень доверия. Не всё подозрительное должно сразу попадать в основную ленту. Слабые отклонения лучше держать отдельно как “зоны наблюдения” — без красного статуса и без требования немедленной реакции.
Математически это не один жёсткий порог “продажи выросли на X%”. Скорее используется набор признаков с весами: отклонение от собственной истории объекта, повторяемость, скорость изменения, согласованность нескольких источников данных и уровень доверия к самим данным.
Если признака нет, он не ломает модель, а просто получает нулевой или низкий вес. Например, без данных по закупкам сигнал дефицита возможен, но его уверенность ниже.
В-третьих, первые недели — это период калибровки. Важна обратная связь от бизнеса: подтвердилось, шум, в наблюдение, принято в работу, подтвердилось позже. Пороги и чувствительность уточняются не только от статистики, но и от реакции людей, которые знают реальный бизнес.
И ещё важный момент: норму лучше строить не по средней температуре компании, а по привычному поведению конкретного объекта — SKU, клиента, склада, региона или категории.
Хороший результат здесь — не больше сигналов. Хороший результат — меньше лишних сигналов и выше доверие к тем, которые остаются.
Поэтому Radar для меня начинается не с “найти всё необычное”, а с вопроса: какие отклонения действительно заслуживают внимания бизнеса.