कई सॉफ़्टवेयर टेंडरों का अंत एक ही तरह होता है। हर बोलीदाता (Bidder) हर पंक्ति के आगे “Complied” लिख देता है, सबसे कम दर वाली बोली (L1) टेंडर जीत जाती है, और एक साल बाद विभाग के हाथ में ऐसा सिस्टम होता है जो कागज़ी शर्तें तो पूरी करता है पर ज़मीनी ज़रूरत नहीं। आम तौर पर इसमें किसी ने धोखा नहीं दिया होता; बस RFP के स्पेसिफ़िकेशन के एक से ज़्यादा अर्थ निकल सकते थे, और सबसे सस्ते अर्थ वाली व्याख्या जीत गई।
स्पेसिफ़िकेशन्स में कमियाँ कैसे निकाली जाती हैं?
- अस्पष्ट शब्द: “यूज़र-फ़्रेंडली होना चाहिए”, “मज़बूत (Robust) होना चाहिए”, “रिपोर्ट निकलनी चाहिए” — ऐसा दावा कोई भी सॉफ़्टवेयर कर सकता है।
- कागज़ी 'Complied' चेकलिस्ट: फ़ीचर्स की लंबी सूची के आगे “Complied” का पूरा कॉलम भर दिया जाता है, और काम सौंपने से पहले उसे परखने का कोई ठोस तरीका नहीं होता।
- सामान्य डेमो: वेंडर अपनी पहले से तैयार सबसे आकर्षक स्क्रीन्स दिखाते हैं, आपके विभाग की वास्तविक कार्य-प्रक्रिया नहीं।
- अस्पष्ट दायरा और कम बोली: यदि काम का दायरा (Scope) ढीला हो, तो सबसे कम बोली लगाने वाला वेंडर उसका सबसे संकीर्ण अर्थ निकालता है और बाद में हर ज़रूरी काम के लिए 'चेंज रिक्वेस्ट' (Change Request) के ज़रिए अतिरिक्त पैसा वसूलता है।
सिद्धांत 1: सिर्फ़ फ़ीचर्स के नाम नहीं, बल्कि पूरा काम लिखिए
सिस्टम को क्या करना है, यह अपनी शब्दावली में साफ़ लिखिए: कार्य-प्रक्रियाएँ (कौन क्या करता है और किस क्रम में), बिज़नेस रूल्स (पात्रता, गणनाएँ, मंज़ूरियाँ), मुख्य रिकॉर्ड और उनके फ़ील्ड्स, भूमिका के अनुसार यूज़र्स की संख्या, अपेक्षित ट्रांज़ैक्शन की मात्रा (Volumes) और भाषाएँ। केवल फ़ीचर्स की सूची का फ़ायदा उठाना आसान होता है, लेकिन नियमों और काम की मात्रा से जुड़े प्रोसेस मैप से बच निकलना बहुत कठिन होता है।
सिद्धांत 2: हर शर्त को परखे जाने योग्य (Testable) बनाइए
हर आवश्यकता के साथ यह भी लिखिए कि आप उसकी जाँच कैसे करेंगे (Acceptance Criteria)। उदाहरण के लिए, “सिस्टम यूज़र-फ़्रेंडली होगा” के बजाय लिखिए: “एक घंटे के प्रशिक्षण के बाद, पहली बार काम कर रहा क्लर्क बिना किसी बाहरी मदद के तय समय के भीतर एक पूरा आवेदन दर्ज कर लेता है।” समय का आँकड़ा आप तय करें; महत्वपूर्ण यह है कि हर शर्त या तो स्पष्ट रूप से पास हो या फ़ेल, और दोनों पक्षों को पहले से पता हो कि उसकी जाँच कैसे की जाएगी।
सिद्धांत 3: वादे नहीं, प्रत्यक्ष प्रमाण माँगिए
तकनीकी मूल्यांकन (Technical Evaluation) के दौरान शॉर्टलिस्ट किए गए बोलीदाताओं को तय स्क्रिप्ट वाला एक व्यावहारिक परिदृश्य (Scripted Scenario) और अपने सैंपल डेटा का एक छोटा सेट दीजिए, और उनसे इसे लाइव चलाकर दिखाने को कहिए। जो सामने दिखे उसी पर अंक दीजिए: क्या नियमों ने सही नतीजे दिए? क्या स्क्रीन्स आपकी प्रक्रिया के अनुसार चलीं? क्या रिपोर्ट्स का मिलान हुआ? सौ पन्नों के कागज़ी अनुपालन पत्रों से कहीं ज़्यादा सच एक लाइव परिदृश्य डेमो बता देता है।
सिद्धांत 4: डिज़ाइन, डेटा और बाहर निकलने के रास्ते का स्वामित्व अपने पास रखिए
- पूरे डेटा का स्वामित्व विभाग का हो, और उसे किसी भी समय खुले व मानक फ़ॉर्मेट में एक्सपोर्ट किया जा सके।
- डेटा मॉडल, बिज़नेस रूल्स और इंटरफ़ेस का पूरा दस्तावेज़ीकरण कर विभाग को सौंपा जाए; वह वेंडर का निजी राज़ बनकर न रहे।
- सोर्स कोड का स्वामित्व या एस्क्रो (Escrow) व्यवस्था अनुबंध की शर्तों में पहले ही तय हो।
- अनुबंध समाप्त होने पर सिस्टम नए वेंडर या विभाग को कैसे हस्तांतरित किया जाएगा, इसके लिए स्पष्ट ट्रांज़िशन धारा (Transition Clause) हो।
सिद्धांत 5: मूल्यांकन में 'काम की उपयुक्तता' को महत्व दीजिए और प्रतिस्पर्धा निष्पक्ष रखिए
केवल सर्टिफ़िकेट और टर्नओवर को ही नहीं, बल्कि लाइव डेमो और प्रस्तावित डिज़ाइन की गुणवत्ता को भी पर्याप्त अंक (Weightage) दीजिए। साथ ही ऐसे मानदंड रखने से बचिए जिन्हें केवल एक ही वेंडर पूरा कर सके; स्पेसिफ़िकेशन में आपकी ज़रूरत का वर्णन होना चाहिए, किसी विशेष प्रोडक्ट का नहीं। हमेशा अपनी संस्था पर लागू खरीद नियमों के दायरे में रहकर ही प्रक्रिया पूरी करें।
सिद्धांत 6: आपके पास पहले से मौजूद पुराने डेटा का स्पष्ट विवरण दीजिए
ज़्यादातर नए सिस्टम्स की शुरुआत पुराने रिकॉर्ड्स से होती है: कागज़ी रजिस्टर, एक्सेल शीट्स या कोई पुराना डेटाबेस। यदि RFP में इनका स्पष्ट ब्योरा न हो, तो डेटा माइग्रेशन बाद में एक अनचाहा अतिरिक्त खर्च या जल्दबाज़ी का अधूरा काम बन जाता है। इसलिए मौजूदा डेटा स्रोतों, उनमें मौजूद अनुमानित रिकॉर्ड्स की संख्या, उनकी स्थिति और उन्हें साफ़ (Clean) करने की ज़िम्मेदारी का उल्लेख RFP में ही करें। साथ ही यह भी स्पष्ट करें कि माइग्रेशन किसकी ज़िम्मेदारी होगी और उसके पूरा होने की जाँच कैसे होगी।
सिद्धांत 7: भविष्य के बदलावों की योजना पहले ही बनाइए
अनुबंध की अवधि के दौरान नीतियाँ और नियम बदलना स्वाभाविक है। इसलिए RFP में ही तय कर लें कि बदलाव की माँग कैसे की जाएगी, उसका आकलन कैसे होगा और उसकी दरें (जैसे Rate Card के माध्यम से) कैसे तय होंगी। साथ ही मूल दायरे की एक हस्ताक्षरित बेसलाइन (Scope Baseline) रखें, ताकि हर चेंज रिक्वेस्ट को एक निश्चित पैमाने पर परखा जा सके।
RFP प्रकाशित करने से पहले की जाँच-सूची
- क्या हर प्रक्रिया, नियम और काम की मात्रा हमारी अपनी शब्दावली में स्पष्ट लिखी गई है?
- क्या हर आवश्यकता के साथ यह लिखा है कि उसे कैसे परखा जाएगा?
- क्या तकनीकी डेमो के लिए तय स्क्रिप्ट वाला परिदृश्य और सैंपल डेटा तैयार है?
- क्या डेटा का स्वामित्व, दस्तावेज़ीकरण, सोर्स कोड और बाहर निकलने की शर्तें अनुबंध में शामिल हैं?
- क्या एक से अधिक सक्षम वेंडर हर मानदंड को पूरा कर सकते हैं?
- क्या पुराने रिकॉर्ड्स, उनकी स्थिति और डेटा माइग्रेशन की ज़िम्मेदारी स्पष्ट रूप से लिखी है?
- क्या भविष्य के बदलावों (Change Requests) की क़ीमत तय करने का स्पष्ट तरीका मौजूद है?
Neodeus टेक्नोलॉजी टेंडरों के लिए तकनीकी स्पेसिफ़िकेशन, मूल्यांकन मानदंड और डेमो परिदृश्य तैयार करता है, और वेंडर चुने जाने के बाद 'डिज़ाइन अथॉरिटी' की भूमिका भी निभा सकता है — ताकि जो सिस्टम बनकर तैयार हो, वह ठीक वैसा ही हो जैसा RFP में तय किया गया था।