MONOLITH LAW OFFICE+81-3-6262-3248काम करने के दिन 10:00-18:00 JST [Englsih Only]

MONOLITH LAW MAGAZINE

IT

सिस्टम विकास में पुराने सिस्टम से हस्तांतरण के साथ जुड़े कानूनी मुद्दे

IT

सिस्टम विकास में पुराने सिस्टम से हस्तांतरण के साथ जुड़े कानूनी मुद्दे

एक नई आईटी सिस्टम बनाना कंपनियों में आईटी इंजीनियरों का प्रमुख कार्यक्षेत्र है, हालांकि, “नई सिस्टम बनाने” के मामले में, यहां “पहले से इस्तेमाल की जा रही सिस्टम को समाप्त करने” की प्रक्रिया भी अक्सर समाविष्ट होती है। इस लेख में, हम नए सिस्टम के विकास के परियोजना को “पुराने सिस्टम के समापन” के दृष्टिकोण से पुनः पकड़ने का प्रयास करेंगे, और इससे संबंधित विभिन्न कानूनी मुद्दों पर चर्चा करेंगे।

नए सिस्टम में स्थानांतरित होना क्या होता है

आईटी सिस्टम की आयु हमेशा के लिए नहीं होती

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

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

पुराने सिस्टम धीरे-धीरे आईटी इंजीनियरों को अधिक “मैनुअल काम” (उदाहरण के लिए, डेटा को व्यक्तिगत रूप से निकालने के लिए क्वेरी जारी करने जैसे ऑपरेशनल कार्य) करने के लिए मजबूर कर सकते हैं। सिस्टम भी, जब यह पुराना हो जाता है, तो व्यंग्यात्मक रूप से कार्य को “व्यक्तिगत” बना देता है। जब पुराने हो जाने के कारण, व्यक्तिगत कार्य बढ़ने लगते हैं, तो सिस्टम संबंधी कार्यों के प्रति, अधिक “सिस्टमतिक” उपाय लागू करने की कोशिश की जाती है, तब “पुराने सिस्टम से स्थानांतरण के लिए नए सिस्टम का विकास” नामक परियोजना शुरू होती है।

नई सिस्टम की विकास यात्रा, पुराने सिस्टम के उन्मूलन के साथ साथ चलती है

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

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

नए सिस्टम में स्थानांतरण के चरण क्या हैं

पुराने सिस्टम से नए सिस्टम में स्थानांतरण के महत्वपूर्ण कदम क्या हैं?

पुराने सिस्टम से नए सिस्टम में स्थानांतरण करते समय, विशेष रूप से महत्वपूर्ण होता है कि डेटा को उचित रूप से स्थानांतरित किया जाए। डेटा स्थानांतरण के चरण आमतौर पर निम्नलिखित प्रक्रिया के अनुसार होते हैं।

  1. पुराने सिस्टम में संग्रहीत डेटा में से, नए सिस्टम में स्थानांतरित करने योग्य डेटा को स्पष्ट रूप से निर्धारित करें → नए सिस्टम की स्क्रीन से आसानी से खोजने योग्य डेटा कौन सा है, और, स्क्रीन से खोजने की आवश्यकता नहीं होने पर भी (जैसे कि ऑडिट के दौरान) जरूरत पड़ने पर निकालने के लिए डेटा कौन सा होना चाहिए, इसका विभाजन भी आवश्यक होता है।
  2. पहले चरण में निर्धारित डेटा में से, नए सिस्टम में ले जाने योग्य डेटा को, CSV फ़ाइल आदि के रूप में निर्यात करें।
  3. दूसरे चरण में निकाले गए डेटा को, नए सिस्टम में ले जाएं।
  4. तीसरे चरण में ले जाए गए डेटा की, नए सिस्टम में प्रतिबिंबित हो रही है या नहीं, इसकी जांच करें, और सही रूप से स्थानांतरण हुआ है या नहीं, इसकी पुष्टि करें। → सही रूप से स्थानांतरण हुआ है या नहीं, इसकी जांच के परिणाम को, स्क्रीन पर प्रदर्शित होने वाले डिस्प्ले या प्रिंट आउट के माध्यम से, साक्ष्य दस्तावेज़ के रूप में बचा जाता है (जिसे टेस्ट प्रक्रिया कहते हैं)।

नई सिस्टम में स्थानांतरण उपयोगकर्ता और विक्रेता की भूमिका की व्यवस्था करना कठिन है

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

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

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

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

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

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

नए सिस्टम में स्थानांतरण से संबंधित पिछले न्यायाधीन मामले

सिस्टम स्थानांतरण परियोजना में मुकदमे की संभावना भी होती है।

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

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

यह मान्य है, और इस मामले में, डाटा स्थानांतरण के दौरान, डाटा असंगतता को सही करने और दूर करने का दायित्व लेना चाहिए।

टोक्यो जिला न्यायालय, हेसी 28 (2016) नवंबर 30

इस मामले में, क्रम 1 और क्रम 4 को उपयोगकर्ता ने स्वीकार किया था, और क्रम 2 और क्रम 3 को विक्रेता ने स्वीकार किया था। यानी, पुराने सिस्टम से डाटा निकालने (क्रम 2) को विक्रेता ने एक बार स्वीकार किया था। इसलिए, न्यायालय ने भी निर्णय दिया कि, यदि विक्रेता ने डाटा निकालने का कार्य स्वीकार किया है, तो उस डाटा निकालने का कार्य सही ढंग से किया जा सकता है या नहीं, इसे भी समेतकर पहले से ही विचार किया जा सकता था।

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

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

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

सारांश

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

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

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

ऊपर लौटें