बदले हुए decisions और cycle time मापें, output volume नहीं। Output volume एक vanity metric है जिस पल model production को सस्ता बनाता है: एक team अपने asset count को तीन गुना कर सकती है और कुछ नहीं सीखती, या वही संख्या की assets भेज सकती है और बहुत कुछ सीखती है। जो signals असल में बताते हैं कि AI काम कर रहा है वे हैं एक फ़ैसला कितनी तेज़ी से चलता है, उसे कितना review चाहिए, AI-assisted version पुराने से कितनी बार बेहतर होता है, और उसके बाद कौन-सा business outcome आया।
मैंने teams को content output में एक छलांग को इस सबूत की तरह मनाते देखा है कि उनका AI programme काम कर रहा था, जबकि output उस बदलाव का सबसे कम दिलचस्प हिस्सा था। Measurement वह जगह है जहाँ एक AI programme या तो ईमानदार हो जाता है या खो जाता है, इसलिए कुछ भी scale करने से पहले इसे सही करना worth है।
Trap: वह मापना जो आसान हो गया
Default instinct throughput मापना है। हमने कितनी assets produce कीं, कितने markets launch किए, कितनी reports भेजीं। ये numbers AI के तहत बढ़ते हैं, और एक deck में संतोषजनक लगते हैं, लेकिन वे उस चीज़ को मापते हैं जिसे AI ने सस्ता बनाया, न कि उस चीज़ को जिसे आप सुधारना चाहते हैं।
Throughput ऐसी वजहों से बढ़ सकता है जिनका value से कोई लेना-देना नहीं। ज़्यादा variants का मतलब ज़्यादा शोर हो सकता है अगर कुछ भी test न हो। ज़्यादा reports का मतलब ऐसी meetings हो सकती हैं जिनकी किसी को ज़रूरत नहीं। ज़्यादा markets का मतलब ऐसी जगहें हो सकती हैं जहाँ आप औसत हैं। एक अच्छा measurement frame जिस सवाल का जवाब देता है वह "क्या हमने ज़्यादा produce किया?" नहीं है बल्कि "क्या ज़्यादा production बेहतर decisions और बेहतर outcomes में बदली?" ये अलग सवाल हैं, और सिर्फ़ दूसरा मायने रखता है।
इसके बजाय क्या मापें
Operating model मापें, production line नहीं। चार signal families ज़्यादातर हिस्सा cover करती हैं। Speed: brief से live तक cycle time, और एक फ़ैसले तक का समय। Effort: प्रति output senior review समय, जो एक AI-native workflow की असली लागत है। Quality: error rate, revision rate, और कितनी बार AI-assisted काम को rework चाहिए। और Outcome: प्रति result लागत, और वह business metric जिसे काम हिलाना था।
इनमें से कोई भी विदेशी नहीं, और कोई भी नई tooling नहीं माँगता। जो उन्हें पुराने metrics से अलग बनाता है वह यह है कि वे volume के बजाय judgment और flow मापते हैं। जो team cycle time काटती है, error rate स्थिर रखती है, और review समय सही रखती है, उसने सचमुच अपना operating model सुधारा है, भले asset count न बदले।
Leading और lagging signals
Signals को timing से बाँटें। Lagging signal business outcome है — revenue, pipeline, brand lift, campaign जिस चीज़ के लिए थी — और यह वही है जो मायने रखता है, लेकिन देर से आता है और कई चीज़ों से प्रभावित होता है। Leading signals operational हैं: cycle time, review time, revision rate, प्रति हफ़्ते decisions। वे पहले हिलते हैं और आपके control में हैं।
आपको दोनों चाहिए, और attribution पर ईमानदार होना चाहिए। जब market हिला तो lagging number को AI के लिए लेने का लालच होता है। ईमानदार frame यह है कि operational बदलाव साबित करने के लिए leading signals इस्तेमाल करें, और business असर का तर्क देने के लिए lagging signal को उचित attribution के साथ — incrementality, holdouts, एक test design — इस्तेमाल करें। Reporting discipline वही है जो दोनों को मिलने से रोकती है।
Quality counter-metric
हर speed metric को एक quality counter-metric चाहिए, वरना team बुरा काम भेजकर speed optimise करेगी। अगर cycle time headline है, तो error rate और revision rate guardrails हैं। अगर review time efficiency की कहानी है, तो counter यह है कि escaped defects — वे problems जो client या customer ने पाए — बढ़े या घटे।
यह AI काम के measurement में सबसे ज़रूरी discipline है, क्योंकि AI speed को आसान और quality को मुश्किल बनाता है। जो team quality counter-metric के बिना तेज़ cycles report करती है वह अपना operating model नहीं माप रही; वह काम को दरवाज़े से बाहर धकेलने की अपनी क्षमता माप रही है, जो ठीक वही व्यवहार है जो review debt पैदा करता है।
एक सरल measurement frame
एक primary operating metric चुनें — मैं उस workflow पर cycle time से शुरू करूँगा जिसे आपने redesign किया — और दो counter-metrics, error rate और review time। एक business outcome जोड़ें जिसे workflow प्रभावित करनी है, एक ऐसे design से मापा गया जो उसे ईमानदारी से attribute कर सके। चारों को साथ report करें, हर महीने, और primary में किसी भी ऐसे हिलाव को एक failed improvement मानें जिसके साथ कोई counter-metric बदतर आए।
वह frame जान-बूझकर पतला है, क्योंकि पतले frames इस्तेमाल होते हैं। बीस metrics वाला एक dashboard अनदेखा हो जाता है। चार numbers जो speed-versus-quality trade-off को सतह पर मजबूर करें, operating model चलाने के लिए काफ़ी हैं, और वे expansion का तर्क enthusiasm के बजाय evidence से बनाते हैं।
Expansion से पहले instrumentation
Measurement का सबसे मुश्किल हिस्सा numbers को उनकी ज़रूरत से पहले रखना है। ज़्यादातर teams पहले एक AI workflow बढ़ाती हैं और बाद में उसका असर reconstruct करने की कोशिश करती हैं, जिससे एक credible programme एक ऐसे दावे पर पहुँचता है जिसे साबित नहीं किया जा सकता। Discipline यह है कि workflow को उसी पल instrument करें जब आप उसे बनाते हैं: cycle time log करें, review step record करें, और error rate शुरू से capture करें।
यह overhead जैसा लगता है, और शुरू में है। लेकिन विकल्प है एक साल बाद बिना baseline और बिना यह जानने के तरीक़े के कि workflow बेहतर हुई या बस बदली। एक सरल log — जब एक brief आया, जब वह live गया, कितने review passes, क्या ग़लत था — काफ़ी है। शुरू करने के लिए platform नहीं चाहिए; उन चार numbers को record करने की आदत चाहिए, उस चीज़ को scale करने से पहले जो उन्हें produce करती है।
एक काम का उदाहरण
एक paid social creative loop की तस्वीर लें। पुराना cycle time दिनों में मापा जाता था: brief, design, review, revisions, launch। model-first workflow पर जाने के बाद, आप उम्मीद करते हैं कि वह गिरे। लेकिन अगर review time दोगुना हो गया और revisions नहीं, तो आपने operating model सुधारा नहीं; आपने bottleneck हिला दिया।
ईमानदार पढ़ना चारों numbers को साथ देखने से आता है। Cycle time नीचे, review time स्थिर या थोड़ा ऊपर, error rate स्थिर, और test-readout quality ऊपर — यह एक असली सुधार है। Cycle time नीचे, review time तेज़ी से ऊपर, और revisions ऊपर — यह एक ऐसी team है जो तेज़ और बुरा भेज रही है, और counter-metrics ने इसे पकड़ लिया। उनके बिना, अकेला cycle-time chart एक जीत जैसा दिखता।
आम measurement ग़लतियाँ
तीन ग़लतियाँ बार-बार आती हैं। Volume मापना और उसे impact कहना, जो programme को चापलूसी देता है और कुछ नहीं सिखाता। Quality counter-metric छोड़ देना, जो speed को काम में गिरावट छिपाने देता है। और बिना उस design के एक market movement को AI को attribute करना जो दावे को support करे, जो तब तक काम करता है जब तक कोई पूछे कि आपको कैसे पता।
तीनों का इलाज एक ही discipline है: operating metric चुनें, counter-metric जुड़ी रखें, और स्पष्ट रहें कि आप क्या attribute कर सकते हैं और क्या नहीं। एक मामूली, defensible दावा एक बड़े, unfalsifiable दावे को हराता है, क्योंकि defensible दावा अगले quarter तक बचता है और बड़ा नहीं।
सोमवार को क्या करें
जिस workflow को आपने AI पर ले जाया उसे लें और पिछले महीने का उसका cycle time, review time और error rate लिखें। अगर नहीं लिख सकते, तो वही पहली खोज है: आप एक AI-native workflow चला रहे हैं बिना यह बताने की instrumentation के कि वह बेहतर है। फिर एक business outcome चुनें और तय करें कि आप उसमें एक बदलाव को credible तरीक़े से कैसे attribute करेंगे। यह अगले campaign से पहले करें, ताकि measurement design से मौजूद हो, reconstruction की तरह नहीं।
FAQ
क्या हमें बचे हुए घंटे गिनने चाहिए?
बचे हुए घंटे एक उपयोगी internal signal हैं लेकिन एक ख़तरनाक external, क्योंकि यह इस पर निर्भर हैं कि लोगों ने उस समय क्या किया। Cycle time और review time गिनें, जो observable हैं, और घंटों को उनसे निकलने दें, उनसे lead करने के बजाय।
हम कैसे साबित करें कि AI ने outcome पैदा किया?
काम से पहले बने एक design से: एक holdout, एक matched control, या एक test जहाँ एक condition AI-assisted है और एक नहीं। उसके बिना, आप correlation और सुधार दिखा सकते हैं, लेकिन causation का दावा नहीं कर सकते। Design पहले बनाएँ या कमज़ोर दावा स्वीकार करें।
अगर business outcome ग़ैर-संबंधित कारणों से हिले?
वह कहें। Operating metrics का इस्तेमाल workflow बदलाव साबित करने के लिए करें और स्पष्ट रहें कि business movement market के साथ साझा है। ज़रूरत से ज़्यादा दावा करना वह तरीक़ा है जिससे एक AI programme credibility खोता है जब अगला quarter स्थिर होता है।
इन metrics को कितनी बार review करें?
एक स्थिर workflow के लिए महीना काफ़ी है, और हफ़्ता जब आप उसे सक्रिय रूप से tune कर रहे हों। बात बातचीत की cadence की है, dashboard की नहीं। चार numbers के साथ एक नियमित मासिक review पूरा system है।
Short version
बदले हुए decisions और cycle time मापें, output volume नहीं। Speed, effort, quality और outcome signals इस्तेमाल करें, हर speed metric को एक quality counter-metric से जोड़ें, और business outcomes को ईमानदारी से attribute करें। Execution guide lane का बाक़ी हिस्सा cover करता है, और for-team-leads track measurement को operating model के ज़रिए चलाती है।
अगर आप अपने AI programme को माप रहे हैं, तो मैं सुनना चाहूँगा कि कौन-सा number defend करना सबसे मुश्किल लगा — आमतौर पर वही ईमानदार होता है।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी और जापानी में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।