Tìm nguyên nhân, không tìm lí do
Hành động khắc phục là một trong những yêu cầu quan trọng của bất cứ tiêu chuẩn hệ thống quản lí nào. Hành động khắc phục có hiệu lực đòi hỏi người thực hiện phải tìm được nguyên nhân gốc rễ của vấn đề. Tuy nhiên trên thực tế hầu hết báo cáo hành động khắc phục không đi đến NGUYÊN NHÂN gốc rễ mà kết thúc ở một LÝ DO hợp lí. Giống như khi bị sếp hỏi “Tại sao đi làm muộn”, bạn có thể liệt kê một danh sách các lí do hợp lí để trả lời dần cho các lần bị hỏi chẳng hạn như hỏng xe, tắc đường, con ốm, trời mưa… trong khi nguyên nhân gốc rễ có thể là bạn chẳng có hứng thú đến công ty làm việc nữa. Không nhận biết được nguyên nhân gốc rễ không thể ngăn chặn hiệu quả vấn đề, mọi giải pháp đều mang tính chữa cháy và vấn đề sẽ tiếp tục phát sinh.
Làm thế nào để biết nguyên nhân gốc
Nguyên nhân của vấn đề có thể được coi là nguyên nhân gốc nếu nó thỏa mãn được 4 tính chất bao gồm: thực tiễn, logic, hệ thống và rõ ràng.
Tính thực tiễn
Khi có một vấn đề, chúng ta có thể dễ dàng liệt kê hàng loạt lí do giải thích cho vấn đề phát sinh. Biểu đồ xương cá (biểu đồ Ishikawa) là một dạng công cụ giúp chúng ta làm việc này. Tuy nhiên, nếu quá trình phân tích nguyên nhân dừng ở đây chúng ta thường có xu hướng lựa chọn một nguyên nhân nào đó dễ xử lí trong biểu đồ này để làm nguyên nhân gốc trong khi đó nó chỉ là nguyên nhân tiềm ẩn hay giả định thay vì nguyên nhân thực tế. Nguyên nhân chỉ được coi là thực tế nếu có trả lời được câu hỏi cái gì xảy ra (What), xảy ra ở đâu (Where), xảy ra khi nào (When) và xảy ra với ai (Who).
Các nguyên tắc dưới đây là công cụ hữu ích giúp tìm kiếm câu trả lời cho các câu hỏi này:
- Nguyên tắc GO & SEE hay TAM HIỆN (Hiện trường – Hiện vật – Hiện trạng)
Người Nhật thường có nói “Câu trả lời không có ở trong máy tính”. Để biết được cái gì xảy ra, xảy ra khi nào, ở đâu và với ai chúng ta phải tìm đến hiện trường của vấn đề để xác định ĐIỂM VẤN ĐỀ.
- Quyết định dựa trên dữ liệu
Có những vấn đề phát sinh tức thời có những vấn đề phát sinh dần dần cho đến khi phát hiện ra. Nhận biết được quá trình này có vai trò quan trọng trong việc phân tích nguyên nhân gốc. Sử dụng hình ảnh hay các dạng biểu đồ ví dụ Histogram, Control Chart là một gợi ý.
- IS – IS NOT
Chúng ta thường có thiên hướng đi về phía những gì đã biêt. Tuy nhiên điều đã biết chưa chắc đã là nguyên nhân gốc. Việc kiểm tra lại các giả định bằng trả lời các câu hỏi Is – Is Not sẽ giúp loại bỏ các giả thuyết không chắc chắn.
Tính logic
Khi cố gắng kết nối một lí do giả định nhưng không thực tế đối với vấn đề đã phát sinh, chúng ta thường không đạt được tính logic trong trả lời câu hỏi tại sao vấn đề phát sinh. Nếu coi vấn đề là thành Rome và nguyên nhân giả định của vấn đề là điểm xuất phát, câu nói “Mọi con đường đều dẫn đến thành Rome” không đúng trong trường hợp này.
Để đảm bảo tính logic của nguyên nhân gốc rễ, chúng ta phải bắt đầu từ thực tế vấn đề và lần lượt đi qua các câu hỏi WHY cho đến khi thấy được nguyên nhân gốc rễ. Cách tiếp cận này thường được biết đến với tên gọi 5 WHY hay 5 TẠI SAO.
Tính hệ thống
Khi được yêu cầu phân tích 5 WHY khi truy tìm nguyên nhân gốc, nhiều người đặt câu hỏi có bắt buộc phải trả lời câu hỏi này đủ 5 lần. Đây là vấn đề được quan tâm vì đa phần chỉ trả lời được 1 hoặc 2 lần đã không thể hỏi được tiếp. Câu trả lời là 5 WHY chỉ mang ý nghĩa tượng trưng chứ không bắt buộc phải trả lời câu hỏi này đủ 5 lần mặc dù càng trả lời nhiều lần càng đến gần nguyên nhân gốc rễ.
Như vậy 5 WHY chỉ là một phương tiện, không phải là cơ sở để xác định chúng ta tìm được nguyên nhân gốc. Bạn chỉ có thể chắc rằng mình đã tìm đến nguyên nhân gốc (không quan trọng bao nhiêu WHY) nếu bạn lỗ hổng trong trong hệ thống hay nói cách khác nguyên nhân có tính hệ thống. Đối với tiêu chuẩn IATF 16949, nếu bạn tìm được nội dung có thể cập nhật vào PFMEA và Control Plan tức là nguyên nhân tìm ra đã đạt được tính hệ thống.
Tính rõ ràng
Cho dù nguyên nhân của bạn có tính thực tiễn, logic và hệ thống nhưng nếu không được giải thích một cách rõ ràng, nguyên nhân đó khó thuyết phục được người phê duyệt hành động khắc phục. Nội dung này liên quan đến việc trả lời câu hỏi vấn đề đã có thể xảy ra như thế nào (HOW). Kiểm chứng nguyên nhân hay kiểm chứng điều kiện gây ra lỗi và mô phỏng quá trình lỗi được hình thành là một trong những hành động cần thực hiện để đảm bảo tính rõ ràng của nguyên nhân gốc.
Có thể bạn quan tâm
HOW TO MAKE A MEETING MORE EFFECTIVE
LÀM THẾ NÀO ĐỂ HỌP HÀNH HIỆU QUẢ Một điều tra của Atlassian (công ty...
CONFORMITY or NON-CONFORMITY
Trong các cuộc đánh giá chứng nhận ISO 9001 khi nó mới du nhập vào...
COMMON ERRORS IN PFMEA
SAI LỖI ĐIỂN HÌNH TRONG PFMEA PFMEA là một công cụ mang lại nhiều lợi...
PREVENTIVE vs PREDICTIVE MAINTENANCE
Bảo dưỡng phòng ngừa (Preventive Maintenance) Trước khi khái niệm về bảo dưỡng dự báo...
FIND THE ROOT CAUSE, NOT THE REASON!
Tìm nguyên nhân, không tìm lí do Hành động khắc phục là một trong những...
SPECIAL CAUSE vs COMMON CAUSE
NGUYÊN NHÂN ĐẶC BIỆT vs NGUYÊN NHÂN HỆ THỐNG Ba chuyện đời thường Khi con...
CLIMATE CHANGE IN ISO 9001
BIẾN ĐỔI KHÍ HẬU TRONG ISO 9001:2015 Biến đổi khí hậu trong ISO 9001 Ngày...
Stand-Alone Control Plan
SỔ TAY CONTROL PLAN Tách ra không phải để đứng một mình Control Plan (CP)...