Quy trình chuyển đổi số gồm những giai đoạn nào?

Không cần ép mọi tổ chức vào cùng một số lượng giai đoạn. Với mục tiêu quản trị thực thi, có thể gom quy trình thành 4 giai đoạn: chuẩn bị và đánh giá hiện trạng → xác lập mục tiêu và lộ trình ưu tiên → triển khai và quản trị thay đổi → đánh giá, tối ưu và mở rộng. Sau mỗi vòng, dữ liệu thực tế được dùng để điều chỉnh ưu tiên cho vòng tiếp theo.

Quy trình chuyển đổi số là gì?

Chuyển đổi số không chỉ là số hóa tài liệu, đưa một quy trình lên phần mềm hay thay hệ thống cũ bằng hệ thống mới. Những hoạt động đó có thể là thành phần của chuyển đổi số, nhưng chỉ trở thành chuyển đổi khi chúng làm thay đổi cách tổ chức tạo giá trị, phục vụ người dùng, ra quyết định hoặc vận hành công việc.

Vì vậy, quy trình chuyển đổi số nên được hiểu là chuỗi hoạt động có kiểm soát để đi từ hiện trạng đến một cách vận hành mới, với công nghệ số, dữ liệu, con người và quy trình được thay đổi đồng bộ. Một quy trình tốt phải trả lời được bốn câu hỏi: đang ở đâu, muốn đạt kết quả gì, sẽ thay đổi bằng cách nào và bằng chứng nào cho thấy thay đổi đó có hiệu quả.

Có thể tóm tắt 4 giai đoạn vận hành như sau:

Bốn giai đoạn này là một cách tổ chức thực thi, không phải chuẩn cứng. Một doanh nghiệp nhỏ có thể gộp bước 1 và 2; một tổ chức lớn có thể tách riêng đánh giá trưởng thành số, kiến trúc dữ liệu, quản trị thay đổi hoặc quản trị rủi ro. Điểm cần giữ nguyên là logic: không triển khai trước khi biết vấn đề và mục tiêu; không mở rộng trước khi có bằng chứng về kết quả.

Giai đoạn 1: Chuẩn bị và đánh giá hiện trạng

Giai đoạn đầu tiên tạo mốc xuất phát cho toàn bộ chương trình. Nếu không có baseline, tổ chức rất khó chứng minh một sáng kiến số đã tạo ra cải thiện hay chỉ thay đổi công cụ.

Đánh giá hiện trạng không nên dừng ở danh sách phần mềm đang sử dụng. Cần nhìn đồng thời vào quy trình, dữ liệu, con người, công nghệ và cơ chế quản trị. Chẳng hạn, một quy trình xử lý hồ sơ chậm có thể xuất phát từ nhiều nguyên nhân: dữ liệu phải nhập lại ở nhiều hệ thống, bước phê duyệt dư thừa, trách nhiệm không rõ, thông tin đầu vào thiếu chuẩn hóa hoặc hệ thống không tích hợp. Mua thêm phần mềm khi chưa xác định nguyên nhân có thể số hóa nguyên trạng một quy trình kém hiệu quả.

Baseline nên gắn với vấn đề cụ thể và đo được. Với một quy trình nghiệp vụ, mốc ban đầu có thể gồm thời gian xử lý trung bình, tỷ lệ lỗi, số lần nhập dữ liệu lặp lại, chi phí trên mỗi giao dịch, tỷ lệ hồ sơ phải xử lý lại hoặc mức độ sử dụng kênh số. Không có ngưỡng chung cho mọi tổ chức; giá trị của baseline nằm ở khả năng tạo điểm so sánh trước và sau thay đổi.

Giai đoạn chuẩn bị chỉ nên kết thúc khi tổ chức đã có tối thiểu:

·         Vấn đề hoặc cơ hội cần chuyển đổi được mô tả đủ cụ thể

·         Baseline cho các chỉ số liên quan trực tiếp đến vấn đề

·         Phạm vi ban đầu đủ nhỏ để kiểm soát nhưng đủ đại diện để kiểm chứng

·         Người chịu trách nhiệm về kết quả, không chỉ người chịu trách nhiệm về công nghệ

·         Các ràng buộc chính về dữ liệu, tích hợp, nhân lực, vận hành và rủi ro

Nếu chưa xác định được những yếu tố này, chuyển sang mua sắm hoặc triển khai thường làm tăng chi phí sửa sai ở các bước sau.

Giai đoạn 2: Xác lập mục tiêu và lộ trình ưu tiên

Từ baseline, tổ chức cần chuyển câu hỏi “nên số hóa gì?” thành “kết quả nào cần thay đổi và bằng cách nào?”. Đây là bước biến nhu cầu chung thành mục tiêu có thể quản trị.

Một mục tiêu chuyển đổi số nên gắn với kết quả nghiệp vụ hoặc trải nghiệm thực tế. Ví dụ, thay vì đặt mục tiêu “triển khai hệ thống quản lý hồ sơ”, mục tiêu có thể là giảm thời gian xử lý, giảm tỷ lệ nhập lại dữ liệu, tăng tỷ lệ giao dịch hoàn thành trên kênh số hoặc tăng khả năng truy vết trạng thái hồ sơ. Hệ thống là phương tiện; KPI cho biết phương tiện đó có tạo ra thay đổi hay không.

KPI nên có ba thành phần: giá trị baseline, giá trị mục tiêu và khoảng thời gian đánh giá. Khi thiếu một trong ba, tổ chức dễ rơi vào tình trạng “đã triển khai” nhưng không thể kết luận “đã chuyển đổi”. Với chỉ số dạng tỷ lệ, cách tính cũng phải thống nhất từ đầu. Chẳng hạn, tỷ lệ chấp nhận có thể được xác định bằng số người dùng hoạt động thực tế chia cho tổng số người dùng mục tiêu; nếu định nghĩa thay đổi giữa các kỳ, kết quả so sánh mất ý nghĩa.

Sau đó, các sáng kiến cần được ưu tiên thay vì triển khai đồng loạt. Có thể xem xét ít nhất bốn yếu tố: giá trị kỳ vọng, mức độ khả thi, phụ thuộc dữ liệu/hệ thống và rủi ro thay đổi. Một sáng kiến có giá trị cao nhưng phụ thuộc vào dữ liệu chưa chuẩn hóa có thể cần xếp sau một bước nền tảng. Ngược lại, một “quick win” dễ làm nhưng không đóng góp vào mục tiêu chính không nên chiếm nguồn lực chỉ vì dễ triển khai.

Roadmap ở giai đoạn này cần đủ cụ thể để thực thi: mỗi sáng kiến có chủ sở hữu, phạm vi, KPI, mốc kiểm tra, nguồn lực, phụ thuộc và điều kiện để tiếp tục hoặc dừng. Giai đoạn 2 hoàn thành khi tổ chức có thể giải thích rõ vì sao sáng kiến này được làm trước sáng kiến khác và kết quả nào sẽ được dùng để đánh giá nó.

Giai đoạn 3: Triển khai và quản trị thay đổi

Triển khai chuyển đổi số khác với cài đặt một hệ thống ở chỗ kết quả cuối cùng phải xuất hiện trong cách làm việc thực tế. Một giải pháp có thể chạy đúng về kỹ thuật nhưng vẫn không tạo chuyển đổi nếu người dùng không sử dụng, dữ liệu không đủ tin cậy, quy trình cũ vẫn tồn tại song song hoặc trách nhiệm vận hành chưa thay đổi.

Vì vậy, triển khai nên được tổ chức theo phạm vi có thể kiểm chứng. Với sáng kiến chưa chắc chắn, một pilot hoặc rollout theo từng nhóm giúp tổ chức quan sát đồng thời ba lớp kết quả: hệ thống có hoạt động ổn định không, người dùng có áp dụng cách làm mới không và chỉ số nghiệp vụ có dịch chuyển theo hướng mong muốn không. Ba lớp này không thay thế nhau. Tỷ lệ sử dụng cao chưa chắc tạo hiệu quả nghiệp vụ; ngược lại, một cải thiện tốt trong nhóm thử nghiệm nhỏ cũng chưa đủ để kết luận toàn tổ chức sẽ đạt kết quả tương tự.

Quản trị thay đổi cần diễn ra cùng lúc với triển khai kỹ thuật. Người dùng phải hiểu quy trình mới, quyền hạn và trách nhiệm cần được cập nhật, dữ liệu phải có chuẩn và người sở hữu, còn đội vận hành phải biết cách xử lý sự cố hoặc ngoại lệ. Khi quy trình mới phụ thuộc vào nhiều hệ thống, việc kiểm thử tích hợp và chất lượng dữ liệu quan trọng không kém tính năng giao diện.

Trong giai đoạn này, nên theo dõi cả chỉ số dẫn dắt và chỉ số kết quả. Chỉ số dẫn dắt cho biết thay đổi có đang được tiếp nhận hay không, chẳng hạn tỷ lệ người dùng hoạt động, tỷ lệ giao dịch đi qua quy trình mới hoặc số lỗi vận hành. Chỉ số kết quả phản ánh mục tiêu cuối, chẳng hạn thời gian xử lý, chi phí, tỷ lệ sai sót hoặc mức độ hoàn thành giao dịch. Nếu chỉ nhìn số lượng tài khoản được cấp hoặc số tính năng đã go-live, tổ chức đang đo đầu ra kỹ thuật chứ chưa đo kết quả chuyển đổi.

Giai đoạn 3 chỉ nên chuyển sang mở rộng khi giải pháp đã hoạt động đủ ổn định, cách làm mới được sử dụng trong thực tế và dữ liệu vận hành đủ tin cậy để đánh giá tác động.

Giai đoạn 4: Đánh giá, tối ưu và mở rộng

Đánh giá là bước biến dữ liệu triển khai thành quyết định quản trị. Thay vì hỏi “dự án đã hoàn thành chưa?”, cần hỏi “kết quả sau thay đổi có tốt hơn baseline, đạt mục tiêu và đủ bền để mở rộng không?”.

Có thể chia chỉ số đánh giá thành bốn nhóm:

·         Kết quả nghiệp vụ: Thời gian xử lý, chi phí trên giao dịch, tỷ lệ lỗi, doanh thu hoặc năng suất tùy mục tiêu

·         Mức độ chấp nhận: Tỷ lệ người dùng hoạt động, tỷ lệ giao dịch qua kênh mới, mức độ tuân thủ quy trình mới

·         Hiệu quả vận hành: Độ ổn định, thời gian xử lý sự cố, chất lượng dữ liệu, mức độ tự động hóa hoặc số bước thủ công còn lại

·         Rủi ro và kiểm soát: Sự cố bảo mật, lỗi phân quyền, sai lệch dữ liệu, điểm nghẽn tích hợp hoặc các ngoại lệ nghiệp vụ

Các KPI chỉ có giá trị khi được so với baseline và mục tiêu đã đặt ở giai đoạn 2. Nếu thời gian xử lý giảm nhưng tỷ lệ lỗi tăng mạnh, kết luận “hiệu quả hơn” là chưa đủ cơ sở. Nếu tỷ lệ sử dụng thấp, cần xác định nguyên nhân nằm ở trải nghiệm, đào tạo, thiết kế quy trình hay chất lượng giải pháp trước khi quyết định mở rộng.

Sau đánh giá, mỗi sáng kiến nên đi vào một trong bốn hướng: tiếp tục như kế hoạch, tối ưu rồi đánh giá lại, dừng vì không còn đủ giá trị, hoặc mở rộng. Mở rộng chỉ hợp lý khi giá trị đã được kiểm chứng và tổ chức sẵn sàng vận hành ở quy mô lớn hơn. Cần kiểm tra khả năng chịu tải của hạ tầng, năng lực hỗ trợ người dùng, tính nhất quán của dữ liệu, chi phí vận hành, khả năng tích hợp và trách nhiệm quản trị. Một pilot chạy tốt trong phạm vi nhỏ không tự động chứng minh rằng cùng thiết kế đó sẽ phù hợp khi số người dùng, khối lượng dữ liệu hoặc số đơn vị tham gia tăng mạnh.

Vì thế, “scale” không nên là phần thưởng mặc định cho việc hoàn thành pilot. Mở rộng là một quyết định dựa trên bằng chứng. Khi bằng chứng chưa đủ, tối ưu hoặc dừng là lựa chọn hợp lý hơn so với nhân rộng một vấn đề chưa được giải quyết.

Vì sao quy trình chuyển đổi số cần vận hành theo vòng lặp?

Chuyển đổi số diễn ra trong môi trường luôn thay đổi: nhu cầu người dùng thay đổi, dữ liệu mới xuất hiện, công nghệ và quy định vận hành có thể thay đổi, còn năng lực nội bộ cũng trưởng thành sau mỗi lần triển khai. Vì vậy, kết quả của giai đoạn 4 không phải điểm kết thúc tuyệt đối mà trở thành dữ liệu đầu vào cho chu kỳ tiếp theo.

Một sáng kiến sau khi mở rộng có thể tạo ra baseline mới. Những điểm nghẽn trước đây quan trọng có thể đã được giải quyết, trong khi vấn đề mới xuất hiện ở tích hợp, dữ liệu, trải nghiệm hoặc năng lực vận hành. Danh mục ưu tiên vì thế cần được xem xét lại dựa trên bằng chứng mới thay vì giữ nguyên roadmap ban đầu bằng mọi giá.

Tính vòng lặp không có nghĩa là thay đổi mục tiêu liên tục. Kỷ luật nằm ở việc giữ mục tiêu đủ ổn định trong một chu kỳ để đo được kết quả, sau đó dùng dữ liệu để quyết định chu kỳ tiếp theo. Nhờ cơ chế này, tổ chức có thể mở rộng những gì đã chứng minh giá trị, sửa những gì chưa đạt và dừng những sáng kiến không còn phù hợp thay vì biến chuyển đổi số thành một chương trình kéo dài nhưng khó xác định hiệu quả.

Quy trình chuyển đổi số có thể được quản trị theo 4 giai đoạn: chuẩn bị và đánh giá hiện trạng; xác lập mục tiêu và lộ trình ưu tiên; triển khai gắn với quản trị thay đổi; sau đó đánh giá, tối ưu và mở rộng. Giá trị của quy trình không nằm ở số lượng bước, mà ở việc mỗi bước tạo ra đầu ra có thể kiểm chứng và cung cấp dữ liệu cho quyết định tiếp theo.

Nếu tổ chức chưa có baseline, KPI và người chịu trách nhiệm về kết quả, chưa nên vội triển khai. Nếu giải pháp đã go-live nhưng người dùng chưa áp dụng hoặc kết quả chưa vượt baseline theo hướng mong muốn, chưa nên vội mở rộng. Khi các quyết định đều dựa trên dữ liệu và vòng phản hồi, chuyển đổi số trở thành năng lực cải tiến liên tục thay vì một dự án công nghệ có điểm kết thúc cố định.