Những sai lầm phổ biến khi xác định vấn đề

Điểm nguy hiểm là một phát biểu vấn đề vẫn có thể nghe rất hợp lý nhưng dẫn toàn bộ quá trình sau đó đi sai hướng. Khi câu hỏi ban đầu sai, dữ liệu được thu thập, nguyên nhân được tìm kiếm và tiêu chí lựa chọn giải pháp cũng dễ bị lệch theo.

Nhầm triệu chứng với vấn đề cốt lõi

Triệu chứng là biểu hiện quan sát được; vấn đề cốt lõi là trạng thái hoặc cơ chế tạo ra biểu hiện đó. Hai yếu tố có liên quan nhưng không đồng nhất.

Chẳng hạn, “khách hàng phàn nàn nhiều” mô tả một tín hiệu. Nếu xem đây là vấn đề hoàn chỉnh, doanh nghiệp có thể tập trung tăng nhân sự chăm sóc khách hàng. Nhưng khi các khiếu nại thực tế bắt nguồn từ giao hàng sai, thông tin sản phẩm không rõ hoặc quy trình đổi trả phức tạp, tăng nhân sự chỉ xử lý phần hậu quả.

Sai lầm này dẫn đến giải pháp không phù hợp vì giải pháp được thiết kế để làm giảm biểu hiện thay vì tác động vào điều kiện tạo ra biểu hiện. Triệu chứng vẫn có giá trị: nó cho biết nơi cần điều tra, nhưng chưa đủ để kết luận phải sửa gì.

Một cách kiểm tra đơn giản là hỏi: nếu biểu hiện này biến mất tạm thời, nguyên nhân khiến nó xuất hiện có còn tồn tại không? Nếu câu trả lời là có, phát biểu hiện tại nhiều khả năng mới dừng ở triệu chứng.

Đóng khung vấn đề quá sớm

Đóng khung quá sớm xảy ra khi một cách diễn giải ban đầu nhanh chóng trở thành “sự thật”, khiến những khả năng khác không còn được xem xét nghiêm túc.

Ví dụ, doanh số giảm có thể lập tức được mô tả thành “đội bán hàng hoạt động kém”. Từ cách đóng khung đó, quá trình phân tích dễ tập trung vào kỹ năng bán hàng, chỉ tiêu và năng suất nhân viên. Trong khi đó, doanh số còn có thể chịu tác động từ giá, nhu cầu thị trường, chất lượng khách hàng tiềm năng, thay đổi sản phẩm hoặc tỷ lệ khách hàng quay lại.

Cơ chế gây sai lệch nằm ở phạm vi tìm kiếm: cách định nghĩa ban đầu quyết định dữ liệu nào được xem là liên quan và nguyên nhân nào được ưu tiên kiểm tra. Khi phạm vi đã bị thu hẹp trước khi có đủ thông tin, bằng chứng trái với giả định ban đầu dễ bị bỏ qua.

Một phát biểu vấn đề tốt vì vậy nên mô tả hiện trạng trước khi gắn trách nhiệm hoặc giải thích nguyên nhân. “Doanh số quý này thấp hơn mục tiêu ở nhóm khách hàng X” để ngỏ nhiều hướng kiểm tra hơn “đội bán hàng nhóm X không đủ năng lực”.

Coi nguyên nhân giả định là nguyên nhân đã được xác định

Một lỗi phổ biến khác là đưa luôn nguyên nhân chưa được kiểm chứng vào câu mô tả vấn đề.

Các câu như “nhân viên thiếu động lực nên năng suất thấp” hay “website chậm vì máy chủ yếu” chứa hai phần khác nhau: một hiện tượng có thể quan sát và một giải thích cần được kiểm tra. Nếu hai phần bị gộp thành một kết luận, quá trình giải quyết vấn đề dễ biến thành quá trình tìm bằng chứng cho giả định sẵn có.

Hệ quả là giải pháp thường bám trực tiếp vào nguyên nhân giả định. Nếu cho rằng nhân viên thiếu động lực, tổ chức có thể thay đổi thưởng; nếu cho rằng máy chủ yếu, doanh nghiệp có thể nâng cấp hạ tầng. Nhưng các hành động đó không xử lý được vấn đề khi nguyên nhân thật nằm ở quy trình, phân bổ công việc, mã nguồn, cấu hình hay một yếu tố khác.

Cần tách rõ ba lớp: điều gì đang xảy ra, bằng chứng nào cho thấy nó đang xảy ra và nguyên nhân nào mới chỉ là giả thuyết. Nguyên nhân chỉ nên trở thành căn cứ lựa chọn giải pháp sau khi đã có dữ liệu hoặc quan sát đủ để phân biệt nó với các khả năng cạnh tranh.

Xác định phạm vi vấn đề quá rộng hoặc quá hẹp

Một vấn đề quá rộng thường không cho biết chính xác cần can thiệp vào đâu. “Dịch vụ khách hàng kém”, “chi phí quá cao” hoặc “quy trình không hiệu quả” đều có thể đúng nhưng chứa quá nhiều thành phần để trực tiếp dẫn đến một giải pháp cụ thể.

Ngược lại, phạm vi quá hẹp có thể cô lập một chi tiết khỏi hệ thống tạo ra nó. Ví dụ, chỉ xem “thời gian nhập dữ liệu ở bước cuối quá lâu” là vấn đề có thể dẫn đến việc tối ưu thao tác nhập liệu, trong khi nguyên nhân thực tế là dữ liệu từ các bước trước thiếu chuẩn hóa nên nhân viên phải kiểm tra và sửa lại.

Phạm vi hợp lý phải đủ hẹp để có thể điều tra và hành động, nhưng đủ rộng để giữ những quan hệ nhân quả quan trọng. Có thể kiểm tra bằng bốn yếu tố: đối tượng nào gặp vấn đề, trạng thái nào đang lệch, phạm vi hoặc thời điểm nào xảy ra và mức mong muốn là gì.

Thay vì “quy trình giao hàng có vấn đề”, một mô tả như “đơn hàng nội thành thường hoàn tất muộn hơn thời gian đã cam kết ở giai đoạn bàn giao cho đơn vị vận chuyển” tạo ranh giới rõ hơn mà chưa áp đặt nguyên nhân.

Bỏ qua dữ liệu và góc nhìn của người chịu tác động

Vấn đề thường được định nghĩa bởi người quản lý hoặc người chịu trách nhiệm xử lý, nhưng họ không nhất thiết quan sát đầy đủ cách vấn đề xuất hiện trong thực tế.

Ví dụ, một đội sản phẩm có thể cho rằng người dùng bỏ dở đăng ký vì biểu mẫu quá dài. Người dùng lại có thể dừng ở bước yêu cầu thông tin mà họ không hiểu lý do phải cung cấp. Hai cách nhìn dẫn đến hai giải pháp khác nhau: rút ngắn biểu mẫu hoặc làm rõ yêu cầu và mức độ cần thiết của dữ liệu.

Góc nhìn của các bên liên quan không tự động chứng minh nguyên nhân, nhưng nó mở rộng tập hợp bằng chứng cần kiểm tra. Dữ liệu hành vi, phản hồi trực tiếp, quan sát quy trình và thông tin từ người thực hiện công việc có thể cho thấy sự khác biệt giữa vấn đề được giả định và vấn đề thực sự trải nghiệm.

Sai lầm cần tránh ở đây là thay thế dữ liệu bằng ý kiến có thẩm quyền. Người ra quyết định có thể hiểu mục tiêu của hệ thống, còn người vận hành hoặc người sử dụng thường nhìn thấy những điểm ma sát mà cấp quản lý không trực tiếp gặp. Hai loại thông tin cần được đối chiếu thay vì chọn một bên làm mặc định.

Viết vấn đề dưới dạng một giải pháp đã chọn

Đây là một trong những sai lầm khi xác định vấn đề dễ làm mất nhiều lựa chọn nhất. Nó xuất hiện khi câu mô tả vấn đề thực chất nói rằng tổ chức đang thiếu một giải pháp cụ thể.

“Chúng ta cần triển khai chatbot”, “cần thêm nhân viên” hay “cần một phần mềm quản lý mới” đều là đề xuất hành động, chưa phải mô tả vấn đề. Khi giải pháp được đặt vào vị trí của vấn đề, quá trình phân tích chỉ còn nhiệm vụ chứng minh tại sao phương án đó nên được triển khai.

Cách diễn đạt này che khuất nhu cầu thực sự. “Cần chatbot” có thể bắt nguồn từ thời gian phản hồi dài, khối lượng câu hỏi lặp lại hoặc chi phí hỗ trợ tăng. Mỗi vấn đề có thể cần một giải pháp khác nhau; thậm chí chatbot có thể không phải phương án phù hợp nhất.

Để phát hiện lỗi này, có thể thử loại tên giải pháp khỏi câu và hỏi: trạng thái không mong muốn nào vẫn còn phải được giải quyết? Nếu chưa mô tả được trạng thái đó, vấn đề chưa được xác định độc lập với phương án.

Một phát biểu tốt nên cho phép tồn tại nhiều giải pháp cạnh tranh. Khi chỉ có một giải pháp dường như “đúng” ngay từ câu xác định vấn đề, cần kiểm tra xem câu hỏi ban đầu có đang bị thiết kế quanh lựa chọn sẵn có hay không.

Xác định vấn đề không phải là tìm một câu mô tả nghe hợp lý, mà là thiết lập đúng đối tượng cần giải quyết trước khi lựa chọn cách can thiệp. Những lỗi đáng chú ý nhất là nhầm triệu chứng với vấn đề, đóng khung quá sớm, biến giả định nguyên nhân thành kết luận, đặt phạm vi sai, bỏ qua dữ liệu thực tế và viết vấn đề dưới dạng giải pháp.

Một phép kiểm tra hữu ích trước khi đi tìm giải pháp là xem phát biểu vấn đề có mô tả rõ điều gì đang xảy ra, với ai hoặc ở đâu, khác trạng thái mong muốn như thế nào, đồng thời vẫn để ngỏ câu hỏi về nguyên nhân và phương án xử lý. Nếu câu mô tả đã chứa sẵn lời giải hoặc một nguyên nhân chưa được chứng minh, rủi ro chọn sai giải pháp bắt đầu ngay từ bước xác định vấn đề.