Як рахувати OEE лазерного верстата, якщо причини простою фіксуються неточно ART-146

Що OEE відповідає, а чого не відповідає

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

Він не відповідає сам по собі:

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

Високий OEE може супроводжуватися виробництвом зайвого WIP. Низький OEE може бути очікуваним для дільниці з дослідними або одиничними роботами. Тому цифру треба читати разом із планом, номенклатурою, чергою та якістю даних.

Формула з чіткими межами

Одна практична форма:

Доступність = фактичний час роботи / плановий виробничий час.

Продуктивність = нормативний час на фактичний випуск / фактичний час роботи.

Якість = придатний випуск / загальний випуск.

OEE = Доступність × Продуктивність × Якість.

Це не єдина можлива термінологія. ISO 22400-2 описує KPI через формули та їхні елементи, а NIST показує ієрархічні зв’язки між показниками. Важливіше не назва чисельника, а незмінність визначення.

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

Приклад без претензії на універсальну норму

Припустімо, для зміни визначено 420 хвилин планового виробничого часу. Достовірно встановлено 315 хвилин роботи. Нормативний час фактично виготовленого випуску — 270 хвилин. Із 100 облікових одиниць 96 підтверджено придатними.

• доступність: 315 / 420 = 0,75;
• продуктивність: 270 / 315 ≈ 0,857;
• якість: 96 / 100 = 0,96;
• OEE ≈ 0,75 × 0,857 × 0,96 ≈ 0,617, або 61,7%.

Цифра показує сумарний ефект трьох груп втрат у заданій моделі. Якщо з 105 хвилин неробочого часу 60 мають невідому причину, не можна заявляти, що головна проблема — матеріал або оператор. У звіті слід додати: «невідома причина — 57% часу зупинок». Це окремий показник якості даних.

Чому однаковий OEE може вимагати різних рішень

Уявімо дві зміни з OEE близько 60%. У першій доступність низька через довгі підтверджені очікування матеріалу, але під час роботи нормативний темп і якість стабільні. У другій машина майже весь плановий час працює, однак Performance слабкий, а причини відхилення CAM-часу не розділені. Однакова підсумкова цифра не робить ці ситуації однаковими.

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

Додайте до звіту коротку картку інтерпретації:

| Поле | Що показати | |---|---| | OEE | значення та період | | Складові | Availability, Performance/Effectiveness, Quality | | Знаменник | визначення планового виробничого часу й версія правила | | Покриття | частка часу, випуску й нормативів із валідними даними | | Найбільша підтверджена втрата | лише те, що доводять події | | Невідоме | некласифікований downtime та завдання без коректного зв’язку | | Наступна перевірка | власник, строк і потрібний доказ |

Така картка не перетворює OEE на діагноз. Вона змушує відокремити виміряну складову від припущення про причину.

Версія методики є частиною результату

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

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

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

Найважливіше рішення — плановий виробничий час

Знаменник визначає сенс OEE. Перед розрахунком письмово вирішіть:

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

Немає потреби доводити, що один варіант універсально правильний. Але не можна змінювати правила між змінами без позначки. Якщо керівник виключив відсутність замовлень із планового часу, OEE стає показником виконання під час запланованого виробництва, а не використання календарної потужності. Для планування інвестицій потрібен додатковий коефіцієнт завантаження.

Як визначити «час роботи» лазера

Сигнал живлення не підходить. Верстат може бути ввімкнений, але READY або WAIT. Тільки «beam on» теж надто вузький: корисний цикл містить необхідні переміщення, зміну палети та інші дії. MTConnect розділяє ACTIVE, READY, INTERRUPTED, WAIT, FEED_HOLD, STOPPED, PROGRAM_COMPLETED та причини очікування, зокрема завантаження й вивантаження. Це дає словник для зіставлення, але локальний стан контролера треба перевірити на реальній машині.

Практичний тест:

1. Візьміть одну типову зміну. 2. Порівняйте машинний журнал із фактичними подіями. 3. Для кожного стану визначте, чи входить він до run time. 4. Перевірте переходи: старт, пауза, завершення, очікування палети. 5. Задокументуйте mapping і версію.

Після оновлення ПЗ або інтеграції mapping перевіряють повторно. Інакше зміна OEE може бути наслідком іншої класифікації, а не покращення процесу.

Якщо причини простою неточні

Неточна причина не завжди руйнує компонент Availability. Якщо часовий інтервал зупинки достовірний, доступність можна обчислити. Але аналіз Парето причин буде слабким. Треба розділити два поля:

• машинний стан — автоматичний факт, наприклад WAIT або STOPPED;
• операційна причина — матеріал, програма, розбір, контроль, несправність, планова дія тощо.

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

Який довідник причин працює

Початковий список може бути коротким:

1. немає готового матеріалу; 2. немає підтвердженої програми/завдання; 3. налаштування або перша деталь; 4. розбір/вивантаження не завершено; 5. контроль якості або очікування рішення; 6. планове обслуговування; 7. непланова технічна зупинка; 8. інфраструктура — газ, електрика, мережа, витяжка; 9. організаційна пауза; 10. невідомо / потребує уточнення.

Категорія «невідомо» необхідна. Заборона на неї породжує вигадані точні відповіді. Але вона має запускати review, якщо перевищує погоджений внутрішній поріг.

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

Як рахувати Performance, якщо CAM-час неточний

Компонент продуктивності може стати головним джерелом помилки. Якщо нормативний цикл взято з CAM, спочатку перевірте його план/факт за стабільними групами робіт. ART-142 присвячений цій перевірці окремо.

До стабілізації нормативу:

• показуйте Performance як попередній;
• не використовуйте його для преміювання;
• не обрізайте значення понад 100% мовчки;
• аналізуйте відхилення за матеріалом, товщиною, версією постпроцесора й типом геометрії;
• зберігайте версію оцінки;
• не порівнюйте тренд через зміну методики без перерахунку.

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

Як рахувати Quality

Якість має базуватися на підтвердженому результаті. Якщо деталі ще лежать у скелеті й не ідентифіковані, їх не варто автоматично вважати придатними. Визначте момент, коли одиниця входить до total count і коли отримує статус good.

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

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

Додайте Data Confidence Score

Це не стандартизована складова OEE, а локальний контроль довіри. Її не треба множити на OEE. Показуйте поруч кілька простих часток:

• покриття машинним журналом;
• частка downtime з класифікованою причиною;
• частка випуску з підтвердженим good/total;
• частка завдань із валідним нормативним часом;
• частка подій, пов’язаних із правильним ID замовлення.

Наприклад: OEE 61,7%; причини підтверджено для 43% downtime; якість підтверджена для 100% випуску; норматив покриває 82% робіт. Такий запис набагато чесніший за одну зелену цифру.

Відновлення історії, якщо журналу немає

Не варто заднім числом вигадувати точні коди. Можна:

1. зібрати контролерні стани й часові мітки; 2. зіставити їх зі змінними рапортами, заявками сервісу, CAM-файлами та рухом матеріалу; 3. позначити підтверджені, ймовірні й невідомі інтервали; 4. порахувати OEE лише там, де достатньо основних елементів; 5. не використовувати реконструйоване Парето як точний факт.

Реконструкція корисна для стартової оцінки, але майбутній процес треба будувати на подіях, а не на постійному ручному відновленні.

План поліпшення даних на чотири тижні

Тиждень 1: визначити календар і mapping станів, перевірити дві зміни вручну.

Тиждень 2: запровадити короткі причини верхнього рівня, виміряти частку «невідомо».

Тиждень 3: пов’язати завдання, програму, лист і good/total; перевірити межі циклу.

Тиждень 4: провести review найбільших невідомих інтервалів, уточнити довідник і зафіксувати версію методики.

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

Як читати OEE на лазерній дільниці

Завжди розкривайте три складові. Однакові 60% можуть означати:

• низьку доступність при хорошому темпі й якості;
• стабільну роботу з хибним нормативом;
• багато повторного різання;
• комбінацію малих втрат.

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

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

• рахувати від 24 календарних годин, хоча виробництво планується одну зміну;
• виключати неприємні зупинки зі знаменника після факту;
• прирівнювати powered до running;
• брати CAM-час без перевірки;
• рахувати вирізані деталі як good до контролю;
• приховувати «невідомо»;
• порівнювати різні методики в одному тренді;
• оцінювати людину за OEE;
• купувати автоматизацію лише через низьку загальну цифру;
• не зберігати версію формули й mapping.

Чекліст

• [ ] Плановий виробничий час визначено до розрахунку.
• [ ] Усі виключення описані.
• [ ] Run time перевірено на часовій шкалі.
• [ ] Нормативний час має версію й оцінку точності.
• [ ] Good і total мають однозначні події.
• [ ] OEE показано разом зі складовими.
• [ ] Невідомі причини не розподілені припущенням.
• [ ] Є показники покриття даними.
• [ ] Зміна методики створює нову версію.
• [ ] OEE не замінює аналіз потоку, черги та економіки.
• [ ] Висновок не містить неперевіреної технічної причини.
• [ ] Дії спрямовані на найбільшу підтверджену втрату.

Висновок

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

Безпечні межі

• Приклад чисел ілюстративний, не цільова норма.
• Стаття не встановлює технічну причину простою.
• Не використовується для оцінювання персоналу без контексту.
• Не замінює аудит контролера, MES/ERP та локальні правила.
• Relations без URL; статус DRAFT.

Потрібна допомога з вибором обладнання