कानूनी दृष्टिकोण से सिस्टम विकास के विनिर्देशन में नहीं होने वाले सुविधाओं को कितना लागू करना चाहिए?

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

स्पेसिफिकेशन में नहीं होने वाले चीजों के कार्यान्वयन के साथ जुड़े कानूनी मुद्दे

विक्रेताओं के काम में विवेकाधिकार की आवश्यकता होती है

सिस्टम विकास जैसी परियोजनाओं से जुड़े समझौतों और उनसे जुड़े विभिन्न कानूनी मुद्दों की एक बड़ी विशेषता यह है कि काम करने वाले विक्रेता के पास बड़ा विवेकाधिकार होता है।

संबंधित लेख: सिस्टम विकास में प्रोजेक्ट प्रबंधन की जिम्मेदारियां क्या हैं[ja]

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

संबंधित लेख: सिस्टम विकास में ठेका और अधिकारपूर्ण अनुबंध का अंतर और भिन्नता[ja]

विवेकाधिकार, कठोर विकास प्रक्रिया में भी व्यक्त किया जाना चाहिए

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

संबंधित लेख: कानूनी दृष्टिकोण से देखा, सिस्टम विकास में परिवर्तन प्रबंधन कैसे करें[ja]

स्पेसिफिकेशन से बाहर, विशेषज्ञ के रूप में क्या करना चाहिए

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

कानूनी दायित्व, विशेषण पत्र और अनुबंध पत्र के ‘उद्देश्य’ के अनुसार तय होते हैं

जिसे लागू करना होता है, उसकी सामग्री, चाहे अनुबंध पत्र या विशेषण पत्र में विवरण न हो, फिर भी उन अनुबंध पत्र और विशेषण पत्र के विवरण के ‘उद्देश्य’ यानी ‘किस प्रकार के अर्थ और इरादे के साथ, ऐसा निर्णय लिया गया था’ के आधार पर तय होती है। निम्नलिखित में, हम कुछ न्यायाधीशों के उदाहरणों के साथ इसे देखेंगे।

अदालती फैसले में अनुपालन करने की आवश्यकता को नकारा गया क्योंकि विवरण नहीं दिया गया था

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

ऊपर उल्लेखित प्रमाण के अनुसार, इस समझौते, मूल डिजाइन दस्तावेज और विस्तृत डिजाइन दस्तावेज में, ③ क्षमता को इस सिस्टम के विकास के लक्ष्य के रूप में दर्शाने वाली कोई जानकारी नहीं है।

मुद्दायी ने दावा किया कि, ③ क्षमता विक्रेता के मुद्दायी के प्रति इस सिस्टम का मुख्य बिक्री बिंदु था, और उस क्षमता की आवश्यकता को बल दिया, यदि उनका दावा सही है, तो यह बात समझौते आदि में स्पष्ट रूप से लिखी जानी चाहिए, और यदि ऐसा नहीं है, तो उस क्षमता के विकास पर सहमति होने की संभावना कम है।

टोक्यो जिला न्यायालय, हेइसेई 21 वर्ष (2009)

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

विवरण की अनुपस्थिति के बावजूद लागू करने की आवश्यकता को मान्यता दी गई न्यायिक प्रकरण

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

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

संबंधित लेख: पुराने सिस्टम से सिस्टम विकास के दौरान स्थानांतरण के साथ कानूनी मुद्दे[ja]

मौजूदा सिस्टम में पहले से ही 50,000 से अधिक रोगी डेटा संग्रहीत था, और मुद्दायी ने इन डेटा का उपयोग करके कार्यक्षमता को बढ़ाने की कोशिश की थी, तो यदि रोगी डेटा को मौजूदा सिस्टम से इस मामले के सिस्टम में स्थानांतरित नहीं किया जा सकता, तो फार्मेसी में डिस्पेंसिंग कार्य में बाधा आ सकती है, यह स्पष्ट है, और मुद्दायी प्रतिनिधि में भी, यह स्वाभाविक रूप से माना जाता है कि उन्होंने इस बात को मान्यता दी थी। और, इस मामले के समझौते से पहले, मुद्दायी प्रतिनिधि ने, प्रतिवादी प्रतिनिधि के प्रति, डेटा स्थानांतरण की संभावना के बारे में प्रश्न किया था, जिसे प्रतिवादी प्रतिनिधि ने स्वीकार किया (मध्य छोड़कर), मुद्दायी प्रतिनिधि में, 50,000 से अधिक रोगी डेटा के लिए हाथ से इनपुट करने की आवश्यकता हो सकती है, जिसे मान्यता दी गई थी, इस मामले के सिस्टम का परिचय देने का निर्णय लेने का सोचना मुश्किल है। इसके अलावा, ऊपर (1) ई के अनुसार, प्रतिवादी ने, मौजूदा सिस्टम के दवा इतिहास डेटा को इस मामले के सिस्टम में स्थानांतरित नहीं कर सका, इसलिए उसने उस डेटा को कागज पर मुद्रित किया, और इसे पीडीएफ फ़ाइल में ले लिया, इस मामले के समझौते में डेटा स्थानांतरण को पूर्वानुमान नहीं किया गया था, प्रतिवादी ने सेवा के रूप में इस तरह का श्रमसाध्य कार्य करने का सोचना मुश्किल है।

टोक्यो जिला न्यायालय, 18 नवम्बर 2010 (हेइसेई 22)

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

दोनों फैसलों से हमें क्या पता चलता है

डाटा माइग्रेशन के संबंध में, यदि अनुबंध या विनिर्देश पत्र में कोई उल्लेख नहीं है, तो भी कार्यान्वयन की आवश्यकता को स्वीकार किया गया था, इसके पीछे का एक कारण यह भी हो सकता है कि यह ‘डाटा’ की बात थी, जो स्क्रीन की बाहरी दिखावट पर प्रकट नहीं होती। पहले का ‘अनिवार्य सुविधाओं की कमी’ मूल रूप से सिस्टम की स्क्रीन या बाहरी दिखावट पर सीधे प्रकट होती है। इसलिए, यदि कोई सिस्टम विकास का शौकीन है, तो विनिर्देश पत्र में उल्लेख छूटने का पता लगाना इतना कठिन नहीं होता। वहीं, डाटा माइग्रेशन की समस्या का एक विशेषता यह है कि सिस्टम विकास के शौकीनों के लिए इस कार्यक्रम की महत्वता, कार्य की कठिनाई और कार्य समय आदि को समझना मुश्किल होता है। इसलिए, विचार किया जा सकता है कि विक्रेता के पक्ष में विशेषज्ञता के साथ सुचारू रूप से संभालने के लिए यह मामला आसानी से संभावित होता था।

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

संबंधित लेख: सिस्टम विकास के आदेशदाता यानी उपयोगकर्ता की ओर से बोझ उठाने की सहयोग की आवश्यकता क्या है[ja]

ऊपर के लेख को भी देखने के बाद, उपयोगकर्ता की ओर से सहयोग की मांग जैसे कि स्क्रीन और अनिवार्य सुविधाओं की जांच आदि के क्षेत्र में, और डाटा माइग्रेशन की चर्चा में छूट, बात बहुत अलग होती है, यह भी स्वतः ही समझ में आ जाती है।

स्पेसिफिकेशन में नहीं होने वाले विकास के लिए भुगतान कैसे सोचना चाहिए

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

संबंधित लेख: क्या सिस्टम विकास की अनुमानित राशि को बाद में बढ़ाया जा सकता है[ja]

उपरोक्त लेख में, भुगतान और मूल्य विपरीत संबंध में कार्य क्षेत्र से अधिक कार्य की उपस्थिति का महत्व बताया गया है। अर्थात, इस लेख के संदर्भ में, यदि विक्रेता मूल स्पेसिफिकेशन में शामिल नहीं होने वाले विकास (इस लेख के हिसाब से, नकारात्मक उदाहरण) के लिए सहमत होता है, तो उसमें अतिरिक्त भुगतान का दावा करने की अनुमति हो सकती है।

सारांश

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