Parade problem वह failure mode है जिसमें आप AI को उस workflow पर जोड़ते हैं जिसे कभी redesign नहीं किया और आपको एक तेज़ पहला कदम मिलता है जिसके पीछे ठीक वही bottleneck होता है। Parade अब भी तेज़ float के पीछे की सबसे धीमी चीज़ की रफ़्तार से पहुँचती है। आप आगे रफ़्तार महसूस करते हैं और finish पर उसका कुछ नहीं।
मैंने इसे यह नाम दिया क्योंकि यह AI adoption की सबसे सस्ती ग़लती है और देखने में सबसे मुश्किल। आप एक pilot चलाते हैं, कोई मिनटों में दो-सौ-वariant वाला creative generator demo करता है, कमरा ताली बजाता है, और छह हफ़्ते बाद campaign फिर देर से है। Generator में कुछ ग़लत नहीं था। उसके नीचे का route कभी छुआ ही नहीं गया।
मैंने advertising में 19 साल बिताए हैं, और पिछले कुछ साल उसी काम को AI के साथ दोबारा बनाने में। मेरे अनुभव से, जो teams अटकती हैं वे लगभग कभी model quality पर नहीं अटकतीं। वे उस workflow पर अटकती हैं जो AI को एक stage मानता है, default नहीं, इसलिए जिस पल machine काम वापस सौंपती है, gains बग़ल से रिस जाते हैं। चलिए बताता हूँ कहाँ।
Parade problem कैसा दिखता है
एक असली parade की तस्वीर लें। आगे की float सुंदर और तेज़ है। उसके पीछे एक marching band, एक दर्जन धीमी floats, और एक सफ़ाई दल अपनी रफ़्तार से चलता हुआ। अगर आप आगे की float को rocket car से बदल दें, parade जल्दी नहीं पहुँचती। Rocket बस आगे निकल जाती है और band के पहुँचने से पहले एक बड़ा gap बना देती है।
एक media workflow वही parade है। Research planning को feed करती है, planning activation को, activation reporting को, और reporting research के अगले दौर को। एक stage तेज़ करें और आप parade छोटी नहीं करते — आप उस stage और उसके पड़ोसियों के बीच का gap चौड़ा कर देते हैं। Parade को छोटा करने वाली अकेली चीज़ सबसे धीमे stage को हिलाना है, और सबसे धीमा stage लगभग कभी वह नहीं होता जिसे demo किया जा रहा है।
तेज़ float gap क्यों बनाती है
ऐसा होने का एक सीधा कारण है, और यह technology की problem नहीं है। यह constraint की problem है।
हर workflow में एक stage होता है जो रफ़्तार तय करता है, और आमतौर पर वह सबसे कम glamorous होता है: एक sign-off, एक data pull, एक client review, एक brief जो कभी तय नहीं हुआ। Constraint से upstream AI जोड़ना work-in-progress produce करता है, output नहीं। आप उससे ज़्यादा कच्चा माल generate करते हैं जितना अगला stage consume कर सके, और ज़्यादा माल queue में लगता है, पुराना होता है, और दोबारा काम माँगता है।
इसीलिए AI pilots इतनी बार एक तेज़ कदम और एक स्थिर cycle time report करते हैं। कदम तेज़ हुआ। Constraint नहीं हिला। और चूँकि असली लागत constraint में रहती है, business result लगभग नहीं बदलता — जबकि यही वह समय होता है जब skeptics "हमने कहा था" कहने लगते हैं और budget चुपचाप ग़ायब हो जाता है।
वे चार bottlenecks जो एक AI pilot में बच जाते हैं
जिन pilots को मैंने देखा, उनमें bottleneck लगभग हमेशा चार में से किसी एक जगह जाता है। इनमें से कोई model नहीं है।
- अनिर्णीत brief। Model निष्ठापूर्वक उस सवाल के दो सौ versions produce करता है जिसका जवाब किसी ने नहीं दिया। Bottleneck generation से upstream है, उस फ़ैसले में जिसे brief encode करना था।
- Approval queue। एक human reviewer एक दर्जन variants ध्यान से पढ़ सकता है या सौ बुरी तरह। अगर workflow अब सौ produce करता है और review capacity वही है, तो आपने ढेर हिलाया, काम नहीं।
- Data handoff। Report सेकंडों में generate होती है, फिर तीन दिन उस किसी का इंतज़ार करती है जो दो अलग systems के numbers reconcile करे। Generation कभी धीमा हिस्सा नहीं था।
- Integration seam। Output एक tool में रहता है और अगला stage दूसरे में, इसलिए एक human उनके बीच copy-paste करता है। वह copy-paste अब production line है।
Pattern देखें: चार में से तीन कौन और क्या इंतज़ार करता है के बारे में हैं, intelligence के बारे में नहीं। आप approval queue को prompts से पार नहीं कर सकते।
वह कहानी जिस पर मैं बार-बार लौटता हूँ
सबसे साफ़ उदाहरण मेरे पास एक ऐसी team है जिसने एक AI copy generator बनाया जो मिनटों में सैकड़ों headline variants produce करता था। यह सचमुच प्रभावशाली था, और सब ख़ुश थे। Campaign फिर भी कमज़ोर perform करती रही।
Bottleneck कभी headlines नहीं थे। वह यह था कि किसी ने तय नहीं किया था कि campaign कौन-सा एक संदेश कह रही है। Generator ने निष्ठापूर्वक एक undecided brief के सैकड़ों versions बना दिए, और team ने वही दो हफ़्ते उस संदेश पर बहस करने में बिताए जो वह tool के बिना भी बिताती। AI ने सस्ता stage हटा दिया और महँगा वाला अछूता छोड़ दिया।
जब team ने एक हफ़्ता brief को machine-readable बनाने में लगाया — एक चुना हुआ संदेश, brand rules, audience, metric — तो वही generator उपयोगी हो गया, क्योंकि अब generate करने के लिए एक direction थी। Tool में ज़रा भी बदलाव नहीं आया था। Route में आया था।
"Route redesign करना" का असल में क्या मतलब है
Route redesign करना कोई भव्य transformation programme नहीं है। यह चार specific कदम हैं, और आप उन्हें एक stage एक बार में कर सकते हैं।
- Generate करने से पहले brief तय करें। Direction को स्पष्ट और लिखित बनाएँ, ताकि पहले pass के पास amplify करने के लिए कुछ सच्चा हो।
- Review को हिलाएँ, सिर्फ़ output को नहीं। अगर model ज़्यादा produce करता है, review capacity का shape बदलना चाहिए — sampling, structured checks, एक साफ़ standard — वरना volume risk बन जाता है।
- Context को वहाँ रखें जहाँ workflow उस तक पहुँच सके। Brand rules, audience और history काम के साथ चलने चाहिए, किसी senior व्यक्ति के दिमाग़ में नहीं बैठने चाहिए।
- Copy-paste gaps बंद करें। जहाँ भी एक human manually tools के बीच output हिला रहा है, वह एक bottleneck है जो ख़ुद को किसी की नौकरी बता रहा है।
ये चार करें और parade चलती है। इन्हें छोड़ें और आपने एक तेज़ float ख़रीद ली है।
अपनी parade diagnose कैसे करें
किसी भी AI investment की सिफ़ारिश करने से पहले मैं एक जान-बूझकर सीधा test इस्तेमाल करता हूँ।
पूछें: कौन-सा stage सबसे आख़िर में ख़त्म होता है? यह नहीं कि कौन-सा stage शुरू होने में सबसे धीमा है — यह कि अंत में campaign किस stage का इंतज़ार कर रही है। वह stage आपका constraint है, और अगर आप cycle time हिलाना चाहते हैं तो AI को पहले वहीं जाना चाहिए।
फिर दूसरा सवाल पूछें: जब AI ख़त्म करता है, output के साथ एक human क्या करता है? अगर ईमानदार जवाब "सब पढ़ता है, चुनता है, reformat करता है, और downstream paste करता है" है, तो आपने अगला bottleneck पा लिया। पहला pass तेज़ होना बहुत कम क़ीमती है अगर दूसरा pass वही है जो हमेशा था।
आप एक stage से शुरू कर सकते हैं
अच्छी ख़बर यह है कि parade problem एक बड़ी शुरुआत के बजाय एक छोटी, ग़ैर-चमकदार शुरुआत का तर्क देता है।
Constraint चुनें — आमतौर पर reporting, research या brief — और सिर्फ़ उस stage को redesign करें ताकि machine पहला pass produce करे और एक human ऐसे review करे जैसे किसी junior का। उस stage का cycle time पहले और बाद में मापें। अगर वह हिला, तो आपके पास सबूत है कि approach काम करती है और अगले stage को छूने का कारण। अगर नहीं हिला, तो आपने अपनी operation के बारे में कुछ सस्ता सीखा।
यह वही sequencing तर्क है जो Strategy guide पूरी lane के लिए देता है, और इसीलिए templates हैं: एक machine-readable brief और एक review standard वे दो artefacts हैं जो एक तेज़ stage को एक तेज़ parade में बदलते हैं। एक stage ठीक से करना पाँच stages आधे-अधूरे करने से ज़्यादा सिखाता है।
FAQ
क्या parade problem सिर्फ़ change-management की problem है?
कुछ हद तक, लेकिन मुख्य रूप से नहीं। Change management adoption की है — लोग tool इस्तेमाल करते हैं या नहीं। Parade problem design की है — workflow tool का output absorb कर सकता है या नहीं। एक बिल्कुल adopt किया हुआ tool, अपरिवर्तित route पर चढ़ाया गया, फिर भी वही bottleneck produce करता है।
क्या इसका मतलब है कि पुराने workflows पर AI कभी काम नहीं करता?
वह किनारों पर मदद कर सकता है, और वह कुछ क़ीमती है। लेकिन gains उसके पीछे वाली constraint से capped हैं। अगर लक्ष्य material रूप से तेज़ campaign cycle है, तो route बदलना पड़ेगा; अगर लक्ष्य थोड़ा तेज़ individual कदम है, तो चढ़ाना ठीक है।
अपना constraint जल्दी कैसे खोजूँ?
पूछें कि अंत में campaign किस stage का इंतज़ार कर रही है, यह नहीं कि कौन-सा stage शुरू होने में सबसे धीमा है। जिस stage पर queue है वही constraint है। यह आमतौर पर कोई technical चीज़ नहीं बल्कि एक approval, एक data reconciliation या एक undecided brief होता है।
क्या मुझे सारे stages एक साथ redesign करने हैं?
नहीं — उल्टा। एक stage शुरू से आख़िर तक redesign करें, cycle time मापें, और तभी आगे बढ़ें। एक stage ठीक से करना अगले के लिए evidence देता है; पाँच आधे-अधूरे करना पाँच नए bottlenecks देता है।
Short version
Parade problem एक तेज़ पहले कदम और एक अपरिवर्तित bottleneck के बीच का gap है। पुराने workflow पर AI float को तेज़ करता है, parade को नहीं, क्योंकि constraint उसके पीछे बैठता है और शायद ही कभी वहाँ जहाँ demo होता है। Fix एक बेहतर model नहीं है। यह brief तय करना, review को हिलाना, context को वहाँ रखना जहाँ workflow उस तक पहुँच सके, और copy-paste gaps बंद करना है — एक stage एक बार में।
मैं अब भी यह field सबके सामने सीख रहा हूँ, और मैंने दोनों दिशाओं में ग़लती की है: मैंने tools पर ज़रूरत से ज़्यादा invest किया और route पर कम, और route हमेशा महँगा हिस्सा था। तो मैं वही सीधा सवाल पूछता रहूँगा — कौन-सा stage सबसे आख़िर में ख़त्म होता है?
अगर आपने किसी तेज़ float को अपनी parade हिलाने में fail होते देखा है, तो मैं सुनना चाहूँगा कि bottleneck आख़िर कहाँ निकला।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी और जापानी में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।