Marketing org में AI कैसे pilot करें: एक well-defined workflow चुनें, एक owner नाम लें, एक baseline record करें, और कुछ भी चलने से पहले decision rule तय करें। एक pilot एक showcase नहीं है; यह एक ऐसा test है जो एक फ़ैसला produce करने के लिए designed है। अगर आप पहले से नहीं बता सकते कि कौन-सा result आपको रोक देगा, तो आप pilot नहीं चला रहे, आप extra steps वाला एक demo चला रहे हैं।
ज़्यादातर AI programmes जो अटक जाते हैं वे ऐसा इसलिए करते हैं क्योंकि उन्होंने यह step छोड़ दिया। वे interest से rollout तक गए, या interest से एक ऐसे pilot तक जो असल में छिपा हुआ launch था। Pilot वह जगह है जहाँ एक organisation scale करने का हक़ कमाती है, और यह सिर्फ़ तब काम करता है जब इसे fail हो सकने के लिए designed किया जाए।
ज़्यादातर pilots क्यों fail होते हैं
आम failure एक ऐसा pilot है जो succeed करने के लिए बनाया गया। Workflow इसलिए चुना जाता है क्योंकि वह आसान है, scope बढ़ता जाता है जब तक वह सब कुछ छू न ले, और success बाद में "team को पसंद आया" की तरह define हो जाता है। किसी ने नहीं लिखा कि क्या failure गिना जाता, इसलिए कुछ भी failure नहीं हुआ। Pilot तालियों के साथ ख़त्म होता है और बिना किसी transferable नतीजे के।
दूसरा failure उल्टा है: एक pilot इतना hedged कि वह कुछ test ही नहीं करता। यह synthetic data इस्तेमाल करता है, एक ऐसे side project पर चलता है जिसकी किसी को परवाह नहीं, और ऐसे लोगों द्वारा review होता है जिनका नतीजे में कोई stake नहीं। यह fail नहीं हो सकता, और यह आपको कुछ नहीं सिखा सकता, जो इसे उस एक चीज़ की बर्बादी बनाता है जिसके लिए एक pilot होता है।
एक workflow चुनें
एक ऐसा workflow चुनें जो संकुचित, repetitive और measurable हो, एक साफ़ शुरुआत और अंत और एक ऐसी team के साथ जो पहले से दर्द महसूस करती हो। अच्छे candidates वे हैं जैसे first-draft creative production, reporting assembly, या campaign localization। बुरे candidates वे हैं जो दस दूसरी teams पर निर्भर हों, जिनका कोई baseline न हो, या जो असल में एक strategy का सवाल एक task की पोशाक में हों।
Test यह है कि क्या आप workflow को एक input, एक process और एक output की तरह describe कर सकते हैं। अगर हाँ, तो इसे pilot किया जा सकता है। अगर नहीं, तो इसे पहले design करना है, pilot नहीं। सबसे मुश्किल, सबसे ambiguous workflow से शुरू करना यह नतीजा निकालने का सबसे तेज़ तरीक़ा है कि AI काम नहीं करता, जब असली मुद्दा target था।
एक baseline record करें
बिना baseline का एक pilot कुछ साबित नहीं कर सकता, क्योंकि compare करने के लिए कुछ नहीं। AI workflow चलने से पहले, उन कुछ चीज़ों के मौजूदा numbers capture करें जो मायने रखती हैं: cycle time, senior review time, error या revision rate, और वह business outcome जिसे workflow feed करती है। यह वह discipline है जो AI marketing impact कैसे मापें में रखी गई है, और यह pilot से पहले होना चाहिए, बाद में नहीं।
Baseline perfect होने की ज़रूरत नहीं; उसे मौजूद होने की ज़रूरत है। पिछले हफ़्ते record किया एक मोटा number अगले quarter में memory से reconstruct किए एक precise number को हराता है। अगर आपके पास न baseline है और न बनाने का समय, तो पुरानी workflow दो और cycles चलाएँ और record करें। वह देरी एक ऐसे pilot से सस्ती है जिसका result कोई defend नहीं कर सकता।
शुरू करने से पहले rule तय करें
पहली run से पहले decision rule लिखें: कौन-सा result pilot को expand करता है, कौन-सा उसे change करता है, और कौन-सा उसे stop करता है। उदाहरण के लिए, expand करें अगर cycle time एक-पाँचवाँ गिरे बिना error rate बढ़े; change करें अगर speed सुधरे पर quality गिरे; stop करें अगर कोई न हिले। Specific numbers उन पर commit करने से कम मायने रखते हैं जब आप अब भी unbiased हों।
यह वह step है जिसे teams छोड़ती हैं क्योंकि यह bureaucratic लगता है। यह वह step है जो pilot को ईमानदार बनाता है। एक बार जब आप workflow चला चुके और एक result देख चुके, हर व्याख्या self-serving बन जाती है; अकेली defence एक ऐसा rule है जो तब लिखा गया जब आपको जवाब नहीं पता था।
Human को loop में रखें
जो pilot human को पूरी तरह हटा दे वह ग़लत चीज़ test करता है। जो आप सीखना चाहते हैं वह यह है कि क्या एक AI-assisted workflow senior समय की प्रति इकाई बेहतर output produce कर सकती है, और उसके लिए एक मापने लायक़ review step चाहिए। Track करें कि human कितनी बार output बदलता है और review में कितना समय लगता है, क्योंकि एक AI-native workflow की असली लागत review step में रहती है।
Pilot को operator के judgement के लिए जगह भी छोड़नी चाहिए। अगर workflow एक कठोर रास्ता मजबूर करती है, तो आप सीखेंगे कि वह रास्ता काम करता है या नहीं, यह नहीं कि team बेहतर tools के साथ ज़्यादा कर सकती है। Pilot को adapt होने की जगह दें, और adaptations record करें — वे उस operating model के बीज हैं जिसे आप scale करते हैं।
Pilot को एक page पर design करें
Pilot design इतना छोटा रखें कि सब उसे थाम सकें। नीचे की table वे न्यूनतम फ़ैसले हैं जो कुछ भी चलाने से पहले लेने हैं।
| फ़ैसला | क्या लिखें |
|---|---|
| Workflow | Test के तहत वह अकेला input-output काम |
| Owner | एक नामित व्यक्ति, एक committee नहीं |
| Scope | कौन अंदर, कौन बाहर, क्या बाहर रखा गया |
| Baseline | Cycle time, review time, error rate, outcome |
| Decision rule | वह result जो expand, change या stop करता है |
| Duration | Test के लिए एक तय अंत तारीख़ |
अगर आप यह table नहीं भर सकते, तो pilot तैयार नहीं है। इसे भरने में एक घंटा लगता है और एक quarter बचता है।
छोटा चलाएँ, फिर decide करें
Pilot को एक छोटी team के साथ असली काम पर चलाएँ, एक तय अवधि के लिए — चार से आठ हफ़्ते आमतौर पर यह देखने के लिए काफ़ी हैं कि workflow हिलती है या नहीं। Decision rule दिखने वाला रखें, numbers हर हफ़्ते review करें, और pilot के बीच scope बढ़ाने की इच्छा का विरोध करें। मक़सद एक साफ़ चीज़ सीखना है, सब कुछ एक साथ ठीक करना नहीं।
अंत में, वह फ़ैसला लें जो आपने लिखा था। अगर expand होता है, तो pilot एक rollout बन जाता है जिसके पीछे एक असली baseline है। अगर change होता है, तो अब आप जानते हैं कि कौन-सा हिस्सा fail हुआ, जो एक vague success से ज़्यादा क़ीमती है। अगर stop होता है, तो आपने organisation को एक साल बचाया और अगला pilot आज़माने की credibility कमाई — ईमानदार failure उपलब्ध सबसे सस्ता नतीजा है।
Governance pilot का हिस्सा है
एक छोटे pilot को भी एक data boundary और एक review step चाहिए, तो उन्हें पहली run से पहले तय करें, आधे रास्ते में खोजने के बजाय। यह policy और governance काम का हल्का सिरा है, और एक pilot यह test करने की अच्छी जगह है कि आपको असल में कौन-से controls चाहिए। जो controls यहाँ ज़रूरी साबित हों वे scale करने लायक़ हैं; जो बिना कुछ पकड़े friction जोड़ें उन्हें छोड़ा जा सकता है।
Pilot के result को transferable बनाना
जो pilot एक team को कुछ सिखाता है जिसे कोई और इस्तेमाल न कर सके वह आधा fail हुआ। शुरू से, जो सीखा उसे एक ऐसी shape में capture करें जो चले: workflow जैसा वह अंत में बना, वे prompts और templates जो चले, वे failure modes जो मिले, और वह फ़ैसला जो आपने लिया। Pilot के output को दो चीज़ें मानें — एक फ़ैसला और एक reusable kit।
वह kit ही एक pilot को rollout में बदलता है। अगली team शून्य से शुरू नहीं करती; वह एक चलते design से शुरू करती है और उसे अपने काम में ढालती है। Kit सिर्फ़ तब काम करता है जब अगली team उसे ढूँढ और पढ़ सके, इसीलिए एक memory layer उतनी ही मायने रखती है जितनी workflow ख़ुद — वह बात जो मैं बिना memory वाला AI सिर्फ़ एक महँगा chatbot है में कहता हूँ। यह भी वह जगह है जहाँ एक centre of excellence, अगर आपके पास हो, अपनी जगह कमाता है, kit और उन standards को रखकर जो उसे उपयोगी बनाते हैं। बिना transferable output का pilot एक ऐसा experiment है जिसे दोहराना पड़ता है, जो सबसे महँगा प्रकार है।
Pilot के लिए एक counter-metric
अकेली speed लगभग हर pilot को चापलूसी देगी, तो इसे एक counter-metric से जोड़ें जो छिपी लागत पकड़े। Track करें कि human कितनी बार output बदलता है, review में कितना समय लगता है, और error या rework rate हिलती है या नहीं। जो workflow drafting समय आधा करती है जबकि review समय दोगुना, उसने कुछ नहीं बचाया; उसने काम एक महँगे व्यक्ति पर हिला दिया। ईमानदार measure senior समय की प्रति इकाई output है, quality बनी हुई, और इसे देखने का अकेला तरीक़ा review step को production step जितने ध्यान से record करना है। अगर pilot headline number सुधारता है और counter-metric बिगाड़ता है, तो आपने वह असली सवाल पा लिया जिसका जवाब rollout को देना है।
FAQ
एक pilot कितने समय चलना चाहिए?
एक संकुचित workflow पर चार से आठ हफ़्ते आमतौर पर यह देखने के लिए काफ़ी हैं कि cycle time और quality हिलती हैं। कम तो numbers शोर हैं; ज़्यादा तो आप decide किए बिना एक rollout चला रहे हैं। अंत तारीख़ शुरुआत में चुनें।
अगर हमारे पास baseline न हो?
मौजूदा workflow दो और cycles चलाएँ और शुरू करने से पहले numbers record करें। यह देरी लगता है, लेकिन बिना baseline का pilot एक ऐसा result produce करता है जिसे आप defend नहीं कर सकते, जो दो हफ़्ते इंतज़ार करने से बुरा है।
Pilot में कौन होना चाहिए?
एक छोटी team जो पहले से काम करती है और दर्द महसूस करती है, साथ वह owner जो फ़ैसला लेगा। Leaders को शामिल होने के बजाय सूचित रखें; उनकी उपस्थिति व्यवहार बदलती है और result धुँधला करती है। Pilot को असली काम दिखाना चाहिए, management के लिए एक performance नहीं।
सबसे अच्छा पहला workflow क्या है?
सबसे repetitive, well-defined, दर्दभरा वाला। Reporting assembly, first-draft production, और localization आम अच्छी शुरुआतें हैं। किसी ऐसी चीज़ से बचें जिसे दस teams के alignment की ज़रूरत हो, क्योंकि आप pilot सीखने के बजाय coordination पर बिताएँगे।
Short version
एक workflow को एक नामित owner, एक baseline, और पहले से तय एक decision rule के साथ test करके AI pilot करें। इसे असली काम पर छोटा चलाएँ, human को loop में रखें, और वह फ़ैसला लें जो आपने लिखा था। Execution guide दिखाता है कि pilot व्यापक workflow में कहाँ फिट होता है, और for-team-leads track pilot और उस operating model से गुज़ारती है जिसमें वह जाता है।
अगर आपने एक चलाया है, तो मैं सुनना चाहूँगा कि आपका decision rule क्या था — और क्या आपने वाक़ई उसे follow किया।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी, जापानी, सरलीकृत चीनी और कोरियाई में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।