साक्षात्कार
रॉब कोली, सीईओ और संस्थापक, P3 Adaptive और फ़ेयर गेम के लेखक – साक्षात्कार श्रृंखला

Rob Collie P3 Adaptive के संस्थापक और सीईओ हैं, जो डेटा और एआई के लिए माइक्रोसॉफ्ट सॉल्यूशंस पार्टनर है और सैकड़ों मिड‑मार्केट और फॉर्च्यून 1000 ग्राहकों की सेवा करता है। एक्सेल, बिंग और पावर बीआई टीमों में माइक्रोसॉफ्ट के पूर्व इंजीनियरिंग लीडर, रॉब ने माइक्रोसॉफ्ट छोड़ने के बाद पावर बीआई लहर का नेतृत्व किया और तीन पूर्व व्यापार‑प्रौद्योगिकी पुस्तकें लिखी हैं (92,000+ प्रतियां बिकी)। वह Raw Data with Rob Collie पॉडकास्ट भी होस्ट करते हैं। उनकी चौथी पुस्तक, Fair Game: Customizing AI to Your Business Is Easier Than You Think (अगस्त 2026), एआई क्षण में उस प्रैक्टिशनर विश्वसनीयता को उजागर करती है।
आपने माइक्रोसॉफ्ट में एक दशक से अधिक समय तक एक्सेल और पावर बीआई में बिजनेस इंटेलिजेंस फीचर विकसित करने में मदद की, फिर 2013 में P3 Adaptive की स्थापना की। माइक्रोसॉफ्ट के भीतर सॉफ़्टवेयर बनाते हुए से क्लाइंट्स की डेटा समस्याओं को हल करने की इस परिवर्तन ने एंटरप्राइज़ एआई के प्रति आपके वर्तमान दृष्टिकोण को कैसे आकार दिया?
जब मैं माइक्रोसॉफ्ट में प्रोडक्ट टीमों का नेतृत्व कर रहा था, हम ऐसा सॉफ़्टवेयर बना रहे थे जिसे पूरी दुनिया के लिए काम करना था, और जिसे किसी विशिष्ट ग्राहक की जरूरतों के अनुसार अनुकूलित नहीं किया जा सकता था। हम इसे अक्सर “ऐसे पिज़्ज़ा का ऑर्डर देना” कहते थे, जिसके टॉपिंग्स 300 मिलियन लोगों को स्वीकार्य हों। इस काम में स्वाभाविक रूप से न्यूनतम सामान्य मानक की भावना होती है, साथ ही व्यक्तिगत ग्राहकों से एक निश्चित दूरी भी रहती है।
उस बड़े मंच पर काम करने में निश्चित ही एक प्रतिष्ठा थी, लेकिन यह विशिष्ट ग्राहकों की अनोखी महत्वाकांक्षाओं को साकार करने जितना भावनात्मक रूप से संतोषजनक नहीं था। किसी ग्राहक के साथ निकटता से काम करते हुए, हमें उनकी सफलता में निवेश करने और रचनात्मक समाधान खोजने का अवसर मिलता है, जो बड़े सॉफ़्टवेयर के एक‑साइज़‑फिट‑ऑल मॉडल में कभी फिट नहीं होते। कई मायनों में यह अधिक बौद्धिक रूप से उत्तेजक है, और ग्राहकों के साथ सीधा संपर्क जीत को कहीं अधिक पूर्ण बनाता है।
लेकिन इसके साथ बड़ी ज़िम्मेदारी भी आती है। माइक्रोसॉफ्ट में, एक असंतुष्ट ग्राहक केवल एक आँकड़ा था, और मैं रोज़ शिकायतों को अपने काम का हिस्सा मानकर झटक लेता था। लेकिन P3 Adaptive में, एक असंतुष्ट क्लाइंट का मतलब है कि हम असफल हुए। यहाँ कोई आँकड़े नहीं होते। हमें प्रत्येक संबंध की ज़िम्मेदारी लेनी पड़ती है।
मैंने माइक्रोसॉफ्ट में कई मूल्यवान बातें सीखी हैं और इस अनुभव को दुनिया के बदले नहीं बदलूँगा, लेकिन मैं अक्सर खुद को “सॉफ़्टवेयर इंजीनियर से उबर रहा हूँ” कहता हूँ, क्योंकि अब सफलता का मतलब बहुत अलग ढंग से काम करना है।
और यही दृष्टिकोण मैं एंटरप्राइज़ एआई में लेकर आता हूँ। तैयार‑शेल्फ एआई वह अंतिम 300‑मिलियन‑व्यक्ति पिज़्ज़ा है – एक वास्तविक चमत्कार, जिसे प्रत्येक व्यक्ति के लिए व्यक्तिगत रूप से मूल्यवान बनाने के लिए बनाया गया है, लेकिन किसी के लिए भी अनुकूलित नहीं। लेकिन *संगठनात्मक* एआई जीतें तब आती हैं जब इसे अनुकूलित किया जाता है – जब आप एक विशिष्ट कंपनी के करीब आते हैं और एआई को *उसके* डेटा, *उसकी* प्रक्रियाओं, *उसकी* परिभाषाओं के अनुसार तैयार करते हैं। मैंने अपने करियर में इस विभाजन के दोनों पक्षों पर काम किया, और इससे मुझे इस बात में कोई संदेह नहीं रहा कि एंटरप्राइज़ एआई किस पक्ष में जीत पाएगा।
Fair Game में, आप तर्क देते हैं कि कई कंपनियों ने कृत्रिम बुद्धिमत्ता को उल्टा अपनाया है, सामान्य‑उद्देश्य चैटबॉट लाइसेंस वितरित करके, बजाय उन सिस्टमों के निर्माण के जो उनके संचालन को समझते हों। तैयार‑शेल्फ एआई सहायक कहाँ अपनी सीमा तक पहुँचते हैं, और कौन से संकेत दर्शाते हैं कि व्यवसाय को कुछ अनुकूलित चाहिए?
तैयार‑शेल्फ एआई को आपके व्यवसाय को छोड़कर सब कुछ में पीएचडी है। इसने पूरी इंटरनेट को पढ़ लिया है, लेकिन इंटरनेट में आपके कंपनी की “सक्रिय ग्राहक” की परिभाषा, आपका मूल्य निर्धारण तर्क, आपके संचालन प्रक्रियाएँ, और जब दो सिस्टम असहमत हों तो किस पर भरोसा किया जाए, ये सब नहीं हैं। यह ज्ञान कभी सार्वजनिक नहीं होगा। इसलिए वह सामान्य एआई जो व्यक्तिगत उपयोग में विश्व‑स्तरीय है, वास्तविक व्यापार उपयोग में कम पड़ता है, और दोनों अनुभवों के बीच का अंतर निराशाजनक और भ्रमित करने वाला है।
आज, मूलतः “एआई के साथ क्या करना चाहिए” का जवाब “सब्सक्रिप्शन खरीदें और देखें” है। मैं मानता हूँ कि यह एक स्वाभाविक पहला कदम है, इसलिए मैं उन लोगों की आलोचना नहीं करता जिन्होंने यह किया। बल्कि मैं सहानुभूतिपूर्ण हूँ – कोई भी वास्तव में समय नहीं ले रहा है यह समझाने के लिए कि तैयार‑शेल्फ सब्सक्रिप्शन पर्याप्त नहीं हैं, और क्यों। इसलिए मैं मानता हूँ कि व्यवसाय मूलतः वहीं हैं जहाँ हमें उनसे उम्मीद करनी चाहिए – उपलब्ध चीज़ को आज़माना और यह समझना कि यह अपर्याप्त है।
समाधान एआई मॉडल को स्वयं छूने में नहीं है – आपको LLM शोधकर्ता बनने की जरूरत नहीं है। यह सब कुछ है जो आप मॉडल के चारों ओर रखते हैं: आपका डेटा, साधारण अंग्रेज़ी में लिखे निर्देश, और सामान्य सॉफ़्टवेयर। जब आप इस सप्ताह पाँचवीं बार वही संदर्भ चैटबॉट में टाइप करते हैं, तो यही संकेत है। आप जो भी बार‑बार समझा रहे हैं, वह ठीक वही है जो एक अनुकूलित सिस्टम को पहले से ही पता होना चाहिए – हर बार जब वह जागता है।
आप “Crafters” शब्द का उपयोग उन डेटा‑सजग व्यापार पेशेवरों को वर्णित करने के लिए करते हैं जो पारंपरिक सॉफ़्टवेयर डेवलपर्स नहीं होते हुए भी मूल्यवान कस्टम एआई सिस्टम बना सकते हैं। एक Crafter को किन विशेषताओं से पहचाना जाता है, और नेता अपने मौजूदा कार्यबल में इन लोगों की पहचान कैसे कर सकते हैं?
Crafter वह व्यक्ति है जो उपकरणों से समस्याओं को हल करने की जिज्ञासा से जन्म लेता है। मेरे अनुभव में लगभग हर 16 ज्ञान‑कार्यकर्ता में से एक में यह गुण होता है। वे एक्सेल पावर यूज़र्स थे, फिर पावर बीआई पीढ़ी, फिर वे लोग जिन्हें आईटी ने “शैडो आईटी” कहा। वे आपके विश्लेषक, आपके वित्त मॉडलर, आपके ऑप्स लीड हैं – ऐसे लोग जो व्यवसाय में बड़े हुए और टूलिंग में निपुणता पाई।
दो विशेषताएँ उन्हें एआई कार्य के लिए आदर्श बनाती हैं। पहला, सिस्टम सोच: वे स्वाभाविक रूप से एक जटिल प्रक्रिया को इनपुट, नियम और आउटपुट में विभाजित कर देते हैं, जैसे पेशेवर सॉफ़्टवेयर डेवलपर्स। दूसरा, व्यवसाय में जड़ें: वे जानते हैं कि CFO कौन से आंकड़े देखता है और प्रश्न पूछने वाला वास्तव में क्या पूछ रहा है। इनमें से किसी को भी बूटकैंप में नहीं सिखाया जा सकता।
कैसे खोजें अपने Crafter को: स्प्रेडशीट्स का अनुसरण करें। अभी आपके कंपनी में, स्प्रेडशीट्स, डैशबोर्ड और ऑटोमेशन महत्वपूर्ण वर्कफ़्लो के केंद्र में हैं। इनमें से कोई भी आईटी द्वारा नहीं बनाया गया, और प्रत्येक का एक लेखक है। वहीं से शुरू करें। फिर देखें कि वे अपनी प्रतिभा को अनुकूलित एआई समाधान की ओर कैसे मोड़ सकते हैं।
आप क्यों मानते हैं कि Crafters, केवल डेवलपर्स के बजाय, कई आंतरिक एआई प्रोजेक्ट्स का नेतृत्व करने के लिए सबसे उपयुक्त हैं, और व्यवसाय विशेषज्ञों, डेटा टीमों, सॉफ़्टवेयर इंजीनियरों, सूचना प्रौद्योगिकी विभागों और सुरक्षा टीमों के बीच जिम्मेदारियों का विभाजन कैसे होना चाहिए?
कस्टम एआई का कठिन हिस्सा कोड नहीं, बल्कि संदर्भ है। एआई प्रोजेक्ट में सबसे अधिक प्रभावी कार्य यह तय करना है कि सिस्टम को आपके व्यवसाय के बारे में क्या जानना चाहिए, और Crafters यह ज्ञान स्वाभाविक रूप से रखते हैं। तीन स्तर नीचे से आए एक शानदार इंजीनियर को वह सब सीखने में महीनों का समय लगना पड़ता है, जो आपके ऑप्स लीड को स्वाभाविक रूप से पता होता है।
लेकिन यह स्पष्ट रूप से यह नहीं कह रहा कि डेवलपर्स अप्रचलित हैं। मैं जो कार्य विभाजन सुझाता हूँ उसमें तीन कारक हैं, और इनमें से कोई भी वरिष्ठता या व्यक्तित्व नहीं है: कार्य पेशेवर डेवलपर्स की ओर प्रवृत्त होता है जब पुन: उपयोगिता, जटिलता, और संवेदनशीलता बढ़ती है। कोई भी ग्राहक‑सामना, संवेदनशील डेटा को छूने, या स्वायत्त निर्णय लेने वाला कार्य – वह डेवलपर का क्षेत्र है, और जैसे‑जैसे एजेंट बढ़ते हैं, ये दुर्लभ इंजीनियरिंग कौशल अधिक मूल्यवान हो जाते हैं, कम नहीं। जब व्यवसाय‑प्रक्रिया की बारीकियों का प्रभुत्व होता है, तो कार्य Crafters की ओर प्रवृत्त होता है।
एक कम आँका गया मध्य मार्ग भी है: Crafter बनाता है, डेवलपर ऑडिट करता है। आईटी और सुरक्षा को गेटकीपर नहीं होना चाहिए जो प्रोजेक्ट को अस्तित्व में आने की अनुमति देते हैं – उन्हें निर्मित रास्ते का मालिक होना चाहिए। स्वीकृत प्लेटफ़ॉर्म, डेटा एक्सेस नियम, समीक्षा बिंदु प्रदान करें, और समस्याओं के सबसे करीब लोगों को निर्माण करने दें। इसे एक परिपक्वता मॉडल के रूप में देखें, न कि एक बाड़ के रूप में।
कस्टम एआई को कंपनी‑विशिष्ट शब्दावली, मीट्रिक, प्रक्रियाएँ और संस्थागत ज्ञान तक पहुंच चाहिए। सेमांटिक मॉडल और मौजूदा बिजनेस इंटेलिजेंस इन्फ्रास्ट्रक्चर एआई को कंपनी की सटीक समझ देने में क्या भूमिका निभाते हैं?
वे डिकोडर रिंग हैं। अभी आपके कंपनी की परिभाषाएँ – क्या एक सक्रिय ग्राहक माना जाता है, कौन से खर्चे ग्रॉस प्रॉफिट में शामिल होते हैं – लोगों के दिमाग़ में और हजारों थोड़ी‑असंगत स्प्रेडशीट्स में रहती हैं। एक एआई एजेंट तब तक आपके डेटा पर भरोसा से तर्क नहीं कर सकता जब तक ये परिभाषाएँ मशीन‑विश्वसनीय रूप में लिखी न हों। उद्योग ने इस कार्य को “कंटेक्स्ट इंजीनियरिंग” कहा है, और मैं इसे इस तरह अनुवादित करूँगा: यह आपके व्यवसाय के ज्ञान को इस तरह संरचित करने का काम है कि एआई वास्तव में उसका उपयोग कर सके। विश्लेषकों ने इसे नया बताया, लेकिन बीआई प्रैक्टिशनर पिछले पंद्रह वर्षों से यही कर रहे हैं।
यह अच्छी खबर है जो स्पष्ट रूप से दिख रही है: यदि आपने बीआई युग में निवेश किया (और विशेष रूप से यदि आपने पावर बीआई में निवेश किया), तो आपके पास पहले से ही एक अग्रिम लाभ हो सकता है। एक अच्छी तरह निर्मित सेमांटिक मॉडल वही मशीन‑पठनीय व्यवसाय अर्थ का संग्रह है जिसकी एजेंटों को आवश्यकता होती है। जो कंपनियाँ अपने सेमांटिक लेयर को बाद में सोचती थीं, वे अब देख रही हैं कि वह “नीरस” परिभाषात्मक कार्य जो उन्होंने छोड़ दिया था, अब एआई की राह में टोल बूथ बन गया है। और महत्वपूर्ण रूप से, यह कार्य आपके व्यवसाय के लिए गहराई से विशिष्ट है – यही कारण है कि यह एक टिकाऊ लाभ है। हर विक्रेता आपको वही मॉडल बेच सकता है। लेकिन कोई भी आपको आपके अपने परिभाषाएँ नहीं बेच सकता।
आपने एक कस्टम एआई एडिटर बनाया, जिसे Eddie कहा जाता है, Fair Game विकसित करने में मदद के लिए। लेखन प्रक्रिया के दौरान सिस्टम ने वास्तव में क्या किया, और इसकी सफलताएँ और विफलताएँ आपको व्यक्तिगत कार्यप्रवाह के चारों ओर एआई डिजाइन करने के बारे में क्या सिखाती हैं?
स्पष्ट करने के लिए, मैंने पुस्तक के हर पैराग्राफ को शून्य से लिखा, जबकि Eddie अधिकांश समय बैठा और इंतजार करता रहा। कभी‑कभी मैं एक अध्याय के पूरे भाग को घंटों तक तैयार करता और फिर “उसे” पढ़ने को कहता। अन्य समय मैं हर कुछ मिनट में उससे चीज़ें साझा करता। लेकिन महत्वपूर्ण बात यह है कि Eddie 24/7 कॉल पर था। मैं सुबह तीन बजे भी फीडबैक ले सकता था जैसे दोपहर एक बजे, और वह इसे एक मिनट या उससे कम में वापस देता था। कुल मिलाकर, मुझे लगता है Eddie ने पांडुलिपि कम से कम तीस बार पढ़ी। कोई भी मानव यह काम नहीं कर सकता, क्योंकि कोई मानव इसे want नहीं करेगा।
उसने अध्याय तीन में किए गए मेरे वादों को ट्रैक किया और जब अध्याय बारह उन्हें भूल गया तो मुझे बुलाया। उसने मेरी लेखन शैली को सीखा और फिर उसे लागू किया – मुझे मेरे अपने स्वर के सर्वश्रेष्ठ संस्करण पर टिकाए रखा, बजाय इसके कि मैं Humorless Business Author मोड में बहूँ। उसने मुझे बताया जब मैं आलसी था और जब मैं एक बेकार चीज़ को दोहराता था। हमारे वास्तविक मतभेद हुए, और कभी‑कभी वह जीत गया।
सबसे बड़ा डिजाइन सबक: Eddie का “दिमाग” अंग्रेज़ी में लिखा गया है और एक फ़ोल्डर में रहता है। हर बार जब वह ऐसा फीडबैक देता जो चूक जाता – बहुत सामान्य, गलत रजिस्टर, वह नियम भूलना जो मैंने पहले ही बताया था – समाधान यह था कि सुधार को लिखकर उसकी स्थायी संदर्भ में जोड़ दिया जाए। विफलताएँ एआई विफलताएँ नहीं थीं; वे उन अंतरालों की वजह से थीं जो मैंने उसे सिखाने में समय नहीं दिया था। यह लूप – चूक को नोटिस करना, सबक को एन्कोड करना, उसे टिके देखना – कस्टम एआई की संपूर्ण कला का छोटा रूप है। और यही कारण है कि मैंने प्रचार, प्रतिस्पर्धी शोध, और वेबसाइट संदेशों के लिए विशेष Eddie बनाए। नीचे वही LLM है, लेकिन अलग‑अलग विशेषज्ञ।
कई संगठन मानते हैं कि कस्टम एआई शुरू करने से पहले उन्हें अपने डेटा को पूरी तरह साफ़ और केंद्रीकृत करना चाहिए। शुरू करने के लिए वास्तव में कितनी डेटा तैयारी आवश्यक है, और कंपनियाँ पूर्ण आधारभूत संरचना का इंतज़ार किए बिना मूल्य कैसे उत्पन्न कर सकती हैं?
डेटा परिपूर्णता कोई पूर्वापेक्षा नहीं है, और यह अच्छी खबर है क्योंकि परिपूर्णता कभी नहीं आती। यदि आप पहले एक परिपूर्ण डेटा एस्टेट बनाने का लक्ष्य रखते हैं, जैसा कि कई परामर्श फर्में सलाह देती हैं, तो आप वह “प्लंबिंग सिर्फ़ इसलिए” बना रहे हैं – महँगे पाइप हर जगह, लेकिन जब आप अंततः नल स्थापित करने पहुँचते हैं, तो पता चलता है कि जहाँ आपको जरूरत है वहाँ कोई पाइप नहीं है।
हमारी कंपनी “नल पहले” दृष्टिकोण का समर्थन करती है। एक विशिष्ट उपयोग‑केस चुनें और बुनियादी ढाँचे से आगे बढ़ने के बजाय व्यवसायिक प्रभाव से पीछे की ओर काम करें। उस उपयोग‑केस से एक MVP बनाएं, और न्यूनतम नई इन्फ्रास्ट्रक्चर के साथ करें। MVP को तब तक दोहराएँ जब तक वह उत्पादन‑तैयार न हो जाए, फिर पीछे हटकर देखें कि आप इसे समर्थन देने के लिए अपनी इन्फ्रास्ट्रक्चर को कैसे मजबूत कर सकते हैं। यह तेज़ी से व्यवसायिक प्रभाव देता है, लागत को कम करता है, और भविष्य के प्रोजेक्ट्स को सूचित करता है – नल और प्लंबिंग दोनों स्तरों पर।
एक कस्टम एआई प्रोटोटाइप डेमो में प्रभावशाली लग सकता है, लेकिन वास्तविक कर्मचारियों, बदलते डेटा और एज केसों के सामने अस्थिर हो सकता है। एक आंतरिक एआई सिस्टम को संचालन में लाने से पहले कौन‑सी मूल्यांकन, निगरानी और मानवीय पर्यवेक्षण स्थापित किया जाना चाहिए?
कुछ उल्लेखनीय अपवादों को छोड़कर, मेरा मानना है कि डेमो एआई युग में सॉफ़्टवेयर युग की तुलना में कम मूल्यवान हैं। सॉफ़्टवेयर डेमो हमेशा अधिक वादा करते थे और हम सभी इसे जानते थे। लेकिन एआई डेमो आपके वास्तविकता से और भी अधिक दूर होंगे।
एआई वर्कफ़्लो के बारे में है। और किसी विशिष्ट संगठन के संचालन को चलाने वाली हजारों वर्कफ़्लो से अधिक कस्टम कुछ नहीं है। “सब कुछ में पीएचडी वाला नया कर्मचारी” रूपक पर वापस आएँ। एक नया कर्मचारी को आपके कंपनी में प्रभावी होने से पहले कितना प्रशिक्षण – और व्यावहारिक अनुभव – चाहिए? एक डेमो कैसे इन सबको ध्यान में रख सकता है?
इसलिए हम डेमो का उपयोग लोगों को सोचने के लिए करते हैं। उन्हें संभावनाओं की कला दिखाने के लिए। किसी उत्पाद को बेचने के लिए नहीं। वास्तविक डेमो कस्टम समाधान के प्रोटोटाइप से शुरू होता है। MVP। और फिर हम तेजी से दोहराते और सुधारते हैं।
किसी बिंदु पर यह सॉफ्ट लॉन्च या पायलट प्रोग्राम के लिए तैयार हो जाता है। और फिर, हम साथ मिलकर सीखते हैं और उस सीख के आधार पर तेजी से सुधारते हैं। अक्सर यही वह चरण होता है जहाँ निगरानी, मूल्यांकन और पर्यवेक्षण स्पष्ट रूप से सामने आते हैं। जो चीज़ें आपको अंत में चाहिए, वे अक्सर उस अनुमान से बहुत अलग होती हैं जो आप शुरू में लगा रहे थे।
कंपनियाँ Crafters को प्रयोग करने के लिए कैसे सशक्त बना सकती हैं, बिना नई पीढ़ी के शैडो एआई सिस्टम, दोहराए गए वर्कफ़्लो, सुरक्षा कमजोरियों और ऐसे टूल्स जो कोई रख‑रखाव नहीं करता, उत्पन्न किए?
याद रखें कि शैडो आईटी कहाँ से आया: यह द्वेष नहीं था, बल्कि अनपूरी मांग की आवश्यक पूर्ति थी। Crafters निर्माण करते हैं क्योंकि समस्याएँ उन्हें परेशान करती हैं – यही जीन है। यदि स्वीकृत मार्ग में एक साल इंतजार करना पड़ता है, तो शैडो एआई अंतर को भर देगा – और वह सबसे खतरनाक जगह, यानी रडार के नीचे, भर देगा।
इसलिए स्वीकृत लेन को आसान बनाएँ। Crafters को एक स्वीकृत प्लेटफ़ॉर्म दें जिसमें सुरक्षा गार्डरेल पहले से ही शामिल हों – पहचान, डेटा एक्सेस, लॉगिंग – ताकि अनुपालन वाला विकल्प भी सुविधाजनक हो। एक हल्का रजिस्ट्री रखें: कोई भी चीज़ जो व्यक्तिगत प्रयोग से दूसरे व्यक्ति पर निर्भर होने तक बढ़ती है, उसे लिखित रूप में रखें, साथ ही एक नामित मालिक रखें। यह एकल नियम अधिकांश अनाथ‑टूल समस्या को खत्म कर देता है, क्योंकि नाम वाले टूल्स को चुपचाप नहीं छोड़ा जाता।
फिर एस्केलेशन मॉडल लागू करें: प्रयोग स्वतंत्र रूप से चलें, लेकिन जब कुछ मिशन‑क्रिटिकल बन जाता है – अधिक उपयोगकर्ता, अधिक संवेदनशीलता, अधिक स्वायत्तता – तो उसे क्रमशः अधिक इंजीनियरिंग समीक्षा मिलती है। Crafter व्यवसायिक लॉजिक का स्वामित्व रखता है; एक डेवलपर वह चीज़ को सुदृढ़ करता है जिसे सुदृढ़ करने की जरूरत है। लक्ष्य एक परिपक्वता पाइपलाइन है, न कि अनुमति प्रक्रिया। कंपनियों ने पहले ही स्प्रेडशीट्स के साथ यह सीनारियो चलाया है, और विजेता वे नहीं थे जिन्होंने एक्सेल को प्रतिबंधित किया।
किसी कंपनी के लिए जो अपनी पहली कस्टम एआई पहल शुरू कर रही है, उसे प्रारंभिक उपयोग‑केस कैसे चुनना चाहिए, यह मापना चाहिए कि प्रोजेक्ट सार्थक व्यवसायिक मूल्य दे रहा है या नहीं, और यह तय करना चाहिए कि इसे विस्तारित, पुनःडिज़ाइन या त्यागना चाहिए?
हम अपने ग्राहकों के साथ दो प्रकार के प्रारंभिक बिंदु उपयोग करते हैं।
विकल्प एक, उन कार्यों को देखें जो कोई नहीं कर रहा है – उन कार्यों को नहीं जिन्हें आप हटाना चाहते हैं। मेरे पास प्रबंधकों से पूछने का एक पसंदीदा प्रश्न है: आपने कभी सोचा है, “अगर मेरे पास एक व्यक्ति लगातार इसे देखता और सोचता रहता, तो चीज़ें बहुत बेहतर हो जातीं – लेकिन मैं इसे करने के लिए पूरी तरह से एक नई नियुक्ति को उचित नहीं ठहरा सकता?” ऐसे अक्सर आपके सबसे अच्छे प्रारंभिक बिंदु होते हैं। वे सुरक्षित हैं, भरोसे को बनाते हैं, कोई लक्ष्य बनकर नहीं महसूस करता, और वैकल्पिक स्थिति ईमानदार है: विकल्प यह था कि कोई मानव इसे अच्छी तरह नहीं कर रहा था, बल्कि कोई भी नहीं कर रहा था (जैसे मेरे संपादक मित्र Eddie)।
विकल्प दो, डैशबोर्ड को डेटा एजेंट्स से बदलने पर विचार करें। जितना सरल डैशबोर्ड लगते थे, वे अपने वादे को पूरा करने में बहुत कम पड़ते थे। जब कोई व्यापार प्रश्न पूछता है, तो उसे उस प्रश्न को डैशबोर्ड पर अनुवादित करने में बहुत काम करना पड़ता है। कहाँ है वह डैशबोर्ड जो इस प्रश्न का उत्तर देता है? उसका नाम क्या है? क्या ऐसा डैशबोर्ड वास्तव में मौजूद है? और यदि आप “सही” वाला ढूँढ लेते हैं, तो क्या वह स्पष्ट और सुविधाजनक है? क्या आपको उसे बार‑बार हेर‑फेर करना पड़ता है, कई संस्करणों को लिखना या स्क्रीनशॉट लेना ताकि आप जो कुल चित्र चाहते हैं, उसे बना सकें?
एआई युग में, आप बस अपना व्यापार प्रश्न – अपने शब्दों में – टाइप (या कहें!) करते हैं एक डेटा एजेंट को, जो फिर आपके लिए सब संभालता है, और एक प्रमाणित, अच्छी तरह शोधित उत्तर देता है – दृश्य सहित – एक या दो मिनट में। जब आपके पास फॉलो‑अप प्रश्न हो, तो वह भी जल्दी जवाब देता है – बैठक में जबकि निर्णय अभी भी लिए जा सकते हैं।
इन दोनों प्रारंभिक विकल्पों के पीछे सामान्य धागा क्या है? वे दोनों उन दर्द‑बिंदुओं को संबोधित करते हैं जिन्हें कर्मचारी अपनाएंगे न कि विरोध करेंगे। आप नहीं चाहते कि आपके शुरुआती एआई पहल अविश्वास को जन्म दें। आप चाहते हैं कि वे कर्मचारियों को टेबल पर लाएँ। आप चाहते हैं कि कर्मचारी सुधार और नए प्रोजेक्ट विचार सुझाएँ। क्योंकि फिर से, आपकी कंपनी हजारों वर्कफ़्लो से बनी है, और आपके कर्मचारी उन्हें आपसे बेहतर जानते हैं।
विस्तार, पुनःडिज़ाइन, या त्याग के बारे में – खुद के प्रति दयालु रहें, क्योंकि इस पर शोध वास्तव में आश्वस्त करता है: अधिकांश सफल एआई डिप्लॉयमेंट्स के पहले विफलताएँ थीं। पहला प्रोजेक्ट जो लाभ के बजाय सीख देता है, वह ट्यूशन है, न कि यह प्रमाण कि एआई काम नहीं करता। मेरा नियम है: यदि लोग इसका उपयोग कर रहे हैं, तो इसे विस्तारित करें। यदि लोग इसका उपयोग नहीं कर रहे हैं, तो आपको कारण जानना चाहिए, और यह कई प्रकार के उत्तर हो सकते हैं, “क्योंकि यह ठीक से काम नहीं करता” से लेकर “क्योंकि मैं इसे समझ नहीं पाता” या “यह मुझे डराता है” तक। उत्तर यह तय करता है कि आप इसे सुधारें, पुनःडिज़ाइन करें या त्यागें। आपको यह भविष्यवाणी करने की जरूरत नहीं है कि यह कहाँ पहुँचेगा। आपको केवल ईमानदार रूप से कहीं शुरू करना है।
उत्कृष्ट साक्षात्कार के लिए धन्यवाद, पाठकों को Fair Game: Customizing AI to Your Business Is Easier Than You Think भी पढ़ना चाहिए।












