प्रणाली विकासमा पुरानो प्रणालीबाट सार्ने क्रममा आउने कानूनी समस्याहरु

नयाँ IT प्रणालीहरू विकास गर्नु IT इन्जिनियरहरूको प्रमुख कार्यक्षेत्र हो, तर जब “नयाँ प्रणाली निर्माण गर्ने” कुरा आउँछ, यसमा धेरै पटक “पुरानो प्रणाली हटाउने” प्रक्रिया पनि समावेश हुन्छ। यस लेखमा, हामी नयाँ प्रणाली विकासको परियोजनालाई पुरानो प्रणाली हटाउने दृष्टिकोणबाट पुनः अवलोकन गर्दै, त्यससँग सम्बन्धित विभिन्न कानूनी समस्याहरूको विश्लेषण गर्नेछौं।

नयाँ प्रणालीमा संक्रमण के हो?

आईटी प्रणालीको आयु सधैंको लागि हुँदैन

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

१० वर्षको अवधिमा, बजारमा उपलब्ध कम्प्युटरहरूको प्रदर्शन पनि परिवर्तन हुन्छ। यस्तो अवस्थामा, १० वर्ष अघि जुन कार्यक्रमहरू मानवीय दृष्टिकोणबाट सरल र उत्कृष्ट डिजाइन भए पनि कम्प्युटरको प्रोसेसिङ गतिको सीमाले कार्यान्वयन गर्न अव्यावहारिक थियो, ती अहिले कार्यान्वयन गर्न सकिन्छ। यदि एउटा प्रणालीलाई १० वर्षसम्म प्रयोग गरिएको छ भने, त्यस अवधिमा कम्पनीका कार्य प्रवाह र आन्तरिक नियमहरू पनि धेरै परिवर्तन भएका हुन सक्छन्। यस्ता कम्पनीका आन्तरिक र बाह्य व्यवस्थापन परिवर्तनहरूलाई समायोजन गर्न बादमा कार्यान्वयन गरिएका कोडहरू स्क्रिनबाट हेर्दा चिन्न नसकिने गरी जटिल र जथाभावी बनेका हुन सक्छन्। यस्तो अवस्थामा, प्रयोगकर्ताहरूले थप्न चाहने सुविधाहरू भए पनि, विकासकर्ताहरूको दृष्टिकोणबाट थप कार्यान्वयन गर्न असम्भव हुन सक्छ।

पुरानो भएका प्रणालीहरूले आईटी इन्जिनियरहरूलाई धेरै ‘म्यानुअल काम’ (उदाहरणका लागि, व्यक्तिगत डाटा निकाल्नका लागि क्वेरीहरू जारी गर्ने जस्ता सञ्चालन कार्यहरू) गर्न बाध्य पार्न सक्छ। प्रणाली स्वयं पनि, पुरानो भएसँगै विडम्बनापूर्वक कार्यलाई ‘व्यक्तिगत’ बनाउँदै जान्छ। धेरै पुरानो भएर, व्यक्तिगत कार्यहरू बढ्दै गएका प्रणाली सम्बन्धित कार्यहरूमा थप ‘प्रणालीकरण’का उपायहरू अपनाउने क्रममा, ‘पुरानो प्रणालीबाट नयाँ प्रणालीमा सार्ने’ परियोजना सुरु हुन्छ।

नयाँ प्रणालीको विकास जापानमा पुरानो प्रणालीको हटाइसँगै अगाडि बढ्दैछ

यसअघि उल्लेख गरिएको छ कि (सबै प्रणाली विकास परियोजनाहरूमा यो लागू हुँदैन तर) एक प्रणाली विकास परियोजनामा प्रायः पुरानो प्रणालीबाट सार्ने पक्ष पनि समावेश हुन्छ। प्रणाली आफैंमा कुनै विशेष दिनमा अचानक परिवर्तन हुन सक्छ।

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

नयाँ प्रणालीमा संक्रमणका चरणहरू

पुरानो प्रणालीबाट नयाँ प्रणालीमा संक्रमण गर्दा विशेष गरी महत्वपूर्ण हुने कुरा डाटा उपयुक्त रूपमा सार्नु हो। डाटा सार्ने क्रममा अपनाइने चरणहरू सामान्यतया निम्नानुसार हुन्छ:

1. पुरानो प्रणालीले भण्डारण गरेको डाटामध्ये कुन डाटा नयाँ प्रणालीमा सार्नुपर्छ भन्ने कुरा स्पष्ट पार्नुपर्छ → नयाँ प्रणालीको स्क्रिनमा सजिलै खोजी गर्न सकिने डाटा कुन हो, र स्क्रिनबाट खोजी गर्न नसकिए पनि (लेखा परीक्षण आदि को समयमा) आवश्यकता अनुसार निकाल्न सकिने डाटा कुन हो भन्ने विभाजन पनि आवश्यक छ।
2. १ मा चिन्हित डाटाहरूमध्ये नयाँ प्रणालीमा लिनुपर्ने डाटा CSV फाइल जस्ता फर्म्याटमा निर्यात गर्नुहोस्।
3. २ मा निकालिएको डाटा नयाँ प्रणालीमा लिनुहोस्।
4. ३ बाट लिइएको डाटा नयाँ प्रणालीमा कसरी प्रतिबिम्बित भएको छ भनेर जाँच गर्नुहोस्, र डाटा सही रूपमा सारिएको छ कि छैन भन्ने कुरा पुष्टि गर्नुहोस्। → सही रूपमा सारिएको छ कि छैन भन्ने जाँचको नतिजा सामान्यतया स्क्रिनको प्रदर्शन स्क्रिन वा चलानी प्रिन्ट मार्फत दस्तावेजीकरण गरिन्छ (यसलाई परीक्षण प्रक्रिया भनिन्छ)।

नयाँ प्रणालीमा सार्ने क्रममा प्रयोगकर्ता र विक्रेताको भूमिका व्यवस्थापन गर्न गाह्रो

डाटा सार्ने प्रक्रियामा अक्सर सामना गरिने समस्या यो हो कि प्रयोगकर्ताहरूले यसलाई कति सम्म आफ्नो आन्तरिक समस्या को रूपमा हेर्ने र नियन्त्रणमा राख्ने भन्ने कुरा हो। डाटा सार्ने विषयमा मात्र होइन, सिस्टम विकासका सम्पूर्ण परियोजनाहरूमा प्रयोगकर्ताको सहयोगको अनिवार्यताको विषयमा थप जानकारीका लागि तलको लेख हेर्नुहोस्।

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

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

बाहिरी स्रोतमा नभरी, यदि पुरानो सिस्टमको कुरा आफ्नै भित्रबाट सम्भव छ भने, नयाँ सिस्टमको कुरा मात्र विक्रेतालाई बाहिरी स्रोतमा दिने विचारले आदेश दिइन्छ। यसरी, डाटा सार्ने काममा, प्रयोगकर्ता र विक्रेता, दुवैको भूमिका व्यवस्थापन कहिलेकाहीँ अस्पष्ट हुन सक्छ। यदि प्रयोगकर्ताले विक्रेतालाई सिस्टम विकास सम्बन्धी काम बाहिरी स्रोतमा दिन्छ भने, सामान्यतया विक्रेताबाट के प्रकारको भूमिका अपेक्षित छ र कुन प्रकारका कानूनी दायित्वहरू लागू हुन्छन् भन्ने बारेमा सामान्य विवरणका लागि तलको लेख पनि हेर्नुहोस्।

नयाँ प्रणालीमा संक्रमणसँग सम्बन्धित पुराना न्यायिक निर्णयहरू

नयाँ प्रणालीमा संक्रमण गर्ने उद्देश्यले गरिएको प्रणाली विकास परियोजनामा वास्तवमा समस्या उत्पन्न भएको छ र मुद्दा समेत भएको छ। तल उल्लेख गरिएको निर्णय पाठमा, डाटा संक्रमणको समयमा संक्रमण कार्य असफल भएको छ, नयाँ प्रणालीमा विभिन्न डाटाहरूको असंगति र बगहरू उत्पन्न भएका छन्, र डेलिभरीमा पनि ढिलाइ भएको छ। यस्ता विभिन्न समस्याहरूको सामना गर्दा, वेन्डर पक्ष र प्रयोगकर्ता पक्षले आफ्नो परियोजनामा कस्तो कर्तव्य बहन गर्नुपर्ने भन्ने विषय विवादित बनेको थियो। निष्कर्षमा, वेन्डर पक्षले बहन गर्नुपर्ने मूल ध्यान दिनुपर्ने कर्तव्यको रूपमा तलका सामग्रीहरू निर्दिष्ट गरिएको छ, र वेन्डर पक्षको ध्यान दिने कर्तव्यको उल्लंघन स्वीकार गरिएको छ।

प्रतिवादीले, यस अनुबंध अनुसारको डाटा संक्रमण सेवाको रूपमा, यस पुरानो प्रणालीमा रहेको डाटालाई केवल नयाँ प्रणालीमा सार्ने काममा सीमित नरही, नयाँ प्रणालीलाई सञ्चालन गर्ने दायित्व, विशेष गरी, डाटा संक्रमण कार्य सुरु गर्नु अघि, पुरानो प्रणालीमा रहेको संक्रमणको लक्ष्य डाटालाई अनुसन्धान र विश्लेषण गर्नुपर्छ, डाटाको प्रकृति र स्थिति बुझ्नुपर्छ, र त्यस डाटा संक्रमण पछि नयाँ प्रणालीमा सञ्चालनको बाधा बन्न सक्छ कि भन्ने कुरा अध्ययन गर्नुपर्छ, र बाधा बन्ने हो भने, कहिले, कसरी त्यस डाटालाई सच्याउने भन्ने कुरा निर्णय गर्नुपर्छ, र त्यसपछि मात्र डाटा संक्रमण कार्य (संक्रमण डिजाइन, संक्रमण उपकरण विकास, डाटा संक्रमण)मा लाग्नुपर्छ, र अन्ततः, पुरानो प्रणालीबाट सारिएको डाटाले नयाँ प्रणालीलाई सञ्चालन गर्ने दायित्व बहन गरेको छ।

टोक्यो जिल्ला अदालत, हेइसेइ (2016) नोभेम्बर 30

यो मामला यस्तो थियो जहाँ प्रक्रिया 1 र 4 लाई प्रयोगकर्ता पक्षले सम्हालेको थियो र प्रक्रिया 2 र 3 लाई वेन्डर पक्षले सम्हालेको थियो। अर्थात्, पुरानो प्रणालीबाट डाटा निकाल्ने काम (प्रक्रिया 2) वेन्डर पक्षले पहिलो पटक सम्हालेको थियो। त्यसैले अदालतले पनि, डाटा निकाल्ने काम सम्म वेन्डरले सम्हालेको भए, त्यस कामले सहज रूपमा सम्पन्न हुन सक्छ कि नसक्छ भन्ने कुरा पनि पहिले नै अध्ययन गर्नुपर्ने थियो भन्ने निर्णय गरिएको थियो।

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

यस्तो निर्णय अनुबंध पत्र मात्र होइन, प्रणाली विकासको प्रगतिसँग मेल खाने मिनट्सहरू पनि प्रमाणको रूपमा लिइन्छ। मिनट्सको महत्वको बारेमा तलको लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।

सारांश

सिस्टम विकासको परियोजना यस्तो हो जहाँ प्रयोगकर्ता र विक्रेता दुवै पक्षले आपसमा धेरै कर्तव्यहरू बहन गर्दै, कडा संवादका साथ अगाडि बढ्नु पर्ने हुन्छ। त्यसैले यसअघि उल्लेखित न्यायिक निर्णयमा पनि, मात्र केही पूर्वाधारका शर्तहरूमा सानो परिवर्तन गर्दा पनि, दोषारोपणको लक्ष्य प्रयोगकर्ता र विक्रेता दुवै पक्षमा सजिलै पल्टिन सक्छ।

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