सिस्टम विकास का पुरस्कार अदा नहीं होने पर कानून क्या है?
सिस्टम विकास का कार्य संभालने वाले विक्रेता के लिए, एक तरह से सबसे बड़ा जोखिम यह हो सकता है कि “हमने उत्पादन कर दिया है, लेकिन उपयोगकर्ता हमें पुरस्कार नहीं दे रहा है”। सिस्टम विकास की लागत का अधिकांश प्रोग्रामर सहित कुशल कर्मचारियों पर आधारित होता है, इसलिए अधिकांश मामलों में मनपवर की लागत अधिक होती है। बिक्री की वसूली में देरी कभी-कभी मरने और जीने का मुद्दा भी बन सकती है। इस लेख में, हम उपयोगकर्ता के द्वारा पुरस्कार भुगतान के लिए सहमत नहीं होने की स्थिति का ध्यान में रखते हुए, विक्रेता के द्वारा विचार करने योग्य मुद्दों पर कानूनी दृष्टिकोण से चर्चा करेंगे।
सबसे पहले, यह सुनिश्चित करना आवश्यक है कि क्या आप मुआवजा का दावा करने के लिए सक्षम हैं
- विक्रेता ने उपयोगकर्ता के लिए परिणामस्वरूप उत्पाद वितरित किया है, फिर भी उपयोगकर्ता ने वितरण को स्वीकार नहीं किया, और इसके कारण मुआवजा का दावा करने का कार्य भी अवरुद्ध हो गया है
- मान्यता थी कि स्वीकृति प्रक्रिया पूरी हो चुकी थी, फिर भी उपयोगकर्ता की समझ और बीच में कुछ असहमति है, और वे मुआवजा की भुगतान के लिए सहमत नहीं हो रहे हैं
यह स्थिति, वास्तव में भी पूरी तरह से संभव है।
वैसे, उपयोगकर्ता ने तैयार सिस्टम की विशेषताओं की जांच की है, और वितरण को स्वीकार करना, सिस्टम विकास के शब्दों में, “स्वीकृति” कहलाता है। इस “स्वीकृति” के महत्व और उसकी प्रगति के बारे में विचार करने के लिए, निम्नलिखित लेख में विस्तार से व्याख्या की गई है।
संबंधित लेख: सिस्टम विकास की स्वीकृति और मान्यता प्राप्त स्वीकृति क्लॉज का उपयोग क्या है[ja]
स्वीकृति के बारे में सम्पूर्ण विवरण ऊपर दिए गए लेख को सौंप दिया जाता है, लेकिन कानूनी रूप से, क्या उपयोगकर्ता की स्वीकृति पूरी हो चुकी है या नहीं, इसके लिए “मान्यता प्राप्त स्वीकृति क्लॉज” के नियमों को भी ध्यान में रखकर विचार करने की आवश्यकता होती है।
इस बिंदु को ध्यान में रखते हुए, उपयोगकर्ता ने मुआवजा की भुगतान करने से इनकार कर दिया है, ऐसी स्थिति को ध्यान में रखते हुए, सबसे पहले विचार करने योग्य बिंदु निम्नलिखित होंगे।
- क्या काम पूरा हो चुका है, या अभी अधूरा है
- क्या दोष गारंटी जिम्मेदारी (जापानी सिविल कोड धारा 635) लागू हो सकती है या नहीं
यदि आप पूछें कि क्यों हमें उपरोक्त दो बिंदुओं की पुष्टि सबसे पहले करनी चाहिए, तो इसका कारण यह है कि अगर काम पूरा हो चुका है, और दोष गारंटी जिम्मेदारी (जापानी सिविल कोड धारा 635) लागू नहीं होती है, तो यदि हम मुकदमा दायर करते हैं, तो अंततः हमें मुआवजा की भुगतान की उम्मीद नहीं होती है।
तो, विशेष रूप से, उपरोक्त दो बिंदुओं का विचार करने के लिए, विक्रेता के प्रतिनिधि को क्या जांचना चाहिए? निम्नलिखित में, हम देखते हैं कि किन दस्तावेजों की जांच करनी चाहिए।
पुरस्कार की मांग की संभावना की जांच करने के लिए जिन दस्तावेजों की जांच करनी चाहिए
| डिलीवरी नोट यदि डिलीवरी नोट नहीं है, तो यह माना जाता है कि डिलीवरी अधूरी है और काम पूरा नहीं हुआ है। |
| इंस्पेक्शन के परिणाम की सूचना देने वाला दस्तावेज़ काम पूरा हो गया है या नहीं, इसका निर्णय करने के लिए यह सबसे महत्वपूर्ण दस्तावेज़ होता है। साथ ही, यदि उपयोगकर्ता के कारण इंस्पेक्शन को टाला जा रहा है, तो “अनुमानित इंस्पेक्शन क्लॉज़” का उल्लेख किस प्रकार संविदा पत्र पर था, इसकी जांच भी करनी चाहिए। |
| टास्क मैनेजमेंट सूची यह दस्तावेज़ यह बताने के लिए होता है कि अब तक कौन सी समस्याएं उभरी हैं और उनका समाधान कैसे किया गया है। इसके अलावा, यह डिलीवरी के बाद सामने आई दिक्कतों और उनके समाधान की स्थिति को समझने के लिए भी दस्तावेज़ होता है। |
| आवश्यकता परिभाषा दस्तावेज़, डिजाइन दस्तावेज़ और परिवर्तन प्रबंधन दस्तावेज़, विभिन्न मीटिंग की मीटिंग मिनट्स आदि उपयोगकर्ता और विक्रेता ने शुरुआत में कैसी समझ बनाई थी, इसे स्पष्ट करने के लिए, यह दस्तावेज़ होता है जो यह स्पष्ट करता है कि क्या कोई दिक्कत या खराबी कहलाने योग्य है। |
विकसित करने योग्य सिस्टम के विशेषताओं में किए गए परिवर्तनों को कैसे प्रबंधित किया जाए और परिवर्तन प्रबंधन दस्तावेज़ कैसे तैयार किए जाएं, इसके बारे में हमने अन्य लेख में विस्तार से चर्चा की है।
संबंधित लेख: कानूनी दृष्टिकोण से देखा, सिस्टम विकास में परिवर्तन प्रबंधन कैसे करें[ja]
| खुलासा नोटिस या उपयोगकर्ता की इच्छा को दर्ज करने वाला दस्तावेज़ इंस्पेक्शन को आगे बढ़ाने की इच्छा नहीं होने (या पुरस्कार की भुगतान में सहयोग नहीं करने) के बारे में, उपयोगकर्ता का क्या इरादा है, इसे जानने का एक तरीका होता है। |
अगला, कितनी मुआवजा की मांग की जा सकती है, इसकी जांच करें
कितनी मुआवजा की मांग की जा सकती है, इसके बारे में, सिद्धांत रूप से यह अनुबंध में लिखा होता है। हालांकि, यदि स्पेसिफिकेशन में बाद में कोई बदलाव किया गया है, तो यह संभावना हो सकती है कि एक ठोस अनुबंध (या उससे समान दस्तावेज़) मौजूद नहीं हो। स्पेसिफिकेशन के बदलाव, फ़ंक्शन की वृद्धि आदि के बाद उत्पन्न होने वाले कारणों के आधार पर अनुमान का पुनर्गणना कैसे करें, इसके बारे में हमने निम्नलिखित लेख में विस्तार से विवरण दिया है।
संबंधित लेख: क्या सिस्टम विकास की अनुमानित राशि को बाद में बढ़ाया जा सकता है[ja]
अनुमान का पुनर्गणना कैसे करें, इसके बारे में यह लेख है, लेकिन विशेष रूप से बिल की राशि को बढ़ाने की संभावना का अध्ययन करने के दृष्टिकोण से,
- अतिरिक्त विकास / फ़ंक्शन की सुधार के बारे में अनुमान का विवरण और उसकी सामग्री
- अनुमान के प्रति उपयोगकर्ता की प्रतिक्रिया की सामग्री
- अतिरिक्त विकास / फ़ंक्शन की सुधार को उत्पन्न करने वाली स्थिति और उस राशि के बारे में सहमति की उपस्थिति को चुनौती प्रबंधन सूची में दर्ज करना
इसका मुख्य ध्यान इन बिंदुओं पर होगा। मुख्य बात यह है कि “उस राशि के लिए कार्य का आदेश देने” के बारे में, क्या उपयोगकर्ता के साथ इच्छाओं का मेल था (अर्थात्, क्या अनुबंध स्थापित हुआ था) और इस बिंदु की जांच करने की प्रक्रिया होगी।
अंत में, वास्तविक मुकदमेबाजी के मामले में गंभीर मुद्दों पर विचार
उलटा, प्रतिवाद की संभावना का ध्यान रखें
सिस्टम विकास में, यदि उपयोगकर्ता या विक्रेता में से कोई एक दूसरे पर मुकदमा चलाता है, तो उसके उलटे दूसरे पक्ष से प्रतिवाद की संभावना होती है। अर्थात, भुगतान के प्रति अनुकूल नहीं होने की स्थिति में, उपयोगकर्ता के पक्ष में भी कुछ या दूसरा कहने की बात होती है।
सिस्टम विकास में, उपयोगकर्ता को भी विभिन्न सहयोग कर्तव्यों का पालन करना होता है, लेकिन सबसे पहले, हमें यह नहीं भूलना चाहिए कि विक्रेता के रूप में सिस्टम विकास के विशेषज्ञ के रूप में व्यापक विचारण और बड़ी जिम्मेदारी उठाते हैं। विक्रेता के पक्ष में सिस्टम विकास के प्रति उठाए गए प्रोजेक्ट प्रबंधन कर्तव्यों के बारे में, निम्नलिखित लेख में विस्तार से व्याख्या की गई है।
संबंधित लेख: सिस्टम विकास में प्रोजेक्ट प्रबंधन कर्तव्य क्या है[ja]
अर्थात, क्या एकतरफा भुगतान न करने वाले उपयोगकर्ता को दोषी ठहराया जा सकता है, इस बात पर, आपको पहले से ही अच्छी तरह से विचार करने की आवश्यकता है। पिछले न्यायाधीश के फैसलों को देखते हुए, मूल रूप से विक्रेता ने भुगतान की मांग की और मुकदमा चलाया, लेकिन उपयोगकर्ता ने उलटा, मूल स्थिति की बहाली और क्षतिपूर्ति की मांग की, ऐसे मामले अधिकांशतः पाए गए हैं।
व्यापार के लिए वास्तव में लाभ है या नहीं, इसकी भी जांच करनी चाहिए
मान लीजिए कि विक्रेता की बात मानी जाती है, और वास्तव में भुगतान की मांग की स्थिति मुकदमेबाजी में स्वीकार की जाती है, तो यदि मुकदमेबाजी तक मामला उलझ जाता है, तो आगे के लेन-देन को जारी रखना वास्तविक रूप से कठिन हो सकता है। इसके अलावा, यदि मुकदमेबाजी में आपकी बात मानी जाती है, तो वास्तव में भुगतान प्राप्त करने में काफी समय लग सकता है, इसकी तैयारी आपको करनी चाहिए। मुकदमेबाजी करने में लगने वाले समय और लागत को भी ध्यान में रखते हुए, शायद समझौते का बिंदु खोजने की कोशिश करना अधिक उचित और अच्छा होगा।
सारांश
यदि उपयोगकर्ता पुरस्कार भुगतान का पालन नहीं करते हैं, तो उस समस्या का कानूनी रूप से अध्ययन करने की कोशिश करने पर, विभिन्न प्रकार के दस्तावेजों की जांच की आवश्यकता होती है। इसके अलावा, केवल दस्तावेज प्रबंधन की पूरी तरह से योग्यता होने की बात नहीं है, अंत में मुकदमा दायर करने के मामले में संगठनात्मक रूप से किस प्रकार के जोखिम और नुकसान का सामना करना पड़ सकता है, इस बारे में भी विचार करने की आवश्यकता होती है।
दस्तावेज प्रबंधन की नियमितता जैसे मुद्दों पर, यद्यपि यह सामान्यतः स्थलीय स्तर के कार्य के अंतर्गत आता है। हालांकि, यदि संग्रहीत दस्तावेजों और सामग्री के आधार पर मुकदमा दायर करने की बात आती है, तो यह एक महत्वपूर्ण व्यवसायिक निर्णय हो सकता है। इस तरह की अनियमित स्थितियों में, स्थलीय पक्ष और व्यवसाय के पक्ष की एकता और संगठनात्मक शक्ति की मांग होती है, साथ ही, इस पूरे प्रक्रिया को समझना चाहिए।
Category: IT
Tag: ITSystem Development
