चालानों की एंट्रॉपी: क्यों संशोधन टकराव उत्पादन को नष्ट करते हैं

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

ऑपरेटर असेंबली में विफल नहीं हो रहे हैं; सिस्टम समन्वय में विफल हो रहा है।

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

इंजीनियरिंग आमतौर पर ठीक काम करती है। घर्षण इस बात से आता है कि इंजीनियरिंग को एक सतत प्रवाह के रूप में माना जाता है जबकि निर्माण अलग-अलग स्नैपशॉट में होता है। जब आप बिल ऑफ मटेरियल्स (BOM) को सॉफ़्टवेयर रिपॉजिटरी की तरह मानते हैं, तो आप अराजकता को आमंत्रित करते हैं। एक git revert की कोई लागत नहीं होती। एक प्लास्टिक इंजेक्शन मोल्ड टूल को वापस लेना या 5,000 प्रिंटेड सर्किट बोर्डों को स्क्रैप करना क्योंकि संशोधन पत्र स्टेंसिल से मेल नहीं खाता, छह अंकों की गलती है। निर्धारित निर्माण के दौरान कई ECOs का टकराव "सॉफ्ट" यील्ड लॉस का सबसे सामान्य कारण है। आपने यूनिट गलत नहीं बनाई है; आपने बस गलत यूनिट बनाई है क्योंकि समयसीमा टकराई।

"लेटेस्ट रिवीजन" का जाल

आधुनिक हार्डवेयर विकास में एक खतरनाक धारणा है कि किसी फ़ाइल का "लेटेस्ट" संस्करण ही बनाया जाना चाहिए। एक प्रोडक्ट लाइफसायकल मैनेजमेंट (PLM) सिस्टम में, एक फ़ाइल "मंजूर" हो सकती है बहुत पहले कि वह "लागू" हो। वह अंतर वह जगह है जहाँ पैसा गायब हो जाता है।

ऑस्टिन कार्यालय में बैठा एक इंजीनियर देखता है कि नया ब्रैकेट डिज़ाइन सिस्टम में मंजूर है और मानता है कि लाइन से अगली यूनिट में यह होगा। लेकिन फैक्ट्री फ्लोर भौतिक इन्वेंट्री पर काम करता है, डिजिटल स्थिति पर नहीं। यदि गोदाम में पुराने ब्रैकेट की 4,000 इकाइयाँ हैं, तो फैक्ट्री की डिफ़ॉल्ट लॉजिक उन्हें खत्म करने की होती है ताकि बर्बादी न हो। जब तक ECO स्पष्ट रूप से "पर्ज और स्क्रैप" कार्रवाई को मजबूर नहीं करता, "लेटेस्ट" संशोधन केवल सर्वर पर मौजूद होता है, लाइन पर नहीं।

यह असंगति तब घातक हो जाती है जब आप "डिविएशन वेवर" को पेश करते हैं। अक्सर सप्लाई चेन प्रबंधन में आवश्यक बुराई, वेवर अस्थायी रूप से नियम तोड़ने की औपचारिक अनुमति है—शायद कमी के दौरान एक विकल्प कैपेसिटर का उपयोग करने के लिए या शिपिंग डेडलाइन को पूरा करने के लिए एक कॉस्मेटिक टेस्ट छोड़ने के लिए। खतरा तब उत्पन्न होता है जब इन वेवरों को प्रशासनिक कागजी कार्रवाई के रूप में माना जाता है न कि इंजीनियरिंग परिवर्तनों के रूप में।

एक वेवर प्रभावी रूप से एक अस्थायी ECO होता है जिसकी समाप्ति तिथि होती है। यदि आप एक ब्रोकरेज-स्रोतित घटक का उपयोग करने के लिए डिविएशन को अधिकृत करते हैं लेकिन उस डिविएशन को PLM में विशिष्ट सीरियल नंबर रेंज से लिंक करने में विफल रहते हैं, तो आपने एक टाइम बम बना दिया है। छह महीने बाद, जब वे घटक विफल होंगे, तो आपको पता नहीं चलेगा कि किन इकाइयों में वे हैं। आप केवल खराब इकाइयों को रिकॉल नहीं कर सकते क्योंकि डेटा मौजूद नहीं है। बिना किसी विशिष्ट कार्यान्वयन गेट के, फैक्ट्री डिफ़ॉल्ट रूप से शेल्फ पर जो कुछ भी है उसे उपयोग करता है, और "आशा" ट्रैसेबिलिटी लॉग में एक मान्य फ़ील्ड नहीं है।

फर्मवेयर एक घटक है, कोई वाइब नहीं

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

“फैंटम फर्मवेयर” परिदृश्य पर विचार करें। एक डेवलपर एक गंभीर बग को ठीक करने के लिए संस्करण 2.1 को रिपॉजिटरी में पुश करता है। हालांकि, फैक्ट्री प्रोग्रामर टेस्ट सर्वर पर एक विशिष्ट फ़ोल्डर में स्थित बाइनरी को फ्लैश कर रहे हैं। यदि ECO प्रक्रिया स्पष्ट रूप से टेस्ट इंजीनियर को नए चेकसम को मान्य करने और प्रोग्रामर इमेज को अपडेट करने का निर्देश नहीं देती है, तो फैक्ट्री हमेशा के लिए संस्करण 2.0 को फ्लैश करती रहेगी। यूनिट्स फंक्शनल टेस्ट पास कर लेंगी क्योंकि टेस्ट लिमिट्स संभवतः नए संस्करण स्ट्रिंग के लिए अपडेट नहीं की गई हैं।

यहाँ बाद में इन समस्याओं को ठीक करने के लिए ओवर-द-एयर (OTA) अपडेट्स पर भरोसा करने का प्रलोभन है। यह एक खतरनाक सहारा है। OTA उस डिवाइस को ठीक नहीं कर सकता जो बूट होते ही ब्रिक हो जाता है क्योंकि बूटलोडर संस्करण एप्लिकेशन पार्टिशन मैप से मेल नहीं खाता। इसके अलावा, फील्ड अपडेट्स पर भरोसा करने से आपकी विफलताओं का निदान करने की क्षमता नष्ट हो जाती है। यदि कोई ग्राहक ब्रिक्ड यूनिट के साथ सपोर्ट को कॉल करता है, और आपकी RMA टीम सीरियल नंबर से यह नहीं बता पाती कि फैक्ट्री में मूल रूप से कौन सा कोड फ्लैश किया गया था, तो वे अंधेरे में हैं। उन्हें पता नहीं होता कि वे हार्डवेयर दोष का पीछा कर रहे हैं या सॉफ़्टवेयर बग का। यदि बाइनरी में पार्ट नंबर नहीं है, तो वह लाइन ऑपरेटर के लिए मौजूद नहीं है, और निश्चित रूप से यह आपकी सपोर्ट टीम की मदद नहीं करेगा।

डिस्पोजीशन मैट्रिक्स

किसी भी ECO पर सबसे महत्वपूर्ण फ़ील्ड परिवर्तन का विवरण नहीं, बल्कि पुराने सामग्री की “डिस्पोज़िशन” है। यहीं परिवर्तन की वित्तीय वास्तविकता की गणना की जाती है। जब आप नया संशोधन पेश करते हैं, तो आपको सामग्री को चार अवस्थाओं में ध्यान में रखना चाहिए: ऑन हैंड (वेयरहाउस में), ऑन ऑर्डर (वेंडर्स से आने वाली), WIP (लाइन पर वर्क इन प्रोसेस), और फिनिश्ड गुड्स (डॉक पर रखी हुई)।

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

आपको गणना करनी होगी। अक्सर ऑपरेटरों द्वारा नाजुक रीवर्क करने की कोशिश के दौरान तीन दिनों की लाइन-डाउन समय की तुलना में $5,000 कच्चे PCB को स्क्रैप करना सस्ता होता है। रीवर्क लगभग हमेशा एक कल्पना होती है; स्क्रैप स्पष्टता की कीमत है।

द क्लीन ब्रेक प्रोटोकॉल

रक्तस्राव रोकने के लिए, आपको “क्लीन ब्रेक” लागू करना होगा। एक रोलिंग परिवर्तन—जहाँ नए संशोधन पुराने संशोधनों के साथ बिन में मिलाए जाते हैं—केवल उन भागों के लिए स्वीकार्य है जो 100% रूप, फिट, और कार्य में विनिमेय हैं, जैसे किसी अलग विक्रेता का स्क्रू। बाकी सब के लिए, आपको एक सख्त कटौती की आवश्यकता है।

इसका मतलब है कट-इन पॉइंट को कैलेंडर तिथि द्वारा नहीं, जो अस्थिर होती है, बल्कि एक विशिष्ट लॉट कोड या सीरियल नंबर द्वारा परिभाषित करना। “संशोधन B SN: 100500 से शुरू होता है।” यह निर्देश फैक्ट्री को लाइन को अलग करने की अनुमति देता है। वे संशोधन A की रन पूरी कर सकते हैं, लाइन को साफ कर सकते हैं, पुरानी स्टॉक को हटाकर, और संशोधन B को एक नई सेटअप के साथ शुरू कर सकते हैं।

यह अनुशासन की मांग करता है। इसका मतलब हो सकता है कि नए भागों के आने तक दो दिन का निर्माण विलंब करना, बजाय एक “हाइब्रिड” मॉन्स्टर बनाने के। लेकिन वह विलंब रिकॉल से सस्ता है। ब्रेक पॉइंट को नियंत्रित करें, नहीं तो ब्रेक पॉइंट आपके मार्जिन को नियंत्रित करेगा।