Chào anh em 😀
Lâu quá rồi không viết blog, nay nhân dịp đầu xuân nên mình sẽ chia sẻ về một khái niệm rất quan trọng mà BA nào cũng cần nắm vững – Business Rule (Quy tắc nghiệp vụ).
1. Giới thiệu
Làm BA, chúng ta thường xuyên phải đi phân tích nghiệp vụ và viết tài liệu. Và một trong những thứ quan trọng nhất mà BA cần xác định chính là Business Rule. Vậy:
- Business Rule là gì?
- Nó khác gì với Business requirement?
- Làm sao để định nghĩa business rule hiệu quả?
Qua bài viết này, mình sẽ chia sẻ kinh nghiệm thực tế về business rule nhé.
2. Business Rule là gì?
Business Rule là các quy tắc, chính sách, ràng buộc mà một tổ chức/doanh nghiệp đặt ra để:
- Kiểm soát hoạt động kinh doanh
- Đảm bảo tính nhất quán của dữ liệu
- Tuân thủ các quy định pháp lý
- Thống nhất cách vận hành nghiệp vụ
Và đặt ra để khi build hệ thống (tại ta đang nói là IT BA mà) thì hệ thống sẽ phải tuân theo.
Nói cách khác
Business Rule là những gì định nghĩa hoặc ràng buộc một khía cạnh nào đó của nghiệp vụ. Nó giúp kiểm soát hoặc ảnh hưởng đến hành vi nghiệp vụ.
Ví dụ thực tế:
- “Khách hàng phải trên 18 tuổi mới được mở thẻ tín dụng”
- “Đơn hàng trên 500k được miễn phí ship”
- “Mỗi user chỉ được tạo tối đa 3 tài khoản”
3. Business Rule vs Business Requirement
Đây là 2 khái niệm hoàn toàn khác nhau mà nhiều bạn hay nhầm lẫn.
Business Requirement là những mục tiêu, nhu cầu mà business muốn đạt được. Nó trả lời câu hỏi “CÁI GÌ” (WHAT).
- “Hệ thống cần lưu được lịch sử giao dịch của khách hàng”
- “Khách hàng có thể đặt lịch với bác sĩ yêu thích”
Business Rule là các quy định, ràng buộc để đạt được requirement. Nó trả lời câu hỏi “NHƯ THẾ NÀO” (HOW).
- “Lịch sử giao dịch được lưu tối đa 5 năm”
- “Chỉ khách hàng VIP mới được đặt lịch trước 30 ngày”
- “Mỗi khách chỉ được đặt tối đa 3 lịch/tuần”
Những điểm khác biệt:
| Business Requirement | Business Rule | |
| Về tính chất | Mang tính định hướng, mục tiêu
Thường chung chung, high-level Focus vào outcome |
Mang tính ràng buộc, quy định
Phải cụ thể, chi tiết Focus vào implementation |
| Về nguồn gốc | Đến từ stakeholder/business user
Thường là pain point cần giải quyết Xuất phát từ nhu cầu thực tế |
Có thể từ nhiều nguồn:
Dựa trên phân tích nghiệp vụ |
| Về cách thể hiện | Khách hàng có thể mở thẻ tín dụng online | BR-001: Tuổi từ 18-65
BR-002: Thu nhập >= 10tr/tháng BR-003: CMND còn hiệu lực BR-004: Có tài khoản thanh toán |
| Về tính linh hoạt | Ít khi thay đổi
Thay đổi impact lớn Cần approval từ business |
Thường xuyên thay đổi
Thay đổi impact nhỏ hơn BA có thể suggest thay đổi |
4. Phân loại Business Rule
Theo kinh nghiệm làm việc của mình, business rule có thể chia thành các nhóm:
- Quy tắc ràng buộc (Constraint Rules): đây là những rule về giới hạn, điều kiện mà hệ thống phải tuân theo.
- Giới hạn độ tuổi (Khách hàng phải từ 18-65 tuổi mới được mở thẻ tín dụng)
- Hạn mức giao dịch (Rút tiền ATM tối đa 5tr/lần và 100tr/ngày)
- Số lượng tối đa/tối thiểu (Mỗi user chỉ được tạo max 3 tài khoản)
- Quy tắc tính toán (Computation Rules): Những rule liên quan đến công thức tính toán, xử lý số liệu
- Công thức tính điểm thưởng (Mỗi 100k chi tiêu = 1 điểm)
- Cách tính lãi suất (Lãi suất = Số dư * 0.8%/tháng)
- Logic tính phạt (Phí trả trễ = 3%/tháng trên số tiền chậm trả)
- Quy tắc quy trình (Process Rules): Rules về các bước xử lý, thứ tự thực hiện
- Đơn hàng phải qua bước xác nhận OTP trước khi thanh toán
- Khách hàng phải upload CMND trước khi tạo tài khoản
- Hoàn tiền sau 24h kể từ khi huỷ đơn thành công
- Quy tắc dữ liệu (Data Rules): Rules về format, ràng buộc dữ liệu.
- CMND phải là số và có 9 hoặc 12 ký tự
- Email phải đúng định dạng [email protected]
- Ngày sinh không được lớn hơn ngày hiện tại
5. Vai trò của Business Rule với BA
Business Rule cực kỳ quan trọng vì:
- Là nền tảng để xây dựng tính năng:
- Thiếu rule => thiếu validation
- Rule không rõ => code sai logic
- Rule không đầy đủ => thiếu case xử lý
Ví dụ: làm feature đăng ký tài khoản mà không có rule về format mật khẩu => users tạo mật khẩu yếu => security risk
- Giúp quản lý thay đổi:
- Dễ tracking khi có thay đổi
- Đánh giá impact dễ hơn
- Update requirement nhanh hơn
Ví dụ: khi legal yêu cầu thay đổi điều kiện mở thẻ, BA sẽ rà soát lại và chỉ cần update lại các rule liên quan, sau đó ghi rõ lại change để sau này dễ track.
- Trao đổi với team dễ hơn:
- Dev hiểu rõ logic cần code
- Tester biết case cần test
- PO/PM nắm được ràng buộc
6. Tips định nghĩa Business Rule hiệu quả
Qua thực tế làm việc, mình rút ra một số tips:
- Viết ngắn gọn, rõ ràng:
- Tránh câu dài, khó hiểu, một rule chỉ mô tả một ràng buộc
- Dùng từ ngữ đơn giản
- Format dễ đọc
Ví dụ:
- BAD: Khách hàng đăng ký thẻ phải đủ 18 tuổi và có thu nhập ổn định từ 10 triệu trở lên mỗi tháng
- GOOD:
- BR1: Khách hàng phải từ 18 tuổi trở lên
- BR2: Thu nhập tối thiểu 10tr/tháng
- Phân nhóm logic:
- Group theo chức năng
- Đánh ID dễ tracking
- Sắp xếp độ ưu tiên
Ví dụ nhóm rule cho feature Mở thẻ:
- Điều kiện cơ bản
- BR-001: Tuổi >= 18
- BR-002: Thu nhập >= 10tr/tháng
- Xác thực thông tin
- BR-003: CMND còn hiệu lực
- BR-004: SĐT đã xác thực OTP
- Tính hạn mức
- BR-005: Hạn mức = 3x thu nhập
- Validate kỹ:
- Review với SME (Subject Matter Expert)
- Check conflict
- Test các edge case
VD: Rule “Khách VIP được ưu tiên xử lý trong 2h” có conflict với rule “Đơn khiếu nại được xử lý theo thứ tự”.
- Cập nhật thường xuyên nếu có thay đổi:
- Version control: Lưu lại các version để dễ tracking
- Change log: Change log khi release sản phẩm
- Notification khi update: Update gì thì thông báo các bên liên quan
7. Một ví dụ thực tế
Ví dụ một feature Đặt lịch khám
| Business Requirement | Business Rules |
| UC01: Khách hàng có thể đặt lịch khám với bác sĩ yêu thích | Điều kiện đặt lịch BR-UC01-001: Chỉ đặt được lịch trong 30 ngày tới BR-UC01-002: Mỗi KH chỉ đặt max 3 lịch/tuần BR-UC01-003: Phải đặt trước ít nhất 24hRàng buộc bác sĩ BR-UC01-004: BS chỉ nhận tối đa 20 lịch/ngày BR-UC01-005: Thời gian khám: 8h-17h các ngày 2-7 BR-UC01-006: Mỗi ca khám 30pThanh toán BR-UC01-007: Phí đặt lịch: 50.000đ BR-UC01-008: Hoàn 100% nếu huỷ trước 24h BR-UC01-009: Hoàn 50% nếu huỷ trước 12h BR-UC01-010: Không hoàn tiền nếu huỷ < 12h |
8. Công cụ quản lý Business Rule
Mình hay dùng các tool sau:
- Confluence/Notion/Docs/Word: Viết doc, xưa hay sài, giờ cũng ít sài
- Excel: Track version, lúc 2019 sài cái này kha khá, viết dạng sheet nói chung đánh dấu ID các kiểu khá dễ quản lý
- Draw.io: Vẽ flow
- Dùng AI (ChatGPT/ClaudeAI): Phụ Generate ra thêm details, và nhờ vẽ các diagram logic
- Jira: Link với requirement
- Trello: Giờ hay sài Trello để add task, và trong task sẽ add luôn các Business Rule (dạng như add AC)
9. Kết bài
Hi vọng qua bài viết này anh em đã hiểu rõ hơn về Business Rule và cách quản lý nó hiệu quả. Nếu thấy hay thì anh em đừng quên chia sẻ và để lại comment góp ý nhé 😀
