प्रस्तावना

पहली और दूसरी कड़ी में हमने देखा कि EUC और कामी एक्सेल ने कैसे अल्पकाल में फ्रंटलाइन को बचाया लेकिन दीर्घकाल में संगठन को नकारात्मक विरासत सौंप दी। इस लेख में हम दृष्टि को वर्तमान पर लाते हुए RPA और नो-कोड/लो-कोड जैसे आधुनिक सिटिजन डेवलपमेंट प्लेटफ़ॉर्म के उजाले और अंधेरे का परीक्षण करेंगे।

ये उपकरण कामी एक्सेल की कहानी को दोहराते हैं, पर पैमाने और निर्भरता के कारण कहीं अधिक जोखिम समेटे हैं। अगली कड़ी में हम जिस जनरेटिव एआई के प्रभाव को देखेंगे, उसके लिए भी इनका स्वभाव समझना आवश्यक है।

पूरी श्रृंखला

उजाला── इन्हें क्यों अपनाया गया

तुरंत परिणाम

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

‘दृश्यता’ की मनाने वाली शक्ति

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

नागरिकों के लिए पहला कदम

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

परछाईं（1）── व्यावहारिक उपयोग में उभरने वाली “प्रोफ़ेशनल की दीवार”

ऊपरी तौर पर यह “किसी के लिए भी आसान” लगता है, लेकिन वास्तविक काम में गहराई से इस्तेमाल करने पर प्रोग्रामिंग जैसी सोच और सिस्टम इंजीनियरिंग की दृष्टि की ही मांग होती है।

  • नियंत्रण संरचनाएँ अनिवार्य हैं
    ग्राहक की शर्तों के अनुसार प्रक्रिया विभाजित करनी हो तो शर्तीय शाखाएँ (If/Else) चाहिए। सैकड़ों रिकॉर्ड संभालने हों तो लूप (ForEach) अनिवार्य हैं। बाहरी सिस्टम के विलंब और त्रुटियों से निपटने के लिए अपवाद प्रबंधन (Try/Catch) ज़रूरी हो जाता है। GUI में घटकों को खींचना-छोड़ना भले आसान लगे, पर सार रूप में यह प्रोग्रामिंग ही है।

  • डेटा संरचना की समझ आवश्यक है
    JSON या एरे को खोलना, उनकी परतों को मैप करना, तारीख़ और मानों का प्रारूप एकरूप करना—ये कदम व्यावसायिक समन्वय के लिए अनिवार्य हैं। मात्र तालिका-जैसा सोचना काफी नहीं; डेटा संरचना न समझें तो तंत्र ढह जाता है।

  • सिस्टम एकीकरण की जटिलता बनी रहती है
    API प्रमाणीकरण की समयसीमा, कई प्रणालियों में स्थिरता बनाए रखना, रेट-लिमिट का सामना करना—ये सब पारंपरिक सॉफ़्टवेयर इंजीनियरिंग की ही समस्याएँ हैं जो GUI के पीछे छिपी रहती हैं।

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

ऐसी दीवार के सामने सिटिजन डेवलपर्स के लिए अकेले उत्पादन-योग्य सिस्टम बनाना और संभालना कठिन हो जाता है। अंततः विशेषज्ञों पर निर्भरता बनी रहती है, और क्षमता की मूल समस्या वैसे ही खड़ी रहती है।

परछाईं（2）── वेंडर लॉक-इन और माइग्रेशन की कठिनाई

कामी एक्सेल में कम से कम सब कुछ एक फ़ाइल में सीमित था। तालिका डेटा को CSV में निकाला जा सकता था, और सूत्र या मैक्रो भले जटिल हों, फिर भी किसी हद तक पढ़े जा सकते थे। इसके विपरीत, आधुनिक RPA या नो-कोड/लो-कोड से बने समाधान अधिकांशतः प्लेटफ़ॉर्म-विशिष्ट UI या विन्यास फ़ाइलों में कैद हो जाते हैं।

  • दूसरे वेंडर पर जाना लगभग “शुरू से दोबारा बनाना” ही होता है।
  • SaaS का बंद होना या विनिर्देश बदलना उपयोगकर्ता के नियंत्रण से बाहर है, और जमा की गई परिसंपत्तियाँ पल भर में बेकार हो सकती हैं।
  • PaaS पर निर्मित समाधान संबंधित क्लाउड इकोसिस्टम से बाँध देते हैं, जिससे दूसरे वातावरण में ले जाना अत्यंत कठिन हो जाता है।
  • जब लॉजिक कोड के बजाय UI में बंधा हो, तो समस्या-स्थल खोज पाना मुश्किल होता है; कई बार हर ब्लॉक को खोलकर देखना पड़ता है।
  • कुछ टूल ऐसे डिज़ाइन होते हैं कि तब तक अंदर की प्रक्रिया नहीं दिखती जब तक घटक को डबल-क्लिक न करें, जिससे पठनीयता और कम हो जाती है।

इस तरह, केवल तालिका फ़ाइलों पर टिके कामी एक्सेल की तुलना में निर्भरता और ऋण का जोखिम कई गुना बढ़ जाता है।

परछाईं（3）── प्रबंधन को बहकाने वाला “दृश्यता पूर्वाग्रह”

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

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

प्रबंधन की इस安心 भावना और तकनीकी टीम की आशंका के बीच का अंतर अपनाने को तेज़ करता है, लेकिन भविष्य के ऋण को भी उतना ही बढ़ाता है।

“कामी एक्सेल 2.0” के युग की ओर

इन अवलोकनों को जोड़ें तो RPA और नो-कोड/लो-कोड टूल कामी एक्सेल का वही पैटर्न दोहराते हैं। वे तुरंत प्रभाव से फ्रंटलाइन को राहत देते हैं, दृश्यता से प्रबंधन को राज़ी करते हैं, और फिर ब्लैक बॉक्स बनकर संगठन पर बोझ डालते हैं।

फर्क यह है कि असर का पैमाना कहीं बड़ा है। कामी एक्सेल फ़ाइल स्तर पर सीमित था, जबकि आधुनिक प्लेटफ़ॉर्म क्लाउड और मुख्य व्यवसाय प्रक्रियाओं में समा जाते हैं और पूरे संगठन को प्लेटफ़ॉर्म-स्तरीय ऋण से बाँध देते हैं। Excel से भी अधिक कड़ा लॉक-इन इन्हें “कामी एक्सेल 2.0” कहने का आधार देता है।

सारांश

  • RPA और नो-कोड/लो-कोड टूल्स को उनकी त्वरित उपलब्धि और दृश्यता की प्रभावशीलता ने लोकप्रिय किया।
  • उत्पादन स्तर पर टिकाऊ उपयोग के लिए नियंत्रण प्रवाह, डेटा संरचना, सिस्टम एकीकरण और संचालन डिज़ाइन का ज्ञान अनिवार्य है; केवल सिटिजन डेवलपर्स के दम पर यह संभव नहीं।
  • प्लेटफ़ॉर्म-विशिष्ट UI माइग्रेशन को बेहद कठिन बनाते हैं और वेंडर लॉक-इन को गहरा करते हैं।
  • प्रबंधन का “दृश्यता पूर्वाग्रह” इन जोखिमों को कम करके आँकता है और अपनाने की रफ़्तार को बेधड़क बढ़ा देता है।

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

अगली कड़ी: जेनरेटिव एआई सिटिजन डेवलपमेंट को कैसे प्रभावित करता है 4/7