Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang vẽ một quy trình "Khách hàng đặt món trên app, nhà hàng nhận đơn, shipper giao hàng". Nếu bạn chỉ vẽ một dãy task nối tiếp nhau từ trái sang phải, người đọc sẽ hỏi ngay: "Ai làm việc này? Khách hàng tự bấm hay hệ thống tự động? Cái task xác nhận đơn là của nhà hàng hay của tổng đài?". Một sơ đồ quy trình mà không chỉ rõ ai chịu trách nhiệm cho từng việc thì gần như vô dụng khi đưa vào thực tế — vì khi có sự cố, không ai biết phải gọi cho bộ phận nào.
Đây chính là lý do Pools và Lanes tồn tại trong BPMN 2.0. Chúng là công cụ để trả lời câu hỏi "WHO" — ai làm gì trong quy trình. Nếu Events, Activities và Gateways (mà bạn sẽ học ở các bài sau) trả lời câu hỏi "WHAT" và "WHEN", thì Pools và Lanes trả lời "WHO". Đây là hai khái niệm nền tảng mà bất kỳ Business Process Analyst nào cũng phải nắm vững trước khi vẽ bất cứ sơ đồ nào phức tạp hơn một dòng chảy đơn giản.
Trong bài này, tôi sẽ giúp bạn phân biệt rõ Pool và Lane, hiểu khi nào dùng cái nào, và quan trọng nhất là tránh được những lỗi kinh điển mà ngay cả người đã vẽ BPMN vài năm vẫn mắc phải — đặc biệt là lỗi liên quan đến đường chảy (flow) cắt ngang Pool.
Khái niệm cốt lõi
Pool — một "participant" độc lập
Pool (cái hồ bơi) là hình chữ nhật lớn, thường nằm ngang, đại diện cho một participant trong quy trình. Participant ở đây có thể là:
- Một tổ chức: Công ty A, Ngân hàng B, Nhà cung cấp C.
- Một vai trò nghiệp vụ tổng quát ở góc nhìn cao: "Khách hàng", "Đối tác giao vận".
- Một hệ thống: "Hệ thống cổng thanh toán VNPay", "ERP nội bộ".
Có một loại Pool đặc biệt gọi là Black Box Pool (Pool hộp đen) — là Pool rỗng, không vẽ gì bên trong. Bạn dùng nó khi bạn không biết hoặc không quan tâm chuyện gì xảy ra bên trong participant đó. Ví dụ: bạn vẽ quy trình của công ty mình, và khách hàng chỉ hiện ra như một hộp đen — bạn không kiểm soát được khách hàng nghĩ gì hay làm gì bên trong, bạn chỉ biết bạn gửi email cho họ và họ gửi lại đơn hàng.
Lane — sự phân chia bên trong một Pool
Lane (làn đường) là sự phân chia nhỏ bên trong một Pool duy nhất. Trong khi Pool tách biệt các participant khác nhau, Lane tách biệt các vai trò, phòng ban, hoặc chức năng con bên trong cùng một participant.
Ví dụ: Pool là "Công ty FPT Software". Bên trong Pool đó, bạn chia thành các Lane: "Phòng Kinh doanh", "Phòng Pháp chế", "Phòng Tài chính". Cả ba làn này nằm trong cùng một tổ chức, dùng chung một dòng chảy quy trình, nhưng mỗi việc được gán vào làn của bộ phận chịu trách nhiệm.
Điểm khác biệt then chốt nằm ở dòng chảy:
- Trong cùng một Pool, dòng chảy đi qua các Lane bằng Sequence Flow (mũi tên liền nét). Một task ở làn Kinh doanh có thể nối thẳng bằng mũi tên liền nét sang task ở làn Pháp chế.
- Giữa hai Pool khác nhau, bạn KHÔNG được dùng Sequence Flow. Bạn phải dùng Message Flow (mũi tên nét đứt, đầu mũi tên rỗng). Vì hai participant độc lập không "điều khiển" nhau bằng dòng tuần tự — họ chỉ trao đổi thông điệp.
Khi nào dùng Pool, khi nào dùng Lane?
Một nguyên tắc thực dụng để quyết định:
- Nếu hai bên là hai thực thể độc lập, không kiểm soát lẫn nhau (công ty mình với khách hàng, với nhà cung cấp, với cơ quan thuế) → dùng Pool riêng.
- Nếu các bên nằm trong cùng một tổ chức và bạn kiểm soát được toàn bộ dòng chảy (các phòng ban nội bộ) → dùng Lane trong cùng một Pool.
Định hướng ngang hay dọc?
Pool và Lane có thể vẽ ngang (horizontal — phổ biến nhất ở phương Tây) hoặc dọc (vertical). Định hướng không thay đổi ý nghĩa, chỉ là sở thích trình bày. Lời khuyên: chọn một kiểu và nhất quán trong toàn bộ tài liệu của dự án.
Tình huống thực tế
Ví dụ 1 — Quy trình đặt món của GrabFood (3 Pool)
Bối cảnh: Bạn được giao mô hình hóa quy trình một đơn hàng GrabFood từ lúc khách bấm đặt đến lúc nhận món. Có ba bên rõ ràng tham gia, mỗi bên hoàn toàn độc lập:
- Pool 1 — Khách hàng: Start (đói bụng) → Mở app, chọn món → Bấm đặt và thanh toán → (chờ) → Nhận món → End.
- Pool 2 — Nền tảng Grab: Nhận đơn → Trừ tiền qua ví → Tìm shipper gần nhất → Gửi đơn cho nhà hàng → Theo dõi giao hàng → End.
- Pool 3 — Nhà hàng & Shipper: Nhận đơn → Chuẩn bị món → Bàn giao cho shipper → Giao đến khách → End.
Bài học rút ra: Khi nhiều tổ chức độc lập tham gia, mỗi tổ chức là một Pool, và mọi giao tiếp giữa chúng phải đi qua Message Flow. Việc tách Pool giúp lãnh đạo nhìn ngay được "chỗ nào là trách nhiệm của Grab, chỗ nào là của nhà hàng" — cực kỳ hữu ích khi đơn hàng bị chậm và cần truy trách nhiệm.
Ví dụ 2 — Quy trình duyệt hồ sơ vay tại một ngân hàng (1 Pool, nhiều Lane)
Bối cảnh: Một ngân hàng thương mại cổ phần ở TP.HCM muốn chuẩn hóa quy trình phê duyệt khoản vay tiêu dùng dưới 200 triệu đồng. Toàn bộ quy trình diễn ra bên trong ngân hàng, không có bên thứ ba điều khiển. Bạn chọn vẽ một Pool duy nhất tên "Ngân hàng", chia thành bốn Lane:
- Lane Quan hệ khách hàng (RM): Tiếp nhận hồ sơ → Kiểm tra giấy tờ đầy đủ.
- Lane Thẩm định: Chấm điểm tín dụng → Đề xuất hạn mức.
- Lane Phê duyệt: Trưởng phòng duyệt (nếu dưới 100 triệu) hoặc Giám đốc duyệt (nếu 100–200 triệu).
- Lane Giải ngân: Lập hợp đồng → Chuyển tiền vào tài khoản.
Bài học rút ra: Khi tất cả công việc nằm trong một tổ chức, hãy gói gọn trong một Pool và dùng Lane để phân vai. Sơ đồ này sau đó trở thành cơ sở để gán SLA cho từng phòng (ví dụ: Thẩm định phải xong trong 4 giờ làm việc) — một việc gần như bất khả thi nếu không phân Lane rõ ràng.
Ví dụ 3 — Lỗi tách Pool sai khiến dự án phải vẽ lại
Bối cảnh: Một bạn analyst tại một công ty thương mại điện tử ở Hà Nội vẽ quy trình "Xử lý hoàn hàng". Bạn ấy tách thành ba Pool: "Bộ phận Chăm sóc khách hàng", "Bộ phận Kho", "Bộ phận Kế toán". Vì nghĩ rằng ba bộ phận này là ba "đối tượng" khác nhau nên phải là ba Pool. Hậu quả: bạn ấy buộc phải nối ba Pool bằng Message Flow, và sơ đồ trông như ba tổ chức xa lạ gửi thư cho nhau, trong khi thực tế đây chỉ là quy trình nội bộ của một công ty.
Diễn giải: Cả ba bộ phận đều thuộc cùng một công ty, dòng công việc được chuyển giao trực tiếp và liên tục — đây đúng là tình huống của Lane trong một Pool, không phải ba Pool. Khi review, trưởng nhóm yêu cầu vẽ lại thành một Pool "Công ty" với ba Lane. Sơ đồ mới gọn hơn 40%, dễ đọc hơn hẳn, và quan trọng là phản ánh đúng bản chất "đây là việc nhà mình tự làm với nhau".
Bài học rút ra: Đừng để số lượng "phòng ban" đánh lừa bạn thành tách Pool. Hãy luôn quay về câu hỏi gốc: "Đây có phải là một participant độc lập không?". Phòng ban nội bộ gần như luôn là Lane, không phải Pool.
Hướng dẫn từng bước
Khi bắt tay vẽ một quy trình có nhiều bên tham gia, hãy theo trình tự sau:
- Liệt kê tất cả các bên tham gia (actor). Viết ra giấy mọi vai trò/tổ chức/hệ thống xuất hiện trong quy trình. Ví dụ: Khách hàng, Tổng đài, Phòng kho, Hệ thống thanh toán.
- Phân loại từng actor: độc lập hay nội bộ? Với mỗi actor, hỏi: "Mình có kiểm soát trực tiếp được không?". Độc lập → ứng viên cho Pool riêng. Nội bộ cùng tổ chức → ứng viên cho Lane.
- Vẽ các Pool trước. Tạo một Pool cho mỗi participant độc lập. Đặt tên Pool bằng danh từ chỉ thực thể (ví dụ "Ngân hàng", "Khách hàng"), không phải động từ.
- Chia Lane bên trong từng Pool. Trong Pool có nhiều vai trò nội bộ, kẻ các Lane và đặt tên theo phòng ban hoặc vai trò.
- Đặt mỗi Activity vào đúng Lane. Quy tắc: task nằm ở Lane của người/bộ phận thực hiện task đó. Nếu bạn phân vân một task thuộc Lane nào, đó là dấu hiệu trách nhiệm chưa rõ — cần làm rõ với nghiệp vụ.
- Nối dòng chảy bên trong mỗi Pool bằng Sequence Flow. Mũi tên liền nét, có thể cắt ngang giữa các Lane thoải mái.
- Nối giữa các Pool bằng Message Flow. Mỗi lần một Pool "gửi" gì đó cho Pool khác (yêu cầu, xác nhận, dữ liệu), vẽ một mũi tên nét đứt đầu rỗng. Thường gắn với một task gửi/nhận.
- Rà soát ranh giới. Đi dọc tất cả mũi tên: bất kỳ Sequence Flow nào cắt qua biên Pool đều SAI và phải sửa thành Message Flow (hoặc gộp Pool lại nếu thực ra là nội bộ).
Lỗi thường gặp & mẹo
Lỗi 1 — Sequence Flow cắt ngang hai Pool. Đây là lỗi số một. Hai Pool độc lập chỉ giao tiếp qua Message Flow. Nếu bạn thấy mình muốn kéo mũi tên liền nét sang Pool khác, hãy dừng lại: hoặc đổi thành Message Flow, hoặc nhận ra hai bên thực ra là nội bộ và nên gộp thành một Pool với hai Lane.
Lỗi 2 — Nhầm Lane thành Pool. Như ví dụ 3, tách các phòng ban nội bộ thành nhiều Pool làm sơ đồ rối và sai bản chất. Mẹo: nếu bạn kiểm soát được toàn bộ dòng chảy giữa các bên, chúng nên ở chung một Pool.
Lỗi 3 — Đặt nhiều Start Event trong một Pool một cách tùy tiện. Mỗi Pool nên có một câu chuyện rõ ràng, lý tưởng là một điểm bắt đầu. Nhiều Start Event không có lý do rõ ràng khiến người đọc bối rối "quy trình bắt đầu từ đâu".
Lỗi 4 — Đặt tên Pool bằng động từ. Pool là một thực thể (danh từ): "Khách hàng", "Ngân hàng", "Hệ thống ERP". Đừng đặt tên Pool là "Xử lý đơn hàng" — đó là tên quy trình, không phải tên participant.
Lỗi 5 — Black Box Pool nhưng lại vẽ task bên trong. Nếu bạn đã quyết định một bên là hộp đen (không quan tâm nội bộ của họ), hãy để Pool đó trống hoàn toàn và chỉ nối Message Flow tới biên của nó.
Mẹo 1 — Lane không phải là tổ chức, mà là vai trò. Một Lane "Thẩm định" có thể có nhiều người luân phiên đảm nhận. Đừng đặt tên Lane theo tên cá nhân.
Mẹo 2 — Giữ Pool của "mình" làm trung tâm. Khi mô hình hóa quy trình của công ty bạn, hãy vẽ chi tiết Pool công ty mình, còn các bên ngoài (khách hàng, đối tác) thường để dạng Black Box. Bạn kiểm soát được phần của mình, không kiểm soát được phần của họ.
Mẹo 3 — Dùng Lane để gắn trách nhiệm và sau này gắn SLA. Phân Lane sạch sẽ là bước chuẩn bị hoàn hảo cho việc thiết kế RACI và SLA ở các giai đoạn sau của dự án.
Bài tập thực hành
Bài tập 1 — Phân loại Pool/Lane. Cho các actor sau trong quy trình "Mua bảo hiểm xe ô tô online": Khách hàng, Website công ty bảo hiểm, Nhân viên thẩm định, Bộ phận phát hành hợp đồng, Cổng thanh toán Napas. Hãy quyết định cái nào là Pool riêng, cái nào nên là Lane trong cùng Pool, và giải thích vì sao. (Gợi ý: Khách hàng và Napas độc lập; ba thành phần còn lại thuộc công ty bảo hiểm.)
Bài tập 2 — Tìm lỗi. Bạn được đưa một sơ đồ có hai Pool "Cửa hàng" và "Nhà cung cấp", và giữa chúng có một mũi tên liền nét đi từ task "Gửi đơn đặt hàng" (Pool Cửa hàng) sang task "Nhận đơn" (Pool Nhà cung cấp). Lỗi ở đâu? Sửa thế nào?
Bài tập 3 — Vẽ thực tế. Hãy vẽ (trên giấy hoặc draw.io) quy trình "Nhân viên xin nghỉ phép" trong công ty bạn, dùng một Pool "Công ty" với ít nhất ba Lane (ví dụ: Nhân viên, Quản lý trực tiếp, Phòng Nhân sự). Gán mỗi task vào đúng Lane và nối bằng Sequence Flow. Sau đó tự kiểm tra: có mũi tên nào cắt ngang biên Pool không?
Tóm tắt
- Pool đại diện cho một participant độc lập (tổ chức, vai trò tổng quát, hệ thống), mỗi Pool chứa một process flow riêng có vòng đời độc lập.
- Lane là sự phân chia bên trong một Pool, dùng để gán việc cho các vai trò/phòng ban nội bộ.
- Quy tắc vàng: bên trong Pool dùng Sequence Flow (liền nét, có thể cắt ngang Lane); giữa các Pool dùng Message Flow (nét đứt). Sequence Flow KHÔNG BAO GIỜ cắt ngang biên Pool.
- Quyết định Pool hay Lane dựa trên câu hỏi: "Đây có phải là một bên độc lập mà mình không kiểm soát trực tiếp không?". Có → Pool. Không (nội bộ) → Lane.
- Black Box Pool dùng cho bên mà bạn không quan tâm nội bộ; để trống và chỉ nối Message Flow.
- Lỗi phổ biến nhất là tách Pool sai cho phòng ban nội bộ, và kéo Sequence Flow cắt ngang Pool — luôn rà soát biên Pool trước khi hoàn thiện sơ đồ.