वर्कफ़्लो में प्रतिनिधि स्वीकृतियाँ: छुट्टी मोड और प्रतिनिधि

लोग दूर होने पर स्वीकृतियाँ क्यों अटक जाती हैं

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

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

कुछ करीबी लेकिन अलग भावों को अलग रखना मददगार होता है, जिन्हें लोग अक्सर मिला देते हैं:

• Delegation (प्रतिनियुक्ति): मूल स्वीकर्ता ज़िम्मेदारी बनाए रखता है, पर एक प्रतिनिधि एक अवधि या विशिष्ट मामलों के लिए उनकी ओर से कार्य कर सकता है।
• Forwarding (फॉरवर्डिंग): कार्य किसी और के साथ शेयर या भेजा जाता है, पर सिस्टम अभी भी मूल व्यक्ति से प्रतिक्रिया की उम्मीद कर सकता है।
• Reassignment (पुन:असाइनमेंट): स्वीकृति कार्य का स्वामित्व किसी और को स्थानांतरित हो जाता है, अक्सर स्थायी रूप से या किसी एक अनुरोध के लिए।

असल लक्ष्य सिर्फ गती नहीं है। यह पूर्वानुमेयता और साफ रिकॉर्ड है।

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

लक्ष्य परिणाम सरल है: कोई ब्लॉक्ड अनुरोध न हो, और यह स्पष्ट, रिव्यू करने योग्य ट्रेल रहे कि किसने क्या किया—even जब कोई अनुपस्थित हो।

मुख्य शब्द: approver, substitute, और delegation

साफ शब्द बाद में गंदे नियमों को रोकते हैं। अगर लोग इस पर सहमत नहीं हैं कि कौन क्या स्वीकृत कर सकता है, तो आपका वर्कफ़्लो या तो अटक जाएगा या ऑडिट के लिए परेशानी पैदा करेगा।

अधिकांश स्वीकृति वर्कफ़्लो में कुछ सामान्य भूमिकाएँ होती हैं:

• Requester (अनुरोधक) वह प्रक्रिया शुरू करता है (खर्च, खरीद अनुरोध, पहुंच अनुरोध)।
• Approver (स्वीकर्ता) निर्णय लेता है।
• Admin (व्यवस्थापक) वर्कफ़्लो, अनुमति और नियम कॉन्फ़िगर करता है।
• Substitute (प्रतिनिधि) किसी अन्य व्यक्ति की ओर से स्वीकृति देने के लिए अनुमति रखता है।

Primary approver (प्राथमिक स्वीकर्ता) वह डिफ़ॉल्ट व्यक्ति है जिससे उस चरण में स्वीकृति की उम्मीद होती है। Backup approver (बैकअप स्वीकर्ता) वह फॉलबैक व्यक्ति है जो प्राथमिक अनुपलब्ध होने पर स्वीकृति दे सकता है।

लोग अक्सर “backup approver” और “second approver” को मिला देते हैं, पर वे अलग हैं। सेकंड अप्रोवर एक अतिरिक्त स्तर जोड़ता है। बैकअप वही स्तर का वैकल्पिक मार्ग होता है।

डेलीगेशन वह नियम है जो प्रतिनिधि को कार्य करने देता है। दो सामान्य शैलियाँ हैं:

• Always-on delegation: प्रतिनिधि कभी भी स्वीकृति दे सकता है, भले ही प्राथमिक उपलब्ध हो।
• Absence-only delegation: प्रतिनिधि तब ही स्वीकृति दे सकता है जब प्राथमिक को अनुपस्थित दिखाया गया हो (छुट्टी मोड) या टाइमआउट हो गया हो।

स्वीकृति levels (स्तर) वे क्रमिक कदम हैं जिनसे अनुरोध को गुजरना होता है (मैनेजर, फिर वित्त, फिर कानूनी, फिर आईटी, अनुरोध और राशि के आधार पर)। “Levels” को “substitutes” से अलग रखें: स्तर यह परिभाषित करते हैं कि किसे मंज़ूरी देनी है; प्रतिनिधि यह परिभाषित करते हैं कि जब सामान्य व्यक्ति नहीं हो तो कौन दे सकता है।

अपने प्रोसेस के अनुसार प्रतिनिधि मॉडल चुनें

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

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

सामान्य प्रतिनिधि मॉडल (और कब काम करते हैं)

ज़्यादातर टीमें इनका संयोजन उपयोग करती हैं:

• Vacation mode (तिथि-आधारित): स्वीकर्ता एक आरंभ और समाप्ति तिथि सेट करता है, और उस विंडो के दौरान अनुरोध नामित प्रतिनिधि पर रूट होते हैं।
• Manual one-off delegation: एक एडमिन या मैनेजर एक आपात स्थिति में एक ही अनुरोध के लिए प्रतिनिधि असाइन करता है।
• Rule-based delegation: प्रतिनिधि नियमों के द्वारा चुना जाता है, जैसे टीम, अनुरोध श्रेणी, या राशि।
• Escalation: अगर कोई समय पर जवाब नहीं देता, तो अनुरोध अगले व्यक्ति (अक्सर स्वीकर्ता के मैनेजर या ऑन-कॉल क्यू) को चला जाता है।
• Separation of duties: संवेदनशील स्वीकृतियों के लिए अलग व्यक्ति (या दूसरा स्वीकर्ता) चाहिए ताकि अनुरोधक या प्रतिनिधि अपने ही काम को स्वीकृत न कर सके।

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

मॉडल जल्दी तय करने वाले प्रश्न

कई उत्तर आपकी विकल्पों को जल्दी संकुचित कर देंगे:

• क्या स्वीकृति उच्च-जोखिम (पैसा, एक्सेस, अनुपालन) है या कम-जोखिम (रूटीन प्रशासन)?
• क्या आपको प्रति व्यक्ति एक प्रतिनिधि चाहिए, या एक पूल (जैसे “Finance On-Call”)?
• क्या प्रतिनिधि अनुरोधक को दिखाई देना चाहिए, या केवल एडमिन को ही दिखाई देना चाहिए?\
• अनुरोध कितने समय तक इंतज़ार कर सकता है इससे पहले कि एस्केलेशन ट्रिगर हो?\
• क्या आपको सेल्फ-अप्रोवल को रोकने वाले सख्त नियम चाहिए?

छुट्टी मोड और प्रतिनिधियों के लिए डिज़ाइन नियम

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

एक स्पष्ट समय विंडो अनिवार्य करें। हर डेलीगेशन की एक आरंभ और समाप्ति तिथि होनी चाहिए (और अगर आप क्षेत्रों में काम करते हैं तो टाइमज़ोन भी)। “अगले आदेश तक” से बचें। अगर कोई इसे बंद करना भूल जाता है, तो गलत व्यक्ति को हफ्तों तक स्वीकृतियाँ रूट हो सकती हैं।

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

सिस्टम द्वारा लागू किए जाने योग्य पात्रता नियम सेट करें। उन्हें सरल रखें, और “विशेष मामले” जिन्हें केवल किसी के दिमाग में होता है, मत रखें। सामान्य नियमों में शामिल हैं: वही विभाग या कॉस्ट सेंटर में होना, सही स्वीकृति स्तर होना, और आवश्यक प्रशिक्षण पूरा होना। स्पष्ट संघर्षों को हमेशा ब्लॉक करें: प्रतिनिधि अनुरोधक नहीं होना चाहिए, और सर्कुलर स्वीकृतियों को रोका जाना चाहिए।

इन-फ्लाइट (प्रारम्भिक) स्वीकृतियों के साथ क्या होता है यह परिभाषित करें। कई टीमें नए अनुरोधों को प्रतिनिधि पर रूट करती हैं पर मौजूदा लंबित आइटम्स को प्राथमिक के साथ ही छोड़ देती हैं जब तक वे ओवरड्यू न हों। एक बार ओवरड्यू होने पर वर्कफ़्लो ऑटो-रअसाइन या एस्केलेट कर सकता है।

स्थिति दृश्यमान बनाएं। अनुरोधक को वर्तमान स्वीकर्ता, क्या डेलीगेशन सक्रिय है, और आगे क्या है यह दिखना चाहिए। “Waiting for approval (delegated to Alex until Jan 30)” जैसा स्टेटस फॉलो-अप को घटाता है और भरोसा बनाए रखता है।

चरण-दर-चरण: वर्कफ़्लो में वैकल्पिक स्वीकर्ताओं को लागू करें

एक सामान्य अनुरोध (खरीद, पहुंच, नीति अपवाद) के लिए सटीक स्वीकृति पथ लिखने से शुरू करें। इसे छोटा रखें। पैटर्न डिजाइन करने के लिए दो से चार कदम काफी हैं।

एक व्यावहारिक कार्यान्वयन पैटर्न

1. प्रत्येक चरण को एक भूमिका और एक रिकॉर्ड के एकल मालिक से मैप करें। भले ही प्रतिनिधि कार्य कर सके, हर चरण के लिए एक प्राथमिक स्वीकर्ता रखें ताकि ज़िम्मेदारी स्पष्ट रहे।

2. डेलीगेशन के लिए एक प्राथमिक ट्रिगर चुनें। अधिकांश टीमें अनुपस्थिति फ़्लैग, एक तिथि विंडो, या मैनेजर-नियंत्रित स्विच का उपयोग करती हैं। पहले एक चुनें ताकि लोग चुप्पी से होने वाली रीरूट से हैरान न हों।

3. क्रियान्वयन के लिए रूटिंग नियम जोड़ें कि कौन acting approver होगा। बाद में समझाने के लिए एक पूर्वानुमेय क्रम सबसे आसान होता है: उपयोगकर्ता द्वारा चुना गया प्रतिनिधि, फिर मैनेजर, फिर साझा बैकअप क्यू। तय करें कि प्रतिनिधि तुरंत स्वीकृति दे सकता है या केवल टाइमआउट के बाद।

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

5. एक end-to-end टेस्ट चलाएँ और इतिहास का निरीक्षण करें। आपको देखना चाहिए कि किसे असाइन किया गया, डेलीगेशन क्यों हुआ, किसने स्वीकृति दी, और कब।

टेस्ट और पुष्टि

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

स्पष्ट स्वीकृति इतिहास (ऑडिट ट्रेल) के लिए क्या लॉग करें

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

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

स्वीकृति निर्णयों को अपरिवर्तनीय घटनाओं के रूप में रखें। “Pending” को “Approved” से ओवरराइट न करें। “Approved”, “Rejected”, या “Requested changes” जैसी घटनाओं को रिकॉर्ड करें और उन्हें रखें, भले ही वर्कफ़्लो फिर से शुरू हो जाए।

एक व्यावहारिक ऑडिट ट्रेल आम तौर पर शामिल करता है:

• ईवेंट ID, वर्कफ़्लो आइटम ID, और चरण का नाम
• टाइमस्टैम्प (टाइमज़ोन के साथ), एक्टिंग व्यक्ति की पहचान, और उस समय उनकी भूमिका
• acting-on-behalf-of विवरण (मौलिक स्वीकर्ता, डेलीगेशन नियम ID)
• परिणाम साथ ही टिप्पणी, कारण कोड, और कोई अटैचमेंट्स
• डेलीगेशन नियमों में किसी भी संपादन का रिकॉर्ड (किसने क्या बदला, और कब)

टिप्पणियों और अटैचमेंट्स को निर्णय ईवेंट से जोड़ कर रखें। अगर वे अलग चैट में या सामान्य “नोट्स” फ़ील्ड में रहते हैं, तो यह साबित करना मुश्किल हो जाता है कि किस टिप्पणी ने किस निर्णय का समर्थन किया।

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

पारदर्शिता: स्वीकृतियाँ होते समय उपयोगकर्ताओं को क्या दिखना चाहिए

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

अनुरोधक और समीक्षक को हमेशा वर्तमान स्वीकर्ता और उन्हें चुनने का कारण दिखना चाहिए। अगर कार्य प्राथमिक स्वीकर्ता से प्रतिनिधि पर चला गया, तो सीधे दिखाएँ: “Assigned to: Priya (substitute for Alex).” यह एक लाइन भ्रम रोकेगी और जवाबदेही सुरक्षित रखेगी।

डेलीगेशन विंडो और जिसने इसे सेट किया वह भी दिखाएँ। “Delegation active: Jan 10 to Jan 20, set by Alex” जैसी जानकारी टीमों को विश्वास दिलाती है कि हैंडऑफ़ जानबूझकर हुआ।

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

एक साधारण “View history” पैनल अक्सर पर्याप्त होता है। इसे केंद्रीत रखें: वर्तमान स्थिति, वर्तमान स्वीकर्ता और कारण, डेलीगेशन अवधि, कोई मैन्युअल पुन:असाइनमेंट, और निर्णय टिप्पणियाँ।

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

सामान्य गलतियाँ जो देरी या ऑडिट समस्याएँ पैदा करती हैं

प्रतिनियुक्ति आम तौर पर सरल कारणों से विफल होती है: नियम बहुत ढीले हैं, रिकॉर्ड अस्पष्ट हैं, या बैकअप योजना नहीं है। परिणाम अनुमानित है: अनुरोध ठहरे रहते हैं, और बाद में कोई साबित नहीं कर पाता कि किसने क्या मंज़ूर किया।

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

अक्सर दिखने वाली गलतियाँ:

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

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

अधिकांश समस्याएँ रोकने के डिजाइन विकल्प:

• डेलीगेशन के लिए प्रारंभ और समाप्ति तिथियाँ अनिवार्य करें, और ऑटो-एक्सपायर सेट करें
• प्रतिनिधियों को सक्रिय करने से पहले स्पष्ट नियमों के खिलाफ वेलिडेट करें
• दोनों पहचानें रखें: “assigned approver” और “acted by,” और मूल पहचान को कभी मिटाएँ नहीं
• एस्केलेशन जोड़ें: अगर X घंटे में कोई कार्रवाई नहीं, तो मैनेजर या ऑन-कॉल क्यू को रूट करें

रोलआउट से पहले त्वरित चेकलिस्ट

प्रतिनियुक्ति तब काम करती है जब "निराशाजनक विवरण" लगातार हों। कंपनी भर में छुट्टी मोड सक्षम करने से पहले हर स्वीकृति चरण को स्कैन करें और पूछें: अगर आज असाइन किया गया स्वीकर्ता अनुपलब्ध है, तो अगला क्या होगा?

• हर चरण के पास एक नामित बैकअप (या परिभाषित ऑन-कॉल क्यू) है, और उस बैकअप के पास सही अनुमतियाँ हैं।
• डेलीगेशन नियम समय-सीमित हैं, और एडमिन देख सकते हैं कौन सी प्रतिनियुक्तियां सक्रिय हैं।
• स्वीकृति इतिहास दोनों व्यक्तियों को दिखाता है: जिसने जिम्मेदारी रखी और जिसने कार्य किया।
• किसी भी रिकॉर्ड के लिए आप बिना अनुमान लगाए "किसने कब और किस नियम के तहत स्वीकृत किया" का उत्तर दे सकते हैं।
• टाइमआउट के लिए एक एस्केलेशन है (उदा., 48 घंटों के बाद, मैनेजर या क्यू को रअसाइन)।

फिर कम से कम एक "छुट्टी पर व्यक्ति" परिदृश्य end-to-end टेस्ट करें: अनुरोध छुट्टी शुरू होने से पहले जमा किया गया, छुट्टी के दौरान स्वीकृत हुआ, और व्यक्ति लौटने के बाद इसकी समीक्षा हुई।

उदाहरण: छुट्टी के दौरान वास्तविक स्वीकृति हैंडऑफ़

एक सेल्स टीम 12 नए हेडसेट्स (USD 1,200) के लिए खरीद अनुरोध जमा करती है। सामान्यतः यह अनुरोध Maya, Sales Manager को जाता है। लेकिन Maya दो हफ्ते के लिए छुट्टी पर है, और स्वीकृतियाँ रुकी नहीं रह सकतीं।

छुट्टी से पहले, Maya छुट्टी मोड सक्रिय करती हैं और Jordan (Sales Ops Lead) को USD 5,000 तक की खरीद स्वीकृतियों के लिए अपनी प्रतिनिधि के रूप में नामित करती हैं। उससे ऊपर वाली राशि अब भी Finance के पास जाएगी।

साफ़, ऑडिट-फ्रेंडली हैंडऑफ़ इस तरह चलता है:

• सोम 9:10: एक प्रतिनिधि “Headsets for onboarding” vendor और कॉस्ट सेंटर के साथ सबमिट करता है।
• सोम 9:10: वर्कफ़्लो प्राथमिक के रूप में Maya को असाइन करता है, फिर तुरंत क्योंकि छुट्टी मोड सक्रिय है, Jordan पर रीरूट कर देता है।
• सोम 9:18: Jordan अनुरोध की समीक्षा करते हैं और स्वीकृत कर देते हैं। रिकॉर्ड दिखाता है “Jordan (acting for Maya)” और Jordan का नोट शामिल है: “Approved for Q1 onboarding. Budget confirmed.”
• सोम 9:18: वर्कफ़्लो बजट चेक के लिए Finance को जारी रहता है, फिर अनुरोध को स्वीकृत के रूप में चिह्नित कर देता है।

दो बातें इस अनुभव को विश्वसनीय बनाती हैं। अनुरोधक देख सकता है कि स्वीकर्ता क्यों बदला गया (“Routed to substitute: Maya out of office”), और Maya लौटने पर भी यह नहीं रहस्यमय रहता।

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

बाद में, एक ऑडिटर पूछता है, “किसने यह खरीद स्वीकृत की, और यह Maya ने क्यों नहीं की?” टाइमलाइन एक सुसंगत कहानी बताती है: मूल स्वीकर्ता, डेलीगेशन कारण (छुट्टी मोड), प्रतिनिधि की पहचान, acting-for श्रेणी, टाइमस्टैम्पेड निर्णय, और नोट।

अगले कदम: सुरक्षित रूप से रोल आउट करें और रख-रखाव आसान रखें

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

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

एक छोटी डेलीगेशन नीति लिखें जिसे लोग वास्तव में पालन करेंगे: कौन प्रतिनिधि कर सकता है, क्या प्रतिनिधि किया जा सकता है (उदा., केवल एक लागत या जोखिम सीमा के नीचे), डेलीगेशन कैसे शुरू और खत्म होता है, और एक आपातकालीन ओवरराइड कैसा दिखता है और कैसे रिकॉर्ड होता है।

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

अगर आप बिना भारी प्रोग्रामिंग के एक स्वीकृति ऐप बनाना चाहते हैं, तो AppMaster (appmaster.io) उपयोगकर्ता, भूमिकाओं, और डेलीगेशन विंडो को डेटाबेस में मॉडल कर सकता है, फिर विज़ुअल Business Process Editor में रूटिंग और टाइमआउट लागू कर सकता है, जबकि ऑडिट के लिए एक सुसंगत स्वीकृति इतिहास बनाए रखता है।

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