Nhìn lại sau sự cố: rút bài học không đổ lỗi

Một chiến dịch quảng cáo đốt ngân sách sai. Một lô hàng ra trễ. Một listing đăng nhầm giá. Sự cố xảy ra ở mọi công ty. Điều phân biệt các công ty không phải có sự cố hay không, mà cách họ xử lý sau đó: tìm người để đổ lỗi, hay tìm bài học để không lặp lại.

Sự cố là dữ liệu, không phải tòa án

Phản xạ tự nhiên khi có sự cố là tìm ai gây ra. Phản xạ đó dễ hiểu, nhưng nó làm hỏng chính thứ ta cần: sự thật.

Khi người ta sợ bị đổ lỗi, họ giấu. Họ kể phiên bản có lợi cho mình, bỏ qua chi tiết bất lợi. Và khi thông tin bị bóp méo, ta không bao giờ tìm ra nguyên nhân thật. Một buổi nhìn lại sau sự cố không đổ lỗi (blameless) đảo ngược điều đó: coi sự cố là một mẩu dữ liệu để mổ xẻ, không phải một phiên tòa để tuyên án.

Vì sao "không đổ lỗi" lại hiệu quả hơn

Nghe qua, "không đổ lỗi" dễ bị hiểu là "không ai chịu trách nhiệm". Thực ra ngược lại.

Không đổ lỗi nghĩa là tách con người khỏi lỗi hệ thống. Giả định nền tảng: hầu hết mọi người đến làm với ý định tốt và năng lực đủ. Nếu một người có năng lực vẫn mắc lỗi, thì rất có thể hệ thống đã tạo điều kiện cho lỗi đó — thiếu một bước kiểm tra, một hướng dẫn mập mờ, một cảnh báo lẽ ra phải có. Sửa hệ thống chặn được lỗi cho tất cả mọi người. Trách một cá nhân chỉ khiến người tiếp theo lặp lại đúng lỗi đó.

Hỏi "hệ thống nào đã cho phép điều này xảy ra" đưa ta đi xa hơn nhiều so với hỏi "ai đã làm điều này".

Cách chạy một buổi nhìn lại

Một buổi nhìn lại sau sự cố không cần cầu kỳ. Nó đi qua vài bước rõ ràng.

1. Dựng lại dòng thời gian. Chuyện gì đã xảy ra, theo đúng thứ tự, chỉ ghi sự việc — không bình luận, không quy trách.
2. Tìm nguyên nhân gốc (root cause). Hỏi "tại sao" nhiều lần cho đến khi chạm tới nguyên nhân hệ thống, không dừng ở triệu chứng bề mặt. Cách này hay được gọi là 5 Whys (hỏi "tại sao" năm lần).
3. Hỏi điều gì lẽ ra đã chặn được nó. Bước kiểm tra nào, cảnh báo nào, quy trình nào, nếu có, sẽ ngăn được sự cố?
4. Chốt hành động cụ thể. Mỗi bài học biến thành một thay đổi có người chịu trách nhiệm và có thời hạn.

Một ví dụ về 5 Whys: listing đăng sai giá. Tại sao? Vì nhập tay nhầm số. Tại sao nhập tay dẫn tới sai? Vì chưa có bước kiểm tra trước khi đăng. Tại sao chưa có? Vì quy trình đăng listing chưa gồm bước rà giá. Nguyên nhân gốc không phải "người nhập ẩu", mà "quy trình thiếu một bước kiểm tra".

Từ triệu chứng đến hệ thống

Điểm mấu chốt của cả buổi là kéo câu hỏi từ con người sang hệ thống. "Ai làm sai" dẫn tới một lời xin lỗi và không có gì thay đổi. "Hệ thống nào cho phép việc này" dẫn tới một thay đổi cụ thể ngăn được lần sau.

Điều này không có nghĩa cá nhân không bao giờ chịu trách nhiệm. Nó có nghĩa: khởi điểm luôn là hệ thống. Chỉ khi đã loại hết các nguyên nhân hệ thống mà vẫn còn vấn đề, câu chuyện mới chuyển sang con người. Trong phần lớn trường hợp, chỉ riêng việc sửa hệ thống đã đủ để vấn đề không tái diễn.

Biến bài học thành thay đổi dùng lại được

Một buổi nhìn lại chỉ có giá trị nếu nó để lại thay đổi. Bài học rút ra mà không đổi cách làm thì lần sau sự cố lặp y nguyên.

Cách giữ bài học là ghi nó vào chính quy trình. Một bước kiểm tra được thêm vào SOP (standard operating procedure — quy trình thao tác chuẩn). Một mục mới trong danh sách rà trước khi đăng. Một cảnh báo tự động được dựng lên. Khi bài học nằm trong quy trình, nó bảo vệ cả những người chưa từng nghe về sự cố gốc. Đây chính là cách hệ thống vận hành của một tổ chức mạnh lên qua thời gian.

Cùng xây

Nhìn lại sau sự cố mà không đổ lỗi không phải sự dễ dãi. Nó là kỷ luật: kỷ luật đi tới tận nguyên nhân gốc thay vì dừng ở người gần nhất, và kỷ luật biến mỗi sự cố thành một hệ thống tốt hơn. Một tổ chức làm được điều này sẽ mạnh dần lên sau mỗi lần vấp, thay vì chỉ tìm người thế tội rồi vấp lại.

Cách làm này ăn khớp với hai giá trị của Equarus: quyết định bằng data, và tư duy builder — thấy quy trình chưa ổn thì chủ động sửa. Đọc thêm ở Bốn giá trị cốt lõi trong công việc hằng ngày. Nếu bạn muốn làm ở một nơi coi sự cố là cơ hội học, không phải cơ hội đổ lỗi, xem các vị trí đang tuyển.