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

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

एसेट रजिस्टर: वह नींव जिसके बिना कुछ नहीं चलता

एक सरल प्रश्न के सटीक उत्तर के बिना कोई प्रिवेंटिव मेंटेनेंस नहीं होता: आप ठीक-ठीक किसका रखरखाव कर रहे हैं, और वह कहाँ है? एसेट रजिस्टर ही वह उत्तर है, और यह साल में एक बार अपडेट होने वाली स्प्रेडशीट नहीं है। यह वह रिकॉर्ड है जिससे हर प्लान, हर विज़िट, हर स्पेयर पार्ट और हर लागत जुड़ी होती है।

हर एसेट के लिए न्यूनतम जानकारी:

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

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

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

प्लान और चेकलिस्ट: तकनीशियन वास्तव में क्या करता है

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

चेकलिस्ट विज़िट की सामग्री है। उपयोगी और बेकार चेकलिस्ट में अंतर यह है कि उपयोगी चेकलिस्ट डेटा देती है: यूनिट जाँची गई लिखने के बजाय वह प्रेशर रीडिंग, तापमान का अंतर, करंट ड्रॉ, फ़िल्टर की स्थिति दर्ज करती है — फ़ील्ड में संख्याओं के रूप में, खुले टेक्स्ट के रूप में नहीं। संख्याएँ जमा होती हैं और रुझान दिखाती हैं; खुला टेक्स्ट कागज़ ही रहता है।

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

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

विज़िट कब ट्रिगर करें: कैलेंडर बनाम रनटाइम और मीटर रीडिंग

किसी प्लान को ट्रिगर करने के दो तरीके हैं, और इन्हें आपस में मिलाना एक आम कारण है कि मेंटेनेंस पर पैसा खर्च होता है पर खराबियाँ नहीं रुकतीं।

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

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

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

अनुबंध में वादा किया गया समय, मैनेजर के दिमाग वाला नहीं

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

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

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

कंडीशन-आधारित और प्रेडिक्टिव मेंटेनेंस: क्या यथार्थवादी है और क्या विक्रेताओं की बातें

ये दोनों शब्द आज कॉन्ट्रैक्टिंग और मेंटेनेंस कंपनियों को ज़ोर-शोर से बेचे जा रहे हैं, और इन्हें स्पष्ट रूप से अलग करना ज़रूरी है।

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

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

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

Origami का दृष्टिकोण

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

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

यह आपको कहाँ छोड़ता है

प्रिवेंटिव मेंटेनेंस दीवार पर टँगा कोई शेड्यूल नहीं है। यह तीन जुड़ी हुई परतें हैं: परिभाषित एसेट्स, ऐसे प्लान जो अपने वर्क ऑर्डर खुद बनाते हैं, और ऐसी चेकलिस्ट जो जमा होती संख्याएँ देती हैं। जब ये परतें मौजूद होती हैं, तो आपकी टीमों के काम का बढ़ता हिस्सा अचानक के बजाय नियोजित हो जाता है, और केवल इतना ही आपातकालीन विज़िट्स घटा देता है और वह समय खाली कर देता है जो पहले आग बुझाने में जल जाता था।

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

स्रोत