Bạn mở BABOK ra, đọc vài trang “Business Analysis Key Concepts”, rồi chợt nhận ra mình vừa đọc lại cùng một đoạn lần thứ ba mà vẫn không nhớ nó nói gì. Quen không?
Với mình còn thêm một cái khó nữa là tiếng Anh không tốt, mà BABOK lại viết bằng thứ tiếng Anh rất chuẩn mực, câu dài, mệnh đề lồng mệnh đề, đọc một trang phải tra từ liên tục thì buồn ngủ là chuyện đương nhiên. Mình đã thi CBAP xong, và cách mình đọc BABOK chẳng có gì thần kỳ, dưới đây là mấy thứ mình làm thật, cộng thêm vài điều theo mình là đáng thử.
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.
Giả sử bạn là giám đốc một nhà máy vừa và nhỏ, trên bàn có hai bảng chào giá, một bên bảo Cloud ERP rẻ hơn, triển khai nhanh, bên kia bảo On-premise mới an toàn, dữ liệu xưởng sao mà đưa lên mây được. Tin ai bây giờ? Theo mình câu trả lời chưa bao giờ gói gọn trong một từ.
cloud ERP, cái được và cái mất # Cloud ERP bán chạy vì không cần đầu tư ban đầu lớn, không mua server, không thuê IT, không lo bảo trì, vendor lo hết, và với nhà máy vừa và nhỏ ở Việt Nam thì đây là đường ngắn nhất để có ERP. Có điều theo mình nó có mấy cái bẫy.
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ó.
Mới đây ERP Today có bài phân tích khá hay về cuộc đua ERP ngành năng lượng giữa bốn ông lớn SAP, Oracle, IFS và Infor, đọc xong mình thấy có mấy điểm đáng nghĩ, nhất là với anh em đang tư vấn ERP cho nhà máy hay utility ở Việt Nam. Bài này không nhằm so xem ai tốt nhất, vì câu trả lời lúc nào cũng là tùy, mà để thấy mỗi ông có một góc tấn công riêng, và có cái khung đó trong đầu thì lúc chọn ERP mình đặt câu hỏi đúng hơn.
Data migration làm mình đau đầu nhất ở một chỗ nghe rất cơ bản, là không hiểu rõ thứ tự các loại data phải migrate, cái gì đi trước, cái gì đi sau, cái gì phụ thuộc cái gì, đổ sai thứ tự một cái là dữ liệu phía sau không còn chỗ mà bám. Theo mình đó cũng là lý do data migration không phải chuyện code với script, nó là chuyện hiểu dữ liệu, hiểu con người, hiểu quy trình, và hiểu cả những ô Excel tưởng vô hại.
