12.2 काम का गुणवत्तापूर्ण आईटी स्टेटमेंट तैयार करना (SOW)
प्रोजेक्ट स्कोप पूरा हो जाने के बाद, प्रोजेक्ट टीम एसओडब्ल्यू तैयार करेगी, जो सप्लायर के प्रस्ताव पर प्रतिक्रिया और कॉन्ट्रैक्ट परफॉरमेंस का आधार होता है। सॉलिसिटेशन में एसओडब्ल्यू शामिल करने से प्रत्येक सप्लायर को वह जानकारी मिलती है जिससे उसे ऑफ़र तैयार किया जाता है। चूंकि विजेता सप्लायर एसओडब्ल्यू की ज़रूरतों का पालन करते हुए कॉन्ट्रैक्ट पूरा करेगा, इसलिए एसओडब्ल्यू में सभी तकनीकी, कार्यात्मक, परफ़ॉर्मेंस और प्रोजेक्ट प्रबंधन से जुड़ी ज़रूरतों और अपेक्षाओं को स्पष्ट रूप से और बिना किसी अस्पष्टता के शामिल करना और बताना ज़रूरी है। VITA SCM अधिकृत उपयोगकर्ताओं के लिए SOW टेम्पलेट और SOW परिवर्तन आदेश टेम्पलेट प्रदान करता है, जिसका उपयोग वे इस स्थान पर VITA राज्यव्यापी अनुबंध से ऑर्डर करते समय "टूल्स:" नामक अनुभाग के अंतर्गत कर सकते हैं। https://www.vita.virginia.gov/procurement/policies--procedures/procurement-tools/। यह टेम्प्लेट और इस अध्याय में दिए गए मार्गदर्शन, अभ्यास के लिए सबसे अच्छे सुझाव हैं। आप टेम्प्लेट, नीचे दिए गए मार्गदर्शन या किसी भी कॉम्बिनेशन का इस्तेमाल कर सकते हैं—जो आपकी ख़रीदारी के आकार और जटिलता के हिसाब से सबसे उपयुक्त है। जिन IT परियोजनाओं के लिए CIO अनुमोदन और/या VITA निरीक्षण की आवश्यकता होती है, उन्हें इस यूआरएल पर दिए गए राष्ट्रमंडल परियोजना प्रबंधन मानकों और नीतियों का पालन करना होगा: https://www.vita.virginia.gov/policy--governance/project-management/project-management-division-pmd/।
एसओडब्ल्यू को एक संक्षिप्त, घोषणात्मक दस्तावेज़ के रूप में लिखा जाना चाहिए, क्योंकि यह एजेंसी की ज़रूरतों और आपूर्तिकर्ता की प्रदर्शन की प्रतिबद्धता का विवरण होता है। ग़ैर-प्रदर्शन पर आधारित SOWs में सप्लायर को विस्तृत विशिष्टताओं का इस्तेमाल करते हुए, उपलब्ध कराए जाने वाले प्रमुख कर्मियों को निर्दिष्ट करने और सेवा अनुबंधों के लिए इस्तेमाल किए जाने वाले तरीकों का इस्तेमाल करते हुए, एक खास तरीके से काम करने की आवश्यकता हो सकती है। एक अच्छी तरह से लिखे गए SOW को चाहिए:
- स्टैंड-अलोन डॉक्यूमेंट बनें।
- सामान्य से खास तरीके से तैयार किए जाएं।
- ज़रूरतों की परिभाषा के नतीजों और मंज़ूर किए गए स्कोप स्टेटमेंट के मुताबिक दी गई जानकारी का विस्तार करें और इसमें कोई गड़बड़ी और/या परस्पर विरोधी ज़रूरतें न हों।
- परफ़ॉर्मेंस की अवधि, डिलीवर करने योग्य आइटम, यदि कोई हो, और परफ़ॉर्मेंस के लचीलेपन की वांछित डिग्री के हिसाब से व्यक्तिगत रूप से तैयार रहें।
- ऐसी सामग्री को बार-बार न दोहराएं जो सॉलिसिटेशन/कॉन्ट्रैक्ट के अन्य हिस्सों में पहले से ही शामिल है।
- नीचे दिए गए चार तत्वों को हल करके सप्लायर को क्या हासिल करना है, इसके बारे में विस्तार से बताएं:
- क्या किया जाना चाहिए और डिलीवरेबल/माइलस्टोन क्या हैं?
- कौन क्या करने वाला है (एजेंसी, सप्लायर, थर्ड पार्टी CoVA एजेंट, वगैरह)।
- डिलीवरेबल और/या माइलस्टोन से यह कब किया जाएगा?
- यह कहाँ किया जाएगा?
- यह कैसे किया जाएगा और एजेंसी को कैसे पता चलेगा कि यह कब हो गया है (यानी, परीक्षण और स्वीकृति)?
SOW सामग्री और जानकारी खरीद की प्रकृति पर निर्भर करेगी और इसमें बेहद सरल—पैक किए गए सॉफ़्टवेयर ख़रीदना—से लेकर बेहद जटिल—समाधान खरीदना या सिस्टम डिज़ाइन शामिल हो सकता है। ज़रूरतों का आकलन/ज़रूरतों की परिभाषा/विशिष्टताओं के विकास के बारे में जानकारी (देखें) अध्याय 8) एसओडब्ल्यू के कुछ प्रासंगिक क्षेत्रों में डुप्लीकेट बनाया जाना चाहिए। सभी SOWs में कम से कम निम्नलिखित घटक शामिल होने चाहिए:
- परिचय—प्रोक्योरमेंट का सामान्य विवरण।
- बैकग्राउंड—ऐसी जानकारी जो सप्लायर को एजेंसी की प्रकृति और इतिहास, प्रोजेक्ट, दर्शकों को दी जा रही सेवा और नई ज़रूरतों के मकसद को समझने में मदद करती है। जब लागू हो, तो मौजूदा और पसंदीदा तकनीकी वातावरण (आर्किटेक्चर) और ग्राफ़िक और टेक्स्ट के बारे में जानकारी वाले इंटरफेस शामिल करें।
- स्कोप—स्कोप स्टेटमेंट से लिया गया SOW का अवलोकन, जो मापदंडों और आवश्यकताओं के महत्वपूर्ण पहलुओं से संबंधित है।
- लागू निर्देश (अगर कोई हो) —संदर्भित दस्तावेज़, मानक, विनिर्देश या निर्देश जो या तो खरीद के लिए अनिवार्य या जानकारी के लिए हैं।
- परफ़ॉर्मेंस की आवश्यकताएँ—क्या पूरा करना ज़रूरी है, प्रदर्शन के मानक और गुणवत्ता के स्वीकार्य स्तर।
- डिलीवर करने योग्य आवश्यकताएँ—टेक्नोलॉजी उत्पाद, सेवाएँ, सॉफ़्टवेयर, प्रोजेक्ट और दूसरी रिपोर्ट, परीक्षण और सभी डिलिवरेबल्स और औपचारिक ज़रूरतें जो कॉन्ट्रैक्ट के दौरान सप्लायर द्वारा सबमिट की जानी चाहिए।
- क्वालिटी एश्योरेंस और स्वीकार्यता मापदंड—स्वीकार्यता एजेंसी की औपचारिक, लिखित प्रक्रिया है, ताकि यह स्वीकार किया जा सके कि डिलिवरेबल्स कॉन्ट्रैक्ट की लागू गुणवत्ता, मात्रा और अन्य आवश्यकताओं के अनुरूप हैं। स्वीकृति में क्वालिटी आश्वासन प्रोसेस शामिल हो भी सकते हैं और नहीं भी, और आमतौर पर भुगतान से पहले किया जाता है। किसी भी माइलस्टोन डिलीवरी के लिए औपचारिक स्वीकृति की प्रक्रिया प्रदान की जानी चाहिए, साथ ही उसे अंतिम स्वीकृति भी दी जानी चाहिए।
नीचे एक व्यापक सूची दी गई है, जो SOW सामग्री के लिए सरल से लेकर जटिल खरीद तक के लिए विचारों का चयन प्रदान करती है - एकल IT घटक से लेकर प्रमुख सिस्टम डिजाइन तक। प्रोजेक्ट टीम को इस सूची से उपयोगी रिमाइंडर मिल सकते हैं, भले ही वे सभी किसी ख़ास ख़रीदारी के लिए सही न हों। पूरी जानकारी और सटीकता पक्की करने के लिए ज़रूरत के परिभाषा दस्तावेज़ से ली जा सकती है।
प्रोजेक्ट के आकार, जटिलता, डेलिगेशन और मंज़ूरी की सीमाओं के आधार पर, बिज़नेस के मालिक को यह पक्का करना होगा कि वह इस यूआरएल पर मौजूद SOWs बनाने के लिए कॉमनवेल्थ प्रोजेक्ट मैनेजमेंट के सभी मानकों और ज़रूरतों का अनुपालन करे: https://www.vita.virginia.gov/policy--governance/project-management/project-management-division-pmd/।
|
परिचय |
यह प्रोक्योरमेंट का सामान्य विवरण है। |
|
बैकग्राउंड |
एजेंसी, प्रोजेक्ट/प्रोग्राम और/या इस खरीद से प्रभावित होने वाली सेवाओं के बारे में जानकारी दें। यूज़र एनवायरनमेंट के ग्राफ़िक्स/जानकारी के फ्लो/मौजूदा बिज़नेस और ऑपरेटिंग एनवायरनमेंट का ग्राफ़िक्स शामिल करें। |
|
स्कोप स्टेटमेंट |
इस प्रोसेस के चरण 2 में तैयार किए गए स्कोप स्टेटमेंट से पीछे हटें। |
|
तकनीकी, फ़ंक्शनल और परफ़ॉर्मेंस का सारांश ऑब्जेक्टिव (ओं) |
इन उद्देश्यों के बारे में सामान्य जानकारी दें। |
|
तकनीकी जानकारी का सारांश, फंक्शनल और परफॉरमेंस से जुड़ी आवश्यकताएँ |
इन ज़रूरतों का सामान्य विवरण दें, जिसमें सभी ज़रूरी समाधान, उत्पाद और/या सेवाएँ शामिल हैं। |
|
खास तकनीकी, फंक्शनल और परफॉरमेंस से जुड़ी ज़रूरतें |
खास और विस्तृत आवश्यकताओं के बारे में पूरी जानकारी दी जानी चाहिए और अगर जानकारी हो, तो उसमें वांछित एजेंसी ऑपरेटिंग आर्किटेक्चर/यूज़र एनवायरनमेंट शामिल करना चाहिए। अगर सप्लायर इसे अपने प्रस्ताव के हिस्से के तौर पर देगा, तो इन ज़रूरतों पर बातचीत की जाएगी और कॉन्ट्रैक्ट की पक्की एसओडब्ल्यू प्रदर्शनी के तौर पर उन्हें अंतिम रूप दिया जाएगा। इनमें सभी सॉफ़्टवेयर और हार्डवेयर, समाधान और/या ख़रीदे जा रहे सिस्टम और इससे जुड़ी सभी सेवाओं के लिए सभी तकनीकी और कार्यात्मक ज़रूरतें शामिल होंगी। अगर ज़रूरतों का विकास/सिस्टम डिज़ाइन डिलीवर किया जा सकता है, तो इसे अंतिम रूप देने, लागू करने और परीक्षण से पहले अंतिम रूप दिया जाएगा और इसके तहत इसे अलग से डिलीवर किया जा सकता है SOW. |
|
आवश्यकताएँ विकसित करना |
अगर यह सप्लायर द्वारा किए जाने वाले कामों का हिस्सा है, तो प्रोजेक्ट के माइलस्टोन शेड्यूल और डिलीवरेबल्स लिस्टिंग में संदर्भ बताएं और शामिल करें। |
|
कस्टम डेवलपमेंट और टेस्ट सिस्टम का माहौल |
पिछले आइटम की तरह ही |
|
बिज़नेस डिज़ाइन और टेक्निकल डिज़ाइन |
पिछले आइटम की तरह ही |
|
इंटरफ़ेस/ इंटीग्रेशन/लिगेसी सिस्टम आवश्यकताएँ |
पिछले आइटम की तरह ही। अनुरोध से इनके बारे में सारी जानकारी मिलनी चाहिए, ताकि सप्लायर किसी दृष्टिकोण का पर्याप्त अनुमान लगा सकें और उनका प्रस्ताव रख सकें और इन आवश्यकताओं को अंतिम कॉन्ट्रैक्ट के एसओडब्ल्यू, माइलस्टोन शेड्यूल और डिलिवरेबल्स की सूची में शामिल किया जाना चाहिए। |
|
डेटा कन्वर्ज़न |
एजेंसी को उस डेटा की स्थिति के बारे में जानना चाहिए और उसे फिर से बताना चाहिए, जिसके लिए कन्वर्ज़न ज़रूरी है। आमतौर पर, यह ज़्यादा लागत और/या परफ़ॉर्मेंस से जोखिम उठाने की संभावना वाला क्षेत्र हो सकता है। |
|
सामग्री का बिल |
सॉफ़्टवेयर और हार्डवेयर के सभी कंपोनेंट्स और डिलीवरी की अपेक्षित तारीखों की सूची दें |
|
परीक्षण किया जा रहा है |
किसी भी इंस्टॉलेशन, कॉन्फ़िगरेशन, सिस्टम, फ़ंक्शनल, प्रॉडक्ट, बीटा/प्रोडक्शन टेस्टिंग और फ़ाइनल एक्सेप्टेंस टेस्टिंग के लिए ज़रूरी शर्तें शामिल करें। जीवन में सच्ची परीक्षा लेने के लिए परीक्षण की अवधि और वातावरण को ध्यान से देखें। |
|
स्वीकार्यता मानदंड और स्वीकार्यता प्रक्रिया |
पेपर रिपोर्ट से लेकर सिस्टम के अंतिम टर्नओवर तक, सभी डिलिवरेबल्स के लिए खास स्वीकार्यता मानदंड शामिल करें। एजेंसी की मंज़ूरी का समय तय करना, सप्लायर द्वारा फिर से सबमिट करने का समय वगैरह तय करना उचित है। पक्का कर लें कि यहाँ और/या असल अनुबंध की भाषा में कोई परस्पर विरोधी जानकारी न दी गई हो। |
|
जोखिम प्रबंधन की प्रक्रिया |
ख़रीद की जटिलता के आधार पर मॉनिटरिंग/रिपोर्टिंग के लिए कॉन्ट्रैक्ट की अवधि और फ़्रीक्वेंसी और जोखिम क्षेत्रों (लागत, शेड्यूल, डिज़ाइन/डेवलपमेंट, इंटरफ़ेस, आदि) के लिए लिखित आवश्यकताएं/प्रक्रियाएँ शामिल करें। लिखित रिपोर्ट/डिलिवरेबल्स की ज़रूरत भी हो सकती है। सप्लायर के दिवालिया होने या कारोबार की निरंतरता में रुकावट आने की स्थिति में सप्लायर सॉफ़्टवेयर के चल रहे इस्तेमाल को सुरक्षित रखने के लिए एस्क्रो अकाउंट बनाना भी ज़रूरी हो सकता है। |
|
क्वालिटी कंट्रोल/आश्वासन से जुड़ी ज़रूरतें |
सप्लायर द्वारा क्वालिटी कंट्रोल, एजेंसी द्वारा क्वालिटी आश्वासन और मॉनिटरिंग या किसी स्वतंत्र IV & V संसाधन की सभी ज़रूरतों के बारे में बताएं, जिसमें सभी ज़रूरी प्लान, शेड्यूल की गई रिपोर्टिंग और मेट्रिक्स कैप्चर/वैलिडेशन कैसे और कब किया जाता है, इसके बारे में जानकारी शामिल है। देखें अध्याय 21 परफ़ॉर्मेंस पर आधारित कॉन्ट्रैक्ट और सेवा स्तर के एग्रीमेंट की पूरी चर्चा के लिए इस मैनुअल का इस्तेमाल किया गया है। |
|
Configuration/change management/engineering फ़ैसले का पता लगाने की योग्यता से जुड़ी ज़रूरी शर्तें |
एजेंसी के संचालन में स्वतंत्रता बनाए रखने और भविष्य में संदर्भ के लिए ऐतिहासिक अनुभव हासिल करने के लिए सभी आवश्यक स्कीमैटिक्स, इंजीनियरिंग ड्रॉइंग, प्लान, दस्तावेज़ों और अन्य ट्रैसेबिलिटी डिलिवरेबल्स का विवरण/सूची बनाएं/सूचीबद्ध करें। |
|
प्रोजेक्ट प्रबंधन से जुड़ी ज़रूरतें |
ख़रीद की जटिलता के आधार पर, ये ज़रूरतें आसान या गंभीर हो सकती हैं। प्रोजेक्ट प्रबंधन की ज़िम्मेदारियाँ एजेंसी और सप्लायर के बीच साझा की जा सकती हैं या सिर्फ़ एक पक्ष द्वारा निभाई जा सकती हैं; हालाँकि, यह साफ़ तौर पर बताया जाना चाहिए। प्रमुख परियोजनाओं तथा VITA निरीक्षण की आवश्यकता वाली परियोजनाओं के लिए कुछ राष्ट्रमंडल परियोजना प्रबंधन मानकों की आवश्यकता हो सकती है। |
|
प्रशिक्षण और दस्तावेजीकरण से जुड़ी ज़रूरतें |
इसमें एजेंसी के बजट के हिसाब से ऑफ़साइट या ऑनसाइट ट्रेनिंग शामिल हो सकती है। इसमें प्रतिभागियों की संख्या, स्थान, पूरी की जाने वाली ट्रेनिंग का प्रकार और ट्रेनर की अगुवाई वाले, ट्रेनर को प्रशिक्षित करने, क्लासरूम, कंप्यूटर या वेब से जुड़ी सारी जानकारी शामिल करें-आधारित, आदि। |
|
मीटिंग/समीक्षाएं (डिज़ाइन करना/प्रोजेक्ट स्थिति/समीक्षाएं) |
प्रोजेक्ट नियंत्रण के लिए और प्रोजेक्ट की ईमानदारी और जवाबदेही बनाए रखने के लिए इस्तेमाल करें। सप्लायर से मिलने की आवश्यकता हो भी सकती है और नहीं भी; हालाँकि, अगर वे हैं तो वे अपनी कीमत में यात्रा को शामिल करेंगे। वर्जीनिया डिपार्टमेंट ऑफ़ अकाउंट्स के हर दिन के नियम लागू होते हैं। |
|
रखरखाव और विश्वसनीयता और/या सहायता और रखरखाव से जुड़ी ज़रूरतें |
वारंटी के दौरान और अनुबंध में शामिल किए गए बजट के अनुसार किसी भी पुराने साल के लिए रखरखाव और सहायता के लिए सभी ज़रूरतों को शामिल करें। संबंधित सहायता सेवाएँ आम तौर पर सप्लायर की सामान्य कमर्शियल ऑफ़र पर आधारित होंगी, जब तक कि अन्यथा बातचीत न की गई हो। |
|
प्रदर्शन/फ़ंक्शनैलिटी से जुड़ी ज़रूरतें |
इसमें फॉल्ट आइसोलेशन, न्यूनतम सहनशीलता मापदंड, विफलताओं के बीच का समय, पर्यावरण की स्थिति आदि शामिल करें। सेवा स्तर की अपेक्षाएं और उन्हें पूरा करने के लिए प्रोत्साहन शामिल किए जा सकते हैं और उन पर नजर रखी जा सकती है, ताकि सफल प्रदर्शन को प्रोत्साहित करने के लिए सप्लायर को पूरा भुगतान किया जा सके या निर्धारित प्रतिशत में कटौती की जा सके। |
|
कॉन्ट्रैक्ट डिलिवरेबल्स |
सभी हार्डवेयर, सॉफ़्टवेयर, सिस्टम/सॉल्यूशन, और पेपर डिलिवरेबल्स जैसे कि QA/QC प्लान, कॉन्फ़िगरेशन कंट्रोल प्लान, टेस्ट प्लान, IV & V प्लान/रिपोर्ट, मासिक स्टेटस रिपोर्ट, जोखिम मूल्यांकन प्लान, प्रोजेक्ट/माइलस्टोन प्लान, GANTT, आदि की सूची बनाएं। देय तारीख, मात्रा, कोई भी ज़रूरी फ़ॉर्मेट, मीडिया शामिल करें (पेपर, इलेक्ट्रॉनिक, सीडी, डीवीडी, आदि), जब देय हो, तो किसको/कहाँ सबमिशन करना है, डेज़ एजेंसी को समीक्षा करना/स्वीकार करना पड़ता है। |
|
मानक/विशिष्टताएं/ निर्देश |
सभी आवश्यक एजेंसी/VITA/सीओवीए/संघीय, वाणिज्यिक या उद्योग, एसईआई प्रक्रिया, IT पहुंच/508के लिए मानक शामिल करें अनुपालन, HIPAA, पर्यावरण, पैकेजिंग, आकार, फ़ॉर्मेट इत्यादि, और बताएँ कि क्या ये देखने के लिए उपलब्ध हैं या अटैचमेंट के रूप में शामिल हैं। किसी भी बेसलाइन ड्रॉइंग या स्पेक्स, तकनीकी शब्दों की शब्दावली, संगठनात्मक चार्ट आदि को ज़रूर शामिल करें, ध्यान रखें कि इस यूआरएल पर स्थित कॉमनवेल्थ के प्रासंगिक मानकों को नज़रअंदाज़ न करें या उन्हें बाहर न करें: https://www.vita.virginia.gov/it-governance/itrm-policies-मानक/ |
|
सरकार या सप्लायर के प्रावधान |
कोई भी उपकरण, सुविधाएं, सामग्री और संसाधन बताएँ, जो कॉमनवेल्थ द्वारा सप्लायर को उपलब्ध कराया जाएगा या कॉन्ट्रैक्ट परफ़ॉर्मेंस के लिए इसका विपरीत। उपलब्ध कराने की तारीखें, ट्रांसमिटल से जुड़ी ज़रूरतें और रिटर्न की प्रक्रिया शामिल करें। |
|
प्रोजेक्ट शेड्यूल की आवश्यकताएं/प्रदर्शन की अवधि |
अपेक्षित या निश्चित तारीखों (कैलेंडर या “अवार्ड के बाद के दिन”) के साथ, पूरी अवधि और माइलस्टोन शेड्यूल दें (या सप्लायर से प्रस्तावित शेड्यूल का अनुरोध करें, जिसे किसी भी कॉन्ट्रैक्ट में शामिल किया जाएगा)। परफ़ॉर्मेंस स्टेटस को सबसे अच्छे से मॉनिटर करने के लिए प्रोजेक्ट प्लानिंग और माइलस्टोन को सबसे निचले स्तर पर ले जाएं। किसी भी प्रोजेक्ट पर निर्भर रहने पर विचार करें, जो मील के पत्थर और पूरे शेड्यूल को प्रभावित कर सकती है। |
|
परफ़ॉर्मेंस का स्थान |
अगर आपूर्तिकर्ता के स्थान के अलावा, ऑफ़साइट परिसर में स्थान और समय का प्रतिशत बताएं; सप्लायर के लिए मीटिंग अटेंडेंस शामिल करें। यदि प्रदर्शन VITA में होगा या अन्य अधिकृत यूज़र लोकेशन, अटेंडेंस, बैकग्राउंड चेक, ऑफ़िस ऐक्सेस आदि की अपेक्षाओं के बारे में खास जानकारी रखें। |
|
कर्मचारियों के लिए विशेष/प्रमुख आवश्यकताएँ |
अगर सप्लायर को मुख्य कर्मियों को रिज्यूमे उपलब्ध कराने के अनुरोध में कोई आवश्यकता है, तो अनुबंध अवधि के दौरान किसी भी प्रतिस्थापन के लिए एजेंसी की लिखित स्वीकृति की आवश्यकता के साथ अंतिम बातचीत की गई एसओडब्ल्यू में इन व्यक्तियों का नाम लिया जा सकता है। इसके बाद, सॉलिसिटेशन में यह सारी भाषा शामिल करें। अगर कुछ कर्मचारी प्रोजेक्ट की सफलता के लिए महत्वपूर्ण हैं, तो उन्हें खास तौर पर नाम दें और बताएं कि उन्हें कैसे बदला जाएगा और वे किसी भी कारण से प्रोजेक्ट को कब छोड़ देंगे। |
|
कीमत निर्धारण का प्रकार |
यह पहचानें कि प्रदर्शन समय & सामग्री और/या निश्चित मूल्य पर आधारित होगा; हालांकि, असली कीमत शेड्यूल कॉन्ट्रैक्ट का एक स्टैंड-अलोन एग्ज़िबिट होगा। |
|
संपर्क का तकनीकी बिंदु |
नामित प्रोजेक्ट मैनेजर और/या तकनीकी प्रतिनिधियों के नाम और संपर्क जानकारी दें, कॉन्ट्रैक्ट परफ़ॉर्मेंस के दौरान ज़रूरत पड़ने पर कॉन्ट्रैक्ट में संशोधन करके अपडेट करें। |
|
किसी खास वारंटी से जुड़ी ज़रूरतें |
पक्का कर लें कि ये कॉन्ट्रैक्ट दस्तावेज़ में कहीं और रखी गई किसी भी सामान्य वारंटी शर्तों की नकल न करें। |
|
सुरक्षा और/या ऐक्सेस से जुड़ी ज़रूरतें |
सभी एजेंसी/VITA/कॉमनवेल्थ भौतिक पहुंच और डेटा पहुंच (हार्डकॉपी और इलेक्ट्रॉनिक) और होस्टिंग आवश्यकताओं को शामिल करें। VITA सुरक्षा आवश्यकताएँ इस वेबसाइट पर स्थित हैं: https://www.vita.virginia.gov/it-governance/itrm-नीतियाँ-मानक/ और यदि IT खरीद के लिए लागू हो तो इसका संदर्भ एसओडब्ल्यू में शामिल किया जाना चाहिए। इनमें से किसी भी आवश्यकता को पूरा करने के लिए अपने VITA AITR/परियोजना प्रबंधन प्रतिनिधियों के साथ इस संबंध में बातचीत करना महत्वपूर्ण है। |
|
एंटरप्राइज़ क्लाउड ओवरसाइट (ECOS) आवश्यकताएँ |
इस SOW को जारी करने के लिए उपयोग किए जा रहे VITA राज्यव्यापी अनुबंध की जांच करें। अगर यह है नहीं क्लाउड सेवा या सॉफ्टवेयर ऐज़ अ सर्विस (SaaS) अनुबंध और DOE नहीं आवश्यक क्लाउड/SaaS शर्तें शामिल करें, या यदि अनुबंध का दायरा DOE नहीं अधिकृत करें और उत्पाद सूची DOE नहीं SaaS प्रॉडक्ट शामिल करें, संपर्क करें scminfo@vita.virginia.gov अगले चरणों का पता लगाने के लिए आगे जाने से पहले। यदि अनुबंध DOE में आवश्यक क्लाउड/SaaS शर्तें शामिल हैं, तो यह निर्धारित करने के लिए कि क्या विशेष SaaS उत्पाद ECOS अनुमोदित है या नहीं और अगले कदम निर्धारित करने के लिए enterpriseservices@vita.virginia.gov से संपर्क करें। |
कीवर्ड या सामान्य शब्द के आधार पर मैनुअल में खोजें।