تفاوت تجزیه و تحلیل حوادث شغلی با تجزیه و تحلیل حوادث فرایندی

خلاصه مقاله

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

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

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

---

چرا یک مدل واحد برای بررسی همه حوادث کافی نیست؟

در HSE عمومی، بسیاری از رویدادها حول این محور شکل می‌گیرند:

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

در این فضا، بررسی حادثه معمولاً بر این متمرکز است که:

• چه کسی درگیر بود
• چه کاری انجام شد
• کدام اقدام ناایمن رخ داد
• چه شرایط ناایمنی وجود داشت
• چگونه می‌توان از تکرار آن جلوگیری کرد

اما در حوادث فرایندی، موضوع متفاوت است. اینجا معمولاً با مسائلی روبه‌رو هستیم مثل:

• از دست رفتن مهار فرایند
• افزایش فشار یا دما خارج از کنترل
• نشت ماده قابل‌اشتعال یا سمی
• شکست سامانه ایمنی
• failure تجهیز بحرانی
• ضعف در shutdown، isolation یا relief
• ترکیب چند انحراف کوچک که به یک رویداد بزرگ منتهی شده‌اند

در چنین حوادثی، صرفاً پرسیدن «چه کسی اشتباه کرد؟» یا «کدام دستورالعمل رعایت نشد؟» کافی نیست.

باید پرسید: سیستم چرا اجازه داد این سناریو شکل بگیرد؟

---

در HSE عمومی، تمرکز بررسی حادثه معمولاً روی چیست؟

در رویکرد عمومی HSE، بررسی حادثه اغلب بر این پایه‌ها می‌چرخد:

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

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

مثلاً اگر فردی در اثر بی‌نظمی در محل کار زمین بخورد، بررسی روی این موارد متمرکز می‌شود:

• چرا مسیر تمیز نبوده؟
• چرا علائم هشدار نبوده؟
• چرا فرد عجله کرده؟
• آیا آموزش داده شده بود؟
• مسئول اصلاح محیط چه کسی است؟

این مدل در جای خودش درست است؛

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

---

در تحلیل حوادث فرایندی، سؤال اصلی چیست؟

در تحلیل حوادث فرایندی، سؤال محوری این نیست که فقط «چه کسی چه کرد؟»

سؤال محوری این است که:

• چه سناریوی فرایندی رخ داده است؟
• چه چیزی باعث از دست رفتن مهار فرایند شده؟
• کدام deviationها قبل از حادثه شکل گرفته‌اند؟
• چه barrierهایی باید عمل می‌کردند و نکردند؟
• کدام فرض طراحی، عملیاتی یا نگهداری نادیده گرفته شده؟
• چه تغییر، ضعف یا degradation زمینه‌ساز حادثه بوده است؟
• چرا سازمان زودتر سیگنال‌ها را ندیده است؟

در اینجا تمرکز از «فرد» به «سیستم» منتقل می‌شود.

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

---

مهم‌ترین تفاوت: علت مستقیم در برابر علل سیستمی و فرایندی

در HSE عمومی، معمولاً پیدا کردن علت مستقیم و اقدام سریع اصلاحی اهمیت زیادی دارد.

مثلاً:

• فرد دستکش نداشته
• نردبان درست استفاده نشده
• محیط لغزنده بوده
• ابزار معیوب بوده

اما در حادثه فرایندی، علت مستقیم فقط لایه رویی ماجرا است.

مثلاً:

• اپراتور valve اشتباه را باز کرده
• interlock bypass شده
• تجهیز rupture کرده
• alarm نادیده گرفته شده

اگر تحلیل در همین سطح متوقف شود، مسئله اصلی پنهان می‌ماند.

باید رفت سراغ علل عمیق‌تر:

• چرا valveها به‌گونه‌ای بودند که اشتباه عملیاتی محتمل بود؟
• چرا bypass قابل‌قبول یا عادی شده بود؟
• چرا تجهیز به این وضعیت degradation رسیده بود؟
• چرا alarm management ضعیف بوده؟
• چرا PHA، MOC، MI یا رویه‌ها این سناریو را خوب پوشش نداده‌اند؟

این تفاوت بسیار کلیدی است.

در حوادث فرایندی، علت مستقیم تقریباً هیچ‌وقت برای یادگیری کافی نیست.

---

چرا تمرکز بیش از حد بر خطای انسانی در حوادث فرایندی خطرناک است؟

یکی از رایج‌ترین خطاها در سازمان‌ها این است که بعد از حادثه فرایندی، خیلی سریع به این نتیجه برسند:

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

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

• barrierهای فنی و سازمانی نادیده گرفته می‌شوند
• ضعف‌های طراحی یا یکپارچگی مکانیکی پنهان می‌مانند
• مشکل MOC، PSSR، PSI یا PHA دیده نمی‌شود
• اقدام اصلاحی به آموزش مجدد و تذکر تقلیل پیدا می‌کند
• سازمان توهم یادگیری پیدا می‌کند، بدون اینکه ریسک واقعی کم شده باشد

در حادثه فرایندی باید پرسید:

• اگر یک فرد اشتباه کرد، چرا سیستم اجازه داد آن اشتباه به حادثه بزرگ تبدیل شود؟
• چه safeguardهایی باید جلوی escalation را می‌گرفتند؟
• چرا recovery امکان‌پذیر نبوده؟
• چه ضعف مزمنی قبل از روز حادثه در سیستم وجود داشته است؟

کارشناس PSM باید از تحلیل‌هایی که خیلی زود روی «خطای انسانی» می‌نشینند، حساس شود.

---

در حادثه فرایندی، sequence یا توالی رویدادها چرا این‌قدر مهم است؟

در حوادث عمومی، گاهی علت و پیامد نسبتاً خطی و سریع دیده می‌شوند.

اما در حادثه فرایندی، فهم توالی رویدادها حیاتی است. چون معمولاً حادثه نتیجه یک زنجیره است:

• تغییر در شرایط بهره‌برداری
• ضعف یا failure یک تجهیز
• پاسخ ناکافی سامانه کنترلی
• آلارم یا نشانه‌ای که درست درک نشده
• تصمیم عملیاتی در زمان نامناسب
• نبود isolation مؤثر
• و در نهایت release، ignition یا escalation

اگر این توالی دقیق فهم نشود، تحلیل به نتیجه نادرست می‌رسد.

مثلاً ممکن است سازمان فقط روی لحظه release تمرکز کند، در حالی که ریشه حادثه روزها، هفته‌ها یا حتی ماه‌ها قبل شکل گرفته بوده است.

برای همین، تحلیل حوادث فرایندی نیازمند بازسازی دقیق این موارد است:

• وضعیت پایدار قبل از رویداد
• انحراف‌های اولیه
• پاسخ سامانه‌های کنترلی
• تصمیم‌های عملیاتی
• عملکرد لایه‌های حفاظتی
• و نقطه شکست نهایی

---

خروجی Incident Investigation در HSE عمومی معمولاً چیست، اما در PSM باید چه باشد؟

در HSE عمومی، خروجی بررسی حادثه معمولاً به این موارد ختم می‌شود:

• شرح رویداد
• علت مستقیم
• علت ریشه‌ای
• اقدام اصلاحی
• مسئول و مهلت اجرا

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

در PSM، خروجی تحلیل باید شامل این‌ها باشد:

• تعریف دقیق سناریوی فرایندی
• مشخص‌کردن loss of containment یا loss of control
• تحلیل barrierها و نقاط شکست آن‌ها
• شناسایی عوامل طراحی، عملیاتی، نگهداری و سازمانی
• بررسی نقش MOC، MI، PHA، PSSR، رویه‌ها و آموزش
• تعیین اقدام‌های اصلاحی که واقعاً ریسک سناریو را کم کنند
• استخراج درس‌آموخته قابل‌انتقال به واحدهای مشابه

یعنی خروجی نباید فقط «پرونده حادثه» باشد؛

باید مبنای تقویت سیستم کنترل ریسک فرایندی شود.

---

کارشناس PSM در تحلیل حادثه فرایندی دقیقاً چه نقشی دارد؟

کارشناس PSM صرفاً دبیر جلسه بررسی حادثه نیست.

نقش او بسیار تخصصی‌تر است:

• کمک به تعریف درست سناریوی فرایندی
• جلوگیری از سقوط تحلیل به سطح خطای فردی
• طرح سؤال درباره barrierها، MOC، MI، operating envelope و PSI
• اتصال حادثه به PHA و سناریوهای قبلی
• بررسی اینکه آیا سیگنال‌های هشدار زودتر وجود داشته‌اند یا نه
• کمک به ترجمه یافته‌ها به اقدام اصلاحی مؤثر
• اطمینان از اینکه درس‌آموخته فقط در سطح همان رویداد نماند

اگر این نقش خوب ایفا نشود، تحلیل حادثه ممکن است کامل به نظر برسد، اما از نظر PSM ناقص باشد.

---

از کجا بفهمیم یک تحلیل حادثه فرایندی هنوز سطحی است؟

چند نشانه هشداردهنده وجود دارد:

• علت اصلی خیلی زود «خطای انسانی» اعلام می‌شود
• درباره barrierهای ازکارافتاده بحث کمی می‌شود
• نقش MOC، MI، PHA یا PSSR اصلاً بررسی نمی‌شود
• توالی رویدادها دقیق بازسازی نشده
• داده‌های فرایندی، trendها یا وضعیت تجهیز قبل از حادثه بررسی نشده
• اقدام اصلاحی‌ها بیشتر آموزشی و انضباطی هستند
• مشابهت با near missها یا رویدادهای قبلی بررسی نشده
• درس‌آموخته فقط در همان واحد می‌ماند و تعمیم داده نمی‌شود

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

---

تفاوت در نوع اقدام اصلاحی هم بسیار مهم است

در HSE عمومی، اقدام‌های اصلاحی زیاد بر این موارد متمرکز می‌شوند:

• آموزش مجدد
• تذکر
• نصب تابلو
• اصلاح رفتار
• تغییر چیدمان محیط
• نظارت بیشتر

اما در حادثه فرایندی، اقدام اصلاحی مؤثر ممکن است این‌ها باشد:

• بازنگری در تحلیل مخاطرات فرایند
• اصلاح منطق کنترلی یا alarm management
• حذف bypassهای مزمن
• بازبینی integrity تجهیز یا برنامه بازرسی
• اصلاح رویه start-up یا shutdown
• تقویت isolation، relief یا detection
• اصلاح MOC و PSSR
• بازنگری در operating limitها
• تغییر در طراحی یا safeguard

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

---

چرا near missهای فرایندی باید متفاوت تحلیل شوند؟

در HSE عمومی، near miss گاهی به‌عنوان یک رویداد کم‌اهمیت‌تر دیده می‌شود.

اما در PSM، یک near miss فرایندی می‌تواند ارزش بسیار بالایی داشته باشد، چون:

• barrierها تا آستانه شکست رفته‌اند
• release ممکن بوده رخ دهد اما اتفاقی نداده
• نشانه‌ای از ضعف سیستم قبل از حادثه بزرگ دیده شده
• سازمان فرصت یادگیری بدون پرداخت هزینه فاجعه را داشته است

برای همین، کارشناس PSM باید near miss فرایندی را تقریباً با همان جدیت یک حادثه بزرگ ببیند، اگر پتانسیل سناریوی آن بالا بوده است.

---

جمع‌بندی

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

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

---

تمرین و تکلیف پیشنهادی

تمرین 1: یک حادثه را با دو عینک تحلیل کنید

یک رویداد واقعی یا فرضی را انتخاب کنید؛ مثلاً نشت از یک خط فرایندی.

ابتدا آن را با نگاه HSE عمومی تحلیل کنید:

• چه کسی درگیر بود؟
• چه رفتار یا شرایط ناایمنی وجود داشت؟
• اقدام اصلاحی چیست؟

سپس همان رویداد را با نگاه PSM تحلیل کنید:

• سناریوی فرایندی چه بود؟
• کدام barrierها شکست خوردند؟
• نقش MOC، MI، PHA یا رویه‌ها چه بود؟
• ریشه سیستمی حادثه چه بود؟

در پایان، تفاوت دو تحلیل را در یک جدول بنویسید.

---

تمرین 2: فهرست علل سطحی و علل سیستمی بسازید

برای 5 حادثه یا near miss گذشته، دو ستون تهیه کنید:

• علل سطحی
• علل سیستمی و فرایندی

هدف این تمرین این است که یاد بگیرید از پاسخ‌های سریع عبور کنید و به ساختارهای عمیق‌تر برسید.

---

تمرین 3: نقشه barrierها را برای یک حادثه رسم کنید

یک حادثه یا near miss فرایندی را انتخاب کنید و بنویسید:

• چه barrierهای پیشگیرانه‌ای باید عمل می‌کردند؟
• چه barrierهای کنترلی باید شدت حادثه را کم می‌کردند؟
• کدام barrierها ضعیف، غیرفعال یا نامؤثر بوده‌اند؟

این تمرین کمک می‌کند تحلیل شما از «علت حادثه» به «شکست لایه‌های حفاظتی» ارتقا پیدا کند.

---

تمرین 4: اقدام‌های اصلاحی را بازنویسی کنید

یک گزارش حادثه قدیمی را بردارید که اقدام‌های اصلاحی آن بیشتر آموزشی یا انضباطی بوده‌اند.

حالا آن‌ها را با منطق PSM بازنویسی کنید:

• چه اقدام فنی لازم بوده؟
• چه بازنگری فرایندی لازم بوده؟
• چه تغییر سیستمی باید انجام می‌شده؟

---

تمرین 5: یک اسلاید مدیریتی طراحی کنید

یک اسلاید یک‌صفحه‌ای آماده کنید با این 3 بخش:

• 5 تفاوت کلیدی بین Incident Investigation عمومی و تحلیل حادثه فرایندی
• 3 نشانه اینکه سازمان شما هنوز حادثه فرایندی را سطحی تحلیل می‌کند
• 3 اقدام برای ارتقای کیفیت تحلیل حوادث فرایندی