BAHUB.VN
Glossary

Business Analysis

General BAPhân tích nghiệp vụ

Hoạt động tìm ra nhu cầu thật của tổ chức và đề xuất giải pháp mang lại giá trị, theo định nghĩa của IIBA. Nó là một việc chứ không phải một chức danh, nên PO, PM hay trưởng phòng đều đang làm.

Định nghĩa

Nhiều bạn mới vào nghề dùng lẫn "Business Analysis" với "Business Analyst" như thể là một. Cái đầu là công việc, cái sau là người có chức danh đó trên hợp đồng lao động. Phân biệt được chỗ này giúp bạn bớt tự ái khi PO hay trưởng phòng vận hành làm phần việc mà bạn tưởng là của riêng mình.

IIBA định nghĩa trong BABOK v3: business analysis là thực hành tạo điều kiện cho thay đổi trong một tổ chức, bằng cách xác định nhu cầu và đề xuất giải pháp mang lại giá trị cho các bên liên quan.

Ba từ khoá cần nhớ trong định nghĩa đó: thay đổi, nhu cầu, giá trị. Thiếu một trong ba thì việc bạn đang làm là ghi chép, chưa phải phân tích.

Bóc từng chữ trong định nghĩa

  • Thay đổi (change): luôn có một trạng thái trước và một trạng thái sau. Nếu sau khi bạn làm xong mà chẳng có gì khác đi, đó chưa phải business analysis.
  • Nhu cầu (need): vấn đề hoặc cơ hội, chứ không phải giải pháp. "Khách muốn thêm nút xuất Excel" là giải pháp. Nhu cầu ẩn phía sau có thể là "kế toán đang gõ tay 200 dòng mỗi sáng".
  • Giải pháp (solution): phần mềm chỉ là một loại. Sửa quy trình, đổi phân quyền, bỏ hẳn một bước duyệt cũng là giải pháp — loại giải pháp không cần ai mở IDE lên.
  • Giá trị (value): đo được thì tốt, đo bằng cảm nhận cũng chấp nhận, nhưng phải nói ra được nó dành cho ai.

Ai làm, làm lúc nào

Việc này không bị khoá trong một chức danh. Trong một tổ chức bình thường bạn sẽ thấy:

NgườiLàm business analysis ở phần nào
BA / IT BAToàn bộ chu trình, từ nhu cầu tới nghiệm thu
Product OwnerƯu tiên và quyết định giá trị nào làm trước
Trưởng phòng nghiệp vụMô tả hiện trạng, xác nhận đúng sai
Tech LeadĐánh giá tính khả thi, chi phí kỹ thuật của từng phương án
QCPhát hiện yêu cầu mâu thuẫn khi viết test case

Thời điểm thì trải dài trước, trong và sau dự án. Phần sau dự án hay bị bỏ qua nhất: gần như không đội nào ở Việt Nam quay lại đo xem tính năng đã xây có được dùng không.

Ví dụ thực tế

Tám giờ sáng ở phòng điều phối của một công ty vận tải đường dài, ba máy bàn đổ chuông cùng lúc. Ban giám đốc đã chốt từ tuần trước: làm app cho tài xế để giảm gọi. Nếu chỉ nhận yêu cầu rồi làm, bạn sẽ ra một app có nút nhận đơn, nút cập nhật trạng thái, xong.

Làm business analysis tử tế thì trước hết ngồi nghe tổng đài hết buổi sáng đó. Trong 183 cuộc của một ngày thứ Ba bình thường, số cuộc để nhận đơn chỉ chiếm một phần nhỏ. Phần còn lại là hỏi bãi nào đang trống và giấy tờ nào phải mang theo. Nhu cầu thật nằm ở thông tin bãi và checklist chứng từ. Một app tập trung vào nhận đơn sẽ được cài rồi bỏ đó, còn tổng đài vẫn đổ chuông như cũ.

Lỗi hay gặp

Nhận nguyên yêu cầu rồi chuyển thẳng cho dev, gọi đó là "làm theo ý khách". Khách trả tiền cho kết quả, không phải cho việc bạn ghi đúng lời họ nói.

Lỗi thứ hai tinh vi hơn: phân tích quá đà. Có dự án cần đúng hai buổi họp và một bảng tính là đủ để ra quyết định, nhưng BA vẫn dựng đủ bộ tài liệu vì "quy trình công ty yêu cầu". BABOK gọi việc chọn mức độ nặng nhẹ này là adaptive hay predictive approach, và nó là quyết định phải cân nhắc chứ không mặc định.

Muốn tự đánh giá mình có đang làm business analysis hay không, thử trả lời một câu: nếu tính năng này bị cắt khỏi bản phát hành, ai sẽ khó chịu và khó chịu vì cái gì. Trả lời không được thì phần phân tích còn thiếu.

Business Analysis là gì? Định nghĩa chuẩn IIBA | BAHUB.VN