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 duyệt hồ sơ vay tín chấp bằng BPMN. Đến đoạn "quyết định lãi suất", bạn gặp một mớ điều kiện: nếu điểm tín dụng trên 700 và thu nhập trên 20 triệu thì lãi suất 12%, nếu điểm 600–700 và có tài sản đảm bảo thì 15%, nếu khách hàng VIP thì giảm thêm 1%... Bạn bắt đầu nhồi tất cả vào sơ đồ bằng một rừng Gateway lồng nhau. Kết quả là một bản đồ quy trình rối như tơ vò, không ai dám sửa vì sợ làm hỏng logic.
Đây chính xác là vấn đề mà DMN — Decision Model and Notation ra đời để giải quyết. Trong các bài trước về Gateway (XOR, AND, OR ở Bài 15–17), bạn đã thấy Gateway rất giỏi diễn tả "dòng chảy rẽ nhánh", nhưng lại rất tệ khi phải diễn tả "logic quyết định phức tạp nhiều biến". DMN tách phần logic ấy ra khỏi luồng quy trình, đặt vào một mô hình riêng, gọn gàng và dễ kiểm thử.
Với một Business Process Analyst, DMN là kỹ năng tạo ra khác biệt rõ rệt. Nó giúp bạn nói chuyện cùng một ngôn ngữ với cả nghiệp vụ lẫn IT: business hiểu được bảng quyết định mà không cần biết code, còn engine thì có thể thực thi trực tiếp bảng đó. Bài này sẽ giúp bạn nắm chắc DMN 1.3, hai cấp độ của nó, cách kết hợp với BPMN, và quan trọng nhất là biết khi nào nên dùng — khi nào không.
Khái niệm cốt lõi
DMN là gì và vì sao tách rule khỏi process
DMN (Decision Model and Notation) là chuẩn do OMG ban hành — cùng tổ chức đã chuẩn hóa BPMN. Phiên bản phổ biến hiện nay là DMN 1.3 (2019). Triết lý cốt lõi của DMN nằm trong một câu: tách business rules ra khỏi process flow.
Tại sao việc tách này quan trọng đến vậy? Vì process và rule thay đổi với tốc độ khác nhau. Luồng quy trình "tiếp nhận hồ sơ → thẩm định → phê duyệt → giải ngân" có thể ổn định nhiều năm. Nhưng quy tắc tính lãi suất hay điều kiện phê duyệt tự động thì có thể thay đổi mỗi quý theo chính sách của Ngân hàng Nhà nước hoặc theo chiến lược kinh doanh. Nếu logic được nhúng cứng trong sơ đồ BPMN hoặc trong code, mỗi lần đổi rule là một lần phải sửa quy trình, test lại toàn bộ, rủi ro cao. DMN cho phép bạn sửa bảng rule mà không động đến luồng.
Hai cấp độ của DMN
DMN có hai cấp độ làm việc, và hiểu rõ sự phân tầng này là chìa khóa.
Cấp 1 — Decision Requirements Diagram (DRD): Đây là góc nhìn "kiến trúc". DRD trả lời câu hỏi: để ra một quyết định, ta cần những quyết định con nào và những dữ liệu đầu vào nào? DRD gồm các thành phần chính:
- Decision (hình chữ nhật): một quyết định cần được tính ra, ví dụ "Xác định hạng tín dụng".
- Input Data (hình bo góc kiểu oval): dữ liệu đầu vào, ví dụ "Thu nhập tháng", "Điểm tín dụng".
- Knowledge Source (hình giống tài liệu rách góc): nguồn tri thức/chính sách chi phối quyết định, ví dụ "Chính sách tín dụng 2026".
- Business Knowledge Model (hình chữ nhật vát góc): một khối logic tái sử dụng được.
Cấp 2 — Decision Logic (Decision Table): Đây là góc nhìn "chi tiết". Mỗi Decision trong DRD được hiện thực bằng logic cụ thể, mà phổ biến nhất là Decision Table (bảng quyết định). Bảng này có các cột Input (điều kiện), các cột Output (kết quả), và các dòng (rule). DMN còn cho phép viết logic bằng FEEL (Friendly Enough Expression Language) — một ngôn ngữ biểu thức được thiết kế để vừa con người đọc được vừa máy thực thi được.
Decision Table và Hit Policy
Decision Table là trái tim của DMN trong thực tế. Hãy hình dung một bảng:
| # | Điểm tín dụng | Thu nhập (triệu) | → Hạng | Lãi suất |
|---|---|---|---|---|
| 1 | ≥ 700 | ≥ 20 | A | 12% |
| 2 | [600..700) | ≥ 15 | B | 15% |
| 3 | < 600 | - | C | 18% |
- U (Unique): chỉ đúng một rule được khớp; các điều kiện không được chồng lấn. Đây là loại an toàn, dễ kiểm thử nhất, nên ưu tiên dùng.
- A (Any): nhiều rule có thể khớp nhưng tất cả phải cho cùng output.
- F (First): lấy rule khớp đầu tiên theo thứ tự — giống if/elseif trong lập trình.
- P (Priority): lấy output có độ ưu tiên cao nhất theo danh sách định trước.
- C (Collect): thu thập tất cả output khớp được (có thể kèm sum, min, max, count).
DMN kết hợp với BPMN như thế nào
Trong sơ đồ BPMN, có một loại Task đặc biệt tên là Business Rule Task (biểu tượng bảng nhỏ ở góc). Task này không tự xử lý logic mà "gọi" sang một Decision của DMN. Quy trình đi đến đó, đưa dữ liệu vào DMN, nhận kết quả về, rồi tiếp tục chảy. Nhờ vậy, BPMN lo phần điều phối (orchestration), còn DMN lo phần quyết định (decision logic) — mỗi bên làm đúng việc của mình.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số tại Việt Nam: tự động duyệt vay tiêu dùng
Một ngân hàng số giả định tên VietNeo Bank triển khai sản phẩm vay tiêu dùng online, mục tiêu duyệt tự động trong dưới 5 phút. Ban đầu, đội phân tích nhúng toàn bộ logic duyệt vào BPMN bằng 14 Gateway XOR lồng nhau. Mỗi lần phòng Rủi ro đổi ngưỡng (ví dụ nâng yêu cầu thu nhập tối thiểu từ 8 lên 10 triệu), đội IT mất trung bình 3 ngày để sửa, test và deploy lại — chưa kể vài lần sửa nhầm nhánh gây từ chối oan khách hàng tốt.
Sau khi tái cấu trúc theo DMN: luồng BPMN chỉ còn một Business Rule Task tên "Đánh giá đủ điều kiện vay", trỏ tới một DRD gồm ba Decision con — "Xác minh thu nhập", "Tính điểm rủi ro", "Quyết định phê duyệt". Mỗi Decision là một Decision Table với Hit Policy Unique. Giờ đây khi phòng Rủi ro muốn đổi ngưỡng, một Business Analyst chỉ cần sửa một ô trong Decision Table, kiểm thử bằng vài bộ dữ liệu mẫu, và publish — thời gian từ 3 ngày xuống còn nửa buổi. Tỷ lệ từ chối oan giảm vì logic giờ minh bạch, ai cũng đọc được bảng.
Bài học: khi logic có nhiều biến và thay đổi thường xuyên, đừng nhồi vào Gateway. Tách ra DMN để business tự bảo trì được, IT chỉ lo hạ tầng.
Ví dụ 2 — Sàn thương mại điện tử: phân loại đơn hàng để chống gian lận
Một sàn TMĐT khu vực Đông Nam Á (giả định tên ShopFast) cần quyết định mỗi đơn hàng sẽ đi tuyến nào: duyệt tự động, yêu cầu OTP bổ sung, hay chuyển đội fraud xem xét thủ công. Quyết định phụ thuộc vào: giá trị đơn, lịch sử khách, phương thức thanh toán, địa chỉ giao có khớp địa chỉ thẻ không, và đơn có dùng voucher giá trị lớn không.
Đội kiến trúc xây một DRD với Decision gốc "Xác định tuyến xử lý đơn", ăn kết quả từ hai Decision con: "Tính điểm gian lận" (Decision Table, Hit Policy Collect với phép sum để cộng dồn điểm rủi ro từ nhiều dấu hiệu) và "Phân hạng khách hàng". Decision gốc dùng Hit Policy Priority: nếu đơn vừa khớp điều kiện "duyệt tự động" vừa khớp "chuyển fraud", thì ưu tiên an toàn — chuyển fraud thắng.
Điểm hay: khi đội Tăng trưởng muốn nới lỏng để tăng tỷ lệ chuyển đổi mùa sale, họ chỉ điều chỉnh ngưỡng điểm trong bảng "Tính điểm gian lận" mà không chạm vào luồng giao hàng. Một lần, nhờ Collect + sum minh bạch, họ phát hiện một dấu hiệu rủi ro bị tính trùng trọng số — sửa ngay trên bảng thay vì lục code.
Bài học: Hit Policy không phải chi tiết kỹ thuật vụn vặt — chọn đúng Hit Policy (Collect để cộng điểm, Priority để ưu tiên an toàn) chính là chỗ thể hiện tư duy nghiệp vụ.
Ví dụ 3 — Công ty bảo hiểm: tính phí và quy tắc thay đổi theo chính sách
Một công ty bảo hiểm giả định An Phúc Life tính phí bảo hiểm nhân thọ dựa trên tuổi, giới tính, tình trạng hút thuốc, số tiền bảo hiểm và gói sản phẩm. Quy tắc tính phí được nhà tái bảo hiểm cập nhật mỗi năm. Trước đây, mỗi lần cập nhật là một dự án IT nhỏ.
Họ mô hình hóa bằng DMN, trong đó Knowledge Source trên DRD ghi rõ "Bảng phí tái bảo hiểm 2026" — tài liệu chính sách chi phối các Decision Table. Điều này tạo ra khả năng truy vết: khi kiểm toán hỏi "tại sao phí dòng này là con số đó", Analyst chỉ ngay vào Knowledge Source và rule tương ứng. Logic phức tạp (nội suy phí theo tuổi) được viết bằng biểu thức FEEL thay vì liệt kê hàng trăm dòng.
Bài học: DMN không chỉ để thực thi, mà còn để quản trị và truy vết tri thức nghiệp vụ — đặc biệt giá trị trong ngành bị quản lý chặt như bảo hiểm, ngân hàng.
Hướng dẫn từng bước
Khi bạn cần tách một khối logic quyết định ra DMN, hãy làm theo trình tự sau:
- Phát hiện điểm nóng quyết định trong BPMN. Rà soát sơ đồ, tìm chỗ có từ ba Gateway lồng nhau trở lên, hoặc một Gateway có điều kiện phụ thuộc nhiều biến. Đó là ứng viên để chuyển sang DMN.
- Đặt tên cho quyết định chính. Viết nó dưới dạng động từ + danh từ rõ ràng: "Xác định hạng tín dụng", "Quyết định tuyến xử lý đơn". Tên tốt giúp cả team hiểu ngay phạm vi.
- Vẽ Decision Requirements Diagram (DRD). Bắt đầu từ quyết định chính, hỏi "để ra được nó, tôi cần biết gì?". Liệt kê Input Data và các Decision con. Nối bằng mũi tên phụ thuộc. Thêm Knowledge Source nếu có chính sách/tài liệu chi phối.
- Thiết kế từng Decision Table. Với mỗi Decision, xác định cột Input (điều kiện), cột Output (kết quả). Liệt kê các rule thành dòng. Dùng khoảng (như
[600..700)) thay vì viết nhiều dòng rời rạc.
- Chọn Hit Policy phù hợp. Mặc định ưu tiên Unique vì dễ kiểm thử. Chỉ dùng First/Priority/Collect khi nghiệp vụ thực sự yêu cầu. Ghi rõ Hit Policy ở góc trên trái bảng.
- Kiểm tra tính đầy đủ và nhất quán. Đảm bảo mọi tổ hợp input đều khớp ít nhất một rule (không có lỗ hổng), và với Unique thì không có chồng lấn. Nhiều tool như Camunda Modeler có chức năng kiểm tra completeness tự động.
- Gắn lại vào BPMN bằng Business Rule Task. Thay cụm Gateway cũ bằng một Business Rule Task trỏ tới Decision chính. Định nghĩa rõ dữ liệu vào và kết quả ra.
- Kiểm thử bằng bộ dữ liệu mẫu. Tạo các test case bao phủ cả trường hợp biên (đúng ngưỡng, dưới ngưỡng, thiếu dữ liệu) và chạy thử trên engine trước khi đưa vào sản xuất.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi mọi logic vào Decision Table mà bỏ qua DRD. Nhiều người mới nhảy thẳng vào vẽ bảng khổng lồ 30 cột. Hãy luôn bắt đầu bằng DRD để phân rã quyết định lớn thành các quyết định con nhỏ, dễ đọc, dễ tái sử dụng.
Lỗi 2 — Bảng có lỗ hổng hoặc chồng lấn. Một input không khớp dòng nào sẽ khiến engine trả về rỗng và có thể làm treo quy trình. Luôn thêm một dòng "mặc định" cho trường hợp còn lại, và dùng công cụ kiểm tra completeness.
Lỗi 3 — Chọn sai Hit Policy. Dùng First Policy khi đáng lẽ phải Unique sẽ che giấu lỗi chồng lấn — engine âm thầm lấy dòng đầu mà bạn không biết logic đang sai. Mặc định hãy bắt đầu với Unique, chỉ đổi khi có lý do nghiệp vụ rõ ràng.
Lỗi 4 — Lạm dụng DMN cho mọi thứ. DMN giỏi với quyết định dạng "input → output theo rule". Nó không thay thế quy trình. Đừng cố mô hình hóa luồng tuần tự nhiều bước bằng DMN — đó là việc của BPMN.
Mẹo 1 — Dùng khoảng và FEEL để gọn bảng. Thay vì 10 dòng cho từng mức tuổi, hãy dùng [18..30], > 60. FEEL cho phép viết điều kiện và phép tính ngắn gọn mà vẫn dễ đọc.
Mẹo 2 — Đặt Knowledge Source rõ ràng để phục vụ kiểm toán. Trong ngành bị quản lý, việc chỉ ra "rule này đến từ chính sách nào" là yêu cầu bắt buộc khi audit (chủ đề ta sẽ gặp lại ở Bài 50).
Mẹo 3 — Phiên bản hóa bảng quyết định. Mỗi lần đổi rule, lưu phiên bản và ghi chú lý do. Việc này giúp truy vết "tại sao tháng trước đơn này được duyệt còn tháng này thì không".
Bài tập thực hành
Bài tập 1 — Vẽ DRD. Một chuỗi cửa hàng cà phê muốn quyết định "mức chiết khấu cho khách hàng thành viên" dựa trên: hạng thành viên (Bạc/Vàng/Kim cương), tổng chi tiêu 6 tháng gần nhất, và việc có đang trong tháng sinh nhật hay không. Hãy vẽ DRD: xác định Decision chính, các Input Data, và ít nhất một Decision con (gợi ý: "Xác định hạng dựa trên chi tiêu" có thể là một Decision con).
Bài tập 2 — Thiết kế Decision Table. Từ DRD trên, hãy viết Decision Table cho "Quyết định mức chiết khấu" với tối thiểu 5 rule. Ghi rõ cột Input, cột Output và Hit Policy bạn chọn. Giải thích vì sao chọn Hit Policy đó.
Bài tập 3 — Tìm lỗ hổng. Cho bảng: dòng 1 "Tuổi [18..30] → gói A", dòng 2 "Tuổi [30..40] → gói B", dòng 3 "Tuổi > 40 → gói C". Hãy chỉ ra hai vấn đề: (a) input nào bị chồng lấn, (b) input nào không khớp dòng nào. Đề xuất cách sửa.
Bài tập 4 — Tích hợp BPMN. Lấy một quy trình bạn quen thuộc (ví dụ duyệt nghỉ phép) có ít nhất 3 điều kiện rẽ nhánh. Hãy mô tả bằng lời cách thay cụm Gateway đó bằng một Business Rule Task trỏ tới DMN: dữ liệu nào đi vào, kết quả nào quay ra.
Tóm tắt
DMN — Decision Model and Notation, chuẩn DMN 1.3 của OMG — là người bạn song hành của BPMN, sinh ra để tách business rules khỏi process flow. Nhờ đó, rule (vốn thay đổi nhanh) có thể được sửa độc lập với luồng quy trình (vốn ổn định hơn).
DMN làm việc ở hai cấp: Decision Requirements Diagram (DRD) cho góc nhìn kiến trúc — phân rã quyết định lớn thành các quyết định con và dữ liệu đầu vào; và Decision Logic với ngôi sao là Decision Table cho phần chi tiết. Hiểu sâu Hit Policy (Unique, Any, First, Priority, Collect) là chìa khóa để bảng quyết định vừa đúng vừa kiểm thử được — mặc định hãy chọn Unique.
Trong BPMN, Business Rule Task là cây cầu nối: quy trình điều phối, DMN quyết định. Qua ba ví dụ — duyệt vay ngân hàng, chống gian lận TMĐT, tính phí bảo hiểm — bạn thấy giá trị thực: business tự bảo trì logic, IT lo hạ tầng, và mọi thứ minh bạch để kiểm toán. Hãy nhớ quy tắc vàng: khi thấy Gateway lồng nhau từ ba tầng trở lên, đó là tín hiệu nên rút logic ra DMN. Dùng đúng chỗ, DMN sẽ biến những bản đồ quy trình rối rắm thành thiết kế gọn gàng, dễ thay đổi và đáng tin cậy.