यदि सिस्टम विकास कार्य उपयोगकर्ता की सुविधा के कारण रुक गया हो, तो उसका समाधान क्या है?

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

इस लेख में, हम सिस्टम विकास नामक अनुबंध की विशेषताओं को संगठित करेंगे, साथ ही उस स्थिति के प्रतिक्रिया योजना के बारे में व्याख्या करेंगे।

उपयोगकर्ता की सहूलियत के कारण रुकावट के बारे में विचार करने का महत्व

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

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

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

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

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

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

सबसे पहले, रद्द करने के लिए कहने के कारण को संगठित करें

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

हालांकि, यदि ऐसा निर्णय लेने के पीछे की प्रक्रिया में, विक्रेता के पास भी प्रोजेक्ट प्रबंधन की हर कदम में देरी जैसी अनुपालन की असली स्थिति होती है, और विकास की प्रगति भी कठिनाई से हो रही होती है, तो क्या होता? यह भी कंपनी की नीति में परिवर्तन का एक कारण बन सकता है।

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

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

अगला, पुरस्कार दावा और क्षतिपूर्ति के आधार धारा की जांच

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

ऐसे मामले में संदर्भित धारा, समझौते के प्रकार पर निर्भर करती है। सिस्टम विकास के संबंध में समझौते, बड़े तौर पर कहते हुए, ठेका समझौते और अनुपालन समझौते में विभाजित किए जा सकते हैं।

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

और, अनुपालन समझौते और ठेका समझौते के मामले में, जापानी सिविल कोड (मिनपो) निम्नलिखित प्रावधान रखता है।

a.) अनुपालन समझौते के मामले में
पुरस्कार दावा: जापानी सिविल कोड (मिनपो) धारा 648(3)
यदि अनुपालन अनुपालनकर्ता की दोष में नहीं आता है और आधा अधूरा छोड़ दिया जाता है, तो अनुपालनकर्ता पहले से किए गए कार्य के अनुपात में पुरस्कार का दावा कर सकता है।
क्षतिपूर्ति दावा: जापानी सिविल कोड (मिनपो) धारा 651
1. अनुपालन को किसी भी पक्ष द्वारा कभी भी रद्द किया जा सकता है।
2. जब एक पक्ष दूसरे पक्ष के लिए अनुकूल समय में अनुपालन को रद्द करता है, तो उस पक्ष को दूसरे पक्ष के क्षति का पूर्ति करना होगा। हालांकि, यदि अपरिहार्य कारण होते हैं, तो यह सीमित नहीं होता है।

b.) ठेका समझौते के मामले में
क्षतिपूर्ति दावा: जापानी सिविल कोड (मिनपो) धारा 641
जब तक कि ठेकेदार काम पूरा नहीं करता है, आदेशकर्ता किसी भी समय क्षति का पूर्ति करके समझौते को रद्द कर सकता है।

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

हालांकि, जापानी सिविल कोड (मिनपो) धारा 641 के आधार पर क्षतिपूर्ति के बारे में, विक्रेता और उपयोगकर्ता के बीच व्यक्तिगत समझौते में, क्षतिपूर्ति के विषय को बाहर रखा जाता है, ऐसे मामले अमूमन होते हैं। ऐसे मामले में, व्यक्तिगत रूप से बनाए गए पक्षों के बीच के वादे (समझौते) को अधिकार दिया जाता है, और इस प्रकार के सिविल कोड के प्रावधानों का विचार नहीं किया जाता है, इसलिए सतर्कता जरूरी है।

और आगे वॉल्यूम और हानि के साक्ष्य को बढ़ावा दें

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

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

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

उल्टा, उपयोगकर्ता की ओर से क्या विचार करना चाहिए

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

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

वैसे भी, इस लेख में, हमने सिस्टम विकास के संबंध में समझौते की स्थापना की मान्यता को ध्यान में रखकर व्याख्या की है, लेकिन वास्तविक सिस्टम विकास के दृश्य में, ‘क्या समझौता वास्तव में स्थापित हुआ है’ इसका विवाद होने का मामला भी कम नहीं होता। इसके बारे में निम्नलिखित लेख में विस्तार से व्याख्या की गई है।

https://monolith.law/corporate/system-development-contract[ja]

सारांश

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

सिस्टम विकास के ऐसे प्रोजेक्ट में विक्रेता और उपयोगकर्ता दोनों को बड़ी जिम्मेदारी उठानी पड़ती है। इसलिए, यदि हम यह नहीं सोचते कि क्या वास्तव में दोस्तरफा दोष लगाना संभव है या नहीं, तो यह आगे चलकर आग में घी डालने जैसी स्थिति भी पैदा कर सकता है, इस बात का ध्यान रखना चाहिए।