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