अपना सॉफ्टवेयर बनाएँ या रेडीमेड सॉफ्टवेयर खरीदें — क्या चुनें?

वो सवाल जो ज़्यादातर कंपनियाँ उल्टा पूछती हैं

मैंने इस सवाल के मुश्किल वाले सिरे पर लगभग एक दशक बिताया है।

अपनी पिछली कंपनी में सात साल तक, कंपनी के अंदर चलने वाला सॉफ्टवेयर बनाना ही मेरा काम था। कोई साइड प्रोजेक्ट नहीं, कोई तिमाही पहल नहीं। यही मैं हर दिन करता था, और साथ में वो मुश्किल और चुपचाप वाला काम भी: यह पक्का करना कि जो बनाया है उसे लोग सच में इस्तेमाल करें। आज मैं AgentUI का CEO हूँ, जहाँ मैं दूसरी कंपनियों को ठीक यही फैसला लेने में मदद करता हूँ। तो जब कोई पूछता है कि बनाएँ या खरीदें, तो मैं कहीं पढ़ा हुआ कोई फ्रेमवर्क नहीं निकालता। मैं अपने ज़ख्मों के निशान निकालता हूँ।

मैंने जो सीखा उसका छोटा वर्ज़न यह है: ज़्यादातर कंपनियाँ सवाल उल्टा पूछती हैं। वे शुरू करती हैं "क्या यह खरीदा जा सकता है?" से, जबकि बेहतर शुरुआती सवाल है "क्या यह प्रोसेस सिर्फ़ हमारी कंपनी में ऐसा है?" ये दोनों एक ही सवाल नहीं हैं, और इन्हें आपस में मिला देना सालों का नुकसान कराता है।

मैं समझाता हूँ।

वो डिफ़ॉल्ट नियम जिसे सब गलत तरीके से लगाते हैं

चली आ रही समझ कागज़ पर ठीक ही लगती है: पहले रेडीमेड सॉफ्टवेयर आज़माओ, और तभी बनाओ जब कुछ भी फिट न बैठे। हम उस नियम को पूरी श्रद्धा से मानते थे। बनाने से पहले हमेशा खरीदने की कोशिश करते थे।

दिक्कत यह है कि असल में "कोशिश" किस चीज़ जैसी दिखती थी। अपने ऑपरेशन के एक अहम हिस्से के लिए हमने साल लगाए — हफ़्ते नहीं, साल — खरीदे हुए सॉफ्टवेयर को चलाने की कोशिश में। उस दौरान हमने दो अलग-अलग टूल चलाए। दोनों फेल हुए। और हर बार एक ही वजह से फेल हुए: वे हमसे कहते थे कि हम अपना काम उनके सॉफ्टवेयर के हिसाब से बदलें, न कि सॉफ्टवेयर हमारे काम के हिसाब से बदले।

यही एक वाक्य पूरी बहस का छोटा रूप है। जब आप ऐसे प्रोसेस के लिए रेडीमेड सॉफ्टवेयर खरीदते हैं जो सच में सिर्फ़ आपके बिज़नेस का है, तो आप कोई समाधान नहीं खरीद रहे। आप अपने काम करने के पूरे तरीके की मरम्मत का प्रोजेक्ट खरीद रहे हैं, और वह मरम्मत कभी पूरी नहीं होती। हर जुगाड़, हर "यह हिस्सा तो बगल में एक एक्सेल शीट पर कर लेंगे", हर ट्रेनिंग सेशन जिसमें समझाना पड़ता है कि टूल सबसे सीधी चीज़ क्यों नहीं करता — यही कीमत है अपने बिज़नेस को किसी और की मान्यताओं में ठूँसने की।

जो कोई नहीं बताता वो यह है कि यह कीमत बिल पर नहीं दिखती। सॉफ्टवेयर पर दाम लिखा होता है। सालों की ऑपरेशनल रगड़ पर नहीं।

एक असली उदाहरण: वो सेल्स टूल जिसने दुनिया खोल दी

मैं इसे ठोस बना देता हूँ, क्योंकि अमूर्त बातों पर सिर हिलाना आसान है और उन पर अमल करना मुश्किल।

मैंने जो सबसे बड़े टूल बनाए, उनमें से एक हमारे सेल्स रेप्स के लिए था। उससे पहले एक कोटेशन बनाना हाथ से किया जाने वाला सिरदर्द था। रेप को कई Excel फाइलें जोड़नी पड़ती थीं, ऐसा स्टॉक डेटा ढूँढना पड़ता था जो अपडेटेड हो भी सकता था और नहीं भी, और टेक्निकल जानकारी — स्पेक शीट्स, PDF, अप्रोच के डॉक्यूमेंट — जहाँ भी पड़ी हो वहाँ से खोदकर निकालनी पड़ती थी। यह धीमा था, गलतियों से भरा था, और पूरी तरह इस पर टिका था कि उस एक रेप को पता हो कि कौन-सी चीज़ कहाँ रखी है।

तो हमने एक टूल बनाया जिसमें रेप लॉग-इन करके लाइव स्टॉक देख सकता था और उसी वक्त कोटेशन बना सकता था। फायदा सिर्फ़ रफ़्तार का नहीं था। फायदा यह था कि हर टेक्निकल जानकारी एक ही जगह आ गई। प्रोडक्ट पर क्लिक कीजिए और सब कुछ सामने: स्पेसिफिकेशन, डॉक्यूमेंटेशन, PDF, अप्रोच। और फिर — यही हिस्सा सबसे अहम था — पूरा पैकेज एक क्लिक में क्लाइंट के साथ शेयर किया जा सकता था।

उस टूल ने कुछ ऐसा किया जिसका मुझे बनाना शुरू करते वक्त पूरा अंदाज़ा नहीं था। उसने हमें दुनिया भर से ऐसे क्लाइंट दिलाए जिन तक हम पहले कभी पहुँच ही नहीं पाए थे। जब दूसरे महाद्वीप पर बैठे किसी संभावित ग्राहक को पूरा, प्रोफेशनल और टेक्निकली डिटेल्ड कोटेशन दिनों की जगह मिनटों में मिल जाता है, तो दूरी मायने रखना बंद कर देती है। उस टूल ने हमें सिर्फ़ तेज़ नहीं बनाया। उसने उस बाज़ार का आकार ही बढ़ा दिया जिसे हम भरोसे के साथ सँभाल सकते थे।

कोई भी रेडीमेड प्रोडक्ट यह नहीं कर पाता, क्योंकि कोई भी रेडीमेड प्रोडक्ट हमारे स्टॉक, हमारे टेक्निकल डॉक्यूमेंटेशन और हमारे बेचने के तरीके को उतना नहीं समझता था जितना हम समझते थे। हमने कोशिश की थी। वो दो टूल और वो बर्बाद हुए साल याद हैं? यही था जिसे वे बदलने की कोशिश कर रहे थे और नहीं कर पाए।

तो आपको कब खरीदना चाहिए?

अगर आप यहाँ तक यह सोचते हुए पहुँचे हैं कि मैं "सब कुछ खुद ही बनाओ" वाला कट्टर आदमी हूँ, तो मैं अभी सुधार कर देता हूँ। मैं वैसा नहीं हूँ।

मैं कभी CRM नहीं बनाऊँगा। अपना CRM हम खरीदते हैं, बस, और लगभग सबको यही सलाह दूँगा।

फ़र्क यह है। CRM को आपके ईमेल और एक दर्जन दूसरे टूल्स से जुड़ना पड़ता है। यह सचमुच जटिल और परिपक्व कैटेगरी है, और मौजूदा प्रोडक्ट्स इसलिए मज़बूत हैं क्योंकि हज़ारों कंपनियों ने सालों तक उन्हें ठोका-पीटा है। अपना बनाकर कोई खास बढ़त नहीं मिलती। आप बहुत मेहनत लगाकर, अच्छे से अच्छे मामले में, उस चीज़ से थोड़ी खराब चीज़ तक पहुँचेंगे जो पहले ही दिन खरीदी जा सकती थी।

यही टेस्ट है, और यह "बनाएँ या खरीदें" के ज़्यादातर फ्रेमवर्क से आसान है:

• जब समस्या सबकी एक जैसी हो तो खरीदिए। अगर सौ और कंपनियों की भी वही ज़रूरत है, तो किसी ने आपसे बेहतर वर्ज़न पहले ही बना दिया है और उसे हर चीज़ से जोड़ भी दिया है। CRM, ईमेल, अकाउंटिंग, पेरोल — ये हल हो चुके हैं। इन्हें दोबारा मत बनाइए।
• जब प्रोसेस सिर्फ़ आपका हो तो बनाइए। जब आपके पास ऐसा वर्कफ्लो हो जो आपकी कंपनी के चलने के तरीके से जुड़ा है — जैसे हमारा टेक्निकल कोटेशन बनाने का तरीका — तभी बनाना सही बैठता है। कोई प्रोडक्ट फिट नहीं होगा, क्योंकि वह प्रोसेस सिर्फ़ आपकी दीवारों के भीतर मौजूद है।

फैसला करने वाला सवाल कभी "क्या इसके लिए सॉफ्टवेयर मौजूद है?" नहीं होता। वह होता है "हम यहाँ जो करते हैं, क्या वह इतना अलग है कि कोई भी जनरल टूल उसे पकड़ ही न पाए?" अगर हाँ, तो बनाइए। अगर नहीं, तो खरीदिए और आगे बढ़िए।

AI ने असल में क्या बदला

मेरे करियर के ज़्यादातर हिस्से में इस फैसले के साथ एक कड़वी शर्त जुड़ी रहती थी: जब बनाना साफ़ तौर पर सही होता था, तब भी वह महँगा था। डेवलपर्स चाहिए थे। वक्त चाहिए था। बनाना सिद्धांत में सही और हकीकत में अक्सर बजट से बाहर था, और इसीलिए इतनी कंपनियाँ ऐसे टूल खरीद लेती थीं जो फिट नहीं बैठते थे — और फिर हमारी तरह सालों तक भुगतती थीं।

AI ने वह शर्त खत्म कर दी, और यही हिस्सा मुझे सच में रोमांचित करता है।

पुरानी दुनिया आपको मजबूर करती थी कि आप अपना पूरा ऑपरेशन सॉफ्टवेयर के हिसाब से ढालें। नई दुनिया आपको ऐसा सॉफ्टवेयर बनाने देती है जो आपके बिज़नेस के हिसाब से ढलता है। यही पलटाव पूरा खेल है। हर बिज़नेस अलग है, और पहली बार आपके पास ऐसा सिस्टम हो सकता है जो आपके ऑपरेशन और आपकी कंपनी चलाने के अपने तरीके को डिजिटल कर दे — इंजीनियरों की फौज के बिना।

AgentUI में हम ठीक यही बना रहे हैं। बात यह है कि डेवलपर हायर करके महीनों इंतज़ार करने की जगह, आपको जो भी इंटरनल टूल चाहिए वह आप AI से बना सकें। साफ़ कर दूँ: डेवलपर्स के पास अब भी बहुत काम है। ग्राहक के सामने जाने वाले प्रोडक्ट के लिए मैं बिना सोचे डेवलपर रखूँगा — जिसे आपके ग्राहक छूते हैं, वह उस स्तर की बारीकी माँगता है। लेकिन अंदरूनी टूल्स के लिए? ज़्यादातर मामलों में अब उसकी ज़रूरत नहीं। ज़रूरत है AI की और एक ऐसे टूल की जो आपको बनाने दे।

इससे "बनाएँ या खरीदें" का गणित ऐसे बदलता है जिसे कम आँकना आसान है। जब बनाना महँगा था, तब "खरीद लो और अपना काम मोड़ लो" अक्सर समझदारी वाला विकल्प था, भले तकलीफ़ देता हो। अब जब बनाना सस्ता और तेज़ है, तराज़ू ज़ोर से उस तरफ़ झुक जाता है कि जो चीज़ सच में आपकी है उसे खुद बनाइए।

दो आपत्तियाँ जो मैं सबसे ज़्यादा सुनता हूँ

जब भी मैं यह बात रखता हूँ, लगभग हर बार दो चिंताएँ सामने आती हैं। ये जायज़ हैं और सीधे जवाब की हकदार हैं।

"सिक्योरिटी का क्या?"

यह सबसे बड़ी है। कंपनियों को डर रहता है कि जानकारी लीक हो जाएगी, गलत लोग डेटा तक पहुँच जाएँगे, हैक हो जाएगा या जानकारी खो जाएगी। यह डर वाजिब है: इतिहास में अपने टूल बनाने का मतलब अपनी सिक्योरिटी का सिरदर्द भी खुद उठाना रहा है। इसे हम AgentUI में मैनेज्ड इन्फ्रास्ट्रक्चर के साथ सीधे हल करते हैं, ताकि आप जो भी बनाएँ वह शुरू से सुरक्षित रहे। एक इंटरनल टूल बनाने के लिए आपको सिक्योरिटी एक्सपर्ट नहीं बनना चाहिए, और "यह हमारे बिज़नेस पर फिट बैठता है" और "इससे हम हैक नहीं होंगे" में से किसी एक को चुनना भी नहीं पड़ना चाहिए।

"क्या हम हमेशा के लिए इसके रखरखाव में नहीं फँस जाएँगे?"

यह मेंटेनेंस और टेक्निकल डेट का डर है, और यही चुपचाप बहुत सारे अच्छे फैसलों को मार देता है। मान्यता यह है कि बनाने का मतलब है हमेशा की देखरेख पर दस्तखत कर देना। पर लोग एक बात चूक जाते हैं: एक वक्त ऐसा आता है जब आप बस बनाना बंद कर सकते हैं। टूल अपना काम करता रहता है और आप आगे बढ़ जाते हैं। और जो हिस्सा सचमुच मुश्किल है — नीचे की इन्फ्रास्ट्रक्चर को सँभालना, वही जो असल में घबराहट पैदा करता है — वही हम बैक एंड पर सँभालते हैं, ताकि आपको हर टुकड़े की निगरानी न करनी पड़े। बनाइए, पूरा कीजिए, आगे बढ़िए।

सबसे उलटी बात: कैथेड्रल बनाने की कोशिश छोड़ दीजिए

यहाँ मैं अपना झंडा गाड़ता हूँ, और मुझे लगता है कि बनाने का फैसला कर लेने के बाद भी ज़्यादातर लोग यही गलती करते हैं।

शुरू से एक विशाल सिस्टम बनाने की कोशिश मत कीजिए। यह लगभग हमेशा बुरा आइडिया है।

जैसे ही कोई कंपनी अपना सॉफ्टवेयर बनाने को लेकर उत्साहित होती है, प्रवृत्ति बड़ा सोचने की होती है — एक ऐसा भारी-भरकम इंटरनल प्लेटफ़ॉर्म डिज़ाइन करना जो पूरा बिज़नेस चलाएगा। इसी तरह ये प्रोजेक्ट मरते हैं। कोई नतीजा देने से पहले ही वे अपनी महत्वाकांक्षा के बोझ से ढह जाते हैं।

कहीं बेहतर चाल यह है कि जो प्रोसेस आप पहले से हाथ से कर रहे हैं उन्हें डिजिटल कीजिए — वे जो अभी Excel में रहते हैं, वे जो सिर्फ़ आपकी कंपनी के हैं। बस इतना। वो शीट ढूँढिए जिससे आपकी टीम परेशान है, वो हाथ से जोड़-तोड़ जो हर हफ़्ते घंटे खा जाती है, वो काम जो सिर्फ़ आपकी कंपनी और सिर्फ़ आपके तरीके से होता है। वही बनाइए। वह छोटा है, ठोस है, उसका फ़ायदा साफ़ दिखता है, और वह ठीक उसी किस्म की चीज़ है जिसे कोई रेडीमेड टूल कभी ढंग से नहीं सँभालेगा।

बड़ी दृष्टि से नहीं, उस तकलीफ़ देने वाली एक्सेल शीट से शुरू कीजिए। कैथेड्रल इंतज़ार कर सकता है। जिस कोटेशन टूल ने हमारे लिए दुनिया खोली, वह किसी भव्य प्रोजेक्ट के रूप में शुरू नहीं हुआ था — वह इस बात से शुरू हुआ कि "यह हाथ का काम हमें मार रहा है, चलो इसे ठीक करते हैं।"

कुल मिलाकर

जो सबके लिए एक जैसा है वो खरीदिए। जो सचमुच आपका है वो बनाइए। ऐसे सॉफ्टवेयर में फिट होने के लिए अपने काम को मत मोड़िए जो कभी आपके लिए बनाया ही नहीं गया — हमने सालों यह गलती की, और बिल खोए हुए समय और खोए हुए मौकों के रूप में चुकाना पड़ा। और जो भी बनाइए, छोटा शुरू कीजिए, उसी हाथ वाले प्रोसेस से शुरू कीजिए जिसे आप पहले से समझते हैं, और टूल को वहीं से बढ़ने दीजिए।

मेरे करियर के ज़्यादातर हिस्से में इस सलाह के साथ यह शर्त लगी रहती थी कि बनाना एक विलासिता है। अब नहीं है। जिस चीज़ के लिए पहले डेवलपर्स और महीनों का काम चाहिए था, उसे अब वही लोग बना सकते हैं जो प्रोसेस को असल में समझते हैं — यानी आप।

यही असली बदलाव है। सवाल कभी सिर्फ़ बनाने बनाम खरीदने का नहीं था। सवाल यह था कि क्या आप ऐसा सॉफ्टवेयर रख सकते हैं जो आपके काम करने के असली तरीके पर फिट बैठे। अब आप रख सकते हैं।