Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa phỏng vấn xong năm stakeholder về quy trình "xử lý đơn hàng" của một sàn thương mại điện tử. Bạn ghi chép kín ba trang giấy: "khách đặt hàng", "kho kiểm tra tồn", "kế toán xác nhận thanh toán", "giao vận lấy hàng"... Khi bạn đưa bản ghi đó cho lập trình viên, họ nhíu mày: "Vậy nếu hết hàng thì sao? Ai hủy đơn? Tiền đã thu rồi thì hoàn lại lúc nào?" Bạn nhận ra văn bản thuần túy không trả lời được những câu hỏi đó một cách rõ ràng.
Đây chính là khoảng trống mà Process Flow (sơ đồ luồng quy trình) và Data Flow (sơ đồ luồng dữ liệu) lấp đầy. Một bức tranh quy trình tốt giúp mọi người — từ giám đốc nghiệp vụ không rành kỹ thuật đến developer khó tính nhất — nhìn cùng một thực tại, phát hiện ngay những lỗ hổng, những nhánh rẽ bị bỏ quên, những điểm dữ liệu "biến mất" giữa các phòng ban.
Trong vai trò BA, kỹ năng vẽ và đọc sơ đồ quy trình không phải là "trang trí cho đẹp tài liệu". Nó là công cụ tư duy. Khi bạn buộc mình phải vẽ từng bước, từng quyết định, từng dòng dữ liệu, bạn không thể giấu sự mơ hồ được nữa — mọi thiếu sót sẽ lộ ra trên giấy. Bài này thuộc nhóm Documentation: chúng ta tập trung vào cách thể hiện quy trình và dữ liệu thành sơ đồ chuẩn, dễ đọc, dễ bàn giao. Đây là kỹ năng nền tảng mà bạn sẽ dùng gần như mỗi dự án trong suốt sự nghiệp.
Khái niệm cốt lõi
Business Process Model (BPM) là gì?
Business Process Model là cách mô hình hóa một quy trình nghiệp vụ từ điểm bắt đầu đến điểm kết thúc: ai làm gì, theo thứ tự nào, rẽ nhánh ra sao khi gặp điều kiện. Mục tiêu của BPM là trả lời câu hỏi: "Công việc chảy qua tổ chức này như thế nào?"
Một process flow tốt mô tả ba thứ:
- Hoạt động (activities/tasks): những việc cụ thể được thực hiện, ví dụ "Xác nhận thanh toán".
- Trình tự và rẽ nhánh (sequence & gateways): thứ tự các bước, và các điểm quyết định "nếu... thì...".
- Vai trò (roles): ai chịu trách nhiệm cho mỗi bước, thường biểu diễn bằng swimlane (làn bơi).
BPMN — ngôn ký hiệu chuẩn cho process flow
BPMN (Business Process Model and Notation) là bộ ký hiệu chuẩn quốc tế (do tổ chức OMG duy trì) để vẽ quy trình. Lợi ích lớn nhất của BPMN là tính chuẩn hóa: một sơ đồ vẽ ở Hà Nội, gửi sang đối tác ở Singapore hay Tokyo, ai biết BPMN đều đọc hiểu giống nhau. Bạn không cần thuộc hết 100+ ký hiệu — với 90% công việc BA, chỉ cần nắm vững nhóm cơ bản sau:
- Start Event (vòng tròn mảnh): điểm bắt đầu quy trình. Mỗi sơ đồ nên có một start rõ ràng.
- End Event (vòng tròn viền đậm): điểm kết thúc. Một quy trình có thể có nhiều end (kết thúc thành công, kết thúc bị hủy...).
- Task / Activity (hình chữ nhật bo góc): một việc được làm, ví dụ "Kiểm tra tồn kho". Đặt tên bằng cấu trúc động từ + danh từ.
- Gateway (hình thoi): điểm rẽ nhánh hoặc hội tụ. Loại phổ biến nhất là Exclusive Gateway (XOR) — chọn đúng một trong nhiều đường, ví dụ "Còn hàng?" → Có / Không. Ngoài ra có Parallel Gateway (AND) — chạy song song nhiều nhánh cùng lúc.
- Sequence Flow (mũi tên nét liền): nối các phần tử theo trình tự, thể hiện "đi tiếp tới đâu".
- Message Flow (mũi tên nét đứt): trao đổi thông tin giữa các bên (giữa các pool khác nhau).
- Pool & Lane (khung lớn và các làn ngang): Pool đại diện một tổ chức/hệ thống; Lane là một vai trò bên trong pool. Đây chính là kỹ thuật swimlane giúp nhìn rõ "ai làm bước nào".
Data Flow Diagram (DFD) — góc nhìn về dữ liệu
Trong khi process flow trả lời "công việc chảy thế nào", Data Flow Diagram (DFD) trả lời "dữ liệu chảy thế nào": dữ liệu đến từ đâu, được xử lý ở đâu, lưu vào đâu, đi ra cho ai. DFD chỉ dùng bốn ký hiệu, rất gọn:
- External Entity (hình chữ nhật): nguồn hoặc đích của dữ liệu nằm ngoài hệ thống — ví dụ "Khách hàng", "Cổng thanh toán", "Cơ quan thuế".
- Process (hình tròn hoặc bo góc, có đánh số): nơi dữ liệu được biến đổi — ví dụ "1.0 Xử lý đơn hàng".
- Data Store (hai vạch song song hoặc hình chữ nhật hở): nơi dữ liệu được lưu trữ — ví dụ "D1 | Bảng Đơn hàng".
- Data Flow (mũi tên có nhãn): dòng dữ liệu di chuyển, luôn phải đặt tên nội dung — ví dụ "thông tin đơn hàng", "trạng thái thanh toán".
- Context Diagram (Level 0): cả hệ thống là một process duy nhất, xung quanh là các external entity. Dùng để nhìn ranh giới hệ thống ở mức cao nhất.
- Level 1, Level 2...: bung process tổng thành các process con chi tiết hơn. Nguyên tắc quan trọng là balancing — dữ liệu vào/ra ở cấp con phải khớp với cấp cha.
flowchart LR
KH[Khách hàng] -->|đơn hàng| SYS((Hệ thống Xử lý đơn hàng))
SYS -->|xác nhận, hóa đơn| KH
SYS -->|yêu cầu thanh toán| TT[Cổng thanh toán]
TT -->|kết quả thanh toán| SYS
SYS -->|dữ liệu thuế| CQT[Cơ quan thuế]Khi nào dùng cái nào?
Đừng nhầm hai loại sơ đồ. Process flow / BPMN mạnh khi bạn cần mô tả trình tự công việc, vai trò, và quyết định — phù hợp để bàn với stakeholder nghiệp vụ. DFD mạnh khi bạn cần làm rõ dữ liệu di chuyển và lưu trữ ở đâu — phù hợp khi thiết kế hệ thống, tích hợp, hoặc rà soát rủi ro dữ liệu. Trong thực tế, một BA giỏi thường dùng cả hai cho cùng một bài toán: BPMN để thống nhất với nghiệp vụ, DFD để chuẩn bị cho đội kỹ thuật.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT "ChợViệt": process flow phơi bày nhánh bị bỏ quên
Một startup TMĐT giả định tên ChợViệt thuê BA để mô tả quy trình xử lý đơn hàng. Khi phỏng vấn, các phòng ban kể "đường thẳng đẹp đẽ": Khách đặt hàng → Hệ thống nhận đơn → Kho đóng gói → Giao vận giao hàng → Hoàn tất.
BA vẽ thành BPMN với ba swimlane: Khách hàng, Hệ thống ChợViệt, Kho vận. Ngay khi đặt một Exclusive Gateway với câu hỏi "Còn hàng trong kho?", cả phòng họp im lặng. Nhánh "Không còn hàng" chưa từng được ai định nghĩa. Tiếp tục đặt gateway thứ hai "Thanh toán thành công?", lại lộ ra một lỗ hổng: với đơn COD thì khác hẳn đơn trả trước, nhưng trước đó quy trình gộp chung làm một.
Kết quả: từ một quy trình "5 bước thẳng", BA bóc ra được 3 nhánh ngoại lệ (hết hàng, thanh toán thất bại, khách hủy trong 30 phút) và một quy tắc nghiệp vụ về hoàn tiền. Con số cụ thể: trước đó, 8% đơn hàng rơi vào trạng thái "treo" không ai xử lý vì hệ thống cũ không có luồng cho các ngoại lệ này.
Sơ đồ BPMN — quy trình xử lý đơn hàng ChợViệt: mỗi hình thoi (gateway) phơi bày một nhánh ngoại lệ:
flowchart TD
A([Khách đặt hàng]) --> B[Hệ thống nhận đơn]
B --> C{Còn hàng?}
C -->|Không| X1([Hủy đơn: hết hàng])
C -->|Có| D[Kho đóng gói]
D --> E{Thanh toán thành công?}
E -->|Không| X2([Hủy đơn: thanh toán thất bại])
E -->|Có| F[Giao vận giao hàng]
F --> G{Khách hủy trong 30 phút?}
G -->|Có| X3([Hoàn tiền, hủy đơn])
G -->|Không| H([Hoàn tất])Bài học: Giá trị lớn nhất của việc vẽ process flow không nằm ở các bước "happy path" mà ở chỗ nó ép bạn đặt câu hỏi tại mỗi gateway. Mỗi hình thoi là một cơ hội phát hiện yêu cầu bị thiếu.
Tình huống 2 — Phòng khám "An Khang": DFD lộ ra dữ liệu đi vòng
Một chuỗi phòng khám giả định An Khang muốn số hóa quy trình khám bệnh. BA dùng DFD để rà dòng dữ liệu bệnh nhân. Vẽ Context Diagram trước: external entity gồm "Bệnh nhân", "Bảo hiểm xã hội", "Nhà thuốc"; ở giữa là một process "Hệ thống Quản lý Khám bệnh".
Khi bung xuống Level 1, BA phát hiện một dòng data flow kỳ lạ: thông tin chẩn đoán được lễ tân gõ tay lại từ giấy của bác sĩ vào hệ thống, thay vì bác sĩ nhập trực tiếp. Trên DFD, điều này hiện ra là một process thừa "Nhập lại chẩn đoán" với một data flow lặp. Đây là điểm vừa tốn công vừa dễ sai sót (gõ nhầm liều thuốc là rủi ro nghiêm trọng).
Nhờ DFD, đội dự án xác định được một data store trùng lặp: "Sổ giấy bác sĩ" và "Bảng chẩn đoán điện tử" lưu cùng một dữ liệu nhưng không đồng bộ. Sau khi thiết kế lại để bác sĩ nhập một lần duy nhất, thời gian xử lý mỗi lượt khám giảm khoảng 4 phút, và lỗi sai thông tin thuốc giảm rõ rệt.
Sơ đồ DFD (Level 1) — dữ liệu chẩn đoán bị gõ lại (process 2.0) và lưu trùng ở hai data store D1, D2:
flowchart TD
BN[Bệnh nhân] -->|hồ sơ khám| P1((1.0 Tiếp nhận, khám))
P1 -->|chẩn đoán viết tay| D1[(D1 · Sổ giấy bác sĩ)]
D1 -->|đọc, gõ tay lại| P2((2.0 Nhập lại chẩn đoán))
P2 -->|chẩn đoán số hóa| D2[(D2 · Chẩn đoán điện tử)]
D2 -->|đơn thuốc| NT[Nhà thuốc]Bài học: DFD giỏi nhất ở việc phát hiện dữ liệu đi vòng, nhập lại, hoặc lưu trùng. Những lãng phí này gần như vô hình trong văn bản nhưng nổi bật ngay khi vẽ thành mũi tên có nhãn.
Tình huống 3 — Ngân hàng số: kết hợp BPMN và DFD cho một tính năng
Một ngân hàng số giả định triển khai tính năng "mở tài khoản online (eKYC)". BA dùng BPMN để thống nhất với khối Vận hành: các bước từ khách chụp CCCD → hệ thống đối chiếu khuôn mặt → bộ phận tuân thủ duyệt → kích hoạt tài khoản, với gateway "Đối chiếu khớp?" và "Tuân thủ duyệt?".
Nhưng khi làm việc với đội kỹ thuật và bộ phận an ninh thông tin, BPMN chưa đủ. BA vẽ thêm DFD để chỉ rõ ảnh CCCD và dữ liệu sinh trắc đi qua những process nào, lưu ở data store nào, và quan trọng nhất — có gửi ra external entity bên thứ ba (dịch vụ xác thực) hay không. Chính DFD giúp phát hiện một dòng dữ liệu nhạy cảm bị lưu ở một data store không mã hóa, một vấn đề tuân thủ nghiêm trọng cần xử lý trước khi go-live.
Bài học: Hai loại sơ đồ bổ trợ nhau. BPMN nói chuyện với nghiệp vụ về trình tự; DFD nói chuyện với kỹ thuật và an ninh về dữ liệu. Một BA trưởng thành biết chọn đúng công cụ cho đúng cuộc trò chuyện.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để bạn vẽ một bộ sơ đồ quy trình hoàn chỉnh.
Bước 1 — Xác định ranh giới (scope). Trước khi vẽ, viết một câu: "Quy trình này bắt đầu khi nào và kết thúc khi nào?" Ví dụ: "Bắt đầu khi khách bấm Đặt hàng, kết thúc khi đơn được giao hoặc bị hủy." Ranh giới mơ hồ là nguyên nhân số một khiến sơ đồ phình to mất kiểm soát.
Bước 2 — Liệt kê các vai trò (cho swimlane). Hỏi: "Có những ai/hệ thống nào tham gia?" Mỗi vai trò sẽ là một lane. Với ChợViệt: Khách hàng, Hệ thống, Kho vận, Giao vận.
Bước 3 — Vẽ happy path trước. Đi từ Start Event, nối các Task theo trình tự lý tưởng nhất, đến End Event. Chưa cần lo ngoại lệ. Mục tiêu là có một xương sống để mọi người gật đầu "đúng rồi".
Bước 4 — Thêm gateway và các nhánh ngoại lệ. Quay lại từng điểm có thể "rẽ", đặt một Exclusive Gateway dạng câu hỏi Có/Không. Đây là bước phát hiện yêu cầu thiếu, hãy làm cẩn thận. Mỗi nhánh phải dẫn tới đâu đó (đừng để mũi tên "lơ lửng").
Bước 5 — Rà tên gọi. Mỗi Task đặt theo động từ + danh từ ("Xác nhận thanh toán", không phải "Thanh toán"). Mỗi nhánh gateway dán nhãn rõ ("Có" / "Không" / "Hết hàng").
Bước 6 — Chuyển sang góc nhìn dữ liệu (nếu cần). Vẽ Context Diagram của DFD: hệ thống là một process, xung quanh là external entity. Sau đó bung Level 1, đặt tên mọi data flow và data store. Kiểm tra balancing: dữ liệu vào/ra ở mỗi cấp có khớp nhau không.
Bước 7 — Walkthrough với stakeholder. Đặt câu hỏi: "Có trường hợp nào sơ đồ chưa cover không?" Đây là lúc bạn xác nhận lại (chúng ta sẽ học sâu về kỹ thuật playback/sign-off ở các bài elicitation sau).
Công cụ gợi ý: Với người mới, draw.io (diagrams.net) miễn phí và có sẵn shape BPMN/DFD. Lucidchart và Microsoft Visio mạnh hơn cho doanh nghiệp. Khi làm việc nhóm real-time, Miro rất tiện. Đừng để việc chọn tool làm bạn chần chừ — vẽ tay trên giấy hoặc bảng trắng vẫn là cách khởi đầu tốt nhất.
Lỗi thường gặp & mẹo
Lỗi 1 — Sơ đồ "mì sợi" (spaghetti). Quá nhiều mũi tên cắt chéo nhau khiến không ai đọc nổi. Mẹo: nếu một process flow vượt quá 15–20 task, hãy tách thành các sub-process. Mỗi sơ đồ chỉ nên vừa một trang nhìn.
Lỗi 2 — Gateway không có nhánh hội tụ. Bạn mở ra hai nhánh nhưng quên gộp lại, làm logic treo. Mẹo: mỗi khi mở gateway, tự hỏi "hai nhánh này có gặp lại nhau ở đâu không?"
Lỗi 3 — Nhầm sequence flow (nét liền) với message flow (nét đứt). Trong BPMN, hai pool khác nhau phải nối bằng message flow nét đứt, không phải sequence flow. Mẹo: nét liền chỉ chảy trong cùng một pool.
Lỗi 4 — Data flow không có nhãn. Một mũi tên DFD trống nghĩa là "có dữ liệu chảy" nhưng không ai biết là dữ liệu gì. Mẹo: mọi data flow đều phải có danh từ mô tả nội dung.
Lỗi 5 — Process trong DFD không cân bằng vào/ra. Một process có dữ liệu vào nhưng không có ra (gọi vui là "lỗ đen"), hoặc có ra nhưng không có vào ("phép màu"). Mẹo: mỗi process phải vừa nhận vừa xuất dữ liệu hợp lý.
Lỗi 6 — Vẽ quá chi tiết quá sớm. Sa đà vào từng nút bấm giao diện trong khi stakeholder mới cần bức tranh tổng. Mẹo: dùng đúng cấp độ trừu tượng cho đúng người nghe — lãnh đạo cần cấp cao, dev cần cấp chi tiết.
Mẹo vàng: Dù dùng ký hiệu chuẩn, hãy luôn để chú thích (legend) trên sơ đồ. Không phải stakeholder nào cũng biết BPMN. Một sơ đồ "đúng chuẩn" mà không ai đọc được thì vẫn là sơ đồ thất bại.
Bài tập thực hành
Hãy chọn quy trình "Đăng ký và mượn sách tại thư viện trường đại học" và thực hiện:
- Process flow (BPMN): Vẽ sơ đồ với ít nhất ba swimlane (Sinh viên, Thủ thư, Hệ thống thư viện). Bắt đầu từ "Sinh viên tìm sách" và kết thúc ở "Mượn thành công" hoặc "Bị từ chối". Bắt buộc có tối thiểu hai Exclusive Gateway, gợi ý: "Sách còn không?", "Sinh viên còn nợ phí phạt?".
- Liệt kê ngoại lệ: Viết ra ít nhất ba nhánh ngoại lệ mà bạn phát hiện được khi đặt gateway, và mô tả mỗi nhánh dẫn tới kết cục nào.
- Data Flow Diagram: Vẽ Context Diagram (Level 0) cho cùng hệ thống, xác định các external entity. Sau đó bung Level 1 với ít nhất hai process, hai data store (gợi ý: "Danh mục sách", "Hồ sơ mượn"), và đặt nhãn cho mọi data flow.
- Tự rà lỗi: Dùng danh sách "Lỗi thường gặp" ở trên để kiểm tra lại bài của mình — đặc biệt là balancing của DFD và việc gắn nhãn data flow.
Tóm tắt
- Process flow (BPMN) mô hình hóa công việc chảy qua tổ chức: dùng Start/End Event, Task, Gateway, và swimlane để thể hiện trình tự, quyết định và vai trò.
- Data Flow Diagram (DFD) mô hình hóa dữ liệu chảy qua hệ thống: dùng External Entity, Process, Data Store và Data Flow có nhãn; tổ chức theo cấp Context → Level 1 → Level 2, luôn giữ balancing.
- Giá trị thật sự của sơ đồ không nằm ở "happy path" mà ở các gateway và nhánh ngoại lệ — chúng phơi bày những yêu cầu bị bỏ sót.
- BPMN nói chuyện với nghiệp vụ về trình tự; DFD nói chuyện với kỹ thuật và an ninh về dữ liệu. BA giỏi dùng cả hai cho cùng một bài toán.
- Quy trình thực hành: xác định ranh giới → liệt kê vai trò → vẽ happy path → thêm gateway → rà tên → chuyển sang DFD → walkthrough với stakeholder.
- Tránh sơ đồ "mì sợi", gateway không hội tụ, nhầm message flow với sequence flow, và data flow không nhãn. Luôn kèm legend để mọi người đọc được.