Chi phí thật của một dự án ERP

Các dòng thêm đó không phải thứ bên kia nghĩ ra để lấy tiền, chúng là những việc chắc chắn xảy ra trong cả hai dự án. Khác biệt duy nhất là một bản viết chúng thành dòng có người chịu trách nhiệm, còn bản kia để chúng rơi vào khoảng trống, và tới lúc phát sinh thì hai bên ngồi cãi nhau xem việc đó thuộc về ai.

Lý do bài này không có con số

Phần lớn các bài tiếng Việt về chi phí triển khai ERP mà tôi đọc rơi vào một trong hai kiểu.

Kiểu thứ nhất đưa ra một dải số theo quy mô doanh nghiệp hoặc theo phân hệ, kèm một dòng nhỏ rằng số liệu chỉ mang tính tham khảo, nhưng không nói dải số đó dựng từ dự án nào, phạm vi nào, năm nào. Kiểu thứ hai thì không đưa số mà kết bằng một nút xin báo giá.

Bài này cũng không đưa số, và tôi nói thẳng lý do. Các đơn giá phần mềm, hạ tầng và ngày công mà tôi có đều đến từ những dự án cụ thể với phạm vi cụ thể, không có nguồn công bố chính thức nào để đối chiếu, nên đưa lên đây thì bạn sẽ lấy số của dự án người khác mà ước lượng cho dự án mình. Sai kiểu đó nguy hiểm hơn là không có số.

Phí phần mềm theo người dùng và theo phân hệ

Đây là khoản duy nhất có bảng giá công khai, nên cũng là khoản ai cũng nhìn thấy đầu tiên, kể cả khi doanh nghiệp chọn bản Community và dòng này bằng không.

Điều cần hỏi ở đây không phải con số, mà là con số đó tính trên cái gì. Bạn cần biết một tài khoản người dùng được định nghĩa thế nào, cụ thể là:

• người chỉ vào xem báo cáo có phải mua tài khoản không
• hai nhân viên hai ca dùng chung một tài khoản có hợp lệ không
• và hóa đơn đổi ra sao khi thêm người giữa kỳ hoặc mở thêm một phân hệ

Chính sách của từng hãng thay đổi theo thời gian, nên câu trả lời phải lấy bằng văn bản từ nhà cung cấp tại thời điểm ký chứ không lấy từ một bài viết, kể cả bài này.

Hạ tầng và các dịch vụ chạy kèm

Khoản hạ tầng phát sinh từ ngày dựng môi trường đầu tiên và không bao giờ dừng, nên nó là chi phí định kỳ chứ không phải chi phí dự án.

Ba lựa chọn nơi đặt hệ thống đã có bài riêng, còn ở góc chi phí thì bạn cần đếm cả những thứ đứng cạnh nó, gồm:

• môi trường thử
• cơ chế sao lưu
• và công của người quản trị dù đó là nhân sự nội bộ hay dịch vụ thuê ngoài

Đặc biệt đừng quên nhóm dịch vụ bên thứ ba, thứ hầu như không xuất hiện trong báo giá vì không do bên triển khai bán.

Một tích hợp gửi tin nhắn chẳng hạn, đòi doanh nghiệp tự tìm nhà cung cấp dịch vụ, đăng ký tên thương hiệu và đăng ký mẫu tin nhắn với cơ quan quản lý trước khi hệ thống gửi được dòng đầu tiên, mà mỗi bước vừa tốn phí riêng vừa tốn thời gian chờ.

Hóa đơn điện tử cũng nằm ở nhóm này, bởi kể cả khi phần kết nối đã có sẵn trong hệ thống thì tài khoản với nhà cung cấp hóa đơn và chứng thư số để ký vẫn là những thứ doanh nghiệp phải tự mua.

Công triển khai và công tùy biến

Công triển khai gần như luôn được tính bằng số ngày công nhân với đơn giá, do đó câu hỏi đáng tiền nhất là số ngày công ấy dựa trên cái gì mà ra.

Trong trường hợp bên triển khai đã khảo sát và đã có tài liệu phân tích khoảng trống, con số đó gắn được vào từng dòng công việc và bạn kiểm tra được. Ngược lại, nếu báo giá đến ngay sau một buổi giới thiệu sản phẩm thì thứ bạn cầm là một phỏng đoán, và phỏng đoán luôn được điều chỉnh về sau bằng các yêu cầu thay đổi.

Trên diễn đàn của Odoo, trong một chủ đề than phiền về dự án của mình, một doanh nghiệp tóm tình trạng đó trong đúng một câu, rằng mọi thay đổi hay làm rõ nhỏ đều biến thành một báo giá mới.

Công tùy biến khác mọi dòng còn lại ở chỗ nó không được trả một lần. Chi phí mang vác của phần đã customize qua từng lần nâng cấp thuộc về một bài riêng, ở đây bạn chỉ cần ghi rằng mỗi hạng mục tùy biến sinh ra một dòng lặp lại chứ không phải một dòng trọn gói.

Chi phí của dữ liệu

Đây là khoản gần như không có mặt trong các bản báo giá tôi từng đọc, và cũng là khoản làm trượt tiến độ nhiều nhất.

Cách nạp dữ liệu theo từng đối tượng đã có bài riêng, ở đây tôi chỉ nói phần tốn kém. Về mặt chi phí, dữ liệu gồm ba lớp việc tách bạch nhau là làm sạch, chuẩn hóa, rồi nạp và đối soát.

Chỉ lớp cuối là phần bên triển khai làm chính, còn hai lớp đầu rơi vào người của doanh nghiệp. Không phải vì bên triển khai lười, mà vì chỉ người trong nhà mới biết hai dòng gần giống nhau kia là một hay hai thứ, và cũng chỉ họ đủ thẩm quyền chốt một bộ danh mục dùng chung. Việc doanh nghiệp phải tự chuẩn bị gì trước khi mở dự án là chủ đề của một bài khác, còn ở đây thì dữ liệu phải có ba dòng.

Thời gian của người trong doanh nghiệp

Nếu chỉ được thêm một dòng vào bảng, tôi đề nghị thêm dòng này, bởi nó lớn, kéo dài suốt dự án, và không xuất hiện trên hóa đơn nào nên rất dễ bị coi như miễn phí.

Hãy nhớ rằng người mà dự án cần nhất ở mỗi bộ phận thường là người đang bận nhất. Họ ngồi trong các buổi khảo sát, đọc và xác nhận lưu đồ, tham gia nghiệm thu, làm sạch dữ liệu của bộ phận mình, đi học rồi dạy lại cho đồng nghiệp, trong khi khối lượng công việc hằng ngày của họ hầu như không giảm đi tương ứng.

Nên dự án chậm không phải vì bên triển khai chậm, mà vì mỗi lần chờ một xác nhận lại mất vài ngày.

Cách ước lượng thì đơn giản, chỉ là ít người ngồi làm. Bạn lấy số buổi khảo sát nhân với số người tham dự và thời lượng, cộng thời gian đọc tài liệu, nghiệm thu và làm dữ liệu, rồi quy ra số ngày làm việc bị chiếm.

Con số đó không cần chính xác, chỉ cần đủ lớn để người ký quyết định hiểu rằng mình đang cam kết một nguồn lực nội bộ chứ không chỉ một khoản tiền. Trong trường hợp doanh nghiệp thuê người làm thay việc thường ngày cho vài nhân sự chủ chốt suốt mấy tháng cao điểm, khoản ẩn đó trở thành một khoản có tên.

Đào tạo và đào tạo lại

Đợt đào tạo trước go-live thì bên nào cũng nhớ. Khoản hay bị quên là những đợt sau nó.

Doanh nghiệp có người nghỉ việc và người mới vào, có bộ phận thay trưởng nhóm, có mùa cao điểm phải tuyển nhân sự thời vụ, và mỗi lần như vậy là một lần dạy lại từ đầu cho người chưa từng thấy hệ thống. Nếu không ai chuẩn bị trước thì phần dạy lại rơi vào người dùng cũ theo kiểu truyền miệng, mà truyền miệng thì mỗi đời lệch một chút, cho tới lúc không ai còn làm đúng quy trình ban đầu.

Do đó bạn nên tách dòng đào tạo thành hai, một dòng đợt đầu và một dòng định kỳ, đồng thời hỏi bên triển khai rằng tài liệu hướng dẫn bàn giao ở dạng nào và ai chịu trách nhiệm cập nhật nó, bởi tài liệu tốt làm các đợt dạy lại rẻ đi nhiều.

Vận hành sau go-live

Chi phí không dừng ở ngày go-live, nó chỉ đổi từ chi phí dự án sang chi phí vận hành.

Mức tốn kém của phần hỗ trợ giai đoạn đầu phụ thuộc vào một thứ ít ai nghĩ tới lúc ký hợp đồng, đó là nhịp làm việc của khách, và nhịp đó quyết định khoản này nhiều hơn cả phạm vi phần mềm. Cùng một phạm vi, nhưng một doanh nghiệp chạy ba ca và một doanh nghiệp làm một ca sẽ ra hai mức chi phí hỗ trợ khác hẳn nhau; cách bố trí người theo ca của khách đã có bài riêng.

Với phần bảo trì định kỳ, các trang của nhà cung cấp hay nhắc tới một tỷ lệ tính theo giá trị dự án, nhưng truy ngược thì tôi không thấy nguồn gốc của nó nên không đưa vào đây. Cái cần hỏi là hợp đồng bảo trì gồm:

• bao nhiêu giờ hỗ trợ
• thời gian phản hồi cam kết
• và ranh giới giữa lỗi được sửa miễn phí với yêu cầu thay đổi phải trả thêm

Bên cạnh hỗ trợ và bảo trì, vòng đời một phiên bản và quy trình một lần nâng cấp đã có bài riêng. Thứ phải đưa vào bảng chi phí chỉ gồm hai dòng, là mốc phải nâng cấp và bên chịu trách nhiệm nâng cấp phần nằm ngoài sản phẩm chuẩn.

Khoản cuối cùng khó đo nhất, đó là cái giá của quãng hệ thống chưa chạy trơn. Trong quãng đó doanh nghiệp thường vận hành hai nơi cùng lúc, vừa nhập vào hệ thống mới vừa giữ cách làm cũ trên sổ hoặc bảng tính cho yên tâm, và đây là khoản rất hay bị đánh giá thấp, bởi nó không nằm trên hóa đơn nào mà nằm trong giờ làm của chính nhân viên.

Khoản này không quy ra tiền chính xác được, nhưng vẫn ước lượng được, bằng cách hỏi bộ phận chịu ảnh hưởng nặng nhất rằng thao tác của họ chậm đi ba tuần thì hệ quả với khách hàng là gì, rồi ghi câu trả lời ấy vào bảng dưới dạng một rủi ro.

Bảng chi phí bạn tự dựng

Thứ thay thế được cho con số là bảng dưới đây, mỗi khoản chi một dòng, gồm sáu cột.

Cột cuối có giá trị nhất, bởi nó cho người ký quyết định thấy phần nào của con số tổng là chắc và phần nào còn lỏng.

Một bảng nhiều dòng đang đoán không phải bảng tồi, nó chỉ ra đúng chỗ cần hỏi trước khi ký.

Đi kèm bảng là những dòng bạn nên đề nghị nhà cung cấp tách riêng thay vì gộp vào một chữ trọn gói, bởi gộp lại thì không so sánh được hai bản báo giá:

• Tách phí phần mềm theo người dùng và theo phân hệ
• Tách hạ tầng thành môi trường thật và môi trường thử
• Liệt kê dịch vụ bên thứ ba phải mua thêm
• Tách công triển khai theo từng giai đoạn
• Tách từng hạng mục tùy biến thành một dòng riêng
• Tách dữ liệu thành làm sạch, chuẩn hóa và nạp
• Tách đào tạo thành đợt đầu và các đợt sau
• Ghi rõ hỗ trợ sau go-live theo tuần, người và ca làm việc
• Ghi rõ phạm vi và thời gian phản hồi của bảo trì định kỳ
• Chỉ rõ trách nhiệm nâng cấp phần ngoài sản phẩm chuẩn

Những gì bài này không trả lời được

Có ba chỗ tôi phải nói thẳng.

1. Thứ nhất là toàn bộ phần số, gồm đơn giá phần mềm, đơn giá hạ tầng, đơn giá ngày công và tổng chi phí theo quy mô, bởi tôi không có nguồn công bố nào để đối chiếu, mà một con số sai ở đây sẽ đi thẳng vào cuộc thương lượng thật của người đọc.
2. Thứ hai là cơ cấu chi phí theo tỷ lệ, thứ nội dung nước ngoài rất hay đưa ra, nhưng các tỷ lệ đang lưu hành đều trích lại qua nhiều tầng mà không truy về được báo cáo gốc, đúng như chuyện đã xảy ra với con số tỷ lệ thất bại mà một bài khác đã truy ngược tới tận nơi.
3. Thứ ba, bản đồ này dựng từ các nhóm chi phí tôi quan sát được khi đi triển khai chứ không từ hồ sơ quyết toán của một dự án, nên nó giúp bạn không bỏ sót dòng nào, chứ chưa nói được dòng nào nặng hơn.

Cần lưu ý thêm rằng bảng đầy đủ nhất cũng chỉ mô tả được phần mua bán, trong khi khoản đắt nhất lại là thời gian và sự hợp tác của chính người trong doanh nghiệp. Giá trị của khoản đó không do bảng giá nào quyết định mà do việc những người ấy có chịu đổi cách làm hay không, và phần việc làm cho thay đổi đó thật sự xảy ra thì đã có một bài riêng.