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

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

1. क्या आप प्रक्रिया को सीधे-सादे चरणों में समझा सकते हैं?

जो होता है उसे ट्रिगर से लेकर अंतिम नतीजे तक सरल क्रमांकित चरणों में लिखिए। हर चरण कौन करता है? वह क्या देखता है? वह क्या तय करता है? वह कौन सा सिस्टम खोलता है?

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

2. क्या यह चरण होना भी चाहिए?

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

3. क्या यह बार-बार होने वाला, नियमों पर चलने वाला और काफ़ी बार होने वाला काम है?

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

कमज़ोर उम्मीदवार वे हैं जो काफ़ी हद तक समझ-बूझ पर निर्भर हैं, हर बार अलग होते हैं, या साल में एक बार होते हैं। जो काम कभी-कभार होता है वह आमतौर पर ऑटोमेट करने लायक नहीं होता, जब तक कि उसमें जोखिम ज़्यादा न हो और गलती आसान न हो।

4. “सही” का मतलब क्या है?

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

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

5. डेटा कितना साफ़ है?

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

6. अपवाद क्या हैं?

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

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

7. इंसान को कहाँ शामिल रहना चाहिए?

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

8. सिस्टम आपस में कैसे जुड़ेंगे?

सोचिए कि ऑटोमेशन अपने ज़रूरी सिस्टम तक कैसे पहुँचेगा।

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

यह भी देखें कि हर सिस्टम का मालिक कौन है। कुछ वेंडर स्वचालित एक्सेस पर रोक लगाते हैं या API इस्तेमाल पर शुल्क लेते हैं। बनाने से पहले यह जान लेना बेहतर है।

9. फ़ेल होने पर क्या होता है?

यह कभी न कभी विफल होगा। पासवर्ड की मियाद खत्म हो जाती है, सप्लायर फ़ाइल का फ़ॉर्मेट बदल देता है, सर्वर गलत समय पर रीस्टार्ट हो जाता है। सवाल यह है कि क्या आपको पता चलेगा।

पहले से तय कर लें:

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

चुपचाप फ़ेल होना असली दुश्मन है। जो जॉब ज़ोर से फ़ेल होता है वह असुविधा है। जो चुपचाप फ़ेल होता है वह जोखिम है।

10. क्रेडेंशियल और संवेदनशील डेटा कहाँ रहते हैं?

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

11. इसकी देखभाल कौन करेगा?

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

12. क्या इसमें AI होना चाहिए?

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

13. छोटी शुरुआत करें, और उसे साबित करें

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

संक्षेप में

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

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