Прогноз продаж записується в таблицю, склад поповнює запаси за рівнем досвіду, а виробництво планується на основі замовлень у виконанні — коли три системи не збігаються, виникає або переповнення складу, або дефіцит товару. Управлінські проблеми, які вирішує S&OP (планування продажів і операцій), дуже конкретні: забезпечити узгодженість плану попиту, плану постачання та стратегії запасів на одній базі фактів і під час однієї зустрічі , а не звинувачувати один одного під час підсумкової перевірки наприкінці місяця.
Управлінський сценарій: чому прогноз і запаси завжди розходяться?
Поширене явище серед середніх виробничих та дистрибуційних компаній: маркетологи подають оптимістичні прогнози за регіонами; планувальники не довіряють цим даним і пропонують знижки «за кадром»; закупівельники замовляють за мінімальними партіями постачальників; фінансисти бачать погіршення оборотності запасів, але не можуть чітко визначити відповідальність. Прогнози надсилаються по електронній пошті, а через три дні ніхто вже не пам’ятає, який саме варіант є актуальним. Якщо акції та замовлення ключових клієнтів не включаються до загального обсягу прогнозу, дефіцит проявляється лише в день відвантаження.
Ціна розбіжності може бути кількісно оцінена: витрати на термінову доставку повітрям, збитки від недостачі товару під час акцій, резерви на застарілі запаси, втрати при переналаштуванні виробничих ліній. Якщо система надає лише форму для введення прогнозу та інструмент для перевірки запасів, то все одно не вистачає механізму співпраці — хто змінює прогноз, хто підтверджує дефіцит постачання, хто затверджує виняткові закупівлі.
Що має контролювати система: версії планів та права прийняття рішень
- Версія плану попиту : заморожується щотижнево або щомісяця, зміни проходять через процедуру затвердження і фіксуються в різниці.
- Потужність постачання та товари в дорозі : потужність виробництва, закупівлі в дорозі, стратегія безпечних запасів — усі на одному екрані.
- Дефіцит та виняткові випадки : автоматично розраховується нестача SKU, а для виняткових закупівель і переміщення товару передбачені ліміти.
- Записи засідань повертаються назад : рішення перетворюються на системні завдання, а не додаються до протоколу.
| Розміри | Таблиці + електронна пошта | Системне планування S&OP |
|---|---|---|
| Версія прогнозу | Назви файлів заплутані, важко відстежити | Номер версії + затвердження + порівняння |
| Факти про запаси | Експорт з декількох систем і збирання в одну таблицю | Уніфікація методики визначення доступного обсягу |
| Обробка дефіциту | Голосові термінові доручення | Виняткові замовлення та контроль лімітів |
| Результати засідань | Легко загубити протокол | Рішення стимулює закупівлі та планування виробництва |
| Визначення відповідальності | Післяподійні суперечки | Ролі та ланцюг затверджень можна перевірити |
Кроки реалізації: спочатку узгодження, потім співпраця
Спочатку уніфікувати визначення доступного обсягу: віднімаємо вже виділені та заморожені запаси, додаємо підтверджені товари в дорозі. Потім встановлюємо деталізацію прогнозу, розрізняючи за категоріями ABC. На третьому етапі вводимо ритм засідань: перед засіданням фіксуємо версію, під час засідання обговорюємо лише дефіцит та виняткові випадки, після засідання завдання мають крайні терміни. Лише на четвертому етапі розробляємо алгоритми обчислення дефіциту та процеси роботи з винятками.
Як інтегрувати з ERP-системою управління запасами, замовленнями та продажами?
На рівні S&OP читаємо дані з ERP про запаси, виробничі замовлення та закупівельні замовлення, але не заміняємо виконавчу ланку, яка хаотично змінює документи. Пишемо відповіді з обмеженнями: після підтвердження план може генерувати рекомендації щодо закупівель або виробничих замовлень, які після підтвердження планувальника надсилаються далі. Так уникнемо ситуації, коли зміна прогнозу автоматично скасовує закупівельні замовлення.
Основні дані — невидимий бар’єр: плутанина в кодах матеріалів, помилки при перерахунку одиниць виміру, повторювані SKU — все це спотворює розрахунки дефіциту. Перед впровадженням S&OP слід провести роботу з матеріальними ресурсами. Контролюємо точність прогнозу, частоту виникнення дефіциту, частку застарілих запасів, частку виняткових закупівель, а також відсоток закритих рішень.
Закінчення
Розбіжність між прогнозом і запасами здебільшого виникає через те, що ніхто не візьме на себе відповідальність за версії та за визначення обсягів. Краще зробити S&OP системою, де планування має затвердження, дефіцит та виняткові випадки фіксуються, а рішення повертаються назад, ніж купувати ще один великий екран.
Shandong XYN Information Technology Co., Ltd. (XYN Tech) надає підприємствам системи управління запасами, планування та цифровізовані рішення. Детальніше про продукти можна дізнатися на сайті xynadmin.com, а про історію компанії — на сторінці Про нас в XYN Tech.
При впровадженні часто зустрічаються перешкоди типу «спочатку запустити, потім стандартизувати». Якщо стандарти не будуть чітко визначені, запуск лише посилить хаос. Рекомендуємо два тижні присвятити воркшопу з правил: оформити звичайні практики у формі виконуваних пунктів, занести спірні питання до списку очікувань, і не переходити до етапу розробки, поки ці питання не будуть вирішені.
Якість збору даних визначає довіру до системи. Ключові дії повинні мати відповідальних осіб, часові відмітки та необхідні додатки. Механізм перевірок має входити до щомісячних засідань з управління бізнесом; невідповідність під час перевірки веде до навчання або до відкликання прав, інакше система швидко стане порожньою.
При інтеграції з сусідніми системами спочатку визначаємо авторитетний джерело даних, а потім обговорюємо частоту синхронізації. Хаотичне двостороннє записування — швидкий шлях до зіпсу основних даних. Інтерфейс має передбачати повторні спроби, звіти про збір даних та механізм людської компенсації, щоб уникнути ситуації, коли синхронізація зазнає невдачі, а ніхто про це не знає.
На початку впровадження можна організувати чергування надзвичайних управителів та вікно швидких змін, але це вікно має мати крайній термін. Тривала залежність від людської допомоги свідчить про недосконалість проекту. Руководство з технічного обслуговування має чітко вказувати поширені несправності, процедури відката та шляхи пониження рівня послуг.
Навчання проводиться за ролевим принципом, а не за функціональним меню. Робочі посади тренуються лише на трьох ключових етапах; управлінські посади — на вирішенні непередбачених ситуацій та звірці. Оцінка проводиться на основі реальних документів, а записи навчання вносяться до системи доступу до запуску.
Безпека та аудит не можуть бути додані після факту: ключові списання, зміни сум, підвищення прав повинні піддаватися подвійній перевірці та фіксуватися в журналі аудиту. Період зберігання журналу має відповідати вимогам внутрішнього та зовнішнього аудиту, а права доступу та бізнес-повноваження мають бути розділені.
При впровадженні часто зустрічаються перешкоди типу «спочатку запустити, потім стандартизувати». Якщо стандарти не будуть чітко визначені, запуск лише посилить хаос. Рекомендуємо два тижні присвятити воркшопу з правил: оформити звичайні практики у формі виконуваних пунктів, занести спірні питання до списку очікувань, і не переходити до етапу розробки, поки ці питання не будуть вирішені.
Якість збору даних визначає довіру до системи. Ключові дії повинні мати відповідальних осіб, часові відмітки та необхідні додатки. Механізм перевірок має входити до щомісячних засідань з управління бізнесом; невідповідність під час перевірки веде до навчання або до відкликання прав, інакше система швидко стане порожньою.
При інтеграції з сусідніми системами спочатку визначаємо авторитетний джерело даних, а потім обговорюємо частоту синхронізації. Хаотичне двостороннє записування — швидкий шлях до зіпсу основних даних. Інтерфейс має передбачати повторні спроби, звіти про збір даних та механізм людської компенсації, щоб уникнути ситуації, коли синхронізація зазнає невдачі, а ніхто про це не знає.
На початку впровадження можна організувати чергування надзвичайних управителів та вікно швидких змін, але це вікно має мати крайній термін. Тривала залежність від людської допомоги свідчить про недосконалість проекту. Руководство з технічного обслуговування має чітко вказувати поширені несправності, процедури відката та шляхи пониження рівня послуг.
Навчання проводиться за ролевим принципом, а не за функціональним меню. Робочі посади тренуються лише на трьох ключових етапах; управлінські посади — на вирішенні непередбачених ситуацій та звірці. Оцінка проводиться на основі реальних документів, а записи навчання вносяться до системи доступу до запуску.
Безпека та аудит не можуть бути додані після факту: ключові списання, зміни сум, підвищення прав повинні піддаватися подвійній перевірці та фіксуватися в журналі аудиту. Період зберігання журналу має відповідати вимогам внутрішнього та зовнішнього аудиту, а права доступу та бізнес-повноваження мають бути розділені.