Công ty bạn đã thử qua khá nhiều phần mềm CRM, ERP hoặc các module quản lý khác nhau. Đổi nhà cung cấp, thử thêm một hệ thống mới, cho nhân viên học lại cách sử dụng, rồi sau một thời gian vẫn quay về cảm giác quen thuộc: phần mềm có rất nhiều chức năng nhưng công việc thực tế chẳng hiệu quả hơn bao nhiêu, thậm chí càng dùng càng “chán”.
Nếu tình trạng này đã lặp lại vài lần, có lẽ vấn đề không còn nằm ở việc tìm thêm một phần mềm khác.
Đây có thể là lúc doanh nghiệp nên nghĩ tới chuyện xây lại một hệ thống dành riêng cho cách công ty mình đang vận hành.
Và câu hỏi gần như chắc chắn xuất hiện ngay sau đó là:
Xây lại phần mềm thì tốn bao nhiêu tiền?
Không có một con số cố định cho mọi doanh nghiệp. Một công ty chỉ cần CRM quản lý khách hàng, dự án và công việc sẽ có phạm vi hoàn toàn khác với doanh nghiệp cần thêm báo giá, phê duyệt, KPI, kho, công nợ hay những nghiệp vụ kỹ thuật riêng.
Nhưng có một điều khá quan trọng: xây phần mềm riêng không đồng nghĩa phải xây tất cả mọi thứ ngay từ đầu.
Nếu biết chọn đúng phần lõi cần làm trước, chi phí có thể thấp hơn khá nhiều so với hình dung ban đầu.
Đừng bắt đầu bằng việc xây tất cả những gì công ty đang có
Khi bắt đầu nói về phần mềm riêng, rất dễ rơi vào một suy nghĩ như thế này:
Công ty đang có CRM, công việc, KPI, báo giá, nhân sự, tài liệu, kho và báo cáo. Vậy hệ thống mới phải có đầy đủ tất cả ngay từ phiên bản đầu tiên.
Cách nghĩ này gần như chắc chắn làm chi phí tăng rất nhanh.
Không những vậy, thời gian triển khai cũng dài hơn, lượng chức năng cần kiểm thử lớn hơn và nhân viên phải tiếp nhận một hệ thống mới quá nhiều thứ cùng lúc.
Theo kinh nghiệm triển khai của SYP, cách thực tế hơn là tìm ra phần lõi đang ảnh hưởng nhiều nhất tới hoạt động hàng ngày rồi giải quyết phần đó trước.
Ví dụ với một doanh nghiệp bán hàng dự án, phần lõi có thể nằm ở luồng:
khách hàng → contact → dự án/deal → công việc → kỹ thuật → báo giá → phê duyệt → theo dõi tiến độ.
Nếu hiện tại nhân viên đang mất rất nhiều thời gian ở chính chuỗi này thì việc xây nó cho thật rõ ràng đã có thể tạo ra khác biệt lớn.
KPI có thể làm sau.
Một số báo cáo nâng cao có thể để giai đoạn sau.
Nhân sự nếu hệ thống hiện tại vẫn đáp ứng được thì chưa cần đưa vào.
Phần mềm riêng không bắt buộc phải trở thành một “siêu ứng dụng” ngay ngày đầu tiên.
Ngược lại, một hệ thống nhỏ nhưng xử lý đúng phần doanh nghiệp đang mất thời gian nhất thường có giá trị hơn rất nhiều so với một hệ thống chứa hàng trăm chức năng nhưng nhân viên chỉ sử dụng một phần nhỏ.
Dưới 100 triệu vẫn có thể xây được một CRM đủ để vận hành
Nhiều doanh nghiệp nghe tới “phần mềm theo yêu cầu” thường mặc định đây phải là dự án vài trăm triệu hoặc thậm chí hàng tỷ đồng.
Điều đó có thể đúng với những hệ thống lớn, nhiều tích hợp và nghiệp vụ phức tạp.
Nhưng với doanh nghiệp vừa và nhỏ, nếu phạm vi được làm rõ và tập trung đúng vào những chức năng lõi thì một hệ thống CRM dưới 100 triệu đồng hoàn toàn có thể là một phạm vi khả thi.
Quan trọng nằm ở chữ phạm vi.
Một CRM quản lý khách hàng, contact, deal, công việc, trạng thái dự án, báo giá cơ bản và phân quyền sẽ khác hoàn toàn một hệ thống cần thêm BOQ kỹ thuật, kho, công nợ, quy trình duyệt nhiều cấp, ứng dụng mobile, GPS, dashboard nâng cao hay tích hợp kế toán.
Vì vậy SYP không tiếp cận báo giá theo kiểu:
“CRM bên tôi giá X triệu.”
Thay vào đó, hệ thống được tách thành từng hạng mục chức năng để doanh nghiệp biết rõ mình đang trả tiền cho cái gì.
Đây cũng là cách đơn giản nhất để kiểm soát ngân sách.
Không cần mua nguyên một “cục” phần mềm
Khi khảo sát xong quy trình, SYP có thể chia hệ thống thành những phần chức năng cụ thể và báo giá theo từng hạng mục.
Doanh nghiệp lúc đó có quyền lựa chọn.
Phần nào đang thực sự cần để vận hành thì làm ngay.
Phần nào tốt nếu có nhưng chưa cấp thiết có thể để sang giai đoạn 2.
Phần nào sau khi phân tích lại thấy không tạo ra nhiều giá trị thì có thể bỏ hẳn.
Điều này khá khác với việc mua một gói phần mềm có sẵn, nơi doanh nghiệp thường nhận cả một tập hợp tính năng do nhà cung cấp đã định nghĩa trước.
Với custom software, câu hỏi không nên là:
“Phần mềm có bao nhiêu chức năng?”
Mà nên là:
“Những chức năng nào thực sự giúp công ty làm việc tốt hơn?”
Khi trả lời được câu đó, chi phí thường giảm đi đáng kể.
Và quan trọng hơn, nhân viên sau này cũng không phải đối mặt với một giao diện chứa quá nhiều thứ mà họ chẳng bao giờ sử dụng.
Chi phí tư vấn ban đầu tại SYP là 0 đồng
Trước khi có thể nói một hệ thống nên có những chức năng nào, cần phải hiểu công ty hiện đang vận hành ra sao.
Vì vậy giai đoạn đầu thường không phải là ngồi xem một danh sách tính năng rồi đánh dấu cái nào cần làm.
SYP cần trao đổi trực tiếp với doanh nghiệp để hiểu flow hiện tại.
Một khách hàng mới đi vào hệ thống bằng cách nào?
Ai là người phụ trách?
Khi nào kỹ thuật tham gia?
Báo giá được tạo và duyệt ra sao?
Có những trường hợp nào thường xuyên đi lệch khỏi quy trình chuẩn?
Bước nào đang khiến nhân viên tốn nhiều thời gian nhất?
Và có những bước nào doanh nghiệp vẫn đang làm rất tốt, không cần thay đổi?
Đây là phần cực kỳ quan trọng vì xây phần mềm không có nghĩa phải thay đổi toàn bộ cách công ty đang làm việc.
Nếu một quy trình hiện tại đã hợp lý và hoạt động ổn định thì phần mềm nên được thiết kế để hỗ trợ nó.
Nếu trong quá trình trao đổi phát hiện một điểm đang quá vòng vèo hoặc gây mất kiểm soát, hai bên mới cùng xem xét có nên điều chỉnh trước khi đưa nó vào hệ thống hay không.
SYP hiện áp dụng tư vấn ban đầu miễn phí cho giai đoạn này.
Mục tiêu của những buổi trao đổi đầu tiên là làm rõ bài toán trước khi cả hai bên quyết định có nên bắt đầu dự án hay không.
Không phải bỏ toàn bộ tiền ngay từ đầu
Một câu hỏi khác khá thực tế là:
Nếu dự án khoảng 80–100 triệu thì có phải thanh toán toàn bộ ngay không?
Thông thường là không.
Các dự án của SYP thường được chia thành nhiều đợt thanh toán theo tiến độ thực tế, thay vì yêu cầu doanh nghiệp thanh toán toàn bộ trước khi nhìn thấy sản phẩm.
Tùy dự án và hợp đồng cụ thể, quá trình có thể được chia thành khoảng bốn mốc như tạm ứng để bắt đầu dự án, thanh toán sau khi có phiên bản demo theo phạm vi đã thống nhất, thanh toán khi hệ thống được triển khai lên server và phần còn lại theo mốc nghiệm thu/bảo hành.
Cách chia này có hai ý nghĩa.
Thứ nhất, doanh nghiệp không phải chịu toàn bộ áp lực tài chính cùng một lúc.
Thứ hai, tiền được chi theo tiến độ của chính sản phẩm.
Doanh nghiệp có thể nhìn thấy hệ thống dần hình thành, kiểm tra những chức năng đã triển khai và phản hồi trong quá trình phát triển.
Với một dự án phần mềm riêng, theo tôi đây là cách hợp lý hơn việc trả toàn bộ rồi chờ vài tháng mới biết sản phẩm cuối cùng trông như thế nào.
Phần mềm lên production chưa phải là lúc mọi thứ kết thúc
Có những vấn đề gần như không thể nhìn thấy hết trên bản thiết kế.
Một nút đặt ở vị trí này khi demo có vẻ hoàn toàn hợp lý, nhưng đến lúc nhân viên phải bấm nó 50 lần mỗi ngày mới thấy bất tiện.
Một bước trong workflow khi họp nghe rất logic, nhưng lúc chạy thật lại phát sinh một tình huống mà trước đó không ai nhớ tới.
Một màn hình có đầy đủ dữ liệu nhưng người dùng nhận ra thông tin quan trọng nhất lại nằm quá thấp.
Đó là chuyện rất bình thường.
Vì vậy sau khi hệ thống được đưa vào production, SYP áp dụng 6 tháng bảo hành.
Khoảng thời gian này trước hết dùng để xử lý những lỗi của hệ thống.
Nhưng trong phạm vi đã được hai bên thống nhất, đây cũng là thời gian để tiếp tục trao đổi những điều chỉnh nhỏ liên quan tới giao diện hoặc luồng sử dụng nếu thực tế cho thấy cần phải tối ưu thêm.
Điều này đặc biệt quan trọng với phần mềm nội bộ.
Bởi mục tiêu cuối cùng không phải là bàn giao được một hệ thống “đúng tài liệu”.
Mục tiêu là nhân viên sử dụng nó hàng ngày mà không cảm thấy phần mềm đang tạo thêm việc cho mình.
Sau 6 tháng, chi phí duy trì không nhất thiết phải cao
Một trong những lý do nhiều doanh nghiệp ngại phần mềm riêng là nghĩ rằng sau khi xây xong sẽ phải tiếp tục trả một khoản bảo trì lớn hàng năm.
Thực tế không nhất thiết như vậy.
Nếu doanh nghiệp muốn SYP tiếp tục bảo trì hệ thống định kỳ thì mức chi phí thường vào khoảng 8% giá trị hệ thống mỗi năm, tùy phạm vi hỗ trợ cụ thể.
Nhưng bảo trì cũng không phải lúc nào là bắt buộc.
Nếu hệ thống đã chạy ổn định, doanh nghiệp có thể tiếp tục sử dụng mà không cần mua một gói bảo trì hàng năm.
Khi nào xuất hiện nhu cầu mới, chẳng hạn muốn thêm một workflow, phát triển module mới hoặc thay đổi một phần nghiệp vụ, doanh nghiệp có thể liên hệ lại SYP để đánh giá và báo giá phần phát triển mới đó.
Điểm khác biệt ở đây là chi phí không nhất thiết tăng lên chỉ vì doanh nghiệp tuyển thêm vài nhân viên sử dụng hệ thống.
Sau khi phần mềm đã được xây và triển khai cho doanh nghiệp, phần lõi đó tiếp tục được sử dụng.
Nếu muốn nhìn bài toán rộng hơn theo thời gian sử dụng, có thể tham khảo tổng chi phí sở hữu phần mềm quản lý doanh nghiệp trong 5 năm.
Vậy chi phí xây lại phần mềm thực sự nên được tính như thế nào?
Theo tôi, đừng bắt đầu bằng câu:
“Làm một phần mềm quản lý công ty hết bao nhiêu?”
Câu hỏi đó quá rộng để có một con số có ý nghĩa.
Hãy bắt đầu bằng một câu thực tế hơn:
“Trong cách công ty đang vận hành hiện nay, phần nào đang làm chúng tôi mất nhiều thời gian hoặc khó kiểm soát nhất?”
Nếu câu trả lời là khách hàng và sales, hãy bắt đầu từ CRM.
Nếu vấn đề nằm ở báo giá và phê duyệt, hãy bắt đầu từ đó.
Nếu dự án chạy qua nhiều phòng ban nhưng không ai nhìn được toàn bộ tiến độ, hãy xây phần quản lý dự án và workflow trước.
Khi phần lõi hoạt động ổn định, những phần còn lại có thể được bổ sung từng bước.
Đây cũng là cách để một dự án phần mềm riêng không biến thành một khoản đầu tư quá lớn ngay từ đầu.
Với phạm vi phù hợp, doanh nghiệp có thể bắt đầu bằng một hệ thống dưới 100 triệu đồng, đưa vào vận hành thực tế rồi tiếp tục phát triển khi nhu cầu thật sự xuất hiện.
Xây lại phần mềm không nhất thiết phải là một dự án thật lớn
Nếu đã thử nhiều CRM, ERP hay các module phần mềm khác nhau nhưng vẫn không tìm được một hệ thống phù hợp, có thể vấn đề không phải là thị trường chưa có đủ phần mềm.
Có thể đơn giản là cách công ty bạn vận hành đủ khác để phần mềm đại trà không thể khớp hoàn toàn.
Lúc đó, xây một hệ thống riêng là một phương án đáng cân nhắc.
Nhưng không cần phải xây tất cả.
Không cần phải bỏ vài trăm triệu ngay từ đầu.
Và cũng không cần biến dự án thành một cuộc “thay máu” toàn bộ công nghệ của doanh nghiệp.
Hãy tìm đúng phần lõi.
Chia chức năng thành từng hạng mục.
Chọn những gì thực sự cần.
Triển khai.
Đưa nhân viên vào sử dụng.
Rồi mới quyết định phần tiếp theo có đáng để đầu tư hay không.
Chi phí xây lại phần mềm vì vậy không chỉ phụ thuộc vào phần mềm có bao nhiêu chức năng. Nó phụ thuộc rất nhiều vào việc doanh nghiệp có biết mình thực sự cần xây cái gì hay không.
Và nhiều khi, cách tiết kiệm nhất không phải tìm một đơn vị báo giá rẻ hơn.
Mà là bỏ những thứ chưa cần xây ra khỏi báo giá ngay từ đầu.