आपका ब्राउज़र जावास्क्रिप्ट का समर्थन नहीं करता है!

अध्याय 8 - आवश्यकता का वर्णन - विनिर्देश और आवश्यकताएँ

8.8 आईटी प्रोक्योरमेंट का विश्लेषण करना और उसकी योजना बनाना

आम तौर पर, एजेंसी के व्यवसाय के स्वामी (अर्थात, परियोजना प्रबंधक) और तकनीकी विषय वस्तु विशेषज्ञों की एक टीम आवश्यकताओं की परिभाषा तैयार करेगी, लेकिन खरीद अधिकारी यह सुनिश्चित करना चाहेंगे कि आवश्यकताओं की योजना अच्छी तरह से बनाई गई है और वे कार्यक्षेत्र विवरण और कार्य विवरण में खरीद विवरण को परिभाषित करने के लिए पर्याप्त हैं (अध्याय 12, IT खरीद के लिए कार्य विवरण देखें)। याचना का दायरा और/या काम का विवरण ज़रूरतों की परिभाषा, विश्लेषण और योजना के नतीजों को दिखाएगा। नीचे एक टेबल दी गई है जिसमें कई उच्च-स्तरीय प्रश्न दिए गए हैं, जिन पर प्रोजेक्ट टीम को प्रोजेक्ट की ज़रूरतों की पहचान करते समय और उनकी योजना बनाते समय विचार करना पड़ सकता है। नीचे दी गई टेबल में एक जेनेरिक टूल दिया गया है। VITAके प्रौद्योगिकी कार्यक्रम निर्देशों के अनुरूप अधिक विस्तृत मार्गदर्शन निम्नलिखित वेबसाइट पर पाया जा सकता है: https://www.vita.virginia.gov/policy--governance/project-management/project-management-templates-tools/.

 

1

प्रोजेक्ट के मुख्य उद्देश्य/ लक्ष्य क्या हैं?

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

2

प्रोजेक्ट के द्वितीयक उद्देश्य/ लक्ष्य क्या हैं?

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

3

परियोजना को सबसे कम क्या DOE ?

इस प्रोक्योरमेंट में सभी अनावश्यक तत्वों का मूल्यांकन करने में ईमानदार रहें, संभवत: प्रश्नों 1 और 2 के नतीजों को हटाकर उन्हें प्रश्न 12 पर ले जाएं।

4

मौजूदा परिवेश क्या है?

मौजूदा तकनीकी और यूज़र परिवेश का टेक्स्ट और ग्राफ़िक विवरण तैयार करें, जिसमें कर्मचारी, अन्य प्रोग्राम, एजेंसियां/संस्थाएं और प्रभावित सेवाएँ शामिल हैं।

5

कौनसी डिपेंडेंसी मौजूद हैं या हो सकती हैं?

अन्य आंतरिक और बाह्य नेटवर्क, सर्वर, अनुप्रयोग और/या प्रणाली, इंटरफेस और विरासत प्रणालियों का विवरण प्रदान करें जो इस खरीद से प्रभावित होंगे, जिसमें अन्य एजेंसियां/संस्थाएं/उपयोगकर्ता और VITA भागीदारी शामिल हैं।

6

क्या यह ख़रीदारी एजेंसी- विशिष्ट और कॉमनवेल्थ की रणनीतिक नीति के अनुरूप है

योजना बना रहे हैं?

अपनी खुद की एजेंसी या कॉमनवेल्थ की अल्पकालिक या लंबी अवधि की एंटरप्राइज़ रणनीतियों या अन्य उद्देश्यों के साथ इस प्रोक्योरमेंट से होने वाले किसी भी सीधे या संभावित टकराव को पहचानें। इस सवाल में मदद के लिए अपने मौजूदा AITR से संपर्क करें।

7

घर में क्या किया जा सकता है?

प्रश्न 1 और 2 पर फिर से जाएं और मौजूदा स्टाफ़ या भूमिकाओं को विस्तृत उद्देश्यों के अनुसार मिलाएं।

8

एजेंसी को बाहरी स्रोतों से DOE खरीदना होगा?

जवाबों में सभी हार्डवेयर, सॉफ़्टवेयर (COTS और/या हाल ही में बनाए गए), सहायता सेवाएँ, कार्यान्वयन, डिज़ाइन, इंटरफ़ेस डेवलपमेंट, प्रशिक्षण, रखरखाव आदि शामिल होने चाहिए। मौजूदा राज्यव्यापी कॉन्ट्रैक्ट की खोज ज़रूर करें, जो इनमें से कुछ या सभी ज़रूरतों को पूरा कर सकते हैं: (https://vita.cobblestonesystems.com/public/)।

9

बजट क्या होता है?

प्रोजेक्ट के निश्चित और अनुमानित बजट स्रोतों और समय को परिभाषित करें। साल भर की सहायता और रखरखाव और किसी भी चरणबद्ध ख़रीदारी गतिविधि, और/या फ़ेडरल फ़ंडिंग के लिए बजट स्रोत शामिल करें।

10

अंदरूनी अनुमान क्या है?

आपके अनुमान के आधार पर इस्तेमाल करने के लिए वर्क ब्रेकडाउन स्ट्रक्चर विकसित करने का सुझाव दिया जाता है, क्योंकि इससे प्रोक्योरमेंट दस्तावेज़ों की ज़रूरतों और/या काम के हिस्सों के विवरण (यानी, अनुरोध और अनुबंध) का पता चल सकता है। यह तरीका यह पक्का करने में भी मदद करता है कि प्रोजेक्ट के जीवन चक्र की सभी बातों पर विचार किया जाए और इससे प्रस्तावों का मूल्यांकन करते समय उन्हें सही ठहराया जा सकता है।

11

शेड्यूल क्या है?

किसी भी तकनीकी निर्भरता से जुड़ी समस्याओं और बजट खर्च (और सप्लायर से भुगतान) की योजना बनाने के लिए इस्तेमाल किए जाने वाले किसी भी मुश्किल और सॉफ्ट प्रोजेक्ट शेड्यूल की पहचान करें—समग्र और महत्वपूर्ण इवेंट।

12

हम क्या ख़रीदना बंद कर सकते हैं?

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

13

हमारे जोखिम क्या हैं?

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

14

कौनसे स्पेसिफिकेशन्स और मानक लागू होने चाहिए?

एक दस्तावेज बनाएं जिसमें नाम, संख्या, संस्करण आदि सूचीबद्ध हों, तथा यदि उपलब्ध हो तो सभी एजेंसी-विशिष्ट, राष्ट्रमंडल, VITA और/या संघीय (यदि संघीय अनुदान लागू हो) विनिर्देशों और मानकों के लिंक उपलब्ध हों, जो खरीदे जा रहे सभी समाधानों, सेवाओं और/या उत्पादों के लिए उचित अनुबंध निष्पादन के लिए आवश्यक हैं।

15

क्या यह उच्च जोखिम वाला कॉन्ट्रैक्ट है जैसा कि कोड ऑफ़ वर्जीनिया § 2.2- 4303.01 के अनुसार परिभाषित किया गया है?

2.2-4303.01 “हाई रिस्क कॉन्ट्रैक्ट” को वस्तुओं, सेवाओं, बीमा या निर्माण की ख़रीद के लिए राज्य के सार्वजनिक निकाय के साथ किसी भी सार्वजनिक अनुबंध के रूप में परिभाषित करता है, जिसकी अनुमानित लागत (i) कॉन्ट्रैक्ट की शुरुआती अवधि में $10 मिलियन से अधिक या (ii) कॉन्ट्रैक्ट की शुरुआती अवधि में $5 मिलियन से अधिक की लागत और निम्न में से कम से कम एक मानदंड को पूरा करना होगा: (क) सामान, सेवाएँ, बीमा, या निर्माण जो कि कॉन्ट्रैक्ट का विषय है, दो या दो से ज़्यादा राज्य सार्वजनिक निकायों द्वारा ख़रीदा जा रहा है; (ख) शुरुआती कॉन्ट्रैक्ट की प्रत्याशित अवधि, नवीनीकरण को छोड़कर, पांच साल से अधिक है; या (सी) सामान, सेवाएँ, बीमा या निर्माण ख़रीदने वाली राज्य की सार्वजनिक संस्था ने पिछले पांच सालों में इसी तरह के सामान, सेवाएँ, बीमा या निर्माण नहीं ख़रीदा है।

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

16

क्या आपने यह सुनिश्चित किया है कि आपके परफ़ॉर्मेंस स्पेसिफिकेशन्स में अलग और मापने योग्य परफ़ॉर्मेंस मेट्रिक और स्पष्ट प्रवर्तन प्रावधान शामिल हों?

सभी खरीद जो वर्जीनिया संहिता की धारा 2.2-4303.01 में परिभाषित “उच्च जोखिम” की परिभाषा को पूरा करती हैं, उनमें सभी उच्च जोखिम वाले IT निवेदनों और IT वस्तुओं और सेवाओं के अनुबंधों में गैर-निष्पादन के मामले में उपायों सहित स्पष्ट और अलग प्रदर्शन उपाय और प्रवर्तन प्रावधान शामिल होने चाहिए। VITAका अनुबंध जोखिम प्रबंधन समूह प्रत्येक उच्च जोखिम IT निवेदन और अनुबंध की समीक्षा करेगा और अनुरोधकर्ता एजेंसी से परामर्श करेगा कि उच्च जोखिम IT निवेदन और/या अनुबंध को धारा 2.2-4303.01 के अनुरूप बनाने के लिए क्या कदम उठाए जाने की आवश्यकता है। ज़्यादा जानकारी के लिए, कृपया scminfo@vita.virginia.gov पर संपर्क करें

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


वर्तमान अध्याय: अध्याय 8 - ज़रूरत के बारे में बताना -
खास जानकारी और आवश्यकताएँ पिछला < | > अगला

कीवर्ड या सामान्य शब्द के आधार पर मैनुअल में खोजें।