Just culture (thường dịch là văn hoá công bằng) là cách tổ chức phản ứng với sai sót dựa trên bản chất hành vi chứ không dựa trên mức độ hậu quả: lỗi vô ý được hỗ trợ và sửa hệ thống, hành vi chấp nhận rủi ro được huấn luyện lại, còn hành vi cố ý vi phạm hoặc liều lĩnh thì bị xử lý. Văn hoá không đổ lỗi (blameless) là thực hành đi kèm: khi phân tích sự cố, câu hỏi là “điều gì đã xảy ra và vì sao hệ thống cho phép nó xảy ra”, không phải “ai có lỗi”.
Hai khái niệm này ra đời từ những ngành mà sai sót có thể gây chết người, như hàng không và y tế, và ngày nay được dùng rộng rãi trong vận hành phần mềm, sản xuất, logistics. Chúng giải quyết một mâu thuẫn mà mọi nhà quản lý gặp: muốn nhân viên báo cáo lỗi để học, nhưng cũng không muốn ai vô trách nhiệm.
Vì sao đổ lỗi làm tổ chức kém an toàn hơn
Khi một sự cố xảy ra, phản xạ tự nhiên là tìm người gây ra nó. Người cuối cùng chạm vào hệ thống, người bấm nhầm nút, người ký duyệt, thường bị coi là nguyên nhân. James Reason, nhà tâm lý học người Anh, trong cuốn Managing the Risks of Organizational Accidents (1997) chỉ ra rằng phần lớn sự cố lớn là kết quả của nhiều lớp phòng vệ cùng có lỗ hổng, mô hình thường được gọi là “pho mát Thuỵ Sĩ”. Người tuyến đầu chỉ là lớp cuối cùng; những lỗ hổng phía trước nằm ở thiết kế, quy trình, áp lực tiến độ, đào tạo, cách phân bổ nguồn lực.
Đổ lỗi cá nhân tạo ra hai hệ quả xấu. Thứ nhất, nó đóng cuộc điều tra quá sớm: khi đã tìm được người có lỗi, không ai đào tiếp vào những lỗ hổng hệ thống, nên sự cố tương tự sẽ lặp lại với người khác. Thứ hai, nó khiến mọi người giấu lỗi và giấu các tình huống suýt xảy ra sự cố, vốn là nguồn thông tin quý nhất để phòng ngừa.
Một thiên kiến góp phần vào vòng đổ lỗi là thiên kiến nhìn lại (hindsight bias): khi đã biết kết quả, người ta đánh giá quá cao khả năng người trong cuộc lẽ ra phải thấy trước. Sidney Dekker, trong các công trình về just culture từ năm 2007, nhấn mạnh rằng muốn hiểu sai sót, phải tái hiện điều người đó biết và thấy vào thời điểm đó, chứ không phải điều ta biết bây giờ.
Ba loại hành vi và cách phản ứng tương ứng
David Marx, kỹ sư và luật sư người Mỹ, hệ thống hoá just culture đầu thập niên 2000 thành ba loại hành vi, dùng phổ biến trong y tế và hàng không:
| Loại hành vi | Mô tả | Ví dụ trong doanh nghiệp | Phản ứng phù hợp |
|---|---|---|---|
| Lỗi do người | Vô ý làm khác với dự định: nhầm, sót, trượt tay | Nhân viên kho nhập nhầm mã hàng do hai mã gần giống nhau | An ủi, hỗ trợ; sửa hệ thống để lỗi khó xảy ra (đổi mã, thêm bước quét) |
| Hành vi rủi ro | Chọn cách làm tắt vì không nhận ra rủi ro hoặc tin rằng rủi ro nhỏ, thường do cả nhóm đều làm vậy | Kỹ sư bỏ qua bước kiểm tra trên môi trường thử vì “lần nào cũng ổn” và bị ép tiến độ | Huấn luyện, làm rõ rủi ro; tìm hiểu vì sao làm tắt trở thành bình thường; giảm động cơ làm tắt |
| Hành vi liều lĩnh | Biết rõ rủi ro đáng kể mà vẫn cố ý bỏ qua, không có lý do chính đáng | Tài xế tắt thiết bị giám sát hành trình để chạy quá tốc độ | Xử lý kỷ luật theo nội quy, bất kể có gây hậu quả hay không |
Điểm cốt lõi: phản ứng dựa trên loại hành vi, không dựa trên hậu quả. Hai nhân viên cùng làm tắt một bước, một người không gây hậu quả và một người gây thiệt hại lớn, nên được đối xử giống nhau. Nếu chỉ người gặp xui bị phạt, tổ chức đang trừng phạt sự không may và dạy mọi người rằng điều quan trọng là đừng để bị phát hiện.
Lịch sử: từ hàng không đến phần mềm
Năm 1976, Hệ thống Báo cáo An toàn Hàng không (ASRS) của Mỹ bắt đầu hoạt động, do NASA vận hành như một bên thứ ba độc lập với cơ quan quản lý. Phi công, kiểm soát viên không lưu và nhân viên kỹ thuật có thể báo cáo sự cố và tình huống suýt xảy ra, với cơ chế bảo mật và trong những điều kiện nhất định được miễn hoặc giảm chế tài. Hàng trăm nghìn báo cáo đã giúp ngành hàng không phát hiện những mô thức rủi ro mà không cuộc điều tra tai nạn đơn lẻ nào thấy được.
Quân đội Mỹ phát triển phương pháp Đánh giá sau hành động (After Action Review) từ thập niên 1970, với bốn câu hỏi: dự định điều gì xảy ra, điều gì đã thực sự xảy ra, vì sao có khác biệt, lần sau làm gì. Phương pháp này sau đó lan sang doanh nghiệp.
Trong ngành phần mềm, cuốn Site Reliability Engineering do các kỹ sư Google viết, xuất bản năm 2016, phổ biến khái niệm blameless postmortem: mọi sự cố đáng kể đều có một văn bản phân tích, tập trung vào chuỗi sự kiện, nguyên nhân góp phần và hành động khắc phục, tuyệt đối không quy lỗi cá nhân. Văn bản được chia sẻ rộng để cả tổ chức học. Nhiều công ty công nghệ tại Việt Nam đã áp dụng thực hành này trong đội vận hành hệ thống.
Quy trình họp rút kinh nghiệm không đổ lỗi
Quy trình sau dùng được cho sự cố sản xuất, khiếu nại khách hàng nghiêm trọng, dự án trễ hạn hay lỗi hệ thống. Nên áp dụng trong vòng vài ngày sau sự cố khi trí nhớ còn rõ:
- Tuyên bố nguyên tắc ngay đầu buổi. Người điều phối nói rõ mục đích là hiểu và cải thiện hệ thống, không ai bị xử lý vì những gì chia sẻ trong buổi này, trừ trường hợp phát hiện hành vi liều lĩnh cố ý.
- Dựng dòng thời gian. Ghi lại sự kiện theo thứ tự với mốc thời gian: ai biết gì, khi nào, quyết định gì đã được đưa ra. Mời người trong cuộc kể lại bằng lời của họ.
- Hỏi “làm thế nào” thay vì “tại sao”. “Tại sao anh làm vậy?” nghe như buộc tội. “Lúc đó anh thấy thông tin gì? Điều gì khiến lựa chọn đó có vẻ hợp lý?” giúp tái hiện góc nhìn tại thời điểm đó.
- Tìm các yếu tố góp phần. Thay vì một nguyên nhân gốc duy nhất, liệt kê nhiều yếu tố: thiết kế giao diện, áp lực thời gian, thiếu cảnh báo, tài liệu lỗi thời, phân công mơ hồ. Kỹ thuật “5 lần tại sao” hữu ích nhưng dễ dẫn tới chuỗi đơn tuyến, nên kết hợp với sơ đồ xương cá.
- Xác định hành động cụ thể. Mỗi hành động có người chịu trách nhiệm và hạn chót, ưu tiên thay đổi hệ thống (tự động hoá kiểm tra, sửa quy trình) hơn là “nhắc nhở nhân viên cẩn thận hơn”.
- Viết và chia sẻ. Văn bản ngắn gọn, không nêu tên người theo hướng quy lỗi, chia sẻ cho các nhóm liên quan.
- Theo dõi việc thực hiện. Rà lại sau một tháng xem hành động đã làm chưa. Họp rút kinh nghiệm mà không ai thực hiện hành động là cách nhanh nhất làm mất niềm tin vào quy trình.
Một dấu hiệu quy trình đang vận hành tốt là số báo cáo tình huống suýt xảy ra tăng lên trong những tháng đầu. Đó không phải là an toàn giảm đi, mà là thông tin bắt đầu lộ ra.
Đo xem văn hoá học từ sai sót có đang vận hành
Chỉ số sự cố thấp không chứng minh tổ chức an toàn hay học tốt; nó có thể chỉ phản ánh việc ít người báo cáo. Vì vậy cần một bộ chỉ báo khác. Chỉ báo thứ nhất là tỷ lệ giữa báo cáo tình huống suýt xảy ra và sự cố thật: tổ chức có văn hoá báo cáo tốt thường ghi nhận nhiều tình huống suýt xảy ra hơn hẳn sự cố, còn nếu hai con số xấp xỉ nhau thì nhiều khả năng các tình huống suýt xảy ra đang bị bỏ qua.
Chỉ báo thứ hai là thời gian từ khi phát hiện đến khi báo cáo. Khi người ta tin rằng báo cáo không bị trừng phạt, khoảng thời gian này rút ngắn rõ rệt. Chỉ báo thứ ba là tỷ lệ hành động khắc phục được hoàn thành đúng hạn, phản ánh việc tổ chức có thật sự học hay chỉ họp. Chỉ báo thứ tư là tỷ lệ sự cố lặp lại cùng nguyên nhân sau khi đã có hành động khắc phục.
Bên cạnh số liệu, có thể khảo sát ngắn với câu hỏi như “nếu bạn mắc một lỗi không ai phát hiện, bạn có báo cáo không?” và “lần gần nhất có người báo lỗi trong nhóm, chuyện gì xảy ra với họ?”. Câu trả lời cho câu thứ hai thường cho biết nhiều hơn mọi chính sách viết trên giấy.
Những hiểu lầm thường gặp
Không đổ lỗi nghĩa là không ai chịu trách nhiệm. Sai. Just culture vẫn xử lý hành vi liều lĩnh và vi phạm cố ý. Ngoài ra, trách nhiệm được hiểu theo hướng tương lai: người liên quan có trách nhiệm kể lại trung thực và tham gia khắc phục.
Chỉ phù hợp với ngành nguy hiểm. Cơ chế học từ sai sót áp dụng cho mọi công việc có lỗi lặp lại tốn kém: kế toán nhầm số liệu, giao hàng sai địa chỉ, chiến dịch marketing gửi nhầm danh sách khách. Chi phí không phải tính mạng, nhưng vẫn là tiền và uy tín.
Sửa hệ thống tốn kém hơn phạt người. Phạt có vẻ rẻ vì không tốn ngân sách, nhưng nếu không sửa lỗ hổng, sự cố sẽ lặp lại với người khác. Nhiều thay đổi hệ thống rất rẻ: đổi màu nhãn, thêm một bước xác nhận, viết lại một câu hướng dẫn.
Quản lý cấp cao được miễn. Quyết định của lãnh đạo, như cắt nguồn lực hay ép tiến độ, thường là yếu tố góp phần quan trọng. Một quy trình rút kinh nghiệm thật phải được phép chỉ ra các quyết định này mà người nói không bị trả đũa.
Câu hỏi thường gặp
Just culture có mâu thuẫn với nội quy lao động không?
Không, nếu được thiết kế đồng bộ. Nội quy vẫn quy định hành vi vi phạm và hình thức kỷ luật theo pháp luật; just culture bổ sung nguyên tắc rằng lỗi vô ý được báo cáo kịp thời sẽ không bị xử lý kỷ luật. Doanh nghiệp nên rà soát nội quy để hai thứ không mâu thuẫn và tham khảo chuyên gia pháp lý khi cần.
Làm sao phân biệt hành vi rủi ro và hành vi liều lĩnh trong thực tế?
Một phép thử là hỏi liệu những người khác có cùng năng lực, trong cùng hoàn cảnh, có thể chọn như vậy không. Nếu nhiều người cũng làm tắt như thế, đó là hành vi rủi ro phản ánh vấn đề hệ thống. Nếu người đó biết rõ và cố ý bỏ qua một quy định an toàn mà người khác đều tuân thủ, nhiều khả năng là liều lĩnh.
Có nên công khai tên người liên quan trong báo cáo sự cố?
Thông lệ blameless là mô tả theo vai trò, như “kỹ sư trực ca”, thay vì nêu tên theo hướng quy lỗi. Người trong cuộc có thể tự nguyện được ghi tên để ghi nhận sự hợp tác. Mục tiêu là để người đọc tập trung vào chuỗi sự kiện và bài học.
Thưởng cho người báo cáo lỗi có hiệu quả không?
Ghi nhận công khai việc báo cáo sớm, đặc biệt tình huống suýt xảy ra, thường giúp văn hoá chuyển biến nhanh. Nhưng thưởng tiền theo số báo cáo dễ tạo báo cáo hình thức. Cách bền là cho người báo cáo thấy báo cáo của họ dẫn tới thay đổi cụ thể.
Doanh nghiệp nhỏ có cần quy trình chính thức không?
Không cần phức tạp. Một mẫu ghi chép một trang với các mục: chuyện gì xảy ra, dòng thời gian, các yếu tố góp phần, hành động khắc phục, người phụ trách, cùng một buổi họp ba mươi phút sau mỗi sự cố đáng kể là đủ để bắt đầu. Quan trọng là chủ doanh nghiệp giữ đúng nguyên tắc không quy lỗi.
Khi khách hàng đòi “xử lý người có lỗi” thì làm thế nào?
Có thể giải thích với khách rằng doanh nghiệp chịu trách nhiệm với tư cách tổ chức và trình bày hành động khắc phục hệ thống để sự cố không lặp lại. Phần lớn khách hàng quan tâm đến việc vấn đề được giải quyết và không tái diễn hơn là việc một nhân viên cụ thể bị phạt.
