Dự án ERP là gì? Cách tổ chức, lập ngân sách và nghiệm thu

Phần lớn nội dung tiếng Việt về dự án ERP dừng ở việc liệt kê các bước triển khai. Nhưng dự án đổ vỡ hiếm khi vì sai bước. Nó đổ vỡ vì không rõ ai quyết định, vì ngân sách thiếu những khoản không ai tính, và vì không có tiêu chí để nói dự án đã xong hay chưa.

Bài viết tập trung vào phần quản trị đó.

Dự án ERP là gì?

Dự án ERP là toàn bộ công việc có thời hạn, ngân sách và phạm vi xác định, nhằm đưa một hệ thống ERP vào vận hành thực tế tại doanh nghiệp.

Khác biệt cần nắm ngay: triển khai ERP là phần kỹ thuật, dự án ERP là toàn bộ phạm vi quản trị bao quanh nó.

Triển khai ERP	Dự án ERP
Cấu hình hệ thống	Cấu hình hệ thống
Chuyển đổi dữ liệu	Chuyển đổi dữ liệu
Kiểm thử và đào tạo	Kiểm thử và đào tạo
	Cơ cấu tổ chức và phân quyền quyết định
	Ngân sách và kiểm soát chi
	Tiến độ và quản lý rủi ro
	Quản trị thay đổi quy trình và con người
	Tiêu chí nghiệm thu và bàn giao

Chi tiết phần kỹ thuật có trong bài triển khai ERP là gì và quy trình 8 bước. Bài này không lặp lại.

Vì sao dự án ERP khó hơn dự án phần mềm thông thường?

Phạm vi cắt ngang nhiều phòng ban. Một dự án phần mềm bán hàng chỉ ảnh hưởng phòng kinh doanh. Dự án ERP chạm vào kế toán, kho, mua hàng, sản xuất, nhân sự cùng lúc. Mỗi phòng có cách làm riêng đã dùng nhiều năm, và mọi thay đổi đều phải thương lượng.

Dự án thay đổi cách làm việc, không chỉ thay công cụ. Phần lớn giá trị của ERP đến từ việc chuẩn hóa quy trình. Nếu doanh nghiệp giữ nguyên mọi cách làm cũ và bắt phần mềm chạy theo, chi phí tùy chỉnh tăng vọt và hệ thống trở nên khó nâng cấp.

Không thể chạy thử nửa vời. Không thể vận hành nửa kho trên ERP, nửa kho trên Excel. Đến ngày go-live, toàn bộ nghiệp vụ chuyển sang hệ thống mới cùng lúc. Rủi ro tập trung vào một thời điểm.

Dữ liệu quá khứ là nút thắt. Danh mục vật tư trùng lặp, công nợ không khớp, tồn kho sổ sách lệch thực tế. Những vấn đề tồn tại nhiều năm bị phơi ra khi chuyển dữ liệu, và dự án phải giải quyết chúng trước khi chạy được.

Tổ chức ban dự án ERP

Đây là phần quyết định nhiều nhất nhưng hay bị bỏ qua. Sai lầm phổ biến: lãnh đạo giao toàn bộ dự án cho phòng IT hoặc phòng kế toán rồi rút ra ngoài. Cả hai phòng đều không có thẩm quyền yêu cầu phòng khác đổi cách làm việc.

Sáu vai trò cần có

Vai trò	Ai đảm nhiệm	Trách nhiệm chính
Ban chỉ đạo	Tổng giám đốc hoặc phó tổng	Duyệt ngân sách, quyết các vấn đề vượt thẩm quyền, xử lý xung đột giữa các phòng
Chủ nhiệm dự án phía doanh nghiệp	Cấp trưởng phòng trở lên, làm toàn thời gian	Điều phối hằng ngày, kiểm soát tiến độ và phạm vi, báo cáo ban chỉ đạo
Chủ nhiệm dự án phía nhà cung cấp	Nhân sự của đối tác triển khai	Điều phối đội triển khai, cấu hình, đào tạo
Người dùng chủ chốt	Mỗi phòng nghiệp vụ cử 1 đến 2 người	Mô tả quy trình hiện tại, kiểm thử, đào tạo lại cho phòng mình
Phụ trách kỹ thuật	IT nội bộ	Hạ tầng, phân quyền, sao lưu, tích hợp hệ thống khác
Phụ trách dữ liệu	Kế toán trưởng hoặc trưởng bộ phận dữ liệu	Làm sạch danh mục, đối chiếu số dư, ký xác nhận dữ liệu chuyển đổi

Nguyên tắc chọn người dùng chủ chốt: chọn người hiểu nghiệp vụ nhất, không chọn người rảnh nhất. Đây là sai lầm hay gặp và hậu quả xuất hiện muộn, thường ở giai đoạn kiểm thử khi phát hiện quy trình mô tả sai.

Nguyên tắc về thời gian: chủ nhiệm dự án phía doanh nghiệp cần làm toàn thời gian trong giai đoạn cao điểm. Người dùng chủ chốt cần được giảm tải công việc thường ngày ít nhất 30% trong các giai đoạn phân tích, kiểm thử và go-live. Không giảm tải thì họ sẽ ưu tiên việc thường ngày và dự án chậm.

Bảng phân vai RACI

R là người thực hiện, A là người chịu trách nhiệm cuối cùng, C là người được hỏi ý kiến, I là người được thông báo.

Công việc	Ban chỉ đạo	CNDA doanh nghiệp	CNDA nhà cung cấp	Người dùng chủ chốt	IT
Duyệt phạm vi dự án	A	R	C	C	I
Mô tả quy trình hiện tại	I	A	C	R	I
Chốt quy trình chuẩn mới	A	R	C	C	I
Duyệt yêu cầu tùy chỉnh	A	R	C	C	C
Làm sạch dữ liệu danh mục	I	A	I	R	C
Chuẩn bị hạ tầng	I	I	C	I	A/R
Kiểm thử nghiệp vụ	I	A	C	R	I
Ký nghiệm thu từng giai đoạn	A	R	C	C	I
Quyết định ngày go-live	A	R	C	C	C
Xử lý sự cố sau go-live	I	A	R	C	C

Bảng này nên được in ra, ký và treo trong phòng dự án. Phần lớn tranh cãi giữa doanh nghiệp và nhà cung cấp bắt nguồn từ chỗ không ai chốt trước ai là A của việc gì.

Lập ngân sách dự án ERP

Vượt ngân sách gần như luôn đến từ các khoản không nằm trong báo giá của nhà cung cấp.

Các đầu mục chi phí

Nhóm	Đầu mục	Ghi chú
Phần mềm	Bản quyền theo người dùng hoặc theo phân hệ	Thuê bao hằng năm hoặc mua đứt
Phần mềm	Phí bảo trì và nâng cấp hằng năm	Thường 15 đến 22% giá bản quyền nếu mua đứt
Triển khai	Phí tư vấn, khảo sát, cấu hình	Tính theo ngày công
Triển khai	Phí tùy chỉnh theo yêu cầu riêng	Khoản dễ phình nhất
Triển khai	Phí chuyển đổi dữ liệu	Phụ thuộc mức độ sạch của dữ liệu cũ
Triển khai	Phí đào tạo	Tính theo lớp hoặc theo người
Hạ tầng	Máy chủ, thiết bị đầu cuối, đường truyền	Với ERP đám mây thì phần này nhỏ hơn nhiều
Nội bộ	Chi phí thời gian nhân sự tham gia dự án	Ít doanh nghiệp tính, nhưng đây là khoản lớn
Nội bộ	Thuê ngoài hoặc tăng ca bù việc thường ngày	Phát sinh trong cao điểm
Vận hành	Hỗ trợ sau go-live	Thường 1 đến 3 tháng, cần thỏa thuận rõ

Bốn khoản chi phí ẩn hay bị bỏ sót

Thời gian của nhân sự nội bộ. Một dự án 6 tháng với 8 người dùng chủ chốt dành 30% thời gian tương đương khoảng 14 tháng công. Quy ra tiền lương, khoản này thường bằng 20 đến 40% phí triển khai trả cho nhà cung cấp. Không tính vào ngân sách không có nghĩa là không tốn.

Năng suất giảm sau go-live. Trong 4 đến 8 tuần đầu, nhân viên làm chậm hơn vì đang học hệ thống mới. Doanh nghiệp cần chuẩn bị tinh thần và không nên chọn go-live vào mùa cao điểm.

Làm sạch dữ liệu. Nếu danh mục vật tư có hàng nghìn mã trùng lặp, việc gộp và chuẩn hóa mất hàng tháng nhân sự. Khoản này nên khảo sát và ước lượng trước khi ký hợp đồng, không để phát sinh giữa chừng.

Tùy chỉnh phát sinh. Đây là khoản nguy hiểm nhất vì nó xuất hiện dần. Mỗi yêu cầu nhỏ nghe hợp lý, cộng lại thành con số lớn. Cách kiểm soát ở phần dưới.

Cách kiểm soát yêu cầu tùy chỉnh

Đặt một quy tắc từ đầu và ghi vào quy chế dự án: mọi yêu cầu tùy chỉnh phải qua ba câu hỏi trước khi được duyệt.

1. Nghiệp vụ này có thể xử lý bằng chức năng sẵn có nếu đổi cách làm không?
2. Nếu không tùy chỉnh thì hậu quả cụ thể là gì, đo được bằng tiền hay thời gian?
3. Chi phí tùy chỉnh và chi phí bảo trì nó về sau là bao nhiêu?

Yêu cầu nào không trả lời được câu 2 bằng con số thì chuyển sang danh sách xem xét sau go-live. Thực tế phần lớn các mục trong danh sách đó không bao giờ được yêu cầu lại, vì sau vài tháng người dùng đã quen với cách làm mới.

Nên dành sẵn khoản dự phòng 10 đến 15% ngân sách cho phát sinh, và quy định rõ ai có quyền duyệt chi từ khoản này.

Thời gian dự án theo quy mô

Quy mô doanh nghiệp	Phạm vi phân hệ	Thời gian tham khảo
Dưới 50 nhân sự, 1 địa điểm	Kế toán, bán hàng, kho	2 đến 4 tháng
50 đến 200 nhân sự	Thêm mua hàng, công nợ, tài sản	4 đến 8 tháng
200 đến 500 nhân sự, có sản xuất	Thêm sản xuất, giá thành, nhân sự	8 đến 14 tháng
Trên 500 nhân sự, nhiều chi nhánh	Toàn bộ, có hợp nhất báo cáo	12 đến 24 tháng

Đây là khoảng tham khảo, phụ thuộc mạnh vào ba yếu tố: mức độ sạch của dữ liệu cũ, số lượng tùy chỉnh, và mức độ sẵn sàng của người dùng chủ chốt.

Về cách chia giai đoạn: với doanh nghiệp từ 200 người trở lên, nên chia thành nhiều đợt go-live thay vì chuyển toàn bộ cùng lúc. Đợt một thường là kế toán, mua hàng, kho và bán hàng vì đây là luồng dữ liệu nền. Đợt hai là sản xuất và giá thành. Đợt ba là các phân hệ còn lại. Cách này giảm rủi ro tập trung, đổi lại thời gian tổng dài hơn và phải duy trì kết nối tạm giữa hệ thống cũ và mới.

Tiêu chí nghiệm thu từng giai đoạn

Không có tiêu chí nghiệm thu bằng văn bản thì dự án không có điểm kết thúc. Nhà cung cấp cho là xong, doanh nghiệp thấy chưa dùng được, và tranh cãi kéo dài.

Giai đoạn	Sản phẩm bàn giao	Tiêu chí nghiệm thu
Khảo sát	Tài liệu quy trình hiện tại và quy trình đề xuất	Trưởng từng phòng nghiệp vụ ký xác nhận mô tả đúng thực tế
Thiết kế	Tài liệu cấu hình, danh mục yêu cầu tùy chỉnh có báo giá	Ban chỉ đạo duyệt phạm vi và ngân sách phát sinh
Cấu hình	Hệ thống trên môi trường thử nghiệm	Chạy được toàn bộ kịch bản nghiệp vụ đã thống nhất
Chuyển đổi dữ liệu	Dữ liệu danh mục và số dư đầu kỳ	Số dư trên hệ thống mới khớp với báo cáo tài chính đã duyệt, chênh lệch bằng 0
Kiểm thử người dùng	Biên bản kiểm thử theo kịch bản	Toàn bộ lỗi mức nghiêm trọng và cao đã đóng, lỗi mức thấp có kế hoạch xử lý
Đào tạo	Tài liệu hướng dẫn, danh sách người đã đào tạo	Người dùng tự thao tác được nghiệp vụ của mình mà không cần hỗ trợ
Go-live	Hệ thống chạy thật	Nghiệp vụ hằng ngày thực hiện trọn vẹn trên hệ thống, không dùng song song sổ cũ
Kết thúc dự án	Biên bản nghiệm thu tổng thể	Chốt sổ được kỳ đầu tiên trên hệ thống mới và ra được báo cáo tài chính

Tiêu chí quan trọng nhất nằm ở dòng cuối. Dự án ERP chưa xong vào ngày go-live. Nó xong khi doanh nghiệp chốt được kỳ kế toán đầu tiên và ra báo cáo trên hệ thống mới. Nhiều hợp đồng nghiệm thu ở ngày go-live rồi doanh nghiệp mắc kẹt ở kỳ chốt sổ đầu tiên khi đối tác đã rút.

Nên ghi vào hợp đồng: khoản thanh toán cuối cùng gắn với việc chốt sổ thành công kỳ đầu tiên, không gắn với ngày go-live.

Về kiểm thử người dùng: cần phân mức lỗi từ đầu, thường là bốn mức. Nghiêm trọng là lỗi làm nghiệp vụ không thực hiện được hoặc số liệu sai. Cao là có cách làm thay thế nhưng bất tiện đáng kể. Trung bình là bất tiện nhỏ. Thấp là góp ý về giao diện. Chỉ chặn go-live với mức nghiêm trọng và cao.

Tám nguyên nhân khiến dự án ERP đổ vỡ

Nguyên nhân	Dấu hiệu nhận biết sớm	Cách phòng
Lãnh đạo giao khoán rồi rút ra	Ban chỉ đạo không họp quá 1 tháng	Lịch họp ban chỉ đạo cố định 2 tuần một lần, có biên bản
Không rõ mục tiêu đo được	Không ai nói được dự án thành công thì cái gì tốt lên	Chốt 3 đến 5 chỉ số cụ thể trước khi ký hợp đồng
Phạm vi phình dần	Danh mục yêu cầu tùy chỉnh dài thêm mỗi tuần	Quy trình duyệt tùy chỉnh 3 câu hỏi ở phần trên
Người dùng chủ chốt không được giảm tải	Họ vắng mặt liên tục ở buổi làm việc	Ghi cam kết giảm tải vào quyết định thành lập ban dự án
Dữ liệu cũ bẩn hơn dự kiến	Không đối chiếu được số dư kho hoặc công nợ	Khảo sát dữ liệu trước khi ký hợp đồng, không để sau
Chọn sai sản phẩm	Số yêu cầu tùy chỉnh vượt quá 20% phạm vi	Chạy thử trên dữ liệu thật của mình trước khi chọn
Đào tạo hình thức	Đào tạo một buổi rồi thôi	Đào tạo theo vai trò, kiểm tra thao tác, đào tạo lại trước go-live
Không có tiêu chí nghiệm thu	Tranh cãi xong hay chưa xong	Bảng tiêu chí nghiệm thu ở phần trên, đưa vào hợp đồng

Sáu trong tám nguyên nhân này xuất hiện trước khi dòng cấu hình đầu tiên được thiết lập. Đó là lý do phần chuẩn bị quan trọng hơn phần thực thi.

Về chỉ số đo mục tiêu: nên chọn chỉ số đo được từ dữ liệu, không chọn chỉ số cảm tính. Ví dụ số ngày chốt sổ mỗi tháng, tỷ lệ chênh lệch giữa tồn kho sổ sách và kiểm kê thực tế, thời gian trung bình từ lúc nhận đơn hàng đến lúc xuất kho, số ngày công nợ phải thu bình quân. Đo trước khi triển khai để có mốc so sánh.

Bộ chỉ số theo dõi trong lúc chạy dự án

Chỉ số	Cách đo	Ngưỡng cần cảnh báo
Tiến độ so với kế hoạch	Số mốc đã hoàn thành trên tổng số mốc đến thời điểm này	Chậm quá 15%
Chi phí đã chi so với ngân sách	Lũy kế chi trên tổng ngân sách, đối chiếu với tiến độ	Chi vượt tiến độ quá 10%
Số yêu cầu tùy chỉnh phát sinh	Đếm theo tuần	Tăng liên tục 3 tuần
Lỗi tồn chưa xử lý	Đếm theo mức nghiêm trọng	Còn lỗi nghiêm trọng trong vòng 2 tuần trước go-live
Tỷ lệ tham gia của người dùng chủ chốt	Số buổi có mặt trên tổng số buổi	Dưới 80%
Tiến độ làm sạch dữ liệu	Tỷ lệ danh mục đã chuẩn hóa	Chậm hơn tiến độ chung

Báo cáo bộ chỉ số này cho ban chỉ đạo mỗi hai tuần. Một trang giấy là đủ.

Checklist trước khi ký hợp đồng dự án ERP

• Đã có quyết định thành lập ban dự án với đầy đủ 6 vai trò và cam kết giảm tải
• Đã chốt 3 đến 5 chỉ số mục tiêu và đo được số liệu hiện trạng
• Đã khảo sát mức độ sạch của dữ liệu danh mục và số dư
• Đã chạy thử sản phẩm trên dữ liệu thật của doanh nghiệp
• Đã có bảng phân vai RACI được các bên ký
• Đã thống nhất tiêu chí nghiệm thu từng giai đoạn bằng văn bản
• Ngân sách đã tính cả chi phí nội bộ và dự phòng 10 đến 15%
• Khoản thanh toán cuối gắn với việc chốt sổ thành công kỳ đầu tiên
• Đã thỏa thuận rõ phạm vi và thời hạn hỗ trợ sau go-live
• Đã chọn thời điểm go-live tránh mùa cao điểm và tránh sát kỳ quyết toán

Arito đồng hành trong dự án ERP

Arito ERP làm việc với doanh nghiệp Việt Nam từ khâu khảo sát đến khi chốt được kỳ kế toán đầu tiên trên hệ thống mới:

• Khảo sát quy trình và đánh giá mức độ sạch của dữ liệu trước khi báo giá, để ngân sách sát thực tế
• Phạm vi và tiêu chí nghiệm thu từng giai đoạn ghi rõ trong hợp đồng
• Các phân hệ dùng chung một nền dữ liệu, gồm tài chính kế toán, mua hàng, kho, bán hàng, sản xuất and hr
• Cập nhật theo quy định kế toán và thuế Việt Nam hiện hành, gồm Thông tư 99/2025 áp dụng từ 01/01/2026
• Service tư vấn và triển khai cùng đào tạo hướng dẫn sử dụng tách bạch trong hợp đồng

Đọc thêm bài triển khai ERP là gì để nắm phần quy trình kỹ thuật, hoặc top công ty phần mềm ERP để so sánh nhà cung cấp. Đăng ký demo để chạy thử trên dữ liệu thật của doanh nghiệp bạn.

Câu hỏi thường gặp

Dự án ERP là gì?

Dự án ERP là toàn bộ công việc có thời hạn, ngân sách và phạm vi xác định nhằm đưa hệ thống ERP vào vận hành thực tế. Ngoài phần kỹ thuật, dự án còn gồm tổ chức nhân sự, kiểm soát ngân sách và tiến độ, quản trị thay đổi và nghiệm thu.

Dự án ERP khác gì triển khai ERP?

Triển khai ERP là phần kỹ thuật gồm cấu hình, chuyển dữ liệu, kiểm thử và đào tạo. Dự án ERP bao gồm phần đó cộng với quản trị: ai quyết định gì, tiền lấy từ đâu, đo tiến độ ra sao, nghiệm thu bằng tiêu chí nào.

Dự án ERP mất bao lâu?

Doanh nghiệp dưới 50 người với phạm vi kế toán, bán hàng, kho thường mất 2 đến 4 tháng. Doanh nghiệp 200 đến 500 người có sản xuất thường mất 8 đến 14 tháng. Thời gian phụ thuộc mạnh vào mức độ sạch của dữ liệu cũ và số lượng yêu cầu tùy chỉnh.

Ai nên làm chủ nhiệm dự án ERP?

Người từ cấp trưởng phòng trở lên, hiểu nghiệp vụ liên phòng ban, có thẩm quyền yêu cầu các phòng phối hợp, và được giao làm toàn thời gian trong giai đoạn cao điểm. Không nên giao cho nhân sự IT thuần túy vì vai trò này cần thẩm quyền về nghiệp vụ.

Vì sao nhiều dự án ERP thất bại?

Nguyên nhân thường gặp gồm lãnh đạo giao khoán rồi không tham gia, không có mục tiêu đo được, phạm vi phình dần vì yêu cầu tùy chỉnh, người dùng chủ chốt không được giảm tải công việc thường ngày, dữ liệu cũ bẩn hơn dự kiến, và không có tiêu chí nghiệm thu bằng văn bản.

Nên tính những chi phí nào vào ngân sách dự án ERP?

Ngoài bản quyền và phí triển khai của nhà cung cấp, cần tính phí bảo trì hằng năm, chi phí hạ tầng, chi phí thời gian nhân sự nội bộ tham gia dự án, chi phí bù đắp năng suất giảm sau go-live, chi phí làm sạch dữ liệu, và khoản dự phòng 10 đến 15%.

Khi nào coi là dự án ERP đã hoàn thành?

Không phải ngày go-live mà là khi doanh nghiệp chốt được kỳ kế toán đầu tiên trên hệ thống mới và ra được báo cáo tài chính. Nên gắn khoản thanh toán cuối cùng với mốc này trong hợp đồng.

Có nên go-live toàn bộ cùng lúc không?

Với doanh nghiệp dưới 200 người và một địa điểm thì go-live toàn bộ thường hợp lý hơn. Với quy mô lớn hơn hoặc nhiều chi nhánh, nên chia thành nhiều đợt, bắt đầu từ nhóm kế toán, mua hàng, kho, bán hàng vì đây là luồng dữ liệu nền.

Tổng kết

Dự án ERP đổ vỡ hiếm khi vì lý do kỹ thuật. Nó đổ vỡ vì ban dự án không có người đủ thẩm quyền, vì ngân sách bỏ sót chi phí nội bộ, vì không ai chốt trước tiêu chí nghiệm thu.

Ba việc cần làm trước khi ký hợp đồng: lập ban dự án có đủ sáu vai trò kèm cam kết giảm tải bằng văn bản, đo hiện trạng ba đến năm chỉ số để sau này biết dự án có hiệu quả không, và thống nhất tiêu chí nghiệm thu từng giai đoạn.

Một việc cần ghi vào hợp đồng: khoản thanh toán cuối gắn với kỳ chốt sổ đầu tiên thành công, không gắn với ngày go-live.

Cần trao đổi về cách tổ chức dự án cho doanh nghiệp của bạn, liên hệ với Arito.