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

خلاصه مقاله

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

واقعیت این است که کارشناس HSE سایت به روشی نیاز دارد که هم ساده باشد، هم ساختار داشته باشد، هم بشود با آن در شرایط واقعی سایت کار کرد، و هم خروجی آن برای supervisor، maintenance، operations و مدیریت قابل فهم باشد. اینجا دقیقاً همان جایی است که ابزارهایی مثل 5Why، Incident Tree و TapRooT در سطح پایه ارزش پیدا می‌کنند. این‌ها اگر درست استفاده شوند، کمک می‌کنند حادثه را از سطح «چه کسی اشتباه کرد» به سطح «چه چیزی در سیستم، شرایط و کنترل‌ها ضعیف بود» منتقل کنیم.

چرا بسیاری از تحلیل‌های حادثه در سایت ضعیف می‌شوند؟

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

اشتباه دوم این است که تیم بین «عامل فوری» و «علت ریشه‌ای» تفاوت نمی‌گذارد. مثلاً اگر فرد دستش بین دو قطعه گیر کرده، می‌نویسند «بی‌دقتی فرد». این فقط توصیف سطحی رفتار است، نه تحلیل. سؤال حرفه‌ای این است که چرا شرایطی وجود داشته که فرد در line of fire قرار گرفته؟ چرا طراحی کار، روش اجرا، supervision، isolation، guarding یا planning جلوی این وضعیت را نگرفته است؟

قبل از انتخاب ابزار، اول این سه چیز باید روشن شوند

قبل از اینکه تصمیم بگیرید 5Why استفاده کنید یا Tree یا TapRooT پایه، باید مطمئن شوید سه خروجی اولیه را دارید. اول، شرح دقیق و بی‌طرفانه رویداد. دوم، timeline یا همان توالی رخدادها. سوم، وضعیت barrierها یا کنترل‌هایی که باید مانع وقوع می‌شدند. بدون این سه مورد، هر ابزار تحلیلی خیلی زود به حدس و برداشت شخصی آلوده می‌شود.

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

روش اول: 5Why؛ ساده، سریع و مفید اگر درست استفاده شود

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

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

در این مثال، اگر خیلی سریع می‌نوشتیم «عدم دقت نفرات در بررسی line»، تحلیل متوقف می‌شد. اما 5Why کمک می‌کند ببینیم مسئله فقط رفتار فردی نیست و احتمالاً یک ضعف ساختاری در work control و handover وجود دارد.

روش دوم: Tree؛ وقتی باید زنجیره رویداد را ببینید

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

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

شما لازم نیست Tree پیچیده نرم‌افزاری بکشید. حتی روی تخته یا کاغذ هم می‌توان این ساختار را ساخت. نقطه مهم این است که شاخه‌ها بر پایه شواهد باشند، نه ذهنیات. هر شاخه باید به سؤال «از کجا می‌دانیم؟» پاسخ داشته باشد.

روش سوم: TapRooT سطح پایه؛ نگاه دسته‌بندی‌شده به عوامل زمینه‌ای

TapRooT در نسخه کامل خود روش عمیق‌تری است، اما برای کارشناس سایت، حتی استفاده سطح پایه از منطق آن هم بسیار ارزشمند است. ایده اصلی این است که در تحلیل، فقط روی آنچه در لحظه حادثه دیده شده متمرکز نمانیم و به دسته‌های زمینه‌ای هم نگاه کنیم؛ مثل communication، training، procedure، supervision، planning، human factors، equipment condition و work direction.

در عمل، استفاده پایه از TapRooT یعنی پس از روشن شدن timeline و عوامل فوری، از خود بپرسید این رویداد در کدام دسته‌های سیستمی ریشه دارد. آیا نفر اطلاعات درست نداشته؟ آیا دستورالعمل مبهم بوده؟ آیا ابزار یا تجهیز مناسب نبوده؟ آیا supervision ضعیف بوده؟ آیا طراحی کار یا برنامه‌ریزی ایراد داشته؟ این نگاه باعث می‌شود تحلیل از سطح حادثه عبور کند و به زبان ضعف‌های سازمانی نزدیک شود.

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

کدام روش را چه زمانی استفاده کنیم؟

انتخاب ابزار باید متناسب با پیچیدگی رویداد باشد، نه بر اساس سلیقه یا مد روز. برای یک near miss ساده یا incident محدود که توالی آن روشن است، 5Why معمولاً کافی است. برای رویدادهایی که چند مرحله، چند تصمیم یا چند تیم در آن نقش داشته‌اند، Tree بهتر جواب می‌دهد. اگر احساس می‌کنید حتی بعد از شناخت زنجیره رویداد، هنوز نیاز دارید به لایه‌های سازمانی‌تر نگاه کنید، منطق TapRooT پایه کمک می‌کند.

سناریوی عملی: سقوط یک قطعه از ارتفاع بدون آسیب

فرض کنید هنگام کار در ارتفاع، یک قطعه یا ابزار کوچک سقوط کرده اما به کسی برخورد نکرده است. اگر این رویداد فقط با برچسب «near miss» بسته شود، یادگیری محدودی ایجاد می‌کند. اما با یک تحلیل ساده و درست می‌توان فهمید آیا این فقط یک خطای لحظه‌ای بوده یا نشانه ضعف در dropped object control است.

با 5Why ممکن است به این برسید که ابزار tether نشده بود، چون در setup کار لحاظ نشده بود، چون pre-job review روی dropped object risk ضعیف بوده است. با Tree می‌توانید ببینید قبل از سقوط چه شرایطی وجود داشته؛ مثلاً ابزار در موقعیت ناپایدار بوده، ناحیه زیر کار cordon نشده، و نظارت حین کار هم محدود بوده است. با TapRooT پایه هم می‌توانید عوامل زمینه‌ای را دسته‌بندی کنید: ضعف planning، ضعف procedure، ضعف field supervision و نبود کنترل کافی روی tool retention.

خروجی حرفه‌ای در اینجا دیگر «تذکر به نفرات» نیست. خروجی می‌تواند بازنگری pre-job checklist، کنترل dropped object در planning کار در ارتفاع، الزام بررسی tethering پیش از شروع و پایش میدانی هدفمند روی این نوع کارها باشد.

اشتباهات رایج هنگام استفاده از این روش‌ها

اولین اشتباه این است که تیم ابزار را جای تحلیل می‌گذارد. یعنی فرم 5Why پر می‌شود، Tree کشیده می‌شود یا چند دسته TapRooT انتخاب می‌شود، اما هنوز فهم واقعی از رویداد شکل نگرفته است. ابزار فقط وسیله است؛ اگر شواهد ضعیف باشند یا گفت‌وگوها سطحی باشند، خروجی هم سطحی خواهد بود.

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

یک قالب ساده برای تحلیل حادثه در سایت

این قالب برای Excel، Word یا حتی یک فرم داخلی ساده هم قابل اجراست. مهم این نیست که ظاهر آن چقدر حرفه‌ای باشد؛ مهم این است که فکر تحلیلی پشت آن منظم و قابل دفاع باشد.

نمونه گفت‌وگوی حرفه‌ای

سرپرست: علت حادثه مشخص است، اپراتور عجله کرده بود. چرا وقت بگذاریم؟

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

سرپرست: یعنی لازم است تحلیل را پیچیده کنیم؟

کارشناس HSE: نه. لازم است تحلیل را دقیق کنیم. برای این مورد با یک 5Why خوب و یک نگاه به barrierها می‌توانیم به اقدام بهتری برسیم تا فقط تذکر دادن.

چک‌لیست کاربردی برای کارشناس HSE

جمع‌بندی

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

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