यहाँ आपके लिए हिंदी अनुवाद प्रस्तुत है:
अपने पिछले लेख में, मैंने AI आवश्यकता परिभाषा की वर्तमान स्थिति के बारे में लिखा था—कैसे यह प्रक्रिया 'व्यवस्थित करने' से 'निर्णय लेने' की ओर बदल रही है, और मेरी चिंता यह है कि कई कार्यस्थल बिना इस बदलाव को समझे, आँख बंद करके अपनी सोच को ऑफलोड कर रहे हैं।
इस बार, मैं एक संबंधित मुद्दे पर एक और अलार्म बजाना चाहता हूँ।
समस्या यह है कि CTO और आंतरिक SE, क्योंकि वे अब AI-संचालित डेवलपमेंट के साथ बहुत तेज़ी से कोड कर सकते हैं, व्यवसाय विभागों के केवल ऑर्डर लेने वाले बन रहे हैं—अनिवार्य रूप से 'आंतरिक SIers'।
AI-संचालित डेवलपमेंट द्वारा निर्मित नई गतिशीलता
यह एक निर्विवाद तथ्य है कि AI-संचालित डेवलपमेंट के प्रसार ने कोडिंग की बाधा को नाटकीय रूप से कम कर दिया है।
इसके परिणामस्वरूप, व्यवसाय विभागों से 'मुझे यह चाहिए' या 'मैं इसे सिस्टमाइज़ करना चाहता हूँ' जैसे अनुरोध पहले की तुलना में अतुलनीय गति से आ रहे हैं। यह असामान्य नहीं है कि व्यवसाय कर्मचारी स्वयं AI का उपयोग करके आवश्यकताओं को सूचीबद्ध करते हैं, या प्रोटोटाइप भी बनाते हैं।
पहली नज़र में, यह एक अच्छी बात लगती है। यह एक आदर्श परिदृश्य जैसा दिखता है जहाँ व्यवसाय विभाग DX में अग्रणी भूमिका निभाते हैं और सिस्टम को जल्दी से लॉन्च करने के लिए IT के साथ सहयोग करते हैं।
हालाँकि, यहाँ एक जाल है।
मुझे लगता है कि अधिक से अधिक CTO और आंतरिक SE 'ऐसे लोग बन रहे हैं जो केवल व्यवसाय विभागों के अनुरोधों को आकार देते हैं।' वे एक अनुरोध प्राप्त करते हैं, उसे तकनीकी रूप से साकार करते हैं, और उसे वितरित करते हैं। यह वास्तव में एक आंतरिक SIer करता है।
ऑर्डर लेने के अंत में क्या इंतजार करता है
व्यवसाय के अनुरोधों का जवाब देना अपने आप में गलत नहीं है। समस्या यह है कि जब आप प्रत्येक व्यक्तिगत विभाग के अनुरोध को ज्यों-का-त्यों पूरा करना जारी रखते हैं तो क्या होता है।
मैं इसे 'आवारा सिस्टम' और 'आवारा डेटाबेस' का प्रसार कहता हूँ।
सेल्स अपना खुद का CRM बनाता है, मार्केटिंग एक अलग डेटा विश्लेषण प्लेटफॉर्म स्थापित करता है, और कस्टमर सपोर्ट अपना खुद का टिकट प्रबंधन बनाता है। प्रत्येक विभाग संतुष्ट है क्योंकि उन्हें उच्च गति पर अपने काम के लिए अनुकूलित एक सिस्टम मिला।
लेकिन पूरी कंपनी के बारे में क्या?
डेटा अलग-अलग जगहों पर बिखरा हुआ है, और फॉर्मेट एकीकृत नहीं हैं। वही ग्राहक जानकारी कई डेटाबेस में अलग-अलग रूपों में मौजूद है। जब भी आप विभागों के बीच डेटा लिंक करने का प्रयास करते हैं, तो आपको मैन्युअल काम या कस्टम डेवलपमेंट की आवश्यकता होती है।
यह एक तकनीकी साइलो है।
क्योंकि AI-संचालित डेवलपमेंट सिस्टम बनाना इतना आसान बना देता है, यह साइलोइंग अभूतपूर्व गति से आगे बढ़ता है। पहले, उच्च डेवलपमेंट लागत एक प्राकृतिक ब्रेक के रूप में कार्य करती थी। 'इसे बनाना मुश्किल है, तो आइए केवल वही सख्ती से चुनें जो वास्तव में आवश्यक है' की एक गतिशीलता थी।
अब, वह ब्रेक चला गया है। क्योंकि इसे बनाया जा सकता है, यह बनाया जाता है। परिणामस्वरूप, आवारा सिस्टम और डेटाबेस कई गुना बढ़ जाते हैं, और प्रबंधित करने के लिए ऐप्स और इंफ्रास्ट्रक्चर की संख्या बढ़ती जाती है।
AI युग में यह घातक क्यों है
आप सोच सकते हैं, 'भले ही सिस्टम थोड़े बिखरे हुए हों, यह ठीक है जब तक वे काम करते हैं।' हालाँकि, AI युग में, यह साइलोइंग पहले से कहीं अधिक घातक समस्याएँ पैदा करता है।
कारण सरल है: AI का मूल्य डेटा एकीकरण की डिग्री के समानुपाती होता है।
AI वास्तव में अपनी शक्ति तब दिखाता है जब डेटा पूरी कंपनी में एकीकृत होता है, जिससे ऐसी अंतर्दृष्टि की अनुमति मिलती है जो विभागों में फैली होती है। केवल जब सेल्स डेटा, ग्राहक इतिहास, मार्केटिंग प्रभाव और वित्तीय डेटा एकीकृत होते हैं, तब AI प्रबंधन निर्णयों में सहायता करने वाली अंतर्दृष्टि प्रदान कर सकता है।
आवारा सिस्टम से भरे वातावरण में, डेटा शुरू से ही जुड़ा नहीं है। आप विभागों के भीतर छोटे AI ऑप्टिमाइज़ेशन प्राप्त कर सकते हैं, लेकिन आप कभी भी कंपनी-व्यापी AI उपयोग तक नहीं पहुँच पाएंगे—जिसका वास्तव में व्यवसाय पर प्रभाव पड़ता है।
विभागीय ऑप्टिमाइज़ेशन जमा करके, आप स्थायी रूप से कुल ऑप्टिमाइज़ेशन खो देते हैं। यह वह जोखिम है जो ऑर्डर लेने वाले CTO और आंतरिक SE अनजाने में पैदा करते हैं।
CTO और आंतरिक SE को निभानी चाहिए वास्तविक भूमिका
तो, CTO और आंतरिक SE को कैसा होना चाहिए?
उत्तर स्पष्ट है: केवल 'निर्माता' नहीं बल्कि 'डिज़ाइनर और निर्णायक' बनें।
यहाँ 'डिज़ाइन' का मतलब व्यक्तिगत सिस्टम डिज़ाइन करना नहीं है। इसका मतलब है पूरी कंपनी के लिए डेटा और सिस्टम आर्किटेक्चर डिज़ाइन करना।
जब किसी व्यवसाय विभाग से कोई अनुरोध आता है, तो केवल इसे बनाने के बजाय, आप निर्णय लेते हैं कि 'इस अनुरोध को कंपनी-व्यापी आर्किटेक्चर के भीतर कैसे रखा जाना चाहिए।' कुछ मामलों में, आपको कहना होगा, 'इसे व्यक्तिगत रूप से नहीं बनाया जाना चाहिए।' यदि इसे मौजूदा प्लेटफॉर्म का विस्तार करके संभाला जा सकता है, तो उन्हें वहाँ मार्गदर्शन करें।
यह व्यवसाय विभागों के लिए असुविधाजनक लग सकता है। वे पूछ सकते हैं, 'जब मैं बस यह अभी बनवाना चाहता हूँ तो आप पूरी कंपनी की बात क्यों कर रहे हैं?'
लेकिन केवल CTO और आंतरिक SE ही वह निर्णय ले सकते हैं। व्यवसाय विभागों के पास अपने स्वयं के क्षेत्र को अनुकूलित करने के लिए प्रोत्साहन होते हैं, लेकिन कंपनी-व्यापी आर्किटेक्चर की रक्षा करने का कोई प्रोत्साहन नहीं होता। यही कारण है कि तकनीकी विशेषज्ञों को कुल ऑप्टिमाइज़ेशन के संरक्षक की भूमिका निभानी चाहिए।
'न बनाने का निर्णय' सर्वोच्च तकनीकी कौशल है
विडंबना यह है कि AI युग में CTO और आंतरिक SE के लिए आवश्यक सबसे महत्वपूर्ण क्षमता 'न बनाने का निर्णय' हो सकती है। यही कारण है कि मैं उन्हें 'निर्णायक' कहता हूँ।
एक व्यवसाय विभाग से एक अनुरोध आता है। यह तकनीकी रूप से संभव है। AI के साथ, इसे कुछ दिनों में आकार दिया जा सकता है। लेकिन आपके पास यह सवाल करने की शक्ति होनी चाहिए कि क्या इसे बनाना वास्तव में पूरी कंपनी के लिए सही है।
क्या इस अनुरोध को मौजूदा प्लेटफॉर्म द्वारा संभाला जा सकता है? क्या डेटा संरचना कंपनी के नियमों के अनुरूप है? क्या कोई समान सिस्टम पहले से किसी अन्य विभाग में चल रहा है? क्या एक व्यक्तिगत रूप से अनुकूलित सिस्टम जोड़ने से भविष्य में डेटा एकीकरण मुश्किल हो जाएगा?
इन सवालों को पूछने में सक्षम होना AI युग में सच्ची तकनीकी ताकत है।
AI कोडिंग संभालेगा। हालाँकि, क्या बनाना है और क्या नहीं बनाना है, इसका निर्णय AI नहीं कर सकता। जैसा कि मैंने पिछले लेख में उल्लेख किया था कि 'आवश्यकता परिभाषा निर्णय लेने की प्रक्रिया बन जाएगी,' CTO और आंतरिक SE की भूमिका बिल्कुल उसी संरचना का अनुसरण करती है।
ऑर्डर लेने वाले होने के बजाय, कंपनी-व्यापी आर्किटेक्चर के डिज़ाइनर के रूप में आपकी भूमिका AI युग के कारण और भी महत्वपूर्ण हो जाती है।
'तैयारी की स्थिति' बनाना क्योंकि भविष्य अप्रत्याशित है
जबकि मैंने 'न बनाने के निर्णय' के महत्व पर जोर दिया है, CTO और आंतरिक SE के पास एक और दृष्टिकोण होना चाहिए।
क्योंकि AI युग में भविष्य अप्रत्याशित है, आपको कंपनी को ऐसी स्थिति में रखना चाहिए जहाँ वह किसी भी समय आगे बढ़ सके।
वर्तमान में, यह चर्चा फैल रही है कि 'SaaS मर चुका है।' जब Microsoft के CEO सत्या नडेला ने 2024 के अंत में ये शब्द कहे, तब से कई लोगों ने SaaS के अंत की भविष्यवाणी की है। वास्तव में, SaaS वैल्यूएशन संकुचित हो रहे हैं, और निवेशकों की रुचि तेज़ी से AI-नेटिव प्लेटफॉर्म की ओर बढ़ रही है।
लेकिन क्या SaaS वास्तव में मर रहा है?
मुझे नहीं लगता कि यह इतना सरल है। SaaS कंपनियाँ AI युग के लिए सॉफ्टवेयर का इष्टतम रूप खोजने के लिए R&D में भारी निवेश कर रही हैं। एजेंटिक AI एकीकरण, आउटकम-आधारित बिलिंग, उद्योग-विशिष्ट AI प्लेटफॉर्म... इस बात की उच्च संभावना है कि ऐसे उत्पाद सामने आएँगे जिनकी हम वर्तमान में कल्पना नहीं कर सकते।
दूसरे शब्दों में, 'SaaS मर चुका है' यह निष्कर्ष निकालना और इन-हाउस डेवलपमेंट में कूदना, और 'SaaS काफी है' सोचकर सोचना रोक देना, दोनों जोखिम हैं।
एक CTO/आंतरिक SE को जो रुख अपनाना चाहिए, वह किसी एक पर दांव लगाना नहीं है। यह एक ऐसा आर्किटेक्चर डिज़ाइन करना है जो चाहे जो भी हो, जवाब दे सके।
विशेष रूप से, डेटा को कैसे रखा जाए, इसे मानकीकृत करें और एक ऐसी संरचना बनाएँ जो किसी विशिष्ट SaaS या टूल में लॉक न हो। सिस्टम कनेक्शन को APIs के माध्यम से शिथिल रूप से युग्मित रखें। आवारा सिस्टम को फैलने न दें; कंपनी के डेटा फाउंडेशन को एकीकृत करें।
इस डिज़ाइन दर्शन के साथ, यदि SaaS विकसित होता है और बेहतर उत्पाद आते हैं, तो आप स्विच कर सकते हैं। इसके विपरीत, यदि यह स्पष्ट हो जाता है कि किसी निश्चित क्षेत्र के लिए इन-हाउस बनाना बेहतर है, तो आप वहाँ माइग्रेट कर सकते हैं।
आप भविष्य की भविष्यवाणी नहीं कर सकते। लेकिन आप एक ऐसी संरचना बना सकते हैं जो उसका जवाब दे सके। यही AI युग में CTO और आंतरिक SE से अपेक्षित आर्किटेक्चरल डिज़ाइन का सार है। इसके विपरीत, केवल तकनीकी विशेषज्ञ ही ऐसा कर सकते हैं। मैं नहीं चाहता कि आप उन कीमती संसाधनों को एक आंतरिक SIer के रूप में खर्च करें।
AI के साथ अपस्ट्रीम प्रक्रियाओं को तेज़ करना
अपस्ट्रीम प्रक्रियाओं के परिवर्तन का समर्थन करने के एक उपकरण के रूप में, हमने 'GEAR-UI,' एक स्क्रीन परिभाषा और मॉक जनरेशन AI टूल, को OSS (ओपन सोर्स सॉफ्टवेयर) के रूप में जारी किया है।
इसे OSS बनाकर, हम उपयोगकर्ताओं को कार्यान्वयन की बाधाओं से मुक्त करने और उन्हें आवश्यकताओं का सामना करने में मदद करने की आशा करते हैं। कृपया इसका उपयोग विशेष रूप से उन 'पूर्व-निर्माण' निर्णयों के लिए करें जिनकी मैंने चर्चा की है।
अनुकूलन निःशुल्क है। कृपया इसका उपयोग करें।
