Đánh giá hiện trạng chuyển đổi số được thực hiện thế nào?

Vì vậy, đánh giá hiện trạng không đồng nghĩa với kiểm kê số lượng phần mềm, máy chủ hay dữ liệu đang sở hữu. Một doanh nghiệp có nhiều hệ thống vẫn có thể phải nhập liệu lặp lại, dữ liệu thiếu nhất quán và quyết định phụ thuộc vào bảng tính thủ công. Ngược lại, một tổ chức chưa tự động hóa mọi khâu vẫn có thể có nền tảng tốt nếu quy trình được kiểm soát, dữ liệu đáng tin cậy, hệ thống tích hợp phù hợp và trách nhiệm quản trị rõ ràng.

Cách đánh giá phù hợp là khoanh vùng đối tượng, thu thập bằng chứng vận hành, xác định chỉ số, đối chiếu với tiêu chí hoặc mô tả mức trưởng thành đã lựa chọn, kiểm chứng kết quả giữa nhiều nguồn rồi tổng hợp thành baseline. Nếu sử dụng một khung như DBI hoặc một mô hình trưởng thành số chính thức, tổ chức cần giữ nguyên định nghĩa tiêu chí và logic chấm điểm của khung đó thay vì tự ghép các thang đo khác nhau.

Đánh giá hiện trạng chuyển đổi số bắt đầu từ đâu?

Điểm bắt đầu không phải là hỏi “đang có những công nghệ nào”, mà là xác định phạm vi nào đang được đánh giá và bằng chứng nào phản ánh đúng thực tế vận hành trong phạm vi đó. Nếu phạm vi không rõ, kết quả rất dễ trở thành tập hợp ý kiến của các phòng ban thay vì một bức tranh hiện trạng có thể kiểm chứng.

Một chu trình đánh giá có thể triển khai theo năm bước:

1.    Khoanh vùng đơn vị, quy trình, dữ liệu, hệ thống và nhóm nhân sự thuộc phạm vi đánh giá

2.    Xác định tiêu chí, chỉ số và nguồn bằng chứng cho từng nội dung

3.    Thu thập dữ liệu trong một chu kỳ vận hành đủ đại diện thay vì chỉ chụp trạng thái tại một thời điểm bất thường

4.    Đối chiếu số liệu hệ thống, hồ sơ vận hành, tài liệu và phỏng vấn để phát hiện chênh lệch giữa quy định với thực tế

5.    Chấm mức hiện trạng theo mô tả đã định nghĩa trước và ghi rõ độ tin cậy của bằng chứng

Khi đánh giá một hành vi vận hành có thể đo được, bằng chứng tạo ra trực tiếp từ quá trình làm việc thường có giá trị hơn nhận định chủ quan. Nhật ký workflow, thời gian giao dịch, lịch sử ticket, dữ liệu ERP hoặc CRM có thể cho thấy số lượng trường hợp thực tế, thời gian xử lý hay số lần phát sinh lỗi. Tài liệu quy trình cho biết cách tổ chức dự kiến phải vận hành, nhưng không tự chứng minh rằng nhân sự luôn làm đúng như tài liệu.

Phỏng vấn vẫn cần thiết vì log hệ thống không giải thích đầy đủ nguyên nhân, ngoại lệ và các công việc nằm ngoài hệ thống. Tuy nhiên, một điểm số chỉ dựa trên câu trả lời “đơn vị đã số hóa tốt” có độ tin cậy thấp nếu không có bằng chứng đối chiếu.

Tiêu chí cũng phải được định nghĩa trước khi nhìn vào kết quả. Chẳng hạn, nếu dùng “mức tự động hóa quy trình”, cần xác định bước nào thực sự có khả năng tự động hóa, trường hợp nào bắt buộc phải có quyết định của con người và cách tính tỷ lệ. Nếu định nghĩa thay đổi sau khi đã thấy số liệu, điểm hiện trạng giữa các phòng ban sẽ không còn khả năng so sánh.

Một baseline tốt vì thế luôn chứa hai lớp thông tin: mức hiện trạng và cơ sở tạo ra mức đó. Điểm số mà không biết được lấy từ dữ liệu nào chỉ tạo cảm giác chính xác, không tạo ra một kết quả đánh giá đáng tin cậy.

Đánh giá hiện trạng quy trình theo hiệu quả và mức số hóa

Với quy trình, cần quan sát dòng công việc từ đầu đến cuối thay vì chỉ kiểm tra xem từng phòng ban đã sử dụng phần mềm hay chưa. Chuyển một biểu mẫu giấy thành biểu mẫu điện tử không giải quyết được vấn đề nếu hồ sơ sau đó vẫn phải chuyển thủ công qua nhiều người, nhập lại dữ liệu hoặc chờ phê duyệt ngoài hệ thống.

Các chỉ số nên phản ánh trực tiếp cách quy trình vận hành, chẳng hạn:

·         Thời gian chu kỳ từ lúc tiếp nhận đến lúc hoàn tất

·         Thời gian chờ so với tổng thời gian xử lý

·         Tỷ lệ trường hợp phải làm lại hoặc sửa lỗi

·         Số điểm bàn giao giữa người, phòng ban và hệ thống

·         Tỷ lệ bước đủ điều kiện được thực hiện tự động

·         Tỷ lệ trường hợp phải nhập lại dữ liệu đã tồn tại ở một hệ thống khác

·         Tỷ lệ ngoại lệ phải xử lý ngoài luồng chuẩn

Ví dụ, tỷ lệ làm lại có thể được tính bằng số trường hợp phải xử lý lại / tổng số trường hợp hoàn tất × 100%. Tỷ lệ tự động hóa nên dùng mẫu số là những bước thực sự có khả năng tự động hóa, thay vì toàn bộ các bước của quy trình. Cách tính này tránh đánh giá thấp các hoạt động bắt buộc phải sử dụng phán đoán chuyên môn.

Bằng chứng nên được lấy từ timestamp của workflow, ERP, CRM, hệ thống quản lý hồ sơ, lịch sử ticket, báo cáo lỗi và mẫu giao dịch thực tế. Sau đó mới đối chiếu với SOP hoặc sơ đồ quy trình. Nếu tài liệu thể hiện năm bước nhưng log và phỏng vấn cho thấy nhân sự thường phải thực hiện thêm ba thao tác ngoài hệ thống, tám bước thực tế mới là hiện trạng cần ghi nhận.

Cơ chế cần quan tâm là ma sát trong dòng công việc. Mỗi lần nhập lại dữ liệu, chờ chuyển hồ sơ, phê duyệt ngoài hệ thống hay xử lý ngoại lệ không kiểm soát đều có thể kéo dài thời gian và làm suy giảm khả năng truy vết. Khi số hóa một quy trình còn nhiều ma sát, công nghệ có thể chỉ chuyển phần lãng phí từ môi trường giấy sang môi trường điện tử.

Dù vậy, mức tự động hóa thấp không mặc nhiên đồng nghĩa với quy trình yếu. Một quy trình có tần suất thấp, rủi ro cao hoặc cần đánh giá chuyên môn sâu có thể chủ động giữ con người trong vòng quyết định. Điều cần đánh giá là quy trình có đạt yêu cầu về thời gian, chất lượng, kiểm soát và truy vết hay không, chứ không phải tự động hóa càng nhiều thì điểm càng cao.

Đánh giá dữ liệu theo chất lượng, khả năng quản trị và khai thác

Dữ liệu phải được đánh giá như một tài sản phục vụ vận hành và ra quyết định, không phải theo số lượng bảng, tệp hay dung lượng lưu trữ. Một kho dữ liệu lớn vẫn có giá trị thấp nếu cùng một khách hàng tồn tại dưới nhiều mã khác nhau, các phòng ban hiểu khác nhau về cùng một trường dữ liệu hoặc không xác định được nguồn gốc của con số trong báo cáo.

Có ba câu hỏi cần được trả lời đồng thời: dữ liệu có đúng không, có quản trị được không và có sử dụng được trong đúng ngữ cảnh hay không.

Ở lớp chất lượng, tổ chức có thể lượng hóa bằng các chỉ số như:

·         Tỷ lệ đầy đủ = số trường bắt buộc có dữ liệu / tổng số trường bắt buộc cần có dữ liệu × 100%

·         Tỷ lệ bản ghi trùng = số bản ghi được xác định là trùng / tổng số bản ghi × 100%

·         Tỷ lệ dữ liệu đúng hạn = số bản ghi đáp ứng yêu cầu về độ mới / tổng số bản ghi cần kiểm tra × 100%

·         Tỷ lệ sai lệch đối soát = số trường hợp không khớp giữa các nguồn cần nhất quán / tổng số trường hợp đối soát × 100%

Ngưỡng đạt không nên được gán chung cho mọi loại dữ liệu. Dữ liệu phục vụ báo cáo quản trị nội bộ có thể có yêu cầu khác dữ liệu dùng cho giao dịch tài chính, tuân thủ hoặc vận hành thời gian thực. Benchmark đúng phải xuất phát từ yêu cầu nghiệp vụ, SLA dữ liệu hoặc tiêu chuẩn đang được tổ chức áp dụng.

Ở lớp quản trị, cần xác định dữ liệu quan trọng có chủ sở hữu hay không, định nghĩa nghiệp vụ có thống nhất không, quyền truy cập được quản lý thế nào, thay đổi cấu trúc dữ liệu có được kiểm soát không và có thể lần ngược nguồn gốc của dữ liệu hay không. Data dictionary, schema, danh mục dữ liệu, hồ sơ phân quyền và data lineage là những bằng chứng hữu ích hơn một tuyên bố chung rằng doanh nghiệp “đã quản trị dữ liệu”.

Khả năng khai thác lại phụ thuộc vào mức dữ liệu có thể di chuyển và được hiểu thống nhất giữa các quy trình. Dữ liệu của từng phòng ban có thể rất chính xác nhưng vẫn tạo điểm nghẽn nếu phải xuất Excel, gửi qua email rồi nhập thủ công vào hệ thống khác. Khi đó, vấn đề không nằm ở chất lượng cục bộ mà ở khả năng chia sẻ và sử dụng xuyên suốt.

Vì vậy, “có nhiều dữ liệu” và “có dữ liệu trưởng thành” là hai trạng thái khác nhau. Baseline cần chỉ ra rõ dữ liệu nào đáng tin cậy, dữ liệu nào còn vấn đề, ai chịu trách nhiệm và giới hạn sử dụng hiện tại nằm ở đâu.

Đánh giá công nghệ theo kiến trúc, tích hợp và vận hành

Công nghệ nên được đánh giá theo khả năng hỗ trợ hoạt động hiện tại, mức tích hợp, khả năng duy trì và mức kiểm soát kỹ thuật. Tuổi đời của một hệ thống hay việc hệ thống chạy trên cloud không đủ để kết luận nó trưởng thành hay lạc hậu.

Trước hết cần có danh mục các ứng dụng và hạ tầng quan trọng, kèm vai trò của từng thành phần trong quy trình. Từ danh mục đó, đánh giá các quan hệ phụ thuộc: hệ thống nào trao đổi dữ liệu với hệ thống nào, bằng API hay file, có bước trung gian thủ công hay không, một chức năng nghiệp vụ đang được thực hiện ở một hay nhiều ứng dụng.

Các KPI vận hành giúp thay thế nhận xét định tính bằng bằng chứng, gồm:

·         Tỷ lệ hệ thống quan trọng còn được nhà cung cấp hoặc đội kỹ thuật hỗ trợ

·         Tỷ lệ luồng tích hợp quan trọng được thực hiện tự động thay vì xuất nhập file hoặc nhập lại thủ công

·         Mức sẵn sàng thực tế so với SLA mà hoạt động kinh doanh yêu cầu

·         Thời gian trung bình khôi phục dịch vụ sau sự cố

·         Số lượng và tần suất sự cố ảnh hưởng đến quy trình trọng yếu

·         Tỷ lệ kiểm thử sao lưu và khôi phục đạt yêu cầu RTO, RPO nếu tổ chức đã quy định các ngưỡng này

Không nên áp một con số SLA, RTO hoặc RPO giống nhau cho mọi hệ thống. Một cổng giao dịch trực tiếp với khách hàng và một ứng dụng nội bộ ít sử dụng có mức độ quan trọng khác nhau. Hiện trạng phải được đánh giá so với yêu cầu dịch vụ tương ứng của từng hệ thống.

Khả năng thay đổi cũng là dấu hiệu đáng chú ý. Nếu một thay đổi nhỏ phải chỉnh sửa nhiều hệ thống, tạo nhiều file trung gian hoặc phụ thuộc vào một số cá nhân duy nhất, kiến trúc hiện tại đang tạo ra chi phí phối hợp và rủi ro vận hành. Nhật ký triển khai, thời gian xử lý thay đổi, sơ đồ tích hợp và dữ liệu sự cố có thể làm rõ mức phụ thuộc này.

Một hệ thống legacy vì thế không nhất thiết phải bị đánh giá thấp. Nếu hệ thống vẫn được hỗ trợ, ổn định, đáp ứng yêu cầu bảo mật, tích hợp được và phục vụ đúng nhu cầu nghiệp vụ, tuổi đời không phải lý do đủ để kết luận nó là điểm yếu. Tương tự, sử dụng cloud không tự động chứng minh mức trưởng thành cao nếu dữ liệu vẫn phân mảnh, tích hợp thủ công và vận hành thiếu kiểm soát.

Đánh giá năng lực theo con người, quản trị và khả năng thay đổi

Quy trình, dữ liệu và công nghệ chỉ tạo ra năng lực số bền vững khi tổ chức có người chịu trách nhiệm, kỹ năng phù hợp và cơ chế ra quyết định đủ rõ. Vì vậy, đánh giá năng lực không nên dừng ở số lượng nhân sự IT hoặc số giờ đào tạo đã hoàn thành.

Ở cấp con người, cần đối chiếu yêu cầu của từng vai trò với năng lực thực tế. Một ma trận năng lực có thể cho thấy vị trí nào cần hiểu dữ liệu, vận hành quy trình số, quản trị hệ thống hoặc sử dụng công cụ phân tích và mức đáp ứng hiện tại. Với năng lực quan trọng, kết quả kiểm tra kỹ năng hoặc khả năng hoàn thành tác vụ thực tế có giá trị hơn việc chỉ ghi nhận đã tham gia khóa học.

Mức độ chấp nhận công cụ cũng cần được đo bằng hành vi. Một hệ thống có 500 tài khoản không có nghĩa 500 người đang sử dụng nó đúng mục đích. Có thể theo dõi tỷ lệ người dùng hoạt động trong nhóm được yêu cầu sử dụng, tần suất sử dụng các chức năng trọng yếu, tỷ lệ giao dịch vẫn bị xử lý ngoài hệ thống hoặc số trường hợp quay lại cách làm cũ.

Ở cấp quản trị, các câu hỏi trọng tâm gồm: ai sở hữu quy trình, ai chịu trách nhiệm về dữ liệu, ai có quyền quyết định thay đổi hệ thống và khi phát sinh xung đột giữa các đơn vị thì cơ chế xử lý là gì. Nếu một dữ liệu quan trọng không có chủ sở hữu hoặc một quy trình xuyên phòng ban không có người chịu trách nhiệm đầu cuối, công nghệ khó giải quyết được điểm nghẽn về quyền quyết định.

Các bằng chứng thích hợp gồm ma trận vai trò và trách nhiệm, hồ sơ phân quyền, dữ liệu sử dụng hệ thống, kết quả đánh giá năng lực, lịch sử yêu cầu hỗ trợ và tài liệu quản trị. Khảo sát nhận thức có thể bổ sung góc nhìn về thái độ và rào cản thay đổi, nhưng nên được đối chiếu với hành vi sử dụng thực tế.

Số lượng nhân sự lớn, ngân sách đào tạo cao hay tỷ lệ hoàn thành khóa học cao vì vậy không tự chứng minh năng lực chuyển đổi. Năng lực chỉ thực sự thể hiện khi con người có thể thực hiện công việc theo phương thức mới, trách nhiệm được xác định và tổ chức có khả năng duy trì cách vận hành đó.

Tổng hợp hiện trạng bằng thang điểm, bằng chứng và độ tin cậy

Bước tổng hợp phải chuyển hàng loạt quan sát khác nhau thành một baseline có thể đọc và so sánh mà không làm mất bối cảnh. Sai lầm phổ biến là quy tất cả về một điểm trung bình rồi dùng con số đó để đại diện cho toàn bộ hiện trạng.

Trước khi chấm điểm, mỗi mức phải có mô tả quan sát được. Nếu sử dụng thang năm mức, chẳng hạn, từng mức cần nêu rõ trạng thái tương ứng về chuẩn hóa, kiểm soát, tích hợp và đo lường. Người đánh giá phải chọn mức dựa trên bằng chứng phù hợp với mô tả, không chấm trước rồi tìm lý do giải thích sau.

Các loại chỉ số cũng không nên cộng trực tiếp với nhau. Tỷ lệ dữ liệu đầy đủ 96%, thời gian xử lý 18 giờ và điểm năng lực 3/5 nằm trên những thang khác nhau. Muốn tổng hợp, chúng phải được quy đổi theo tiêu chí và ngưỡng đã xác định trước. Nếu có trọng số, trọng số phải phản ánh mức quan trọng của tiêu chí đối với phạm vi đánh giá và được thống nhất trước khi biết kết quả, tránh điều chỉnh trọng số để tạo ra điểm tổng mong muốn.

Một điểm tổng hợp cũng không nên che khuất điểm nghẽn có tính phụ thuộc. Quy trình có thể được số hóa tốt nhưng dữ liệu đầu vào kém sẽ làm lỗi lan nhanh hơn. Dữ liệu có chất lượng nhưng các hệ thống không tích hợp sẽ khiến nhân sự tiếp tục chuyển file thủ công. Công nghệ có đủ chức năng nhưng quyền quyết định và khả năng sử dụng yếu sẽ khiến công cụ bị bỏ qua. Do đó, kết quả cần giữ cả điểm hoặc mức của từng chiều và mối quan hệ giữa chúng.

Độ tin cậy của bằng chứng nên được thể hiện cùng với mức đánh giá. Có thể phân biệt thực tế như sau:

Một kết quả 4/5 với độ tin cậy thấp không nên được hiểu giống 4/5 có log hệ thống và dữ liệu vận hành đầy đủ. Việc tách hai thông tin này giúp tổ chức biết đâu là hiện trạng đã được chứng minh và đâu mới là giả định cần kiểm tra thêm.

Baseline cuối cùng nên giữ tối thiểu các trường thông tin sau:

·         Tiêu chí và phạm vi được đánh giá

·         Chỉ số hoặc mức hiện trạng

·         Bằng chứng dùng để xác lập kết quả

·         Độ tin cậy của bằng chứng

·         Điểm nghẽn hoặc giới hạn đã quan sát

·         Quan hệ phụ thuộc với quy trình, dữ liệu, công nghệ hoặc năng lực khác

Khi các trường này được lưu nhất quán, kết quả không chỉ trả lời “đang ở mức nào” mà còn giải thích được vì sao có kết luận đó và bằng chứng nào có thể kiểm tra lại. Đây mới là giá trị của đánh giá hiện trạng trước chuyển đổi số.

Hiện trạng trước chuyển đổi số được đánh giá đúng khi tổ chức xây dựng được một baseline dựa trên hoạt động thực tế thay vì cảm nhận. Quy trình cần được đo bằng hiệu quả và mức kiểm soát, dữ liệu bằng chất lượng và khả năng quản trị, công nghệ bằng mức tích hợp và năng lực vận hành, còn năng lực tổ chức phải được chứng minh qua kỹ năng, hành vi sử dụng và trách nhiệm quản trị.

Điểm số chỉ là lớp tóm tắt. Kết quả có giá trị hơn là tập hợp gồm mức hiện trạng, KPI, bằng chứng, độ tin cậy, điểm nghẽn và các quan hệ phụ thuộc giữa bốn chiều. Khi những yếu tố này được xác lập rõ, tổ chức mới có một bức tranh đủ đáng tin cậy về trạng thái trước chuyển đổi số mà chưa cần suy diễn sang giải pháp hoặc lộ trình triển khai.