--- title: "Vai trò và trách nhiệm chính của IT Business Analyst" url: "https://bahub.vn/khoa-hoc/ba-foundation/vai-tro-va-trach-nhiem-chinh-cua-it-business-analyst" author: "Hiển Nguyễn, Phan Minh Hoàng" published: "2026-08-14" updated: "2026-08-15" source: "bahub.vn" license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc." --- # Vai trò và trách nhiệm chính của IT Business Analyst > 10 vai trò cốt lõi của IT Business Analyst trong một dự án phần mềm, từ phân tích yêu cầu nghiệp vụ tới đánh giá hiệu quả giải pháp. - Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/vai-tro-va-trach-nhiem-chinh-cua-it-business-analyst - Tác giả: Hiển Nguyễn, Phan Minh Hoàng - Khoá học: BA Foundation (mục lục: https://bahub.vn/khoa-hoc/ba-foundation.md) - Chương: Nhập môn và định hướng nghề nghiệp Hỏi mười người làm IT Business Analyst xem hằng ngày họ làm gì, bạn sẽ nhận mười câu trả lời khác nhau — vì phần việc của BA co giãn theo quy mô đội và cách mỗi công ty chia vai. Bài này gom lại 10 nhóm việc mà một BA thường đụng tới trong dự án phần mềm. Không phải BA nào cũng làm đủ cả 10, và người mới vào nghề thường chỉ chạm được vài nhóm đầu. ## 1. Phân tích yêu cầu nghiệp vụ kinh doanh Vai trò đầu tiên của một BA là hiểu rõ nhu cầu nghiệp vụ kinh doanh: * **Thu thập thông tin từ nhiều nguồn**: BA làm việc trực tiếp với các bên liên quan (stakeholders) — từ quản lý, nhân viên đến khách hàng — qua phỏng vấn, khảo sát, hội thảo hoặc phân tích tài liệu như hợp đồng, báo cáo. * **Phân tích và làm rõ yêu cầu**: Sau khi thu thập, việc của BA là đào sâu bằng câu hỏi cho tới khi hết chỗ mơ hồ, tách được cái doanh nghiệp hoặc khách hàng **muốn** (want) ra khỏi cái họ **thật sự cần** (need). * **Đảm bảo khả thi**: Yêu cầu phải vừa phản ánh đúng mong muốn, vừa khả thi để tránh dự án đi sai hướng. Khả thi ở đây có hai mặt. Mặt nghiệp vụ — quy trình mới có chạy được với cách doanh nghiệp đang vận hành không, ai sẽ là người thao tác, có vướng quy định nào không — là phần BA phải tự trả lời. Mặt kỹ thuật thì BA không tự kết luận được, phải ngồi lại với dev hoặc kiến trúc sư hệ thống. Ví dụ về want và need: * **WANT**: "Tôi muốn một website bán hàng thật đẹp." Đây là mong muốn ban đầu, mang tính cảm quan, chưa đủ rõ để triển khai kỹ thuật. * **NEED**: Sau khi trao đổi, BA xác định nhu cầu thật sự là tăng doanh số bán hàng online. * **Giải pháp**: Thiết kế giao diện thu hút, dễ dùng, tối ưu mobile, tích hợp công cụ marketing (như Facebook Pixel), hỗ trợ quảng cáo và SEO. ## 2. Xây dựng tài liệu yêu cầu Dựa trên yêu cầu từ khách hàng và nội bộ doanh nghiệp, BA soạn hoặc góp phần soạn các tài liệu phục vụ quá trình phát triển phần mềm. Tên gọi và người chịu trách nhiệm thay đổi theo từng công ty — PRD chẳng hạn, ở nhiều nơi thuộc về Product Owner hoặc Product Manager chứ không phải BA: * **Business Requirement Document (BRD)**: mô tả mục tiêu và nhu cầu nghiệp vụ của doanh nghiệp. * **Product Requirement Document (PRD)**: tập trung vào các tính năng cụ thể cần xây dựng để đáp ứng yêu cầu. * **User Requirement Document (URD)**: tập trung vào nhu cầu của người dùng cuối hoặc các bên liên quan không chuyên về kỹ thuật. * **Software Requirements Specification (SRS)**: dành cho đội kỹ thuật. Tuỳ dự án và tuỳ công ty, danh sách này còn dài hơn nữa. ![BA soạn bộ tài liệu yêu cầu cho từng nhóm người đọc](https://bahub.vn/uploads/2026/08/1786801959251-8g17xx-vai-tro-va-trach-nhiem-chinh-cua-it-business-analy.webp "BA soạn bộ tài liệu yêu cầu cho từng nhóm người đọc") Viết tài liệu không dừng ở việc ghi lại yêu cầu: * **Dễ hiểu, trực quan**: Viết sao cho cả người không chuyên và đội kỹ thuật đều hiểu, kết hợp sơ đồ, bảng biểu để minh hoạ. Ví dụ: khi làm việc với một khách hàng không rành công nghệ, sơ đồ luồng người dùng (User Flow) giúp họ hình dung rõ ràng cách hệ thống hoạt động. * **Trình bày và giải đáp**: Giải thích chi tiết và trả lời mọi thắc mắc từ Dev, QC hay khách hàng. Có những buổi họp kéo dài 2–3 tiếng chỉ để làm rõ một yêu cầu nhỏ, nhưng đó là cách để đảm bảo không ai hiểu sai. * **Cập nhật liên tục**: Tài liệu luôn được điều chỉnh để phản ánh chính xác yêu cầu tại mọi thời điểm. ## 3. Đóng vai trò cầu nối BA đảm bảo thông tin được truyền đạt chính xác giữa các bên: * **Truyền đạt hai chiều**: Diễn giải yêu cầu kinh doanh sang ngôn ngữ kỹ thuật và ngược lại. * **Điều phối**: Tổ chức họp, workshop để các bên đồng thuận về mục tiêu. * **Giải quyết xung đột**: Tìm phương án dung hoà khi các bên không cùng quan điểm. Ví dụ: trong một dự án e-commerce, team kinh doanh đề xuất "Thêm tính năng gợi ý sản phẩm theo sở thích khách hàng". Dev phản đối vì cho rằng cần phân tích hành vi người dùng phức tạp, tốn thời gian. BA đứng ra phân tích dữ liệu đơn hàng và thấy 70% khách thường mua lại sản phẩm cũ, nên đề xuất một giải pháp đơn giản hơn: hiển thị mục "Mua lại gần đây" trên trang chủ. Nhờ vậy, yêu cầu được đáp ứng nhanh, khách dễ mua sắm hơn, dev cũng không phải làm hệ thống quá phức tạp. > Các con số trong những ví dụ ở bài này là giả định để minh hoạ cách BA dùng dữ liệu ra quyết định, không phải số liệu thật của một dự án cụ thể. ## 4. Phân tích quy trình — tối ưu hoá hiệu quả * **Nghiên cứu quy trình hiện hành**: BA tìm hiểu chi tiết cách doanh nghiệp vận hành, từ các bước thực hiện công việc hàng ngày đến cách xử lý dữ liệu, nhằm hiểu rõ thực trạng hoạt động. * **Xác định điểm cần cải tiến**: Phân tích để phát hiện các điểm kém hiệu quả, như thời gian chờ lâu hoặc bước thừa, đồng thời tìm kiếm cơ hội tối ưu hoá quy trình để tăng năng suất. * **Đề xuất cải tiến**: Đưa giải pháp giảm chi phí, tăng năng suất, tạo giá trị bền vững. ![Tối ưu quy trình: khách tự đặt món qua mã QR](https://bahub.vn/uploads/2026/08/1786802004954-ieynni-vai-tro-va-trach-nhiem-chinh-cua-it-business-analy.webp "Tối ưu quy trình: khách tự đặt món qua mã QR") **Ví dụ 1**: Tại một quán ăn, BA nhận thấy khách phải gọi nhân viên để order, gây chậm trễ và dễ sai sót. Sau khi phân tích, BA đề xuất triển khai menu điện tử bằng mã QR để khách tự quét và đặt món. Kết quả là giảm tải cho nhân viên, tăng tốc độ phục vụ và cải thiện trải nghiệm khách hàng. **Ví dụ 2**: Trong một công ty logistics, quy trình giao nhận còn nhiều bước thủ công, nhân viên phải nhập tay mã đơn hàng nhiều lần. BA phát hiện điểm này gây chậm trễ và dễ nhầm lẫn, đề xuất tích hợp hệ thống quét mã vạch và đồng bộ dữ liệu qua app. Kết quả là rút ngắn thời gian xử lý và giảm lỗi nhập liệu. ## 5. Quản lý yêu cầu * **Theo dõi và ghi nhận thay đổi**: Trong dự án, yêu cầu thường xuyên thay đổi, nên BA phải cập nhật lại trên tài liệu hoặc công cụ quản lý task. * **Đánh giá rủi ro kỹ lưỡng**: Mỗi thay đổi được phân tích về tác động đến tiến độ dự án và ảnh hưởng nghiệp vụ tới các tính năng khác, từ đó đưa ra giải pháp hợp lý. * **Sắp xếp độ ưu tiên**: Phân loại yêu cầu thành các mức độ quan trọng khác nhau, giúp đội ngũ tập trung vào những yếu tố cốt lõi trước, đảm bảo sản phẩm cuối cùng đáp ứng mục tiêu chính. ## 6. Hỗ trợ thiết kế * **Đề xuất luồng người dùng chi tiết**: BA đóng góp vào việc xây dựng cấu trúc luồng người dùng (User Flow), dựa trên hiểu biết sâu về nghiệp vụ để đảm bảo quá trình sử dụng hệ thống logic và liền mạch. * **Cải thiện UX**: Phối hợp với UI/UX để giao diện dễ dùng, thân thiện, dễ thao tác, phù hợp với đối tượng người dùng cuối. * **Tinh chỉnh thiết kế**: Xem xét mockup, prototype và đề xuất điều chỉnh nếu cần. Thiết kế không phải là nhiệm vụ chính của BA. Nhưng với góc nhìn nghiệp vụ và hiểu biết sâu về người dùng, BA có thể hỗ trợ đội ngũ thiết kế để đảm bảo sản phẩm phù hợp về cả chức năng lẫn trải nghiệm. ## 7. Hỗ trợ kiểm thử Bên cạnh phân tích và quản lý yêu cầu — hai nhiệm vụ cốt lõi — đôi khi BA cũng tham gia vào một số hoạt động hỗ trợ nhằm đảm bảo chất lượng đầu ra của sản phẩm: * **Hỗ trợ QC**: Viết checklist, test case cho các kịch bản kiểm thử. BA cũng có thể tham gia review chéo test case nhằm đảm bảo các trường hợp kiểm thử được bao phủ toàn diện. * **Tham gia UAT**: Làm việc trực tiếp với người dùng cuối để ghi nhận phản hồi, xác định lỗi và hỗ trợ xử lý kịp thời. * **Xác nhận**: Đảm bảo sản phẩm đáp ứng đầy đủ yêu cầu đã thống nhất ban đầu. ## 8. Hỗ trợ triển khai dự án — chuyển giao suôn sẻ * **Đào tạo người dùng cuối**: Tổ chức hướng dẫn, giúp người dùng làm quen hệ thống. * **Soạn tài liệu hỗ trợ**: Viết hướng dẫn sử dụng chi tiết, bao gồm các bước thao tác và câu trả lời cho thắc mắc phổ biến, giúp quá trình chuyển đổi diễn ra suôn sẻ. * **Giải quyết vấn đề phát sinh**: Trong giai đoạn đầu triển khai, BA hỗ trợ xử lý các sự cố kỹ thuật hoặc câu hỏi từ người dùng, phối hợp với đội kỹ thuật để khắc phục nhanh chóng. ![BA đào tạo người dùng cuối khi bàn giao hệ thống](https://bahub.vn/uploads/2026/08/1786802052976-up0di4-vai-tro-va-trach-nhiem-chinh-cua-it-business-analy.webp "BA đào tạo người dùng cuối khi bàn giao hệ thống") ## 9. Xây dựng chiến lược — nhìn xa trông rộng Tuỳ vào mô hình tổ chức và phạm vi công việc ở từng công ty, BA có thể tham gia vào một số hoạt động mang tính chiến lược, nhằm hỗ trợ doanh nghiệp phát triển bền vững và tối ưu vận hành: * **Phân tích dữ liệu chuyên sâu**: BA sử dụng dữ liệu từ hệ thống hoặc quy trình để đánh giá xu hướng, cung cấp thông tin chi tiết hỗ trợ quá trình ra quyết định của doanh nghiệp. * **Định hướng chiến lược dài hạn**: Tư vấn các kế hoạch phát triển bền vững, dựa trên nhu cầu hiện tại và dự đoán những thay đổi trong tương lai của tổ chức. * **Đề xuất cải tiến liên tục**: Ngoài dự án đang chạy, BA còn gợi ý những chỗ nên nâng cấp để giải pháp không lạc hậu sau vài năm. Ví dụ: trong dự án vận hành trung tâm chăm sóc khách hàng, BA nhận thấy nhân viên tốn quá nhiều thời gian trả lời các câu hỏi lặp lại. Sau khi phân tích dữ liệu chat và cuộc gọi, BA đề xuất tích hợp chatbot AI để tự động trả lời các câu hỏi phổ biến. Đồng thời, BA lập kế hoạch đánh giá hiệu quả sau ba tháng và đề xuất mở rộng chatbot ra các kênh khác như Zalo, Facebook. Nhờ đó nhân viên đỡ tải, và khách hàng được phản hồi nhanh hơn. ## 10. Đánh giá hiệu quả giải pháp Đánh giá xem giải pháp có thật sự giải quyết được vấn đề ban đầu hay không là việc của chính nghề BA — IIBA xếp Solution Evaluation thành một trong các nhóm kiến thức của business analysis, gồm đo hiệu suất, phân tích giá trị mang lại, tìm ra cái đang cản trở và đề xuất cách tăng giá trị. Ai là người chịu trách nhiệm cuối cùng thì tuỳ cách tổ chức phân vai: có nơi PO hoặc PM chốt, có nơi BA làm toàn bộ. Nhưng phần dưới đây thì BA gần như luôn có tay vào: * **Đo lường hiệu quả thực tế**: Sau khi kết thúc dự án, BA thu thập dữ liệu về hiệu suất hệ thống và phản hồi từ người dùng nhằm đánh giá mức độ thành công của giải pháp. * **Phân tích điểm mạnh và yếu**: Xem xét kỹ lưỡng những gì hoạt động tốt và những gì cần cải thiện, dựa trên các chỉ số cụ thể và trải nghiệm thực tế. * **Đề xuất tối ưu hoá**: Đưa ra các phương án điều chỉnh hoặc nâng cấp giải pháp, tập trung vào việc tăng giá trị lâu dài và giải quyết các vấn đề còn tồn đọng. ## Kết luận Nhìn lại 10 nhóm việc ở trên, hai nhóm đầu — phân tích yêu cầu và viết tài liệu — là phần không ai làm thay BA được. Những nhóm còn lại thì chia sẻ với PO, PM, QC hoặc designer, tỷ lệ tuỳ công ty. Đây cũng là lý do hai người cùng chức danh BA ở hai nơi có thể làm những việc rất khác nhau. Với người mới, điều đáng lưu ý là đừng nhìn danh sách này rồi nghĩ phải giỏi cả 10 mới xin được việc. Thực tế ngược lại: hầu hết vị trí Fresher và Junior chỉ yêu cầu nhóm 1, 2 và 3, cộng thêm khả năng hỏi đúng câu khi chưa hiểu vấn đề. Các nhóm còn lại đến dần theo dự án. --- Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/vai-tro-va-trach-nhiem-chinh-cua-it-business-analyst — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.