Đừng vội code ERP khi quy trình còn là một mớ rác

Suốt hai thập kỷ triển khai các hệ sinh thái từ ERP, SCM đến DMS tại thị trường Việt Nam, tôi chứng kiến không dưới 50 doanh nghiệp rơi vào cái bẫy này: Bỏ ra vài chục tỷ đồng mua giải pháp hàng đầu thế giới (SAP, Oracle) hoặc thuê đội ngũ tinh nhuệ về code may đo, rồi sau 18 tháng nhận lại một hệ thống đắp chiếu, nhân viên quay lại dùng Excel.

Nguyên nhân không nằm ở công nghệ. Nguyên nhân nằm ở tư duy lãnh đạo: Cố gắng tự động hóa một quy trình đã lỗi thời và rách nát.

Số hóa một mớ hỗn độn, thứ duy nhất bạn nhận được là một mớ hỗn độn đắt tiền chạy bằng điện.

1. Ảo tưởng mang tên “Hệ thống sẽ tự sửa lỗi vận hành”

Nhiều CEO nói với tôi: “Anh Tường ơi, kho bên em thất thoát nhiều quá, phê duyệt thì chậm trễ, giờ cài ERP vào là siết được đúng không?”

Câu trả lời ngắn gọn: Không.

Nếu một phiếu xuất kho cần 5 chữ ký sống chạy qua 3 phòng ban chỉ để hợp thức hóa một đơn hàng 5 triệu đồng, việc bạn đưa quy trình đó lên ERP chỉ biến nó thành 5 cái click chuột gây nghẽn mạng nội bộ. Người ta vẫn sẽ gọi điện giục nhau: “Duyệt trên web cho em với”. Sự trì trệ không biến mất, nó chỉ chuyển từ giấy sang màn hình LED.

Tái cấu trúc quy trình (BPR - Business Process Re-engineering) là công việc phẫu thuật cắt bỏ khối u trước khi cho bệnh nhân mặc bộ đồ công nghệ đắt tiền. Bạn phải trả lời được các câu hỏi tàn nhẫn:

Bước phê duyệt này có tạo ra giá trị gia tăng không? Nếu không, xóa bỏ.
Điểm kiểm soát (Control Point) này sinh ra để phòng ngừa rủi ro gì? Chi phí kiểm soát có lớn hơn tổn thất tiềm tàng không?
Dữ liệu này thu thập để phục vụ ai, hay chỉ để nằm chết trong báo cáo tháng?

2. Xung đột muôn thuở: Kế toán thuế (VAS) và Kế toán Quản trị

Tại Việt Nam, rào cản lớn nhất của BPR nằm ở độ vênh giữa báo cáo tài chính tuân thủ VAS và dữ liệu điều hành thực tế.

Doanh nghiệp thường cố nhồi nhét nghiệp vụ lắt léo, các thủ thuật “lách” chứng từ vào logic của hệ thống ERP. Lập trình viên nhận yêu cầu sẽ biến mã nguồn thành một mê cung không thể bảo trì. Khi luật thuế thay đổi hoặc doanh nghiệp mở rộng quy mô, toàn bộ cấu trúc sụp đổ.

Người làm kiến trúc hệ thống chuyên nghiệp phải tách bạch hai dòng chảy: Chuẩn hóa luồng vận hành quản trị thực tế (vận đơn, tồn kho, công nợ thực) làm lõi trung tâm, sau đó thiết lập các bộ quy tắc ánh xạ (Mapping Rules) sang hệ thống sổ sách kế toán thuế. Không bao giờ được dùng tư duy đối phó thuế để định hình quy trình vận hành cốt lõi.

3. So sánh: Có BPR vs. Không BPR trước khi triển khai ERP

Tiêu chí	Triển khai ERP thông thường (No BPR)	Triển khai ERP sau khi chuẩn hóa BPR
Tỷ lệ Custom Code	Rất cao (> 40% hệ thống)	Rất thấp (< 10%, ưu tiên Best Practice)
Thời gian triển khai	Kéo dài gấp đôi, thường vỡ tiến độ	Đúng hạn, sai số thời gian dưới 15%
Tâm lý người dùng	Kháng cự quyết liệt, thao tác rườm rà	Dễ tiếp nhận vì quy trình đã tinh gọn
Chi phí ẩn	Phí bảo trì, sửa lỗi phình to theo năm	Tối ưu hóa TCO (Total Cost of Ownership)
Khả năng mở rộng	Rất khó nâng cấp phiên bản mới	Dễ dàng tích hợp thêm CRM, SCM, BI

4. Ba bước dọn dẹp trước khi gõ dòng code đầu tiên

Nếu doanh nghiệp của bạn đang rục rịch chuẩn bị cho một dự án chuyển đổi số lớn, hãy dừng lại và thực hiện 3 điều này:

Chuẩn hóa Master Data (Dữ liệu chủ): Một mã vật tư có bao nhiêu tên gọi? Danh mục khách hàng có bị trùng lặp không? Bảng tài khoản kế toán (Chart of Accounts) đã thống nhất giữa các chi nhánh chưa? Nếu rác đi vào (Garbage In), chắc chắn rác sẽ đi ra (Garbage Out).
Tối giản hóa ma trận phân quyền (RACI Matrix): Một việc chỉ nên có duy nhất một người chịu trách nhiệm chính (Accountable). Cắt giảm ít nhất 30% các nấc phê duyệt vô thưởng vô phạt mang tính thủ tục.
Đóng băng quy trình mục tiêu (To-Be Process): Quy trình tương lai phải được thống nhất bằng văn bản giữa các Trưởng bộ phận và ký duyệt bởi Tổng Giám đốc. Tuyệt đối không cho phép vừa làm hệ thống vừa tùy tiện thay đổi logic nghiệp vụ.

Đừng bao giờ giao vận mệnh và dòng tiền của doanh nghiệp cho một đội ngũ lập trình khi chính bạn còn chưa vẽ rõ con đường mà hàng hóa và tiền tệ đang vận hành.