Mua phần mềm chưa phải chuyển đổi số: CDO thay đổi nhận thức tổ chức từ đâu?

Phần mềm đã chạy, cách làm việc có thay đổi không?

Doanh nghiệp đưa hệ thống mới vào sử dụng, nhưng nhân viên vẫn giữ bảng tính riêng, quản lý tiếp tục phê duyệt qua tin nhắn và khách hàng phải gọi nhiều lần để biết trạng thái yêu cầu. Dự án công nghệ có thể hoàn tất trong khi trải nghiệm dịch vụ và quyết định vận hành gần như chưa đổi.

Mua phần mềm tạo điều kiện để thay đổi, nhưng giá trị còn phụ thuộc quy trình, dữ liệu, trách nhiệm và hành vi sử dụng. CDO cần làm rõ sự khác biệt giữa tài sản công nghệ được bàn giao với kết quả doanh nghiệp muốn đạt. Nếu không, cuộc thảo luận dễ xoay quanh tính năng và giấy phép, còn vấn đề kinh doanh vẫn chưa có người chịu trách nhiệm.

Trong loạt bài này, CDO được hiểu là Chief Digital Officer, giám đốc chuyển đổi số. Điểm khởi đầu của vai trò là giúp tổ chức thống nhất điều gì cần thay đổi và vì sao. Nền tảng lãnh đạo chuyển đổi số hỗ trợ kết nối lựa chọn công nghệ với năng lực quản lý thay đổi và kết quả kinh doanh.

Phân biệt ba cấp độ thay đổi trong một cuộc trao đổi

Có thể dùng ba cấp độ thực hành để đặt câu hỏi. Số hóa thông tin chuyển dữ liệu sang dạng có thể xử lý bằng công cụ số. Cải tiến quy trình bằng công nghệ thay đổi cách công việc được thực hiện. Chuyển đổi ở cấp tổ chức tác động đến cách tạo giá trị, phối hợp, ra quyết định hoặc cung cấp sản phẩm và dịch vụ.

Ba cấp độ không phải những bước bắt buộc mọi doanh nghiệp phải đi qua theo thứ tự. Một nhu cầu số hóa hồ sơ có thể hợp lý và đủ phạm vi, không cần gọi là chuyển đổi mô hình kinh doanh. Ngược lại, mở một kênh trực tuyến chỉ tạo giá trị khi các phần thực hiện phía sau đáp ứng được lời hứa với khách hàng.

CDO dùng bảng để làm rõ phạm vi, không để xếp hạng các phòng ban. Tổ chức có thể cần các sáng kiến ở cả ba cấp độ. Điều phải tránh là đặt tên quá lớn cho một khoản mua sắm rồi sử dụng tên đó như bằng chứng thành công.

Bắt đầu từ một vấn đề mà kinh doanh nhận ra

Hỏi lãnh đạo và chủ quy trình về điều đang cản trở kết quả: khách hàng phải chờ, đơn hàng bị trả lại, dự báo không đáng tin hoặc nhân viên nhập dữ liệu nhiều lần. Mỗi vấn đề cần phạm vi và bằng chứng, thay vì những nhận xét như “doanh nghiệp chưa hiện đại”.

Quan sát công việc thực tế để hiểu chỗ chờ và nguyên nhân. Nếu phê duyệt chậm do quyền quyết định chưa rõ, chuyển biểu mẫu lên ứng dụng chưa chắc giải quyết. Nếu nhân viên tạo bảng riêng vì dữ liệu chính không đầy đủ, chỉ cấm bảng tính có thể làm họ mất công cụ mà chưa có phương án thay thế.

Chọn một vấn đề đủ quan trọng và có chủ sở hữu để thảo luận trước. CDO không cần thuyết phục toàn tổ chức bằng khẩu hiệu. Một quyết định rõ về trải nghiệm khách hàng hoặc hiệu quả quy trình tạo nền tảng tốt hơn cho việc thay đổi nhận thức.

Chuyển lời hứa công nghệ thành chuỗi bằng chứng

Với sáng kiến được đề xuất, mô tả chuỗi: năng lực mới, thay đổi công việc, mức áp dụng và kết quả mong muốn. Ví dụ, thông tin trạng thái dùng chung giúp nhân viên trả lời nhất quán; khách hàng nhận được cập nhật đúng lúc; số lần phải liên hệ lại có thể giảm. Mỗi mắt xích cần được kiểm chứng bằng dữ liệu phù hợp.

Không xem việc hệ thống hoạt động là bằng chứng người dùng đã áp dụng. Cũng không xem số lượt đăng nhập là bằng chứng quy trình tốt hơn. Cần biết người dùng có hoàn thành công việc theo cách mới không, còn phải dùng đường vòng nào và kết quả có đáp ứng tiêu chí dịch vụ không.

Quản lý lợi ích của APM phân biệt sản phẩm bàn giao và việc hiện thực hóa lợi ích. Trong doanh nghiệp, CDO nên cùng chủ quy trình xác định ai xác nhận kết quả và ai duy trì cách làm. Bộ phận IT chịu trách nhiệm phù hợp với công nghệ, nhưng không thể một mình bảo đảm mọi thay đổi nghiệp vụ.

Nếu quy đổi thành tiền, phải nêu giả định và phối hợp với tài chính. Thời gian giải phóng chưa tự trở thành tiết kiệm chi phí; cần biết năng lực đó được sử dụng thế nào. Kiến thức quản lý bộ phận IT giúp kết nối năng lực thực thi với trách nhiệm và nguồn lực vận hành.

Thay đổi nhận thức theo từng nhóm trách nhiệm

Ban điều hành cần hiểu lựa chọn kinh doanh và đánh đổi nguồn lực. Chủ quy trình cần biết trách nhiệm thiết kế và duy trì cách làm mới. Quản lý tuyến giữa cần biết cách giao việc, xử lý ngoại lệ và đánh giá. Nhân viên cần thấy công việc của mình thay đổi thế nào, được hỗ trợ gì và báo vướng mắc ở đâu.

Không dùng một bài trình bày kỹ thuật cho mọi nhóm. Với lãnh đạo, thảo luận kết quả và quyền quyết định. Với người thực hiện, dùng tình huống và thử nghiệm công việc. Khi có phản đối, tìm lý do: thiếu kỹ năng, mất thông tin, thêm thao tác hay lo ngại trách nhiệm; mỗi lý do cần cách xử lý khác nhau.

Sự thay đổi cũng cần thể hiện trong quản lý. Nếu lãnh đạo yêu cầu dùng dữ liệu chung nhưng vẫn quyết định từ báo cáo riêng không truy vết được, đội sẽ nhận thông điệp mâu thuẫn. CDO cần phối hợp để cách báo cáo, phê duyệt và ghi nhận kết quả hỗ trợ hành vi mong muốn.

Tình huống giả định: mua CRM nhưng khách hàng vẫn phải hỏi lại

Một doanh nghiệp giả định đã triển khai CRM. Bộ phận bán hàng nhập dữ liệu, nhưng bộ phận thực hiện đơn hàng chưa cập nhật trạng thái theo cùng quy tắc. Khách hàng vẫn phải gọi để biết tiến độ, còn nhân viên bán hàng dùng bảng riêng vì không tin thông tin trên hệ thống.

CDO không bắt đầu bằng yêu cầu mua thêm module. Nhóm liên chức năng xem hành trình từ nhận đơn đến thông báo hoàn tất, chốt người cập nhật tại từng mốc và quy tắc xử lý ngoại lệ. Doanh nghiệp thử trên một nhóm đơn hàng, với hỗ trợ đào tạo và quyền truy cập phù hợp.

Kết quả được đánh giá qua tính đầy đủ của trạng thái, khả năng trả lời và việc khách hàng phải liên hệ lại. Tình huống không giả định một tỷ lệ tăng doanh thu. Bài học là công nghệ đã có chỉ tạo giá trị khi trách nhiệm, dữ liệu và cách sử dụng được nối thành một luồng nhất quán.

Thử thay đổi nhỏ trước khi mở rộng khoản đầu tư

Một thử nghiệm nên có vấn đề, phạm vi, người tham gia, tiêu chí kiểm chứng và điều kiện kết thúc. Chọn nhóm công việc đủ thường xuyên để quan sát, nhưng không bỏ qua kiểm soát dữ liệu và an toàn. Việc thử công nghệ vẫn cần theo cơ chế phê duyệt của tổ chức.

Theo dõi cả lợi ích và chi phí áp dụng. Nếu thời gian ở một bộ phận giảm nhưng bộ phận khác phải nhập thêm dữ liệu, cần xem tổng tác động. Nếu người dùng không hoàn tất được công việc, hỏi điều kiện và thao tác còn thiếu trước khi kết luận họ chống thay đổi.

OECD đề cập các yếu tố bổ trợ như kỹ năng và thực hành tổ chức trong chuyển đổi số doanh nghiệp nhỏ và vừa. CDO có thể vận dụng nguyên tắc này để nhìn đầu tư công nghệ cùng năng lực con người và cách quản lý, thay vì chờ phần mềm tự tạo thay đổi.

Kết thúc thử nghiệm bằng quyết định: giữ, sửa, mở rộng hoặc dừng. Nội dung triển khai dự án chuyển đổi số giúp chuyển mục tiêu đã làm rõ thành kế hoạch có phạm vi, trách nhiệm và kiểm soát phù hợp.

Bộ câu hỏi trước khi phê duyệt sáng kiến số

• Vấn đề kinh doanh nào được giải quyết và bằng chứng hiện trạng ở đâu?
• Ai nhận giá trị, ai thay đổi cách làm và ai chịu trách nhiệm kết quả?
• Quy trình, dữ liệu hoặc quyền quyết định nào cần thay đổi cùng công nghệ?
• Người dùng có đủ kỹ năng, thời gian và hỗ trợ để áp dụng không?
• Cách đo nào phân biệt bàn giao hệ thống, mức áp dụng và kết quả thực tế?
• Điều kiện nào khiến doanh nghiệp điều chỉnh hoặc dừng sáng kiến?

Các câu hỏi này có thể đưa vào cuộc họp lựa chọn đầu tư và kỳ rà soát sau triển khai. Khi câu trả lời chưa rõ, cần thu thập bằng chứng hoặc thiết kế thử nghiệm, không tự bổ sung những cam kết lợi ích chưa có căn cứ.

Nhận thức tổ chức thay đổi khi các quyết định nhất quán với kết quả mong muốn. CDO tạo sự nhất quán đó bằng cách đặt vấn đề kinh doanh trước, kết nối chủ sở hữu và giữ chuỗi bằng chứng trong suốt triển khai. Phần mềm là một nguồn lực quan trọng trong chuỗi này, còn thành công phải được nhìn qua công việc và giá trị thực sự được duy trì.

Bài viết liên quan

• Vai trò thực sự của CDO: Dẫn dắt thay đổi mô hình kinh doanh hay triển khai công nghệ?
• Đánh giá mức độ trưởng thành số của doanh nghiệp trước khi xây dựng chiến lược chuyển đổi.
• Xây dựng chiến lược chuyển đổi số từ các vấn đề kinh doanh và nhu cầu khách hàng.
• Thiết kế Digital Transformation Roadmap: Xác định sáng kiến, mức độ ưu tiên và nguồn lực thực hiện.

Nguồn tham khảo

1. OECD – The Digital Transformation of SMEs
2. APM – Benefits management and project success
3. GOV.UK Service Manual – Solve a whole problem for users