मैनुअल अप्रूवल वर्कफ़्लो सॉफ़्टवेयर: पहले प्रक्रिया मैप करें

क्यों ईमेल अप्रूवल गड़बड़ हो जाते हैं

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

पहली समस्या दृश्यता (visibility) की है। अप्रूवल अनुरोध न्यूज़लेटर्स, कैलेंडर इनवाइट्स और रोज़मर्रा के संदेशों के बीच बैठे रहते हैं। कोई कहता है कि बाद में देखूंगा, फिर वह थ्रेड इनबॉक्स में नीचे चला जाता है और गायब हो जाता है।

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

ऑनरशिप भी धुंधली हो जाती है। अगर अनुरोध को finance, legal और टीम लीड की इनपुट चाहिए, तो जब यह रुकता है तो कौन जिम्मेदार है? ईमेल में अक्सर इसका स्पष्ट जवाब नहीं मिलता। लोग मान लेते हैं कि कोई और संभाल रहा होगा, और तब कुछ नहीं होता।

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

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

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

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

सेटिंग्स छूने से पहले असली प्रक्रिया मैप करें

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

छोटे से शुरू करें। एक साथ हर अप्रूवल फ्लो नहीं ले जाएँ। एक ऐसी प्रक्रिया चुनें जो अक्सर होती हो, देरी पैदा करती हो, या सबसे ज़्यादा फ़ॉलो-अप बनाती हो—जैसे खरीद अनुरोध, कंटेंट साइन-ऑफ़, छूट अप्रूवल, या एक्सेस अनुरोध।

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

उन उदाहरणों की समीक्षा करते हुए, सामान्य भाषा में मूल बातें कैप्चर करें:

• अनुरोध कैसे शुरू होता है
• कौन पहले समीक्षा करता है
• कौन अगला अप्रूव करता है
• कहाँ यह रुकता या लूप-बैक होता है
• यह कैसे समाप्त होता है

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

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

पूरी प्रक्रिया को एक पन्ने पर लोगों की बोली में रखें। लिखें "Finance checks the amount" या "Manager asks for missing details," न कि कुछ अमूर्त और सिस्टम-जैसा। लक्ष्य ऐसा मानचित्र बनाना है जिसे लोग पहचानें, न कि एक पॉलिश दिखने वाला डायग्राम।

जब जिन लोगों को काम करना है वे कहें, "हाँ, वाकई में ऐसा ही होता है," तब आपका मैप तैयार है।

ऐसे स्टेटस चुनें जो लोग जल्दी समझ लें

अच्छी स्टेटस सूची को एक साधारण परीक्षण पास करना चाहिए: अगर दो लोग एक ही अनुरोध पढ़ें, तो दोनों को अगले कदम के बारे में एक ही निष्कर्ष पर पहुँचना चाहिए।

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

एक व्यावहारिक शुरुआती सेट इस तरह दिखता है:

• Draft
• Waiting for approval
• Approved
• Rejected
• Needs changes

हर स्टेटस का एक सटीक अर्थ होना चाहिए। Waiting for approval का मतलब है अनुरोध तैयार है और किसी को समीक्षा करनी चाहिए। Needs changes का मतलब है यह अभी अप्रूव नहीं हुआ है, पर अपडेट के बाद वापस आ सकता है। Rejected का मतलब है अनुरोध रोक दिया गया है जब तक कोई नियम उसे फिर से खोलने की अनुमति न दे।

भ्रम तब शुरू होता है जब टीमें लगभग-डुप्लिकेट बनाती हैं जैसे Pending, In review, Under review, और Awaiting sign-off. सिस्टम के नज़रिए से ये अलग हैं, पर लोगों के लिए अक्सर एक ही मतलब रखते हैं। इससे रिपोर्टिंग गड़बड़, हैंडऑफ़ अस्पष्ट और अतिरिक्त प्रश्न पैदा होते हैं।

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

स्टेटस को ओनरशिप से अलग रखना भी समझदारी है। Waiting for approval अक्सर With finance से ज़्यादा स्पष्ट होता है। पहला अनुरोध की स्थिति बताता है; दूसरा स्थिति और वर्तमान रिव्यूवर को मिला देता है।

सबसे छोटा सेट चुनें जो काम करे। बाद में जब सच्ची ज़रूरत दिखे तो स्टेटस जोड़ सकते हैं।

मालिक और हैंडऑफ़ स्पष्ट रूप से सेट करें

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

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

हर स्टेप के लिए चार सरल प्रश्नों का उत्तर दें:

• अभी इसका मालिक कौन है?
• अगर वह व्यक्ति अनुपस्थित हो तो कौन काम करेगा?
• अप्रूवल या रिजेक्शन के बाद अगला किसे मिलता है?
• कौन इसे फिर से खोल सकता या रद्द कर सकता है?

हैंडऑफ़ उतने ही स्पष्ट होने चाहिए। अगर मैनेजर अप्रूव करता है और फिर फाइनेंस समीक्षा करेगा, तो वर्कफ़्लो में सीधे वह कहें। इसे बस "send to finance" न छोड़ें जब तक सिस्टम न जानता हो कि किस व्यक्ति या रोल को भेजना है।

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

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

डेडलाइन और अपवाद नियम जोड़ें

जब पूरी रिक्वेस्ट के लिए केवल एक डेडलाइन हो तो वर्कफ़्लो अटक जाता है। हर स्टेज का अपना ड्यू डेट होना चाहिए ताकि टीमें देख सकें असल में समय कहाँ खो रहा है।

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

ऑटोमेशन करने से पहले चार बुनियादी चीज़ें परिभाषित करें:

• हर स्टेज के लिए एक ड्यू डेट
• डेडलाइन मिस होने पर स्पष्ट कार्रवाई
• अर्जेंट मामलों के लिए अलग पथ
• गुम जानकारी, रीवर्क और अपवादों के नियम

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

अर्जेंट अनुरोधों के लिए अलग पथ चाहिए, पर इसे संकीर्ण रखें। अगर सब कुछ अर्जेंट चिह्नित किया जा सके तो यह लेबल बेअसर हो जाएगा। इसे कुछ स्पष्ट मामलों तक सीमित रखें, जैसे ग्राहक-सामना करने वाले मुद्दे या अनुपालन डेडलाइंस।

अपवाद नियम उतने ही महत्वपूर्ण हैं। अगर अनुरोध में जानकारी गायब है, तो उसे Waiting for requester जैसे स्टेटस पर भेजें और टाइमर को पॉज़ करें। अगर इसे ठीक किया जा सकता है तो इसे बंद करने के बजाय रीवर्क भेजें। यदि नीति के बाहर है, तो इसे किसी नामांकित अपवाद अप्रूवर के पास भेजें बजाय इसके कि लोग ईमेल में इम्प्रोवाइज़ करें।

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

व्यवहार में एक सरल फ्लो

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

एक बुनियादी संस्करण इन स्टेटस का उपयोग कर सकता है:

• Submitted
• Needs more info
• Manager approved
• Finance approved
• Completed

अनुरोध Submitted के रूप में शुरू होता है और मैनेजर के पास जाता है। अगर कर्मचारी केवल "laptop for new hire" लिख देता है और बजट कोड छोड़ देता है, तो मैनेजर को इसे अप्रूव नहीं करना चाहिए और साइड ईमेल में समस्या समझाने की बजाय स्टेटस को Needs more info में बदलकर इसे वापस भेजना चाहिए। कर्मचारी फिर मालिक बनता है, बताई गई जानकारी जोड़ता है और पुनः सबमिट करता है।

जब अनुरोध पूरा हो जाता है, तो मैनेजर इसे देखता है और स्टेटस बदलकर Manager approved कर देता है। ओनरशिप तब फाइनेंस को मिलती है। फाइनेंस बजट, विक्रेता नियम और खर्च सीमा की जाँच करता है। अगर सब कुछ सही है, तो स्टेटस Finance approved हो जाता है।

अब एक वास्तविक अपवाद जोड़ें। फाइनेंस अप्रूवर तीन दिनों के लिए बीमार है। अगर यह नियम पहले से नहीं था, तो अनुरोध बस वहीं रुक जाता है। बेहतर सेटअप में पहले से एक बैकअप नामित होता है। डेडलाइन के पास होने पर, या अनुपस्थिति के पता चलते ही, अनुरोध बिना लिंबो में रहे बैकअप की ओर चला जाता है।

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

सॉफ़्टवेयर में जाते समय सामान्य गलतियाँ

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

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

एक और सामान्य गलती जल्द ही बहुत ज़्यादा विवरण जोड़ना है। टीमें स्टेप्स के हर छोटे पल को दिखाने के लिए लंबी स्टेटस सूचियाँ बनाती हैं। व्यवहार में इससे प्रक्रिया समझना मुश्किल हो जाता है। अगर एक अनुरोध को मार्क किया जा सकता है pending review, under review, waiting for comments, sent back, resubmitted, और ready for sign-off के बीच, तो ज्यादातर लोग नहीं जानेंगे किस लेबल का उपयोग करना है।

ऐसा ही अनावश्यक अप्रूवर्स के साथ होता है। अगर सिर्फ़ संभावित कारणों के लिए पाँच लोग जोड़ दिए जाएँ, तो काम धीमा हो जाता है और कोई भी पूरी तरह जिम्मेदार नहीं महसूस करता।

कुछ चेतावनी संकेत जल्दी दिखते हैं:

• लोग बार-बार पूछते हैं कि अनुरोध का मालिक कौन है
• दो स्टेटस एक ही जैसा लगते हैं
• अप्रूवल अभी भी यह समझाने के लिए साइड ईमेल्स की ज़रूरत रखते हैं कि क्या हो रहा है
• कई लोग कार्रवाई कर सकते हैं, पर कोई स्पष्ट रूप से जवाबदेह नहीं है

टीमें अक्सर बुनियादी नियमों के तय होने से पहले रिमाइंडर्स और एसकेलेशन्स जोड़ देती हैं। रिमाइंडर तभी मदद करते हैं जब सिस्टम पहले से जानता हो कि क्याWaiting माना जाता है, कौन लेट है, और अगला कदम क्या होना चाहिए। अगर वे नियम अस्पष्ट हैं, तो रिमाइंडर बस शोर बढ़ाते हैं।

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

दिन के पहले चरण में सरलता पूर्णता से बेहतर है। कमजोर कदम पहले ठीक करें, स्टेटस कम रखें, हर स्टेप के लिए एक मालिक असाइन करें, और ऑटोमेशन जोड़ने से पहले अपवादों का फैसला कर लें।

ऑटोमेट करने से पहले एक त्वरित जांच

रूटिंग नियम, रिमाइंडर या एसकेलेशन्स ऑन करने से पहले जाँचें कि क्या प्रक्रिया ईमेल के बिना भी काम करने के लिए स्पष्ट है।

एक उपयोगी परीक्षण सरल है: क्या एक सामान्य अनुरोध अधिकतर मामलों में एक स्पष्ट पथ से स्टार्ट से फिनिश तक जा सकता है? अगर नहीं, तो पहले पथ ठीक करें।

इन प्रश्नों से गुजरें:

• क्या एक सामान्य अनुरोध का एक मानक मार्ग है?
• क्या स्टेटस साधारण भाषा में लिखे गए हैं?
• क्या हर स्टेप का एक मुख्य मालिक और एक बैकअप है?
• क्या डेडलाइन वर्कफ़्लो के अंदर दिखाई देती हैं?
• क्या अपवाद मामले ऑटोमेशन शुरू करने से पहले लिखे गए हैं?

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

इसीलिए कई टीमें पहले एक साधारण दस्तावेज़ या वाइटबोर्ड पर प्रक्रिया का स्केच बनाती हैं फिर उसे टूल में बनाती हैं। अगर आप एक आंतरिक अप्रूवल ऐप बना रहे हैं, तो Koder.ai एक व्यावहारिक तरीका हो सकता है जिससे साधारण भाषा के वर्कफ़्लो को कामकाजी सॉफ़्टवेयर में बदला जा सके बिना लंबे विकास चक्र के।

छोटे, सुरक्षित पायलट में रोल आउट करें

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

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

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

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

ध्यान दें:

• अनुरोध जो अटकते हैं क्योंकि ओनरशिप स्पष्ट नहीं है
• स्टेटस जिन्हें लोग अलग-अलग अर्थ में लेते हैं
• डेडलाइन नियम जो असली काम से मेल नहीं खाते
• अपवाद जो अभी भी ईमेल या चैट में फैलते हैं

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

एक साधारण समीक्षा ताल भी मददगार है। पहले 5–10 अनुरोधों के बाद प्रक्रिया की जाँच करें, फिर दो हफ्ते बाद फिर से। एक सरल प्रश्न पूछें: लोग अभी भी कहाँ वर्कअराउंड कर रहे थे?

अगर आप जल्दी से एक आंतरिक approval टूल टेस्ट करना चाहते हैं, तो Koder.ai चैट से उस तरह के वर्कफ़्लो का प्रोटोटाइप बनाकर उसे कामकाजी ऐप में बदलने के लिए उपयोगी है। कई बार यह बड़े रोलआउट से पहले प्रक्रिया सत्यापित करने के लिए पर्याप्त होता है।

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