Mở đầu — vì sao bài này quan trọng
Bạn đã bao giờ ngồi họp với team dev, đọc một đoạn yêu cầu kiểu "nếu khách hàng là thành viên VIP và đơn hàng trên 2 triệu thì miễn phí ship, nhưng nếu là thành viên thường thì phải mua trên 500 nghìn, còn khách vãng lai thì không bao giờ được miễn..." rồi cả phòng nhìn nhau hoang mang không biết đã liệt kê đủ trường hợp chưa? Đó chính xác là lúc bạn cần Decision Table (bảng quyết định) — một trong những kỹ thuật được đánh giá cao nhất trong BABOK Guide v3 và xuất hiện thường xuyên trong đề thi ECBA.
Decision Table không phải là một công cụ "đẹp để trang trí tài liệu". Nó là vũ khí giúp người Business Analyst (BA) biến những logic nghiệp vụ rối rắm — vốn dễ bị thiếu sót, mâu thuẫn, hiểu nhầm — thành một cấu trúc đầy đủ, có thể kiểm tra được, và dev chỉ việc đọc rồi code. Trong kỳ thi ECBA, bạn sẽ gặp các câu hỏi yêu cầu nhận diện khi nào nên dùng Decision Table thay vì viết yêu cầu dạng văn xuôi, và hiểu mối liên hệ giữa Decision Table với Business Rules Analysis. Quan trọng hơn, đây là kỹ năng bạn dùng gần như hàng tuần khi đi làm thật.
Bài này tập trung riêng vào Decision Tables và Decision Modeling — một technique cụ thể trong bộ 50 techniques của BABOK. Chúng ta sẽ không lan sang Decision Trees ở mức sâu (đó là biến thể), cũng không bàn về MoSCoW hay các kỹ thuật ưu tiên (Bài 28), mà đào sâu đúng vào cách dựng, kiểm tra và tối ưu một bảng quyết định.
Khái niệm cốt lõi
Decision Table là gì?
Decision Table là một biểu diễn dạng bảng của một tập hợp các điều kiện và các hành động (action) tương ứng. Nó trả lời câu hỏi: "Với mỗi tổ hợp giá trị của các điều kiện đầu vào, hệ thống/người dùng phải làm gì?".
Theo BABOK Guide v3, Decision Tables thuộc nhóm kỹ thuật hỗ trợ Business Rules Analysis và Requirements Analysis. Nó đặc biệt hữu ích khi logic có nhiều rule, mỗi rule phụ thuộc vào nhiều điều kiện, và các tổ hợp điều kiện khác nhau dẫn đến hành động khác nhau.
Cấu trúc bốn vùng (four quadrants)
Một Decision Table chuẩn được chia làm bốn vùng:
- Condition Stubs (gốc điều kiện): liệt kê các điều kiện đầu vào. Ví dụ: "Khách là thành viên VIP?", "Giá trị đơn hàng > 2 triệu?".
- Condition Entries (giá trị điều kiện): giá trị mà mỗi điều kiện có thể nhận — thường là Y (Yes) / N (No), đôi khi là khoảng giá trị.
- Action Stubs (gốc hành động): liệt kê các hành động khả thi. Ví dụ: "Miễn phí ship", "Tặng voucher 50k".
- Action Entries (giá trị hành động): đánh dấu (thường là X) hành động nào được kích hoạt cho mỗi rule.
Limited entry vs Extended entry
Có hai dạng bảng:
- Limited-entry table: mỗi điều kiện chỉ nhận giá trị nhị phân Y/N. Đơn giản, dễ kiểm tra tính đầy đủ.
- Extended-entry table: điều kiện có thể nhận nhiều giá trị (ví dụ loại khách = VIP / Thường / Vãng lai). Gọn hơn khi điều kiện có nhiều mức.
Tính đầy đủ và số tổ hợp
Đây là phần "vàng" mà nhiều BA bỏ qua. Nếu bạn có n điều kiện nhị phân, số tổ hợp lý thuyết tối đa là 2^n. Ví dụ 3 điều kiện Y/N → 2³ = 8 cột rule có thể có. Một Decision Table được làm đúng phải đảm bảo mọi tổ hợp đều được xử lý (đầy đủ — completeness) và không có hai rule cho cùng tổ hợp lại bảo làm hai việc trái ngược (không mâu thuẫn — consistency).
Tối ưu hóa: dấu gạch ngang "–" (don't care)
Khi một điều kiện không ảnh hưởng đến kết quả trong một rule nào đó, ta dùng dấu "–" (don't care). Điều này cho phép gộp nhiều cột thành một, làm bảng gọn lại. Ví dụ: "Khách vãng lai → không bao giờ miễn ship, bất kể giá trị đơn hàng" — cột giá trị đơn hàng đánh dấu "–".
Decision Modeling và mối liên hệ DMN
Decision Table thường là một mảnh của bức tranh lớn hơn gọi là Decision Modeling — mô hình hóa các quyết định nghiệp vụ và cách chúng phụ thuộc lẫn nhau. Chuẩn quốc tế phổ biến là DMN (Decision Model and Notation) của OMG, trong đó Decision Table là thành phần biểu diễn logic chi tiết bên trong mỗi "decision node". BA ở mức ECBA chỉ cần nắm ý niệm: Decision Table mô tả logic của một quyết định; Decision Model mô tả mạng lưới nhiều quyết định liên kết với nhau.
Tình huống thực tế
Ví dụ 1 — Tiki: chính sách miễn phí vận chuyển
Giả sử bạn là BA tại một sàn thương mại điện tử lớn như Tiki, được giao mô tả lại chính sách freeship. Sau khi phỏng vấn bộ phận vận hành, bạn rút ra ba điều kiện:
- C1: Khách hàng có gói TikiNOW không?
- C2: Giá trị đơn hàng ≥ 250.000đ?
- C3: Đơn thuộc danh mục hàng cồng kềnh (tủ lạnh, máy giặt)?
Với 3 điều kiện nhị phân, lý thuyết có 2³ = 8 tổ hợp. Khi dựng bảng, bạn phát hiện chính sách ban đầu mà vận hành mô tả bằng văn xuôi chỉ nói rõ 4 trường hợp — 4 tổ hợp còn lại bị bỏ trống, không ai biết xử lý ra sao. Ví dụ: "Khách có TikiNOW, đơn 300k, nhưng là hàng cồng kềnh" thì miễn ship hay vẫn phụ thu? Nhờ Decision Table, bạn mang đúng 4 lỗ hổng này quay lại hỏi vận hành, và họ chốt: hàng cồng kềnh luôn phụ thu 100k kể cả có TikiNOW.
Bài học: Decision Table không chỉ ghi lại logic — nó phơi bày những trường hợp chưa ai nghĩ tới. Đây là giá trị lớn nhất của kỹ thuật này.
Ví dụ 2 — Ngân hàng số: duyệt hạn mức thẻ tín dụng
Một ngân hàng số tại Việt Nam (giả định: ngân hàng "VBank") muốn tự động hóa việc đề xuất hạn mức thẻ tín dụng. BA dựng extended-entry table với các điều kiện:
- Thu nhập hàng tháng: < 10tr / 10–20tr / > 20tr
- Lịch sử tín dụng CIC: Tốt / Trung bình / Xấu
- Có tài sản đảm bảo: Có / Không
Ở đây nếu dùng limited-entry (Y/N) thì bảng phình to khủng khiếp, nên extended-entry là lựa chọn đúng. Khi rà soát, team rủi ro phát hiện một mâu thuẫn: có hai rule cùng điều kiện "thu nhập 10–20tr, CIC trung bình, không tài sản đảm bảo" nhưng một rule ghi hạn mức 30tr, rule kia ghi từ chối — do hai chuyên viên viết chính sách ở hai thời điểm khác nhau. Decision Table giúp họ phát hiện và thống nhất ngay trước khi đưa vào hệ thống core banking, tránh rủi ro pháp lý và khiếu nại.
Bài học: Với logic có rủi ro tài chính cao, tính không mâu thuẫn của Decision Table không phải là chuyện "cho đẹp" mà là yêu cầu tuân thủ.
Ví dụ 3 — Grab: phát hiện chuyến đi gian lận
Đội chống gian lận của một nền tảng gọi xe (giả định kiểu Grab) cần quy tắc gắn cờ "chuyến đi nghi ngờ". Các điều kiện: GPS tài xế và khách trùng vị trí bất thường? Tài khoản mới tạo dưới 24h? Mã giảm giá có dùng không? Thanh toán bằng thẻ vừa thêm?
Đây là bài toán fraud detection kinh điển — đúng tình huống dàn ý gốc của bài nhắc tới. Decision Table giúp đội vận hành diễn đạt rule cho dev mà không cần biết code, đồng thời dùng dấu "–" để gộp: "Nếu tài khoản mới < 24h VÀ thẻ vừa thêm → luôn gắn cờ, bất kể các điều kiện khác". Một dòng gộp này thay cho hàng chục tổ hợp con.
Bài học: Dấu "don't care" giúp bảng phản ánh đúng tư duy nghiệp vụ ("trường hợp này thì chặn ngay, khỏi xét thêm") và giữ bảng ở kích thước con người đọc nổi.
Hướng dẫn từng bước
Đây là quy trình 7 bước để dựng một Decision Table chỉn chu:
- Xác định quyết định cần mô hình hóa. Viết một câu rõ ràng: "Quyết định: có miễn phí ship cho đơn hàng này không và phụ thu bao nhiêu?". Một bảng nên phục vụ đúng một quyết định.
- Liệt kê toàn bộ điều kiện đầu vào (condition stubs). Phỏng vấn stakeholder, đọc business rules hiện hành. Ghi mỗi điều kiện dưới dạng câu hỏi trả lời được rạch ròi.
- Xác định các giá trị mỗi điều kiện có thể nhận. Quyết định dùng limited-entry (Y/N) hay extended-entry (nhiều mức).
- Liệt kê toàn bộ hành động (action stubs). Mỗi hành động là một kết quả cụ thể mà hệ thống/người dùng thực hiện.
- Sinh đầy đủ các tổ hợp (rules). Với n điều kiện nhị phân, tạo đủ 2^n cột trước, đừng vội bỏ cột nào. Sau đó điền hành động cho từng cột bằng cách hỏi stakeholder.
- Kiểm tra completeness và consistency. Đảm bảo: (a) mọi tổ hợp đều có hành động — không có lỗ hổng; (b) không có hai cột giống nhau lại chỉ hai hành động khác nhau — không mâu thuẫn.
- Tối ưu hóa (rút gọn). Dùng dấu "–" để gộp các cột mà một điều kiện không ảnh hưởng kết quả. Sau khi gộp, kiểm tra lại lần nữa rằng bảng vẫn bao phủ đủ.
Lỗi thường gặp & mẹo
- Bỏ sót tổ hợp. Lỗi phổ biến nhất. Luôn bắt đầu bằng 2^n cột đầy đủ rồi mới rút gọn, đừng làm ngược lại. Nếu bảng "trông gọn ngay từ đầu" thì khả năng cao bạn đã thiếu trường hợp.
- Nhồi nhiều quyết định vào một bảng. Một bảng = một quyết định. Nếu thấy hành động của bạn lại trở thành đầu vào cho một logic khác, đó là dấu hiệu cần tách thành Decision Model nhiều bảng liên kết.
- Điều kiện bị chồng lấn (overlap). Hai điều kiện không độc lập, ví dụ "đơn > 500k" và "đơn > 1tr" trong cùng bảng nhị phân, gây ra tổ hợp vô lý (đơn > 1tr nhưng không > 500k). Hãy thiết kế điều kiện loại trừ nhau hoặc dùng extended-entry với các khoảng.
- Quên rule mặc định (default/else). Luôn tự hỏi: "Nếu không rule nào khớp thì sao?". Một Decision Table tốt thường có hành động mặc định.
- Dùng văn xuôi khi lẽ ra nên dùng bảng. Trong đề ECBA, nếu câu hỏi mô tả "nhiều rule, đa điều kiện, action khác nhau" thì đáp án thường là Decision Table. Nhớ cụm tín hiệu này.
- Mẹo thi: Decision Table gắn với hai thứ trong BABOK — nó là một technique, và nó hỗ trợ phân tích business rules. Phân biệt với "business rules" (là nội dung quy tắc) và "decision table" (là cách biểu diễn quy tắc đó).
Bài tập thực hành
Bài tập 1 — Dựng bảng đầy đủ. Một quán cà phê chuỗi (giả định "Highlands") áp dụng chương trình: thành viên app được giảm 10%; đơn từ 3 ly trở lên tặng thêm 1 bánh; vào khung giờ 14h–16h (giờ thấp điểm) giảm thêm 15%. Hãy xác định các điều kiện nhị phân, tính số tổ hợp tối đa (2^n), dựng bảng đầy đủ, rồi điền action cho từng cột.
Bài tập 2 — Phát hiện lỗ hổng. Lấy bảng ở Bài tập 1, kiểm tra xem có tổ hợp nào dẫn đến hành động "khó xử" không (ví dụ: vừa được giảm 10% vừa 15% thì cộng dồn hay lấy mức cao nhất?). Ghi lại câu hỏi bạn sẽ mang đi hỏi stakeholder.
Bài tập 3 — Rút gọn. Tìm ít nhất một cặp cột trong bảng của bạn có thể gộp bằng dấu "–", giải thích vì sao điều kiện đó là "don't care" trong trường hợp ấy.
Bài tập 4 — Tư duy ECBA. Cho tình huống: "BA cần ghi lại logic xét duyệt hoàn tiền với 4 điều kiện, mỗi điều kiện Y/N, dẫn đến 3 mức hoàn tiền khác nhau". Hỏi: kỹ thuật nào phù hợp nhất và số tổ hợp tối đa cần kiểm tra là bao nhiêu? (Gợi ý: 2⁴.)
Tóm tắt
Decision Table là kỹ thuật biểu diễn logic nghiệp vụ dưới dạng bảng, dùng khi có nhiều rule với đa điều kiện dẫn đến hành động khác nhau — như pricing, eligibility, hay fraud detection. Cấu trúc gồm bốn vùng: condition stubs, condition entries, action stubs, action entries; mỗi cột là một rule. Giá trị cốt lõi của kỹ thuật không chỉ là ghi lại logic mà là phơi bày lỗ hổng và mâu thuẫn mà văn xuôi che giấu — nhờ nguyên tắc kiểm tra đầy đủ 2^n tổ hợp (completeness) và không mâu thuẫn (consistency). Dùng dấu "–" (don't care) để rút gọn bảng về kích thước người đọc nổi. Ở tầm rộng hơn, nhiều Decision Table liên kết tạo thành Decision Model (chuẩn DMN). Với kỳ thi ECBA, hãy nhớ: Decision Table là một technique hỗ trợ Business Rules Analysis, và cụm tín hiệu "nhiều điều kiện → nhiều hành động" gần như luôn dẫn tới đáp án này. Khi đi làm thật, đây là một trong những công cụ giúp bạn nói chuyện chính xác với cả vận hành lẫn dev mà không ai hiểu nhầm ai.