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.
Một chu kỳ triển khai thường đi qua workshop khảo sát với mua hàng, kế toán, kho, xưởng, rồi fit-gap xem chỗ nào sản phẩm đáp ứng sẵn, cấu hình tham số, luồng duyệt, danh mục, viết FSD (functional specification document) cho phần cần phát triển thêm, chạy SIT (system integration test) và hỗ trợ UAT (user acceptance test), sau cùng là đào tạo người dùng, trực go-live và hỗ trợ sau đó. Nghe giống việc BA, và đúng là elicitation, viết tài liệu, test đều dùng lại được, cái khác nằm ở chỗ bạn đứng và thứ bạn phải giỏi.
khác BA phần mềm ở đâu#
BA phần mềm thường đứng giữa người dùng và đội dev để thiết kế thứ chưa có, còn ERP consultant đứng giữa người dùng và một sản phẩm đã có, việc chính là quyết ai phải đổi, quy trình của khách hay sản phẩm. Kiểu khách yêu cầu gì build nấy hiếm khi chạy được, vì mỗi tùy biến là một khoản nợ khi nâng cấp phiên bản, cách ra quyết định này mình viết riêng trong bài Fit-gap analysis ERP.
Khác biệt thứ hai là nghiệp vụ nặng hơn giao diện. Bạn phải hiểu vì sao kế toán cần đối chiếu đơn mua, phiếu nhập kho và hóa đơn trước khi thanh toán, vì sao thủ kho không chịu nhập lô khi chưa có kết quả QC, giao diện đẹp xấu ít ai bàn, nhưng sai một tài khoản hạch toán thì cả phòng kế toán đi tìm bạn.
| Tiêu chí | BA phần mềm | ERP functional consultant |
|---|---|---|
| Sản phẩm | Xây mới theo yêu cầu | Có sẵn, cần cấu hình |
| Việc chính | User story, mockup, làm việc với dev | Workshop, fit-gap, cấu hình, FSD, UAT |
| Kiến thức nặng | Logic sản phẩm, trải nghiệm người dùng | Kế toán, kho, mua hàng, sản xuất |
| Stakeholder chính | PO, dev, designer | Kế toán trưởng, thủ kho, trưởng bộ phận, key user |
| Cao trào | Release, sprint review | Data migration, UAT, go-live |
functional hay technical#
Mảng ERP hay chia hai nhánh, functional lo nghiệp vụ, cấu hình, tài liệu, đào tạo, còn technical lo SQL, PL/SQL hoặc ngôn ngữ riêng của sản phẩm, tích hợp, báo cáo, script migration. Từ dev sang thì technical là đường thuận, nhưng đừng coi functional là phần dễ, nó khó ở chỗ bạn phải hiểu nghiệp vụ đủ để nói không với kế toán trưởng mà vẫn được nghe. Theo mình hướng chắc nhất cho người mới là functional cộng thêm SQL đủ để tự kiểm dữ liệu, khỏi phải chờ team technical mỗi lần nghi số sai.
chọn mảng nghiệp vụ đầu tiên#
Chẳng ai giỏi toàn bộ ERP ngay, chọn một mảng đi sâu trước dựa vào nền của bạn, nền kế toán thì Finance (công nợ phải trả, phải thu, tài sản), từng làm kho, vận tải thì Supply chain và Procurement, nền kỹ thuật, sản xuất thì Manufacturing hoặc Maintenance.
Không có nền nào liên quan thì chọn mảng có quy trình dễ hình dung, procure-to-pay, từ yêu cầu mua tới thanh toán nhà cung cấp, là ứng viên tốt, vì ai cũng hiểu cần mua thì tạo yêu cầu, duyệt, đặt hàng, nhận hàng, trả tiền. Học kỹ một luồng như vậy, biết dữ liệu đi qua màn hình nào và ai duyệt ở đâu, là bạn có khung để học tiếp các luồng khác như order-to-cash.
ba cửa vào nghề#
Cửa thứ nhất là vào một đối tác triển khai ERP, được đào tạo sản phẩm và đưa vào dự án sớm, đổi lại là onsite và deadline dày. Cửa thứ hai là vào team ERP nội bộ của một doanh nghiệp đang dùng hệ thống, nhịp chậm hơn, hiểu sâu một mảng. Cửa thứ ba là làm key user ngay ở công ty bạn đang làm nếu công ty có dự án ERP, ngồi UAT, viết hướng dẫn cho phòng mình, và có thứ cụ thể để kể khi đi phỏng vấn.
Chứng chỉ thì để sau, các hãng lớn như SAP có chương trình chứng chỉ chính thức, nhưng theo mình chứng chỉ chỉ có trọng lượng khi bạn đã chạm vào hệ thống, học chứng chỉ trước giống học bơi trên cạn, thuộc động tác mà xuống nước vẫn đuối.
chỗ người ta hay hiểu sai#
Nhiều người nghĩ ERP là nghề cũ, nhàm, BA phần mềm mới hiện đại, mình thấy nói vậy đúng một nửa. ERP ít hào nhoáng thật, không ship tính năng mỗi hai tuần, không demo giao diện bóng bẩy, nhưng một cấu hình sai có thể làm công nợ lệch cả tháng, và áp lực đó không nhẹ hơn một bản release lỗi.
Hiểu sai thứ hai là chuyển sang ERP thì bắt đầu lại từ số 0, không đúng, kỹ năng hỏi, ghi, kiểm tra yêu cầu vẫn nguyên, phần phải học mới là nghiệp vụ và sản phẩm, mà phần này chỉ học nhanh khi bạn ngồi họp và chịu hỏi mấy câu nghe có vẻ ngớ ngẩn như vì sao phải duyệt hai lần.
Cái giá thì nên biết trước, onsite tại nhà máy là chuyện thường, mấy tuần quanh data migration và go-live rất dài, và khách hay muốn hệ thống mới chạy y như file Excel cũ. Kỳ UAT là lúc mọi thứ lộ ra, bài UAT cho dự án ERP nói cách chuẩn bị cho đỡ vỡ.
trước khi nộp đơn#
Tự trả lời ba câu, bạn có chịu được việc ít vẽ màn hình, nhiều đọc bút toán không, có tò mò về kế toán, kho, mua hàng không, có chấp nhận onsite và mấy tuần cao trào quanh go-live không. Cả ba đều có thì ERP đáng thử, còn nếu chỉ vì thấy lương ổn thì theo mình bạn sẽ nản khá nhanh. Đang phân vân giữa nhiều hướng sau vài năm làm BA thì bài BA, PO, PM khác nhau thế nào đặt ERP consultant cạnh các lựa chọn khác.
Bạn đang nghiêng về functional hay technical, và mảng nghiệp vụ nào làm bạn tò mò nhất? Trả lời mình qua Facebook hoặc LinkedIn nhé.
