अपवाद पथ: व्यावसायिक ऑटोमेशन में गायब आर्किटेक्चर

अधिकतर वर्कफ़्लो आरेख आशावादी होते हैं। वे केवल सफल पथ दिखाते हैं: एक ट्रिगर आता है, सॉफ्टवेयर उसे प्रोसेस करता है, एक निर्णय लिया जाता है और कार्य आगे बढ़ जाता है।

वास्तविक व्यवसाय केवल सफल पथ पर नहीं चलते।

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

किसी ऑटोमेशन सिस्टम की गुणवत्ता अक्सर इस बात से कम तय होती है कि वह सामान्य काम कितनी तेज़ी से करता है, और इस बात से अधिक कि वह अपवादों को कितनी समझदारी से संभालता है।

अपवाद पथ क्या है?

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

यह ऐसे सवालों के जवाब देता है:

• जब आवश्यक सबूत न हों तो क्या होता है?
• जब ऑटोमेशन आगे नहीं बढ़ सकता, तब उस मामले की ज़िम्मेदारी किसकी होती है?
• क्या सिस्टम सुरक्षित तरीके से फिर से कोशिश कर सकता है?
• जब मामला रुका हुआ हो, तो उपयोगकर्ता को क्या दिखना चाहिए?
• मानवीय समीक्षा करने वाले को कौन-सी जानकारी मिलती है?
• समाधान के बाद वर्कफ़्लो मुख्य पथ पर कैसे लौटता है?

इन जवाबों के बिना, ऑटोमेशन एक ऑपरेटिंग सिस्टम के बजाय केवल स्क्रिप्ट्स का संग्रह बन जाता है।

AI के साथ अपवाद डिज़ाइन क्यों और भी महत्वपूर्ण है

पारंपरिक ऑटोमेशन आमतौर पर साफ़ तौर पर विफल होता है: कोई नियम मेल नहीं खाता, कोई फ़ील्ड खाली है या API त्रुटि लौटा देता है।

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

इसका मतलब है कि agentic workflows को भरोसे, अनुमतियों, सबूत और मानवीय अधिकार के लिए स्पष्ट सीमाओं की ज़रूरत है।

लक्ष्य अपवादों को खत्म करना नहीं है। लक्ष्य उन्हें दृश्यमान, स्वामित्वयुक्त और पुनर्प्राप्त करने योग्य बनाना है।

डिज़ाइन करने के लिए पाँच अपवाद श्रेणियाँ

1. जानकारी का अभाव

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

2. परस्पर विरोधी सबूत

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

3. कम-भरोसे वाले AI निर्णय

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

4. सिस्टम और इंटीग्रेशन विफलता

API समय पर जवाब नहीं देतीं, प्रमाणीकरण समाप्त हो जाता है और तृतीय-पक्ष सिस्टम उपलब्ध नहीं रहते। बिना सोचे-समझे फिर से कोशिश करने से डुप्लीकेट कार्रवाइयाँ हो सकती हैं। उत्पादन वर्कफ़्लो में idempotency, retry limits, failure states और reconciliation होना चाहिए।

5. नीति या अनुमति सीमाएँ

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

ASTACKRA का Trust Center उन संचालन सिद्धांतों को समझाता है जिन्हें हम पहुँच, मानवीय अधिकार, observability और recovery के लिए अपनाते हैं।

केवल अलर्ट नहीं, handoff भी डिज़ाइन करें

कमज़ोर अपवाद सिस्टम एक नोटिफ़िकेशन भेजता है जिसमें लिखा होता है “कुछ गलत हो गया।” एक उपयोगी सिस्टम अगले स्वामी को समस्या सुलझाने के लिए सब कुछ देता है।

एक अच्छा handoff शामिल करता है:

• क्या हुआ
• वर्कफ़्लो क्यों रुका
• संबंधित सबूत
• पिछली कार्रवाइयाँ
• कौन-सा निर्णय चाहिए
• समय-सीमा या व्यावसायिक प्रभाव
• समाधान और पुनःआरंभ करने का सीधा रास्ता

इससे कर्मचारियों पर मानसिक बोझ कम होता है और अपवाद छिपी हुई कतारों में बदलने से बचते हैं।

अपवादों को डेटा बनना चाहिए

हर अपवाद एक उत्पाद संकेत भी है।

अगर वही गायब दस्तावेज़ बार-बार सामने आता है, तो intake सुधारें। अगर कोई इंटीग्रेशन अक्सर विफल होता है, तो उसे मज़बूत करें। अगर लोग लगातार किसी खास AI recommendation को ओवरराइड करते हैं, तो prompt, model, rule या evidence set पर फिर से विचार करें। अगर एक approval stage देरी पैदा करता है, तो ownership को फिर से डिज़ाइन करें।

समय के साथ, exception data बताता है कि operating model को कहाँ सुधारने की ज़रूरत है।

एक व्यावहारिक वर्कफ़्लो टेस्ट

किसी भी प्रक्रिया को ऑटोमेट करने से पहले, सफल पथ का नक्शा बनाइए और फिर पूछिए:

• इस पथ के टूटने के सबसे संभावित दस कारण क्या हैं?
• किन विफलताओं पर फिर से कोशिश करना सुरक्षित है?
• किन मामलों में इंसान की ज़रूरत होगी?
• कौन-सा सबूत दिखाना अनिवार्य है?
• उपयोगकर्ता को वर्तमान स्थिति कैसे पता चलेगी?
• वर्कफ़्लो कैसे फिर से शुरू होगा?

अगर इन सवालों के जवाब नहीं हैं, तो ऑटोमेशन अभी production-ready नहीं है।

पहले दिन से ही recovery के लिए बनाइए

विश्वसनीय ऑटोमेशन कोई सीधी रेखा नहीं है। यह एक नियंत्रित सिस्टम है, जिसमें स्पष्ट अवस्थाएँ, स्वामित्व और recovery routes होते हैं।

अधिक व्यावहारिक सिस्टम-डिज़ाइन सोच के लिए Project Risk Radar, Architecture Library और ASTACKRA Automation देखें। अगर आप कोई custom workflow बना रहे हैं, तो विकास से पहले समस्या को संरचित करने के लिए Project Planner का उपयोग करें।