Bài 53 — BPMN: process levels (descriptive, analytic, executable) — Kiến Thức Cơ Bản BA: Thu Thập Yêu Cầu Hiệu Quả

Mở đầu — vì sao bài này quan trọng

Hãy hình dung bạn vừa vẽ xong một sơ đồ BPMN tuyệt đẹp cho quy trình "Phê duyệt khoản vay" của một ngân hàng. Bạn tự hào mang nó vào phòng họp. Nhưng rồi điều kỳ lạ xảy ra: anh giám đốc khối kinh doanh nhíu mày vì sơ đồ quá rối, đầy các ký hiệu lạ; còn anh kỹ sư phần mềm lại thở dài vì sơ đồ "thiếu chi tiết, không thể code được". Cùng một sơ đồ, hai người dùng hoàn toàn khác nhau, và cả hai đều không hài lòng. Vấn đề không nằm ở kỹ năng vẽ của bạn — vấn đề là bạn đã chọn sai cấp độ chi tiết (level of detail) cho đối tượng người đọc.

Đây chính xác là vấn đề mà framework "BPMN Method and Style" của Bruce Silver — chuyên gia BPMN hàng đầu thế giới — ra đời để giải quyết. Silver chỉ ra rằng BPMN 2.0 là một ngôn ngữ rất giàu (có hơn 100 ký hiệu), nhưng trong thực tế bạn không bao giờ dùng hết. Thay vào đó, BPMN nên được sử dụng theo ba cấp độ (three levels): Descriptive, Analytic, và Executable. Mỗi cấp độ phục vụ một mục đích, một đối tượng, và dùng một tập hợp ký hiệu khác nhau.

Là một Business Analyst, đây là một trong những kiến thức "phân biệt người chuyên nghiệp với người mới vào nghề". Người mới vẽ tất cả mọi thứ ở cùng một mức, gây quá tải cho người này và thiếu thông tin cho người kia. Người chuyên nghiệp biết chọn đúng cấp độ cho đúng tình huống. Bài học này sẽ giúp bạn làm chủ ba cấp độ đó.

Khái niệm cốt lõi

Ba cấp độ của BPMN theo framework Bruce Silver

Cấp độ	Đối tượng chính	Tập ký hiệu	Mục đích sử dụng
Descriptive (Mô tả)	Business users, lãnh đạo, người không chuyên BPMN	Tập tối giản: Task, Subprocess, Sequence Flow, Pool/Lane, Start/End event đơn giản, Exclusive Gateway	Truyền đạt quy trình ở mức "câu chuyện", ai cũng đọc hiểu trong 5 phút
Analytic (Phân tích)	BA, process analyst, kiến trúc sư nghiệp vụ	Mở rộng: nhiều loại event (message, timer, error), Parallel/Inclusive Gateway, event-based gateway, boundary event, message flow	Mô tả chính xác hành vi quy trình, xử lý ngoại lệ, đủ chặt để phân tích và cải tiến
Executable (Thực thi)	Process engineer, developer trên BPMS engine	Toàn bộ ký hiệu + thuộc tính kỹ thuật: data object, data mapping, service task, script task, biến, expression	Chạy trực tiếp trên một BPM engine (Camunda, jBPM, Bizagi...) để tự động hóa

Điểm mấu chốt cần ghi nhớ: ba cấp độ này là một dãy "lồng vào nhau" (nested). Tập ký hiệu Descriptive là tập con của Analytic, và Analytic lại là tập con của Executable. Bạn không phải học ba ngôn ngữ khác nhau — bạn học một ngôn ngữ, rồi mở rộng dần độ chi tiết khi cần.

Ba cấp độ lồng nhau — tập ký hiệu Descriptive ⊂ Analytic ⊂ Executable, làm sâu dần chứ không vẽ lại:

flowchart TD
    subgraph E["Executable — Developer, chạy trên BPM engine"]
      direction TB
      subgraph A["Analytic — BA, đầy đủ ngoại lệ và logic chặt"]
        direction TB
        subgraph D["Descriptive — Business, happy path"]
          D1["Task · Sequence Flow · Pool/Lane · Exclusive Gateway"]
        end
        A1["Thêm: Message/Timer/Error Event · Parallel Gateway · Boundary"]
      end
      E1["Thêm: Data Object · Variables · Service/User/Script Task"]
    end

Level 1 — Descriptive: kể câu chuyện quy trình

Descriptive là cấp độ "high-level happy path" — tức là mô tả luồng chính, con đường thuận lợi của quy trình, mà không sa đà vào mọi tình huống ngoại lệ. Mục tiêu là để một người không biết gì về BPMN nhìn vào và hiểu được "quy trình này hoạt động thế nào" trong vài phút.

Ở cấp này bạn chỉ dùng vài ký hiệu cơ bản: Task (hoạt động), Subprocess (gom nhóm nhiều bước thành một khối để giấu chi tiết), Sequence Flow (mũi tên nối các bước), Pool và Lane (phân vai trò ai làm gì), một Start Event và End Event đơn giản, và Exclusive Gateway (điểm rẽ nhánh "hoặc... hoặc..."). Bạn thường KHÔNG dùng các loại event phức tạp, không dùng boundary event, không mô tả từng ngoại lệ.

Quy tắc của Silver: ở mức Descriptive, một quy trình nên gói gọn trong khoảng dưới 10 hoạt động trên một trang. Nếu nhiều hơn, hãy gom lại thành subprocess và đặt chi tiết ở trang con.

Level 2 — Analytic: chính xác và đầy đủ ngoại lệ

Analytic là cấp độ mà BA dành phần lớn thời gian làm việc. Đây là nơi bạn mô tả quy trình một cách chặt chẽ về mặt logic — không chỉ happy path mà cả các ngoại lệ, lỗi, timeout, các nhánh xử lý song song.

Cấp này bổ sung kho ký hiệu phong phú hơn nhiều: Message Event (nhận/gửi thông điệp giữa các bên), Timer Event (chờ đến thời điểm, hoặc hết hạn sau X ngày), Error Event (xử lý lỗi nghiệp vụ), Boundary Event (sự kiện "đính" vào một task, ví dụ "nếu task này quá 48h thì kích hoạt nhánh khác"), Parallel Gateway (làm song song nhiều việc), Inclusive Gateway (chọn một hoặc nhiều nhánh), Event-based Gateway (chờ xem sự kiện nào đến trước), và Message Flow giữa các pool. Mức Analytic phải tuân thủ chặt các quy tắc cú pháp BPMN — đây là nơi "method and style" của Silver phát huy tác dụng để sơ đồ vừa đúng vừa đẹp.

Level 3 — Executable: máy chạy được

Executable là cấp độ kỹ thuật cao nhất, nơi sơ đồ BPMN không còn chỉ là tài liệu mà trở thành mã chạy được trên một BPM engine. Ở đây người ta thêm các thuộc tính mà mắt người thường không cần nhưng máy thì bắt buộc: Data Object và Data Store với cấu trúc cụ thể, biến (variables) và biểu thức điều kiện, phân biệt rõ Service Task (gọi API/hệ thống), User Task (con người làm trên form), Script Task (chạy đoạn mã), cấu hình form, gán người thực hiện, mapping dữ liệu vào/ra...

Là BA, bạn thường không tự tay hoàn thiện cấp Executable — đó là việc của process engineer/developer. Nhưng bạn cần hiểu nó tồn tại, và quan trọng là sơ đồ Analytic của bạn càng chuẩn thì việc chuyển sang Executable càng ít phải vẽ lại từ đầu.

Tình huống thực tế

Ví dụ 1 — Ngân hàng TMCP (Việt Nam): quy trình mở thẻ tín dụng

Một ngân hàng thương mại cổ phần tại TP.HCM triển khai số hóa quy trình mở thẻ tín dụng. Đội BA gồm 4 người làm việc với ba nhóm đối tượng rất khác nhau.

Với Ban lãnh đạo khối Thẻ, BA dùng sơ đồ Descriptive chỉ 7 bước: "Khách nộp hồ sơ → Thẩm định sơ bộ → Chấm điểm tín dụng → Phê duyệt → Phát hành thẻ → Kích hoạt → Bàn giao". Một Exclusive Gateway duy nhất ở bước Phê duyệt ("Duyệt / Từ chối"). Lãnh đạo nhìn 30 giây là gật đầu, vì họ chỉ cần thấy bức tranh tổng thể và điểm ra quyết định.

Sơ đồ Descriptive — 7 bước, một gateway duy nhất, lãnh đạo nhìn 30 giây là hiểu:

flowchart LR
    A[Khách nộp hồ sơ] --> B[Thẩm định sơ bộ] --> C[Chấm điểm tín dụng] --> D{Phê duyệt?}
    D -->|Duyệt| E[Phát hành thẻ] --> F[Kích hoạt] --> G([Bàn giao])
    D -->|Từ chối| H([Kết thúc: từ chối])

Khi làm việc với đội vận hành và rủi ro, cũng quy trình đó nhưng BA vẽ ở mức Analytic: subprocess "Chấm điểm tín dụng" được mở ra cho thấy việc gọi sang CIC (Trung tâm Thông tin Tín dụng Quốc gia) bằng một message event; thêm timer boundary event "nếu CIC không trả lời trong 24h thì chuyển sang thẩm định thủ công"; thêm error event cho trường hợp khách có nợ xấu nhóm 3-5. Sơ đồ này có khoảng 25 phần tử — quá rối với lãnh đạo, nhưng vừa đủ cho đội rủi ro phân tích các kịch bản.

Cuối cùng, khi bàn giao cho đội phát triển trên nền tảng Camunda, process engineer nâng sơ đồ Analytic lên Executable: gán Service Task cho lời gọi API tới CIC, User Task cho màn hình thẩm định viên, biến creditScore với điều kiện creditScore >= 600 trên các nhánh gateway.

Bài học: cùng một quy trình nghiệp vụ, BA đã tạo ra ba "phiên bản" ở ba cấp độ cho ba đối tượng. Không phải vẽ lại ba lần từ con số 0, mà là làm sâu dần. Đây là cách làm thực sự tiết kiệm thời gian và tránh xung đột "sơ đồ quá rối / quá thiếu".

Ví dụ 2 — Sàn TMĐT khu vực: khi đội kỹ thuật đòi chi tiết quá sớm

Tại một công ty thương mại điện tử ở Đông Nam Á (quy mô tương tự Tiki/Sendo), một BA mới vào nghề được giao mô tả quy trình "Xử lý đơn hoàn trả (return/refund)". Vì muốn gây ấn tượng, bạn ấy vẽ ngay một sơ đồ siêu chi tiết với đầy đủ data object, service task gọi cổng thanh toán, và 8 loại event khác nhau — tức là nhảy thẳng lên gần mức Executable.

Kết quả: buổi review với các trưởng nhóm vận hành kho và chăm sóc khách hàng trở thành thảm họa. Họ không đọc nổi sơ đồ, tranh luận lạc đề về ký hiệu thay vì về nghiệp vụ. Quy trình thực tế "khách yêu cầu hoàn → kiểm hàng về kho → quyết định hoàn tiền hay đổi hàng" — vốn rất đơn giản về mặt nghiệp vụ — bị che lấp bởi chi tiết kỹ thuật.

BA leader can thiệp, yêu cầu vẽ lại ở mức Descriptive với đúng 6 task. Buổi họp sau đó chốt được luồng nghiệp vụ trong 20 phút. Chỉ sau khi nghiệp vụ đã thống nhất, BA mới phát triển dần lên Analytic để bổ sung tình huống "hàng về kho bị hư hỏng", "khách không gửi hàng về sau 7 ngày".

Bài học: chọn cấp độ quá cao quá sớm cũng tệ như chọn quá thấp. Hãy luôn xuất phát từ Descriptive để chốt nghiệp vụ với business, rồi mới đào sâu. Đừng "khoe" độ chi tiết khi người đọc chưa cần.

Ví dụ 3 — Công ty logistics: chuyển từ Analytic sang Executable mượt mà

Một công ty logistics tại Hà Nội tự động hóa quy trình "Điều phối đơn giao hàng" trên nền tảng Bizagi. Đội BA đã làm tốt phần Analytic: mô tả đầy đủ các event timer ("nếu tài xế không nhận đơn trong 5 phút thì tự động chuyển sang tài xế khác"), parallel gateway ("đồng thời thông báo cho khách và cập nhật kho").

Khi chuyển sang Executable, vì sơ đồ Analytic đã tuân thủ đúng method and style, process engineer chỉ mất 3 ngày để gắn thuộc tính kỹ thuật và đưa vào chạy — thay vì phải vẽ lại. Ngược lại, một dự án trước đó của họ, do sơ đồ Analytic vẽ ẩu (gateway không cân bằng, event dùng sai), khi lên Executable engine báo lỗi liên tục và phải làm lại mất gần 3 tuần.

Bài học: chất lượng của cấp Analytic quyết định tốc độ lên cấp Executable. BA làm chuẩn ở mức Analytic chính là đang tiết kiệm hàng tuần công sức cho đội kỹ thuật.

Hướng dẫn từng bước

Đây là quy trình thực hành để chọn và xây dựng đúng cấp độ BPMN:

Xác định đối tượng người đọc trước khi vẽ. Hãy tự hỏi: ai sẽ đọc sơ đồ này, và họ cần ra quyết định gì? Lãnh đạo và business user → Descriptive. BA, đội rủi ro, kiến trúc sư nghiệp vụ → Analytic. Developer trên BPM engine → Executable.

Luôn bắt đầu từ Descriptive. Dù mục tiêu cuối cùng là gì, hãy vẽ luồng chính (happy path) trước, dưới 10 hoạt động, dùng tập ký hiệu tối giản. Mục đích là chốt sự đồng thuận về nghiệp vụ với business một cách nhanh nhất.

Dùng Subprocess để quản lý độ phức tạp. Khi một bước có nhiều chi tiết, hãy gói nó thành một subprocess (hình chữ nhật có dấu +). Ở Descriptive bạn để nó "đóng"; ở Analytic bạn "mở" nó ra trang con. Đây là kỹ thuật giúp cùng một quy trình tồn tại ở nhiều cấp độ.

Nâng lên Analytic bằng cách thêm ngoại lệ. Sau khi happy path được duyệt, đặt câu hỏi "chuyện gì xảy ra nếu...?": nếu hệ thống không phản hồi (timer), nếu có lỗi (error event), nếu cần chờ tin nhắn từ bên ngoài (message event), nếu nhiều việc chạy song song (parallel gateway). Mỗi câu trả lời thêm một ký hiệu Analytic.

Kiểm tra cú pháp theo method and style. Mỗi gateway rẽ nhánh phải có gateway gộp tương ứng. Mỗi pool phải có đúng một start event ngầm hoặc tường minh. Đặt tên task theo cấu trúc "Động từ + Danh từ" (ví dụ: "Phê duyệt hồ sơ", không phải "Hồ sơ").

Chỉ chuyển sang Executable khi nghiệp vụ đã đóng băng. Phối hợp với process engineer/developer để thêm data object, biến, service/user/script task, và cấu hình engine. Là BA, vai trò của bạn ở bước này là review để đảm bảo logic nghiệp vụ không bị bóp méo khi kỹ thuật hóa.

Lưu và đặt tên rõ cấp độ. Đặt tên file/diagram kèm hậu tố như _descriptive, _analytic để mọi người biết mình đang xem phiên bản nào, tránh nhầm lẫn khi sơ đồ được chia sẻ.

Lỗi thường gặp & mẹo

Lỗi 1 — Vẽ mọi thứ ở một cấp độ duy nhất. Đây là lỗi phổ biến nhất: dùng một sơ đồ Analytic siêu chi tiết để trình bày cho cả lãnh đạo lẫn developer. Kết quả là không ai hài lòng. Mẹo: hãy nghĩ về BPMN như Google Maps — bạn có thể zoom in/zoom out. Lãnh đạo cần bản đồ quốc gia, developer cần bản đồ từng con hẻm.

Lỗi 2 — Nhồi quá nhiều phần tử vào một trang. Một sơ đồ với 40 task chằng chịt là dấu hiệu bạn đang thiếu subprocess. Mẹo: áp dụng quy tắc "dưới 10 hoạt động mỗi trang" của Silver; cái gì nhiều hơn thì gom thành subprocess.

Lỗi 3 — Dùng ký hiệu Analytic/Executable khi không cần. Thêm message event, boundary timer vào một sơ đồ vốn chỉ cần Descriptive sẽ làm business user hoảng. Mẹo: chỉ thêm một ký hiệu phức tạp khi nó thực sự trả lời một câu hỏi nghiệp vụ mà người đọc quan tâm.

Lỗi 4 — Nhầm "cấp độ" với "công cụ". Nhiều bạn nghĩ phải đổi phần mềm để làm cấp độ khác. Không. Cùng một công cụ (Bizagi, Camunda Modeler, draw.io) đều vẽ được cả ba cấp; cấp độ là lựa chọn về tập ký hiệu và độ chi tiết, không phải về phần mềm.

Lỗi 5 — Bỏ qua Descriptive vì nghĩ nó "quá đơn giản, không chuyên nghiệp". Ngược lại, khả năng diễn đạt một quy trình phức tạp bằng sơ đồ đơn giản mới là dấu hiệu của một BA giỏi. Mẹo: Descriptive là công cụ giao tiếp mạnh nhất của bạn với cấp lãnh đạo.

Mẹo vàng: trước mỗi sơ đồ, hãy viết một dòng ghi chú ở góc: "Level: Descriptive — Audience: Ban lãnh đạo khối Thẻ". Một câu nhỏ này tránh được vô số hiểu lầm và giúp người xem tự điều chỉnh kỳ vọng.

Bài tập thực hành

Hãy chọn một quy trình quen thuộc — ví dụ "Đăng ký khóa học và thanh toán trên một nền tảng học trực tuyến" — và thực hiện:

Bản Descriptive: Vẽ luồng chính dưới 8 task, chỉ dùng Task, Sequence Flow, một Exclusive Gateway (ví dụ "Thanh toán thành công / thất bại"), một Pool với 2 lane (Học viên / Hệ thống). Mục tiêu: một người không biết BPMN đọc hiểu trong 2 phút.

Bản Analytic: Từ bản trên, thêm các ngoại lệ thực tế: timer event "nếu học viên không thanh toán trong 15 phút thì hủy đơn"; message event "nhận xác nhận từ cổng thanh toán VNPay/Momo"; error event "thẻ bị từ chối". Mở subprocess "Xử lý thanh toán" ra trang con. Đếm xem bạn đã thêm bao nhiêu ký hiệu mới.

Đề xuất Executable (mô tả bằng chữ): Liệt kê — không cần vẽ — những thuộc tính kỹ thuật mà developer sẽ cần thêm để chạy trên engine: biến nào (orderId, amount, paymentStatus), task nào là Service Task (gọi API cổng thanh toán), task nào là User Task (học viên nhập thông tin).

Tự đánh giá: Với mỗi bản, ghi rõ "Audience" phù hợp. Tự hỏi: nếu đưa bản Analytic cho lãnh đạo, điều gì sẽ khiến họ bối rối? Nếu đưa bản Descriptive cho developer, họ sẽ thiếu thông tin gì?

Hoàn thành bài tập này, bạn sẽ tận tay trải nghiệm tính "lồng nhau" của ba cấp độ và hiểu sâu vì sao chọn đúng cấp độ lại quan trọng đến vậy.

Tóm tắt

BPMN theo framework Bruce Silver có ba cấp độ: Descriptive (cho business, tập ký hiệu tối giản, kể câu chuyện happy path), Analytic (cho BA, đầy đủ ngoại lệ và logic chặt chẽ), và Executable (cho developer, chạy được trên BPM engine).
Ba cấp độ lồng vào nhau: tập ký hiệu cấp dưới là con của cấp trên. Bạn chỉ học một ngôn ngữ và làm sâu dần, không vẽ lại từ đầu.
Đối tượng người đọc quyết định cấp độ. Luôn bắt đầu từ Descriptive để chốt nghiệp vụ, rồi nâng dần lên Analytic, và chỉ kỹ thuật hóa thành Executable khi nghiệp vụ đã đóng băng.
Dùng Subprocess làm "công tắc zoom" để cùng một quy trình tồn tại ở nhiều cấp độ.
Chất lượng cấp Analytic quyết định tốc độ lên Executable — BA làm chuẩn ở đây chính là tiết kiệm hàng tuần cho đội kỹ thuật.
Lỗi nguy hiểm nhất là vẽ mọi thứ ở một cấp độ duy nhất. Hãy nghĩ về BPMN như Google Maps: biết khi nào cần zoom in, khi nào cần zoom out.