Mở đầu — vì sao bài này quan trọng
Nếu bạn quan sát bất kỳ tổ chức nào, từ một startup mười người đến một ngân hàng hàng nghìn nhân sự, bạn sẽ thấy có một loại hành vi lặp đi lặp lại khắp nơi: ai đó đề xuất một việc, và ai đó khác phải đồng ý trước khi việc đó được thực hiện. Duyệt đơn nghỉ phép, duyệt chi phí công tác, duyệt hợp đồng, duyệt khoản vay, duyệt một bài đăng marketing trước khi lên sóng. Đây chính là approval pattern — mẫu phê duyệt — và nó là một trong những mẫu quy trình (process pattern) phổ biến nhất mà bạn sẽ gặp khi mô hình hóa nghiệp vụ bằng BPMN.
Lý do bài này quan trọng không nằm ở chỗ "vẽ một cái gateway duyệt/từ chối" — điều đó ai cũng làm được sau Bài 15. Vấn đề nằm ở chỗ: thực tế phê duyệt phức tạp hơn nhiều. Một khoản chi 500 triệu có nên cần cùng số người duyệt như khoản chi 2 triệu không? Khi cần ba người duyệt, họ duyệt lần lượt hay cùng lúc? Nếu một người vắng mặt thì sao? Nếu chỉ cần 2 trong 3 người đồng ý thì mô hình thế nào?
Nắm vững các biến thể của approval pattern giúp bạn thiết kế quy trình vừa kiểm soát được rủi ro (đúng người, đúng thẩm quyền) vừa không làm chậm vận hành (không bắt mọi thứ phải đi qua sếp tổng). Đây là kỹ năng cốt lõi của một Business Process Analyst. Trong bài này chúng ta tập trung riêng vào ba biến thể nền tảng: single approval (đơn cấp), multiple/sequential approval (nhiều cấp tuần tự), và parallel approval (song song), cùng cách biểu diễn chúng chuẩn xác bằng BPMN.
Khái niệm cốt lõi
Approval pattern, ở dạng tổng quát, gồm ba thành phần: một request (yêu cầu được gửi đi), một hoặc nhiều approver (người có thẩm quyền quyết định), và một outcome (kết quả: chấp thuận hoặc từ chối, đôi khi có thêm "trả lại để sửa"). Sự khác biệt giữa các biến thể nằm ở số lượng approver và cách họ phối hợp về mặt thời gian.
1. Single approval — phê duyệt đơn cấp
Đây là dạng đơn giản nhất: một người gửi, một người duyệt, xong.
[Submit request] → (X) Manager decision → [Approved] → [Done]
│
└──→ [Rejected] → [Notify submitter]
Trong BPMN, ta dùng một User Task "Review request" do Manager thực hiện, theo sau là một Exclusive Gateway (XOR) rẽ hai nhánh: Approved và Rejected. Single approval phù hợp với những quyết định rủi ro thấp, giá trị nhỏ, cần tốc độ: duyệt đơn nghỉ nửa ngày, duyệt mua văn phòng phẩm dưới 1 triệu. Ưu điểm là nhanh và rõ trách nhiệm. Nhược điểm là nó tạo ra single point of failure — nếu người duyệt bận hoặc nghỉ, cả quy trình đứng.
2. Sequential multi-approval — phê duyệt nhiều cấp tuần tự
Khi quyết định có giá trị lớn hơn hoặc liên quan nhiều bên, ta cần nhiều người duyệt lần lượt theo thứ tự. Người sau chỉ xem xét sau khi người trước đã đồng ý.
[Submit] → [Manager approve] → [Director approve] → [CFO approve] → [Done]
│ reject │ reject │ reject
└────────────────────┴───────────────────┴──→ [Rejected]
Đặc trưng của sequential approval là tính dây chuyền: nếu bất kỳ cấp nào từ chối, quy trình dừng ngay (gọi là early termination — không cần làm phiền các cấp sau). Mô hình này phản ánh thẩm quyền tăng dần theo cấp bậc và thường gắn với ngưỡng giá trị. Nhược điểm rõ rệt là cycle time dài: nếu mỗi cấp mất một ngày để xử lý, một hồ sơ ba cấp có thể "ngâm" cả tuần. Đây là nơi bottleneck hay xuất hiện.
3. Parallel approval — phê duyệt song song
Khi nhiều bên cần xem xét cùng một yêu cầu nhưng không phụ thuộc lẫn nhau (mỗi bên xét một góc độ riêng), ta cho họ duyệt đồng thời để tiết kiệm thời gian.
┌→ [Legal review] ──┐
[Submit] → (+) split ├→ [Finance review]─┤ (+) join → [Approved] → [Done]
└→ [Security review]┘
Ta dùng Parallel Gateway (AND) để tách (split) yêu cầu ra ba luồng chạy song song, rồi một Parallel Gateway khác để gộp (join) lại. Quy trình chỉ tiếp tục khi cả ba đều xong. Vì các bên làm cùng lúc nên cycle time bằng đúng thời gian của bên chậm nhất, không phải tổng. Đây là điểm mạnh lớn so với sequential.
Một câu hỏi quan trọng: nếu chạy song song mà một bên từ chối thì sao? Có hai chiến lược:
- Unanimous (đồng thuận tuyệt đối): chỉ cần một bên từ chối là cả hồ sơ bị từ chối. Lúc này, đúng nghĩa BPMN, bạn cần xử lý việc dừng các luồng còn lại — thường giải quyết bằng một terminate end event hoặc gom luồng rồi đánh giá ở gateway sau join.
- Quorum / N-of-M (đa số): chỉ cần M trong N người đồng ý là đạt. Ví dụ hội đồng 5 người, cần 3 phiếu thuận. Mẫu này thường biểu diễn bằng multi-instance task kèm một completion condition (điều kiện hoàn tất sớm), thay vì vẽ tay từng luồng.
Một biến thể lai thường gặp: conditional / threshold approval
Trong thực tế, ba mẫu trên hiếm khi đứng riêng. Phổ biến nhất là threshold-based routing — định tuyến theo ngưỡng: giá trị càng cao thì càng nhiều cấp duyệt. Ta đặt một Exclusive Gateway ngay sau khi submit để phân loại giá trị, rồi mỗi nhánh dẫn tới một cấu hình duyệt khác nhau (single cho khoản nhỏ, sequential ba cấp cho khoản lớn). Đây chính là cách các hệ thống ERP thật vận hành.
Tình huống thực tế
Ví dụ 1 — Tiki: duyệt chi phí marketing theo ngưỡng (threshold + single/sequential)
Giả sử phòng Marketing của Tiki cần một quy trình duyệt ngân sách chiến dịch. Ban đầu họ làm rất đơn giản: mọi đề xuất đều phải qua Giám đốc Marketing duyệt (single approval). Kết quả là vị giám đốc này mỗi ngày duyệt 40–50 đề xuất, phần lớn là những khoản nhỏ vài triệu để chạy quảng cáo Facebook. Cycle time trung bình của một đề xuất là 1,5 ngày, chủ yếu vì hồ sơ xếp hàng chờ một người.
Nhóm process analyst thiết kế lại theo ngưỡng:
- Dưới 20 triệu: single approval bởi Team Lead — duyệt trong ngày.
- 20–100 triệu: sequential Team Lead → Giám đốc Marketing.
- Trên 100 triệu: sequential Team Lead → Giám đốc Marketing → CFO.
Bài học: đừng bắt mọi thứ qua một mẫu duy nhất. Phân tầng theo rủi ro/giá trị giúp giải phóng người có thẩm quyền cao khỏi những quyết định vụn vặt, và đó là cách giảm bottleneck hiệu quả nhất.
Ví dụ 2 — Một ngân hàng tại TP.HCM: duyệt khoản vay doanh nghiệp (parallel approval)
Một chi nhánh ngân hàng xử lý hồ sơ vay vốn doanh nghiệp với quy trình tuần tự: hồ sơ qua Quan hệ khách hàng → Thẩm định tín dụng → Pháp chế → Quản lý rủi ro, lần lượt từng phòng. Mỗi phòng mất trung bình một ngày, nên một hồ sơ "sạch" cũng mất 4 ngày làm việc mới ra quyết định — quá chậm trong thị trường cạnh tranh.
Khi phân tích, analyst nhận ra ba bộ phận Thẩm định, Pháp chế và Quản lý rủi ro xem xét ba khía cạnh độc lập: khả năng trả nợ, tính pháp lý của tài sản đảm bảo, và mức độ rủi ro tổng thể. Họ không cần kết quả của nhau. Vậy tại sao phải xếp hàng?
Quy trình được vẽ lại: sau bước Quan hệ khách hàng tiếp nhận, một Parallel Gateway tách hồ sơ thành ba luồng chạy song song cho ba phòng. Một Parallel Gateway gộp lại, rồi tới gateway đánh giá: nếu cả ba đều đạt thì chuyển sang ký duyệt cuối; nếu bất kỳ phòng nào đánh dấu "không đạt" thì hồ sơ bị từ chối kèm lý do. Cycle time của giai đoạn thẩm định giảm từ 3 ngày (3 phòng tuần tự) xuống còn khoảng 1 ngày (bằng phòng chậm nhất).
Bài học: khi các bước phê duyệt độc lập về dữ liệu, hãy chuyển từ sequential sang parallel. Đây là một trong những đòn bẩy tối ưu cycle time mạnh nhất mà gần như không tốn chi phí gì ngoài việc thiết kế lại luồng.
Ví dụ 3 — Hội đồng học bổng của một trường đại học (parallel quorum / N-of-M)
Một trường đại học có quỹ học bổng, mỗi hồ sơ ứng viên cần được hội đồng 5 giảng viên chấm. Quy định: hồ sơ được duyệt nếu có ít nhất 3 trong 5 phiếu thuận. Năm thành viên chấm độc lập, không cần chờ nhau.
Nếu vẽ thủ công năm luồng song song rồi gắn logic "đếm phiếu", sơ đồ sẽ rất rối và khó bảo trì. Cách chuẩn trong BPMN là dùng một Multi-instance User Task ("Đánh giá hồ sơ") với 5 instance chạy song song (parallel multi-instance), kèm completion condition: dừng và kết luận ngay khi đủ 3 phiếu thuận hoặc khi không còn khả năng đạt 3 phiếu (đã có 3 phiếu chống). Nhờ completion condition, hệ thống không cần bắt cả 5 người chấm xong nếu kết quả đã rõ — tiết kiệm thời gian cho hội đồng.
Bài học: với phê duyệt kiểu biểu quyết/quorum, đừng vẽ tay từng người. Multi-instance + completion condition là công cụ đúng, vừa gọn sơ đồ vừa diễn đạt chính xác ngữ nghĩa "M trong N". (Chi tiết kỹ thuật về multi-instance sẽ được đào sâu ở Bài 25; ở đây ta chỉ dùng nó như một công cụ biểu diễn approval pattern.)
Hướng dẫn từng bước
Khi đứng trước một yêu cầu thiết kế quy trình phê duyệt, hãy đi theo trình tự sau:
Bước 1 — Xác định đối tượng được duyệt và rủi ro. Hỏi rõ: cái gì đang được duyệt? Hậu quả của một quyết định sai là gì? Một khoản chi 5 tỷ và một đơn nghỉ phép nửa ngày không thể dùng chung mức độ kiểm soát.
Bước 2 — Liệt kê các approver và thẩm quyền. Ghi ra ai có quyền duyệt cái gì, tới ngưỡng nào (delegation of authority — phân quyền phê duyệt). Đây là dữ liệu đầu vào quyết định bạn cần bao nhiêu cấp.
Bước 3 — Xác định quan hệ phụ thuộc giữa các approver. Đặt câu hỏi then chốt: người duyệt sau có cần kết quả/ý kiến của người duyệt trước không?
- Có phụ thuộc → sequential.
- Không phụ thuộc → parallel.
Bước 4 — Xác định luật quyết định tập thể (nếu nhiều người). Cần tất cả đồng ý (unanimous) hay chỉ cần đa số (quorum)? Điều này quyết định bạn dùng AND-join thuần hay multi-instance kèm completion condition.
Bước 5 — Có cần phân tầng theo ngưỡng không? Nếu giá trị/độ phức tạp biến thiên rộng, đặt một Exclusive Gateway phân loại ở đầu để định tuyến mỗi loại tới cấu hình duyệt phù hợp.
Bước 6 — Vẽ BPMN với đúng phần tử.
- Mỗi lần một người ra quyết định → User Task + Exclusive Gateway (Approved/Rejected).
- Tách/gộp luồng độc lập → Parallel Gateway (AND).
- Định tuyến theo điều kiện/giá trị → Exclusive Gateway (XOR).
- Biểu quyết N-of-M → Multi-instance task + completion condition.
Bước 8 — Thêm cơ chế chống nghẽn. Với mỗi User Task duyệt, cân nhắc gắn timer để escalate nếu approver không xử lý trong SLA (mẫu escalation sẽ học kỹ ở Bài 42). Ít nhất, hãy đặt câu hỏi: nếu người này không bấm gì trong 3 ngày thì sao?
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm parallel với sequential. Đây là lỗi phổ biến nhất. Nhiều người mặc định vẽ tuần tự vì "ai cũng làm thế", khiến quy trình chậm không cần thiết. Mẹo: với mỗi cặp bước duyệt, hỏi "nếu đảo thứ tự hai bước này, kết quả có đổi không?" Nếu không đổi → chúng độc lập → cho chạy song song.
Lỗi 2 — Dùng Parallel Gateway nhưng cần XOR logic ở chỗ join. Khi ba bên duyệt song song theo luật "một người chống là trượt", người mới hay dùng AND-split rồi cũng AND-join và quên mất rằng cần đánh giá kết quả sau đó. Mẹo: sau AND-join, đặt một Exclusive Gateway để kiểm tra "có ai từ chối không?". Đừng nhầm việc gộp luồng (join) với việc ra quyết định tập thể.
Lỗi 3 — Quên early termination trong sequential. Nếu cấp 1 đã từ chối thì không được để hồ sơ chạy tiếp tới cấp 2, cấp 3. Mỗi cấp phải có nhánh reject dẫn thẳng tới kết thúc/thông báo. Sơ đồ thiếu nhánh này là sơ đồ sai về mặt nghiệp vụ.
Lỗi 4 — Vẽ tay quorum thay vì dùng multi-instance. Vẽ 5 luồng song song cho 5 người chấm, rồi cố gắn logic đếm phiếu bằng các gateway lồng nhau — sơ đồ trở thành "mì spaghetti". Multi-instance + completion condition là lời giải đúng và gọn.
Lỗi 5 — Bỏ qua trường hợp approver vắng mặt. Single approval đặc biệt mong manh: chỉ một người nghỉ là cả quy trình đứng. Mẹo: với mọi điểm duyệt quan trọng, định nghĩa sẵn người duyệt thay thế (delegate/backup) và cơ chế escalate theo timer.
Lỗi 6 — Trộn lẫn approver là người với approval tự động. Một số bước "duyệt" thực ra là kiểm tra bằng quy tắc (rule-based), không cần con người — ví dụ "nếu hồ sơ đủ giấy tờ thì tự qua". Đừng mô hình hóa nó như User Task; đó là một quyết định tự động, nên tách thành Business Rule / DMN (xem Bài 28). Phân biệt rõ "duyệt bởi người" và "duyệt bởi luật" giúp quy trình gọn và tự động hóa được nhiều hơn.
Mẹo tổng quát: luôn gắn approval pattern với một ma trận thẩm quyền rõ ràng (ai duyệt được gì, tới ngưỡng nào). Sơ đồ BPMN đẹp mà không có ma trận này thì khi triển khai sẽ vỡ trận vì tranh cãi "ai có quyền".
Bài tập thực hành
Bài 1 — Single → Threshold. Một công ty hiện duyệt mọi đề nghị thanh toán đều qua Kế toán trưởng (single approval). Hãy thiết kế lại thành quy trình phân tầng: dưới 10 triệu do Trưởng nhóm duyệt; 10–50 triệu thêm Kế toán trưởng; trên 50 triệu thêm Giám đốc. Vẽ sơ đồ BPMN dùng một Exclusive Gateway phân loại đầu vào và các chuỗi sequential phù hợp. Đảm bảo mỗi cấp đều có nhánh reject.
Bài 2 — Sequential → Parallel. Cho quy trình duyệt một bài viết PR công ty: Trưởng phòng Truyền thông → Pháp chế → Ban Giám đốc, hiện đang tuần tự, mất 3 ngày. Phân tích xem bước nào thật sự phụ thuộc bước nào. Vẽ lại để rút ngắn cycle time, giải thích bước nào bạn cho chạy song song và vì sao. Ước lượng cycle time mới nếu mỗi bước mất 1 ngày.
Bài 3 — Quorum. Một quỹ đầu tư có hội đồng 7 thành viên; một thương vụ được thông qua nếu có ít nhất 5 phiếu thuận. Mô tả bằng lời cách bạn dùng multi-instance task và completion condition để biểu diễn quy tắc này, và nêu rõ điều kiện nào sẽ khiến quy trình dừng sớm (cả hướng đạt và hướng trượt).
Bài 4 — Phản biện. Cho sơ đồ sau (mô tả bằng lời): "Submit → AND-split tới Legal, Finance, Risk → AND-join → Approved". Chỉ ra lỗi nghiệp vụ trong sơ đồ này nếu quy tắc thực tế là "một bên từ chối thì cả hồ sơ trượt", và đề xuất cách sửa.
Tóm tắt
Approval pattern là mẫu quy trình xuất hiện ở khắp mọi tổ chức, và việc chọn đúng biến thể quyết định trực tiếp đến tốc độ lẫn mức độ kiểm soát của nghiệp vụ. Single approval đơn giản và nhanh, hợp với quyết định rủi ro thấp, nhưng tạo điểm nghẽn đơn lẻ. Sequential approval phản ánh thẩm quyền tăng dần và cho phép dừng sớm khi bị từ chối, nhưng làm dài cycle time vì các cấp xếp hàng. Parallel approval rút ngắn thời gian đáng kể khi các bên duyệt độc lập về dữ liệu, với cycle time bằng bên chậm nhất thay vì tổng các bên.
Câu hỏi vàng để chọn mẫu là: các approver có phụ thuộc kết quả của nhau không? — phụ thuộc thì tuần tự, độc lập thì song song. Khi nhiều người cùng quyết, cần xác định rõ luật tập thể (đồng thuận tuyệt đối hay quorum đa số), và với quorum hãy dùng multi-instance kèm completion condition thay vì vẽ tay. Trong thực tế, mạnh nhất là kết hợp: phân tầng theo ngưỡng giá trị, dùng single cho khoản nhỏ và sequential/parallel cho khoản lớn, đồng thời luôn gắn ma trận thẩm quyền, xử lý nhánh từ chối, và phòng ngừa trường hợp approver vắng mặt. Nắm chắc ba biến thể này, bạn đã có bộ công cụ nền tảng để thiết kế phần lớn các quy trình phê duyệt mà doanh nghiệp Việt Nam đang cần tối ưu.