Triển khai công nghệ doanh nghiệp là gì và gồm những hoạt động nào?

Một hệ thống chỉ thực sự được triển khai khi công nghệ đã được cấu hình cho đúng môi trường, kết nối với những thành phần liên quan, có dữ liệu cần thiết, được kiểm thử, có người chịu trách nhiệm sử dụng và vận hành, đồng thời đáp ứng các điều kiện nghiệm thu đã xác định.

Vì vậy, triển khai công nghệ doanh nghiệp thường trải dài từ chuẩn bị, thiết lập môi trường, cấu hình và tích hợp đến kiểm thử, đào tạo, chuyển giao, go-live và vận hành ổn định. Phạm vi cụ thể thay đổi theo loại công nghệ: một nền tảng SaaS có thể không cần lắp đặt máy chủ tại doanh nghiệp, trong khi hệ thống sản xuất, hạ tầng mạng hoặc giải pháp triển khai tại chỗ có thể đòi hỏi cả thiết bị, mạng, phần mềm và quy trình vận hành.

Triển khai công nghệ doanh nghiệp là gì?

Triển khai công nghệ doanh nghiệp là tập hợp các hoạt động cần thiết để đưa một giải pháp công nghệ vào môi trường nghiệp vụ thực tế và làm cho giải pháp đó có thể được sử dụng, quản trị và duy trì theo yêu cầu đã đặt ra.

Điểm cốt lõi nằm ở sự chuyển đổi từ giải pháp ở trạng thái thiết kế hoặc sẵn sàng cung cấp sang hệ thống đang hoạt động trong điều kiện thực tế của doanh nghiệp.

Quá trình này thường phải xử lý đồng thời ba lớp vấn đề.

Thứ nhất là lớp kỹ thuật: môi trường, cấu hình, quyền truy cập, tích hợp, dữ liệu, hiệu năng, bảo mật và khả năng phục hồi phải phù hợp với yêu cầu sử dụng.

Thứ hai là lớp nghiệp vụ: hệ thống phải hỗ trợ đúng quy trình, vai trò và tình huống làm việc mà doanh nghiệp cần.

Thứ ba là lớp vận hành: phải xác định ai quản trị, ai hỗ trợ người dùng, cách xử lý sự cố, cách thay đổi cấu hình và cách duy trì hệ thống sau khi đội dự án rút khỏi giai đoạn triển khai.

Ba lớp này liên hệ trực tiếp với nhau. Một chức năng có thể chạy đúng về mặt kỹ thuật nhưng vẫn chưa đủ điều kiện sử dụng nếu quy trình nghiệp vụ chưa được xác nhận hoặc người dùng chưa có quyền phù hợp. Ngược lại, một quy trình được thiết kế hợp lý cũng không thể vận hành nếu dữ liệu, tích hợp hoặc hạ tầng chưa sẵn sàng.

Bởi vậy, trạng thái “đã cài đặt” không đồng nghĩa với “đã triển khai xong”.

Triển khai công nghệ khác gì với mua, cài đặt và vận hành hệ thống?

Mua công nghệ, cài đặt công nghệ, triển khai công nghệ và vận hành công nghệ là những hoạt động có liên hệ nhưng không hoàn toàn đồng nhất.

Mua hoặc đăng ký giải pháp tạo quyền sở hữu hoặc quyền sử dụng sản phẩm, dịch vụ. Doanh nghiệp có thể đã ký hợp đồng hoặc được cấp tài khoản nhưng hệ thống vẫn chưa phù hợp với quy trình thực tế.

Cài đặt tập trung vào việc làm cho thành phần kỹ thuật tồn tại và có thể khởi chạy trong một môi trường nhất định. Đây thường chỉ là một công đoạn của triển khai.

Triển khai bao quát việc đưa giải pháp vào điều kiện sử dụng thực tế: cấu hình theo yêu cầu, kết nối hệ thống, chuẩn bị dữ liệu, kiểm thử, phân quyền, đào tạo, nghiệm thu và đưa vào sử dụng.

Vận hành bắt đầu khi hệ thống đã được đưa vào hoạt động và cần được giám sát, hỗ trợ, bảo trì cũng như quản lý thay đổi liên tục.

Ranh giới này đặc biệt quan trọng khi xác định trách nhiệm dự án. Nếu phạm vi hợp đồng chỉ quy định “cài đặt phần mềm” nhưng doanh nghiệp kỳ vọng cả chuyển đổi dữ liệu, tích hợp, đào tạo và hỗ trợ go-live, hai bên có thể hiểu khác nhau về điều kiện hoàn thành.

Do đó, một dự án triển khai cần xác định kết quả đầu ra và tiêu chí nghiệm thu cho từng phần việc thay vì chỉ dùng một trạng thái chung như “hệ thống đã chạy”.

Chuẩn bị trước khi triển khai công nghệ

Giai đoạn chuẩn bị quyết định doanh nghiệp đang đưa giải pháp vào môi trường nào, phục vụ ai và phải đạt điều kiện gì trước khi chuyển sang sử dụng thực tế.

Xác định yêu cầu và phạm vi triển khai

Trước khi cấu hình hệ thống, đội triển khai cần làm rõ các quy trình được hỗ trợ, nhóm người dùng, đơn vị tham gia, chức năng nằm trong phạm vi và những thành phần chưa triển khai ở giai đoạn hiện tại.

Yêu cầu cũng cần được chuyển thành các điều kiện có thể kiểm tra. Ví dụ, thay vì chỉ yêu cầu “đồng bộ dữ liệu khách hàng”, phạm vi triển khai cần xác định dữ liệu nào được đồng bộ, nguồn và đích là hệ thống nào, thời điểm đồng bộ, quy tắc xử lý bản ghi trùng và cách phản ứng khi đồng bộ thất bại.

Sự cụ thể này tạo cơ sở cho cấu hình, kiểm thử và nghiệm thu sau đó.

Đánh giá mức độ sẵn sàng của môi trường

Giải pháp công nghệ luôn phụ thuộc vào một số điều kiện nền. Tùy mô hình triển khai, chúng có thể bao gồm máy chủ, thiết bị đầu cuối, mạng, tài khoản, dịch vụ danh tính, chứng thư số, tên miền, cơ sở dữ liệu, API hoặc dịch vụ đám mây.

Đánh giá readiness nhằm phát hiện các phụ thuộc chưa sẵn sàng trước khi chúng trở thành điểm nghẽn của dự án.

Với giải pháp SaaS, phần hạ tầng do nhà cung cấp quản lý có thể giảm đáng kể, nhưng doanh nghiệp vẫn phải chuẩn bị tài khoản, phân quyền, danh tính người dùng, kết nối dữ liệu và các chính sách quản trị liên quan. Với hệ thống triển khai tại chỗ, phạm vi chuẩn bị thường rộng hơn vì doanh nghiệp còn phải kiểm soát hạ tầng chạy hệ thống.

Xác định tiêu chí nghiệm thu

Tiêu chí nghiệm thu cần được xác định trước khi kiểm thử, không phải sau khi hệ thống đã được triển khai.

Các tiêu chí có thể liên quan đến chức năng nghiệp vụ, tính chính xác của dữ liệu, quyền truy cập, khả năng tích hợp, thời gian phản hồi, tính sẵn sàng của tài liệu hoặc mức độ hoàn thành đào tạo.

Những chỉ số như thời gian phản hồi hay tỷ lệ lỗi không có một ngưỡng chung phù hợp cho mọi hệ thống. Ngưỡng chấp nhận phải xuất phát từ yêu cầu nghiệp vụ, kiến trúc và mức dịch vụ mà dự án đã thống nhất.

Cấu hình, tích hợp và chuẩn bị dữ liệu

Khi môi trường đã sẵn sàng, trọng tâm chuyển sang làm cho giải pháp phù hợp với kiến trúc và cách vận hành cụ thể của doanh nghiệp.

Cấu hình hệ thống

Cấu hình có thể bao gồm cơ cấu tổ chức, vai trò người dùng, quy trình phê duyệt, thông báo, trường dữ liệu, tham số nghiệp vụ, chính sách truy cập hoặc các quy tắc tự động hóa.

Nguyên tắc quan trọng là phân biệt giữa cấu hình cần thiết và tùy biến không cần thiết. Cấu hình sử dụng khả năng sẵn có của sản phẩm thường dễ bảo trì hơn, trong khi tùy biến mã nguồn hoặc phát triển thành phần riêng có thể tạo thêm phụ thuộc khi nâng cấp.

Tuy nhiên, không thể kết luận rằng mọi tùy biến đều nên tránh. Nếu một yêu cầu nghiệp vụ bắt buộc không thể đáp ứng bằng chức năng tiêu chuẩn, tùy biến có thể là lựa chọn hợp lý miễn là tác động đến bảo trì, kiểm thử và nâng cấp đã được đánh giá.

Tích hợp với các hệ thống liên quan

Trong doanh nghiệp, một công nghệ hiếm khi hoạt động hoàn toàn độc lập. Hệ thống mới có thể phải trao đổi dữ liệu với ERP, CRM, phần mềm kế toán, hệ thống nhân sự, nền tảng định danh, kho dữ liệu hoặc các dịch vụ bên ngoài.

Tích hợp không chỉ là thiết lập kết nối. Đội triển khai phải xác định dữ liệu nào được trao đổi, hệ thống nào là nguồn chính, cách xác thực, thời điểm truyền dữ liệu, cách xử lý lỗi và cách đối soát khi hai hệ thống không nhất quán.

Nếu các quan hệ này không rõ, hệ thống có thể vẫn kết nối thành công về mặt kỹ thuật nhưng tạo dữ liệu sai hoặc không xác định được bên chịu trách nhiệm khi xảy ra lỗi.

Chuyển đổi và kiểm soát dữ liệu

Khi hệ thống mới cần tiếp nhận dữ liệu từ công nghệ cũ, hoạt động migration thường gồm trích xuất, làm sạch, ánh xạ, chuyển đổi, nạp dữ liệu và đối soát.

Một đợt migration thành công không chỉ được xác định bằng việc “đã nhập đủ file”. Doanh nghiệp cần kiểm tra số lượng bản ghi, trường dữ liệu quan trọng, quan hệ giữa các đối tượng, dữ liệu trùng, dữ liệu thiếu và khả năng sử dụng dữ liệu sau khi chuyển đổi.

Với dữ liệu quan trọng, nên thực hiện migration thử trước lần chuyển chính thức. Điều này giúp phát hiện lỗi ánh xạ hoặc chất lượng dữ liệu khi vẫn còn khả năng điều chỉnh quy trình.

Thiết lập quyền truy cập và kiểm soát bảo mật

Phân quyền nên dựa trên vai trò và nhu cầu công việc thay vì cấp quyền rộng để thuận tiện trong giai đoạn triển khai.

Ngoài quyền người dùng, tùy loại hệ thống còn cần xem xét tài khoản quản trị, tài khoản dịch vụ, bí mật kết nối, nhật ký hoạt động, cơ chế xác thực và quyền của các hệ thống tích hợp.

Việc kiểm soát các yếu tố này ngay trong triển khai giúp tránh tình trạng một cấu hình tạm thời được giữ nguyên khi hệ thống đã chuyển sang vận hành chính thức.

Kiểm thử và nghiệm thu trước khi đưa vào sử dụng

Kiểm thử trả lời câu hỏi quan trọng: hệ thống có hoạt động đúng trong điều kiện mà doanh nghiệp sẽ sử dụng hay không?

Chỉ kiểm tra từng chức năng riêng lẻ thường chưa đủ. Một hệ thống có thể xử lý đúng từng bước nhưng thất bại khi nhiều thành phần phối hợp với nhau.

Kiểm thử chức năng và tích hợp

Kiểm thử chức năng xác nhận các tính năng thực hiện đúng yêu cầu đã xác định. Kiểm thử tích hợp tập trung vào luồng dữ liệu và tương tác giữa các hệ thống.

Những tình huống lỗi cũng cần được kiểm tra. Ví dụ, ngoài trường hợp API nhận dữ liệu thành công, cần biết điều gì xảy ra khi kết nối gián đoạn, dữ liệu không hợp lệ hoặc hệ thống đích không phản hồi.

Kiểm thử quy trình nghiệp vụ

Đây là bước kiểm tra hệ thống từ góc nhìn của người thực hiện công việc.

Thay vì thử từng nút hoặc màn hình độc lập, người dùng đi qua một quy trình hoàn chỉnh: tạo dữ liệu, xử lý, phê duyệt, cập nhật trạng thái, phát sinh chứng từ hoặc chuyển thông tin sang hệ thống khác.

Cách kiểm thử này giúp phát hiện những khoảng trống mà kiểm thử kỹ thuật đơn lẻ khó nhận thấy.

Kiểm thử chấp nhận của người dùng

User Acceptance Testing tập trung xác nhận giải pháp đáp ứng các yêu cầu nghiệp vụ đã thống nhất và có thể được chấp nhận để đưa vào sử dụng.

UAT không nên biến thành giai đoạn khám phá lại toàn bộ nhu cầu ban đầu. Nếu trong UAT liên tục xuất hiện yêu cầu nền tảng chưa từng được xác định, nguyên nhân thường nằm ở quá trình thu thập yêu cầu hoặc thiết kế trước đó.

Kết quả kiểm thử nên được ghi nhận cùng lỗi tồn tại, mức độ ảnh hưởng, người chịu trách nhiệm xử lý và điều kiện để lỗi được đóng.

Nghiệm thu chỉ có ý nghĩa khi dựa trên tiêu chí đã thống nhất. Việc “không còn lỗi nào” thường không phải điều kiện thực tế; quan trọng hơn là không còn lỗi vượt ngưỡng chấp nhận đối với phạm vi đưa vào hoạt động.

Đào tạo, chuyển giao và đưa hệ thống vào hoạt động

Một hệ thống đạt yêu cầu kỹ thuật vẫn có thể thất bại khi đưa vào thực tế nếu người dùng và đội vận hành không biết cách sử dụng, quản trị hoặc xử lý sự cố.

Đào tạo người dùng và quản trị viên

Nội dung đào tạo cần gắn với vai trò.

Người dùng nghiệp vụ cần hiểu cách hoàn thành công việc trên hệ thống và xử lý các tình huống thường gặp. Quản trị viên cần biết quản lý tài khoản, cấu hình, theo dõi trạng thái, sao lưu hoặc các thao tác vận hành phù hợp với phạm vi trách nhiệm.

Đào tạo quá sớm có thể kém hiệu quả nếu giao diện và quy trình còn thay đổi mạnh. Đào tạo quá muộn lại khiến người dùng chưa sẵn sàng khi hệ thống go-live. Vì vậy, thời điểm đào tạo nên gắn với mức độ ổn định của cấu hình và kế hoạch chuyển đổi.

Chuẩn bị tài liệu và bàn giao trách nhiệm

Chuyển giao không chỉ là gửi tài liệu hướng dẫn. Doanh nghiệp phải biết sau go-live ai chịu trách nhiệm với từng loại vấn đề.

Tùy hệ thống, bộ tài liệu có thể bao gồm hướng dẫn người dùng, tài liệu quản trị, sơ đồ tích hợp, danh sách cấu hình quan trọng, quy trình xử lý sự cố, thông tin sao lưu và phục hồi, danh sách đầu mối hỗ trợ hoặc các thay đổi đã thực hiện trong dự án.

Một phần đặc biệt quan trọng là phân định trách nhiệm giữa đội dự án, bộ phận IT nội bộ, bộ phận nghiệp vụ và nhà cung cấp. Nếu phần này không rõ, sự cố sau go-live dễ bị chuyển qua lại giữa các bên.

Thực hiện go-live

Go-live là thời điểm hệ thống bắt đầu phục vụ người dùng hoặc quy trình thực tế theo phạm vi đã xác định.

Việc chuyển đổi có thể được thực hiện một lần cho toàn bộ phạm vi hoặc theo từng nhóm người dùng, đơn vị hay chức năng. Không có phương án duy nhất phù hợp với mọi dự án.

Chuyển đổi đồng loạt có thể rút ngắn thời gian phải duy trì hai môi trường nhưng làm tăng mức độ tập trung rủi ro. Chuyển đổi từng giai đoạn giúp giới hạn phạm vi ảnh hưởng nhưng có thể làm tăng độ phức tạp của dữ liệu, tích hợp và vận hành song song.

Quyết định nên dựa trên mức độ phụ thuộc giữa các quy trình, khả năng quay lại phương án cũ, độ phức tạp dữ liệu và khả năng hỗ trợ trong thời gian chuyển đổi.

Vận hành ổn định sau triển khai

Go-live không phải lúc mọi công việc triển khai kết thúc ngay lập tức. Những ngày hoặc tuần đầu thường là giai đoạn xác nhận rằng hệ thống có thể duy trì hoạt động trong điều kiện thực tế.

Theo dõi hệ thống và xử lý sự cố ban đầu

Sau khi đưa vào sử dụng, số lượng người dùng, dữ liệu thật và các tình huống nghiệp vụ thực tế có thể làm lộ ra những vấn đề không xuất hiện trong môi trường kiểm thử.

Đội triển khai cần theo dõi các chỉ số phù hợp với hệ thống như lỗi ứng dụng, thời gian phản hồi, trạng thái tích hợp, hàng đợi xử lý, tài nguyên hạ tầng hoặc số lượng yêu cầu hỗ trợ.

Không nên sử dụng một bộ ngưỡng chung cho mọi công nghệ. Một hệ thống giao dịch thời gian thực và một công cụ nội bộ dùng theo đợt có yêu cầu hiệu năng và mức độ sẵn sàng rất khác nhau.

Ổn định cấu hình và quản lý thay đổi

Trong giai đoạn đầu, người dùng thường phát sinh đề nghị điều chỉnh. Không phải yêu cầu nào cũng nên được thực hiện ngay.

Cần phân biệt lỗi phải sửa, thay đổi cần thiết để hoàn thành yêu cầu đã thống nhất và nhu cầu mới phát sinh sau khi người dùng bắt đầu làm quen với hệ thống.

Nếu mọi đề nghị đều được xử lý như lỗi triển khai, phạm vi dự án có thể liên tục mở rộng. Ngược lại, nếu mọi vấn đề đều bị xem là yêu cầu mới, những thiếu sót thực sự của quá trình triển khai có thể không được xử lý đầy đủ.

Quản lý thay đổi tạo ranh giới giữa hai trường hợp này và giúp hệ thống tiếp tục ổn định.

Chuyển sang mô hình vận hành thường xuyên

Giai đoạn triển khai có thể kết thúc khi các lỗi nghiêm trọng trong phạm vi đã thống nhất được xử lý, hệ thống đáp ứng tiêu chí nghiệm thu, đội vận hành tiếp nhận trách nhiệm và quy trình hỗ trợ đã hoạt động.

Từ thời điểm đó, các hoạt động như giám sát, hỗ trợ người dùng, bảo trì, quản lý bản vá, thay đổi cấu hình, quản trị quyền và nâng cấp trở thành công việc vận hành thường xuyên.

Đây cũng là ranh giới giúp doanh nghiệp đánh giá chính xác dự án triển khai đã hoàn thành hay vẫn đang phụ thuộc vào đội dự án để duy trì hoạt động cơ bản.

Một triển khai công nghệ được xem là hoàn thành khi nào?

Không nên xác định hoàn thành chỉ bằng ngày go-live. Một cách đánh giá thực tế hơn là kiểm tra đồng thời khả năng hoạt động của công nghệ, mức độ đáp ứng nghiệp vụ và khả năng tiếp quản của tổ chức.

Thông thường, doanh nghiệp cần xác nhận các nhóm điều kiện sau:

·         Các chức năng thuộc phạm vi đã vượt qua tiêu chí nghiệm thu

·         Dữ liệu cần thiết đã được chuyển đổi và đối soát theo yêu cầu

·         Các tích hợp trọng yếu hoạt động đúng trong những tình huống đã kiểm thử

·         Quyền truy cập và vai trò quản trị đã được thiết lập

·         Người dùng và nhân sự vận hành cần thiết đã được đào tạo

·         Tài liệu và trách nhiệm hỗ trợ đã được chuyển giao

·         Các lỗi còn tồn tại đã được phân loại và nằm trong mức chấp nhận đã thống nhất

·         Quy trình giám sát, hỗ trợ và xử lý sự cố đã có người chịu trách nhiệm

Các điều kiện này phải được điều chỉnh theo từng hệ thống. Một giải pháp nhỏ phục vụ một nhóm nội bộ không cần cơ chế nghiệm thu giống một hệ thống lõi có ảnh hưởng đến nhiều đơn vị.

Điểm chung là doanh nghiệp cần có bằng chứng rằng công nghệ không chỉ “đã bật lên” mà đã trở thành một hệ thống có thể sử dụng và vận hành trong phạm vi dự kiến.

Triển khai công nghệ doanh nghiệp là quá trình đưa công nghệ từ trạng thái được lựa chọn hoặc thiết kế vào hoạt động thực tế, với đầy đủ điều kiện về kỹ thuật, dữ liệu, nghiệp vụ, con người và vận hành. Vì vậy, cấu hình hay cài đặt chỉ là một phần của toàn bộ quá trình.

Một triển khai đầy đủ thường đi qua chuẩn bị yêu cầu và môi trường, cấu hình, tích hợp, chuyển đổi dữ liệu, kiểm thử, nghiệm thu, đào tạo, chuyển giao, go-live và ổn định vận hành. Chất lượng triển khai không được xác định bởi việc hệ thống có thể khởi chạy, mà bởi việc nó đáp ứng yêu cầu đã thống nhất và doanh nghiệp có thể tiếp tục sử dụng, quản trị cũng như hỗ trợ hệ thống sau khi dự án kết thúc.