Nhiều bạn mới học BA hay hỏi: "Business Analyst là BA nghiệp vụ hay BA phần mềm?" Câu trả lời thực tế là: cả hai đều là BA, nhưng phạm vi và độ sâu artifact khác nhau.
Nếu bạn hiểu nhầm hai vai trò này, bạn rất dễ học lệch. Có người học quá nhiều tool Jira nhưng không hiểu nghiệp vụ. Có người viết business process rất tốt nhưng khi vào team phần mềm lại không biết SRS, API, UAT, defect triage là gì.
Bài này giúp bạn nhìn rõ hơn.
1. BA nghiệp vụ là gì?
BA nghiệp vụ tập trung vào vấn đề kinh doanh:
- Doanh nghiệp đang gặp vấn đề gì?
- Quy trình hiện tại đang tắc ở đâu?
- Ai là stakeholder chính?
- Chính sách, quy định, KPI nào ảnh hưởng đến quyết định?
- Solution có tạo value thật không?
Ví dụ: công ty bảo hiểm muốn giảm thời gian xử lý claim từ 5 ngày xuống 2 ngày. BA nghiệp vụ sẽ phân tích quy trình claim hiện tại, phỏng vấn nhân viên xử lý hồ sơ, tìm bottleneck, định nghĩa future process và đề xuất hướng cải tiến.
Artifact thường gặp:
| Artifact | Dùng để làm gì |
|---|---|
| Stakeholder map | Biết ai ảnh hưởng, ai quyết định, ai cần được hỏi |
| Current state / future state | So sánh quy trình hiện tại và quy trình mong muốn |
| Business case | Giải thích vì sao nên đầu tư |
| Capability map | Xem tổ chức thiếu năng lực nào |
| Policy / rule catalog | Ghi lại quy định nghiệp vụ |
2. Software BA là gì?
Software BA chuyển nhu cầu nghiệp vụ thành yêu cầu hệ thống có thể build và test.
Software BA vẫn cần hiểu business, nhưng phải đi thêm một lớp:
- Hệ thống cần hành xử thế nào?
- User story và acceptance criteria đã đủ testable chưa?
- Có NFR về performance, security, availability, accessibility không?
- API/data nào bị ảnh hưởng?
- Error case và permission case đã rõ chưa?
- UAT sẽ kiểm chứng bằng scenario nào?
Ví dụ với bài toán bảo hiểm ở trên, Software BA sẽ viết SRS cho module claim intake: màn hình nhập hồ sơ, rule kiểm tra thiếu giấy tờ, trạng thái hồ sơ, notification, API lấy thông tin khách hàng, quyền xem hồ sơ, audit log và UAT scenarios.
Artifact thường gặp:
| Artifact | Dùng để làm gì |
|---|---|
| SRS | Đặc tả yêu cầu phần mềm |
| User story + AC | Đưa requirement vào backlog Agile |
| BPMN/UML | Mô hình hóa luồng và tương tác hệ thống |
| RTM | Trace requirement tới story và test case |
| UAT plan | Kế hoạch kiểm thử chấp nhận bởi business |
| API/data notes | Ghi rõ integration và validation |
3. So sánh nhanh
| Tiêu chí | Business BA | Software BA |
|---|---|---|
| Trọng tâm | Business outcome, process, stakeholder | System behavior, requirement, testability |
| Người làm việc nhiều | Business owner, operation, compliance, PM | PO, UX, Dev, QA, Architect, Data |
| Artifact chính | Business case, process map, rule catalog | SRS, user story, AC, RTM, UAT |
| Kỹ thuật cần biết | Facilitation, process analysis, strategy | SDLC, API/data basics, NFR, testing |
| Câu hỏi hay hỏi | "Vì sao cần thay đổi?" | "Hệ thống phải làm gì trong tình huống này?" |
Điểm quan trọng: Software BA không được bỏ business. Nếu không hiểu mục tiêu kinh doanh, bạn chỉ đang viết ticket. Business BA cũng không nên né phần mềm nếu solution cuối cùng là digital product.
4. Một ngày làm việc mẫu
Business BA
Buổi sáng:
- Review KPI vận hành với business owner
- Phỏng vấn team operations về bottleneck
- Vẽ current process và đánh dấu pain points
Buổi chiều:
- Facilitate workshop chọn option cải tiến
- Viết business case 1 trang
- Cập nhật stakeholder concerns và assumption log
Software BA
Buổi sáng:
- Refine user stories với PO, Dev, QA
- Làm rõ acceptance criteria và edge cases
- Review API/data impact với Tech Lead
Buổi chiều:
- Cập nhật SRS, RTM, change log
- Viết UAT scenarios
- Triage defect cùng QA và business stakeholder
5. Bạn nên học hướng nào trước?
Nếu bạn hoàn toàn mới, hãy học theo thứ tự:
- Business analysis foundation: problem framing, stakeholder, business process.
- Requirements engineering: BRD, SRS, business rules, acceptance criteria.
- SDLC và Agile/Scrum: requirement đi qua team phần mềm như thế nào.
- Modeling: BPMN, UML, wireframe, data flow.
- Technical literacy: API, SQL cơ bản, NFR, security/privacy.
- Delivery: backlog refinement, UAT, defect triage, release readiness.
- Evaluation: KPI, dashboard, benefit tracking.
Nếu bạn đến từ QA hoặc Dev, bạn có lợi thế ở phần Software BA. Hãy bổ sung business analysis foundation để không bị mắc kẹt ở ticket-level thinking.
Nếu bạn đến từ operations hoặc business domain, bạn có lợi thế về nghiệp vụ. Hãy bổ sung SDLC, SRS, API/data và testing để nói chuyện trơn tru với team phần mềm.
6. Bài tập thực hành
Chọn một tính năng quen thuộc, ví dụ "đặt lịch khám bệnh online".
Viết 2 phần:
Góc nhìn Business BA
- Problem statement
- Stakeholder map
- Current state process
- Future state process
- Success metrics
Góc nhìn Software BA
- 5 user stories
- Acceptance criteria cho mỗi story
- 5 business rules
- 5 NFR
- 5 UAT scenarios
Sau bài tập này, bạn sẽ thấy hai vai trò khác nhau nhưng bổ sung cho nhau.
7. Lỗi thường gặp
Lỗi 1: Nghĩ BA chỉ là người ghi biên bản
BA không chỉ ghi lại điều stakeholder nói. BA phải phân tích, phát hiện mâu thuẫn, hỏi lại, đề xuất option và giúp team ra quyết định.
Lỗi 2: Nghĩ Software BA phải biết code sâu
Không cần code như developer. Nhưng bạn cần đọc hiểu API contract, data fields, error codes, permission model và testing approach ở mức đủ để viết requirement rõ.
Lỗi 3: Viết requirement mà không trace tới business value
Mỗi requirement nên trả lời được: nó phục vụ mục tiêu nào, người dùng nào, metric nào.
Ví dụ end-to-end: đặt lịch tư vấn online
Giả sử công ty có đội tư vấn tài chính. Khách hàng đang gọi hotline để đặt lịch, nhân viên nhập thủ công vào Google Sheet. Vấn đề là lịch bị trùng, khách quên lịch, manager không có số liệu no-show.
Output của Business BA
| Phần | Ví dụ viết tốt |
|---|---|
| Problem statement | Khách hàng mất trung bình 12 phút để đặt lịch qua hotline; 18% lịch bị nhập sai hoặc đổi nhiều lần, làm tăng tải CSKH và giảm tỷ lệ tham gia tư vấn. |
| Business objective | Giảm 40% cuộc gọi hotline liên quan đến đặt lịch trong 3 tháng; giảm double booking xuống dưới 1%; tăng attendance từ 62% lên 75%. |
| Stakeholder | Khách hàng, CSKH, consultant, sales manager, compliance, IT support. |
| Current process | Khách gọi hotline -> CSKH kiểm tra sheet -> hỏi consultant -> nhập lịch -> gửi email thủ công. |
| Future process | Khách chọn consultant/slot trên web -> hệ thống giữ slot -> gửi email/SMS -> CSKH chỉ xử lý exception. |
| Policy | Khách được đổi lịch trước giờ hẹn tối thiểu 4 giờ; hủy dưới 4 giờ phải gọi hotline. |
Output của Software BA
| Artifact | Ví dụ |
|---|---|
| User story | As a customer, I want to book an available consultation slot online so that I can schedule without calling hotline. |
| Acceptance criteria | Given slot còn trống, when khách xác nhận đặt lịch, then hệ thống tạo appointment ở trạng thái Confirmed và gửi email xác nhận. |
| Business rule | BR-001: Slot đã Confirmed không được hiển thị cho khách khác. BR-002: Khách chỉ được đổi lịch trước giờ hẹn ít nhất 4 giờ. |
| Data fields | appointment_id, customer_id, consultant_id, slot_id, status, channel, confirmation_code, created_at. |
| API touchpoint | POST /appointments, PATCH /appointments/{id}/reschedule, GET /consultants/{id}/slots. |
| Error case | Nếu slot vừa bị người khác đặt, trả SLOT_UNAVAILABLE và hiển thị 3 slot thay thế. |
| UAT scenario | Khách đặt lịch thành công, đổi lịch trước 4 giờ, thử đổi lịch dưới 4 giờ, consultant xem lịch ngày hôm nay. |
Điểm cần thấy: Business BA giúp tổ chức thống nhất vấn đề, value và quy trình. Software BA giúp team build thống nhất behavior, data, rule, API, lỗi và test.
Nguồn tham khảo
- IIBA BABOK Guide: https://www.iiba.org/standards-and-resources/babok/
- PMI Business Analysis for Practitioners: https://www.pmi.org/shop/p-/book/business-analysis-for-practitioners-a-practice-guide/00101570601
- Scrum Guide 2020: https://scrumguides.org/scrum-guide.html
Kết luận
Business BA giúp tổ chức chọn đúng vấn đề. Software BA giúp team xây đúng giải pháp. Một BA mạnh trong sản phẩm số cần đi qua cả hai: hiểu business đủ sâu để không build sai hướng, và hiểu software đủ tốt để requirement có thể triển khai, kiểm thử và vận hành.
