8D रिपोर्ट कैसे लिखें: D0–D8 और Toyota के 8 स्टेप से फ़र्क

मान लीजिए कस्टमर के receiving inspection में आपके भेजे ब्रैकेट टॉलरेंस से बाहर निकले। कुछ ही घंटों में उनका supplier quality engineer ईमेल करता है: "Please respond with an 8D." उनके supplier quality manual में पहले जवाब के लिए 24 घंटे लिखे हैं। अगर आपने कंपनी के अंदर वाली साधारण defect report भेज दी, जिसमें कारण की एक लाइन और सुधार की एक लाइन होती है, तो वह अक्सर वापस आ जाती है।

8D रिपोर्ट कस्टमर को भेजी जाने वाली तय क्रम की रिपोर्ट है। इसमें पहले जवाब से लेकर असली कारण, सुधार की कार्रवाई और दोबारा न होने का इंतज़ाम तक सब कुछ आता है। अच्छी 8D की जान है दो अलग-अलग असली कारण। पहला है पैदा होने का कारण (occurrence cause), यानी खराब पीस बना क्यों। दूसरा है निकल जाने का कारण (escape cause), यानी वह कस्टमर तक पहुँचने से पहले पकड़ा क्यों नहीं गया।

जापानी क्वालिटी टीमें भी यही बँटवारा करती हैं। वे इन्हें hassei gen'in (पैदा होने का कारण) और ryushutsu gen'in (बाहर निकलने का कारण) कहती हैं।

कस्टमर आपकी भाषा की सुंदरता नहीं देखता। वह यह देखता है कि आपने दोनों कारणों में से हर एक के खिलाफ़ ऐसा उपाय किया या नहीं जो सिस्टम में बदलाव लाए। इस लेख में चार बातें हैं: 8D कहाँ से आया और Toyota के 8 स्टेप से कैसे अलग है, D0 से D8 तक हर स्टेप में क्या लिखना है, किन गलतियों से 8D वापस आती है, और एक चेकलिस्ट व सवालों की लिस्ट जो आप दोबारा इस्तेमाल कर सकते हैं।

विषय-सूची

1. 8D रिपोर्ट क्या है?
2. कस्टमर 8D कब माँगता है और कितने समय में
3. D0–D8 के स्टेप एक नज़र में
4. D0–D3: टीम, समस्या का ब्योरा और containment
5. D4: पैदा होने और निकल जाने के असली कारण अलग करें
6. D5–D6: स्थायी एक्शन चुनना और उसका असर जाँचना
7. D7–D8: दोबारा होने से रोकना और काम पूरा करना
8. 8D वापस क्यों आती है
9. टेम्पलेट: D4–D5 की कारण-से-एक्शन टेबल
10. शुरू करने से पहले कस्टमर से पूछने के सवाल
11. इस गाइड की सीमाएँ
12. FAQ
13. स्रोत

8D रिपोर्ट क्या है?

8D रिपोर्ट में लिखा जाता है कि टीम ने क्वालिटी की समस्या को आठ स्टेप (discipline) में कैसे हल किया और क्या पाया। Siemens के मुताबिक 8D रिपोर्ट आठ स्टेप वाली समस्या-हल प्रक्रिया का नतीजा है। इसे manufacturing की गड़बड़ी (nonconformity) सुलझाने और लगातार सुधार के लिए इस्तेमाल किया जाता है।

"8D" तरीके का नाम है और रिपोर्ट उसका रिकॉर्ड। मकसद फ़ॉर्म भरना नहीं है। मकसद यह है कि टीम ने समस्या कैसे सुलझाई, इसका रास्ता ऐसे रूप में रखा जाए कि कस्टमर बाद में भी जाँच सके।

शुरुआत: Ford, TOPS और Global 8D

8D की शुरुआत Ford Motor Company में हुई। Ford के Powertrain विभाग का मैनेजमेंट चाहता था कि design, manufacturing engineering और production के लोग पुरानी, बार-बार लौटने वाली समस्याओं पर टीम बनाकर काम करें। इसके लिए 1986 में मैनुअल और ट्रेनिंग बनाने का काम शुरू हुआ।

मैनुअल का पहला एडिशन Team Oriented Problem Solving (TOPS) 1987 में आया। 1990 के दशक के आख़िर में Ford ने इसे बदलकर Global 8D (G8D) बनाया। इसमें D0 जुड़ा, जिसमें लक्षण और इमरजेंसी कार्रवाई लिखी जाती है। साथ में escape point का विचार भी आया, यानी वह जगह जहाँ समस्या पकड़ी जानी चाहिए थी पर नहीं पकड़ी गई।

आज ज़्यादातर कस्टमर जो D0–D8 के नौ स्टेप वाला रूप इस्तेमाल करते हैं, वह G8D पर टिका है। कुछ स्रोत बताते हैं कि 8D में MIL-STD-1520 से मिलते-जुलते हिस्से हैं। यह 1974 का अमेरिकी रक्षा विभाग का standard है, जो खराब मटीरियल की सुधार कार्रवाई के बारे में है। पर 8D पर इसका सीधा असर था या नहीं, इस पर राय बँटी हुई है। 8D ऑटो इंडस्ट्री से शुरू हुआ और अब food, healthcare और electronics की manufacturing में भी फैल चुका है।

8D और Toyota का 8-स्टेप समस्या-समाधान

8D से सबसे ज़्यादा जिसे मिलाया जाता है, वह Toyota का आठ स्टेप वाला तरीका है। इसे TBP (Toyota Business Practices) भी कहते हैं। दोनों में आठ स्टेप हैं, पर दोनों की जड़ें और इस्तेमाल अलग हैं। Ford से आया 8D ज़्यादातर कस्टमर को खराबी का जवाब देने वाले फ़ॉर्मेट के रूप में इस्तेमाल होता है।

Toyota के आठ स्टेप समस्या साफ़ करने और टारगेट तय करने से शुरू होते हैं। फिर असली कारण (shin'in) तक पहुँचना और नतीजे को टिकाना आता है। यह अपनी कंपनी के अंदर समस्या सुलझाने का तरीका है। यह एक A3 कागज़ पर पूरा सार लिखने के लिए जाना जाता है।

चित्र 1: 8D और Toyota का 8-स्टेप तरीका

सोचने का तरीका काफ़ी मिलता है, पर हर एक में एक ऐसा स्टेप है जो दूसरे में नहीं है: 8D में containment (D3), Toyota के आठ स्टेप में टारगेट तय करना।

8D रिपोर्ट

Toyota का 8-स्टेप समस्या-समाधान

शुरुआत

Ford का टीम वाला समस्या-समाधान तरीका (आधार: TOPS, 1987)

Toyota के अंदर इस्तेमाल होने वाला समस्या सुलझाने का ढाँचा

मुख्य इस्तेमाल

कस्टमर को खराबी का जवाब; supplier की सुधार कार्रवाई

कंपनी के अंदर सुधार और समस्या-समाधान; A3 शीट पर शेयर करना

समस्या को कैसे बताते हैं

D2: 5W2H और Is/Is Not से समस्या लिखें

1 समस्या साफ़ करें / 2 समस्या को हिस्सों में बाँटें (फ़ोकस छोटा करें)

टारगेट

अलग स्टेप नहीं है

3 टारगेट तय करें

अस्थायी कार्रवाई

D3: containment (निकले हुए खराब पीस अलग करना और छाँटना)

अलग स्टेप नहीं है

कारण

D4: पैदा होने और निकल जाने के कारण अलग करें और असली कारण की पुष्टि करें

4 असली कारण खोजें (बार-बार "क्यों" पूछकर असली कारण तक पहुँचें)

कार्रवाई और असर

D5–D6: स्थायी एक्शन चुनें, लागू करें और असर जाँचें

5 उपाय की योजना बनाएँ / 6 उपाय को पूरा करें / 7 नतीजे और प्रोसेस पर नज़र रखें

टिकाना

D7: स्टैंडर्ड अपडेट करें और मिलते-जुलते प्रोडक्ट तक फैलाएँ; D8: टीम के साथ काम पूरा करें

8 कामयाब तरीके को स्टैंडर्ड बनाएँ

Toyota वाले तरीके के स्टेप के नाम अलग-अलग स्रोतों में थोड़े अलग मिलते हैं। पंक्तियाँ मकसद की समानता के हिसाब से रखी हैं, ये ठीक एक-से-एक जोड़ी नहीं हैं।

अगर कस्टमर 8D माँगे और आपकी टीम समस्या को पहले ही Toyota के आठ स्टेप से जाँच चुकी हो, तो उस काम का ज़्यादातर हिस्सा दोबारा काम आएगा। समस्या को हिस्सों में बाँटकर जो समस्या छोटी की थी, वह D2 में जाएगी। असली कारण वाला विश्लेषण D4 में जाएगा और स्टैंडर्ड बनाना D7 में।

जो आप छोड़ नहीं सकते, वह यह है: 8D में containment का दायरा और निकल जाने का कारण, दोनों अलग-अलग दिखने चाहिए। कंपनी के अंदर का सुधार-रिकॉर्ड जस का तस भेजने पर आम तौर पर ये दोनों छूट जाते हैं, और यही रिपोर्ट वापस आने की एक आम वजह है।

8D और कंपनी की अंदरूनी defect रिपोर्ट

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

8D इसके उलट वह दस्तावेज़ है जिससे कस्टमर तय करता है कि आप उसकी क्वालिटी बचा सकते हैं या नहीं। इसलिए इसमें तीन बातें अलग-अलग दिखानी पड़ती हैं: खराब पीस कस्टमर तक जाने से कैसे रोके, वे बने क्यों, और inspection से बच कैसे गए।

चित्र 2: अंदरूनी defect रिपोर्ट और 8D रिपोर्ट

8D को ऐसा सबूत मानकर लिखें जिससे कस्टमर तय कर सके कि आप उसकी क्वालिटी बचा सकते हैं या नहीं।

अंदरूनी defect रिपोर्ट

8D रिपोर्ट

पढ़ने वाले

कंपनी के दूसरे विभाग, आपके मैनेजर

कस्टमर की क्वालिटी एश्योरेंस टीम, ऑडिटर

फ़ॉर्मेट

हर कंपनी का अपना

D0–D8 का तय क्रम; कुछ कस्टमर अपना फ़ॉर्म भी देते हैं

कारण कैसे लिखा जाता है

अक्सर एक ही बात में समेट दिया जाता है, जैसे "operator की गलती"

पैदा होने और निकल जाने के कारण अलग, और दोनों असली कारण तक खोदे हुए

कार्रवाई का दायरा

ज़्यादातर उसी प्रोसेस को ठीक करना जिसने खराबी बनाई

containment, स्थायी एक्शन, मिलते-जुलते प्रोडक्ट तक फैलाना और स्टैंडर्ड अपडेट

कब बंद होती है

जब सुधार लागू हो जाए

जब डेटा से साबित हो कि सुधार काम कर रहा है और कस्टमर रिपोर्ट मंज़ूर कर ले

कई कंपनियाँ अंदरूनी खराबियों के लिए भी 8D वाली सोच इस्तेमाल करती हैं और अपने लिए फ़ॉर्म का छोटा रूप रखती हैं।

ज़्यादातर कंपनियों में 8D क्वालिटी एश्योरेंस विभाग लिखता है, क्योंकि कस्टमर से बात वही करता है। पर असली कारण का विश्लेषण और सुधार production, manufacturing engineering और design की मदद के बिना आगे नहीं बढ़ते।

कस्टमर 8D कब माँगता है और कितने समय में

आम तौर पर 8D तब माँगी जाती है जब आपके भेजे पार्ट्स में खराबी मिलती है। कस्टमर उसे receiving inspection या असेंबली लाइन पर पकड़ सकता है, या बाज़ार में किसी फ़ेल्योर को आपके पार्ट तक वापस ढूँढ सकता है।

ऑटो इंडस्ट्री में 8D इतनी आम है, इसकी बड़ी वजह IATF 16949 है, जो ऑटोमोटिव क्वालिटी मैनेजमेंट का standard है। इसकी clause 10.2.3, "Problem solving", एक लिखित समस्या-समाधान प्रक्रिया माँगती है। उसमें ये बातें होनी चाहिए:

• Containment और अस्थायी कार्रवाई (interim actions)
• असली कारण का विश्लेषण (root cause analysis)
• सिस्टम स्तर की सुधार कार्रवाई, जिसमें मिलते-जुलते प्रोडक्ट और प्रोसेस पर असर भी सोचा गया हो
• असर की पुष्टि (verification of effectiveness)
• PFMEA और control plan जैसे दस्तावेज़ों की समीक्षा और अपडेट

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

इंडस्ट्री संस्थाओं ने भी 8D की गाइड छापी हैं। जर्मन ऑटोमोबाइल इंडस्ट्री संघ के क्वालिटी मैनेजमेंट सेंटर (VDA QMC) ने 2018 में 8D की किताब निकाली। अमेरिका की ऑटो इंडस्ट्री संस्था AIAG भी CQI-20 नाम की समस्या-समाधान गाइड छापती है। कस्टमर बदलने पर फ़ॉर्म और बारीक माँगें बदल जाती हैं, उसकी एक वजह यह है कि कस्टमर अलग-अलग गाइड मानते हैं।

समय-सीमा कस्टमर के मैनुअल से तय होती है

कौन-सा स्टेप कब तक देना है, यह हर कस्टमर के supplier quality manual में लिखा होता है। सब पर लागू होने वाला कोई एक नियम नहीं है, इसलिए सबसे पहले फ़ॉर्म और समय-सीमा पूछकर पक्का करें।

एक मिसाल जर्मन ऑटो पार्ट्स कंपनी MAHLE का "1-5-20 नियम" है। शिकायत की तारीख़ से supplier को 1 दिन (24 घंटे) में containment बताना होता है। 5 कार्य-दिवस में असली कारण और सुधार की कार्रवाई, और 20 कार्य-दिवस में लागू की गई कार्रवाई और दोबारा न होने का इंतज़ाम बताना होता है।

चित्र 3: समय-सीमा की मिसाल (MAHLE का 1-5-20 नियम)

इस मिसाल की तरह, कस्टमर 8D एक साथ नहीं, कई चरणों में माँग सकता है और हर चरण की अपनी समय-सीमा होती है।

24 घंटेD1–D3टीम, समस्या का ब्योरा और containment की कार्रवाई बताएँ

5 कार्य-दिवसD1–D5असली कारण का विश्लेषण और चुनी गई सुधार कार्रवाई बताएँ

20 कार्य-दिवसD1–D8लागू की गई कार्रवाई और दोबारा न होने का इंतज़ाम बताकर बंद करें

यह एक कंपनी का नियम है। समय-सीमा और चरण कस्टमर के हिसाब से बदलते हैं, इसलिए हमेशा कस्टमर का क्वालिटी मैनुअल देखें।

अगर समय-सीमा चरणों में बँटी है, तो पहले जवाब तक असली कारण पता होना ज़रूरी नहीं। उलटे, पहली रिपोर्ट में "कारण: operator की गलती" लिख दिया और बाद में बदलना पड़ा, तो भरोसा घटता है। जो पता है और जो अभी जाँच में है, उसे अलग-अलग लिखें और समय पर भेजें।

D0–D8 के स्टेप एक नज़र में

स्टेप चार हिस्सों में बाँटकर देखें तो समझना आसान होता है: कस्टमर को बचाने वाला पहला जवाब, असली कारण की जाँच, स्थायी कार्रवाई और दोबारा न होने का इंतज़ाम, और काम पूरा करना।

चित्र 4: 8D रिपोर्ट के नौ स्टेप

पहले कस्टमर को बचाएँ, फिर कारण खोजें, फिर सिस्टम में बदलाव करके दोबारा होने से रोकें।

पहला जवाब (कस्टमर को बचाना)

D0तैयारी और इमरजेंसी कार्रवाईलक्षण और इमरजेंसी कार्रवाई लिखें; तय करें कि 8D चाहिए या नहीं

D1टीम बनाएँविश्लेषण और कार्रवाई के लिए अलग-अलग विभागों के ज़रूरी लोग जोड़ें

D2समस्या का ब्योरा5W2H और Is/Is Not से तथ्य और आँकड़े सामने रखें

D3अस्थायी containmentशक वाले पार्ट्स अलग करें और छाँटें ताकि खराब माल बाहर न जाए

असली कारण की जाँच

D4असली कारण पहचानेंपैदा होने और निकल जाने के कारण अलग-अलग खोजें; खराबी दोबारा बनाकर पुष्टि करें

स्थायी कार्रवाई और रोकथाम

D5स्थायी एक्शन चुनेंहर कारण के लिए एक एक्शन चुनें और पक्का करें कि वह काम करेगा

D6लागू करें और असर जाँचेंलागू करें, डेटा से पुष्टि करें, फिर containment हटाएँ

D7दोबारा होने से रोकेंस्टैंडर्ड अपडेट करें और मिलते-जुलते प्रोडक्ट व प्रोसेस तक फैलाएँ

काम पूरा करना

D8बंद करें और टीम का धन्यवादरिपोर्ट पूरी करें और जो सीखा वह सबके साथ बाँटें

कुछ कस्टमर D0 के बिना सिर्फ़ D1–D8 (आठ स्टेप) इस्तेमाल करते हैं। अलग-अलग फ़ॉर्म में स्टेप के नाम भी थोड़े बदल जाते हैं।

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

D0–D3: टीम, समस्या का ब्योरा और containment

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

D0: इमरजेंसी कार्रवाई और 8D की ज़रूरत

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

हर अंदरूनी खराबी पर पूरी 8D चलाई जाए तो कोई टीम संभाल नहीं पाएगी। इसीलिए G8D में D0 से तय किया जाता है कि 8D चाहिए या नहीं। पर जब कस्टमर ने खुद 8D माँगी हो, तब यह तय करने की गुंजाइश आपके पास बहुत कम होती है।

D1: टीम

D1 में उन लोगों के नाम लिखें जो समस्या पर काम कर रहे हैं। सिर्फ़ एक क्वालिटी इंजीनियर का नाम न लिखें। टीम में अलग-अलग विभाग के लोग हों: production, manufacturing engineering, design, और ज़रूरत हो तो आपका अपना supplier भी।

MAHLE का मैनुअल कहता है कि टीम के सदस्य उनके काम (function) के साथ लिखे जाएँ। टीम का एक लीडर हो जो 8D पूरी करने का ज़िम्मेदार हो। साथ ही मैनेजमेंट का एक champion हो जो टीम को ज़रूरी संसाधन मंज़ूर करे।

सिर्फ़ नाम और विभाग नहीं, हर सदस्य की भूमिका भी लिखें। इससे कस्टमर समझ पाता है कि टीम एक्शन सच में लागू कर सकती है या नहीं।

D2: 5W2H और Is/Is Not से समस्या का ब्योरा

टीमें अक्सर D2 जल्दी में निपटा देती हैं, और 8D की क्वालिटी में सबसे ज़्यादा फ़र्क यहीं पड़ता है। सिर्फ़ "दिखने में खराबी" या "साइज़ की खराबी" न लिखें। लिखें कि कौन-सी characteristic स्पेक से बाहर थी और कितनी।

एक आम ढाँचा 5W2H है: क्या, कब, कहाँ, कौन, क्यों, कैसे और कितना। इसके साथ ये तथ्य भी इकट्ठा करें:

• बनने की तारीख़
• शिफ़्ट
• Lot नंबर
• माप के नतीजे
• खराब पीस की गिनती

एक और असरदार तरीका Is/Is Not की तुलना है। जिन हालात में खराबी आ रही है, उन्हें मिलते-जुलते उन हालात के बगल में रखें जहाँ खराबी नहीं आ रही। तब संभावित कारणों की लिस्ट तेज़ी से छोटी हो जाती है।

चित्र 5: Is/Is Not से समस्या छोटी करना (उदाहरण)

कारण का सुराग "Is" और "Is Not" के फ़र्क में छिपा होता है।

मद

Is (खराबी आ रही है)

Is Not (खराबी नहीं आ रही)

क्या

ब्रैकेट के माउंटिंग होल का व्यास ऊपरी सीमा से 0.03 mm ज़्यादा

उसी पार्ट की बाहरी साइज़ और शीट की मोटाई

कहाँ

प्रेस नंबर 2 पर बने lot

उसी डाई वाली प्रेस नंबर 1 पर बने lot

कब

8 सितंबर से नाइट शिफ़्ट

7 सितंबर या उससे पहले; उसी दौरान डे शिफ़्ट

कितने

भेजे गए 5,000 में से 42 (कस्टमर की receiving inspection में मिले)

दूसरे कस्टमर को भेजे उसी तरह के पार्ट पर कोई रिपोर्ट नहीं

यह समझाने के लिए बनाया गया काल्पनिक उदाहरण है। यहाँ आप "प्रेस नंबर 2", "8 सितंबर से" और "नाइट शिफ़्ट" तीनों में साझा किसी बदलाव को ढूँढेंगे (सेटअप, मशीन, operator आदि)।

D2 में ही यह सोचना शुरू कर दें कि कहीं और भी यही समस्या तो नहीं हो रही। जो दूसरे पार्ट नंबर उसी मशीन या डाई पर बनते हैं, उन्हें जल्दी जाँच लें। इससे D7 में योकोतेन (yokoten) बहुत आसान हो जाता है।

D3: अस्थायी containment

D3 का मकसद है कि कारण पता चलने तक खराब पार्ट्स कस्टमर तक न जाएँ। MAHLE का मैनुअल साफ़ कहता है कि containment कस्टमर को बचाने के लिए है, और सिर्फ़ अपनी लाइन पर खराबी ठीक कर लेना काफ़ी नहीं।

दायरा तय करने के लिए पीछे की ओर चलें: कस्टमर के पास का स्टॉक, रास्ते में जा रहे पार्ट्स, आपका finished goods वेयरहाउस और WIP (अधूरा माल)। शक वाले पार्ट्स अलग करें, फिर 100% inspection, छँटाई या rework करें।

8D में सिर्फ़ कार्रवाई मत लिखिए। ये बातें भी जोड़ें:

• हर जगह कितनी मात्रा कवर हुई
• छँटाई के नतीजे (कितने जाँचे गए, उनमें कितने खराब मिले)
• ज़िम्मेदार व्यक्ति और शुरू करने की तारीख़

कस्टमर यह भी पूछेगा कि आपकी छँटाई का तरीका खुद तो खराबी नहीं चूक सकता। inspection का तरीका और पास होने की शर्त साथ में लगा दें, तो रिपोर्ट वापस आने की संभावना कम होती है।

साथ में clean point भी लिखें, यानी वह lot जिससे आगे आप पक्का कह सकते हैं कि सिर्फ़ अच्छे पार्ट्स जा रहे हैं। Containment अस्थायी है। यह तब तक चलता रहता है जब तक D6 में स्थायी एक्शन का असर साबित न हो जाए।

D4: पैदा होने और निकल जाने के असली कारण अलग करें

D4 8D का दिल है, और कस्टमर इसी स्टेप को सबसे बारीकी से देखता है। याद रखने की बात: हर खराबी के कम से कम दो तरह के कारण होते हैं।

कारण के तीन स्तर

पहला है पैदा होने का कारण (occurrence cause): खराब पीस बना क्यों। दूसरा है निकल जाने का कारण (escape cause): inspection ने उसे कस्टमर तक पहुँचने से पहले रोका क्यों नहीं। Siemens भी D4 को दो रास्तों की जाँच बताता है, एक पैदा होने का और एक निकल जाने का।

MAHLE का मैनुअल एक स्तर और गहरा जाता है। वह पूछता है कि समस्या को पहले ही क्यों नहीं रोका गया, और इसके लिए डेवलपमेंट के दौर और सिस्टम को देखता है। इसे अक्सर system root cause (सिस्टम का कारण) कहते हैं। इसमें देखा जाता है कि FMEA या स्टैंडर्ड में कोई कमी तो नहीं थी।

चित्र 6: 8D में कारण के स्तर

एक ही खराबी से "हमने बनाया क्यों" और "हमने भेजा क्यों", ये दोनों रास्ते अलग-अलग खोजें।

लक्षण (कस्टमर के यहाँ मिली खराबी)उदाहरण: माउंटिंग होल ऊपरी सीमा से बड़े वाले ब्रैकेट भेज दिए गए

दो रास्तों में बाँटें

पैदा होने का कारणबना क्यों? मशीन, डाई, मटीरियल, काम का तरीका आदि

निकल जाने का कारणचूका क्यों? inspection का तरीका, कितनी बार जाँच, पास होने की शर्त आदि

और गहरा खोदें

सिस्टम का कारणपहले क्यों नहीं रोका गया? FMEA, control plan या स्टैंडर्ड में कमी

निकल जाने का कारण उस escape point से जुड़ता है जो G8D में जोड़ा गया: वह कंट्रोल पॉइंट जिसे खराबी पकड़नी चाहिए थी। जिस 8D में सिर्फ़ पैदा होने का कारण हो, उसके वापस आने की संभावना ज़्यादा है।

अगर आप सिर्फ़ पैदा होने का कारण ठीक करें और inspection का सिस्टम जस का तस रहे, तो किसी और कारण से बना खराब पीस फिर भी कस्टमर तक पहुँच सकता है। दोनों कारण अलग लिखने से आप दोनों तरफ़ से कार्रवाई कर पाते हैं: बनाओ मत, और भेजो मत।

विश्लेषण का टूल चुनना

कारण खोदने के आम टूल हैं: 5 Why (जापान में क्यों-क्यों विश्लेषण, naze-naze bunseki), fishbone (Ishikawa) डायग्राम और fault tree analysis (FTA)। MAHLE का मैनुअल टूल इस आधार पर चुनता है कि आपको कारण का अंदाज़ा है या नहीं। अंदाज़ा है तो असली कारण ढूँढने और उसकी पुष्टि के लिए 5 Why इस्तेमाल करें।

अगर कारण पता नहीं और समस्या अपेक्षाकृत सीधी है, तो पहले fishbone डायग्राम पर संभावित कारण लिखें। फिर 5 Why या FTA से उन्हें छोटा करें। ज़्यादा पेचीदा समस्याओं के लिए मैनुअल में statistical तरीके भी बताए गए हैं।

Fishbone डायग्राम में संभावित कारण आम तौर पर 6M के तहत रखे जाते हैं: man (लोग), material (मटीरियल), measurement (माप), machine (मशीन), method (तरीका) और mother nature (माहौल)। 8D में बुनियादी नियम यह है कि पैदा होने के कारण और निकल जाने के कारण, दोनों के लिए अलग-अलग 5 Why चलाएँ।

चित्र 7: 5 Why को पैदा होने और निकल जाने में बाँटना (उदाहरण)

एक ही खराबी को दो रास्तों से खोदने पर कार्रवाई की जगहें अलग निकलती हैं।

पैदा होने का रास्ता

क्यों 1माउंटिंग होल का व्यास ऊपरी सीमा से बड़ा हो गया

क्यों 2पियर्सिंग पंच की धार घिसी हुई थी

क्यों 3नाइट शिफ़्ट के सेटअप में घिसा पंच दोबारा लगा दिया गया

क्यों 4पंच बदलने का फ़ैसला स्ट्रोक गिनती से नहीं, आँख से देखकर होता था

असली कारणटूल की लाइफ़ का कोई स्टैंडर्ड नहीं था, इसलिए कब बदलना है यह हर operator पर छोड़ा गया था

निकल जाने का रास्ता

क्यों 1आउटगोइंग inspection में स्पेक से बाहर वाले होल चूक गए

क्यों 2होल का व्यास हर lot के सिर्फ़ पहले पीस पर नापा जाता था

क्यों 3घिसावट धीरे-धीरे बढ़ती है, इसलिए पहला पीस स्पेक में था

क्यों 4जाँच कितनी बार हो, यह तय करते समय टूल कितनी तेज़ी से घिसता है, यह नहीं सोचा गया

असली कारणcontrol plan में जाँच की बारंबारता ने टूल की घिसावट को माना ही नहीं था

चित्र 5 वाला ही काल्पनिक उदाहरण। "operator की लापरवाही" पर मत रुकें; तब तक खोदें जब तक सिस्टम की कोई कमी न मिल जाए।

असली कारण की पुष्टि खराबी दोबारा बनाकर करें

5 Why से जो कारण मिला, वह अभी सिर्फ़ अंदाज़ा (hypothesis) है। 8D में वे नतीजे भी होने चाहिए जो दिखाएँ कि इसी कारण से खराबी बनी। MAHLE का मैनुअल असली कारण की पुष्टि ऐसे तरीकों से माँगता है: खराबी को दोबारा बनाना, या कारण को चालू-बंद करके दिखाना कि खराबी आती और जाती है।

ऊपर वाले उदाहरण में टेस्ट स्ट्रोक से यह दिखाना कि घिसे पंच से होल बड़े बनते हैं और नया पंच लगाने पर होल वापस स्पेक में आ जाते हैं, कस्टमर के सामने कारण का अच्छा सबूत है।

टेस्ट की शर्तें और नतीजे फ़ोटो और माप के डेटा के साथ लगाएँ। जो कारण "अनुमान है" या "लगता है" पर खत्म हो, उसे अक्सर बिना जाँचा हुआ माना जाता है।

D5–D6: स्थायी एक्शन चुनना और उसका असर जाँचना

D4 में कारण पक्का होने पर ऐसा स्थायी एक्शन चुनें जो उसे हटा दे। उसे लागू करें और साबित करें कि वह काम करता है। D3 का containment हट सकेगा या नहीं, यह इसी नतीजे पर टिका है।

हर कारण के लिए एक एक्शन, एक-से-एक

D5 में D4 में लिखे हर कारण के सामने एक एक्शन रखें। पैदा होने के कारण वाले एक्शन और निकल जाने के कारण वाले एक्शन अलग लिखें। एक टेबल में हर कारण के बगल में उसका एक्शन रखें, तो कस्टमर आसानी से देख लेता है कि कुछ छूटा तो नहीं।

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

सिर्फ़ "ट्रेनिंग" से रिपोर्ट क्यों वापस आती है

रिपोर्ट वापस आने की एक आम वजह ऐसा एक्शन है जिसमें सिर्फ़ "operator को दोबारा ट्रेनिंग दी" या "चेतावनी का बोर्ड लगाया" लिखा हो। MAHLE का मैनुअल साफ़ कहता है कि ऑटो इंडस्ट्री में 8D की सुधार कार्रवाई के रूप में सिर्फ़ प्रोसेस में सुधार गिना जाता है। याद दिलाना और कर्मचारी की ट्रेनिंग जैसे इंसानों पर टिके उपाय प्रोसेस सुधार नहीं माने जाते।

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

चित्र 8: जो एक्शन वापस आते हैं बनाम जो मंज़ूर होते हैं

इंसान की सावधानी पर टिके एक्शन की जगह ऐसे एक्शन रखें जो रोकथाम को सिस्टम में डाल दें।

वापस आने की संभावना ज़्यादा

पैदा होनाOperator को टूल अच्छे से जाँचने की दोबारा ट्रेनिंग दी

पैदा होनाप्रेस पर "घिसावट पर ध्यान दें" का बोर्ड लगाया

निकल जानाInspector से कहा कि ज़्यादा ध्यान से नापें

दोनोंज़िम्मेदार व्यक्ति को डाँटा और उससे लिखित सफ़ाई व माफ़ीनामा लिया

मंज़ूर होने की संभावना ज़्यादा

पैदा होनापंच बदलना स्ट्रोक गिनती से तय किया, और प्रेस का काउंटर बदलने का समय बताता है

पैदा होनासेटअप के समय पंच की धार नापने का काम वर्क स्टैंडर्ड में जोड़ा, रिकॉर्ड के साथ

निकल जानाहोल का व्यास सिर्फ़ पहले पीस पर नहीं, तय स्ट्रोक के बाद नापा जाए, और control plan बदला

निकल जानाऐसा jig या सेंसर लगाया जो हर होल का व्यास जाँचे

इसका मतलब यह नहीं कि ट्रेनिंग ज़रूरी नहीं। सिस्टम बदलने से जब तरीका बदले, तो उस नए तरीके की ट्रेनिंग D6 का हिस्सा है।

वर्क स्टैंडर्ड बदल देने का कोई फ़ायदा नहीं अगर शॉप फ़्लोर पर उसे माना ही न जाए। Jig और सेंसर से गलती को शारीरिक रूप से रोकने वाला तरीका पोका-योके (poka-yoke, गलती-रोक उपाय) कहलाता है, और बहुत-सी फ़ैक्ट्रियाँ इसे इस्तेमाल करती हैं।

असर की जाँच और containment हटाना

D6 में लागू करने की तारीख़, ज़िम्मेदार व्यक्ति और जाँच के नतीजे लिखें। MAHLE का मैनुअल दो तरह की जाँच बताता है। एक, लागू करने के तुरंत बाद की छोटी जाँच, जिसमें जानबूझकर खराबी वाले हालात बनाकर देखते हैं कि खराबी लौटती है या नहीं। दूसरी, लंबे समय की जाँच, जिसमें प्रोसेस capability और खराबी का विश्लेषण देखा जाता है।

"सुधार के बाद कोई खराबी नहीं आई" लिखना काफ़ी नहीं। डेटा दिखाएँ: सुधार से पहले और बाद की खराबी की दर या process capability index, या तय अवधि में बने और खराब हुए पीस की गिनती। यह भी लिखें कि किन lot और किन तारीख़ों को जाँचा।

स्थायी एक्शन का असर पक्का होने पर D3 में शुरू किया containment (छँटाई आदि) हटा दें। हटाने की तारीख़ और उस फ़ैसले का आधार भी 8D में लिखें।

D7–D8: दोबारा होने से रोकना और काम पूरा करना

D6 तक आज की खराबी हल हो जाती है, पर 8D यहाँ खत्म नहीं होती। D7 का काम है कि इसी तरह की समस्या दूसरे प्रोडक्ट में या आगे के प्रोडक्ट में न आए।

स्टैंडर्ड अपडेट करें

D7 में सुधार को कंपनी के स्टैंडर्ड में डाल दें। MAHLE का मैनुअल अपडेट के लिए इन दस्तावेज़ों का नाम लेता है:

• ड्रॉइंग
• FMEA
• Control plan
• Special characteristics की लिस्ट
• प्रोडक्ट और प्रोसेस के स्टैंडर्ड
• मेंटेनेंस प्लान

FMEA की समीक्षा सबसे ज़रूरी है। अगर FMEA में इस खराबी का कारण सोचा ही नहीं गया था, तो वह कमी खुद सिस्टम के कारणों में से एक है।

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

योकोतेन (yokoten) और lessons learned

योकोतेन (yokoten, यानी दूसरी जगहों तक फैलाना) में देखा जाता है कि जो मिलते-जुलते प्रोडक्ट और प्रोसेस आज मौजूद हैं, उनमें यही समस्या तो नहीं। ज़रूरत हो तो वही उपाय वहाँ भी लगाया जाता है। कुछ अंग्रेज़ी मैनुअल में इसे "read across" भी कहते हैं। ऊपर के उदाहरण में, जिन दूसरी डाई और प्रेस पर इसी तरह का पंच लगता है, वहाँ भी बदलना स्ट्रोक गिनती से तय होने लगेगा।

Lessons learned इससे अलग है। इसका मकसद है कि आगे बनने वाले प्रोडक्ट और प्रोसेस के डिज़ाइन में यही गलती न दोहराई जाए, जैसे उसे डिज़ाइन स्टैंडर्ड और चेकलिस्ट में जोड़कर। दोनों को अलग लिखें तो कस्टमर आसानी से समझता है: योकोतेन उसके लिए है जो आज मौजूद है; lessons learned उसके लिए है जो आगे बनेगा।

D8 में क्या लिखें

D8 से 8D बंद होती है। टीम रिपोर्ट पूरी करती है, सबके काम की सराहना करती है, और जो सीखा तथा कस्टमर से जो फ़ीडबैक मिला, वह साझा करती है। कई फ़ॉर्म में पूरा होने की तारीख़, मंज़ूर करने वाले का नाम और कस्टमर को अंतिम रिपोर्ट भेजने की तारीख़ माँगी जाती है।

टीम का धन्यवाद करना औपचारिकता लग सकती है। पर इससे ऐसा माहौल बनता है जहाँ लोग अगली समस्या में भी मदद करना चाहते हैं। इसीलिए G8D में भी यह अलग स्टेप के रूप में रखा गया है।

8D वापस क्यों आती है

रिपोर्ट भेजने से पहले आख़िरी बार इन बातों से मिलान कर लें। कस्टमर का क्वालिटी इंजीनियर सबसे पहले यही चीज़ें देखता है।

चित्र 9: भेजने से पहले छह जाँचें

इनमें से एक भी न मिले, तो 8D के वापस आने की संभावना ज़्यादा है।

क्या समस्या आँकड़ों में लिखी है?D2 में characteristic, स्पेक की सीमा, नापा हुआ मान, खराब पीस की गिनती और lot हैं

क्या containment का दायरा काफ़ी बड़ा है?कस्टमर का स्टॉक, रास्ते में माल, आपका स्टॉक और WIP, सबकी मात्रा और नतीजे

क्या निकल जाने का कारण शामिल है?सिर्फ़ यह नहीं कि बना क्यों, यह भी कि inspection ने क्यों चूका

क्या असली कारण की पुष्टि हुई है?खराबी दोबारा बनाने वाले टेस्ट या कारण की पुष्टि करने वाला दूसरा सबूत लगा हुआ है

क्या एक्शन सिस्टम स्तर के हैं?मशीन, jig या स्टैंडर्ड बदले हैं, सिर्फ़ ट्रेनिंग या याद दिलाना नहीं

क्या असर डेटा से दिखाया गया है?सुधार से पहले-बाद की खराबी की दर या capability, जाँच की अवधि और lot के साथ

कारण "operator की गलती" पर रुक गया

जिस 8D के असली कारण वाले खाने में "operator ने चेक नहीं किया" या "ग़लती से हो गया" लिखा हो, उसके वापस आने की संभावना ज़्यादा है। कस्टमर यह जानना चाहता है कि प्रोसेस ऐसा क्यों था कि उस operator से गलती हो सकी। गलती करवाने वाले तरीके, jig, निशान-संकेत और ट्रेनिंग के सिस्टम तक खोदें।

कारण और एक्शन आपस में नहीं मिलते

एक और आम कमी: D4 के कुछ ही कारणों के लिए एक्शन हैं, या एक्शन की लिस्ट में ऐसी चीज़ें हैं जिन्हें कोई लिखा हुआ कारण समझाता ही नहीं। D4 और D5 को टेबल में साथ-साथ रखें। देखें कि हर कारण के लिए एक्शन है और हर एक्शन किसी कारण तक पहुँचता है।

समय-सीमा बचाने के चक्कर में रिपोर्ट खोखली

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

टेम्पलेट: D4–D5 की कारण-से-एक्शन टेबल

यह लेआउट पिछले हिस्से की एक-से-एक जाँच को टेबल में रखता है। इसे अपने कस्टमर के तय 8D फ़ॉर्म के हिसाब से बदलें। पंक्तियों में चित्र 5 और 7 वाला काल्पनिक ब्रैकेट का उदाहरण है; इन्हें अपने कारण और एक्शन से बदलें।

कारण का प्रकार	असली कारण (D4)	पुष्टि कैसे हुई	स्थायी एक्शन (D5)	ज़िम्मेदार / तारीख़	असर का सबूत (D6)
पैदा होना	टूल की लाइफ़ का स्टैंडर्ड नहीं; पंच बदलना हर operator पर छोड़ा गया था	टेस्ट स्ट्रोक: घिसे पंच से बड़े होल बने; नया पंच लगाने पर होल वापस स्पेक में आए	पंच स्ट्रोक गिनती से बदलें; प्रेस का काउंटर बदलने का समय बताए	(नाम / तारीख़)	(सुधार से पहले-बाद की खराबी की दर या capability; जाँचे गए lot और अवधि)
निकल जाना	Control plan में जाँच की बारंबारता ने टूल की घिसावट को नहीं माना	(कैसे दिखाया कि सिर्फ़ पहले पीस की जाँच धीरे-धीरे बढ़ती घिसावट को चूक जाती है)	होल का व्यास तय स्ट्रोक के अंतराल पर नापें; control plan बदलें	(नाम / तारीख़)	(जाँचे गए lot और अवधि)
सिस्टम	(FMEA, control plan या स्टैंडर्ड में कमी)	(समीक्षा का नतीजा)	(D7 अपडेट: FMEA, स्टैंडर्ड, योकोतेन का दायरा)	(नाम / तारीख़)	(अपडेट हुए दस्तावेज़, रिवीज़न नंबर)

शुरू करने से पहले कस्टमर से पूछने के सवाल

फ़ॉर्म और समय-सीमा कस्टमर के हिसाब से बदलते हैं, इसलिए शुरू में कस्टमर के supplier quality वाले संपर्क से ये बातें पक्की कर लें। कस्टमर अक्सर अपनी माँगें supplier quality manual में बताते हैं; आपके पास न हो तो उसका ताज़ा वर्शन माँग लें।

• हम कौन-सा 8D फ़ॉर्म इस्तेमाल करें? क्या आपका तय किया हुआ टेम्पलेट है?
• हर चरण की समय-सीमा क्या है (जैसे containment, असली कारण, अंतिम बंदी)?
• क्या आपको D0 चाहिए, या आप सिर्फ़ D1–D8 इस्तेमाल करते हैं?
• Containment किन जगहों को कवर करे: आपका स्टॉक, रास्ते में माल, और हमारा स्टॉक व WIP?
• Clean point (पहला lot जो अच्छा पक्का हुआ) की रिपोर्ट कैसे दें?
• खुली मदों के लिए क्या हम "जाँच जारी है" और संभावित तारीख़ के साथ भेजकर 8D बाद में अपडेट कर सकते हैं?
• 8D मंज़ूर करके बंद करने के लिए आपको कौन-सा सबूत चाहिए (डेटा की अवधि, lot की संख्या)?

पहले संपर्क के लिए छोटा ईमेल अच्छा रहता है। कस्टमर से आम तौर पर अंग्रेज़ी में बात होती है, इसलिए नीचे अंग्रेज़ी का नमूना है। इसका मतलब यह है: समस्या बताने के लिए धन्यवाद; हमने उस lot की शिपमेंट रोककर containment शुरू कर दिया है; कृपया बताएँ कि कौन-सा फ़ॉर्म इस्तेमाल करें और हर चरण की समय-सीमा क्या है; D1–D3 हम [तारीख़ और समय] तक भेजेंगे।

"Thank you for informing us of the issue with [part number], lot [number]. We have stopped shipping the affected lot and started containment. To make sure our 8D meets your requirements, could you confirm the form you would like us to use and the deadline for each stage? We will send D1–D3 by [date and time]."

सुधार कार्रवाई की माँगें तब भी आती हैं जब कस्टमर आपकी फ़ैक्ट्री का ऑडिट करता है।

इस गाइड की सीमाएँ

• 8D के फ़ॉर्म, स्टेप के नाम और समय-सीमा कस्टमर के हिसाब से बदलते हैं। कस्टमर का अपना supplier quality manual और तय फ़ॉर्म हमेशा इस गाइड से ऊपर है। यह लेख किसी BIS (IS) standard पर आधारित नहीं है।
• यहाँ बताई गई समय-सीमा और माँगें (1-5-20 नियम, टीम की भूमिकाएँ, टूल का चुनाव, ट्रेनिंग को कैसे गिना जाता है, D7 में अपडेट होने वाले दस्तावेज़) एक ही कंपनी, MAHLE, के मैनुअल से हैं। दूसरे कस्टमर के नियम अलग हो सकते हैं।
• Toyota के आठ स्टेप को 8D से मकसद की समानता के आधार पर मिलाया गया है। स्रोतों में स्टेप के नाम बदलते हैं, और यह मिलान ठीक-ठीक नहीं है।
• चित्र 5, 7, 8 और टेम्पलेट का ब्रैकेट वाला उदाहरण काल्पनिक है और सिर्फ़ यह दिखाता है कि खाने कैसे भरें।

FAQ

8D और Toyota के 8-स्टेप तरीके में क्या फ़र्क है?

8D Ford से आया है और ज़्यादातर कस्टमर को खराबी का जवाब देने में इस्तेमाल होता है। इसमें containment का स्टेप (D3) है और पैदा होने व निकल जाने के कारण अलग-अलग माँगे जाते हैं। Toyota के आठ स्टेप कंपनी के अंदर का समस्या-समाधान तरीका हैं, जिन्हें आम तौर पर A3 शीट पर समेटा जाता है। इनमें टारगेट तय करने का स्टेप है, जो 8D में नहीं होता। विश्लेषण एक से दूसरे में ले जा सकते हैं, पर 8D में containment और निकल जाने का कारण फिर भी अलग से लिखना पड़ेगा।

8D आठ स्टेप की है या नौ की?

असली तरीके में आठ discipline थे, D1 से D8। Ford के Global 8D ने इमरजेंसी कार्रवाई और "पूरी 8D चाहिए या नहीं" के फ़ैसले के लिए D0 जोड़ा। इसलिए अब कई फ़ॉर्म में D0 से D8 तक नौ स्टेप हैं। कुछ कस्टमर अब भी सिर्फ़ D1–D8 इस्तेमाल करते हैं।

8D में escape point क्या होता है?

यह वह कंट्रोल पॉइंट है जिसे समस्या पकड़नी चाहिए थी पर उसने नहीं पकड़ी, जैसे प्रोसेस के बीच की जाँच या आउटगोइंग inspection। यह विचार G8D में जोड़ा गया। रिपोर्ट में यह निकल जाने के कारण की शुरुआत है, यानी खराब पीस कस्टमर तक कैसे पहुँचा।

क्या operator की ट्रेनिंग मंज़ूर होने वाला सुधार एक्शन है?

अकेले नहीं। उदाहरण के लिए MAHLE का मैनुअल कहता है कि ऑटो इंडस्ट्री में 8D की सुधार कार्रवाई के रूप में सिर्फ़ प्रोसेस सुधार गिने जाते हैं, याद दिलाना या कर्मचारी की ट्रेनिंग नहीं। जब सिस्टम बदलने से तरीका बदले, तब ट्रेनिंग ज़रूरी है, और उसे D6 के हिस्से के रूप में रिपोर्ट किया जाता है।

स्रोत

• 8D की शुरुआत, TOPS, G8D, MIL-STD-1520: Wikipedia, "Eight disciplines problem solving"; AllAboutLean, "The History of the Eight Disciplines Problem Solving (8D)"
• 8D रिपोर्ट की परिभाषा और D4 के दो रास्ते: Siemens, "8D Report" (जापानी)
• 1-5-20 नियम, हर स्टेप की माँगें, इंसानों पर टिके उपायों का दर्जा, अपडेट होने वाले दस्तावेज़: MAHLE Supplier Quality Assurance, "8D Process" (PDF)
• IATF 16949 clause 10.2.3, Problem solving: "IATF 16949:2016 Clause 10.2.3 Problem solving" (टिप्पणी); IATF16949 Kouryaku, "10.2.3 Problem solving requirements" (जापानी)
• Toyota के आठ स्टेप और TBP: Gemba Academy, "TBP: Toyota Business Practice"; Lean Enterprise Academy, "Back to Basics: Problem Solving at Toyota"; OJT Solutions, "The 8 Steps of Problem Solving" (जापानी); Toyota Enterprise, "Toyota-style kaizen (problem solving) training" (जापानी)
• VDA की 8D किताब: VDA QMC, "8D – Problemlösung in 8 Disziplinen" (पहला एडिशन, नवंबर 2018)
• AIAG CQI-20: AIAG, "CQI-20 Effective Problem Solving Guide"