AI-прогнозування попиту на запчастини та оптимізація запасів

Надлишки на складі заморожують гроші, а дефіцит зриває відвантаження: звичні формули не встигають за сезонністю та попитом. Ми розробляємо під ключ прогнозування попиту на запчастини — за складськими групами, з урахуванням історії та сезонності. На виході — модель, регламенти та зрозумілі звіти, з якими закупівлі плануються без ручних правок.

AI-прогнозування попиту на запчастини та оптимізація запасів

Аналіз часових рядівСередній~2-4 тижні
Часті запитання

Чому прогнозування попиту на запчастини дає збої

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

Попит на деталі рідкісний і рваний: одна позиція витрачається раз на квартал, інша — партіями після сезонного навантаження на парк.

Помилка прогнозу потреби виникає там, де історія не розділена на заміну через відмову, планове обслуговування та разову закупівлю під конкретний ремонт. Розрахунок «середнє за період плюс запас» не бачить ані життєвого циклу вузла, ані взаємозамінності деталей.

Помилка б'є в обидві сторони. В один бік — дефіцит деталей на складі: постачання від виробника триває тижнями, а простій техніки та зірваний термін ремонту б'ють по всьому ланцюжку.

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

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

Що дає прогнозування на рівні складських груп

Ручне планування тримається на порогових правилах: дозамовити, коли залишок пробив точку замовлення, і в обсязі «як минулого разу».

На рідкісних деталях це розвалюється — по одній позиції ряд занадто короткий, щоб відокремити сезонність від випадковості, тому запас або заморожується надлишком, або йде в дефіцит і термінове дозамовлення.

Розрахункове планування рахує прогноз на рівні складської групи: усередині групи ряд щільніший, у ньому видно тренд, сезонність і ефект замінників.

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

З інтервалу виростає страховий запас: для популярних артикулів він прив'язаний до верхнього квантиля помилки та строку постачання, для рідкісних — до ризику відмови та комплектності замовлення.

Звідси вимірювані ефекти: зниження надлишків на 20–40% без просідання рівня сервісу за деталями, зростання оборотності запасів завдяки виведенню нерухомих залишків і різке скорочення частки термінових дозамовлень.

Метрики зводимо до галузевого словника — у SCOR це точність прогнозу, оборотність і рівень сервісу, — тому ефект видно не лише у звіті моделі.

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

Порівняння підходів до планування запасів

Підхід обирають не за «просунутістю», а за структурою каталогу: скільки позицій, яка частка сезонних, як часто змінюється попит і наскільки довга історія є за кожною позицією.

Жорсткі правила поповнення тримають популярні артикули, статистичні моделі попиту — сезонні групи, навчальна модель — розріджений попит за великим каталогом. Нижче — чотири схеми, їхні умови застосовності та точки, де кожна перестає тримати заданий рівень сервісу.

Підхід Коли підходить Де ламається
Жорсткі правила поповнення складу: точка замовлення, пороги мінімум-максимум, страховий запас від середньої витрати Популярні позиції зі стабільним попитом і коротким строком постачання Зміна режиму продажів або перебої у постачальника — середні відстають на місяці, запас завмирає
Статистичні моделі попиту: згладжування та сезонна декомпозиція Виражена сезонність попиту та довга рівна історія за позицією Рідкісні позиції з короткою історією: розкид оцінки вищий за сам попит
Навчальна модель на історії та ознаках: акції, аналоги, графік постачання Великий каталог, є дані про замінники та про постачання Потребує чистих даних і регулярного перенавчання, інакше тихо деградує
Гібридна схема планування: модель дає рівень попиту, правила — постачання Різнорідний каталог, де поруч живуть популярні та рідкісні позиції Складніша в підтримці: два контури передбачення та явні стики між ними

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

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

Етапи впровадження: від аудиту даних до передачі

Планування закупівель ламається не на розрахунку, а на вхідних даних: в однієї деталі кілька артикулів у каталозі, списання проведені без прив'язки до техніки, частину замін оформлено вручну.

Поки це не розібрано, будь-який прогноз попиту на запчастини лише відтворює поточний безлад. Тому етапи впровадження планування йдуть фіксованою послідовністю — від аудиту історичних даних до передачі рішення в експлуатацію.

  1. Аудит історичних даних. Вивантажуємо рухи по складу та історію замін за весь доступний період, зводимо дублі номенклатури, відновлюємо дати встановлення. На виході — таблиця, де заміна прив'язана до деталі, техніки та дати.
  2. Схема розрахунку. Прив'язуємо запчастину до вузла, моделі техніки та регламенту обслуговування, виділяємо групи зі спільною логікою витрати: оборотні, рідкісні, нові без історії.
  3. Налаштування моделі попиту. Задаємо розріз прогнозу — склад, регіон, група, — закладаємо сезонність, тренд і строки постачання, з очікуваної помилки рахуємо страховий запас і точку дозамовлення.
  4. Перевірка якості прогнозу. Розрахунок налаштовується на історичному інтервалі, а перевіряється на відкладеному періоді, який не брав участі в налаштуванні: порівнюємо помилку за групами та з ручним плануванням.
  5. Передача рішення в експлуатацію. Переносимо розрахунок в облікову систему, описуємо регламент перерахунку й оновлення, навчаємо планувальника та передаємо документацію.

Далі — підтримка: раз на квартал звіряємо факт із прогнозом і коригуємо налаштування, якщо змінюється парк техніки або умови постачання.

Конфігурації, регламенти та документація на виході

Комплект передаємо у ваш репозиторій і разом проходимо по ньому на прийманні: перевіряємо не наявність файлів, а відтворюваність результату на ваших даних.

Кожен документ прив'язаний до конкретного артефакту в системі, тому оновлення налаштувань і оновлення опису йдуть однією зміною.

  • Конфігурація моделі попиту: горизонти планування, сезонні профілі, окремі правила для позицій із рідкісними продажами, пороги перенавчання та умови, за яких модель повертається до попередньої версії.
  • Схема потоків даних: джерела історії продажів, залишків, строків постачання та статусів замовлень, точки очищення й агрегації до рівня склад — артикул — тиждень, затримки на кожній ділянці.
  • Регламент поповнення: точки замовлення та страховий запас за класами деталей, округлення до кратної упаковки, пріоритети при дефіциті та правила ручного коригування.
  • Документація щодо моделі: опис ознак, метрики якості на відкладеному періоді, розбір типових помилок і межі застосовності — де прогноз втрачає точність.
  • Матриця відповідальності: хто погоджує зміни порогів, хто володіє довідником артикулів, хто розбирає розбіжності прогнозу та факту і в який строк.
  • Інструкції з експлуатації: перезапуск перерахунку, відкат конфігурації, додавання нового складу або каналу продажів без правки коду.

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

Проєкт: надлишки на складі скоротилися втричі

Клієнт — мережа сервісних центрів з розподіленим складом: кілька тисяч номенклатурних позицій, де частина деталей витрачається щодня, а частина — одиницями на рік. Планування велося за середнім продажем за минулі періоди, без сезонності та прив'язки до моделей обладнання.

Закупівельник страхувався й добирав «про всяк випадок»: склад зростав швидше за виручку, а за популярними позиціями все одно виникав дефіцит.

Ми зібрали єдиний контур — історію рухів по складу, довідник сумісності, календар сервісних кампаній і сезонні профілі.

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

Показники до та після

Показник До Після
Частка неліквіду на складі 24% номенклатури 8%
Дефіцит за популярними позиціями 11% заявок 3%
Оборотність запасів 2,3 обороти на рік 6,1
Термінові закупівлі в обхід плану 18% замовлень 5%
Відхилення прогнозу на місяць ±38% ±14%

Окремо налаштували контур контролю: регулярне перенавчання на свіжих рухах, відстеження зсуву прогнозу та автоматичне повернення до попереднього правила, якщо точність падає. Це знімає головний ризик — розрахунок тихо застаріває після зміни асортименту або умов постачання.

Що робити, якщо є своя система планування?

Своя система планування — не перешкода, а контур, у який ми вбудовуємося, а не який замінюємо. Перший крок — зняти чинні правила поповнення: точку замовлення, страховий запас, кратність і мінімальну партію, обмеження за складами та строками постачання. Ці правила вже містять знання про специфіку бізнесу, і втрачати їх під час переходу немає потреби.

Далі — порівняння з поточним процесом на історії: проганяємо минулі періоди через розрахунок і через нинішні правила, дивимося, де рекомендації розходяться і чому. Зазвичай причини зрозумілі — сезонність, разові акції, заміни артикулів, ручні коригування планувальника. Розбіжності розбираємо за групами номенклатури разом із тими, хто веде їх вручну.

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

У 1С обмін іде через вивантаження або проміжну базу, довідники номенклатури та крос-заміни зіставляємо заздалегідь — інакше розрахунок піде за позиціями, яких немає в замовленнях.

Правила переносимо поштучно: коректні обмеження — кратність, строки постачання, мінімальну партію — залишаємо як є, застарілі перезбираємо.

Перехід поступовий: одну групу ведемо паралельно, звіряємо рекомендації з рішеннями людей і задаємо поріг розбіжності, за якого розрахунок іде на розбір. Відкат — повернення до попереднього правила за конкретною групою, без зупинки всього процесу планування.

Питання щодо даних, сезонності та точності моделі

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

Що робити, якщо історія продажів неповна?

Достатньо одного-двох сезонів за активними позиціями; рідкісні артикули об'єднуємо в групи за категорією та взаємозамінністю. Пропуски та розриви від зміни облікових систем вирівнюємо до навчання — інакше модель добудує їх як падіння попиту.

Як прогнозувати нові позиції без історії продажів?

Для них беремо профіль аналогів і категорійну криву попиту: модель переймає характер сезонності та темп виходу на плановий обсяг. Після накопичення факту позиція переходить на власний прогноз.

Сезонність і разові сплески — як модель їх розрізняє?

Сезонність описуємо окремими ознаками: місяць, свята, акції, графік постачання. Викиди позначаємо під час підготовки даних і прибираємо з навчання — сплеск, залишений у вибірці, завищує прогноз на весь горизонт і дає перезапас.

Як стежите за якістю прогнозу після запуску?

Порівнюємо прогноз із фактичними відвантаженнями за кожним артикулом і категорією, відстежуємо систематичний зсув і частку позицій, що потрапили в допустимий коридор. Модель перенавчаємо за розкладом, а ознаки правимо при зміні асортименту або логіки постачання.

Обговоримо вашу задачу планування запасів

Щоб перейти від загальних міркувань до цифр, потрібно небагато: вивантаження з облікової системи та опис того, як планування влаштовано у вас зараз.

Цього достатньо, щоб зробити пілотний розрахунок на вашій історії та показати поведінку моделі на вашій номенклатурі, а не на демонстраційних даних. Щоб обговорити задачу предметно, до першої зустрічі варто підготувати:

  • Номенклатура та глибина історії: за якими групами плануємо запаси і за скільки періодів є рух по складу.
  • Гранулярність і горизонт: плануємо за днями, тижнями чи місяцями і на який строк уперед потрібне рішення.
  • Ознаки попиту: регіон, канал, тип клієнта, сезонність, акції, взаємозамінність артикулів.
  • Обмеження постачання: строки постачання, мінімальні партії, кратність упаковки, місткість складу.
  • Правила управління запасом: цільовий рівень сервісу, страховий запас, що вважається дефіцитом і перезапасом.
  • Якість даних: пропуски, ручні коригування, викиди, зміна артикулів і постачальників.
  • Доступи та відповідальні особи: вивантаження із системи, тестовий контур, хто приймає результат і затверджує регламент.

Після цього повертаємося з оцінкою та планом робіт: етапи, строки впровадження, точки контролю та склад передачі в експлуатацію — документація, регламенти перенавчання моделі та інструкції для планувальників. Опишіть задачу в зручному для вас вигляді — відповімо по суті та запропонуємо порядок робіт.

Напрямки AI-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1543
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1395
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1374
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142