सिस्टम विकास प्रोजेक्ट की 'जलन' से संबंधित कानून क्या हैं?

सिस्टम विकास जैसी परियोजनाएं एक रात में पूरी होने वाली नहीं होतीं, बल्कि इसे पूरा करने के लिए कई लोगों, संगठनों, विशाल धनराशि और लंबे समय तक के विकास अवधि आदि, बहुत सारे संसाधनों की आवश्यकता होती है। इस लेख में, हम सिस्टम विकास की परियोजनाओं में “जलने” के नाम की घटना को कानूनी ढांचे के अंतर्गत कैसे संगठित किया जा सकता है, इसकी व्याख्या करेंगे, साथ ही समाधान की दिशा निर्धारित करने वाले बिंदुओं को संग्रहित करेंगे।

परियोजनाएं क्यों ‘जल’ जाती हैं

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

• केवल डिलीवरी की तारीख पहले ही तय हो गई है, और विशेषताएं और आवश्यकताएं अस्पष्ट रहती हैं जबकि समय बीतता जा रहा है
• सदस्यों का ध्यान केवल कंपनी की राजनीतिक समस्याओं पर होता है, और मानव संबंधों के तनाव से बीच में बहुत सारे सदस्य ड्रॉपआउट हो जाते हैं
• PM सहित प्रबंधन स्तर में भी समझौते की कमी होती है, और सदस्यों से उचित रिपोर्टिंग, संपर्क, और परामर्श की मांग नहीं की जाती है

ऐसे, परियोजना के अनुसार विशिष्ट ‘जलने’ के कारण अलग-अलग हो सकते हैं। हालांकि, कानूनी दृष्टि से, परियोजनाओं के ‘जलने’ के कारणों को कुछ विभिन्न प्रकारों के द्वारा अपेक्षाकृत सरल रूप से व्यवस्थित किया जा सकता है।

आगजनी प्रकार 1: प्रोजेक्ट बीच में अचानक रुक जाने की स्थिति

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

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

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

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

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

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

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

इसके अलावा, ऐसी “अचानक रुकावट” आमतौर पर स्वीकृति के समय उत्पन्न होती है। स्वीकृति के बारे में नीचे दिए गए लेख में विस्तार से व्याख्या की गई है।

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

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

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

आगजनी प्रकार 2: उपयोगकर्ता की खुद की सुविधा के लिए समाप्त करने का मामला

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

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

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

・ठेका अनुबंध के मामले में: जापानी सिविल कोड धारा 641
जापानी सिविल कोड धारा 641
→ठेकेदार काम पूरा नहीं करता है, तो आदेशकर्ता कभी भी नुकसान का भुगतान करके अनुबंध को समाप्त कर सकता है।
・अनुबंध के मामले में: जापानी सिविल कोड धारा 648, धारा 3 (परिस्थितियों के आधार पर, जापानी सिविल कोड धारा 651 के आधार पर नुकसान भुगतान की मांग भी)
जापानी सिविल कोड धारा 648
→यदि अनुबंध का पालन करने के दौरान अनुबंध समाप्त हो जाता है, तो अनुबंध ग्राहक अब तक के पालन के अनुपात में भुगतान की मांग कर सकता है।
जापानी सिविल कोड धारा 651
→1. अनुबंध को किसी भी समय समाप्त किया जा सकता है।
→2. यदि एक पक्ष दूसरे पक्ष के लिए अनुकूल समय में अनुबंध को समाप्त करता है, तो वह पक्ष दूसरे पक्ष के नुकसान का भुगतान करना होगा। हालांकि, यदि अपरिहार्य कारण होते हैं, तो यह सीमित नहीं होता है।

सारांश

प्रत्येक सिस्टम विकास परियोजना विभिन्न और बहुमुखी चुनौतियों को सामना करती है। हालांकि, यदि कानूनी परियोजनाओं की “ज्वलन” की बात होती है, तो इस लेख में प्रस्तुत किए गए ढांचे को एक नजरिया के रूप में देखा जा सकता है। सिस्टम विकास से संबंधित कानूनी मुद्दे निश्चित रूप से बहुत अधिक विषयों को शामिल करते हैं।

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