Phân tích nguyên nhân gốc rễ (root cause analysis — RCA) là quá trình có phương pháp để tìm ra nguyên nhân sâu nhất mà nếu loại bỏ thì sự cố không tái diễn, thay vì chỉ xử lý triệu chứng. Ví dụ: máy dừng vì cầu chì cháy; thay cầu chì là xử lý triệu chứng; tìm ra cầu chì cháy vì trục thiếu dầu, thiếu dầu vì bơm dầu bị tắc do không có lưới lọc, rồi lắp lưới lọc và đưa vào lịch bảo trì, đó là xử lý gốc.
Công cụ phổ biến nhất là 5 Why (hỏi “tại sao” liên tiếp), nhưng 5 Why làm cẩu thả là nguồn gốc của rất nhiều kết luận sai kiểu “do công nhân bất cẩn”. Bài này trình bày cách làm RCA đúng: mô tả vấn đề, 5 Why có kiểm chứng, cây nguyên nhân cho sự cố nhiều nhánh, và các bẫy tư duy cần tránh.
Nguồn gốc của 5 Why và vì sao nó dễ bị dùng sai
Kỹ thuật hỏi “tại sao” lặp lại gắn với Sakichi Toyoda và được Taiichi Ohno phổ biến trong hệ thống sản xuất Toyota. Ví dụ cầu chì và bơm dầu ở trên phỏng theo chính ví dụ Ohno hay kể. Con số năm không phải định luật: có vấn đề ba lần “tại sao” đã tới gốc, có vấn đề cần bảy tám lần. Năm chỉ là lời nhắc đừng dừng ở câu trả lời đầu tiên.
Điểm mạnh của 5 Why là đơn giản, không cần thống kê, ai cũng học được trong một buổi. Điểm yếu cũng nằm ở đó. Alan Card, trong bài phân tích đăng trên BMJ Quality & Safety năm 2017, phê phán việc dùng 5 Why trong an toàn người bệnh: chuỗi một đường thẳng ép sự cố phức tạp thành một nguyên nhân duy nhất, kết quả phụ thuộc nhiều vào người hỏi, và hai nhóm khác nhau phân tích cùng sự cố có thể ra hai “gốc” khác nhau.
Phê bình này đúng với cách làm phổ biến, nhưng không có nghĩa là bỏ 5 Why. Kết luận thực tế là: 5 Why phù hợp cho vấn đề vận hành có phạm vi hẹp và cơ chế vật lý rõ, khi mỗi câu trả lời được kiểm chứng tại hiện trường. Với sự cố có nhiều yếu tố tương tác như tai nạn lao động nghiêm trọng, sự cố y khoa, lỗi hệ thống thông tin, cần công cụ phân nhánh như cây nguyên nhân hoặc phân tích theo mô hình hệ thống.
Bước 0: mô tả vấn đề trước khi hỏi “tại sao”
Phần lớn RCA thất bại ngay từ câu mô tả vấn đề. “Khách phàn nàn chất lượng kém” không phân tích được; “Lô 2.000 hộp giao ngày 12 có 60 hộp móp góc trên bên phải, phát hiện tại kho khách” thì phân tích được. Trước khi hỏi tại sao, hãy làm đủ các bước sau.
- Đến hiện trường và nhìn vật thật. Xem sản phẩm lỗi, máy, hồ sơ, thay vì nghe kể lại trong phòng họp. Nhiều giả thuyết bị loại ngay khi nhìn tận mắt.
- Mô tả bằng sự kiện có đo đếm. Cái gì, ở đâu (vị trí trên sản phẩm, trên dây chuyền), khi nào (ca, giờ, lô), bao nhiêu (số lượng, tỷ lệ, xu hướng), phát hiện như thế nào.
- Dùng bảng “là / không là” (is / is not). Kỹ thuật của Charles Kepner và Benjamin Tregoe trong The Rational Manager (1965): lỗi xảy ra ở máy A nhưng không ở máy B cùng loại; ở ca đêm nhưng không ở ca ngày; từ tuần 32 nhưng không trước đó. Điều gì khác biệt giữa hai cột thường chỉ thẳng tới nguyên nhân.
- Ghi lại điều gì đã thay đổi. Nguyên liệu mới, người mới, sửa chữa máy, đổi nhà cung cấp, đổi thông số quanh thời điểm vấn đề bắt đầu.
- Khoanh vùng và ngăn chặn tạm thời. Cách ly hàng nghi ngờ, kiểm tra 100% tạm thời nếu cần, để khách hàng được bảo vệ trong lúc phân tích. Ngăn chặn không phải khắc phục.
Cách làm 5 Why đúng: mỗi tầng phải kiểm chứng được
Quy tắc quan trọng nhất: mỗi câu trả lời phải là sự kiện đã kiểm chứng, không phải phỏng đoán hợp lý. Khi trả lời “tại sao trục thiếu dầu” bằng “có lẽ bơm yếu”, phải dừng lại để đo áp suất bơm, tháo kiểm tra, rồi mới viết tầng tiếp theo. Một chuỗi 5 Why dựng trên phỏng đoán chỉ là câu chuyện mạch lạc, không phải phân tích.
Quy tắc thứ hai: kiểm tra ngược bằng “vì vậy”. Đọc từ dưới lên: “không có lưới lọc, vì vậy bơm tắc; bơm tắc, vì vậy trục thiếu dầu; trục thiếu dầu, vì vậy quá tải; quá tải, vì vậy cầu chì cháy”. Nếu một mắt xích đọc ngược không thuyết phục, chuỗi bị đứt.
Quy tắc thứ ba: tách hai câu hỏi. Một là vì sao lỗi xảy ra; hai là vì sao lỗi lọt qua mà không bị phát hiện. Phương pháp 8D gọi đây là điểm phát sinh và điểm thoát. Một lô hàng lỗi tới tay khách luôn có hai gốc: gốc tạo lỗi và gốc của hệ thống kiểm soát bỏ sót. Sửa một bỏ một là chưa xong.
Quy tắc thứ tư: dừng ở tầng mình có thể hành động và hành động đó ngăn được tái diễn. Hỏi tiếp tới “vì thị trường cạnh tranh nên phải cắt chi phí” là quá xa, không ai trong nhóm hành động được. Dừng ở “không có lưới lọc” là quá gần nếu không hỏi thêm “vì sao thiết kế và quy trình bảo trì không yêu cầu lưới lọc”, vì máy khác cùng loại có thể đang chịu cùng rủi ro. Nguyên nhân gốc tốt thường nằm ở hệ thống: thiết kế, quy trình, tiêu chuẩn, đào tạo, cách ra quyết định.
Quy tắc thứ năm: “lỗi con người” không bao giờ là gốc. Nếu câu trả lời là “công nhân quên”, hỏi tiếp: vì sao hệ thống cho phép quên mà không phát hiện? Thao tác có quá nhiều bước phải nhớ không? Có thiết bị chống sai không? Ca có bị dồn việc không? Hành động “nhắc nhở, kỷ luật” gần như không bao giờ ngăn được tái diễn.
Khi sự cố có nhiều nhánh: cây nguyên nhân và phân tích cây lỗi
Sự cố thật thường cần nhiều điều kiện cùng xảy ra. Một vụ cháy kho cần nguồn nhiệt, vật liệu dễ cháy, hệ thống báo cháy không hoạt động, và người trực không kịp phản ứng. Ép thành một chuỗi 5 Why sẽ bỏ sót ba trong bốn nhánh. Cây nguyên nhân giải quyết điều này: đặt sự kiện ở gốc cây, mỗi tầng hỏi “điều gì phải đúng để tầng trên xảy ra”, và cho phép nhiều nhánh song song.
Phân tích cây lỗi (fault tree analysis — FTA) là phiên bản chặt chẽ hơn, được phát triển ở Bell Labs đầu thập niên 1960 cho hệ thống điều khiển tên lửa của Không quân Hoa Kỳ, sau đó dùng rộng rãi trong hàng không, hạt nhân và hoá chất. FTA dùng cổng logic: cổng “VÀ” khi sự kiện trên cần tất cả nhánh dưới cùng xảy ra, cổng “HOẶC” khi chỉ cần một nhánh. Khi có xác suất cho từng sự kiện cơ sở, có thể tính xác suất sự kiện đỉnh và tìm tổ hợp tối thiểu gây sự cố.
Với doanh nghiệp, giá trị thực hành lớn nhất của cây nguyên nhân là chỉ ra chỗ nào có cổng VÀ thì chỉ cần chặn một nhánh là đủ ngăn sự cố, còn chỗ có cổng HOẶC thì phải chặn tất cả. Điều này giúp chọn hành động khắc phục rẻ mà hiệu quả.
Một cách nhìn bổ sung là mô hình “pho mát Thuỵ Sĩ” của James Reason (1990): mỗi lớp phòng vệ như thiết kế, quy trình, đào tạo, giám sát đều có lỗ, sự cố xảy ra khi các lỗ thẳng hàng. Reason phân biệt lỗi chủ động của người tuyến đầu với điều kiện tiềm ẩn do quyết định quản lý tạo ra từ trước. RCA tốt tìm cả hai, và đặc biệt chú ý điều kiện tiềm ẩn vì chúng tạo ra nhiều sự cố khác nhau trong tương lai.
Chọn công cụ RCA theo loại vấn đề
Không có công cụ tốt nhất cho mọi tình huống. Bảng dưới gợi ý chọn theo độ phức tạp và mức độ hậu quả.
| Loại vấn đề | Công cụ phù hợp | Ai tham gia | Kết quả cần có |
|---|---|---|---|
| Lỗi vận hành nhỏ, cơ chế rõ, một máy hoặc một công đoạn | 5 Why có kiểm chứng tại hiện trường | Tổ trưởng, người vận hành, kỹ thuật | Hành động sửa trong vài ngày, cập nhật chuẩn |
| Lỗi lặp lại, chưa rõ biến nào ảnh hưởng | Biểu đồ xương cá để liệt kê, rồi kiểm chứng bằng dữ liệu | Nhóm liên chức năng | Danh sách nguyên nhân được xác nhận bằng số liệu |
| Khiếu nại khách hàng chính thức | 8D: là / không là, 5 Why cho điểm phát sinh và điểm thoát | Nhóm 8D có chủ trì | Báo cáo cho khách, hành động vĩnh viễn được xác nhận |
| Sự cố nghiêm trọng, nhiều yếu tố | Cây nguyên nhân hoặc FTA, dòng thời gian sự kiện | Nhóm điều tra độc lập với khu vực xảy ra | Điều kiện tiềm ẩn ở cấp hệ thống và quản lý |
| Biến động thống kê phức tạp | DMAIC với phân tích dữ liệu, thiết kế thí nghiệm | Chuyên gia thống kê cùng chủ quá trình | Mô hình quan hệ biến đầu vào – đầu ra |
Một sai lầm hay gặp là dùng biểu đồ xương cá rồi dừng ở đó. Xương cá chỉ là công cụ liệt kê giả thuyết theo nhóm (con người, máy, vật liệu, phương pháp, đo lường, môi trường); sau đó vẫn phải kiểm chứng từng giả thuyết bằng dữ liệu hoặc thí nghiệm trước khi gọi là nguyên nhân.
Các bẫy tư duy khiến RCA đi sai hướng
Ngay cả nhóm có kinh nghiệm cũng hay rơi vào các bẫy dưới đây. Người điều phối nên chủ động kiểm tra từng bẫy trước khi chốt kết luận.
- Thiên kiến xác nhận: nhóm có sẵn giả thuyết (thường là “nhà cung cấp kém”) và chỉ tìm bằng chứng ủng hộ. Cách chống: bắt buộc ghi ít nhất một giả thuyết cạnh tranh và nêu dữ liệu nào sẽ bác bỏ nó.
- Thiên kiến kết quả và hồi tưởng: biết sự cố đã xảy ra, ai cũng thấy dấu hiệu “rõ ràng”. Câu hỏi đúng là với thông tin có lúc đó, người làm có hợp lý không.
- Dừng ở nguyên nhân thuận tiện: chọn nguyên nhân mà hành động khắc phục dễ hoặc rẻ, thay vì nguyên nhân thật.
- Thứ bậc trong phòng họp: khi giám đốc nói giả thuyết trước, nhóm hiếm khi phản bác. Người cấp cao nên nói sau cùng.
- Nhầm tương quan với nhân quả: lỗi tăng cùng lúc với nhân viên mới vào chưa chắc do nhân viên mới; có thể cùng lúc đổi nguyên liệu.
- Không kiểm chứng hiệu quả: đóng hồ sơ khi hành động đã làm, thay vì khi dữ liệu sau vài tuần hoặc vài lô chứng minh vấn đề không quay lại. Cách kiểm chứng mạnh nhất là bật và tắt nguyên nhân: tạo lại điều kiện thì lỗi xuất hiện, loại bỏ thì lỗi mất.
Câu hỏi thường gặp
Phải hỏi “tại sao” đúng năm lần không?
Không. Năm là con số gợi nhớ để không dừng ở câu trả lời đầu tiên. Dừng khi tới một nguyên nhân mà nhóm có thể hành động, hành động đó ngăn được tái diễn, và chuỗi đọc ngược bằng “vì vậy” vẫn hợp lý. Nhiều vấn đề cần ba tầng, một số cần nhiều hơn năm.
Một sự cố có thể có nhiều nguyên nhân gốc không?
Có, và thường là vậy với sự cố phức tạp. Ngoài ra luôn nên tách nguyên nhân phát sinh lỗi và nguyên nhân lỗi lọt qua kiểm soát. Ý tưởng “một nguyên nhân gốc duy nhất” là giả định đơn giản hoá, phù hợp với vấn đề cơ khí hẹp hơn là với sự cố tổ chức.
Làm sao biết đã tìm đúng nguyên nhân gốc?
Ba dấu hiệu: nguyên nhân giải thích được mọi dữ kiện trong bảng là / không là; có thể tái tạo hoặc tắt lỗi bằng cách bật tắt nguyên nhân; và sau khi khắc phục, dữ liệu trong một khoảng đủ dài cho thấy vấn đề không quay lại. Thiếu cả ba thì nên coi kết luận là giả thuyết.
RCA có nên dùng để xác định ai chịu trách nhiệm không?
Nên tách hai việc. RCA nhằm hiểu hệ thống để ngăn tái diễn; nếu người tham gia sợ bị phạt, họ sẽ giấu thông tin và phân tích sai. Xử lý kỷ luật chỉ phù hợp với vi phạm cố ý hoặc liều lĩnh rõ ràng, và nên do quy trình riêng xem xét. Nhiều ngành an toàn cao gọi đây là văn hoá công bằng.
Ai nên điều phối buổi phân tích nguyên nhân?
Người nắm phương pháp và không có lợi ích trực tiếp trong kết luận, thường là kỹ sư chất lượng hoặc một quản lý từ bộ phận khác. Nhóm phải có người trực tiếp làm việc ở khu vực xảy ra sự cố, vì họ biết những chi tiết không có trong hồ sơ.
Có phần mềm nào thay thế được phân tích nguyên nhân thủ công không?
Phần mềm giúp lưu trữ, theo dõi hành động và tìm sự cố tương tự trong quá khứ; công cụ phân tích dữ liệu giúp tìm tương quan trong dữ liệu sản xuất lớn. Nhưng xác định cơ chế nhân quả vẫn cần người hiểu quá trình, đi hiện trường và kiểm chứng giả thuyết. Tương quan do máy tìm ra chỉ là điểm bắt đầu.