# Закупівлі: прогноз попиту й готове замовлення постачальнику

> Прогноз попиту по кожній позиції й готове замовлення постачальнику з урахуванням товару в дорозі, кратності й терміну придатності. Рішення за закупівельником.

URL: https://emilus.dev/poslugy/zakupivli/
Emilus OÜ · реєстраційний код 17490988 · Sepapaja tn 6, 11415 Tallinn, Estonia · hello@emilus.dev · https://t.me/brrr28

1. [Emilus](https://emilus.dev/)
2. [Послуги](https://emilus.dev/poslugy/)
3. Закупівлі

Закупівлі

Система прогнозує попит по кожній позиції і рахує, скільки замовити, з урахуванням товару в дорозі, кратності партії і терміну придатності. Остаточне рішення за закупівельником.

[Обговорити задачу](https://t.me/brrr28)

[Ціни](https://emilus.dev/tsiny/)

Статус: У проді у бренду ветеринарної продукції: прогноз попиту й щомісячне замовлення виробникам.

## Проблема

- Закупівельник рахує замовлення вручну в таблицях, і розрахунок живе в його голові.
- Одних позицій забагато, і гроші заморожені на складі. Інших не вистачає, і продажі втрачені.
- Замовлення їде місяцями, тому помилка сьогодні видна тільки через квартал.
- Сезонність, акції і нові позиції враховуються «на око».

Як вирішуємо

## Спершу дані й метрика, потім модель.

До аудиту даних ми не називаємо ні строк, ні точність.

1. Бриф : Як ви закуповуєте зараз, у кого, з якими термінами, мінімальними партіями й обмеженнями.
2. Аудит даних : Історія продажів, залишків і замовлень постачальникам з вашої облікової системи. Головне, чи видно періоди дефіциту: інакше модель вивчить порожній склад, а не попит.
3. Метрика до старту : Разом фіксуємо, як міряємо точність: горизонт, по позиції чи по групі, у штуках чи в грошах. Базова лінія: як закупівельник рахує зараз.
4. Перевірка на «сліпому» періоді : Модель прогнозує період, якого не бачила, і ми порівнюємо з фактом, до того, як їй довірити гроші.
5. Застосунок для закупівельника : Готове замовлення, правка з поясненням причини, історія рішень.
6. Перенавчання під контролем : Нова версія моделі йде в роботу тільки тоді, коли на перевірці не гірша за попередню.

Що отримуєте

## Готове замовлення з поясненням, а не «чорна скринька».

Система рахує, закупівельник вирішує. Його правки з причиною теж дані для моделі.

- Прогноз попиту по кожній позиції з поясненням: сезон, акції, тренд.
- Готове замовлення постачальнику з урахуванням товару в дорозі, кратності, страхового запасу і терміну придатності.
- Ліміт грошей на закупівлю в місяць як обмеження розрахунку.
- Звіт «прогноз проти факту» щомісяця.
- Правку закупівельника з причиною: система вчиться на ній.

Канали та інтеграції

## Звідки беремо дані і куди віддаємо замовлення.

- працює · у проді в наших системах
- робили · зроблено в іншому проєкті
- під проєкт · у вашому проєкті робимо вперше, API перевірено

- **1С / BAS: читання продажів і залишків** · : під проєкт · : стандартні маршрути: OData, HTTP-сервіси, обмін файлами; перевірено за документацією
- **Excel і Google-таблиці: вивантаження замовлення** · : під проєкт · : з Google-таблицями працювали в інших проєктах
- **Сповіщення в Telegram** · : робили · : у наших системах у проді
- **Модель прогнозу** · : працює · : у проді у бренду ветеринарної продукції; інструменти аналізу даних розгортаємо під кожен проєкт

Строки і ціна

## Строк після аудиту даних. Ціна після брифу.

Спершу дивимось, що є у ваших даних, і тільки тоді обіцяємо.

### Строк і точність

Після аудиту даних

До аудиту ми не називаємо ні строк, ні точність.

**Строки:**
Після аудиту даних.

**Ціна:**
Після брифу.

**Бриф:**
Безкоштовно.

Кейс і демо

## Як це виглядає на практиці.

Кейс у проді: прогноз і щомісячне замовлення виробникам для бренду ветеринарної продукції. Публічного демо немає.

[Прогноз попиту і щомісячне замовлення виробникам](https://emilus.dev/keysy/prohnoz-zakupivel/)

Демо

### Демо поки немає

Покажемо підхід на ваших даних після аудиту: прогноз на «сліпому» періоді проти факту.

Часті питання

## Що питають про прогноз.

### Яку точність ви гарантуєте?

До аудиту даних жодної. На ходових позиціях висока точність зазвичай досяжна, на рідкісних ні. Ціль ставимо після перевірки на «сліпому» періоді ваших даних.

### Скільки історії потрібно?

Важливіша не кількість років, а якість: позначки дефіциту, календар акцій, історія замовлень постачальникам з датами. Мінімум визначаємо на аудиті.

### Хто ухвалює рішення про замовлення?

Закупівельник. Система дає готовий розрахунок із поясненням, людина підтверджує або править.

### Модель перенавчається сама?

За кнопкою або за розкладом, але нова версія йде в роботу тільки тоді, коли на перевірці виявилась не гіршою.

### Продажі мережам це ж не попит покупця?

Так, відвантаження в мережі й маркетплейси не те саме, що продажі кінцевому покупцю. Ми враховуємо це на аудиті даних і в моделі.

Наступний крок

## Напишіть, відповість людина, а не агент.

[Написати в Telegram](https://t.me/brrr28)

[Усі контакти](https://emilus.dev/kontakt/)