Phân tích nguyên nhân cốt lõi (Root Cause Analysis) – Kỹ thuật và cách ứng dụng

Phân tích nguyên nhân gốc rễ cũng là một kỹ thuật bảo dưỡng thiết bị, áp dụng để tìm ra nguyên nhân gốc rễ gây ra hư hỏng và từ đó khắc phục triệt để tránh lặp lại hoặc làm giảm hậu quả sau này. Trong bài dưới đây trình bày các khái niệm chung và cách ứng dụng:
T
rong hoạt động logistics hàng ngày, hẳn bạn sẽ gặp phải rất nhiều vấn đề xảy ra như hàng chuyển sai, hàng bị hư hỏng, hàng bị giao trễ, xe bị hỏng, thông tin bị cập nhật sai lệch. Lẽ dĩ nhiên bạn cần tìm ra nguyên nhân, nhưng phần lớn tôi quan sát thì chưa ai phân tích nguyên nhân một cách bài bản và có hệ thống. Có chăng chỉ dựa vào kinh nghiệm là chính. Đây là một nhận thức sai lầm. Bởi bạn không thể giải quyết được vấn đề nếu như bạn không biết được nguyên nhân cốt lõi nhất của nó.
Ví dụ, nếu như hàng bị chuyển sai thay vì mã hàng B thì là mã hàng A, thì phần lớn chúng ta ngay lập tức cho rằng do nhân viên đóng hàng (picker) đã đóng hàng sai và lần sau họ cần rút kinh nghiệm thế là xong. Như vậy là chưa đủ và vô cùng sơ suất. Bởi bạn chưa đào vào cái gốc rễ của nó! Tại sao nhân viên lại đóng hàng sai? Hãy tiếp tục lần theo dấu vết ấy bạn sẽ đi đến căn nguyên mà người ta gọi là atomic.


Mô hình xương cá (tham khảo)

Bài viết dưới đây tôi xin trích tổng hợp từ một tác giả viết rất hay và hệ thống về Root Cause Analysis. Hi vọng giúp các bạn có một cái nhìn hệ thống hơn.

Thông thường khi xảy ra một vấn đề thì nguyên nhân thường được đổ lỗi lòng vòng. Điều này gây ra sự mẫu thuẫn trong nội bộ, cũng như sự thiếu trung thực, đổ lỗi lẫn cho nhau dẫn tới việc communication giữa các bên thất bại dẫn tới hoạt động hoặc dự án có thể bị đổ vỡ. Cách tốt nhất giải quyết việc này là cần xác định được nguyên nhân cốt lõi (root cause) của vấn đề thay vì chỉ quan sát bề ngoài của vấn đề (mà chúng ta gọi là hiện tượng).

Cách thức mang tính hệ thống và có cơ cấu này người ta gọi là Root Cause Analysis. Có nhiều công cụ ứng dụng để phát triển Root Cause Analysis thì cách phổ biến nhất được nhiều công ty sử dụng là mô hình 5 TẠI SAO ? (5 WHY?) của công ty TOYOTA. Cơ bản công cụ này được hiểu là việc sử dụng câu hỏi TẠI SAO nhiều lần cho đến khi tìm ra được yếu tố cốt lõi nhất (atomic-yếu tố hạt nhân) nhưng phải đảm bảo có thể xử lý được (actionable). Để mô hình hóa quy trình “5-WHY?” người ta áp dụng mô hình xương cá (Fishbone Diagram hay Ishikawa diagram ) mà chúng tôi sẽ đi sâu ở dưới đây.

Ishikawa Diagram

Các thành tố của mô hình Xương Cá:

  • Ở đầu bộ xương cá thể hiện lỗi xảy ra hoặc tác động của lỗi , thể hiện bằng câu hỏi
  • Ở các khúc xương sống của cá thể hiện nhóm nguyên nhân chính
  • Ở các xương dăm thế hiện chi tiết các nguyên nhân cho từng nhóm nguyên nhân chính
  • Có những khúc xương sống phổ biến như sau:
    • Con người
    • Thiết Bị
    • Nguyên liệu
    • Thông tin
    • Quy trình
    • Thước đo
    • Môi trường
    • Hệ thống

Sau khi hoàn thành hệ thống sơ đồ xương cá, bạn có thể nhanh chóng kiểm tra khả năng phân tích logic của mình bằng cách quan sát xương cá từ trên xuống hoặc từ dưới lên như:

Lỗi xảy ra là do yếu tố g; g xảy ra là do f; f xảy ra là do e; e xảy ra là do c; c xảy ra là do b; b xảy ra là do a

Đây là công việc rất quan trọng giúp bạn tìm ra nguyên nhân cốt lỗi để từ đó tìm ra phương cách điều trị : giảm bớt hoặc loại trừ nó
Ngay khi xác định được nguyên nhân cốt lõi của mỗi xương sống của cá bạn cần khoanh tròn hoặc đánh dấu nó. Nguyên tắc vàng là hiếm khi chỉ có một nguyên nhân cho mỗi lỗi xảy ra mà thường sẽ là khá nhiều yếu tố.

Hình dưới mô tả cách đánh dâu nguyên nhân cốt lõi của mỗi xương sống của cá


bone sample

Một vài gợi ý quan trọng:

  • Khi phân tích lỗi cần có sự tham gia của nhiều bên tham gia đảm bảo bạn sẽ tìm ra nguyên nhân cốt lõi hiệu quả hơn
  • Luôn luôn hỏi “tại sao” cho đến khi nào bạn tìm thấy nguyên nhân cốt lõi nhất và có thể xử lý được
  • Mục đích của xương cá là trả lời cho một câu hỏi, do đó cần tư duy và suy nghĩ xem cách để xử lý nguyên nhân cốt lõi.
  • Hãy luôn đảm bảo những người tham gia phân tích có được quyền chủ động và trách nhiệm cần thiết- đảm bảo họ luôn là một phần quan trọng của quy trình này

Hãy vận dụng một cách linh hoạt và sáng tạo
Phân tích nguyên nhân cốt lõi có thể ứng dụng trong rất nhiều ho
t động từ coding phần mềm để tìm lỗi, trong xây dựng quy trình, trong quản lý dự án, trong quản trị gia đình, quản trị logistics,..

Nên nhớ, sau khi tìm ra nguyên nhân cốt lõi, thì điều tiếp theo bạn phải luôn đảm bảo nguyên nhân ấy được xử lý một cách có hệ thống mà thường người ta xây dựng quy trình Corrective Action Plan để theo dõi quá trình cải tiến sau khi xảy ra lỗi..

Cuối cùng hãy luôn nhớ một định luật vô cùng quan trọng

Định luật Murphy:

“Nếu một việc có thể diễn tiến xấu, nó sẽ diễn tiến đúng như thế”

Nếu mọi việc dường như tiến triển rất tốt đẹp, thì hiển nhiên bạn đã bỏ qua một điều gì đó

Tổng hợp từ Shmula.com,và các nguồn khác.
www.diendantmdt.com/forum/showthread.php?p=19496

SCCK.TK

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s