Sáng gửi báo giá cho khách, chiết khấu đang là 5%. Chiều khách xác nhận đặt hàng, mở lại thấy 15%.
Sales hỏi kế toán. Kế toán hỏi trưởng nhóm. Trưởng nhóm nhắn vào group:
- “Ai vừa sửa chiết khấu đơn này?”
- “Em có sửa đâu.”
- “Em chỉ cập nhật số lượng.”
- “Hình như hôm qua anh có nhờ ai chỉnh lại.”
Thế là cả team lục tin nhắn, tìm ảnh chụp màn hình, nhớ lại ai đã mở đơn. Khách đang chờ xác nhận, còn mọi người bận dựng lại chuyện đã xảy ra.
Dữ liệu hiện tại cho biết đơn hàng đang được chiết khấu 15%. Nhưng con số đó xuất hiện từ lúc nào, qua thao tác nào?
Đó là lúc cần đến Audit Trail.
Audit Trail là gì?
Audit Trail có thể hiểu là dấu vết ghi lại các hoạt động trong hệ thống. Với lịch sử thay đổi dữ liệu, những thông tin thường cần tra cứu gồm:
-
Tài khoản thực hiện thao tác.
-
Thời điểm thay đổi.
-
Bản ghi và trường dữ liệu bị tác động.
-
Giá trị trước và sau khi sửa, nếu hệ thống có ghi nhận.
Ví dụ, Microsoft Dataverse hỗ trợ tra cứu người cập nhật, thời điểm, trường bị sửa và giá trị trước đó khi auditing được bật cho dữ liệu liên quan.
Một dòng lịch sử minh họa cho tình huống trên có thể như sau:
| Thời điểm | Tài khoản | Bản ghi | Nội dung thay đổi |
|---|---|---|---|
| 14:32 | sales.lan | Báo giá BG-024 | Chiết khấu: 5% → 15% |
Team đã có một mốc cụ thể để kiểm tra. Có thể Lan nhập nhầm. Có thể Lan đang làm theo một yêu cầu mới. Cũng có thể cần kiểm tra việc sử dụng tài khoản.
Lịch sử cho biết thao tác được ghi nhận dưới tài khoản nào. Lý do thay đổi vẫn cần được đối chiếu với yêu cầu và quy trình.
Có lịch sử thay đổi, team xử lý khác đi thế nào?
1. Khoanh vùng sự cố nhanh hơn
Thay vì hỏi lần lượt từng người, team bắt đầu từ đúng bản ghi, đúng trường và đúng thời điểm. Sau đó kiểm tra báo giá nào đã gửi khách, đơn nào đã xác nhận để xác định phạm vi ảnh hưởng.
2. Có căn cứ khi bàn giao
Người nhận ca mở một yêu cầu và thấy trạng thái hiện tại là “Đã xử lý”. Lịch sử chuyển trạng thái giúp họ lần lại diễn biến trước đó, rồi đối chiếu với ghi chú hoặc kết quả bàn giao.
3. Nhìn ra chỗ quy trình cần sửa
Nếu chiết khấu thường xuyên bị chỉnh sau khi báo giá đã được duyệt, Solution Builder cần xem lại: ai được sửa, sửa trong trường hợp nào, thay đổi nào phải duyệt lại?
Một sự cố cụ thể có thể dẫn đến việc điều chỉnh quyền truy cập hoặc luồng phê duyệt.
Solution Builder nên tính chuyện này từ lúc thiết kế
Với app báo giá, hãy thử đặt tình huống:
“Báo giá đã duyệt nhưng có người đổi chiết khấu. Ngày mai khách hỏi, team cần tra lại những gì?”
Từ đó xác định:
-
Những dữ liệu cần theo dõi, như đơn giá, chiết khấu, trạng thái duyệt.
-
Người được phép xem lịch sử.
-
Khoảng thời gian cần lưu để phục vụ đối chiếu.
-
Cách ghi nhận lý do cho các thay đổi quan trọng.
Cần kiểm tra khả năng và cấu hình của nền tảng đang dùng. Chẳng hạn, Dataverse yêu cầu bật auditing ở các phạm vi phù hợp và cấp quyền xem lịch sử; thời gian lưu cũng có thể được cấu hình.
Lần tới khi kiểm tra app, bạn có thể thử sửa một dữ liệu quan trọng rồi nhờ người khác tìm lại: ai sửa, sửa gì, lúc nào?
Nếu họ vẫn phải nhắn group để hỏi, đây là một điểm đáng xem lại trong thiết kế.
Bạn từng phải lục tin nhắn hoặc ảnh chụp màn hình để chứng minh một thông tin trước đó chưa? Lần ấy bạn tìm ra bằng cách nào?