Phần lớn các phần mềm bị bỏ ở công ty nhỏ không phải vì phần mềm kém, mà vì công ty chọn sai việc để bắt đầu, nhập dữ liệu bẩn, không ai phụ trách và không bao giờ dừng cách làm cũ. Tin tốt là nhiều dự án đang chững vẫn cứu được trong khoảng một tháng nếu chẩn đoán đúng nguyên nhân, thay vì vội kết luận phần mềm không hợp rồi đi mua phần mềm khác và lặp lại đúng vòng cũ.
Bài này dành cho chủ doanh nghiệp đang trả tiền thuê một phần mềm mà nhân viên ít dùng, hoặc đang cân nhắc đổi phần mềm lần thứ hai. Bạn sẽ có danh sách nguyên nhân thường gặp, bộ câu hỏi chẩn đoán, bảng quyết định cứu hay dừng, kế hoạch 30 ngày và cách dùng AI để đọc phản hồi của nhân viên.
Phần mềm có, không ai dùng: một kịch bản quen thuộc
Ví dụ giả định: một xưởng may gia công khoảng ba mươi người thuê phần mềm quản lý đơn hàng và sản xuất. Ba tháng đầu, quản lý xưởng nhập đơn đều đặn. Tháng thứ tư vào mùa cao điểm, đơn dồn dập, mọi người quay lại ghi sổ và nhắn tin cho nhanh, định bụng hết mùa sẽ nhập bù. Hết mùa, khối dữ liệu cần nhập bù quá lớn nên không ai làm. Sáu tháng sau, phần mềm vẫn được gia hạn hằng năm nhưng chỉ còn kế toán mở để xem danh sách khách.
Kịch bản này lặp lại ở rất nhiều công ty với những biến thể khác nhau. Điều đáng chú ý là không có thời điểm nào ai quyết định bỏ phần mềm. Nó bị bỏ dần, qua từng ngày bận rộn, từng lần ngoại lệ được cho phép. Vì vậy, dấu hiệu nguy hiểm nhất không phải là nhân viên phàn nàn, mà là sự im lặng: không ai còn hỏi gì về phần mềm nữa.
Một hệ quả ít được nhìn thấy là chi phí cơ hội. Công ty vẫn trả tiền thuê, vẫn tốn thời gian đã bỏ ra để chọn, nhập dữ liệu, đào tạo, nhưng không nhận lại được gì. Tệ hơn, nhân viên rút ra bài học rằng các dự án thay đổi của công ty rồi cũng sẽ bị bỏ, và lần sau sẽ hưởng ứng ít hơn.
Nguyên nhân thường gặp
Chọn phần mềm theo buổi giới thiệu, không theo việc thật. Phần mềm nhiều tính năng nhưng không làm trôi những tình huống bán hàng hay sản xuất đặc thù của công ty, nên nhân viên phải làm vòng ngoài.
Dữ liệu ban đầu bẩn. Danh mục hàng trùng, tồn kho đầu kỳ sai, nên số trên phần mềm không khớp thực tế. Một khi nhân viên không tin con số, họ quay về sổ cũ.
Không có người phụ trách rõ tên. Dự án được giao chung cho cả nhóm hoặc cho người đã quá tải việc, nên vướng mắc không ai giải quyết.
Không bao giờ dừng cách cũ. Chạy song song kéo dài làm nhân viên phải ghi hai lần. Khi bận, họ bỏ cái tốn công hơn, và đó luôn là phần mềm mới.
Chủ không dùng. Chủ vẫn hỏi số liệu qua tin nhắn, vẫn duyệt việc bằng miệng, nên nhân viên hiểu phần mềm chỉ là hình thức.
Chuyển đổi vào mùa cao điểm. Thời điểm bận nhất là lúc nhân viên ít kiên nhẫn với thứ mới nhất.
Đào tạo một lần rồi thôi. Không có người kèm, không có tài liệu ngắn, nhân viên mới vào sau không được ai dạy.
Phần mềm không khớp quy trình nhưng không ai điều chỉnh. Có chỗ nên đổi cách làm cho khớp phần mềm, có chỗ nên cấu hình phần mềm cho khớp cách làm; không ai đứng ra quyết nên cứ vướng mãi.
Bộ câu hỏi chẩn đoán dự án đang chững
Trước khi quyết định cứu hay bỏ, dành một buổi trả lời các câu hỏi sau, tốt nhất là hỏi trực tiếp từng nhóm người dùng chứ không chỉ hỏi người phụ trách:
- Hôm nay có bao nhiêu phần trăm đơn hàng, phiếu nhập, phiếu xuất được ghi trên phần mềm, bao nhiêu còn ghi ngoài?
- Ai còn dùng phần mềm hằng ngày, ai đã thôi, và họ thôi từ lúc nào?
- Những thao tác nào nhân viên phải làm vòng ngoài phần mềm, vì sao?
- Số liệu trên phần mềm lệch thực tế ở đâu: tồn kho, công nợ, doanh thu?
- Có lỗi nào đã báo cho bên bán mà chưa được giải quyết?
- Người phụ trách dự án còn thời gian cho việc này không?
- Nếu ngày mai phần mềm biến mất, ai sẽ thấy khó khăn và khó khăn gì?
Câu hỏi cuối rất đáng giá. Nếu không ai thấy khó khăn, phần mềm đã thực sự bị bỏ. Nếu có một hai bộ phận vẫn cần nó, đó là điểm tựa để cứu dự án từ chỗ đang chạy tốt.
Cứu hay dừng: bảng quyết định
Không phải dự án nào cũng nên cứu. Dựa trên kết quả chẩn đoán, đối chiếu với bảng sau:
| Tình trạng | Hướng nên đi | Lý do |
|---|---|---|
| Phần mềm làm được việc, nhưng dữ liệu bẩn và thiếu người phụ trách | Cứu | Nguyên nhân nằm ở cách triển khai, sửa được trong vài tuần |
| Phần mềm làm được phần lớn việc, thiếu vài tình huống đặc thù | Cứu và điều chỉnh | Cấu hình lại, đổi quy trình chỗ hợp lý, bù bằng bước thủ công nhỏ |
| Phần mềm không làm được các tình huống cốt lõi dù đã cấu hình | Dừng và chọn lại | Cứu chỉ kéo dài thêm thời gian và chi phí |
| Bên bán không hỗ trợ, lỗi kéo dài nhiều tháng | Dừng, xuất dữ liệu trước | Rủi ro mất dữ liệu và gián đoạn lớn hơn lợi ích |
| Công ty đang trong giai đoạn biến động lớn | Tạm dừng có kế hoạch | Chọn thời điểm ổn định hơn để làm lại cho đúng |
Nếu quyết định dừng, hãy xuất toàn bộ dữ liệu trước khi hết hạn thuê bao, và ghi lại bài học bằng văn bản. Phần mềm tiếp theo sẽ gặp đúng những vấn đề đó nếu cách triển khai không đổi.
Kế hoạch 30 ngày để dùng lại phần mềm
Khi quyết định cứu, đây là khung gợi ý trong một tháng, bạn điều chỉnh theo quy mô và nghiệp vụ của mình:
- Ngày 1–3: chủ doanh nghiệp tuyên bố lại cam kết trước toàn công ty, chỉ định một người phụ trách rõ tên và giảm bớt việc cũ của người này.
- Ngày 4–10: thu hẹp phạm vi về một hai nghiệp vụ cốt lõi, như bán hàng và kho; tạm gác các phân hệ khác.
- Ngày 4–10: làm sạch lại danh mục, kiểm kho thật, nhập lại số dư cho đúng.
- Ngày 11–15: đào tạo lại theo vai trò, có người kèm và tài liệu một trang; xử lý dứt điểm các lỗi đã báo với bên bán.
- Ngày 16: dừng cách làm cũ ở phần nghiệp vụ đã chọn, thông báo rõ ngày và lý do.
- Ngày 17–30: người phụ trách kiểm mỗi ngày số đơn trên phần mềm so với thực tế; chủ mở phần mềm xem số liệu và hỏi về con số trong đó ở mỗi buổi giao ban.
Mục tiêu sau 30 ngày không phải là dùng hết phần mềm, mà là một hai nghiệp vụ cốt lõi chạy hoàn toàn trên phần mềm, số liệu đáng tin. Từ đó mới mở rộng sang các phần khác, mỗi lần một phần.
Dùng AI đọc phản hồi của nhân viên
Khi hỏi nhân viên vì sao không dùng phần mềm, bạn sẽ nhận được nhiều câu trả lời rời rạc qua tin nhắn, ghi chú, lời kể. AI giúp gom và phân loại những phản hồi này để thấy vấn đề chung. Câu lệnh mẫu: "Dưới đây là phản hồi của nhân viên một cửa hàng về phần mềm quản lý bán hàng đang dùng, đã bỏ tên người. Hãy nhóm các phản hồi theo loại vấn đề: lỗi phần mềm, thiếu tính năng, thiếu đào tạo, quy trình chưa khớp, thái độ với thay đổi. Mỗi nhóm cho biết số lượng phản hồi và trích một hai câu tiêu biểu."
Trước khi dán, bỏ tên nhân viên và những chi tiết giúp nhận ra ai nói gì. Mục đích là tìm vấn đề của hệ thống, không phải tìm người để trách. Nếu nhân viên biết phản hồi của họ bị truy ra để phê bình, lần sau họ sẽ không nói thật nữa.
Sau khi có các nhóm vấn đề, bạn có thể hỏi tiếp AI để lập danh sách việc cần làm cho từng nhóm và sắp theo mức độ ảnh hưởng. Đây vẫn là gợi ý; người phụ trách cần đối chiếu với tình hình thật, gặp lại vài nhân viên để kiểm xem AI có hiểu đúng ý họ không, rồi mới đưa vào kế hoạch 30 ngày.
Bài học cho lần chuyển đổi tiếp theo
Dù cứu được hay phải dừng, hãy ghi lại những điều rút ra thành một trang ngắn và lưu cùng hồ sơ dự án. Những bài học hay gặp nhất ở công ty nhỏ:
- Viết yêu cầu dựa trên tình huống có thật trước khi xem phần mềm, và dùng thử bằng dữ liệu thật thay vì dữ liệu mẫu.
- Làm sạch dữ liệu và kiểm kho thật trước khi nhập, chấp nhận mất thêm vài ngày ở đầu dự án.
- Chỉ định một người phụ trách có thời gian, và giảm việc cũ của người đó trong suốt giai đoạn chuyển đổi.
- Đặt ngày dừng cách làm cũ ngay từ đầu và giữ đúng, kể cả khi có người xin thêm thời gian.
- Tránh chuyển đổi vào mùa cao điểm; chọn giai đoạn công việc đều để nhân viên có sức học.
- Bắt đầu với một hai nghiệp vụ, thành công rồi mới mở rộng.
- Đo số liệu trước và sau để biết dự án có thật sự giúp được gì, thay vì dựa vào cảm giác.
Trang bài học này đặc biệt có ích khi công ty đổi người phụ trách hay chủ doanh nghiệp bận việc khác. Người sau đọc một trang là tránh được những vấp ngã mà người trước đã trả giá bằng nhiều tháng. Nếu dừng hẳn, ghi thêm lý do dừng và dữ liệu đã xuất được lưu ở đâu.
Câu hỏi thường gặp
Phần mềm bị bỏ có phải do chọn sai phần mềm không?
Thường là không. Phần lớn trường hợp nguyên nhân nằm ở cách triển khai: dữ liệu bẩn, không có người phụ trách, không dừng cách làm cũ, chủ không dùng. Đổi sang phần mềm khác mà giữ nguyên cách triển khai thì dễ lặp lại kết quả cũ.
Khi nào nên bỏ hẳn phần mềm đang dùng?
Khi phần mềm không làm được các tình huống nghiệp vụ cốt lõi dù đã cấu hình, hoặc bên bán không hỗ trợ và lỗi kéo dài. Trước khi dừng, hãy xuất toàn bộ dữ liệu và ghi lại bài học để lần chọn sau không lặp lại.
Có nên cho phép nhân viên ghi sổ khi đang bận rồi nhập bù sau không?
Nên hạn chế tối đa. Nhập bù thường không bao giờ được làm đủ, và mỗi ngoại lệ được cho phép làm phần mềm bị bỏ dần. Nếu phần mềm làm chậm việc lúc đông khách, cần sửa nguyên nhân thay vì cho phép ghi ngoài.
Chủ doanh nghiệp cần làm gì để nhân viên dùng phần mềm?
Chủ cần tự dùng phần mềm để xem số liệu, hỏi về con số trong phần mềm ở các buổi giao ban, và giữ đúng ngày dừng cách làm cũ. Khi chủ vẫn hỏi số liệu qua tin nhắn, nhân viên sẽ hiểu phần mềm chỉ là hình thức.
Thu hẹp phạm vi phần mềm có phải là lùi bước không?
Không. Thu hẹp về một hai nghiệp vụ cốt lõi giúp dự án có thành công thật, số liệu đáng tin và nhân viên lấy lại niềm tin. Sau đó mở rộng dần từng phần sẽ nhanh hơn so với cố dùng tất cả cùng lúc.
Có nên đòi bên bán phần mềm hoàn tiền khi không dùng được?
Tuỳ hợp đồng và nguyên nhân. Nếu phần mềm không đáp ứng những gì đã cam kết bằng văn bản, bạn có cơ sở để trao đổi. Nếu nguyên nhân nằm ở cách triển khai của công ty, cách tốt hơn là đề nghị bên bán hỗ trợ triển khai lại.