CAPA (सुधारात्मक और निवारक कार्रवाई) घटित हो चुकी समस्या का कारण हटाती है ताकि वह दोबारा न हो, और सबक को उन उत्पादों, प्रक्रियाओं और साइटों तक ले जाती है जहाँ वह आगे हो सकती है। 8D (Eight Disciplines) वह टीम पद्धति है जिसकी अपेक्षा ऑटोमोटिव ग्राहक इसके लिए करते हैं: IATF 16949 का खंड 10.2.3 कंटेनमेंट, मूल कारण विश्लेषण, सिस्टमिक सुधारात्मक कार्रवाई, सत्यापित प्रभावशीलता और अपडेट किए गए PFMEA तथा कंट्रोल प्लान की माँग करता है।
Zometric नौ चरण चलाता है, D0 से D8: इनटेक और ट्राइएज, टीम, समस्या विवरण, कंटेनमेंट, मूल कारण, कार्रवाइयों का चयन और परीक्षण, उन्हें लागू करना और सिद्ध करना, पुनरावृत्ति की रोकथाम, और टीम सम्मान के साथ क्लोज़र। D0 पूर्ण 8D और शॉर्ट फ़ॉर्म के बीच निर्णय लेता है। वही चरण VDA 8D या AIAG CQI-20 की शब्दावली में दिखाए जा सकते हैं।
सत्यापित मूल कारण को तथ्यों की व्याख्या करनी चाहिए और, जहाँ संभव हो, समस्या को चालू और बंद करके दिखाना चाहिए। कारणों को इसमें बाँटा जाता है कि दोष क्यों हुआ और वह क्यों पकड़ा नहीं गया, और तकनीकी तथा सिस्टमिक कारणों में, क्योंकि जो समाधान केवल पार्ट को कवर करता है वह उस प्रक्रिया को अपरिवर्तित छोड़ देता है जिसने उसे निकल जाने दिया।
छह समस्याएँ, जैसा क्वालिटी टीमें उन्हें अपने शब्दों में बताती हैं — और 8D के फ़ॉर्म के बजाय गेट वाला केस बनने से क्या बदलता है।
हर डिसिप्लिन की अपनी जाँचें हैं: खुली त्रुटि चरण को रोकती है, और अगले-चरण का कार्ड बताता है कि क्या कम है।
D0 · इनटेक और ट्राइएज
केस ग्राहक या आपूर्तिकर्ता की शिकायत, ऑडिट फ़ाइंडिंग, लेयर्ड-ऑडिट अननुरूपता या किसी आंतरिक स्रोत से खुलता है। तीन ट्राइएज प्रश्न पूर्ण 8D या शॉर्ट फ़ॉर्म का सुझाव देते हैं; सुरक्षा, नियामक और गंभीर समस्याओं को हमेशा पूर्ण 8D मिलता है।
D1–D2 · टीम और समस्या विवरण
एक स्पॉन्सर और टीम लीडर नामित करें, सदस्य, ग्राहक या आपूर्तिकर्ता प्रतिनिधि जोड़ें। समस्या को आवश्यकता बनाम वास्तविक के रूप में बताएँ — 5W2H, IS / IS NOT, त्रुटि पैटर्न और समान पार्ट, लाइन और साइटों पर जाँचों के साथ।
D3 · कंटेनमेंट
स्थान के अनुसार कंटेनमेंट दर्ज करें — आपूर्तिकर्ता, वर्क इन प्रोग्रेस, तैयार माल, ट्रांज़िट में, ग्राहक के पास — लॉट, जाँची और अस्वीकृत मात्राओं और डिस्पोज़िशन के साथ। जैसा-है-वैसा उपयोग और रिपेयर के लिए ग्राहक का प्राधिकरण चाहिए; पहले ही भेजे जा चुके संदिग्ध उत्पाद के लिए ग्राहक को सूचना देनी होती है।
D4 · मूल कारण
5-Why, Ishikawa, IS / IS NOT, Pareto, फ़ॉल्ट ट्री, डिसीज़न मैट्रिक्स, मल्टी-वेरी या कॉज़-एंड-इफ़ेक्ट मैट्रिक्स के साथ काम करें, और संभावित कारण को मूल कारण में प्रमोट करें। प्रोजेक्ट की PFMEA श्रृंखलाएँ और कंट्रोल प्लान पंक्तियाँ उसके बगल में रहती हैं, ताकि टीम उत्तर दे सके “क्या यह FMEA में था?”।
D5–D6 · कार्रवाइयाँ और प्रमाण
सुधारात्मक और सिस्टमिक कार्रवाइयों को उन कारणों से जोड़ें जिन्हें वे हटाती हैं। कोई परिणाम दर्ज होने से पहले स्वीकृति मानदंड तय करें, कार्यान्वयन से पहले परीक्षण करें, फिर उसके बाद सिद्ध करें — वैकल्पिक रूप से बदलाव से पहले और बाद के लाइव SPC या निरीक्षण डेटा के विरुद्ध।
D7 · पुनरावृत्ति की रोकथाम
हर रोकथाम लक्ष्य पर निर्णय लें: PFMEA, DFMEA, कंट्रोल प्लान, प्रोसेस फ़्लो, कार्य निर्देश, समान उत्पाद और प्रक्रियाएँ, अन्य साइटें, सीखे गए सबक या कोई LPA प्रश्न। हर निर्णय या तो पूर्ण है, स्वामी और तिथि के साथ नियोजित है, या कारण के साथ लागू नहीं है।
D8 · क्लोज़र और सम्मान
टीम लीडर और स्पॉन्सर के साइन-ऑफ़ के लिए क्लोज़र सारांश सबमिट करें, और शिकायत की माँग होने पर ग्राहक के भी; अनुमोदन इलेक्ट्रॉनिक रूप से हस्ताक्षरित हो सकते हैं। क्लोज़र प्रभावशीलता समीक्षा शेड्यूल करता है, डिफ़ॉल्ट रूप से 90 दिन बाद।
हर क्षमता उस निर्णय से जुड़ी है जो आपकी टीम पहले से लेने का प्रयास कर रही है।
हर डिसिप्लिन की अपनी जाँचें हैं, और खुली त्रुटि चरण को रोक देती है। अगले-चरण का कार्ड टीम लीडर को बताता है कि आगे बढ़ने के लिए क्या चाहिए — इसलिए कोई 8D साक्ष्य से समर्थित सत्यापित मूल कारण के बिना बंद नहीं हो सकता।
समस्या पर एक बार काम करें और उसे उसी फ़ॉर्मेट में रिपोर्ट करें जो ग्राहक माँगता है। फ़ॉर्मेट चरण, लेबल और रिपोर्ट लेआउट तय करते हैं — ग्राहक वर्कबुक सहित — टीम के समस्या सुलझाने के तरीक़े को बदले बिना।
स्थान के अनुसार कंटेनमेंट कार्रवाइयाँ — आपका प्लांट, ट्रांज़िट में, ग्राहक का वेयरहाउस — प्रभावित लॉट, छाँटी गई मात्रा और डिस्पोज़िशन के साथ। क्लीन पॉइंट दर्ज होता है, और कंटेनमेंट तभी हटाया जा सकता है जब स्थायी समाधान सिद्ध हो जाए, जब तक कि स्पॉन्सर या कोई गुणवत्ता प्रबंधक लिखित कारण के साथ इसे ओवरराइड न करे।
5 क्यों, Ishikawa, Pareto, Is / Is-Not, फ़ॉल्ट ट्री और डिसीज़न मैट्रिक्स, सब केस रिकॉर्ड पर। मूल कारण दो हिस्सों में बँटे हैं — दोष क्यों हुआ और वह क्यों निकल गया — और संबंधित PFMEA तथा कंट्रोल प्लान का संदर्भ उनके बगल में रहता है।
रोकथाम वास्तविक दस्तावेज़ों के आधार पर लिया गया निर्णय है। वह PFMEA, कंट्रोल प्लान या प्रोसेस फ़्लो चुनें जिस पर सबक लागू होता है, और उस पर समीक्षा फ़्लैग लग जाता है — फ़ील्ड विफलता से वापस जोखिम विश्लेषण तक का लूप सिस्टम में बंद होता है, किसी मीटिंग में नहीं।
क्लोज़र के समय प्रभावशीलता समीक्षा शेड्यूल होती है। यदि समस्या लौट आई है, तो केस फिर खुल जाता है। बंद CAPA पर दोबारा आई शिकायत उस पर अपने आप फ़्लैग लगा देती है।
हर चरण पर फ़ोटो और फ़ाइलें, ई-हस्ताक्षरित साइन-ऑफ़, और क्रमांकित रिपोर्ट संस्करण — प्रारंभिक, अंतरिम और अंतिम — जारी किए गए रूप में फ़्रीज़। प्रबंधन-समीक्षा पैक पूरी CAPA तस्वीर Excel में निर्यात करता है।
मिलते-जुलते पुराने केस, सिद्ध मूल कारण और कारगर रही कार्रवाइयाँ आपके अपने CAPA और FMEA से सुझाई जाती हैं, प्रत्येक संदर्भ के साथ। इस मॉड्यूल में किसी बाहरी LLM का उपयोग नहीं होता, और क्या स्वीकार करना है यह इंजीनियर तय करता है।
चरणों की नियत तिथियाँ समस्या रिपोर्ट होने के क्षण से गिनी जाती हैं, इससे नहीं कि किसी ने केस कब खोला। ये VDA 8D, CQI-20 और Generic 8D फ़ॉर्मेट के डिफ़ॉल्ट हैं; प्रत्येक को डुप्लिकेट फ़ॉर्मेट में बदला जा सकता है, और शिकायत तथा ऑडिट की समय-सीमाएँ इनकी जगह लेती हैं।
| चरण | कितने समय बाद देय | देय तिथि |
|---|---|---|
| D0 तैयारी और प्रतिक्रिया | कितने समय बाद देय24 घंटे | देय तिथि3 मार्च 09:00 |
| D1 टीम | कितने समय बाद देय24 घंटे | देय तिथि3 मार्च 09:00 |
| D2 समस्या का वर्णन | कितने समय बाद देय5 दिन | देय तिथि7 मार्च 09:00 |
| D3 कंटेनमेंट | कितने समय बाद देय24 घंटे | देय तिथि3 मार्च 09:00 |
| D4 मूल कारण खोजें | कितने समय बाद देय15 दिन | देय तिथि17 मार्च 09:00 |
| D5 कार्रवाइयाँ चुनें और परखें | कितने समय बाद देय15 दिन | देय तिथि17 मार्च 09:00 |
| D6–D8 लागू करें, रोकें, बंद करें | कितने समय बाद देय60 दिन | देय तिथि1 मई 09:00 |
दूसरे मॉड्यूल CAPA के माध्यम से केस खोलते हैं और उनके बदलने पर सूचना पाते हैं, इसलिए उनके बीच कुछ भी दोबारा टाइप नहीं होता।
शिकायत कंटेनमेंट, मूल कारण और अंतिम रिपोर्ट की अपनी समय-सीमाओं के साथ एक CAPA खोलती है। दोबारा आई शिकायत बंद CAPA पर समीक्षा फ़्लैग लगाती है और उसकी प्रभावशीलता समीक्षा में दिखती है।
अननुरूपता फ़ाइंडिंग और लेयर्ड-ऑडिट अननुरूपताएँ फ़ाइंडिंग की प्रतिक्रिया तिथियों पर देय CAPA खोलती हैं। D7 में, रोकथाम निर्णय एक ड्राफ़्ट LPA प्रश्न बना सकता है।
D4 प्रोजेक्ट की PFMEA श्रृंखलाएँ दिखाता है ताकि मूल कारण उनसे जोड़ा जा सके, और D7 निर्णय PFMEA या DFMEA पर समीक्षा फ़्लैग लगाता है।
D4 मूल कारणों के बगल में कंट्रोल प्लान की पंक्तियाँ दिखाता है, और कंट्रोल प्लान पर D7 निर्णय उस पर समीक्षा फ़्लैग लगाता है।
केस प्रोजेक्ट के प्रोसेस फ़्लो से वह ऑपरेशन दर्ज करता है जहाँ समस्या उत्पन्न होती है; D7 प्रोसेस फ़्लो डायग्राम को समीक्षा के लिए चिह्नित कर सकता है।
आपूर्तिकर्ता एक सुरक्षित लिंक से कंटेनमेंट, मूल कारण, कार्रवाइयों और कार्यान्वयन का उत्तर देता है। जब तक टीम उत्तर स्वीकार न करे, CAPA में कुछ नहीं बदलता।
कार्यान्वयन के बाद का प्रमाण पार्ट की किसी SPC स्ट्रीम की ओर इंगित कर सकता है और बदलाव से पहले और बाद का उसका प्रदर्शन दिखा सकता है।
पार्ट के निरीक्षण परिणाम भी प्रमाण के रूप में काम आ सकते हैं, कार्रवाई से पहले और बाद की समान अवधियों में तुलना करके।
D7 में सीखे-गए-सबक का निर्णय सीखे गए सबक की लाइब्रेरी में एक प्रविष्टि बनाता है, जो CAPA से वापस जुड़ी होती है।
केस चलाता है: ट्राइएज, चरण, क्लोज़र अनुरोध और प्रभावशीलता समीक्षा। जल्द देय या विलंबित चरणों के रिमाइंडर पाता है।
टीम लीडर के साथ क्लोज़र पर हस्ताक्षर करता है, और लिखित कारण के साथ कंटेनमेंट हटाने को ओवरराइड कर सकता है।
डिसिप्लिन पर काम करते हैं — समस्या विवरण, कंटेनमेंट, विश्लेषण, मूल कारण और कार्रवाइयाँ। ट्राइएज और क्लोज़र टीम लीडर और स्पॉन्सर के पास रहते हैं।
कोई भी केस प्रबंधित करते हैं, विलंबित चरणों के एस्केलेशन पाते हैं, गुणवत्ता-प्रबंधक साइन-ऑफ़ पर हस्ताक्षर करते हैं और कंटेनमेंट हटाने को ओवरराइड कर सकते हैं।
शिकायत समन्वयक, ऑडिट प्रोग्राम प्रबंधक और LPA प्रोसेस स्वामी अपनी शिकायतों, फ़ाइंडिंग और लेयर्ड ऑडिट से खुले CAPA प्रबंधित करते हैं।
आपूर्तिकर्ता पोर्टल के माध्यम से अपने 8D के कंटेनमेंट, मूल कारण, कार्रवाइयों और कार्यान्वयन का उत्तर देते हैं।
| Zometric CAPA और 8D बनाम स्प्रेडशीट या Word 8D टेम्पलेट | स्प्रेडशीट या Word टेम्पलेट | Zometric CAPA और 8D |
|---|---|---|
| चरण गेट | कोई भी बॉक्स ख़ाली या अस्पष्ट छोड़ा जा सकता है | 52 CAPA नियम; खुली त्रुटियाँ चरण और क्लोज़र रोकती हैं |
| मूल कारण | एक मुक्त-पाठ बॉक्स | घटित होने और पकड़ में न आने के तकनीकी और सिस्टमिक कारण, प्रत्येक साक्ष्य से सत्यापित |
| कंटेनमेंट से निकास | जब सुरक्षित लगे तब रोक दिया जाता है | केवल पास हुए प्रमाण के बाद हटाया जाता है, या कारण के साथ ओवरराइड |
| नियत तिथियाँ | हाथ से टाइप, शायद ही कभी पीछा | रिपोर्ट तिथि से गिनी गई, रिमाइंडर और एस्केलेशन के साथ |
| PFMEA और कंट्रोल प्लान | D7 में "अपडेट किया" लिख दिया जाता है | D7 निर्णय आवश्यक है और दस्तावेज़ पर समीक्षा फ़्लैग लगाता है |
| ग्राहक फ़ॉर्मेट | हर ग्राहक के लिए अलग फ़ाइल | एक केस; VDA 8D, CQI-20 या ग्राहक फ़ॉर्मेट और वर्कबुक |
| प्रभावशीलता | क्लोज़र के बाद शायद ही कभी जाँची जाती है | क्लोज़र पर समीक्षा शेड्यूल; विफल समीक्षा केस फिर खोलती है |
| संस्करण और साइन-ऑफ़ | ई-मेल से भेजा गया "8D_final_v2" | जारी किए गए रूप में फ़्रीज़ क्रमांकित रिपोर्ट संस्करण, ई-हस्ताक्षर के साथ |
स्क्रीन पर VDA 8D, CQI-20 या सामान्य लेआउट में 8D रिपोर्ट, PDF के लिए प्रिंट लेआउट और प्रति डिसिप्लिन एक शीट वाली Excel वर्कबुक के साथ।
ग्राहक की ख़ाली 8D वर्कबुक अपलोड करें, उसके सेल एक बार मैप करें, और उसे किसी भी जारी रिपोर्ट संस्करण से भरें।
CAPA रजिस्टर को उसके KPI के साथ, और ट्रेंड, स्रोतों, कारण Pareto, खुले और बंद केसों और प्रभावशीलता वाले प्रबंधन-समीक्षा पैक को Excel में निर्यात करें।
ग्राहक कारण कैटलॉग, फ़ॉर्मेट पाठ और मूल्यांकन मानदंड Excel या CSV से लोड करें।
केस, चरण, टीम, कंटेनमेंट, मूल कारण और साइन-ऑफ़ REST API के माध्यम से उपलब्ध हैं, और केस की स्थिति बदलने पर एक वेबहुक भेजा जाता है।
Zometric के मॉड्यूल एक ही डेटा रीढ़ साझा करते हैं — इनमें से अधिक को अपनाने से सिग्नल-टू-नॉइज़ का लाभ कई गुना बढ़ जाता है।
डेमो से पहले टीमें जो प्रश्न पूछती हैं, उनके सीधे उत्तर।
CAPA (सुधारात्मक और निवारक कार्रवाई) आवश्यकता है: समस्या का कारण हटाना ताकि वह वापस न आए, और उसे कहीं और होने से रोकना। 8D इसे करने की एक संरचित टीम पद्धति है, टीम से क्लोज़र तक आठ डिसिप्लिन में। Zometric हर CAPA को नौ चरणों, D0 से D8, वाले 8D केस के रूप में चलाता है, जहाँ D0 पूर्ण 8D और शॉर्ट फ़ॉर्म के बीच निर्णय लेता है।
Zometric तीन फ़ॉर्मेट देता है: VDA 8D, CQI-20 समस्या समाधान और एक Generic 8D। फ़ॉर्मेट चरणों के नाम, आवश्यक मूल कारण वर्ग, सत्यापन स्तर, साइन-ऑफ़, नियत तिथियाँ और रिपोर्ट लेआउट तय करता है। फ़ॉर्मेट को किसी ग्राहक के लिए डुप्लिकेट करके समायोजित किया जा सकता है, और ग्राहक की अपनी 8D वर्कबुक किसी जारी रिपोर्ट संस्करण से भरी जा सकती है।
ट्राइएज पर तीन प्रश्न दृष्टिकोण का सुझाव देते हैं: क्या कारण ज्ञात है, क्या समस्या विवरण पूर्ण है, और क्या समस्या एक व्यक्ति के बस से बाहर है। सुरक्षा, नियामक और गंभीर समस्याओं को हमेशा पूर्ण 8D मिलता है, और ग्राहक शिकायतों को भी, जब तक फ़ॉर्मेट शॉर्ट फ़ॉर्म की अनुमति न दे। जो शॉर्ट फ़ॉर्म बड़ा निकले, उसे डेटा खोए बिना पूर्ण 8D तक एस्केलेट किया जा सकता है।
नियत तिथियाँ समस्या रिपोर्ट होने के समय से गिनी जाती हैं। डिफ़ॉल्ट है: कंटेनमेंट के लिए 24 घंटे, मूल कारणों और कार्य योजना के लिए 15 दिन, और कार्यान्वयन, रोकथाम और क्लोज़र के लिए 60 दिन। शिकायत की समय-सीमाएँ या ऑडिट फ़ाइंडिंग के प्रतिक्रिया समय इनकी जगह लेते हैं, और तीन दिन से अधिक विलंबित चरण गुणवत्ता प्रबंधकों तक एस्केलेट होता है।
केवल तब जब सुधारात्मक कार्रवाइयों का कार्यान्वयन के बाद का प्रमाण पास हो चुका हो। फ़ॉर्मेट ग्राहक के निकास अनुमोदन या क्लीन पॉइंट के बाद एक क्लीन अवधि की भी माँग कर सकता है। कंटेनमेंट को पहले हटाने के लिए स्पॉन्सर या गुणवत्ता प्रबंधक और लिखित कारण चाहिए, जो रिकॉर्ड के साथ रखा जाता है।
क्लोज़र एक प्रभावशीलता समीक्षा शेड्यूल करता है, डिफ़ॉल्ट रूप से 90 दिन बाद। क्लोज़र के बाद की दोबारा आई शिकायतें पुनरावृत्ति संकेत के रूप में दिखती हैं, और उनके बावजूद प्रभावशीलता की पुष्टि के लिए लिखित औचित्य चाहिए। विफल समीक्षा केस को चुने गए चरण से फिर खोलती है, या उसे बंद रखकर एक जुड़ा हुआ दोहराव CAPA शुरू करती है।
हाँ। आपूर्तिकर्ता पोर्टल के माध्यम से आपूर्तिकर्ता एक सुरक्षित लिंक से कंटेनमेंट, मूल कारण, सुधारात्मक कार्रवाइयों और कार्यान्वयन का उत्तर देता है। उनके उत्तर प्रस्ताव ही रहते हैं: जब तक टीम उन्हें स्वीकार न करे, CAPA में कुछ नहीं लिखा जाता, और स्वीकार किए गए मूल कारण सत्यापित के रूप में नहीं, सबसे संभावित के रूप में शुरू होते हैं।
नहीं। मूल कारणों, कार्रवाइयों और रोकथाम लक्ष्यों के सुझाव एक लोकल इंजन से आते हैं जो आपके अपने पिछले CAPA और FMEA खोजता है, प्रत्येक संदर्भ के साथ। किसी बाहरी LLM का उपयोग नहीं होता, और जब तक कोई इंजीनियर स्वीकार न करे, केस में कुछ भी नहीं जोड़ा जाता।
30 मिनट की डिस्कवरी कॉल। वास्तविक फ़ैक्टरी डेटा पर 2–3 सप्ताह का पायलट। फिर अपनी गति से विस्तार करें।
