यील्ड रैंप सेवा: एक नाजुक प्रोटोटाइप को स्थिर पायलट रन में बदलना

एक पायलट रन स्थिर दिख सकता है जब तक कि यह नहीं हो जाता। एक दिन लाइन साफ बोर्ड बनाती है, AOI शांत दिखता है, और हर कोई बात करता है कि कठिन हिस्सा खत्म हो गया है। अगले दिन, वही प्रोग्राम पुलियों और ओपन की तरह परिणाम देता है जैसे किसी ने स्विच फ्लिप कर दिया हो। असहज हिस्सा यह है कि कुछ भी “बड़ा” नहीं बदला—सिर्फ सामान्य चीजें जो मंगलवार रात को एक मिश्रित क्रू के साथ होती हैं।

ब्रुकलिन पार्क पायलट लाइन निर्माण में, ड्रिफ्ट उस जगह दिखाई दी जहां लोग देखना नहीं चाहते थे: क्षेत्र में सोल्डर पेस्ट मात्रा का ट्रेंड नीचे जाना। कोह यंग SPI ने इसे स्पष्ट कर दिया जब किसी ने ट्रेंड को देखने की जहमत उठाई बजाय पास/फेल स्नैपशॉट के। और फिर यह और भी खराब हो गया: हेलर 1809 पर रीफ्लो रेसिपी को बीच में ही ट्यून किया गया क्योंकि किसी ने “शाइन के लिए ट्यूनिंग” की। यह तो sabotage नहीं है। यह बस वही होता है जब “समान निर्माण” की कोई सहमति वाली परिभाषा नहीं होती।

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

वास्तव में Yield Ramp Service क्या है (और क्या नहीं है)

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

“निरीक्षण जोड़ें” प्रतिक्रिया सबसे आसान जगह है विफलता देखने की। AOI कवरेज जोड़ना या कार्यात्मक परीक्षण का विस्तार करना असफलताओं को कम कर सकता है अल्पकालिक में—और नियंत्रित उत्पादों में, वह नियंत्रण अनिवार्य है। लेकिन निरीक्षण प्रक्रिया को अधिक स्थिर नहीं बनाता। इससे भी बुरा, अनियंत्रित निरीक्षण फैक्ट्री को सामाजिक रूप से सुन्न कर सकता है: ऑपरेटर सीखते हैं कि कौन-कौन सी कॉल शोर हैं, ऑटो-डिस्पोज़िशन उनमें से आधे को कर देता है, और दोष डेटा तर्क का ढेर बन जाता है। यह मिर्टेक AOI प्रोग्राम पर हुआ जहां कनेक्टर शैडोिंग ने लगातार परेशानी कॉल्स बनाई। लाइन पर “कई दोष” थे कागज पर, लेकिन वास्तविकता में बहुत कम स्पष्टता थी। निरीक्षण प्रणालियाँ तकनीकी रूप से फेल होने से पहले सामाजिक रूप से फेल हो जाती हैं।

आपके पास यील्ड समस्या नहीं है; आपके पास अनियंत्रित प्रक्रिया समस्या है।

यह वित्तीय और परिचालन दोनों रूप से महत्वपूर्ण है, केवल दार्शनिक नहीं। यदि एक बोर्ड रीवर्क बेंच पर 14 मिनट का टच-अप लेता है और बोझ वाला दर $55/घंटा है, तो वह लगभग $6.40 प्रति बोर्ड श्रम में है, रीटेस्ट समय, स्क्रैप जोखिम, और कतारों की छुपी लागत से पहले। वह संख्या असामान्य नहीं है; यह तब दिखाई देती है जब टीमें रीवर्क को योजना के रूप में सामान्य बनाती हैं। यदि संगठन केवल शिपिंग वाले को ही गिनता है, तो यील्ड संख्या अभी भी “ठीक” दिख सकती है।

यह भ्रम स्थायी है, इसलिए आइए स्पष्ट करें: FPY पहले पास यील्ड है जो रीवर्क के बिना एक परिभाषित चरण से गुजरता है। RTY चरणों के बीच रोल्ड थ्रूपुट यील्ड है। “शिप्ड यील्ड” वह है जो तब बचता है जब पर्याप्त लोग इसे छूते हैं और यह पास हो जाता है। टीमें अंतिम संख्या को पसंद करती हैं क्योंकि यह स्लाइड डेक को सुरक्षित महसूस कराता है, लेकिन यह मार्जिन को काल्पनिक बनाता है। एक उचित FPY लक्ष्य सार्वभौमिक नहीं है; यह इकाई अर्थशास्त्र और जोखिम पर निर्भर करता है। एक उच्च-मिश्रण औद्योगिक नियंत्रण कुछ समय के लिए 92% FPY के साथ रह सकता है यदि रीवर्क सीमित और दस्तावेजीकृत है। एक टाइट-मार्जिन, उच्च मात्रा वाला उत्पाद नहीं कर सकता, और गणित इसे सजा देगा।

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

प्रथम फोर्सिंग फंक्शन: एक दोष पारेतो जो झूठ नहीं बोलता

रैंप अराजकता सब कुछ को समान रूप से तात्कालिक महसूस कराती है, इसी तरह टीमें सप्ताह जला देती हैं। इसका इलाज एक दोष लॉग है जो जांच के तहत टिक सकता है और एक पारेटो है जो तर्क करना कठिन बना देता है।

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

एक दोष लॉग जो वास्तविक पारेटो की आवश्यकताओं का समर्थन करता है, कम से कम:

• दोष प्रकार (सुसंगत श्रेणियां; यदि टीम वास्तव में उनका उपयोग कर सकती है तो IPC-7912A-शैली श्रेणियां ठीक हैं)
• स्थान और संदर्भ des (सिर्फ “साइड A” नहीं)
• समय/तिथि और निर्माण/लॉट पहचानकर्ता (ताकि विचलन दिखे)
• लाइन/मशीन और ऑपरेटर/शिफ्ट (क्योंकि परिवर्तन के फिंगरप्रिंट होते हैं)
• निर्णय और पुनःकार्य कदम (ताकि पुनःकार्य अदृश्य श्रम न हो)

वहां से, कदम निर्दय हो जाता है: शीर्ष एक से तीन दोष मोड को घेरें और प्रत्येक तंत्र को प्रवाह के पार ट्रेस करें—सामग्री → प्रिंट → स्थान → पुनः प्रवाह → निरीक्षण → परीक्षण → हैंडलिंग। हर दोष को समान इंजीनियरिंग समय नहीं मिलना चाहिए। प्राथमिकता देना निर्दयता नहीं है; यह रैंप को जीवित रहने का तरीका है। एक अपवाद है जिसे जोर से कहना चाहिए: एक कम-आवृत्ति दोष जो विनाशकारी है (सुरक्षा, नियामक, रिकॉल-स्तर) उसे उसके पारेटो रैंक से ऊपर उठाया जाता है। यह बस जोखिम प्रबंधन के साथ रीढ़ है।

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

पेस्ट वह स्थान है जहाँ पायलट चुपचाप मर जाते हैं (स्टेंसिल + प्रिंट नियंत्रण)

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

पेस्ट प्रिंटिंग सबसे सामान्य जगह है जहां एक पायलट की स्थिरता कहानी टूट जाती है। यह भी एक ऐसी जगह है जहां छोटे, तेज बदलाव अधिक उत्पादन कर सकते हैं बनाम बड़े, धीमे बदलाव। एक निर्माण में जहां एक BGA कोना खोल अस्थायी रूप से दिखाई दिया, आसान कथा यह थी कि BGA आपूर्तिकर्ता को दोष दें। असहज कदम था SPI टाइम-सीरीज डेटा माँगना और प्रिंटिंग के एक घंटे में विचलन देखना। उस डेटा ने दिखाया कि समय के साथ पेस्ट मात्रा में परिवर्तन बढ़ रहा है, विशेष रूप से परिधि पैड पर। एक्स-रे (एक Nordson Dage जैसी प्रणाली) ने BGA कोने पर लक्षण की पुष्टि की, लेकिन SPI ने तंत्र की ओर इशारा किया।

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

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

प्रिंट नियंत्रण की एक छोटी चेकलिस्ट जो अक्सर पायलट बेसलाइन में होनी चाहिए:

• पेस्ट टाइप और हैंडलिंग नियम (टाइप 4 SAC305 जादुई नहीं है; यह केवल एक पैरामीटर है जिसे नियंत्रित किया जाना चाहिए)
• अंडर-स्टेंसल वाइप सॉल्वैंट और कैडेंस (और जब यह बदलता है तो एक नियम)
• स्कुईजी दबाव और गति सीमा (एक सीमा, न कि एक संख्या)
• शिफ्ट परिवर्तन से जुड़ी प्रिंटर सेटअप जांच (क्योंकि ड्रिफ्ट का समय पूर्वानुमानित होता है)
• SPI थ्रेशोल्ड और डेटा एक्सपोर्ट जो रुझान दिखाते हैं, केवल पास/फेल स्नैपशॉट नहीं

यह पूर्ण स्टेंसल डिज़ाइन ट्यूटोरियल नहीं है। IPC-7525 का अस्तित्व किसी कारण से है। मुख्य बात यह है कि यील्ड रैम्प सेवा पेस्ट और प्रिंट को पहले दर्जे का यील्ड लीवर मानती है और नियंत्रण पर जोर देती है जो सामान्य परिवर्तन के साथ भी टिक सके।

रीफ्लो प्रोफ़ाइल: रेसिपी हंटिंग बंद करें, एक बोरिंग विंडो बनाएं

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

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

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

और हाँ, यह संदर्भगत है। SAC305 के लिए सार्वभौमिक “सर्वश्रेष्ठ रीफ्लो प्रोफ़ाइल” नहीं है, क्योंकि ओवन प्रकार भिन्न होते हैं, बोर्ड का भार भिन्न होता है, घटक घनत्व भिन्न होता है, और नाइट्रोजन बनाम वायु की स्थिति गीलेपन के व्यवहार को बदलती है। सबसे ईमानदार आउटपुट गार्डरेल्स और एक स्थिर विंडो जल्दी खोजने का तरीका है, न कि कॉपी-पेस्ट ग्राफ।

एक बार जब टीम बिना हिचकिचाहट के कह सके कि प्रोफ़ाइल क्या है और कौन सा रेंज स्वीकार्य है, तो अगला सवाल मानव का बन जाता है: क्या प्रक्रिया शिफ्ट-टू-शिफ्ट व्यवहार में जीवित रह सकती है? वहीं ऑपरेटर लूप “सॉफ्ट स्टफ” से “यील्ड मैकेनिक्स” बन जाते हैं।

ऑपरेटर, निरीक्षण विश्वसनीयता, और 10 मिनट का लूप

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

जहां AOI परेशानियों के कॉल्स ने प्रशिक्षित लोगों को ऑटो-डिस्पोज़िशन सिखाया, वहां विफलता यह नहीं थी कि मिर्टेक एक खराब मशीन थी। विफलता शासन व्यवस्था की थी। ऑपरेटर बार-बार एक ही कनेक्टर शैडो कॉल को क्लियर कर रहे थे, जो पुनरावृत्त शोर के प्रति एक अनुमानित मानवीय प्रतिक्रिया है। समाधान आंशिक रूप से तकनीकी था—लाइटिंग और लाइब्रेरी थ्रेशोल्ड्स—और आंशिक सामाजिक: एक स्पष्ट नियम कि दोहराए जाने वाले परेशानियों के कॉल्स 48 घंटे के भीतर ठीक कर दिए जाएंगे या हटा दिए जाएंगे। उस नियम ने विश्वसनीयता फिर से बनाई, डेटा साफ किया, और पारेटो को ईमानदार बनाया।

एक हल्का लूप जो पायलट में काम करता है वह तीन प्रॉम्प्ट के साथ 10 मिनट का शिफ्ट-एंड डिब्रीफ है: “क्या आपको धीमा किया?”, “आपने किसे दो बार पुनः काम किया?”, “निर्देश मेल नहीं खाते थे?” मुख्य बात समापन है: परिवर्तन एक या दो दिनों के भीतर होते हैं, और टीम स्पष्ट रूप से जोड़ती है “हमने X बदला क्योंकि आपने Y देखा।” नियंत्रित वातावरण में, उस समापन को ECO/NCR मार्गों और नियंत्रित कार्य निर्देश अपडेट्स के माध्यम से प्रवाहित करना पड़ता है। लूप अभी भी काम करता है; बस सही कागजी कार्रवाई की जरूरत है ताकि “लाइन को ठीक करना” बिना दस्तावेज़ीकरण प्रक्रिया के बदलाव न बन जाए।

गोल्डन प्रोसेस पैकेट: पायलट को ट्रांसफरेबल बनाने का तरीका (और सीएम-प्रूफ़)

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

मेडिकल पायलट ट्रांसफर के दौरान मैडिसन में ग्राहक साइट और ग्वाडलाजारा में एक सीएम के बीच, बोर्ड अक्सर विद्युत रूप से ठीक थे, लेकिन लॉट समीक्षा अराजकता थी। लोग यह नहीं बता सकते थे कि क्या बदला है। एक ओवन क्षेत्र को ट्यून किया गया था। एक स्टेंसिल वाइप सॉल्वेंट को बदला गया था। नाइट्रोजन रिफ्लो का उपयोग एक स्थान पर किया गया था और दूसरे में हवा का उपयोग बिना कैप्चर किए। जब BTC/QFN वॉयडिंग और इंटरमिटेंट ओपन सीएम पर दिखाई दिए, तो इसे 'सीएम इसे नहीं बना सकता' के रूप में फ्रेम करना आकर्षक था। वास्तविक दोष मिसिंग बेसलाइन था।

यहां से उपज रैंप सेवा शासन कार्य बन जाती है। एक 'गोल्डन बिल्ड पैकेट' कोई औपचारिकता नहीं है; यह ट्रांसफर वाहन है। यह परिभाषित करता है कि 'एक ही बिल्ड' का क्या अर्थ है, न कि इरादों में। यह एक फोर्सिंग फंक्शन भी बनाता है: यदि टीम प्रक्रिया को लिख नहीं सकती, तो टीम इसे स्थिर नहीं कह सकती।

एक व्यावहारिक गोल्डन पैकेट में आमतौर पर संस्करण-नियंत्रित, संशोधन-मैच आइटम शामिल होते हैं जैसे:

• स्टेंसिल ड्राइंग और कोई भी कदम स्टेंसिल कॉलआउट (समेत एपर्चर नोट्स)
• ओवन रेसिपी और इसे मापा/मान्य किया गया कैसे (सिर्फ़ “ज़ोन 3 = 240” नहीं)
• प्लेसमेंट प्रोग्राम आइडेंटिफायर या हैश और मशीन सेटअप नोट्स
• AOI लाइब्रेरी संस्करण और निरीक्षण थ्रेशोल्ड (और nuisance कॉल्स के नियम)
• SPI थ्रेशोल्ड और कौन सा डेटा निर्यात होता है
• वर्क इंस्ट्रक्शंस, टॉर्क स्पेक्स जहां आवश्यक हो, ESD नियंत्रण, और रीवर्क सीमाएं
• बदलाव नियंत्रण मार्ग: कौन क्या बदल सकता है, किस साक्ष्य के साथ, और इसे कैसे रिकॉर्ड किया जाता है

एक डायवर्जन जो महत्वपूर्ण है क्योंकि लोग यहां फंस जाते हैं: स्वीकृति थ्रेशोल्ड हमेशा सार्वभौमिक नहीं होते। उदाहरण के लिए, BTC/QFN वॉयडिंग मानदंड आवेदन- और मानक-निर्भर हो सकते हैं, और टीमों को ट्रांसफर के बीच में इसे सुधारने का प्रयास नहीं करना चाहिए। अनुशासित कदम है कि मानदंड को गुणवत्ता/ग्राहक हितधारकों के साथ सहमति बनाना और रिकॉर्ड करना कि कौन सा मानक संशोधन या आंतरिक स्पेक का उपयोग किया जा रहा है। बात यह नहीं है कि पायलट को कागजी कार्रवाई का त्योहार बना दिया जाए। बात यह है कि मौन ट्यूनिंग को रोकें ताकि पायलट डेटा कहानियों में न बदल जाए।

गेट सख्त है: जब तक 'एक ही बिल्ड' की परिभाषा नहीं होती, तब तक स्केल न करें, और वह परिभाषा एक पैकेट में होनी चाहिए जो यात्रा कर सके।

यूनिट का पालन करें: जब “Yield” अब बाधा नहीं रह जाती

यहां तक कि जब SMT FPY में सुधार होता है, पायलट शिपमेंट तिथियों को चूक सकते हैं क्योंकि बाधा स्थानांतरित हो गई है। केवल सोल्डर जॉइंट्स पर ध्यान केंद्रित करने वाली उपज रैंप सेवा असली बाधक को चूक सकती है।

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

एक सरल लिटमस टेस्ट लूप को बंद कर देता है: कंटेनमेंट वह है जो इस सप्ताह शिपिंग जोखिम को नियंत्रित रखता है। क्षमता वह है जो अगले सप्ताह को शांत और सस्ता बनाती है। यदि पायलट केवल कंटेनमेंट के साथ समाप्त होता है—अधिक परीक्षण, अधिक निरीक्षक, अधिक रीवर्क बेंच—आउटपुट हो सकता है, लेकिन रैंप इसे किराए पर ले रहा है। यदि पायलट एक पारेटो-प्रेरित क्लोजर योजना, एक विश्वसनीय निरीक्षण प्रणाली, एक उबाऊ प्रक्रिया विंडो, और एक गोल्डन पैकेट के साथ समाप्त होता है जो 'एक ही बिल्ड' को परिभाषित करता है, तो रैंप में कुछ ऐसा है जिसे वास्तव में स्केल किया जा सकता है।