Quy trình trong phân tích nghiệp vụ

CÁC Ý CHÍNH 

Business Analysis là quy trình tạo ra giá trị kinh doanh, không chỉ là viết tài liệu.
Quy trình Business Analysis gồm 7 giai đoạn từ khởi tạo đến đóng dự án.
Thu thập yêu cầu là nền tảng của toàn bộ dự án.
Business Analyst đóng vai trò cầu nối giữa Business và Technical Team.
Thành công của Business Analysis được đo bằng Business Outcome, không phải số lượng tài liệu tạo ra.
Một Business Analyst giỏi tập trung vào vấn đề kinh doanh trước khi nghĩ đến giải pháp.

1. Tổng quan

Phân tích nghiệp vụ là một quy trình có cấu trúc nhằm:

Hiểu vấn đề kinh doanh.
Xác định nhu cầu.
Phân tích hiện trạng.
Thiết kế giải pháp.
Hỗ trợ triển khai.
Đánh giá kết quả.

Mục tiêu cuối cùng là giải quyết vấn đề kinh doanh và tạo giá trị cho tổ chức.

2. Quy trình trong Phân tích nghiệp vụ

2.1. Khởi tạo và lên kế hoạch

Mục đích của việc này là hiểu vấn đề kinh doanh, cơ hội cải tiến, mục tiêu của dự án. Trong bước này, các hoạt động chính bao gồm:

Xác định vấn đề hoặc cơ hội của Business: Cần xác định được hiện trạng (Current State) và vạch ra tương lai mong muốn (Future State).
Ví dụ: Hiện trạng là quản lý kho bằng Excel, sai lệch tồn kho cao. Mong muốn tương lai là quản lý tập trung, theo dõi tồn kho theo thời gian thực.
Xác định các bên liên quan: Tìm kiếm và xác định tất cả các bên liên quan (Stakeholder).
Việc này không chỉ là quy trình trong Phân tích nghiệp vụ, mà còn hỗ trợ rất nhiều trong công tác quản trị dự án.
Định nghĩa mục tiêu và phạm vi: Xác định rõ ràng mục tiêu của dự án, phạm vi thực hiện (in-scope) và loại trừ (out-of-scope).
Điều này giúp tránh tình trạng công việc không bao giờ xong (Scope Creep) và giúp các bên thống nhất với nhau.

2.2. Thu thập yêu cầu

Mục đích của bước này là nắm bắt, khai thác, thu thập nhu cầu từ các bên liên quan. Một chuyên viên Phân tích nghiệp vụ cần hiểu người dùng đang làm gì, vấn đề của họ và các kỳ vọng họ mong muốn.

Kỹ thuật thu thập yêu cầu có thể bao gồm:

Phỏng vấn (Interview): Phù hợp khi cần đào sâu vấn đề, hiểu ngữ cảnh.
Hội thảo (Workshop): Làm việc nhóm với nhiều Stakeholder cùng lúc, giúp đồng bộ nhận thức và giải quyết xung đột yêu cầu.
Khảo sát (Survey): Thu thập dữ liệu số lượng lớn, nhanh chóng và tiết kiệm thời gian.
Quan sát (Observation): Quan sát người dùng làm việc thực tế để phát hiện quy trình ngầm, công việc thủ công, điểm nghẽn vận hành.
Phân tích tài liệu (Document Analysis): Phân tích SOP, quy trình, báo cáo, hệ thống hiện tại.

Sau khi có danh sách yêu cầu, cần cân nhắc mức độ ưu tiên vì không phải yêu cầu nào cũng quan trọng như nhau. Tiêu chí ưu tiên có thể là:

Phục vụ giá trị cho tổ chức (Business Value).
Mức độ cấp thiết (Urgency).
Khả năng thực hiện (Feasibility).
Nguồn lực đáp ứng (Resource Availability).

2.3. Phân tích và đặc tả yêu cầu

Việc phân tích đặc tả yêu cầu nhằm đảm bảo các yêu cầu chính xác, đầy đủ, nhất quán và khả thi.

2.3.1. Phân tích yêu cầu

Khi có các yêu cầu, cần phân tích để phát hiện mâu thuẫn, thiếu sót hoặc trùng lặp. Kết quả giúp đảm bảo yêu cầu phù hợp với mục tiêu tổ chức.

2.3.2. Phân tích khoảng Gap

Hiện trạng thực tế của tổ chức và mong muốn cải tiến luôn có một khoảng Gap ở giữa. Việc phân tích Gap giúp xác định khoảng cách cần thay đổi để đạt trạng thái mong muốn.

2.3.3. Xác nhận yêu cầu

Sau khi phân tích và làm rõ, cần xác nhận với các bên liên quan để chứng thực rằng yêu cầu đã đúng, đủ và khả thi.

2.3.4. Mô hình hóa yêu cầu

Sử dụng mô hình trực quan để mô tả yêu cầu, giúp các bên hiểu góc nhìn của nhau. Một số mô hình:

Process Model: Mô tả luồng công việc.
Data Flow Diagram (DFD): Mô tả luồng dữ liệu.
Entity Relationship Diagram (ERD): Mô tả cấu trúc dữ liệu.

2.3.5. Đặc tả yêu cầu

Viết yêu cầu thành tài liệu dưới các hình thức:

Business Requirements Document (BRD): Mô tả nhu cầu kinh doanh, mục tiêu và phạm vi.
Functional Requirements Document (FRD): Mô tả các chức năng của hệ thống.
Use Case: Mô tả tương tác của các nhóm người dùng với hệ thống.
User Story: Cấu trúc phổ biến: “Là một <vai trò>, tôi mong muốn <mục tiêu>, vậy nên <kết quả mong đợi>”.

2.4. Thiết kế giải pháp

Thiết kế giải pháp (Solution Design) là bước đề xuất phương án đáp ứng các yêu cầu đã phân tích.

Các hoạt động chính:

Thiết kế bản mẫu: Wireframe, Mockup, Prototype, Functional Design.
Phối hợp với mục tiêu Business: Giải pháp phải phục vụ mục tiêu kinh doanh, không để công nghệ dẫn dắt nhu cầu.
Đánh giá phương án thay thế: So sánh theo chi phí, thời gian, rủi ro, mức độ ảnh hưởng đến Business.

2.5. Thực thi

Đây là bước triển khai các giải pháp đã thiết kế và được phê duyệt. Vai trò của chuyên viên phân tích nghiệp vụ:

Hỗ trợ nhóm phát triển: Làm rõ yêu cầu, trả lời câu hỏi nghiệp vụ, xử lý thay đổi.
Quản lý thay đổi: Quản lý thay đổi yêu cầu, đào tạo người dùng, truyền thông nội bộ, hướng dẫn vận hành.
Quản lý rủi ro: Theo dõi rủi ro về tiến độ, thay đổi yêu cầu, rào cản chấp nhận giải pháp.

2.6. Đánh giá giải pháp

Sau khi triển khai, cần đánh giá hiệu quả thực tế của giải pháp thông qua:

Kiểm thử (Testing):
Kiểm thử chức năng (Functional Testing).
Người dùng xác nhận hệ thống đáp ứng đúng yêu cầu (User Acceptance Testing).
Đánh giá hiệu năng (Performance Testing).
Xác nhận mục tiêu kinh doanh (Business Validation): Mục tiêu ban đầu có đạt được không, giải pháp có tạo giá trị thực tiễn không.
Đo lường kết quả (Success Measurement): Đánh giá bằng KPI.

KPI	Trước	Sau
Hiệu quả chốt đơn	80%	98%
Sản phẩm lỗi	15%	2%

2.7. Kết thúc dự án

Sau khi hoàn thành đánh giá, bước cuối cùng là đóng dự án chính thức. Công việc còn lại thường gồm:

Ghi nhận bài học (Lessons Learned): Ghi nhận điều làm tốt và điều cần cải thiện.
Chốt tài liệu (Final Documentation): Hoàn thiện hướng dẫn sử dụng, tài liệu training, tài liệu quy trình.
Chính thức kết thúc (Formal Sign-off): Các bên liên quan xác nhận hạng mục đã bàn giao đầy đủ, mục tiêu dự án đã đạt.

3. Quy trình thu thập yêu cầu

Quy trình thu thập gồm 5 bước chính:

Khai thác / khai mở yêu cầu.
Tài liệu hóa yêu cầu.
Phân tích yêu cầu.
Xác nhận yêu cầu.
Quản lý yêu cầu.

Trong đó, công việc quản lý yêu cầu được thực hiện suốt vòng đời dự án, bao gồm:

Change Management: Quản lý thay đổi yêu cầu. Nếu có, cần thực hiện quy trình 9 bước.
Version Control: Quản lý phiên bản tài liệu để luôn cập nhật và có thể truy vết.
Stakeholder Communication: Duy trì thông tin nhất quán giữa các bên.

4. Thách thức của chuyên viên phân tích

Thách thức	Nguyên nhân	Giải pháp gợi ý
Yêu cầu quá mơ hồ	Thiếu chi tiết	Phỏng vấn đào sâu để làm rõ yêu cầu; xác nhận lại với bên liên quan; làm bản trực quan để giảm hiểu nhầm.
Có quá nhiều Stakeholder, mỗi bên có mục tiêu khác nhau và không có người chốt	Mục tiêu khác nhau	Đưa các bên vào cùng workshop để thống nhất ưu tiên; review yêu cầu với các bên liên quan; liên tục lấy phản hồi trong suốt quá trình thiết kế.
Yêu cầu phát sinh ngoài phạm vi quá nhiều (Scope Creep)	Scope không rõ ràng	Định nghĩa phạm vi rõ ràng và sớm; đánh mức độ ưu tiên yêu cầu; mọi thay đổi cần phân tích, phê duyệt, văn bản hóa trước khi đưa vào dự án chính thức.
Khoảng cách hiểu giữa Business và nhóm kỹ thuật quá lớn	Business và Technical khác “ngôn ngữ”	Viết tài liệu rõ ràng; mô hình hóa và trực quan hóa bằng luồng dữ liệu, wireframe; duy trì trao đổi liên tục để tránh hiểu ngầm.
Yêu cầu thay đổi liên tục trong quá trình thực hiện	Môi trường thay đổi	Chấp nhận thay đổi là tất yếu do thị trường, luật, khách hàng; quản lý yêu cầu, quản lý phiên bản và tuân thủ quy trình thay đổi.
Khách hàng không thực sự hiểu họ cần gì	Chưa hiểu vấn đề gốc	Liên tục quan sát, xác định nguyên nhân cốt lõi và phân tích Gap.

5. Góc nhìn thực tiễn cho Coden

Đối với mô hình tư vấn chuyển đổi số, Business Analyst không chỉ dừng ở việc thu thập yêu cầu. Chuyên viên phân tích cần dẫn dắt hành trình:

Vấn đề kinh doanh.
Phân tích tình trạng hiện tại.
Phân tích nguyên nhân gốc rễ (root cause).
Thu thập yêu cầu.
Thiết kế giải pháp.
Triển khai giải pháp.
Thu thập kết quả sau triển khai.

Điều cần tránh là chỉ ghi nhận những gì khách hàng yêu cầu. Cần hướng tới hiểu đúng vấn đề thực sự và giúp khách hàng tìm ra giải pháp phù hợp nhất.

—- Đỗ Xuân Phong —