डॉन जोन्स। "अपने वातावरण में एकीकृत आईटी निगरानी प्रणाली बनाना" अध्याय 3. एक ही आईटी प्रबंधन चक्र में सब कुछ जोड़ना

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


सामग्री

अध्याय 1. अपने आईटी वातावरण का प्रबंधन: चार चीजें जो आप गलत करते हैं
अध्याय 2. आईटी प्रबंधन में व्यक्तिगत साइटों के लिए प्रबंधन प्रथाओं का उन्मूलन
अध्याय 3. एक आईटी प्रबंधन चक्र में सब कुछ जोड़ना
अध्याय 4. निगरानी: डेटा केंद्र से परे एक नज़र
अध्याय 5: समस्याओं को समाधान में बदलना
अध्याय 6: उदाहरणों के साथ एकीकृत प्रबंधन

अध्याय 3. एक आईटी प्रबंधन चक्र में सब कुछ जोड़ना

एक लंबे समय के लिए, वास्तविक जीवन से डिस्कनेक्ट की गई असतत प्रक्रियाओं का अभ्यास आईटी में मौजूद रहा है, जो अक्सर महत्वपूर्ण प्रतिभागियों को आईटी के अंदर हो रहा है। सभी को मिलाकर - उपयोगकर्ता, प्रबंधक, आईटी विशेषज्ञ और अन्य कर्मचारी एक ही चक्र में महत्वपूर्ण लाभ प्रदान कर सकते हैं, साथ ही साथ व्यक्तिगत क्षेत्रों में आईटी प्रबंधन में लौटने की प्रवृत्ति को कम कर सकते हैं। यह वह जगह है जहाँ सेवा डेस्क और निगरानी प्रणाली के बीच सही एकीकरण होता है, और ये दो अवधारणाएं इस पुस्तक में चर्चा किए गए सबसे केंद्रीय और महत्वपूर्ण विषयों के लिए आधार बनाती हैं। यह सब संचार से संबंधित है - बेहतर बातचीत प्राप्त करने के तरीके, साथ ही निरंतर सुधार के अवसर पैदा करना। उपयोगकर्ता कभी-कभी अपने आईटी विभाग को खराब संचार कौशल के साथ अभेद्य, उच्चतर और अजीब प्रकार के रूप में देखते हैं। यह सच है या नहीं यह खुद आईटी पेशेवरों पर निर्भर करता है, लेकिन ऐसा पूर्वाग्रह है , चाहे वह उचित हो या न हो, अक्सर मौजूद होता है। और सभी क्योंकि आईटी सेवा अक्सर उन घटनाओं के बारे में जानने के लिए अंतिम हो सकती है जो उपयोगकर्ता एक समस्या के रूप में अनुभव करते हैं। सर्वर सेट मानों के भीतर काम कर सकता है, लेकिन ऑर्डर दर्ज करने का आवेदन बहुत धीमा है। आईटी का कहना है कि मेल बहुत अच्छा काम करता है, लेकिन मैं एक घंटे के लिए खरीद के आदेश के साथ आने वाले संदेश का इंतजार कर रहा हूं, इसलिए मेल सिस्टम ठीक से काम नहीं कर रहा है!

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

हम चक्र शुरू करते हैं: हम निगरानी और सेवा डेस्क को जोड़ते हैं

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

अलग-अलग स्थानों पर, अलग-अलग समय पर स्थापित अलग-अलग प्रणालियां - ये सभी टिकट बनाने के तरीके को प्रभावित कर सकते हैं, साथ ही किसी समस्या पर काम करने में शामिल लोगों के चक्र को भी बदल सकते हैं।

टिकटों को यथासंभव पूर्ण होना चाहिए, इस अर्थ में कि "अलार्म टिकट" के भरे हुए क्षेत्रों के मूल्यों को जितना संभव हो सके स्वचालित रूप से एकत्र किया जाना चाहिए। विवरण भरते समय, आपको मदद डेस्क या किसी और पर भरोसा नहीं करना चाहिए।

विस्तृत जानकारी में समस्या से प्रभावित सर्वर के बारे में जानकारी हो सकती है। चित्र 3.1। यह दिखाया गया है कि कैसे, लगभग, एक स्वचालित रूप से बनाया गया टिकट ऐसा लग सकता है, जिसमें मुख्य फ़ील्ड सिस्टम द्वारा पहले से भरे हुए थे।


चित्र 3.1: प्राप्त अलार्म के जवाब में सिस्टम द्वारा स्वचालित रूप से बनाए गए टिकट।

सेवा डेस्क के आयोजन के लिए एक उपाय है - सॉफ्टवेयर जो आईटी गतिविधियों को समन्वित और प्रबंधित करने में मदद करता है (अक्सर टिकट के माध्यम से), एक निगरानी प्रणाली के साथ मिलकर काम करता है, जो इस प्रकार आईटी में उत्पन्न होने वाली समस्याओं के साथ काम करने के लिए वास्तव में एकीकृत समाधान बनाता है।

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

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

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


चित्र 3.2: कई घटनाओं और एक समस्या के बीच संबंध।

मैंने वर्तमान चर्चा में कुछ खोजशब्दों का उपयोग किया और उन्हें इस पुस्तक के संदर्भ में रेखांकित करना चाहूंगा:

• एक घटना एक ऐसी चीज है जो पर्यावरण में घटित होती है, उदाहरण के लिए, एक विफल सर्वर या धीमी गति से चलने वाला अनुप्रयोग।
• घटना से निपटने के लिए, आईटी स्टाफ समस्या का रिकॉर्ड बनाता है । समस्या, वास्तव में, कई घटनाओं से जुड़ी हो सकती है, जैसे कि, उदाहरण के लिए, एक ओवरहीट राउटर के मामले में, जो पहली नज़र में बार-बार होने वाली असंबंधित असफलताओं के कारण होता है, जो पूरे वातावरण में खुद को प्रकट करता है।

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

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

1. उपयोगकर्ता "कैटलॉग" से एक भी अनुरोध का चयन करने के लिए वेबसाइट पर जाता है जिसे वह बना सकता है - सिस्टम तक पहुंच, उपकरण के प्रतिस्थापन आदि।
2. उपयोगकर्ता कैटलॉग से एक आइटम का चयन करता है और अनुरोध को पूरा करने के लिए अतिरिक्त स्पष्ट जानकारी बनाता है।
3. एक उपयोगकर्ता अनुरोध वाला टिकट सेवा डेस्क में बनाया गया है। अनुरोध के आधार पर, टिकट उपयोगकर्ता के प्रबंधक को अनुमोदन के लिए भेजा जा सकता है।
4. अनुमोदन के बाद, टिकट को स्वचालित रूप से उपयुक्त आईटी तकनीकी विशेषज्ञ के काम में स्थानांतरित किया जा सकता है।
5. जब आप काम करते हैं, तो उपयोगकर्ता अनुरोध की स्थिति के बारे में जानकारी प्राप्त कर सकता है, उदाहरण के लिए ई-मेल के माध्यम से। टिकट बंद होने के बाद सूचना में एक स्थिति संदेश "पूरा" शामिल है।
6. टिकटों के प्रसंस्करण के लिए एक ही प्रणाली का उपयोग करते समय, समस्याओं को हल करने और नियमित अनुरोधों को संसाधित करने के लिए, आईटी विशेषज्ञ अपने कार्यभार को प्रबंधित करने के लिए एकल इंटरफ़ेस का उपयोग कर सकते हैं। अंजीर। 3.3 दिखाता है कि रूटीन अनुरोध से संबंधित टिकट को संसाधित करने का अनुरोध कैसा दिख सकता है।

चित्र 3.3: रूटीन अनुरोध भी टिकट के रूप में जारी किए जा सकते हैं।

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


चित्र 3.4: प्रबंधन रिपोर्ट तब और प्रभावी हो जाती है जब वे सभी आईटी सेवा कार्य शामिल करते हैं।

मुख्य विचार सभी को एक ही चक्र में रखना है: उपयोगकर्ता, आईटी, प्रबंधन - ताकि सभी को मामलों की स्थिति के बारे में सूचित किया जा सके। अधिसूचना का मुख्य बोझ सॉफ्टवेयर पर पड़ता है, जिसमें ई-मेल या अन्य माध्यमों से मामलों की स्थिति के बारे में अद्यतन जानकारी भेजने की क्षमता होती है, इसलिए हर कोई मौजूदा स्थिति से अवगत है।

परिवर्तन कर रहा है। सही खिड़की कैसे खोजें

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

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

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

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

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

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


चित्र 3.5: कैलेंडर दृश्य में शेड्यूल परिवर्तन प्रबंधन।

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

संचार: एक चक्र में उपयोगकर्ताओं को कैसे संलग्न करें

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

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

वास्तव में, एक अच्छा सर्विस डेस्क समाधान आपके लिए यह कर सकता है। ई-मेल के माध्यम से अपडेट का वितरण, यदि, उदाहरण के लिए, एक उपयोगकर्ता टिकट बदल गया है - यह सॉफ्टवेयर के लिए एक सरल ऑपरेशन है। इस तरह के संदेश सूचनात्मक हो सकते हैं और उपयोगकर्ताओं को उनके अनुरोधों की स्थिति के बारे में सबसे अधिक चिंता से छुटकारा दिला सकते हैं। चित्र 3.6।यह कैसे दिख सकता है।


चित्र 3.6। विस्तृत ई-मेल के माध्यम से उपयोगकर्ताओं को सूचित करना।

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

, . , , , .

:

यदि आप निश्चित रूप से पिछले दस वर्षों के बीच में नहीं रहे हैं, तो वाक्यांश 'सेवा स्तर समझौता (SLA)' से आपको परिचित होना चाहिए। अपने सरलतम रूप में, यह एक आईटी सेवा द्वारा की गई प्रतिबद्धता है और किसी विशेष सेवा के लिए एक विशिष्ट स्तर की उपलब्धता, प्रदर्शन और उपलब्धता प्रदान करता है। "डाक सेवा प्रति वर्ष काम के समय का 99.999% उपलब्ध होगी" एक साधारण एसएलए का एक उदाहरण है।

SLAs बहुत जल्दी जटिल हो जाते हैं और आप उनमें से केवल एक संख्या को नहीं समझ पाएंगे। आप किस स्तर की सेवा प्रदान कर सकते हैं? आपकी ऐतिहासिक रूप से स्थापित सेवा का स्तर क्या है? और व्यवसाय की जरूरतों को क्या पूरा करता है? आप SLAs के स्तर को कैसे ट्रैक करते हैं जो एक बार प्रचलन में थे, और आप यह कैसे सुनिश्चित करते हैं कि वे व्यवसाय में फिट हों? और क्या आप, आदर्श रूप से, समझौते की शर्तों के अनुपालन न करने के खतरे को देखते हैं?

SLAs केवल एक ही प्रकार का समझौता नहीं हो सकता है जिसे स्वीकार किया जाए और उसकी निगरानी की जाए। कुछ भी अंडरपिनिंग कॉन्ट्रैक्ट्स ( यूसी ) या ऑपरेशनल लेवल एग्रीमेंट्स का इस्तेमाल करते हैं- OLA) विभिन्न आंतरिक और बाह्य सेवाओं के लिए जो अक्सर SLAs में समर्थित होते हैं।

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

एक बार समझौते के मापदंडों को पंजीकृत करने के बाद, सॉफ़्टवेयर समाधान को वर्तमान प्रदर्शन और उपलब्धता की निगरानी करनी चाहिए, इसे संकेत देना चाहिए, शायद एक साधारण संकेतक के रूप में, चित्र 3.7 में दिखाया गया है और वर्तमान एसएलए के साथ अपना अनुपालन दिखा रहा है। आपके पास SLA मैट्रिक्स पर अधिक व्यापक और विस्तृत रिपोर्ट तक पहुंच भी हो सकती है।


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

यह स्वीकार किया जाना चाहिए कि कोई पूर्ण SLAs नहीं हैं। कभी-कभी, किसी भी कारण से, एक व्यवसाय यह तय कर सकता है कि दावा की गई सेवा को अक्षम रखा जाना चाहिए। कभी-कभी यह हो सकता है, उदाहरण के लिए, सॉफ़्टवेयर अपडेट या रखरखाव कार्य। इन मामलों में, आप SLA का उल्लंघन नहीं करते हैं ; आप सहमत हैं - व्यवसाय के उस हिस्से के साथ जो इसे प्रभावित करता है - काम पूरा होने तक SLA को अस्थायी रूप से निलंबित करने के लिए। सर्विस डेस्क को व्यवस्थित करने के लिए एक सॉफ्टवेयर समाधान को इन प्रकार के अपवादों का समर्थन करना चाहिए, जिसमें SLAs शामिल है, जो केवल कुछ समय अवधि के लिए वैध है; सप्ताहांत और छुट्टियों के रूप में अपवादों को सही ढंग से संभालना, सेवा खिड़कियों पर सहमति, सेवा खिड़कियों के आकार में परिवर्तन आदि।

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

मुझे बताओ कि तुम वास्तव में क्या सोचते हो

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

एक बहुत बड़ी समस्या यह है कि आईटी हमेशा अपने ग्राहकों के बीच अपनी धारणा के साथ संघर्ष कर रहा है। क्या उपयोगकर्ता वास्तव में सोचते हैं कि आप एक अच्छा काम कर रहे हैं? और एक अच्छी नौकरी क्या है ?

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

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

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

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

यदि आपके SLAs दिखाते हैं कि आप अपना काम पूरी तरह से कर रहे हैं, और उपयोगकर्ता मूल्यांकन समीक्षा शानदार है, तो आपके SLAs सही स्तर पर नहीं हो सकते हैं - या आपके SLAs विचार करने के लिए केवल मीट्रिक नहीं हैं।

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

जब हर किसी को सब कुछ देखने की आवश्यकता नहीं होती है: एक बहु-स्वामित्व दृष्टिकोण

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

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

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

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

इसे एक निजी क्लाउड कहें: लागत साझाकरण

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


चित्र 3.8: उपयोगकर्ता गतिविधि को मापने के लिए बिलिंग की रिपोर्ट करें।

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

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

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

यह भी एक प्रक्रियात्मक चक्र में सभी को एक साथ जोड़ने का एक और तरीका है। यहां तक ​​कि अगर आप अपने इच्छित उद्देश्य के लिए आंतरिक बिलिंग या खातों का उपयोग नहीं करते हैं, तो वे लागत के स्रोतों और आईटी निवेशों के मूल्य को समझने के लिए वरिष्ठ प्रबंधन के लिए उपयोगी हो सकते हैं। एक आईटी प्रबंधक सीईओ को बता सकता है: "ठीक है, आपने पिछली तिमाही में आईटी पर $ 25 बिलियन खर्च किए थे, लेकिन यह यहाँ है कि कब और कैसे इन निवेशों का उपयोग संगठन द्वारा किया गया था। यदि आप पैसा बचाना चाहते हैं, तो उपयोगकर्ताओं के साथ शुरुआत करें और हमारी सेवाओं का कम उपभोग करने के तरीके खोजें ”

निष्कर्ष

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

अगले अध्याय में ...

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

अध्याय 2 पर जाएं