Закупівлі: прогноз попиту й готове замовлення постачальнику
Система прогнозує попит по кожній позиції і рахує, скільки замовити, з урахуванням товару в дорозі, кратності партії і терміну придатності. Остаточне рішення за закупівельником.
Статус: У проді у бренду ветеринарної продукції: прогноз попиту й щомісячне замовлення виробникам.
Проблема
- Закупівельник рахує замовлення вручну в таблицях, і розрахунок живе в його голові.
- Одних позицій забагато, і гроші заморожені на складі. Інших не вистачає, і продажі втрачені.
- Замовлення їде місяцями, тому помилка сьогодні видна тільки через квартал.
- Сезонність, акції і нові позиції враховуються «на око».
Спершу дані й метрика, потім модель.
До аудиту даних ми не називаємо ні строк, ні точність.
Бриф
:Як ви закуповуєте зараз, у кого, з якими термінами, мінімальними партіями й обмеженнями.
Аудит даних
:Історія продажів, залишків і замовлень постачальникам з вашої облікової системи. Головне, чи видно періоди дефіциту: інакше модель вивчить порожній склад, а не попит.
Метрика до старту
:Разом фіксуємо, як міряємо точність: горизонт, по позиції чи по групі, у штуках чи в грошах. Базова лінія: як закупівельник рахує зараз.
Перевірка на «сліпому» періоді
:Модель прогнозує період, якого не бачила, і ми порівнюємо з фактом, до того, як їй довірити гроші.
- людина підтверджує
Застосунок для закупівельника
:Готове замовлення, правка з поясненням причини, історія рішень.
Перенавчання під контролем
:Нова версія моделі йде в роботу тільки тоді, коли на перевірці не гірша за попередню.
Готове замовлення з поясненням, а не «чорна скринька».
Система рахує, закупівельник вирішує. Його правки з причиною теж дані для моделі.
- Прогноз попиту по кожній позиції з поясненням: сезон, акції, тренд.
- Готове замовлення постачальнику з урахуванням товару в дорозі, кратності, страхового запасу і терміну придатності.
- Ліміт грошей на закупівлю в місяць як обмеження розрахунку.
- Звіт «прогноз проти факту» щомісяця.
- Правку закупівельника з причиною: система вчиться на ній.
Звідки беремо дані і куди віддаємо замовлення.
- працюєу проді в наших системах
- робилизроблено в іншому проєкті
- під проєкту вашому проєкті робимо вперше, API перевірено
- 1С / BAS: читання продажів і залишків: під проєкт: стандартні маршрути: OData, HTTP-сервіси, обмін файлами; перевірено за документацією
- Excel і Google-таблиці: вивантаження замовлення: під проєкт: з Google-таблицями працювали в інших проєктах
- Сповіщення в Telegram: робили: у наших системах у проді
- Модель прогнозу: працює: у проді у бренду ветеринарної продукції; інструменти аналізу даних розгортаємо під кожен проєкт
Строк після аудиту даних. Ціна після брифу.
Спершу дивимось, що є у ваших даних, і тільки тоді обіцяємо.
Строк і точність
Після аудиту даних
До аудиту ми не називаємо ні строк, ні точність.
- Строки
- Після аудиту даних.
- Ціна
- Після брифу.
- Бриф
- Безкоштовно.
Як це виглядає на практиці.
Кейс у проді: прогноз і щомісячне замовлення виробникам для бренду ветеринарної продукції. Публічного демо немає.
Прогноз попиту і щомісячне замовлення виробникам
Читати кейсДемо поки немає
Покажемо підхід на ваших даних після аудиту: прогноз на «сліпому» періоді проти факту.
Що питають про прогноз.
Яку точність ви гарантуєте?
До аудиту даних жодної. На ходових позиціях висока точність зазвичай досяжна, на рідкісних ні. Ціль ставимо після перевірки на «сліпому» періоді ваших даних.
Скільки історії потрібно?
Важливіша не кількість років, а якість: позначки дефіциту, календар акцій, історія замовлень постачальникам з датами. Мінімум визначаємо на аудиті.
Хто ухвалює рішення про замовлення?
Закупівельник. Система дає готовий розрахунок із поясненням, людина підтверджує або править.
Модель перенавчається сама?
За кнопкою або за розкладом, але нова версія йде в роботу тільки тоді, коли на перевірці виявилась не гіршою.
Продажі мережам це ж не попит покупця?
Так, відвантаження в мережі й маркетплейси не те саме, що продажі кінцевому покупцю. Ми враховуємо це на аудиті даних і в моделі.