ஒரு factory-ஐ AI புரிந்துகொள்ளாமல் ஏன் optimize செய்ய முடியாது

ยंत्रम् उत्पादन के बीच में रुक जाता है। ERP को ग्राहक ऑर्डर और देय तिथियाँ पता हैं, MES को पता है कि कौन-सा ऑपरेशन रुका, रखरखाव विभाग को मरम्मत की स्थिति पता है, और मशीन स्तर को सटीक फ़ॉल्ट कोड और सटीक टाइमस्टैम्प पता है। फिर कोई स्वाभाविक प्रश्न पूछता है: अब हमें क्या करना चाहिए?

AI अलार्म का सारांश बना सकता है, ऐतिहासिक डाउनटाइम में पैटर्न खोज सकता है, और समझा सकता है कि शायद क्या हुआ। लेकिन जब तक वह यह न समझे कि कौन-सा उत्पाद चल रहा था, कौन-से ऑर्डर उस ऑपरेशन पर निर्भर हैं, कौन-सी मशीनें स्वीकृत विकल्प हैं, कौन-से टूल उपलब्ध हैं, कौन-से ऑपरेटर योग्य हैं, और कौन-से गुणवत्ता या प्रक्रिया नियम लागू होते हैं, तब तक वह प्रतिक्रिया को सुरक्षित रूप से अनुकूलित नहीं कर सकता।
यह मुख्य रूप से AI की समस्या नहीं है। यह फ़ैक्टरी-संदर्भ की समस्या है।

डेटा और संदर्भ एक जैसे नहीं हैं
फ़ैक्टरियाँ पहले से ही भारी मात्रा में डेटा उत्पन्न करती हैं। ERP, MES, रखरखाव, गुणवत्ता, हिस्टोरियन, PLC, IoT प्लेटफ़ॉर्म और स्प्रेडशीट सभी उपयोगी तथ्य रखते हैं।
समस्या यह है कि ये तथ्य अक्सर आपस में जुड़े हुए नहीं रहते। अकेला मशीन-स्टॉप कोड यह नहीं बताता कि घटना उत्पादन, चेंजओवर, रखरखाव, या कठोर प्रसंस्करण-समय सीमा वाले बैच के दौरान हुई। कोई मशीन निष्क्रिय दिख सकती है, फिर भी वह अनुपयोगी हो सकती है क्योंकि आवश्यक फ़िक्सचर उपलब्ध नहीं है या योग्य ऑपरेटर शिफ़्ट में नहीं है।
संदर्भ घटना को उसके आसपास की परिचालन स्थिति से जोड़ता है।

इसमें शामिल है:

• एसेट और संसाधन की पहचान
• सक्रिय ऑपरेशन और वर्क ऑर्डर
• उत्पाद और संशोधन
• रूट और वैकल्पिक रूट
• सामग्री और बैच की स्थिति
• टूलिंग और फ़िक्सचर
• कौशल और शिफ़्ट कवरेज
• गुणवत्ता प्रतिबंध
• रखरखाव की स्थिति
• क्षमता और डाउनस्ट्रीम निर्भरताएँ
• ग्राहक प्रतिबद्धताएँ

डैशबोर्ड क्यों पर्याप्त नहीं हैं
Power BI और परिचालन डैशबोर्ड यह दिखाने में उत्कृष्ट हैं कि क्या बदला। वे डाउनटाइम, बढ़ती कतारें, देरी से पहुँचने वाले ऑर्डर, स्क्रैप, या उपलब्ध क्षमता उजागर कर सकते हैं।

लेकिन किसी समस्या को दिखाना और यह तय करना कि उत्पादन को आगे क्या करना चाहिए, दो अलग बातें हैं।
एक डैशबोर्ड दिखा सकता है कि कोई दूसरी मशीन उपलब्ध है। लेकिन वह स्वतः यह नहीं जानता कि वह मशीन वर्तमान उत्पाद संशोधन के लिए स्वीकृत है या नहीं, फ़िक्सचर पहले से आरक्षित है या नहीं, स्थानांतरण के लिए गुणवत्ता की मंज़ूरी चाहिए या नहीं, या काम को स्थानांतरित करने से डाउनस्ट्रीम में नई बाधा बनती है या नहीं।

जब रिपोर्टों में दर्जनों विशेष-स्थिति गणनाएँ आ जाती हैं और योजनाकार विकल्पों की जाँच के लिए परिणाम को Excel में निर्यात करते हैं, तब लापता चीज़ आमतौर पर एक और विज़ुअलाइज़ेशन नहीं होती। वह उस निर्णय के पीछे के फ़ैक्टरी-नियमों का एक स्पष्ट मॉडल होता है।

पूर्वानुमान अनुकूलन नहीं है
पूर्वानुमान बता सकता है कि कोई मशीन खराब होने की संभावना है या कोई ऑर्डर देरी से पहुँचने की उच्च संभावना रखता है।
यह उपयोगी है, पर यह नहीं बताता कि क्या करना है।
अनुकूलन का काम अलग है। वह संभावित कार्रवाइयों का मूल्यांकन फ़ैक्टरी के नियमों और बाधाओं के विरुद्ध करता है।

उदाहरण के लिए, मशीन खराब होने के बाद एक ऑप्टिमाइज़र जाँच सकता है कि प्रभावित काम मूल संसाधन पर रह सकता है, किसी स्वीकृत वैकल्पिक मशीन पर जा सकता है, अनुक्रम बदल सकता है, या ओवरटाइम का उपयोग कर सकता है।
एक व्यवहार्य योजना को वास्तविक परिस्थितियों का सम्मान करना होगा।
सुरक्षा सीमाएँ, प्रक्रिया स्वीकृतियाँ, सामग्री की अनुकूलता, ऑपरेटर प्रमाणन, टूलिंग, गुणवत्ता प्रतिबंध, रखरखाव विंडो, और अनुक्रम नियम केवल इसलिए गायब नहीं हो सकते कि कोई दूसरी मशीन खाली दिखती है।

AI, अनुकूलन और नियमों के अलग-अलग काम हैं
Generative AI योजनाकारों को स्थिति समझने, जुड़ी हुई जानकारी खोजने, विकल्पों की तुलना करने, ट्रेड-ऑफ़ समझाने, और उपयोगी हैंडओवर बनाने में मदद कर सकता है।
पूर्वानुमान मॉडल जोखिम का अनुमान लगा सकते हैं।
अनुकूलन इंजन व्यवहार्य अनुसूचियाँ खोज सकते हैं।
नियम-आधारित तर्क यह जाँच सकते हैं कि प्रस्तावित कार्रवाई ज्ञात उत्पादन-शर्तों का पालन करती है।
ये घटक साथ मिलकर काम कर सकते हैं, पर इन्हें एक-दूसरे के साथ भ्रमित नहीं करना चाहिए।
एक भाषा मॉडल विश्वसनीय लगने वाली व्याख्या दे सकता है। इससे यह साबित नहीं होता कि कोई उत्पादन योजना क्रियान्वयन योग्य है।

उत्पाद, प्रक्रिया, संसाधन
एक उपयोगी फ़ैक्टरी मॉडल उत्पाद (Product), प्रक्रिया (Process), और संसाधन (Resource) से शुरू होता है।
उत्पाद बताता है कि क्या बनाया जा रहा है, जिसमें संशोधन, सामग्री, बैच-नियम, और ग्राहक-विशिष्ट आवश्यकताएँ शामिल हैं।

प्रक्रिया बताती है कि उसे बनाने के लिए कौन-से ऑपरेशन, अनुक्रम, सेटअप शर्तें, निरीक्षण, वैकल्पिक मार्ग और नियम आवश्यक हैं।

संसाधन बताता है कि वह काम कौन कर सकता है। संसाधन एक मशीन, टूल, फ़िक्सचर, भट्टी, परीक्षण स्टेशन, परिवहन उपकरण, या व्यक्ति हो सकता है।
महत्वपूर्ण बात इनके बीच का संबंध है।

प्रश्न यह नहीं है:
“कौन-सी मशीन खाली है?”

उपयोगी प्रश्न यह है:
“कौन-सा उपलब्ध संसाधन, स्वीकृत प्रक्रिया, टूलिंग, सामग्री, गुणवत्ता, स्टाफ़िंग और समय-शर्तों के तहत, इस उत्पाद और इस ऑर्डर के लिए अगला आवश्यक ऑपरेशन कर सकता है?”

बिना हाइप के नॉलेज ग्राफ़
नॉलेज ग्राफ़ इन जुड़े हुए फ़ैक्टरी-संबंधों को दर्शाने का एक तरीका देता है।
मशीनों, ऑपरेशनों, ऑर्डरों, टूलों और सामग्रियों को अलग-अलग रिकॉर्ड में रखने के बजाय, ग्राफ़ उनके बीच के संबंधों को भी दर्शाता है।

एक मशीन एक ऑपरेशन कर सकती है। वह ऑपरेशन एक रूट से संबंधित है। वह रूट एक उत्पाद संशोधन से संबंधित है। एक वर्क ऑर्डर उस रूट की माँग करता है। उस ऑपरेशन के लिए एक फ़िक्सचर आवश्यक हो सकता है। वह फ़िक्सचर अभी किसी दूसरे काम के लिए प्रतिबद्ध हो सकता है।

इससे “यह ऑर्डर मशीन 7 पर क्यों नहीं जा सकता?” जैसे प्रश्नों की व्याख्या कहीं आसान हो जाती है।
उत्तर केवल “संभव नहीं” नहीं होना चाहिए।

उसे समझाना चाहिए कि मशीन 7 उस ऑपरेशन को सहारा देती है, लेकिन आवश्यक फ़िक्सचर उपलब्ध नहीं है, या उत्पाद संशोधन को स्वीकृति नहीं मिली है, या डाउनस्ट्रीम गुणवत्ता शर्त उस रूट को रोक रही है।

डिजिटल ट्विन को एक काम चाहिए
एक लाइव डैशबोर्ड स्वतः डिजिटल ट्विन नहीं होता।
एक उपयोगी ट्विन भौतिक संचालन के एक परिभाषित हिस्से का प्रतिनिधित्व करता है और एक विशिष्ट उद्देश्य के आसपास संरचना, स्थिति, नियम और स्रोत-डेटा को जोड़ता है।

एक एसेट ट्विन रखरखाव-निर्णयों में सहायता कर सकता है।
एक लाइन ट्विन प्रवाह और बाधाओं को समझने में मदद कर सकता है।
एक उत्पादन-प्रणाली ट्विन उपकरण की स्थिति को ऑर्डरों, रूटों, सामग्रियों, लोगों, गुणवत्ता नियमों और डिलीवरी-प्रतिबद्धताओं से जोड़ सकता है।

महत्वपूर्ण प्रश्न यह नहीं है कि “क्या हमारे पास डिजिटल ट्विन है?”
बल्कि यह है कि “यह ट्विन किस उपयोगकर्ता, निर्णय और समय-अवधि का समर्थन करता है?”

एसेट पहचान मूलभूत है
एक भौतिक मशीन की कई पहचानें हो सकती हैं।
रखरखाव एक एसेट नंबर उपयोग कर सकता है। MES एक उत्पादन संसाधन उपयोग करता है। ERP एक वर्क सेंटर उपयोग करता है। IoT परत एक कंट्रोलर या टैग पथ देखती है।

इन पहचानकर्ताओं को समाप्त होने की आवश्यकता नहीं है, पर उनके संबंधों का शासन होना चाहिए।
यदि कोई AI प्रणाली अनुमान लगा ले कि दो मिलते-जुलते मशीन-नाम एक ही भौतिक एसेट हैं, तो बाद का हर निर्णय गलत हो सकता है, भले ही अंतर्निहित डेटा तकनीकी रूप से साफ़ हो।

इसलिए एसेट मैपिंग के लिए स्वामित्व, प्रभावी तिथियाँ, स्रोत-संदर्भ और परिवर्तन-प्रबंधन होना चाहिए।

बाधाएँ डेटा का हिस्सा हैं
एक रूट तकनीकी रूप से संभव हो सकता है और फिर भी उत्पादन के लिए अस्वीकार्य हो सकता है।

कठोर बाधाओं में शामिल हो सकते हैं:
• सुरक्षा सीमाएँ
• स्वीकृत नुस्खे
• सामग्री की अनुकूलता
• मशीन की क्षमता
• ऑपरेटर प्रमाणन
• गुणवत्ता रिलीज़
• टूल की उपलब्धता
• रखरखाव प्रतिबंध

अन्य बाधाएँ पूर्ण सीमाएँ नहीं, बल्कि ट्रेड-ऑफ़ का प्रतिनिधित्व करती हैं। एक तत्काल डिलीवरी की रक्षा के लिए अतिरिक्त चेंजओवर स्वीकार्य हो सकता है। एक ग्राहक-प्रतिबद्धता के लिए ओवरटाइम की अनुमति हो सकती है, दूसरी के लिए नहीं।

प्रणाली को इन ट्रेड-ऑफ़ को उजागर करना चाहिए, न कि उन्हें एक अपारदर्शी सिफ़ारिश के भीतर छिपाना चाहिए।

स्वच्छ डेटा आवश्यक है — पर पर्याप्त नहीं
सटीक टाइमस्टैम्प, पूर्ण घटनाएँ, मानकीकृत पहचानकर्ता और विश्वसनीय इंटरफ़ेस अनिवार्य हैं।

पर एक पूर्णतः स्वच्छ तालिका भी यह नहीं समझाती कि “उपलब्ध,” “पूर्ण,” या “क्षमता” का अर्थ क्या है।
एक मशीन यांत्रिक रूप से उपलब्ध हो सकती है, फिर भी वर्तमान ऑपरेशन के लिए अनुपलब्ध हो सकती है। P