Mengapa AI Tidak Bisa Mengoptimalkan Pabrik yang Tidak Dipahaminya

Sebuah mesin berhenti di tengah produksi. ERP mengetahui pesanan pelanggan dan tanggal jatuh temponya, MES mengetahui operasi mana yang terhenti, pemeliharaan mengetahui status perbaikan, dan lapisan mesin mengetahui kode kesalahan serta cap waktu yang tepat. Kemudian seseorang mengajukan pertanyaan yang jelas: apa yang harus kita lakukan sekarang?

AI dapat merangkum alarm, menemukan pola dari riwayat downtime, dan menjelaskan kemungkinan penyebabnya. Namun kecuali AI juga memahami produk apa yang sedang berjalan, pesanan mana yang bergantung pada operasi tersebut, mesin mana yang merupakan alternatif yang disetujui, alat apa yang tersedia, operator mana yang memenuhi kualifikasi, dan aturan kualitas atau proses mana yang berlaku, AI tidak dapat mengoptimalkan respons secara aman.
Ini bukan terutama masalah AI. Ini adalah masalah konteks pabrik.

DATA BUKANLAH KONTEKS
Pabrik sudah menghasilkan data dalam jumlah besar. ERP, MES, pemeliharaan, kualitas, historian, PLC, platform IoT, dan spreadsheet semuanya menyimpan fakta yang berguna.
Masalahnya, fakta-fakta tersebut sering tetap terpisah.Kode henti mesin saja tidak memberi tahu apakah kejadian itu terjadi selama produksi, pergantian produk, pemeliharaan, atau dalam batch dengan jendela pemrosesan yang ketat. Sebuah mesin dapat tampak menganggur namun tetap tidak dapat digunakan karena fixture yang dibutuhkan tidak tersedia atau operator yang berkualifikasi tidak bertugas pada shift tersebut.
Konteks menghubungkan kejadian dengan situasi operasional di sekitarnya.

Itu mencakup:

• Identitas aset dan sumber daya
• Operasi dan perintah kerja yang aktif
• Produk dan revisinya
• Rute dan rute alternatif
• Status material dan batch
• Perkakas dan fixture
• Keterampilan dan cakupan shift
• Pembatasan kualitas
• Status pemeliharaan
• Kapasitas dan ketergantungan hilir
• Komitmen pelanggan

MENGAPA DASHBOARD SAJA TIDAK CUKUP
Power BI dan dashboard operasional sangat baik untuk menunjukkan apa yang berubah. Keduanya dapat memperlihatkan downtime, antrean yang membesar, pesanan yang terlambat, scrap, atau kapasitas yang tersedia.

Namun menampilkan masalah berbeda dengan memutuskan apa yang harus dilakukan produksi selanjutnya.
Sebuah dashboard mungkin menunjukkan bahwa mesin lain tersedia. Dashboard tidak secara otomatis mengetahui apakah mesin itu disetujui untuk revisi produk saat ini, apakah fixture sudah dicadangkan, apakah kualitas harus menyetujui pemindahan, atau apakah memindahkan pekerjaan menciptakan bottleneck baru di hilir.

Ketika laporan mulai berisi puluhan perhitungan kasus khusus dan perencana masih mengekspor hasilnya ke Excel untuk menguji alternatif, bagian yang hilang biasanya bukan visualisasi tambahan. Yang dibutuhkan adalah model eksplisit dari aturan pabrik di balik keputusan tersebut.

PREDIKSI BUKANLAH OPTIMISASI
Prediksi dapat memberi tahu Anda bahwa sebuah mesin kemungkinan akan gagal atau bahwa suatu pesanan memiliki probabilitas tinggi untuk terlambat.
Itu berguna, tetapi tidak memberi tahu apa yang harus dilakukan.
Optimisasi memiliki tugas yang berbeda. Optimisasi mengevaluasi kemungkinan tindakan terhadap aturan dan batasan pabrik.

Misalnya, setelah kegagalan mesin, sebuah optimizer dapat menguji apakah pekerjaan yang terdampak dapat tetap berada di sumber daya awal, dipindahkan ke mesin alternatif yang disetujui, diubah urutannya, atau menggunakan lembur.
Rencana yang layak harus menghormati kondisi nyata.
Batas keselamatan, persetujuan proses, kompatibilitas material, sertifikasi operator, perkakas, pembatasan kualitas, jendela pemeliharaan, dan aturan urutan tidak dapat begitu saja diabaikan hanya karena mesin lain tampak kosong.

AI, OPTIMISASI, DAN ATURAN MEMILIKI TUGAS YANG BERBEDA
Generative AI dapat membantu perencana memahami situasi, mencari informasi yang terhubung, membandingkan alternatif, menjelaskan trade-off, dan membuat serah terima yang berguna.
Model prediktif dapat memperkirakan risiko.
Mesin optimisasi dapat mencari jadwal yang layak.
Aturan deterministik dapat memverifikasi bahwa suatu tindakan yang diusulkan menghormati kondisi produksi yang diketahui.
Komponen-komponen ini dapat bekerja bersama, tetapi tidak boleh dikacaukan satu sama lain.
Sebuah language model dapat menghasilkan penjelasan yang meyakinkan. Itu tidak membuktikan bahwa sebuah rencana produksi dapat dieksekusi.

PRODUK, PROSES, SUMBER DAYA
Model pabrik yang berguna dimulai dengan Product, Process, dan Resource.
Product mendeskripsikan apa yang diproduksi, termasuk revisi, material, aturan batch, dan persyaratan spesifik pelanggan.

Process mendeskripsikan operasi, urutan, kondisi setup, inspeksi, jalur alternatif, dan aturan yang diperlukan untuk memproduksinya.

Resource mendeskripsikan apa yang dapat melakukan pekerjaan tersebut. Sumber daya dapat berupa mesin, alat, fixture, tungku, stasiun uji, perangkat transportasi, atau orang.
Bagian yang penting adalah hubungan di antara keduanya.

Pertanyaannya bukan:
“Mesin mana yang kosong?”

Pertanyaan yang berguna adalah:
“Sumber daya mana yang tersedia dan dapat melakukan operasi berikutnya yang dibutuhkan untuk produk dan pesanan yang tepat ini, sesuai dengan proses, perkakas, material, kualitas, staf, dan kondisi waktu yang telah disetujui?”

GRAF PENGETAHUAN TANPA HYPE
Graf pengetahuan menyediakan satu cara untuk merepresentasikan hubungan pabrik yang saling terkait tersebut.
Alih-alih menyimpan mesin, operasi, pesanan, alat, dan material sebagai catatan yang terisolasi, graf juga merepresentasikan hubungan di antara mereka.

Sebuah mesin dapat melakukan suatu operasi. Operasi tersebut termasuk dalam sebuah rute. Rute tersebut termasuk dalam revisi produk. Sebuah perintah kerja membutuhkan rute tersebut. Sebuah fixture mungkin dibutuhkan untuk operasi tersebut. Fixture tersebut mungkin saat ini sudah dialokasikan untuk pekerjaan lain.

Hal ini membuat pertanyaan seperti “mengapa pesanan ini tidak dapat dipindahkan ke Mesin 7?” jauh lebih mudah dijelaskan.
Jawabannya seharusnya tidak sekadar “tidak layak.”

Jawabannya harus menjelaskan bahwa Mesin 7 mendukung operasi tersebut tetapi fixture yang dibutuhkan tidak tersedia, revisi produk belum disetujui, atau kondisi kualitas hilir memblokir rute tersebut.

DIGITAL TWIN MEMBUTUHKAN TUJUAN
Dashboard live secara otomatis bukanlah digital twin.
Digital twin yang berguna merepresentasikan bagian operasi fisik yang terdefinisi dan menghubungkan struktur, status, aturan, dan data sumber di sekitar tujuan tertentu.

Twin aset dapat mendukung keputusan pemeliharaan.
Twin lini dapat membantu memahami aliran dan bottleneck.
Twin sistem produksi dapat menghubungkan status peralatan dengan pesanan, rute, material, orang, aturan kualitas, dan komitmen pengiriman.

Pertanyaan yang penting bukanlah “apakah kita memiliki digital twin?”
Melainkan “pengguna, keputusan, dan jendela waktu mana yang didukung oleh twin ini?”

IDENTITAS ASET ADALAH FONDASI
Satu mesin fisik dapat memiliki beberapa identitas.
Pemeliharaan mungkin menggunakan nomor aset. MES menggunakan sumber daya produksi. ERP menggunakan work center. Lapisan IoT melihat controller atau path tag.

Pengenal tersebut tidak perlu dihilangkan, tetapi hubungan di antara mereka harus diatur dengan baik.
Jika sebuah sistem AI menebak bahwa dua nama mesin yang mirip merepresentasikan aset fisik yang sama, setiap keputusan berikutnya bisa keliru meskipun data yang mendasarinya secara teknis bersih.

Pemetaan aset oleh karena itu membutuhkan kepemilikan, tanggal efektif, referensi sumber, dan manajemen perubahan.

BATASAN ADALAH BAGIAN DARI DATA
Sebuah rute mungkin secara teknis memungkinkan namun tidak dapat diterima untuk produksi.

Batasan keras dapat mencakup:
• Batas keselamatan
• Resep yang disetujui
• Kompatibilitas material
• Kapabilitas mesin
• Sertifikasi operator
• Rilis kualitas
• Ketersediaan alat
• Pembatasan pemeliharaan

Batasan lain merepresentasikan trade-off dan bukan batas mutlak. Pergantian produk tambahan mungkin dapat diterima untuk melindungi pengiriman yang mendesak. Lembur mungkin diizinkan untuk satu komitmen pelanggan tetapi tidak untuk yang lain.

Sistem sebaiknya menampilkan trade-off tersebut alih-alih menyembunyikannya di dalam rekomendasi yang tidak transparan.

DATA BERSIH ITU PERLU — TETAPI TIDAK CUKUP
Cap waktu yang akurat, kejadian yang lengkap, pengenal yang distandarisasi, dan antarmuka yang andal sangat penting.

Namun tabel yang sangat bersih pun tidak menjelaskan arti “tersedia,” “lengkap,” atau “kapasitas.”
Sebuah mesin mungkin tersedia secara mekanis tetapi tidak tersedia untuk operasi saat ini. P