किसी व्यक्ति को दोष दिए बिना प्रक्रिया से जुड़े समर्थित कारण का पता लगाएं
एक उपयोगी मूल-कारण की परिभाषा तीन चीजों को अलग करती है: वह लक्षण जो आपने देखा, वह स्थिति जिसने इसे घटित होने में मदद की, और साक्ष्यों द्वारा समर्थित कारण। एक सामुदायिक शिल्प कार्यशाला के लिए, इसका मतलब यह हो सकता है कि दो लोगों को एक ही सीट के लिए पुष्टिकरण (कन्फर्मेशन) प्राप्त होता है; फोन और ऑनलाइन बुकिंग को अलग-अलग रिकॉर्ड में संभाला जा रहा है; और एक विलंबित अपडेट के कारण फोन द्वारा आरक्षित होने के बाद भी सीट ऑनलाइन उपलब्ध रह जाती है। अंतिम कथन केवल तभी एक कारण है यदि रिकॉर्ड उस तंत्र का समर्थन करते हैं। यह प्रक्रिया की किसी छोटी समस्या का विवरण लिखने का एक व्यावहारिक तरीका है, न कि यह दावा कि प्रत्येक विश्लेषण में लेबलों के एक ही निश्चित सेट का उपयोग होना चाहिए।
किसी छोटे प्रोजेक्ट में "मूल कारण" का क्या अर्थ है?
अमेरिकन सोसाइटी फॉर क्वालिटी (ASQ) मूल कारण को एक ऐसे कारक के रूप में परिभाषित करती है जिसने गैर-अनुरूपता (नॉनकनफॉरमेंस) पैदा की और जिसे सुधारात्मक कार्रवाई के माध्यम से संबोधित किया जाना चाहिए। यह मूल-कारण विश्लेषण को यह उजागर करने के तरीके के रूप में वर्णित करता है कि कोई समस्या क्यों उत्पन्न हुई, और ध्यान दिलाता है कि घटना-और-कारक-घटक विश्लेषण कारण और योगदान देने वाले कारकों की पहचान करने के लिए साक्ष्य और समय-सीमा का उपयोग करता है। वे विचार एक सरल कार्यशील परिभाषा का समर्थन करते हैं: एक मूल कारण प्रक्रिया का एक साक्ष्य-समर्थित हिस्सा है जो बताता है कि बताई गई समस्या कैसे उत्पन्न हुई और जिसे एक व्यावहारिक बदलाव के माध्यम से संबोधित किया जा सकता है। ASQ का मूल-कारण विश्लेषण मार्गदर्शन
"मूल" (रूट) यह संकेत दे सकता है कि केवल एक ही कारण है। वास्तविक प्रक्रिया की समस्याओं में, कई कारक मिलकर काम कर सकते हैं। ASQ स्वयं कारण और योगदान देने वाले कारकों को संदर्भित करता है, इसलिए एक सावधानीपूर्वक तैयार किया गया विवरण एक से अधिक कारणों की पहचान कर सकता है जहाँ साक्ष्य इसका समर्थन करते हैं। केवल इसलिए किसी सुविधाजनक स्पष्टीकरण को चुनने से बचें क्योंकि यह किसी के द्वारा सुझाया गया पहला विचार है।
एक लक्षण, एक योगदान देने वाली स्थिति और एक कारण किस प्रकार भिन्न हैं?
ये लेबल समस्या के एक संक्षिप्त विवरण को अधिक स्पष्ट बनाने में मदद करते हैं। वे विवरण लिखने में सहायक हैं, वास्तव में क्या हुआ था इसकी जांच करने का विकल्प नहीं।
कोई स्थिति पूरे तंत्र को समझाए बिना भी योगदान दे सकती है। उदाहरण के लिए, किसी व्यस्त कार्यशाला के दौरान अपडेट में देरी हो सकती है, लेकिन केवल "बहुत व्यस्तता थी" यह नहीं समझाता कि दूसरा पुष्टिकरण कैसे संभव हुआ। कारण के कथन को प्रक्रिया और परिणाम के बीच संबंध जोड़ना चाहिए, और यह किसी जांचने योग्य तथ्य द्वारा समर्थित होना चाहिए: टाइमस्टैम्प, बुकिंग रिकॉर्ड, या आरक्षण के चरणों का विस्तृत अवलोकन। यदि वह साक्ष्य गायब है, तो स्पष्टीकरण को तब तक एक संभावित कारण कहें जब तक कि उसकी जांच न हो जाए।
समर्थित कारण खोजने के लिए प्रश्नों का एक संक्षिप्त क्रम
किसी व्यक्ति के बारे में निर्णय लेने के बजाय घटना से शुरुआत करें। ASQ व्यवस्थित रूप से एक समयरेखा (टाइमलाइन) स्थापित करने और कारणों तथा प्रभावों का विश्लेषण करने की अनुशंसा करता है; निम्नलिखित प्रश्न उस दृष्टिकोण को एक छोटी बुकिंग समस्या पर लागू करते हैं। मूल-कारण विश्लेषण का ASQ का अवलोकन
यह "पाँच क्यों" (five whys) पूछताछ जैसा दिखता है, लेकिन पाँच कोई अनिवार्य संख्या नहीं है। तब रुकें जब आपके पास एक विशिष्ट, सत्यापन योग्य प्रक्रिया स्पष्टीकरण हो जो घटना का विवरण देता हो और समाधान के परीक्षण का मार्गदर्शन कर सके। यदि कोई प्रश्न साक्ष्य के बजाय अटकलों को जन्म देता है, तो अनिश्चितता को चिह्नित करें और उत्तर को स्थापित मानने से पहले कोई रिकॉर्ड खोजें या प्रक्रिया का अवलोकन करें।
निष्कर्ष को बढ़ा-चढ़ाकर बताए बिना लिखें
एक संक्षिप्त विवरण इस पैटर्न का उपयोग कर सकता है:
> लक्षण: [अवलोकन योग्य परिणाम।] योगदान देने वाली स्थिति: [वह परिस्थिति जिसने इसे अधिक संभावित बनाया।] साक्ष्य द्वारा समर्थित कारण: [प्रक्रिया तंत्र, साथ ही वह साक्ष्य जो इसका समर्थन करता है।]
ऊपर दिए गए उदाहरणात्मक परिदृश्य पर लागू किया गया:
यह उदाहरण काल्पनिक है; इसके साक्ष्य चित्रण का हिस्सा हैं, किसी वास्तविक कार्यशाला के बारे में रिपोर्ट नहीं। किसी वास्तविक जाँच में, माने गए क्रम को अपने द्वारा जाँचे गए रिकॉर्ड से बदलें। यदि आप अभी तक यह स्थापित नहीं कर सकते हैं कि फ़ोन बुकिंग दूसरी पुष्टि से पहले हुई थी या ऑनलाइन सूची में अभी भी सीट खाली दिखाई दे रही थी, तो "संभावित कारण" लिखें और निर्दिष्ट करें कि आपको क्या सत्यापित करने की आवश्यकता है।
एक प्रतिवर्ती (रिवर्सिबल) समाधान चुनें और जाँचें कि क्या यह कार्यप्रणाली को संबोधित करता है
कम जोखिम वाले परीक्षण के लिए, कार्यशाला प्रत्येक बुकिंग चैनल के लिए एक साझा उपलब्धता बहीखाता (लेज़र) का उपयोग कर सकती है। कर्मचारी आरक्षण दर्ज करेंगे और इसकी पुष्टि करने से पहले सीट को अनुपलब्ध के रूप में चिह्नित करेंगे, चाहे अनुरोध फ़ोन द्वारा आया हो या ऑनलाइन। यह प्रस्तावित कार्यप्रणाली को लक्षित करता है—दो चैनल अलग-अलग या पुराने दृश्यों से पुष्टि करते हैं—बिना किसी स्थायी सिस्टम परिवर्तन की आवश्यकता के।
एक स्पष्ट शुरुआत और समाप्ति बिंदु के साथ, आगामी सत्रों के एक सीमित सेट के लिए इस प्रक्रिया को आज़माएँ। साझा बहीखाते के साथ प्रत्येक पुष्टि की तुलना करें और बुकिंग संभालने वाले कर्मचारियों से पूछें कि क्या वे लगातार इस क्रम का पालन कर सकते हैं। यदि डुप्लिकेट पुष्टियां जारी रहती हैं, या पुष्टि से पहले बहीखाता विश्वसनीय रूप से अपडेट नहीं किया जाता है, तो परीक्षण ने यह स्थापित नहीं किया है कि यह परिवर्तन कारण को नियंत्रित करता है। चरणों और साक्ष्यों की फिर से समीक्षा करें; यह न मानें कि उसी सुधार को दोहराने से कोई भिन्न कार्यप्रणाली हल हो जाएगी।
इसलिए एक अच्छी परिभाषा केवल किसी समस्या का नाम बताने से कहीं अधिक काम करती है। यह किसी अन्य व्यक्ति को यह देखने देती है कि क्या देखा गया था, किस स्थिति ने योगदान दिया हो सकता है, साक्ष्य किस प्रक्रियात्मक व्याख्या का समर्थन करते हैं, और एक छोटा, प्रतिवर्ती परिवर्तन उस व्याख्या का परीक्षण कैसे कर सकता है।
स्रोत और दायरा
मूल डबल-बुकिंग उदाहरण एक प्रतिवर्ती प्रक्रिया परीक्षण के लिए साक्ष्यों का अनुसरण करता है। सूचीबद्ध स्रोत उल्लिखित तथ्यों का समर्थन करते हैं; उदाहरण और अभ्यास मूल संपादकीय अनुप्रयोग हैं।