مدیریت اقدامات اصلاحی و پیشگیرانه (CAPA) در HSE چیست؟

مقدمه

یکی از مشکلات رایج در سیستم‌های HSE این است که مشکلات شناسایی می‌شوند، گزارش‌ها نوشته می‌شوند و اقدامات اصلاحی نیز در سیستم ثبت می‌شوند؛ اما چند ماه بعد همان مشکل دوباره ظاهر می‌شود.

برای مثال:

در بازرسی مشخص می‌شود مسیر خروج اضطراری با پالت مسدود شده است.

پالت جابه‌جا می‌شود و Action بسته می‌شود.

یک ماه بعد دوباره همان مسیر مسدود است.

سؤال مهم اینجاست:

آیا مشکل واقعاً حل شده بود یا فقط نشانه آن را موقتاً برطرف کرده بودیم؟

مدیریت اقدامات اصلاحی و پیشگیرانه یا CAPA برای جلوگیری از چنین وضعیتی اهمیت دارد.

---

CAPA چیست؟

CAPA مخفف:

Corrective Action and Preventive Action

است.

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

در HSE، اقدامات می‌توانند از منابع مختلفی ایجاد شوند، مانند:

• حوادث

• Near Miss

• بازرسی‌ها

• ممیزی‌ها

• ارزیابی ریسک

• شکایات

• خرابی تجهیزات

• مانورهای اضطراری

• گزارش کارکنان

---

Correction چیست؟

Correction یعنی اصلاح مشکل موجود.

مثلاً:

یک کابل برق آسیب دیده است.

Correction:

کابل آسیب‌دیده تعویض شود.

این اقدام مشکل فعلی را برطرف می‌کند.

اما هنوز یک سؤال باقی است:

چرا کابل آسیب دیده بود؟

---

Corrective Action چیست؟

Corrective Action اقدامی است که برای حذف یا کنترل علت یک عدم انطباق یا مشکل رخ‌داده انجام می‌شود تا احتمال تکرار آن کاهش یابد.

مثلاً مشخص می‌شود کابل‌ها به دلیل عبور مداوم لیفتراک از روی آنها آسیب می‌بینند.

Corrective Action می‌تواند:

اصلاح مسیر کابل‌کشی و حفاظت مکانیکی مناسب از کابل‌ها

باشد.

حالا به جای تعویض مداوم کابل، علت اصلی هدف قرار گرفته است.

---

Preventive Action چیست؟

Preventive Action بر جلوگیری از ایجاد یک مشکل بالقوه تمرکز دارد.

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

قبل از وقوع مشکل می‌توان:

• مسیر کابل را تغییر داد.

• محافظ نصب کرد.

• روش اجرا را اصلاح کرد.

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

---

تفاوت سه مفهوم مهم

مفهوم	هدف
Correction	رفع مشکل فعلی
Corrective Action	جلوگیری از تکرار مشکل رخ‌داده
Preventive Action	جلوگیری از ایجاد مشکل بالقوه

در عمل ممکن است برای یک مسئله بیش از یکی از این اقدامات لازم باشد.

---

یک مثال ساده

فرض کنید روغن روی کف سالن ریخته است.

Correction

روغن را پاک می‌کنیم.

اما فردا دوباره روغن روی زمین است.

چرا؟

چون گیربکس دستگاه نشتی دارد.

Corrective Action

نشتی گیربکس تعمیر می‌شود.

اما اگر همین مدل گیربکس روی 20 دستگاه دیگر نصب باشد، می‌توانیم بررسی کنیم آیا آنها نیز در معرض مشکل مشابه هستند.

این بررسی گسترده‌تر می‌تواند جنبه پیشگیرانه داشته باشد.

---

چرا بعضی Actionها مؤثر نیستند؟

یکی از دلایل اصلی این است که سازمان سریعاً به سمت «راه‌حل» می‌رود بدون اینکه مشکل را درست تحلیل کند.

مثلاً:

حادثه رخ داد → آموزش مجدد کارکنان

اما شاید علت واقعی:

• طراحی نامناسب

• کمبود حفاظ

• فشار کاری

• روش اجرایی غیرواقعی

• خرابی تجهیز

بوده باشد.

در چنین شرایطی آموزش ممکن است تأثیر محدودی داشته باشد.

---

قبل از Action، مشکل را درست تعریف کنید

یک Problem Statement خوب باید مشخص و مبتنی بر واقعیت باشد.

مثلاً:

❌ «ایمنی دستگاه ضعیف است.»

این عبارت بسیار کلی است.

بهتر:

✅ «در بازرسی تاریخ X مشخص شد حفاظ بخش انتقال قدرت دستگاه M-04 در محل نصب نبود و بخش متحرک هنگام کار قابل دسترس بود.»

حالا مسئله مشخص است.

---

Containment یا کنترل فوری

برخی مشکلات نمی‌توانند تا پایان Root Cause Analysis منتظر بمانند.

اگر خطر فوری وجود دارد، ابتدا باید شرایط کنترل شود.

مثلاً:

• دستگاه متوقف شود.

• منطقه ایزوله شود.

• دسترسی محدود شود.

• تجهیز از سرویس خارج شود.

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

---

Root Cause Analysis

بعد از کنترل فوری، باید بررسی کنیم:

چرا مشکل ایجاد شد؟

برای مسائل ساده ممکن است چند سؤال «چرا» کافی باشد.

برای مسائل پیچیده‌تر می‌توان از ابزارهایی مانند:

• 5 Whys

• Fishbone Diagram

• Fault Tree

• Barrier Analysis

استفاده کرد.

روش انتخابی باید متناسب با پیچیدگی و اهمیت مسئله باشد.

---

مثال 5 Whys

مسئله:

حفاظ دستگاه برداشته شده بود.

چرا؟

اپراتور برای رفع گیرکردگی محصول آن را باز کرده بود.

چرا؟

رفع گیرکردگی بدون باز کردن حفاظ دشوار بود.

چرا؟

نقطه دسترسی مناسب برای رفع گیرکردگی وجود نداشت.

چرا؟

این سناریو در طراحی و ارزیابی ریسک به‌درستی بررسی نشده بود.

حالا می‌بینیم که اقدام:

«به اپراتور تذکر داده شود»

احتمالاً مشکل اصلی را حل نمی‌کند.

---

خطای انسانی همیشه Root Cause نیست

عبارت‌هایی مانند:

• بی‌احتیاطی

• عدم توجه

• خطای اپراتور

اغلب پایان تحلیل نیستند.

اگر فرد اشتباه کرده، سؤال بعدی این است:

چه شرایطی باعث شد این اشتباه امکان‌پذیر یا محتمل شود؟

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

• طراحی

• خستگی

• آموزش

• فشار زمانی

• رابط کاربری

• نظارت

• روش اجرایی

• محیط کار

---

انتخاب Corrective Action

بعد از شناسایی علت‌ها باید اقدام مناسب انتخاب شود.

در HSE بهتر است Hierarchy of Controls را در نظر بگیریم.

ترتیب کلی:

1. حذف

2. جایگزینی

3. کنترل مهندسی

4. کنترل اداری

5. PPE

هرچه بتوانیم به کنترل‌های بالاتر نزدیک شویم، وابستگی به رفتار فرد کاهش پیدا می‌کند.

---

مثال اقدام ضعیف و قوی

فرض کنید افراد مرتباً وارد منطقه حرکت لیفتراک می‌شوند.

اقدام ضعیف

❌ «به کارکنان گفته شود مراقب لیفتراک باشند.»

اقدام بهتر

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

کنترل دوم وابستگی کمتری به توجه دائمی افراد دارد.

---

SMART Action

یک اقدام خوب بهتر است تا حد امکان ویژگی‌های SMART داشته باشد:

Specific – مشخص
Measurable – قابل اندازه‌گیری
Achievable – قابل انجام
Relevant – مرتبط
Time-bound – دارای مهلت

---

Action مبهم

❌ «ایمنی انبار بهبود یابد.»

چه کسی؟ چگونه؟ تا چه زمانی؟

مشخص نیست.

---

Action مشخص‌تر

✅ «مسیر تردد عابر در انبار شماره 2 تا تاریخ تعیین‌شده توسط واحد مربوط با مانع فیزیکی از مسیر لیفتراک جدا و پس از تکمیل توسط HSE و عملیات بررسی شود.»

این Action قابل پیگیری‌تر است.

---

Action Owner

هر اقدام باید یک مالک مشخص داشته باشد.

مالک Action مسئول پیگیری آن تا تکمیل است.

عبارت‌هایی مانند:

همه واحدها

معمولاً انتخاب خوبی برای Owner نیستند.

وقتی همه مسئول باشند، ممکن است در عمل هیچ‌کس مسئولیت نهایی را بر عهده نگیرد.

---

Deadline

هر اقدام باید مهلت داشته باشد.

Deadline باید با توجه به:

• سطح ریسک

• پیچیدگی اقدام

• منابع موردنیاز

• کنترل‌های موقت

تعیین شود.

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

---

Actionهای Overdue

اقدامات معوق یکی از شاخص‌های مهم سلامت سیستم CAPA هستند.

باید بررسی شود:

• چند Action معوق داریم؟

• کدام‌ها High Risk هستند؟

• چرا تأخیر ایجاد شده است؟

• آیا کنترل موقت وجود دارد؟

• چه کسی باید موضوع را Escalate کند؟

---

Extension

گاهی واقعاً امکان تکمیل Action در Deadline وجود ندارد.

در این شرایط تمدید نباید صرفاً با تغییر تاریخ انجام شود.

بهتر است مشخص شود:

• چرا تمدید لازم است؟

• ریسک فعلی چیست؟

• چه کنترل موقتی وجود دارد؟

• تاریخ جدید چیست؟

• چه کسی تمدید را تأیید کرده است؟

---

Closure چیست؟

وقتی مسئول Action اعلام می‌کند:

«انجام شد»

هنوز الزاماً Action بسته نشده است.

باید Evidence وجود داشته باشد.

مثلاً:

• عکس

• گزارش تعمیر

• دستورالعمل بازنگری‌شده

• رکورد آموزش

• نتیجه تست

• گزارش بازرسی

---

Verification

Verification یعنی بررسی کنیم:

آیا کاری که قرار بود انجام شود، واقعاً انجام شده است؟

مثلاً Action می‌گفت حفاظ نصب شود.

Verification بررسی می‌کند:

آیا حفاظ نصب شده است؟

---

Effectiveness Review

اما سؤال مهم‌تر:

آیا اقدام واقعاً مشکل را حل کرده است؟

این همان بررسی اثربخشی است.

ممکن است حفاظ نصب شده باشد اما کارکنان بتوانند آن را به‌راحتی دور بزنند.

پس Action اجرا شده، اما اثربخش نیست.

---

Verification و Effectiveness یکسان نیستند

Verification

«آیا Action انجام شد؟»

Effectiveness

«آیا Action نتیجه موردنظر را ایجاد کرد؟»

این تفاوت یکی از مهم‌ترین مفاهیم CAPA است.

---

چگونه اثربخشی را بررسی کنیم؟

بسته به Action می‌توان:

• بازدید مجدد انجام داد.

• داده‌ها را بررسی کرد.

• با کارکنان صحبت کرد.

• Repeat Finding را پایش کرد.

• عملکرد تجهیز را آزمایش کرد.

• روند Near Missها را بررسی کرد.

زمان بررسی نیز باید متناسب با نوع اقدام باشد.

---

Repeat Finding

اگر همان Finding دوباره ایجاد شود، باید CAPA قبلی بررسی شود.

سؤال‌ها:

• Root Cause اشتباه بود؟

• Action مناسب نبود؟

• Action کامل اجرا نشد؟

• تغییر دیگری باعث بازگشت مشکل شد؟

• اثربخشی به‌درستی بررسی نشده بود؟

تکرار Finding یک علامت مهم برای ضعف سیستم است.

---

CAPA Register

سازمان می‌تواند اقدامات را در یک CAPA Register مدیریت کند.

فیلدهای مفید می‌توانند شامل:

• شماره Action

• منبع

• شرح Finding

• سطح ریسک

• Root Cause

• Correction

• Corrective Action

• Owner

• Open Date

• Due Date

• Status

• Evidence

• Verification

• Effectiveness

• Closure Date

باشند.

---

اولویت‌بندی Actionها

همه اقدامات اهمیت یکسان ندارند.

بهتر است اولویت با توجه به ریسک تعیین شود.

مثلاً:

Critical / High

پیگیری فوری و Escalation مدیریت.

Medium

اقدام در بازه تعریف‌شده.

Low

برنامه‌ریزی و پیگیری عادی.

روش طبقه‌بندی باید با سیستم مدیریت ریسک سازمان هماهنگ باشد.

---

منبع Action را ثبت کنید

هر CAPA باید مشخص کند از کجا ایجاد شده است.

مثلاً:

• Audit

• Inspection

• Incident

• Near Miss

• Risk Assessment

• Management Review

• Employee Report

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

---

تحلیل داده‌های CAPA

با گذشت زمان می‌توان سؤالات مهمی مطرح کرد:

• کدام واحد بیشترین Action را دارد؟

• چه نوع Finding بیشتر تکرار می‌شود؟

• میانگین زمان Closure چقدر است؟

• چند درصد Actionها Overdue هستند؟

• کدام Root Causeها بیشتر دیده می‌شوند؟

• چند Action پس از Closure دوباره تکرار شده‌اند؟

این داده‌ها می‌توانند مشکلات سیستمی را آشکار کنند.

---

تعداد Action بیشتر الزاماً بهتر نیست

هدف CAPA تولید هزاران Action نیست.

اگر برای هر مشکل کوچک چندین Action ثبت شود، سیستم ممکن است اشباع شود و اقدامات مهم در میان آنها گم شوند.

تمرکز باید بر:

کیفیت + ریسک + اثربخشی

باشد.

---

نقش مدیریت

برخی اقدامات بدون حمایت مدیریت قابل اجرا نیستند.

مثلاً:

• تغییر طراحی

• خرید تجهیزات

• توقف فرایند

• افزایش نیروی انسانی

• اصلاح زیرساخت

بنابراین مدیریت باید وضعیت CAPAهای مهم و معوق را به‌صورت دوره‌ای بررسی کند.

---

نقش HSE

HSE نباید مالک همه Actionها باشد.

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

اگر مربوط به تولید است، مسئولیت باید در واحد عملیاتی قرار گیرد.

نقش HSE می‌تواند شامل:

• تسهیل

• پیگیری

• ارزیابی ریسک

• مشاوره

• Verification

باشد.

ایمنی مسئولیت یک واحد نیست؛ مسئولیت سازمان است.

---

اشتباهات رایج CAPA

۱. بستن مشکل با آموزش

بدون بررسی علت واقعی.

۲. Action بدون Owner

کسی مسئول نهایی نیست.

۳. Action بدون Deadline

اقدام ماه‌ها باز می‌ماند.

۴. تغییر Deadline بدون بررسی ریسک

مشکل فقط به آینده منتقل می‌شود.

۵. Closure بدون Evidence

فقط وضعیت نرم‌افزار تغییر می‌کند.

۶. Verification بدون Effectiveness

بررسی می‌کنیم کار انجام شده، اما نه اینکه مؤثر بوده است.

۷. نادیده گرفتن Repeat Finding

همان مشکل بارها تکرار می‌شود.

---

نمونه چرخه CAPA

Finding

حفاظ دستگاه وجود ندارد.

↓

Immediate Control

دستگاه از سرویس خارج می‌شود.

↓

Root Cause Analysis

طراحی دسترسی برای رفع گیرکردگی نامناسب است.

↓

Corrective Action

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

↓

Owner + Deadline

مسئول و زمان اجرا تعیین می‌شوند.

↓

Implementation

اصلاح اجرا می‌شود.

↓

Verification

نصب و اجرای تغییر تأیید می‌شود.

↓

Effectiveness Review

بررسی می‌شود آیا دسترسی به نقطه خطر حذف شده و مشکل تکرار نشده است.

↓

Closure

CAPA بسته می‌شود.

---

چک‌لیست CAPA مؤثر

• Finding به‌وضوح تعریف شده است.

• ریسک ارزیابی شده است.

• خطر فوری کنترل شده است.

• Root Cause در صورت نیاز بررسی شده است.

• Correction مشخص است.

• Corrective Action متناسب با علت است.

• Hierarchy of Controls در نظر گرفته شده است.

• Owner مشخص است.

• Deadline تعیین شده است.

• کنترل موقت در صورت نیاز وجود دارد.

• Evidence ثبت شده است.

• Verification انجام شده است.

• Effectiveness بررسی شده است.

• Repeat Finding پایش می‌شود.

• اقدامات معوق Escalate می‌شوند.

• Closure فقط پس از تکمیل واقعی انجام می‌شود.

---

جمع‌بندی

CAPA فقط یک لیست از Actionها نیست.

هدف واقعی آن ایجاد یک چرخه یادگیری است:

Problem → Immediate Control → Root Cause → Corrective Action → Implementation → Verification → Effectiveness → Closure

تفاوت یک سیستم ضعیف و یک سیستم قوی معمولاً در همین نقطه مشخص می‌شود.

سیستم ضعیف می‌پرسد:

«آیا Action بسته شد؟»

اما سیستم قوی می‌پرسد:

«آیا خطر واقعاً کاهش پیدا کرد و احتمال تکرار مشکل کمتر شد؟»