Mở đầu — vì sao bài này quan trọng
Ở bài trước, bạn đã làm quen với Exclusive Gateway (XOR) — loại cổng "rẽ một đường", nơi quy trình chỉ chọn đúng MỘT nhánh để đi tiếp. Nhưng đời sống doanh nghiệp hiếm khi đơn giản như vậy. Rất nhiều công việc thực tế đòi hỏi nhiều thứ phải xảy ra CÙNG LÚC, hoặc xảy ra theo điều kiện mở — "cái nào đủ điều kiện thì làm cái đó". Đây chính là lúc bạn cần đến hai loại cổng còn lại trong nhóm phổ biến nhất của BPMN: Parallel Gateway (AND) và Inclusive Gateway (OR).
Hãy hình dung khi một khách hàng đặt mua một đơn hàng lớn trên Tiki. Hệ thống không thể "rẽ một đường": nó phải đồng thời (1) trừ tồn kho, (2) xử lý thanh toán, và (3) gửi email xác nhận. Ba việc này không phụ thuộc nhau, nên để chúng chạy nối tiếp sẽ làm chậm trải nghiệm khách hàng một cách vô lý. Parallel Gateway giải quyết chính xác bài toán này.
Nắm vững hai loại cổng này là ranh giới phân biệt giữa một người "vẽ được sơ đồ cho đẹp" và một Business Process Analyst thực thụ — người hiểu rõ token (mã thông báo điều khiển) chạy như thế nào, và quan trọng nhất: hiểu vì sao một mô hình sai sót về gateway có thể khiến cả quy trình bị treo (deadlock) hoặc chạy lệch (stuck) khi đưa vào engine thực thi. Trong bài này, mentor sẽ giúp bạn không chỉ "biết ký hiệu" mà còn "hiểu cơ chế".
Khái niệm cốt lõi
Parallel Gateway (AND) — cổng song song
Ký hiệu: hình thoi (diamond) có dấu cộng + ở giữa.
Parallel Gateway buộc quy trình tách ra thành nhiều nhánh chạy đồng thời, không phụ thuộc vào bất kỳ điều kiện nào. Đây là điểm khác biệt cốt lõi so với Exclusive Gateway: ở XOR bạn đặt câu hỏi "đi đường nào?", còn ở Parallel bạn KHÔNG đặt câu hỏi gì cả — tất cả các đường đều được đi.
Parallel Gateway có hai vai trò:
- Split (phân nhánh / fork): Khi một token đi vào cổng split, engine tạo ra một token cho TẤT CẢ các nhánh đầu ra. Mỗi nhánh chạy độc lập và song song. Nếu cổng có 3 nhánh ra, sẽ có 3 token được sinh ra cùng lúc.
- Merge (đồng bộ / join): Cổng merge làm nhiệm vụ chờ đợi. Nó đợi cho đến khi token từ TẤT CẢ các nhánh đầu vào đã đến nơi, rồi mới gộp lại thành một token duy nhất và cho đi tiếp. Đây gọi là cơ chế synchronization (đồng bộ hóa). Nếu chỉ 2 trong 3 nhánh hoàn thành, cổng merge sẽ đứng yên chờ nhánh thứ 3 — không bao giờ tự cho đi tiếp.
Inclusive Gateway (OR) — cổng bao hàm
Ký hiệu: hình thoi có vòng tròn O ở giữa.
Inclusive Gateway là sự kết hợp linh hoạt giữa Exclusive và Parallel. Mỗi nhánh đầu ra đều có một điều kiện gắn kèm. Khi token đi vào:
- Split: Engine đánh giá điều kiện của mọi nhánh. Nhánh nào có điều kiện đúng (true) thì sẽ nhận một token. Có thể là một, vài, hoặc tất cả nhánh được kích hoạt cùng lúc — tùy vào dữ liệu thực tế. Đây là chỗ chữ "Inclusive" (bao hàm) thể hiện: nó bao hàm mọi khả năng đúng, không loại trừ như XOR.
- Merge: Đây là phần khó nhất và cũng là nơi nhiều người làm sai. Cổng merge của Inclusive chỉ chờ đúng những nhánh đã thực sự được kích hoạt ở split. Nó "thông minh" hơn Parallel merge: không chờ mù quáng tất cả nhánh, mà chờ đúng số token đang thực sự chạy về phía nó. Để làm được điều này, engine phải nhìn ngược lại cấu trúc đồ thị để biết nhánh nào có khả năng gửi token tới.
| Loại cổng | Ký hiệu | Số nhánh kích hoạt khi split | Hành vi merge |
|---|---|---|---|
| Exclusive (XOR) | × | Đúng 1 | Đi tiếp ngay khi 1 token tới |
| Parallel (AND) | + | Tất cả | Chờ tất cả token |
| Inclusive (OR) | O | 1 đến tất cả (tùy điều kiện) | Chờ đúng các nhánh đã kích hoạt |
Vì sao merge lại quan trọng đến vậy?
Điểm mấu chốt mà mentor muốn bạn ghi nhớ: gateway split và merge phải đi thành cặp, đúng loại với nhau. Nếu bạn split bằng Parallel rồi merge bằng Exclusive, quy trình sẽ "rò rỉ" token — mỗi nhánh khi về tới XOR sẽ cho đi tiếp ngay, khiến phần sau quy trình chạy lặp lại nhiều lần (mỗi token một lần). Ngược lại, nếu bạn split bằng Inclusive nhưng merge bằng Parallel, cổng Parallel sẽ chờ TẤT CẢ nhánh — kể cả nhánh không hề được kích hoạt — và quy trình sẽ treo vĩnh viễn (deadlock) vì token chờ mãi không bao giờ tới.
Tình huống thực tế
Ví dụ 1 — Xử lý đơn hàng tại sàn TMĐT (Parallel Gateway)
Bối cảnh: Một sàn thương mại điện tử giả định tên ShopMart (mô hình tương tự Tiki, Lazada) xử lý đơn hàng giá trị cao. Sau khi đơn được xác nhận, có ba việc bắt buộc phải làm, và chúng hoàn toàn độc lập:
- Trừ tồn kho tại kho hàng (mất ~2 giây)
- Xử lý thanh toán qua cổng VNPay (mất ~5 giây)
- Gửi email xác nhận cho khách (mất ~1 giây)
Vì sao phải merge bằng Parallel? Vì bước vận chuyển KHÔNG được phép bắt đầu nếu thanh toán chưa xong hoặc tồn kho chưa trừ. Đồng bộ hóa ở đây là yêu cầu nghiệp vụ bắt buộc, không phải tùy chọn.
Bài học rút ra: Parallel Gateway không chỉ giúp vẽ đúng mà còn là công cụ tối ưu thời gian thực sự. Khi các bước độc lập về dữ liệu, hãy mạnh dạn cho chúng chạy song song. Nhưng luôn nhớ đặt cổng merge để đồng bộ trước khi sang bước phụ thuộc.
Ví dụ 2 — Quy trình mở tài khoản tại ngân hàng (Inclusive Gateway)
Bối cảnh: Một ngân hàng số tại Việt Nam (giả định tên VietBank Digital) có quy trình duyệt hồ sơ mở tài khoản kèm các sản phẩm phụ. Khi khách hàng đăng ký, họ có thể tick chọn thêm: thẻ tín dụng, vay tiêu dùng, và/hoặc bảo hiểm liên kết. Khách có thể chọn 0, 1, 2 hay cả 3 sản phẩm.
Diễn giải: Đây là tình huống kinh điển cho Inclusive Gateway. Sau bước "Mở tài khoản cơ bản", đặt một Inclusive split với ba nhánh điều kiện:
- Nhánh 1:
khách chọn thẻ tín dụng = true→ bộ phận thẻ thẩm định - Nhánh 2:
khách chọn vay = true→ bộ phận tín dụng chấm điểm - Nhánh 3:
khách chọn bảo hiểm = true→ bộ phận bancassurance xử lý
Hãy thử tưởng tượng nếu đội thiết kế dùng nhầm Parallel merge: cổng sẽ chờ cả nhánh vay (nhánh 2) — vốn không bao giờ được kích hoạt cho khách này — và hồ sơ sẽ treo vĩnh viễn. Khách hàng chờ mãi không nhận được thông báo, còn nhân viên không hiểu vì sao "đơn bị kẹt trong hệ thống".
Bài học rút ra: Khi số nhánh được thực hiện thay đổi tùy theo dữ liệu của từng ca, Inclusive Gateway là lựa chọn đúng. Và tuyệt đối phải dùng Inclusive merge — đừng bao giờ trộn lẫn với Parallel merge.
Ví dụ 3 — Quy trình duyệt chi phí (so sánh AND vs OR)
Bối cảnh: Một công ty công nghệ tại TP.HCM xử lý đề nghị thanh toán chi phí của nhân viên. Quy tắc: mọi đề nghị đều cần Kế toán kiểm tra hóa đơn (luôn luôn), đồng thời tùy giá trị mà cần thêm các cấp duyệt.
Tình huống này khéo léo dùng cả hai loại cổng. Trước hết, một Parallel split tách ra hai nhánh luôn-luôn-chạy: "Kế toán kiểm tra hóa đơn" và "Kiểm tra ngân sách phòng ban". Cả hai luôn bắt buộc nên dùng AND là chuẩn xác.
Tiếp đó, ở nhánh phê duyệt, một Inclusive split dựa trên giá trị chi phí:
số tiền > 5 triệu→ Trưởng phòng duyệtsố tiền > 50 triệu→ Giám đốc tài chính duyệtliên quan đối tác nước ngoài = true→ Phòng Pháp chế rà soát
Bài học rút ra: Trong thực tế, bạn thường phối hợp nhiều loại gateway trong cùng một quy trình. Nguyên tắc chọn: luôn-luôn-chạy thì dùng Parallel; chạy-tùy-điều-kiện-và-có-thể-nhiều-cái thì dùng Inclusive; chỉ-một-cái-duy-nhất thì dùng Exclusive.
Hướng dẫn từng bước
Khi cần mô hình hóa một đoạn quy trình có rẽ nhánh, hãy đi theo trình tự sau:
- Liệt kê các công việc sau điểm rẽ. Viết ra tất cả các nhánh có thể xảy ra mà chưa vội nghĩ đến ký hiệu.
- Trả lời câu hỏi vàng cho mỗi nhánh: "Việc này LUÔN xảy ra, hay chỉ xảy ra KHI một điều kiện đúng?"
- Đặt cổng split với đúng ký hiệu (
+cho Parallel,Ocho Inclusive). Với Inclusive, ghi rõ điều kiện trên từng sequence flow ra.
- Vẽ các hoạt động trên từng nhánh. Mỗi nhánh là một luồng độc lập.
- Đặt cổng merge ĐÚNG LOẠI với split. Đây là bước hay bị quên nhất. Parallel split → Parallel merge. Inclusive split → Inclusive merge. Số nhánh vào merge phải khớp số nhánh ra từ split.
- Kiểm tra cân bằng token (token balance): Hình dung một token đi vào split, đếm xem nó sinh ra bao nhiêu token, rồi xác nhận cổng merge gom đủ chừng đó token để trả về một token duy nhất. Nếu không cân bằng, quy trình sẽ lỗi.
- Mô phỏng vài ca thực tế: Với Inclusive, hãy thử các kịch bản (chọn 1 sản phẩm, chọn 2, chọn cả 3) và kiểm tra cổng merge có chờ đúng số nhánh không.
Lỗi thường gặp & mẹo
Lỗi 1 — Quên cổng merge. Người mới thường split rồi để các nhánh "tự chảy" vào bước tiếp theo. Hậu quả: bước sau bị kích hoạt nhiều lần (mỗi token một lần). Mẹo: cứ split là phải nghĩ ngay đến merge — chúng đi thành cặp.
Lỗi 2 — Trộn loại cổng split và merge. Split Parallel nhưng merge Exclusive (gây chạy lặp), hoặc split Inclusive nhưng merge Parallel (gây deadlock). Mẹo: ghi nhớ quy tắc "cùng loại, cùng cặp".
Lỗi 3 — Dùng Parallel khi đáng lẽ phải Inclusive. Khi không phải nhánh nào cũng chạy, dùng Parallel sẽ khiến cổng merge chờ những nhánh trống và treo quy trình. Mẹo: hỏi "có ca nào mà một nhánh KHÔNG chạy không?" — nếu có, dùng Inclusive.
Lỗi 4 — Gắn điều kiện lên Parallel Gateway. Parallel KHÔNG đánh giá điều kiện — mọi nhánh đều chạy bất kể bạn viết gì lên đó. Nếu bạn cần điều kiện, đó là dấu hiệu phải đổi sang Inclusive hoặc Exclusive.
Mẹo về hiệu năng: Inclusive Gateway tốn tài nguyên tính toán hơn Parallel vì engine phải phân tích đồ thị để biết chờ nhánh nào. Một số engine cũ xử lý Inclusive merge chưa tối ưu. Nếu một quy trình thực ra luôn kích hoạt tất cả nhánh, hãy ưu tiên Parallel cho gọn và nhanh.
Mẹo đặt tên: Đừng đặt nhãn câu hỏi cho Parallel Gateway (vì không có lựa chọn nào cả). Chỉ Exclusive và Inclusive mới cần nhãn điều kiện trên các nhánh ra.
Bài tập thực hành
Bài 1 — Phân loại cổng. Với mỗi tình huống, hãy xác định nên dùng Parallel hay Inclusive:
- a) Sau khi tuyển dụng, công ty đồng thời: cấp email, làm thẻ ra vào, đăng ký bảo hiểm. Cả ba luôn làm.
- b) Khi khách đặt tour, tùy chọn mà cần xử lý: visa (nếu đi nước ngoài), thuê xe (nếu chọn), hướng dẫn viên (nếu chọn).
Bài 3 — Tìm lỗi. Một bạn đồng nghiệp vẽ quy trình mở tài khoản kèm sản phẩm tùy chọn (như Ví dụ 2), dùng Inclusive để split nhưng dùng Parallel để merge. Hãy giải thích bằng lời chuyện gì sẽ xảy ra với một khách chỉ chọn 1 trong 3 sản phẩm, và đề xuất cách sửa.
Gợi ý đáp án: Bài 1: a) Parallel — vì luôn làm cả ba; b) Inclusive — vì tùy chọn và có thể nhiều. Bài 3: Parallel merge chờ cả 3 nhánh, nhưng 2 nhánh không được kích hoạt sẽ không bao giờ gửi token → deadlock; sửa bằng cách đổi merge thành Inclusive.
Tóm tắt
Parallel Gateway (+) và Inclusive Gateway (O) là hai công cụ giúp bạn mô hình hóa những quy trình thực tế có nhiều việc xảy ra cùng lúc. Parallel kích hoạt TẤT CẢ nhánh vô điều kiện và merge bằng cách chờ đủ tất cả token — lý tưởng cho các bước độc lập luôn-luôn-chạy, đồng thời giúp tối ưu thời gian. Inclusive kích hoạt các nhánh có điều kiện đúng (một, vài, hay tất cả) và merge bằng cách chờ đúng những nhánh đã được kích hoạt — lý tưởng cho các quy trình mà số việc cần làm thay đổi theo từng ca.
Quy tắc sống còn cần khắc cốt ghi tâm: split và merge phải cùng loại và đi thành cặp; tách ra bao nhiêu phải gộp lại bấy nhiêu. Trộn lẫn loại cổng là nguyên nhân số một gây deadlock hoặc chạy lặp khi quy trình được đưa vào engine thực thi. Khi phân vân, hãy quay lại câu hỏi vàng: "Nhánh này LUÔN chạy, hay chỉ chạy KHI điều kiện đúng?" — câu trả lời sẽ dẫn bạn đến đúng loại cổng. Ở bài tiếp theo, chúng ta sẽ khám phá hai loại cổng nâng cao hơn: Event-based Gateway và Complex Gateway.