उपकरण केलिब्रेशन शेड्यूलर: अलर्ट और प्रमाणपत्र भंडारण

क्यों वास्तविक टीमों में केलिब्रेशन छूट जाता है

केलिब्रेशन सामान्यतः इसलिए नहीं छूटता कि लोग परवाह नहीं करते। यह इसलिए छूटता है क्योंकि “सिस्टम” अक्सर एक स्प्रेडशीट, कुछ कैलेंडर रिमाइंडर और एक ईमेल थ्रेड होता है जिसे केवल एक ही व्यक्ति ढूँढ पाता है।

स्प्रेडशीट जल्दी पुरानी हो जाती हैं। एक टैब सही दिख सकता है जब तक कोई इंटरवल बदलता नहीं, उपकरण बदलता नहीं, या पिछले साल की शीट कॉपी करके एक रो भूल नहीं जाता। ईमेल इससे भी खराब है। निर्णय इनबॉक्स में बिखर जाते हैं, और आप पुराने संदेशों में खोदकर ही उनका ऑडिट कर पाते हैं।

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

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

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

एक केलिब्रेशन शेड्यूलर को एक काम अच्छा करना चाहिए: इंटरवल, अगली ड्यू डेट, रिमाइंडर नियम और सबूत (सर्टिफिकेट फ़ाइलें और मुख्य डिटेल्स) एक जगह रखे, और इन्हें उसी उपकरण रिकॉर्ड से जुड़ा रखें।

हर उपकरण के लिए क्या ट्रैक करें

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

न्यूनतम, यह कैप्चर करें जो एसेट की पहचान और उसका मालिक बताता है:

• एसेट ID (आपका आंतरिक टैग, और यदि है तो सीरियल नंबर)
• उपकरण का नाम और मॉडल (जिसे लोग रोज कहते हैं)
• स्थान (साइट, कमरा, लाइन, विभाग)
• मालिक (निर्धारित करने वाले व्यक्ति या टीम)
• कैलिब्रेशन इंटरवल और विधि

इंटरवल्स वह जगह है जहां भ्रम शुरू होता है। कैलेंडर-आधारित इंटरवल सीधे होते हैं (हर 30 दिन, 6 महीने, 1 साल)। उपयोग-आधारित इंटरवल के लिए भरोसेमंद काउंटर चाहिए (उपयोग घंटे, साइकिल)। अगर आप उपयोग ट्रैक करते हैं, तो तय करें कि नंबर कहाँ से आएगा ताकि लोग अनुमान न लगाएँ। इवेंट-आधारित इंटरवल ऐसे ट्रिगर कवर करते हैं जैसे मरम्मत के बाद, झटका के बाद, या स्थानांतरण के बाद। उन ट्रिगर्स को “अब एक कैलिब्रेशन टास्क बनाओ” के रूप में देखें, न कि किसी भविष्य की तारीख के रूप में।

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

साफ़ स्टेटस लेबल डैशबोर्ड्स को उपयोगी रखते हैं। एक सरल सेट अक्सर पर्याप्त है: In service, Due soon, Overdue, Out of service, Under repair.

उदाहरण: एक टॉर्क रेंच लाइन A से लाइन C में चला जाता है। अगर स्थान, मालिक और इंटरवल एसेट रिकॉर्ड पर रहते हैं, तो जिम्मेदारी मूव के साथ जाती है और अलर्ट सही टीम को ही मिलते हैं।

एक सरल डेटा स्ट्रक्चर डिज़ाइन करें जो बाद में टूटे नहीं

अगर आपका डेटा मॉडल गन्दा है, तो अलर्ट और ऑडिट भी गंदे होंगे। हर एसेट के लिए एक स्पष्ट रिकॉर्ड रखें, और जो कुछ भी उसके साथ हुआ उसका एक साफ़ टाइमलाइन रखें।

एक यूनिक पहचान चुनें और उसे बदलें नहीं। आंतरिक एसेट टैग आमतौर पर सबसे अच्छा है। अगर लेबल झड़ जाते हैं, तो मैन्युफैक्चरर सीरियल नंबर सेकेंडरी फ़ील्ड के रूप में रखें।

उपकरण रिकॉर्ड स्थिर रखें, और समय-आधारित चीज़ें हिस्ट्री में रखें। एक बुनियादी उपकरण रिकॉर्ड आमतौर पर शामिल करता है:

• Equipment ID (asset tag)
• नाम और श्रेणी (Pressure Gauge, Scale, Pipette)
• साइट और विभाग (कहाँ रहता है और किसका है)
• स्टेटस (active, out of service, retired)
• कैलिब्रेशन विधि और इंटरवल (जैसे हर 6 महीने, external vendor)

फिर कैलिब्रेशन हिस्ट्री को अलग टाइमलाइन के रूप में ट्रैक करें जहाँ हर कैलिब्रेशन अपना रिकॉर्ड हो। एक “Calibration Event” एंट्री में इवेंट तारीख, अगली ड्यू डेट, परिणाम (pass/fail), प्रोवाइडर और नोट्स शामिल हो सकते हैं। इससे ऑडिट आसान होते हैं क्योंकि आप पूरा ट्रेल दिखा सकते हैं बिना पुराने मान ओवरराइट किए।

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

सर्टिफिकेट को खोजने योग्य रखने के लिए, हर फ़ाइल के साथ थोड़ा मेटाडेटा रखें: दस्तावेज़ प्रकार (certificate, service report, photo), दस्तावेज़ संख्या, जारी करने की तारीख और जारीकर्ता, और किस इवेंट को यह सपोर्ट करता है। कुछ नियंत्रित टैग (जैसे “as found” और “as left”) मदद कर सकते हैं बिना फ्री-टेक्स्ट अफरा-तफरी में बदले।

उदाहरण: एक लैब में तीन समान बैलेंस अलग-ग- अलग कमरों में हैं। अगर पहचान सिर्फ “Balance” है, तो प्रमाणपत्र गड़बड़ा जाएगा। एसेट टैग B-104, B-105, और B-106 के साथ, हर कैलिब्रेशन इवेंट और सर्टिफिकेट सही यूनिट से जुड़ जाते हैं और अलर्ट सटीक रहते हैं।

बिल्ड करने से पहले अपने अलर्ट नियम तय करें

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

लीड टाइम से शुरू करें। कई टीमें कई रिमाइंडर उपयोग करती हैं क्योंकि लोग संदेश मिस कर देते हैं, बीमार हो जाते हैं, या बस व्यस्त होते हैं। 30 दिन का हेड्स-अप विक्रेता बुक करने में मदद करता है। 14 दिन की याददिहानी योजना की पुष्टि में मदद करती है। 7 दिन का रिमाइंडर अंतिम धक्का है।

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

एक सरल एस्केलेशन पैटर्न:

• 30 दिन: मालिक + टीम मेलबॉक्स
• 14 दिन: मालिक + बैकअप
• 7 दिन: मालिक + बैकअप + टीम मेलबॉक्स
• ड्यू डेट: टीम मेलबॉक्स + मैनेजर
• ओवरड्यू: मैनेजर एस्केलेशन

उन नोटिफिकेशन मार्गों को चुनें जो आपकी टीम के काम करने के तरीके से मिलते हों। ईमेल सेटअप में आसान है और अनदेखा भी किया जा सकता है। SMS कम अनदेखा होता है। Telegram उन ऑप्स टीमों के लिए अच्छा हो सकता है जो पहले से इसका उपयोग करती हैं। ऑडिट के लिए एक साफ ओपन/क्लोज रिकॉर्ड चाहिए तो एक आंतरिक टास्क लिस्ट उपयोगी है।

अंत में, रिपीट और एस्केलेशन नियम पर निर्णय लें। ड्यू डेट के बाद कुछ दिनों पर दोहराना और एक सप्ताह के बाद एस्केलेट करना अक्सर काफी सख्त होता है बिना अलर्ट थकान पैदा किए। रोजाना रिमाइंडर लोगों को नज़रअंदाज़ करने की आदत डाल देता है।

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

चरण-दर-चरण: एक बुनियादी कैलिब्रेशन शेड्यूलिंग वर्कफ़्लो

एक भरोसेमंद वर्कफ़्लो फैंसी फीचर्स का नहीं, बल्कि हर बार एक ही कदमों को होने देने और ऑडिटर को दिखाने लायक साफ ट्रेल रखने का मामला है।

हर उपकरण को एक छोटा प्रोजेक्ट मानें। जब एक नया टूल आता है, तो जिम्मेदार कौन है और उस डिवाइस के लिए "समय पर" का मतलब क्या है, यह कैप्चर करें।

एक बुनियादी वर्कफ़्लो:

• एसेट रजिस्टर करें (ID टैग, स्थान, मॉडल/सीरियल) और एक मालिक असाइन करें।
• कैलिब्रेशन इंटरवल सेट करें और आखिरी ज्ञात कैलिब्रेशन के आधार पर अगली ड्यू डेट रिकॉर्ड करें।
• अगला टास्क तुरंत बनाएं और स्पष्ट स्टेटस रखें (Planned, Due soon, Overdue, Completed)।
• जब कैलिब्रेशन हो जाए, तो टास्क बंद करें और प्रमाणपत्र व कोई मुख्य नोट्स (जैसे as found/as left रीडिंग्स) अटैच करें।
• सहमति वाले नियम से अगली ड्यू डेट की गणना करें और अगला साइकिल तुरन्त बना दें।

एक विवरण जो बाद में बहुत विवाद रोकता है: तय करें कि कौन सी तारीख शेड्यूल चलाती है। कुछ टीमें विक्रेता द्वारा प्रदर्शन की तारीख उपयोग करती हैं। अन्य लोग उपकरण सेवा में लौटने की तारीख उपयोग करते हैं। एक नियम चुनें और उसे लिखें।

यदि उपकरण निकालकर सर्विस पर जा सकता है, तो एक सरल स्टेटस जोड़ें जैसे Under repair या Retired। इससे अनावश्यक अलर्ट बंद हो जाते हैं पर इतिहास बना रहता है।

उदाहरण: एक क्वालिटी मैनेजर शुक्रवार को एक टॉर्क रेंच कैलिब्रेट करता है, PDF प्रमाणपत्र अपलोड करता है और टास्क बंद कर देता है। अगली ड्यू डेट कैल्कुलेट हो जाती है और अगला टास्क स्वतः बन जाता है, बिना किसी को नये रिमाइंडर मैन्युअली सेट करने के।

प्रमाणपत्र भंडारण: खोजने योग्य और ऑडिट-फ्रेंडली बनाएं

एक कैलिब्रेशन प्रमाणपत्र तभी मदद करता है जब आप सही प्रमाण पत्र सेकंडों में ढूँढ सकें। प्रमाणपत्र भंडारण को शेड्यूलर का हिस्सा मानें, न कि उस फ़ोल्डर को जहाँ PDF गायब हो जाते हैं।

अपलोड के समय सही डिटेल्स कैप्चर करें

कुछ फ़ील्ड पूछें जो बाद में मायने रखते हैं। छोटा रखें ताकि लोग वास्तव में भरें।

• कैलिब्रेशन तारीख (प्रमाणपत्र से)
• प्रोवाइडर (विक्रेता नाम या आंतरिक लैब)
• सर्टिफिकेट नंबर
• रिज़ल्ट/स्टेटस (pass, fail, limited, adjusted)
• नोट्स (as found/as left, उपयोग किए गए स्टैण्डर्ड, अपवाद)

साथ ही अपलोडेड बाय और अपलोडेड एट को ऑटोमैटिक रिकॉर्ड करें। अगर कोई फ़ाइल महीनों बाद जोड़ी जाती है, तब भी आप जानते हैं कि किसने और कब की।

प्रमाणपत्र खोजने में आसान बनाएं

खोज तभी काम करती है जब पहचान consistent हो। हर प्रमाणपत्र को एसेट ID (asset tag) से जोड़ें। फ़ाइल के लिए एक सरल नामकरण नियम उपयोग करें ताकि यह सिस्टम के बाहर भी समझ में आए, उदाहरण: EquipmentID_CalDate_Provider_CertNo.pdf।

टैग मदद कर सकते हैं, पर नियंत्रित रखें। छोटा पिकलिस्ट फ्री-टेक्स्ट से बेहतर है जो दस अलग- अलग वर्तनी में बदल जाता है।

संशोधनों को बिना इतिहास खोए हैंडल करें

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

ऑडिटर्स क्या मांगते हैं (और तेज़ी से कैसे जवाब दें)

ऑडिटर्स आमतौर पर यह देखना चाहते हैं कि किसी उपकरण का किसी समय पर कैलिब्रेशन वैध था और प्रमाणपत्र वही उपकरण से मेल खाता है।

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

अगर आप एसेट ID, कैलिब्रेशन तारीख और प्रोवाइडर से फ़िल्टर कर सकते हैं, तो आप अधिकांश अनुरोधों का उत्तर एक मिनट से कम में दे सकते हैं।

सामान्य गलतियाँ जो अनुपालन छूट का कारण बनती हैं

अधिकांश अनुपालन समस्याएँ लापरवाही से नहीं होतीं। वे छोटे प्रोसेस गैप्स से आती हैं जो समय के साथ इकट्ठा हो जाती हैं जब तक कि कोई ऑडिट या घटना घबराहट न पैदा करे।

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

प्रमाणपत्र फैलाव (sprawl) एक और सामान्य अपराधी है। अगर प्रमाणपत्र किसी के इनबॉक्स या एक साझा ड्राइव "Calibration stuff" में रहते हैं, तो ट्रैसेबिलिटी टूट जाती है। आप एक PDF पा सकते हैं, पर आपको नहीं पता कि क्या वह नवीनतम संस्करण है, क्या वह सीरियल नंबर से मेल खाता है, या यह किस एसेट का है।

बार-बार दिखने वाली समस्याएँ:

• केवल वर्तमान ड्यू डेट रखना बजाय पूर्ण कैलिब्रेशन इतिहास के
• प्रमाणपत्र अपलोड करना बिना खोजने योग्य मेटाडेटा के (एसेट ID, विक्रेता, तारीख, रिज़ल्ट)
• रिमाइंडर केवल एक व्यक्ति को भेजना
• जीवनचक्र अपवादों (नया उपकरण, मरम्मत किए गए एसेट, डी-कमीशन) को भूल जाना
• बिना एस्केलेशन के केवल एक रिमाइंडर का उपयोग

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

समाधान साधारण होता है: हर कैलिब्रेशन को अपना इवेंट रिकॉर्ड रखें, प्रमाणपत्र उसी इवेंट से अटैच करें, और नोटिफिकेशन रोल या ग्रुप को भेजें (एक अकेले इनबॉक्स की जगह) जिसमें बैकअप भी हो।

भरोसा करने से पहले एक त्वरित चेकलिस्ट

शेड्यूलर को अपने सिस्टम ऑफ रिकॉर्ड मानने से पहले एक त्वरित रियलिटी चेक करें। अगर कोई बीमार है, ऑडिटर सवाल पूछे, या स्प्रेडशीट गायब हो जाए, तब भी आपको यह साबित करना चाहिए कि क्या ड्यू है, क्या किया गया और सबूत कहाँ है।

कवरिज से शुरू करें। एक यादृच्छिक दिन और एक यादृच्छिक कमरा चुनें, फिर जो फिजिकल वहाँ है उसे आपकी सूची से मिलाइए। अगर कोई टूल सूची में नहीं है, तो उसे शेड्यूल नहीं किया जा सकता।

कुछ छोटे चेक अधिकांश समस्याओं को जल्दी पकड़ लेते हैं:

• हर सक्रिय एसेट का नामित मालिक और एक स्पष्ट अगली ड्यू डेट है।
• आपका Due soon विंडो परिभाषित है और सैंपल तारिखों से टेस्ट किया गया है।
• ओवरड्यू आइटम एक स्क्रीन पर अदृश्य नहीं हो सकते, और काउंट एक सरल "past due" फ़िल्टर से मेल खाता है।
• हर पूरा किया गया कैलिब्रेशन सही इवेंट के साथ प्रमाणपत्र संलग्न है।
• आप एक एसेट खोलकर उसकी पूरी कैलिब्रेशन हिस्ट्री एक मिनट से कम में खींच सकते हैं।

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

उदाहरण: एक टीम कैसे ऑडिट घबराहट से बचती है

एक छोटी QA टीम के पास दो साइटों में बँटे 40 उपकरण हैं: साइट A (उत्पादन) और साइट B (इनकमिंग इंस्पेक्शन)। वे पहले कैलिब्रेशन स्प्रेडशीट में ट्रैक करते थे, और वही समस्या बार-बार होती रही: कोई व्यक्ति तभी नोटिस करता था जब उपकरण बेन्च पर होता।

वे एक सरल शेड्यूलर पर स्विच करते हैं जहाँ हर डिवाइस एक रिकॉर्ड है जिसमें ड्यू डेट, मालिक, साइट और नवीनतम प्रमाणपत्र अटैच होता है।

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

उनकी साप्ताहिक लय सरल है: 30 दिनों में ड्यू आइटम प्लान करें, 14 दिन में पुष्टि करें, 7 दिन में एस्केलेट करें, और किसी भी ओवरड्यू आइटम पर उपयोग ब्लॉक करें।

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

बाद में, ऑडिटर पूछता है: “पिछले महीने साइट B में उपयोग हुए डिवाइस TP-17 के लिए नवीनतम प्रमाणपत्र दिखाओ।” टीम एसेट ID और साइट से फ़िल्टर करती है, नवीनतम कैलिब्रेशन रिकॉर्ड खोलती है और सेकंडों में प्रमाणपत्र निकाल लेती है। किसी PDF के सही होने का अनुमान नहीं, और न ही ईमेल खोजबीन।

अगले कदम: प्रक्रिया को एक सरल आंतरिक ऐप में बदलें

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

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

पहले संस्करण के लिए कुछ स्क्रीन अक्सर पर्याप्त होते हैं: फिल्टर के साथ एक उपकरण सूची, Due soon/Overdue व्यू, एक उपकरण हिस्ट्री पेज, और एक टास्क पेज जो आवश्यक होने पर क्लोज करने से पहले प्रमाणपत्र माँगता है।

समय-समय पर एक हल्का मासिक रूटीन जोड़ें ताकि समस्याएँ छिप न सकें। 15 मिनट की समीक्षा एक मालिक के साथ ओवरड्यू आइटम, आवर्ती ब्लॉकर (विक्रेता देरी, गायब प्रमाणपत्र, उपकरण सर्विस पर) और किसी भी एसेट जिनके इंटरवल बदलने चाहिए, को कवर कर सकती है।

अगर आप इसे बिना बड़े विकास प्रोजेक्ट के बनाना चाहते हैं, तो AppMaster एक व्यावहारिक विकल्प है। यह आपको उपकरण, कैलिब्रेशन इवेंट्स और अटैचमेंट्स को PostgreSQL-backed Data Designer में मॉडल करने देता है, फिर विज़ुअल Business Process Editor में वर्कफ़्लो और रिमाइंडर ऑटोमेट कर सकता है।

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