Яким вимогам має відповідати графік і як його оцінити

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

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

Почніть з обмежень, бо програма цікава рівно настільки, наскільки вона здатна їх описати. Верстат виконує одне завдання за раз, а час переходу від завдання, яке він виконує, до наступного зазвичай залежить від того, які саме це два завдання. Перехід зі світлого кольору в темний потребує протирання, з темного у світлий вимагає промивання та очищення. Це і є переналагодження, залежне від послідовності: час переналагодження є властивістю пари операцій на конкретному ресурсі, бо та сама зміна кольору обходиться по-різному на великому й на малому пресі, а на деяких лініях залежить ще й від стану обладнання. Саме цього обмеження найчастіше бракує в обліковій системі. Тому план із 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) і підтверджень належить до тієї самої роботи.

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