अध्याय 24 - प्रस्तावों के लिए अनुरोध और प्रतिस्पर्धात्मक वार्ताएँ

1

परिचय

समस्या का विवरण प्रदान करता है और इसके बारे में इतना विस्तार से बताया जाना चाहिए, ताकि सप्लायर RFP को चलाने वाली व्यावसायिक समस्याओं और समस्या उत्पन्न होने वाली तकनीकी समस्याओं को समझ सकें।

2

प्रस्ताव के निर्देश और एडमिनिस्ट्रेशन

इसमें वे सभी प्रशासनिक आवश्यकताएँ और जानकारी शामिल है, जिनका अनुपालन किसी स्वीकार्य प्रस्ताव को सबमिट करने के लिए आपूर्तिकर्ता को करना चाहिए। इस सेक्शन में ख़रीदारी के लिए बुनियादी नियम शामिल हैं, RFP सबमिट करने से लेकर कॉन्ट्रैक्ट देने तक और इसमें निम्न प्रकार की जानकारी होनी चाहिए:

• प्रस्ताव से पहले का कॉन्फ़्रेंस कब और कब आयोजित किया जाएगा
• ख़रीद चक्र के लिए प्रासंगिक तारीखें
• प्रस्ताव तैयार करने और सबमिट करने के लिए आवश्यकताएँ (यानी, वर्जीनिया कोड की आवश्यकताएँ, साथ ही प्रस्ताव प्रोटोकॉल)
• प्रस्तावों का मूल्यांकन कैसे किया जाएगा
• RFP सिंगल पॉइंट ऑफ़ कॉन्टैक्ट नाम और संपर्क जानकारी
• प्रस्ताव कब, कहाँ और किसको मिलने वाले हैं
• दूसरी जानकारी जो सप्लायर को पूरी तरह से रेस्पॉन्सिव बनाने के लिए ज़रूरी होती है

अगर निर्देश अधूरे या अस्पष्ट हैं, तो सप्लायर महत्वपूर्ण मीटिंग्स या माइलस्टोन को नज़रअंदाज़ कर सकते हैं। कुछ आपूर्तिकर्ता गुणवत्ता निर्देशों की कमी को एक कमज़ोर प्रोजेक्ट टीम या विवादित प्रोजेक्ट की निशानी के रूप में देख सकते हैं, जो उद्योग के प्रमुख आपूर्तिकर्ताओं को प्रस्ताव सबमिट न करने के लिए प्रभावित कर सकता है। RFP की प्रशासनिक ज़रूरतों का अनुपालन करने में आपूर्तिकर्ता की विफलता, प्रस्ताव अस्वीकार होने का कारण हो सकता है। इस सेक्शन में RFP का जवाब देने के लिए और सप्लायर को फ़ॉलो न करने पर लगने वाले जुर्माने के बारे में जानकारी देने के लिए स्पष्ट नियम पेश किए जाएंगे।

3

प्रस्ताव का फ़ॉर्मेट

प्रस्तावों को फ़ॉर्मेट और बाउंड कैसे किया जाता है और आवश्यक मीडिया (यानी, हार्डकॉपी, सीडी, आदि) के बारे में जानकारी प्रदान करता है। यह दिखाने के लिए कि क्या प्रस्ताव के अलग-अलग सेक्शन अलग से सबमिट किए जाने हैं या नहीं; यानी, लागत से तकनीकी जानकारी शामिल करना, फिर से बनाया गया, आदि)। इस सेक्शन को सेक्शन 2 में प्रस्ताव के निर्देशों की नकल या उसके विपरीत नहीं होना चाहिए।

4

मौजूदा स्थिति

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

5

कार्यात्मक और तकनीकी आवश्यकताएँ

कार्यात्मक और तकनीकी आवश्यकताएँ और पर्याप्त जानकारी प्रदान करता है, ताकि सप्लायर समस्याओं को समझ सकें और एक पूर्ण और पक्का प्रस्ताव तैयार कर सकें। इस अवलोकन से मौजूदा बिज़नेस एप्लिकेशन और तकनीकी वातावरण (हार्डवेयर, सॉफ़्टवेयर, संचार), दोनों के बारे में पता होना चाहिए। यह सुझाव दिया जाता है कि एजेंसियां “ज़रूरी” और “करेंगे” तकनीकी ज़रूरतों का इस्तेमाल न करें, लेकिन सप्लायर को सुझाव दें कि वे समाधान पर आधारित प्रस्ताव के तहत समस्या का समाधान कैसे करेंगे। तकनीकी और फ़ंक्शनल आवश्यकताएँ सेक्शन में वे सवाल शामिल हैं, जिनके जवाब सप्लायर को देने होंगे, जैसे:

• सफलता के महत्वपूर्ण कारक
• मौजूदा सिस्टम के लिए फ़ंक्शनल स्पेसिफिकेशन्स
• प्रोजेक्टेड सिस्टम के लिए फंक्शनल स्पेसिफिकेशन्स
• परफ़ॉर्मेंस के खास विवरण
• सेवा स्तर की उम्मीदें
• हार्डवेयर आवश्यकताएँ (अगर ज़रूरी हो)
• सॉफ़्टवेयर से जुड़ी आवश्यकताएँ
• सुरक्षा और डेटा सुरक्षा से जुड़ी ज़रूरी शर्तें
• संचार आवश्यकताएँ (अगर ज़रूरी हो)
• परीक्षण की आवश्यकताएँ
• क्या उनका समाधान VITA सुरक्षा, डेटा मानक और एंटरप्राइज़ आर्किटेक्चर और IT पहुँच/508 अनुपालन ITRMPSGs का अनुपालन करता है (या कर सकता है)

प्रोजेक्ट प्रबंधन की ज़रूरतों में प्रोजेक्ट के प्रबंधन और उसे लागू करने की शर्तें बताई गई हैं। इस सेक्शन से सप्लायर को प्रोजेक्ट योजना, जोखिम शमन योजना या अन्य प्रबंधन योजना तैयार करने के लिए ज़रूरी जानकारी मिलेगी, जो प्रोजेक्ट की जटिलता और मिशन की गंभीरता के लिए ज़रूरी है और इसमें आवश्यकताओं की परिभाषा, कार्यान्वयन, इंस्टॉलेशन, परीक्षण, प्रशिक्षण, रखरखाव और प्रोजेक्ट के अन्य चरणों तक फैली हुई है। प्रस्तावित प्रोजेक्ट प्लान यह आश्वासन देता है कि सप्लायर के पास कॉन्ट्रैक्ट को सफलतापूर्वक पूरा करने के लिए ज़रूरी संसाधन हैं। प्रोजेक्ट मैनेजमेंट प्लान में आम तौर पर निम्नलिखित शामिल होते हैं:

• स्टाफ़िंग से जुड़ी ज़रूरतें
• साइट तैयार करने की ज़िम्मेदारियाँ
• डिलीवरी और इंस्टालेशन का शेड्यूल और प्लान
• सिस्टम स्वीकार्यता परीक्षण से जुड़ी आवश्यकताएँ
• सिस्टम के रखरखाव से जुड़ी आवश्यकताएँ
• सिस्टम प्रशिक्षण की आवश्यकताएँ
• दस्तावेज़ों से जुड़ी आवश्यकताएँ

एजेंसियों को याद रखना चाहिए कि यह संभव है कि सप्लायर तकनीकी ज़रूरतों को पूरा कर सके, लेकिन प्रबंधन की ज़रूरतों को पूरा नहीं कर सकता, जैसा कि इस सेक्शन पर उनकी खराब या अपर्याप्त प्रतिक्रियाओं से पता चलता है। प्रबंधन सेक्शन परिपक्व या अपरिपक्व प्रबंधन क्षमताओं वाले आपूर्तिकर्ताओं के बीच अंतर करने में मदद करेगा।

आप आपूर्तिकर्ताओं से कह सकते हैं कि वे RFP और प्रोजेक्ट के इच्छित उद्देश्यों से जुड़ी सभी धारणाओं और संभावित जोखिमों की पहचान करें; और/या उनसे एक समान प्रोजेक्ट के बारे में विस्तार से बताने के लिए कह सकते हैं और उन्होंने अपने ग्राहकों की संतुष्टि के लिए अपने प्रदर्शन के दौरान होने वाली समस्याओं या समस्याओं को कैसे हल किया है।

6

स्पष्ट और विशिष्ट प्रदर्शन के उपाय और प्रवर्तन प्रावधान

IT निवेदन और अनुबंध जो वर्जीनिया संहिता की धारा 2.2-4303.01 में परिभाषित “उच्च जोखिम” की परिभाषा को पूरा करते हैं, उनमें आपूर्तिकर्ता के गैर-प्रदर्शन के मामले में उपायों सहित स्पष्ट और अलग प्रदर्शन उपाय और प्रवर्तन प्रावधान शामिल होने चाहिए।

प्रदर्शन के स्पष्ट और विशिष्ट उपायों और प्रवर्तन प्रावधानों के बारे में ज़्यादा जानने के लिए नीचे दिए गए टूल का इस्तेमाल करें, जिनमें उपचार भी शामिल हैं:

         प्रमुख IT खरीद, उच्च जोखिम IT खरीद और के लिए न्यूनतम आवश्यकता मैट्रिक्स

         1। डेलिगेटेड प्रोक्योरमेंट्स 

         2। परफ़ॉर्मेंस मेट्रिक्स टूल

7

सप्लायर प्रोफ़ाइल

सप्लायर से कहा जाता है कि वे अपनी बिज़नेस और पेशेवर योग्यताओं के बारे में बताएं और उनका संदर्भ दें। उन्हें अपनी कॉर्पोरेट और वित्तीय स्थिति और उन ग्राहकों के बारे में जानकारी देने के लिए कहा जाना चाहिए, जो उनके पेशेवर प्रदर्शन और ईमानदारी के लिए रेफ़रेंस के तौर पर काम करेंगे। इस सेक्शन में आम तौर पर जिन चीज़ों की ज़रूरत होती है, वे नीचे दिए गए उदाहरण दिए गए हैं:

• सप्लायर का कॉर्पोरेट इतिहास, संगठनात्मक ढांचा, स्थान और बिज़नेस के आकार की स्थिति (यानी, DSBSD-प्रमाणन स्थिति, अगर लागू हो)।
• समाधान या प्रॉडक्ट का प्रकार उपलब्ध कराने के लिए सप्लायर का सामान्य बैकग्राउंड अनुभव और क्षमता
• सप्लायर और किसी भी प्रस्तावित पार्टनर/उप-ठेकेदार/निर्माता के बीच के संबंध का विवरण, यदि कोई है, और यह संबंध कितने समय से चल रहा है
• इस बात का सबूत है कि सप्लायर के पास ज़रूरी तकनीकी, परिचालन और प्रबंधन कौशल, स्टाफ़ और वित्तीय संसाधन हैं और उन्हें पूरा करने की व्यवहार्यता है
• वर्तमान में इन्स्टॉल किए गए समान/मिलते-जुलते प्रॉडक्ट्स, सिस्टमों की सूची या
• मिलते-जुलते प्रोजेक्ट, कॉन्फ़िगरेशन और/या ऐप्लिकेशन वाले ग्राहकों के नाम, जो रेफ़रंस दे सकते हैं, जिनमें संपर्क नाम और टेलीफ़ोन नंबर शामिल हैं।
• सप्लायर की योग्यताएं, जिसमें रिज़्यूमे, कंपनी प्रोफ़ाइल और बिज़नेस शामिल हैं
• सेवाएँ प्रदान करने का आपूर्तिकर्ता का सामान्य तरीका, जिसमें कार्य योजना का विवरण, इस्तेमाल की जाने वाली विधियाँ और डिलीवरेबल/प्रोजेक्ट के लिए टाइमलाइन का नमूना शेड्यूल शामिल है

8

स्वाम सेक्शन

आपूर्तिकर्ताओं से एक “सप्लायर प्रोक्योरमेंट और सब-कॉन्ट्रैक्टिंग प्लान” देने को कहा जाता है, जिसमें बताया जाता है कि सप्लायर कॉन्ट्रैक्ट की ज़रूरतों को पूरा करने के लिए उप-ठेकेदारों के साथ सीधे ख़र्च करने का अनुमान लगाता है। इसके अलावा, सप्लायर से कहा जाता है कि वे उन सब-ठेकेदारों की सूची दें, जिन्हें वह सप्लायर के कॉन्ट्रैक्ट के प्रदर्शन में इस्तेमाल करने की उम्मीद करता है। उप-ठेकेदारों की सूची में उन उप-ठेकेदारों को निर्दिष्ट किया जाना चाहिए जो SWAM व्यवसाय हैं, साथ ही जो नॉन-SWAM व्यवसाय हैं। यदि आपूर्तिकर्ता DOE अनुबंध के निष्पादन में उपठेकेदारों के उपयोग की आशा नहीं है, तो आपूर्तिकर्ता को अपने उत्तर में यह तथ्य बताने के लिए कहा जाता है।

9

कीमत की जानकारी

बताता है कि सप्लायर मूल्य निर्धारण की जानकारी कैसे देते हैं और मूल्य प्रस्तावों को तैयार करने के लिए उन्हें फ़ॉलो करने के लिए विस्तृत फ़ॉर्मेट प्रदान करता है। निर्देश बिल्कुल साफ़ होने चाहिए, ताकि यह पक्का किया जा सके कि कीमत के प्रस्तावों की समान आधार पर तुलना की जा सके। इस तुलना को आसान बनाने के लिए, स्प्रेडशीट का नमूना देने पर विचार करें, जो प्रस्तावित सिस्टम को निम्नलिखित जैसे घटकों में विभाजित करती है:

• सिस्टम सॉफ़्टवेयर
• ऐप्लिकेशन डेवलपमेंट सॉफ़्टवेयर
• इंस्टालेशन
• रख-रखाव
• प्रशिक्षण
• दस्तावेज़ीकरण
• प्रोजेक्ट प्रबंधन
• यूनिक हार्डवेयर या सॉफ़्टवेयर का इंटीग्रेशन
• लाइसेंस शुल्क (चल रहा है)

मूल्य सबमिट करने का तरीका के तौर पर, कीमत निर्धारण का शेड्यूल/परिदृश्य शामिल करें। अगर एकमुश्त कीमत लगाना फ़ायदेमंद नहीं है, तो अज्ञात मात्रा या घंटों के लिए मूल्य निर्धारण परिदृश्य का इस्तेमाल करें। आवर्ती बनाम गैर-आवर्ती लागतों के ब्रेकआउट के लिए पूछें। कीमत का शेड्यूल डिलिवरेबल्स से जुड़ा होना चाहिए और यह सॉलिसिटेशन में निर्धारित भुगतान के तरीके के अनुसार होना चाहिए।

कीमत के शेड्यूल देखते समय, कीमत पर ध्यान दें, जिसमें एक बार की लागत बनाम बार-बार होने वाली लागत शामिल होती है। किसी सॉफ़्टवेयर पैकेज की शुरुआती कीमत एक बार की लागत है; वार्षिक रखरखाव और सॉफ़्टवेयर लाइसेंस शुल्क बार-बार होने वाली लागतें हैं, जिन्हें किसी प्रोजेक्ट की संपूर्ण जीवन-चक्र लागत को विकसित करने के लिए पहचाना जाना चाहिए। आमतौर पर पुरस्कार के लिए मूल्य निर्धारण ही एकमात्र निर्धारक नहीं होता है, लेकिन इसका इस्तेमाल समान रूप से अच्छे तकनीकी और प्रबंधन प्रस्तावों वाले दो आपूर्तिकर्ताओं के बीच के रिश्ते को तोड़ने के लिए किया जाना चाहिए।

जटिल प्रोजेक्ट के लिए आप सप्लायर से एक माइलस्टोन प्राइसिंग शेड्यूल सबमिट करने के लिए भी कह सकते हैं, जिस पर अंतिम इनवॉइस पर अंतिम स्वीकृति के बाद भुगतान करने के लिए होल्डबैक प्रतिशत लागू किए जा सकते हैं। यह सप्लायर को प्रेरित करता है और अगर अंतिम स्वीकृति में देरी या समस्या आती है, तो यह एजेंसी के लिए सुरक्षा प्रदान करता है। अगर सप्लायर काम नहीं कर रहा है, तो इससे किसी भी पड़ाव पर कॉन्ट्रैक्ट को आसानी से अलग किया जा सकता है।

10

एजेंसी मानक अनुबंध (यानी, कॉन्ट्रैक्ट टेम्पलेट)

इसमें गैर-प्रकटीकरण समझौते, गोपनीयता, डेटा संरक्षण और सुरक्षा आवश्यकताओं, वारंटियों, लाइसेंसिंग अनुबंध आवश्यकताओं और अन्य वैधानिक, कानूनी और IT-विशिष्ट नियमों और शर्तों, या किसी भी संघीय प्रवाह-डाउन शर्तों के साथ एक प्रस्तावित अनुबंध टेम्पलेट शामिल है, जो आवश्यक हो सकता है। आपूर्तिकर्ताओं से उन सभी अपवादों को उजागर करने के लिए प्रस्तावित कॉन्ट्रैक्ट टेम्प्लेट को फिर से लाइन करने के लिए कहा जाना चाहिए, जिनसे वे सहमत नहीं हो सकते। सप्लायर को इस समय लायबिलिटी क्लॉज़ को फिर से लाइन नहीं करना चाहिए।

वे बाद में बातचीत के दौरान पहली बार समस्याएँ या टिप्पणियां दे सकते हैं। प्रस्ताव मूल्यांकन की अवधि के दौरान शोस्टॉपर की समस्याओं को पहचानें क्योंकि ऐसा सप्लायर चुनना संभव है जो एजेंसी का कॉन्ट्रैक्ट स्वीकार नहीं करेगा।

11

सप्लायर सेक्शन (वैकल्पिक)

आपूर्तिकर्ताओं को वह जानकारी शामिल करने की अनुमति देता है जो उन्हें लगता है कि प्रासंगिक है, हालांकि आवश्यक नहीं है या RFP में अनुरोध नहीं किया गया है। वे उन संभावित समस्याओं के बारे में भी चर्चा कर सकते हैं जो RFP और उनके प्रस्ताव के लिए प्रासंगिक हैं। उदाहरण के लिए, किसी सप्लायर के पास ऐसी अतिरिक्त प्रॉडक्ट सुविधाएँ हो सकती हैं, जो यह दर्शाती हैं कि वे RFP के दायरे से बाहर हैं, एक अनोखा समाधान पेश करती हैं जिसका खरीदार को अनुमान नहीं था, या वह RFP में ऐसी समस्या का समाधान प्रदान कर सकती है जिस पर अन्य आपूर्तिकर्ता विचार नहीं करते थे। भले ही यह विशेष आपूर्तिकर्ता जीत न DOE , फिर भी समस्या का स्पष्टीकरण और संभावित समाधान पर विचार करना उचित होगा।

12

अपेंडिस

इसमें भारी लेकिन ज़रूरी जानकारी शामिल है जैसे कि नेटवर्क डायग्राम, तकनीकी ज़रूरतों से जुड़े अध्ययन, प्रोजेक्ट प्लान की रूपरेखा और दूसरी जानकारी। उदाहरणों में यह शामिल है:

• आंकड़ों के साथ स्प्रैडशीट
• संचार नेटवर्क के चित्र और
• मौज़ूदा की सूची
• में इस्तेमाल किए जाने वाले मानक
• के साथ टेंटेटिव प्रोजेक्ट प्लान
• कॉन्ट्रैक्ट टेम्पलेट
• लघु व्यवसाय के लिए सब-कॉन्ट्रैक्टिंग प्लान फ़ॉर्म
• में कारोबार करने के लिए रजिस्टर किए गए स्टेट कॉर्पोरेशन कमीशन फ़ॉर्म को सप्लायर द्वारा पूरा किया गया

इसके बाद यह सूचना आपूर्तिकर्ता को उपलब्ध हो जाती है, लेकिन DOE RFP के वर्णनात्मक भाग से ध्यान नहीं भटकाना पड़ता। ध्यान दें: सप्लायर को बताएं कि क्या उन्हें अपने प्रस्ताव बनाते समय इस जानकारी का इस्तेमाल करना चाहिए।