Các cột mốc quan trọng của một dự án triển khai ERP

Một kế hoạch triển khai ERP thường được xây dựng theo các giai đoạn tương đối rõ ràng, từ khảo sát nghiệp vụ, thiết kế giải pháp, cấu hình hệ thống, chuyển đổi dữ liệu và kiểm thử đến đào tạo người dùng và Go-live. Cách chia này cần thiết để lập kế hoạch nguồn lực và theo dõi tiến độ, nhưng nếu chỉ dựa vào việc một giai đoạn đã “hoàn thành” trên timeline, doanh nghiệp chưa chắc đã đánh giá đúng mức độ sẵn sàng thực tế của dự án.

Trong triển khai ERP, các giai đoạn có mối quan hệ phụ thuộc rất lớn. Một yêu cầu chưa được thống nhất trong quá trình khảo sát có thể trở thành thay đổi phạm vi khi cấu hình. Dữ liệu chưa được chuẩn hóa có thể tạo ra hàng loạt vấn đề trong UAT. Một quy trình chưa được kiểm thử đầy đủ có thể chỉ bộc lộ khi doanh nghiệp bắt đầu xử lý giao dịch thật sau Go-live.

Vì vậy, ở góc độ tư vấn triển khai, tôi cho rằng bên cạnh timeline, doanh nghiệp cần quản lý dự án thông qua các cột mốc có điều kiện hoàn thành rõ ràng. Mỗi cột mốc không chỉ xác nhận một nhóm công việc đã được thực hiện mà còn phải cung cấp đủ cơ sở để doanh nghiệp quyết định dự án có thể chuyển sang giai đoạn tiếp theo hay chưa.

Đây cũng là điểm khác biệt quan trọng giữa một dự án “đang chạy đúng kế hoạch” và một dự án thực sự được kiểm soát tốt.

Cột mốc trong dự án ERP nên được hiểu như thế nào?

Trong quản lý dự án ERP, cột mốc và công việc là hai khái niệm có liên quan nhưng không đồng nhất. “Cấu hình quy trình mua hàng” là một công việc. Trong khi đó, “quy trình mua hàng đã được cấu hình, kiểm tra theo các tình huống nghiệp vụ đã thống nhất và được người phụ trách quy trình xác nhận” mới phản ánh một trạng thái đủ rõ để sử dụng như cột mốc kiểm soát.

Sự khác biệt nằm ở kết quả và khả năng xác nhận. Việc một đội triển khai hoàn thành cấu hình chưa chứng minh rằng giải pháp phù hợp với nghiệp vụ. Tương tự, việc tổ chức xong một buổi UAT chưa đồng nghĩa người dùng đã xác nhận hệ thống đáp ứng các quy trình cần thiết cho Go-live.

Vì vậy, mỗi cột mốc quan trọng nên gắn với ít nhất bốn yếu tố: kết quả cần đạt, bằng chứng cho thấy kết quả đã đạt, người có trách nhiệm xác nhận và những vấn đề còn tồn tại trước khi dự án chuyển sang bước tiếp theo.

Cách tiếp cận này không nhằm bổ sung thêm thủ tục phê duyệt. Mục tiêu chính là ngăn những vấn đề chưa được giải quyết âm thầm chuyển từ giai đoạn này sang giai đoạn khác, nơi chi phí và mức độ ảnh hưởng của chúng thường lớn hơn.

Tổng quan các cột mốc quan trọng khi triển khai ERP

Tên gọi và cách phân chia giai đoạn có thể khác nhau tùy phương pháp triển khai, phạm vi và đặc điểm doanh nghiệp. Tuy nhiên, xét từ góc độ kiểm soát dự án, một dự án ERP thường cần quản lý các cột mốc chính sau:

Khởi động dự án và thiết lập cơ chế quản trị

Khởi động dự án không nên được hiểu đơn giản là tổ chức một cuộc họp kickoff và công bố timeline. Đây là thời điểm doanh nghiệp và đơn vị triển khai thiết lập nền tảng quản trị cho toàn bộ dự án, bao gồm mục tiêu kinh doanh, phạm vi ban đầu, đội ngũ tham gia, trách nhiệm của từng bên, cơ chế trao đổi, phương thức xử lý vấn đề và thẩm quyền ra quyết định.

Trong thực tế triển khai, một trong những nguyên nhân khiến dự án chậm không nhất thiết đến từ kỹ thuật mà có thể đến từ việc quyền quyết định chưa rõ. Khi Sales, Finance và Operations có những yêu cầu khác nhau đối với cùng một quy trình, đội triển khai không nên là bên tự quyết định mô hình vận hành nào phù hợp với doanh nghiệp. Dự án cần xác định ngay từ đầu người sở hữu quy trình và cấp có thẩm quyền xử lý những vấn đề liên phòng ban.

Mục tiêu kinh doanh cũng cần được làm rõ ở giai đoạn này. Một doanh nghiệp thay ERP vì hệ thống cũ không còn đáp ứng được tốc độ tăng trưởng sẽ có ưu tiên khác với doanh nghiệp triển khai ERP để chuẩn hóa quy trình giữa nhiều công ty hoặc tăng khả năng kiểm soát tài chính. Những mục tiêu này sẽ trở thành cơ sở để đánh giá và ưu tiên phạm vi khi dự án phát sinh thêm yêu cầu.

Điều kiện hoàn thành cột mốc: Mục tiêu, phạm vi ban đầu, cơ cấu đội dự án, trách nhiệm, cơ chế trao đổi, thẩm quyền ra quyết định và phương thức xử lý vấn đề đã được các bên thống nhất.

Khảo sát nghiệp vụ và xác nhận yêu cầu

Khảo sát nghiệp vụ không nên dừng ở việc hỏi từng phòng ban cần những tính năng nào. Một yêu cầu hệ thống chỉ có ý nghĩa khi đội triển khai hiểu được quy trình, nguyên nhân và mục tiêu kinh doanh phía sau yêu cầu đó.

Ví dụ, yêu cầu bổ sung một bước phê duyệt đơn bán hàng có thể xuất phát từ nhu cầu kiểm soát hạn mức tín dụng, biên lợi nhuận, chính sách giá hoặc phân quyền giữa các cấp quản lý. Nếu chỉ ghi nhận yêu cầu “thêm bước phê duyệt”, hệ thống có thể được cấu hình đúng về mặt chức năng nhưng chưa chắc đã giải quyết đúng vấn đề doanh nghiệp cần kiểm soát.

Do đó, khảo sát cần bao quát quy trình hiện tại, các điểm kiểm soát, dữ liệu đầu vào và đầu ra, ngoại lệ, trách nhiệm giữa các bộ phận, yêu cầu báo cáo, yêu cầu pháp lý và các hệ thống cần tích hợp. Đội tư vấn cũng cần phân biệt giữa những yêu cầu xuất phát từ nhu cầu vận hành thực tế và những yêu cầu đơn giản là sự tiếp nối của cách làm trên hệ thống cũ.

Đây là bước quan trọng để tránh tình trạng ERP mới được thiết kế chỉ nhằm tái tạo toàn bộ quy trình cũ trên một nền tảng công nghệ khác.

Điều kiện hoàn thành cột mốc: Các quy trình trọng yếu, vấn đề hiện tại, yêu cầu nghiệp vụ, dữ liệu, báo cáo, tích hợp và các yêu cầu bắt buộc đã được xác định đủ rõ để thiết kế giải pháp.

Thiết kế giải pháp và thống nhất phạm vi

Thiết kế giải pháp là một trong những cột mốc có ảnh hưởng lớn nhất đến chi phí, tiến độ và mức độ phức tạp của dự án. Sau giai đoạn khảo sát, đội dự án cần chuyển từ việc hiểu doanh nghiệp đang vận hành như thế nào sang xác định doanh nghiệp sẽ vận hành như thế nào trên ERP mới.

Đối với Odoo, mỗi yêu cầu cần được đánh giá xem chức năng tiêu chuẩn đã đáp ứng hay chưa, có thể giải quyết bằng cấu hình hay không, có thực sự cần tùy chỉnh hoặc cần tích hợp với hệ thống bên ngoài. Việc phân biệt này quan trọng vì mức độ tùy chỉnh càng lớn thì doanh nghiệp càng phải cân nhắc thêm chi phí phát triển, kiểm thử, bảo trì và tác động khi nâng cấp hệ thống.

Đây cũng là giai đoạn dễ phát sinh mở rộng phạm vi. Finance có thể cần thêm báo cáo, Sales đề xuất thêm quy tắc báo giá, Operations nhận thấy một số thao tác có thể tự động hóa, trong khi ban quản lý muốn bổ sung dashboard. Từng yêu cầu riêng lẻ có thể hợp lý, nhưng tổng hợp nhiều thay đổi như vậy có thể khiến phạm vi ban đầu tăng đáng kể mà nguồn lực và thời hạn Go-live không thay đổi tương ứng.

Với Odoo, khả năng kết nối nhiều ứng dụng trong cùng một hệ sinh thái khiến việc mở rộng phạm vi tương đối hấp dẫn. Tuy nhiên, khả năng triển khai về mặt kỹ thuật không đồng nghĩa một chức năng phải xuất hiện ngay trong lần Go-live đầu tiên. Việc ưu tiên nên dựa trên mức độ cần thiết đối với khả năng vận hành liên tục, chính xác và tuân thủ của doanh nghiệp.

Điều kiện hoàn thành cột mốc: Quy trình tương lai, phạm vi chức năng, phần sử dụng tiêu chuẩn, cấu hình, tùy chỉnh, tích hợp, báo cáo, dữ liệu cần chuyển đổi và các yêu cầu được chuyển sang giai đoạn sau đã được thống nhất.

Cấu hình và phát triển hệ thống

Sau khi thiết kế được xác nhận, giải pháp bắt đầu được hiện thực hóa trên ERP. Với Odoo, đội dự án cần tiếp tục duy trì nguyên tắc phân biệt giữa chức năng tiêu chuẩn, cấu hình và phát triển tùy chỉnh thay vì mặc định mọi khác biệt so với quy trình hiện tại đều phải giải quyết bằng lập trình.

Tài liệu phương pháp triển khai của Odoo mô tả giai đoạn triển khai theo các vòng phân tích, cấu hình hoặc phát triển, xác nhận và đào tạo người dùng chủ chốt. Cách tiếp cận theo vòng lặp này có một giá trị thực tế quan trọng: bộ phận nghiệp vụ có thể tiếp xúc và xác nhận giải pháp trong quá trình xây dựng thay vì chỉ nhìn thấy kết quả hoàn chỉnh ở UAT.

Đối với những quy trình quan trọng, việc rà soát định kỳ với người phụ trách nghiệp vụ giúp phát hiện sớm các giả định chưa phù hợp. Một thay đổi ở thời điểm cấu hình ban đầu thường dễ kiểm soát hơn nhiều so với khi dữ liệu, tích hợp, báo cáo và các quy trình khác đã được xây dựng dựa trên thiết kế đó.

Điều kiện hoàn thành cột mốc: Các chức năng trong phạm vi đã được cấu hình hoặc phát triển ở mức đủ hoàn chỉnh để chuyển sang kiểm thử hệ thống và xác nhận nghiệp vụ.

Chuẩn bị và chuyển đổi dữ liệu

Dữ liệu thường là một trong những phần bị đánh giá thấp trong kế hoạch ERP. Việc chuyển dữ liệu về mặt kỹ thuật có thể tương đối rõ, nhưng đảm bảo dữ liệu đủ chính xác để doanh nghiệp vận hành lại là vấn đề khác.

Các vấn đề như khách hàng hoặc nhà cung cấp trùng lặp, mã sản phẩm thiếu nhất quán, đơn vị tính sai, thông tin danh mục thiếu, tồn kho không chính xác hoặc số dư kế toán chưa được đối soát sẽ không tự biến mất khi được đưa sang ERP mới. Nếu dữ liệu đầu vào có vấn đề, hệ thống mới có thể vận hành đúng về mặt kỹ thuật nhưng vẫn tạo ra kết quả không đáng tin cậy.

Vì vậy, chuyển đổi dữ liệu cần được quản lý như một phần của nghiệp vụ, không chỉ là nhiệm vụ kỹ thuật. Doanh nghiệp cần xác định dữ liệu nào phải chuyển, dữ liệu lịch sử nào thực sự cần thiết, cách ánh xạ sang cấu trúc mới và ai chịu trách nhiệm xác nhận từng nhóm dữ liệu.

Đối với những dữ liệu ảnh hưởng trực tiếp đến hoạt động như danh mục sản phẩm, khách hàng, nhà cung cấp, tồn kho và số dư đầu kỳ, người chịu trách nhiệm xác nhận nên là bên hiểu ý nghĩa và tác động nghiệp vụ của dữ liệu. Việc chạy thử chuyển đổi trước Go-live cũng giúp doanh nghiệp kiểm tra thời gian thực hiện, phát hiện sai lệch và xây dựng phương pháp đối soát trước lần chuyển đổi cuối cùng.

Điều kiện hoàn thành cột mốc: Dữ liệu cần thiết đã được làm sạch, ánh xạ, chuyển đổi thử và đối soát ở mức phù hợp với yêu cầu vận hành.

Tích hợp và kiểm thử hệ thống

Việc từng chức năng hoạt động riêng lẻ không chứng minh rằng toàn bộ quy trình ERP có thể vận hành chính xác. Trong một hệ thống tích hợp, giao dịch được tạo ở một bộ phận có thể ảnh hưởng đến tồn kho, kế toán, mua hàng, sản xuất hoặc báo cáo ở bộ phận khác.

Vì vậy, kiểm thử cần ưu tiên các tình huống nghiệp vụ xuyên suốt thay vì chỉ kiểm tra từng màn hình hoặc từng chức năng độc lập. Với quy trình bán hàng, chẳng hạn, việc tạo thành công đơn bán hàng chỉ là một phần; doanh nghiệp còn phải kiểm tra ảnh hưởng của đơn hàng đến giao hàng, tồn kho, hóa đơn, thanh toán và ghi nhận kế toán.

Nguyên tắc tương tự áp dụng cho tích hợp. Khi Odoo kết nối với ngân hàng, hệ thống E-Commerce, nền tảng thanh toán, hệ thống kho hoặc các giải pháp bên ngoài khác, việc API kết nối thành công chưa đủ để xác nhận toàn bộ quy trình đã sẵn sàng. Dữ liệu cần được kiểm tra từ điểm phát sinh đến điểm cuối, bao gồm cả các tình huống lỗi và ngoại lệ.

Điều kiện hoàn thành cột mốc: Các luồng nghiệp vụ và tích hợp quan trọng đã được kiểm thử; những lỗi có khả năng cản trở UAT đã được xử lý hoặc có phương án kiểm soát rõ ràng.

UAT và xác nhận khả năng đáp ứng nghiệp vụ

UAT là giai đoạn người dùng nghiệp vụ xác nhận rằng giải pháp có thể hỗ trợ những quy trình họ thực sự cần vận hành. Vì vậy, chất lượng của UAT phụ thuộc nhiều vào cách xây dựng kịch bản kiểm thử.

Một UAT chỉ tập trung vào việc người dùng mở màn hình, tạo bản ghi và kiểm tra từng chức năng riêng lẻ sẽ khó phản ánh đầy đủ khả năng vận hành thực tế. Kịch bản nên đi xuyên suốt toàn bộ chuỗi giao dịch, chẳng hạn từ báo giá đến đơn bán hàng, giao hàng, xuất hóa đơn và thanh toán; hoặc từ nhu cầu mua hàng đến đơn mua, nhận hàng, hóa đơn nhà cung cấp và thanh toán.

Các tình huống ngoại lệ cũng cần được đưa vào phạm vi phù hợp. Trả hàng, giao thiếu, hủy đơn, điều chỉnh số lượng, thay đổi giá hoặc các giao dịch cần phê duyệt thường là nơi những điểm yếu của thiết kế quy trình xuất hiện rõ hơn so với luồng giao dịch tiêu chuẩn.

Kết quả UAT cũng không nên chỉ được đo bằng số lượng kịch bản đã chạy. Các lỗi cần được phân loại theo mức độ ảnh hưởng đến vận hành, có người chịu trách nhiệm xử lý và được kiểm thử lại khi cần thiết. Một lỗi hiển thị nhỏ không thể được đánh giá tương đương với lỗi khiến doanh nghiệp không thể giao hàng hoặc ghi nhận hóa đơn.

Điều kiện hoàn thành cột mốc: Người dùng chủ chốt đã xác nhận các quy trình trọng yếu, các lỗi nghiêm trọng đã được xử lý và những vấn đề còn lại nằm trong mức rủi ro mà doanh nghiệp chấp nhận trước Go-live.

>>> Xem thêm: UAT là gì? Tầm quan trọng của của UAT trong dự án ERP

Đào tạo và chuẩn bị Go-live

Đào tạo ERP không nên được thiết kế như một buổi giới thiệu toàn bộ chức năng hệ thống. Người dùng cần hiểu những quy trình liên quan trực tiếp đến vai trò của mình, dữ liệu cần nhập, trách nhiệm ở từng bước và cách xử lý những tình huống thường gặp.

Đào tạo theo vai trò thường phù hợp hơn đào tạo theo danh sách chức năng. Nhân viên bán hàng cần hiểu quy trình từ cơ hội đến đơn hàng và những quy tắc liên quan đến giá hoặc phê duyệt. Nhân viên kho cần thành thạo các giao dịch nhận, chuyển và giao hàng. Finance cần hiểu cách các giao dịch từ những bộ phận khác được phản ánh vào kế toán và cách kiểm tra chúng.

Quan trọng hơn, mức độ sẵn sàng trước Go-live không chỉ nằm ở người dùng. Doanh nghiệp cần đánh giá đồng thời con người, quy trình, dữ liệu và hệ thống. Một hệ thống đã kiểm thử tốt nhưng dữ liệu đầu kỳ chưa sẵn sàng vẫn có thể khiến Go-live thất bại về mặt vận hành. Tương tự, dữ liệu và hệ thống có thể chính xác nhưng người dùng chưa hiểu quy trình mới vẫn tạo ra rủi ro đáng kể.

Điều kiện hoàn thành cột mốc: Người dùng cần thiết đã được đào tạo, tài liệu và quy trình vận hành đã sẵn sàng, dữ liệu cuối cùng được chuẩn bị và cơ chế hỗ trợ sau Go-live đã được xác định.

Đánh giá Go/No-Go

Go/No-Go là điểm kiểm soát cuối cùng trước khi hệ thống được đưa vào vận hành chính thức. Đây nên được xem là quyết định kinh doanh của doanh nghiệp thay vì quyết định thuần túy của đội CNTT hoặc đơn vị triển khai.

Ở thời điểm này, ban chỉ đạo cần có một bức tranh tổng hợp về mức độ sẵn sàng của các quy trình trọng yếu, dữ liệu, tích hợp, người dùng, các lỗi còn tồn tại, kế hoạch chuyển đổi và nguồn lực hỗ trợ. Đối với những vấn đề chưa thể đóng hoàn toàn, cần đánh giá mức độ ảnh hưởng, phương án xử lý và người chịu trách nhiệm.

Một dự án không nhất thiết phải đạt trạng thái “không còn bất kỳ lỗi nào” mới có thể Go-live. Trong thực tế, điều quan trọng hơn là không còn vấn đề có khả năng ngăn cản các hoạt động kinh doanh trọng yếu hoặc tạo ra rủi ro vượt quá mức doanh nghiệp chấp nhận.

Kế hoạch Go-live cũng cần bao gồm trình tự chuyển đổi dữ liệu cuối cùng, thời điểm dừng giao dịch trên hệ thống cũ, kiểm tra số dư và dữ liệu sau chuyển đổi, trách nhiệm của từng đội và phương án xử lý nếu một bước quan trọng không hoàn thành như dự kiến.

Điều kiện hoàn thành cột mốc: Ban chỉ đạo đã đánh giá đầy đủ mức độ sẵn sàng và xác nhận rằng doanh nghiệp có thể chuyển sang hệ thống mới với mức rủi ro chấp nhận được.

Go-live và chuyển sang vận hành thực tế

Go-live là thời điểm hệ thống chuyển từ môi trường dự án sang môi trường vận hành thực tế. Dữ liệu cuối cùng được chuyển đổi, số dư đầu kỳ được thiết lập và người dùng bắt đầu thực hiện các giao dịch thật trên ERP.

Đây là một trong những cột mốc quan trọng nhất, nhưng không nên được sử dụng như tiêu chí duy nhất để đánh giá thành công của dự án. Việc hệ thống hoạt động trên môi trường chính thức mới chỉ chứng minh rằng doanh nghiệp đã thực hiện được quá trình chuyển đổi. Những tuần tiếp theo mới phản ánh rõ hơn hệ thống có hoạt động ổn định với khối lượng giao dịch thực tế, dữ liệu có duy trì được độ chính xác và người dùng có thích nghi được với quy trình mới hay không.

Trong giai đoạn này, cơ chế hỗ trợ và xử lý vấn đề cần được kích hoạt ngay từ đầu. Các vấn đề ảnh hưởng đến bán hàng, mua hàng, giao nhận, sản xuất, thanh toán hoặc kế toán cần được phân loại và xử lý dựa trên mức độ ảnh hưởng đến hoạt động kinh doanh.

Điều kiện hoàn thành cột mốc: Việc chuyển đổi sang môi trường chính thức hoàn tất, các kiểm tra sau chuyển đổi đạt yêu cầu và doanh nghiệp bắt đầu thực hiện giao dịch thực tế trên ERP.

>>> Xem thêm: Hiện thực hóa giá trị của ERP: Bài toán cho doanh nghiệp sau Go-live

Hỗ trợ sau Go-live

Những ngày và tuần đầu sau Go-live thường có mức nhu cầu hỗ trợ cao hơn giai đoạn vận hành thông thường. Nguyên nhân có thể đến từ cấu hình, dữ liệu, tích hợp, quyền truy cập, thao tác của người dùng hoặc những tình huống nghiệp vụ chỉ xuất hiện khi hệ thống xử lý giao dịch thật.

Ở giai đoạn này, cách ưu tiên vấn đề rất quan trọng. Một lỗi khiến doanh nghiệp không thể giao hàng, xuất hóa đơn hoặc ghi nhận giao dịch cần được xử lý khác với một yêu cầu thay đổi bố cục báo cáo. Việc phân loại theo tác động kinh doanh giúp đội dự án tập trung nguồn lực vào những vấn đề ảnh hưởng trực tiếp đến khả năng vận hành.

Các vấn đề lặp lại cũng cần được phân tích nguyên nhân thay vì chỉ đóng từng ticket. Nếu nhiều người dùng liên tục mắc cùng một lỗi, nguyên nhân có thể nằm ở thiết kế quy trình, giao diện, phân quyền hoặc chất lượng đào tạo chứ không nhất thiết là lỗi của từng cá nhân.

Điều kiện hoàn thành cột mốc: Các vấn đề nghiêm trọng đã được kiểm soát, khối lượng hỗ trợ giảm về mức có thể quản lý và các quy trình trọng yếu hoạt động ổn định.

Ổn định vận hành và kết thúc dự án

Go-live đánh dấu việc hệ thống bắt đầu được sử dụng, trong khi ổn định vận hành phản ánh khả năng doanh nghiệp thực sự làm việc trên hệ thống đó. Đây là hai trạng thái khác nhau và không nên được đánh đồng.

Một dự án có thể đã Go-live nhưng vẫn chưa ổn định nếu Finance chưa thể đối soát số liệu, tồn kho thường xuyên sai lệch, người dùng vẫn phải duy trì nhiều file Excel bên ngoài hoặc đội triển khai phải can thiệp hàng ngày để xử lý các giao dịch cơ bản.

Ở góc độ vận hành, trạng thái ổn định thường được thể hiện qua việc các giao dịch cốt lõi được thực hiện bình thường, dữ liệu đạt độ chính xác cần thiết, Finance có thể đối soát và thực hiện các hoạt động cuối kỳ, người dùng xử lý được công việc thường ngày, các tích hợp quan trọng hoạt động đáng tin cậy và những vấn đề nghiêm trọng đã được kiểm soát.

Khi các điều kiện này được đáp ứng, dự án có thể chuyển từ cơ chế triển khai sang cơ chế hỗ trợ dài hạn. Những yêu cầu cải tiến chưa cần thiết cho lần Go-live đầu tiên cũng có thể được đánh giá lại và đưa vào lộ trình tiếp theo.

Điều kiện hoàn thành cột mốc: Doanh nghiệp có thể vận hành các quy trình trọng yếu một cách ổn định mà không còn phụ thuộc liên tục vào đội dự án, đồng thời trách nhiệm hỗ trợ đã được chuyển giao rõ ràng.

5 điểm kiểm soát mà ban lãnh đạo cần đặc biệt quan tâm

Trong toàn bộ vòng đời dự án, không phải mọi quyết định đều cần đưa lên CEO hoặc ban chỉ đạo. Tuy nhiên, có năm điểm kiểm soát có ảnh hưởng trực tiếp đến phạm vi, rủi ro và khả năng vận hành của doanh nghiệp.

Xác nhận phạm vi là điểm đầu tiên. Doanh nghiệp cần có ranh giới rõ giữa những yêu cầu phải hoàn thành trong lần triển khai hiện tại và những yêu cầu có thể chuyển sang giai đoạn sau. Nếu ranh giới này không rõ, phạm vi có xu hướng mở rộng trong khi ngân sách, nguồn lực và deadline không thay đổi tương ứng.

Phê duyệt thiết kế giải pháp xác nhận cách các quy trình tương lai sẽ vận hành trên ERP. Đây là thời điểm cần giải quyết những khác biệt quan trọng giữa các phòng ban trước khi chúng trở thành cấu hình, tùy chỉnh hoặc mã nguồn.

Xác nhận UAT cung cấp bằng chứng từ phía nghiệp vụ rằng những quy trình trọng yếu có thể hoạt động xuyên suốt. Chỉ số quan trọng ở đây không phải số lượng kịch bản đã chạy mà là khả năng vận hành của các quy trình cần thiết cho hoạt động thực tế.

Go/No-Go là quyết định về mức độ sẵn sàng tổng thể. Ban chỉ đạo cần xem xét đồng thời hệ thống, dữ liệu, con người, quy trình và những rủi ro còn tồn tại trước khi chấp thuận chuyển đổi.

Cuối cùng, xác nhận ổn định vận hành giúp doanh nghiệp phân biệt giữa việc hệ thống đã được đưa vào sử dụng và việc hệ thống đã trở thành một phần ổn định trong hoạt động thường ngày. Đây cũng là cơ sở phù hợp hơn để kết thúc dự án và chuyển sang hỗ trợ dài hạn.

Dự án Odoo có thể có nhiều cột mốc Go-live

Odoo được tổ chức thành nhiều ứng dụng nghiệp vụ có khả năng kết nối với nhau. Đặc điểm này cho phép doanh nghiệp cân nhắc triển khai theo từng giai đoạn thay vì nhất thiết đưa toàn bộ phạm vi vào vận hành trong một lần.

Chẳng hạn, một doanh nghiệp có thể ưu tiên giai đoạn đầu cho các quy trình cốt lõi như Kế toán, Bán hàng, Mua hàng và Kho. Giai đoạn tiếp theo mở rộng sang Sản xuất, Chất lượng và Bảo trì; sau đó mới tiếp tục với CRM, Website, E-Commerce, POS hoặc Marketing.

Cấu trúc trên chỉ mang tính minh họa. Thứ tự triển khai thực tế phải dựa trên mức độ phụ thuộc giữa các quy trình, ưu tiên kinh doanh, khả năng chuẩn bị dữ liệu, nguồn lực của doanh nghiệp và rủi ro chuyển đổi. Trong một số trường hợp, tách các quy trình có mức độ phụ thuộc cao thành nhiều lần Go-live thậm chí có thể làm dự án phức tạp hơn.

Vì vậy, lựa chọn giữa triển khai đồng loạt và triển khai theo giai đoạn không nên dựa trên một nguyên tắc cố định. Mục tiêu là xác định được một phạm vi đủ hoàn chỉnh để doanh nghiệp có thể vận hành an toàn và tạo ra giá trị sau mỗi lần Go-live, đồng thời không tạo ra quá nhiều quy trình tạm thời giữa hệ thống cũ và hệ thống mới.

Với cách triển khai theo giai đoạn, mỗi phạm vi vẫn cần trải qua các bước kiểm soát cần thiết từ thiết kế, cấu hình, dữ liệu và kiểm thử đến UAT, Go-live và ổn định vận hành. Việc một giai đoạn trước đã thành công không có nghĩa giai đoạn tiếp theo có thể bỏ qua các điểm kiểm soát này.

Checklist cột mốc ERP dành cho ban quản lý

Ban chỉ đạo không cần theo dõi từng cấu hình hoặc từng ticket của dự án. Vai trò của management là đảm bảo rằng tại những điểm quyết định quan trọng, dự án có đủ bằng chứng để tiếp tục.

Checklist này không thay thế kế hoạch triển khai chi tiết. Giá trị của nó nằm ở việc giúp ban quản lý tập trung vào kết quả và bằng chứng, thay vì chỉ nhìn vào tỷ lệ hoàn thành công việc trên báo cáo tiến độ.

Kết luận

Go-live thường là ngày được chú ý nhiều nhất trong một dự án ERP vì đây là thời điểm doanh nghiệp chính thức chuyển sang hệ thống mới. Tuy nhiên, xét từ góc độ quản trị và vận hành, việc hệ thống được đưa lên môi trường chính thức mới chỉ là một phần của kết quả triển khai.

Giá trị của ERP chỉ bắt đầu được thể hiện khi các bộ phận có thể sử dụng hệ thống một cách ổn định trong công việc thực tế: Sales xử lý đơn hàng theo quy trình thống nhất, Operations kiểm soát được luồng hàng hóa, Finance có thể tin cậy dữ liệu để đối soát và báo cáo, trong khi ban quản lý có được thông tin đủ nhất quán để hỗ trợ việc ra quyết định.

Do đó, thành công của một dự án ERP không nên chỉ được đánh giá bằng việc hệ thống có Go-live đúng ngày dự kiến hay không. Một tiêu chí có ý nghĩa hơn là khả năng doanh nghiệp vận hành chính xác, ổn định và bền vững trên hệ thống mới sau Go-live.

Đó cũng là lý do trong các dự án ERP, việc xác định rõ điều kiện hoàn thành cho từng cột mốc có giá trị hơn việc chỉ xây dựng một timeline chi tiết. Khi mỗi giai đoạn đều có kết quả cần đạt, người chịu trách nhiệm và cơ sở xác nhận rõ ràng, ban lãnh đạo có thể kiểm soát tốt hơn cả tiến độ lẫn mức độ sẵn sàng thực tế của dự án.

Với các dự án Odoo, A1 Consulting tiếp cận quá trình triển khai từ cả góc độ hệ thống và vận hành doanh nghiệp, với mục tiêu làm rõ phạm vi, trách nhiệm và các điểm kiểm soát quan trọng từ giai đoạn chuẩn bị cho đến khi hệ thống đi vào vận hành ổn định.

Liên hệ A1 Consulting để được tư vấn