Khi bắt đầu chuyển đổi số, một doanh nghiệp nhỏ thường đứng trước nhiều lựa chọn: quản lý khách hàng, đơn hàng, kế toán, lịch hẹn hoặc nhân sự. Nếu chọn theo độ nổi bật của công cụ, doanh nghiệp có thể triển khai nhiều phần mềm nhưng nhân viên vẫn phải đối chiếu thông tin bằng tin nhắn và bảng tính.
Điểm xuất phát nên là một vấn đề vận hành đủ cụ thể để cả người quản lý và người trực tiếp làm việc cùng nhận ra. Trước khi hỏi nên mua phần mềm nào, hãy làm rõ công việc nào cần thay đổi, sự thay đổi đó có ích cho ai và kết quả sẽ được kiểm tra bằng cách nào.
1. Tách vấn đề thực tế khỏi mong muốn về công cụ
“Cần có CRM” là một ý tưởng về giải pháp. “Yêu cầu của khách bị bỏ sót vì không có người tiếp nhận rõ ràng” mới mô tả vấn đề cần giải quyết. Sự phân biệt này giúp doanh nghiệp tìm được nhiều phương án hơn: điều chỉnh trách nhiệm, thống nhất dữ liệu, cấu hình công cụ hiện có hoặc triển khai phần mềm mới.
Hãy dành thời gian quan sát một vài tình huống thật. Yêu cầu đến từ đâu, ai ghi nhận, thông tin nào bị hỏi lại và bước nào thường phải chờ? Đừng chỉ hỏi người quản lý về quy trình dự kiến; cần đối chiếu với cách nhân viên đang xử lý những trường hợp phát sinh.
2. Lập danh sách điểm nghẽn rồi chọn ưu tiên
Một danh sách ngắn có thể gồm đơn hàng nhập nhiều lần, khó xác định người phụ trách khách, lịch hẹn không được cập nhật hoặc báo cáo cuối ngày cần ghép nhiều tệp. Với mỗi vấn đề, ghi lại tác động, tần suất và người bị ảnh hưởng.
MAXVSYS đề xuất đánh giá từng vấn đề theo bốn câu hỏi. Đây là khung lựa chọn tham khảo, không phải thang đánh giá chuẩn áp dụng cho mọi doanh nghiệp:
- Tác động: vấn đề làm chậm công việc, tạo sai lệch hay ảnh hưởng trải nghiệm khách hàng như thế nào?
- Tần suất: xảy ra thường xuyên hay chỉ trong một tình huống hiếm?
- Khả năng thử nghiệm: có thể giới hạn ở một nhóm hoặc một luồng việc để kiểm tra không?
- Mức sẵn sàng: đã có người phụ trách, dữ liệu và thời gian tham gia triển khai chưa?
Ưu tiên đầu tiên không nhất thiết là vấn đề có quy mô lớn nhất. Một bài toán có tác động rõ và phạm vi kiểm soát được thường giúp đội ngũ học cách triển khai trước khi mở rộng sang những thay đổi phức tạp hơn.
3. Mô tả quy trình hiện tại bằng ngôn ngữ công việc
Vẽ các bước từ lúc công việc bắt đầu đến khi hoàn tất. Mỗi bước cần có người thực hiện, thông tin đầu vào, kết quả đầu ra và điều kiện chuyển sang bước tiếp theo. Đánh dấu nơi có quyết định phê duyệt hoặc bàn giao giữa hai bộ phận.
Cũng cần ghi nhận ngoại lệ: khách đổi yêu cầu, nhân viên nghỉ, dữ liệu thiếu hoặc một đơn bị trả lại. Nếu chỉ mô tả tình huống thuận lợi, phần mềm có thể chạy đúng trong buổi trình diễn nhưng nhân viên vẫn phải xử lý ngoài hệ thống khi công việc thực tế thay đổi.
4. Chuẩn bị dữ liệu tối thiểu và người chịu trách nhiệm
Liệt kê những thông tin thực sự cần cho quy trình đã chọn. Ví dụ, luồng tiếp nhận yêu cầu có thể cần mã yêu cầu, ngày tiếp nhận, người phụ trách, trạng thái và thời hạn phản hồi. Mỗi trường cần có ý nghĩa rõ ràng và một nơi lưu được dùng làm căn cứ chính.
Người quản lý nghiệp vụ cần xác nhận quy tắc; nhân viên trực tiếp sử dụng cần góp ý về thao tác; đội kỹ thuật phụ trách cấu hình và kết nối. Doanh nghiệp cũng cần một người có quyền chốt phạm vi để các ý kiến không biến thành danh sách tính năng thay đổi liên tục.
5. Đặt tiêu chí kết quả trước khi chạy thử
Chỉ tiêu nên gắn với vấn đề ban đầu. Nếu mục tiêu là tránh bỏ sót yêu cầu, hãy theo dõi số yêu cầu chưa có người phụ trách hoặc chưa phản hồi đúng hạn. Nếu mục tiêu là giảm nhập lại, hãy đo số lần một thông tin được ghi ở các hệ thống khác nhau.
Thống nhất cách tính, nguồn dữ liệu và thời điểm ghi nhận. Cần đo một giai đoạn trước thay đổi để có cơ sở so sánh. Khi đánh giá sau thử nghiệm, xem cả khối lượng công việc và thay đổi nhân sự; không nên quy mọi khác biệt cho phần mềm.
6. Thử giải pháp bằng một tình huống đầy đủ
Giả sử một doanh nghiệp dịch vụ đang tiếp nhận yêu cầu qua nhiều kênh. Một thử nghiệm có thể theo dõi trọn luồng: ghi nhận yêu cầu, giao người phụ trách, bổ sung thông tin, phản hồi và đóng yêu cầu. Nhóm thử cần biết nơi nào là dữ liệu chính và cách xử lý khi yêu cầu trùng hoặc đổi người phụ trách.
Đây là ví dụ minh họa, không phải một dự án khách hàng cụ thể. Kết quả cần kiểm tra là đội ngũ có nhận biết công việc đang chờ và trách nhiệm hiện tại hay không, cùng với mức độ dễ sử dụng trong ca làm việc thực tế.
7. Biết khi nào chưa nên mở rộng
Nếu người dùng vẫn phải ghi sổ riêng vì hệ thống không xử lý được tình huống thường gặp, cần tìm nguyên nhân trước khi thêm bộ phận mới. Nếu báo cáo chưa thống nhất định nghĩa hoặc dữ liệu còn thiếu, mở rộng có thể làm số liệu sai lan nhanh hơn.
Trước bước tiếp theo, hãy kiểm tra hướng dẫn theo vai trò, phân quyền, nơi tiếp nhận hỗ trợ và khả năng khôi phục dữ liệu. Những yếu tố này giúp việc sử dụng tiếp tục ổn định sau giai đoạn đội triển khai hỗ trợ sát.
Checklist cho buổi trao đổi đầu tiên với nhà cung cấp
- Mô tả một quy trình đang gặp khó và cung cấp vài tình huống đại diện đã loại bỏ thông tin nhạy cảm.
- Nêu rõ kết quả muốn cải thiện, cách đo hiện tại và những giới hạn về thời gian, ngân sách, nhân sự.
- Liệt kê hệ thống đang dùng, dữ liệu cần giữ và yêu cầu kết nối bắt buộc.
- Thống nhất người phụ trách, phạm vi thử nghiệm và điều kiện nghiệm thu.
- Hỏi cách đào tạo, hỗ trợ sau bàn giao và xuất dữ liệu khi cần chuyển đổi.
Doanh nghiệp SME nên bắt đầu từ một thay đổi có thể kiểm chứng trong công việc hằng ngày. Khi đã hiểu vấn đề, dữ liệu và cách phối hợp, việc lựa chọn công nghệ sẽ có cơ sở hơn. Bạn có thể trao đổi với MAXVSYS để cùng làm rõ phạm vi phù hợp.