विशेष उपकरण किराया सॉफ़्टवेयर: अपने हायर बिज़नेस के अनुसार सॉफ़्टवेयर कैसे कॉन्फ़िगर करें

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

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

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

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

यही सवाल है जिसका जवाब देने की कोशिश यह लेख करता है।

जब कोई विशेष किराया बिज़नेस सामान्य बिज़नेस के लिए बने सॉफ़्टवेयर पर चलने की कोशिश करता है, तो तीन पैटर्न बार-बार सामने आते हैं।

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

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

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

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

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

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

दूसरा हिस्सा है क़ानूनी परीक्षण और निरीक्षण प्रीसेट जो उससे मेल खाते हों जो उपकरण को वाक़ई चाहिए। अलग-अलग उपकरण श्रेणियाँ अलग-अलग व्यवस्थाओं के तहत आती हैं - यूके में लिफ़्टिंग उपकरण निरीक्षण (LOLER), पोर्टेबल उपकरण परीक्षण (PAT), अमेरिका में OSHA-आधारित निरीक्षण ज़रूरतें, ऑस्ट्रेलिया में Test & Tag परंपराएँ, वग़ैरह। सॉफ़्टवेयर जिसे किसी उपकरण पर वाक़ई लागू होने वाली क्षेत्रीय और श्रेणी-विशिष्ट व्यवस्था पर सेट किया जा सके, न कि सबके लिए एक ही सामान्य अनुपालन फ़ॉर्म दिया जाए, इसका मतलब है कि निरीक्षण रिकॉर्ड असली ज़रूरतों को दर्शाता है, न कि उनका मोटा-मोटा अनुमान।

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

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

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

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

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

कॉन्फ़िगरेबिलिटी की सीमाओं के बारे में ईमानदार रहना ज़रूरी है, क्योंकि इसे बढ़ा-चढ़ाकर पेश करना विशेष बिज़नेसों के साथ नाइंसाफ़ी है।

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

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

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

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

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

जिस विशेष बिज़नेस को अंततः Renttix को अपनी निश से जुड़े दूसरे सिस्टम से बात करवाने की ज़रूरत पड़ती है - जैसे कोई शेड्यूलिंग टूल, कोई एसेट-ट्रैकिंग सिस्टम, या उद्योग-विशिष्ट सॉफ़्टवेयर - उसके लिए Renttix एक डॉक्यूमेंटेड REST API भी देता है, जो ठीक उसी तरह के बिज़नेस के लिए अहम है जिसकी यह लेख बात कर रहा है: वह जिसका वर्कफ़्लो किसी मानक किराया प्लेटफ़ॉर्म की सीमाओं पर रुकता नहीं।

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