कानूनी दृष्टिकोण से देखा गया, सिस्टम विकास में परिवर्तन प्रबंधन का आचरण क्या है

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

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

सिस्टम विकास परियोजनाएं बाद में क्यों ‘बदल’ जाती हैं

सिस्टम विकास विक्रेता और उपयोगकर्ता का साझा कार्य है

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

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

सहयोग की आवश्यकता होती है, लेकिन उपयोगकर्ता अक्सर बदलाव की मांग करते हैं

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

बदलाव प्रबंधन पुस्तिका क्या होती है

परिवर्तन प्रबंधन पत्र का उपयोग किस प्रकार किया जाता है

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

परिवर्तन प्रबंधन पत्र की आवश्यकता के कुछ उदाहरण निम्नलिखित हो सकते हैं:

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

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

https://monolith.law/corporate/increase-of-estimate[ja]

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

परिवर्तन प्रबंधन पुस्तिका के विवरण

तो, कानूनी रूप से, परिवर्तन प्रबंधन पुस्तिका में क्या जानकारी दर्ज करनी चाहिए? परिवर्तन प्रबंधन पुस्तिका का उपयोग करके, विशेषताओं के परिवर्तन और नई सुविधाओं के लिए समाधान करने का संविधान पहले से ही सामान्य रूप से स्वीकार किया जा चुका है। इसलिए, जैसे कि जापानी वाणिज्य मंत्रालय के मॉडल संविदा, सरकारी एजेंसियों द्वारा प्रस्तुत संविदा शर्तों के ढांचे की जांच करके, कौन से मुद्दे रिकॉर्ड के रूप में बचाने चाहिए, यह सामान्य रूप से समझा जा सकता है।

(परिवर्तन प्रबंधन प्रक्रिया)
धारा 37 के अनुसार, पक्ष A या पक्ष B, जब दूसरे पक्ष से धारा 34 (सिस्टम विशेषताओं का परिवर्तन), धारा 35 (उपयोगकर्ताओं द्वारा मध्यवर्ती सामग्री की मंजूरी), धारा 36 (अनिश्चित मामलों का निपटारा) के आधार पर परिवर्तन प्रस्ताव पत्र प्राप्त होता है, तो वे प्राप्ति की तारीख से ○ दिनों के भीतर, निम्नलिखित विवरण वाले दस्तावेज (जिसे ‘परिवर्तन प्रबंधन पुस्तिका‘ कहा जाता है।) को दूसरे पक्ष को सौंपना चाहिए, और पक्ष A और पक्ष B को, धारा 12 के अनुसार संपर्क समिति में इस परिवर्तन की स्वीकृति पर विचार करना चाहिए।
① परिवर्तन का नाम
② प्रस्ताव का प्रमुख
③ तारीख
④ परिवर्तन का कारण
⑤ परिवर्तन के विवरण जिसमें परिवर्तन के संबंधित विशेषताएं शामिल हैं
⑥ यदि परिवर्तन के लिए खर्च की आवश्यकता होती है, तो उसकी राशि
⑦ परिवर्तन कार्य की समय सारणी, जिसमें विचार काल शामिल है
⑧ अन्य परिवर्तन जो इस संविदा और व्यक्तिगत संविदा की शर्तों (कार्य काल या डिलीवरी डेट, आवंटन शुल्क, संविदा शर्तें आदि) पर प्रभाव डालते हैं

सीधे धारा को पढ़कर, जो विवरण दर्ज करने की सिफारिश की जाती है, उसे जांचने के बाद, अधिक विवरण की आवश्यकता नहीं होगी। बाद में ‘मैंने कहा-मैंने नहीं कहा’ की समस्या से बचने के लिए, परिवर्तन की विस्तृत और विशेष जानकारी को रिकॉर्ड करना चाहिए।

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

बदलाव प्रबंधन से संबंधित जानकारी

बदलाव प्रबंधन आमतौर पर मुद्दों के प्रबंधन के साथ किया जाना चाहिए

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

बदलाव चर्चा का तरीका भी निर्धारित करना बेहतर होता है

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

बदलाव चर्चा और ईमानदारी का दायित्व

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

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

लिखित उदाहरण के रूप में, निम्नलिखित वाक्यांश है (नीचे, धारा के उदाहरण को प्रकाशित किया गया है। यह स्वतंत्र प्रशासनिक संगठन जानकारी प्रसंस्करण प्रोत्साहन संगठन द्वारा आधिकारिक रूप से तैयार “ff बेसिक/व्यक्तिगत अनुबंध मॉडल का बेसिक अनुबंध प्रस्ताव” से उद्धृत किया गया है)।

धारा 4, उप-धारा 3: बदलाव चर्चा में, बदलाव के विषय, बदलाव की संभावना, बदलाव के प्रभाव का मूल्यांकन करें, और बदलाव करने के बारे में दोनों पक्ष ईमानदारी से चर्चा करें।

बदलाव के तरीके के बारे में नियम

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

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

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

सारांश

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

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