Product software implementation method
एक उत्पाद सॉफ्टवेयर कार्यान्वयन विधि एक संगठनात्मक संरचना या एक व्यक्तिगत अंतिम उपयोगकर्ता के कार्यप्रवाह में एक सॉफ्टवेयर आधारित सेवा या घटक को प्रभावी ढंग से एकीकृत करने के लिए एक व्यवस्थित रूप से संरचित दृष्टिकोण है। यह प्रविष्टि "बड़े" (जटिलता अंतर में समझाया गया) उत्पाद सॉफ्टवेयर के कार्यान्वयन के प्रक्रिया मॉडलिंग (प्रक्रिया मॉडलिंग) पक्ष पर केंद्रित है, जिसमें विस्तार से बताने के लिए मुख्य उदाहरण के रूप में उद्यम संसाधन योजना प्रणालियों के कार्यान्वयन का उपयोग किया गया है। एक उत्पाद सॉफ्टवेयर कार्यान्वयन विधि उपयोगकर्ताओं और/या संगठनों को एक विशिष्ट सॉफ्टवेयर उत्पाद के साथ चलाने के लिए एक खाका है। विधि एक सॉफ्टवेयर उत्पाद को लागू करते समय होने वाले सबसे आम मुद्दों से निपटने के लिए नियमों और विचारों का एक समूह हैः संगठनात्मक दृष्टिकोण से व्यावसायिक संरेखण और मानव दृष्टिकोण से स्वीकृति। सॉफ्टवेयर उत्पादन की परिनियोजन श्रृंखला में अंतिम कड़ी के रूप में उत्पाद सॉफ्टवेयर का कार्यान्वयन वित्तीय परिप्रेक्ष्य में एक प्रमुख मुद्दा है। यह कहा गया है कि (उत्पाद) सॉफ़्टवेयर के कार्यान्वयन में सॉफ़्टवेयर खरीद के बजट का एक तिहाई (हार्डवेयर और सॉफ़्टवेयर आवश्यकताओं से अधिक) खर्च होता है। कार्यान्वयन जटिलता अंतर उत्पाद सॉफ्टवेयर को लागू करने की जटिलता कई मुद्दों पर भिन्न होती है। उदाहरण हैंः उत्पाद सॉफ्टवेयर का उपयोग करने वाले अंतिम उपयोगकर्ताओं की संख्या, अंतिम उपयोगकर्ता के लिए कार्यों और जिम्मेदारियों में परिवर्तन पर कार्यान्वयन का प्रभाव, संगठन की संस्कृति और अखंडता जहां सॉफ्टवेयर का उपयोग किया जा रहा है और उत्पाद सॉफ्टवेयर प्राप्त करने के लिए उपलब्ध बजट। सामान्य तौर पर, अंतर को आकार के पैमाने (बड़े, छोटे, अधिक, कम) पर पहचाना जाता है। "छोटे" उत्पाद सॉफ्टवेयर का एक उदाहरण कार्यालय पैकेज का कार्यान्वयन है। हालांकि एक संगठन में बहुत सारे अंतिम उपयोगकर्ता हो सकते हैं, अंतिम उपयोगकर्ता के कार्यों और जिम्मेदारियों पर प्रभाव बहुत तीव्र नहीं होगा, क्योंकि अंतिम उपयोगकर्ता का दैनिक कार्यप्रवाह महत्वपूर्ण रूप से नहीं बदल रहा है। "बड़े" उत्पाद सॉफ्टवेयर का एक उदाहरण उद्यम संसाधन योजना प्रणाली का कार्यान्वयन है। कार्यान्वयन के लिए संगठन की वास्तुकला के साथ-साथ उत्पाद के बारे में गहन अंतर्दृष्टि की आवश्यकता होती है, इससे पहले कि इसे संरेखित किया जा सके। इसके बाद, ई. आर. पी. प्रणाली के उपयोग में अंतिम उपयोगकर्ताओं का अधिक समर्पण शामिल होता है क्योंकि नए कार्य और जिम्मेदारियां या तो बनाई जाएंगी या स्थानांतरित की जाएंगी। अन्य "बड़े" उत्पाद सॉफ्टवेयर के उदाहरण हैंः उद्यम संसाधन योजना सॉफ्टवेयर ग्राहक संबंध प्रबंधन सॉफ्टवेयर सामग्री प्रबंधन प्रणाली सॉफ्टवेयर मानव संसाधन प्रबंधन प्रणाली आपूर्ति श्रृंखला प्रबंधन सॉफ्टवेयर सॉफ्टवेयर अनुकूलन और व्यवसाय प्रक्रिया पुनः डिज़ाइन प्रक्रिया मॉडलिंग, उत्पाद सॉफ्टवेयर और संगठनात्मक संरचनाओं को संरेखित करने के लिए उपयोग किया जाता है, जिसमें एक प्रमुख मुद्दा शामिल होता है, जब निष्कर्ष निकाला जाता है कि उत्पाद सॉफ्टवेयर और संगठनात्मक संरचना सॉफ्टवेयर को लागू करने के लिए पर्याप्त रूप से संरेखित नहीं होती है। इस मामले में, दो विकल्प संभव हैंः सॉफ्टवेयर का अनुकूलन या संगठनात्मक संरचना का नया डिज़ाइन, इस प्रकार व्यावसायिक प्रक्रियाएँ। सॉफ़्टवेयर को अनुकूलित करना वास्तव में उत्पाद सॉफ़्टवेयर को दर्जी सॉफ़्टवेयर में बदल देता है, क्योंकि मानकीकृत सॉफ़्टवेयर का विचार अब लागू नहीं होता है। इसके परिणामस्वरूप सॉफ्टवेयर पर समर्थन का नुकसान हो सकता है और सॉफ्टवेयर के उपयोग में समस्या उत्पन्न होने पर परामर्श प्राप्त करने की आवश्यकता हो सकती है। हालाँकि अनुकूलन के परिणामस्वरूप ऐसी स्थिति पैदा होती है जहाँ संगठनात्मक अखंडता को समायोजित नहीं किया जाता है, जो अंतिम उपयोगकर्ताओं पर कम दबाव डालता है, क्योंकि कार्यप्रवाह में कम परिवर्तन या बदलाव की आवश्यकता होती है। यह तथ्य उपयोग किए जाने वाले किसी भी नए (उत्पाद) सॉफ्टवेयर अनुप्रयोग की स्वीकृति को सकारात्मक रूप से बढ़ा सकता है और इस प्रकार कार्यान्वयन बजट के नरम पक्ष पर कार्यान्वयन समय और बजट को कम कर सकता है। उत्पाद सॉफ्टवेयर के उपयोग में प्रतिरोध पैदा करने के लिए व्यावसायिक प्रक्रियाओं को फिर से डिज़ाइन करना अधिक समझदारी भरा है, क्योंकि परिवर्तित व्यावसायिक प्रक्रियाएं उत्पाद सॉफ्टवेयर के अंतिम उपयोगकर्ताओं के लिए कार्यों और जिम्मेदारियों को बदल देंगी। हालांकि, जबकि उत्पाद सॉफ्टवेयर में बदलाव नहीं किया गया है, बेहतर समर्थन, प्रशिक्षण और सेवा स्तर संभव हैं. क्योंकि समर्थन सॉफ्टवेयर की विशिष्ट अखंडता के लिए बनाया गया था। कार्यान्वयन संरचना व्यवसाय बनाम मार्गदर्शक सिद्धांत उत्पाद सॉफ्टवेयर की कार्यान्वयन प्रक्रिया पर एक और मुद्दा है, या वास्तव में सवाल यह है कि कार्यान्वयन विधि का उपयोग किस हद तक किया जाना चाहिए। कार्यान्वयन विधियों का उपयोग एक ओर एक मार्गदर्शक सिद्धांत के रूप में किया जा सकता है, जो दर्शाता है कि यह विधि एक वैश्विक विचार के रूप में कार्य करती है कि किसी भी परियोजना के कार्यान्वयन चरण को कैसे चलाया जाना चाहिए। यह विकल्प स्थितिजन्य कारकों के लिए अधिक जगह छोड़ता है जिन्हें चुनी गई विधि में ध्यान में नहीं रखा जाता है, लेकिन कार्यान्वयन प्रक्रिया के निष्पादन में प्रश्न उत्पन्न होने पर अस्पष्टता पैदा होगी। दूसरी ओर, विधियों का उपयोग एक पेशे के रूप में किया जा सकता है, जिसका अर्थ है कि विधि को सख्त लिया जाना चाहिए और विधि का उपयोग एक मार्गदर्शक सिद्धांत के बजाय एक पेशा होना चाहिए। यह दृष्टिकोण बहुत उपयोगी है यदि कार्यान्वयन प्रक्रिया बहुत जटिल है और सटीक और सटीक कार्य पर बहुत निर्भर है। संगठनात्मक और गुणवत्ता प्रबंधन इस दृष्टिकोण को अपनाएगा, क्योंकि किसी भी विधि के सख्त उपयोग के परिणामस्वरूप संगठनात्मक स्तर पर अधिक स्पष्टता आती है। परिवर्तन प्रबंधन हालांकि यह संकेत दे सकता है कि कार्यान्वयन विधि में अधिक लचीलापन कार्यान्वयन प्रक्रियाओं के नरम पक्ष के लिए अधिक जगह छोड़ देता है। कार्यान्वयन ढांचा किसी विशिष्ट उत्पाद या सेवा को लागू करने के लिए नियमों के समूह के रूप में कार्य करने वाली कार्यान्वयन विधियों के अलावा, कार्यान्वयन ढांचा समय, बजट और गुणवत्ता में कार्यान्वयन चरण को परिभाषित करने के लिए परियोजना प्रबंधित संरचना के रूप में कार्य करता है। कई परियोजना प्रबंधन विधियाँ कार्यान्वयन विधि को करने के लिए एक आधार के रूप में काम कर सकती हैं। चूँकि यह प्रविष्टि उत्पाद सॉफ्टवेयर के कार्यान्वयन पर केंद्रित है, इसलिए कार्यान्वयन चरण का समर्थन करने के लिए उपयुक्त सबसे अच्छी परियोजना प्रबंधन विधियाँ परियोजना प्रबंधन विधियाँ हैं जो सॉफ्टवेयर और सूचना प्रणालियों पर भी ध्यान केंद्रित करती हैं। कार्यान्वयन विधियों के लिए एक ढांचे का उपयोग करने की प्रयोज्यता को गतिशील और स्थिर प्रणाली विकास विधि (डी. एस. डी. एम.) और प्रिंस 2 को परियोजना प्रबंधन विधि ढांचे के रूप में उपयोग करने के उदाहरणों द्वारा स्पष्ट किया जाता है। डी. एस. डी. एम. गतिशील प्रणाली विकास विधि की शक्ति यह है कि विधि पुनरावृत्ति और वृद्धिशील मूल्य के सिद्धांतों का उपयोग करती है, जिसका अर्थ है कि परियोजनाओं को दोहराए जाने वाले चरणों में किया जाता है जहां प्रत्येक चरण परियोजना में मूल्य जोड़ता है। इस तरह से कार्यान्वयन चरणों को क्रमिक रूप से किया जा सकता है और प्रत्येक वृद्धि के भीतर स्वीकृति, जागरूकता और कौशल जैसे महत्वपूर्ण परियोजना पहलुओं में मूल्य जोड़ा जा सकता है [एफ. वॉन मेयेनफेल्ट, बेसिस्केनिस परियोजना प्रबंधन, अकादमिक सेवा 1999]। अवसर दायरे के प्रबंधन के अलावा, वृद्धि कार्यान्वयन चरणों के प्रक्रिया मॉडलिंग दायरे में भी उपयोग करने योग्य हैं। वृद्धि का उपयोग व्यावसायिक वास्तुकला और उत्पाद सॉफ्टवेयर के प्रक्रिया मॉडल को संरेखित कर सकता है क्योंकि चरण की प्रत्येक वृद्धि में अधिक विवरण जोड़ना दोनों मॉडल को करीब लाता है। डी. एस. डी. एम. में चरणबद्ध प्रशिक्षण, प्रलेखन और समीक्षा के लिए भी जगह है। डी. एस. डी. एम. की तरह, प्रिंस2 विधि कार्यान्वयन को विधि के भीतर एक चरण के रूप में स्वीकार करती है। प्रिंस 2 में प्रक्रियाओं का एक समूह होता है, जिनमें से 3 प्रक्रियाएं विशेष रूप से कार्यान्वयन के लिए होती हैं। एक चरण को नियंत्रित करने, उत्पाद वितरण का प्रबंधन करने और चरण सीमाओं का प्रबंधन करने की प्रक्रियाएं एक कार्यान्वयन प्रक्रिया को समय और गुणवत्ता के रूप में कारकों के साथ विस्तृत करने में सक्षम बनाती हैं। प्रिंस2 विधि को बार-बार किया जा सकता है लेकिन यह प्रक्रियाओं के सीधे निष्पादन के लिए भी उपयुक्त है। परियोजना प्रबंधन ढांचे में तैयार की जा रही किसी भी कार्यान्वयन प्रक्रिया के लिए लाभ हैंः स्पष्टता एक कार्यान्वयन ढांचा समय, गुणवत्ता, बजट और व्यवहार्यता जैसे कारकों के साथ प्रक्रिया को विस्तृत करने की पेशकश करता है। पुनरावृत्ति, वृद्धिशील दृष्टिकोण जैसा कि समझाया गया है, कार्यान्वयन प्रक्रिया के विभिन्न चरणों को निष्पादित करने की संभावना अंतिम-उपयोगकर्ता (संगठन) के साथ लागू किए जाने वाले उत्पाद को वृद्धिशील रूप से संरेखित करके प्रक्रिया को निष्पादित करने में सक्षम बनाती है। अंतर्निहित और सामान्य विधियाँ उत्पाद सॉफ्टवेयर को लागू करने का एक तरीका अंतर्निहित विधि या मॉडल का उपयोग करना है। एम्बेडेड मॉडल सहायक सामग्री का हिस्सा हैं (देखें उत्पाद सॉफ्टवेयर की परिभाषा) जो सॉफ्टवेयर पैकेज के साथ आते हैं। एम्बेडेड मॉडल का उपयोग करके एक सॉफ्टवेयर उत्पाद को लागू करने का तात्पर्य न केवल यह है कि मॉडल (ज्यादातर) केवल विशिष्ट सॉफ्टवेयर उत्पाद के साथ उपयोग करने योग्य है, बल्कि यह भी है कि उत्पाद को केवल मॉडल का उपयोग करके लागू किया जा सकता है या किया जाना चाहिए। अंतःस्थापित विधियों को इस प्रकार उत्पाद सॉफ्टवेयर को लागू करने के बहुत विशिष्ट तरीकों के रूप में देखा जा सकता है। एम्बेडेड विधि के साथ सॉफ्टवेयर उत्पादों के उदाहरण हैंः एआरआईएस एम्बेडेड मॉडल का उपयोग करके एसएपी (एसएपी आर/3) को लागू करना। डायनेमिक एंटरप्राइज मॉडलिंग (डी. ई. एम.) का उपयोग करके बान ई. आर. पी. प्रणाली को लागू करना। ओरेकल अनुप्रयोग कार्यान्वयन विधि (ए. आई. एम.) का उपयोग करके ओरेकल ई-बिजनेस सूट को लागू करना। सामान्य कार्यान्वयन विधियाँ किसी विशिष्ट सॉफ्टवेयर उत्पाद के लिए नहीं हैं, बल्कि उत्पाद सॉफ्टवेयर उत्पादों को लागू करने में सामान्य उपयोग के लिए हैं। इस उपयोग को ऑब्जेक्ट प्रोसेस मेथोडोलॉजी का उपयोग करके उत्पाद सॉफ्टवेयर को लागू करने के उदाहरण का उपयोग करने पर विस्तार से बताया जा रहा है। ई. आर. पी. मॉडलिंगः ई. आर. पी. प्रणालियों के मॉडलिंग में यह पद्धति बहुत उपयोगी है ताकि इसे एक संगठनात्मक संरचना में लागू किया जा सके। आकलन एक अंतर्निहित विधि का उपयोग करने से वह शक्ति आती है जिसे विधि के साथ आने वाले सॉफ्टवेयर उत्पाद को लागू करने के लिए डिज़ाइन किया गया है। यह विधि के कम जटिल उपयोग और अधिक समर्थन संभावनाओं का सुझाव देता है। अंतर्निहित विधि का नकारात्मक पहलू स्पष्ट रूप से यह है कि इसका उपयोग केवल विशिष्ट उत्पाद सॉफ्टवेयर के लिए किया जा सकता है। कई सॉफ्टवेयर उत्पादों के साथ काम करने वाले इंजीनियरों और सलाहकारों के पास काम करने का केवल एक ही तरीका होने के लिए एक सामान्य विधि का अधिक उपयोग हो सकता है। ई. आर. पी. मॉडलिंग जैसी सामान्य विधि का उपयोग करने की शक्ति है कि विधि का उपयोग कई ई. आर. पी. प्रणालियों के लिए किया जा सकता है। अंतर्निहित विधियों के विपरीत, सामान्य विधियों का उपयोग इंजीनियरों और सलाहकारों को सक्षम बनाता है जो एक कंपनी में काम करते हैं जहां कई ईआरपी सिस्टम ग्राहक संगठनों में लागू किए जाते हैं, कई अंतर्निहित मॉडलों के लिए कौशल प्राप्त करने के बजाय एक विशिष्ट कार्य विधि के अनुकूल होने के लिए। सामान्य विधियों में हालांकि कमी है कि कार्यान्वयन परियोजनाएं बहुत अधिक स्थितिजन्य हो सकती हैं, जिसके परिणामस्वरूप मॉडलिंग प्रक्रिया के निष्पादन में कठिनाइयाँ और जटिलता हो सकती है, क्योंकि कम समर्थन उपलब्ध होगा। सॉफ्टवेयर विकास प्रक्रिया