कानूनी दृष्टिकोणबाट, प्रणाली विकासमा परिवर्तन व्यवस्थापन कसरी गर्ने?

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

जापानमा परिवर्तन व्यवस्थापन दस्तावेज प्रयोग गरिने अवस्थाहरू
परिवर्तन व्यवस्थापन दस्तावेज भनेको प्रयोगकर्ताले विक्रेता (vendor) लाई पहिले गरिएको व्याख्याको सामग्रीबाट, विशिष्टताको परिवर्तन वा कार्यक्षमताको थपको लागि अनुरोध गर्दा प्रयोग गरिने कागजात हो। पहिले उल्लेख गरिएझैं, आवश्यकताहरूको परिभाषा र आधारभूत डिजाइन जस्ता चरणहरूमा, प्रयोगकर्ताले पनि विक्रेताको काममा सहयोग गर्ने दायित्व वहन गर्छन्, तर त्यसपछि फरक मागहरू उठाउने कुरा व्यावहारिक रूपमा हुन सक्छ।
परिवर्तन व्यवस्थापन दस्तावेज आवश्यक पर्ने अवस्थाहरूको उदाहरण दिनुपर्दा, जस्तै:
- आवश्यकता परिभाषा वा आधारभूत डिजाइनमा विचारमा छुट भएको छ, र पछि कार्यक्षमता थपको अनुरोध गरिन्छ।
- विकासको क्रममा, व्यवसायको नीति आदिमा पुनरावलोकन गरिन्छ, र विशिष्टताको परिवर्तन आवश्यक हुन्छ।
आदि विचार गर्न सकिन्छ।
यद्यपि, कार्यक्षमता थप्ने वा विशिष्टता परिवर्तन गर्ने जस्ता विषयहरूमा सम्बन्धित कुरा गर्दा, काम लिने पक्षको लागि सबैभन्दा चासोको विषय भनेको अनुमानित रकमको परिवर्तन कानूनी रूपमा मान्य छ कि छैन भन्ने कुरा हो। यस बिषयमा, अर्को लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।
यस्ता पछिल्लो अनुमानको वृद्धि गर्दा, त्यसको सामग्रीको अनुमानको उपयुक्तता मापन गर्नको लागि आधार बन्ने कुरा परिवर्तन व्यवस्थापन दस्तावेज हो। पछि वृद्धि गरिएको अनुमानको आधारमा दाबी गर्दा, विपक्षीसँग विवाद नहोस् (र विवाद भएमा आफ्नो तर्कलाई विश्वासिलो बनाउनको लागि पनि), परिवर्तन व्यवस्थापन दस्तावेजको निर्माण महत्त्वपूर्ण हुन्छ।
जापानमा परिवर्तन व्यवस्थापन दस्तावेजमा समावेश गर्नुपर्ने विवरणहरू
तपाईंलाई थाहा छ, जापानी कानुन अन्तर्गत, परिवर्तन व्यवस्थापन दस्तावेजमा के-कस्ता विवरणहरू समावेश गर्नुपर्छ? परिवर्तन व्यवस्थापन दस्तावेजको प्रयोग गरेर, विशिष्टता परिवर्तन र कार्यक्षमता थप्ने सम्झौताको प्रणाली पहिले नै सामान्य रूपमा व्यापक रूपमा मान्यता प्राप्त छ। त्यसैले, जापानको अर्थव्यवस्था, व्यापार र उद्योग मन्त्रालय (METI) द्वारा प्रस्तावित मोडेल सम्झौताहरू जस्ता सरकारी निकायहरूले देखाएका सम्झौता धाराहरूको नमूना जाँच गरेर, कुन विवरणहरू रेकर्डको रूपमा राख्नुपर्छ भन्ने कुरा प्रायः थाहा हुन्छ।
(परिवर्तन व्यवस्थापन प्रक्रिया)
धारा 37:甲 वा 乙 ले, यदि तिनीहरूले धारा 34 (प्रणाली विशिष्टता परिवर्तन), धारा 35 (मध्यवर्ती सामग्रीको प्रयोगकर्ता द्वारा अनुमोदन), धारा 36 (अविचारित विषयहरूको व्यवस्थापन) अन्तर्गत प्रस्तावित परिवर्तन प्रस्ताव प्राप्त गरेमा, उक्त प्राप्त मितिबाट ○ दिन भित्र, निम्न विवरणहरू समावेश गरिएको दस्तावेज (यसपछि ” परिवर्तन व्यवस्थापन दस्तावेज” भनिन्छ) लाई अर्को पक्षलाई हस्तान्तरण गर्नुपर्छ, र 甲 र 乙 ले धारा 12 मा निर्दिष्ट गरिएको सम्पर्क परामर्श समितिमा उक्त परिवर्तनको सम्भाव्यता बारे छलफल गर्नुपर्छ।
① परिवर्तनको नाम
② प्रस्तावको जिम्मेवार व्यक्ति
③ मिति
④ परिवर्तनको कारण
⑤ परिवर्तनको विवरण, जसमा परिवर्तनको विशिष्टता समावेश छ
⑥ परिवर्तनको लागि लागत आवश्यक भएमा, त्यसको रकम
⑦ पुनरावलोकन अवधि सहितको परिवर्तन कार्यको तालिका
⑧ अन्य परिवर्तनहरूले यस सम्झौता र व्यक्तिगत सम्झौताका सर्तहरू (कार्य अवधि वा डेलिभरी मिति, शुल्क, सम्झौता धाराहरू आदि) मा पार्ने प्रभाव
प्रत्यक्ष रूपमा धारा पढेर, समावेश गर्न सिफारिस गरिएका वस्तुहरू पुष्टि गरेपछि, थप व्याख्या आवश्यक छैन। पछि “भनेको-नभनेको” को समस्या नहोस् भन्नको लागि, परिवर्तनको इतिहासलाई विस्तृत र ठोस रूपमा रेकर्ड गर्नुपर्छ।
यस्ता विवरणहरू स्पष्ट रूपमा उल्लेख गरेर, विक्रेता र प्रयोगकर्ता दुवैका जिम्मेवार व्यक्ति वा निर्णयकर्ताको हस्ताक्षर वा छापसँग सेट गरिएमा, यदि कुनै बेला मुद्दा चल्नुपर्ने स्थिति आएमा, यो प्रमाणको रूपमा सम्झौतासँग समान महत्व राख्नेछ।
जापानमा परिवर्तन व्यवस्थापनसँग सम्बन्धित जान्नुपर्ने कुराहरू

परिवर्तन व्यवस्थापन प्रायः मुद्दा व्यवस्थापनसँगै गरिनु पर्छ
परिवर्तन व्यवस्थापन दस्तावेज तयार पार्नुको कारण भनेको परिवर्तनको इतिहासलाई व्यवस्थापन गरेर परियोजनालाई सफलतामा पुर्याउनु (वा, सफलतामा पुर्याउन नसकिएको अवस्थामा, अनुचित जिम्मेवारीबाट बच्नु) हो। यस्तो उद्देश्य प्राप्त गर्नको लागि, व्यावहारिक रूपमा, परिवर्तन व्यवस्थापन दस्तावेजको तयारी प्रायः मुद्दा व्यवस्थापन सूचीको तयारी र अद्यावधिकसँगै गरिन्छ। यसरी, परिवर्तनको इतिहासलाई परिवर्तन व्यवस्थापन तालिकामा व्यवस्थापन गरेपछि, सहमति भएका परिवर्तन बुँदाहरूलाई भविष्यमा समाधान गर्नुपर्ने मुद्दाहरूको रूपमा मुद्दा व्यवस्थापन सूचीमा समावेश गरिन्छ।
परिवर्तनको सहमति प्रक्रियालाई पनि नियमबद्ध गर्नु राम्रो हुन्छ
परिवर्तन व्यवस्थापनको तरिका मात्र नभई, परिवर्तन सम्बन्धी सहमति प्रक्रियालाई पनि नियमबद्ध गर्नु राम्रो हुन्छ, जसले गर्दा परिवर्तनको प्रक्रिया सहज रूपमा अघि बढ्न सक्छ। यो विशेष गरी जापानमा एगाइल विकास जस्ता विकास विधिहरूमा महत्वपूर्ण हुन्छ, जहाँ विभिन्न परिवर्तनहरू पछि गरिन्छ। व्यावहारिक रूपमा पनि, परिवर्तन व्यवस्थापन सम्बन्धी सहमति अनुरोध भएमा, प्रतिपक्षले कहिलेसम्म सहमति दिनुपर्छ भन्ने कुरा नियमबद्ध गरिएका उदाहरणहरू धेरै पाइन्छन्।
परिवर्तन सहमति र इमानदारीको कर्तव्य
दुवै पक्षले एक पटक सहमति गरेको सम्झौतामा, पछि परिवर्तन गर्ने कुरा भनेको नयाँ सम्झौता गर्ने जस्तै हो। सम्झौता स्वतन्त्र इच्छामा आधारित हुने भएकाले, सिद्धान्ततः विक्रेताले परिवर्तन सम्झौतामा सहमति दिनुपर्ने कर्तव्य हुँदैन। तर, यस्तो अधिकारलाई धेरै जोड दिइएमा, जापानमा प्रणाली विकास परियोजना सहज रूपमा अघि बढ्न नसक्ने चिन्ता हुन सक्छ।
त्यसैले, व्यावहारिक रूपमा, सम्झौतामा “परिवर्तनको सहमति इमानदारीपूर्वक दिनुपर्ने कर्तव्य” स्पष्ट रूपमा उल्लेख गरिएको हुन्छ, र विक्रेताले परिवर्तनमा इमानदारीपूर्वक सहमति नदिएमा क्षतिपूर्ति दाबी गर्न सकिने व्यवस्था पनि हुन्छ।
उदाहरणको रूपमा, तलको जस्तै वाक्यांशहरू छन् (तल, स्वतन्त्र प्रशासनिक संस्था सूचना प्रशोधन प्रवर्द्धन संस्थानद्वारा आधिकारिक रूपमा तयार गरिएको ‘ff आधारभूत/व्यक्तिगत सम्झौता मोडेलको आधारभूत सम्झौता प्रस्ताव’ बाट उद्धृत गरिएको छ)।
धारा 4, उपधारा 3: परिवर्तन सहमति प्रक्रियामा, परिवर्तनको विषय, परिवर्तनको सम्भाव्यता, परिवर्तनले मूल्य र समयसीमामा पर्ने प्रभाव आदिको समीक्षा गरिन्छ, र परिवर्तन गर्ने बारेमा दुवै पक्ष इमानदारीपूर्वक सहमति गर्छन्।
परिवर्तन विधिको नियम
पहिले उल्लेख गरिएझैं, परिवर्तन गर्दा हरेक पटक परिवर्तन सम्बन्धी सहमति प्रक्रिया आयोजना गर्नु कानूनी रूपमा “सुरक्षित” हुन्छ। तर, साना परियोजनाहरूमा, परिवर्तन सम्बन्धी सहमति प्रक्रियालाई नियमबद्ध नगर्ने पनि हुन सक्छ। यस्तो अवस्थामा, सहमति प्रक्रियाको नियम राख्नुको सट्टा, सहमति बिना पनि परिवर्तन व्यवस्थापन दस्तावेजमा प्रयोगकर्ता र विक्रेताको जिम्मेवार व्यक्तिहरूको हस्ताक्षर र छाप लगाएर मात्र परिवर्तन गरिने व्यवस्था गर्न सकिन्छ। मौखिक सहमति मात्रमा परिवर्तन गर्न सजिलो बनाउँदा परिवर्तन भएको हो कि होइन भन्ने कुरा अस्पष्ट हुन सक्छ, जसले पछि ठूलो समस्या निम्त्याउन सक्छ, त्यसैले दस्तावेज व्यवस्थापनलाई कडाइका साथ पालना गर्नुपर्छ।
यद्यपि, हरेक पटक परिवर्तन व्यवस्थापनको लागि अलग्गै दस्तावेज तयार पार्नुपर्ने बोझ धेरै हुन सक्छ, र लचिलो प्रतिक्रिया दिन चाहनु पनि हुन सक्छ। यस्तो अवस्थामा, बैठकको कार्यवृत्तमा परिवर्तन सम्बन्धी कुराहरूलाई दस्तावेजीकरण गर्ने तरिका अपनाउन सकिन्छ। प्रणाली विकासमा बैठकको कार्यवृत्त कसरी राख्ने भन्ने विषयमा, तलको लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।
सारांश
जापानमा बारम्बार विशिष्टता परिवर्तन गरिने कार्यस्थलमा, समस्याहरू र विवादहरूको जोखिमसँग नजिक रहनु सामान्य कुरा हो। तर, यस्तो लचिलोपन आवश्यक पर्ने कार्यस्थलमा, केवल “व्यवस्थापनको महत्त्व”लाई जोड दिनु मात्रले व्यावहारिक उपायहरू अपनाउन गाह्रो हुन सक्छ।
व्यवसायमा आवश्यक पर्ने गति र आकस्मिक अवस्थाहरूको तयारीलाई कसरी सन्तुलनमा राख्ने भन्ने समस्या, कम्पनीको अवस्था र परियोजनाको विषयवस्तु अनुसार फरक-फरक समाधान हुन सक्छ। यस लेखको विषयवस्तुलाई ध्यानमा राख्दै, कम्पनी र परियोजनाको आधारमा उपयुक्त उपायहरूको खोजी गर्नु महत्त्वपूर्ण हुन्छ।
Category: IT
Tag: ITSystem Development




















