Bài này trả lời: BPMN cơ bản cho BA: 8 ký hiệu Các phần: tình huống thật — trả lời ngắn — điều gì cản trở — framework — bảng thực thi — ví dụ minh họa — FAQ — checklist tự kiểm. Đọc 12 phút, dùng được tuần này.
Tình huống minh họa: BA vẽ lưu đồ 40 hình đẹp lung linh trình khách. Khách nhìn 5 phút, hỏi: "quy trình này ai duyệt khi trên 50 triệu?" — câu trả lời nằm... đâu mất trong 40 hình. Sơ đồ đẹp nhưng đọc không ra nghiệp vụ: cổng XOR viết "Có/Không" không ai biết điều kiện gì, lane người phụ trách thiếu nửa, và không một hình nào có số liệu lượng. Lưu đồ như thế chỉ để treo tường — không để fit-gap, không để dev đọc, không để ai ký.
Trả lời ngắn: BPMN cho BA không cần học 100 ký hiệu — 8 ký hiệu phủ 90% nghiệp vụ doanh nghiệp: sự kiện bắt đầu/kết thúc, việc (task), cổng XOR (rẽ nhánh điều kiện), luồng, lane người/phòng, gate duyệt, ghi chú số liệu, sub-process gói. Nhưng sức mạnh không nằm ở hình — nằm ở quy tắc mỗi hình trả lời được một câu hỏi nghiệp vụ: việc gì (verb + đối tượng), ai làm (lane), điều kiện gì (cổng ghi rõ điều kiện text), bao lâu (số giờ ngay cạnh task), và đầu ra gì. Lưu đồ trả lời được 5 câu hỏi đó là tài liệu fit-gap chạy được — không thì là tranh treo.
Bài này dành cho ai?
Dành cho BA và consultant phải vẽ quy trình As-Is/To-Be trong dự án ERP — người từng trình lưu đồ đẹp mà khách xem 5 phút không trả lời được một câu nghiệp vụ nào.
Điều gì đang xảy ra?
- Lưu đồ đẹp nhưng đọc không ra ai-điều kiện-thời gian.
- Cổng ghi "Có/Không" không rõ điều kiện thật.
- Task ghi danh từ ("Đơn hàng") thiếu động từ.
- Số liệu lượng (giờ, tần suất) không có.
- 40 hình phẳng — không gói sub-process.
- Khách xem 5 phút không trả lời được 1 câu.
Điều người đọc muốn đạt được
Vẽ BPMN bằng 8 ký hiệu chuẩn + quy tắc 5 câu hỏi cho mỗi hình — lưu đồ fit-gap chạy được, dev đọc được, khách ký được.
Điều gì đang cản trở?
| Cản trở | Biểu hiện | Hệ quả |
|---|---|---|
| Học quá nhiều ký hiệu | Dùng 20+ hình hiếm | Chậm vẽ, người đọc không theo kịp |
| Hình không ngữ nghĩa | Task danh từ, cổng mơ hồ | Đọc 3 lần không ra nghiệp vụ |
| Không số liệu | Không giờ/tần suất | Không ước effort được |
| Phẳng toàn bộ | 40 hình cùng tầng | Người đọc lạc giữa dòng |
| Không lane rõ | Ai làm đọc phải đoán | Fit-gap thiếu người quyết |
Tác động nếu không xử lý
- Chậm vẽ, người đọc không theo kịp
- Đọc 3 lần không ra nghiệp vụ
- Không ước effort được
- Người đọc lạc giữa dòng
- Fit-gap thiếu người quyết
Insight: Sơ đồ quy trình có 3 độc giả khác nhau và ba người cần thứ khác nhau: khách cần thấy việc mình đúng chỗ (lane + tên việc quen), dev cần điều kiện rõ để mã hóa (cổng có text điều kiện), PM cần số liệu để ước effort (giờ/tần suất cạnh task). Lưu đồ chết vì vẽ cho 1 trong 3 — quên 2 còn lại. 8 ký hiệu + quy tắc 5 câu hỏi ép mỗi hình phục vụ cả ba cùng lúc: đó là lý do sơ đồ "đơn giản hơn" mà đọc được nhiều hơn.
Framework (6 bước)
8 KÝ HIỆU LÕI: sự kiện bắt đầu/kết thúc, task, cổng XOR, luồng, lane, gate duyệt, ghi chú số, sub-process
↓
QUY TẮC 1 — Task = động từ + đối tượng ("Duyệt PO", không "PO")
↓
QUY TẮC 2 — Cổng ghi text điều kiện đầy đủ ("tổng > 50tr", không "Có/Không")
↓
QUY TẮC 3 — Mỗi task có giờ ước + tần suất (lần/ngày) cạnh hình
↓
QUY TẮC 4 — Gom vùng >8 hình liên tiếp thành 1 sub-process đặt tên
↓
QUY TẮC 5 — Sơ đồ xong chạy checklist 5 câu: việc gì/ai/điều kiện/bao lâu/đầu ra
Lộ trình học theo luồng nghiệp vụ, lớp theo vai, bài thực hành chấm theo tình huống thật — học xong kể được luồng, không chỉ bấm được nút.
Khám phá EcoTalent →Bảng thực thi (To-Be)
| Câu hỏi kiểm | Hình nào trả lời | Chuẩn đạt |
|---|---|---|
| Việc gì? | Task (động từ + đối tượng) | Người nghiệp vụ đọc tên hiểu ngay việc thật |
| Ai làm? | Lane người/phòng | Không hình nào không lane |
| Điều kiện gì? | Cổng XOR + text điều kiện | Dev đọc mã hóa được không hỏi lại |
| Bao lâu? | Ghi chú số cạnh task | PM ước effort có đầu vào |
| Đầu ra gì? | Sự kiện kết thúc / tài liệu ra | Mỗi nhánh kết thúc có đầu ra đặt tên |
Ví dụ minh họa — số liệu giả định
Số liệu giả định để minh họa, không phải thống kê thực tế.
Cùng quy trình duyệt PO — 2 cách vẽ cho 3 độc giả (khách, dev, PM).
| Chỉ số | Lưu đồ 20+ ký hiệu "đẹp" | 8 ký hiệu + 5 câu hỏi |
|---|---|---|
| Khách trả lời "ai duyệt >50tr" trong | 5 phút vẫn không thấy | 5 giây — lane + điều kiện cổng |
| Dev hỏi lại nghiệp vụ | 5–8 câu | 1–2 câu — điều kiện viết đủ |
| PM ước effort từ sơ đồ | Không (không số) | Được — giờ × tần suất có sẵn |
| Số hình quy trình 12 bước | 40 hình phẳng | 9 hình + 2 sub-process |
| Khách ký sơ đồ As-Is | Chần chừ | Ký — vì nhận ra việc mình |
Triển khai 4 tuần đầu
Tuần 1: chọn đúng nơi bắt đầu theo framework trên — dựng tối thiểu dữ liệu/thành phần bắt buộc, chưa hoàn thiện. Tuần 2: chạy thử 1 luồng/vòng đầy đủ trên dữ liệu thật hoặc giả định có tính cách; ghi vướng vào danh sách. Tuần 3: xử 3 vướng lớn nhất + mở rộng nửa còn lại; bắt đầu đo 1–2 con số so với cách làm cũ. Tuần 4: chốt thành quy trình có người chịu + số liệu theo tuần — nếu tuần 4 vẫn cần đôn đốc từng ngày, quay lại xem bước nào trong framework gây ma sát và đơn giản hóa nó.
Quan niệm sai và thực tế
| Quan niệm sai | Thực tế | Hệ quả nếu tin sai |
|---|---|---|
| ['Vấn đề này giải quyết bằng thêm công sức cá nhân', 'Giải bằng cấu trúc — quy trình + dữ liệu tại nguồn + người chịu', 'Người giỏi kiệt sức, vấn đề tái phát khi người đó nghỉ'] | ['Đợi khi nào "rảnh" sẽ làm', 'Chuyện để dành never cheaper — dữ liệu rối thêm mỗi ngày chờ', 'Chi phí sửa tăng theo thời gian trì hoãn'] | ['Cách cũ vẫn chạy — chưa cần đổi', 'Vẫn chạy nghĩa là vẫn trả chi phí vô hình mỗi ngày', 'Tiền mất âm thầm nhân lên trong khi đối thủ đi trước'] |
Câu hỏi thường gặp
Phải học đủ BPMN 2.0 đầy đủ không?
Không cần cho 90% việc BA: 8 ký hiệu lõi đủ vẽ quy trình doanh nghiệp chuẩn. Học thêm khi gặp bài cần (sự kiện thời gian, đa luồng song song) — vừa làm vừa học từng ký hiệu mới nhớ. Học trước 100 ký hiệu như học từ điển: xong vẫn không viết được câu nào.
Tool vẽ gì — đủ dùng không cần license nặng?
Dùng gì cũng được miễn tuân 8 ký hiệu + 5 quy tắc: các tool vẽ sơ đồ phổ biến đều có stencil BPMN. Điều quyết định không phải tool đắt — là hình có ngữ nghĩa đủ cho 3 độc giả. Sơ đồ bút giấy đúng quy tắc còn hơn sơ đồ tool đắt sai ngữ nghĩa.
Khách không đọc được BPMN — vẽ kiểu gì?
Đó là tín hiệu sơ đồ thiếu quy tắc 5 câu hỏi — không phải lỗi của khách: khi task ghi "Duyệt PO" trong lane "Giám đốc", khách nào cũng đọc được (đó là tiếng Việt của việc họ làm). Khách "không đọc được" thường vì sơ đồ dùng hình thay lời (nhiều hình nối không chữ). Chữa bằng chữ, không bằng thêm hình.
As-Is và To-Be vẽ cùng một bản đồ được không?
Tách 2 bản: As-Is là sự thật hôm nay (kể cả đoạn xấu), To-Be là đề xuất. Vẽ chung thì 2 điều xấu xảy ra: tranh cãi không biết hình nào thật hôm nay, và To-Be "tự động đẹp" theo sở thích người vẽ thay vì phát triển từ As-Is. Nối 2 bản bằng đánh số bước tương ứng để trace được "từ đây tới đây thay gì".
Số giờ/tần suất lấy đâu khi vẽ As-Is?
Hỏi người làm thật trong buổi khảo sát — con số ước của họ vẫn tốt hơn không số ("đối soát mất khoảng 1 ngày" của kế toán 10 năm vẫn đáng tin 90%). Ghi rõ "ước từ phỏng vấn" — sau này đo thật thì thay. Không có số nào là lý do PM ước effort mù về sau.
Bài học một câu?
Lưu đồ không để đẹp — để 3 người (khách, dev, PM) đều đọc ra thứ mình cần: 8 ký hiệu + mỗi hình trả lời 5 câu (việc gì/ai/điều kiện/bao lâu/đầu ra) — đúng chuẩn đó thì 9 hình thắng 40 hình.
Checklist tự kiểm tra
3 dấu hiệu bạn cần bài này
(1) Lưu đồ đẹp nhưng đọc không ra ai-điều kiện-thời gian. (2) Task ghi danh từ ("Đơn hàng") thiếu động từ. (3) Khách xem 5 phút không trả lời được 1 câu.
Nếu ít nhất 2 trong 3 dấu hiệu trên đúng với tình huống của bạn, framework trong bài đáng áp dụng ngay tuần này — đừng đợi đến khi dấu hiệu thứ ba "đau" thêm. Nếu chỉ có 1 dấu hiệu, hãy đánh dấu bài và quay lại khi dữ kiện đủ: áp dụng nửa vời một framework thường tốn công hơn chờ đúng lúc.
Kết luận
BPMN cho BA không cần 100 ký hiệu — cần 8 ký hiệu lõi dùng đúng quy tắc: task = động từ + đối tượng, cổng = điều kiện đầy đủ, lane = người thật, số giờ-tần suất cạnh hình, sub-process gói vùng dài. Mỗi hình trả lời 5 câu (việc gì/ai/điều kiện/bao lâu/đầu ra) thì khách nhận ra việc mình, dev mã hóa được, PM ước effort có số — 9 hình đọc được thắng 40 hình đẹp.
Bước tiếp theo thực dụng: chọn đúng 1 hạng mục nhỏ nhất từ framework trên — vừa đủ để làm trong 1 tuần và đo được 1 con số. Làm trọn 1 hạng mục nhỏ tạo moment duy trì tốt hơn cố gắng làm 5 hạng mục cùng lúc rồi bỏ giữa chừng. Khi hạng mục đầu chạy đúng, hạng mục sau có sẵn người tin việc đang làm — và dữ liệu để mở rộng. Đó là cách mọi đội chuyển từ "biết nên làm" sang "đang làm được": một bước nhỏ trọn vẹn mỗi tuần, thay vì một kế hoạch lớn nằm giấy.