Dev báo bug, hỏi chỗ này hồi đó chốt thế nào anh, và bạn mở máy ra tìm mà không thấy gì, không phải vì tài liệu bị xóa, mà vì nó chưa bao giờ được viết, lúc triển khai mọi thứ toàn nói miệng trong họp hoặc gõ vội qua tin nhắn. Bài này mình viết từ chính mấy lỗi documentation mình đã mắc, chứ không phải từ sách.
Giả sử bạn gửi khách một wireframe xám để chốt luồng màn hình đề nghị mua hàng, và phản hồi đầu tiên là giao diện thế này người dùng không chịu đâu, đổi sang màu logo công ty nhé, thế là cả buổi họp sau đó bàn màu, còn câu bạn cần chốt là duyệt xong thì đề nghị đi đâu thì chẳng ai trả lời. Chuyện này dễ xảy ra khi hai bên chưa thống nhất đang xem loại bản vẽ nào, vì wireframe, mockup và prototype trả lời ba câu hỏi khác nhau, mà BA thường chỉ cần sở hữu một.
Phỏng vấn hỏi use case và user story khác nhau thế nào thì bạn trả lời bằng định nghĩa hay bằng một ví dụ, nhiều ứng viên chọn định nghĩa, và câu trả lời của ai nghe cũng giống hệt nhau. Cách thuyết phục hơn là viết cùng một chức năng theo cả hai kiểu, rồi chỉ ra lúc nào kiểu nào giúp dự án đỡ cãi nhau.
hai định nghĩa trong hai câu # User story là một câu mô tả ngắn nhu cầu của một vai trò, theo mẫu quen thuộc As a [vai trò], I want [điều gì], so that [lợi ích], nó thiên về câu hỏi tại sao. Use case là một đặc tả chi tiết cách một actor tương tác với hệ thống để đạt một mục tiêu, nó thiên về câu hỏi chạy thế nào.
Nhiều đợt UAT trong dự án ERP hỏng từ trước khi ai bấm nút đầu tiên, kịch bản viết theo màn hình, dữ liệu test toàn abc, chẳng ai thống nhất thế nào là đạt, tới tuần test thì key user bận, lỗi nào cũng bị ném vào một sheet chung, và buổi sign-off thành buổi cãi nhau. Nếu bạn là BA được giao chuẩn bị UAT, phần lớn việc của bạn nằm ở trước tuần test.
Nếu ngày mai bạn thôi viết user story mà bắt đầu ngồi cãi với kế toán trưởng về cách ghi nhận công nợ, bạn có chịu nổi một tháng không, theo mình câu đó quan trọng hơn con số lương trên tin tuyển ERP Functional Consultant. BA phần mềm với tư vấn ERP dùng chung nhiều kỹ năng, nhưng một ngày làm việc thì khác nhau khá xa.
ERP functional consultant làm gì mỗi ngày # ERP functional consultant giúp doanh nghiệp triển khai một hệ thống ERP có sẵn như SAP, Oracle hay IFS Cloud sao cho khớp cách công ty vận hành, bạn không xây phần mềm mới mà map quy trình nghiệp vụ vào sản phẩm, rồi cấu hình sản phẩm cho đúng.
Giả sử bạn viết xong mọi yêu cầu chức năng cho màn hình báo cáo tồn kho, chạy test ngon lành, ai cũng khen, rồi tới ngày go-live dữ liệu thật đổ vào mấy chục nghìn dòng, báo cáo mất hơn một phút mới load xong, khách đứng bên cạnh nhìn bạn. Đó là lúc bạn nhận ra mình đã quên một thứ tên là non-functional requirement, yêu cầu phi chức năng.
Mình không tin mấy con số lương trung bình BA trôi nổi trên mạng, vì chẳng ai ghi rõ nó lấy từ đâu, nên bài này làm cách khác, đọc thẳng tin tuyển dụng, chỉ lấy con số có ghi trong tin, kèm link để bạn tự kiểm. Giới hạn nói rõ từ đầu là mẫu nhỏ, chủ yếu ở Hà Nội, đọc vào tháng 10/2026, đây là một bức ảnh chụp chứ không phải khảo sát thị trường.
Trả lời ngắn: Theo trang chính thức của IFS, IFS Cloud là nền tảng gộp ERP, quản lý tài sản (EAM), chuỗi cung ứng (SCM) và dịch vụ hiện trường (FSM) cho doanh nghiệp công nghiệp. BA trong dự án IFS Cloud khảo sát quy trình, làm fit-gap, chuyển yêu cầu thành đặc tả cấu hình rõ ràng, rồi hỗ trợ UAT và đào tạo người dùng.
Giả sử bạn là BA vừa bị điều vào một dự án IFS Cloud, tuần đầu tài liệu toàn thuật ngữ lạ, họp buổi nào cũng nghe release, lobby, configuration, và câu đầu tiên trong đầu là mình phải biết gì về IFS Cloud, việc của mình bắt đầu từ đâu.
Có lần mình làm một hệ thống chia lệnh sản xuất tự động, hệ thống đã tự tính hết rồi, vậy mà khách vẫn muốn giữ file Excel cũ, tự nhập tự điền như trước, vì quen và vì tiện lưu trữ. Nói thẳng thì việc đó không còn cần nữa, nhưng gốc của nó không phải lười đổi thói quen, họ sợ hệ thống tính nhầm, một nỗi lo rất tự nhiên.
Lỗi hay gặp của BA mới với ERD là lướt qua luôn, coi đó là việc của dev, mà hậu quả thì tới muộn, viết yêu cầu xem lịch sử mua hàng của khách mà không biết dữ liệu nằm ở bảng nào, nên chẳng hỏi được mấy câu quan trọng kiểu một khách có thể có mấy địa chỉ giao hàng. Đọc ERD ở mức BA không cần biết code, chỉ cần bốn bước và một ví dụ.
