मेन्यू

गाइड टू रूट कॉज़ एनालिसिस - स्टेप्स, टेक्निक्स एंड एग्ज़ाम्पल्स

  • मुख्य
  • अन्य
  • गाइड टू रूट कॉज़ एनालिसिस - स्टेप्स, टेक्निक्स एंड एग्ज़ाम्पल्स

guide root cause analysis steps

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

यह ट्यूटोरियल बताता है कि रूट कॉज एनालिसिस क्या है और फिशबोन एनालिसिस और 5 व्हिइस टेक्नीक जैसे अलग-अलग रूट कॉज एनालिसिस क्यों हैं:

RCA (मूल कारण विश्लेषण) सॉफ़्टवेयर प्रोजेक्ट टीम में समस्याओं के मूल कारण का पता लगाने के लिए एक संरचित और प्रभावी प्रक्रिया है। यदि व्यवस्थित रूप से प्रदर्शन किया जाता है, तो यह न केवल टीम स्तर पर बल्कि संगठन में भी डिलिवरेबल्स और प्रक्रियाओं के प्रदर्शन और गुणवत्ता में सुधार कर सकता है।

यह ट्यूटोरियल आपको अपनी टीम या संगठन में रूट कॉज़ एनालिसिस प्रक्रिया को परिभाषित और व्यवस्थित करने में मदद करेगा।

मूल कारण विश्लेषण

यह ट्यूटोरियल रूट मैनेज एनालिसिस की मूल बातों को समझने के लिए डिलिवरी मैनेजर्स, स्क्रैम मास्टर्स, प्रोजेक्ट मैनेजर्स, क्वालिटी मैनेजर्स, डेवलपमेंट टीम, टेस्ट टीम, इंफॉर्मेशन मैनेजमेंट टीम, क्वालिटी टीम, सपोर्ट टीम आदि के लिए अभिप्रेत है। ।

आप क्या सीखेंगे:

रूट कारण विश्लेषण क्या है?

RCA (मूल कारण विश्लेषण) दोषों के विश्लेषण का एक तंत्र है, इसके कारण की पहचान करना। हम इस बात की पहचान करने के लिए कि क्या दोष 'की वजह से था' परीक्षण मिस ',' विकास की याद आती है 'या था' आवश्यकता या डिजाइन याद आती है ”।

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

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

मूल कारण विश्लेषण प्रक्रिया

परिचय

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

रूट कॉज का विश्लेषण करना उस डॉक्टर के काम के समान है जो एक मरीज का इलाज करता है। डॉक्टर पहले लक्षणों को समझेंगे। फिर वह रोग के मूल कारण का विश्लेषण करने के लिए प्रयोगशाला परीक्षणों का उल्लेख करेगा।

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

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

मूल कारण विश्लेषण का नाम:

रूट कॉज एनालिसिस नाम की उत्पत्ति

(छवि स्रोत )

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

रूट कारण विश्लेषण के लाभ

नीचे सूचीबद्ध कुछ लाभ हैं, आपको मिलेगा:

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

रूट कारणों के प्रकार

# 1) मानव कारण: मानव निर्मित त्रुटि।

उदाहरण:

  • कुशल के तहत।
  • निर्देशों का विधिवत पालन नहीं हुआ।
  • एक अनावश्यक ऑपरेशन किया।

# 2) संगठनात्मक कारण: एक प्रक्रिया जो लोग निर्णय लेने के लिए उपयोग करते हैं जो उचित नहीं थे।

उदाहरण:

  • टीम लीड से टीम के सदस्यों को अस्पष्ट निर्देश दिए गए थे।
  • किसी कार्य के लिए गलत व्यक्ति को चुनना।
  • गुणवत्ता का आकलन करने के लिए उपकरण की निगरानी नहीं करना।

# 3) शारीरिक कारण: कोई भी भौतिक वस्तु किसी तरह से विफल रही।

उदाहरण:

  • कंप्यूटर रीस्टार्ट होता रहता है।
  • सर्वर बूट नहीं हो रहा है।
  • सिस्टम में अजीब या जोर से शोर।

रूट कारण विश्लेषण करने के लिए कदम

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

रूट कारण विश्लेषण करने के लिए कदम

(1) फॉर्म आरसीए टीम

हर टीम को एक समर्पित होना चाहिए रूट कारण विश्लेषण प्रबंधक (आरसीए प्रबंधक) जो सपोर्ट टीम से विवरण एकत्र करेंगे और आरसीए के लिए किक-ऑफ प्रक्रिया शुरू करेंगे। वह उन संसाधनों का समन्वय और आबंटन करेगा, जिन्हें आरसीए बैठकों में शामिल होने की जरूरत है।

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

बैठक में भाग लेने से पहले टीम के साथ समस्या का विवरण साझा करें ताकि वे कुछ प्रारंभिक विश्लेषण कर सकें और तैयार हो सकें। टीम के सदस्य दोष से संबंधित जानकारी भी एकत्र करते हैं। घटना की रिपोर्ट के आधार पर, प्रत्येक टीम अपने चरणों में इस परिदृश्य में गलत w.r.t का पता लगाएगी। तैयार होने से आगामी चर्चा की दक्षता बढ़ जाएगी।

# 2) समस्या को परिभाषित करें

समस्या का विवरण, घटना की रिपोर्ट, समस्या के सबूत (स्क्रीनशॉट, लॉग, रिपोर्ट, आदि) को इकट्ठा करें, फिर नीचे दिए गए प्रश्नों को पूछकर समस्या का अध्ययन / विश्लेषण करें:

  • समस्या क्या है?
  • घटनाओं का क्रम क्या है जिससे समस्या पैदा हुई?
  • क्या सिस्टम शामिल थे?
  • समस्या कब तक अस्तित्व में थी?
  • समस्या का प्रभाव क्या है?
  • कौन शामिल था और निर्धारित करता है कि किसका साक्षात्कार होना चाहिए?

अपनी समस्या को परिभाषित करने के लिए 'स्मार्ट' नियमों का उपयोग करें:

  • एस विशेष
  • म आसान
  • सेवा मेरे CTION-ORIENTED
  • आर हाथी
  • टी NAME-BOUND

जॉन डेवी बोली

# 3) मूल कारण को पहचानें

आचरण करना बुद्धिशीलता कारणों की पहचान के लिए गठित आरसीए टीम के भीतर सत्र। उपयोग फ़िशबोन चित्र या 5 विश्लेषण क्यों विधि या दोनों मूल कारण / s पर पहुंचने के लिए।

आरसीए प्रबंधक को बैठक को मध्यम करना चाहिए और विचार मंथन सत्र के लिए नियम निर्धारित करने चाहिए। उदाहरण के लिए, नियम निम्न हो सकते हैं:

  1. दूसरों की आलोचना / दोषारोपण की अनुमति नहीं दी जानी चाहिए।
  2. दूसरे के विचारों को न आंकें। कोई भी विचार बुरा नहीं है वे जंगली विचारों को प्रोत्साहित करते हैं।
  3. दूसरों पर विचारों का निर्माण करें। इस बारे में सोचें कि आप अन्य विचारों पर कैसे निर्माण कर सकते हैं और इसे बेहतर बना सकते हैं।
  4. प्रत्येक प्रतिभागी को अपने विचार साझा करने का समय दें।
  5. आउट ऑफ बॉक्स सोच को प्रोत्साहित करें।
  6. ध्यान केंद्रित रहना।

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

# 4) मूल कारण सुधारक कार्रवाई (RCCA)

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

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

समाधान को प्रभावी करने के लिए चरणों को मान्य करें और कार्यान्वित समाधान की निगरानी करें।

# 5) मूल कारण निवारक कार्रवाई (RCPA) लागू करें

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

कृपया इसे देखें शोध पत्र में प्रकाशित 'दोष विश्लेषण और सॉफ्टवेयर प्रक्रिया गुणवत्ता सुधार के लिए रोकथाम' पर सॉफ्टवेयर इंजीनियरिंग और अनुप्रयोग के अंतर्राष्ट्रीय जर्नल प्रत्येक सॉफ़्टवेयर चरण में रिपोर्ट किए गए दोषों के प्रकारों का अंदाजा लगाने के लिए और उनके लिए निवारक क्रियाओं का सुझाव दिया।

आरसीए से प्राप्त जानकारी इनपुट के रूप में जा सकती है विफलता मोड और प्रभाव विश्लेषण (FMEA) ) उन बिंदुओं की पहचान करने के लिए जहां समाधान विफल हो सकता है।

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

ड्यूक एलिंगटन बोली

मूल कारण विश्लेषण तकनीक

# 1) फिशबोन विश्लेषण

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

इसे इशिकावा आरेख भी कहा जाता है क्योंकि इसे बनाया गया था डॉ। कोरु इशिकावा (एक जापानी गुणवत्ता नियंत्रण सांख्यिकीविद्)। इसे हेरिंगबोन या फिशिकावा आरेख के रूप में भी जाना जाता है।

फिशबोन विश्लेषण का उपयोग चरण के विश्लेषण में किया जाता है छह सिग्मा का DMAIC समस्या-समाधान के लिए दृष्टिकोण। यह एक है गुणवत्ता नियंत्रण के 7 बुनियादी उपकरण ।

फिशबोन आरेख बनाने के लिए कदम:

फिशबोन आरेख मछली के सिर के आकार की समस्या के साथ एक मछली के कंकाल जैसा दिखता है और मछली की रीढ़ और हड्डियों का कारण बनता है।

फिशबोन आरेख बनाने के लिए नीचे दिए गए चरणों का पालन करें:

  1. लिखना संकट पर मछली का सिर ।
  2. पहचान करें कारणों की श्रेणी और पर लिखें प्रत्येक हड्डी का अंत (कारण श्रेणी 1, कारण श्रेणी 2 …… कारण श्रेणी एन)
  3. पहचान करें प्राथमिक कारण प्रत्येक श्रेणी के तहत और इसे प्राथमिक कारण 1, प्राथमिक कारण 2, प्राथमिक कारण एन के रूप में चिह्नित करें।
  4. के कारणों का विस्तार करें द्वितीयक, तृतीयक और अधिक स्तर जैसा लागू हो।

FIshbone_template

एक फिशबोन आरेख को सॉफ़्टवेयर दोष पर कैसे लागू किया जाता है इसका एक उदाहरण (नीचे देखें)।

FIshbone_softwareDefect

फ़िशबोन आरेख बनाने के लिए बहुत सारे मुफ्त और भुगतान किए गए उपकरण उपलब्ध हैं। इस ट्यूटोरियल में फिशबोन आरेख b का उपयोग करके बनाया गया था रचनात्मक रूप से ' ऑनलाइन टूल । फिशबोन टेम्प्लेट और टूल के बारे में अधिक जानकारी हमारे अगले ट्यूटोरियल में बताई जाएगी।

# 2) 5 Whys तकनीक

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

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

तकनीक की सफलता व्यक्ति के ज्ञान पर निर्भर करती है। एक ही क्यों प्रश्न के अलग-अलग उत्तर हो सकते हैं। इसलिए, बैठक में सही दिशा और फोकस का चयन करना महत्वपूर्ण है।

5 Whys आरेख बनाने के लिए कदम

समस्या को परिभाषित करके विचार-विमर्श शुरू करें। तो बाद में क्यों और उनके जवाब के साथ पालन करें।

5Why_Template

एक सॉफ्टवेयर दोष के लिए 5 Whys आरेख कैसे लागू किया जाता है, इसका एक उदाहरण:

5Why_Software_Defect उदाहरण

5 टेम्प्लेट और सॉफ्टवेयर ऑनलाइन क्रिएट क्यों किए जाते हैं।

कारक दोष

कई कारक हैं जो दोष उत्पन्न करने के लिए उकसाते हैं:

  • अस्पष्ट / गुम / गलत आवश्यकताएं
  • गलत डिजाइन
  • गलत कोडिंग
  • अपर्याप्त परीक्षण
  • पर्यावरण के मुद्दे (हार्डवेयर, सॉफ़्टवेयर या कॉन्फ़िगरेशन)

आरसीए प्रक्रिया करते समय इन कारकों को हमेशा ध्यान में रखा जाना चाहिए।

आरसीए शुरू होता है और दोष पर मंथन के साथ आगे बढ़ता है। केवल एक सवाल जो हम आरसीए करते समय खुद से पूछते हैं वह है 'क्यों?' और क्या?' हम ट्रैक करने के लिए जीवन चक्र के प्रत्येक चरण में खुदाई कर सकते हैं, जहां दोष बनी रहती है।

चलो 'क्यों?' प्रश्न, (सूची सीमित नहीं है)। आप बाहरी चरण से शुरू कर सकते हैं और एसडीएलसी के आंतरिक चरण की ओर बढ़ सकते हैं।

सी ++ के लिए ग्रहण की स्थापना
  • परीक्षण के दौरान दोष क्यों नहीं पकड़ा गया?
  • टेस्ट केस की समीक्षा के दौरान 'दोष' को क्यों नहीं पकड़ा गया?
  • 'क्यों' डिजाइन समीक्षा के दौरान दोष पकड़ा नहीं गया था?
  • आवश्यकता के चरण के दौरान दोष को क्यों नहीं पकड़ा गया?

इस प्रश्न का उत्तर आपको सटीक चरण देगा, जहां दोष मौजूद है। अब एक बार जब आप चरण और कारण की पहचान करते हैं, तो 'WHAT' भाग आता है।

“भविष्य में इससे बचने के लिए आप क्या करेंगे?

इस 'WHAT' प्रश्न का उत्तर, यदि लागू किया गया और ध्यान रखा गया, तो फिर से उत्पन्न होने वाले दोष या उस तरह के दोष को रोका जा सकेगा। पहचान की गई प्रक्रिया को बेहतर बनाने के लिए उचित उपाय करें ताकि दोष या दोष का कारण दोहराया न जाए।

आरसीए के परिणामों के आधार पर, आप यह निर्धारित कर सकते हैं कि समस्या के किस चरण में समस्या है।

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

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

निष्कर्ष

यह पूरी टीम की जिम्मेदारी है कि वह दोषों का विश्लेषण और विश्लेषण करे और उत्पाद और प्रक्रिया में सुधार करे।

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

अनुशंसित पाठ

^