فصل ۱۷. تحلیل حوادث، شبه‌حوادث و یادگیری سازمانی:بخش اول

فهرست کلی فصل

17.1. مقدمه: چرا تحلیل رخدادها برای HSE حیاتی است؟

17.2. فراتر از «چه کسی مقصر بود؟»: گذار از تحلیل خطی به تحلیل سیستمی

17.3. تحلیل علت ریشه‌ای و محدودیت‌های آن در سیستم‌های پیچیده

17.4. روش‌های سیستمی تحلیل رخداد: STAMP، FRAM، AcciMap و Bow-Tie

17.5. تحلیل شبه‌حوادث: از هشدارهای ضعیف تا فرصت‌های یادگیری

17.6. کیفیت داده، مصاحبه و بازسازی رخداد در فرایند تحلیل

17.7. یادگیری سازمانی: از گزارش حادثه تا تغییر پایدار

17.8. فرهنگ گزارش‌دهی، فرهنگ عادلانه و اعتماد سازمانی

17.9. موانع یادگیری سازمانی و راهکارهای غلبه بر آن‌ها

17.10. طراحی نظام یکپارچه تحلیل رخداد و پایش عملکرد HSE

17.11. جمع‌بندی تحلیلی فصل: از تحلیل رخداد تا بلوغ یادگیری در HSE

منابع

17.1. مقدمه: چرا تحلیل رخدادها برای HSE حیاتی است؟

17.1.1. رخداد به‌مثابه منبع شناخت سازمان

در قلب مدیریت HSE، یک پرسش بنیادین وجود دارد: چگونه می‌توانیم از آنچه رخ داده، برای جلوگیری از آنچه ممکن است رخ دهد، یاد بگیریم؟ حادثه، شبه‌حادثه، انحراف عملیاتی، خرابی کنترل، گزارش وضعیت ناایمن و حتی یک مشاهده ساده می‌توانند حامل اطلاعاتی باشند که سازمان در شرایط عادی کمتر به آن‌ها دسترسی دارد. رخدادها پنجره‌هایی هستند به درون سیستم؛ پنجره‌هایی که نشان می‌دهند کار واقعی چگونه انجام می‌شود، کنترل‌ها در عمل چگونه عمل می‌کنند، تصمیم‌ها چگونه به خط مقدم می‌رسند و فشارهای سازمانی چگونه رفتار افراد را شکل می‌دهند.

در بسیاری از سازمان‌ها، تحلیل رخداد هنوز به‌صورت یک فرآیند اداری فهمیده می‌شود: حادثه رخ می‌دهد، فرم تکمیل می‌شود، علت‌های ظاهری ثبت می‌شوند، اقدام اصلاحی تعریف می‌شود و پرونده بسته می‌شود. اما پرسش مهم این است که آیا واقعاً سازمان چیزی آموخته است؟ اگر چند ماه بعد حادثه‌ای مشابه رخ دهد، می‌توان گفت گزارش قبلی «وجود داشته»، اما یادگیری رخ نداده است. از نظر من، تفاوت میان سازمان واکنشی و سازمان یادگیرنده دقیقاً در همین نقطه آشکار می‌شود: سازمان واکنشی حادثه را ثبت می‌کند؛ سازمان یادگیرنده حادثه را می‌فهمد و خود را تغییر می‌دهد.

ادبیات کلاسیک ایمنی مدت‌ها بر شناسایی علت‌ها، خطاها و شکست‌ها تمرکز داشت. این رویکرد در جای خود ارزشمند است، اما پژوهش‌های چند دهه اخیر نشان داده‌اند که در سیستم‌های اجتماعی-فنی پیچیده، حوادث معمولاً حاصل یک علت منفرد نیستند؛ بلکه از ترکیب تصمیم‌ها، محدودیت‌ها، تعاملات، سازگاری‌ها، ضعف کنترل‌ها و فشارهای زمینه‌ای پدید می‌آیند (Reason, 1997; Leveson, 2011; Hollnagel, 2012). بنابراین، تحلیل رخداد در HSE نباید فقط به دنبال پاسخ به این پرسش باشد که «چه چیزی خراب شد؟» بلکه باید بپرسد «سیستم چگونه به نقطه‌ای رسید که این رخداد ممکن شد؟»

17.1.2. پیوند تحلیل رخداد با پایش عملکرد HSE

در موضوع کلی این کتاب، یعنی ارزیابی و پایش عملکرد HSE، تحلیل رخداد جایگاهی کاملاً مرکزی دارد. اگر پایش عملکرد را فقط به شاخص‌هایی مانند نرخ حوادث، تعداد آسیب‌ها یا روزهای از دست‌رفته محدود کنیم، تنها بخشی از واقعیت را دیده‌ایم؛ آن هم معمولاً با تأخیر. تحلیل رخداد، به‌ویژه وقتی شامل شبه‌حوادث و ضعف‌های کنترل نیز باشد، می‌تواند داده‌هایی غنی‌تر و پیش‌نگرتر برای پایش فراهم کند.

برای مثال، افزایش تعداد شبه‌حوادث مرتبط با مجوز کار ممکن است پیش از وقوع حادثه جدی نشان دهد که کیفیت هماهنگی، کنترل انرژی یا نظارت عملیاتی در حال فرسایش است. یا تکرار خطاهای مشابه در تحویل شیفت ممکن است نشانه‌ای از ضعف طراحی ارتباطات، بار کاری بالا یا ابهام در نقش‌ها باشد. چنین داده‌هایی اگر درست تحلیل شوند، فقط گزارش گذشته نیستند؛ بلکه نشانه‌هایی از آینده‌اند.

در این فصل تلاش می‌کنم تحلیل حادثه و شبه‌حادثه را از سطح یک ابزار فنی به سطح یک سازوکار یادگیری سازمانی ارتقا دهم. برای این کار، ابتدا محدودیت نگاه فردمحور و خطی را بررسی می‌کنیم، سپس روش‌های سنتی و سیستمی تحلیل رخداد را مرور می‌کنیم، جایگاه شبه‌حوادث را توضیح می‌دهیم، و در نهایت نشان می‌دهیم چگونه می‌توان خروجی تحلیل رخداد را به تغییر پایدار، فرهنگ گزارش‌دهی و پایش هوشمند HSE پیوند زد. .

17.2. فراتر از «چه کسی مقصر بود؟»: گذار از تحلیل خطی به تحلیل سیستمی

17.2.1. محدودیت پرسش «چه کسی اشتباه کرد؟»

وقتی حادثه‌ای رخ می‌دهد، یکی از نخستین واکنش‌های طبیعی این است که بپرسیم: «چه کسی اشتباه کرد؟» این پرسش در ظاهر ساده و منطقی به نظر می‌رسد؛ زیرا حادثه غالباً در نقطه تماس انسان با سیستم دیده می‌شود. اپراتوری شیر اشتباه را باز کرده، راننده‌ای سرعت را رعایت نکرده، تکنسینی از دستورالعمل فاصله گرفته یا سرپرستی مجوز کار را کامل بررسی نکرده است. اما اگر تحلیل در همین سطح متوقف شود، معمولاً بخش مهمی از واقعیت از دست می‌رود.

Dekker (2014) با دقت نشان می‌دهد که «خطای انسانی» اغلب توضیح نیست، بلکه برچسبی است که بر نقطه پایان یک زنجیره پیچیده می‌زنیم. وقتی می‌گوییم اپراتور خطا کرد، هنوز توضیح نداده‌ایم چرا آن تصمیم در آن لحظه برای او قابل قبول، منطقی یا حتی ضروری به نظر رسیده است.

• آیا اطلاعات کافی در دسترس بود؟
• آیا رویه‌ها قابل اجرا بودند؟
• آیا فشار تولید یا زمان‌بندی وجود داشت؟
• آیا طراحی رابط کاربری خطا را محتمل‌تر کرده بود؟
• آیا سازمان پیش‌تر همین میان‌برها را تحمل یا حتی غیرمستقیم تشویق کرده بود؟

Reason (1997) در مدل معروف «پنیر سوئیسی» نشان داد که حوادث سازمانی معمولاً حاصل هم‌ترازی ضعف‌های فعال و پنهان هستند. خطای فردی ممکن است در لایه خط مقدم دیده شود، اما پشت آن ضعف‌هایی در طراحی، آموزش، نگهداشت، مدیریت تغییر، نظارت، قراردادها و تصمیم‌های مدیریتی قرار دارد. این نگاه کمک کرد تا تحلیل حوادث از تمرکز صرف بر فرد به سمت بررسی لایه‌های سازمانی حرکت کند.

تمرکز افراطی بر مقصر، سه پیامد خطرناک دارد. نخست، سازمان را از دیدن سهم خود در تولید شرایط حادثه بازمی‌دارد. دوم، فضای ترس ایجاد می‌کند و کارکنان را از گزارش خطاها و شبه‌حوادث منصرف می‌سازد. سوم، اقدامات اصلاحی را به راه‌حل‌های سطحی مانند تذکر، آموزش مجدد یا تنبیه محدود می‌کند. این اقدامات شاید از نظر اداری قابل ارائه باشند، اما معمولاً توان تغییر سیستم را ندارند.

17.2.2. تحلیل سیستمی و تغییر نوع پرسش

تحلیل سیستمی حادثه با تغییر پرسش آغاز می‌شود. به جای آنکه بپرسیم «چه کسی مقصر بود؟»، می‌پرسیم «چه شرایطی باعث شد این رفتار ممکن یا محتمل شود؟»، «چه کنترل‌هایی باید عمل می‌کردند اما نکردند؟»، «چه بازخوردهایی به مدیریت نرسید؟» و «چه فشارهایی عملکرد عادی را به سمت مرزهای خطر سوق داد؟» این تغییر پرسش، ماهیت تحلیل را دگرگون می‌کند.

در رویکرد سیستمی، حادثه نتیجه شکست یک جزء منفرد نیست، بلکه حاصل برهم‌کنش اجزای متعدد در یک سیستم اجتماعی-فنی است. این دیدگاه در آثار Rasmussen (1997)، Leveson (2011)، Hollnagel (2012) و Woods et al. (2010) به‌خوبی توسعه یافته است. Rasmussen (1997) نشان داد که سیستم‌ها تحت تأثیر فشارهای اقتصادی، بار کاری و الزامات بهره‌وری به‌تدریج به سمت مرزهای عملکرد ایمن رانده می‌شوند. به بیان ساده‌تر، بسیاری از سازمان‌ها تا زمانی که حادثه رخ نداده است، نمی‌فهمند تا چه اندازه به مرز خطر نزدیک شده‌اند.

از منظر HSE، ارزش تحلیل سیستمی در این است که حادثه را به زبان تصمیم‌گیری مدیریتی ترجمه می‌کند. اگر بگوییم «کارگر دستورالعمل را رعایت نکرد»، اقدام اصلاحی ممکن است محدود به آموزش یا تذکر شود. اما اگر نشان دهیم دستورالعمل با شرایط واقعی کار ناسازگار بوده، نقاط اتصال کافی وجود نداشته، برنامه زمان‌بندی فشار غیرواقعی ایجاد کرده و پیمانکار بر اساس سرعت کار ارزیابی شده است، آنگاه اقدامات اصلاحی به طراحی کار، قراردادها، برنامه‌ریزی و نظارت مدیریتی گسترش می‌یابد. این همان جهشی است که تحلیل رخداد را به یادگیری سازمانی تبدیل می‌کند.

.

17.3. تحلیل علت ریشه‌ای و محدودیت‌های آن در سیستم‌های پیچیده

17.3.1. جایگاه و کاربرد تحلیل علت ریشه‌ای

تحلیل علت ریشه‌ای یا Root Cause Analysis یکی از رایج‌ترین رویکردها در تحلیل حوادث است. ابزارهایی مانند «پنج چرا»، نمودار استخوان ماهی، تحلیل درخت خطا و روش‌های مشابه تلاش می‌کنند از علت‌های سطحی به علت‌های عمیق‌تر برسند. این ابزارها، به‌ویژه در رخدادهای نسبتاً ساده یا فنی، می‌توانند مفید باشند. برای مثال، اگر خرابی یک پمپ ناشی از برنامه نگهداشت نامناسب، انتخاب نادرست قطعه یا نبود کنترل کیفیت باشد، RCA می‌تواند مسیر تحلیل را روشن کند.

مزیت RCA در سادگی، قابلیت آموزش و کاربردپذیری آن است. بسیاری از سازمان‌ها به کمک همین ابزارها توانسته‌اند از گزارش‌های توصیفی فاصله بگیرند و ساختار منظم‌تری برای تحلیل ایجاد کنند. روش‌هایی مانند پنج چرا به تیم تحلیل یادآوری می‌کنند که به نخستین پاسخ رضایت ندهد و چند لایه عمیق‌تر برود. نمودار استخوان ماهی نیز کمک می‌کند عوامل انسانی، تجهیزاتی، محیطی، مدیریتی و رویه‌ای هم‌زمان دیده شوند.

با این حال، باید مراقب باشیم RCA را بیش از ظرفیت واقعی آن به کار نگیریم. اصطلاح «علت ریشه‌ای» گاهی این تصور را ایجاد می‌کند که برای هر حادثه یک علت بنیادی وجود دارد که اگر کشف و حذف شود، مسئله حل خواهد شد. این تصور در سیستم‌های پیچیده همیشه درست نیست. در بسیاری از حوادث HSE، آنچه رخ می‌دهد حاصل ترکیب چندین عامل است که هر یک به‌تنهایی کافی نیستند، اما در کنار هم مسیر حادثه را می‌سازند.

17.3.2. محدودیت‌های RCA در رخدادهای پیچیده

یکی از محدودیت‌های مهم RCA، گرایش آن به خطی‌سازی حادثه است. حادثه به‌صورت زنجیره‌ای از علت‌ها و معلول‌ها تصویر می‌شود: A باعث B شد، B باعث C شد و C به حادثه انجامید. این مدل برای برخی رخدادها مناسب است، اما در سیستم‌های پیچیده که تعاملات غیرخطی، بازخوردهای ناقص، سازگاری‌های محلی و تصمیم‌های چندسطحی وجود دارد، کافی نیست (Leveson, 2011; Salmon et al., 2012).

محدودیت دوم، سوگیری پس‌نگر است. پس از حادثه، مسیر رخداد روشن و بدیهی به نظر می‌رسد. ما می‌دانیم چه اتفاقی افتاده و ناخودآگاه تصور می‌کنیم دیگران نیز باید آن را پیش‌بینی می‌کردند. Dekker (2014) این پدیده را یکی از دام‌های اصلی تحلیل حادثه می‌داند. تحلیل‌گر باید خود را در موقعیت زمانی و اطلاعاتی افراد درگیر قرار دهد، نه در جایگاه کسی که پایان داستان را می‌داند.

محدودیت سوم، ضعف در دیدن عوامل سازمانی و مدیریتی است. در بسیاری از گزارش‌های RCA، علت‌های نهایی به «عدم رعایت رویه»، «عدم توجه»، «آموزش ناکافی» یا «نظارت ناکافی» ختم می‌شوند. این عبارات اگر بیشتر تحلیل نشوند، ارزش یادگیری محدودی دارند. «آموزش ناکافی» یعنی چه؟ چه کسی نیاز آموزشی را تشخیص نداده است؟ چرا آموزش با ریسک واقعی کار منطبق نبوده است؟ چرا نظام ارزیابی صلاحیت نتوانسته ضعف را آشکار کند؟ تا زمانی که چنین پرسش‌هایی مطرح نشوند، RCA در سطح کلی‌گویی باقی می‌ماند.

بنابراین، من RCA را رد نمی‌کنم؛ بلکه آن را یک ابزار محدود می‌دانم. در رخدادهای ساده‌تر می‌تواند مفید باشد، اما در رخدادهای پیچیده باید با روش‌های سیستمی تکمیل شود. سازمان بالغ، ابزار را با ماهیت مسئله هماهنگ می‌کند؛ نه اینکه همه رخدادها را با یک قالب ثابت تحلیل کند.

.

17.4. روش‌های سیستمی تحلیل رخداد: STAMP، FRAM، AcciMap و Bow-Tie

17.4.1. STAMP و تحلیل کنترل ناکافی

مدل STAMP که توسط Leveson (2011) توسعه یافت، ایمنی را مسئله کنترل در یک سیستم اجتماعی-فنی می‌داند. در این نگاه، حادثه الزاماً نتیجه خرابی یک جزء نیست؛ بلکه می‌تواند ناشی از کنترل ناکافی، محدودیت‌های ایمنی نامناسب، بازخورد ناقص یا مدل ذهنی نادرست تصمیم‌گیرندگان باشد. STPA نیز به‌عنوان روش تحلیلی مرتبط با STAMP، برای شناسایی کنترل‌های ناایمن و سناریوهای خطرناک به کار می‌رود (Leveson & Thomas, 2018).

در تحلیل حادثه با منطق STAMP، پرسش‌هایی مانند این مطرح می‌شود: چه کنترل‌هایی باید وجود می‌داشت؟ چه کسی مسئول اعمال آن‌ها بود؟ چه بازخوردهایی باید به کنترل‌کننده می‌رسید؟ آیا تصمیم‌گیرنده تصویر درستی از وضعیت سیستم داشت؟ آیا محدودیت‌های ایمنی با فشارهای تولیدی، زمانی یا اقتصادی تضعیف شده بودند؟ این پرسش‌ها حادثه را از سطح رفتار فردی به سطح معماری کنترل سیستم منتقل می‌کنند.

برای مثال، در حادثه‌ای مربوط به ورود به فضای بسته، تحلیل سنتی ممکن است بر این تمرکز کند که کارگر گازسنجی را درست انجام نداده است. اما تحلیل STAMP بررسی می‌کند که ساختار صدور مجوز کار چگونه طراحی شده، بازخورد وضعیت تهویه چگونه منتقل شده، مسئولیت توقف کار در شرایط متغیر با چه کسی بوده، و آیا مدیریت پروژه اطلاعات کافی درباره هم‌زمانی فعالیت‌ها داشته است یا نه. این نوع تحلیل برای سیستم‌هایی که چند واحد، چند پیمانکار و چند سطح تصمیم‌گیری دارند، بسیار راهگشاست.

17.4.2. FRAM و فهم تغییرپذیری عملکرد

روش FRAM که توسط Hollnagel (2012) معرفی شد، بر ایده تغییرپذیری عملکرد استوار است. در جهان واقعی، کار همیشه دقیقاً مطابق دستورالعمل انجام نمی‌شود. افراد برای پیشبرد کار، با محدودیت منابع، زمان، اطلاعات و شرایط محیطی سازگار می‌شوند. این سازگاری‌ها در اغلب مواقع مفید و حتی ضروری‌اند، اما گاهی ترکیب آن‌ها می‌تواند به پیامد ناخواسته منجر شود.

ارزش FRAM در این است که به جای تمرکز صرف بر شکست، بر عملکرد عادی تمرکز می‌کند. می‌پرسد کار در حالت معمول چگونه انجام می‌شود؟ کدام عملکردها به یکدیگر وابسته‌اند؟ تغییرپذیری یک فعالیت چگونه بر فعالیت دیگر اثر می‌گذارد؟ این نگاه با مفهوم Safety-II نیز هم‌خوان است؛ مفهومی که بر یادگیری از عملکرد موفق و روزمره، نه فقط شکست‌ها، تأکید دارد (Hollnagel, 2014).

برای نمونه، در یک پروژه تعمیراتی، تأخیر در آماده‌سازی تجهیزات ممکن است باعث فشرده شدن زمان صدور مجوز، کاهش کیفیت گفت‌وگوی پیش از کار، و افزایش اتکا به تجربه افراد شود. هیچ‌یک از این موارد به‌تنهایی حادثه نیست، اما ترکیب آن‌ها می‌تواند شرایطی ایجاد کند که در آن یک خطای کوچک به پیامد جدی منجر شود. FRAM به ما کمک می‌کند این تشدید تدریجی و غیرخطی را ببینیم.

17.4.3. AcciMap و تحلیل چندسطحی حادثه

AcciMap که ریشه در آثار Rasmussen (1997) و Svedung و Rasmussen (2002) دارد، حادثه را در سطوح مختلف سیستم تحلیل می‌کند: سیاست‌گذاری و مقررات، مدیریت ارشد، مدیریت میانی، فرایندهای سازمانی، فعالیت‌های خط مقدم، تجهیزات و محیط کار. این روش به‌ویژه برای حوادثی مفید است که عوامل آن در سطوح مختلف پراکنده‌اند.

در بسیاری از رخدادهای HSE، تصمیم‌هایی که ماه‌ها قبل گرفته شده‌اند، در روز حادثه اثر خود را نشان می‌دهند. کاهش بودجه نگهداشت، تغییر پیمانکار، فشار زمان‌بندی، ادغام واحدها، کاهش نیروی باتجربه یا ضعف در مدیریت تغییر ممکن است به‌تدریج ظرفیت ایمنی سیستم را کاهش دهد. AcciMap این زنجیره چندسطحی را قابل مشاهده می‌کند.

Salmon et al. (2012) در مقایسه روش‌های سیستمی تحلیل حادثه نشان می‌دهند که AcciMap برای آشکارسازی عوامل سازمانی و بین‌سازمانی بسیار مناسب است. از نظر کاربردی، این روش کمک می‌کند اقدامات اصلاحی فقط به سطح عملیات محدود نشوند. اگر ریشه‌های حادثه در سطح قرارداد، برنامه‌ریزی یا سیاست‌های سازمانی قرار دارد، اصلاح نیز باید به همان سطوح برسد.

17.4.4. Bow-Tie و تحلیل موانع

مدل Bow-Tie با تمرکز بر تهدیدها، رویداد مرکزی، پیامدها و موانع پیشگیرانه و کاهشی، پلی میان تحلیل حادثه و مدیریت کنترل‌ها ایجاد می‌کند. این مدل در صنایع فرایندی، نفت و گاز و فعالیت‌های پرخطر کاربرد گسترده دارد و در گزارش‌های CCPS و IOGP نیز جایگاه مهمی یافته است (CCPS, 2018; IOGP, 2016).

در تحلیل رخداد، Bow-Tie کمک می‌کند بپرسیم کدام مانع باید از وقوع رویداد مرکزی جلوگیری می‌کرد و چرا موفق نبود؟ کدام مانع پیامد را کاهش داد؟ چه عوامل فرساینده‌ای اثربخشی مانع را کاهش داده بودند؟ آیا مالک مانع مشخص بود؟ آیا وضعیت مانع پیش از رخداد پایش می‌شد؟ این پرسش‌ها تحلیل را به سمت پایش کنترل‌های حیاتی هدایت می‌کنند.

برای مثال، اگر شبه‌حادثه‌ای در کار گرم نزدیک یک ماده قابل اشتعال رخ داده باشد، Bow-Tie ما را وادار می‌کند وضعیت موانعی مانند جداسازی مواد، پاک‌سازی محیط، گازسنجی، مجوز کار، دیده‌بان آتش، آموزش، توقف کار و پاسخ اضطراری را بررسی کنیم. به این ترتیب، رخداد به آزمونی برای سلامت سیستم کنترل تبدیل می‌شود.

.

17.5. تحلیل شبه‌حوادث: از هشدارهای ضعیف تا فرصت‌های یادگیری

17.5.1. مفهوم شبه‌حادثه و ارزش پیشگیرانه آن

شبه‌حادثه یا Near Miss رخدادی است که ظرفیت ایجاد آسیب، خسارت یا پیامد زیست‌محیطی را داشته، اما به دلیل شانس، مداخله به‌موقع یا عملکرد یک مانع، پیامد جدی رخ نداده است. تفاوت شبه‌حادثه با حادثه گاهی فقط چند ثانیه، چند سانتی‌متر یا یک تصمیم است. به همین دلیل، شبه‌حوادث از نظر یادگیری بسیار ارزشمندند؛ زیرا سیستم فرصت می‌دهد بدون پرداخت هزینه سنگین حادثه، ضعف‌های خود را ببیند.

Heinrich (1931) با نسبت‌های معروف خود میان حوادث شدید، حوادث خفیف و رخدادهای بدون آسیب، توجه سازمان‌ها را به فراوانی رخدادهای کوچک‌تر جلب کرد. اگرچه نسبت‌های دقیق هرم هاینریش بعدها مورد نقد جدی قرار گرفت و نباید به‌صورت مکانیکی استفاده شود، ایده اصلی همچنان مهم است: همه نشانه‌های خطر در قالب حادثه شدید ظاهر نمی‌شوند. بسیاری از هشدارها پیش‌تر در قالب شبه‌حادثه، انحراف یا ضعف کنترل دیده شده‌اند.

در ادبیات جدید ایمنی، شبه‌حوادث را می‌توان نوعی «سیگنال ضعیف» دانست؛ نشانه‌ای که اگر جدی گرفته شود، می‌تواند از رخدادهای بزرگ‌تر جلوگیری کند. Weick و Sutcliffe (2015) در بحث سازمان‌های با قابلیت اطمینان بالا تأکید می‌کنند که این سازمان‌ها نسبت به شکست‌های کوچک حساس‌اند و آن‌ها را بی‌اهمیت تلقی نمی‌کنند. در HSE نیز همین منطق صادق است: سازمانی که شبه‌حادثه را جدی می‌گیرد، پیش از حادثه یاد می‌گیرد.

17.5.2. چرا شبه‌حوادث گزارش نمی‌شوند؟

با وجود ارزش بالای شبه‌حوادث، بسیاری از آن‌ها گزارش نمی‌شوند. دلایل این مسئله متنوع است. برخی کارکنان تصور می‌کنند چون آسیبی رخ نداده، موضوع ارزش گزارش ندارد. برخی می‌ترسند گزارش به سرزنش، تنبیه یا دردسر اداری منجر شود. گاهی فرآیند گزارش‌دهی طولانی و پیچیده است. در برخی سازمان‌ها نیز کارکنان تجربه کرده‌اند که گزارش‌های قبلی به تغییر واقعی منجر نشده‌اند؛ بنابراین انگیزه‌ای برای گزارش ندارند.

Probst و Graso (2013) نشان می‌دهند که اقلیم ایمنی و اعتماد سازمانی نقش مهمی در تمایل کارکنان به گزارش دارند. اگر کارکنان باور داشته باشند که گزارش برای یادگیری استفاده می‌شود، نه برای مجازات، احتمال مشارکت افزایش می‌یابد. در مقابل، اگر گزارش‌دهی با پیامدهای منفی همراه باشد، سازمان به‌تدریج کور می‌شود؛ یعنی رخدادها اتفاق می‌افتند، اما به سطح یادگیری سازمانی نمی‌رسند.

از نظر من، کیفیت نظام گزارش‌دهی را نباید فقط با تعداد گزارش‌ها سنجید. افزایش ناگهانی تعداد گزارش‌ها ممکن است نشانه بهبود اعتماد باشد، نه بدتر شدن وضعیت ایمنی. برعکس، کاهش گزارش‌ها لزوماً نشانه ایمن‌تر شدن سازمان نیست؛ ممکن است نشانه سکوت، بی‌اعتمادی یا خستگی گزارش‌دهی باشد. بنابراین، شاخص‌های گزارش‌دهی باید با تحلیل زمینه‌ای همراه شوند.

17.5.3. تحلیل شبه‌حادثه با نگاه ریسک‌محور

همه شبه‌حوادث نیازمند تحلیل یکسان نیستند. سازمان باید بتواند شبه‌حوادث را بر اساس پتانسیل پیامد، ضعف کنترل‌های حیاتی، تکرارپذیری و امکان یادگیری اولویت‌بندی کند. یک شبه‌حادثه بدون پیامد اما با پتانسیل فاجعه‌بار باید جدی‌تر از یک آسیب خفیف با پتانسیل محدود تحلیل شود. این نکته در مدیریت ایمنی فرایند نیز اهمیت زیادی دارد؛ زیرا برخی رخدادهای بدون آسیب ممکن است نشان‌دهنده ضعف عمیق در کنترل‌های حیاتی باشند (API, 2021; CCPS, 2018).

برای تحلیل شبه‌حادثه، باید از خود بپرسیم: چه چیزی مانع تبدیل آن به حادثه شد؟ آیا مانع مورد نظر طراحی‌شده و قابل اتکا بود یا صرفاً شانس و واکنش فردی نقش داشت؟ اگر همین رخداد در شیفتی دیگر، با فردی کم‌تجربه‌تر یا در شرایط آب‌وهوایی متفاوت رخ می‌داد، پیامد چه بود؟ این نوع پرسش‌ها ارزش یادگیری شبه‌حادثه را افزایش می‌دهند.

.

17.6. کیفیت داده، مصاحبه و بازسازی رخداد در فرایند تحلیل

17.6.1. بازسازی رخداد و پرهیز از روایت ساده‌ساز

تحلیل رخداد با داده آغاز می‌شود، اما داده خام به‌خودی‌خود یادگیری ایجاد نمی‌کند. تیم تحلیل باید بتواند رخداد را بازسازی کند: چه اتفاقی افتاد، چه زمانی رخ داد، چه کسانی درگیر بودند، چه اطلاعاتی در دسترس بود، چه کنترل‌هایی عمل کردند یا نکردند، و شرایط محیطی و سازمانی چگونه بود. این بازسازی باید تا حد امکان به «کار واقعی» نزدیک باشد، نه فقط به آنچه در دستورالعمل‌ها نوشته شده است.

یکی از خطاهای رایج در تحلیل حادثه، ساختن روایتی بیش از حد مرتب و ساده پس از رخداد است. در واقعیت، افراد معمولاً با اطلاعات ناقص، فشار زمان، محدودیت منابع و ابهام تصمیم می‌گیرند. اما گزارش حادثه گاهی طوری نوشته می‌شود که گویی همه چیز از ابتدا روشن بوده است. چنین روایتی شاید از نظر اداری تمیز باشد، اما از نظر یادگیری فقیر است.

Woods et al. (2010) تأکید می‌کنند که برای فهم خطای انسانی باید به زمینه تصمیم‌گیری توجه کرد. تحلیل‌گر باید بپرسد شرایط چگونه برای افراد در همان لحظه معنا شده بود. این پرسش ساده، اما بسیار مهم است؛ زیرا ما را از داوری پس‌نگر دور می‌کند و به فهم عمیق‌تر رفتار نزدیک می‌سازد.

17.6.2. مصاحبه، مشاهده و شواهد چندمنبعی

مصاحبه با افراد درگیر یکی از حساس‌ترین بخش‌های تحلیل رخداد است. اگر مصاحبه حالت بازجویی پیدا کند، افراد دفاعی می‌شوند و روایت واقعی پنهان می‌ماند. مصاحبه مؤثر باید با هدف فهم انجام شود، نه اثبات تقصیر. پرسش‌های باز، گوش دادن فعال، پرهیز از قضاوت زودهنگام و توجه به جزئیات عملیاتی اهمیت فراوان دارد.

در کنار مصاحبه، شواهد دیگری نیز باید بررسی شود: اسناد مجوز کار، سوابق نگهداشت، داده‌های فرایندی، تصاویر، نقشه‌ها، گزارش‌های شیفت، سوابق آموزشی، پیام‌های ارتباطی، داده‌های آب‌وهوا، تغییرات برنامه‌ریزی و سوابق تصمیم‌های مدیریتی. هرچه تحلیل به منابع متنوع‌تری متکی باشد، احتمال گرفتار شدن در روایت یک‌جانبه کمتر می‌شود.

در رخدادهای پیچیده، بهتر است تیم تحلیل چندرشته‌ای باشد. حضور HSE، عملیات، نگهداشت، مهندسی، منابع انسانی و در صورت لزوم نماینده پیمانکار، کیفیت تحلیل را افزایش می‌دهد. البته چندرشته‌ای بودن به‌تنهایی کافی نیست؛ تیم باید مهارت تحلیل سیستمی داشته باشد و بتواند میان داده، تفسیر و فرضیه تمایز بگذارد.

17.6.3. کیفیت طبقه‌بندی و کدگذاری رخدادها

در سازمان‌های بزرگ، رخدادها معمولاً در سامانه‌های نرم‌افزاری ثبت و طبقه‌بندی می‌شوند. کیفیت این طبقه‌بندی برای پایش عملکرد HSE بسیار مهم است. اگر علت‌ها به‌صورت کلی و تکراری ثبت شوند، مانند «بی‌احتیاطی»، «عدم رعایت دستورالعمل» یا «نقص آموزش»، بانک داده در بلندمدت ارزش تحلیلی خود را از دست می‌دهد.

برای استفاده مؤثر از داده‌های رخداد، طبقه‌بندی باید به‌گونه‌ای طراحی شود که عوامل سیستمی را نیز ثبت کند: ضعف طراحی کار، ابهام نقش، فشار زمان، نقص بازخورد، ضعف پیمانکاری، فرسایش موانع، تغییرات کنترل‌نشده، ضعف ارتباطات و مانند آن. البته باید مراقب بود طبقه‌بندی بیش از حد پیچیده نشود؛ زیرا کاربران در عمل از آن استفاده نخواهند کرد. تعادل میان دقت تحلیلی و سادگی کاربردی، یک اصل کلیدی در طراحی نظام گزارش‌دهی است.

.

17.7. یادگیری سازمانی: از گزارش حادثه تا تغییر پایدار

17.7.1. تفاوت ثبت، اصلاح و یادگیری

هر سازمانی که حادثه‌ای را ثبت می‌کند، الزاماً یاد نمی‌گیرد. حتی اجرای اقدام اصلاحی نیز همیشه معادل یادگیری نیست. یادگیری سازمانی زمانی رخ می‌دهد که سازمان فهم خود را تغییر دهد، فرض‌های نادرست را اصلاح کند، فرآیندها و کنترل‌ها را بهبود دهد و این تغییر در عمل پایدار شود. Argyris و Schön (1978) میان یادگیری تک‌حلقه‌ای و دوحلقه‌ای تمایز قائل شدند. این تمایز برای HSE بسیار آموزنده است.

در یادگیری تک‌حلقه‌ای، سازمان خطا را اصلاح می‌کند، اما قواعد و فرض‌های اصلی را تغییر نمی‌دهد. مثلاً پس از حادثه، آموزش مجدد برگزار می‌کند یا چک‌لیست را تکمیل‌تر می‌سازد. این اقدامات ممکن است لازم باشند، اما همیشه کافی نیستند. در یادگیری دوحلقه‌ای، سازمان می‌پرسد چرا اصلاً چنین شرایطی ایجاد شد، چه فرض‌هایی در طراحی کار نادرست بود، و آیا اهداف، ساختارها یا معیارهای عملکرد باید تغییر کنند.

برای مثال، اگر حادثه ناشی از عجله در پایان پروژه باشد، اقدام تک‌حلقه‌ای ممکن است تأکید مجدد بر رعایت رویه باشد. اما یادگیری دوحلقه‌ای می‌پرسد چرا نظام ارزیابی پروژه، تحویل به‌موقع را بیش از کیفیت کنترل‌های HSE پاداش می‌دهد. این پرسش دشوارتر است، اما یادگیری واقعی دقیقاً از همین نقطه آغاز می‌شود.

17.7.2. اقدامات اصلاحی اثربخش

اقدامات اصلاحی قلب عملی یادگیری از رخداد هستند. اما کیفیت اقدامات اصلاحی بسیار متفاوت است. اقداماتی مانند «آموزش مجدد»، «تذکر به کارکنان» یا «بازنگری دستورالعمل» اگر بدون تحلیل عمیق تعریف شوند، معمولاً اثر محدودی دارند. اقدامات مؤثر باید با علت‌های سیستمی مرتبط باشند، مالک مشخص داشته باشند، زمان‌بندی واقع‌بینانه داشته باشند، منابع لازم برای اجرا فراهم شود و اثربخشی آن‌ها پس از اجرا ارزیابی گردد.

در ادبیات مدیریت ایمنی، سلسله‌مراتب کنترل‌ها اصل مهمی است. هرچه اقدام اصلاحی به حذف خطر، جایگزینی، کنترل مهندسی و طراحی سیستم نزدیک‌تر باشد، معمولاً پایدارتر از اقداماتی است که صرفاً بر رفتار فردی تکیه دارند. البته در HSE همیشه نمی‌توان خطر را حذف کرد، اما می‌توان بسیاری از وابستگی‌های غیرضروری به حافظه، توجه و قهرمانی فردی را کاهش داد.

یکی از ضعف‌های رایج، بستن اقدام اصلاحی بر اساس «انجام کار» است، نه «اثر کار». برای مثال، اگر اقدام اصلاحی برگزاری آموزش باشد، بستن آن پس از برگزاری کلاس کافی نیست. باید بررسی شود آیا رفتار، فهم، صلاحیت یا کیفیت کنترل واقعاً تغییر کرده است یا خیر. در غیر این صورت، سازمان به جای یادگیری، فقط مدارک تکمیل‌شده تولید می‌کند.

17.7.3. انتقال یادگیری در سازمان

یادگیری از یک رخداد نباید در همان واحد یا همان سایت باقی بماند. بسیاری از حوادث در سازمان‌های بزرگ تکرار می‌شوند، زیرا درس‌ها به‌خوبی منتقل نمی‌شوند. انتقال یادگیری نیازمند سازوکارهای رسمی و غیررسمی است: بولتن‌های یادگیری، نشست‌های گفت‌وگوی عملیاتی، بازنگری استانداردها، آموزش مبتنی بر سناریو، اشتراک تجربه میان واحدها و ادغام درس‌ها در فرآیند مدیریت تغییر.

با این حال، انتشار یک گزارش طولانی برای همه واحدها معمولاً یادگیری ایجاد نمی‌کند. درس‌آموخته باید متناسب با مخاطب ترجمه شود. مدیر ارشد نیاز دارد بداند چه تصمیم‌هایی باید تغییر کند. سرپرست نیاز دارد بداند چه نشانه‌هایی را در میدان رصد کند. اپراتور نیاز دارد بفهمد در شرایط مشابه چه کنترل‌هایی حیاتی‌اند. پیمانکار نیاز دارد بداند چه انتظاری از او وجود دارد. بنابراین، یادگیری سازمانی یک فرآیند ارتباطی فعال است، نه ارسال منفعلانه گزارش. .

برای مطالعه ادامه فصل به مقاله فصل ۱۷. تحلیل حوادث، شبه‌حوادث و یادگیری سازمانی:بخش دوم را مطالعه کنید.