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.
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.
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 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ử 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.
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.
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.
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.
