Tháng thứ 9 của dự án, requirement đã chốt, solution design đã duyệt, dev đang chạy full sprint, mọi thứ đi đúng lộ trình, rồi vendor publish roadmap, và trong danh sách tính năng mới có một feature standard làm y chang cái mà team đã bỏ mấy tháng thiết kế custom. Cả phòng im lặng, rồi ai đó hỏi, vậy giờ làm sao?
Mình đã ngồi đúng khoảnh khắc đó hai lần. Lần đầu mình im, vì chưa biết nên nói gì, lần thứ hai mình mở miệng, không phải để trả lời mà để hỏi.
Trả lời ngắn: làm BA không cần viết code sản phẩm, nhưng nên đọc được SQL, tài liệu API và luồng dữ liệu, mức đó đủ để bạn tự kiểm tra requirement với dữ liệu thật và nói chuyện thẳng với dev, thay vì chuyển lời qua lại.
Hỏi ba nhà tuyển dụng câu “BA có cần biết code không” thì bạn có thể nhận về ba câu trả lời khác nhau, chỗ này bảo chỉ cần hiểu nghiệp vụ, chỗ kia hỏi SQL, chỗ khác lại đưa một đoạn JSON rồi hỏi thiếu trường gì. Người mới nghe xong rất dễ hoang mang, nhưng thật ra ba câu đó không mâu thuẫn nhau, chúng chỉ phản ánh ba kiểu dự án khác nhau. Câu trả lời của mình là BA cần biết đọc, chưa cần biết viết, còn đọc cái gì và đến mức nào thì ở phần dưới.
Giả sử bạn ngồi trong một cuộc họp chỉ để chốt một câu tưởng đơn giản, cột này để mấy số thập phân, dev bảo ít là đủ, user muốn nhiều hơn vì sợ sai số làm tròn, cuối cùng cả phòng gật đầu để nhiều cho chắc rồi ai về nhà nấy, không ai ghi lại đã chốt gì và vì sao. Một quyết định nhỏ như thế, nhân lên hàng trăm lần trong một dự án ERP, là decision debt.
Hợp đồng ghi đúng ba chữ “module mua hàng”, nghe thì rõ, nhưng module mua hàng 5 input với module mua hàng 15 input là hai thứ rất khác nhau, mà hợp đồng thì không nói là cái nào.
Đây là chuyện mình gặp thật. Phạm vi không được ghi rõ nên change request cứ tới liên tục, scope cứ thế phình ra, và mình không có cách nào từ chối khách, vì chẳng có tờ giấy nào nói cái gì nằm ngoài phạm vi. Scope creep, cái thuật ngữ nghe rất chuyên nghiệp ấy, thực chất là chuyện những cái “thêm tí nữa” không bao giờ dừng, và nó không chỉ là vấn đề của BA mà của cả team, cả dự án, cả cái deadline.
Tuần trước mình đọc một bài khá hay trên ERP Today của Sridevi Mutyala bên Oracle, nói về identity governance trong cloud ERP. Bài kể một chuyện tưởng đơn giản, một nhân viên chuyển phòng ban, HR update xong, mấy ứng dụng cloud ERP như Oracle Fusion, SAP S/4HANA, Dynamics 365 đều chạy đúng config, authentication OK, provisioning OK, integration OK, vậy mà quyền truy cập vẫn bị delay, vì approval paths mỗi ứng dụng một kiểu, role definitions không đồng bộ, còn quyết định cấp quyền thì không ai nhớ rõ là của ai. Chuyện ấy quen không? Với mình thì quen lắm.
Tuần rồi mình đọc được hai case study trên ERP Today mà ngồi nghĩ cả buổi tối, một bài về ngành dược đang chạy SAP S/4HANA migration nhưng mối quan tâm số một lại không phải AI, một bài về Defense Logistics Agency (DLA) của Mỹ, nơi audit readiness mới là động lực chính cho ERP modernization. Một bên thuốc men, một bên vũ khí, khác nhau hoàn toàn, mà chung một câu chuyện là AI không cứu được bạn nếu integration với governance chưa có.
Giả sử bạn đang họp với một anh trưởng phòng, anh ấy mở ra cái file Excel đã dùng nhiều năm, ô xanh ô đỏ loạn xạ, VLOOKUP chồng lên VLOOKUP, rồi nhẹ nhàng bảo “em ơi, làm giống cái này nhé, đơn giản thôi”. Bạn cười, trong lòng thì không cười nổi.
Chưa nghe câu đó bao giờ thì chắc bạn chưa làm BA cho dự án chuyển đổi số ở Việt Nam, còn nghe rồi thì chắc bạn hiểu cái cảm giác vừa buồn cười vừa bất lực ấy.
Người ta hay hỏi nhau “bên đó chạy ERP gì”, như thể chọn đúng phần mềm là xong một nửa dự án, nhưng càng làm mình càng thấy câu hỏi đó đặt sai chỗ, vì hai nhà máy chạy cùng một hệ thống vẫn có thể một bên trơn tru, một bên ngày nào cũng ngồi đối chiếu Excel. Khác nhau ở dữ liệu.
không phải ERP gì, mà dữ liệu có chạy xuyên không # Giả sử một nhà máy có ERP, có MES, có hệ thống kho, nhưng mỗi hệ thống là một ốc đảo, dữ liệu từ PLM sang ERP phải export Excel, từ ERP sang MES lại import bằng tay, mỗi lần đổi cấu hình sản phẩm là một đợt đối chiếu mệt nghỉ. Theo mình, cảnh này không hiếm ở nhà máy Việt. Ai cũng biết dữ liệu quan trọng, nhưng nối được một mạch từ khâu thiết kế đến khâu vận hành thì không nhiều nơi làm được, và phần mềm có xịn đến đâu mà dữ liệu đi bộ qua tay người thì cũng chỉ nhanh bằng người gõ.
Khách nói họ cần cả một đống màn hình quản lý ở nhiều module, mình hì hục đào mãi mới vỡ ra là thứ họ thật sự cần chỉ là một cái dashboard. Sốc nhẹ.
Đó là một trong những cú sốc đầu tiên của mình với nghề BA, và nó chẳng có trong giáo trình nào mình từng đọc. Bài này gom lại mấy cú sốc mà BA mới vào nghề hay va phải, trong đó hai cú đầu là chuyện thật của mình, còn ba cú sau là quan điểm của mình về những gì người trong nghề hay gặp.
Mình mở blog này vì một lý do khá ích kỷ, là viết ra thì mới biết mình hiểu đến đâu. Mấy năm đi làm, có những thứ mình cứ tưởng là hiểu rồi, đến lúc ngồi gõ lại thành câu cho người khác đọc mới lòi ra chỗ nào mình còn mơ hồ, nên blog này về cơ bản là cái bàn nháp của mình. Nháp công khai.
mình là ai # Mình là Đức Quân, nghề chính là Business Analyst, chuyên triển khai ERP và quản lý chuỗi cung ứng (SCM) trong các nhà máy sản xuất. Việc hằng ngày xoay quanh IFS Cloud, từ procurement, inventory đến manufacturing, cộng thêm mấy dự án ERP tự viết. Mình có chứng chỉ CBAP của IIBA, nhưng thứ giúp mình làm được việc không phải mấy chữ cái đó, mà là những buổi chiều đứng dưới xưởng nghe quản đốc chửi hệ thống.
