Khi tin nhắn trở thành nơi duyệt việc
Một yêu cầu mua thiết bị, tuyển thêm người hay chi một khoản nhỏ thường bắt đầu bằng một tin nhắn. Cách này nhanh khi team còn ít người. Nhưng khi số việc tăng lên, câu hỏi quan trọng không còn là “đã nhắn chưa?” mà là:
- Ai đang giữ yêu cầu?
- Nó đã đủ thông tin để quyết định chưa?
- Ai có quyền duyệt?
- Nếu quá hạn hoặc bị từ chối, chuyện gì xảy ra tiếp theo?
Một luồng duyệt tốt không cần phức tạp. Nó cần khiến mọi người nhìn vào cùng một trạng thái và hiểu bước tiếp theo là gì.
Bước 1 — Yêu cầu: đưa đủ bối cảnh vào ngay từ đầu
Đừng mở đầu bằng một ô nhắn “chị duyệt giúp em”. Mỗi loại yêu cầu nên có một mẫu ngắn, chỉ thu thập thông tin cần cho quyết định.
Với một yêu cầu chi phí, mẫu tối thiểu có thể gồm:
- mục đích và kết quả mong muốn;
- số tiền hoặc khoảng ngân sách;
- thời điểm cần quyết định;
- người chịu trách nhiệm triển khai;
- tài liệu hoặc báo giá liên quan.
Mục tiêu không phải bắt mọi người điền form dài. Mục tiêu là để người duyệt không phải hỏi lại các câu cơ bản trong nhiều vòng chat.
Bước 2 — Kiểm tra: tách điều kiện rõ ràng khỏi ý kiến cá nhân
Trước khi gửi đến người duyệt, cần có một bước kiểm tra đơn giản. Ví dụ: ngân sách có thuộc kỳ này không, yêu cầu có trùng không, người gửi có đúng vai trò không, hay đã có đủ báo giá chưa.
Các điều kiện này nên được viết thành câu có thể kiểm tra:
Yêu cầu được gửi duyệt khi có người phụ trách, có mức chi dự kiến, và có tài liệu kèm theo nếu vượt ngưỡng đã thống nhất.
Khi điều kiện chưa đủ, hệ thống không nên tự đoán. Nó trả yêu cầu về cho đúng người, kèm lý do cụ thể. Đây là cách giảm việc qua lại mà không biến quy trình thành rào cản.
Bước 3 — Phê duyệt: đúng người, đúng ngưỡng, đúng thời hạn
Một lỗi phổ biến là mọi việc đều dồn lên một người sáng lập. Điều đó tạo nút thắt và làm team chờ. Thay vào đó, hãy chốt trước ba điểm:
- Ai quyết định? Ví dụ, trưởng bộ phận duyệt nhu cầu; người phụ trách ngân sách duyệt mức chi.
- Ngưỡng nào cần chuyển cấp? Không phải mọi yêu cầu đều cần cùng một cấp duyệt.
- Bao lâu thì phải phản hồi? Nếu quá thời hạn, ai nhận cảnh báo và yêu cầu đi về đâu?
Quyền duyệt rõ không có nghĩa là cứng nhắc. Nó giúp team biết lúc nào cần hỏi ý kiến, và lúc nào có thể tự xử lý trong phạm vi đã được giao.
Bước 4 — Theo dõi: quyết định xong không có nghĩa công việc đã xong
Sau khi duyệt, nhiều team quay lại chat và mất dấu phần thực hiện. Luồng tốt cần tối thiểu các trạng thái: mới gửi, cần bổ sung, đang duyệt, đã duyệt, từ chối, đã hoàn tất.
Mỗi trạng thái nên trả lời được ba câu hỏi:
- Việc đang ở đâu?
- Ai cần làm bước tiếp theo?
- Có ngoại lệ hoặc rủi ro nào không?
Nếu một yêu cầu bị từ chối, hãy lưu lý do ngắn. Nếu đã duyệt nhưng quá hạn triển khai, hãy có nhắc việc. Nhờ vậy, dữ liệu vận hành dần trở thành cơ sở để cải thiện quy trình, thay vì chỉ là lịch sử tin nhắn.
Bắt đầu bằng một loại yêu cầu, không phải toàn công ty
Đừng cố chuẩn hóa mọi việc trong một lần. Chọn một loại yêu cầu lặp lại nhiều và gây mất thời gian nhất, chẳng hạn mua sắm nội bộ hoặc yêu cầu triển khai công việc cho khách hàng.
Trong hai tuần đầu, chỉ cần kiểm tra:
| Cần quan sát | Câu hỏi kiểm tra |
|---|---|
| Đủ thông tin | Người duyệt còn phải hỏi lại điều gì không? |
| Tốc độ | Thời gian từ gửi đến quyết định có rõ hơn không? |
| Trách nhiệm | Có yêu cầu nào không biết ai đang giữ không? |
| Ngoại lệ | Khi thiếu dữ liệu hoặc quá hạn, team xử lý có nhất quán không? |
Nếu một bước gây chậm mà không tăng chất lượng quyết định, hãy bỏ hoặc đơn giản hóa nó. Quy trình tốt là quy trình được team dùng đều, không phải quy trình đẹp trên sơ đồ.
Khi nào nên dùng công cụ hoặc tự động hóa?
Chỉ nên đưa công cụ vào khi bốn bước trên đã rõ. Khi đó, công cụ có thể giúp tạo mẫu yêu cầu, kiểm tra thông tin thiếu, gửi đến đúng người, nhắc quá hạn và lưu lịch sử quyết định.
Ngược lại, nếu chưa biết ai duyệt việc gì hoặc dữ liệu nào là nguồn chính, tự động hóa chỉ làm sự mơ hồ chạy nhanh hơn. Tinh thần này tương đồng với khuyến nghị quản trị rủi ro của NIST: cần xác định bối cảnh, trách nhiệm và cách xử lý rủi ro trước khi mở rộng việc ứng dụng công nghệ.
OXMODE có thể hỗ trợ từ đâu?
OXMODE bắt đầu bằng việc cùng team nhìn vào một luồng công việc thật: ai gửi, ai quyết, dữ liệu nằm ở đâu và điểm nào đang bị chờ. Từ đó, team có thể chọn một quy trình vừa đủ nhỏ để thử, nhưng đủ giá trị để tạo thay đổi rõ ràng.
Nguồn tham khảo
- NIST, AI Risk Management Framework — tham chiếu về xác định bối cảnh, trách nhiệm và quản trị rủi ro khi áp dụng công nghệ.
- Google Search Central, Creating helpful, reliable, people-first content — nguyên tắc nội dung hữu ích, rõ ràng và phục vụ người đọc trước.
