تجزیه و تحلیل مخاطرات مقدماتی (PHA)

تجزیه و تحلیل مخاطرات مقدماتی (PHA) یک تحلیل نیمه کمی است که برای شناسایی، در مراحل اولیه طراحی و تعریف یک سیستم، تمام خطرات بالقوه و رویدادهای خطرناکی که می توانند باعث حادثه شوند، کنترل های ریسک مورد نیاز و طبقه بندی وقایع خطرناک شناسایی شده بر اساس شدت شناسایی و اقدامات بعدی مربوطه آنها انجام می شود.

چه زمانی باید از PHA استفاده شود؟

PHA به عنوان یک مطالعه ریسک اولیه در مراحل اولیه یک پروژه مناسب است و از نتایج آن برای 1- مقایسه مفاهیم اصلی 2- تمرکز بر مسائل مهم ریسک، و 3- ورودی برای تجزیه و تحلیل بیشتر ریسک های دقیق استفاده می شود.

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

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

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

ساختارهای یک PHA 

مرحله 1 – پیش نیازهای PHA

اولین قدم در شروع توسعه PHA، ایجاد تیم PHA است، که معمولا متشکل از یک رهبر با مهارت و تجربه، فردی مسئول ثبت و تکمیل تحولات تجزیه و تحلیل گروه، و اعضای تیم، معمولاً یک گروه 2 تا 6 نفره است. افراد با آگاهی از سیستم مورد تجزیه و تحلیل، محیطی که در آن عمل می کند و فرآیندهایی که تحت تأثیر قرار خواهند گرفت.

جای تعجب نیست که تعداد اعضای تیم برای شرکت به پیچیدگی سیستم و همچنین به اهداف تجزیه و تحلیل بستگی دارد.

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

ارائه تعریف سیستم نیز باید در صورت امکان در سطح بلوک باشد و سیستم را به بخش هایی تقسیم کند که توسط تحلیلگران قابل مدیریت باشد.

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

نتایج PHA معمولا توسط کاربرگ PHA (یا یک برنامه رایانه ای) گزارش می شود. سپس، یک کاربرگ معمولی PHA نشان داده می شود. برخی از تحلیل‌ها ممکن است به ستون‌های دیگری نیاز داشته باشند، اما اینها رایج‌ترین ستون‌ها هستند.

مرحله 2 – شناسایی خطر

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

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

– برخورد دو قطار در حال کار

– برخورد با قطار، بخشی از قطار یا وسیله نقلیه ریلی دیگر

– برخورد قطار و وسیله نقلیه جاده ای

– برخورد قطار با عناصری غیر از قطار یا وسیله نقلیه

– برخورد قطار با موجود زنده (حیوان یا انسان)

– خروج قطار از ریل (که در اثر برخورد ایجاد نشده است)

– واژگونی قطار (غیر از برخورد)

– سقوط مردم

– تصادف در نتیجه گیر افتادن

– جراحت یا له شدن (به جز خروج از ریل، واژگونی، به دام افتادن)

– برق گرفتگی

– سوختگی (نه بر اثر برق گرفتگی)

– مسمومیت یک یا چند نفر

– خفگی یک یا چند نفر

– تجاوزات به محیط زیست، بلایای طبیعی،

– حمله به طیف الکترومغناطیسی

چند نکته برای شناسایی خطرات برای کسانی که قبلا PHA را انجام نداده اند:

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

همچنین نظر دهید که تکنیک “چه می شود اگر یا what if” (چه اتفاقی می افتد بله) نیز روش خوبی برای ایجاد تهدیدهایی است که بر سیستم تأثیر می گذارد.

مرحله 3 – تخمین عواقب و فراوانی

خطر مرتبط با یک رویداد خطرناک تابعی از فراوانی رویداد و شدت پیامدهای احتمالی آن است. برای تعیین خطر، باید فراوانی و شدت هر رویداد خطرناک را تخمین بزنیم.

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

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

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

مرحله 4 – طبقه بندی خطر و اقدامات پیگیری

ریسک به عنوان ترکیبی از یک رویداد / پیامد معین و شدت همان رویداد / پیامد بیان می شود. این اجازه می دهد تا رویدادها / پیامدها در یک ماتریس ریسک طبقه بندی شوند:

بنابراین، همانطور که مشاهده می شود، جدولی می سازیم که در آن هر یک از خطرات شناسایی شده را بر اساس فراوانی (ستون ها) و شدت (ردیف ها) قرار می دهیم. از اینجا به بعد، رنگ ها به تنهایی صحبت می کنند:

قرمز – “H”: خطر بالا، قابل قبول نیست. تجزیه و تحلیل بیشتر و مهمتر از همه، اقدامات باید روی سیستم انجام شود تا تخمین بهتری از ریسک بدست آید. اگر این تجزیه و تحلیل هنوز یک طراحی مجدد ریسک متوسط ​​یا غیرقابل قبول را نشان می دهد، باید تغییرات دیگری برای کاهش بحران ایجاد شود.

زرد – “M”: خطر ممکن است قابل قبول باشد، اما اگر به طور منطقی عملی باشد، طراحی مجدد یا تغییرات دیگر باید در نظر گرفته شود. برای به دست آوردن تخمین بهتری از ریسک باید تجزیه و تحلیل بیشتری انجام شود. هنگام ارزیابی نیاز به اقدام اصلاحی، تعداد رویدادها در این سطح ریسک باید در نظر گرفته شود.

سبز – “L”: خطر کم است و هیچ اقدام دیگری برای کاهش آن لازم نیست.

قرار گرفتن رنگ های قرمز / سبز / زرد در جدول به دلیل پیچیدگی آن چیزی نیست که بتوان از آن چشم پوشی کرد. با مکان یابی رنگ های سبز و زرد خطراتی را در نظر می گیریم یا می پذیریم و بنابراین ارزیابی آنها باید یک تحلیل عمیق باشد. در بسیاری از مواقع این مشتری ما (که سیستم را خریداری می کند) خواهد بود یا باید این جدول را برای همیشه یا حتی طراحی کند، معمولاً معیارها و پذیرش سیستماتیک خطرات را با سه روش شناخته شده ALARP، GAME یا MEM اعمال می کند.

نتیجه گیری

PHA یک فعالیت بسیار رایج در تجزیه و تحلیل ریسک و فرآیندهای مدیریت است. PHA امکان ارزیابی اولیه ریسک‌های پروژه را فراهم می‌کند و به عنوان ورودی برای یک فرآیند پیچیده‌تر و بادوام‌تر در کل چرخه عمر از نظر تجزیه و تحلیل تهدیدها عمل می‌کند.

بنابراین PHA به ما کمک می کند تا مطمئن شویم که سیستم از ابتدا ایمن است. در این راستا، مهم است که به یاد داشته باشید که تغییرات هزینه کمتری دارند و در مراحل اولیه طراحی ساده تر اجرا می شوند. بنابراین، با کاهش تعداد «غافلگیری ها» زمان طراحی را کاهش می دهیم.