Xác định nhu cầu chuyển đổi số được thực hiện thế nào?

Có thể hiểu ngắn gọn theo chuỗi: vấn đề → mục tiêu → hiện trạng → khoảng cách → nhu cầu → ưu tiên. Chuỗi này giữ việc chuyển đổi số gắn với kết quả vận hành hoặc kinh doanh thay vì bị dẫn dắt bởi công cụ.

Xác định nhu cầu theo chuỗi vấn đề → mục tiêu → hiện trạng → khoảng cách

Điểm cốt lõi của việc xác định nhu cầu chuyển đổi số là so sánh trạng thái cần đạt với trạng thái hiện tại, nhưng phép so sánh chỉ có ý nghĩa khi trạng thái cần đạt xuất phát từ một vấn đề hoặc cơ hội thực tế. Nếu không có vấn đề rõ ràng, tổ chức dễ coi mọi công nghệ mới là một “nhu cầu”.

Ví dụ, “triển khai CRM” là tên một giải pháp. Nhu cầu nằm phía trước giải pháp đó, chẳng hạn: dữ liệu khách hàng đang phân tán, nhân viên phải nhập lại thông tin ở nhiều nơi, thời gian phản hồi khách hàng dài hơn mục tiêu và quản lý không có một nguồn dữ liệu thống nhất để theo dõi cơ hội bán hàng. Khi các khoảng cách này được chứng minh, tổ chức mới có cơ sở xác định mình cần năng lực quản lý dữ liệu và quy trình khách hàng tốt hơn. CRM chỉ là một phương án có thể được xem xét ở bước sau.

Vì vậy, đầu ra của giai đoạn xác định nhu cầu nên là một tập hợp nhu cầu trung lập với giải pháp, gắn với mục tiêu và có tiêu chí đo. Cách làm này giúp tránh khóa quyết định quá sớm vào một công nghệ cụ thể.

Bắt đầu từ vấn đề có bằng chứng, không từ danh sách công nghệ

Một vấn đề đủ để đưa vào phân tích cần được mô tả bằng hiện tượng quan sát được và tác động của nó. Nguồn bằng chứng có thể đến từ thời gian xử lý, tỷ lệ lỗi, số bước thủ công, số lần nhập lại dữ liệu, phản hồi của khách hàng hoặc nhân viên, chi phí vận hành, số lượng hồ sơ tồn đọng hay mức độ phụ thuộc vào một cá nhân.

Nên tách triệu chứng khỏi nguyên nhân có thể can thiệp. Chẳng hạn, “doanh thu giảm” là một kết quả, chưa tự nó chỉ ra nhu cầu chuyển đổi số. Nếu phân tích cho thấy nhân viên bán hàng phản hồi chậm vì dữ liệu khách hàng nằm ở nhiều hệ thống và việc phân công cơ hội vẫn làm thủ công, khi đó khoảng cách về dữ liệu và quy trình mới là đối tượng cần xem xét.

Một cách mô tả vấn đề hữu ích là trả lời bốn câu hỏi: vấn đề xảy ra ở đâu, ai bị ảnh hưởng, bằng chứng nào cho thấy nó tồn tại và hậu quả nào đáng kể. Nếu chưa trả lời được, chưa nên chuyển thẳng sang giải pháp số. Không phải mọi vấn đề của tổ chức đều là vấn đề công nghệ; có trường hợp nguyên nhân chính nằm ở quy định nội bộ, phân quyền, năng lực nhân sự hoặc cách thiết kế quy trình.

Chuyển vấn đề thành mục tiêu và chỉ số đích

Sau khi xác định vấn đề, cần mô tả trạng thái mong muốn bằng kết quả có thể kiểm chứng. Mục tiêu càng cụ thể thì khoảng cách càng dễ xác định. “Nâng cao trải nghiệm khách hàng” khó dùng để phân tích nhu cầu nếu không có tiêu chí đi kèm; “giảm thời gian phản hồi yêu cầu từ mức hiện tại xuống mức mục tiêu” tạo được một điểm đích để so sánh.

Mỗi mục tiêu nên có ít nhất ba thành phần: đối tượng cần cải thiện, chỉ số theo dõi và mức đích hoặc điều kiện đích. Tùy bài toán, chỉ số có thể là thời gian xử lý, tỷ lệ hoàn thành đúng hạn, tỷ lệ lỗi, số thao tác thủ công, mức độ sử dụng dữ liệu chung hoặc tỷ lệ giao dịch được xử lý xuyên suốt mà không cần nhập lại.

Mức đích có thể đến từ mục tiêu chiến lược, cam kết dịch vụ, yêu cầu tuân thủ hoặc benchmark ngành phù hợp. Benchmark chỉ là điểm tham chiếu; nếu không phản ánh bối cảnh, năng lực và ưu tiên của tổ chức, nó không nên được dùng như mục tiêu bắt buộc.

Không nhất thiết mọi mục tiêu đều phải quy về tiền. Một mục tiêu về chất lượng dữ liệu, khả năng truy vết, tốc độ phục vụ hay tính liên tục của quy trình vẫn hợp lệ nếu tổ chức xác định được cách đo hoặc điều kiện nghiệm thu. Ngược lại, mục tiêu không có tiêu chí kiểm chứng sẽ khiến nhu cầu dễ bị diễn đạt thành mong muốn chung chung.

Đánh giá hiện trạng trên quy trình, dữ liệu, con người và công nghệ

Đánh giá hiện trạng nhằm tạo đường cơ sở (baseline) để biết tổ chức đang cách mục tiêu bao xa. Chỉ kiểm kê phần mềm đang sử dụng là chưa đủ, vì cùng một hệ thống có thể cho kết quả rất khác nhau tùy quy trình, dữ liệu và cách con người vận hành.

Bốn nhóm nên được xem xét cùng nhau:

·         Quy trình: Các bước xử lý, điểm chờ, thao tác thủ công, bước phê duyệt, điểm bàn giao và nơi phát sinh lỗi

·         Dữ liệu: Dữ liệu được tạo ở đâu, có trùng lặp hay thiếu không, ai sở hữu, có thể dùng chung và truy xuất kịp thời hay không

·         Con người và quản trị: Vai trò, trách nhiệm, kỹ năng, quyền ra quyết định, mức độ tuân thủ quy trình và khả năng sử dụng dữ liệu

·         Công nghệ: Hệ thống hiện có, mức tích hợp, khả năng tự động hóa, giới hạn kỹ thuật, độ ổn định và mức đáp ứng nhu cầu vận hành

Các bộ chỉ số trưởng thành số hoặc khung đánh giá do cơ quan quản lý, hiệp hội ngành hay tổ chức chuyên môn ban hành có thể giúp chuẩn hóa câu hỏi và tạo một điểm tham chiếu chung giữa các đơn vị. Tuy nhiên, điểm số tổng hợp không tự động cho biết tổ chức phải làm dự án nào. Một mức điểm thấp chỉ trở thành nhu cầu ưu tiên khi nó liên quan tới mục tiêu cụ thể và có bằng chứng về tác động.

Kết quả của bước này nên là dữ liệu hiện trạng đủ để đối chiếu với mục tiêu: baseline của KPI, bản đồ quy trình, các điểm đứt gãy dữ liệu, hạn chế về năng lực hoặc các ràng buộc kỹ thuật có liên quan. Không cần đánh giá mọi thứ trong doanh nghiệp với cùng độ sâu; chỉ nên đi sâu vào những khu vực có quan hệ trực tiếp với vấn đề đang phân tích.

Biến khoảng cách giữa hiện trạng và mục tiêu thành nhu cầu cụ thể

Khoảng cách là phần chênh giữa điều tổ chức muốn đạt và khả năng hiện có. Khoảng cách có thể là định lượng, như thời gian xử lý hiện tại so với mức đích, hoặc định tính nhưng kiểm chứng được, như chưa có dữ liệu dùng chung, chưa có cơ chế truy vết hay chưa có quyền truy cập phù hợp giữa các bộ phận.

Để tránh biến khoảng cách thành một danh sách công nghệ, có thể viết nhu cầu theo cấu trúc:

Để đạt [mục tiêu], [đơn vị/quy trình] cần có [năng lực hoặc thay đổi cần thiết] nhằm khắc phục [khoảng cách hiện tại], và kết quả được kiểm chứng bằng [chỉ số/điều kiện].

Ví dụ, thay vì ghi “cần ứng dụng AI để chăm sóc khách hàng”, một nhu cầu trung lập hơn có thể là: “Bộ phận chăm sóc khách hàng cần khả năng phân loại và định tuyến yêu cầu nhanh hơn để giảm thời gian phản hồi, trong khi vẫn bảo đảm các trường hợp ngoại lệ được chuyển cho nhân sự xử lý.” Cách diễn đạt này giữ mục tiêu và điều kiện vận hành ở trung tâm; AI, tự động hóa theo luật hay thay đổi quy trình vẫn là các phương án có thể so sánh sau đó.

Một khoảng cách cũng không nhất thiết tạo ra một nhu cầu công nghệ. Nếu nguyên nhân chính là quy trình phê duyệt có quá nhiều cấp nhưng hệ thống hiện tại đã đáp ứng được, nhu cầu trước hết có thể là thiết kế lại quy trình và quyền hạn. Chỉ khi xác định được phần nào cần năng lực số hỗ trợ mới nên gắn nó vào phạm vi chuyển đổi số.

Ưu tiên nhu cầu theo giá trị, cấp thiết, khả thi và rủi ro

Sau khi lập danh sách nhu cầu, không nên coi tất cả có cùng mức ưu tiên. Một nhu cầu đáng làm trước cần tạo tác động rõ ràng tới mục tiêu, có đủ điều kiện để triển khai và giữ rủi ro trong mức tổ chức có thể chấp nhận.

Có thể chấm từng nhu cầu theo thang nội bộ, chẳng hạn 1–5, trên bốn nhóm tiêu chí. Giá trị phản ánh mức đóng góp vào mục tiêu kinh doanh, vận hành, chất lượng dịch vụ hoặc tuân thủ. Cấp thiết cho biết hậu quả của việc tiếp tục trì hoãn. Khả thi xem xét mức sẵn sàng về dữ liệu, quy trình, nhân lực, ngân sách, tích hợp và quyền ra quyết định. Rủi ro và phụ thuộc cho thấy nhu cầu đó có thể bị cản trở bởi điều gì hoặc phụ thuộc vào năng lực nào chưa có.

Thang điểm không phải một benchmark chung cho mọi doanh nghiệp; trọng số cần phản ánh chiến lược và ràng buộc của từng tổ chức. Giá trị của việc chấm điểm nằm ở chỗ buộc các bên nêu rõ căn cứ cho thứ tự ưu tiên, thay vì chọn dự án theo mức độ hấp dẫn của công nghệ hoặc sức ảnh hưởng của một bộ phận.

Khi hai nhu cầu có giá trị tương đương, nên xem thêm quan hệ phụ thuộc. Một nhu cầu về dữ liệu nền tảng có thể cần được xử lý trước một nhu cầu tự động hóa nếu tự động hóa phụ thuộc trực tiếp vào dữ liệu đó. Ngược lại, không nên biến “nền tảng” thành lý do để trì hoãn vô thời hạn những cải tiến nhỏ có thể tạo giá trị độc lập.

Kiểm chứng nhu cầu trước khi đưa vào lộ trình chuyển đổi số

Trước khi coi một nhu cầu là đầu vào chính thức cho lộ trình, nên kiểm tra lại với chủ quy trình, người sử dụng, bộ phận dữ liệu hoặc công nghệ và người chịu trách nhiệm về mục tiêu. Mục đích không phải tìm sự đồng thuận tuyệt đối, mà là xác nhận rằng nhu cầu dựa trên cùng một tập hợp sự kiện và không bỏ sót ràng buộc quan trọng.

Một nhu cầu đủ cơ sở để đưa vào lộ trình thường trả lời được năm câu hỏi: vấn đề nào đang được giải quyết, bằng chứng hiện trạng là gì, trạng thái đích là gì, khoảng cách cụ thể nằm ở đâu và giá trị của việc thu hẹp khoảng cách đó là gì. Nếu câu trả lời chỉ xoay quanh tên một phần mềm hoặc công nghệ, nhu cầu vẫn đang bị “neo” vào giải pháp và cần được viết lại.

Cũng cần kiểm tra tính thay đổi theo thời gian. Khi mục tiêu kinh doanh, quy trình, dữ liệu nguồn hoặc các ràng buộc lớn thay đổi, nhu cầu đã xác định có thể không còn giữ nguyên mức ưu tiên. Vì thế, nhu cầu chuyển đổi số nên được xem là một kết luận dựa trên bằng chứng có thể cập nhật khi baseline hoặc mục tiêu thay đổi, không phải một danh sách cố định sau một lần khảo sát.

Xác định nhu cầu chuyển đổi số hiệu quả bắt đầu từ việc chứng minh vấn đề, đặt mục tiêu có thể kiểm chứng, đo hiện trạng và xác định khoảng cách cần thu hẹp. Từ đó, tổ chức diễn đạt nhu cầu ở dạng năng lực hoặc thay đổi cần có, chưa khóa vào giải pháp công nghệ, rồi ưu tiên dựa trên giá trị, tính cấp thiết, khả thi, rủi ro và quan hệ phụ thuộc. Cách tiếp cận này giúp mỗi sáng kiến số có một lý do rõ ràng để tồn tại và một tiêu chí cụ thể để đánh giá sau này.