Khi Business Analyst Phải “Giải Mã” Quy Trình Hóa Đơn Trong Im Lặng

Bài viết được phân tích từ Case Study: Waterfall Approach – Invoice Process Restructure. How Do I Identify What Needs to Be Done by Ryland Leyton

Làm Business Analysis không phải lúc nào cũng có đầy đủ thông tin, thời gian dư dả hay stakeholder hợp tác cởi mở. Có những dự án diễn ra trong bối cảnh nhạy cảm, giới hạn người tham gia, áp lực thời gian cao và kết quả phân tích phải đủ chắc để phục vụ quyết định chiến lược.

Case study Invoice Process Restructure là một ví dụ điển hình cho kiểu dự án đó, nơi BA buộc phải phân tích quy trình trong “im lặng”, áp dụng Waterfall Approach và BACCM để dẫn dắt bài toán đến hồi kết rõ ràng.

Bối cảnh dự án và bài toán tuyệt mật

Morwin Company đang tái cơ cấu để tiết kiệm chi phí. Một văn phòng xử lý hóa đơn ở xa bị đưa vào cân nhắc đóng cửa, và toàn bộ nhân viên ở đó có thể sẽ bị cho nghỉ – ngoại trừ Susan, người duy nhất hiểu rõ toàn bộ quy trình.

Đáng nói hơn:

• Dự án phải tiến hành âm thầm, tuyệt đối không được để nhân sự văn phòng cũ biết.
• BA chỉ được làm việc với 1 stakeholder duy nhất (Susan).
• Công ty chưa chắc chắn sẽ đóng văn phòng → phân tích cần làm nhanh để lãnh đạo quyết định.

Mục tiêu: hiểu toàn bộ quy trình để xem HQ có thể tiếp nhận hoặc tự động hóa phần nào hay không.

Đây là tình huống điển hình khi BA phải làm việc trong bối cảnh nhạy cảm, hạn chế thông tin, nhưng kết quả phải đủ chi tiết để phục vụ quyết định chiến lược.

Định hình vấn đề bằng BACCM

Trước khi đi vào phân tích chi tiết, BA sử dụng BACCM để xác định rõ bức tranh tổng thể. Đây là bước giúp dự án không bị trôi vào phân tích lan man trong bối cảnh thông tin hạn chế.

Change

• Chuyển toàn bộ quy trình sang văn phòng chính.
• Có thể tự động hóa một phần.

Need

• Người mới phải thực hiện được quy trình.
• Tech team cần đủ thông tin để đánh giá automation.
• Billing Director cần dữ liệu để tính chi phí – rủi ro.

Stakeholders

• HQ Billing Director (James)
• Tech SME (Barbara)
• PM (John)
• SME duy nhất: Susan
• Nhân sự sẽ tiếp nhận công việc sau này

Value

• Tiết kiệm chi phí, tinh gọn bộ máy

Context

• Mọi thứ phải giữ bí mật.
• Tâm lý nhân sự rất nhạy cảm.
• Điều quan trọng ở đây: BA không vội nhảy vào vẽ quy trình, mà phải hiểu “vì sao dự án tồn tại”, “ai đang bị ảnh hưởng”, và “mình cần tạo ra giá trị gì”.

Lý do Waterfall là lựa chọn phù hợp

Với nhiều người, Waterfall thường bị xem là cứng nhắc. Tuy nhiên, trong bối cảnh này, Waterfall lại là lựa chọn hợp lý nhất.

Dự án có phạm vi rõ ràng: mô tả và hiểu quy trình hiện tại.
Stakeholder hạn chế, không phù hợp iterative dài hơi.
Kết quả cần độ chính xác cao để phục vụ quyết định chiến lược.

BA trình bày kế hoạch tiếp cận rất rõ ràng với lãnh đạo, bao gồm cả phạm vi và deliverable ngay từ đầu.

Các giai đoạn phân tích chính

1. Làm rõ Happy Path từ đầu đến cuối
2. Ghi nhận các lỗi (exceptions) và cách xử lý
3. Lập catalog: hệ thống – công cụ – dữ liệu – vai trò
4. Thu thập đề xuất cải tiến từ Susan
5. Xác thực toàn bộ với team HQ

Các deliverable

• Process Diagram (happy path)
• Process Diagram (exceptions)
• Danh mục hệ thống & công cụ
• Danh mục role/skillset liên quan
• ERD hoặc catalog dữ liệu chính
• Ghi nhận đề xuất cải tiến

Đây cũng là bộ deliverable chuẩn mực cho mọi dự án chuyển giao quy trình.

Thách thức lớn nhất: một SME và thời gian cực ngắn

Ban đầu BA nghĩ mình cần 3 ngày làm việc liên tục với Susan.

Nhưng vấn đề:

• Văn phòng của Susan quá nhỏ → không có nơi để trao đổi bí mật.
• Công việc của cô quá bận → không thể dành 3 ngày liên tục.
• Dự án nhạy cảm → không thể họp từ xa tại văn phòng.

Cuối cùng, HQ quyết định cho Susan bay sang văn phòng chính một tuần.

Tác giả sẽ

• Sáng: làm việc từ xa quản lý team của mình
• Chiều: dành 4 giờ mỗi ngày cho BA

BA ngay lập tức xây dựng phân tích theo chu trình:

Phỏng vấn → chỉnh sửa → xác thực → phỏng vấn tiếp → chỉnh sửa → xác thực

Đây là mô hình cực kỳ hiệu quả trong những dự án có nhiều quy trình phức tạp nhưng ít tài liệu.

Kế hoạch phân tích chi tiết theo Waterfall

BA xây dựng kế hoạch 10 ngày rất chặt chẽ, chia thành hai giai đoạn.

Tuần 1 (với Susan trực tiếp):

• Ngày 1: Happy Path
• Ngày 2: Error Paths
• Ngày 3: Review – refine
• Ngày 4: Chốt tài liệu + catalog hệ thống/dữ liệu
• Ngày 5: Dự phòng

Tuần 2 (với stakeholders HQ):

• Ngày 6–7: Trình bày & trả lời Q&A
• Ngày 8: Finalize tài liệu
• Ngày 9–10: Dự phòng

Cách làm việc này cho thấy một điều BA cần ghi nhớ:

“Không phải lúc nào bạn cũng có quyền kiểm soát bối cảnh, nhưng bạn luôn có thể kiểm soát cách tiếp cận.”

Kết quả phân tích và quyết định cuối cùng

Sau khi phân tích xong, HQ nhận thấy:

• Con người: có thể tiếp nhận quy trình
• Nhưng hệ thống và dữ liệu: quá khác biệt, quá phức tạp
• Việc đào tạo HQ dùng hệ thống mới → tốn thời gian & rủi ro cao

Kết luận:

Chi phí chuyển giao > Chi phí duy trì quy trình cũ.

→ Dự án dừng lại.

Một điểm thú vị:

Susan – người chịu áp lực lớn nhất – lại chính là người được đánh giá cao và được thăng chức & chuyển về HQ.

Những bài học thực tế cho Business Analyst

1. Không có bối cảnh nào quá khó – chỉ có cách tiếp cận chưa đúng

Dù thông tin hạn chế, BA vẫn xây được phương pháp rõ ràng.

2. BACCM là “kim chỉ nam” khi dự án mơ hồ

Nó giúp định hình giá trị, phạm vi, stakeholder và nhu cầu thật sự.

3. Một SME giỏi quan trọng hơn mười cuộc họp

Susan là chìa khóa giúp dự án sáng tỏ.

4. Trong dự án nhạy cảm, BA cần EQ nhiều như IQ

giữ bí mật

thấu hiểu tâm lý stakeholder

giao tiếp tế nhị

5. Deliverable chất lượng = ra quyết định chất lượng

Dù dự án dừng lại, tài liệu BA tạo ra giúp lãnh đạo đưa ra quyết định đúng.

Kết luận

Case study này không chỉ dạy BA cách phân tích quy trình theo Waterfall, mà còn dạy cách làm BA trong điều kiện nhạy cảm, giới hạn thông tin, áp lực thời gian, stakeholder tối thiểu.

Nó nhắc chúng ta rằng:

Công việc của BA không chỉ là tạo diagram – mà là giúp doanh nghiệp ra quyết định tốt hơn.

Nếu bạn đang làm BA, hoặc đang học để trở thành BA, đây là một ví dụ kinh điển về việc tư duy phân tích có thể tạo ra giá trị ngay cả khi dự án… dừng lại.