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