समस्या हमेशा ‘process’ ही होती है, बेवकूफ
(its.promp.td)- सिर्फ AI अपनाने से business समस्याएँ हल नहीं होतीं, और अगर अक्षम process को automate किया जाए तो नतीजा सिर्फ ‘कचरा और तेज़ी से पैदा करना’ होता है
- कंपनियाँ अक्सर AI को जादुई छड़ी समझ लेती हैं, लेकिन AI संगठन को अधिक समझदार नहीं बनाता; यह सिर्फ गति बढ़ाने वाला एक tool है
- AI की एकमात्र खास ताकत unstructured data को process करने की क्षमता है, लेकिन ऐसे data पर निर्भर process खुद ही अक्सर unstructured होते हैं और documented नहीं होते
- इसलिए AI लागू करने से पहले process को design और structure करना ज़रूरी है, और input·transformation·output चरणों को स्पष्ट रूप से परिभाषित करना चाहिए
- तकनीक बदलती रहती है, लेकिन business efficiency के सिद्धांत नहीं बदलते, और AI की सफलता की कुंजी आखिरकार process optimization में ही है
AI strategy नहीं, business process optimization
- कंपनियाँ “AI strategy” पर चर्चा करती हैं, लेकिन वास्तव में मौजूद चीज़ सिर्फ business process optimization (BPO) है
- AI business समस्याओं को हल करने वाली कोई स्वतंत्र strategy नहीं, बल्कि पहले से मौजूद process को तेज़ करने वाला tool है
- अक्षम structure के ऊपर AI चढ़ाने से समस्याएँ सिर्फ और तेज़ी से बढ़ती हैं
‘जादुई छड़ी’ का भ्रम
- बहुत-सी कंपनियाँ मानती हैं कि AI अपने-आप inefficiency हटा देगा, लेकिन यह गलत धारणा है
- AI बुद्धिमत्ता नहीं देता, यह सिर्फ decision की speed बढ़ाता है
- गलत decision को automate करने पर यह सिर्फ ‘प्रकाश की गति से मूर्खतापूर्ण फैसले’ लेने वाला system बन जाता है
- जटिल approval procedure जैसे bureaucratic process पर AI लगाने का मतलब है कर्मचारी की तरह नाराज़ robot बना देना
unstructured data का जाल
- AI unstructured data processing में ताकत रखने वाली पहली तकनीक है
- email, Slack message, PDF, image आदि जैसे ऐसे data को समझ सकता है जिन्हें पुराना software संभाल नहीं पाता था
- लेकिन ऐसे data पर निर्भर process ज़्यादातर unstructured और informal होते हैं
- उदाहरण: customer complaint handling, marketing campaign planning आदि अक्सर documented नहीं होते और सिर्फ अनुभवी कर्मचारियों के दिमाग में मौजूद रहते हैं
- पहले computer इन्हें process नहीं कर सकते थे, इसलिए लोग खुद करते थे; इसी वजह से flowchart या standard operating procedure (SOP) मौजूद नहीं होते
जिसे design नहीं किया गया, उसे automate नहीं किया जा सकता
- AI लागू करने के लिए पहले process को स्पष्ट रूप से design और structure करना होगा
- unstructured data को संभालने के लिए workflow को ही structure देना पड़ता है
- इसके लिए नीचे दिए गए तीन सवाल ज़रूरी हैं
- Trigger: unstructured data कहाँ से पैदा होता है
- Transformation: इंसान (या AI) को उस data से क्या निकालना या समझना है
- Output: परिणाम ERP या CRM जैसे structured system में कैसे दर्ज होगा
गति और बुद्धिमत्ता का अंतर
- AI चीज़ों को तेज़ बनाता है, अधिक समझदार नहीं
- उदाहरण:
- पारंपरिक तरीके में analyst 50 contracts को 3 दिन तक review करता है
- AI तरीके में 3 मिनट में risk clauses निकाले जा सकते हैं
- process खुद (review → risk identification → summary) वही रहता है, लेकिन AI के काम करने के लिए स्पष्ट रूप से परिभाषित procedure चाहिए
- ‘risk’ का मतलब क्या है, इसका बौद्धिक निर्णय अब भी इंसान की भूमिका है
- उदाहरण:
निष्कर्ष: process ही सब कुछ है
- AI मसीहा खोजने के बजाय, whiteboard पर लौटकर value chain की फिर से जाँच करनी चाहिए
- खासकर unstructured data से जुड़े मानव-केंद्रित जटिल क्षेत्रों को visualize करके bottleneck और waste ढूँढने चाहिए
- process सरल, तार्किक और मज़बूत होने के बाद ही AI को acceleration layer की तरह इस्तेमाल किया जा सकता है
- तकनीक बदलती है, लेकिन business efficiency के सिद्धांत नहीं बदलते
- अंततः मूल बात हमेशा process ही होती है
6 टिप्पणियां
लगता है जैसे कोई बहुत ही जाहिर सी बात कह रहा हो..
ऐसी मिलती-जुलती पोस्ट लगातार आती रहती हैं कि "बस क्लिक मत करो, सोचो और लिखो", तो लगता है अमेरिका में AI के दुरुपयोग के काफ़ी मामले हैं..
मैंने 2007 में सेना के कंप्यूटर सेंटर में डेवलपर के रूप में पहली बार काम शुरू किया था, और तब मैंने सीखा था कि "डेवलपर को डोमेन को पर्याप्त रूप से समझने के बाद यूज़र requirements को परिष्कृत करके सबसे बेहतर विकल्प पेश करना चाहिए"।
आजकल लगता है कि "यूज़र जैसा कहे वैसा ही कर दो" ही मुख्यधारा है। सच कहूँ तो शायद यूज़र भी वही ज़्यादा पसंद करते हों..?
(मैं financial sector में SI कर रहा/रही हूँ) कई developers से पूछा कि आप expert हैं, तो ग्राहक जैसा कहे वैसा ही करने के बजाय क्या ग्राहकों से यह कहना कैसा रहेगा कि उन्हें इस तरह काम करना चाहिए।
इसका क्या मतलब है?
अगर आप यह पूछ रहे हैं कि "नतीजा वैसा ही है जैसा हम कल्पना करते हैं" का क्या मतलब है।
इसका कोई खास मतलब नहीं है, बस ऐसा ही है—इस तरह के एक शब्द-खेल जैसा लिख दिया था.
Hacker News की राय
यह process और documentation से जुड़ा मेरे पसंदीदा किस्सों में से एक है
जब मैं एक hedge fund में काम करता था, तब हर शाम अगले trading day की तैयारी के लिए 18-step procedure में step 7 फेल हो जाता था
मैंने उस step को document किया और कई लोगों को दिखाया, और सब इस बात पर सहमत थे कि “step 7 का document गलत था”, लेकिन “असल में step 7 को क्या करना चाहिए” इस पर बिल्कुल सहमति नहीं थी
इस अनुभव से मुझे समझ आया कि सिर्फ ‘अभी जो हो रहा है उसे लिख देना’ भर से भी लोग असली process को समझने और उस पर सहमत होने की दिशा में बहुत आगे बढ़ जाते हैं
पहले जब मैंने market data system का document लिखा था, तब “यह इतना complex नहीं है” कहने वाले लोगों ने तैयार document देखकर कहा था, “यह तो सोच से ज़्यादा complex है”
“अभी step 7 वास्तव में क्या करता है, यह लिखने का समय है, इसे कैसे बदलना है इस पर चर्चा करने का नहीं” ऐसा कहने पर भी दोनों बातें बार-बार मिल जाती हैं
मेरा मानना है कि पहले चाहे वह गलत तरीके से ही क्यों न हो, एक version में उसे दर्ज कर लेना चाहिए, और बाद में उसे ठीक करना चाहिए
आखिर में नतीजा यह निकला कि “documentation मत करो”, और वही असल में और बड़ी समस्या थी
documentation सहमति के लिए एक baseline देता है, और नए जुड़ने वाले लोग भी बेकार की detail-level बहस के बिना काम कर पाते हैं
अब तो मैं साफ process के बिना कोई बड़ा काम होने की कल्पना भी नहीं कर सकता
मुझे किसी CEO का 5-step product process याद आता है
AI को इनमें ‘कब’ लाना है, यह साफ होना चाहिए
बहुत से लोग इस sequence को उल्टा लागू करते हैं और फेल हो जाते हैं
इसे बहुत कम आंका जाता है, लेकिन मानव आविष्कारों में यह top 5 में होना चाहिए
“AI से गड़बड़ business process को सोना नहीं बनाया जा सकता” — यह पंक्ति बहुत असरदार लगी
आखिरकार AI strategy जैसी कोई चीज़ नहीं होती, जो होता है वह business process optimization है
मुझे लगता है समस्या नाम में ही थी — ‘Redesign’ नहीं, ‘Design’ होना चाहिए था
customer number को unify करने की कोशिश पूरी तरह उलझ गई, और आखिरकार नए numbers देने पड़े, जबकि पुराने numbers भी चलते रहे
अगर ऐसी company ने AI introduce किया होता, तो कैसी अराजकता पैदा होती, इसकी कल्पना की जा सकती है
दशकों की cost cutting और layoffs ने processes को तोड़ दिया है, और अब तो बड़ी कंपनियाँ भी ठीक से काम नहीं करतीं
AI कंपनियाँ इन्हीं खंडहरों पर data निगलकर उसे LLM output के रूप में वापस दे रही हैं और पैसा कमा रही हैं
बड़े enterprises में process को लेकर मेरे मन में mixed feelings हैं
यह average लोगों से अच्छे results निकलवाने में useful है, लेकिन exceptional लोगों के लिए यह उल्टा बेड़ी बन जाता है
इसलिए मुझे लगता है कि बेहतरीन talent को exception privileges देना एक practical रास्ता है
यानी उन्हें तेज़ी से काम करने और focus बनाए रखने के लिए कुछ procedures से छूट दे दी जाए
मैं अभी भी सोच रहा हूँ कि इस approach का process के अपने अर्थ पर क्या असर पड़ता है
जो cases बार-बार आते हैं, उनके लिए clear process होना चाहिए, लेकिन बेहतरीन engineers के लिए तेज़ी से प्रतिक्रिया देने का एक escape hatch भी होना चाहिए
average quality को ऊपर उठाने पर ceiling नीचे आ जाने की एक structural समस्या भी है
अच्छा process तो rockstar को और तेज़ी से काम करने में मदद करना चाहिए
management का paperwork को ही process समझ लेना असली समस्या है
बेतरतीब requests और non-cooperative behavior बार-बार होने लगें, तो आखिरकार procedure enforce करना ही पड़ता है
भले creative कोशिशें कम हो जाएँ, लेकिन अव्यवस्था की लागत उससे बड़ी होती है
ServiceNow form खड़ा कर देना भी प्रगति माना जाता है, यही आज की हक़ीक़त है
“AI unstructured data को संभालने वाली पहली technology है” — यह पंक्ति अच्छी लगी
unstructured data को संभालने वाले processes आम तौर पर खुद भी unstructured होते हैं — यह सार मुझे पसंद आया
वजह है बाहरी दुनिया या दूसरी teams के साथ unstructured interaction, या बहुत तरह की variability
experienced process designers ऐसे ‘semi-structured boundaries’ को मानते हैं और ध्यान से observe करते हैं
AI को भी यही principle मानना चाहिए — system की scope को ज़रूरत से ज़्यादा मत बढ़ाओ, बल्कि छोटे structured processes को unstructured environment के भीतर तैरने दो
structured data के आने से पहले भी बहुत-सी कंपनियाँ अच्छी तरह चलती थीं
search industry में 13 साल काम करके मुझे यह महसूस हुआ कि management हमेशा trendy technology से cost cutting का सपना देखती है, जबकि असल में ज़रूरत और गहरे investment की होती है
वे कहते हैं, “पुरानी technology समस्या है, लेकिन नए नाम से पैक की गई technology असली savings देगी,” और फिर नया trend बेचना शुरू कर देते हैं
20 साल process automation करने के बाद मेरा निष्कर्ष है कि undefined process को automate करने की कोशिश करोगे तो फेल होगे
requirements define करने की प्रक्रिया कभी-कभी company को और स्पष्ट भी बना देती थी, लेकिन ज़्यादातर लोग उससे बचते हैं
उसकी जगह tool में flexibility जोड़ते-जोड़ते अंत में वह बिल्कुल बेकार tool बन जाता है
दूसरी team data processing workflow को simplify करने वाला tool चाहती है, लेकिन मौजूदा process का document तक नहीं है
नतीजा यह है कि हमें उनका process उल्टा analyze करना पड़ रहा है
मैं Fred Brooks का “No Silver Bullet” quote करना चाहूँगा
link
मैंने कई कंपनियों में ERP लाते देखा है, जहाँ लोग मौजूदा process को ज्यों का त्यों ले जाना चाहते हैं और customization hell में फँस जाते हैं
budget और timeline हमेशा overshoot हो जाते थे
मुझे लगता है कि इस लेख ने मुद्दे के केंद्र को ठीक पकड़ा है
बहुत ज़्यादा process समस्या है, लेकिन structure अपने आप में हमेशा ज़रूरी है
AI structured data के साथ अच्छा काम करता है, इसलिए पूरी आज़ादी के बजाय उचित structure का संतुलन महत्वपूर्ण है
संबंधित लिंक
documentation सोच को साफ़ करने में बहुत उपयोगी है
जैसे ही आप किसी बार-बार किए जाने वाले काम को लिखते हैं, अनावश्यक steps घटाने के ideas आने लगते हैं
अभी मैं अपने business operations का एक हिस्सा AI को सौंपने की कोशिश कर रहा हूँ
जब मैं कोई छोटा e-commerce brand acquire करता हूँ, तब शुरुआती analysis के लिए LLM को लगाने हेतु 6-page prompt का इस्तेमाल करता हूँ
इस अनुभव से मुझे समझ आया कि LLM की intelligence से ज़्यादा structured task design आर्थिक value बनाती है
लेकिन अभी भी ऐसा agent नहीं है जो web browsing और file upload अपने-आप संभाल दे, इसलिए full automation मुश्किल है