प्रस्तावित सिंक में बीस डिब्बे हैं. सातवां स्टेटस स्प्रेडशीट में कॉपी करता है. आठवां उसे ईमेल प्लेटफ़ॉर्म के लिए बदलता है. नौवां आयात मंज़ूर करने के लिए प्रबंधक को ईमेल करता है. योजना पूछती है कि सात से नौ तक कौन सा एजेंट काम करेगा.
पहला सवाल है कि वे डिब्बे हैं क्यों. यह वास्तविक टीम का ऑडिट नहीं, उदाहरण है.
वर्कफ़्लो डिज़ाइन की चर्चा काम के चार वर्ग सुझाती है: चरण हटाएं, सामान्य कोड लें, एजेंट लें या मानवीय निर्णय छोड़ें. उपयोगी कदम मॉडल चुनने से पहले है. चरण हटाने से उसके आसपास की सारी व्यवस्था अनावश्यक हो सकती है.
ग्राहक को दिखने वाले परिणाम से शुरू करें
वर्कफ़्लो को देने वाला परिणाम नाम दें. स्टोर से ईमेल कनेक्शन में यह “खरीदने वाले ग्राहक को कार्ट याद दिलाने वाला संदेश न मिले” हो सकता है. इससे स्थिति, समय और बाहर करने का नियम निकलता है. स्प्रेडशीट, रात का पूरा एक्सपोर्ट या प्रबंधक का इनबॉक्स नहीं.
नीचे Tajo का चित्र प्रस्तावित मैपिंग और चालू करने से पहले की सीमा पर ध्यान देता है. यह कार्ट रिमाइंडर रोकने की सुविधा लागू नहीं करता. उस परिणाम के लिए पहले ख़रीदारी संकेत और रोकने का नियम तय करना होगा. एक और मैप्ड फ़ील्ड इन फ़ैसलों की जगह नहीं ले सकता.
सिंक चलने से पहले उसकी समीक्षा करें
ग्राहक अपडेट मेरे ईमेल प्लेटफ़ॉर्म पर सिंक करें.
ग्राहक सिंक
| स्रोत फ़ील्ड | डेस्टिनेशन फ़ील्ड | नियम |
|---|---|---|
email | EMAIL | सीधा |
first_name | FIRSTNAME | सीधा |
last_name | LASTNAME | सीधा |
कृत्रिम डेटा वाला प्रीव्यू सफल
3 फ़ील्ड मैप हुए · डेस्टिनेशन पर कोई राइट नहीं
यह उदाहरणात्मक लेआउट Tajo के मैपिंग टूल पर आधारित है. कृत्रिम प्रीव्यू और सेव किया गया ड्राफ़्ट सिंक चालू नहीं करते.
परिणाम से पीछे मौजूदा रास्ता चलें. हर चरण के गायब होने पर क्या बिगड़ेगा पूछें. असली नियंत्रण का उत्तर है: सहमति खो जाएगी, भुगतान विवाद छूटेगा या बिना अनुमति संदेश जा सकता है. आदत वाला हैंडऑफ़ केवल ऐतिहासिक उत्तर दे सकता है: पुराने सिस्टम को फ़ाइल चाहिए थी.
हटाने वाला वर्ग सुरक्षा उपाय मिटाने की अनुमति नहीं. वर्ग चुनने से पहले हर चरण का उद्देश्य देखें.
- आवश्यक परिणामग्राहक परिणामपीछे चलें
- चरण जांचेंउद्देश्य और नियंत्रणबेकार चरण हटाएं
- बचा कामस्वामी और टेस्ट
जांच डिलीवर होने वाली चीज़ और उसकी वास्तविक रक्षा करने वाली निर्भरता पहचानती है. स्प्रेडशीट में कहीं और न दर्ज बिज़नेस निर्णय हो तो फ़ाइल हटने पर भी निर्णय बचना चाहिए.
| चरण प्रकार | सवाल | उदाहरण के कार्ट वर्कफ़्लो में |
|---|---|---|
| हटाएं | आवश्यक परिणाम बनाता या बचाता है? | डुप्लिकेट एक्सपोर्ट जिसे कोई नहीं पढ़ता |
| सामान्य कोड | नियम सटीक और स्थिर है? | सत्यापित खरीद पर याद दिलाना रोकें |
| मॉडल निर्णय | सीमित व्याख्या चाहिए? | मुक्त पाठ अनुरोध को सही टीम भेजना |
| व्यक्ति या स्वीकृत नीति | क्या चुनाव अधिकार देता है या गंभीर असर डालता है? | ग्राहक डेटा पहुंच मंज़ूर करना |
तालिका डिज़ाइन का साधन है. किसी कंपनी के असली चरणों का वर्गीकरण रिपोर्ट नहीं करती.
सटीक नियम कोड में रखें
API कॉल, फ़ील्ड जांच, समय तुलना या अनुमति जांच मॉडल के अनुमान से बेहतर नहीं बनती. कोड स्थिर शर्त व्यक्त कर सकता है, दो बार एक जैसा चलता और जांची जा सकने वाली विफलता देता है. नियम कहा जा सके वहां कोड लें.
कार्ट उदाहरण में खरीद इवेंट देर या दो बार आ सकता है. प्रोग्राम ऑर्डर पहचाने, वर्तमान स्थिति मिलाए और खरीद ज्ञात हो तो संदेश रोके. खरीद हुई या नहीं तय न हो तो अनिश्चितता स्थिति चाहिए. मॉडल को ग्राहक न खरीदने का अनुमान लगाने की अनुमति खुद नहीं मिलती.
कुछ काम सटीक नियम से नहीं निपटते. सहायता अनुरोध कह सकता है, “कल खरीदा था, लेकिन रसीद में पुराना पता है.” उसे सही टीम भेजना सीमित अर्थ निर्णय मांग सकता है. आउटपुट ज्ञात टीम या “अनिश्चित” हो, ऑर्डर बदलने की खुली छूट नहीं. मॉडल निर्णय को पहुंच और लिखाई लागू करने वाले कोड से अलग रखें.
एक एजेंट चरण छिपा सकता है
“एजेंट वर्कफ़्लो पढ़कर सब कर सकता है.” डेमो में सरल लगता है. प्रोडक्शन में फिर भी बताना होगा वह रिकॉर्ड क्यों देख सकता, क्या कर सकता और खराब कार्य कैसे लौटेगा. व्यापक एजेंट वही चरण प्रॉम्प्ट में छिपाकर ऑडिट करने योग्य नाम मिटा सकता है.
दूसरी आपत्ति है कि चार-वर्ग जांच में खुद समय लगता है. सही. छोटा रखें. ग्राहक परिणाम एक चुनें, ज़रूरी चरण लिखें और हर चरण क्या जोड़ता है पूछें. अभ्यास तभी मूल्यवान है जब काम घटे या स्वामित्व साफ़ हो. आस-पास के हर सिस्टम का लंबा ऑडिट एक और डिब्बा है.
सामान्य और विफल मामला लेकर वर्गीकरण जांचें. हटाया चरण छिपा नियंत्रण था तो टेस्ट दिखाए. मॉडल निर्णय उदाहरण पर जांचा न जा सके तो सीमित करें या व्यक्ति को लौटाएं. हर ग्राहक अपवाद पर कोड बदलना पड़े तो स्थिर तकनीकी तरीका स्थानीय बिज़नेस नियम से अलग करें.
जांच को रुकने का नियम भी चाहिए. टीम हर काम को तब तक तोड़ सकती है जब तक वर्गीकरण की लागत बचत से अधिक हो जाए. बचे हर चरण का स्वामी, ट्रिगर और जांचा जा सकने वाला कारण मिल जाए तो रुकें. डिज़ाइन बदल सकने वाली एक अनिश्चितता दर्ज करें और सबसे छोटे लाइव हिस्से में जांचें. सिंक में यह हो सकता है कि खरीद इवेंट कतार वाले संदेश को रोकने से पहले पहुंचता है या नहीं. इंटीग्रेशन गाइड व्यापक योजना देती है; चार वर्ग उसे बेकार चरण बचाने से रोकते हैं. वर्कफ़्लो या अनुमति बदले तो वर्ग फिर देखें.
सबसे सस्ता चरण वह है जिसकी परिणाम को कभी ज़रूरत ही नहीं थी.
अक्सर पूछे जाने वाले प्रश्न
ऑटोमेशन से पहले क्या हटाएं?
केवल हटाए जा सकने वाले हैंडऑफ़, डुप्लिकेट रिकॉर्ड या अनुपयोगी रिपोर्ट के कारण मौजूद चरण उम्मीदवार हैं. हटाने से पहले उसके बाद के उपयोग और नियंत्रण देखें.
किस चरण में मॉडल चाहिए?
स्थिर सटीक नियम से व्यक्त न हो सकने वाले सीमित अर्थ संबंधी निर्णय में मॉडल लें. दिखाई देने वाला इनपुट, तय प्रकार का आउटपुट और अनिश्चितता का रास्ता रखें.
कौन से निर्णय व्यक्ति के पास रहें?
सहमति चाहने, अनुमति देने या सिस्टम के अधिकार से बाहर परिणाम लाने वाले चुनाव जवाबदेह व्यक्ति या स्पष्ट स्वीकृत नीति के पास रखें.