Quản lý thay đổi chuyển đổi số được thực hiện thế nào?

Quản lý thay đổi vì thế không nhằm hạn chế mọi thay đổi. Cơ chế này tạo ra một chuỗi quyết định có thể truy vết: thay đổi gì, vì sao cần thực hiện, ai chịu trách nhiệm, rủi ro nào đã được xem xét, ai có thẩm quyền phê duyệt, điều kiện triển khai là gì và kết quả thực tế có đạt tiêu chí đã cam kết hay không. Với những thay đổi ảnh hưởng đến cách con người làm việc, kiểm soát kỹ thuật còn phải đi cùng truyền thông, đào tạo và theo dõi mức độ áp dụng.

Quy trình quản lý thay đổi chuyển đổi số vận hành theo một vòng đời kiểm soát

Một thay đổi được quản lý đầy đủ thường đi qua chuỗi: nhận diện → ghi nhận → phân loại → đánh giá tác động và rủi ro → phê duyệt → chuẩn bị triển khai → thực thi và giám sát → đánh giá kết quả → đóng thay đổi. Mức kiểm soát ở từng bước phụ thuộc vào tính chất và mức độ rủi ro của thay đổi.

Cách tiếp cận này tương đồng với thực hành Change Enablement của ITIL 4: rủi ro của thay đổi phải được đánh giá, thay đổi phải được cấp thẩm quyền phù hợp chấp thuận và lịch thay đổi cần được quản lý để tăng xác suất triển khai thành công. COBIT 2019, tại mục tiêu quản trị BAI06 Managed IT Changes, cũng đặt việc đánh giá, ưu tiên, phê duyệt, theo dõi và kiểm soát thay đổi trong một cơ chế chính thức.

Điểm quan trọng nằm ở tính liên tục của vòng đời. Một thay đổi được phê duyệt chưa có nghĩa là đã sẵn sàng đưa vào môi trường vận hành. Quyết định phê duyệt chỉ xác nhận rằng tổ chức chấp nhận thực hiện thay đổi trong những điều kiện nhất định; kiểm thử, nguồn lực, thời điểm triển khai, phương án quay lui và tiêu chí nghiệm thu vẫn phải được chuẩn bị trước khi thực thi.

Nhận diện và ghi nhận thay đổi để tạo một nguồn thông tin chính thức

Thay đổi có thể phát sinh từ yêu cầu kinh doanh, phản hồi người dùng, lỗi vận hành, yêu cầu tuân thủ, vấn đề bảo mật, cải tiến quy trình, nâng cấp công nghệ hoặc kết quả của một giai đoạn chuyển đổi trước đó. Khi nhu cầu đã đủ cụ thể để có khả năng tác động đến hệ thống hoặc cách vận hành, nó cần được đưa vào một bản ghi thay đổi thay vì tiếp tục tồn tại dưới dạng trao đổi rời rạc qua email hoặc tin nhắn.

Bản ghi này cần đủ thông tin để những người không trực tiếp đề xuất thay đổi vẫn hiểu được quyết định đang được yêu cầu. Các trường thông tin cốt lõi thường gồm:

·         Lý do và kết quả mong đợi của thay đổi

·         Quy trình, hệ thống, dữ liệu, dịch vụ hoặc nhóm người dùng bị ảnh hưởng

·         Chủ sở hữu yêu cầu và chủ sở hữu triển khai

·         Các phụ thuộc kỹ thuật hoặc nghiệp vụ đã biết

·         Thời gian mong muốn và các ràng buộc về lịch

·         Tiêu chí xác định thay đổi đã thành công

·         Tài liệu hoặc bằng chứng liên quan nếu đã có

Một bản ghi thiếu lý do kinh doanh hoặc phạm vi tác động khiến bước đánh giá sau đó dễ trở thành phỏng đoán. Ngược lại, yêu cầu ghi quá nhiều tài liệu ngay từ đầu có thể tạo chi phí kiểm soát không cần thiết cho những thay đổi nhỏ. Mức thông tin bắt buộc nên được quy định theo loại thay đổi và mức rủi ro dự kiến.

Từ thời điểm được ghi nhận, thay đổi cũng cần một chủ sở hữu rõ ràng. Chủ sở hữu không nhất thiết là người trực tiếp lập trình, cấu hình hay đào tạo người dùng; vai trò này chịu trách nhiệm bảo đảm thay đổi được đưa qua đúng vòng đời và các quyết định liên quan có người chịu trách nhiệm.

Phân loại và đánh giá tác động, rủi ro trước khi xin phê duyệt

Phân loại giúp tổ chức quyết định mức kiểm soát nào thực sự cần thiết. Các tiêu chí thường bao gồm phạm vi ảnh hưởng, mức độ quan trọng của dịch vụ, khả năng đảo ngược, số lượng người dùng bị tác động, phụ thuộc giữa các hệ thống, yêu cầu tuân thủ và mức độ quen thuộc của phương án triển khai.

Đánh giá rủi ro không nên chỉ xem khả năng hệ thống gặp lỗi. Với chuyển đổi số, ít nhất các nhóm tác động sau cần được xem xét khi có liên quan:

·         Vận hành: Khả năng gián đoạn dịch vụ, giảm năng suất hoặc phát sinh công việc thủ công

·         Dữ liệu: Nguy cơ mất, sai, trùng, chuyển đổi không đầy đủ hoặc thay đổi quyền truy cập

·         Bảo mật và tuân thủ: Tác động đến kiểm soát truy cập, nhật ký, phân quyền hoặc nghĩa vụ pháp lý

·         Tích hợp: Phụ thuộc vào API, ứng dụng, hạ tầng, nhà cung cấp hoặc quy trình khác

·         Kinh doanh: Ảnh hưởng đến khách hàng, doanh thu, chi phí, SLA hoặc hoạt động trọng yếu

·         Con người: Thay đổi vai trò, thao tác, trách nhiệm, kỹ năng hoặc hành vi cần thiết

·         Khả năng phục hồi: Thời gian và độ khó để quay về trạng thái ổn định nếu triển khai thất bại

Tổ chức có thể chuẩn hóa việc đánh giá bằng ma trận xác suất và mức tác động, nhưng điểm số chỉ có ý nghĩa khi thang đo đã được định nghĩa nhất quán. Một thay đổi chạm vào dịch vụ trọng yếu hoặc dữ liệu nhạy cảm có thể cần mức thẩm định cao ngay cả khi xác suất lỗi kỹ thuật được đánh giá thấp.

Kết quả của bước này phải dẫn tới quyết định cụ thể về đường đi của thay đổi: thủ tục đơn giản, quy trình phê duyệt thông thường hay cơ chế khẩn cấp. Nếu đánh giá rủi ro không làm thay đổi mức kiểm soát, việc chấm điểm dễ trở thành thủ tục hành chính hơn là công cụ hỗ trợ quyết định.

Phê duyệt thay đổi theo thẩm quyền và mức độ rủi ro

Thẩm quyền phê duyệt nên tương xứng với hậu quả mà tổ chức phải chấp nhận nếu thay đổi thất bại. Một điều chỉnh có rủi ro thấp và đã được thực hiện nhiều lần không cần đi qua cùng cấp quyết định với thay đổi ảnh hưởng đến nền tảng lõi, dữ liệu khách hàng hoặc nhiều đơn vị kinh doanh.

Người hoặc nhóm có thẩm quyền cần xem xét ít nhất bốn yếu tố: giá trị hoặc sự cần thiết của thay đổi, mức rủi ro còn lại sau các biện pháp kiểm soát, mức độ sẵn sàng để triển khai và xung đột với các thay đổi khác. Quyết định sau đánh giá có thể là chấp thuận, chấp thuận kèm điều kiện, trì hoãn hoặc từ chối.

Một cơ chế phê duyệt hiệu quả thường phân quyền theo tầng rủi ro. Thay đổi lặp lại, rủi ro thấp có thể được phê duyệt trước theo một mô hình chuẩn. Thay đổi thông thường được chuyển đến change authority đã được quy định cho loại hệ thống hoặc mức rủi ro tương ứng. Những thay đổi có ảnh hưởng lớn có thể cần sự tham gia của chủ sở hữu nghiệp vụ, kỹ thuật, an toàn thông tin, tuân thủ hoặc lãnh đạo có quyền chấp nhận rủi ro.

Không phải mọi thay đổi đều cần một hội đồng phê duyệt tập trung. Nếu tất cả yêu cầu, kể cả những thay đổi nhỏ và đã được chuẩn hóa, đều phải chờ cùng một cuộc họp, thời gian xử lý tăng nhưng chất lượng kiểm soát không nhất thiết tăng tương ứng. Trọng tâm nên là đúng thẩm quyền cho đúng mức rủi ro, đồng thời lưu được bằng chứng về quyết định và các điều kiện đi kèm.

Khi phạm vi, rủi ro hoặc điều kiện triển khai thay đổi đáng kể sau khi được phê duyệt, quyết định cũ cũng cần được xem xét lại. Phê duyệt không phải giấy phép vô thời hạn cho một phương án đã khác với phương án ban đầu.

Chuẩn bị triển khai bằng kiểm thử, truyền thông và phương án quay lui

Sau phê duyệt, thay đổi cần được chuyển thành một kế hoạch có thể thực thi. Kế hoạch này phải trả lời được ai thực hiện, thực hiện những bước nào, vào thời điểm nào, phụ thuộc vào điều kiện gì và xử lý thế nào nếu kết quả lệch khỏi dự kiến.

Đối với thay đổi kỹ thuật, bằng chứng kiểm thử phải phù hợp với mức rủi ro. Một thay đổi cấu hình đơn giản có thể chỉ cần kiểm tra chức năng và xác nhận trên môi trường phù hợp; thay đổi liên quan đến dữ liệu, tích hợp hoặc nền tảng trọng yếu có thể cần kiểm thử hồi quy, kiểm tra khả năng phục hồi và xác minh dữ liệu sau chuyển đổi.

Tiêu chí nghiệm thu phải được xác định trước khi triển khai. Nếu nhóm chỉ đánh giá thành công sau khi đã nhìn thấy kết quả, tiêu chuẩn có thể bị điều chỉnh theo kết quả thực tế. Tiêu chí nên gắn với các điều kiện quan sát được như chức năng hoạt động đúng, dữ liệu đối soát đạt yêu cầu, không xuất hiện lỗi nghiêm trọng hoặc quy trình nghiệp vụ hoàn thành theo cách đã thiết kế.

Phương án quay lui cũng cần cụ thể hơn câu “khôi phục phiên bản cũ”. Cần biết trạng thái nào có thể phục hồi, dữ liệu phát sinh trong thời gian triển khai được xử lý ra sao, ai có quyền kích hoạt quay lui và mốc thời gian nào khiến rollback không còn khả thi. Với những thay đổi không thể đảo ngược hoàn toàn, phương án dự phòng phải tập trung vào giảm tác động và khôi phục dịch vụ theo một cấu hình ổn định khác.

Nếu thay đổi tác động đến cách nhân viên hoặc khách hàng thực hiện công việc, kế hoạch kỹ thuật chưa đủ. Hướng dẫn sử dụng, truyền thông thời điểm thay đổi, đào tạo, hỗ trợ sau triển khai và người chịu trách nhiệm giải đáp cần được chuẩn bị cùng lịch triển khai. Một tính năng hoạt động đúng về kỹ thuật nhưng người dùng không hiểu hoặc không áp dụng được vẫn có thể không đạt mục tiêu chuyển đổi.

Triển khai, giám sát và quyết định tiếp tục hay quay lui

Trong thời gian triển khai, nhóm thực hiện phải làm theo phiên bản kế hoạch đã được chấp thuận và ghi nhận những sai lệch có ý nghĩa. Nếu một vấn đề buộc nhóm phải thay đổi đáng kể phạm vi hoặc phương pháp thực hiện, quyết định đó cần được đưa trở lại cơ chế kiểm soát phù hợp thay vì âm thầm biến thành một thay đổi mới bên trong thay đổi cũ.

Các thay đổi có phạm vi rộng có thể được triển khai theo từng giai đoạn khi kiến trúc và nghiệp vụ cho phép. Pilot, rollout theo nhóm người dùng hoặc phát hành từng phần giúp giới hạn phạm vi ảnh hưởng và tạo bằng chứng trước khi mở rộng. Cách này không phù hợp với mọi thay đổi; một số hoạt động chuyển đổi dữ liệu hoặc thay đổi hạ tầng có điểm chuyển đổi mà hệ thống chỉ có thể vận hành ở một trạng thái thống nhất.

Giám sát sau triển khai phải bám vào rủi ro và tiêu chí nghiệm thu đã xác định trước đó. Với thay đổi ứng dụng, nhóm có thể theo dõi lỗi, độ trễ, tỷ lệ giao dịch thành công hoặc ticket hỗ trợ. Với thay đổi quy trình, các tín hiệu như tỷ lệ hoàn thành tác vụ, lỗi thao tác, thời gian xử lý hoặc mức độ sử dụng quy trình mới có thể quan trọng hơn thông số hạ tầng.

Ngưỡng tiếp tục, tạm dừng hoặc quay lui nên được định nghĩa trước đối với những rủi ro trọng yếu. Khi quyết định rollback chỉ dựa vào tranh luận tại thời điểm sự cố, áp lực thời gian dễ làm tăng độ trễ phản ứng. Các ngưỡng đã thống nhất giúp nhóm biết tình huống nào có thể tiếp tục theo dõi và tình huống nào phải ưu tiên phục hồi trạng thái ổn định.

Đánh giá sau triển khai và đóng thay đổi bằng bằng chứng

Một thay đổi chỉ nên được đóng khi kết quả đã được đối chiếu với tiêu chí nghiệm thu và các vấn đề phát sinh đã có cách xử lý rõ ràng. Việc triển khai hoàn tất về mặt kỹ thuật không tự động đồng nghĩa với thay đổi thành công.

Bản ghi đóng thay đổi có thể lưu kết quả kiểm thử sau triển khai, sai lệch so với kế hoạch, sự cố liên quan, quyết định rollback nếu có và mức độ đạt tiêu chí kinh doanh hoặc vận hành. Thông tin này tạo dữ liệu cho các lần đánh giá rủi ro sau thay vì để kinh nghiệm tồn tại riêng trong từng nhóm.

Đánh giá sau triển khai không nhất thiết phải có cùng độ sâu cho mọi thay đổi. Những trường hợp rủi ro cao, thay đổi khẩn cấp, triển khai thất bại, phải quay lui hoặc tạo ra hậu quả ngoài dự kiến cần được xem xét kỹ hơn. Một thay đổi tiêu chuẩn đã thực hiện nhiều lần mà không có sai lệch có thể được đóng bằng thủ tục nhẹ hơn.

Kết quả đánh giá cũng có thể làm thay đổi cách phân loại cho tương lai. Một thay đổi từng được xem là thông thường nhưng đã ổn định qua nhiều lần thực hiện có thể trở thành ứng viên cho quy trình tiêu chuẩn hóa. Ngược lại, một thay đổi tưởng như đơn giản nhưng liên tục gây sự cố cần được nâng mức kiểm soát hoặc thiết kế lại cách triển khai.

Thay đổi tiêu chuẩn, thông thường và khẩn cấp cần cơ chế khác nhau

Áp một quy trình duy nhất cho mọi trường hợp tạo ra hai rủi ro đối lập: kiểm soát quá nặng làm chậm các thay đổi an toàn, còn kiểm soát quá nhẹ khiến các thay đổi quan trọng được triển khai mà chưa đủ bằng chứng. Phân loại theo tính chất và rủi ro giải quyết mâu thuẫn này.

Thay đổi tiêu chuẩn phù hợp với những hoạt động rủi ro thấp, đã được hiểu rõ, có thủ tục ổn định và được phê duyệt trước. Mỗi lần thực hiện vẫn phải đáp ứng điều kiện của mô hình chuẩn; nếu phạm vi hoặc rủi ro vượt khỏi điều kiện đó, thay đổi phải chuyển sang quy trình khác.

Thay đổi thông thường cần được đánh giá và phê duyệt theo cơ chế quản trị đã xác định. Cấp phê duyệt có thể khác nhau tùy hệ thống, tác động và mức rủi ro.

Thay đổi khẩn cấp cần tốc độ cao hơn vì trì hoãn có thể gây thiệt hại lớn hơn, chẳng hạn khi cần phục hồi dịch vụ hoặc xử lý một rủi ro nghiêm trọng. Khẩn cấp không có nghĩa là bỏ kiểm soát. Phạm vi đánh giá có thể được rút gọn, thẩm quyền được chuyển sang một cơ chế phản ứng nhanh và một số hồ sơ có thể hoàn thiện sau, nhưng tổ chức vẫn cần biết ai đã chấp thuận, rủi ro nào được chấp nhận, phương án phục hồi là gì và kết quả phải được xem xét lại sau triển khai.

Cách phân tầng này cũng cho phép quản lý tốc độ và kiểm soát cùng lúc. Những thay đổi đã chứng minh được tính lặp lại được xử lý nhanh hơn, trong khi nguồn lực đánh giá được tập trung vào những trường hợp thực sự có khả năng gây hậu quả lớn.

Đo hiệu quả quản lý thay đổi bằng KPI thay vì số lượng phê duyệt

Số lượng yêu cầu được phê duyệt không cho biết quy trình quản lý thay đổi có hiệu quả hay không. Hệ thống đo lường cần phản ánh cả tốc độ xử lý và kết quả sau triển khai.

Một số KPI có thể sử dụng gồm:

·         Tỷ lệ thay đổi thành công: Tỷ lệ thay đổi đạt tiêu chí nghiệm thu mà không phải rollback hoặc xử lý sự cố nghiêm trọng

·         Tỷ lệ thay đổi thất bại: Tỷ lệ thay đổi dẫn đến rollback, hotfix, gián đoạn hoặc kết quả không đạt tiêu chí

·         Lead time của thay đổi: Thời gian từ khi yêu cầu đủ điều kiện xử lý đến khi được triển khai

·         Tỷ lệ thay đổi khẩn cấp: Tỷ trọng thay đổi phải đi qua đường khẩn cấp

·         Số thay đổi không được ủy quyền: Những thay đổi được thực hiện ngoài cơ chế đã quy định

·         Tỷ lệ làm lại: Phần thay đổi phải sửa chữa hoặc triển khai lại do lỗi chuẩn bị hay thực hiện

·         Chỉ số áp dụng: Mức sử dụng quy trình, tính năng hoặc cách làm mới khi thay đổi phụ thuộc vào hành vi người dùng

Không có một ngưỡng KPI duy nhất phù hợp cho mọi doanh nghiệp và mọi loại hệ thống. Mức chấp nhận của một nền tảng trọng yếu có thể khác đáng kể so với một công cụ nội bộ có khả năng quay lui nhanh. Vì vậy, KPI nên được so với đường cơ sở của chính tổ chức, mức độ quan trọng của dịch vụ và mục tiêu cải thiện theo từng nhóm thay đổi.

Dữ liệu này còn giúp phát hiện vấn đề trong cơ chế quản trị. Lead time tăng nhưng tỷ lệ thất bại không giảm có thể cho thấy quy trình phê duyệt đang tạo thêm thời gian mà chưa tạo thêm khả năng kiểm soát. Tỷ lệ thay đổi khẩn cấp tăng kéo dài có thể phản ánh chất lượng lập kế hoạch, bảo trì hoặc quản lý nhu cầu chưa ổn định. Ngược lại, rút ngắn lead time trong khi giữ được kết quả vận hành là dấu hiệu cho thấy các bước kiểm soát đang được đặt đúng chỗ.

Quản lý thay đổi chuyển đổi số hiệu quả dựa trên một vòng đời có thể truy vết, trong đó yêu cầu được ghi nhận, tác động và rủi ro được đánh giá, thẩm quyền phù hợp đưa ra quyết định, kế hoạch triển khai có tiêu chí nghiệm thu và phương án phục hồi, còn kết quả được giám sát trước khi đóng thay đổi.

Mức kiểm soát phải tỷ lệ với rủi ro. Thay đổi tiêu chuẩn có thể đi theo đường đã phê duyệt trước, thay đổi thông thường cần đánh giá theo thẩm quyền đã quy định, còn thay đổi khẩn cấp được xử lý nhanh hơn nhưng vẫn phải duy trì trách nhiệm và khả năng truy vết. Khi dữ liệu về thành công, thất bại, lead time, rollback và mức độ áp dụng được đưa trở lại quá trình đánh giá, quản lý thay đổi trở thành một cơ chế học và cải tiến liên tục thay vì chỉ là bước phê duyệt trước khi triển khai.