Một dự án có thể có đầy đủ Developer, Tester, Project Manager và hệ thống công nghệ phù hợp nhưng vẫn gặp vấn đề khi sản phẩm hoàn thành không đúng điều doanh nghiệp thực sự cần. Nguyên nhân đôi khi không nằm ở năng lực lập trình mà bắt đầu từ một câu hỏi đơn giản: doanh nghiệp đang giải quyết vấn đề gì và yêu cầu đó đã được hiểu đúng chưa?
Đây là khoảng trống mà Business Analyst (BA) thường tham gia để kết nối nhu cầu kinh doanh với giải pháp công nghệ.
Khi “yêu cầu rõ ràng” vẫn có thể dẫn đến một sản phẩm sai
Trong quá trình triển khai dự án, những yêu cầu như “xây dựng hệ thống quản lý khách hàng”, “tạo Dashboard cho phòng kinh doanh” hay “tự động hóa quy trình báo cáo” nghe có vẻ khá cụ thể.
Nhưng khi đi sâu hơn, doanh nghiệp sẽ phải trả lời hàng loạt câu hỏi:
Hệ thống đang giải quyết vấn đề nào? Ai thực sự sử dụng? Quy trình hiện tại đang gặp điểm nghẽn ở đâu? Dữ liệu được lấy từ đâu? Điều kiện nào được xem là một khách hàng hợp lệ? Dashboard phục vụ quyết định nào? Nếu thay đổi quy trình thì bộ phận nào bị ảnh hưởng?
Nếu những câu hỏi này chưa được làm rõ, Developer có thể hoàn thành đúng những gì được yêu cầu nhưng sản phẩm cuối cùng vẫn không giải quyết đúng vấn đề ban đầu.
Vì vậy, vấn đề của dự án không phải lúc nào cũng là “lập trình sai”, mà có thể bắt đầu từ “xác định sai hoặc hiểu chưa đầy đủ bài toán”.
Business Analyst đứng ở đâu trong quá trình này?
Business Analyst đóng vai trò phân tích nhu cầu, làm rõ vấn đề và chuyển hóa nhu cầu kinh doanh thành những yêu cầu mà đội ngũ triển khai có thể hiểu và thực hiện.
BA không đơn thuần là người “viết tài liệu yêu cầu”.
Một BA cần làm việc với nhiều nhóm khác nhau: lãnh đạo, phòng nghiệp vụ, người dùng cuối, Project Manager, Developer, Tester và các bên liên quan khác.
Mỗi nhóm nhìn dự án từ một góc độ khác nhau.
Ban lãnh đạo quan tâm đến hiệu quả đầu tư. Người dùng quan tâm đến quy trình làm việc. Developer quan tâm đến yêu cầu có thể triển khai. Tester cần biết hệ thống phải hoạt động như thế nào để kiểm thử.
BA giúp những góc nhìn này được đưa về cùng một bài toán.
Từ yêu cầu của phòng ban đến bài toán có thể triển khai
Giả sử phòng kinh doanh đề xuất:
“Cần một hệ thống CRM để quản lý khách hàng tốt hơn.”
Nếu chỉ ghi lại câu này và chuyển cho đội kỹ thuật, thông tin vẫn còn quá rộng.
BA cần tiếp tục tìm hiểu: doanh nghiệp đang quản lý khách hàng bằng Excel hay hệ thống nào khác? Nhân viên kinh doanh đang gặp khó khăn ở bước nào? Những thông tin nào cần được lưu trữ? Ai được quyền xem và chỉnh sửa? Khi một khách hàng chuyển trạng thái thì điều gì xảy ra tiếp theo? Nhà quản lý cần theo dõi chỉ số nào?
Từ đó, yêu cầu ban đầu có thể được phân rã thành quy trình, business rules, functional requirements, user stories, use cases hoặc các tài liệu phù hợp với phương pháp triển khai của dự án.
Đây chính là quá trình biến một nhu cầu kinh doanh còn mơ hồ thành yêu cầu có thể phân tích, xây dựng và kiểm thử.
BA giúp giảm khoảng cách giữa Business và IT
Một trong những khó khăn phổ biến của dự án công nghệ là mỗi bên sử dụng một cách diễn đạt khác nhau.
Business nói về mục tiêu và quy trình.
IT nói về hệ thống, dữ liệu và giải pháp.
Nếu không có bước phân tích ở giữa, cùng một yêu cầu có thể được hiểu theo nhiều cách.
BA cần đặt câu hỏi, xác nhận lại yêu cầu, mô hình hóa quy trình và làm rõ các trường hợp ngoại lệ trước khi yêu cầu được đưa vào triển khai.
Điều này đặc biệt quan trọng với những dự án có nhiều phòng ban tham gia hoặc quy trình nghiệp vụ phức tạp.
BA không chỉ xuất hiện khi doanh nghiệp làm phần mềm
Nhu cầu phân tích nghiệp vụ không chỉ tồn tại trong các dự án phát triển phần mềm.
Khi doanh nghiệp triển khai ERP, CRM, Data Warehouse, Dashboard quản trị, tự động hóa quy trình hoặc ứng dụng AI vào vận hành, vẫn cần xác định rõ vấn đề kinh doanh, quy trình hiện tại, yêu cầu dữ liệu và tiêu chí đánh giá kết quả.
Chẳng hạn, một doanh nghiệp muốn dùng AI để tự động xử lý yêu cầu khách hàng.
Câu hỏi đầu tiên không nên là “dùng mô hình AI nào?”, mà cần bắt đầu từ quy trình: yêu cầu nào đang được xử lý thủ công, dữ liệu đầu vào là gì, trường hợp nào AI có thể xử lý, trường hợp nào phải chuyển cho nhân viên và kết quả được đánh giá bằng tiêu chí nào.
Đó cũng là tư duy phân tích nghiệp vụ.
Doanh nghiệp cần đào tạo Business Analyst theo bài toán thực tế
Một chương trình đào tạo Business Analyst cho doanh nghiệp không nên chỉ tập trung vào thuật ngữ, tài liệu hay công cụ.
Nhân sự cần được đặt vào những tình huống gần với công việc thực tế: thu thập và phân tích yêu cầu, stakeholder analysis, mô hình hóa quy trình, xác định business rules, viết requirement, user story, use case và phối hợp với đội ngũ phát triển.
Quan trọng hơn, chương trình cần gắn với lĩnh vực và quy trình mà doanh nghiệp đang vận hành.
Một BA làm trong ngân hàng sẽ gặp những bài toán khác với BA trong thương mại điện tử, sản xuất hay doanh nghiệp công nghệ.
Khi nào doanh nghiệp nên quan tâm đến năng lực BA?
Nếu dự án thường xuyên thay đổi yêu cầu, các phòng ban hiểu sản phẩm theo những cách khác nhau, Developer phải làm lại nhiều lần hoặc sản phẩm hoàn thành nhưng người dùng vẫn không sử dụng như kỳ vọng, doanh nghiệp nên xem lại năng lực phân tích nghiệp vụ trong quy trình triển khai.
Đôi khi vấn đề không cần thêm người lập trình mà cần làm rõ bài toán trước khi bắt đầu lập trình.
Tại Cole, chương trình đào tạo Business Analyst cho doanh nghiệp có thể được thiết kế theo bài toán, quy trình và nhu cầu năng lực thực tế của từng tổ chức, thay vì áp dụng một chương trình giống nhau cho mọi doanh nghiệp.
