Tác động từ chính trị nội bộ đến một dự án ERP

Khi một dự án ERP chậm tiến độ, vượt ngân sách hoặc không đạt được tỷ lệ sử dụng như kỳ vọng, doanh nghiệp thường tìm nguyên nhân ở phần mềm, khả năng tích hợp hoặc năng lực của đơn vị triển khai.

Tuy nhiên, trong nhiều trường hợp, vấn đề thực sự không bắt đầu từ công nghệ.

ERP làm thay đổi cách doanh nghiệp vận hành, cách dữ liệu được chia sẻ, cách hiệu suất được đo lường và cách quyền ra quyết định được phân bổ. Vì vậy, dự án có thể nhanh chóng làm bộc lộ những xung đột vốn đã tồn tại giữa các phòng ban, cấp quản lý và đơn vị thành viên.

Điều này đặc biệt phổ biến tại các doanh nghiệp Việt Nam đang chuyển đổi từ mô hình quản trị dựa nhiều vào kinh nghiệm cá nhân, bảng tính và trao đổi không chính thức sang một hệ thống có quy trình, dữ liệu và trách nhiệm rõ ràng hơn.

Khi mục tiêu chưa được thống nhất, lãnh đạo thiếu cam kết hoặc từng bộ phận cố gắng bảo vệ quy trình và quyền kiểm soát hiện tại, ngay cả một giải pháp ERP phù hợp về mặt kỹ thuật cũng khó phát huy giá trị.

Chính trị nội bộ trong triển khai ERP là gì?

Trong bối cảnh triển khai ERP, chính trị nội bộ không chỉ đề cập đến mâu thuẫn cá nhân hoặc cạnh tranh chức vụ. Khái niệm này bao gồm những hành vi và quyết định xuất phát từ việc các cá nhân hoặc phòng ban muốn bảo vệ:

• Quyền kiểm soát dữ liệu.
• Quyền sở hữu quy trình.
• Ngân sách của phòng ban.
• Quyền phê duyệt và ra quyết định.
• Chỉ tiêu hiệu suất hiện tại.
• Phạm vi trách nhiệm và ảnh hưởng trong tổ chức.
• Các công cụ hoặc phương pháp làm việc đã quen sử dụng.

Ví dụ, phòng Tài chính có thể muốn bổ sung nhiều bước phê duyệt để tăng khả năng kiểm soát chi phí. Trong khi đó, phòng Kinh doanh muốn rút ngắn quy trình để đẩy nhanh thời gian báo giá, xác nhận đơn hàng và giao hàng cho khách.

Cả hai yêu cầu đều có cơ sở nghiệp vụ. Vấn đề xuất hiện khi mỗi phòng ban chỉ bảo vệ lợi ích của mình mà không dựa trên mục tiêu vận hành chung của doanh nghiệp.

Lúc này, câu hỏi ERP nên được cấu hình như thế nào không còn đơn thuần là một câu hỏi kỹ thuật. Nó trở thành vấn đề về việc mục tiêu nào được ưu tiên, ai có quyền quyết định và phòng ban nào phải thay đổi cách làm việc.

Vì sao ERP dễ làm bộc lộ xung đột trong doanh nghiệp Việt Nam?

ERP khác với một ứng dụng riêng lẻ vì hệ thống kết nối nhiều phòng ban và quy trình trên cùng một nền tảng. Một quyết định được đưa ra tại bộ phận này có thể trực tiếp ảnh hưởng đến hoạt động của bộ phận khác. Chẳng hạn:

• Cách phòng Kinh doanh tạo đơn hàng ảnh hưởng đến kế hoạch tồn kho và giao hàng.
• Cách bộ phận Kho xác nhận nhập xuất ảnh hưởng đến số liệu kế toán.
• Cách phòng Mua hàng quản lý nhà cung cấp ảnh hưởng đến dòng tiền và công nợ.
• Cách bộ phận Sản xuất ghi nhận nguyên vật liệu ảnh hưởng đến giá thành.
• Cách phân quyền dữ liệu ảnh hưởng đến khả năng kiểm soát của cấp quản lý.
• Cách các chi nhánh nhập liệu ảnh hưởng đến báo cáo hợp nhất toàn doanh nghiệp.

Trong nhiều doanh nghiệp Việt Nam, các phòng ban đã quen vận hành tương đối độc lập. Mỗi bộ phận có thể sử dụng một file Excel, một phần mềm riêng hoặc một cách đặt mã dữ liệu khác nhau.

Một số quy trình phê duyệt còn được thực hiện qua email, Zalo, điện thoại hoặc chỉ dựa trên trao đổi trực tiếp. Khi ERP yêu cầu các bước này phải được chuẩn hóa và ghi nhận trên hệ thống, những điểm chưa rõ ràng về quyền hạn và trách nhiệm sẽ xuất hiện.

ERP cũng tạo ra mức độ minh bạch cao hơn. Các giao dịch được ghi nhận theo người thực hiện, thời điểm, trạng thái và luồng phê duyệt. Những thao tác thủ công, dữ liệu trùng lặp, quy trình không chính thức hoặc ngoại lệ trước đây có thể được nhìn thấy rõ hơn.

Đối với một số cá nhân hoặc phòng ban, sự minh bạch này có thể được nhìn nhận như việc mất quyền kiểm soát. Đây là lý do xung đột thường xuất hiện ngay từ giai đoạn khảo sát yêu cầu, trước khi hệ thống được cấu hình hoặc đưa vào sử dụng.

Những biểu hiện phổ biến của chính trị nội bộ trong dự án ERP

Kháng cự thay đổi để bảo vệ cách làm hiện tại

Không phải mọi sự phản đối ERP đều xuất phát từ việc người dùng không hiểu công nghệ.

Một số nhân sự có thể lo ngại rằng tự động hóa sẽ làm giảm vai trò của họ. Một số quản lý lại sợ mất quyền kiểm soát khi dữ liệu, báo cáo và quy trình được chuyển sang một nền tảng chung.

Sự kháng cự có thể biểu hiện dưới nhiều hình thức:

• Trì hoãn cung cấp yêu cầu.
• Không tham gia đầy đủ các buổi khảo sát.
• Không chuẩn bị dữ liệu đúng thời hạn.
• Từ chối kiểm thử hệ thống.
• Tiếp tục sử dụng Excel hoặc phần mềm cũ.
• Cho rằng mọi quy trình hiện tại đều là đặc thù không thể thay đổi.
• Chỉ nêu vấn đề sau khi cấu hình đã hoàn tất.
• Yêu cầu hệ thống mới phải hoạt động hoàn toàn giống hệ thống cũ.

Trong thực tế, một nhân sự có thể đang nắm giữ nhiều thông tin quan trọng mà doanh nghiệp chưa chuẩn hóa thành quy trình. Khi ERP được triển khai, kiến thức này phải được chuyển hóa thành dữ liệu, quy tắc và trách nhiệm rõ ràng.

Điều đó có thể khiến người đang nắm thông tin cảm thấy vai trò của mình bị giảm đi. Nếu doanh nghiệp không nhận diện được mối lo này, vấn đề con người rất dễ bị hiểu nhầm thành vấn đề tính năng.

Tranh chấp quyền sở hữu quy trình

ERP yêu cầu doanh nghiệp xác định rõ ai chịu trách nhiệm cho từng quy trình xuyên phòng ban.

Ví dụ, quy trình từ báo giá đến thu tiền có thể liên quan đến Kinh doanh, Kho, Vận chuyển, Kế toán và Quản lý công nợ. Khi quy trình gặp sự cố, doanh nghiệp cần biết ai có quyền quyết định và ai chịu trách nhiệm cuối cùng.

Trong nhiều tổ chức, quyền sở hữu quy trình chưa được xác định rõ. Mỗi trưởng bộ phận chỉ chịu trách nhiệm cho một phần công việc, nhưng không có cá nhân nào chịu trách nhiệm cho kết quả đầu cuối.

Điều này có thể dẫn đến các tình trạng:

• Quyết định bị trì hoãn.
• Yêu cầu liên tục thay đổi.
• Các phòng ban đưa ra chỉ đạo trái ngược.
• Đối tác triển khai không có cơ sở để chốt thiết kế.
• Một vấn đề đã thống nhất nhiều lần vẫn bị mở lại.
• Các bộ phận đổ lỗi cho nhau khi quy trình phát sinh lỗi.

Đây không phải là vấn đề mà đội kỹ thuật có thể tự giải quyết. Doanh nghiệp cần chỉ định người sở hữu quy trình có đủ thẩm quyền để đưa ra quyết định cuối cùng.

Thiếu hợp tác giữa các phòng ban

ERP được triển khai để kết nối hoạt động, nhưng nhiều doanh nghiệp vẫn tiếp cận dự án theo từng phòng ban riêng biệt.

Mỗi bộ phận xây dựng danh sách yêu cầu riêng mà không đánh giá tác động đến toàn bộ chuỗi vận hành. Kết quả là doanh nghiệp có thể tạo ra một hệ thống gồm nhiều quy trình rời rạc thay vì một nền tảng quản trị thống nhất.

Tình trạng này thường thể hiện khi các phòng ban:

• Không muốn chia sẻ dữ liệu.
• Sử dụng định nghĩa KPI khác nhau.
• Không thống nhất mã khách hàng, sản phẩm hoặc nhà cung cấp.
• Đưa ra yêu cầu tối ưu cho bộ phận mình nhưng làm quy trình tổng thể phức tạp hơn.
• Ưu tiên sự thuận tiện của phòng ban thay vì hiệu quả chung.
• Không thống nhất cách xử lý một giao dịch xuyên suốt từ đầu đến cuối.

Ví dụ, phòng Kinh doanh có thể muốn tạo sản phẩm mới nhanh chóng để làm báo giá. Trong khi đó, phòng Kho và Kế toán cần các thông tin bắt buộc như đơn vị tính, nhóm hàng, phương pháp định giá và tài khoản kế toán.

Nếu mỗi phòng ban chỉ tập trung vào phần việc của mình, dữ liệu sản phẩm sẽ thiếu nhất quán và gây lỗi ở các công đoạn sau.

Tranh chấp ngân sách và nguồn lực

Triển khai ERP không chỉ cần ngân sách mua phần mềm hoặc trả phí triển khai. Dự án còn cần thời gian của nhân sự chủ chốt, nguồn lực làm sạch dữ liệu, kiểm thử, đào tạo và hỗ trợ người dùng.

Trong doanh nghiệp Việt Nam, nhân sự tham gia dự án thường đồng thời phải hoàn thành công việc vận hành hằng ngày. Nếu lãnh đạo không phân bổ thời gian rõ ràng, các nhiệm vụ ERP thường bị xếp sau công việc hiện tại.

Dự án có thể bị cắt giảm ở những hạng mục quan trọng như:

• Làm sạch dữ liệu.
• Chuẩn hóa danh mục.
• Quản trị thay đổi.
• Đào tạo người dùng.
• Kiểm thử tích hợp.
• Hỗ trợ sau Go-Live.
• Cải tiến quy trình.

Ngược lại, một số phòng ban có thể đề xuất thêm nhiều tính năng nhằm bảo vệ ngân sách hoặc phạm vi ảnh hưởng của mình. Điều này dễ dẫn đến tùy chỉnh quá mức, làm tăng chi phí và kéo dài thời gian triển khai.

Xung đột về quyền sở hữu dữ liệu

Dữ liệu là một trong những vấn đề nhạy cảm nhất của dự án ERP.

Phòng Kinh doanh có thể xem thông tin khách hàng là dữ liệu của mình. Phòng Kho muốn kiểm soát dữ liệu sản phẩm. Phòng Tài chính muốn có quyền quyết định đối với dữ liệu nhà cung cấp, điều khoản thanh toán và tài khoản kế toán.

Các chi nhánh hoặc công ty thành viên cũng có thể không muốn chia sẻ toàn bộ dữ liệu với trụ sở chính vì lo ngại bị kiểm soát chặt hơn.

Nếu không có mô hình quản trị dữ liệu rõ ràng, doanh nghiệp sẽ gặp nhiều câu hỏi khó:

• Ai được phép tạo mới dữ liệu?
• Ai có quyền chỉnh sửa?
• Ai chịu trách nhiệm kiểm tra độ chính xác?
• Dữ liệu nào là nguồn chính thức?
• Bộ phận nào xử lý dữ liệu trùng lặp?
• Ai phê duyệt thay đổi thông tin quan trọng?
• Chi nhánh được quyền quản lý dữ liệu ở mức nào?
• Trụ sở chính được xem và điều chỉnh những dữ liệu nào?

Quyền sở hữu dữ liệu không nên được hiểu là quyền giữ dữ liệu trong phạm vi phòng ban. Data Owner có trách nhiệm đảm bảo chất lượng và tiêu chuẩn dữ liệu, nhưng dữ liệu phải phục vụ hoạt động chung của doanh nghiệp.

Quyết định phụ thuộc quá nhiều vào một cá nhân

Tại nhiều doanh nghiệp Việt Nam, đặc biệt là doanh nghiệp vừa và nhỏ hoặc doanh nghiệp gia đình, các quyết định quan trọng thường tập trung vào chủ doanh nghiệp hoặc một số lãnh đạo cấp cao.

Mô hình này có thể giúp doanh nghiệp ra quyết định nhanh trong hoạt động thường ngày. Tuy nhiên, đối với dự án ERP, sự phụ thuộc quá lớn vào một cá nhân có thể tạo ra điểm nghẽn.

Ví dụ:

• Mọi yêu cầu đều phải chờ Tổng giám đốc phê duyệt.
• Các trưởng phòng không dám chốt quy trình.
• Quyết định đã được thống nhất có thể thay đổi sau một trao đổi riêng với lãnh đạo.
• Đội dự án không biết ý kiến nào là quyết định cuối cùng.
• Các phòng ban tìm cách tác động trực tiếp đến người có quyền cao nhất.

Lãnh đạo cấp cao vẫn cần đóng vai trò bảo trợ dự án, nhưng doanh nghiệp phải phân quyền quyết định phù hợp cho Ban chỉ đạo, Project Manager và Process Owner.

Thiếu sự bảo trợ thực chất từ lãnh đạo

Một dự án ERP không thể được điều hành chỉ bằng sự ủng hộ mang tính hình thức. Lãnh đạo bảo trợ dự án cần có đủ thẩm quyền để:

• Đưa ra định hướng chung.
• Phân bổ nguồn lực.
• Giải quyết xung đột liên phòng ban.
• Chốt những quyết định còn tranh cãi.
• Yêu cầu các bên chịu trách nhiệm.
• Bảo vệ mục tiêu tổng thể của dự án.
• Ngăn các bộ phận trì hoãn hoặc không hợp tác.

Nếu lãnh đạo chỉ tham gia buổi khởi động nhưng vắng mặt trong các quyết định quan trọng, dự án sẽ thiếu một cơ chế phân xử đủ mạnh.

Khi đó, các trưởng phòng có thể tiếp tục tranh luận theo lợi ích riêng, trong khi đội dự án và đối tác triển khai không có thẩm quyền quyết định thay cho doanh nghiệp.

Truyền thông không minh bạch

Khoảng trống thông tin dễ làm phát sinh tin đồn và tâm lý phản đối. Khi doanh nghiệp không giải thích rõ lý do triển khai ERP, người dùng có thể tự hình thành các giả định như:

• ERP được triển khai để cắt giảm nhân sự.
• Hệ thống được dùng để giám sát nhân viên.
• Một số phòng ban sẽ mất quyền kiểm soát.
• Lãnh đạo đã quyết định mọi thứ mà không tham khảo người dùng.
• Đơn vị triển khai đang áp đặt quy trình.
• Mọi thao tác của nhân viên sẽ bị đánh giá thông qua hệ thống.

Truyền thông không nhất quán cũng khiến các cấp quản lý hiểu khác nhau về phạm vi, thời gian và mục tiêu dự án. Khi thông tin được truyền qua nhiều lớp, yêu cầu cuối cùng có thể khác hoàn toàn với quyết định ban đầu.

Doanh nghiệp cần truyền thông rõ rằng mục tiêu của ERP là cải thiện khả năng phối hợp, kiểm soát và ra quyết định, không phải chỉ để giám sát từng cá nhân.

Cản trở đào tạo và quản trị thay đổi

Một số doanh nghiệp xem đào tạo là hoạt động diễn ra ngay trước thời điểm Go-Live.

Trên thực tế, quản trị thay đổi cần được bắt đầu từ sớm, khi doanh nghiệp xác định những nhóm người dùng bị ảnh hưởng, quy trình nào sẽ thay đổi và năng lực nào cần được xây dựng.

Chính trị nội bộ có thể làm suy yếu hoạt động này khi:

• Quản lý không bố trí thời gian để nhân sự tham gia đào tạo.
• Key User được lựa chọn dựa trên chức danh thay vì năng lực và mức độ cam kết.
• Các phòng ban không muốn công khai những hạn chế của quy trình hiện tại.
• Người dùng phản đối hệ thống nhưng không có kênh phản hồi chính thức.
• Đội dự án tập trung vào cấu hình mà bỏ qua sự sẵn sàng của tổ chức.
• Một số nhân sự giữ thông tin cho riêng mình thay vì chuyển giao cho đội dự án.

Nếu người dùng không hiểu quy trình mới và lý do phải thay đổi, họ sẽ có xu hướng quay lại sử dụng công cụ cũ sau khi hệ thống Go-Live.

Duy trì Excel, Zalo và quy trình ngoài hệ thống

Một trong những biểu hiện rõ nhất của sự kháng cự là người dùng vẫn duy trì các công cụ song song sau khi ERP được đưa vào vận hành.

Ví dụ:

• Đơn hàng được tạo trên ERP nhưng vẫn theo dõi thêm bằng Excel.
• Phê duyệt được xác nhận qua Zalo rồi mới nhập lại vào hệ thống.
• Báo cáo quản trị tiếp tục được tổng hợp thủ công.
• Dữ liệu tồn kho trên ERP không được tin tưởng nên bộ phận Kho duy trì một file riêng.
• Các chi nhánh gửi số liệu qua email thay vì cập nhật trực tiếp.

Khi đó, ERP không trở thành nguồn dữ liệu thống nhất. Doanh nghiệp vừa phải duy trì hệ thống mới, vừa tiếp tục chịu rủi ro từ các phương pháp cũ.

Vấn đề không nhất thiết nằm ở phần mềm. Nguyên nhân có thể đến từ việc quy trình chưa phù hợp, người dùng chưa được đào tạo hoặc quản lý chưa yêu cầu các bộ phận tuân thủ hệ thống chung.

>>> Xem thêm: Vì sao nhân viên vẫn dùng Excel sau khi doanh nghiệp đã triển khai ERP?

Lựa chọn giải pháp dựa trên ảnh hưởng nội bộ

Quyết định lựa chọn ERP hoặc đối tác triển khai đôi khi bị chi phối bởi kinh nghiệm cá nhân, quan hệ hoặc sở thích của một phòng ban.

Ví dụ, một bộ phận có thể muốn giữ lại phần mềm hiện tại vì đã quen sử dụng. Một quản lý khác lại muốn chọn hệ thống từng dùng tại công ty cũ, dù chưa chắc phù hợp với mô hình vận hành hiện tại.

Khi tiêu chí lựa chọn không được chuẩn hóa, doanh nghiệp có nguy cơ:

• Chọn hệ thống theo danh tiếng thay vì mức độ phù hợp.
• Đánh giá quá cao một số tính năng riêng lẻ.
• Bỏ qua tổng chi phí sở hữu.
• Không xem xét khả năng mở rộng và tích hợp.
• Chọn đối tác dựa trên quan hệ thay vì phương pháp triển khai.
• Đưa ra quyết định kỹ thuật để giải quyết một xung đột tổ chức.

Doanh nghiệp nên xây dựng bộ tiêu chí đánh giá minh bạch, bao gồm mức độ phù hợp quy trình, khả năng tích hợp, năng lực triển khai, chi phí dài hạn và khả năng hỗ trợ sau Go-Live.

Hậu quả của việc bỏ qua chính trị nội bộ

Dự án bị trì hoãn

Tranh luận kéo dài về yêu cầu, phạm vi, quyền truy cập hoặc cách thiết kế quy trình có thể làm chậm toàn bộ kế hoạch.

Thời gian của đội dự án bị tiêu tốn cho việc tổ chức lại workshop, xác nhận lại quyết định và chỉnh sửa những cấu hình đã hoàn thành.

Phạm vi liên tục mở rộng

Mỗi phòng ban có thể bổ sung yêu cầu để bảo vệ cách làm hiện tại. Nếu không có cơ chế đánh giá lợi ích, dự án sẽ dần tích lũy nhiều tính năng và tùy chỉnh không thực sự cần thiết.

Scope Creep không chỉ làm tăng chi phí mà còn khiến hệ thống khó nâng cấp, khó bảo trì và phức tạp hơn đối với người dùng.

Chất lượng dữ liệu suy giảm

Nếu các phòng ban không thống nhất quyền sở hữu và tiêu chuẩn dữ liệu, dữ liệu được chuyển sang ERP có thể tiếp tục trùng lặp, thiếu thông tin hoặc không nhất quán.

Hệ thống mới khi đó chỉ tập trung những vấn đề cũ vào cùng một nền tảng.

Người dùng duy trì hệ thống song song

Một số bộ phận có thể tiếp tục sử dụng bảng tính hoặc phần mềm cũ để giữ quyền kiểm soát. Điều này tạo ra nhiều nguồn dữ liệu, làm giảm độ tin cậy của báo cáo và khiến doanh nghiệp không khai thác được giá trị của ERP.

Dữ liệu trên ERP không được tin tưởng

Khi quy trình nhập liệu không được tuân thủ hoặc dữ liệu không có người chịu trách nhiệm, lãnh đạo có thể tiếp tục yêu cầu báo cáo thủ công.

Điều này tạo thành một vòng lặp: người dùng không tin ERP nên duy trì Excel, nhưng chính việc duy trì Excel lại khiến dữ liệu ERP không đầy đủ và kém tin cậy.

Dự án không có chủ thể chịu trách nhiệm

Khi quyết định được đưa ra theo thỏa hiệp nhưng không có người chịu trách nhiệm cuối cùng, mọi vấn đề sau đó dễ bị chuyển thành lỗi của hệ thống hoặc lỗi của nhà cung cấp.

Trong trường hợp nghiêm trọng, xung đột không được giải quyết có thể khiến dự án bị đình trệ, phải triển khai lại hoặc không được người dùng chấp nhận sau Go-Live.

Những dấu hiệu cảnh báo doanh nghiệp cần nhận biết

Dấu hiệu trong dự án	Vấn đề tiềm ẩn
Một yêu cầu đã thống nhất liên tục bị mở lại	Không có quyền quyết định rõ ràng
Mỗi phòng ban có một phiên bản dữ liệu khác nhau	Tranh chấp quyền sở hữu dữ liệu
Mọi quy trình đều được xem là đặc thù	Các bộ phận muốn bảo vệ cách làm hiện tại
Key User thường xuyên vắng mặt	Dự án không được ưu tiên đủ cao
Lãnh đạo tránh đưa ra quyết định cuối cùng	Vai trò bảo trợ dự án chưa hiệu quả
Yêu cầu tùy chỉnh tăng nhanh nhưng không có Business Case	Phòng ban đang bảo vệ lợi ích riêng
Người dùng tiếp tục vận hành bằng Excel	Mức độ chấp nhận hệ thống thấp
Phê duyệt vẫn được thực hiện qua Zalo hoặc email	Quy trình trên ERP chưa được tuân thủ
Các phòng ban đổ lỗi cho nhau hoặc cho đối tác	Thiếu cơ chế chịu trách nhiệm
UAT diễn ra hình thức, ít phản hồi thực tế	Người dùng chưa được tham gia hoặc chưa sẵn sàng
Quyền truy cập được thiết kế theo từng cá nhân	Chưa có nguyên tắc quản trị dữ liệu
Mọi quyết định đều phải chờ một lãnh đạo	Phân quyền dự án chưa phù hợp

Phát hiện các dấu hiệu này sớm giúp doanh nghiệp xử lý vấn đề ở cấp quản trị thay vì liên tục yêu cầu đội kỹ thuật chỉnh sửa hệ thống.

Cách kiểm soát chính trị nội bộ trong dự án ERP

Xác định mục tiêu chung cho dự án

Doanh nghiệp cần thống nhất ERP được triển khai để đạt kết quả gì ở cấp tổ chức. Mục tiêu không nên chỉ là thay phần mềm hoặc số hóa quy trình. Mục tiêu cần được chuyển thành các kết quả có thể đo lường, chẳng hạn:

• Rút ngắn thời gian khóa sổ.
• Tăng độ chính xác tồn kho.
• Giảm thao tác nhập liệu trùng lặp.
• Chuẩn hóa quy trình giữa các chi nhánh.
• Tăng khả năng kiểm soát phê duyệt.
• Cung cấp báo cáo quản trị kịp thời.
• Tạo một nguồn dữ liệu thống nhất.
• Hỗ trợ doanh nghiệp đáp ứng yêu cầu về hóa đơn điện tử, thuế và báo cáo tài chính.

Khi có xung đột, các phương án phải được đánh giá dựa trên mục tiêu chung này thay vì quyền lợi của từng phòng ban.

Thiết lập lãnh đạo bảo trợ có đủ thẩm quyền

Lãnh đạo bảo trợ không nhất thiết phải tham gia mọi cuộc họp, nhưng phải xuất hiện tại những thời điểm cần quyết định.

Người bảo trợ dự án cần:

• Hiểu mục tiêu kinh doanh của chương trình ERP.
• Có quyền điều phối nguồn lực giữa các phòng ban.
• Giải quyết các vấn đề vượt thẩm quyền của Project Manager.
• Duy trì trách nhiệm của các trưởng bộ phận.
• Bảo vệ những quyết định đã được thống nhất.
• Ngăn phạm vi dự án bị điều chỉnh vì lợi ích cục bộ.

Tại doanh nghiệp gia đình, lãnh đạo bảo trợ thường là chủ doanh nghiệp hoặc Tổng giám đốc. Tuy nhiên, người này cần phân quyền rõ ràng để đội dự án có thể xử lý các quyết định vận hành hằng ngày mà không phải chờ phê duyệt cho mọi vấn đề.

Xây dựng cơ cấu quản trị và quyền quyết định

Doanh nghiệp nên thiết lập cơ cấu quản trị gồm:

• Ban chỉ đạo dự án.
• Lãnh đạo bảo trợ.
• Project Manager phía doanh nghiệp.
• Project Manager phía đối tác triển khai.
• Process Owner.
• Data Owner.
• Key User.
• Đội kỹ thuật và tích hợp.

Đối với từng loại quyết định, cần xác định rõ:

• Ai đề xuất?
• Ai tư vấn?
• Ai phê duyệt?
• Ai thực hiện?
• Ai cần được thông báo?
• Thời hạn đưa ra quyết định là bao lâu?
• Vấn đề được escalated theo cơ chế nào?

Một ma trận RACI rõ ràng giúp giảm tình trạng nhiều người cùng tham gia nhưng không ai thực sự chịu trách nhiệm.

Tổ chức khảo sát theo quy trình xuyên phòng ban

Thay vì chỉ tổ chức workshop riêng cho từng bộ phận, doanh nghiệp nên khảo sát theo các chuỗi quy trình như:

• Lead-To-Cash.
• Procure-To-Pay.
• Plan-To-Produce.
• Order-To-Delivery.
• Record-To-Report.
• Hire-To-Retire.

Cách tiếp cận này giúp các phòng ban nhìn thấy tác động qua lại giữa các hoạt động.

Một thay đổi giúp phòng ban này tiết kiệm vài bước nhưng tạo thêm nhiều thao tác cho phòng ban khác sẽ được nhận diện sớm hơn.

Đây cũng là cơ hội để doanh nghiệp xác định những bước nào thực sự tạo ra giá trị và những bước nào chỉ tồn tại vì thói quen hoặc lịch sử vận hành.

Phân loại yêu cầu theo giá trị kinh doanh

Không phải mọi yêu cầu đều có mức độ ưu tiên ngang nhau.

Doanh nghiệp có thể phân loại yêu cầu thành:

• Bắt buộc để tuân thủ pháp luật.
• Bắt buộc để duy trì hoạt động.
• Tạo ra giá trị kinh doanh rõ ràng.
• Cải thiện trải nghiệm người dùng.
• Có thể triển khai trong giai đoạn sau.
• Chỉ nhằm duy trì thói quen hiện tại.

Mỗi yêu cầu tùy chỉnh nên có Business Case, người sở hữu và tác động cụ thể.

Nếu một yêu cầu chỉ nhằm giữ nguyên cách làm trên Excel hoặc phần mềm cũ, doanh nghiệp cần đánh giá lại liệu quy trình đó có thực sự cần thiết hay không.

Thiết lập quản trị dữ liệu từ đầu

Doanh nghiệp cần xác định Data Owner đối với từng nhóm dữ liệu chính:

• Khách hàng.
• Nhà cung cấp.
• Sản phẩm.
• Bảng giá.
• Tài khoản kế toán.
• Trung tâm chi phí.
• Nhân sự.
• Tài sản.
• Định mức và cấu trúc sản xuất.

Data Owner chịu trách nhiệm về tiêu chuẩn, độ chính xác và quy trình thay đổi dữ liệu, nhưng dữ liệu vẫn phải phục vụ mục tiêu chung của toàn doanh nghiệp.

Doanh nghiệp cũng cần quy định rõ:

• Tiêu chuẩn đặt mã.
• Trường dữ liệu bắt buộc.
• Quy trình tạo mới và phê duyệt.
• Cách xử lý dữ liệu trùng lặp.
• Quyền truy cập theo vai trò.
• Chính sách lưu trữ và bảo mật dữ liệu.

Truyền thông theo từng nhóm đối tượng

Thông điệp dành cho lãnh đạo không thể giống với thông điệp dành cho người dùng vận hành.

Doanh nghiệp nên giải thích rõ:

• Vì sao cần triển khai ERP?
• Những quy trình nào sẽ thay đổi?
• Những quy trình nào không thay đổi?
• Người dùng được lợi gì?
• Vai trò nào có thể thay đổi?
• Ai là người hỗ trợ khi có vướng mắc?
• Phản hồi được tiếp nhận và xử lý như thế nào?
• ERP có thay thế Excel và các phương thức phê duyệt ngoài hệ thống hay không?

Truyền thông cần được thực hiện liên tục, không chỉ tại buổi Kick-Off hoặc ngay trước Go-Live.

Đầu tư vào quản trị thay đổi và đào tạo

Đào tạo không nên chỉ hướng dẫn người dùng bấm nút trên hệ thống.

Chương trình cần giúp người dùng hiểu:

• Quy trình mới hoạt động như thế nào?
• Vì sao quy trình được thay đổi?
• Dữ liệu họ nhập ảnh hưởng đến phòng ban nào?
• Trách nhiệm của từng vai trò là gì?
• Những lỗi nào cần tránh?
• Tình huống ngoại lệ được xử lý ra sao?
• Khi nào được phép xử lý ngoài quy trình tiêu chuẩn?

Key User cần được lựa chọn dựa trên kiến thức nghiệp vụ, khả năng phối hợp và mức độ cam kết, không chỉ dựa trên chức danh.

Sau đào tạo, doanh nghiệp nên đánh giá lại khả năng sử dụng của từng nhóm người dùng thay vì chỉ ghi nhận số lượng người đã tham dự.

Lưu trữ quyết định và kiểm soát thay đổi

Mỗi quyết định quan trọng nên được ghi nhận trong Decision Log, bao gồm:

• Vấn đề cần quyết định.
• Các phương án đã xem xét.
• Người phê duyệt.
• Lý do lựa chọn.
• Tác động đến phạm vi và ngân sách.
• Ngày quyết định.
• Điều kiện để xem xét lại.

Khi một bên muốn thay đổi quyết định, yêu cầu cần được xử lý qua Change Request thay vì đưa ra chỉ đạo không chính thức cho đội triển khai.

Cơ chế này đặc biệt quan trọng trong môi trường mà các quyết định có thể được thay đổi sau những cuộc trao đổi riêng giữa quản lý và lãnh đạo.

Thiết lập nguyên tắc ngừng sử dụng hệ thống cũ

Nếu doanh nghiệp không xác định thời điểm và điều kiện ngừng sử dụng Excel, phần mềm cũ hoặc các luồng phê duyệt qua Zalo, người dùng sẽ có xu hướng duy trì cả hai hệ thống.

Doanh nghiệp cần quy định rõ:

• Ngày ngừng nhập dữ liệu vào hệ thống cũ.
• Nguồn dữ liệu nào được xem là chính thức.
• Báo cáo nào phải được lấy từ ERP.
• Những ngoại lệ nào được phép xử lý ngoài hệ thống.
• Ai có quyền phê duyệt ngoại lệ.
• Cách kiểm tra việc tuân thủ sau Go-Live.

Trong một số trường hợp, doanh nghiệp có thể duy trì hệ thống cũ trong giai đoạn chuyển tiếp. Tuy nhiên, thời gian chuyển tiếp phải có giới hạn và kế hoạch kết thúc cụ thể.

Góc nhìn thực tiễn khi triển khai Odoo ERP

Odoo cung cấp khả năng cấu hình và tùy chỉnh linh hoạt. Đây là một lợi thế lớn, nhưng cũng có thể khiến doanh nghiệp dễ chuyển mọi bất đồng tổ chức thành yêu cầu phát triển phần mềm.

Ví dụ, khi hai phòng ban không thống nhất quy trình phê duyệt, giải pháp không nhất thiết là xây dựng hai luồng hoàn toàn khác nhau. Doanh nghiệp cần xác định nguyên tắc kiểm soát, mức độ rủi ro và người có quyền quyết định trước khi cấu hình hệ thống.

Tương tự, nếu các chi nhánh sử dụng nhiều cách đặt mã sản phẩm khác nhau, việc đưa toàn bộ cách đặt mã cũ lên Odoo sẽ không giải quyết được vấn đề. Doanh nghiệp cần thống nhất quy chuẩn dữ liệu trước khi di chuyển.

Một tình huống phổ biến khác là doanh nghiệp yêu cầu Odoo tạo ra nhiều bước ngoại lệ vì trước đây mọi vấn đề đều có thể được xử lý thông qua trao đổi trực tiếp với quản lý. Nếu tất cả ngoại lệ được đưa vào hệ thống mà không có nguyên tắc rõ ràng, quy trình sẽ trở nên phức tạp và khó kiểm soát.

Vì vậy, một dự án Odoo hiệu quả cần cân bằng ba yếu tố:

• Khả năng tiêu chuẩn hóa quy trình.
• Mức độ linh hoạt cần thiết cho hoạt động kinh doanh.
• Khả năng quản trị và duy trì hệ thống trong dài hạn.

Đối tác triển khai có thể đề xuất phương án kỹ thuật, phân tích tác động và hỗ trợ điều phối workshop. Tuy nhiên, các quyết định về chính sách, quyền hạn và trách nhiệm vẫn phải được doanh nghiệp đưa ra.

Không một hệ thống ERP nào có thể tự giải quyết một xung đột tổ chức mà ban lãnh đạo chưa sẵn sàng xử lý.

Vai trò của đối tác triển khai ERP

Một đối tác triển khai ERP phù hợp không chỉ tiếp nhận danh sách yêu cầu và cấu hình phần mềm.

Đối tác cần giúp doanh nghiệp:

• Làm rõ mục tiêu kinh doanh.
• Nhận diện xung đột giữa các yêu cầu.
• Phân tích tác động xuyên phòng ban.
• Xây dựng lộ trình triển khai phù hợp.
• Đề xuất quy trình chuẩn trước khi tùy chỉnh.
• Thiết lập cơ chế quản trị phạm vi.
• Hỗ trợ kiểm thử, đào tạo và chuyển đổi người dùng.
• Đưa ra góc nhìn khách quan khi các bên chưa thống nhất.
• Nhận diện những yêu cầu xuất phát từ nhu cầu nghiệp vụ và những yêu cầu chỉ nhằm duy trì thói quen cũ.

Tuy nhiên, đối tác triển khai không nên được đặt vào vị trí phân xử thay cho lãnh đạo doanh nghiệp.

Khi một vấn đề liên quan đến quyền phê duyệt, quyền sở hữu dữ liệu hoặc trách nhiệm giữa các phòng ban, đối tác chỉ có thể trình bày các phương án và hệ quả. Quyết định cuối cùng phải đến từ cơ cấu quản trị của doanh nghiệp.

Biến xung đột thành cơ hội chuẩn hóa doanh nghiệp

Chính trị nội bộ không phải lúc nào cũng là dấu hiệu hoàn toàn tiêu cực. Trong nhiều trường hợp, xung đột cho thấy doanh nghiệp đang thiếu một số nền tảng quản trị quan trọng:

• Quyền sở hữu quy trình chưa rõ ràng.
• Dữ liệu chưa có người chịu trách nhiệm.
• KPI giữa các phòng ban chưa đồng bộ.
• Cơ chế phê duyệt thiếu nhất quán.
• Quyết định phụ thuộc quá nhiều vào cá nhân.
• Các chi nhánh đang vận hành theo những tiêu chuẩn khác nhau.
• Nhiều quy trình chỉ tồn tại trong kinh nghiệm của một số nhân sự.

Thay vì né tránh các mâu thuẫn này, dự án ERP có thể trở thành cơ hội để doanh nghiệp làm rõ cách tổ chức thực sự muốn vận hành.

Điều quan trọng là xung đột phải được giải quyết bằng dữ liệu, mục tiêu kinh doanh và một cơ chế ra quyết định minh bạch, thay vì bằng ảnh hưởng cá nhân hoặc thỏa hiệp không có người chịu trách nhiệm.

Kết luận

Triển khai ERP không chỉ là một dự án công nghệ. Đây là chương trình thay đổi cách doanh nghiệp vận hành, phân bổ quyền hạn và sử dụng dữ liệu.

Phần mềm có thể được cấu hình đúng nhưng dự án vẫn khó thành công nếu:

• Các phòng ban không thống nhất mục tiêu.
• Không có người đủ thẩm quyền đưa ra quyết định.
• Dữ liệu bị xem là tài sản riêng của từng bộ phận.
• Người dùng không hiểu lý do phải thay đổi.
• Các quy trình ngoài hệ thống vẫn được duy trì.
• Những xung đột tổ chức được chuyển thành yêu cầu tùy chỉnh.

Ngược lại, khi doanh nghiệp xây dựng được cơ chế quản trị rõ ràng, sự bảo trợ thực chất của lãnh đạo và một mục tiêu chung, ERP có thể tạo ra nhiều giá trị hơn việc tự động hóa quy trình.

Hệ thống trở thành nền tảng giúp tăng tính minh bạch, nâng cao trách nhiệm và kết nối các phòng ban theo cùng một định hướng.

A1 Consulting hỗ trợ doanh nghiệp triển khai Odoo ERP theo cách tiếp cận gắn kết giữa công nghệ, quy trình và con người. Từ khảo sát nghiệp vụ, xây dựng lộ trình, chuẩn hóa quy trình đến đào tạo và hỗ trợ sau Go-Live, mục tiêu không chỉ là đưa hệ thống vào vận hành mà còn xây dựng một nền tảng quản trị có thể phát triển lâu dài cùng doanh nghiệp.

Liên hệ A1 Consulting để trao đổi về lộ trình triển khai Odoo ERP phù hợp với mô hình vận hành, quy mô và mức độ sẵn sàng thay đổi của doanh nghiệp.