सिस्टम विकास के आदेशकर्ता यानी उपयोगकर्ता पक्ष की सहयोग की जिम्मेदारी क्या होती है

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

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

इस लेख में, हम विकास के लिए वेंडर पर ही निर्भर नहीं होने वाले सिस्टम विकास के बारे में बात करेंगे, और आदेश देने वाले के पास कौन से कानूनी दायित्व होते हैं, इसके बारे में विवरण देंगे।

यदि यह आपकी स्वयं की सिस्टम है, तो सब कुछ ‘पूरी तरह से डालना’ उचित नहीं होगा

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

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

इसलिए, उपयोगकर्ता की ओर से “मैं आईटी तकनीक का विशेषज्ञ नहीं हूं” के कारण स्वीकार करने के बजाय, बल्कि सूचना प्रदान करने में सक्रिय रहने से, परियोजना की प्रगति सुचारू रूप से हो सकती है। इस मायने में, सिस्टम विकास परियोजना में उपयोगकर्ता की ओर से निभाई जा रही भूमिका वास्तव में बिल्कुल छोटी नहीं होती है।

उपयोगकर्ता की सहयोग की जिम्मेदारी क्या होती है, अदालती फैसलों को ध्यान में रखते हुए

तो विस्तार से, सिस्टम विकास परियोजना में, उपयोगकर्ता की ओर से सहयोग की जिम्मेदारी क्या होती है? इस बारे में, पिछले अदालती फैसलों में कई संकेत मिलते हैं।

अदालत में, विक्रेता (प्रतिवादी) की तरफ से समय सीमा में विलंब के मामले में, उपयोगकर्ता (मुद्दायी) के निर्णय लेने में देरी आदि के कारण, उपयोगकर्ता की विकास में सहयोग की जिम्मेदारी का मुद्दा उठा। इस मामले पर अदालत ने, उपयोगकर्ता की ओर से सहयोग की जिम्मेदारी का उल्लंघन मानते हुए, विक्रेता की दायित्व अधिनियम की जिम्मेदारी को नकार दिया। (समझौते के रद्द करने के बारे में मान्यता मिली, लेकिन इसमें भी 60% दोष का कटौती स्वीकार की गई।)

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

टोक्यो जिला अदालत, हेइसेई 16 (2004) मार्च 10 का फैसला

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

चलिए प्रयास करते हैं कि उपरोक्त फैसला के शब्दों को, सिस्टम विकास के IT शब्दों में अनुवाद करें।

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

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

बाद में स्पेसिफिकेशन बदलने की अनुरोध कैसे समझी जाती है

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

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

इस प्रकार के मामलों में, यदि समय सीमा में नहीं मिलता है, तो हम कैसे सोचेंगे। पिछले निर्णयों को पढ़ने से, अतिरिक्त कार्य के उत्पन्न होने के समय के आधार पर निष्कर्ष में अंतर हो सकता है।

यदि अतिरिक्त कार्य बाहरी डिजाइन आदि की स्पष्टता से पहले था

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

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

टोक्यो जिला न्यायालय, हेइसेई 16 (2004) मार्च 10 का निर्णय

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

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

यदि अतिरिक्त कार्य निर्माण या परीक्षण कार्यक्रम की स्पेसिफिकेशन की पुष्टि के बाद था

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

हालांकि, स्पेसिफिकेशन की पुष्टि के बाद आदेश सामग्री को बदलने या जोड़ने का काम, कार्य को फिर से करने की संभावना को बढ़ाता है। इस प्रकार के मामलों में, “वह ग्राहक है, इसलिए वह अनेक आवश्यकताएं उठाता है, यह स्वाभाविक है” का समर्थन करना कठिन हो सकता है। इसके अलावा, बहुत सारे स्पेसिफिकेशन परिवर्तन या कार्यक्षमता जोड़ने की स्थिति बाद में उत्पन्न होती है, जो वास्तव में पहले ही पूरा हो चुका होता है, बुनियादी डिजाइन आदि के ऊपरी कार्यक्रम में भी उपयोगकर्ता की सहयोग की गड़बड़ी हो सकती है।

इन बातों से भी, स्पेसिफिकेशन की एक बार पुष्टि हो जाने के बाद किए गए स्पेसिफिकेशन परिवर्तन के बारे में, यदि वह कारण होता है कि समय सीमा में देरी होती है, तो विक्रेता की जिम्मेदारी को मान्यता देना वास्तविक नहीं होता है। पहले के निर्णय पाठ से, इस प्रकार की अर्थ भी समान रूप से पढ़ना उचित होगा।

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

संबंधित लेख: सिस्टम विकास में मीटिंग के नोट्स को कानूनी दृष्टिकोण से कैसे देखा जाता है[ja]

सारांश: यह महत्वपूर्ण है कि हम यह न भूलें कि आवश्यकता परिभाषा उपयोगकर्ता की प्रक्रिया है

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

यदि उपयोगकर्ता का सहयोग विकास प्रक्रिया में नहीं है, तो यहां तक कि यदि परियोजना जल जाती है, तो न्यायालय उपयोगकर्ता की ओर से कठोर दृष्टिकोण रख सकता है। इस बात को पहले ही समझ लेना चाहिए।