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

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

सबसे पहले: अनुरोध प्राप्त करने का एक ही चैनल

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

इसका मतलब ग्राहकों को संदेश भेजने से रोकना नहीं है। इसका मतलब है कि जिसे संदेश मिलता है, वह किसी भी तकनीशियन के निकलने से पहले उसे वर्क ऑर्डर में बदलने के लिए ज़िम्मेदार है। व्यवहार में, जो कंपनियाँ इसे टिकाऊ बना पाती हैं, वे तीन काम एक साथ करती हैं:

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

अनुरोध नंबर: वह फ़ील्ड जिस पर बाकी सब कुछ टिका है

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

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

स्थिति और ज़िम्मेदार व्यक्ति: यह अनुरोध इस समय किसके पास है

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

और हर अनुरोध का एक नामित ज़िम्मेदार व्यक्ति होता है। जो अनुरोध पूरी टीम का है, वह किसी का नहीं है। ज़िम्मेदार व्यक्ति ज़रूरी नहीं कि काम करने वाला ही हो; वह वह व्यक्ति है जो जवाब देता है जब ग्राहक पूछता है कि मामला कहाँ तक पहुँचा।

रिस्पॉन्स टाइम: लिखित प्रतिबद्धता, मौखिक वादा नहीं

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

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

साइट पर क्या दर्ज होता है: नोट्स, फ़ोटो, हस्ताक्षर

यह वह हिस्सा है जिसकी क़ीमत आप आज नहीं, महीनों बाद चुकाते हैं। काम करते समय साइट पर तीन चीज़ें दर्ज की जाती हैं:

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

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

वेरिएशन: करने से पहले दस्तावेज़ बनाएँ

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

वर्क ऑर्डर से बिल और भुगतान आवेदन तक

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

अनुपालन की दृष्टि से, सऊदी अरब में ई-इनवॉइसिंग के तहत आपको ऐसा इलेक्ट्रॉनिक बिल जारी करना होता है जो किसी वास्तविक लेनदेन से जुड़ा हो और ज़कात, कर और सीमा शुल्क प्राधिकरण (ZATCA) के प्लेटफ़ॉर्म के साथ एकीकृत हो। जब आपके बिल की लाइनों का स्रोत बंद और दस्तावेज़ीकृत वर्क ऑर्डर होते हैं, तो अनुपालन महीने के आख़िर का अतिरिक्त काम न रहकर आपके काम करने के तरीक़े का एक सहज परिणाम बन जाता है।

Origami का नज़रिया

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

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

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

आगे क्या

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

स्रोत