🌐 VI / EN | 🏆 CiCC — Cải tiến liên tục từ 2011

Phân tích RCA: hướng dẫn 5 Whys, Fishbone, Fault Tree, Pareto

📅 24/07/2026 👤 Admin ⏱ 16 phút đọc 20+ thực chiến

Phân tích RCA (Root Cause Analysis) là quy trình điều tra có cấu trúc để hiểu vì sao một vấn đề xảy ra, kiểm chứng nguyên nhân bằng bằng chứng và lựa chọn hành động giúp ngăn vấn đề tái diễn. RCA không phải một công cụ duy nhất: nhóm có thể dùng Pareto để xác định vấn đề ưu tiên, Fishbone để mở rộng giả thuyết, 5 Whys để truy vết chuỗi nguyên nhân và Fault Tree để phân tích tổ hợp sự kiện. Chọn đúng công cụ phụ thuộc vào loại vấn đề, dữ liệu sẵn có và mức độ phức tạp.

Bài viết hướng dẫn cách thực hiện RCA từ xác định vấn đề đến kiểm tra hiệu lực đối sách. Các số liệu tình huống bên dưới được ghi rõ là ví dụ minh họa, không phải kết quả dự án khách hàng hay cam kết cải thiện của CiCC.

Quy trình phân tích RCA từ xác định vấn đề, thu thập dữ liệu đến kiểm tra đối sách và duy trì
RCA nên nối dữ kiện, lập luận nhân quả và hành động có thể xác nhận.

RCA là gì và khi nào nên thực hiện?

Root Cause Analysis có thể dịch là phân tích nguyên nhân gốc. Mục tiêu không phải tìm một cá nhân để quy trách nhiệm, mà xác định các điều kiện trong quy trình đã tạo ra hoặc không phát hiện được vấn đề. Một RCA tốt bắt đầu từ hiện tượng được mô tả cụ thể, dựa trên dữ liệu và kết thúc bằng hành động xử lý nguyên nhân cùng cơ chế theo dõi.

Nên cân nhắc RCA khi lỗi lặp lại, sự cố ảnh hưởng đến khách hàng hoặc an toàn, chi phí sửa lỗi tăng, quy trình không đạt mục tiêu, hay biện pháp khắc phục trước đây không ngăn được tái diễn. Với sự cố nghiêm trọng, cần ưu tiên bảo vệ con người, khách hàng và sản phẩm trước; điều tra nguyên nhân chỉ bắt đầu khi tình hình đã được kiểm soát.

Quy trình phân tích nguyên nhân gốc từng bước

  1. Kiểm soát tình hình: ngăn tác động tiếp tục lan rộng, bảo vệ bằng chứng và thông báo theo quy trình hiện hành.
  2. Mô tả vấn đề bằng dữ kiện: nêu điều gì xảy ra, ở đâu, khi nào, tần suất/mức độ ra sao và tiêu chuẩn mong đợi là gì. Tránh mô tả kiểu “nhân viên bất cẩn” khi chưa có bằng chứng.
  3. Xác định phạm vi và nhóm: chọn khoảng thời gian, sản phẩm, công đoạn, khách hàng hoặc hệ thống liên quan; mời người hiểu trực tiếp công việc và dữ liệu tham gia.
  4. Thu thập và kiểm tra dữ liệu: đối chiếu hồ sơ, quan sát tại hiện trường, phỏng vấn, mẫu lỗi và lịch sử thay đổi. Kiểm tra cách ghi nhận và độ tin cậy của dữ liệu trước khi diễn giải.
  5. Phát triển giả thuyết: dùng công cụ phù hợp để sắp xếp và truy vết các nguyên nhân có thể.
  6. Kiểm chứng quan hệ nhân quả: tìm bằng chứng cho từng mối nối “nguyên nhân → kết quả”; thử nghiệm hoặc phân tích dữ liệu nếu có thể.
  7. Chọn đối sách và chủ sở hữu: ưu tiên loại bỏ hoặc kiểm soát điều kiện gây lỗi, đồng thời phân biệt biện pháp tạm thời với hành động khắc phục lâu dài.
  8. Xác nhận hiệu lực: so sánh trước-sau theo cùng định nghĩa, theo dõi đủ thời gian và kiểm tra tác dụng phụ. Chuẩn hóa quy trình sau khi kết quả được xác nhận.

RCA có thể cần nhiều hơn một nguyên nhân: một điều kiện tạo ra lỗi và một điều kiện khác khiến lỗi không được phát hiện. Phân tích cả nguyên nhân phát sinh lẫn nguyên nhân thoát lọt giúp đối sách đầy đủ hơn.

Chọn giữa 5 Whys, Fishbone, Fault Tree và Pareto

Bảng chọn công cụ RCA Pareto, Fishbone, 5 Whys, Fault Tree và FMEA theo câu hỏi phân tích
Các công cụ giải quyết những câu hỏi khác nhau và thường được dùng kết hợp.

5 Whys: truy vết một chuỗi nguyên nhân

5 Whys khuyến khích hỏi “vì sao?” nhiều lần để đi từ triệu chứng đến các điều kiện sâu hơn. Không bắt buộc phải đúng năm câu hỏi; dừng khi nguyên nhân đã được xác minh, nằm trong phạm vi có thể tác động và đối sách có thể kiểm tra. Lean Enterprise Institute nhấn mạnh mục đích là lần theo chuỗi nhân quả, không dừng ở triệu chứng; cần quan sát công việc và đối chiếu bằng chứng.[1]

Không nối các câu trả lời chỉ vì chúng nghe hợp lý. Với mỗi bước, hãy hỏi: có hồ sơ, quan sát, phép đo hay thử nghiệm nào cho thấy nguyên nhân trước thực sự dẫn tới kết quả sau không? Nếu có nhiều nhánh nguyên nhân, 5 Whys đơn tuyến có thể không đủ.

Fishbone (Ishikawa): sắp xếp các nguyên nhân khả dĩ

Fishbone, còn gọi là biểu đồ nhân quả, giúp nhóm tổ chức các giả thuyết theo nhóm để tránh chỉ tập trung vào một lời giải thích. Một bộ nhóm thường dùng trong sản xuất là 6M: con người, máy móc, phương pháp, vật liệu, đo lường và môi trường. Đây là khung gợi ý, không phải danh sách nguyên nhân đã được chứng minh. ASQ mô tả Fishbone như công cụ sắp xếp các nguyên nhân có thể theo nhóm; từng giả thuyết vẫn cần được kiểm tra.[2]

Biểu đồ Fishbone Ishikawa minh họa sáu nhóm nguyên nhân 6M cho phân tích RCA
Fishbone mở rộng góc nhìn; các nhánh chỉ trở thành nguyên nhân khi được xác minh.

Fault Tree Analysis: phân tích tổ hợp sự kiện

Fault Tree Analysis (FTA) bắt đầu từ một sự kiện không mong muốn ở đỉnh cây rồi phân rã các sự kiện dẫn tới nó bằng cổng logic, thường là AND và OR. Dạng này phù hợp khi sự cố có nhiều nhánh hoặc điều kiện kết hợp, nhất là trong phân tích độ tin cậy và an toàn. Sổ tay Fault Tree của NASA giải thích ý nghĩa các cổng logic và cách phát triển cây; phạm vi phân tích cần được định nghĩa rõ trước khi diễn giải kết quả.[3]

Pareto: ưu tiên nơi cần điều tra trước

Biểu đồ Pareto sắp xếp hạng mục theo tần suất, chi phí, thời gian hoặc mức tác động để thấy nhóm vấn đề đáng ưu tiên. Pareto giúp chọn “điều tra việc gì trước”, nhưng không tự chỉ ra nguyên nhân gốc. Cần bảo đảm dữ liệu cùng kỳ, cùng định nghĩa và không cộng gộp các nhóm khác bản chất. ASQ mô tả Pareto là biểu đồ cột sắp theo độ lớn nhằm làm nổi bật các tình huống quan trọng hơn.[4]

Ví dụ 5 Whys minh họa: hồ sơ đơn hàng thiếu trường bắt buộc

Tình huống giả định: một hồ sơ đơn hàng đi qua bước kiểm tra nhưng thiếu trường dữ liệu bắt buộc. Nhóm nêu chuỗi giả thuyết như sau:

Ví dụ minh họa chuỗi 5 Whys điều tra lỗi hồ sơ đơn hàng thiếu trường dữ liệu bắt buộc
Ví dụ giả định để minh họa cách đặt câu hỏi, không phải báo cáo của doanh nghiệp khách hàng.
  1. Vì sao thiếu trường? Biểu mẫu không cảnh báo khi trường để trống.
  2. Vì sao biểu mẫu không cảnh báo? Phiên bản đang sử dụng thiếu quy tắc kiểm tra trường bắt buộc.
  3. Vì sao quy tắc chưa được cập nhật? Danh sách trường bắt buộc đã thay đổi nhưng biểu mẫu chưa được đối chiếu.
  4. Vì sao thay đổi chưa được đối chiếu? Luồng phê duyệt phát hành biểu mẫu chưa nêu rõ bước kiểm tra thay đổi này.
  5. Giả thuyết tiếp theo: trách nhiệm sở hữu và kiểm soát phiên bản có thể chưa rõ.

Đây chưa phải kết luận RCA. Nhóm phải kiểm tra lịch sử thay đổi, phiên bản biểu mẫu, log kiểm tra và quy định phê duyệt. Nếu dữ liệu cho thấy nguyên nhân khác, cần sửa chuỗi phân tích theo bằng chứng. Cách hỏi “nếu điều kiện này tồn tại thì vấn đề có xảy ra không?” và kiểm tra ngược bằng “nếu không có điều kiện đó thì vấn đề có được ngăn không?” giúp rà lại logic nhân quả.

Từ nguyên nhân đã xác minh đến hành động khắc phục

Đối sách nên liên hệ trực tiếp với nguyên nhân đã xác minh. Trong ví dụ giả định, biện pháp có thể gồm cập nhật quy tắc kiểm tra trường bắt buộc, giao chủ sở hữu danh mục dữ liệu và bổ sung bước đối chiếu khi phát hành phiên bản mới. Cảnh báo tạm thời hoặc nhắc nhân viên có thể giúp giảm rủi ro trước mắt, nhưng không thay thế việc sửa điều kiện của quy trình nếu đó là nguyên nhân được xác nhận.

  • Ghi rõ hành động, người chịu trách nhiệm, thời hạn và bằng chứng hoàn thành.
  • Định nghĩa chỉ số hiệu lực: ví dụ số hồ sơ thiếu trường trên tổng hồ sơ đã kiểm tra trong cùng kỳ.
  • Đặt mức mục tiêu và thời gian theo dõi trước khi triển khai; không chọn tiêu chí sau khi đã nhìn kết quả.
  • Kiểm tra tác dụng phụ như thời gian xử lý tăng, lỗi nhập khác phát sinh hoặc bước kiểm soát bị bỏ qua.
  • Nếu vấn đề tái diễn, mở lại phân tích và xem xét liệu nguyên nhân/đối sách trước đó đã được xác minh đủ chưa.
Chu trình kiểm tra hiệu lực đối sách RCA từ baseline đến thí điểm, so sánh và duy trì
Xác nhận đối sách bằng baseline, phép đo nhất quán và theo dõi sau khi chuẩn hóa.

Mẫu biên bản RCA nên có những gì?

Một mẫu RCA hữu ích nên ghi được: mã và ngày sự cố; mô tả hiện tượng bằng dữ kiện; phạm vi ảnh hưởng; hành động kiểm soát tức thời; nguồn dữ liệu và người tham gia; các giả thuyết; bằng chứng ủng hộ hoặc bác bỏ; nguyên nhân đã xác minh; hành động khắc phục; người phụ trách và hạn hoàn thành; chỉ số xác nhận hiệu lực; ngày đánh giá lại. Lưu cả giả thuyết bị loại để nhóm sau không lặp lại điều tra thiếu căn cứ.

RCA thường gắn với chu trình cải tiến rộng hơn. Có thể xem thêm hướng dẫn triển khai Lean Six Sigma và bài Lean Manufacturing ngành ô tô để tham khảo cách kết nối phân tích vấn đề với cải tiến quy trình.

Video hướng dẫn 5 Whys của Lean Enterprise Institute

Video này do Lean Enterprise Institute đăng tải và giải thích phương pháp 5 Whys qua ví dụ máy dừng. Đây là tài liệu học tập độc lập, không phải nghiên cứu tình huống của CiCC.

Câu hỏi thường gặp về phân tích RCA

5 Whys có bắt buộc hỏi đúng năm lần không?

Không. Số năm trong tên gọi nhắc nhóm đào sâu hơn triệu chứng. Hãy tiếp tục hoặc dừng dựa trên chuỗi nhân quả, bằng chứng và khả năng kiểm chứng đối sách.

Fishbone có xác định được nguyên nhân gốc không?

Fishbone giúp liệt kê và phân loại nguyên nhân khả dĩ. Nó không tự chứng minh nguyên nhân nào đúng; nhóm cần xác minh từng giả thuyết bằng dữ liệu hoặc quan sát.

Pareto có thay thế RCA được không?

Không. Pareto giúp chọn vấn đề hoặc hạng mục ưu tiên theo dữ liệu. Sau đó cần điều tra nguyên nhân bằng công cụ và phương pháp phù hợp.

Khi nào nên dùng Fault Tree Analysis?

Dùng FTA khi một sự kiện không mong muốn có nhiều sự kiện nền hoặc tổ hợp điều kiện AND/OR cần phân tích có cấu trúc, đặc biệt trong độ tin cậy và an toàn.

Nguồn tham khảo

  1. Lean Enterprise Institute — 5 Whys.
  2. ASQ — Fishbone / Cause-and-Effect Diagram.
  3. NASA — Fault Tree Handbook with Aerospace Applications.
  4. ASQ — Pareto Chart.
  5. Lean Enterprise Institute — Clarifying the 5 Whys Problem-Solving Method.

CiCC chia sẻ nội dung đào tạo và tư vấn cải tiến quy trình, Lean Six Sigma và chất lượng. Phạm vi, dữ liệu nền, yêu cầu bảo mật và tiêu chí thành công cần được thống nhất cho từng bài toán doanh nghiệp.

📤 Chia sẻ thông tin tư vấn

🚀 Khám phá toàn bộ hệ sinh thái CiCC

Đào tạo · Phần mềm · AI — một hành trình cải tiến liên tục.