Cách quản lý phụ thuộc công nghệ doanh nghiệp
- Nhận diện đầy đủ các điểm phụ thuộc trước khi đưa công nghệ vào kế hoạch
- Đánh giá mức độ trọng yếu thay vì coi mọi phụ thuộc đều nguy hiểm như nhau
- Lượng hóa phụ thuộc bằng các chỉ số có thể theo dõi
- Đưa yêu cầu giảm phụ thuộc vào kiến trúc, mua sắm và hợp đồng
- Xây khả năng phục hồi mà không phải nhân đôi mọi hệ thống
- Đưa phụ thuộc công nghệ vào chu kỳ hoạch định và quyết định đầu tư
- Kiểm thử khả năng thoát để biết mức phụ thuộc thực tế
- Chấp nhận phụ thuộc khi lợi ích lớn hơn rủi ro đã được kiểm soát
Một mức phụ thuộc cao vẫn có thể chấp nhận được nếu công nghệ tạo lợi thế rõ ràng, nhà cung cấp đủ tin cậy và doanh nghiệp có khả năng phục hồi hoặc chuyển đổi khi điều kiện thay đổi. Ngược lại, một hệ thống tưởng như ít quan trọng vẫn có thể trở thành điểm nghẽn nếu giữ dữ liệu duy nhất, kết nối nhiều quy trình hoặc chỉ một nhóm nhỏ có khả năng vận hành.
Do đó, quản lý phụ thuộc công nghệ trong hoạch định cần được xem như một phần của quản trị rủi ro doanh nghiệp và quản trị chuỗi cung ứng công nghệ, thay vì chỉ là nhiệm vụ của bộ phận CNTT. NIST cũng đặt quản trị rủi ro chuỗi cung ứng công nghệ vào hoạt động quản trị và yêu cầu tổ chức xác định, đánh giá, giảm thiểu rủi ro trong toàn bộ vòng đời sản phẩm và dịch vụ công nghệ.
Nhận diện đầy đủ các điểm phụ thuộc trước khi đưa công nghệ vào kế hoạch
Doanh nghiệp chỉ có thể quản lý những phụ thuộc đã được nhìn thấy. Vì vậy, bước đầu tiên không nên là tìm ngay một nhà cung cấp dự phòng mà là lập bản đồ những thành phần mà hoạt động kinh doanh đang hoặc sẽ dựa vào.
Phạm vi nhận diện nên bao gồm cả công nghệ và các điều kiện giúp công nghệ vận hành:
· Nhà cung cấp phần mềm, dịch vụ đám mây và hạ tầng
· Nền tảng hoặc hệ sinh thái công nghệ độc quyền
· Dữ liệu và định dạng lưu trữ
· API, giao diện tích hợp và dịch vụ trung gian
· Phần mềm nguồn đóng, giấy phép và quyền sử dụng
· Thiết bị hoặc linh kiện chuyên dụng
· Nhân sự sở hữu kỹ năng hoặc kiến thức vận hành đặc thù
· Đối tác triển khai, bảo trì và hỗ trợ kỹ thuật
· Các hệ thống kế thừa mà quy trình mới vẫn phải kết nối
Điểm cần chú ý là không đánh giá một công nghệ riêng lẻ chỉ theo chức năng của nó. Một ứng dụng nhỏ có thể trở thành phụ thuộc trọng yếu nếu năm hệ thống khác lấy dữ liệu từ ứng dụng đó. Tương tự, doanh nghiệp có thể ký hợp đồng với nhiều nhà cung cấp nhưng vẫn tồn tại tập trung rủi ro nếu tất cả cùng sử dụng một hạ tầng, thư viện hoặc dịch vụ nền phía sau.
NIST mô tả quản trị rủi ro chuỗi cung ứng công nghệ như quá trình xuyên suốt vòng đời, từ thiết kế, phát triển và mua sắm đến triển khai, bảo trì và loại bỏ. Cách tiếp cận này cho thấy việc nhận diện phụ thuộc cần thực hiện ngay trong hoạch định, thay vì đợi đến khi hệ thống đã vận hành mới xử lý.

Đánh giá mức độ trọng yếu thay vì coi mọi phụ thuộc đều nguy hiểm như nhau
Không phải phụ thuộc công nghệ nào cũng cần loại bỏ. Nếu doanh nghiệp cố tạo phương án thay thế cho mọi công cụ, chi phí kiến trúc, vận hành và nhân lực có thể tăng nhanh hơn giá trị rủi ro được giảm.
Mỗi điểm phụ thuộc nên được đánh giá theo hai nhóm yếu tố: mức độ phụ thuộc và hậu quả nếu phụ thuộc bị gián đoạn.
Với mức độ phụ thuộc, doanh nghiệp cần xem xét khả năng thay thế nhà cung cấp, mức độc quyền của công nghệ, khả năng chuyển dữ liệu, số lượng nhân sự có năng lực vận hành và mức độ hệ thống khác bị khóa vào cùng kiến trúc.
Với hậu quả, cần xem xét quy trình nào sẽ dừng, doanh thu hoặc dịch vụ khách hàng nào bị ảnh hưởng, nghĩa vụ pháp lý nào có thể bị vi phạm và doanh nghiệp chịu được gián đoạn trong bao lâu.
Một mô hình đánh giá thực tế có thể xếp mỗi phụ thuộc theo ba mức:
· Thấp: Có thể thay thế tương đối dễ, tác động gián đoạn hạn chế
· Trung bình: Việc thay thế cần chuẩn bị nhưng vẫn có phương án khả thi
· Trọng yếu: Việc mất công nghệ hoặc nhà cung cấp có thể dừng một chức năng kinh doanh quan trọng và chưa có giải pháp thay thế đủ nhanh
Cách phân loại này giúp ngân sách kiểm soát tập trung vào những nơi mà thất bại công nghệ thực sự có thể trở thành thất bại kinh doanh.
Lượng hóa phụ thuộc bằng các chỉ số có thể theo dõi
Nhận định như “phụ thuộc nhiều”, “khó thay thế” hoặc “rủi ro cao” chưa đủ cho hoạch định. Các kết luận này cần được chuyển thành chỉ số để ban lãnh đạo có thể so sánh giữa các lựa chọn công nghệ.
Một số chỉ số hữu ích gồm:
Tỷ lệ tập trung nhà cung cấp: Xác định bao nhiêu phần trăm hệ thống, quy trình trọng yếu hoặc chi tiêu công nghệ đang tập trung vào cùng một nhà cung cấp hay cùng một nền tảng.
Thời gian chuyển đổi dự kiến: Ước tính thời gian từ khi quyết định rời công nghệ hiện tại đến khi một giải pháp thay thế có thể vận hành ở mức chấp nhận được.
Khả năng di chuyển dữ liệu: Kiểm tra doanh nghiệp có thể xuất toàn bộ dữ liệu cần thiết hay không, dưới định dạng nào, mất bao lâu và có thể nhập dữ liệu đó vào hệ thống khác đến mức nào.
RTO và RPO: Với hệ thống trọng yếu, thời gian phục hồi mục tiêu và mức mất dữ liệu chấp nhận được giúp chuyển tác động gián đoạn thành yêu cầu kỹ thuật cụ thể.
Độ phủ kỹ năng: Xác định bao nhiêu người thực sự có thể vận hành, xử lý sự cố hoặc chuyển đổi hệ thống. Một công nghệ được nhiều nhà cung cấp hỗ trợ vẫn có thể là điểm phụ thuộc nếu nội bộ chỉ có một người hiểu kiến trúc.
Mức sẵn sàng của phương án thay thế: Không chỉ hỏi “có nhà cung cấp khác hay không” mà phải xác định giải pháp thay thế đã được đánh giá, tích hợp thử và kiểm chứng đến đâu.
Không tồn tại một ngưỡng phần trăm duy nhất phù hợp cho mọi doanh nghiệp. Ngưỡng chấp nhận phải gắn với khẩu vị rủi ro, mức độ quan trọng của quy trình và chi phí chuyển đổi. Một hệ thống hậu cần vận hành liên tục sẽ cần giới hạn khác với một công cụ hỗ trợ nội bộ ít quan trọng.
Đưa yêu cầu giảm phụ thuộc vào kiến trúc, mua sắm và hợp đồng
Rủi ro phụ thuộc thường hình thành ngay khi doanh nghiệp lựa chọn kiến trúc hoặc ký hợp đồng. Nếu các điều kiện thoát khỏi công nghệ chỉ được xem xét khi muốn thay nhà cung cấp, phần lớn quyền thương lượng đã mất.
NIST CSF 2.0 khuyến nghị tổ chức xây dựng năng lực quản trị rủi ro chuỗi cung ứng và xác định, truyền đạt các yêu cầu đối với nhà cung cấp. Với hoạch định công nghệ, nguyên tắc này có thể chuyển thành các yêu cầu cụ thể ngay trong quá trình lựa chọn.
Hợp đồng và thiết kế giải pháp cần làm rõ quyền sở hữu dữ liệu, cách xuất dữ liệu, định dạng xuất, khả năng truy cập khi chấm dứt dịch vụ, trách nhiệm hỗ trợ chuyển đổi, SLA, điều kiện thay đổi giá và quy trình xử lý khi nhà cung cấp ngừng sản phẩm.
Ở cấp kiến trúc, doanh nghiệp nên đánh giá mức độ sử dụng tiêu chuẩn mở, khả năng tích hợp thông qua giao diện được tài liệu hóa và mức độ logic nghiệp vụ bị gắn chặt với tính năng độc quyền.
Đặc biệt với môi trường đám mây, khả năng di chuyển ứng dụng và dữ liệu là một yếu tố trực tiếp liên quan đến vendor lock-in. NIST từng xác định portability của ứng dụng và dữ liệu là yếu tố quan trọng để hạn chế tình trạng bị khóa vào một nhà cung cấp.
Điều này không có nghĩa doanh nghiệp phải tránh mọi tính năng độc quyền. Một dịch vụ độc quyền có thể tạo năng suất hoặc tốc độ triển khai vượt trội. Quyết định đúng là hiểu rõ lợi ích nhận được có đủ lớn để chấp nhận chi phí thoát và mức phụ thuộc phát sinh hay không.
Xây khả năng phục hồi mà không phải nhân đôi mọi hệ thống
Một cách hiểu sai phổ biến là giảm phụ thuộc đồng nghĩa với triển khai nhiều nhà cung cấp cho mọi công nghệ. Multi-cloud, nhiều ERP hay hai hệ thống song song đôi khi còn làm tăng chi phí, độ phức tạp và số điểm lỗi.
Khả năng phục hồi nên được thiết kế tương ứng với mức độ trọng yếu.
Với một số hệ thống, sao lưu dữ liệu độc lập và quy trình khôi phục đã đủ. Với hệ thống khác, doanh nghiệp cần một nhà cung cấp thay thế. Trường hợp yêu cầu liên tục rất cao có thể cần kiến trúc dự phòng hoặc phân tán thực sự.
Các biện pháp thường có giá trị gồm chuẩn hóa dữ liệu, tách lớp tích hợp khỏi nền tảng lõi, lưu bản sao dữ liệu ở phạm vi doanh nghiệp kiểm soát, sử dụng API có tài liệu, tự động hóa cấu hình và duy trì tài liệu kiến trúc đủ để đội ngũ khác có thể tiếp quản.
Đối với kỹ năng, giảm phụ thuộc không nhất thiết phải tuyển một đội ngũ thứ hai. Cross-training, tài liệu vận hành, quản lý mã nguồn và phân quyền kiến thức có thể loại bỏ tình trạng một cá nhân trở thành “single point of failure”.
Một phương án dự phòng chỉ có giá trị khi có thể thực hiện trong điều kiện thật. Bản sao lưu chưa từng phục hồi, dữ liệu chưa từng xuất hoặc nhà cung cấp thay thế chưa từng chạy thử vẫn là những giả định, không phải khả năng phục hồi đã được chứng minh.
Đưa phụ thuộc công nghệ vào chu kỳ hoạch định và quyết định đầu tư
Quản lý phụ thuộc công nghệ sẽ kém hiệu quả nếu chỉ tồn tại trong một bảng đăng ký rủi ro của bộ phận CNTT. Mỗi quyết định đầu tư công nghệ quan trọng nên đi kèm câu hỏi về mức phụ thuộc mới mà nó tạo ra.
Trước khi phê duyệt, doanh nghiệp cần biết:
1. Công nghệ này sẽ trở thành điều kiện bắt buộc cho những quy trình nào
2. Điều gì xảy ra nếu nhà cung cấp tăng giá, giảm chất lượng hoặc ngừng dịch vụ
3. Dữ liệu và ứng dụng có thể chuyển đi như thế nào
4. Ai sở hữu năng lực vận hành và xử lý sự cố
5. Chi phí và thời gian chuyển đổi ước tính là bao nhiêu
6. Phương án phục hồi hoặc thay thế đã được kiểm chứng ở mức nào
Trách nhiệm cũng cần được phân chia rõ. Chủ sở hữu nghiệp vụ đánh giá tác động kinh doanh; đội công nghệ đánh giá kiến trúc và khả năng chuyển đổi; mua sắm quản lý điều khoản nhà cung cấp; pháp chế kiểm tra quyền dữ liệu và chấm dứt hợp đồng; quản trị rủi ro xác định mức chấp nhận.
CISA cũng nhấn mạnh việc xác định, ưu tiên các dependency của bên thứ ba và quản lý rủi ro của những dependency đó; hợp đồng và SLA có thể được sử dụng để quy định trách nhiệm, yêu cầu giám sát và kiểm tra nhà cung cấp.
Khi các vai trò này được kết nối với quy trình đầu tư, phụ thuộc công nghệ trở thành một biến số của quyết định kinh doanh thay vì một vấn đề kỹ thuật xuất hiện sau triển khai.
Kiểm thử khả năng thoát để biết mức phụ thuộc thực tế
Kế hoạch thoát khỏi một công nghệ không nên chỉ tồn tại trên giấy. Mức phụ thuộc thực chỉ lộ rõ khi doanh nghiệp thử lấy dữ liệu ra, dựng lại dịch vụ, chuyển workload hoặc vận hành bằng phương án thay thế.
Tùy mức độ quan trọng của hệ thống, kiểm thử có thể bao gồm:
· Xuất và phục hồi một tập dữ liệu hoàn chỉnh
· Dựng lại ứng dụng từ tài liệu và mã nguồn hiện có
· Kiểm tra thời gian chuyển sang nhà cung cấp thay thế
· Mô phỏng việc mất quyền truy cập vào một dịch vụ quan trọng
· Kiểm tra tài khoản quản trị, khóa mã hóa và tài sản kỹ thuật có nằm dưới quyền kiểm soát của doanh nghiệp hay không
· Xác minh đội ngũ khác có thể vận hành hệ thống nếu nhân sự chủ chốt không sẵn sàng
Kết quả kiểm thử phải quay trở lại kế hoạch. Nếu thời gian di chuyển thực tế dài hơn khả năng gián đoạn mà doanh nghiệp chấp nhận, doanh nghiệp phải giảm thời gian chuyển đổi, tăng khả năng dự phòng hoặc chính thức chấp nhận rủi ro ở cấp có thẩm quyền.
Đây là điểm khác biệt giữa “có exit plan” và “có khả năng exit”.
Chấp nhận phụ thuộc khi lợi ích lớn hơn rủi ro đã được kiểm soát
Mục tiêu cuối cùng không phải đạt trạng thái độc lập hoàn toàn về công nghệ. Điều đó vừa khó thực hiện vừa có thể làm mất lợi ích từ chuyên môn hóa, quy mô và tốc độ đổi mới của các nền tảng bên ngoài.
Một doanh nghiệp có thể chủ động phụ thuộc sâu vào một nền tảng khi ba điều kiện đồng thời được đáp ứng: lợi ích kinh doanh đủ lớn, hậu quả khi gián đoạn nằm trong khả năng chịu đựng và có biện pháp kiểm soát phù hợp với mức rủi ro.
Ngược lại, mức phụ thuộc cần được giảm khi doanh nghiệp không biết dữ liệu có thể lấy ra hay không, không thể ước tính thời gian chuyển đổi, thiếu quyền kiểm soát tài sản quan trọng, chỉ một nhà cung cấp hoặc một nhóm nhỏ có khả năng vận hành, hoặc một sự cố duy nhất có thể dừng chức năng kinh doanh trọng yếu.
Vì vậy, trong hoạch định, câu hỏi đúng không phải là “có nên phụ thuộc công nghệ này không?” mà là “doanh nghiệp đang nhận được giá trị gì để đổi lấy mức phụ thuộc này, hậu quả xấu nhất là gì và khả năng thoát đã được chứng minh đến đâu?”.
Quản lý phụ thuộc công nghệ doanh nghiệp cần bắt đầu trước khi công nghệ được mua hoặc triển khai. Doanh nghiệp nên lập bản đồ dependency, xác định mức trọng yếu, lượng hóa rủi ro, đưa yêu cầu portability và exit vào kiến trúc cũng như hợp đồng, xây khả năng phục hồi tương ứng với tác động và kiểm thử định kỳ các phương án thay thế.
Phụ thuộc công nghệ không tự nó là một sai lầm. Rủi ro xuất hiện khi doanh nghiệp phụ thuộc vào một thành phần quan trọng nhưng không biết mình phụ thuộc đến mức nào, không xác định được hậu quả và không có khả năng chuyển đổi trong thời gian hoạt động kinh doanh cho phép.
Doanh nghiệp có nhất thiết phải sử dụng nhiều nhà cung cấp để giảm phụ thuộc không?
Không. Đa nhà cung cấp chỉ phù hợp khi mức độ trọng yếu và lợi ích giảm rủi ro đủ lớn để bù cho chi phí vận hành thêm. Với nhiều hệ thống, khả năng xuất dữ liệu, khôi phục độc lập và có phương án chuyển đổi đã tạo mức kiểm soát phù hợp hơn việc duy trì hai nền tảng cùng lúc.
Khi nào cần lập exit plan cho một công nghệ?
Exit plan đặc biệt cần thiết khi công nghệ giữ dữ liệu trọng yếu, hỗ trợ quy trình không thể gián đoạn lâu, sử dụng định dạng hoặc kiến trúc độc quyền, có chi phí chuyển đổi cao hoặc doanh nghiệp có ít lựa chọn thay thế thực tế.
Tần suất kiểm tra phụ thuộc công nghệ nên được xác định như thế nào?
Tần suất nên dựa vào mức độ trọng yếu và tốc độ thay đổi của dependency, không áp dụng một lịch cố định cho mọi hệ thống. Những công nghệ liên quan trực tiếp đến hoạt động trọng yếu cần được xem xét khi thay đổi kiến trúc, hợp đồng, nhà cung cấp hoặc điều kiện kinh doanh và được kiểm thử phục hồi hoặc chuyển đổi theo chu kỳ phù hợp với khẩu vị rủi ro.
