Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vẽ một quy trình "Đặt hàng online" cho một sàn thương mại điện tử như Tiki. Bạn có khách hàng, có hệ thống bán hàng, có kho vận, có ngân hàng xử lý thanh toán. Mỗi bên là một "thế giới riêng" — họ không nhìn thấy nội bộ của nhau, họ chỉ trao đổi với nhau qua những thông điệp (message): "Đơn hàng mới", "Xác nhận thanh toán", "Đã giao hàng". Nếu bạn cố nhồi tất cả các bên này vào một sơ đồ quy trình duy nhất kiểu Bài 1 đã học, bạn sẽ nhanh chóng nhận ra nó không diễn tả được câu hỏi quan trọng nhất: ai gửi gì cho ai, và theo thứ tự nào?
Đây chính là khoảng trống mà BPMN lấp đầy bằng hai loại sơ đồ ở cấp độ cao hơn: Collaboration Diagram (sơ đồ cộng tác) và Choreography Diagram (sơ đồ vũ đạo / điều phối thông điệp). Nếu các bài trước (Pool/Lane ở Bài 12, Message Flow ở Bài 18) dạy bạn từng "viên gạch", thì bài này dạy bạn cách lắp các viên gạch thành một bức tranh liên-tổ-chức (cross-organizational). Trong thực tế đi làm, đây là những sơ đồ mà Business Analyst dùng để nói chuyện với đối tác, với phòng ban khác, với nhà cung cấp — những nơi bạn không kiểm soát được quy trình nội bộ nhưng vẫn phải phối hợp nhịp nhàng.
Hiểu rõ Collaboration và Choreography giúp bạn trả lời được những câu hỏi mà sếp và khách hàng luôn hỏi: "Hợp đồng tích hợp giữa hệ thống của ta và đối tác gồm những thông điệp gì?", "Bên nào chịu trách nhiệm khởi tạo bước này?", "Nếu đối tác không phản hồi thì quy trình kẹt ở đâu?". Đây là tư duy thiết kế giao tiếp giữa các hệ thống — cực kỳ quan trọng trong thời đại tích hợp API và microservices.
Khái niệm cốt lõi
Collaboration Diagram — góc nhìn "ai gửi gì cho ai"
Một Collaboration Diagram là sơ đồ có từ hai Pool trở lên, và giữa các Pool là các Message Flow (mũi tên nét đứt, đầu mũi tên rỗng) thể hiện thông điệp trao đổi. Mỗi Pool đại diện cho một participant — một bên tham gia, có thể là một tổ chức (Tiki, ngân hàng), một hệ thống (cổng thanh toán), hoặc một vai trò ở mức rất cao.
Điểm cốt lõi cần nhớ:
- Trong một Pool, các hoạt động được nối với nhau bằng Sequence Flow (mũi tên nét liền) — đây là dòng điều khiển nội bộ.
- Giữa hai Pool, các bên chỉ được nối với nhau bằng Message Flow (nét đứt) — vì bạn không thể "ra lệnh" cho quy trình nội bộ của người khác, bạn chỉ có thể gửi thông điệp cho họ.
- White-box (Pool mở): bạn vẽ chi tiết bên trong — các task, gateway, event. Dùng khi đó là quy trình của chính bạn, bạn biết và muốn mô tả nội bộ.
- Black-box (Pool đóng/rỗng): bạn vẽ một hình chữ nhật rỗng, không có gì bên trong, chỉ có tên. Dùng cho đối tác bên ngoài — bạn không biết (hoặc không cần quan tâm) họ làm gì bên trong, bạn chỉ quan tâm họ gửi/nhận thông điệp gì. Ngân hàng, cơ quan thuế, nhà cung cấp thường được vẽ dạng black-box.
Choreography Diagram — góc nhìn lấy thông điệp làm trung tâm
Choreography Diagram là loại sơ đồ mới được giới thiệu chính thức trong BPMN 2.0 (BPMN 1.x chưa có). Nó trả lời câu hỏi hơi khác: thay vì hỏi "mỗi bên làm gì bên trong", nó hỏi "trình tự trao đổi thông điệp giữa các bên diễn ra như thế nào?".
Trong Choreography, không có Pool nào cả. Đơn vị cơ bản là Choreography Task — một hình chữ nhật bo góc, chia thành các band (dải). Mỗi band ghi tên một participant:
- Band của người khởi xướng (initiator) — bên gửi thông điệp đầu tiên — thường tô màu trắng/sáng và nằm trên.
- Band của người nhận (recipient) thường tô đậm/xám và nằm dưới.
- Tên Choreography Task ở giữa mô tả thông điệp/tương tác đang diễn ra, ví dụ "Gửi yêu cầu báo giá".
So sánh nhanh để khỏi nhầm
| Tiêu chí | Collaboration | Choreography |
|---|---|---|
| Đơn vị chính | Pool (participant) | Choreography Task (tương tác) |
| Trọng tâm | Hành vi nội bộ + thông điệp | Thứ tự trao đổi thông điệp |
| Có Pool/Lane không? | Có | Không |
| Có bộ điều khiển trung tâm? | Mỗi Pool có dòng điều khiển riêng | Không có ai điều khiển trung tâm |
| Khi nào dùng | Mô tả quy trình của ta + giao tiếp với bên ngoài | Định nghĩa "hợp đồng" trao đổi giữa nhiều bên |
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Tiki và cổng thanh toán VNPay (Collaboration)
Đội Business Analyst của một sàn TMĐT tại TP.HCM cần mô tả luồng thanh toán đơn hàng. Họ vẽ một Collaboration Diagram với ba Pool:
- Pool "Khách hàng" (black-box): chỉ là hình rỗng, vì sàn không kiểm soát hành vi khách.
- Pool "Hệ thống Tiki" (white-box): chi tiết các task — "Tạo đơn hàng", "Gọi cổng thanh toán", gateway XOR "Thanh toán thành công?", "Xác nhận đơn", "Hủy đơn".
- Pool "VNPay" (black-box): cổng thanh toán bên ngoài, chỉ vẽ rỗng.
Bài học rút ra: Khi vẽ ra như vậy, đội BA phát hiện một lỗ hổng — họ không có Message Flow nào xử lý trường hợp VNPay không phản hồi trong 90 giây (timeout). Sơ đồ Collaboration đã biến một rủi ro tích hợp vô hình thành thứ nhìn thấy được trên giấy, trước khi nó trở thành đơn hàng "treo" gây khiếu nại. Họ bổ sung một boundary timer event (sẽ học kỹ ở Bài 42) ngay tại task "Gọi cổng thanh toán".
Ví dụ 2 — Ngân hàng và khách hàng vay tiêu dùng (Collaboration với black-box)
Một ngân hàng số tại Hà Nội số hóa quy trình vay tiêu dùng. BA vẽ Collaboration với Pool "Khách hàng" (black-box) và Pool "Ngân hàng" (white-box, chi tiết: nhận hồ sơ → chấm điểm tín dụng → gateway "Đạt chuẩn?" → phê duyệt hoặc từ chối). Thêm Pool "Trung tâm Thông tin Tín dụng CIC" (black-box).
Các thông điệp: Khách → Ngân hàng ("Nộp hồ sơ vay"), Ngân hàng → CIC ("Tra cứu lịch sử tín dụng"), CIC → Ngân hàng ("Báo cáo điểm CIC"), Ngân hàng → Khách ("Thông báo kết quả").
Bài học rút ra: Việc để CIC là black-box giúp sơ đồ gọn gàng và tập trung. Ngân hàng không cần (và không được phép) mô tả nội bộ của CIC. Nhưng quan trọng hơn, sơ đồ làm rõ một điểm phụ thuộc bên ngoài: nếu CIC chậm trả lời thì toàn bộ quy trình phê duyệt bị chặn. Đây là thông tin vàng để đội vận hành thiết kế SLA với CIC (chủ đề Bài 36) và bố trí phương án dự phòng.
Ví dụ 3 — Chuỗi cung ứng cà phê xuất khẩu (Choreography)
Một doanh nghiệp xuất khẩu cà phê ở Đắk Lắk làm việc với ba bên độc lập: Nông trại, Nhà xuất khẩu, và Người mua quốc tế ở châu Âu. Không bên nào "sở hữu" quy trình chung; mỗi bên có hệ thống riêng. Đây là tình huống lý tưởng cho Choreography Diagram, vì mục tiêu là thống nhất trình tự trao đổi thông điệp như một hợp đồng giao tiếp.
Chuỗi Choreography Task:
- "Gửi yêu cầu báo giá" — initiator: Người mua, recipient: Nhà xuất khẩu.
- "Gửi báo giá + mẫu" — initiator: Nhà xuất khẩu, recipient: Người mua.
- Gateway XOR: chấp nhận hay không.
- Nếu chấp nhận: "Đặt đơn 18 tấn" — Người mua → Nhà xuất khẩu.
- "Yêu cầu thu hoạch lô hàng" — Nhà xuất khẩu → Nông trại.
- "Xác nhận giao hàng + chứng từ" — Nông trại → Nhà xuất khẩu.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để xây một Collaboration Diagram (loại bạn sẽ dùng 90% thời gian), và phần cuối nói khi nào nâng cấp lên Choreography.
Bước 1 — Liệt kê các participant. Viết ra tất cả các bên tham gia: tổ chức, phòng ban, hệ thống bên ngoài. Mỗi bên sẽ là một Pool. Hỏi: "Bên này có ranh giới sở hữu riêng không?" Nếu có, nó xứng đáng là một Pool độc lập.
Bước 2 — Quyết định white-box hay black-box cho từng Pool. Quy trình của chính bạn / đội bạn → white-box (vẽ chi tiết). Đối tác bên ngoài, hệ thống bạn không kiểm soát → black-box (rỗng). Đừng cố vẽ nội bộ của đối tác khi bạn chỉ đang đoán.
Bước 3 — Vẽ chi tiết bên trong các Pool white-box. Dùng Sequence Flow (nét liền) để nối các task, event, gateway. Mỗi Pool phải có dòng điều khiển khép kín của riêng nó — có Start Event và End Event riêng.
Bước 4 — Xác định các thông điệp trao đổi. Với từng cặp Pool, hỏi: "Họ gửi gì cho nhau?". Mỗi thông điệp là một Message Flow (nét đứt). Đặt tên thông điệp bằng danh từ rõ ràng: "Yêu cầu thanh toán", "Kết quả phê duyệt" — đừng để mũi tên trống không tên.
Bước 5 — Gắn Message Flow đúng điểm. Message Flow phải đi từ một điểm phát (task, hoặc message throw event) ở Pool gửi, đến một điểm nhận (task, hoặc message catch event/start event) ở Pool nhận. Đừng nối Message Flow vào một gateway hay sequence flow — đó là lỗi cú pháp.
Bước 6 — Kiểm tra tính cân bằng. Mỗi thông điệp gửi đi nên có nơi nhận tương ứng, và ngược lại mỗi điểm chờ nhận nên có nguồn gửi. Một message catch event treo lơ lửng không có ai gửi là dấu hiệu thiếu sót.
Bước 7 — Khi nào nâng cấp lên Choreography: nếu bạn có từ 3 bên độc lập trở lên, không bên nào điều phối trung tâm, và mục tiêu là thống nhất trình tự đối thoại (giao thức B2B, chuẩn EDI, tích hợp đa hệ thống) — hãy rút gọn thành Choreography Diagram, mỗi tương tác là một Choreography Task với band initiator (sáng, trên) và recipient (đậm, dưới).
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng Sequence Flow nối giữa hai Pool. Đây là lỗi kinh điển. Hai participant khác nhau KHÔNG BAO GIỜ được nối bằng Sequence Flow. Giữa các Pool chỉ có Message Flow. Lý do: bạn không điều khiển được quy trình của người khác bằng dòng điều khiển; bạn chỉ giao tiếp qua thông điệp. Mẹo: hễ mũi tên vượt qua biên một Pool thì nó phải là nét đứt.
Lỗi 2 — Vẽ nội bộ của đối tác mà thực ra không biết. Nhiều người mới thích vẽ chi tiết Pool "Ngân hàng" với hàng loạt task đoán mò. Điều này tạo ấn tượng sai rằng bạn nắm rõ nội bộ họ, và sơ đồ sẽ sai khi thực tế khác đi. Mẹo: nếu không chắc chắn, hãy để black-box. Black-box không phải lười — nó là sự trung thực về phạm vi hiểu biết.
Lỗi 3 — Nhồi tất cả vào một Pool có nhiều Lane thay vì nhiều Pool. Lane (Bài 12) dùng cho các vai trò trong cùng một tổ chức (cùng dòng điều khiển, nối bằng Sequence Flow). Pool dùng cho các tổ chức/hệ thống độc lập (nối bằng Message Flow). Nhầm hai cái này khiến sơ đồ sai bản chất. Mẹo tự kiểm: "Hai bên này có chung sếp / chung dòng điều khiển không?" Có → Lane. Không → Pool.
Lỗi 4 — Quên xác định initiator trong Choreography. Choreography Task bắt buộc phải rõ ai là người khởi xướng (band sáng). Nếu để mơ hồ, cả "vũ đạo" sẽ bị lệch nhịp. Mẹo: luôn đặt band initiator ở trên cùng và tô sáng theo quy ước.
Lỗi 5 — Lạm dụng Choreography khi Collaboration là đủ. Choreography mạnh nhưng kén người đọc; nhiều stakeholder thấy lạ lẫm. Trừ khi bạn thực sự cần đặc tả giao thức đa bên, hãy ưu tiên Collaboration vì nó trực quan và phổ biến hơn.
Mẹo vàng: Bắt đầu mọi sơ đồ liên-tổ-chức bằng câu hỏi "Có bao nhiêu biên sở hữu khác nhau ở đây?". Mỗi biên là một Pool. Trả lời đúng câu này, bạn đã đi đúng hướng 80% rồi.
Bài tập thực hành
Bài 1 — Đọc hiểu: Cho một Collaboration Diagram của quy trình đặt vé máy bay với 3 Pool: "Hành khách" (black-box), "Hệ thống đại lý" (white-box), "Hãng hàng không" (black-box). Hãy liệt kê tối thiểu 4 Message Flow cần có và đặt tên cho từng thông điệp.
Bài 2 — Phát hiện lỗi: Một bạn đồng nghiệp vẽ sơ đồ giao hàng với Pool "Cửa hàng" và Pool "Shipper Grab", và nối task "Đóng gói" (ở Cửa hàng) với task "Nhận hàng" (ở Grab) bằng một mũi tên nét liền (Sequence Flow). Lỗi ở đâu? Sửa thế nào?
Bài 3 — Thực hành vẽ: Dùng draw.io hoặc Bizagi (các công cụ sẽ học ở Bài 32, 33), vẽ một Collaboration Diagram cho quy trình "Đăng ký khóa học online" gồm: Học viên (black-box), Nền tảng học (white-box, có gateway "Thanh toán OK?"), Cổng thanh toán Momo (black-box). Yêu cầu: tối thiểu 5 Message Flow có tên rõ ràng, và xử lý cả nhánh thanh toán thất bại.
Bài 4 — Nâng cao (Choreography): Mô tả lại quy trình "Đàm phán hợp đồng" giữa 3 bên (Nhà cung cấp, Khách hàng, Bên thẩm định độc lập) dưới dạng Choreography Diagram. Viết ra danh sách các Choreography Task theo thứ tự, và với mỗi task chỉ rõ ai là initiator, ai là recipient.
Tóm tắt
- Collaboration Diagram dùng từ hai Pool trở lên, nối với nhau bằng Message Flow (nét đứt) — trả lời câu hỏi "ai gửi gì cho ai". Đây là loại sơ đồ liên-tổ-chức bạn sẽ dùng thường xuyên nhất.
- Mỗi Pool có thể là white-box (vẽ chi tiết nội bộ — dùng cho quy trình của chính bạn) hoặc black-box (rỗng — dùng cho đối tác bên ngoài bạn không kiểm soát).
- Trong Pool: Sequence Flow (nét liền). Giữa các Pool: chỉ Message Flow (nét đứt). Đây là quy tắc bất di bất dịch — đừng bao giờ nối hai Pool bằng Sequence Flow.
- Choreography Diagram là tính năng mới của BPMN 2.0, không có Pool, lấy Choreography Task làm trung tâm để mô tả trình tự trao đổi thông điệp giữa nhiều bên độc lập, không có bộ điều khiển trung tâm. Mỗi task có band initiator (sáng) và recipient (đậm).
- Phân biệt Pool vs Lane: Pool cho tổ chức/hệ thống độc lập; Lane cho vai trò trong cùng một tổ chức.
- Giá trị thực tế lớn nhất: các sơ đồ này biến những điểm phụ thuộc và rủi ro tích hợp vô hình (đối tác chậm phản hồi, thông điệp thiếu, ai khởi xướng bước nào) thành thứ nhìn thấy được trên giấy — trước khi chúng thành sự cố ngoài đời.