Nonconforming रोल कौन रिलीज़ कर सकता है? AS9100 में इलेक्ट्रॉनिक हस्ताक्षर और ज़िम्मेदारियों का बँटवारा (8.6, 8.7)

प्रकाशित: 8 अक्टूबर 2026 · पढ़ने में 7 मिनट

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

AS9100D का clause 8.6 कहता है कि प्रोडक्ट तभी रिलीज़ हो जब योजना के अनुसार सारी व्यवस्थाएँ पूरी हो जाएँ, और रिकॉर्ड दिखाएँ कि रिलीज़ को किसने अधिकृत किया। Clause 8.7 कहता है कि nonconforming आउटपुट की पहचान हो और उसे नियंत्रित रखा जाए, ताकि वह ग़लती से इस्तेमाल या डिलीवर न हो। दोनों को procedure में लिखना आसान है। कागज़ और स्प्रेडशीट से दोनों को लागू करना मुश्किल है, क्योंकि बॉक्स पर साइन होने से कुछ नहीं रोकता।

नीचे के उदाहरणों में prepreg रोल लिया गया है क्योंकि वह सबसे ठोस मामला है। यही नियम cure लोड, heat-treat बैच या serial नंबर वाले पार्ट पर भी लागू होते हैं।

रिलीज़ हस्ताक्षर में क्या-क्या होना चाहिए

इलेक्ट्रॉनिक हस्ताक्षर स्याही से तभी बेहतर है जब उसमें ज़्यादा जानकारी हो और उसका दुरुपयोग करना ज़्यादा मुश्किल हो। रिलीज़ हस्ताक्षर में ये रिकॉर्ड होने चाहिए:

• कौन। साइन-इन किया हुआ व्यक्ति, जो साइन करने के क्षण पर दोबारा authenticate करे: फिर से पासवर्ड, और साथ में authenticator app का कोड। किसी shared terminal पर खुला छूटा session काफ़ी नहीं होना चाहिए।
• क्या। फ़ैसला (released या rejected) और वह सटीक रिकॉर्ड जिस पर यह लागू होता है: "रोल 7" नहीं, बल्कि रोल 7 के रिकॉर्ड का वह सेव किया हुआ version जिसे साइन करने वाले ने रिव्यू किया।
• क्यों। एक कारण, छोटी सूची से या शब्दों में। Rejection के लिए कारण ज़रूरी है, क्योंकि वहीं से nonconformance trail शुरू होता है।
• कब। सर्वर का timestamp, साइन करने वाले के लैपटॉप की घड़ी नहीं।

हस्ताक्षर को रिकॉर्ड के किसी ख़ास version से बाँधना जितना लगता है उससे ज़्यादा अहम है। अगर रिलीज़ के बाद रिकॉर्ड दोबारा बनाया या एडिट किया जा सकता है, और रिलीज़ चुपचाप उसके साथ चलती रहती है, तो हस्ताक्षर ऐसी चीज़ को approve कर रहा है जिसे साइन करने वाले ने कभी देखा ही नहीं। सुरक्षित डिज़ाइन इसका उल्टा है: अगर रिकॉर्ड बदलता है, तो रिलीज़ उससे मेल नहीं खाती, और आगे की हर चीज़ (जैसे certificate of conformance) तब तक मना होती है जब तक दोबारा साइन न हो।

Blockers सूची, और override क्यों नहीं है

रिलीज़ स्क्रीन जो सबसे उपयोगी काम कर सकती है, वह है साइन करने वाले को आसान शब्दों में वह सब बताना जो अभी खुला है। कंपोज़िट रोल के लिए सूची में आमतौर पर ये होते हैं:

• रोल रिकॉर्ड मौजूद नहीं है, या उसका अलार्म और downtime डेटा अधूरा या उपलब्ध नहीं है।
• कोई critical parameter अपनी सीमा में fail हुआ, या सीमाएँ घोषित न होने की वजह से not evaluated रहा।
• रोल पर कोई quality hold खुला है।
• कोई लैब रिज़ल्ट मौजूद नहीं, fail है या अभी रिव्यू नहीं हुआ, या रेसिपी में उसे परखने के लिए कोई quality specification नहीं है।
• कोई रिज़ल्ट ऐसे इंस्ट्रूमेंट से लिया गया जो इस्तेमाल के समय कैलिब्रेशन में नहीं था।
• कोई input मटीरियल लॉट अपने out-time या shelf life से आगे था, या उसकी हिस्ट्री पता नहीं है।
• कोई nonconformance रिपोर्ट अभी खुली है।
• रेसिपी में first article ज़रूरी है और इस revision के लिए कोई approved first article मौजूद नहीं है।
• साइन करने वाला अधिकृत नहीं है, या वही व्यक्ति है जिसने job चलाया या बनाया।

अगर सूची में कुछ भी है, तो कुछ भी साइन नहीं होता। "फिर भी रिलीज़ करें" जैसा कोई बटन नहीं है, और वजह सीधी है: override एक control को सिर्फ़ सुझाव बना देता है। जो ऑडिटर override बटन देखेगा, वह पूछेगा कि इसका इस्तेमाल कितनी बार होता है, और ज़्यादातर प्लांट्स का ईमानदार जवाब होगा "जब हम व्यस्त होते हैं"।

इसका मतलब यह नहीं कि रुका हुआ रोल हमेशा के लिए अटका रहता है। इसका मतलब है कि हर blocker का एक owner और एक सही रास्ता है: इंजीनियर छूटी हुई सीमाएँ घोषित करता है, लैब रिज़ल्ट दर्ज करती है, Quality hold बंद करता है, और fail हुआ रोल रिकॉर्ड किए गए disposition के साथ nonconformance में जाता है। इनमें से हर स्टेप रिकॉर्ड होता है और, जहाँ ज़रूरी हो, साइन होता है। रिलीज़ तभी होती है जब सूची ख़ाली हो, और यह जाँच साइन करने के क्षण पर फिर से चलती है, सिर्फ़ स्क्रीन खुलने के समय नहीं।

ज़िम्मेदारियों का बँटवारा: preparer कभी approver नहीं होता

ग्राहक तक पहुँचने वाली ज़्यादातर quality गड़बड़ियाँ धोखाधड़ी नहीं होतीं। वे एक काबिल, व्यस्त व्यक्ति का अपना ही काम जाँचना होती हैं। ज़िम्मेदारियों का बँटवारा (separation of duties) सबसे सस्ता बचाव है, और सॉफ़्टवेयर को इसे procedure के भरोसे छोड़ने के बजाय लागू करना चाहिए:

• जो व्यक्ति मटीरियल लॉट रिसीव करता है, वह उसे इस्तेमाल के लिए रिलीज़ नहीं कर सकता।
• जिस ऑपरेटर ने job चलाया, जिस व्यक्ति ने उसे बनाया, और जिसने भी उसे संभाला — कोई भी उसका आउटपुट रिलीज़ नहीं कर सकता।
• जिस इंजीनियर ने first article तैयार किया, वह उसे approve नहीं कर सकता।
• जिस व्यक्ति ने कैलिब्रेशन रिकॉर्ड किया, वह उसे approve नहीं कर सकता।
• Nonconformance disposition के लिए दो लोग चाहिए, Quality और Engineering, material review board के रूप में।

रिलीज़ ख़ुद सिर्फ़ Quality रोल तक सीमित है। हर request पर रोल सर्वर पर जाँचे जाते हैं, इसलिए यूज़र और हस्ताक्षर के बीच सिर्फ़ इंटरफ़ेस में छिपा बटन ही अकेली रुकावट नहीं है।

Reject हुआ, तो reject ही रहता है

Clause 8.7 यह पक्का करने के बारे में है कि nonconforming प्रोडक्ट ग़लती से ग्राहक तक न पहुँचे। ज़्यादातर सिस्टम का सबसे कमज़ोर बिंदु यह है कि rejection सिर्फ़ एक status है, और status वापस बदला जा सकता है।

Rejection कारण के साथ साइन किया गया फ़ैसला होना चाहिए, रिलीज़ वाले ही हस्ताक्षर नियमों के तहत, और उस यूनिट के लिए अंतिम: न सर्टिफ़िकेट, न बाद में रिलीज़, न किसी shipment में जाने का कोई रास्ता। अगर मटीरियल सच में इस्तेमाल हो सकता है, तो वह review board का nonconformance disposition है ("use as is" या "rework"), जो दो लोगों द्वारा रिकॉर्ड और साइन होता है — न कि कोई चुपचाप status वापस पलट दे।

यही तर्क पीछे के स्टेप्स पर भी लागू होता है। Incoming inspection में reject हुआ मटीरियल लॉट कभी किसी मशीन से बाँधा नहीं जा सकना चाहिए। जो रोल out-time पार कर चुके लॉट से बना, उसे सिर्फ़ reject किया जा सकता है।

Finished goods लॉट में क्या दिखना चाहिए

ग्राहक लॉट ऑर्डर करते हैं, और एक लॉट में आमतौर पर कई रोल या पार्ट होते हैं। जब कुछ यूनिट रिलीज़ हो चुकी हों, कुछ reject और कुछ अभी लैब रिज़ल्ट के इंतज़ार में हों, तो लॉट व्यू को ठीक यही दिखाना चाहिए, यूनिट-दर-यूनिट: released, rejected, awaiting QA। तब shipping सिर्फ़ रिलीज़ हुई यूनिट उठाती है, और reject हुआ रोल ग़लती से shipment में नहीं जोड़ा जा सकता।

यही certificate of conformance को भी भरोसेमंद बनाता है। साइन किए गए रिकॉर्ड से बना सर्टिफ़िकेट — जिसमें रोल की पहचान, रेसिपी revision, लैब रिज़ल्ट, इस्तेमाल हुए इंस्ट्रूमेंट और रिलीज़ करने वाला व्यक्ति दर्ज हो — evidence है। बाद में किसी word-processor टेम्पलेट में टाइप किया गया सर्टिफ़िकेट किसी की याददाश्त की नक़ल भर है।

सिर्फ़ कंपोज़िट्स नहीं

यूनिट जो भी हो, नियम वही हैं। मशीनिंग वाले पार्ट के लिए रिलीज़ हर serial नंबर या लॉट पर होती है, पार्ट नंबर के approved first article और कैलिब्रेटेड गेज के बाद। Heat treatment, plating और NDT जैसे स्पेशल प्रोसेस में हर furnace या bath लोड का अपना रिकॉर्ड और अपनी साइन की हुई रिलीज़ होती है। असेंबली में serial नंबर वाली असेंबली अपने पीछे के हर कंपोनेंट के लॉट के साथ रिलीज़ होती है। पूरा फ़्लो देखने के लिए AS9100 मैन्युफैक्चरिंग overview देखें।

PulseMQ यह कैसे करता है

PulseMQ में Quality किसी यूनिट को उसकी रिकॉर्ड स्क्रीन से रिलीज़ करता है। रिलीज़ कार्ड खुलने पर, और फिर साइन करते समय, सर्वर ऊपर दिए हर blocker को जाँचता है; अगर एक भी fail होता है, तो कारण सूचीबद्ध होते हैं और कुछ भी साइन नहीं होता। हस्ताक्षर के लिए पासवर्ड, authenticator app का कोड और एक कारण माँगा जाता है, और यह सेव किए गए सटीक रिकॉर्ड से version और hash के ज़रिए बँधता है। Reject हुई यूनिट को कोई सर्टिफ़िकेट नहीं मिलता और वह बाद में रिलीज़ नहीं हो सकती। Finished goods व्यू हर यूनिट के लिए released, rejected और awaiting QA दिखाता है, और certificate of conformance साइन किए गए रिकॉर्ड से बनता है। हर कार्रवाई एक hash-chained audit trail में दर्ज होती है।

जिस रिकॉर्ड पर साइन होता है, उसका वर्णन कंपोज़िट लाइनों के लिए रोल-स्तर की ट्रेसेबिलिटी में है, और first article व कैलिब्रेशन गेट first article inspection और कैलिब्रेशन में बताए गए हैं। एयरोस्पेस के बाहर लॉट genealogy के सामान्य मामले के लिए देखें बैच ट्रैकिंग और ट्रेसेबिलिटी।

PulseMQ, clauses 8.6 और 8.7 के लिए evidence रखता है। यह किसी प्लांट को compliant नहीं बनाता, न ही certify करता है; यह निर्माता की ज़िम्मेदारी रहती है, और पायलट के दौरान PulseMQ को आपकी अपनी प्रोसेस पर qualify किया जाता है।

अक्सर पूछे जाने वाले सवाल

इलेक्ट्रॉनिक रिलीज़ हस्ताक्षर को भरोसेमंद क्या बनाता है?
यह व्यक्ति की पहचान एक से ज़्यादा factor से करता है (जैसे पासवर्ड और authenticator app का कोड), एक कारण रिकॉर्ड करता है, और रिकॉर्ड के ठीक उसी version से बँधा होता है जिसे रिव्यू किया गया, ताकि रिकॉर्ड में बाद का कोई बदलाव approval को विरासत में पाने के बजाय मेल तोड़ दे।

क्या quality रिलीज़ को कभी override किया जा सकना चाहिए?
Override एक control को सिर्फ़ सुझाव बना देता है। अगर रिलीज़ रुकी है, तो blocker को ठीक किया जाना चाहिए या प्रोडक्ट का disposition nonconformance प्रोसेस से होना चाहिए, जो ख़ुद रिकॉर्ड और साइन होता है। Override बटन वाला रिलीज़ चेक इस बात का evidence है कि चेक को बायपास किया जा सकता है।

क्या reject हुआ रोल बाद में रिलीज़ हो सकता है?
नहीं होना चाहिए। Rejection, clause 8.7 के तहत एक disposition है। अगर बाद की रिलीज़ से फ़ैसला पलटा जा सकता है, तो प्लांट यह नहीं दिखा सकता कि nonconforming प्रोडक्ट को इस्तेमाल या डिलीवरी से रोका गया।

प्रोडक्ट रिलीज़ करने की अनुमति किसे होनी चाहिए?
Quality का कोई अधिकृत व्यक्ति, जिसने approve किया जा रहा रिकॉर्ड न बनाया हो, न तैयार किया हो। Job चलाने वाला ऑपरेटर, उसे बनाने वाला व्यक्ति, और जिसने भी उसे संभाला हो — इनमें से कोई उसका आउटपुट रिलीज़ नहीं कर पाना चाहिए।