सिस्टम विकास परियोजनाओं में व्यवसायिक लक्ष्यों और संख्यात्मक लक्ष्यों का कानूनी अर्थ क्या है?

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

सिस्टम विकास के उद्देश्य और लक्ष्य संघर्ष का कारण क्यों बनते हैं?

यह समस्या उपयोगकर्ता के सहयोग के दायित्व और विक्रेता की विवेकाधिकार के बीच स्थित है

व्यापार लेन-देन के रूप में देखने पर, सिस्टम विकास परियोजनाओं में कुछ विशेषताएं होती हैं। एक बात यह है कि, सिस्टम विकास परियोजना को विक्रेता द्वारा अकेले नहीं किया जा सकता, इसमें उपयोगकर्ता की सहायता की आवश्यकता होती है। इस दायित्व की मौजूदगी को “सहयोग का दायित्व” के नाम से न्यायिक कानून में स्पष्ट रूप से मान्यता प्राप्त है। मुख्य रूप से, यह उपयोगकर्ता से भी मांगी जाती है कि वे ① आवश्यकता परिभाषा ② मूल डिजाइन ③ परिणामस्वरूप की स्वीकृति आदि के चरणों में सिस्टम विकास में सहयोग करें।

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

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

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

ऊपर की बातों को संक्षेप में कहें तो, यहां दो महत्वपूर्ण बातें उल्लेखनीय हैं।

• उपयोगकर्ता को, विक्रेता को उचित जानकारी प्रदान करने की और विक्रेता के विकास कार्य में सहयोग करने की आवश्यकता होती है।
• विक्रेता को, उपयोगकर्ता के परियोजना के उद्देश्य और लक्ष्यों को समझने की और उससे मेल खाने वाले प्रयास करने की आवश्यकता होती है।

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

उपयोगकर्ता के लक्ष्यों का परियोजना पर प्रभाव पड़ने वाले विशेष स्थितियाँ

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

• कर्मचारी वेतन की कमी के कारण बचत
• बिक्री या लाभ की वृद्धि
• कार्य समय की कमी

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

उपयोगकर्ता द्वारा उठाए गए व्यवस्थापन लक्ष्यों को समस्या मानने वाले न्यायाधीन मामले क्या हैं

हालांकि, विक्रेता सामान्यतः केवल सिस्टम विकास के विशेषज्ञ होते हैं। यदि उपयोगकर्ता के व्यवस्थापन लक्ष्यों के प्रति सभी जिम्मेदारियां उनपर डाली जाती हैं, तो यह बहुत ही कठिन हो सकता है।

उन मामलों में जिनमें व्यापार की गति को बढ़ाने का लक्ष्य रखा गया था

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

• मानव द्वारा की गई हस्तलिखित प्रविष्टियों का समय 50% कम करना
• निर्धारित समयावधि के भीतर आईटी सिस्टम का उपयोग करके कार्यालय की कार्यवाही को पूरा करना

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

और, (मध्य लोप) वाद-विवाद के पूरे परिप्रेक्ष्य में, ① मूल उद्देश्य “व्यापार की क्षमता बढ़ाना” “CRM का आधार बनाना” “दृश्य प्रबंधन करना” आदि सामान्य चीजें हैं, और लक्ष्य मूल्य भी, “ग्राहकों से संपर्क बढ़ाना” “कार्यालय के कर्मचारियों की मेहनत को आंतरिक नियंत्रण और विपणन सहायता में विभाजित करना” “बिक्री का अनुमान अधिक सटीक बना सकता है” “अत्यधिक बिक्री मूल्य कम करना” आदि, सामान्य चीजें अधिक हैं और “इनपुट समय को 50% कम करना” “अनुमानित समय को 50% कम करना” “कानूनी प्रकटीकरण कानूनी दिनों के भीतर कर सकता है” आदि लक्ष्य मूल्य SBO के परिचालन के बाद प्रतिवादी के प्रबंधन और व्यापार के तरीके पर निर्भर करते हैं और पैकेज सॉफ्टवेयर का परिचालन सहायता करने वाली सिस्टम विकास कंपनी के रूप में मुद्दाकर्ता, उसकी प्राप्ति का दायित्व ले सकती है ऐसी प्रकृति की चीज नहीं है ② मूल प्रोजेक्ट की किकऑफ के बाद की मीटिंग की मिनट्स में, मूल उद्देश्य और लक्ष्य मूल्य की प्राप्ति के बारे में विशेष रूप से बातचीत की गई थी, ऐसा कोई उल्लेख नहीं है ③ मूल प्रोजेक्ट योजना में, “सूचीबद्ध कंपनी बनने के लिए” आदि, जो स्वयं अनुबंध की प्रकृति की चीज है, ऐसा व्यक्त करने वाली अभिव्यक्ति का उपयोग किया गया है (मध्य लोप) इन सब बातों को ध्यान में रखते हुए, मुद्दाकर्ता ने प्रतिवादी की व्याख्या के आधार पर मूल प्रोजेक्ट योजना में मूल उद्देश्य का वर्णन तैयार किया था, यह माना जाता है कि मूल प्रोजेक्ट असफल न हो, मूल प्रोजेक्ट के उद्देश्य और परिणामों के बारे में साझा समझ को प्राप्त करने के लिए और प्रतिवादी को, मुद्दाकर्ता के प्रति, मूल उद्देश्य को पूरा करने के लिए सिस्टम विकास का ठेका दिया था, ऐसा मानने की अनुमति नहीं है। (मध्य लोप) इसलिए, मुद्दाकर्ता ने प्रतिवादी से मूल उद्देश्य को पूरा करने के लिए सिस्टम विकास का ठेका लिया था, ऐसा माना नहीं जा सकता, (मध्य लोप) ऋण अव्याहृत जिम्मेदारी और दोष गारंटी जिम्मेदारी के दावे का कोई आधार नहीं है।

टोक्यो जिला न्यायालय, हेइसेई 22 (2010) दिसंबर 28

न्यायिक उदाहरणों से प्राप्त व्यवस्थापन लक्ष्य और संख्यात्मक लक्ष्यों का कानूनी अर्थ क्या है

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

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

ऐसा माना गया है कि ऐसी मूल्यांकन कानूनी रूप से स्वीकार की जाती है।

इस फैसले से और क्या समझा जा सकता है

इस फैसले में अन्य कुछ दिलचस्प बातें भी शामिल हैं।

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

वैसे, सिस्टम विकास परियोजनाओं के साथ जुड़े कानूनी मुद्दों के बारे में, दस्तावेज़ प्रबंधन और कार्यवाही की महत्वता के दृष्टिकोण से, निम्नलिखित लेख में विवरण दिया गया है।

https://monolith.law/corporate/the-minutes-in-system-development[ja]

व्यवस्थापन लक्ष्य और संख्यात्मक लक्ष्यों के आसपास कानूनी मुद्दों के विभिन्न ध्यान देने योग्य बिंदु

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

कंसल्टिंग का शुल्क या मुफ्त होने पर भी बात बदल सकती है

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

उत्पाद की कमियों और फ़ंक्शन और स्पेसिफिकेशन आवश्यकताओं की अनुरूपता अलग मुद्दा है

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

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

अन्य संबंधित विषयों में, आवश्यकताओं में शामिल नहीं होने के बावजूद, विक्रेता के पक्ष की विचारधारा के अनुसार कार्यान्वयन करने की जिम्मेदारी मानी जाती है। इसके बारे में निम्नलिखित लेख में विस्तार से व्याख्या की गई है।

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

इन सभी मामलों में, “उद्देश्य” और “लक्ष्य” के आसपास के विवाद को समान लेकिन अलग समझना चाहिए।

जिम्मेदारी और समझौते जैसे विषयों के प्रति मूलभूत समझ भी मांगी जाती है

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

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