सिस्टम विकास में ठेका समझौते का काम समाप्त क्या होता है
सिस्टम विकास आमतौर पर एक लंबे समय की प्रक्रिया होती है, और कई बार इसमें विशेषताओं के परिवर्तन और अतिरिक्त सुविधाओं के कार्यान्वयन की मांग भी होती है, जिससे काम करने वाले विक्रेताओं को कभी-कभी ऐसी कठिनाई में फंसना पड़ता है जिसका कोई समाधान नहीं दिखाई देता। ऐसे विक्रेताओं के लिए, “आखिरकार हमें क्या और कितना करना होगा ताकि हमारा काम पूरा हो जाए” यह समस्या कभी-कभी एक गंभीर चिंता का कारण बन सकती है।
और फिर, सिस्टम विकास के मामले में अधिकांशतः ठेका अनुबंध होते हैं, और ठेका अनुबंध एक “काम की समाप्ति” को लक्ष्य बनाते हैं।
इस लेख में, हम कानूनी दृष्टिकोण से यह समझाने का प्रयास करेंगे कि “सिस्टम विकास कब, क्या और कितना करने पर, समाप्त हो जाता है”।
सिस्टम विकास की समाप्ति क्या होती है
तकनीशियन के लिए सिस्टम विकास की समाप्ति क्या होती है
सिस्टम विकास के क्षेत्र में, “सिस्टम विकास की समाप्ति कब होती है” जैसे प्रश्न पर, सामान्यतः, “जब टेस्ट प्रक्रिया समाप्त हो जाती है और उत्पादन को डिलीवर किया जाता है” जैसा उत्तर मिलता है। निश्चित रूप से, सामान्य सिस्टम विकास की प्रक्रिया शुरू होती है आवश्यकता परिभाषा से, जिसमें लागू करने के लिए फ़ंक्शन की विवरण आदि की जांच की जाती है, फिर विभिन्न डिज़ाइन दस्तावेज़ तैयार किए जाते हैं, और फिर प्रोग्राम का निष्पादन होता है, और अंत में, यह सुनिश्चित किया जाता है कि कार्यवाही सही ढंग से हो रही है या नहीं टेस्ट प्रक्रिया के द्वारा, और यह उपयोगकर्ता की स्वीकृति के साथ समाप्त होती है।
इसलिए, यदि हम तकनीशियन के दृष्टिकोण से देखें, तो “सिस्टम विकास की समाप्ति = स्वीकृति पास” जैसी समझ सामान्य हो सकती है।
कानूनी दृष्टिकोण से देखा गया सिस्टम विकास का समापन
दूसरी ओर, कानूनी दृष्टिकोण से देखें, तो सिस्टम विकास की समाप्ति कब होती है, तो वहां पर विचार का केंद्र बिंदु यह होता है कि विक्रेता ने अपने अनुबंध के तहत लिए गए कानूनी दायित्व को कब और किस समय पूरा किया। सिस्टम विकास के अनुबंध को मूल रूप से या तो ठेका अनुबंध या अनुमति अनुबंध में वर्गीकृत किया जाता है।
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
इन दोनों अनुबंध प्रकारों के अंतर के बारे में विवरण, ऊपरी लेख में दिया गया है, लेकिन यदि हम सिस्टम विकास की समाप्ति, अर्थात विक्रेता के द्वारा लिए गए ऋण के पूर्णता के बारे में बात करें, तो उसके निर्णय के मानदंड को प्रदान करने वाले धारा दोनों के लिए निम्नलिखित रूप में दी गई हैं।
ठेका अनुबंध: नागरिक संहिता धारा 632
धारा 632
ठेका का प्रभाव तब उत्पन्न होता है, जब पक्षों में से एक ने कार्य को पूरा करने का वादा किया होता है, और दूसरा पक्ष उस कार्य के परिणाम के लिए उसकी मुआवजा देने का वादा करता है।
अनुमति अनुबंध: नागरिक संहिता धारा 648
धारा 648
1.यदि कोई विशेष समझौता नहीं हो, तो ग्राहक को आदेशदाता के प्रति मुआवजा मांगने का अधिकार नहीं होता।
2.यदि ग्राहक को मुआवजा प्राप्त करना चाहिए, तो वह आदेश कार्य के पूरा होने के बाद ही इसे मांग सकता है। हालांकि, यदि मुआवजा को समय के आधार पर निर्धारित किया गया हो, तो धारा 624 की उपधारा 2 का प्रावधान लागू होता है।
3.यदि आदेश का पालन ग्राहक की गलती के कारण बीच में ही समाप्त हो गया हो, तो ग्राहक, पहले से किए गए कार्य के अनुपात में मुआवजा मांग सकता है।
सिस्टम विकास की समाप्ति का मुद्दा ठेका अनुबंध होता है
हालांकि, सिस्टम विकास के संदर्भ में या बिना उसके, “कार्य की समाप्ति का समय कब होता है” जैसे बिंदु पर समस्या उत्पन्न होने की संभावना, मूल रूप से ठेका अनुबंध होती है। अनुमति अनुबंध के मामले में, विशेष रूप से परिणाम या उत्पादन को ऋण के पूर्णता के रूप में मानने की बजाय, यह एक विशेषज्ञता वाले कर्मचारी के रूप में, कुछ विचारणीय विचारधारा के साथ, (परिणाम चाहे जैसा हो) उचित कार्य करने का अर्थ होता है। अनुमति अनुबंध धारा में भी, यदि कार्य प्रक्रिया स्वयं को उचित रूप से आगे बढ़ाया गया हो, तो चाहे सोचा गया उत्पादन तैयार हो या नहीं, मुआवजा की मांग संभव होती है (धारा 648, उपधारा 2), और यदि पालन ग्राहक की गलती के कारण बीच में ही समाप्त हो गया हो, तो उसके अनुपात में मुआवजा की मांग संभव होती है (धारा 648, उपधारा 3)। ठेका अनुबंध “परिणाम” पर ध्यान केंद्रित करता है, जबकि अनुमति अनुबंध “प्रक्रिया” पर ध्यान केंद्रित करता है।
इसलिए, अनुमति अनुबंध में, बल्कि, “ध्यान देने की दायित्व” कानूनी मुद्दा बनने की प्रवृत्ति होती है, जो आदेश कार्य को आगे बढ़ाने की प्रक्रिया में होती है। यानी, जब उच्च स्तर की विश्वासघात की आधारभूत मान्यता हो, तो आदेश अनुबंध के तहत ध्यान देने की दायित्व का उल्लंघन कब किया जा सकता है, यह समस्या होती है।
दूसरी ओर, ठेका अनुबंध में महत्वपूर्ण है “कार्य की समाप्ति”। यदि समाप्त करने के लिए जो कुछ भी हो, वह समाप्त नहीं होता है, तो विक्रेता के द्वारा लिए गए ऋण का पूर्णता संभव नहीं होता है, और मुआवजा की मांग भी नहीं की जा सकती है, यह मूल नियम है। लेकिन यदि समाप्त हो गया है, तो उसके मध्यवर्ती चरण के बारे में समस्या उत्पन्न करने का कोई अर्थ नहीं होता है। इसलिए, “सिस्टम विकास परियोजना की समाप्ति कब होती है” जैसी समस्या को मूल रूप से, ठेका अनुबंध में “कार्य की समाप्ति” जैसे शब्दों के कानूनी व्याख्यान की समस्या के रूप में पुन: व्याख्या किया जा सकता है।
सिस्टम विकास में कार्य की समाप्ति कब होती है
तो, ऐसी ‘कार्य की समाप्ति’ की टाइमिंग को विशेष रूप से, कब माना जाना चाहिए? इस बिंदु पर, आइए पिछले न्यायिक मामलों की समीक्षा करते हैं।
कार्य की समाप्ति के आसपास के न्यायिक मामले
नीचे उद्धृत न्यायिक मामले में, विक्रेता ने वितरित किए गए सिस्टम के बारे में, बाद में प्रसंस्करण गति और संचार लागत आदि के मामले में मुद्दे उभरे थे। ऐसे मुद्दों का पता चलने के बावजूद भी, विकास प्रक्रिया स्वयं पूरी तरह से पूरी हो चुकी थी, इसलिए ‘कार्य की समाप्ति’ कहने में क्या यह सही है या नहीं, इस पर विवाद हुआ था। परिणामस्वरूप, कार्य की समाप्ति स्वयं को मान्यता दी गई थी।
सिविल कोड की धारा 632 और 633, ठेकेदार के आदेशकर्ता के प्रति वेतन की भुगतान की अवधि के बारे में, ठेकेदार ने कार्य को पूरा कर दिया है, और कार्य की उद्देश्य वस्तु को आदेशकर्ता के प्रति सौंप दिया है, और दूसरी ओर, उसी कानून की धारा 634, कार्य की उद्देश्य वस्तु में दोष होने पर ठेकेदार को आदेशकर्ता के प्रति गारंटी जिम्मेदारी उठानी पड़ती है (धारा 1), और ठेकेदार ने कार्य की उद्देश्य वस्तु के दोष के बारे में अपनी गारंटी जिम्मेदारी पूरी करने तक आदेशकर्ता को वेतन की भुगतान में समान प्रदर्शन का विरोध करने का अधिकार होता है (धारा 2)। इन सिविल कोड की धाराओं के अनुसार, कानून, कार्य के परिणाम अधूरे होने के मामले में कार्य की उद्देश्य वस्तु में दोष होने वाले मामले और कार्य की समाप्ति नहीं होने वाले मामले को अलग करता है, कार्य की उद्देश्य वस्तु में दोष मौजूद होने पर भी, चाहे वह छिपा हुआ हो या प्रकट हो, उसके लिए कार्य की समाप्ति नहीं होने वाली वस्तु नहीं होती है।
इसलिए, ठेकेदार ने कार्य को पूरा किया है या नहीं, इसके बारे में, कार्य ने मूल ठेका संविदा में निर्धारित अंतिम प्रक्रिया को पूरा किया है या नहीं, इसे मानदंड के रूप में निर्णय करना चाहिए और आदेशकर्ता, ठेकेदार ने कार्य की अंतिम प्रक्रिया को पूरा करके उद्देश्य वस्तु को सौंप दिया है, तो, केवल, कार्य की उद्देश्य वस्तु में दोष होने के कारण ठेका दाम की भुगतान को अस्वीकार करना उचित नहीं होगा।
उपरोक्त निर्णय में ‘कार्य की समाप्ति’ को, सिस्टम विकास में अंतिम प्रक्रिया को पूरा करने के लिए, मानदंड को पूरा करने के लिए मान्यता दी गई थी। विक्रेता द्वारा बनाए गए सिस्टम की अयोग्यता (कानूनी रूप से ‘दोष’ कहा जाता है) के लिए उपाय के रूप में, पहले से ही अलग दोष गारंटी जिम्मेदारी का प्रणाली तैयार किया गया है।
इसलिए ‘कार्य की समाप्ति’ की अवधारणा को थोड़ा व्यापक रूप से समझने के बावजूद, अंततः यह उपयोगकर्ता के पक्ष में अनुचितता को बढ़ाने वाली बात नहीं होगी। संक्षेप में, यह निम्नलिखित है:
【ठेका संविदा में ऋण = कार्य की समाप्ति = सभी प्रक्रियाओं की समाप्ति】
===========
कार्य समाप्त नहीं होता है तो…
↓
【ऋण अनुपालन जिम्मेदारी का दायित्व उठाना】
===========
कार्य समाप्त हो गया है लेकिन अयोग्यता है तो…
↓
【ऋण के अनुपालन को मान्यता देने के बाद, दोष गारंटी जिम्मेदारी का मुद्दा】
इस प्रकार के मुद्दे को विभाजित करने का संकेत, उपरोक्त न्यायिक मामला है।
हालांकि, ‘कार्य की समाप्ति’ के बिंदु से संबंधित, दृष्टिकोण को बदलकर ‘उपयोगकर्ता की पास अनुमानित निरीक्षण’ के बिंदु से भी विचार करने की क्षमता होती है। उपयोगकर्ता की ओर से निरीक्षण की प्रगति नहीं हो रही है, इसके बारे में कानूनी मुद्दों पर, हमने अन्य लेख में विवरण दिया है।
https://monolith.law/corporate/estimated-inspection-of-system-development[ja]
कानूनी काम के पूरा होने का अर्थ क्या होता है
सिस्टम विकास में, यदि “काम का समापन” स्वीकार किया जाता है, तो यह माना जाता है कि आपने अपना ऋण पूरा कर दिया है, इसलिए आपको ऋण “अनपूर्णता” की जिम्मेदारी का सामना नहीं करना पड़ता। यदि यह ठेका अनुबंध है, और काम पूरा नहीं हुआ है, तो आप भुगतान का दावा नहीं कर सकते, और यदि आपने पूर्व भुगतान की विशेष व्यवस्था की होती, तो आपको उन्हें वापस करना पड़ता। दूसरी ओर, यदि काम पूरा होने की स्थिति स्वीकार की जाती है, तो विक्रेता को केवल दोष गारंटी और अनुबंध की गुणवत्ता गारंटी की समस्याओं का सामना करना पड़ता है।
विक्रेता को ऋण अनपूर्णता की जिम्मेदारी से मुक्त होने का अर्थ यह है कि उपयोगकर्ता की ओर से अनुबंध का रद्द करने की संभावना एकदिवसीय रूप से कम हो जाती है। क्योंकि दोष गारंटी के आधार पर अनुबंध का रद्द करना, अनुबंध के उद्देश्य को प्राप्त नहीं करने वाली स्थितियों पर सीमित होता है। यदि अनुबंध रद्द किया जाता है, तो विक्रेता भी भुगतान का दावा करने का अधिकार खो देता है (अर्थात्, भुगतान नहीं मिलता)। इसलिए, व्यावहारिक रूप से, “काम के समापन” के आसपास विवाद उत्पन्न होने की संभावना अधिक होती है।
वैसे, सिस्टम विकास में अनुबंध के “रद्द” के बारे में विवरण, निम्नलिखित लेख में विस्तार से दिया गया है।
कार्य के पूर्ण होने से संबंधित विविध सूचनाएं
स्पेसिफिकेशन परिवर्तन और अतिरिक्त विकास का कैसे विचार करें
विशेष रूप से, विक्रेता के लिए, “मूल रूप से कहा गया था कि स्पेसिफिकेशन पहले से ही स्पष्ट कर दिए गए हैं, लेकिन स्पेसिफिकेशन के परिवर्तन और कार्यक्षमता के अतिरिक्त विकास की मांग की जा रही है, और कार्य को समाप्त करने की कोशिश कर रहे हैं, लेकिन अंत नहीं हो रहा है” जैसी स्थिति में भी आ सकते हैं। ऐसी स्थिति में भी, “सिस्टम विकास को समाप्त करने का समय” जैसी समस्याएं उभर सकती हैं। इस प्रकार की स्थिति के बारे में विस्तार से व्याख्या निम्नलिखित लेख में दी गई है।
https://monolith.law/corporate/increase-of-estimate[ja]
सिविल कोड के संशोधन पर भी ध्यान दें
इसके अलावा, ठेका अनुबंध के आधार पर दोष गारंटी दायित्व के प्रावधानों का नियम है, जो पहले से ही जटिल और समझने में कठिन होते हैं, यह सिविल कोड के संशोधन का प्रभाव अधिकतम प्राप्त कर रहा है। सिविल कोड के संशोधन के दौरान, “दोष” को कैसे समझना चाहिए, इसके बारे में विस्तार से व्याख्या निम्नलिखित लेख में दी गई है।
https://monolith.law/corporate/defect-warranty-liability[ja]
सारांश
इस लेख में, हमने सिस्टम विकास परियोजनाओं के लिए, जो अक्सर “निकासी दिखाई नहीं देती” जैसी स्थितियों में फंस जाती हैं, उन्हें “काम की समाप्ति” के कानूनी सिद्धांत से जोड़ने के लिए पथ का विवरण दिया है। प्रत्येक परियोजना का निकासी स्थल विकास की आवश्यकताओं के आधार पर अलग-अलग हो सकता है, लेकिन जब ऐसे मुद्दों के चारों ओर विवाद होता है, तो कानूनी “काम की समाप्ति” की अवधारणा अक्सर मार्गदर्शन की डोरी के रूप में काम करती है।
Category: IT
Tag: ITSystem Development