Програмне забезпечення для розширеного планування та диспетчеризації: як оцінити APS

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

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

Automatically translated with AI from the original post. Read the English original

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

Головне

• Програмне забезпечення для розширеного планування та диспетчеризації додає до можливостей MRP планування на основі потужностей і послідовності, тож конкуруючі замовлення та обмежені ресурси стають частиною плану.
• Визначте проблему, перш ніж дивитися на продукти: скільки замовлень конкурують між собою, how часто план ламається і яке реальне обмеження.
• Перевірте, що ваша ERP-система вже робить із кінцевими потужностями, перш ніж щось купувати. Частина функцій обмежена ресурсами, для яких їх потрібно ввімкнути.
• Оцінюйте інструменти за моделюванням обмежень, прозорістю, можливістю втручання планувальника, стабільністю перепланування та зусиллями на підтримку чистоти майстер-даних.
• Тестуйте на власних даних: відтворіть минулий тиждень і порівняйте графік інструменту з тим, що справді сталося.

Що таке програмне забезпечення для розширеного планування та диспетчеризації?

Словник APICS, цитований ASCM, описує систему APS як комп'ютерну програму, що використовує складні математичні алгоритми або логіку для оптимізації функцій планування та диспетчеризації. Це доволі широко. Практичніше визначення наведено у дослідженні Fraunhofer IPA (німецькомовна публікація, переклад мій). Воно розміщує APS поруч із двома іншими класами програмного забезпечення: управлінням ланцюгами постачання на рівні мережі та виконанням виробництва на рівні цеху, а ERP — на рівні підприємства. Крім того, воно описує три етапи логіки планування.

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

Ця стаття розглядає питання з погляду покупця: що вирішити спочатку, які критерії важливі та як тестувати. Коротке визначення самого терміна дивіться у статті advanced planning and scheduling на цьому сайті.

Де APS розташовується між ERP і виробничою дільницею?

ISA описує ISA-95 як міжнародний набір стандартів для інтеграції логістичних систем із системами керування виробництвом. У його моделі бізнес-планування та логістика, де живе ERP-система, належать до рівня 4. Керування виробничими операціями, зокрема MES, належить до рівня 3. APS зазвичай працює між ними: він отримує замовлення та майстер-дані зверху, будує графік і передає його на виробничу ділянку.

Fraunhofer IPA зазначає, що ERP зазвичай є головним джерелом для даних планування, таких як майстер-дані номенклатури, специфікації матеріалів і маршрути. Це показує, де буде зосереджена ваша робота з даними. Якщо ці записи в ERP помилкові, будь-яка APS дуже ефективно складатиме графік для неправильних речей.

Та сама публікація вказує, що ринки APS і MES значною мірою перетинаються. Запитайте на ранньому етапі, хто відповідає за диспетчеризацію на виробничій ділянці. Система виконання виробництва фіксує, що насправді сталося. APS визначає, що має статися далі. Якщо обидві системи претендують на список завдань, планувальники та майстри працюватимуть із двома різними списками.

Яку проблему вам потрібно вирішити?

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

1. Скільки замовлень конкурують за ті самі кілька ресурсів? Якщо небагато, таблиця може ще впоратися.
2. Як часто план ламається протягом зміни і чому? Зупинки верстатів, брак матеріалів, термінові замовлення?
3. Яке реальне обмеження: верстат, кваліфікований працівник, інструмент, піч, стенд для випробувань?
4. Чи залежать часи переналагодження від послідовності завдань? Якщо так, послідовність має реальну цінність.
5. Хто складає графік сьогодні, скільки це займає і як часто його переробляють?
6. Які рішення ви хочете доручити інструменту, а які залишити за планувальником?

Далі перевірте, що вже вміє ваша ERP. Наприклад, Microsoft описує планування та складання графіка з обмеженою потужністю в Dynamics 365 Supply Chain Management. За його допомогою запланărе замовлення, яке не вміщається в наявну потужність, переноситься на дату, коли потужність є. Але це працює лише для ресурсів, для яких ви його ввімкнули, використовує часове вікно, що визначає, скільки днів вважаються обмеженими, і Microsoft попереджає, що одноденне вікно, ймовірно, занадто коротке для більшості виробників. Там також сказано, що обмежену потужність не слід використовувати, коли потужність змінюється разом із вимогами, наприклад, потужність, що залежить від змін. Якщо ваше обмеження схоже на це, ви дізналися щось ще до розмови з будь-яким постачальником. Ваша ERP може відрізнятися, тож шукайте такі самі види обмежень у її документації. Пов'язана ідея складання графіка з обмеженою потужністю є основою для всього цього.

За якими критеріями можна відрізнити одну APS від іншої?

Списки функцій виглядають схоже. На практиці інструменти відрізняють такі критерії.

• Моделювання обмежень: чи може система відобразити ваші реальні обмеження? Верстати, працівники з навичками, інструменти, календарі змін, переналагодження, що залежать від послідовності, вивільнення матеріалів.
• Прозорість: чи може планувальник побачити, чому завдання стоїть саме там? Графік, який не можна пояснити, не витримає першої суперечки на виробничій ділянці.
• Правила пріоритетів: чи можна змінювати правила (термін виконання, клієнт, економія на переналагодженні) без допомоги постачальника?
• Ручні втручання: чи може планувальник перемістити завдання вручну, і чи фіксує система цю дію та перевіряє решту графіка? Запитайте, що відбувається з рештою графіка після ручного переміщення.
• Поведінка при перепланування: перепланування після збою має змінювати лише те, що справді потребує змін. Графік, який щоразу перемішує все, на виробничій ділянці непридатний. Fraunhofer IPA також зазначає, що плани ніколи не можна виконати точно, тож потрібен допуск на відхилення між фактичним і запланованим.
• Інтерфейси даних: як система отримує замовлення, маршрути та прогрес і хто підтримує ці інтерфейси?
• Час виконання: скільки триває повне планування на вашому обсязі даних? Fraunhofer IPA зауважує, що час виконання в межах хвилин ставить під сумнів планування лише вночі, але перевірте на власному обсязі.
• Що як: чи можна перевірити сценарій, не чіпаючи чинний графік?
• Зусилля планувальника: скільки часу потрібно, щоб підтримувати майстер-дані та правила в робочому стані?
• Вартість за кілька років: ліцензія, інтерфейси, робота з майстер-даними, навчання, оновлення.

Що варто запитати у постачальника?

Візьміть ці питання на перший дзвінок. Конкретні відповіді свідчать на користь рішення, а розпливчасті теж про щось говорять.

• Покажіть мені графік, побудований на наших даних, а не на вашому зразковому заводі.
• Що відбувається, коли верстат зупиняється о 10:00? Що змінюється, а що ні?
• Як обробляються переналагодження, які залежать від послідовності?
• Які з наших правил планувальник може змінити самостійно?
• Як фіксуються ручні втручання і хто їх переглядає?
• Яка якість даних потрібна від нас і що ви робите, коли вона відсутня?
• Хто відповідає за інтерфейс із нашою ERP і з системою керування цехом?
• З чим зазвичай стикаються клієнти в подібному процесі (дрібносерійне виробництво, масове, пакетне)?
• Чи можемо ми експортувати нашу модель, правила і дані, якщо підемо від вас?

Як протестувати APS перед покупкою?

Використайте відтворення на реальних даних. Це найдешевший спосіб відокремити маркетинг від реальної придатності.

1. Оберіть реальний минулий тиждень із звичайним рівнем проблем.
2. Завантажте замовлення, маршрути, календарі та ресурси такими, якими вони були на початок того тижня.
3. Дайте інструменту побудувати графік.
4. Порівняйте його з тим, що насправді сталося, і з графіком планувальника: прострочені замовлення, кількість переналагоджень, понаднормові години, простої на вузькому місці.
5. Введіть збій, наприклад двогодинну зупинку на вузькому місці, і перевірте, що змінює перепланування.
6. Дайте планувальнику попрацювати з інструментом один день і відмічайте кожен момент, коли він не довіряв або не розумів результат.

Погодьте критерії успіху до початку. Інакше результати доведеться сперечатися постфактум.

Приклад: відтворення з вигаданими числами

Цей приклад вигаданий, щоб показати, як читати відтворення. Це не виміряний результат.

Реальний тиждень планувальника мав 120 замовлень, з них 14 прострочених. Графік інструменту показує 9 прострочених замовлень. Постачальник на цьому й зупинився б і назвав це перемогою. Уважна команда дивиться на п'ять замовлень, які інструмент «врятував». Два з них спиралися на верстат, який насправді простоював більшу частину того тижня, а інструмент цього не знав, бо зупинки не було у вхідних даних. Одне спиралося на занадто оптимістичний час за маршрутом. Справжніх покращень було лише два. Чесний висновок такий: «інструмент, імовірно, кращий, а в наших даних є прогалина, яку варто закрити». Це корисний результат в будь-якому разі.

Чого потребує впровадження?

Переважно даних і відповідальних, а не програмного забезпечення.

• Чисті маршрути, норми часу виконання, часу переналагодження та календарі. Спочатку плануйте очищення даних і будуйте терміни проєкту з цих зусиль, а не зі слайда постачальника.
• Призначений відповідальний за майстер-дані та окремо за правила планування.
• Старт з однієї ділянки, часто тієї, що навколо вузького місця. Розширюйте, коли планувальники довіряють результату.
• Зворотний зв'язок із цеху: кількості розпочатого, завершеного і браку, а також зупинки. Без них графік за кілька днів розходиться з реальністю.
• Щотижневий огляд дотримання графіка в перші місяці. Power BI або будь-який інструмент звітності може показати заплановане порівняно з фактичним.

Типові помилки

• Купівля функцій замість відповідності. Довгий список модулів не допоможе, якщо ваша проблема полягає в одному вузькому місці.
• Пропуск перевірки ERP. Ваша ERP, можливо, вже частково покриває цю потребу.
• Довіра демо-даним. Демонстрація на зразковому заводі показує поведінку інструменту лише в сприятливому випадку.
• Ігнорування майстер-даних. Неправильні норми часу за маршрутами дають охайні, але хибні графіки.
• Вилучення планувальника з процесу. Планувальник має мати змогу втрутитися і бачити, чому система вирішила саме так.
• Неочевидна відповідальність між APS і MES. Два списки робіт дають дві різні правди.
• Очікування ідеального плану. Плани завжди відхиляються. Закладайте допуск і процедуру перепланування.

Де Polaris доречний

Якщо вам потрібен здійсненний план з обмеженнями, варто розглянути iFAKT Polaris. iFAKT описує Polaris як ШІ плюс цифровий двійник виробництва. Його модуль Polaris Optimizer перетворює граф знань «продукт – процес – ресурс» на виконуваний оптимізований виробничий план. Він спирається на оперативні дані ERP, доступність ресурсів і обмеження: зміни, зони, навички та потужності. Модуль виявляє вузькі місця, визначає пріоритети замовлень, аналізує вплив збоїв і перепланує. Чи підійде це вам, залежить від вашого процесу та даних, тож спершу перевірте за допомогою тесту відтворення, описаного вище, на вузькій ділянці.

Пов'язані теми для вивчення

• Планування на кількох майданчиках. Якщо заводи спільно використовують ресурси або замовлення, вирішіть, чи розклад веде одна команда, чи кожен майданчик веде власний.
• Високий асортимент і виробництво під замовлення. Унікальні маршрути та інженерні терміни змінюють вимоги до того, що інструмент планування має вміти.
• Сигнали попиту. Те, наскільки швидко замовлення клієнтів і зміни доходять до розкладу, визначає, як часто потрібно переплановувати.
• Планування і енергія. Деяким заводам потрібна вартість енергії як вхідний параметр планування. Перевірте, чи підтримує це інструмент, ще до того, як це стане важливим.

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

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