Những nội dung cần chuẩn bị triển khai công nghệ

Năm nhóm chuẩn bị này phụ thuộc lẫn nhau. Phạm vi quyết định cần dữ liệu nào và bao nhiêu người tham gia. Dữ liệu và cách tích hợp quyết định yêu cầu đối với hạ tầng. Nguồn lực quyết định ai xử lý các vấn đề trong quá trình triển khai. Người dùng lại là nơi kiểm chứng công nghệ có thực sự tạo ra thay đổi trong hoạt động hay chỉ hoàn thành về mặt kỹ thuật.

Vì vậy, trước khi triển khai, doanh nghiệp nên chuyển mục tiêu chung thành các điều kiện có thể kiểm tra. Thay vì đặt yêu cầu như “hệ thống phải nhanh”, “dữ liệu phải tốt” hoặc “người dùng phải sẵn sàng”, cần xác định chỉ số hiện trạng, mức chấp nhận, người chịu trách nhiệm và cách nghiệm thu. Không có một ngưỡng chung phù hợp cho mọi doanh nghiệp; benchmark có giá trị nhất ở giai đoạn này thường là đường cơ sở của chính quy trình hiện tại và mục tiêu cải thiện đã được thống nhất.

Xác định phạm vi triển khai trước khi lựa chọn cách thực hiện

Phạm vi là điểm xuất phát vì nó xác định công nghệ sẽ giải quyết vấn đề nào, tác động đến đâu và điều gì chưa thuộc lần triển khai hiện tại. Một dự án có mục tiêu đúng nhưng phạm vi không rõ vẫn có thể phát sinh thêm quy trình, dữ liệu, tích hợp và người dùng trong quá trình thực hiện, khiến kế hoạch nguồn lực ban đầu nhanh chóng mất hiệu lực.

Doanh nghiệp nên làm rõ ít nhất bốn thành phần của phạm vi:

·         Vấn đề cần giải quyết: Công nghệ được đưa vào để xử lý điểm nghẽn, nhu cầu hoặc yêu cầu vận hành cụ thể nào

·         Quy trình chịu tác động: Bước nào được thay đổi, tự động hóa, hỗ trợ hoặc thay thế

·         Đối tượng sử dụng: Bộ phận, vai trò và nhóm người dùng nào trực tiếp hoặc gián tiếp tham gia

·         Ranh giới triển khai: Đơn vị, địa điểm, sản phẩm, loại dữ liệu hoặc chức năng nào chưa được đưa vào giai đoạn này

Phạm vi cũng cần gắn với tiêu chí thành công có thể kiểm tra. Nếu mục tiêu là rút ngắn thời gian xử lý, doanh nghiệp cần có thời gian xử lý hiện tại làm baseline và cách đo lại sau triển khai. Nếu mục tiêu là giảm thao tác thủ công, cần xác định thao tác nào sẽ được loại bỏ và thao tác nào vẫn cần con người kiểm soát. Nếu mục tiêu liên quan đến chất lượng dữ liệu hoặc độ chính xác, phải xác định chỉ số tương ứng trước khi hệ thống mới đi vào hoạt động.

Cách làm này giúp phân biệt kết quả kinh doanh với kết quả kỹ thuật. Một hệ thống được cài đặt thành công, kết nối được với các ứng dụng khác và không xuất hiện lỗi nghiêm trọng chưa có nghĩa là mục tiêu triển khai đã đạt. Thành công chỉ có thể đánh giá khi kết quả kỹ thuật được nối với thay đổi mong muốn trong quy trình thực tế.

Với dự án có phạm vi lớn hoặc nhiều yếu tố chưa chắc chắn, triển khai thí điểm trên một nhóm người dùng hoặc quy trình đại diện thường giúp kiểm tra giả định trước khi mở rộng. Tuy nhiên, pilot phải có tiêu chí đánh giá và điều kiện chuyển sang giai đoạn tiếp theo; nếu chỉ thử nghiệm mà không xác định điều cần học hoặc điều kiện nghiệm thu, pilot dễ trở thành một giai đoạn kéo dài nhưng không hỗ trợ quyết định.

Chuẩn bị dữ liệu theo đúng mục đích sử dụng của công nghệ

Dữ liệu chỉ được xem là sẵn sàng khi phù hợp với cách công nghệ sẽ sử dụng nó. Có dữ liệu không đồng nghĩa với dữ liệu có thể đưa ngay vào hệ thống mới.

Trước tiên, doanh nghiệp cần lập danh mục những nguồn dữ liệu liên quan đến phạm vi đã xác định. Với mỗi nguồn, nên biết dữ liệu do hệ thống nào tạo ra, ai sở hữu, ai được phép sử dụng, được cập nhật với tần suất nào và sẽ được truyền sang công nghệ mới bằng phương thức gì.

Sau đó cần kiểm tra chất lượng dữ liệu theo các vấn đề thực tế như:

·         Tính đầy đủ: Các trường thông tin bắt buộc có thường xuyên bị thiếu hay không

·         Tính chính xác: Giá trị có phản ánh đúng đối tượng và nghiệp vụ thực tế hay không

·         Tính nhất quán: Cùng một đối tượng có được biểu diễn khác nhau giữa các hệ thống hay không

·         Tính duy nhất: Có bản ghi trùng hoặc nhiều mã định danh cho cùng một đối tượng hay không

·         Tính kịp thời: Dữ liệu có được cập nhật đủ nhanh cho mục đích sử dụng hay không

·         Khả năng truy xuất: Có xác định được nguồn gốc và các bước biến đổi quan trọng của dữ liệu hay không

Mức chất lượng cần thiết phụ thuộc vào chức năng. Một trường dữ liệu không quan trọng đối với báo cáo tham khảo có thể trở thành điều kiện bắt buộc nếu được sử dụng để tự động ra quyết định, cấp quyền hoặc kích hoạt một quy trình. Vì vậy, không nên đặt mục tiêu mơ hồ như “làm sạch toàn bộ dữ liệu” trước dự án. Doanh nghiệp nên ưu tiên những dữ liệu thực sự được công nghệ sử dụng và xác định mức chấp nhận cho từng mục đích.

Ngoài chất lượng, quyền truy cập và quản trị dữ liệu phải được giải quyết trước khi vận hành. Dữ liệu nhạy cảm cần có nguyên tắc phân quyền, lưu giữ, truyền nhận và xử lý phù hợp với chính sách nội bộ cũng như yêu cầu pháp lý áp dụng cho doanh nghiệp. Với hệ thống sử dụng nhà cung cấp bên ngoài hoặc dịch vụ đám mây, cần làm rõ dữ liệu nào được gửi ra ngoài, được lưu ở đâu, bên nào có quyền truy cập và quy trình xử lý khi dịch vụ chấm dứt.

Cuối cùng là kế hoạch chuyển đổi dữ liệu. Migration không chỉ là sao chép dữ liệu từ hệ thống cũ sang hệ thống mới. Doanh nghiệp cần xác định dữ liệu nào phải chuyển, dữ liệu nào giữ lại, cách ánh xạ trường dữ liệu, cách xử lý giá trị lỗi và cách đối soát sau chuyển đổi. Đối với dữ liệu quan trọng, phải có tiêu chí giúp xác nhận rằng dữ liệu sau migration vẫn đầy đủ và sử dụng được trước khi hệ thống được nghiệm thu.

Bố trí đủ nguồn lực và xác định rõ trách nhiệm

Công nghệ không tự triển khai. Dự án cần đồng thời có hiểu biết về nghiệp vụ, dữ liệu, kỹ thuật, vận hành và người dùng. Một trong những rủi ro phổ biến là doanh nghiệp giao toàn bộ trách nhiệm cho bộ phận công nghệ thông tin trong khi phần lớn quyết định lại liên quan đến quy trình và cách làm việc của các đơn vị nghiệp vụ.

Trước khi bắt đầu, cần xác định rõ ai chịu trách nhiệm cho các nhóm công việc chính:

·         Chủ sở hữu mục tiêu kinh doanh và phạm vi

·         Chủ sở hữu quy trình nghiệp vụ

·         Chủ sở hữu hoặc quản trị dữ liệu

·         Nhóm kỹ thuật, tích hợp và hạ tầng

·         Nhóm bảo mật hoặc quản trị rủi ro khi cần

·         Người phụ trách kiểm thử và nghiệm thu

·         Người phụ trách đào tạo và hỗ trợ người dùng

·         Nhà cung cấp hoặc đối tác triển khai nếu có

Điểm quan trọng không chỉ là có tên người phụ trách mà còn là quyền quyết định. Khi dữ liệu không đạt yêu cầu, ai quyết định trì hoãn migration? Khi nghiệp vụ muốn thêm chức năng ngoài phạm vi, ai có quyền phê duyệt thay đổi? Khi kết quả kiểm thử không đạt tiêu chí nghiệm thu, ai quyết định có được đưa hệ thống vào vận hành hay không? Những câu hỏi này nên được thống nhất trước thay vì giải quyết khi sự cố đã xảy ra.

Nguồn lực cũng phải được đánh giá theo năng lực và khả năng dành thời gian cho dự án. Một chuyên gia nghiệp vụ có kiến thức phù hợp nhưng chỉ có thể tham gia rất ít trong giai đoạn thiết kế và kiểm thử vẫn có thể trở thành điểm nghẽn. Do đó, kế hoạch nhân sự cần xem xét đồng thời vai trò, năng lực, khối lượng công việc và thời điểm cần tham gia.

Nếu doanh nghiệp phụ thuộc đáng kể vào nhà cung cấp, cần xác định những năng lực phải được chuyển giao cho đội ngũ nội bộ. Hệ thống có thể vận hành tốt trong giai đoạn dự án nhưng trở nên khó duy trì khi chuyên gia bên ngoài rời đi. Tài liệu cấu hình, hướng dẫn xử lý lỗi, quy trình vận hành và kiến thức về các tích hợp quan trọng nên nằm trong phạm vi bàn giao.

Kiểm tra hạ tầng và khả năng tích hợp trước khi go-live

Hạ tầng phải đáp ứng đúng đặc tính vận hành của công nghệ, không chỉ điều kiện để cài đặt được hệ thống. Việc kiểm tra cần bao phủ năng lực xử lý, mạng, lưu trữ, tích hợp, bảo mật, giám sát, sao lưu và khả năng khôi phục.

Nếu giải pháp có yêu cầu cụ thể về CPU, bộ nhớ, dung lượng, băng thông, hệ điều hành, cơ sở dữ liệu hoặc phiên bản phần mềm, các thông số này phải được đối chiếu với tài liệu kỹ thuật của nhà cung cấp. Với dịch vụ đám mây, doanh nghiệp vẫn phải đánh giá kết nối mạng, danh tính người dùng, phân quyền, tích hợp, khả năng quan sát và các giới hạn dịch vụ liên quan đến workload của mình.

Không nên đánh giá hiệu năng chỉ bằng nhận xét “đủ nhanh”. Trước khi vận hành, doanh nghiệp nên xác định các chỉ số phù hợp với hệ thống, chẳng hạn:

·         Thời gian phản hồi của giao dịch quan trọng

·         Số lượng giao dịch hoặc yêu cầu cần xử lý trong một khoảng thời gian

·         Số người dùng đồng thời dự kiến

·         Khối lượng dữ liệu hiện tại và mức tăng dự kiến

·         Thời gian cho phép để phục hồi dịch vụ

·         Mức dữ liệu tối đa có thể chấp nhận mất khi xảy ra sự cố

Giá trị mục tiêu của các chỉ số này phải xuất phát từ nhu cầu nghiệp vụ và đặc tính hệ thống; không nên áp dụng một con số chung cho mọi công nghệ. Quan trọng là có baseline, ngưỡng nghiệm thu và phương pháp kiểm thử nhất quán.

Tích hợp cũng cần được xem như một phần của hạ tầng triển khai. Một công nghệ mới thường phụ thuộc vào hệ thống nhận dạng người dùng, cơ sở dữ liệu, ERP, CRM, API hoặc các ứng dụng nội bộ khác. Mỗi kết nối tạo thêm một dependency: hệ thống nguồn thay đổi có thể làm luồng mới ngừng hoạt động. Vì vậy cần xác định giao diện tích hợp, phương thức xác thực, định dạng dữ liệu, cách xử lý lỗi và đơn vị chịu trách nhiệm cho từng đầu kết nối.

Bảo mật phải được thiết kế trước khi go-live thay vì bổ sung sau. Quyền truy cập nên tuân theo nhu cầu công việc; tài khoản có đặc quyền cần được kiểm soát chặt hơn tài khoản thông thường. Log của các hoạt động quan trọng phải đủ để hỗ trợ giám sát và điều tra khi xảy ra bất thường. Các yêu cầu về cấu hình an toàn, quản lý lỗ hổng, sao lưu và khôi phục cũng cần được kiểm thử trong môi trường phù hợp.

Đặc biệt, doanh nghiệp nên thực hiện kiểm thử phương án phục hồi thay vì chỉ xác nhận rằng “đã có backup”. Bản sao lưu chỉ tạo giá trị khi có thể khôi phục đúng dữ liệu và dịch vụ trong điều kiện doanh nghiệp chấp nhận được.

Chuẩn bị người dùng và quy trình vận hành mới

Người dùng không chỉ cần biết cách mở hệ thống và thực hiện thao tác. Họ phải hiểu phần công việc nào thay đổi, trách nhiệm nào vẫn giữ nguyên, tình huống nào cần xử lý thủ công và phải liên hệ ai khi kết quả của công nghệ không phù hợp.

Trước tiên, doanh nghiệp cần xác định các nhóm người dùng chịu tác động. Một thay đổi có thể liên quan đến người trực tiếp sử dụng hệ thống, quản lý phê duyệt, nhân viên nhập dữ liệu, bộ phận hỗ trợ và cả những người chỉ nhận đầu ra. Mỗi nhóm cần mức đào tạo khác nhau.

Đào tạo nên bám theo tình huống công việc thực tế hơn là chỉ giới thiệu chức năng. Người dùng cần thực hành quy trình bình thường, trường hợp ngoại lệ và các lỗi thường gặp. Với những chức năng có ảnh hưởng lớn đến quyết định hoặc dữ liệu quan trọng, cần làm rõ khi nào người dùng được phép tin vào kết quả hệ thống và khi nào phải kiểm tra hoặc chuyển cấp.

Một vấn đề khác là thay đổi trách nhiệm. Khi một bước được tự động hóa, trách nhiệm không nhất thiết biến mất mà có thể chuyển từ “thực hiện” sang “giám sát và xử lý ngoại lệ”. Nếu doanh nghiệp không xác định thay đổi này, công việc dễ rơi vào khoảng trống: hệ thống được cho là tự xử lý trong khi con người cho rằng mình không còn trách nhiệm kiểm tra.

Trước khi go-live, nên có sẵn cơ chế hỗ trợ gồm đầu mối tiếp nhận vấn đề, cách phân loại mức độ ưu tiên, quy trình chuyển cấp và người xử lý các lỗi liên quan đến nghiệp vụ, dữ liệu hoặc kỹ thuật. Giai đoạn đầu sau triển khai thường xuất hiện những tình huống không bộc lộ đầy đủ trong kiểm thử; khả năng phản hồi nhanh vì vậy là một phần của readiness chứ không phải công việc phát sinh sau dự án.

Mức độ sẵn sàng của người dùng cũng nên được kiểm tra bằng hành vi thực tế, chẳng hạn khả năng hoàn thành các tác vụ bắt buộc trong môi trường thử nghiệm, thay vì chỉ dựa vào số lượng người đã tham dự khóa đào tạo. Tham gia đào tạo chứng minh một hoạt động đã diễn ra; hoàn thành đúng quy trình mới chứng minh người dùng có khả năng sử dụng hệ thống.

Đặt điều kiện sẵn sàng trước quyết định đưa công nghệ vào vận hành

Sau khi chuẩn bị từng thành phần, doanh nghiệp cần tổng hợp chúng thành điều kiện go-live. Mục đích của bước này là tránh tình trạng từng nhóm tự đánh giá phần việc của mình đã hoàn thành nhưng toàn bộ hệ thống vẫn còn dependency quan trọng chưa được xử lý.

Một bộ điều kiện sẵn sàng có thể kiểm tra theo năm nhóm:

Không phải mọi vấn đề chưa hoàn thành đều buộc phải hoãn triển khai. Một lỗi nhỏ có thể được chấp nhận nếu tác động đã được hiểu, có biện pháp kiểm soát và người có thẩm quyền chấp thuận. Ngược lại, một vấn đề liên quan đến dữ liệu quan trọng, bảo mật, khả năng phục hồi hoặc quy trình cốt lõi có thể là điều kiện chặn go-live dù phần lớn checklist khác đã hoàn thành.

Vì vậy, tiêu chí sẵn sàng nên phân biệt điều kiện bắt buộc, vấn đề có thể chấp nhận tạm thời và hạng mục có thể hoàn thiện sau triển khai. Mỗi ngoại lệ được chấp nhận cần có chủ sở hữu, biện pháp xử lý và thời điểm xem xét lại. Cách này giúp quyết định triển khai dựa trên mức rủi ro còn lại thay vì dựa vào tỷ lệ công việc đã hoàn thành.

Chuẩn bị triển khai công nghệ là quá trình biến một lựa chọn công nghệ thành một hệ thống có thể vận hành trong điều kiện thực tế của doanh nghiệp. Phạm vi cần rõ để tránh mở rộng không kiểm soát; dữ liệu phải phù hợp với mục đích sử dụng; nguồn lực phải có trách nhiệm và quyền quyết định; hạ tầng phải được kiểm chứng bằng yêu cầu vận hành; còn người dùng phải có khả năng thực hiện quy trình mới, kể cả khi xuất hiện ngoại lệ.

Điểm quan trọng nhất là không đánh giá readiness bằng cảm nhận. Với mỗi nhóm chuẩn bị, doanh nghiệp nên xác định trạng thái hiện tại, điều kiện cần đạt, bằng chứng nghiệm thu và người chịu trách nhiệm. Khi năm nhóm điều kiện này được kiểm tra cùng nhau, quyết định go-live sẽ dựa trên khả năng vận hành và mức rủi ro thực tế thay vì chỉ dựa trên việc dự án đã hoàn thành cài đặt.