वाणिज्यिक सॉफ्टवेयर को अपग्रेड करने के लिए एक रणनीति का दस्तावेजीकरण कैसे करें?


11

हमने लगभग एक दशक से अपने RDBMS या सर्वर OS को अपग्रेड नहीं किया है। एक और मिशन-क्रिटिकल सॉफ्टवेयर पैकेज दो दशक पुराना है और उस समय के लिए इसके विक्रेता द्वारा असमर्थित किया गया है। हमारे प्रबंधन में से कुछ को लगता है कि यह एक अच्छी बात है - हमने उन्नयन नहीं खरीदकर टन पैसा बचाया! अब सॉफ्टवेयर के एक महत्वपूर्ण टुकड़े को अपग्रेड की जरूरत है, लेकिन नया संस्करण एक दशक पुराने सामान का समर्थन नहीं करेगा। अब हम में से कुछ मुट्ठी भर लोग यह जानने की कोशिश कर रहे हैं कि कम से कम समय के साथ सब कुछ कैसे अपग्रेड किया जाए।

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

मैं डेस्कटॉप क्लाइंट ए, बी, सी ... को कैसे दस्तावेज़ कर सकता हूं, यह डेस्कटॉप ओएस एक्स और आरडीबीएमएस वाई पर निर्भर है, जो बदले में सर्वर ओएस जेड पर निर्भर करता है, और फिर यहां हम उन सभी को अपने "मीठे स्पॉट" में कैसे रखते हैं? वहाँ किताबें अवश्य होनी चाहिए, लेकिन मेरे सभी गुगलीकरण ने मुझे केवल उन रणनीतियों को लागू करने के लिए निर्धारित करने की रणनीति के बजाय सॉफ़्टवेयर के एक टुकड़े को अपग्रेड करने की रणनीति के बारे में सामान करने के लिए प्रेरित किया है।


7
किसी को जल्द ही इस पर जाने के लिए होगा, मुझे यकीन है, लेकिन मुझे लगता है कि एक बिंदु को याद नहीं करना चाहिए, जबकि कंपनी ने अपग्रेड पर पैसा खर्च नहीं किया, इसने व्यवसाय को जोखिम में डाल दिया । हमें जो काम करना है उनमें से एक प्रबंधन को अपग्रेड न करने के जोखिमों से अवगत कराना है।
माइकल हैम्पटन

3
उन्नयन स्थगित करने के लिए शब्दजाल है कि आप "तकनीकी ऋण" का निर्माण करते हैं; नियमित रखरखाव और उन्नयन को स्थगित करके आप थोड़े समय के लिए कुछ पैसे बचाने के लिए दिखाई देते हैं, लेकिन जब आपको अंततः उपेक्षा करने के वर्षों के बाद रखरखाव करने की आवश्यकता होती है, तो आपको अभी भी पाइपर का भुगतान करने की आवश्यकता होगी: अक्सर समय दुर्भाग्यपूर्ण होगा, विक्रेताओं को नहीं होगा से एक समर्थित तत्काल उन्नयन पथ $CURRENT-version minus 20 yearsके लिए $CURRENT-versionआदि और आप शायद इस निष्कर्ष तक पहुंच जाएगा: उन वास्तविक बचत लेकिन नहीं थे खर्च करना होगा कि एक भविष्य की तारीख में भुगतान किया
HBruijn

1
जीवन चक्र प्रबंधन किसी भी परिपक्व वातावरण और व्यवस्थित करने के लिए PITA में एक कृतघ्न आवश्यकता है। सौभाग्य!
HBruijn

जवाबों:


7

ऐसा लगता है कि आप एक साथ कई समस्याओं को हल करने की कोशिश कर रहे हैं (और यह एक अच्छे विचार की तरह नहीं दिखता है)।

मैंने जो पढ़ा है:

  • पुराने ओएस और अनुप्रयोगों
  • कोई दीर्घकालिक रणनीति नहीं
  • अपने बुनियादी ढांचे के दस्तावेज में समस्याएं
  • अवसंरचना के महत्वपूर्ण टुकड़े को उन्नत करने की तत्काल आवश्यकता

"सॉफ़्टवेयर का महत्वपूर्ण टुकड़ा" अपग्रेड करना

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

तो पहली बात मैं इसके लिए देखूंगा: क्या प्रबंधकों को पुराने सॉफ़्टवेयर के जोखिमों के बारे में पता है? क्या उन्होंने बताया था?

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

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

इस तरह की सूचियाँ बनाने से आपको पूरी समस्या को हल करने में मदद मिलेगी। अगली बात जोखिम लॉग और आपके द्वारा आवश्यक संसाधनों की सूची बनाना है।

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

यदि आपको यह विश्लेषण करने में समस्या है कि किन गतिविधियों को करने की आवश्यकता है, तो आप कुछ माइंड मैप (मेरा पसंदीदा स्व xMind) आज़मा सकते हैं और फिर इसे और अधिक औपचारिक दस्तावेज़ में बदल सकते हैं।

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

शायद इस विशेष मामले में: उल्लेख करें कि उन्नयन बिल्कुल भी संभव नहीं हो सकता है।

कोई दीर्घकालिक रणनीति नहीं

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

उदाहरण व्यवसाय की आवश्यकता: दो वर्षों में हम चीन और ऑस्ट्रेलिया में नए कार्यालय खोलेंगे।

व्युत्पन्न आईटी कार्य: नए कर्मचारियों को उनकी सबसे खराब स्थिति में लाने के लिए तैयार रहें, विदेशी कार्यालयों में बुनियादी ढांचे का निर्माण करें, नए कर्मचारियों के लिए प्रशिक्षण प्रदान करें (संभवतः उनकी मूल भाषा का उपयोग करके), उन कार्यालयों से केंद्रीय तक सुरक्षित संपर्क प्रदान करें, ...

अगर चीजें अच्छी होती हैं, तो आपके पास कुछ महीनों में एक रणनीति हो सकती है ...? तो लगभग आधा साल तक जब तक सब कुछ पर सहमति नहीं बन जाती?

अपने बुनियादी ढांचे को बनाए रखना और प्रलेखित करना

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

यदि आप कुछ ऐसा अपडेट कर रहे हैं जो अच्छी तरह से चला गया, तो इसे रोजमर्रा के व्यवसाय के रूप में संभालें। यदि आप किसी ऐसी चीज को संभाल रहे हैं जो खराब हो सकती है (खर्च किए गए समय, आवंटित लोगों आदि के संदर्भ में "बड़ी" है), तो इसे परियोजना के रूप में संभालें।

ऐसे उपकरण हैं जो आपको प्रलेखन और सेवा निर्भरता के साथ मदद कर सकते हैं - CMDBs (उदाहरण के लिए iTop)। लेकिन इसे काम पर लाने में कुछ समय लग सकता है और आपको अभी भी कुछ प्रलेखन उपकरण की आवश्यकता है। सबसे अच्छा विचार यह है कि डॉक्यूमेंटेशन के लिए एक विकी सेटअप करें, जहाँ से हर कोई अभी से डॉक्यूमेंटेशन / नोट्स बनाना शुरू कर सके। आप आधे घंटे में एक विकी सेट कर सकते हैं, इसलिए यह चीजों को शुरू करने का एक बहुत प्रभावी तरीका है।

व्यक्तिगत नोट: ओएस को अपग्रेड करना जो पुराना होगा पीटीए, (शायद खराब / लापता) प्रलेखन का उल्लेख नहीं करना। क्या सर्वर को नए सिरे से स्थापित करना, एप्स को माइग्रेट करना और शुरू से ही सब कुछ दस्तावेज करना आसान नहीं है?


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

1
हां मुझे पता है आपका क्या मतलब है। लेकिन मुझे लगता है कि यदि आप उस विशेष वाक्य को काट देते हैं, तो शेष उत्तर अभी भी मान्य है। :)
फिस्क
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.