सॉफ़्टवेयर ख़रीदना
कस्टम सॉफ़्टवेयर बनाम रेडीमेड: वास्तव में निर्णय कैसे लें
यह निर्णय अधिकतर क़ीमत पर लिया जाता है और फ़िट पर पछतावा होता है। इसे ठीक से चलाने का तरीक़ा यह है, उन मामलों सहित जहाँ हम लोगों से कहते हैं कि न बनवाएँ।
हम कस्टम सॉफ़्टवेयर बनाते हैं, इसलिए आगे जो है उसे उतने ही संदेह से लीजिए जितना उसका हक़ है। फिर भी यह सच है कि हमसे यह सवाल पूछने वाले अधिकांश व्यवसायों को बनवाने के बजाय ख़रीदना चाहिए, और जिन्हें बनवाना चाहिए वे आमतौर पर फ़ोन करने से पहले ही कारण जानते हैं — वे बस चाहते हैं कि कोई पुष्टि कर दे कि जो चीज़ उन्हें नहीं मिल रही वह है ही नहीं।
निर्णय आमतौर पर लागत के रूप में रखा जाता है। वह ढाँचा ग़लत है, क्योंकि दोनों विकल्पों की लागतों का स्वरूप अलग है। पैकेज्ड सॉफ़्टवेयर की लागत कम, निश्चित और आवर्ती है और फ़िट अनिश्चित। कस्टम निर्माण की लागत अधिक, अनिश्चित और एकमुश्त है और फ़िट वही जो आप तय करें। पहली संख्या की पहली संख्या से तुलना लगभग कुछ नहीं बताती।
वे चार सवाल जो इसे तय करते हैं
इन्हें क्रम से चलाएँ। जो पहला स्पष्ट उत्तर देता है, आमतौर पर वहीं बहस ख़त्म हो जाती है।
- क्या यह प्रक्रिया प्रतिस्पर्धात्मक बढ़त है, या केवल ज़रूरी है?पेरोल ज़रूरी है। असाधारण रूप से अच्छा पेरोल चलाकर कोई व्यवसाय नहीं जीतता, इसलिए इसे ख़रीदिए। आप किसी काम की लागत कैसे निकालते हैं, किसी लॉट को ख़रीदार से कैसे मिलाते हैं, या अपनी मशीनें कैसे शेड्यूल करते हैं — यही वाक़ई आपकी प्रतिस्पर्धा हो सकती है, और उसे किसी और के वर्कफ़्लो में ढालना ही उस पर प्रतिस्पर्धा करना बंद करने का तरीक़ा है।
- क्या कोई पैकेज्ड उत्पाद आपके डेटा मॉडल को व्यक्त कर सकता है?आपकी स्क्रीन नहीं — आपका मॉडल। यदि आपके स्टॉक में दो इकाइयाँ हैं जिन्हें एक साथ सही रहना है, यदि माल आपका हो सकते हुए भी कहीं और रखा हो, यदि किसी कामगार को एक ही महीने में तीन अलग तरीक़ों से भुगतान होता है, तो एक मात्रा फ़ील्ड और एक वेतन संरचना वाला सिस्टम ऐसे ग़लत होगा जहाँ कॉन्फ़िगरेशन पहुँच ही नहीं सकता।
- कितने पैकेज लगेंगे?एक अच्छा पैकेज अधिकतर समय कस्टम निर्माण से बेहतर होता है। चार पैकेज और उन्हें जोड़ने वाली स्प्रेडशीट लगभग कभी नहीं — आपने चार फ़िट समस्याएँ ख़रीद ली हैं और बिना नाम दिए एक इंटीग्रेशन प्रोजेक्ट बना लिया है।
- तीन साल बाद इसका मालिक कौन होगा?कस्टम निर्माण के लिए कोई जवाबदेह चाहिए — चाहे वह आंतरिक डेवलपर हो, रिटेनर हो, या दूसरा स्टूडियो। यदि ईमानदार उत्तर 'कोई नहीं' है, तो इसके बजाय सपोर्ट अनुबंध वाला कुछ ख़रीदिए। बिना रखरखाव का कस्टम सॉफ़्टवेयर किसी भी और चीज़ से तेज़ी से बोझ बन जाता है।
दोनों ओर वे ख़र्च जो लोग चूक जाते हैं
पैकेज्ड की ओर, आवर्ती लाइसेंस दिखाई देने वाली लागत है और शायद ही सबसे बड़ी। छिपी लागतें हैं प्रति-उपयोगकर्ता मूल्य जो कर्मचारी संख्या के साथ बढ़ता है, वे मॉड्यूल जो अलग उत्पाद निकलते हैं, इम्प्लीमेंटेशन पार्टनर, वार्षिक वृद्धि, और वह काम जो आपकी टीम सॉफ़्टवेयर जो करता है और आपको जो चाहिए, उसके बीच का अंतर पाटने में करती है — जो एक स्थायी स्टाफ़ लागत है और तुलना में कभी नहीं दिखती।
पैकेज्ड की सबसे बड़ी लागत आमतौर पर वही है जिसकी क़ीमत कोई नहीं लगाता: वे प्रक्रियाएँ जो आप सॉफ़्टवेयर में ढलने के लिए बदलते हैं। कभी-कभी यह लाभ है, क्योंकि पैकेज्ड प्रक्रिया आपकी प्रक्रिया से बेहतर है। कभी-कभी इसका अर्थ है कि आपके सबसे अच्छे लोग हफ़्ता भर ऐसी डेटा एंट्री करते हैं जो केवल सिस्टम को ख़ुश रखने के लिए है।
कस्टम की ओर, निर्माण दिखाई देने वाली लागत है और आमतौर पर इसका अनुमान ईमानदारी से लगता है। जो कम आँका जाता है वह है डेटा माइग्रेशन, समानांतर संचालन, और दूसरे वर्ष के बदलाव। माइग्रेशन लगभग हमेशा दिखने से बदतर होता है, क्योंकि पुराने डेटा में दशक भर के ऐसे अपवाद हैं जिन्हें किसी ने दर्ज नहीं किया। समानांतर संचालन न वैकल्पिक है न मुफ़्त — कोई महीने भर काम दो बार करता है। और जो सॉफ़्टवेयर बदल नहीं सकता वह आप बदल देंगे, इसलिए बदलाव को विफलता मानने के बजाय उसका बजट रखिए।
वह हाइब्रिड जिसका प्रस्ताव कोई नहीं देता
व्यवहार में यह शायद ही सब-या-कुछ-नहीं होता है, और सबसे अच्छा उत्तर अक्सर यही है कि सामान्य चीज़ ख़रीदिए और भेद पैदा करने वाली चीज़ बनवाइए। वैधानिक अभिलेख के रूप में पैकेज्ड लेखा प्रणाली रखिए। वह परिचालन प्रणाली बनवाइए जो आपके काम को जानती है, और लेखा में स्वतः प्रविष्टि कराइए।
यह इसलिए काम करता है क्योंकि यह सीमा सही जगह रखता है। लेखा नियम सबके लिए एक जैसे हैं और विधान से बदलते हैं; परिचालन नियम आपके हैं और तब बदलते हैं जब आप तय करें। एक ही सिस्टम से दोनों कराने की कोशिश ही दोनों का सबसे ख़राब संस्करण पैदा करती है।
हम कब लोगों से ख़रीदने को कहते हैं
एक मानक ज़रूरत जिसका बाज़ार परिपक्व है। एकल-इकाई व्यवसाय के लिए लेखा, ईमेल, वेतनभोगी स्टाफ़ का पेरोल, दस्तावेज़ भंडारण, सरल उत्पाद बेचती छोटी टीम के लिए सामान्य CRM। इन श्रेणियों में दशकों से हज़ारों ग्राहकों के सामने निखारे उत्पाद हैं। हम बारह हफ़्तों में उन्हें नहीं हरा सकते और न कोई और।
अस्पष्ट समस्या। यदि आवश्यकता उन लोगों के साथ बातचीत में नहीं टिकती जो इसे इस्तेमाल करेंगे, तो निर्माण उस भ्रम का महँगा संस्करण बना देगा। कुछ सस्ता ख़रीदकर छह महीने उसके साथ गुज़ारना यह जानने का वैध तरीक़ा है कि आपको वास्तव में क्या चाहिए, और कहीं सस्ता भी।
दूसरे वर्ष के लिए न कोई ज़िम्मेदार, न बजट। जिस निर्माण को संभालने वाला कोई नहीं, वह ठीक उसी लेगेसी सिस्टम में बदल जाता है जिसे बदलने के लिए प्रोजेक्ट बना था, बस अब वह केवल आपके पास है।
जब बनवाना स्पष्ट रूप से सही है
आपने पैकेज आज़माए हैं और हर बार एक ही जगह विफल हुए। वह जगह आमतौर पर आपका डेटा मॉडल है, और वही विफलता बिंदु बना रहेगा, क्योंकि कॉन्फ़िगरेशन से यही एक चीज़ नहीं बदलती।
सॉफ़्टवेयर ही उत्पाद है, या वही है जिसका अनुभव ग्राहक करता है। ऐसे प्लेटफ़ॉर्म पर कोई अलग नहीं दिखता जिसकी सदस्यता प्रतिस्पर्धी भी ले सकते हैं।
इंटीग्रेशन का काम निर्माण से अधिक हो जाएगा। जब चार सिस्टम को सहमत होना पड़े और जोड़ने का काम लोग और स्प्रेडशीट करें, तो आप पहले से ही कस्टम सिस्टम की क़ीमत चुका रहे हैं — बस सॉफ़्टवेयर में नहीं, वेतन में, और सॉफ़्टवेयर मिले बिना।
अनुपालन या डेटा रेज़िडेंसी पैकेज्ड विकल्प को वाक़ई असंभव बना दे। यह दावे जितना आम नहीं है, इसलिए जाँचिए कि यह वास्तविक बाधा है या प्राथमिकता — पर जब यह वास्तविक हो, तो निर्णायक होता है।
प्रतिबद्ध होने से पहले निर्णय को कैसे परखें
- वे तीन बातें लिखिए जो आपकी मौजूदा प्रक्रिया करती है और जिन्हें आपके ख़्याल से कोई पैकेज नहीं संभालता। फिर एक दिन वाक़ई कोशिश कीजिए कि कोई एक पैकेज उन्हें कर दे। अधिकतर आपत्तियाँ इसमें नहीं टिकतीं, और जो टिकती हैं वही आपकी असली आवश्यकताएँ हैं।
- किसी भी विक्रेता से अपने विशिष्ट क्षेत्र में रेफ़रेंस माँगिए, और उस रेफ़रेंस से पूछिए कि उन्हें अपने काम करने के तरीक़े में क्या बदलना पड़ा। वही उत्तर फ़िट का अंतर है, ऐसे व्यक्ति के मुँह से जिसे उसे छोटा दिखाने में कोई लाभ नहीं।
- पैकेज्ड विकल्प की क़ीमत तीन वर्षों के लिए लगाएँ — इम्प्लीमेंटेशन, वार्षिक वृद्धि और अंतर पाटने में लगने वाले स्टाफ़ समय सहित — न कि पहले वर्ष के लाइसेंस शुल्क पर।
- निर्माण के लिए ऐसी चरणबद्ध योजना पर ज़ोर दीजिए जहाँ तीन महीने के भीतर कुछ वास्तविक उत्पादन में हो। यदि पहली डिलीवरी नौवें महीने में है, तो जोखिम प्रबंधित नहीं, बस टाला जा रहा है।
संक्षेप में
सामान्य चीज़ ख़रीदिए। जिस पर आप प्रतिस्पर्धा करते हैं वह बनवाइए, यदि उसे संभालने वाला कोई है। किसी पर भी — हम सहित — संदेह कीजिए जो आपका डेटा मॉडल समझे बिना इस सवाल का उत्तर दे दे, क्योंकि उत्तर वास्तव में वहीं बसता है।