आप विमान दुर्घटना का शिकार क्यों नहीं हुए
(asteriskmag.com)-航空安全 किसी दुर्घटना के बाद एक व्यक्ति को सज़ा देने के बजाय उन परिस्थितियों को हटाने के तरीके से आगे बढ़ी है जिनमें वही गलती संभव थी, और 1991 में LAX पर USAir 1493 की टक्कर इसका कारण दिखाती है
- USAir 1493, LAX के रनवे 24L पर उतरते समय टेकऑफ क्लीयरेंस का इंतज़ार कर रहे SkyWest 5569 से टकरा गया, और अंततः 35 लोगों की मौत हुई
- कंट्रोलर Robin Lee Wascher ने यह भूलकर लैंडिंग क्लीयरेंस दे दिया कि SkyWest 5569 अभी भी रनवे पर था, लेकिन NTSB ने इसे किसी व्यक्ति की मनमानी नहीं, बल्कि ग्राउंड रडार की खराबी, बाधित दृश्यता, सूचना-प्रेषण संरचना और रात में रनवे पर होल्ड कराने की प्रथा के संयुक्त सिस्टम मुद्दे के रूप में देखा
- Chicago Convention के Annex 13 के बाद से विमान दुर्घटना जांच का मुख्य उद्देश्य भविष्य की दुर्घटनाओं की रोकथाम रहा है, और वास्तविक कारण खोजने के लिए लोगों को सज़ा के डर के बिना बयान दे पाने चाहिए
- just culture और दोष-रहित postmortem ने गलतियों को छिपाने की प्रवृत्ति घटाई, और LAX दुर्घटना के बाद अमेरिका में कंट्रोल टावर वाले हवाई अड्डों पर घातक रनवे टक्करें खत्म होने जैसी वास्तविक सुरक्षा सुधारों की राह बनी
LAX 1991 की दुर्घटना ने जो सवाल उठाया
- 1 फरवरी 1991 को, USAir flight 1493 ने Columbus, Ohio से Los Angeles International Airport तक की सामान्य उड़ान के अंत में रनवे 24L पर लैंडिंग की
- मौसम साफ था, Boeing 737 में कोई यांत्रिक खराबी नहीं थी, और approach के दौरान भी कोई खास समस्या नहीं थी
- लैंडिंग के तुरंत बाद 737 ने रनवे पर मौजूद छोटे commuter aircraft SkyWest flight 5569 को पीछे से टक्कर मारी
- SkyWest 5569, Palmdale जा रहा 19-सीट Fairchild Metroliner twin-engine turboprop था
- दोनों विमान साथ में रनवे से बाहर निकलकर छोड़े गए एयरपोर्ट फायर स्टेशन से हाईवे जैसी रफ्तार पर टकराए
- मृतकों की अंतिम संख्या 35 थी
- commuter aircraft में सवार सभी 12 लोग और USAir के कप्तान Colin Shaw तुरंत मारे गए
- USAir के cabin में धुआं और आग फैल गई, और कुछ यात्री बाहर नहीं निकल पाए
- गंभीर रूप से झुलसे 2 यात्रियों की बाद में अस्पताल में मौत हो गई
Robin Wascher की गलती और कार्रवाई
- उस समय LAX कंट्रोल टावर की local controller Robin Lee Wascher को दुर्घटना के बाद मानक प्रक्रिया के तहत ड्यूटी से हटा दिया गया
- Wascher ने SkyWest 5569 को “taxi into position and hold” का निर्देश दिया था, लेकिन उन्हें एहसास हुआ कि उन्हें टेकऑफ क्लीयरेंस देने की याद नहीं है
- बाद में वे कंट्रोल टावर लौटीं और अपने वरिष्ठ को बताया कि उन्हें लगता है USAir जिस विमान से टकराया वह SkyWest 5569 था
- उन्हें किसी भी तरह से सज़ा नहीं दी गई
- सहकर्मी उन्हें होटल ले गए ताकि मीडिया उन तक न पहुंच सके
- कुछ महीनों बाद NTSB सुनवाई में उन्होंने अपनी याद के मुताबिक घटनाक्रम बयान किया
- उन्हें कंट्रोल टावर में लौटने का मौका भी मिला, लेकिन उन्होंने खुद मना कर दिया
- किसी पर भी आपराधिक मुकदमा नहीं चला
- aviation industry में माना जाता है कि ऐसी ईमानदार गलती को सज़ा के बजाय कारणों की जांच के रूप में संभालना सुरक्षा के लिए अधिक मददगार है
विमान दुर्घटना जांच का दोष-रहित सिद्धांत
- आपदा के तुरंत बाद किसी खास व्यक्ति को जिम्मेदार ठहराने की इच्छा आम है, लेकिन हर दुर्घटना में कोई दुर्भावनापूर्ण व्यक्ति या स्पष्ट लापरवाही नहीं होती
- aviation क्षेत्र ने लंबे समय से blameless postmortem के करीब की प्रथा को औपचारिक रूप दिया है
- 1956 में Grand Canyon के ऊपर दो यात्री विमानों की टक्कर के मामले में, उस समय Civil Aeronautics Board के Bureau of Aviation Safety ने माना कि दोनों crew ने संभवतः एक-दूसरे को बहुत देर से देखा, इसलिए यह किसी की गलती नहीं थी
- दुर्घटना का कारण यह था कि हवाई टक्कर रोकने का कोई सक्रिय साधन नहीं था
- 1951 में दुनिया के aviation विशेषज्ञों ने Chicago Convention on International Civil Aviation का Annex 13 बनाकर विमान दुर्घटना जांच के तरीके को standardize किया
- Annex 13 का सार यह है कि विमान दुर्घटना जांच का मुख्य उद्देश्य भविष्य की दुर्घटनाओं की रोकथाम है
- यह कानूनी जिम्मेदारी तय करने से अधिक रोकथाम को प्राथमिकता देने का चुनाव है
- मृत pilots को दोषी ठहराने वाली पुलिस-शैली जांच भविष्य की दुर्घटना की संभावना कम नहीं करती
- NTSB भी दुर्घटना और घटना जांच को अधिकार या जिम्मेदारी तय करने की प्रक्रिया नहीं मानता, और उसका सिद्धांत है कि वह दोष या निंदा आवंटित नहीं करता
LAX में सामने आई सिस्टम समस्याएं
- NTSB ने केवल उस क्षण को नहीं देखा जब Wascher ने एक ही रनवे पर दो विमानों को clearance दिया, बल्कि यह जांचा कि ऐसी गलती संभव कैसे हुई
- LAX में airport surface पर विमानों की स्थिति पहचानने वाला ground radar था, लेकिन वह custom-made उपकरण था, इसलिए spare parts जुटाना मुश्किल था और वह अक्सर unusable रहता था
- दुर्घटना वाले दिन Wascher की सीट पर ground radar display काम नहीं कर रहा था
- SkyWest 5569 जिस Intersection 45 पर था, उसे नए बने terminal की lighting के कारण कंट्रोल टावर से देखना मुश्किल था
- Wascher, USAir को landing clearance देने के बाद किसी दूसरे विमान की जानकारी ढूंढ रही थीं, इसलिए अपनी गलती नहीं पकड़ सकीं
- वह जानकारी किसी दूसरे controller को देनी थी, लेकिन नहीं दी गई
- सुविधा की सूचना-प्रेषण hierarchy के कारण छूटी हुई जानकारी सुलझाने का काम Wascher पर आ गया, जिनकी भूमिका सुरक्षा के लिहाज से अधिक महत्वपूर्ण थी
- रात में या कम visibility की स्थिति में विमान को रनवे पर रोककर रखना खतरनाक था, लेकिन उस समय यह legal था और आम तौर पर किया जाता था
- हवा में टक्कर की चेतावनी देने वाला सिस्टम था, लेकिन ground traffic collision के बारे में controller को चेतावनी नहीं दे सकता था
- SkyWest की procedure के अनुसार अधिकांश aircraft lights टेकऑफ clearance मिलने के बाद ही चालू की जाती थीं
- SkyWest 5569 को टेकऑफ clearance नहीं मिली थी, इसलिए उसकी अधिकतर lights बंद थीं
- USAir pilots के लिए उसे देख पाना लगभग असंभव था
सज़ा के बजाय कारण हटाने से आए सुधार
- Wascher की गलती कई कारकों में से एक थी, और वह मजबूत ढांचे को गिरा देने वाले भूकंप जैसी नहीं बल्कि ताश के घर को गिरा देने वाले छोटे झटके जैसी थी
- LAX दुर्घटना जांच ने वास्तविक सुरक्षा सुधारों को जन्म दिया
- अधिक हवाई अड्डों पर अधिक भरोसेमंद ground radar लगाए गए
- automatic ground collision warning technology विकसित हुई
- कम visibility की स्थिति में aircraft को रनवे पर hold कराने की प्रथा पूरे अमेरिका में प्रतिबंधित हुई
- अगर जांच “गलती किसकी थी” पर रुक जाती, तो ये सुधार नहीं होते
- just culture उच्च operational safety के लिए human error के root causes की जांच करने वाली संगठनात्मक संस्कृति है
- किसने गलती की से ज्यादा अहम यह है कि गलती क्यों हुई
- अगर कर्मचारी retaliation से डरते हैं, तो वे गलतियां छिपाते हैं और संगठन अपनी कमजोरियां नहीं जान पाता
- जिन गलतियों में मौतें हुई हों, उनमें भी अगर संबंधित व्यक्ति नेक नीयत से काम करते हुए error कर बैठा, तो केवल परिणाम के आकार के आधार पर सज़ा अलग नहीं होनी चाहिए—यह सिद्धांत लागू होता है
सच्चे बयान को संभव बनाने वाली कानूनी संरचना
- NTSB के पास law enforcement authority नहीं है, और उसकी जांच के निष्कर्षों को legal liability के सबूत के रूप में इस्तेमाल नहीं किया जा सकता
- यह भरोसा pilots और controllers को दुर्घटना जांच में सच्चे बयान देने की शर्त बनाता है
- अगर Wascher पर आपराधिक मुकदमा चला होता, तो defense lawyer को बचाव की दलील बनानी पड़ती, और जांच शुरुआत से ही धुंधली हो जाती
- 1983 में Air Canada Boeing 767 का “Gimli Glider” मामला दिखाता है कि सज़ा का खतरा जांच को धुंधला कर सकता है
- उस विमान का fuel खत्म हो गया और वह Manitoba की drag strip पर उतरा
- कप्तान ने काम कर रहे fuel gauge के बिना takeoff किया, जो कम से कम 1 fuel gauge काम करने की airworthiness requirement के खिलाफ था
- उस समय कनाडा की जांच एक judge की अध्यक्षता वाली inquiry commission ने की थी, जिसके पास संबंधित लोगों पर आपराधिक मुकदमे की सिफारिश करने का अधिकार था
- कप्तान ने कहा कि Maintenance Central ने उस स्थिति में उड़ान की अनुमति दी थी, लेकिन मौके पर मौजूद अन्य लोगों ने इससे इनकार किया
- Maintenance Central के पास ऐसी अनुमति देने का अधिकार भी नहीं था
- सज़ा के खतरे के कारण संभावना बनी कि कप्तान ने वास्तविक कारण ईमानदारी से नहीं बताया, और यह निष्कर्ष नहीं निकल सका कि fuel gauge के बिना takeoff क्यों किया गया
सुरक्षा रिकॉर्ड और निष्कर्ष
- माना जाता है कि अमेरिका ने transparency, justice और truth के प्रति commitment पर आधारित root cause analysis के जरिए दुनिया की सबसे सुरक्षित aviation industry बनाई है
- LAX दुर्घटना के बाद 33 वर्षों में अमेरिका के कंट्रोल टावर वाले हवाई अड्डों पर कोई और घातक runway collision नहीं हुआ
- दुनिया भर में aviation accidents, air traffic हर साल बढ़ने के बावजूद, लगभग गायब होने के स्तर तक कम हो गईं
- 1972 में दुनिया भर के लगभग हर 2 लाख हवाई यात्रियों में 1 अपने गंतव्य पर जिंदा नहीं पहुंचता था
- 2022 में यह आंकड़ा घटकर हर 1.7 करोड़ में 1 हो गया
- अमेरिका में scheduled passenger airlines ने 15 वर्षों तक कोई घातक crash नहीं किया
- Los Angeles दुर्घटना का कारण केवल यह तथ्य नहीं था कि Robin Wascher एक विमान को भूल गई थीं, बल्कि वह कठोर सिस्टम था जिसमें सुरक्षा बनाए रखने के लिए एक व्यक्ति को अमानवीय रूप से लगातार सही काम करना पड़ता था
1 टिप्पणियां
Hacker News की टिप्पणियाँ
UK में workplace safety सुधारने वाले प्रमुख कानूनों में से एक Health and Safety at Work Act 1974 था, जिसने संगठनों पर कर्मचारियों की भलाई का ध्यान रखने की duty of care डाली।
इसके सिद्धांतों में से एक है near miss को गंभीरता से लेना। पहले सुनी एक training में एक health and safety engineer ने कहा था कि near miss “आसमान से मिला तोहफा” जैसा होता है, क्योंकि कोई घायल नहीं होता, लेकिन यह ठीक-ठीक दिखा देता है कि क्या और कैसे गलत हो सकता था, जिससे संगठन को प्रक्रियाएँ सुधारने का मौका मिलता है।
जब असल workplace accident होता है, तो Health and Safety Executive बड़े संगठनों पर कानून लागू करता है, और खासकर ऐसे रोके जा सकने वाले हादसों पर भारी जुर्माना लगा सकता है जिनके बारे में पहले से near miss के सबूत मौजूद थे।
दुर्घटना उस combination का नाम है जिसमें system खतरनाक स्थिति में होता है और प्रतिकूल environmental conditions उस खतरे को वास्तविक दुर्घटना में बदल देती हैं।
Near miss वह मामला है जहाँ system तो खतरनाक स्थिति में था, लेकिन environmental conditions किस्मत से अनुकूल रहीं, इसलिए दुर्घटना नहीं हुई। Environmental conditions को नियंत्रित नहीं किया जा सकता; आप बस इतना कर सकते हैं कि system को खतरनाक स्थिति में न रखें।
इसलिए सिर्फ near miss भी सही postmortem analysis के लिए पर्याप्त जानकारी दे देता है, और environmental conditions असल में गौण होती हैं।
Near miss सचमुच आसमान से मिला तोहफा जैसा है। मैं एक ऐसे near miss की post-incident investigation में शामिल रहा हूँ, जो थोड़ा अलग होता तो ऐसा दिखता: https://en.wikipedia.org/wiki/NOAA-19#Damage_during_manufact...
इस logic से हाल का Boeing 737 incident भी आसमान से मिला तोहफा माना जाना चाहिए। मुझे सच में लगता है कि इसे देखने का यह अच्छा नजरिया है, लेकिन अभी पता नहीं कि यह तोहफा बर्बाद होगा या नहीं।
बार-बार हो रहे data breaches को देखकर लगता है कि क्या कंपनियों को personal data की सुरक्षित handling के लिए जिम्मेदार बनाने वाला कोई मिलता-जुलता कानून बनाया जा सकता है।
मैं YouTube पर US Chemical Safety Board के videos में काफी डूबा हुआ था; वे industrial accidents तक ले जाने वाली घटनाओं को बहुत detail में समझाते हैं।
बार-बार दिखने वाला pattern यह है कि कोई warning sign या near miss था, लेकिन बड़ा नुकसान नहीं हुआ इसलिए जिम्मेदार लोगों ने उसे ignore कर दिया, और कुछ दिन या महीनों बाद वही system पूरी तरह predict किए जा सकने वाले तरीके से fail होकर त्रासदी बन गया।
DuPont chemical plant में हुआ घातक phosgene gas leak इसका अच्छा उदाहरण है1
यह लेख Kyra Dempsey, यानी Admiral Cloudberg ने लिखा है, जो Medium पर aviation accident investigations की लंबी, गहन series लिखती रही हैं: https://admiralcloudberg.medium.com/
LAX runway collision पर उनका Medium लेख यहाँ है: https://admiralcloudberg.medium.com/cleared-to-collide-the-c...
उसमें कुछ अतिरिक्त details भी हैं जो शायद Asterisk लेख में कही जा रही मुख्य बात को धुंधला कर देतीं। जैसे, वह controller जिसने घातक गलती की, उन लोगों में से थी जिन्हें 1981 में Ronald Reagan द्वारा 11,345 air traffic controllers को निकालने और उनकी फिर से hiring पर रोक लगाने के बाद hire किया गया था: https://en.wikipedia.org/wiki/Professional_Air_Traffic_Contr...
1986–87 तक controller workforce शायद trained staff से ठीक-ठाक भर चुकी होगी, इसलिए दोनों के बीच संबंध मानना मुश्किल है। 1991 की दुर्घटना पर चर्चा में PATCO को घसीटना सिर्फ राजनीतिक agenda आगे बढ़ाता है, चर्चा में मदद नहीं करता।
अगर search narrow करना हो, तो ‘possible pilot deviation’ या ‘number to call’ वाले videos खास तौर पर दिलचस्प और जीवंत होते हैं। मैं न pilot हूँ, न aircraft spotter, और planes में कोई खास दिलचस्पी भी नहीं है, लेकिन कुछ बार इस rabbit hole में गिरकर देखा तो यह काफी मजेदार लगा।
यहाँ तक कि मुझे लगा कि in-flight entertainment में ‘pilot/control tower communications सुनें’ वाला option होना चाहिए।
लगता नहीं कि उनका aviation background है, फिर भी वे aviation accidents के बारे में इतना अच्छा लिखना कैसे सीख गईं, यह जानने की curiosity है।
अच्छा लेख है। commercial aviation की safety culture और root causes की जांच कर उन्हें ठीक करने की प्रतिबद्धता से मैं काफी सहमत हूं
क्या अब यही मानक car accidents पर भी लागू नहीं किए जा सकते? वही human errors और खराब infrastructure बार-बार दोहराए जा रहे हैं, और SUVs व distracted driving बढ़ने से समस्या और खराब हो रही है
car culture के छिपे हुए नुकसान के बारे में चेतावनी देने वाला एक community https://www.reddit.com/r/fuckcars/ है। अगर FuckCars बहुत radical लगे, तो ज्यादा moderate urbanism channels भी देखने लायक हैं: https://www.youtube.com/@OhTheUrbanity/videos , https://www.youtube.com/@NotJustBikes/videos , https://www.youtube.com/@CityNerd/videos
इस मुद्दे के आसपास की cognitive dissonance हैरान करने वाली है
कुछ लोगों ने डरावने ढंग से खुला आसमान देख लिया, इसलिए हम पूरे 737MAX fleet को ground करने के लिए तैयार हैं, लेकिन अमेरिकी सड़कों पर हर साल 44,000 लोग मर रहे हैं और यह संख्या बढ़ रही है, फिर भी लगभग किसी को परवाह नहीं
ज्यादातर age groups में car deaths मौत का सबसे बड़ा कारण हैं। अमेरिका में जीवनकाल में car accident में मरने की संभावना 107 में 1 है। इन पागलपन भरे आंकड़ों को घटाने के लिए सरल और तर्कसंगत कदम भी आजादी पर तानाशाही अतिक्रमण जैसे लिए जाते हैं। उदाहरण के लिए, अभी California में speed limiter लागू करने की पहल
अमेरिका और दुनिया के कई हिस्सों में auto industry, car culture और car-centric सोच पूरी तरह नियंत्रण से बाहर हो चुकी है
https://en.m.wikipedia.org/wiki/Motor_vehicle_fatality_rate_...
पता चला कि car fatalities 2019 तक घट रही थीं, फिर trend उलट गया और हालत खराब होने लगी
पिछले 5 सालों में क्या हुआ होगा? cars में safety features तो emergency braking वगैरह के रूप में बेहतर हो रहे हैं। शराब एक factor हो सकती है, लेकिन खासकर पिछले 5 साल ही क्यों? cars बड़ी हुए भी काफी समय हो चुका है, और work from home से commuting time घटा होगा। बाकी देशों में कमी दिख रही है
cars और aircrafts का फर्क कुछ ऐसा लगता है
विमान: कभी-कभी pilot error, अक्सर mechanical या maintenance issue। pilot के reckless तरीके से उड़ाने की वजह से बहुत कम
car: कभी-कभी driver error या अनुभव की कमी, कभी-कभी mechanical या maintenance issue, लगभग हमेशा driver के खराब ढंग से चलाने की वजह से
r/fuckcars में ऐसे members हैं जो जिन vehicles को “बहुत बड़ा” मानते हैं, उनके tyres की हवा निकाल देते हैं या उन्हें फाड़ देते हैं। क्या आप उस तरीके का भी समर्थन करते हैं?
notjustbikes बड़ा होने के बाद विनम्रता छोड़कर पहले से सहमत लोगों को उपदेश देने लगा है, और असहमत लोगों को racist idiots कहना शुरू कर दिया है
मैंने comments में लिखा था कि पहले उनके videos बिना देखे भी उन लोगों को recommend कर सकता था जिन्हें convince करने की जरूरत है, लेकिन अब मुश्किल है; तो उन्होंने खुद reply करके insult किया कि मैंने अभी-अभी channel खोजा है और सच सहन नहीं कर पा रहा
“सीधे निष्कर्ष पर आएं तो, Wascher को किसी भी तरह सजा नहीं मिली।”
ऐसे लेखक की सराहना करनी चाहिए जो reader को कहानी का अंत जानने के लिए लेख के बिल्कुल आखिर तक पढ़ने पर मजबूर नहीं करता
शायद जवाब blameless culture/process है, जो information flow बनाए रखता है और improvements संभव करता है। हालांकि ‘no blame’ companies में काम नहीं करता
GitLab में किसी ने गलती से कई repositories irreversible तरीके से delete कर दी थीं, वह घटना याद आती है
GitLab ने उस incident और पूरे public embarrassment को शानदार तरीके से handle किया था। किसी व्यक्ति को दोष देने के बजाय उन्होंने खुद को दोष दिया कि उनके पास उचित emergency safeguards नहीं थे; इसे ढूंढकर पढ़ना worthwhile है
करीब 10 साल पहले मेरी team में भी ऐसा ही कुछ हुआ था। एक engineer ने production database delete कर दिया, और सौभाग्य से हम उसे recover कर पाए
postmortem का focus था “आखिर हमने ऐसा होने देना संभव कैसे रखा?” अगर मेरी याद सही है तो वह व्यक्ति इसके बाद भी 8 साल तक company में रहा, और हमने system की problem भी ठीक कर ली
medical field में blameless postmortems पढ़ने के बाद मैं team से हमेशा कहता हूं: अगर किसी की मौत के बाद भी doctors blameless postmortem कर सकते हैं, तो हम भी कर सकते हैं
onboarding document में मौजूद write-access credentials गलती से इस्तेमाल करके production database उड़ा देने वाले Reddit thread0 की भी याद आती है। GitLab incident वाला व्यक्ति भी बातचीत में शामिल हुआ था
संबंधित सामग्री: CAST analysis http://sunnyday.mit.edu/CAST-Handbook.pdf
यह approach accident में योगदान देने वाले सभी factors से अधिकतम सीखने पर केंद्रित है। यह blameless analysis सहित कई approaches को समेटता है, और मानता है कि हर factor का सिर्फ एक “cause” नहीं होता, बल्कि अलग-अलग factors interactions के network बनाते हैं
title पर हल्का सा तंज करें तो, आपने शायद plane crash झेला नहीं होगा। झेला होता तो यह लेख पढ़ नहीं रहे होते :)
अगर कोई इतना curious हो गया है कि इस comments section तक आ पहुंचा है, तो उसे CAST Handbook पढ़ने के लिए अलग से समय निकालना चाहिए
इसने सिर्फ accidents को देखने का तरीका ही नहीं, बल्कि organizations और दुनिया को देखने का तरीका भी बदल दिया। जिम्मेदारी वाली position में मौजूद हर किसी के लिए यह must-read होना चाहिए
लंबे समय से blog पर review या summary लिखना चाहता था, लेकिन उपयोगी सामग्री इतनी dense है कि इसे और compress करना मुश्किल है। इसलिए अभी तक publish नहीं कर पाया, तो rough हिस्सों को नजरअंदाज करें। पिछली बार जब मैंने हार मानी थी, draft ऐसा था: https://two-wrongs.com/root-cause-analysis-youre-doing-it-wr...
Switzerland में एक जबरदस्त politician हैं जो avalanche (1993) और plane crash1 (2001) दोनों में जीवित बचे थे
[1]https://en.wikipedia.org/wiki/Crossair_Flight_3597
https://en.wikipedia.org/wiki/Jacqueline_Badran
अगर ऐसी counterfactual दुनिया होती जहाँ airlines की crash रोकने की क्षमता और खराब होती, तो crash survival rate भी शायद कम होता
बहुत कम स्पीड पर जमीन पर विमानों के आपस में टकराने के मामले आंकड़ों को skew कर सकते हैं, लेकिन “plane crash” से क्या मतलब है, यह आप समझते ही होंगे
असल में plane crashes के करीब 90% में बचना संभव होता है, और लोग अपने ही accident के बारे में पढ़ भी लेते हैं
क्या आपका मतलब यह था कि plane crash होने पर मरना तय है? यह साफ तौर पर सच नहीं है
इतनी जोर से crash होने पर भी survivors मिलते हैं कि explosion हो जाए
अच्छी तरह की गई root cause analysis सच में संतोषजनक होती है। “सही जवाब” तक पहुंचने के लिए blame-free culture बिल्कुल जरूरी है
कंपनी की अलग-अलग teams में बड़े outages या high-impact outages की review करते समय, सबसे आदर्श पल वह होता है जब संबंधित लोग उस outage को जन्म देने वाली मुख्य conditions और घटनाओं के क्रम में गहराई से उतरते हैं। वे actions और outcomes पर focus करते हैं—outage के केंद्र में रहे actions, आसपास के actions, और वे actions भी जिनके बारे में पहले से कुछ पता नहीं था
इस स्तर तक पहुंचने के लिए खुद पर, colleagues पर और organization पर बहुत ऊंचा trust होना चाहिए
इसे कुछ बार सही तरह से करने पर एक सरल सिद्धांत सामने आता है। अगर mechanism इंसान की perfection पर निर्भर है, तो आखिरकार fail होगा। उसके बाद चर्चा लगभग हमेशा “अब क्या किया जाए” पर आ जाती है। क्या इंसानी imperfection से बचाने वाला guardrail चाहिए? implementation cost उस चीज की value के अनुरूप है जिसे बचाना है? क्या इस situation में इंसानी imperfection को accept किया जा सकता है?
जो organizations इस स्तर की discussion कर सकती हैं, उन्हें execution में साफ advantage मिलता है
अच्छी तरह लिखा गया लेख है। खासकर यह अच्छी तरह दिखाता है कि long-term thinking, short-term thinking से ज्यादा powerful होती है। साथ ही यह ऐसे organization को दिखाता है जो hope को strategy की तरह इस्तेमाल नहीं करता
“no blame” पर focus करना मुझे गलत लगता है। बेहतर outcomes बनाने वाली चीज accountability की culture है, और यह ऐसे leaders से शुरू होती है जो involve होते हैं और responsibility लेते हैं। blame कई मायनों में accountability का उलटा है, लेकिन blame-free culture होने पर भी accountability की culture न हो सकती है। blame की culture हमेशा irresponsibility की culture होती है
no blame, leader द्वारा problem की responsibility actively चुनने का result था। यह कहना था कि “इस tragedy की जिम्मेदारी किसी individual पर नहीं, हमारे organization पर है”, “यह controller ने नहीं, बल्कि institutional neglect के जरिए हमने किया”
Boeing में अभी भी problems इसलिए हैं क्योंकि Boeing leadership ने responsibility नहीं ली। Boeing leaders ने यह नहीं कहा कि “मैंने ऐसा incentive और punishment system बनाया जिसने unsafe planes पैदा किए”, इसलिए safety issues अब भी आते हैं
leadership का paradox यह है कि “leader organization के behavior के लिए responsible होता है, लेकिन वह behavior followers के individual decisions से पैदा होता है”
अगर air traffic controller ने जानबूझकर error नहीं किया था, तो यह leadership द्वारा solve किया जाने वाला साफ problem है। leadership बदलाव लाने के लिए responsible है, और blame उस बदलाव को रोक देता
Admiral Rickover ने accountability की यह culture nuclear navy में लाई थी, और उस organization का safety record काफी अच्छा है। यह लेख US Navy engineering tradition के बारे में पढ़ी बातों से काफी मिलता-जुलता है। Admiral Rickover का स्वाद लेने के लिए ये छोटी readings अच्छी हैं:
https://www.ans.org/news/article-1592/caught-in-the-leadersh... https://govleaders.org/rickover.htm
अगर लेखक ने अब तक Admiral Rickover और उनकी philosophy नहीं पढ़ी है, तो मुझे यकीन है कि उन्हें पढ़कर आनंद आएगा
जिन्हें यह लेख पसंद आया, उन्हें Extreme Ownership भी interesting लगेगी। cover और subtitle से जो impression मिलता है, उससे यह किताब बहुत बहुत बहुत बेहतर है, और Silicon Valley की हर role पर apply होती है
Rickover कुल मिलाकर पढ़ने लायक एक दिलचस्प व्यक्ति हैं। उनके “rules” के कई versions हैं, एक set यहां है:
https://www.linkedin.com/posts/kelly-robinson-phd-92842b6_ri...
एक और set नीचे जोड़ा है
मैं दो बातें highlight करना चाहता हूं। उन्होंने न सिर्फ बहुत high safety consciousness वाला organization बनाया, बल्कि US Navy के भारी resistance के बावजूद जन्मा एक astonishingly technically innovative organization भी बनाया
सोचिए, बात सिर्फ एक ऐसा छोटा nuclear reactor बनाने की नहीं थी जो पहले कभी बना ही नहीं था, बल्कि ऐसा reactor बनाने की थी जिसे submarine पर ले जाया जा सके। यह आसान technical goal नहीं था। ऊपर से, जिस organization को उन्होंने अपना जीवन दिया, उसके top ranks के resistance—यहां तक कि उन्हें पूरी तरह हटाने की कोशिशों—के बीच वह इसे पूरा करने की कोशिश कर रहे थे
वे perfect इंसान नहीं थे, लेकिन उनकी achievements काफी बड़ी थीं। खासकर अगर आप mechanical engineering में काम करते हैं, तो उनके बारे में और पढ़ना worthwhile है
दूसरा Rickover rules set:
Rule 1: समय के साथ quality standards ऊंचे होते जाने चाहिए, और किसी भी minimum standard द्वारा मांग किए गए level से काफी आगे होने चाहिए
Rule 2: complex systems चलाने वाले लोग बहुत competent होने चाहिए
Rule 3: supervisors को bad news आने पर उसका सामना करना चाहिए, और issues को इतना ऊपर escalate करना चाहिए जहां उन्हें solve किया जा सके
Rule 4: अपने काम के hazards और risks के प्रति healthy respect होना चाहिए
Rule 5: training continuous और rigorous होनी चाहिए
Rule 6: repair, quality control और technical support की सभी functions आपस में tightly integrated होनी चाहिए
Rule 7: organization और उसके members में past mistakes से सीखने की क्षमता और इच्छा होनी चाहिए
इसी महीने Switzerland में एक trial हुआ जिसमें air traffic controller पर military aircraft को गलत instructions देने, जिससे वह चट्टान से टकरा गया, के आरोप में prosecution चला और उन्हें दोषी ठहराया गया
guilty या not guilty होने के कई implications के कारण इसे follow करना काफी interesting था, और media coverage भी बहुत हुई
https://www.swissinfo.ch/eng/swiss-military-jet-crash--publi...
https://www.swissinfo.ch/eng/air-traffic-controller-blamed-f...
यह सैन्य अदालत थी, नागरिक अदालत नहीं। भले ही नागरिक और सैन्य air traffic controllers दोनों एक ही कंपनी Skyguide में काम करते हों, ऐसे मामलों में प्रक्रियाएँ अलग हो सकती हैं
कहने में यह आसान expression है, लेकिन जब on-call के दौरान सुबह 3 बजे किसी और के बनाए बखेड़े की वजह से नींद खुलती थी, तो “blameless” मेरी पहली प्रतिक्रिया नहीं होती थी
फिर भी समस्या की जड़ तक पहुँचना, शामिल सभी लोगों का solutions देना, और runbooks को लगातार बेहतर बनाना ही स्पष्ट रूप से सबसे अच्छा रास्ता है। हाँ, यह reactive है, लेकिन पहले से बनाई गई guidelines production traffic जितनी creative तरह से चीज़ें खराब नहीं कर सकतीं
अजीब या अचानक हुई outages के लिए आप किसी व्यक्ति से निजी रंजिश नहीं रखेंगे, लेकिन मुख्य सवाल है: “ऐसा क्यों हुआ?”
फिर भी आप हमेशा के लिए वही कमबख्त इंसान बने रहते हैं जिसने Christmas पर database outage कर दिया था। शायद आपके पास कोई विकल्प नहीं था, लेकिन फिर भी गालियाँ पड़ती हैं
हम सबके पास ऐसे scars हैं
और फिर सवाल फिर उठता है। हम सबके पास ऐसे scars क्यों हैं? क्या जिन systems से हम निपटते हैं वे पर्याप्त अच्छे नहीं हैं? स्थानीय गुस्सा शायद किसी अधिक systemic problem की ओर इशारा हो सकता है। आखिरकार हम फिर blameless postmortem वाली सोच पर लौट आते हैं