सिस्टम विकासको पारिश्रमिक अवैतनिक भएमा अपनाउनुपर्ने कानून के हो?

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

सबैभन्दा पहिले, पारिश्रमिक माग गर्न सकिने अवस्था छ कि छैन भन्ने कुरा जाँच्नु आवश्यक छ

• वेन्डरले प्रयोगकर्तालाई उत्पादनहरू बुझाएको छ तर प्रयोगकर्ताले बुझाइ लिन अस्वीकार गरेका छन्, जसको कारण पारिश्रमिक माग्ने कार्य पनि अलमलमा परेको छ
• प्रयोगकर्ताको बुझाइसँग असहमति भएको छ भनेर सोचिएको थियो तर प्रयोगकर्ताले पारिश्रमिक भुक्तानी गर्न चाहेका छैनन्

यस्तो परिस्थिति वास्तवमा पनि सम्भव छ।

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

सम्बन्धित लेख: सिस्टम विकासको अनुमोदन र अनुमानित अनुमोदन खण्डहरूको प्रयोगको अवस्था[ja]

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

यस बिन्दुलाई समेत ध्यानमा राख्दै, प्रयोगकर्ताले पारिश्रमिक भुक्तानी गर्न नचाहेको अवस्थालाई ध्यानमा राखेर पहिलो पटक विचार गर्नुपर्ने बिन्दुहरू निम्नानुसार छन्:

1. काम पूरा भएको छ कि अझै पूरा हुन बाँकी छ
2. दोष जिम्मेवारी (जापानी नागरिक संहिता ६३५ धारा)को प्रयोग हुन सक्छ कि सक्दैन

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

त्यसो भए, विशेष गरी, यी दुई बिन्दुहरूलाई विचार गर्नका लागि, वेन्डर पक्षका प्रतिनिधिहरूले के जाँच्नुपर्छ भन्ने कुरा तल हेर्नुहोस्।

जापानमा पारिश्रमिक माग गर्न सकिन्छ कि सकिँदैन भन्ने निर्धारण गर्नका लागि जाँच गर्नुपर्ने कागजातहरू

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

सम्बन्धित लेख: जापानी कानूनी दृष्टिकोणबाट, सिस्टम विकासमा परिवर्तन व्यवस्थापन कसरी गर्ने[ja]

अर्को, कति मुआब्जा माग्न सकिन्छ भन्ने कुरा जाँच्नुहोस्

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

सम्बन्धित लेख: सिस्टम विकासको अनुमानित रकम पछि बढाउन सकिन्छ?[ja]

अनुमानित रकमको पुनः गणना गर्ने विधि यस लेखमा उल्लेख गरिएको छ, तर विशेष गरी मुआब्जा रकमको बढोत्तरीको सम्भावना अध्ययन गर्ने दृष्टिकोणबाट हेर्दा,

1. थप विकास र कार्यक्षमता सुधारसँग सम्बन्धित अनुमानपत्रको उपलब्धता र त्यसको सामग्री
2. प्रयोगकर्ता पक्षको अनुमानपत्र प्रतिक्रिया
3. थप विकास र कार्यक्षमता सुधार उत्पन्न गर्ने परिस्थितिहरू र त्यसको रकम सम्बन्धी सहमतिको उपस्थिति अनुसार चुनौती प्रबन्धन सूचीमा उल्लेख

यस्ता बिन्दुहरूलाई मुख्य रूपमा हेर्नुपर्ने हुन्छ। मुख्य कुरा यो हो कि ‘त्यो रकममा काम अर्डर गर्ने’ भन्ने विषयमा प्रयोगकर्ता पक्षसँग सहमति भएको छ कि छैन (अर्थात् अनुबंध स्थापित भएको छ कि छैन) भन्ने कुरा अध्ययन गर्ने प्रक्रिया हो।

अन्तमा, वास्तविक मुद्दा मुद्दामा जाँदा ध्यान दिनुपर्ने कुराहरू

जवाफी मुद्दा उठाइन सक्ने सम्भावनामा ध्यान दिनुहोस्

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

सिस्टम विकासमा प्रयोगकर्ता पनि विभिन्न सहयोगी कर्तव्यहरू बहन गर्नुपर्छ तर पहिलो कुरा यो हो कि विक्रेता पक्षले सिस्टम विकासका विशेषज्ञको रूपमा व्यापक विवेक र ठूलो जिम्मेवारी बहन गर्दछ। विक्रेता पक्षले सिस्टम विकासमा बहन गर्ने प्रोजेक्ट प्रबन्धन कर्तव्यहरूको बारेमा तलको लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।

सम्बन्धित लेख: सिस्टम विकासमा प्रोजेक्ट प्रबन्धन कर्तव्यहरू[ja]

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

व्यापारिक रूपमा वास्तवमा फाइदा छ कि छैन भन्ने पनि अध्ययन गर्नुपर्छ

यदि विक्रेताको कुरा मान्य हुन्छ र वास्तवमा भुक्तानीको माग गर्न सकिन्छ भनेर मुद्दामा स्वीकृत हुन्छ भने पनि, मुद्दामा जाने क्रममा अवस्था जटिल हुन्छ र त्यसपछि कारोबार जारी राख्न समस्या हुन सक्छ। त्यसैले, मुद्दामा आफ्नो कुरा मान्य भए पनि, वास्तवमा भुक्तानी प्राप्त गर्न सम्म धेरै समय लाग्न सक्छ भन्ने कुरा पनि तयार रहनुपर्छ। मुद्दा चलाउने क्रममा लाग्ने परिश्रम र खर्च पनि कम छैन, त्यसैले बरु सम्झौताको बिन्दु खोज्ने प्रयास गर्नु उचित र राम्रो हुन सक्छ।

सारांश

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

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