सिस्टम विकास समाप्त होने के बाद विक्रेता की समर्थन दायित्व क्या होती है

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

सपोर्ट ड्यूटी क्या है

सपोर्ट ड्यूटी का अवलोकन

विक्रेता द्वारा उपयोगकर्ता के प्रति निभाए जाने वाले कर्तव्यों के संदर्भ में, प्रमुख कर्तव्यों में प्रोजेक्ट मैनेजमेंट ड्यूटी शामिल होती है। यह पिछले न्यायाधीशों के फैसलों आदि के माध्यम से बार-बार उल्लेखित होकर स्थापित हुई है, और यह सिस्टम विकास के विशेषज्ञों के रूप में विक्रेता द्वारा पूरी प्रोजेक्ट के प्रति निभाए जाने वाले कर्तव्यों को संक्षेप में व्याख्या करती है।

https://monolith.law/corporate/project-management-duties[ja]

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

सपोर्ट ड्यूटी उपयोगकर्ता के प्रति ऑपरेशनल सपोर्ट में समस्या बनती है

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

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

सपोर्ट दायित्व के संबंध में न्यायाधीश के निर्णय का उल्लेख

सिस्टम टेस्ट के चरण में, उपयोगकर्ता के कार्य को बाधित करने वाले मामले

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

आ। सपोर्ट दायित्व का उल्लंघन
(अ) मुख्य याचिकाकर्ता ने, 1997 में (हेइसेई 9) 14 जुलाई को, विरोधी पक्ष के प्रति, ‘सिस्टम को बनाने के अलावा, इसे ठीक से चलाने के लिए अंत तक देखभाल करना चाहिए।‘, ‘हम नौसिखिए हैं, इसलिए हम बहुत अधिक धन खर्च कर रहे हैं, इसलिए हमें अंत तक इसका उपयोग करने की अनुमति देनी चाहिए।‘ का अनुरोध किया। इसके जवाब में, विरोधी पक्ष ने, मुख्य याचिकाकर्ता के परिचय लक्ष्य को प्राप्त करने में सक्षम सिस्टम का निर्माण संभव है, ऐसा समझाया और इसे ठीक से उपयोग करने के लिए सपोर्ट करने का वादा किया। इससे, मुख्य याचिकाकर्ता और विरोधी पक्ष के बीच में, मुख्य याचिकाकर्ता को इस सिस्टम का ठीक से उपयोग करने के लिए विरोधी पक्ष का सपोर्ट करने का समझौता हुआ।
विरोधी पक्ष के पास मुख्य याचिकाकर्ता के प्रति सपोर्ट दायित्व है, इसका सबूत इस ठेके की राशि के रूप में, ‘पैकेज इंस्टॉलेशन सपोर्ट’ के शीर्षक में 1,726,000 येन की लागत का हिसाब लगाया गया है, अनुमान पत्र में, मासिक रखरखाव शुल्क के बारे में, ‘छह महीने के लिए मुफ्त रखरखाव’ लिखा गया है, ‘आगामी SE सपोर्ट के बारे में (कंपनी मीटिंग दस्तावेज़)’ शीर्षक वाले दस्तावेज़ में, ताजगी के आदेश के बारे में, ‘इंस्टॉलेशन प्रक्रिया (योजना) का निर्माण’ और ‘डेटा / ऑपरेशनल परीक्षण कार्य’ के बारे में SE सपोर्ट प्राप्त करने की पुष्टि की गई है।

(इ) और फिर, विरोधी पक्ष का मुख्य याचिकाकर्ता के प्रति सपोर्ट दायित्व, विशेष रूप से, कम से कम मुख्य याचिकाकर्ता के इस सिस्टम के मुख्य ऑपरेशनल होने तक, विरोधी पक्ष का, मुख्य याचिकाकर्ता के प्रति, ① इस सिस्टम के ऑपरेशनल तरीके के बारे में उचित सलाह प्रदान करना, ② ऑपरेशनल टेस्ट में उपस्थिति और ऑपरेशनल टेस्ट में उत्पन्न हुई सिस्टम की समस्याओं का समाधान करना, ③ ऑपरेशनल टेस्ट के परिणामों के अनुसार सिस्टम को सुधारना, ④ ऑपरेटर के लिए इंस्टॉलेशन शिक्षा प्रदान करना।
हालांकि, विरोधी पक्ष ने, ऑपरेशनल टेस्ट में समस्याओं के बढ़ने के बावजूद, ऑपरेटर की क्षमता की समस्या होने के कारण इसे गंभीरता से नहीं समाधान किया, केवल ऑपरेटर की इंस्टॉलेशन शिक्षा की लागत की मांग की, मुख्य याचिकाकर्ता के प्रति, मुख्य ऑपरेशनल की ओर उचित सपोर्ट को किसी भी तरह से नहीं किया।

टोक्यो जिला न्यायालय हचिओजी शाखा, 2003 (हेइसेई 15) 5 नवम्बर का निर्णय

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

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

यह है। प्रोजेक्ट मैनेजमेंट के अलग अवधारणा होने के बावजूद, सिस्टम विकास के ठेके को ठेके के दायित्व के रूप में देखने की कोशिश की जा रही है।

सपोर्ट दायित्व की प्रकृति कैसे समझी जानी चाहिए

सपोर्ट दायित्व अभी भी स्पष्ट अवधारणा नहीं है

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

सपोर्ट दायित्व को असीमित रूप से मान्यता नहीं दी जाती है

इसके अलावा, विक्रेता के सपोर्ट दायित्व की उल्लंघना को मान्यता देने वाले उपरोक्त निर्णय ने, साथ ही एक बहुत महत्वपूर्ण बिंदु भी उजागर किया है।

यह समझा जाता है कि प्रतिवादी ने, इस ठेका अनुबंध के आधार पर, मुद्दाकर्ता के लिए निर्माण और वितरण किए गए सिस्टम के लिए, मुद्दाकर्ता को इसे ऑपरेट करने के लिए आवश्यक कुछ सपोर्ट प्रदान करने की दायित्व लेता है। हालांकि, उसकी सामग्री, मुद्दाकर्ता के दावे के अनुसार, समय की सीमा के बिना, वास्तव में मुद्दाकर्ता को इस सिस्टम को ऑपरेट करने की क्षमता होने तक, मुफ्त में हर प्रकार का सपोर्ट प्रदान करने वाली चीज़ थी, ऐसा समझा नहीं जाता है।

टोक्यो जिला कोर्ट हचिओजी शाखा, हेइसेइ 15 वर्ष (2003) नवम्बर 5 का निर्णय

यदि मुख्य कार्य के रूप में स्वीकार किए गए कार्य “विकास” है, तो “ऑपरेशन” के लिए सपोर्ट के रूप में करने की आवश्यकता वाली चीजों में भी स्वतः सीमाएँ होती हैं, ऐसा सोचा जा सकता है। इस निर्णय में भी, सहयोग की मांग करने वाले उपयोगकर्ताओं की आवाज़ को निर्णय पाठ में उद्धृत करने का बिंदु, पूर्वानुमान की सामग्री पर टिप्पणी करने का बिंदु, सपोर्ट प्रदान करने के बारे में विशेष अनुबंध की उपस्थिति आदि के बारे में छूने का बिंदु, कुछ विशेषताओं के बिंदु मिलते हैं। अर्थात, यदि सपोर्ट दायित्व की अवधारणा असीमित रूप से विस्तारित होती है, तो यह विक्रेता के लिए बड़ा बोझ डालने वाली चीज़ होगी, इसे ध्यान में रखते हुए, दायित्व उल्लंघन की मान्यता भी कुछ हद तक सतर्कता से की जानी चाहिए, ऐसा माना जाता है।

सपोर्ट दायित्व की वास्तविकता का अध्ययन करना चाहिए, उपयोगकर्ताओं के सहयोग दायित्व के साथ

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

हालांकि, विक्रेता के द्वारा लिए जाने वाले सपोर्ट दायित्व की वास्तविकता क्या होती है, यह उपयोगकर्ता के द्वारा लिए जाने वाले सहयोग दायित्व को समझने के द्वारा, अधिक सुनिश्चित हो सकती है।

https://monolith.law/corporate/user-obligatory-cooporation[ja]

सबसे पहले, नए सिस्टम के द्वारा कार्य को सुधारने के प्रयास, तकनीकी विशेषज्ञों के रूप में विक्रेता और, संगठन के कार्य ज्ञान वाले उपयोगकर्ताओं के साझा काम का एक पहलू होता है। इसलिए, उस सपोर्ट दायित्व जैसी चीज़ के बारे में भी, उपयोगकर्ताओं को “सहयोग दायित्व का पालन” के एक हिस्से के रूप में स्वयं की मदद से समस्याओं को हल करने के लिए स्पष्ट रूप से बातें करने से, उसकी सीमाएँ स्वतः ही तय हो जाती हैं, ऐसा माना जाता है।

सारांश

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