यूनिट का स्टेटस: एक ही स्रोत जिसे सब देख सकें

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

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

हर यूनिट किसी भी समय ठीक एक ही स्टेटस में होती है

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

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

सूची पर एक नियम लागू होता है: कोई यूनिट किसी भी समय ठीक एक ही स्टेटस में होती है, और अज्ञात नाम का कोई स्टेटस नहीं होता। अगर किसी यूनिट का स्टेटस किसी को पता नहीं, तो वह खाली सेल नहीं है — वह किसी नामित व्यक्ति के लिए एक ज़रूरी काम है। स्प्रेडशीट का खाली सेल किसी को परेशान नहीं करता, और ठीक इसी वजह से वह महीनों खाली रहता है।

स्प्रेडशीट किसी स्थिति को क्यों नहीं दर्शा सकती

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

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

ध्यान दें कि इनमें से कुछ भी Excel की कमी नहीं है। Excel गणना का एक बेहतरीन टूल है; यह संचालन का टूल नहीं है। समस्या तब शुरू होती है जब हम स्प्रेडशीट से लोगों के बीच समय के साथ चलने वाले दायित्वों को संभालने के लिए कहते हैं।

हर स्टेटस बदलाव के साथ क्या होना चाहिए

यह पूरे भाग का व्यावहारिक केंद्र है। स्टेटस बदलना किसी फ़ील्ड को अपडेट करना नहीं; यह एक पूरी परिचालन घटना है। और हर घटना के साथ चार चीज़ें होनी चाहिए, वरना वह बस एक दर्ज की गई अफ़वाह है:

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

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

पोर्टफ़ोलियो के लिए एक स्क्रीन, हर इमारत के लिए अलग फ़ाइल नहीं

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

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

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

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

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

इस हफ़्ते आप क्या कर सकते हैं

पहले सुधार के लिए कुछ भी ख़रीदने की ज़रूरत नहीं। इसके लिए छोटे फ़ैसले चाहिए, लिखे हुए और अपनाए हुए:

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

अगले भाग में

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

स्रोत