OTRS का उपयोग कर ITIL (समस्या प्रबंधन)

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

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

गहरा जाओ!

सिद्धांत की बिट

आईटीआईएल के अनुसार, एक समस्या एक या एक से अधिक घटनाओं का एक अज्ञात कारण है। बस आपको क्या चाहिए!
इसलिए, और यदि आप समस्या प्रबंधन के मुख्य कार्य को देखते हैं - समस्याओं की घटना को रोकने के लिए, आवर्ती घटनाओं की घटना को समाप्त करें और उन घटनाओं के प्रभाव को कम करें जिन्हें रोका नहीं जा सकता है।

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

आइए क्रियान्वयन पर आगे बढ़ते हैं

- क्या, समस्याएं?

हम समस्याओं की तलाश कैसे कर रहे हैं? यहां हमें निगरानी उपकरण, ServiceDesk, घटनाओं, आपूर्तिकर्ताओं से डेटा या प्रोएक्टिव समस्या प्रबंधन के डेटा द्वारा सहायता प्रदान की जाती है

जब यह स्पष्ट हो गया कि हम वास्तव में एजेंट इंटरफ़ेस में एक समस्या का सामना कर रहे हैं, जिसके लिए ओटीआरएस के व्यवस्थापक भाग में कई जोड़तोड़ करना आवश्यक था।

समस्याओं को दर्ज करने के लिए, आपको एप्लिकेशन प्रकार समस्या को सक्रिय करना होगा।

इसके बाद, आपको उपयोगकर्ताओं से एप्लिकेशन के प्रकार छुपाने होंगे।
टिकट -> फ्रंटेंड :: ग्राहक :: टिकट :: ViewNew ने पैरामीटर सेट किया टिकट :: फ्रंटेंड :: CustomerTicketMessage ### टिकट टाइप - नहीं
इस प्रकार, उपयोगकर्ता के लिए कार्य को सरल बनाना, और ServiceDesk के कार्य को जटिल बनाना।

एजेंट इंटरफ़ेस को अनलोड करने के लिए, हम कतार में प्रवेश करते हैं "समस्या कतार"। अब सभी समस्याएं केवल उन एजेंटों के लिए उपलब्ध हैं जिन्हें एक अलग टैब पर ऐसा करने की अनुमति है।

इस मामले में, हम समस्या के विवरण के मामले में सेवा का विवरण सेवा प्रबंधक या समस्या प्रबंधक को देते हैं। वह है, एजेंट के लिए "समस्याओं की कतार" का अधिकार जोड़ें

वर्गीकरण

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

प्राथमिकताओं

स्तर 5. प्रमुख समस्या - एक नियम के रूप में, तत्काल समाधान की आवश्यकता होती है - ये शीर्ष प्रबंधन को प्रभावित करने वाली या बड़ी संख्या में उपयोगकर्ताओं को प्रभावित करने वाली समस्याएं हैं।
लेवल 2-4 अन्य सभी समस्याएं
स्तर 1. उपयोगकर्ताओं की एक छोटी संख्या को प्रभावित करना।

एक कारण के लिए खोजें

यहीं से काम शुरू होता है। समस्या के कारण को निर्धारित करना आवश्यक है।

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


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

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


हमें फ़ील्ड की आवश्यकता है (ड्रॉपडाउन), कारण का विवरण (टेक्स्टअरे), वर्कअराउंड (टेक्स्टअरे)
हम अंग्रेजी के सभी क्षेत्रों का वर्णन करते हैं, और / ऑप्ट / ओटस / कर्नेल / भाषा / फ़ोल्डर में स्थित ru.pm फ़ाइल के माध्यम से अनुवाद करते हैं।

ड्रॉपडाउन फ़ील्ड के लिए, पूर्वनिर्धारित मान सेट करें

कॉन्फ़िगरेशन टिकट में जोड़ें -> फ्रंटेंड :: एजेंट :: टिकट :: ViewAddtlITSMField


एजेंट इंटरफ़ेस में ऐसा दिखता है।

निर्णय

समस्या का समाधान पाए जाने के बाद, हमें अपनी स्थिति को "बंद सफलतापूर्वक" बदलकर समस्या को औपचारिक रूप से बंद कर देना चाहिए।

रिपोर्टिंग

प्रबंधन रिपोर्टिंग

• दी गई अवधि में दर्ज की गई समस्याओं की संख्या।
• रिपोर्टिंग अवधि के लिए समस्याओं को हल करने की लागत
• प्राथमिकता के साथ% समस्याएं 5

रिपोर्टिंग समस्या प्रबंधक

• एक निश्चित अवधि के लिए समस्याओं का कारण, सेवाओं द्वारा, CI द्वारा।

PS 3.2 संस्करण में, एक नई सुविधा दिखाई दी: ProcessManagment, जो आपको वर्कफ़्लो का उपयोग करके अनुप्रयोगों को प्रबंधित करने की अनुमति देता है, इसलिए आपको अनुरोध पूर्ति प्रक्रिया पर वापस लौटना होगा