अध्याय 25 - आईटी अनुबंध निर्माण

25.4। 2 सफल आईटी कॉन्ट्रैक्ट के लिए सामान्य दिशा-निर्देश

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

• आपूर्तिकर्ता अवास्तविक प्रतिबद्धताएं करता है (उदाहरण के लिए, परफ़ॉर्मेंस गारंटी, अप्राप्य शेड्यूल, ज़रूरी विश्लेषण के बिना निश्चित मूल्य के कॉन्ट्रैक्ट) या सप्लायर श्रम के समय, लागतों, जोखिमों को कम आंकते हैं।

• कॉन्ट्रैक्ट में कोई पक्की कॉन्ट्रैक्चुअल बेसलाइन नहीं है (जैसे, अस्पष्ट ज़रूरतें, नियम और शर्तें और काम के बारे में जानकारी)।

• आपूर्तिकर्ता को एजेंसी संबंध का प्रबंधन नहीं DOE (अर्थात, कार्य संबंध को लगातार बढ़ाया जाना चाहिए और समस्याओं को छिपाया नहीं जाना चाहिए)।

• अनुबंध DOE परिवर्तन के प्रबंधन के लिए कोई प्रक्रिया या प्रक्रिया शामिल नहीं है (अर्थात, कोई औपचारिक परिवर्तन प्रबंधन प्रक्रिया नहीं है)।

IT अनुबंध बनाते समय निम्नलिखित उद्योग सर्वोत्तम-अभ्यास विचारों का उपयोग किया जाना चाहिए:

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

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

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

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

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

• कीमत कॉन्ट्रैक्ट में हुए कुछ बदलावों के मुताबिक होनी चाहिए, उदाहरण के लिए, सेवाओं में बदलाव, वैकल्पिक सेवाएं और संशोधित या पूरा नहीं किया गया SLA। एक और अनुकूली कीमत मोडैलिटी में सब्सक्रिप्शन-आधारित सेवाएँ शामिल होंगी, जैसे कि सॉफ़्टवेयर में सेवा खरीद के तौर पर, जहाँ कीमत में पे-एज़-यू-गो मूल्य निर्धारण (या स्केलेबल मूल्य निर्धारण) को शामिल किया जाना चाहिए ताकि एजेंसियां केवल सेवा के यूज़र की वास्तविक संख्या के लिए ही भुगतान करें। अगर कॉन्ट्रैक्ट की कीमतें एक अवधि के लिए तय की जाती हैं, फिर कीमतें बढ़ती हैं, और कभी-कभी घट जाती हैं, तो विचार करने की ज़रूरत हो सकती है। एजेंसियों को महंगाई दर तक बढ़ोतरी को सीमित करना चाहिए और यहाँ तक कि इसमें एक अधिकतम सीमा भी शामिल करनी चाहिए; यानी, CPI का +/-3%।

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

• दोनों पक्षों को मुख्य शब्दों, शर्तों और गतिविधियों को साफ़ तौर पर और स्पष्ट रूप से परिभाषित करना चाहिए, जैसे कि " बीटा टेस्टिंग " का मतलब या यह निर्धारित करने के मानक कि एजेंसी ने सिस्टम को स्वीकार किया है या नहीं। IT जगत में, किसी प्रणाली को स्वीकार करना कई अलग-अलग समय पर हो सकता है, जैसे कि जब वह प्रणाली सहमत परीक्षणों ("स्वीकृति परीक्षण") की एक श्रृंखला से गुजर चुकी हो और बिना किसी गंभीर दोष के एक निश्चित अवधि तक प्रचालन में रही हो। अगर सभी पक्ष स्वीकार्यता को परिभाषित करने के लिए तैयार नहीं हैं, तो यह एक मजबूत चेतावनी संकेत है कि विवाद उत्पन्न हो सकता है। हालांकि, SLA बनाने की कोशिश से किसी भी साइनिंग, पेमेंट या डिलीवरी से पहले ही संभावित समस्याएं दूर हो सकती हैं।

• सभी समय के संदर्भ में खास तारीखें होनी चाहिए। " उचित समय " या " के फ़ौरन " के इस्तेमाल से बचें और कॉन्ट्रैक्ट के तहत हर पक्ष की ज़रूरतों के बारे में खास जानकारी रखें। यानी " तीन दिनों के भीतर (किसी समय; यानी, कॉन्ट्रैक्ट अवार्ड की तारीख)। "

• अगर अनुबंध में फ़ार्मुलों का इस्तेमाल किया जाता है, तो पक्का करें कि वे काम करें।

• हमारी संतुष्टि के हिसाब से तैयार ", " " जैसे अस्पष्ट संदर्भों का समयबद्ध तरीके से इस्तेमाल न करें, " " से यथोचित उम्मीद की जा सकती है। " यह निर्धारित करना मुश्किल होता है कि किसी सप्लायर " ने कब समयबद्ध तरीके से काम किया है। "

• " मटेरियलिटी " और " जैसे शब्दों का इस्तेमाल सिर्फ़ " से बचें, जब तक कि परिभाषाएं शामिल न हों।

• " होगा " (अनिवार्य) और " मई " (अनुमति वाला) शब्दों का इस्तेमाल सावधानी से चुनें।

• अगर वर्जीनिया कोड के 2.2-4303.01 के अनुसार कॉन्ट्रैक्ट को " हाई रिस्क " के तौर पर परिभाषित किया गया है, तो कॉन्ट्रैक्ट में अलग-अलग और मापने योग्य परफ़ॉर्मेंस मेट्रिक्स और साफ़ प्रवर्तन प्रावधान होने चाहिए, जिनका इस्तेमाल कॉन्ट्रैक्ट परफ़ॉर्मेंस मेट्रिक्स या अन्य प्रावधानों के पूरा न होने की स्थिति में किया जाना चाहिए, जिसमें दंड और प्रोत्साहन शामिल हैं।

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