आप कभी विमान दुर्घटना में क्यों नहीं रहे
व्यावसायिक विमानन की उल्लेखनीय सुरक्षा उपलब्धि को व्यापक रूप से एक “जस्ट” या दोषरहित संस्कृति से जोड़ा जाता है, जो दुर्घटनाओं और निकट-चूकों के समय व्यक्तियों को दंडित करने के बजाय प्रणालीगत सीख पर जोर देती है। टिप्पणीकार यह देखते हैं कि औपचारिक, गैर-दंडात्मक जाँच, समृद्ध घटना-रिपोर्टिंग और संस्थागत जिम्मेदारी पर ध्यान ने दुर्घटनाएँ कैसे घटाईं, और इसकी तुलना सॉफ्टवेयर, स्वास्थ्य-सेवा, परमाणु, और सड़क परिवहन जैसे क्षेत्रों से करते हैं जहाँ अभी भी दोषारोपण, गोपनीयता, या कमजोर विनियमन हावी है। कई लोगों का तर्क है कि विमानन-शैली की सुरक्षा प्रथाएँ—विशेषकर कठोर पोस्टमॉर्टम, ईमानदार गलतियों के लिए सुरक्षा, और निकट-चूकों पर ध्यान—इन अन्य उच्च-जोखिम क्षेत्रों में परिणामों को काफी बेहतर बना सकती हैं.
विमानन सुरक्षा संस्कृति और “जस्ट कल्चर”
- टिप्पणीकार विमानन की औपचारिक “दोषरहित” या “जस्ट” संस्कृति को रेखांकित करते हैं: ध्यान इस बात पर कि क्या हुआ और प्रणालियों को कैसे ठीक किया जाए, न कि सद्भावना से काम करने वाले व्यक्तियों को दंडित करने पर।
- इसे इस बात का प्रमुख कारण माना गया है कि व्यावसायिक उड़ान इतनी सुरक्षित क्यों है और त्रुटियों के बारे में जानकारी वास्तव में सामने क्यों आती है।
- कई लोग इसे अन्य उच्च-जोखिम क्षेत्रों (परमाणु, समुद्री, रासायनिक संयंत्र) में RCA और स्विस चीज़ मॉडल की परतदार रक्षा से जोड़ते हैं।
दोष बनाम जवाबदेही
- सूक्ष्मता पर जोरदार चर्चा:
- “दोषरहित” का अर्थ यह नहीं कि किसी पर कभी जिम्मेदारी नहीं आती, खासकर नियम उल्लंघन, दुर्भावना, या गंभीर लापरवाही के मामलों में।
- इसका मतलब है तथ्यों की जाँच को दंड से अलग करना, ताकि जांच ईमानदार और प्रणाली-केंद्रित रहे।
- MCAS, टाइटैनिक, और यूके पोस्ट ऑफिस घोटाले का उपयोग ऐसे उदाहरणों के रूप में किया गया है जहाँ व्यक्तिगत बलि के बकरों की तुलना में संगठनात्मक और नियामकीय विफलताएँ अधिक महत्वपूर्ण हैं।
संस्थागत और प्रणालीगत कारक
- PATCO की बड़े पैमाने पर छंटनी ने क्या अमेरिकी ATC के संस्थागत ज्ञान को नुकसान पहुँचाया और परोक्ष रूप से दुर्घटना जोखिम बढ़ाया—इस पर बहस; कुछ लोग समय अंतराल को देखते हुए संदेह करते हैं, जबकि अन्य कठोरता के दीर्घकालिक क्षरण पर जोर देते हैं।
- Boeing की हाल की समस्याएँ व्यापक रूप से प्रणालीगत मानी जाती हैं: प्रोत्साहन, स्व-प्रमाणीकरण, और पुनःप्रशिक्षण से बचने का दबाव—इन सबने असुरक्षित डिज़ाइन को जन्म दिया, न कि केवल कुछ “खराब तत्वों” ने।
सॉफ्टवेयर और इंजीनियरिंग के साथ उपमाएँ
- कई लोग सॉफ्टवेयर इंजीनियरिंग के लिए सबक निकालते हैं:
- ब्लेमलेस पोस्टमॉर्टम, GitLab की डेटाबेस घटना, और सार्वजनिक “SEV” समीक्षाओं की प्रशंसा की जाती है।
- अन्य तर्क देते हैं कि टेक में अभी भी अक्सर “ब्लेमलेस” का दुरुपयोग स्पष्ट प्रक्रिया या यहाँ तक कि कानूनी उल्लंघनों से बचाने के लिए किया जाता है।
- इस पर एक बड़ा उप-थ्रेड है कि क्या सॉफ्टवेयर को पारंपरिक इंजीनियरिंग की तरह विनियमित किया जाना चाहिए: डेटा उल्लंघनों के लिए दायित्व, न्यूनतम सुरक्षा प्रथाओं का संहिताकरण, लाइसेंसिंग, और क्या “सॉफ्टवेयर इंजीनियर” पर कानूनी जिम्मेदारी आनी चाहिए।
निकट चूक, CAST, और प्रणालियों पर सोच
- निकट चूकों को “उपहार” कहा गया है: वे बिना हताहतों के खतरनाक अवस्थाओं को उजागर करती हैं और जांच को प्रेरित करना चाहिए।
- CAST / STAMP और systems-thinking संसाधनों की सिफारिश की गई है ताकि एकल “मूल कारण” खोजने के बजाय परस्पर क्रिया करने वाले कारकों का विश्लेषण किया जा सके।
कारें, सड़कें, और व्यापक सुरक्षा संस्कृति
- कई टिप्पणीकार पूछते हैं कि इतनी अधिक सड़क मृत्यु होने के बावजूद कार यात्रा में विमानन-शैली की जाँच और प्रणाली-पुनर्रचना क्यों नहीं अपनाई जाती।
- सुझाई गई बाधाएँ: खंडित जिम्मेदारी, ड्राइवरों पर प्रतिबंध लगाने के प्रति सांस्कृतिक प्रतिरोध, व्यक्तिगत दोष पर कानूनी ध्यान, और कार-केंद्रित शहरी डिज़ाइन की जड़ें।