Trả lời ngắn: BA không bắt buộc phải biết SQL, nhưng nên biết ở mức SELECT, JOIN, GROUP BY, mức đó đủ để tự trả lời phần lớn câu hỏi dạng bao nhiêu, mấy cái, theo từng tháng, và đủ để kiểm tra requirement với dữ liệu thật, không cần học tới mức developer.
Thử hình dung cuộc họp với phòng kinh doanh, trưởng phòng hỏi tháng trước có bao nhiêu đơn bị khách trả lại, chủ yếu là sản phẩm nào, bạn hứa sẽ gửi số, về chỗ nhắn dev nhờ lấy, dev đang chạy deadline nên ba ngày sau mới có file, mà tới lúc đó câu hỏi đã đổi, cuộc họp tiếp theo cũng đã diễn ra rồi. Tình huống kiểu này là lý do nhiều BA bắt đầu học SQL, và câu hỏi là học tới đâu thì vừa, để khỏi mất cả năm cày khóa database.
Có lần mình đi công tác xa để hỗ trợ kiểm kê, 4h chiều mới có file kiểm đếm, upload dữ liệu lên hệ thống mất thêm vài tiếng, thế là kế toán, kỹ thuật và mình ở lại tới 1h đêm mới xong, giữa chừng có phát sinh vài vấn đề nhưng rồi cũng xử lý được hết. Go-live nghe thì oách, chứ thật ra nó là lúc mọi thứ mình tin là đã chuẩn bị xong bị đem ra thử thật.
Lần đầu đi phỏng vấn BA, mình bị hỏi một câu tưởng dễ, em kể một lần em làm việc với stakeholder khó tính đi, thế là ngồi im mấy giây rồi lắp bắp vài câu chung chung kiểu em luôn lắng nghe, em kiên nhẫn, về nhà mới tiếc, chuyện thật thì đầy mà không biết kể sao cho ra hồn.
Đi vài vòng mình mới ngộ ra, nhà tuyển dụng không hỏi định nghĩa để chấm điểm thuộc bài, họ hỏi tình huống để xem em xử lý thật thế nào, mà fresher thì chưa có nhiều dự án để khoe, nên cách kể mới là thứ quyết định.
Lần đầu xuống xưởng, mình mang theo trong đầu nguyên cái quy trình đã đọc trên giấy, công đoạn nào xong thì cập nhật ngay, rõ ràng, đẹp đẽ, rồi đứng nhìn một lúc mới thấy dưới này người ta làm khác hẳn. Công nhân xử lý một mạch từ đầu tới cuối, cuối ngày mới ngồi viết vào biên bản. Khác xa luôn.
Mà nghĩ kỹ thì cũng chẳng ai sai. Quy trình trên giấy được viết cho người ngồi văn phòng đọc, còn công nhân thì làm theo cách nào kịp hàng nhất. Từ hôm đó mình tin là muốn lấy requirement thật cho ERP hay MES thì phải xuống xưởng, chứ ngồi phòng họp nghe người ta kể lại thì chỉ được một nửa câu chuyện.
Giả sử có bạn nhắn hỏi mình, anh ơi em làm BA được hơn một năm rồi, bao lâu thì lên senior được? Theo mình câu trả lời tốt nhất là hỏi ngược lại, em đã tự chịu trách nhiệm với một requirement nào chưa, hay mới làm theo bàn giao, vì lên senior nằm ở câu đó nhiều hơn là ở số năm. Nên bài này mình không viết kiểu cứ đủ 5 năm là tự động lên senior, số năm tự nó chẳng nói lên điều gì, dưới đây chỉ là cách mình nhìn cái lộ trình này.
Giả sử bạn mở một file spec ra, toàn những câu kiểu “Hệ thống cho phép người dùng thêm sản phẩm vào giỏ hàng”, đọc lướt thì tưởng đúng, nhưng hỏi lại một câu thêm vào giỏ để làm gì thì chưa chắc người viết trả lời được. Theo mình user story hay bị viết bừa ở đúng phần “để làm gì”, viết đủ là ai, muốn chức năng gì, còn mục đích thì chỉ là giả định với đoán mò.
Bấm nộp bài xong, mình ngồi nhìn màn hình và nghĩ chắc chắn là trượt rồi, vì còn một đống câu đang cắm cờ flag, mấy câu đề dài như đoạn văn tiếng Anh, và kha khá câu mình chọn theo kiểu loại trừ, cái nào nghe đúng nhất thì bấm. Rồi màn hình hiện chữ: đỗ. Mình ngồi đó chưa kịp phản ứng gì, vì đầu vẫn đang chuẩn bị tinh thần cho điều ngược lại.
Giả sử bạn ngồi với CFO của một nhà máy ngay sau buổi nghiệm thu phase 1 ERP, anh ấy kể tồn kho giờ real-time, báo cáo tài chính ra nhanh hơn, sếp họp có số để chốt, nghe xuôi lắm, rồi bạn hỏi vậy AP giờ chạy trên hệ thống luôn chưa anh. Rất có thể câu trả lời là AP thì… kế toán vẫn gõ Excel, cuối tháng mới nhập tay lên ERP. ERP đắt tiền, mà dòng tiền ra, thứ ngốn nhiều nhất, vẫn nằm ngoài hệ thống.
Bạn hẹn họp, họ báo bận, hẹn lại, lại bận, đến lần thứ ba thì bắt đầu tự hỏi họ bận thật hay là không muốn dính vào. Mình gặp kiểu stakeholder này rồi, cứ báo bận, tìm đủ cách để không tham gia dự án, và lý do sâu xa không phải họ ghét ai, mà là họ không thích phải thay đổi.
Nó cũng giống mấy cú sốc mình kể trong bài BA mới vào nghề: 5 cú sốc không ai nói trước, stakeholder không hợp tác chẳng phải chuyện hy hữu gì, nó là chuyện thường ngày của nghề.
Tuần trước mình ngồi cà phê với một anh giám đốc nhà máy, ảnh hào hứng khoe sắp tới tụi anh mua AI về chạy scheduling với dự báo đơn hàng, khỏi cần planner ngồi chỉnh tay từng đơn nữa. Mình hỏi đúng một câu, dữ liệu BOM với lead time trên ERP của anh giờ chuẩn hết chưa? Ảnh im một hồi rồi bảo, thì… cũng tàm tạm.
Đó. Mình không anti-AI, nhưng sau mấy năm đi triển khai ERP với làm BA, mình thấy một pattern lặp đi lặp lại, doanh nghiệp muốn AI, mà cái nền để AI chạy lên thì đang là một mớ hỗn độn. Robert Kramer, managing partner của KramerERP, vừa viết một bài trên ERP Today gãi đúng chỗ ngứa này: AI không làm hệ thống thông minh hơn, nó phơi bày những điểm yếu vốn có, dữ liệu yếu, quy trình rời rạc, ownership mập mờ. Đây không phải chuyện công nghệ, mà là chuyện operating model.
