Dùng bản mẫu quy trình phê duyệt để thiết kế luồng phân bước, SLA và cơ chế leo thang rõ ràng khi đội bạn mở rộng, kèm checklist yêu cầu có thể tái sử dụng.
Quy trình phê duyệt hiếm khi thất bại vì mọi người không quan tâm. Chúng thất bại vì quy trình được thiết kế cho một đội nhỏ, nơi mọi người đã quen các quy ước không viết ra. Khi đội lớn hơn, ký ức chung đó tan biến.
Khi một quy trình hỏng ở quy mô lớn, thường sẽ trông như sau: yêu cầu nằm im vì không ai biết ai chịu trách nhiệm bước tiếp theo; phê duyệt diễn ra qua chat hoặc email nên không có dấu vết kiểm toán đáng tin cậy; mọi người đi vòng quy trình để kịp hạn và bộ phận tài chính hoặc vận hành phải dọn dẹp sau đó; cùng một yêu cầu bị phê duyệt hai lần (hoặc không ai phê duyệt) vì phiên bản và bối cảnh hiện tại không rõ.
Vấn đề gốc rễ là các quy tắc nằm trong đầu người, không nằm trong quy trình. Có người biết rằng "công cụ marketing dưới $500 có thể được phê duyệt bởi trưởng nhóm, trừ khi là nhà cung cấp mới", nhưng hệ thống thì không. Khi người đó vắng mặt, mọi thứ chậm lại.
Tăng trưởng cũng thay đổi ý nghĩa của “phê duyệt”. Bạn có nhiều loại yêu cầu hơn, nhiều người phê duyệt hơn và nhiều ngoại lệ hơn. Một yêu cầu mua hàng không giống yêu cầu giảm giá hay yêu cầu quyền truy cập. Mỗi loại mang rủi ro khác nhau và cần thông tin, bằng chứng khác nhau.
Một quy trình chịu được khi khối lượng tăng gấp đôi nên bảo vệ vài thứ cơ bản:
Điều đó thường có nghĩa là chuyển từ tin nhắn linh hoạt sang một quy trình rõ ràng, nơi các bước, điều kiện và quyền sở hữu được hiển thị và lặp lại được.
Nhiều quy trình thất bại vì không ai đồng ý về yêu cầu là gì, hoặc khi nào nó hoàn tất. Trước khi vẽ, hãy xác định ranh giới và vạch đích.
Định nghĩa yêu cầu bằng ngôn ngữ đơn giản. Ai có thể gửi? Thông tin nào phải có? Khi nào thì đủ để xét duyệt? Nếu biểu mẫu cho phép người ta ghi "N/A" khắp nơi, người phê duyệt sẽ hoặc chặn mọi thứ hoặc phê duyệt một cách mù quáng.
Xác định kết quả ngoài việc phê duyệt. Quyết định điều gì xảy ra khi người phê duyệt cần thay đổi, khi yêu cầu không còn cần nữa, hoặc khi nó bị từ chối. Những lựa chọn này định hình mọi bước sau đó.
Giao quyền sở hữu sớm. Một người chịu trách nhiệm quy trình (process owner) chịu trách nhiệm về các quy tắc và cập nhật. Người phê duyệt chịu trách nhiệm về quyết định, không phải về thiết kế. Những người rà soát như tài chính, an ninh hoặc pháp chế có thể tư vấn, nhưng không phải lúc nào cũng sở hữu quyết định cuối.
Vạch ranh giới phạm vi rõ ràng. "Tất cả các yêu cầu chi tiêu trên $500" rõ ràng. "Mua sắm" thì không. Cũng liệt kê những gì nằm ngoài phạm vi (ví dụ, hoàn trả công tác hay gia hạn xử lý ở nơi khác) để quy trình không trở thành miệng hố cho mọi thứ.
Một vòng xác định yêu cầu nhanh trước khi xây giúp tiết kiệm sửa đổi sau này:
Một ví dụ đơn giản: yêu cầu laptop được coi là "hoàn tất" chỉ khi nó được phê duyệt và chuyển sang bộ phận mua sắm, bị từ chối kèm lý do, hoặc trả lại kèm danh sách chi tiết còn thiếu. Nếu không có định nghĩa đó, cùng một yêu cầu có thể bị trả vòng nhiều ngày mà không có điểm kết rõ ràng.
Bắt đầu với một khung nhỏ, lặp lại được và mở rộng thận trọng. Hầu hết vấn đề khi mở rộng xuất phát từ trộn lẫn trách nhiệm, thêm "một ngoại lệ nữa" và mất dấu bước tiếp theo.
Khung có thể tái sử dụng cho nhiều quy trình:
Giữ kiểm tra tách biệt khỏi phê duyệt. Kiểm tra trả lời câu hỏi “yêu cầu này có hợp lệ và đầy đủ không?” Phê duyệt trả lời câu hỏi “chúng ta có cho phép hay không?” Xác thực thường thuộc về ops hoặc chủ yêu cầu. Phê duyệt thuộc về các vai trò chịu trách nhiệm về rủi ro, ngân sách hoặc chính sách.
Cũng giữ các bước nhỏ: nhắm tới một quyết định cho mỗi bước. Nếu một bước yêu cầu ai đó đánh giá cả ngân sách, tuân thủ và tính khả thi kỹ thuật, nó sẽ bị tắc hoặc biến thành một cuộc họp.
Cuối cùng, bao gồm đường "yêu cầu chỉnh sửa" trả về đúng chỗ, không trả về điểm xuất phát. Nếu tài chính cần một báo giá thiếu, chuyển về người gửi (hoặc xác thực), rồi trở lại rà soát tài chính mà không phải làm lại các bước pháp lý và quản lý.
Phân luồng có điều kiện là nơi quy trình thường biến thành mê cung. Cách sửa phần lớn là kỷ luật: chọn một tập đầu vào nhỏ, viết quy tắc bằng tiếng thường, rồi triển khai đúng như viết.
Giữ các đầu vào phân luồng mà mọi người đã hiểu và có thể điền nhất quán, như số tiền, phòng ban hoặc mã chi phí, mức rủi ro, loại nhà cung cấp (đã có trước hay lần đầu), và vùng.
Viết mỗi quy tắc dưới dạng một câu ngắn trước khi xây. Nếu một quy tắc không vừa một dòng, thường là nó đang cố gắng làm quá nhiều.
Ví dụ vẫn dễ đọc:
Các trường hợp đặc biệt là không tránh khỏi, nên đặt tên và cô lập chúng. "Khẩn cấp" là một ví dụ hay. Định nghĩa khẩn cấp là gì (hạn chót trong 24 giờ, sự cố với khách hàng, v.v.), rồi chuyển nó qua một con đường nhanh hơn với ít bước nhưng yêu cầu ghi chú chặt chẽ hơn.
Khi nhiều quy tắc cùng áp dụng, quyết trước cách giải quyết xung đột. Mẫu phổ biến: thứ tự ưu tiên (rủi ro vượt số tiền), quy tắc đồng thuận (2 trong 3), tất cả phải phê duyệt (theo thứ tự hoặc song song), hoặc vai trò phá hoá (tie-breaker).
Nếu bạn có thể giải thích phân luồng trong một cuộc trao đổi hai phút, bạn có thể giữ nó dễ đọc khi đội nhân đôi.
SLA biến một quy trình "thường thì ổn" thành quy trình dự đoán được khi khối lượng tăng. Mục tiêu đơn giản: quyết định xảy ra đúng hạn và không ai phải canh hàng chờ.
Hầu hết đội cần hơn một chiếc đồng hồ:
Tránh dùng một bộ hẹn giờ chung cho mọi thứ. Yêu cầu rủi ro thấp có thể cho phép 24 giờ để quyết định, trong khi yêu cầu giá trị cao cần ngưỡng chặt hơn. Gắn SLA vào loại yêu cầu, số tiền, hoặc mức rủi ro để quy tắc cảm thấy công bằng.
Leo thang nên là một bậc thang, không phải việc giao lại bất ngờ. Một mẫu đơn giản:
Một chi tiết ngăn tranh luận vô tận: định nghĩa khi nào đồng hồ dừng. Nếu yêu cầu bị gửi trả để lấy thêm thông tin, SLA nên tạm dừng cho tới khi người gửi trả lời. Nếu đang chờ giấy tờ bên ngoài, trạng thái "đang chờ" phải là trạng thái thực, không chỉ một bình luận.
Một quy trình có thể mở rộng hơn bước và điều kiện. Nó cần trạng thái rõ ràng, nhật ký kiểm toán đáng tin cậy và quyền truy cập phù hợp với cách tổ chức hoạt động. Nếu bỏ qua mấy thứ này, quy trình trông ổn vào ngày đầu và trở nên khó chịu vào ngày thứ ba mươi.
Bắt đầu với nhãn trạng thái mà ai cũng hiểu. Giữ chúng nhất quán giữa các quy trình: Draft, Pending, Approved, Rejected. Nếu cần chi tiết, thêm trạng thái phụ như "Pending: Finance" thay vì sáng tạo các trạng thái cấp cao mới cho từng đội.
Xác định những gì bạn ghi vào nhật ký kiểm toán. Xem nó là phương án phòng ngừa cho tranh chấp, tuân thủ và gỡ lỗi:
Thông báo nên theo trạng thái, không theo ký ức của con người. Khi một yêu cầu chuyển sang Pending, thông báo người phê duyệt tiếp theo và người gửi. Khi bị Rejected, thông báo người gửi kèm lý do. Khi Approved, thông báo các đội hạ nguồn cần hành động (như mua sắm).
Quyền truy cập là nơi quy trình thường sụp đổ khi chịu áp lực. Quyết định chúng sớm:
Một quy tắc thực tế cứu rắc rối: khi yêu cầu ở trạng thái Pending, khóa các trường quan trọng (số tiền, nhà cung cấp, phạm vi). Nếu phải thay đổi, gửi về Draft với ghi chú "Yêu cầu chỉnh sửa" rõ ràng để lịch sử giữ sạch.
Một trình chỉnh sửa trực quan giúp bạn thấy toàn bộ quy trình trước khi nó biến thành một mớ ngoại lệ. Xây theo các lần (pass) để có đường đi hoạt động trước, rồi thêm quy tắc.
Vẽ khung. Tạo các bước cho intake, xác thực, phê duyệt, thực hiện và đóng. Thêm các trạng thái kết thúc rõ: Approved, Rejected, Sent back.
Thêm dữ liệu nhập và xác thực. Định nghĩa các trường (số tiền, mã chi phí, nhà cung cấp, ngày cần). Thêm kiểm tra nhanh sớm để yêu cầu xấu không lọt vào hàng chờ.
Thêm phân luồng có điều kiện. Chia nhánh chỉ nơi nào thay đổi người phê duyệt. Xử lý xung đột phổ biến rõ ràng (ví dụ người gửi trùng người phê duyệt).
Thêm bộ hẹn giờ và leo thang. Đặt SLA cho từng bước. Khi bộ hẹn giờ hết hạn, gửi nhắc và leo thang theo bậc thang bạn đã định.
Kiểm thử với các trường hợp thực và biên. Chạy một bộ kịch bản nhỏ từ đầu đến cuối và xác nhận nhiệm vụ, tin nhắn, trạng thái và mục nhật ký là đúng.
Dùng một bộ kịch bản nhất quán mỗi khi thay đổi quy trình:
Sau khi kiểm thử, đổi tên các bước không rõ và gỡ các nhánh tạm. Nếu bây giờ khó đọc, nó sẽ không sống sót khi phát triển.
Hầu hết luồng phê duyệt thất bại vì những lý do có thể dự đoán. Thiết kế cho sự rõ ràng và ngoại lệ ngay từ ngày đầu.
Bẫy: thêm người phê duyệt cho tới khi chẳng ai di chuyển. Thêm người phê duyệt cho cảm giác an toàn nhưng tạo ra thời gian chết và nhầm lẫn. Giữ một người chịu trách nhiệm cho mỗi bước. Những người khác chỉ nhận thông báo FYI.
Bẫy: leo thang không có chủ sở hữu. SLA vô nghĩa nếu không có ai được trao quyền hành động. Giao một chủ sở hữu leo thang (một vai trò, không phải cá nhân) và định nghĩa họ có thể làm gì: phê duyệt, từ chối, điều hướng lại, hay yêu cầu chỉnh sửa.
Bẫy: quy tắc sống trong hộp thư và chat. Nếu logic phân luồng được đồng ý "nơi nào đó" nhưng không nằm trong quy trình, quyết định sẽ không đồng nhất. Đặt điều kiện trực tiếp vào quy trình và thêm ghi chú ngắn vì sao quy tắc tồn tại.
Bẫy: không có vòng yêu cầu chỉnh sửa. Nếu người rà soát chỉ có thể phê duyệt hoặc từ chối, mọi người sẽ khởi tạo lại yêu cầu và mất bối cảnh. Thêm trạng thái Needs changes trả về đúng chỗ.
Bẫy: ngoại lệ buộc mọi người ra khỏi quy trình. Mục khẩn cấp và giấy tờ thiếu vẫn xảy ra. Thêm đường ngoại lệ có kiểm soát và ghi lại ai đã dùng nó và vì sao.
Trước khi xây bất kỳ quy trình phê duyệt nào, thu cùng một tập đầu vào. Nó giữ luồng dễ đọc và ngăn những "trường hợp đặc biệt" biến thành sửa khẩn.
Tổ chức một workshop ngắn (30–45 phút) với người gửi, người phê duyệt và người chịu trách nhiệm tuân thủ hoặc báo cáo. Ghi lại:
Ví dụ này vẫn rõ khi khối lượng và quy mô đội tăng.
Người gửi nộp một yêu cầu mua gồm: số tiền, mã chi phí, nhà cung cấp và mục đích. Phân luồng theo vài ngưỡng đơn giản và quy tắc rủi ro nhà cung cấp:
Giữ quy tắc rủi ro nhà cung cấp tách biệt khỏi quy tắc theo số tiền để bạn có thể điều chỉnh tiêu chí nhà cung cấp mà không chạm vào phần còn lại của luồng.
Đặt một SLA bảo vệ người gửi: phản hồi đầu trong vòng 1 ngày làm việc. "Phản hồi đầu" nghĩa là phê duyệt, từ chối, hoặc yêu cầu chỉnh sửa.
Nếu không có hành động sau 24 giờ, leo thang tới quản lý của người phê duyệt và thông báo cho người gửi. Tránh giao việc ngay khi leo thang lần đầu; tăng hiển thị trước, rồi chỉ giao lại nếu cần.
Làm kết quả rõ ràng:
Để biết quy trình có hiệu quả hay không, theo dõi thời gian phê duyệt theo bước, tỉ lệ phải làm lại (bao nhiêu lần yêu cầu bị yêu cầu chỉnh sửa), và tần suất leo thang theo bước và phòng ban.
Bắt đầu nhỏ có chủ ý. Chọn một đội và một loại yêu cầu (quyền truy cập phần mềm, yêu cầu mua, nghỉ phép) và chạy pilot 2–4 tuần. Giữ luồng như thiết kế để bạn thấy chỗ nào bị uốn cong khi làm việc thực.
Giữ quy tắc và logic quy trình cùng nhau. Nếu phân luồng sống trong tài liệu nhưng logic nằm nơi khác, chúng sẽ trôi. Đặt ghi chú ngôn ngữ thường ngay cạnh các bước ảnh hưởng để câu hỏi "tại sao lại đi vậy?" dễ trả lời.
Thêm giám sát nhẹ sớm. Bạn không cần dashboard cầu kỳ để học nhiều. Theo dõi thời gian trung bình ở mỗi bước, nguyên nhân chính gây tắc (thiếu thông tin, sai người phê duyệt, chính sách không rõ), số lần leo thang, và tỉ lệ phải làm lại.
Lên kế hoạch cho thay đổi trước khi nó xảy ra: ai đề xuất quy tắc mới, ai rà soát, và cách thông báo cập nhật. Một cuộc rà soát hàng tuần hoặc hai tuần một lần thường đủ. Yêu cầu một ghi chú ngắn cho mỗi thay đổi: vấn đề nó sửa, ai bị ảnh hưởng và cách bạn sẽ đo lường thành công.
Nếu bạn muốn biến bản mẫu này thành một ứng dụng hoạt động mà không cần viết mã thủ công, AppMaster (appmaster.io) là một nền tảng no-code nơi bạn có thể mô hình dữ liệu yêu cầu, xây logic phê duyệt trong Trình chỉnh sửa Quy trình Kinh doanh trực quan và phát hành giao diện web và di động gốc để phê duyệt nhanh trong khi giữ nhật ký kiểm toán ở một nơi.
Why do approval workflows start failing when a team grows?Quy trình phê duyệt thường hỏng vì các quy tắc thực tế hay được để ngỏ và chỉ nằm trong đầu người với kinh nghiệm. Khi đội tăng quy mô, ngữ cảnh chung biến mất, dẫn tới yêu cầu bị treo, quyết định diễn ra qua chat và không ai xác định được bước tiếp theo hay lý do của quyết định.
What should I define first before building an approval workflow?Bạn cần xác định phạm vi đủ cụ thể để ai cũng hiểu cái gì thuộc về quy trình và cái gì không. Xác định ai có thể gửi, các trường bắt buộc phải điền, và khi nào thì được coi là “hoàn tất” để tránh việc yêu cầu bị trả vòng vô tận.
What’s the difference between validation and approval steps?Xem validation là “yêu cầu này có đầy đủ và đúng không”, còn approval là “chúng ta có cho phép hay không”. Tách hai bước này giúp người phê duyệt không phải tốn thời gian sửa dữ liệu thiếu và giữ cho bước quyết định nhanh chóng, nhất quán.
What’s a simple approval workflow structure I can reuse?Bắt đầu với khung đơn giản: intake, validation, review, decision, fulfillment, và closeout. Khi quy trình đó hoạt động trơn, chỉ thêm những nhánh thực sự làm thay đổi quyền sở hữu hoặc rủi ro, để luồng vẫn dễ đọc khi khối lượng tăng.
How do I set routing rules without creating a maze of exceptions?Dùng một tập nhỏ các đầu vào mà mọi người có thể điền nhất quán, như số tiền, phòng ban, loại nhà cung cấp, vùng, và mức rủi ro. Viết mỗi quy tắc bằng một câu ngắn trước khi triển khai; nếu không gói vừa một dòng thì nó quá phức tạp và cần tách ra.
What should I do when multiple routing rules apply at the same time?Chọn một thứ tự ưu tiên mặc định khi có nhiều quy tắc cùng áp dụng, ví dụ “rủi ro ưu tiên hơn số tiền”. Triển khai thứ tự đó trong quy trình để không ai phải đoán ai là người phê duyệt cuối cùng khi nhiều quy tắc xung đột.
How do SLAs and escalations work without constant manual chasing?Đặt ít nhất hai bộ hẹn giờ: thời gian phản hồi đầu tiên và thời gian đến quyết định cuối cùng, và tạm dừng đồng hồ khi yêu cầu đang chờ người gửi trả lời. Đường leo thang nên dự đoán được: nhắc người hiện tại trước khi chuyển giao công việc.
What states and audit trail details will I wish I had later?Dùng tập trạng thái nhỏ mà ai cũng hiểu và ghi lại ai đã làm gì, khi nào và tại sao. Khóa các trường quan trọng khi yêu cầu ở trạng thái Pending để mọi thay đổi phải qua đường “request changes” thay vì sửa thầm.
How do I test an approval workflow before rolling it out to everyone?Bắt đầu bằng một pilot cho một đội và một loại yêu cầu, rồi chạy một vài kịch bản thực tế (bao gồm thiếu thông tin và trường hợp người gửi trùng người phê duyệt). Nếu luồng khó đọc ở bước kiểm thử, nó sẽ không chịu được khối lượng thật.
Can I build this kind of workflow without writing code?Một trình chỉnh sửa quy trình trực quan cho phép bạn vẽ các bước, điều kiện, SLA và đường leo thang ở cùng một nơi và gắn chúng vào dữ liệu và giao diện. Với AppMaster (appmaster.io), bạn có thể mô hình trường yêu cầu, xây logic phê duyệt bằng giao diện trực quan và phát hành ứng dụng web và di động với lịch sử có thể tìm kiếm mà không cần viết mã thủ công.
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.
