Спочатку визначте рішення, а потім метрику
Показник корисний не тому, що його легко зняти з контролера. Він корисний, якщо після зміни значення зрозуміло, хто й яке рішення має перевірити. Для кожної метрики варто записати:
1. бізнесове або виробниче запитання; 2. власника рішення; 3. джерело даних; 4. період і рівень агрегації; 5. формулу та одиницю; 6. допустимі виключення; 7. дію при відхиленні; 8. обмеження достовірності.
ISO 22400-2 описує KPI виробничих операцій через формули, елементи, часову поведінку, одиниці й групи користувачів. Це важливий принцип: назва «продуктивність» без формули й адресата не є керованим KPI. ISA-95, також відомий як IEC 62264, розділяє рівні бізнесових і виробничих операцій та дає спільну модель обміну. Практично це означає, що замовлення з ERP, виконання на дільниці та сигнали верстата треба пов’язувати, але не ототожнювати.
Три горизонти управління
Оперативний горизонт — хвилини та години. Тут важливо побачити, що верстат чекає лист, програма зупинилася або накопичилася розкладка на розбір. Дані мають бути свіжими, але не обов’язково фінансово повними.
Технологічний горизонт — замовлення, матеріальна партія, програма, повторювана деталь або тиждень. Тут порівнюють розрахунковий і фактичний час, якість, стабільність режимів, причини перезапусків і повторних проб.
Управлінський горизонт — тиждень, місяць, портфель замовлень. Керівник оцінює виконання плану, завантаження, структуру втрат, чергу, своєчасність, витрати та потребу в зміні процесу або потужності.
Одна й та сама подія має різний сенс. Десять хвилин очікування металу — оперативний сигнал оператору або логістиці; повторення щозміни — процесна проблема для керівника; зв’язок лише з певним форматом листа — предмет аналізу технолога.
Мінімальний набір для оператора
Операторський екран повинен відповідати на запитання «що відбувається зараз і що має бути далі». Корисний мінімум:
| Показник/сигнал | Навіщо | Умова коректності | |---|---|---| | стан завдання | бачити активне, завершене, призупинене | стани мають однозначні визначення | | причина очікування | відрізнити матеріал, програму, газ, розбір, несправність | короткий довідник причин і можливість уточнення | | виконано деталей/листів проти завдання | контролювати залишок | підтверджене завершення, а не лише старт програми | | фактичний цикл проти очікуваного | помітити відхилення | порівнюються однакові межі циклу | | кількість повторних стартів/переривань | виявити нестабільність | автоматичні й ручні події розрізнені | | невідповідні деталі, що очікують рішення | не змішати їх із придатними | є простий статус і фізичне маркування | | наступна підготовча дія | зменшити паузу між завданнями | черга узгоджена з планом |
MTConnect визначає різні стани виконання, зокрема ACTIVE, READY, INTERRUPTED, WAIT і STOPPED, та окремі стани очікування матеріалу або вивантаження. Ця деталізація показує, чому одного сигналу «верстат увімкнений» недостатньо. Але локальний дашборд не зобов’язаний копіювати весь стандарт: він має мати однозначне зіставлення між машинним станом і зрозумілою операційною причиною.
Оператор не повинен вводити довгий звіт у момент зупинки. Якщо список має п’ятдесят причин, найчастіше обиратимуть «інше». NIST на прикладі виробничих записів показує, що вільні описи, різні скорочення й надмірні списки кодів погіршують аналіз. Практичний компроміс — 8–12 верхніх категорій, коротке уточнення та можливість пізнішої класифікації технологом або майстром. Діапазон 8–12 є стартовою редакційною рекомендацією L-SEL, а не вимогою ISO, ISA, MTConnect або NIST: фактичну кількість категорій треба перевірити на локальних подіях.
Мінімальний набір для технолога
Технологові потрібні не загальні години роботи, а контекст результату:
- ID програми, розкладки та версії режиму;
- верстат і конфігурація;
- матеріал, товщина, партія та стан поверхні;
- розрахунковий і фактичний цикл в однакових межах;
- кількість проколів, довжина/структура контуру або інший релевантний драйвер;
- переривання за категоріями;
- перша придатна деталь і повторні проби;
- результат контролю якості;
- ручні корекції режиму;
- фактичний вихід деталей з листа;
- коментар про нетипову геометрію чи вимогу.
Головне питання технолога: «чому однакове на вигляд завдання дало інший результат?» Відповідь неможлива без версій. Якщо в записі є лише назва файлу, а режим у CAM був змінений без журналу, графік циклу не дає причинного висновку.
Окремо варто вести точність прогнозу CAM: медіану й розподіл відхилень за сімействами робіт, а не один середній відсоток. Це межує з ART-142, де методика план/факт розглядається глибше. У ART-145 цей показник потрібен лише як один із сигналів для ролі технолога.
Мінімальний набір для керівника дільниці
Керівникові потрібна компактна панель:
1. виконання плану в придатних деталях або завершених замовленнях; 2. своєчасність завершення; 3. фактична пропускна здатність за релевантною групою робіт; 4. плановий час, продуктивний час і втрати за головними категоріями; 5. черга до лазера й черга після нього; 6. частка повторного різання та невідповідностей; 7. відхилення фактичного часу від оцінки; 8. матеріальний вихід і вартість відходу, якщо дані підтверджені; 9. обсяг незавершеного виробництва; 10. показник достовірності даних.
Останній пункт часто пропускають. Якщо для 35% зупинок причина невідома, красивий розподіл решти 65% не можна подавати як повну картину. На дашборді має бути видно частку некласифікованого часу, відсутніх підтверджень якості й замовлень без коректного зв’язку з програмою.
Керівник не повинен оцінювати оператора лише за лазерним «часом різання». Висока частка активного променя може супроводжуватися зайвим WIP, затримкою сортування, повторним різанням або виробництвом не того пріоритету. KPI має підтримувати загальний потік, а не локальну максимізацію однієї машини.
Які показники спільні для всіх
Є невеликий спільний шар:
- факт виконання завдання;
- поточний стан і головна причина відхилення;
- кількість придатних і непридатних деталей;
- версія програми/режиму;
- час останнього оновлення;
- якість даних.
Відрізняється деталізація. Оператор бачить поточну подію, технолог — історію конкретної програми, керівник — агреговані втрати й тренд. Спільне визначення запобігає ситуації, коли «простій» на трьох екранах означає три різні речі.
Приклад рольової картки одного показника
Припустімо, дільниця хоче контролювати час від завершення програми до звільнення палети. Не потрібно одразу виводити один графік усім ролям. Спершу формується картка показника:
| Поле | Робоче визначення | |---|---| | Питання | чи затримує розбір наступний виробничий цикл | | Початкова подія | підтверджений `PROGRAM_COMPLETED` або локально валідований еквівалент | | Кінцева подія | палета підтверджено готова прийняти наступний лист | | Одиниця | хвилини на розкладку | | Власник визначення | керівник дільниці разом із технологом/аналітиком | | Якість даних | частка розкладок, де обидві події мають валідний час та ID | | Винятки | тестові програми, навчання й інші погоджені категорії, показані окремо |
Для оператора це не місячний KPI, а поточний сигнал: палета ще зайнята, причина обрана, наступна дія зрозуміла. Для технолога — розподіл часу за розкладками, кількістю деталей, товщиною, форматом та версією програми. Для керівника — частка планового часу, втрачена через блокування, черга після різання та вплив на своєчасність готових комплектів.
Якщо машинна подія завершення є для 100% програм, а подію звільнення палети підтверджено лише для частини розкладок, дашборд не повинен заповнювати пропуски нулем. Він показує значення лише для покритих випадків і поруч — coverage. Інакше поліпшення «середнього часу» може означати лише те, що складні випадки перестали реєструватися.
Після двох-трьох тижнів пілота команда перевіряє три речі: чи однаково люди розуміють початок і кінець, чи показник приводить до конкретної дії та чи не створює він небажаної поведінки. Наприклад, прискорення звільнення палети не повинно мотивувати змішувати неідентифіковані деталі. Якщо рішення немає або показник дублює інший, картку переглядають, а не додають ще один віджет.
Час: найчастіше джерело помилок
До запуску аналітики визначте часові межі:
- календарний час;
- час зміни;
- плановий виробничий час;
- час, коли завдання доступне;
- час виконання програми;
- час фактичного різання;
- допоміжний машинний час;
- очікування оператора, матеріалу, програми чи розбору;
- планове обслуговування;
- непланова зупинка.
Не всі підприємства мусять використовувати однакову класифікацію, але всередині одного звіту вона має бути стабільною. Якщо обід або відсутність замовлення одного місяця виключаються з планового часу, а іншого включаються, тренд втрачає зміст.
Для лазерної дільниці також важливо не прирівнювати «програма активна» до створення придатної продукції. Програма може виконувати холості переміщення, чекати, перезапускатися або завершити лист із деталями, які ще не пройшли відокремлення й контроль.
Якість: рахувати не лише брак
Простий показник браку потрібен, але без категорій мало корисний. Доцільно розділити:
- повторне різання через технологічний результат;
- втрата через помилку в геометрії або ревізії;
- пошкодження під час знімання/сортування;
- неправильний матеріал;
- дефект, виявлений у наступній операції;
- деталь на утриманні до рішення.
Кількість дефектів треба пов’язати з базою: деталі, листи, замовлення або вартість. «Три дефекти» на трьох великих індивідуальних деталях і на десяти тисячах серійних заготовок — різні ситуації.
Не всі косметичні ознаки є браком, і не кожна вирізана деталь є прийнятою. Критерії задає креслення, технічна вимога, маршрут контролю або погоджений стандарт підприємства.
Потік після різання
Високошвидкісний лазер здатен перенести обмеження на розбір і сортування. Тому керівник має бачити:
- час від завершення листа до звільнення палети;
- кількість листів/розкладок, що очікують розбору;
- час до комплектування замовлення;
- частку деталей без однозначної ідентифікації;
- пошкодження або втрати після різання;
- готовність наступної операції прийняти комплект.
ART-147 детально розглядає ручне сортування як обмеження, а ART-148 — можливості автоматичного вивантаження. Тут важлива лише управлінська теза: межа дільниці проходить не по корпусу верстата, а від доступності матеріалу до передачі придатного комплекту далі.
Як будувати дашборд поетапно
Етап 1 — словник. Визначте 10–15 подій і полів. Проведіть тест на одній зміні: чи двоє людей однаково класифікують подію.
Етап 2 — зв’язок сутностей. Замовлення, програма, лист, матеріал, верстат, операторська зміна й результат повинні мати ID. Без цього аналітика буде збиратися за назвами файлів.
Етап 3 — базова якість даних. Показуйте невідомі інтервали й пропуски. Не виправляйте їх припущенням.
Етап 4 — рольові екрани. Оператор — сьогодні й зараз; технолог — порівняння контекстів; керівник — потік, втрати та тренд.
Етап 5 — регулярний review. Щотижня перевіряйте не лише значення, а й те, чи привела метрика до рішення. Показник, який ніхто не використовує, прибирають або змінюють.
Антипатерни
Перший — рейтинг операторів за виробленими годинами без урахування номенклатури. Він мотивує уникати складних завдань.
Другий — одна OEE-цифра без складових і якості даних. Причина сховається за добутком.
Третій — порівняння різних верстатів без нормалізації за роботою. Машина на тонкій серії й машина на товстих одиничних деталях виконують різні задачі.
Четвертий — ручне заповнення того, що вже достовірно дає контролер, і автоматичне «вгадування» того, що знає лише людина. Краще поєднати машинний час із короткою людською причиною.
П’ятий — фінансові висновки лише з машинного часу. Собівартість потребує матеріалу, газу, праці, підготовки, відходу, браку й накладних правил.
Чекліст перед запуском KPI
- [ ] Для кожного показника є питання й власник рішення.
- [ ] Формула, одиниця, часові межі та виключення описані.
- [ ] Машинний стан не видається за бізнесовий результат.
- [ ] Видно частку невідомих або неповних даних.
- [ ] Операторський екран містить тільки дієві сигнали зміни.
- [ ] Технолог може знайти версію програми, режиму й матеріалу.
- [ ] Керівник бачить чергу до та після лазера.
- [ ] Якість рахується за підтвердженим результатом.
- [ ] Немає порівняння людей або машин без контексту.
- [ ] Цільові значення встановлюються з власної базової лінії.
- [ ] KPI переглядаються після зміни процесу.
- [ ] Дані не використовуються для покарання за коректну реєстрацію проблеми.
Висновок
Почніть із трьох різних відповідей, а не з одного великого екрана. Оператор має знати, що робити зараз. Технолог — чому результат відрізняється й яку версію перевіряти. Керівник — де втрачається потік, чи виконується план і наскільки даним можна довіряти. Після цього 8–12 добре визначених показників дадуть більше користі, ніж сотня автоматично зібраних тегів.
Безпечні межі
- Цільові відсотки не встановлюються без локальної базової лінії.
- Метрики не є автоматичною оцінкою працівника.
- Стаття не стверджує готовність інтеграції з ERP, CAM або контролером.
- OEE згадано як контекст; повна методика належить ART-146.
- Relations є редакційними ART, а не URL.
Потрібна допомога з вибором обладнання
Опишіть матеріали, деталі та виробниче завдання — фахівець L-SEL допоможе визначити наступний крок без прив’язки до випадкової характеристики.
Підібрати обладнання під завдання