ERP governance: ai chịu trách nhiệm khi ERP không hoạt động đúng?

2026-09-24

Tóm tắt cho CEO / COO / CIO

• ERP không tự vận hành sau go-live — nó cần con người, vai trò, và quy trình để duy trì chất lượng và giá trị theo thời gian.
• Nhiều doanh nghiệp có kế hoạch triển khai chi tiết nhưng không có kế hoạch governance sau go-live.
• Kết quả: dữ liệu xuống cấp, vấn đề không được xử lý có nguyên tắc, và hệ thống dần trở thành thứ không ai muốn chịu trách nhiệm.
• Governance không cần phức tạp — nhưng cần rõ ràng về vai trò, quy trình và quyết định.

Giới thiệu

→ Khám phá các giải pháp ERP Readiness

Để hiểu broader context về user adoption và impact của nó trên governance: ERP và con người — tại sao user adoption quyết định thành bại

Để hiểu giai đoạn sau go-live: Từ ERP Implementation đến ERP Adoption — khoảng cách ít ai nói tới

Để hiểu lý do cơ bản, xem: Tại sao dự án ERP không đạt mục tiêu — và vấn đề thực sự không nằm ở phần mềm

ERP không tự vận hành

Có một giả định ngầm phổ biến trong nhiều dự án ERP: khi hệ thống đã go-live và nhà triển khai rời đi, ERP sẽ tự vận hành và duy trì giá trị của nó.

Giả định đó không đúng.

ERP là một hệ thống sống — nó phản ánh doanh nghiệp đang vận hành. Khi doanh nghiệp thay đổi — thêm sản phẩm mới, thay đổi quy trình, thêm nhân sự, điều chỉnh cơ cấu — hệ thống cần được cập nhật theo. Khi dữ liệu không được duy trì đúng cách, chất lượng dữ liệu xuống cấp theo thời gian. Khi vấn đề phát sinh và không có người chịu trách nhiệm xử lý, chúng tích lũy.

Và không có gì tự nhiên ngăn những điều đó xảy ra — trừ khi có governance.

Governance, trong ngữ cảnh ERP, là cấu trúc vai trò, quy trình và quyết định giúp hệ thống tiếp tục phản ánh đúng thực tế vận hành của doanh nghiệp sau go-live.

Dấu hiệu thiếu ERP governance

Những dấu hiệu này thường xuất hiện từ 6 đến 18 tháng sau go-live — khi không khí “dự án mới” đã qua đi và không có cấu trúc nào thay thế.

Dữ liệu master ngày càng kém chất lượng. Sản phẩm mới được tạo ra không theo chuẩn, nhà cung cấp trùng lặp tích lũy, thông tin khách hàng không được cập nhật. Không ai được phân công duy trì chất lượng master data — và không có quy trình rõ ràng để thêm, sửa, xóa bản ghi.

Vấn đề được báo cáo nhưng không được xử lý. Người dùng gặp lỗi hoặc bất tiện, báo cáo với người quản lý trực tiếp, người quản lý chuyển lên IT, IT không có đủ quyền hoặc hiểu biết để xử lý, vấn đề trôi dạt. Không có quy trình ticket, không có SLA, không có người chịu trách nhiệm cuối cùng.

Yêu cầu thay đổi không được quản lý. Khi nghiệp vụ thay đổi và cần cập nhật cấu hình ERP, không rõ ai quyết định, ai thực hiện, và ai kiểm tra. Một số thay đổi được thực hiện trực tiếp mà không có tài liệu — và không ai biết hệ thống đang ở trạng thái nào so với cấu hình gốc.

Quyền truy cập không được kiểm soát. Nhân viên mới được cấp quyền theo yêu cầu của sếp trực tiếp mà không có nguyên tắc rõ ràng. Nhân viên nghỉ việc nhưng tài khoản không bị vô hiệu hóa kịp thời. Không có ai kiểm tra định kỳ ai đang có quyền gì trong hệ thống.

Không ai biết hệ thống đang hoạt động như thế nào. Không có báo cáo định kỳ về chất lượng dữ liệu, mức độ sử dụng hệ thống, hoặc các vấn đề tồn đọng. CEO hoặc COO không có cách nào biết ERP đang thực sự phục vụ doanh nghiệp tốt đến đâu — trừ khi có sự cố lớn.

Các vai trò cần có sau go-live

Governance không có nghĩa là thêm bộ phận mới. Với doanh nghiệp SME, những vai trò dưới đây có thể được giao cho người hiện tại — quan trọng là các vai trò này được định nghĩa rõ ràng, không phải ngầm hiểu.

ERP System Owner

Đây là người chịu trách nhiệm cuối cùng về hệ thống ERP từ góc độ kinh doanh. Không nhất thiết phải là người kỹ thuật — thực ra, System Owner lý tưởng là người hiểu nghiệp vụ và có đủ thẩm quyền để đưa ra quyết định về hệ thống.

Trách nhiệm của System Owner:

• Đưa ra quyết định về những thay đổi lớn trong cấu hình.
• Phê duyệt yêu cầu thêm tính năng hoặc customization mới.
• Chịu trách nhiệm trước ban lãnh đạo về hiệu quả của hệ thống.
• Đảm bảo governance được thực thi theo đúng quy trình.

Master Data Manager

Người chịu trách nhiệm chất lượng và tính nhất quán của dữ liệu nền tảng trong hệ thống — danh mục sản phẩm, nhà cung cấp, khách hàng, chart of accounts.

Với doanh nghiệp nhỏ, vai trò này có thể giao cho một người trong IT hoặc trong bộ phận vận hành có đủ hiểu biết về nghiệp vụ. Điều quan trọng là có một người cụ thể — không phải “mọi người đều chịu trách nhiệm”, vì điều đó thực chất là không ai chịu trách nhiệm.

Key Users / Super Users

Mỗi bộ phận chính nên có ít nhất một Key User — người hiểu hệ thống sâu hơn mức trung bình, là đầu mối nội bộ khi đồng nghiệp gặp vấn đề, và là người phản hồi yêu cầu thay đổi từ phía người dùng lên ERP System Owner.

Key User không thay thế được IT support, nhưng giảm đáng kể gánh nặng cho IT và tăng tốc độ giải quyết vấn đề hàng ngày.

IT / System Administrator

Người chịu trách nhiệm kỹ thuật: hạ tầng, backup, bảo mật, quản lý người dùng, và thực hiện các thay đổi cấu hình được phê duyệt bởi System Owner. Với doanh nghiệp sử dụng cloud ERP, vai trò này có thể mỏng hơn — nhưng vẫn cần có người được chỉ định rõ ràng.

Governance structure cho SME: không cần phức tạp

Governance không phải là bộ máy hành chính. Với doanh nghiệp SME, một governance structure đơn giản và thực tế có thể bao gồm:

Change Management Process. Bất kỳ yêu cầu thay đổi nào đối với hệ thống — thêm tính năng, thay đổi cấu hình, tạo báo cáo mới — đều phải đi qua một quy trình: ai yêu cầu, ai đánh giá impact, ai phê duyệt, ai thực hiện, ai kiểm tra kết quả. Không phải quy trình phức tạp — nhưng phải có quy trình, không phải “ai muốn làm gì thì làm”.

Master Data Governance. Quy trình rõ ràng để thêm, chỉnh sửa và vô hiệu hóa bản ghi master data. Bao gồm: ai được phép yêu cầu, ai phê duyệt, và ai thực hiện. Định kỳ kiểm tra chất lượng master data — ví dụ hàng quý — và xử lý các bản ghi lỗi thời hoặc trùng lặp.

User Access Management. Quy trình cấp quyền cho nhân viên mới (dựa trên vai trò, không phải yêu cầu riêng lẻ) và thu hồi quyền khi nhân viên nghỉ việc. Kiểm tra định kỳ danh sách người dùng và quyền truy cập — tối thiểu hàng năm.

Periodic Health Check. Định kỳ — tối thiểu hàng quý — ERP System Owner xem xét: dữ liệu có đang được duy trì đúng không, các vấn đề tồn đọng là gì, hệ thống đang được dùng đúng mục đích ở mức nào, và có thay đổi nghiệp vụ nào cần phản ánh vào cấu hình ERP không.

Escalation Path rõ ràng. Khi người dùng gặp vấn đề, họ biết phải liên hệ ai, qua kênh nào, và trong bao lâu sẽ được phản hồi. Không phải “hỏi sếp rồi sếp hỏi IT rồi IT hỏi nhà triển khai rồi nhà triển khai hỏi lại”.

Governance bắt đầu trước go-live

Một trong những sai lầm phổ biến nhất: nghĩ rằng governance là thứ có thể thiết lập sau go-live.

Thực tế: governance cần được lên kế hoạch và một phần được thiết lập trước go-live — ít nhất là xác định rõ ai sẽ là System Owner, ai là Master Data Manager, và quy trình Change Request sau go-live là gì.

Lý do: ngay từ những tuần đầu sau go-live, các quyết định về hệ thống sẽ được đưa ra — dù có governance hay không. Nếu không có governance, những quyết định đó sẽ được đưa ra theo kiểu ad hoc, không nhất quán, và thường không được tài liệu hóa. Đảo ngược những quyết định đó sau này rất khó.

Tự đánh giá: ERP governance của bạn đang ở đâu?

• Có ai được chỉ định rõ ràng là ERP System Owner — người có thẩm quyền quyết định về hệ thống và chịu trách nhiệm trước lãnh đạo không?
• Có người cụ thể chịu trách nhiệm chất lượng master data không?
• Khi người dùng gặp vấn đề với ERP, họ biết liên hệ ai và qua kênh nào không?
• Có quy trình rõ ràng để xử lý yêu cầu thay đổi cấu hình không?
• Khi nhân viên nghỉ việc, tài khoản ERP của họ được xử lý như thế nào và trong bao lâu?
• Lần cuối ai đó kiểm tra chất lượng dữ liệu trong ERP là khi nào?

Nếu nhiều câu trả lời là “không rõ” hoặc “chưa có” — đó là khoảng trống governance cần được điền vào, dù hệ thống đã go-live bao lâu rồi.

Bước tiếp theo trong chuỗi: Sau ERP — doanh nghiệp cần làm gì để khai thác dữ liệu ERP?

→ Làm ERP Readiness Assessment

Bài viết này là một phần của chuỗi chuyên đề về ERP readiness cho doanh nghiệp sản xuất SME.

Bài liên quan:

• Tại sao dự án ERP không đạt mục tiêu — pillar
• Customization ERP: ranh giới giữa linh hoạt và rủi ro
• Sau ERP: doanh nghiệp cần làm gì để khai thác dữ liệu ERP?