Kinh nghiệm triển khai ERP cho thấy yêu cầu tưởng là lỗi hệ thống thực chất bắt nguồn từ quy trình, dữ liệu hoặc cách hiểu chưa thống nhất. Hiểu đúng vấn đề trước khi sửa giúp tránh custom không cần thiết.
Trả lời nhanh
Nhiều vấn đề được gọi là “lỗi ERP” không bắt đầu từ phần mềm. Nguyên nhân có thể nằm ở cách hiểu nghiệp vụ chưa thống nhất, dữ liệu đầu vào chưa đủ hoặc quy trình thực tế khác với thiết kế ban đầu. Vì vậy, trước khi custom hay sửa code, cần xác định rõ nghiệp vụ và dữ liệu rồi mới chọn giải pháp kỹ thuật.
Kinh nghiệm triển khai ERP: đừng bắt đầu bằng câu hỏi sửa thế nào
Khi người dùng nói hệ thống sai, ở góc nhìn của họ điều đó hoàn toàn hợp lý. ERP là nơi hiển thị con số, chặn thao tác hoặc tạo chứng từ. Khi kết quả không giống mong đợi, hệ thống thường là thứ được nhắc đến đầu tiên.
Nhưng với người làm ERP, tôi nghĩ nên lùi lại một bước. Trước khi hỏi “sửa chương trình thế nào”, cần biết người dùng đang thực hiện nghiệp vụ gì, mong đợi kết quả nào, dữ liệu đến từ đâu và công việc trước đây được xử lý ra sao.
Có trường hợp chỉ cần hỏi kỹ thêm vài câu là hướng xử lý thay đổi hoàn toàn. Vấn đề tưởng phải sửa hệ thống cuối cùng chỉ cần thống nhất cách nhập dữ liệu hoặc định nghĩa lại một chỉ tiêu mà các phòng ban đang hiểu khác nhau.
ERP có thể tính rất chính xác. Nhưng nếu doanh nghiệp chưa thống nhất mình muốn tính điều gì, kết quả đúng về kỹ thuật vẫn có thể sai về nghiệp vụ.
Tách một vấn đề ERP thành ba lớp
Trước khi nghĩ đến giải pháp, tôi thường tách vấn đề thành ba phần: nghiệp vụ cần gì, dữ liệu hiện có ra sao và hệ thống nên xử lý phần nào.
1. Nghiệp vụ thực sự muốn kiểm soát điều gì?
Người dùng có thể yêu cầu thêm một trường dữ liệu, một validation hoặc một báo cáo. Tuy nhiên, đó thường mới là hình thức của yêu cầu. Phần quan trọng hơn là hiểu họ muốn kiểm soát rủi ro nào, tránh sai sót gì hoặc cần thông tin nào để ra quyết định.
Ví dụ, yêu cầu “không cho giao vượt Sales Order” nghe khá đơn giản. Nhưng dữ liệu thực tế có thể gồm một mặt hàng trên nhiều dòng, giao từng phần, nhiều Delivery cùng tham chiếu một đơn, mức dung sai hoặc chứng từ đã tạo rồi bị hủy.
Lúc đó, bài toán không còn là viết một câu điều kiện. Người làm hệ thống phải cùng bộ phận nghiệp vụ xác định chính xác lượng được phép giao và những ngoại lệ thực sự được chấp nhận.
2. Dữ liệu đã đủ để ERP xử lý chưa?
Nghiệp vụ rõ chưa có nghĩa dữ liệu đã sẵn sàng. Có những quy tắc hợp lý nhưng thông tin cần thiết chưa được ghi nhận trên ERP, hoặc đang nằm rải rác trong Excel, email và trao đổi giữa các phòng ban.
Ví dụ, doanh nghiệp muốn có dashboard phân tích nguyên nhân giao hàng trễ. ERP có Sales Order, ngày giao và số lượng, nhưng nguyên nhân trễ lại được planner ghi trong một file riêng. BI không thể tự suy ra dữ liệu mà doanh nghiệp chưa từng ghi nhận có cấu trúc.
Đó là lý do tôi thường kiểm tra Master Data và transaction data trước khi kết luận báo cáo hoặc chức năng đang sai.
3. Công cụ nào thực sự phù hợp?
Sau khi nghiệp vụ và dữ liệu tương đối rõ, tôi mới xem ERP cần thay đổi gì. Có trường hợp chức năng chuẩn đã đủ nhưng cấu hình chưa đúng. Có trường hợp một query, approval hoặc report phù hợp hơn việc viết thêm chương trình.
Một số nhu cầu phân tích phù hợp với Power BI hơn ERP. Một số workflow nhỏ có thể được xử lý bằng ứng dụng bổ sung thay vì đưa thêm logic vào màn hình giao dịch chính.
Không phải yêu cầu nào cũng nên trở thành chức năng mới
Điều này càng rõ khi làm với SAP Business One. Hệ thống có thể mở rộng bằng UDF, Formatted Search, Query, Transaction Notification, Add-on và tích hợp. Vì làm được nhiều, câu hỏi khó hơn đôi khi lại là: cái gì không nên làm?
Một UDF có thể tạo rất nhanh nhưng tồn tại nhiều năm. Một validation có thể giải quyết đúng một tình huống, nhưng nếu business rule chưa đủ, nó cũng có thể chặn nhầm giao dịch hợp lệ.
Một Add-on giải quyết tốt vấn đề hôm nay nhưng tạo thêm thành phần cần kiểm thử và bảo trì mỗi khi hệ thống thay đổi. Vì vậy, trước khi custom, tôi thường kiểm tra lại chức năng chuẩn và cấu hình hệ thống.
Bài thiết lập System Initialization trong SAP Business One cho thấy nhiều hành vi bắt đầu từ cấu hình nền. Không nên vội phát triển thêm khi phần standard chưa được hiểu hoặc thiết lập đúng.
Một file Excel có thể cho biết hệ thống đang thiếu gì
Có giai đoạn tôi nhìn những file Excel tồn tại sau khi ERP go-live như một thứ cần loại bỏ. Sau này, tôi thấy nên nhìn chúng bình tĩnh hơn. Không phải Excel nào cũng là vấn đề; đôi khi chính những file đó cho thấy khoảng trống của quy trình.
Nếu một workbook được mở mỗi ngày, dữ liệu luôn được xuất từ ERP rồi người dùng bổ sung cùng một nhóm cột, những cột đó rất đáng để xem lại. Chúng thường phản ánh thông tin người dùng thật sự cần để hoàn thành công việc.
Ví dụ, ERP đã có Sales Order, số lượng, tồn kho và ngày giao. Nhưng file của Sales lại có thêm “khách đang hối”, “ngày nhà máy cam kết lại”, “vật tư đang thiếu”, “người đang theo dõi” và “nguyên nhân chưa giao”.
Không có nghĩa tất cả các cột đó phải trở thành UDF. Tuy nhiên, chúng là nguồn yêu cầu tốt để người tư vấn và triển khai hệ thống ERP hiểu workflow bên ngoài hệ thống.
Trong bài Procurement và MRP trong sản xuất, câu chuyện cũng tương tự. Nếu planner luôn phải đưa kết quả MRP ra Excel rồi điều chỉnh nhiều, cần xem lại Demand, BOM, tồn kho, Lead Time và cách doanh nghiệp lập kế hoạch trước khi kết luận MRP không tốt.
Bài học từ những validation tưởng rất đơn giản
Một nhóm yêu cầu thường gặp trong SAP Business One là validation chứng từ. Business rule ban đầu thường được mô tả rất gọn, chẳng hạn không được giao vượt Sales Order hoặc không được nhận hàng vượt Purchase Order quá tỷ lệ cho phép.
Nếu kiểm thử bằng một Sales Order có một mặt hàng trên một dòng và một Delivery duy nhất, việc viết rule tương đối dễ. Dữ liệu thật thường không đẹp như vậy.
Một mặt hàng có thể xuất hiện trên nhiều dòng. Một đơn được giao nhiều lần. Một chứng từ có thể bị hủy. Ngoài ra còn có quan hệ một-nhiều, nhiều-một, mức dung sai theo phần trăm hoặc trường hợp sửa chứng từ sau khi đã có giao dịch liên quan.
Câu SQL có thể chạy đúng, không báo lỗi và vượt qua test case đầu tiên, nhưng validation vẫn chặn sai khi gặp dữ liệu thực tế. Phần khó lúc đó không nằm ở cú pháp SQL mà ở business rule chưa bao quát đủ tình huống.
Code chạy được chưa chắc business rule đã đúng. Test case đẹp thường chỉ cho biết giải pháp hoạt động trong trường hợp đẹp.
Báo cáo sai có thể bắt đầu từ định nghĩa khác nhau
Finance, Sales và Operations có thể cùng nhìn một chỉ tiêu nhưng nhận kết quả khác nhau. Phản ứng đầu tiên thường là yêu cầu IT xác định báo cáo nào đúng.
Trong thực tế, mỗi báo cáo có thể dùng một định nghĩa khác. “Doanh thu tháng” có thể dựa trên ngày giao hàng, ngày hóa đơn hoặc posting date. “Tồn kho cuối tháng” cũng khác tồn kho hiện tại nếu đã có giao dịch của những ngày sau.
Vì vậy, trước khi sửa query, cần xác định con số đó dùng để trả lời câu hỏi gì và nguồn transaction nào phù hợp với mục tiêu ấy.
Trong bài phân tích chi phí và lợi nhuận trong SAP Business One, dữ liệu chỉ có ý nghĩa khi đối tượng quản trị được xác định và ghi nhận đúng từ transaction.
Một dashboard đẹp không thể sửa dữ liệu thiếu ở phía trước. Một câu SQL phức tạp cũng không thể tự quyết định thay doanh nghiệp rằng “doanh thu” trong ngữ cảnh này nên được hiểu theo cách nào.
Quy trình tiếp nhận một yêu cầu ERP mới
Đây không phải quy trình cứng, nhưng khi nhận một yêu cầu mới, tôi thường giữ trình tự sau:
- Nghe người dùng mô tả vấn đề bằng ngôn ngữ nghiệp vụ, chưa vội chuyển thành yêu cầu kỹ thuật.
- Lấy một hoặc hai chứng từ, giao dịch hoặc trường hợp thật để cùng kiểm tra.
- Xác định kết quả mong muốn và thống nhất định nghĩa nghiệp vụ.
- Kiểm tra dữ liệu cần thiết đã có trong ERP hay đang nằm ở nguồn khác.
- Xem chức năng chuẩn, cấu hình và quy trình hiện tại có thể xử lý đến đâu.
- Chọn giải pháp nhỏ, rõ và dễ bảo trì trước khi nghĩ đến custom lớn.
- Kiểm thử trường hợp bình thường cùng những ngoại lệ quan trọng đã biết.
- Sau khi đưa vào sử dụng, xem người dùng còn phải xử lý thủ công ở bước nào.
Cách làm này có thể khiến giai đoạn đầu chậm hơn một chút vì cần thời gian hỏi và kiểm tra nghiệp vụ. Nhưng thời gian đó thường nhỏ hơn nhiều so với việc phát triển một giải pháp rồi phải sửa lại vì yêu cầu ban đầu chưa đúng.
Checklist trước khi quyết định sửa hệ thống
- Người dùng đang gặp vấn đề gì trong công việc thực tế?
- Kết quả mong muốn được định nghĩa cụ thể như thế nào?
- Các phòng ban có đang hiểu cùng một khái niệm theo cùng một cách không?
- Dữ liệu cần cho yêu cầu đã tồn tại và đủ tin cậy chưa?
- Chức năng chuẩn hoặc cấu hình hiện tại có xử lý được không?
- Có giải pháp nào đơn giản hơn việc custom trực tiếp ERP không?
- Thay đổi này ảnh hưởng thế nào đến chứng từ hoặc quy trình phía sau?
- Những trường hợp ngoại lệ nào đã xảy ra trong thực tế?
- Giải pháp có đủ rõ để người khác tiếp tục bảo trì không?
Câu hỏi thường gặp
Khi nào nên custom ERP hoặc SAP Business One?
Nên custom khi nhu cầu nghiệp vụ có tính lặp lại, tạo giá trị hoặc kiểm soát rủi ro rõ ràng và chức năng chuẩn không đáp ứng phù hợp. Trước đó, nên kiểm tra cấu hình, approval, query, report hoặc khả năng thay đổi quy trình.
Lỗi ERP thường nằm ở phần mềm hay dữ liệu?
Cả hai đều có thể xảy ra. Tuy nhiên, nhiều vấn đề vận hành đến từ Master Data, transaction data, mapping hoặc cách sử dụng chưa thống nhất. ERP có thể chạy đúng về kỹ thuật nhưng tạo kết quả không phù hợp nếu dữ liệu đầu vào hoặc định nghĩa nghiệp vụ chưa đúng.
Có nên làm đúng theo giải pháp người dùng đề xuất không?
Không nhất thiết. Người dùng thường hiểu rõ khó khăn trong công việc, nhưng giải pháp họ đề xuất có thể dựa trên cách đang làm hiện tại. Nên xem yêu cầu đó là điểm bắt đầu, tìm nhu cầu thật phía sau rồi cùng người dùng chọn cách xử lý phù hợp.
Vì sao triển khai ERP rồi vẫn còn Excel?
Excel vẫn phù hợp cho phân tích nhanh, mô phỏng và nhu cầu linh hoạt. Điều cần chú ý là khi một file trở thành bước bắt buộc của quy trình, giữ dữ liệu ERP không có hoặc phải đối chiếu thủ công mỗi ngày. Khi đó, file Excel là tín hiệu để rà lại quy trình và khoảng trống của hệ thống.
Kinh nghiệm triển khai ERP quan trọng nhất là gì?
Với tôi, quan trọng nhất là hiểu đúng vấn đề trước khi chọn giải pháp. ERP nằm giữa nhiều phòng ban, dữ liệu và quy trình nên một thay đổi nhỏ có thể ảnh hưởng đến nhiều bước phía sau. Kỹ thuật giúp triển khai giải pháp, nhưng bối cảnh nghiệp vụ mới giúp xác định giải pháp đó có thực sự đúng hay không.
Kết luận
Kinh nghiệm triển khai ERP tôi giữ lại sau nhiều dự án không nằm ở một công thức kỹ thuật cụ thể. Điều hữu ích nhất là chậm lại ở bước đầu: xem chứng từ thật, hiểu người dùng đang vướng ở đâu, kiểm tra dữ liệu và thống nhất cách hiểu nghiệp vụ trước khi thay đổi hệ thống.
Một báo cáo sai có thể bắt đầu từ định nghĩa chưa thống nhất. Một validation chặn nhầm có thể do yêu cầu thiếu ngoại lệ. Một file Excel tồn tại lâu bên ngoài ERP có thể đang giữ phần quy trình hệ thống chưa bao phủ.
ERP là công nghệ, nhưng phần khó của ERP nhiều khi nằm ngoài công nghệ. Giải pháp tốt không nhất thiết phải lớn hay có nhiều chức năng. Quan trọng hơn là giải pháp xử lý đúng vấn đề, người dùng hiểu cách vận hành và hệ thống vẫn ổn định sau nhiều tháng sử dụng.