Vì sao triển khai Odoo không đạt kỳ vọng? 11 sai lầm cần tránh

Một dự án triển khai Odoo có thể hoàn thành về mặt kỹ thuật nhưng vẫn chưa tạo ra kết quả mà doanh nghiệp kỳ vọng. Hệ thống đã go-live, các ứng dụng đã được cấu hình và người dùng có thể nhập liệu, nhưng doanh nghiệp vẫn phải duy trì Excel bên ngoài, số liệu giữa các bộ phận chưa thống nhất hoặc một số quy trình quan trọng vẫn cần xử lý thủ công.

Trong những trường hợp này, vấn đề không nhất thiết nằm ở khả năng của Odoo. Rủi ro thường xuất phát từ cách doanh nghiệp xác định yêu cầu, thiết kế quy trình, chuẩn bị dữ liệu, kiểm soát tùy chỉnh, tổ chức UAT và chuẩn bị người dùng trước khi hệ thống đi vào vận hành.

Đối với doanh nghiệp Việt Nam, bài toán còn liên quan đến dữ liệu kế toán, hóa đơn điện tử, yêu cầu localization và khả năng kết nối Odoo với các hệ thống đang được sử dụng. Vì vậy, triển khai Odoo cần được nhìn nhận như một dự án thay đổi quy trình và dữ liệu ở cấp doanh nghiệp, thay vì chỉ là quá trình cài đặt một hệ thống ERP mới.

Khi nào một dự án triển khai Odoo được xem là không đạt kỳ vọng?

“Không đạt kỳ vọng” không nhất thiết đồng nghĩa với việc dự án bị hủy hoặc hệ thống không thể go-live. Một dự án Odoo vẫn có thể được đưa vào sử dụng nhưng chưa đạt mục tiêu nếu các vấn đề ban đầu của doanh nghiệp vẫn tồn tại hoặc xuất hiện thêm các quy trình thủ công để bù đắp cho cách hệ thống được thiết kế.

Chẳng hạn, doanh nghiệp triển khai Odoo để thống nhất dữ liệu bán hàng, kho và kế toán, nhưng sau go-live mỗi bộ phận vẫn duy trì một file riêng để kiểm tra số liệu. Trong trường hợp khác, hệ thống đáp ứng được quy trình hiện tại nhưng đã được tùy chỉnh quá sâu, khiến việc thay đổi quy trình, bảo trì hoặc nâng cấp về sau trở nên phức tạp hơn dự kiến.

Do đó, kết quả của dự án không nên chỉ được đánh giá dựa trên việc hệ thống có được đưa vào vận hành đúng ngày hay không. Doanh nghiệp cần xem lại các mục tiêu ban đầu như mức độ chuẩn hóa quy trình, chất lượng dữ liệu, khả năng kiểm soát giao dịch, mức độ sử dụng thực tế và khả năng cung cấp thông tin cần thiết cho quản lý.

11 nguyên nhân khiến dự án triển khai Odoo gặp vấn đề

Mục tiêu và phạm vi triển khai chưa rõ ràng

Một dự án dễ mất phương hướng nếu doanh nghiệp bắt đầu bằng câu hỏi “cần triển khai những ứng dụng Odoo nào?” thay vì xác định những vấn đề kinh doanh cần giải quyết. Bộ phận Sales có thể ưu tiên CRM, bộ phận kho muốn kiểm soát tồn kho tốt hơn, Finance quan tâm đến đối soát và báo cáo, trong khi ban lãnh đạo lại kỳ vọng có một nguồn dữ liệu thống nhất để theo dõi hoạt động.

Từng yêu cầu riêng lẻ đều có thể hợp lý, nhưng nếu không được kết nối với mục tiêu chung, phạm vi dự án dễ trở thành tập hợp yêu cầu của nhiều phòng ban. Khi đó, việc quyết định yêu cầu nào cần cho go-live, yêu cầu nào có thể chuyển sang giai đoạn sau và tiêu chí nào dùng để đánh giá kết quả sẽ trở nên khó khăn.

Trước khi cấu hình hệ thống, doanh nghiệp nên xác định rõ vấn đề cần giải quyết, quy trình nằm trong phạm vi, đơn vị hoặc chi nhánh tham gia, dữ liệu cần chuyển đổi, hệ thống cần tích hợp và kết quả mong muốn. KPI cũng nên được xác định từ giai đoạn này nếu doanh nghiệp muốn đánh giá tác động sau triển khai.

Thiếu người phụ trách dự án có đủ thẩm quyền

Odoo thường kết nối nhiều phòng ban nên các quyết định trong dự án hiếm khi chỉ thuộc về IT. Một thay đổi trong cách xác nhận đơn hàng có thể ảnh hưởng đến Sales, Inventory, Finance và cả quy trình phê duyệt nội bộ. Nếu từng phòng ban gửi yêu cầu riêng nhưng không có người chịu trách nhiệm đưa ra quyết định cuối cùng, dự án dễ bị kéo theo nhiều hướng khác nhau.

Doanh nghiệp vì vậy nên phân biệt giữa người điều phối dự án hằng ngày và người bảo trợ dự án ở cấp quản lý. Project owner hoặc project manager nội bộ cần theo dõi yêu cầu, các công việc phụ thuộc lẫn nhau, quyết định và tiến độ giữa các phòng ban. Trong khi đó, project sponsor cần xử lý các vấn đề liên quan đến ưu tiên kinh doanh, ngân sách hoặc những thay đổi có ảnh hưởng lớn đến tổ chức.

Điểm quan trọng không nằm ở tên chức danh mà ở quyền ra quyết định. Đối tác triển khai Odoo có thể tư vấn phương án hệ thống, nhưng doanh nghiệp vẫn cần quyết định quy trình nào sẽ trở thành chuẩn chung, bộ phận nào chịu trách nhiệm về dữ liệu và yêu cầu nào được ưu tiên.

Phân tích quy trình nghiệp vụ chưa đủ sâu

Nếu doanh nghiệp đang vận hành bằng Excel kết hợp với nhiều phần mềm riêng cho kế toán, bán hàng, kho hoặc các nghiệp vụ khác, một giao dịch thực tế có thể đi qua nhiều bước mà không được thể hiện đầy đủ trong bất kỳ hệ thống nào. Một số bước thậm chí phụ thuộc vào email, tin nhắn hoặc kinh nghiệm của từng nhân viên.

Nếu giai đoạn khảo sát chỉ ghi nhận các chức năng mà từng phòng ban yêu cầu, đội dự án có thể bỏ qua các điểm giao giữa những bộ phận này. Kết quả là từng chức năng hoạt động riêng lẻ nhưng toàn bộ quy trình từ đầu đến cuối vẫn xuất hiện khoảng trống.

Vì vậy, quá trình phân tích nghiệp vụ cần theo dõi toàn bộ luồng công việc, chẳng hạn từ báo giá đến đơn bán hàng, xuất kho, hóa đơn và thanh toán; hoặc từ nhu cầu mua hàng đến phê duyệt, đơn mua hàng, nhận hàng, hóa đơn nhà cung cấp và thanh toán.

Trong quá trình này, doanh nghiệp nên xác định bước nào thực sự cần thiết, bước nào đang bị lặp và điểm nào cần được chuẩn hóa trước khi đưa vào Odoo.

Lựa chọn đối tác triển khai Odoo chủ yếu dựa trên chi phí

Báo giá là một tiêu chí cần thiết khi lựa chọn nhà cung cấp, nhưng khó phản ánh đầy đủ chất lượng của một dự án ERP. Hai đề xuất có thể cùng ghi “triển khai Sales, Inventory và Accounting” nhưng khác đáng kể về phạm vi khảo sát, chuyển đổi dữ liệu, tích hợp, UAT, đào tạo, tài liệu hướng dẫn và hỗ trợ sau go-live.

Nếu so sánh chủ yếu dựa trên tổng giá trị hợp đồng, doanh nghiệp có thể bỏ qua những phần việc chưa được bao gồm hoặc chưa được mô tả rõ. Chi phí phát sinh sau đó có thể đến từ việc phải phân tích lại yêu cầu, sửa phần tùy chỉnh, thực hiện lại quá trình chuyển đổi dữ liệu hoặc bổ sung các kết nối cần thiết cho quy trình thực tế.

Khi đánh giá đối tác triển khai Odoo, doanh nghiệp nên xem xét kinh nghiệm với phạm vi tương tự, khả năng phân tích nghiệp vụ, phương pháp quản lý dự án, cách xử lý tùy chỉnh và chuyển đổi dữ liệu, quy trình kiểm thử cũng như mô hình hỗ trợ sau go-live.

Đề xuất triển khai cũng cần giúp hai bên phân biệt tương đối rõ đâu là cấu hình tiêu chuẩn của Odoo, đâu là phần cần tùy chỉnh và đâu là hạng mục cần khảo sát thêm trước khi chốt giải pháp.

>>> Xem thêm: Chọn đối tác triển khai Odoo - Đưa ra quyết định đúng ngay lần đầu tiên

Cố gắng sao chép toàn bộ hệ thống cũ vào Odoo

Một trong những quyết định làm tăng độ phức tạp của dự án là yêu cầu Odoo tái tạo gần như nguyên trạng màn hình, biểu mẫu, bước phê duyệt và cách xử lý của hệ thống cũ. Một số quy trình cũ có thể tồn tại vì giới hạn của phần mềm trước đây chứ không phải vì đó là cách vận hành tối ưu.

Nếu những giới hạn đó được đưa nguyên sang Odoo, doanh nghiệp có thể phải đầu tư nhiều vào tùy chỉnh nhưng vẫn giữ lại chính các bất cập mà dự án ERP mới được kỳ vọng giải quyết. Mức độ tùy chỉnh càng lớn thì phạm vi phát triển, kiểm thử và bảo trì cũng càng tăng.

Một cách tiếp cận thận trọng hơn là lần lượt kiểm tra: chức năng tiêu chuẩn của Odoo có đáp ứng được không, có thể giải quyết bằng cấu hình hay không, có cần tích hợp với một hệ thống chuyên biệt hay không và cuối cùng mới đánh giá nhu cầu phát triển riêng.

Điều này không có nghĩa doanh nghiệp phải tránh customization. Những yêu cầu đặc thù và có giá trị kinh doanh rõ ràng vẫn có thể cần được phát triển riêng.

Đánh giá thấp độ phức tạp của việc chuyển đổi dữ liệu

Chuyển đổi dữ liệu không đơn giản là xuất dữ liệu từ hệ thống cũ rồi nhập vào Odoo. Dữ liệu khách hàng có thể bị trùng, cùng một sản phẩm có nhiều cách đặt tên, đơn vị tính không thống nhất, mã nhà cung cấp khác nhau giữa các bộ phận hoặc số liệu tồn kho cần được đối chiếu trước ngày chốt dữ liệu.

Rủi ro trở nên rõ hơn khi phạm vi triển khai liên quan đến Accounting. Số dư đầu kỳ, công nợ khách hàng, công nợ nhà cung cấp, giao dịch chưa hoàn tất và các dữ liệu liên quan cần được xác định rõ phạm vi, cách ánh xạ dữ liệu và phương pháp kiểm tra trước khi hệ thống mới trở thành nguồn dữ liệu vận hành.

Doanh nghiệp nên bắt đầu kiểm tra và làm sạch dữ liệu từ sớm thay vì chờ đến gần go-live. Quá trình chuyển đổi nên có ít nhất các bước: xác định dữ liệu cần chuyển, làm sạch, ánh xạ, chuyển đổi thử, xác nhận từ bộ phận nghiệp vụ và chuyển đổi chính thức.

Người dùng nghiệp vụ cần tham gia xác nhận dữ liệu bởi đội kỹ thuật không thể tự quyết định một mã sản phẩm, số dư hay mối quan hệ dữ liệu có đúng với thực tế vận hành hay không.

Xem xét tích hợp và localization quá muộn

Ít doanh nghiệp triển khai ERP trong một môi trường hoàn toàn độc lập. Odoo có thể cần trao đổi dữ liệu với website, nền tảng thương mại điện tử, ngân hàng, hệ thống bên thứ ba hoặc các ứng dụng chuyên biệt mà doanh nghiệp tiếp tục sử dụng.

Nếu việc tích hợp chỉ được xử lý sau khi phần lớn Odoo đã được cấu hình, doanh nghiệp có thể phát hiện muộn rằng dữ liệu giữa các hệ thống không cùng cấu trúc, thời điểm đồng bộ chưa phù hợp hoặc chưa xác định hệ thống nào là nguồn dữ liệu chính.

Vì vậy, kiến trúc tích hợp và trách nhiệm quản lý từng nhóm dữ liệu nên được xác định ngay trong giai đoạn thiết kế giải pháp.

Với doanh nghiệp Việt Nam, các yêu cầu về kế toán, thuế, hóa đơn điện tử và fiscal localization cũng cần được đưa vào phạm vi khảo sát từ đầu. Doanh nghiệp không nên mặc định rằng một quy trình tài chính đang hoạt động ở quốc gia khác có thể áp dụng nguyên trạng tại Việt Nam.

Cấu hình cuối cùng cần được kiểm tra theo yêu cầu pháp lý hiện hành, phiên bản Odoo, localization được sử dụng và mô hình nghiệp vụ thực tế của doanh nghiệp.

UAT chỉ kiểm tra chức năng thay vì quy trình thực tế

Một chức năng hoạt động đúng không đồng nghĩa với toàn bộ quy trình đã sẵn sàng cho go-live. Việc kiểm tra người dùng có thể tạo Sales Order chưa đủ để xác nhận rằng quy trình từ đơn hàng đến giao hàng, lập hóa đơn và ghi nhận thanh toán hoạt động đúng với dữ liệu, quyền truy cập và các tình huống ngoại lệ của doanh nghiệp.

UAT nên sử dụng các kịch bản gần với hoạt động thực tế, bao gồm cả trường hợp thông thường và ngoại lệ. Đối với kho, đó có thể là nhận thiếu hàng, trả hàng hoặc chuyển kho. Đối với mua hàng, có thể là thay đổi số lượng hoặc xử lý chênh lệch giữa đơn mua và hàng nhận. Đối với kế toán, cần kiểm tra các luồng giao dịch thuộc phạm vi triển khai và kết quả ghi nhận tương ứng.

Đặc biệt, UAT nên có sự tham gia của key user từ các phòng ban liên quan. Nếu người dùng chỉ tiếp xúc với hệ thống ở giai đoạn cuối, nhiều vấn đề về thao tác và quy trình có thể chỉ được phát hiện sau go-live, khi việc điều chỉnh đã ảnh hưởng trực tiếp đến vận hành.

Người dùng tham gia quá muộn và đào tạo chỉ tập trung vào thao tác

ERP không chỉ thay đổi giao diện mà còn thay đổi cách dữ liệu được tạo ra, ai chịu trách nhiệm ở từng bước và khi nào giao dịch được chuyển sang bộ phận tiếp theo. Vì vậy, đào tạo theo kiểu chỉ hướng dẫn “bấm nút nào ở đâu” thường chưa đủ để người dùng hiểu quy trình mới.

Chẳng hạn, nhân viên kho không chỉ cần biết cách xác nhận một phiếu nhận hàng mà còn cần hiểu dữ liệu đó ảnh hưởng như thế nào đến tồn kho và các bước tiếp theo. Tương tự, người dùng bán hàng cần biết những trường thông tin nào phải hoàn chỉnh trước khi giao dịch được chuyển tiếp, thay vì chỉ biết cách tạo báo giá.

Đào tạo nên được thiết kế theo vai trò và dựa trên những tình huống mà từng nhóm người dùng thực sự xử lý. Bên cạnh thao tác hệ thống, tài liệu cần giải thích quy trình mới, trách nhiệm của từng vai trò, điểm bàn giao giữa các phòng ban và cách xử lý một số trường hợp ngoại lệ thường gặp.

Không kiểm soát phạm vi và yêu cầu thay đổi

Trong quá trình triển khai, người dùng thường phát hiện thêm nhu cầu sau khi nhìn thấy hệ thống thực tế. Một báo cáo mới, một bước phê duyệt hoặc một trường dữ liệu bổ sung có thể hợp lý khi xem riêng lẻ, nhưng nhiều thay đổi cộng lại có thể tác động đáng kể đến thiết kế, phát triển, kiểm thử và tiến độ.

Vấn đề không nằm ở việc yêu cầu thay đổi xuất hiện. Rủi ro phát sinh khi dự án không có cơ chế đánh giá và quyết định yêu cầu nào cần thực hiện ngay, yêu cầu nào nằm ngoài phạm vi và yêu cầu nào nên chuyển sang giai đoạn tiếp theo.

Doanh nghiệp có thể phân loại yêu cầu thành ba nhóm: bắt buộc, nên có và cải tiến trong tương lai, đồng thời thiết lập quy trình quản lý thay đổi rõ ràng. Mỗi thay đổi cần được xem xét dựa trên giá trị kinh doanh, mức độ phức tạp, chi phí, tác động đến tiến độ và phạm vi kiểm thử trước khi được phê duyệt.

Xem go-live là điểm kết thúc của dự án

Go-live là thời điểm Odoo bắt đầu được sử dụng với dữ liệu và giao dịch thực tế. Do đó, một số vấn đề chỉ trở nên rõ ràng khi khối lượng sử dụng tăng lên. Người dùng có thể cần hỗ trợ thêm, báo cáo cần được điều chỉnh hoặc một quy trình cần được tối ưu sau khi doanh nghiệp đã có đủ dữ liệu vận hành để đánh giá.

Nếu không có cơ chế hỗ trợ rõ ràng, người dùng có xu hướng tìm cách giải quyết vấn đề bên ngoài ERP. Các file Excel hoặc bước xử lý thủ công có thể xuất hiện trở lại, khiến dữ liệu dần phân tán dù hệ thống đã go-live.

Kế hoạch sau go-live vì vậy nên xác định cách tiếp nhận và phân loại vấn đề, mức độ ưu tiên, người chịu trách nhiệm xử lý, quy trình quản lý thay đổi và kế hoạch cải tiến hệ thống.

Một giai đoạn hypercare ngay sau go-live cũng giúp đội dự án tập trung xử lý những vấn đề ảnh hưởng trực tiếp đến vận hành trước khi chuyển sang mô hình hỗ trợ ổn định hơn.

>>> Xem thêm: Odoo Implementation: Những lưu ý quan trọng trước Go-live

Doanh nghiệp Việt Nam nên chuẩn bị gì trước khi triển khai Odoo?

Các nguyên nhân trên cho thấy phần lớn công việc giảm rủi ro cần bắt đầu trước khi đội triển khai đi sâu vào cấu hình hệ thống.

Với doanh nghiệp đang sử dụng nhiều file Excel hoặc phần mềm riêng lẻ, bước đầu tiên nên là xác định hệ thống nào hiện đang lưu dữ liệu gì, ai chịu trách nhiệm và những dữ liệu nào cần trở thành nguồn dùng chung sau khi triển khai Odoo.

Nếu dự án bao gồm nhiều chi nhánh, công ty hoặc kho, doanh nghiệp cũng cần phân biệt giữa những quy trình có thể chuẩn hóa và những khác biệt thực sự cần giữ lại. Việc cấu hình hệ thống trước rồi mới thảo luận về chuẩn chung thường khiến dự án phải quay lại sửa thiết kế khi phát hiện mỗi đơn vị đang sử dụng mã hàng, cách phê duyệt hoặc quy tắc vận hành khác nhau.

Master data cần được coi là một hạng mục công việc riêng thay vì chỉ là công việc nhập dữ liệu ở cuối dự án. Khách hàng, nhà cung cấp, sản phẩm, đơn vị tính, tồn kho và các dữ liệu tài chính thuộc phạm vi chuyển đổi cần có người chịu trách nhiệm, nguyên tắc làm sạch và tiêu chí xác nhận rõ ràng.

Đối với phạm vi Finance và Accounting, đội dự án cần xác định sớm yêu cầu về fiscal localization, thuế, dữ liệu đầu kỳ, hóa đơn điện tử và các luồng nghiệp vụ liên quan. Những yêu cầu này cần được kiểm tra trên phiên bản và cấu hình Odoo thực tế mà doanh nghiệp dự kiến sử dụng, đồng thời đối chiếu với quy định hiện hành tại Việt Nam.

Cuối cùng, doanh nghiệp nên dành đủ thời gian cho UAT và đào tạo thay vì coi đây là hai hoạt động có thể rút ngắn để giữ ngày go-live. Một hệ thống đã hoàn thành phát triển nhưng chưa được người dùng xác nhận trên các quy trình thực tế vẫn còn rủi ro đáng kể khi chuyển sang môi trường vận hành.

Checklist giảm rủi ro trước khi go-live Odoo

Trước khi quyết định go-live, đội dự án nên xác nhận ít nhất các nội dung sau:

Nếu một số hạng mục quan trọng vẫn chưa có câu trả lời rõ ràng, doanh nghiệp nên đánh giá tác động trước khi giữ nguyên ngày go-live. Việc chuyển một hạng mục chưa thiết yếu sang giai đoạn 2 đôi khi hợp lý hơn việc mở rộng phạm vi ngay trước thời điểm vận hành chính thức.

Kết luận

Một dự án triển khai Odoo không đạt kỳ vọng thường không xuất phát từ một lỗi duy nhất. Mục tiêu chưa rõ, quy trình chưa được phân tích đầy đủ, dữ liệu chưa sẵn sàng, tùy chỉnh thiếu kiểm soát hoặc người dùng tham gia quá muộn có thể kết hợp với nhau và tạo ra vấn đề khi hệ thống bắt đầu vận hành thực tế.

Đối với doanh nghiệp Việt Nam, việc chuẩn bị còn cần bao gồm các yêu cầu về dữ liệu kế toán, thuế, hóa đơn điện tử, localization và sự khác biệt giữa các công ty, chi nhánh hoặc kho trong phạm vi dự án. Những nội dung này càng được làm rõ sớm thì đội triển khai càng có cơ sở để thiết kế phạm vi, dữ liệu, tích hợp và kế hoạch kiểm thử phù hợp.

Vì vậy, trước khi triển khai Odoo ERP, doanh nghiệp nên dành đủ thời gian cho khảo sát nghiệp vụ, lập sơ đồ quy trình, chuẩn bị dữ liệu và quản trị dự án thay vì bắt đầu ngay từ việc cấu hình các ứng dụng. Một phạm vi được kiểm soát và các tiêu chí go-live rõ ràng sẽ giúp doanh nghiệp đánh giá dự án dựa trên khả năng vận hành thực tế, thay vì chỉ dựa trên việc hệ thống đã được đưa vào sử dụng hay chưa.

Nếu doanh nghiệp đang chuẩn bị triển khai Odoo, thay thế hệ thống ERP hiện tại hoặc cần đánh giá lại một dự án Odoo đang gặp vướng mắc, A1 Consulting có thể hỗ trợ rà soát yêu cầu nghiệp vụ, phạm vi triển khai, dữ liệu, localization và lộ trình thực hiện trước khi doanh nghiệp đưa ra các quyết định tiếp theo.

Liên hệ A1 Consulting để trao đổi về nhu cầu triển khai Odoo ERP của doanh nghiệp.