5 WHYS VÀ FISHBONE KHÁC NHAU THẾ NÀO? CONSULTANT NÊN DÙNG CÔNG CỤ NÀO?

Một nhà máy liên tục gặp lỗi sản phẩm ở công đoạn đóng gói. Trong cuộc họp xử lý vấn đề, quản lý hỏi: “Tại sao lỗi này xảy ra?”. Nhân viên trả lời rằng máy đóng gói thường xuyên bị lệch vị trí. Câu hỏi tiếp theo là: “Tại sao máy lại lệch?”. Người vận hành cho rằng cảm biến hoạt động không ổn định. Sau vài lần tiếp tục hỏi “Tại sao?”, cả nhóm đi đến kết luận rằng lịch bảo trì cảm biến chưa được chuẩn hóa. Một thành viên lập tức đề xuất: “Đây chính là Root Cause”. Nhưng kỹ sư chất lượng lại đặt câu hỏi khác: nếu nguyên nhân chỉ nằm ở bảo trì cảm biến, tại sao lỗi chỉ xuất hiện ở ca đêm và tập trung ở một số loại bao bì? Có thể còn những nguyên nhân khác liên quan đến vật liệu, phương pháp vận hành, môi trường hoặc con người mà chuỗi câu hỏi vừa rồi chưa chạm tới.

Đây là tình huống rất điển hình cho sự khác nhau giữa 5 Whys và Fishbone. Cả hai đều được sử dụng trong Root Cause Analysis – phân tích nguyên nhân gốc, nhưng chúng không thực hiện cùng một chức năng. ASQ mô tả 5 Whys là kỹ thuật đặt câu hỏi lặp lại để đi sâu qua các lớp triệu chứng và tìm hiểu chi tiết hơn về nguyên nhân của một vấn đề; con số năm không phải quy tắc cứng, bởi có trường hợp cần ít hơn hoặc nhiều hơn năm lần hỏi “Why?”. Trong khi đó, Fishbone Diagram, còn gọi là Ishikawa Diagram hoặc Cause-and-Effect Diagram, được sử dụng để xác định nhiều nguyên nhân có thể dẫn đến một vấn đề và sắp xếp chúng thành các nhóm hữu ích để tiếp tục điều tra.

Với Consultant, điểm quan trọng không phải thuộc lòng cách vẽ hai công cụ mà là biết đang cần mở rộng hay đào sâu. Nếu bài toán còn mơ hồ và có thể xuất phát từ nhiều nhóm nguyên nhân khác nhau, Fishbone thường hữu ích để mở rộng không gian điều tra. Nếu một nhánh nguyên nhân đã đủ rõ và Consultant muốn đi sâu từ triệu chứng đến nguyên nhân bên dưới, 5 Whys thường phù hợp hơn. Trong nhiều dự án, cách làm tốt nhất không phải chọn một trong hai mà là Fishbone để đi rộng, sau đó dùng 5 Whys để đi sâu vào những nhánh đáng kiểm chứng.

1. 5 Whys và Fishbone khác nhau ở cách Consultant tiếp cận nguyên nhân như thế nào?

5 Whys vận hành theo logic chuỗi. Consultant bắt đầu từ một Problem Statement hoặc một nguyên nhân đã được nhận diện, sau đó liên tục hỏi tại sao điều đó xảy ra để từng bước đi xuống tầng nguyên nhân sâu hơn. ASQ mô tả kỹ thuật này như một quá trình “drill down”, tức đào sâu vào chi tiết của vấn đề nhằm bóc dần các lớp triệu chứng. Việc gọi là “Five Whys” không có nghĩa Consultant bắt buộc phải hỏi chính xác năm lần; ASQ lưu ý rằng tùy bài toán, số lần hỏi có thể ít hơn hoặc nhiều hơn để đi đến mức nguyên nhân đủ hữu ích cho hành động.

Ví dụ, doanh nghiệp đang gặp tình trạng giao hàng trễ. Consultant có thể bắt đầu bằng câu hỏi tại sao đơn hàng giao trễ và nhận được câu trả lời rằng hàng chưa được đóng gói đúng kế hoạch. Tiếp tục hỏi tại sao sẽ dẫn tới việc công đoạn đóng gói không nhận được kế hoạch kịp thời, sau đó phát hiện Planning thường xuyên phải điều chỉnh vì Forecast thay đổi vào phút cuối. Đi sâu thêm có thể cho thấy Sales được đánh giá chủ yếu theo doanh thu mà không có cơ chế khóa Forecast hoặc chịu trách nhiệm về độ chính xác dự báo. Như vậy, chuỗi phân tích đã đi từ một triệu chứng ở kho vận tới một vấn đề về cơ chế quản trị. Đây là sức mạnh của 5 Whys: nó buộc Consultant không dừng lại ở nguyên nhân gần nhất chỉ vì nguyên nhân đó dễ nhìn thấy.

Tuy nhiên, chính cấu trúc tuyến tính này cũng là giới hạn của 5 Whys. Một vấn đề thực tế hiếm khi chỉ có một con đường nguyên nhân duy nhất. Nếu nhóm chọn sai nhánh ngay từ câu trả lời đầu tiên, toàn bộ chuỗi “Why” phía sau có thể đi rất sâu nhưng vẫn đi sai hướng. Trong ví dụ giao hàng trễ, nguyên nhân có thể không chỉ nằm ở Forecast mà còn liên quan tới năng lực vận tải, dữ liệu tồn kho, lỗi đóng gói, thiếu nguyên vật liệu hoặc chính sách ưu tiên đơn hàng. Nếu Consultant chỉ bắt đầu với một giả định và liên tục hỏi “Why?” trên giả định đó, kết quả dễ trở thành một câu chuyện hợp lý nhưng chưa chắc phản ánh đúng thực tế.

Fishbone giải quyết bài toán theo hướng khác. Thay vì đi ngay vào một chuỗi nguyên nhân, công cụ mở rộng góc nhìn để đội dự án nhận diện nhiều nhóm nguyên nhân có thể cùng tác động đến một Effect. ASQ mô tả Fishbone là công cụ giúp xác định nhiều nguyên nhân khả dĩ và sắp xếp ý tưởng thành những nhóm có cấu trúc; đây cũng là một trong Seven Basic Quality Tools. Trong môi trường sản xuất, các nhóm nguyên nhân thường được tổ chức theo 4M hoặc 6M như Man, Machine, Method, Material, Measurement và Mother Nature/Environment. Tuy nhiên, Consultant không nên xem 6M như một template bắt buộc; với bài toán dịch vụ, công nghệ hay quản trị, các nhóm nguyên nhân hoàn toàn có thể được điều chỉnh để phản ánh đúng hệ thống cần phân tích.

Có thể hiểu rất ngắn gọn rằng 5 Whys tạo chiều sâu, Fishbone tạo chiều rộng. Một công cụ giúp Consultant lần theo mối quan hệ nguyên nhân – nguyên nhân ở một nhánh, còn công cụ kia giúp tránh việc quá sớm khóa tư duy vào một nguyên nhân duy nhất. ASQ cũng ghi nhận 5 Whys có thể được sử dụng cùng brainstorming hoặc Cause-and-Effect Diagram, cho thấy hai công cụ vốn được thiết kế để bổ trợ chứ không phải cạnh tranh nhau.

2. Khi nào Consultant nên dùng 5 Whys và khi nào Fishbone phù hợp hơn?

5 Whys đặc biệt hiệu quả khi Problem Statement đã tương đối cụ thể và đội dự án có đủ hiểu biết về quy trình để đi sâu vào một chuỗi nguyên nhân. Ví dụ, máy dừng đột ngột ba lần trong một ca, hóa đơn bị xuất sai vì một trường dữ liệu không được cập nhật, hoặc một bước phê duyệt mất trung bình bốn ngày trong khi SLA chỉ cho phép một ngày. Trong những trường hợp này, Consultant đã có một hiện tượng tương đối rõ và có thể bắt đầu đặt câu hỏi tại sao nó xảy ra. Kỹ thuật đặc biệt hữu ích khi cuộc thảo luận có xu hướng dừng ở những câu trả lời bề mặt như “nhân viên bất cẩn”, “máy móc có vấn đề” hoặc “quy trình chưa tốt”, bởi chuỗi Why buộc nhóm phải tiếp tục hỏi điều gì trong hệ thống đã cho phép tình trạng đó xảy ra.

Nhưng 5 Whys không nên được sử dụng như một cuộc thẩm vấn. Nếu Consultant liên tục hỏi “Tại sao?” với một cá nhân theo cách quy trách nhiệm, quá trình phân tích rất dễ biến thành tìm người có lỗi thay vì tìm điều kiện hệ thống tạo ra lỗi. Một nhân viên nhập sai dữ liệu có thể là nguyên nhân trực tiếp, nhưng nguyên nhân sâu hơn có thể nằm ở thiết kế form, hướng dẫn công việc, workload, giao diện phần mềm hoặc cơ chế kiểm tra. ASQ cũng nhấn mạnh trong hướng dẫn Problem Solving rằng Root Cause Analysis cần kiểm tra những nguyên nhân khác đã được nghiên cứu và loại bỏ, đồng thời phải xác minh nguyên nhân chứ không chỉ dừng ở suy luận.

Fishbone phù hợp hơn khi vấn đề có nhiều biến và chưa rõ nên bắt đầu từ đâu. Nếu doanh nghiệp nói “tỷ lệ khiếu nại khách hàng tăng”, “năng suất giảm”, “tỷ lệ nghỉ việc cao” hoặc “Lead Time dài”, Consultant khó có thể ngay lập tức chọn một chuỗi Why duy nhất. Lúc này, Fishbone giúp đội dự án tạo bản đồ giả thuyết nguyên nhân. Với vấn đề năng suất thấp, nhóm có thể xem xét con người, thiết bị, phương pháp, vật liệu, đo lường và môi trường. Với Customer Experience, các nhánh có thể được thiết kế lại thành Process, People, Policy, Technology, Data và Customer Demand. Giá trị không nằm ở việc hình con cá đẹp hay đủ sáu nhánh mà ở việc ép đội dự án nhìn vấn đề từ nhiều góc độ trước khi kết luận.

ASQ cũng lưu ý Fishbone đặc biệt hữu ích để cấu trúc brainstorming, bởi các nguyên nhân và nguyên nhân phụ có thể được phát triển theo từng nhánh và sau đó chọn ra những khu vực cần điều tra thêm. Điều này rất phù hợp với vai trò Consultant khi làm việc với một nhóm liên phòng ban. Operations có thể nhìn ra nguyên nhân về Process, HR nhìn thấy vấn đề năng lực, IT phát hiện giới hạn hệ thống còn Finance nhận ra một cơ chế KPI đang khuyến khích hành vi sai. Fishbone tạo một không gian chung để các góc nhìn này được đưa lên cùng một bức tranh thay vì mỗi phòng ban bảo vệ giả thuyết riêng của mình.

Do đó, một quy tắc thực hành tương đối hữu ích là: khi chưa biết những nhóm nguyên nhân nào cần điều tra, hãy đi rộng bằng Fishbone; khi đã có một nhánh đáng nghi và cần hiểu tại sao nó tồn tại, hãy đi sâu bằng 5 Whys. Nhưng đây không phải công thức cứng. Consultant vẫn cần căn cứ vào độ phức tạp, dữ liệu sẵn có và mức độ hiểu quy trình để quyết định cách sử dụng.

3. Vì sao Fishbone kết hợp 5 Whys thường mạnh hơn việc chỉ dùng một công cụ?

Trong một dự án thực tế, Consultant có thể bắt đầu từ một Problem Statement đã được xác định rõ, chẳng hạn “Tỷ lệ giao hàng trễ tăng từ 8% lên 19% trong ba tháng gần nhất tại nhóm khách hàng B2B miền Bắc”. Thay vì lập tức hỏi Why theo một hướng, đội dự án sử dụng Fishbone để hình thành các nhóm giả thuyết. Một nhánh liên quan tới Planning có thể gồm Forecast Accuracy, thay đổi đơn hàng và lịch sản xuất; nhánh Supply Chain có Lead Time nhà cung cấp và thiếu nguyên vật liệu; nhánh Logistics có Capacity vận tải và routing; nhánh Process có thời gian chờ hoặc bàn giao; nhánh Data có tồn kho hệ thống khác với tồn kho thực tế. Fishbone lúc này không chứng minh nguyên nhân nào đúng, nhưng giúp Consultant đảm bảo không bỏ sót những hướng điều tra quan trọng chỉ vì một ý kiến ban đầu nghe có vẻ thuyết phục.

Sau đó, dữ liệu và Gemba được sử dụng để thu hẹp phạm vi. Nếu phân tích cho thấy 60% các đơn trễ liên quan tới việc thay đổi lịch sản xuất sau khi đơn hàng đã được xác nhận, Consultant có thể chọn nhánh đó để đào sâu bằng 5 Whys. Tại sao lịch sản xuất thay đổi? Vì Forecast thay đổi thường xuyên. Tại sao Forecast thay đổi? Vì Sales cập nhật đơn hàng quá gần thời điểm sản xuất. Tại sao điều này vẫn được chấp nhận? Vì chưa có Frozen Window hoặc nguyên tắc khóa kế hoạch. Tại sao chưa có cơ chế đó? Vì S&OP chưa xác định rõ Decision Rights giữa Sales và Operations. Chuỗi phân tích lúc này đã đi từ một vấn đề giao hàng sang một nguyên nhân quản trị có thể được kiểm chứng và thiết kế giải pháp.

ASQ trong quy trình 8D cũng nhấn mạnh rằng ở bước xác định Root Cause, các nguyên nhân cần được verified or proved, thay vì chỉ được lựa chọn thông qua brainstorming; cả Five Whys và Cause-and-Effect Diagram đều có thể được sử dụng để lập bản đồ nguyên nhân, nhưng nguyên nhân cuối cùng vẫn phải được kiểm chứng. Đây là điểm rất quan trọng đối với Consultant, bởi Fishbone và 5 Whys đều là công cụ suy luận, không phải máy tạo ra sự thật. Một nhánh nghe hợp lý chưa chắc là Root Cause nếu dữ liệu thực tế không hỗ trợ nó.

Vì vậy, một mạch phân tích thực tế có thể đi theo logic Problem Statement → Fishbone → ưu tiên giả thuyết → 5 Whys → Gemba/Dữ liệu → xác minh Root Cause → giải pháp → kiểm chứng kết quả. Consultant có thể sử dụng Pareto để xác định nhóm vấn đề nào chiếm tỷ trọng lớn, Process Map để hiểu nơi vấn đề phát sinh, dữ liệu để kiểm tra tương quan và các công cụ thống kê sâu hơn nếu mức độ phức tạp yêu cầu. ASQ cũng xem Root Cause Analysis là một tập hợp nhiều phương pháp và công cụ, trong đó Fishbone, 5 Whys, Pareto hay các kỹ thuật khác đóng vai trò khác nhau tùy bài toán.

Điều này cũng giải thích tại sao một Consultant giỏi không hỏi “công cụ nào tốt nhất?” mà hỏi “công cụ nào giúp trả lời câu hỏi tiếp theo của quá trình chẩn đoán?”. Nếu cần mở rộng hypothesis space, Fishbone phù hợp. Nếu cần đào sâu một causal chain, dùng 5 Whys. Nếu cần xác định nguyên nhân nào thực sự chiếm phần lớn vấn đề, Pareto có thể phù hợp hơn. Nếu nghi ngờ mối quan hệ giữa hai biến số, cần dữ liệu và các công cụ phân tích khác. Công cụ chỉ có ý nghĩa khi nằm đúng vị trí trong logic chẩn đoán.

4. Consultant cần tránh những sai lầm nào khi dùng 5 Whys và Fishbone?

Sai lầm đầu tiên là đi tìm Root Cause trước khi Problem Statement đủ rõ. Nếu cả nhóm đang phân tích một khái niệm mơ hồ như “nhân viên thiếu trách nhiệm” hoặc “quy trình không hiệu quả”, cả Fishbone lẫn 5 Whys đều dễ tạo ra những kết luận cảm tính. Consultant cần xác định vấn đề theo cách có thể quan sát hoặc đo lường: chỉ số nào đang lệch, lệch ở đâu, từ khi nào, mức độ bao nhiêu và đối tượng nào bị ảnh hưởng. Root Cause Analysis chỉ có chất lượng khi điểm xuất phát đủ cụ thể.

Sai lầm thứ hai là xem Fishbone như danh sách nguyên nhân đã được chứng minh. Trên thực tế, những gì xuất hiện trên sơ đồ ban đầu chủ yếu là hypothesis – giả thuyết cần điều tra. ASQ mô tả Fishbone là công cụ giúp nhận diện “many possible causes”, tức nhiều nguyên nhân có khả năng liên quan, chứ không khẳng định tất cả đều là nguyên nhân thực tế. Consultant cần tiếp tục sử dụng dữ liệu, phỏng vấn, quan sát Gemba hoặc thử nghiệm để loại bỏ các giả thuyết không phù hợp.

Sai lầm thứ ba là dùng 5 Whys một cách máy móc và tin rằng câu trả lời thứ năm mặc nhiên là Root Cause. Ngay chính ASQ cũng lưu ý có thể cần ít hơn hoặc nhiều hơn năm Why. Điều quan trọng không phải số lần đặt câu hỏi mà là Consultant đã đi đến một nguyên nhân đủ sâu, có thể kiểm chứng và có khả năng giải thích vấn đề hay chưa. Nếu câu trả lời cuối cùng là “nhân viên không cẩn thận”, quá trình có thể vẫn chưa đủ sâu bởi cần tiếp tục kiểm tra điều gì trong Process, Standard Work, Training, Workload hoặc Control đã khiến sai sót dễ xảy ra.

Sai lầm cuối cùng là dừng ở phân tích mà không chứng minh nguyên nhân và tác động của giải pháp. Một Root Cause chỉ thực sự có giá trị khi thay đổi nó làm vấn đề thay đổi theo. Nếu Consultant kết luận nhiệt độ môi trường là nguyên nhân của tỷ lệ lỗi nhưng sau khi kiểm soát nhiệt độ Defect không giảm, giả thuyết cần được xem xét lại. Đây chính là tinh thần mà ASQ nhấn mạnh trong Root Cause Analysis và 8D: nguyên nhân phải được xác minh bằng bằng chứng thay vì được chọn chỉ vì đội nhóm đồng thuận.

Trong chương trình CEC Associate của John&Partners, 5 Whys và Fishbone được đặt thành những nội dung liên tiếp trong phần chẩn đoán chất lượng. Chương trình giới thiệu 5 Whys để phân biệt triệu chứng với nguyên nhân gốc, sau đó sử dụng Fishbone theo nhóm nguyên nhân 4M/6M và đặc biệt nhấn mạnh việc liên kết Fishbone – 5 Whys – CTQ thành một mạch phân tích. John&Partners cũng liệt kê Fishbone và 5 Whys trong nhóm công cụ thực hành nền tảng của CEC Associate dành cho việc phân tích nguyên nhân gốc. Cách đặt hai công cụ cạnh nhau phản ánh đúng thực tế tư vấn: Consultant không cần chọn một công cụ để thay thế công cụ còn lại mà cần biết cách kết hợp chúng trong một quá trình chẩn đoán có hệ thống.

Kết luận

5 Whys và Fishbone đều là công cụ Root Cause Analysis nhưng giải quyết hai nhu cầu khác nhau. Fishbone giúp Consultant mở rộng góc nhìn, cấu trúc nhiều nhóm nguyên nhân và tránh kết luận quá sớm; 5 Whys giúp đào sâu một nhánh nguyên nhân để đi qua các lớp triệu chứng và tìm điều kiện hệ thống nằm phía sau.

Vì vậy, Consultant không nên hỏi “5 Whys hay Fishbone tốt hơn?”. Một câu hỏi hữu ích hơn là “Ở thời điểm này tôi cần đi rộng để không bỏ sót nguyên nhân, hay cần đi sâu để hiểu một nhánh nguyên nhân cụ thể?”. Trong nhiều dự án, cách làm hiệu quả là sử dụng Fishbone để tạo bản đồ giả thuyết, sau đó dùng 5 Whys cùng dữ liệu và Gemba để kiểm chứng những nhánh quan trọng nhất.

Câu hỏi thường gặp

5 Whys là gì? 5 Whys là kỹ thuật đặt câu hỏi “Tại sao?” nhiều lần để đào sâu từ triệu chứng tới các lớp nguyên nhân của vấn đề. Con số năm mang tính hướng dẫn chứ không phải quy tắc bắt buộc.

Fishbone là gì? Fishbone hay Ishikawa Diagram là sơ đồ nguyên nhân – kết quả giúp xác định nhiều nguyên nhân có thể dẫn tới một vấn đề và sắp xếp chúng thành các nhóm để tiếp tục phân tích.

5 Whys và Fishbone khác nhau thế nào? 5 Whys thiên về đào sâu một chuỗi nguyên nhân, còn Fishbone thiên về mở rộng và cấu trúc nhiều nhóm nguyên nhân. Hai công cụ có thể được sử dụng kết hợp trong cùng một Root Cause Analysis.

Có phải hỏi đúng 5 lần trong 5 Whys không? Không. ASQ lưu ý quá trình có thể cần ít hơn hoặc nhiều hơn năm lần tùy mức độ phức tạp của vấn đề.

Fishbone có xác định được Root Cause ngay không? Không nhất thiết. Fishbone chủ yếu giúp hình thành và tổ chức các nguyên nhân khả dĩ. Consultant vẫn cần dữ liệu, quan sát và các phương pháp phù hợp để xác minh nguyên nhân thực tế.

Muốn phát triển khả năng phân biệt triệu chứng – vấn đề – nguyên nhân và sử dụng đúng công cụ trong quá trình chẩn đoán? Tìm hiểu chương trình CEC Associate – Certified Excellent Consultant tại John&Partners.