सिस्टम विकास की स्वीकृति और मान्यता प्राप्त स्वीकृति की शर्तों का उपयोग क्या है

सिस्टम विकास के दौरान कानूनी समस्याएं आमतौर पर “इंस्पेक्शन” के चरण में उत्पन्न होती हैं।

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

ऐसी समस्याओं को हल करने के लिए, अनुबंध में अक्सर “मान्यता प्राप्त इंस्पेक्शन” के प्रावधान को शामिल किया जाता है।

इस लेख में हम विवेचना करेंगे कि किस प्रकार की स्थितियों में “मान्यता प्राप्त इंस्पेक्शन” लागू होता है, वास्तविक न्यायाधीन स्थितियों के आधार पर।

सिस्टम विकास में क्या होता है स्वीकृति परीक्षण?

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

यदि विकासकर्ता की दृष्टि से देखें, तो यह “क्या यह वास्तव में पूरा हुआ है या नहीं, इसे जांचने” का अर्थ होता है, और इसे टेस्टिंग प्रक्रिया के रूप में स्थापित किया जा सकता है।

IT सिस्टम का विकास करने का काम, व्यापार की प्रकृति के कारण, आदेश देने वाले विक्रेता की विवेकाधिकार भी बड़ा होता है, इसलिए वास्तव में निर्मित प्रोडक्ट और उपयोगकर्ता द्वारा मांगे गए चीजों के बीच में अंतर पैदा हो सकता है।

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

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

मान्यता प्राप्त निरीक्षण की शर्तों पर ध्यान दें

निरीक्षण के चरण में एक बार समस्या उत्पन्न होने पर, उपयोगकर्ता और विक्रेता दोनों को कठिनाई का सामना करना पड़ता है।

उदाहरण के लिए, अगर विक्रेता ने उत्पादन किया है और पहले से ही उत्पाद का प्रदर्शन कर रहा है, लेकिन उपयोगकर्ता के प्रभारी के कारण, निरीक्षण के लिए सहमत नहीं होते हैं, तो क्या होता है?

ऐसी स्थितियों को ध्यान में रखते हुए, सिस्टम विकास के अनुबंध में अक्सर ‘मान्यता प्राप्त निरीक्षण की शर्त’ कही जाने वाली बातें शामिल की जाती हैं।

मान्यता प्राप्त करने की शर्त क्या है

(इस सॉफ्टवेयर की स्वीकृति) धारा 28
वितरित वस्तुओं में से इस सॉफ्टवेयर के लिए, पक्ष A को, व्यक्तिगत अनुबंध में निर्धारित अवधि (नीचे, ‘परीक्षण अवधि’ कहा जाता है।) के भीतर पिछले धारा के परीक्षण विनिर्देशों के आधार पर परीक्षण करना होगा, और सिस्टम विनिर्देश और इस सॉफ्टवेयर के बीच मेल खाता है या नहीं, यह जांचना होगा।

2. पक्ष A, यदि इस सॉफ्टवेयर पिछले धारा के परीक्षण के अनुरूप है, तो परीक्षण पास सर्टिफिकेट पर हस्ताक्षर और मुहर लगाकर पक्ष B को प्रदान करेगा। इसके अलावा, पक्ष A, यदि इस सॉफ्टवेयर पिछले धारा के परीक्षण में पास नहीं होता है, तो पक्ष B को अस्वीकृति के विशिष्ट कारणों को स्पष्ट रूप से दर्शाने वाला दस्तावेज़ तत्परता से प्रदान करेगा, और सुधार या पूरक का अनुरोध करेगा, और जब अस्वीकृति के कारण स्वीकार किए जाते हैं, तो पक्ष B, बातचीत के बाद निर्धारित समय सीमा के भीतर मुफ्त में सुधार करके पक्ष A को प्रदान करेगा, और पक्ष A को आवश्यकतानुसार, पिछले धारा के परीक्षण को फिर से करना होगा।

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

4. इस धारा के परीक्षण पास के साथ, इस सॉफ्टवेयर की स्वीकृति पूरी हो जाती है।

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf[ja]

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

मानना…
→ वास्तविक रूप में यदि वह नहीं है, तो भी कानूनी रूप से उसे वही माना जाता है।

(उदाहरण) यदि आप परीक्षा के दौरान स्मार्टफोन का उपयोग कर रहे थे, तो उसे ‘माना’ जाता है कि आपने धोखाधड़ी की।
→ वास्तव में स्मार्टफोन का उपयोग करने का कार्य धोखाधड़ी हो सकता है या नहीं, धोखाधड़ी के मामले में उसी प्रकार की कार्रवाई होती है।

अनुमान लगाना…
→ जब तक कि विशेष रूप से किसी प्रमाण के विपरीत नहीं होता, उसे तथ्य के रूप में माना जाता है।

(उदाहरण) यदि आप परीक्षा के दौरान स्मार्टफोन को देख रहे थे, तो उसे ‘अनुमान लगाया’ जाता है कि आपने धोखाधड़ी की।
→ मूल रूप से धोखाधड़ी हुई थी, यह निर्णय लिया जाता है, लेकिन यदि आप धोखाधड़ी के अलावा किसी अन्य उपयोग के लिए थे, तो आप उसे खंडन कर सकते हैं, तो यह निर्णय बाद में भी बदल सकता है। (हालांकि, आपको आमतौर पर ऐसा घोषणा सुनने को नहीं मिलेगी परीक्षा केंद्र में।)

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

मान्यता धारा नियम के संबंध में न्यायाधीश के फैसले

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

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

टोक्यो जिला न्यायालय, हेइसेई 24 (2012) फरवरी 29 का फैसला

हालांकि, इसके विपरीत, यहां तक कि यदि यह मान्यता स्वीकृति नियम लागू होता है, तो इसके लागू होने को नकारते हुए, विक्रेता की दुर्योग को मान्यता प्राप्त करने वाले न्यायाधीश के फैसले भी मौजूद हैं।

निम्नलिखित फैसले में, मुद्दा यह था कि, स्वीकृति करने के लिए, विक्रेता की सहायता आवश्यक थी, लेकिन विक्रेता ने ऐसी सहायता देने से इनकार कर दिया, जो पहले के न्यायाधीश के फैसले से अलग था।

प्लेंटिफ (विक्रेता) ने यह तर्क दिया कि, डिफेंडेंट (उपयोगकर्ता) ने, उत्पाद डिलीवरी के दिन से 10 दिन के भीतर जांच के परिणाम की सूचना नहीं दी, इसलिए, सॉफ्टवेयर विकास अनुबंध 9 धारा 4 के अनुसार, उत्पाद को स्वीकृत माना जाता है। हालांकि, ऐसा परिणाम होने के लिए, प्लेंटिफ की सहायता अपरिहार्य थी, जहां प्लेंटिफ ने, डिफेंडेंट के प्रति, ऐसी जांच के लिए सहायता नहीं दी, इसलिए, इस मामले में, डिफेंडेंट ने, उत्पाद डिलीवरी के दिन से 10 दिन के भीतर जांच के परिणाम की सूचना नहीं दी, इसलिए, सॉफ्टवेयर विकास अनुबंध 9 धारा 4 के अनुसार, डिफेंडेंट ने सॉफ्टवेयर को स्वीकृत माना जाता है, ऐसा नहीं है।

टोक्यो जिला न्यायालय, हेइसेई 16 (2004) जून 23 का फैसला

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

इस प्रकार, ऐसे उद्देश्य से बहुत दूर, “मान्यता स्वीकृति धारा को ढाल बनाकर, समय बचाने की कोशिश करते हुए, स्वीकृति को लंबित करने की कोशिश करते हुए, खराब उत्पाद भी धकेल दें” ऐसी बात नहीं हो सकती।

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

ऐसे निर्णय का समर्थन करने वाले तत्वों में, अनुबंध के अलावा, सिस्टम विकास की प्रगति के साथ-साथ मीटिंग के मिनट्स भी महत्वपूर्ण साक्ष्य हो सकते हैं। इसके बारे में निम्नलिखित लेख में विस्तार से विवेचना की गई है।

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

स्वीकृति कार्य को मूल रूप से उपयोगकर्ता के द्वारा करना चाहिए, लेकिन विक्रेता भी सिस्टम विकास के विशेषज्ञ के रूप में, स्वीकृति के प्रति विभिन्न सहयोग करना चाहिए, इस बात को, निम्नलिखित लेख की सामग्री को ध्यान में रखते हुए, यह बहुत ही स्वाभाविक बात होगी।

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

स्वीकृति के दौरान दोष का पता चलने के पैटर्न

हालांकि, स्वीकृति के चरण में, सिस्टम की कमियों (कानूनी भाषा में इसे ‘दोष’ कहा जाता है) का पता चल सकता है। इस मामले में कानूनी समस्याओं के बारे में, कृपया नीचे दिए गए लेख का संदर्भ लें।

https://monolith.law/corporate/defect-warranty-liability[ja]

सारांश

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

और यदि स्वीकृति सुचारू रूप से नहीं होती है, ऐसी स्थिति की कल्पना करते हुए, अनुबंध के पूर्वावलोकन से ही, दोनों पक्षों को स्वीकृति से संबंधित नियमों के बारे में विशेष रूप से, समझदारी से मेल खाने की प्रक्रिया को ध्यानपूर्वक करना महत्वपूर्ण होता है।