Розширене планування та диспетчеризація: яким вимогам має відповідати графік

Тут припускається, що ви знаєте свій процес і ніколи не купували систему планування.

Обмеження виробничого графіка, яким має відповідати реальна лінія

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

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

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

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

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

Чому розгортання MRP дає дати, у які ніхто не вкладається

MRP робить справді корисну роботу, і це не диспетчеризація. Воно розгортає попит через специфікації (BOM), сальдує із запасами та відкритими замовленнями, зсуває на фіксовану тривалість циклу по кожній позиції й каже вам, що виготовити чи закупити і приблизно коли починати. Щоб робити це по тисячах позицій, воно припускає, що потужність доступна тоді, коли цього вимагає арифметика.

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

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

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

Що змінює диспетчеризація з обмеженою потужністю

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

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

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

Планування, диспетчеризація та видача завдань — це три різні роботи

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

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

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

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

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

Механізм планування — це розрахунок над вашими основними даними. Якщо дані декоративні, то й результат декоративний і впевнений у собі.

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

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

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

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

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

Як оцінювати графік

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

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

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

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

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

Політика перепланування та нервовість графіка

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

Робочий шаблон — заморожений горизонт плюс політика. Усередині вікна послідовність не змінюється, крім справжніх перешкод, тож уже початі переналагодження не пропадають; за його межами переоптимізація дозволена. Емпіричне правило: перепланувати не частіше, ніж триває заморожене вікно, а саме вікно задавати з двох речей, які можна спостерігати на ділянці: скільки триває переналагодження і як часто трапляється справжня перешкода. Механічна дільниця з годинними завданнями та конфліктом оснастки майже щодня заморозить кілька годин і переплановуватиме щозміни; процесне виробництво з тижневими кампаніями заморозить дні. У будь-якому разі планові перерахунки доповнюються подієвими — на поломку верстата, непоставку чи термінове замовлення.

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

Де APS стоїть поруч з ERP і MES і хто що вирішує

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

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

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

Як провести перевірку, яка щось вам скаже

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

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

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

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

Де тут Meta Smart Factory

Модулі APS і MRP у Meta Smart Factory роблять ту частину, що стосується обмеженої потужності, на моделі обмежень, яка охоплює залежні від послідовності переналагодження, спільну оснастку, кваліфікацію операторів і змінні календарі по ділянках, зі сценарними розрахунками для згаданих вище збурень. Оскільки вони живуть на тій самій платформі, що й модуль MES, між виконанням і планувальником немає нічного файлового обміну, тож стан цеху настільки свіжий, наскільки це дозволяють ваші точки підтвердження та дисципліна звітування ваших операторів. Це умова, а не дрібниця: якщо половину підтверджень вносять на перерві, а ручна операція складання не має точки сканування, архітектура вас не врятує. Рішення про те, де ці точки стоять, — це робота з впровадження, а не її побічний продукт. Стик з ERP для замовлень, специфікацій (BOM) і підтверджень — частина тієї самої роботи.

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