Cách giảm gián đoạn khi chuyển đổi công nghệ nghiên cứu

Vì vậy, cách tiếp cận hiệu quả không phải là cố làm cho quá trình thay thế diễn ra thật nhanh. Mục tiêu đúng hơn là kiểm soát sự thay đổi để mỗi bước chuyển đều có bằng chứng cho thấy quy trình vẫn hoạt động trong giới hạn chấp nhận được. Điều này đòi hỏi một đường cơ sở trước chuyển đổi, thử nghiệm có kiểm soát, tiêu chí chuyển hẳn rõ ràng và một đường lui khả dụng.

Lập bản đồ điểm gián đoạn trước khi thay công nghệ

Rủi ro lớn nhất thường không nằm ở bản thân công nghệ mới mà ở những phụ thuộc xung quanh công nghệ cũ. Một nền tảng có thể đáp ứng chức năng chính nhưng vẫn làm dừng quy trình vì định dạng đầu vào thay đổi, dữ liệu không còn truyền sang bước tiếp theo, một tham số cấu hình bị mất hoặc nhân sự phải thực hiện thêm thao tác mà trước đây được tự động hóa.

Do đó, trước khi chuyển đổi cần lập bản đồ quy trình hiện tại từ đầu vào đến đầu ra. Không chỉ ghi công nghệ đang làm gì, mà phải xác định công nghệ đó đang kết nối với ai, dữ liệu nào và công đoạn nào.

Một bản đồ chuyển đổi tối thiểu nên làm rõ:

·         Đầu vào gồm mẫu, dữ liệu, tệp, cấu hình hoặc thông tin nào phải được tiếp nhận

·         Xử lý gồm những bước nào phụ thuộc trực tiếp vào công nghệ hiện tại

·         Đầu ra nào được sử dụng cho phân tích, quyết định hoặc công đoạn kế tiếp

·         Tích hợp nào đang tự động trao đổi dữ liệu với hệ thống khác

·         Thông tin truy vết nào phải được giữ lại như phiên bản, tham số, thời gian, người thực hiện và mã định danh

·         Vai trò con người nào sẽ thay đổi khi công nghệ mới được đưa vào

·         Phương án tạm thời nào tồn tại nếu một mắt xích chưa hoạt động sau chuyển đổi

Không phải mọi phụ thuộc đều có cùng mức độ quan trọng. Nên phân loại chúng thành ba nhóm: phụ thuộc có thể làm dừng nghiên cứu, phụ thuộc làm giảm năng suất nhưng vẫn có giải pháp tạm thời, và phụ thuộc có thể khắc phục sau mà không ảnh hưởng đáng kể đến kết quả.

Cách phân loại này quyết định thứ tự kiểm thử. Một giao diện chỉ phục vụ báo cáo nội bộ không nên được đặt ngang mức với một liên kết làm mất dữ liệu thô hoặc làm thay đổi khả năng truy xuất kết quả nghiên cứu.

Bằng chứng phù hợp ở bước này không phải cảm nhận rằng quy trình “có vẻ đơn giản”. Nên dựa vào SOP đang sử dụng, nhật ký vận hành, các lỗi từng phát sinh, các bước xử lý thủ công và quan sát thực tế về đường đi của dữ liệu. Chính những dữ liệu đó cho biết công nghệ hiện tại đang thực hiện những chức năng ngầm nào mà tài liệu tính năng có thể không phản ánh hết.

Đặt đường cơ sở và tiêu chí nghiệm thu trước khi thử nghiệm

Một lỗi phổ biến trong chuyển đổi công nghệ nghiên cứu là bắt đầu pilot trước rồi mới quyết định thế nào được xem là thành công. Khi đó, nhóm triển khai rất dễ đánh giá công nghệ mới dựa trên cảm giác hoặc trên một vài ca chạy tốt.

Cần làm ngược lại: đo trạng thái hiện tại trước, sau đó đặt tiêu chí nghiệm thu cho trạng thái mới.

Đường cơ sở nên tập trung vào những chỉ số phản ánh trực tiếp tính liên tục của nghiên cứu. Tùy quy trình, có thể sử dụng:

Ngưỡng nghiệm thu không nên được đặt tùy tiện. Với chỉ số liên quan đến giá trị khoa học, giới hạn phải xuất phát từ phương pháp, protocol, tiêu chí validation hoặc yêu cầu nghiên cứu đã được xác định. Không nên mặc định rằng sai lệch ±5% hay một tỷ lệ cố định nào đó phù hợp với mọi loại nghiên cứu.

Với chỉ số vận hành, ngưỡng có thể được xác định dựa trên baseline thực tế. Chẳng hạn, nhóm có thể quy định thời gian xử lý hoặc tỷ lệ chạy lại của công nghệ mới không được vượt quá mức chênh lệch đã thống nhất so với trạng thái hiện tại.

Riêng những yếu tố có tính chất “cổng an toàn”, có thể sử dụng điều kiện chặt hơn. Ví dụ, trước khi chuyển hẳn có thể yêu cầu 100% giao diện được xếp loại quan trọng phải vượt kiểm thử, 100% dữ liệu quan trọng phải đối soát được và không còn lỗi mức nghiêm trọng chưa có biện pháp kiểm soát. Đây là tiêu chí nghiệm thu của dự án, không phải benchmark chung cho mọi công nghệ nghiên cứu.

Điểm quan trọng là tiêu chí phải được xác lập trước khi nhìn thấy kết quả pilot. Nếu liên tục thay ngưỡng để công nghệ mới được xem là đạt, quá trình nghiệm thu sẽ mất giá trị kiểm chứng.

Chạy thử song song để kiểm chứng tính tương đương

Thử công nghệ mới trên một vài trường hợp thuận lợi chỉ chứng minh rằng nó có thể hoạt động. Điều cần biết trước khi chuyển đổi là liệu nó có hoạt động ổn định trong những điều kiện đại diện cho quy trình thật hay không.

Chạy song song giải quyết vấn đề này bằng cách giữ công nghệ hiện tại làm điểm tham chiếu trong khi công nghệ mới xử lý cùng một tập hợp trường hợp hoặc một tập hợp có thể so sánh được.

Tập thử nghiệm nên bao phủ nhiều hơn ca sử dụng thông thường. Ít nhất cần xem xét:

·         Trường hợp phổ biến đại diện cho phần lớn khối lượng công việc

·         Trường hợp biên nằm gần giới hạn vận hành hoặc giới hạn của phương pháp

·         Trường hợp rủi ro cao mà một kết quả sai hoặc thiếu dữ liệu sẽ gây hậu quả lớn cho quy trình

·         Trường hợp phụ thuộc tích hợp cần trao đổi dữ liệu với công đoạn khác

·         Trường hợp từng gây lỗi nếu lịch sử vận hành đã ghi nhận các điểm yếu cụ thể

Khi có thể tạo kết quả ghép cặp giữa hai công nghệ, không nên chỉ so sánh giá trị trung bình. Một mức trung bình gần nhau vẫn có thể che giấu sai lệch có hệ thống ở một nhóm mẫu, một dải giá trị hoặc một điều kiện vận hành nhất định. Vì vậy, sự khác biệt cần được xem xét theo loại trường hợp, độ biến thiên và nguyên nhân.

Chạy song song cũng giúp đo chi phí vận hành của công nghệ mới. Nếu kết quả khoa học đạt yêu cầu nhưng tỷ lệ chạy lại tăng, thời gian xử lý kéo dài hoặc số thao tác thủ công tăng mạnh, gián đoạn chỉ đang chuyển từ “hệ thống không chạy” sang “hệ thống chạy nhưng quy trình chậm đi”.

Không nhất thiết phải chạy hai công nghệ song song trên toàn bộ khối lượng công việc. Làm như vậy có thể tiêu tốn gấp đôi nguồn lực mà không tạo thêm bằng chứng tương xứng. Cách hợp lý hơn là lựa chọn phạm vi thử nghiệm theo mức độ rủi ro và tiếp tục cho đến khi các chỉ số quan trọng ổn định.

Đối với chỉ số vận hành, hai hoặc ba chu kỳ đại diện liên tiếp đạt tiêu chí có thể được sử dụng như một cổng ổn định nội bộ. Tuy nhiên, số chu kỳ này không thay thế yêu cầu validation khoa học nếu phương pháp nghiên cứu đòi hỏi lượng bằng chứng lớn hơn.

Nếu kết quả giữa hai công nghệ không tương đương, câu hỏi đầu tiên không nên là “công nghệ nào tốt hơn” mà là “sự khác biệt đến từ đâu”. Nguyên nhân có thể nằm ở nguyên lý đo, cấu hình, quy trình chuẩn bị, thuật toán xử lý, cách chuẩn hóa dữ liệu hoặc thao tác người dùng. Chỉ sau khi xác định được nguyên nhân mới có thể quyết định hiệu chỉnh, chấp nhận khác biệt hay dừng chuyển đổi.

Chuyển đổi theo từng lớp thay vì cắt sang toàn bộ

Khi pilot đạt yêu cầu, chuyển toàn bộ quy trình sang công nghệ mới trong một thời điểm vẫn tạo ra rủi ro không cần thiết. Pilot có thể chứng minh công nghệ hoạt động, nhưng chưa chắc đã tái hiện đồng thời toàn bộ tải, người dùng, tích hợp và tình huống của môi trường thật.

Chuyển đổi theo từng lớp làm giảm “bán kính ảnh hưởng” của một lỗi. Phạm vi có thể được chia theo công đoạn, nhóm nghiên cứu, loại công việc, tập dữ liệu hoặc nhóm trường hợp có mức rủi ro tương đương.

Một trình tự thường hợp lý là bắt đầu với phạm vi có khả năng kiểm soát tốt nhưng đủ đại diện, sau đó mở rộng khi dữ liệu vận hành chứng minh trạng thái ổn định. Mỗi lần mở rộng phải dựa trên cùng hệ tiêu chí đã được xác định ở giai đoạn baseline, thay vì chỉ dựa vào việc “chưa thấy sự cố lớn”.

Trong thời gian chuyển đổi, nên hạn chế thay nhiều biến quan trọng cùng lúc. Nếu đồng thời đổi công nghệ, thay protocol, sửa cấu trúc dữ liệu và thay quy trình vận hành, khi kết quả lệch sẽ rất khó xác định nguyên nhân. Giữ các yếu tố khác ổn định giúp biến “công nghệ mới” trở thành thay đổi chính có thể quan sát.

Các nghiên cứu đang diễn ra cần được xử lý đặc biệt. Việc chuyển công nghệ giữa chừng có thể làm xuất hiện hai hệ dữ liệu được tạo trong hai điều kiện khác nhau. Khi tính so sánh theo thời gian là quan trọng, lựa chọn ít gián đoạn hơn đôi khi là hoàn tất một giai đoạn nghiên cứu bằng công nghệ cũ và chỉ đưa công nghệ mới vào từ một mốc đã định trước.

Ngoại lệ là khi công nghệ cũ không còn khả dụng hoặc tiếp tục sử dụng tạo rủi ro lớn hơn. Trong trường hợp đó, cần một kế hoạch nối cầu rõ ràng để xác định dữ liệu trước và sau chuyển đổi sẽ được so sánh, chuẩn hóa hoặc diễn giải như thế nào.

Thời điểm chuyển hẳn cũng nên tránh các giai đoạn tải cao nếu quy trình cho phép. Mục đích không phải để che giấu điểm yếu của công nghệ mới, mà để giữ đủ năng lực xử lý sự cố trong những chu kỳ đầu mà không tạo backlog lớn cho hoạt động nghiên cứu.

Bảo toàn dữ liệu, khả năng truy vết và đường lui

Một chuyển đổi có thể hoàn tất về mặt kỹ thuật nhưng vẫn thất bại về mặt nghiên cứu nếu dữ liệu cũ không còn truy cập được hoặc không thể chứng minh một kết quả đã được tạo ra bằng cấu hình nào.

Do đó, kế hoạch migration không nên chỉ trả lời “đã chuyển bao nhiêu tệp”. Cần xác định đầy đủ những thành phần phải được bảo toàn, bao gồm dữ liệu thô, dữ liệu đã xử lý, metadata, tham số phương pháp, cấu hình, mã định danh, mốc thời gian, đơn vị, liên kết giữa các đối tượng và thông tin phiên bản có liên quan.

Trước khi chuyển dữ liệu thật, nên thực hiện một lần migration diễn tập. Mục tiêu là kiểm tra cả ba lớp:

1.    Đủ dữ liệu: Số lượng bản ghi và tệp quan trọng có được đối soát đầy đủ hay không

2.    Đúng dữ liệu: Nội dung có bị thay đổi ngoài dự kiến trong quá trình chuyển đổi hay không

3.    Còn quan hệ: Dữ liệu sau migration có còn liên kết đúng với mẫu, phương pháp, phiên bản và kết quả liên quan hay không

Một điểm dễ bị bỏ qua là xác định hệ thống nào là nguồn dữ liệu chính thức trong từng thời điểm. Nếu cả công nghệ cũ và mới cùng cho phép thay đổi một tập dữ liệu mà không có quy tắc đồng bộ rõ ràng, hai phiên bản sự thật có thể xuất hiện. Việc chạy song song vì thế không đồng nghĩa với việc cho phép hai hệ thống cùng làm nguồn ghi chính thức.

Khả năng rollback cũng phải được thiết kế trước khi cutover. Một kế hoạch rollback có giá trị cần trả lời được: điều kiện nào kích hoạt quay lại, ai có quyền ra quyết định, trạng thái dữ liệu nào phải được phục hồi, dữ liệu phát sinh trên công nghệ mới sẽ được xử lý ra sao và quy trình có thể trở lại trạng thái ổn định trong khoảng thời gian chấp nhận nào.

Các tín hiệu kích hoạt rollback có thể bao gồm mất dữ liệu quan trọng, lỗi tích hợp làm dừng công đoạn, kết quả vượt tiêu chí nghiệm thu hoặc backlog vượt ngưỡng vận hành đã đặt. Điều quan trọng là ngưỡng phải được xác định từ trước; nếu chỉ quyết định sau khi sự cố đã kéo dài, rollback sẽ trở thành phản ứng khẩn cấp thay vì một cơ chế kiểm soát.

Công nghệ cũ cũng không nhất thiết phải bị loại bỏ ngay khi chuyển hẳn. Trong một khoảng thời gian kiểm soát, việc duy trì khả năng truy cập chỉ đọc hoặc khả năng phục hồi môi trường cũ có thể bảo vệ tính truy vết. Thời gian duy trì phải phụ thuộc vào nhu cầu nghiên cứu, chính sách dữ liệu và yêu cầu lưu trữ áp dụng cho tổ chức.

Ổn định sau chuyển đổi bằng giám sát và năng lực vận hành

Cutover không phải điểm kết thúc của chuyển đổi công nghệ nghiên cứu. Những lỗi còn lại thường chỉ xuất hiện khi công nghệ tiếp xúc với tải thực tế, nhiều người dùng và những trường hợp không có trong pilot.

Vì vậy, giai đoạn ngay sau chuyển hẳn cần được xem là một giai đoạn ổn định có kiểm soát. Thay vì hỏi “đã chạy được bao nhiêu ngày”, nên hỏi “đã hoàn thành bao nhiêu chu kỳ đại diện mà các chỉ số vẫn nằm trong giới hạn”.

Các chỉ số đã sử dụng ở giai đoạn baseline cần tiếp tục được theo dõi: thời gian xử lý, tỷ lệ hoàn thành lần đầu, tỷ lệ chạy lại, backlog, lỗi tích hợp, mức độ đầy đủ của dữ liệu và số lần cần can thiệp thủ công. Việc sử dụng cùng một bộ chỉ số giúp so sánh trước và sau chuyển đổi mà không thay đổi tiêu chuẩn đánh giá giữa chừng.

Có thể đặt điều kiện thoát khỏi giai đoạn giám sát tăng cường theo dạng cổng, chẳng hạn:

·         Không còn sự cố nghiêm trọng chưa được kiểm soát

·         Các chỉ số chất lượng đầu ra nằm trong giới hạn nghiệm thu đã xác định

·         Tỷ lệ chạy lại và thời gian xử lý đã trở về phạm vi vận hành chấp nhận được

·         Backlog không còn tăng liên tục do công nghệ mới

·         Các quy trình và tích hợp quan trọng đã hoạt động ổn định qua số chu kỳ đại diện đã quy định

·         Người dùng có thể thực hiện các tác vụ quan trọng mà không phụ thuộc vào workaround chưa được kiểm soát

Đào tạo cần đi cùng dữ liệu vận hành thay vì chỉ hoàn thành trước ngày cutover. Một khóa hướng dẫn có thể giúp người dùng biết các bước thao tác, nhưng các lỗi thực tế thường xuất hiện khi họ gặp ngoại lệ, cảnh báo hoặc dữ liệu không đi theo trường hợp chuẩn. Nhật ký lỗi và yêu cầu hỗ trợ trong những chu kỳ đầu vì thế nên được dùng để cập nhật SOP, hướng dẫn xử lý sự cố và nội dung đào tạo.

Điều này cũng giúp phân biệt lỗi công nghệ với lỗi chuyển giao năng lực. Nếu một tác vụ thường xuyên thất bại ở nhiều người dùng tại cùng một bước, nguyên nhân có thể nằm ở thiết kế quy trình hoặc giao diện. Nếu lỗi tập trung ở nhóm chưa được đào tạo về một thao tác cụ thể, giải pháp phù hợp có thể là điều chỉnh hướng dẫn thay vì thay đổi công nghệ.

Cuối cùng, nên chỉ kết thúc giai đoạn chuyển đổi khi ba loại bằng chứng cùng đạt yêu cầu: kết quả nghiên cứu vẫn nằm trong giới hạn chấp nhận, quy trình vận hành đã ổn định và dữ liệu vẫn đầy đủ, truy vết được. Chỉ một trong ba điều kiện đạt là chưa đủ để chứng minh chuyển đổi đã thành công.

Giảm gián đoạn khi chuyển đổi công nghệ nghiên cứu không phụ thuộc vào việc chuyển nhanh nhất, mà vào khả năng phát hiện và giới hạn rủi ro trước khi chúng lan sang toàn bộ quy trình. Lập bản đồ phụ thuộc giúp biết nơi có thể đứt gãy; baseline và tiêu chí nghiệm thu xác định thế nào là đạt; chạy song song tạo bằng chứng so sánh; chuyển theo từng lớp giới hạn phạm vi ảnh hưởng; còn kế hoạch dữ liệu và rollback bảo vệ khả năng phục hồi.

Khi các quyết định chuyển tiếp được dựa trên chỉ số đã xác định trước thay vì cảm nhận, tổ chức có thể thay công nghệ mà vẫn giữ được tính liên tục của quy trình, khả năng truy vết và chất lượng kết quả nghiên cứu.