Automation báo thành công nhưng nghiệp vụ vẫn thất bại: kiểm tra business outcome
Phân biệt technical success với business success và thiết kế workflow có outcome assertion, reconciliation, audit trail và cơ chế khôi phục.
Một workflow chỉ thật sự thành công khi kết quả nghiệp vụ mong muốn đã xảy ra và có bằng chứng xác nhận. Node trả HTTP 200, execution chuyển sang màu xanh hoặc dữ liệu đã được ghi vào một bảng trung gian chỉ chứng minh bước kỹ thuật đã hoàn tất. Chúng không chứng minh khách đã nhận email, đơn hàng đã được tạo đúng, hóa đơn đã được duyệt hay CRM đã phản ánh trạng thái cuối cùng.
Để tránh “false success”, hãy định nghĩa business outcome trước khi xây workflow, tạo outcome assertion ở cuối luồng, đối soát định kỳ với hệ thống đích và tách lỗi thành retry, repair hoặc manual review. Đây là khác biệt giữa một automation chạy được và một quy trình có thể vận hành lâu dài.
Khoảng cách
Technical success khác business success ở đâu?
Thành công của API không phải lúc nào cũng là thành công của khách hàng.
Giả sử workflow nhận đơn hàng, gọi API tạo invoice và gửi email. API invoice trả 200 nhưng tạo bản ghi ở trạng thái draft; dịch vụ email chấp nhận request nhưng địa chỉ bị bounce; node cuối vẫn chạy xong. Dashboard hiển thị thành công trong khi khách không nhận được hóa đơn hợp lệ.
Lỗi kiểu này xuất hiện khi success criterion được đặt ở biên hệ thống thay vì ở kết quả cuối. Nó cũng xảy ra với eventual consistency, xử lý bất đồng bộ, webhook đến muộn, mapping sai nhưng hợp lệ về schema, hoặc API trả “accepted” thay vì “completed”. Cơ chế retry thông thường không phát hiện vì không có exception.
