Tìm hiểu ủy quyền phê duyệt trong quy trình với chế độ nghỉ phép, quy tắc người thay thế và lịch sử phê duyệt rõ ràng phục vụ kiểm toán và giảm trì hoãn.
Phê duyệt bị đình trệ vì một lý do đơn giản: quy trình chờ một người cụ thể, và hệ thống không biết phải làm gì khi người đó không online. Một yêu cầu đến hộp thư của họ, chẳng ai khác có quyền hành động, và mọi thứ dừng lại.
Tình huống tệ hơn khi phê duyệt gắn với tên cá nhân thay vì vai trò. Nhóm thay đổi, người nghỉ phép, quản lý đi công tác. Nếu quy trình không tự chuyển sang người thay thế, bạn sẽ nhận được những thông báo “khẩn” liên tục, giải pháp thủ công, và quyết định bị trễ.
Cũng cần phân biệt một vài hành động giống nhau mà mọi người dễ nhầm:
Mục tiêu thực sự không chỉ là tốc độ. Là tính dự đoán được và một hồ sơ rõ ràng.
"Minh bạch" với quản lý và kiểm toán nghĩa là hai điều: bạn có thể thấy lý do vì sao quy trình chuyển sang người thay thế, và bạn có thể chứng minh ai đã phê duyệt, khi nào và theo quy tắc nào. Nếu Alex đi nghỉ và Priya phê duyệt một khoản mua, lịch sử phải cho thấy Priya đã hành động như đại diện của Alex. Nó không nên trông như Alex đã phê duyệt, và cũng không được biến mất trong một cuộc trò chuyện riêng.
Kết quả mong muốn đơn giản: không có yêu cầu bị chặn, và một dấu vết có thể xem xét được về ai đã làm gì, ngay cả khi ai đó vắng mặt.
Từ ngữ rõ ràng tránh các quy tắc rối rắm sau này. Nếu mọi người không đồng ý ai được phê duyệt cái gì, quy trình của bạn sẽ hoặc dừng lại hoặc tạo ra vấn đề cho kiểm toán.
Hầu hết quy trình phê duyệt có vài vai trò phổ biến:
Người phê duyệt chính (primary approver) là người mặc định được mong đợi phê duyệt một bước. Người phê duyệt dự phòng (backup approver) là người thay thế khi người chính không thể thực hiện.
Mọi người thường nhầm lẫn “người phê duyệt dự phòng” với “người phê duyệt thứ hai”, nhưng chúng khác nhau. Người phê duyệt thứ hai thêm một cấp độ nữa. Người dự phòng là con đường thay thế cho cùng một cấp độ.
Ủy quyền là quy tắc cho phép người thay thế hành động. Hai kiểu phổ biến là:
Các cấp độ phê duyệt là các bước theo thứ tự mà một yêu cầu phải qua (quản lý, rồi tài chính, rồi pháp chế, rồi IT, tùy theo yêu cầu và số tiền). Giữ “cấp độ” khác với “người thay thế”: cấp độ xác định những gì phải được phê duyệt; người thay thế xác định ai có thể phê duyệt khi người thường xuyên không thể.
Không phải đội nào cũng cần cùng một cách dự phòng. Mô hình phù hợp phụ thuộc vào tần suất mọi người vắng mặt, mức rủi ro của quyết định và mức độ dự đoán được của các bước phê duyệt.
Chọn một mô hình chính trước và coi các trường hợp khác như ngoại lệ. Trộn mọi thứ ngay từ đầu sẽ làm người dùng bối rối và khiến kiểm toán khó khăn hơn.
Hầu hết các đội dùng kết hợp những điều sau:
Chế độ nghỉ phép thường là lựa chọn đơn giản hàng ngày. Ủy quyền theo quy tắc phù hợp với các đội lớn vì giảm quyết định thủ công về việc ai đảm nhiệm. Nâng cấp không thay thế ủy quyền — nó là kế hoạch an toàn cho trường hợp timeout.
Một vài câu trả lời sẽ thu hẹp lựa chọn nhanh:
Chế độ nghỉ phép chỉ hoạt động khi nó có thể dự đoán được. Mục tiêu đơn giản: phê duyệt tiếp tục, và mọi người đều thấy ai chịu trách nhiệm.
Yêu cầu khoảng thời gian rõ ràng. Mỗi ủy quyền nên có ngày bắt đầu và kết thúc (và múi giờ nếu làm việc nhiều vùng). Tránh “cho đến khi thông báo tiếp theo.” Nếu ai đó quên tắt, phê duyệt có thể chạy tới người sai trong nhiều tuần.
Quyết định ai được chọn làm người thay thế. Tự chọn có thể ổn trong đội nhỏ, nhưng rủi ro nếu người ta chọn người chưa được đào tạo. Do quản lý chỉ định phù hợp với hầu hết sơ đồ tổ chức. Admin chỉ định tốt khi cần kiểm soát chặt, nhưng có thể làm chậm thiết lập.
Đặt quy tắc đủ điều kiện mà hệ thống có thể thực thi. Giữ đơn giản, và đừng cho phép “trường hợp đặc biệt” chỉ tồn tại trong đầu ai đó. Quy tắc điển hình gồm cùng bộ phận hoặc cost center, có cấp phê duyệt phù hợp, và đã hoàn thành đào tạo cần thiết. Luôn chặn xung đột rõ ràng: người thay thế không nên là người yêu cầu, và ngăn vòng lặp phê duyệt.
Xác định xử lý các phê duyệt đang chờ. Nhiều đội chuyển các yêu cầu mới đến người thay thế nhưng giữ các mục đang chờ với người phê duyệt chính trừ khi chúng quá hạn. Khi quá hạn, quy trình có thể tự động chuyển giao hoặc nâng cấp.
Hiển thị trạng thái. Người yêu cầu nên thấy người phê duyệt hiện tại, liệu ủy quyền có đang hoạt động và bước tiếp theo là gì. Trạng thái như “Đang chờ phê duyệt (ủy quyền cho Alex đến 30 Jan)” giảm theo dõi và giữ niềm tin cao.
Bắt đầu bằng việc ghi lại con đường phê duyệt chính xác cho một yêu cầu phổ biến (mua hàng, truy cập, ngoại lệ chính sách). Giữ nhỏ. Hai đến bốn bước đủ để thiết kế mẫu.
Gán mỗi bước cho một vai trò và một chủ sở hữu duy nhất. Ngay cả khi người thay thế có thể hành động, vẫn giữ một người phê duyệt chính cho mỗi bước để trách nhiệm rõ ràng.
Chọn một kích hoạt chính cho ủy quyền. Hầu hết đội dùng cờ vắng mặt, cửa sổ ngày, hoặc công tắc do quản lý điều khiển. Chọn một để mọi người không bị bất ngờ bởi việc chuyển hướng im lặng.
Thêm quy tắc định tuyến để chọn người phê duyệt đang hành động. Một thứ tự dễ dự đoán sẽ dễ giải thích sau này: người thay thế do người dùng chọn, rồi quản lý, rồi hàng đợi dự phòng chung. Quyết định xem người thay thế có thể phê duyệt ngay lập tức hay chỉ sau timeout.
Đặt mong đợi bằng thông báo. Người yêu cầu nên thấy ai chịu trách nhiệm ngay lúc này. Người phê duyệt chính nên được thông báo ủy quyền đang hoạt động và cách tắt nó. Người thay thế nên nhận ngữ cảnh và cách từ chối rõ ràng nếu họ không nên hành động.
Chạy một bài kiểm tra end-to-end và kiểm tra lịch sử. Bạn nên thấy ai được gán, lý do ủy quyền, ai phê duyệt và khi nào.
Dùng một kịch bản thực tế: người phê duyệt chính “đi nghỉ” và người thay thế phê duyệt. Sau đó lặp lại với người thay thế không có mặt để xác nhận quy tắc dự phòng. Cuối cùng, xác nhận sao lưu kiểm toán hiển thị cả người phê duyệt chính và người thực hiện, cộng lý do ủy quyền, để kiểm toán viên hiểu được sự bàn giao mà không cần hỏi ai cả.
Một dấu vết kiểm toán nên trả lời ba câu hỏi mà không cần suy đoán: chuyện gì đã xảy ra, ai làm, và tại sao nó được cho phép. Điều này càng quan trọng với ủy quyền, vì “người chịu trách nhiệm” và “người bấm” có thể khác nhau.
Ghi các quy tắc ủy quyền như những bản ghi chính thức, không phải cài đặt thay đổi im lặng. Lưu ai ủy quyền cho ai, thời gian bắt đầu và kết thúc, phạm vi (yêu cầu nào, mức tiền, nhóm hay loại tài liệu), và ai đã xác nhận thay đổi nếu quy trình của bạn yêu cầu.
Quyết định phê duyệt nên là các sự kiện bất biến. Đừng ghi đè “đang chờ” thành “đã phê duyệt.” Ghi các sự kiện như “Approved”, “Rejected”, hoặc “Requested changes” và giữ lại chúng, ngay cả khi quy trình khởi động lại.
Một dấu vết kiểm toán thực tế thường bao gồm:
Giữ bình luận và tệp đính kèm gắn với sự kiện quyết định. Nếu chúng nằm trong chat riêng hoặc trường “ghi chú” chung, sẽ khó chứng minh bình luận nào hỗ trợ quyết định nào.
Cuối cùng, làm cho lịch sử dễ đọc. Một dòng thời gian duy nhất hiển thị thay đổi ủy quyền, thông báo đã gửi, quyết định và nâng cấp theo thứ tự sẽ ngăn tranh chấp sau này.
Mọi người chịu được chậm trễ khi họ thấy chuyện gì đang diễn ra. Khi họ không thấy, họ truy đuổi nhầm người, gửi lại yêu cầu, hoặc cho rằng hệ thống bị hỏng.
Người yêu cầu và người xét duyệt nên luôn thấy người phê duyệt hiện tại và lý do họ được chọn. Nếu nhiệm vụ chuyển từ người phê duyệt chính sang người thay thế, hiển thị trực tiếp: “Assigned to: Priya (substitute for Alex).” Một dòng như vậy ngăn nhầm lẫn và bảo vệ trách nhiệm.
Cũng hiển thị khoảng thời gian ủy quyền và ai đã đặt nó. “Delegation active: Jan 10 to Jan 20, set by Alex” giúp đội tin tưởng rằng việc bàn giao có chủ ý.
Việc chuyển giao ẩn danh là nơi kiểm toán trở nên lộn xộn. Nếu ai đó có thể đổi người phê duyệt mà không để lại dấu vết hiển thị, người dùng mất niềm tin và quản lý không biết ai đã quyết định. Hiển thị việc chuyển giao cho những người phù hợp và luôn ghi lại ai đã kích hoạt nó.
Một bảng “Xem lịch sử” đơn giản thường là đủ. Giữ tập trung: trạng thái hiện tại, người phê duyệt hiện tại và lý do, thời gian ủy quyền, mọi chuyển giao thủ công và bình luận quyết định.
Quyền riêng tư cũng quan trọng. Xác định vai trò nào thấy được gì. Người yêu cầu có thể cần tên và trạng thái, trong khi quy trình HR, tài chính hoặc pháp lý có thể yêu cầu che bớt ghi chú nội bộ.
Ủy quyền thường thất bại vì các lý do đơn giản: quy tắc lỏng lẻo, hồ sơ mơ hồ, hoặc không có kế hoạch dự phòng. Kết quả là dự đoán được: yêu cầu nằm im, và sau đó không ai chứng minh được ai đã phê duyệt gì.
Một bẫy phổ biến là cho ủy quyền cho người không có quyền phê duyệt kiểu yêu cầu đó. Ví dụ, một người mua ủy quyền phê duyệt mua cho đồng nghiệp không có hạn mức chi. Người thay thế bấm phê duyệt, tài chính phát hiện và giờ bạn phải giải quyết giao dịch và giải thích vì sao hệ thống cho phép.
Những lỗi thường thấy:
Quá tải thông báo là tinh tế. Nếu mỗi bước kích hoạt email, chat, push và nhắc, người dùng học cách phớt lờ tất cả.
Các lựa chọn thiết kế ngăn hầu hết vấn đề:
Ủy quyền vận hành khi các “chi tiết tẻ nhạt” nhất quán. Trước khi bật chế độ nghỉ phép cho toàn công ty, rà soát mọi bước phê duyệt và hỏi: nếu người được giao hôm nay không có mặt, chuyện gì xảy ra tiếp theo?
Rồi kiểm tra ít nhất một kịch bản “người đi nghỉ” end-to-end: yêu cầu gửi trước khi kỳ nghỉ bắt đầu, phê duyệt trong kỳ nghỉ, và xem lại sau khi người đó quay lại.
Một đội bán hàng gửi yêu cầu mua 12 tai nghe mới (USD 1,200). Yêu cầu thường gửi đến Maya, Quản lý Bán hàng. Nhưng Maya nghỉ hai tuần, và phê duyệt không thể chờ.
Trước khi đi, Maya bật chế độ nghỉ phép và chỉ định Jordan (Trưởng vận hành Bán hàng) làm người thay thế cho phê duyệt mua đến USD 5,000. Mọi khoản vượt mức vẫn vào nhóm Tài chính.
Quá trình bàn giao diễn ra sạch và dễ kiểm toán như sau:
Hai chi tiết làm chuyện này đáng tin cậy. Người yêu cầu thấy lý do thay đổi người phê duyệt (“Routed to substitute: Maya out of office”), và Maya không phải tự hỏi khi quay lại.
Khi Maya trở về, cô mở mục “Approvals during absence” và xem lại những gì Jordan đã phê duyệt thay cô. Cô có thể lọc theo khoảng ngày, số tiền hoặc người yêu cầu. Cô không phê duyệt lại, nhưng có thể gắn cờ để theo dõi nếu thấy bất thường.
Sau đó, kiểm toán viên hỏi, “Ai đã phê duyệt khoản mua này, và tại sao không phải Maya?” Dòng thời gian kể một câu chuyện nhất quán: người phê duyệt gốc, lý do ủy quyền (chế độ nghỉ phép), danh tính người thay thế, ghi nhận hành động-thay-mặt, dấu thời gian quyết định và ghi chú.
Xem ủy quyền như một thay đổi sản phẩm nhỏ, không phải một mục checkbox. Mục tiêu vẫn là: phê duyệt tiếp tục khi người vắng mặt, và bạn có thể giải thích mọi quyết định sau này.
Bắt đầu với một quy trình thường gây tắc khi bị gián đoạn (chi tiêu, phê duyệt mua, hoặc yêu cầu truy cập). Giữ phạm vi chặt: một đội, một con đường phê duyệt và một chỉ số thành công rõ ràng, ví dụ “không có phê duyệt chờ hơn 24 giờ vì ai đó vắng mặt.”
Viết một chính sách ủy quyền ngắn mà mọi người thực sự sẽ tuân theo: ai được ủy quyền, cái gì được ủy quyền (ví dụ chỉ dưới một mức tiền hoặc rủi ro), cách bắt đầu và kết thúc ủy quyền, và cách xử lý ghi đè khẩn cấp và cách ghi nhận nó.
Chỉ định một người chịu trách nhiệm cho vai trò và quy tắc, và đặt việc rà soát định kỳ (hàng tháng hoặc hàng quý) để dọn dẹp người thay thế lỗi thời. Hầu hết vấn đề lâu dài đến từ ủy quyền cũ không bao giờ được tắt.
Nếu bạn muốn xây một ứng dụng phê duyệt mà không cần nhiều mã, AppMaster (appmaster.io) có thể mô hình hóa người dùng, vai trò và cửa sổ ủy quyền trong cơ sở dữ liệu, rồi triển khai định tuyến và timeout trong Business Process Editor trực quan, đồng thời giữ lịch sử phê duyệt nhất quán cho kiểm toán.
Triển khai theo giai đoạn, lắng nghe sự bối rối, và mở rộng sang quy trình tiếp theo chỉ sau khi quy trình đầu chạy mượt trong vài tuần.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
