Чому AI не може оптимізувати фабрику, яку він не розуміє

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

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

ДАНІ НЕ ТОТОЖНІ КОНТЕКСТУ
Фабрики вже генерують величезні обсяги даних. ERP, MES, обслуговування, якість, історіани, PLC, IoT-платформи та електронні таблиці містять корисні факти.
Проблема в тому, що ці факти часто залишаються розрізненими. Сам по собі код зупинки машини не говорить, чи сталася подія під час виробництва, переналагодження, обслуговування або в партії з жорстким вікном обробки. Машина може здаватися простою, але бути непридатною до роботи, бо потрібний пристрій затиску недоступний або кваліфікований оператор не на зміні.
Контекст пов'язує подію з оперативною ситуацією навколо неї.

Сюди входять:

• Ідентичність активу та ресурсу
• Активна операція і робоче замовлення
• Продукт і його ревізія
• Маршрут і альтернативні маршрути
• Статус матеріалу та партії
• Інструмент і пристрої затиску
• Навички та покриття змін
• Обмеження якості
• Статус обслуговування
• Потужність і залежності на наступних етапах
• Зобов'язання перед клієнтами

ЧОМУ ПАНЕЛЕЙ ПОКАЗНИКІВ НЕДОСТАТНЬО
Power BI та операційні панелі чудово показують, що змінилося. Вони можуть виявити простої, зростання черг, запізнені замовлення, брак або доступні потужності.

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

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

ПРОГНОЗ — НЕ ОПТИМІЗАЦІЯ
Прогноз може підказати, що машина ймовірно вийде з ладу або що замовлення з високою ймовірністю запізниться.
Це корисно, але не говорить, що робити.
Оптимізація має іншу задачу. Вона оцінює можливі дії відповідно до правил і обмежень фабрики.

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

ШІ, ОПТИМІЗАЦІЯ ТА ПРАВИЛА МАЮТЬ РІЗНІ ЗАВДАННЯ
Генеративний ШІ може допомогти плановикам зрозуміти ситуацію, знайти пов'язану інформацію, порівняти альтернативи, пояснити компроміси і підготувати корисну передачу зміни.
Прогнозні моделі оцінюють ризик.
Оптимізаційні рушії шукають здійсненні графіки.
Детерміновані правила перевіряють, що запропонована дія відповідає відомим виробничим умовам.
Ці компоненти можуть працювати разом, але їх не слід плутати.
Мовна модель може створити переконливе пояснення. Це не доводить, що виробничий план можна виконати.

ПРОДУКТ, ПРОЦЕС, РЕСУРС
Корисна модель фабрики починається з Продукту, Процесу і Ресурсу.
Продукт описує, що виготовляється, включно з ревізією, матеріалом, правилами партій і вимогами конкретного клієнта.

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

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

Питання не таке:
«Яка машина вільна?»

Корисне питання таке:
«Який доступний ресурс може виконати наступну необхідну операцію для цього конкретного продукту і замовлення за затвердженого процесу, інструмента, матеріалу, якості, укомплектування персоналом і часових умов?»

ГРАФИ ЗНАНЬ БЕЗ ЗАЙВОГО ХАЙПУ
Граф знань — один зі способів представити ці пов'язані виробничі відносини.
Замість того щоб зберігати машини, операції, замовлення, інструменти і матеріали як ізольовані записи, граф також відображає зв'язки між ними.

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

Це значно спрощує пояснення на кшталт «чому це замовлення не можна перевести на Машину 7?».
Відповідь не повинна просто казати «неможливо».

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

ЦИФРОВІЙ ДВІЙНИК ПОТРЕБУЄ ПРИЗНАЧЕННЯ
Жива панель показників автоматично не є цифровим двійником.
Корисний двійник відображає визначену частину фізичної операції і пов'язує структуру, стан, правила та вихідні дані навколо конкретної мети.

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

Важливе питання не «чи є у нас цифровий двійник?»
А «який користувач, яке рішення і який часовий horizon підтримує цей двійник?»

ІДЕНТИЧНІСТЬ АКТИВУ — ОСНОВА
Одна фізична машина може мати кілька ідентичностей.
Обслуговування може використовувати номер активу. MES використовує виробничий ресурс. ERP — робочий центр. IoT-рівень бачить шлях контролера або тега.

Ці ідентифікатори не обов'язково мають зникнути, але їхні зв'язки мають керуватися.
Якщо ШІ-система вгадує, що дві схожі назви машин позначають один фізичний актив, кожне подальше рішення може бути хибним, навіть якщо базові дані технічно чисті.

Тому відповідності активів потребують власника, дат дії, посилань на джерела і управління змінами.

ОБМЕЖЕННЯ — ЧАСТИНА ДАНИХ
Маршрут може бути технічно можливим і водночас неприйнятним для виробництва.

Жорсткі обмеження можуть включати:
• Граничні значення безпеки
• Затверджені рецептури
• Сумісність матеріалів
• Можливості машини
• Кваліфікацію операторів
• Випуск з якості
• Наявність інструменту
• Обмеження обслуговування

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

Система має відкривати ці компроміси, а не приховувати їх усередині непрозорої рекомендації.

ЧИСТІ ДАНІ НЕОБХІДНІ, АЛЕ НЕДОСТАТНІ
Точні позначки часу, повні події, стандартизовані ідентифікатори і надійні інтерфейси є обов'язковими.

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