ERP là “con hào hộ thành”: khi nào chuẩn hóa, khi nào tùy chỉnh?
Dành cho chủ doanh nghiệp, lãnh đạo bảo trợ, ban chỉ đạo và PMO đang nghe phản ánh “ERP khó dùng, cứng nhắc” và phải quyết định yêu cầu thay đổi nào được chấp nhận.
Phần lớn cảm giác ERP “cứng nhắc” đến từ chuẩn hóa và kiểm soát nội bộ, chính là thứ bảo vệ dữ liệu doanh nghiệp như con hào bảo vệ tòa thành. Nhưng linh hoạt không có nghĩa là tùy tiện đổi quy tắc cốt lõi. Doanh nghiệp cần một cơ chế rõ: khi nào dùng chuẩn, khi nào cấu hình, khi nào tùy chỉnh và ai phê duyệt ngoại lệ.
Vì sao ERP bị chê cứng nhắc, và vì sao sự “cứng” đó có giá trị?
Sau khi triển khai ERP, nhiều chủ doanh nghiệp nghe những phản hồi quen thuộc: “hệ thống khó dùng quá”, “cứng nhắc, làm chậm công việc”, “không linh hoạt bằng Excel”. Có người còn cho rằng ERP nước ngoài không hợp với cách làm việc linh hoạt của doanh nghiệp Việt.
Để trả lời, cần quay lại lý do ERP ra đời. Khi kế toán dùng một phần mềm, kho dùng một hệ thống khác và sản xuất lập kế hoạch bằng Excel, doanh nghiệp tạo ra những “ốc đảo thông tin”: cùng một giao dịch nhưng mỗi nơi một con số. ERP thay các ốc đảo đó bằng một nền dữ liệu chung.
Muốn dữ liệu chung đáng tin, mọi bộ phận phải theo cùng quy tắc. Excel giống như tự đóng một chiếc kệ sách: muốn thêm ngăn, bớt ngăn lúc nào cũng được. ERP giống như xây một tòa nhà cao tầng: có thể sơn lại tường, đổi nội thất, nhưng không thể tùy ý dời cột chịu lực hay sửa móng. Những “cột chịu lực” đó gồm:
- Quy trình chuẩn để dữ liệu đi qua các bộ phận theo cùng một cách;
- Phân quyền và phê duyệt để ngăn sai sót trước khi chúng thành số liệu chính thức;
- Dấu vết thao tác để biết ai đã tạo, sửa, duyệt giao dịch nào;
- Dữ liệu chủ thống nhất để báo cáo dùng cho quyết định là đáng tin.
Không phải mọi cái khó đều là cái giá của kiểm soát. Một phần đến từ cấu hình chưa hợp lý, dữ liệu sai, đào tạo chưa đủ hoặc lỗi hiệu năng, và phần đó cần được sửa chứ không cần được bảo vệ. Để tách hai loại này, xem 7 nhóm nguyên nhân khiến ERP làm công việc chậm hơn.
Khi thiếu cơ chế cân bằng, dự án rơi vào hai thái cực
Yêu cầu thay đổi đến từ nhiều phía: người dùng muốn giữ cách làm quen thuộc, quản lý muốn tăng kiểm soát, IT muốn hạn chế phát triển khó bảo trì, đơn vị triển khai muốn giữ phạm vi và tiến độ. Không có nguyên tắc chung, mỗi yêu cầu được quyết định theo mức độ gấp hoặc tiếng nói của người đề xuất.
Chuẩn hóa quá mức
Mọi khác biệt đều bị từ chối nhân danh “quy trình chuẩn”, kể cả yêu cầu pháp lý, yêu cầu khách hàng hay khác biệt tạo lợi thế cạnh tranh.
Hệ quảCông việc chạy ra ngoài hệ thống qua file riêng và email; dữ liệu chính thức mất dần giá trị.
Tùy chỉnh không kiểm soát
Mỗi yêu cầu được đáp ứng bằng phát triển thêm, không đánh giá tác động và không có ngày xem lại.
Hệ quảHệ thống ngày càng phức tạp, khó kiểm thử, khó nâng cấp và phụ thuộc vào vài cá nhân.
Quản trị ERP thực chất quyết định điều gì?
Tìm điểm cân bằng bắt đầu từ việc biết một yêu cầu thay đổi chạm vào lớp nào, vì mỗi lớp có người quyết định, rủi ro và chi phí vòng đời khác nhau.
| Lớp | Gồm những gì |
|---|---|
| Chính sách | Nguyên tắc kinh doanh và kiểm soát nội bộ, ví dụ ngưỡng phê duyệt, điều kiện công nhận giao dịch hoàn tất. |
| Quy trình | Trình tự công việc, người thực hiện và điểm bàn giao giữa các bộ phận. |
| Dữ liệu | Dữ liệu chủ, quy tắc đặt mã, ai được tạo, sửa và chịu trách nhiệm về chất lượng. |
| Vai trò và bảo mật | Ai được xem, thực hiện hoặc phê duyệt nghiệp vụ nào. |
| Cấu hình | Tham số, luồng duyệt, loại chứng từ, biểu mẫu trong phạm vi chức năng chuẩn. |
| Tích hợp | Trao đổi dữ liệu với hệ thống khác, kèm quy tắc đồng bộ và xử lý lỗi. |
| Mở rộng | Báo cáo, giao diện hoặc chức năng bổ sung bên cạnh hệ thống chuẩn, không đổi logic lõi. |
| Mã tùy chỉnh | Thay đổi hoặc phát triển logic ngoài chức năng chuẩn; có chi phí kiểm thử, hỗ trợ và nâng cấp lâu dài. |
Mỗi giai đoạn của vòng đời ERP cần quyết định gì?
Lựa chọn
Tuyên bố nguyên tắc chuẩn hóa và các yêu cầu không thể thương lượng. Đưa ranh giới chuẩn, cấu hình và tùy chỉnh vào tiêu chí lựa chọn hệ thống ERP.
Thiết kế giải pháp
Với từng yêu cầu, quyết định dùng chuẩn, cấu hình, tích hợp, mở rộng hay tùy chỉnh; ghi lại lý do.
Kiểm thử và go-live
Kiểm chứng các ngoại lệ, điểm kiểm soát và mức độ sẵn sàng của người dùng trước khi vận hành chính thức.
Ổn định và vận hành
Theo dõi lỗi, các cách làm tạm và yêu cầu thay đổi mới; phân biệt lỗi cần sửa với nhu cầu cần thiết kế lại.
Nâng cấp và mở rộng
Đánh giá lại các đối tượng tùy chỉnh và biến thể địa phương trước khi nâng cấp phiên bản hoặc mở rộng sang đơn vị mới. Với hệ thống được nhà cung cấp cập nhật phiên bản theo thay đổi quy định, như Workflow ERP iGP của Digiwin, mỗi tùy chỉnh là một điểm phải kiểm thử lại ở mỗi lần nâng cấp.
Ai đề xuất, ai đánh giá, ai phê duyệt thay đổi ERP?
Bảng dưới đây là mô hình tham khảo để doanh nghiệp điều chỉnh theo cơ cấu của mình. Tên vai trò và ngưỡng phê duyệt cụ thể cần được thống nhất trong từng dự án.
| Quyết định | Đề xuất | Đánh giá tác động | Phê duyệt | Kiểm thử, xác nhận | Duy trì |
|---|---|---|---|---|---|
| Quy trình chuẩn hoặc biến thể | Process owner | Data owner, IT, các bộ phận bị ảnh hưởng | Lãnh đạo bảo trợ hoặc ban chỉ đạo, theo ngưỡng | Key user, người tham gia UAT | Process owner |
| Quy tắc dữ liệu chủ | Data owner | Process owner và người phụ trách tích hợp | Người có thẩm quyền quản trị dữ liệu được chỉ định | Người quản lý dữ liệu và người dùng | Data owner |
| Thay đổi cấu hình | Process owner hoặc tư vấn triển khai | IT, bảo mật, tích hợp | Người có thẩm quyền phê duyệt thay đổi | Key user và process owner | Người phụ trách ứng dụng |
| Phát triển tùy chỉnh | Process owner cùng bộ phận kiến trúc | Chi phí vòng đời, bảo mật, nâng cấp, hỗ trợ | Ban chỉ đạo hoặc người có thẩm quyền phê duyệt thay đổi | Nghiệp vụ và IT | Người phụ trách ứng dụng được chỉ định |
Năm hướng xử lý cho một yêu cầu thay đổi
Xét lần lượt từ trên xuống. Chỉ chuyển sang hướng tiếp theo khi hướng trước không đáp ứng được mục tiêu đã thống nhất.
Áp dụng quy trình chuẩn
Phù hợp khi: yêu cầu xuất phát từ thói quen, và quy trình chuẩn đáp ứng được mục tiêu kiểm soát.
Cần làm: giải thích lý do, điều chỉnh đào tạo, theo dõi phản hồi sau thay đổi.
Cấu hình trong phạm vi chức năng chuẩn
Phù hợp khi: khác biệt xử lý được bằng tham số, vai trò, ngưỡng duyệt hoặc loại giao dịch.
Cần làm: đánh giá tác động đến bộ phận khác, kiểm thử trước khi áp dụng.
Báo cáo, tích hợp hoặc mở rộng
Phù hợp khi: nhu cầu chủ yếu là cách xem, phân tích hoặc trao đổi dữ liệu; giao dịch gốc không đổi.
Cần làm: xác định nguồn dữ liệu, tần suất cập nhật, quyền truy cập và người xử lý khi kết quả không khớp.
Tùy chỉnh có quản trị
Phù hợp khi: yêu cầu tạo giá trị hoặc kiểm soát quan trọng mà ba hướng trên không đáp ứng, có người sở hữu và bằng chứng.
Cần làm: phê duyệt chính thức, ghi rõ chi phí kiểm thử, hỗ trợ, nâng cấp và phương án quay về chuẩn.
Ngoại lệ hoặc cách làm tạm có thời hạn
Phù hợp khi: cần giải pháp ngắn hạn trong lúc chờ quyết định dài hạn, hoặc tình huống hiếm gặp.
Cần làm: ghi vào sổ đăng ký ngoại lệ, đặt ngày xem lại và điều kiện chấm dứt.
Khi ngoại lệ xảy ra thường xuyên
Nếu một ngoại lệ lặp lại liên tục, đó thường là dấu hiệu quy trình chuẩn không còn phù hợp và cần được thiết kế lại, thay vì tiếp tục phê duyệt từng lần.
Quy trình 6 bước xử lý yêu cầu thay đổi ERP
Ghi nhận vấn đề và bằng chứng
Ai gặp vấn đề, ở tác vụ nào, bao lâu một lần, ảnh hưởng ra sao. Không bắt đầu từ giải pháp mong muốn.
Phân loại yêu cầu
Lỗi cần sửa, nhu cầu đào tạo, thay đổi quy trình, dữ liệu, cấu hình, báo cáo, tích hợp hay tùy chỉnh.
Đánh giá tác động
Ảnh hưởng đến quy trình, dữ liệu, bảo mật, tích hợp và các bộ phận khác; chi phí và rủi ro vòng đời.
So sánh phương án
Đặt phương án chuẩn, cấu hình và mở rộng cạnh nhau trước khi xét đến tùy chỉnh.
Phê duyệt, kiểm thử và triển khai
Người có thẩm quyền phê duyệt theo ngưỡng; key user và process owner xác nhận kết quả kiểm thử.
Đánh giá lại và quyết định giữ hay bỏ
Sau một thời gian vận hành, kiểm tra thay đổi có đạt mục tiêu không; giữ, điều chỉnh hoặc gỡ bỏ.
Sổ đăng ký ngoại lệ cần những thông tin gì?
Mục tiêu không phải loại bỏ mọi ngoại lệ, mà làm cho mỗi ngoại lệ nhìn thấy được, có người chịu trách nhiệm và có ngày xem lại. Lịch xem lại do ban chỉ đạo quyết định theo mức rủi ro.
- Yêu cầu và bằng chứng
- Vấn đề gì, ai phát hiện, dữ liệu minh chứng.
- Người sở hữu
- Người sở hữu nghiệp vụ, quy trình hoặc dữ liệu liên quan.
- Phạm vi ảnh hưởng
- Vai trò, hệ thống và tích hợp bị ảnh hưởng.
- Lý do không dùng chuẩn
- Vì sao chức năng chuẩn hoặc cấu hình không đáp ứng được.
- Rủi ro và kiểm soát
- Rủi ro phát sinh và biện pháp kiểm soát bù đắp.
- Hướng xử lý đã chọn
- Một trong năm hướng xử lý ở trên.
- Bằng chứng kiểm thử
- Kết quả kiểm thử và người xác nhận.
- Hệ quả hỗ trợ, nâng cấp
- Ảnh hưởng đến hỗ trợ và nâng cấp phiên bản.
- Ngày hiệu lực, ngày xem lại
- Khi nào bắt đầu, khi nào phải xem xét lại hoặc hết hạn.
- Điều kiện quay lui
- Khi nào gỡ bỏ ngoại lệ và quay về quy trình chuẩn.
- Người phê duyệt cuối
- Người có thẩm quyền đã phê duyệt và ngày phê duyệt.
Ví dụ: yêu cầu nâng ngưỡng tự duyệt đơn mua hàng
Tình huống giả định, không lấy từ một khách hàng cụ thể: bộ phận mua hàng của một nhà máy đề nghị nâng ngưỡng giá trị đơn mua hàng được trưởng bộ phận tự duyệt, vì nhiều đơn vật tư tiêu hao phải chờ giám đốc duyệt làm chậm sản xuất.
Ghi nhận
Trưởng mua hàng ghi lại số đơn bị chờ duyệt, thời gian chờ và các lần sản xuất bị ảnh hưởng.
Phân loại
Đây là thay đổi chính sách phê duyệt và cấu hình luồng duyệt, không phải yêu cầu phát triển.
Đánh giá tác động
Tài chính xem rủi ro chi tiêu; kiểm soát nội bộ xem yêu cầu tách biệt nhiệm vụ; IT xác nhận có thể cấu hình ngưỡng theo nhóm vật tư.
So sánh phương án
Nâng ngưỡng cho mọi đơn; nâng ngưỡng chỉ cho nhóm vật tư tiêu hao; hoặc giữ ngưỡng và bổ sung người duyệt thay khi vắng mặt.
Phê duyệt và kiểm thử
Ban chỉ đạo chọn phương án theo nhóm vật tư; key user kiểm thử trên các đơn mẫu trước khi áp dụng.
Xem lại
Đặt ngày xem lại để so sánh thời gian chờ duyệt và các chi tiêu bất thường trước và sau thay đổi.
Doanh nghiệp đã triển khai đưa quản trị vào vận hành như thế nào?
Hai ví dụ dưới đây được tóm tắt từ case study công khai trên website Digiwin. Chúng cho thấy quản trị không phải là chính sách trừu tượng, mà phải được chuyển thành quy tắc vận hành và sự tham gia cụ thể của lãnh đạo.
Ngưỡng phê duyệt, người duyệt thay và lịch sử hồ sơ
Bối cảnh: văn kiện và chứng từ được xử lý trên giấy, quy trình ký duyệt từ yêu cầu thu mua đến sản xuất rất trắc trở. Cấp phê duyệt thay đổi theo giá trị mua hàng.
Cách làm: giám đốc tham gia từ thảo luận nội bộ đến quy hoạch quy trình và đào tạo; các bộ phận liên quan cùng tham gia đào tạo. Hệ thống lưu toàn bộ lịch sử hồ sơ và tự chuyển hồ sơ cho người duyệt thay khi người phê duyệt vắng mặt.
Điều rút ra: ngưỡng duyệt, ủy quyền và lịch sử phê duyệt phải được thiết kế thành quy tắc cụ thể. Lưu ý: dự án của Fulin kết hợp ERP với BPM; không nên hiểu mọi chức năng trên là chức năng sẵn có của riêng ERP.
Nguồn: Case study Fulin Plastic
Chọn gói phần mềm tiêu chuẩn và xây SOP từng bước
Bối cảnh: doanh nghiệp cung ứng phụ tùng xe, bình ắc quy và sản phẩm dập kim loại này từng có chi phí tồn kho “tương đương doanh thu của ba tháng”.
Cách làm: YUOYI chọn dùng gói phần mềm tiêu chuẩn để tổng hợp toàn bộ dữ liệu, thay vì phát triển theo cách làm cũ. Chị Liou Yu-Fong giữ vai trò quản lý dự án (PM), xây dựng SOP tiêu chuẩn và thực hiện từng bước một. Doanh nghiệp tích hợp dữ liệu kinh doanh, tồn kho, sản xuất, tài chính và giá thành trong 7 tháng, hoàn thành đào tạo nội bộ trong một tháng, và đề nghị cấp quản lý làm gương tham gia đào tạo.
Kết quả doanh nghiệp công bố: theo case study, chi phí tồn kho giảm 33%.
Điều rút ra: “dùng chuẩn” là một quyết định quản trị: có người chịu trách nhiệm, được cụ thể hóa thành SOP và triển khai theo thứ tự. Ưu tiên chuẩn không có nghĩa là không có khác biệt, mà là mọi khác biệt phải đi qua cơ chế quyết định.
Nguồn: Case study YUOYI Việt Nam
Phản ánh của người dùng đi vào quản trị như thế nào?
Phản ánh của người dùng là nguồn bằng chứng quan trọng cho bước đầu tiên của quy trình thay đổi. Để phản ánh hữu ích, người dùng cần mô tả được tác vụ, kết quả mong đợi, kết quả thực tế, tần suất và ảnh hưởng; hướng dẫn chi tiết có trong bài cách người dùng xác định và mô tả vấn đề khi ERP khó dùng hơn Excel. Bằng chứng lặp lại từ nhiều người có thể là lý do chính đáng để thiết kế lại quy trình; một phản ánh đơn lẻ không tự động trở thành lý do để tùy chỉnh hệ thống.
Nên bắt đầu quản trị thay đổi ERP từ đâu?
Trước khi phê duyệt thêm bất kỳ thay đổi nào, hãy thiết lập bộ công cụ quản trị tối thiểu:
- Danh sách nguyên tắc chuẩn hóa và yêu cầu không thể thương lượng;
- Người sở hữu cho từng quy trình chính và từng nhóm dữ liệu chủ;
- Bảng phân quyền quyết định có ngưỡng phê duyệt;
- Mẫu yêu cầu thay đổi theo quy trình 6 bước;
- Sổ đăng ký ngoại lệ có ngày xem lại;
- Lịch rà soát định kỳ các tùy chỉnh và ngoại lệ đang tồn tại.
Nếu doanh nghiệp đang ở giai đoạn lựa chọn hệ thống, hãy đưa các nguyên tắc này vào tiêu chí đánh giá ngay từ đầu.
Câu hỏi thường gặp về quản trị ERP
Chuẩn hóa có luôn tốt hơn tùy chỉnh không?
Không. Chuẩn hóa giúp bảo vệ dữ liệu và giảm chi phí vòng đời, nhưng các yêu cầu pháp lý, yêu cầu của khách hàng hoặc khác biệt tạo lợi thế cạnh tranh vẫn cần được đánh giá. Điều quan trọng là mỗi khác biệt có người sở hữu, lý do và cách kiểm soát.
Ai nên chủ trì ban chỉ đạo ERP?
Thường là một lãnh đạo có đủ thẩm quyền giải quyết xung đột giữa các bộ phận. Ban chỉ đạo cần có đại diện của các quy trình chính, dữ liệu và IT, cùng quản lý dự án.
Quản trị ERP có kết thúc sau khi go-live không?
Không. Sau go-live mới là lúc lỗi, cách làm tạm và yêu cầu thay đổi xuất hiện nhiều nhất. Nếu không tiếp tục quản trị, ngoại lệ tạm thời sẽ dần trở thành độ phức tạp vĩnh viễn và gây khó khăn khi nâng cấp.
Đang lựa chọn ERP hoặc đang dùng Workflow ERP của Digiwin?
Nếu doanh nghiệp đang chọn hệ thống, Digiwin có thể trình bày cách Workflow ERP iGP phân định phần chuẩn, cấu hình và tùy chỉnh trên chính quy trình của bạn. Nếu bạn đang dùng Workflow ERP, hãy chia sẻ thay đổi hoặc ngoại lệ đang được đề xuất để đội tư vấn Digiwin cùng xem cách xử lý. Nếu hệ thống hiện tại không còn phù hợp và bạn đang cân nhắc thay thế, chúng tôi có thể cùng bạn đánh giá lại.
Trao đổi với DigiwinĐang ở giai đoạn lựa chọn hệ thống? Xem 12 tiêu chí lựa chọn ERP.
