13 मार्च 2026·8 मिनट पढ़ने में

बिज़नेस वर्कफ़्लो अपवाद: काम को आगे बढ़ाने वाले रास्ते

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

रोज़मर्रा की वर्कफ़्लो समस्याओं के लिए स्पष्ट रास्ते क्यों ज़रूरी हैं

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

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

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

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

प्रक्रिया की गलती और बिज़नेस फ़ैसले को अलग तरह से सँभालना चाहिए। प्रक्रिया की गलती तब वर्कफ़्लो रोकती है जब ज़रूरी डेटा गायब या गलत हो। उदाहरण के लिए, कोई कर्मचारी रसीद के बिना खर्च का दावा भेज देता है। वर्कफ़्लो को दावा वापस भेजकर यह बताना चाहिए कि कर्मचारी को क्या जोड़ना है।

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

दोनों स्थितियों को सामान्य «त्रुटि» मानने से भ्रम पैदा होता है। अनुरोधकर्ता को पता नहीं चलता कि फ़ील्ड सुधारना है, प्रमाण देना है या फ़ैसले की प्रतीक्षा करनी है। हर अपवाद को सरल नाम, स्पष्ट ज़िम्मेदार व्यक्ति और तय परिणाम दें।

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

वर्कफ़्लो बनाने से पहले हर अपवाद तय करें

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

हर अपवाद के लिए ट्रिगर, ज़िम्मेदार व्यक्ति, समय-सीमा और अगला कदम लिखें। इससे अनुरोध कतार में इसलिए नहीं पड़े रहेंगे कि किसी को पता नहीं कि जवाब कौन देगा।

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

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

ऐसे स्टेटस नाम रखें जो वर्तमान स्थिति बताएँ। «अनुरोधकर्ता की प्रतीक्षा», «अस्वीकृत», «समय-सीमा पार» और «मैनुअल समीक्षा आवश्यक» जैसे नाम «अपवाद 2» या «कार्रवाई लंबित» से बेहतर हैं। सूची देखने वाला व्यक्ति तुरंत समझ सके कि क्या हुआ और अगला कदम कौन उठाएगा।

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

नो-कोड ऐप में अपवादों को स्पष्ट स्टेटस बदलाव और बिज़नेस प्रोसेस के अलग रास्तों के रूप में बनाएँ। AppMaster का विज़ुअल Business Process Editor फ़ैसलों का नक्शा बना सकता है, ज़िम्मेदार व्यक्ति तय कर सकता है और अनुरोध को अगले कदम पर भेज सकता है। स्टेटस सूची, नोटिफ़िकेशन और कर्मचारियों की स्क्रीन पर एक ही भाषा रखें।

छूटी हुई जानकारी वाले अनुरोधों को सही रास्ते पर भेजें

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

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

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

वापसी का रास्ता स्पष्ट करें

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

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

रिमाइंडर और बंद करने का नियम रखें

जवाब की समय-सीमा से पहले रिमाइंडर भेजें। दो कारोबारी दिनों के बाद एक रिमाइंडर और नियत तारीख पर दूसरा रिमाइंडर व्यावहारिक तरीका है। पहले अनुरोधकर्ता को रिमाइंडर भेजें, फिर प्रक्रिया में एस्केलेशन हो तो ही उसके मैनेजर को कॉपी करें।

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

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

संदर्भ खोए बिना अस्वीकृत अनुरोध सँभालें

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

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

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

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

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

अनुरोधकर्ता दोबारा भेजे, तो नया संस्करण दर्ज करें और उसे सही समीक्षक के पास भेजें। पिछली अस्वीकृति इतिहास में रखें। इससे पता चलता है कि अनुरोध क्यों रुका था और अनुरोधकर्ता ने समस्या दूर की या नहीं।

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

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

समय-सीमा पार होने वाले कामों के नियम बनाएँ

अनुरोध वर्कफ़्लो बनाएँ

ऐसा खरीद अनुरोध ऐप बनाएँ, जिसमें फ़ॉर्म, अनुमोदन और अपवादों का इतिहास साथ रहे।

मुफ़्त शुरू करें

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

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

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

समय-सीमा निकलने पर अगली कार्रवाई ऐसे नामित व्यक्ति या भूमिका को सौंपें जिसके पास फ़ैसला लेने का अधिकार हो। देर से आया काम सामान्य इनबॉक्स में न भेजें। इससे ज़िम्मेदारी छिपती है और अक्सर एक और काम समय-सीमा से बाहर हो जाता है।

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

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

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

ऐसा मैनुअल समीक्षा चरण जोड़ें जिसका लोग इस्तेमाल कर सकें

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

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

समीक्षकों को पर्याप्त संदर्भ दें

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

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

फ़ैसले के लिए समय-सीमा रखें

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

जब तक किसी भी व्यक्ति को फ़ैसला लेने का अधिकार न हो, एक ही अनुरोध सबको एक साथ न भेजें। इससे विरोधाभासी जवाब मिल सकते हैं। पहले एक ज़िम्मेदार व्यक्ति तय करें, हर कार्रवाई दर्ज करें और अंतिम फ़ैसले के बाद अनुरोध लॉक कर दें।

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

उदाहरण: ऐसा खरीद अनुरोध जो सामान्य रास्ते से हट जाए

अस्वीकृति का संदर्भ बनाए रखें

अस्वीकृति के कारण, नोट्स, अटैचमेंट और फ़ैसले एक ही अनुरोध रिकॉर्ड में रखें।

ऐप बनाएँ

एक कर्मचारी 2,400 डॉलर के नए मॉनिटर खरीदने का अनुरोध भेजता है। अनुरोध में वस्तुओं की सूची और विभाग शामिल हैं, लेकिन सप्लायर का कोटेशन नहीं है। उसे मैनेजर के पास भेजने के बजाय वर्कफ़्लो स्टेटस «जानकारी की प्रतीक्षा» कर देता है और अगला काम अनुरोधकर्ता को सौंपता है।

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

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

अनुरोधकर्ता दो मॉनिटर हटाकर अनुरोध दोबारा भेजता है। वर्कफ़्लो अनुरोधकर्ता से फिर से शुरुआत करने को कहने के बजाय वित्त समीक्षा का नया काम बनाता है। वित्त टीम संशोधित राशि मंज़ूर करती है। स्टेटस «मैनेजर के अनुमोदन की प्रतीक्षा» हो जाता है और मैनेजर को पहले की अस्वीकृति का पूरा इतिहास दिखाई देता है।

जब अनुमोदन देर से आए

मैनेजर के पास जवाब देने के लिए दो कारोबारी दिन हैं। दूसरे दिन वर्कफ़्लो रिमाइंडर भेजता है। समय-सीमा निकलने पर देर से हुए कामों का प्रबंधन स्टेटस को «मैनेजर का अनुमोदन देर से» कर देता है और एस्केलेशन का काम मैनेजर के टीम लीड को सौंप देता है।

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

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

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

अपवादों के रास्ते बनाते समय आम गलतियाँ

उपयोगी समय-सीमाएँ तय करें

ऐसी रिमाइंडर और एस्केलेशन प्रक्रियाएँ बनाएँ जो आपकी टीम की वास्तविक समय-सीमाओं से मेल खाएँ।

AppMaster आज़माएँ

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

ऐसे नाम रखें जो बताएँ कि क्या हुआ और अब क्या करना है। «समस्या» और «ध्यान आवश्यक» जैसे नाम समीक्षक को हर आइटम खोलने पर मजबूर करते हैं। «सप्लायर का कोटेशन छूटा», «वित्त ने अस्वीकार किया» या «अनुमोदन दो दिन देर से» जैसे लेबल अगले व्यक्ति को उपयोगी शुरुआत देते हैं।

कुछ डिज़ाइन नियम अपवादों को ईमेल के पीछे भागने वाली प्रक्रिया बनने से रोकते हैं:

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

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

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

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

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

त्वरित जाँच और अगले कदम

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

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

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

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

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

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

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

सामान्य प्रश्न

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

छूटी हुई जानकारी को सुधार के काम की तरह सँभालें। अनुरोध का स्टेटस «जानकारी की प्रतीक्षा» रखें, अनुरोधकर्ता को ठीक-ठीक बताएँ कि क्या जोड़ना है और मूल रिकॉर्ड खुला रखें, ताकि वह उसे अपडेट करके दोबारा भेज सके।

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

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

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

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

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

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

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

AppMaster के Business Process Editor में टीम स्पष्ट अपवाद रास्ते बना सकती है। आप स्टेटस और फ़ैसले का इतिहास रख सकते हैं, काम सौंप सकते हैं, समय-सीमा के रिमाइंडर भेज सकते हैं, मैनुअल समीक्षा भेज सकते हैं और सुधारे गए अनुरोधों को बिना वर्कफ़्लो लॉजिक हाथ से लिखे वापस भेज सकते हैं।