Series Từ số hóa đến AI #46: Tránh vendor lock-in khi chọn phần mềm nhà máy – dữ liệu, API và khả năng mở rộng

I. Sáu lớp vendor lock-in

1. Lock-in dữ liệu

Dấu hiệu:

• Không xuất được dữ liệu gốc hoặc metadata.
• Chỉ xuất PDF/Excel tổng hợp, không đủ quan hệ.
• Không lấy được attachment, audit log, quyền hoặc version.
• Dữ liệu dùng định dạng độc quyền không có tài liệu.
• Khi kết thúc hợp đồng phải trả phí lớn để lấy dữ liệu.

Kiểm soát:

• Quyền sở hữu dữ liệu ghi rõ trong hợp đồng.
• Export định kỳ ở định dạng mở.
• Test restore/import một bộ dữ liệu mẫu.
• Data dictionary và schema documentation.

2. Lock-in tích hợp/API

Dấu hiệu:

• Không có API hoặc API chỉ dành cho gói rất cao.
• Connector thuộc độc quyền nhà cung cấp.
• Không có versioning/sandbox/documentation.
• Mọi tích hợp phải qua một đội duy nhất với SLA không rõ.
• API có giới hạn làm use case thực tế không chạy được.

Kiểm soát:

• Yêu cầu API documentation trước khi mua.
• Pilot ít nhất một luồng tích hợp thật.
• Làm rõ ownership của connector và mapping.
• Điều khoản backward compatibility hoặc notice khi thay đổi.

3. Lock-in tùy chỉnh và cấu hình

Dấu hiệu:

• Quy trình được code riêng thay vì cấu hình.
• Nâng cấp phải viết lại customization.
• Nhà máy không thể tự sửa danh mục, role, form hoặc dashboard.
• Tài liệu cấu hình không được bàn giao.

Kiểm soát:

• Ưu tiên standard configuration.
• Phân loại extension và core customization.
• Có môi trường test, release note và regression plan.
• Chuyển giao admin và super user.

4. Lock-in hạ tầng

Dấu hiệu:

• Chỉ chạy trên một môi trường không có phương án migration.
• Backup không thể restore ngoài nền tảng.
• Dịch vụ phụ thuộc vào thành phần không minh bạch.
• Không có sizing, architecture hoặc exit procedure.

Kiểm soát:

• Sơ đồ kiến trúc và dependency.
• Backup/export có thể kiểm thử.
• Kế hoạch chuyển cloud/on-premise nếu phù hợp.
• Làm rõ trách nhiệm và dữ liệu khi chấm dứt.

5. Lock-in thương mại

Dấu hiệu:

• Giá tăng mạnh khi thêm user/device/API.
• Phí export, support hoặc nâng cấp không rõ.
• Hợp đồng tự gia hạn dài, điều kiện chấm dứt khó.
• Không có cap hoặc cơ chế theo dõi chi phí AI usage.

Kiểm soát:

• Mô hình giá theo kịch bản 3-5 năm.
• Điều khoản tăng giá, renewal và termination.
• Unit price cho mở rộng.
• SLA và service credit rõ.

6. Lock-in tri thức và năng lực

Dấu hiệu:

• Chỉ một consultant hoặc một nhân viên nội bộ hiểu hệ thống.
• Không có tài liệu, runbook và đào tạo admin.
• Mọi báo cáo nhỏ đều phải đặt nhà cung cấp.
• Đội nội bộ không biết kiểm tra dữ liệu hoặc lỗi tích hợp.

Kiểm soát:

• Train-the-trainer và knowledge transfer.
• Tài liệu cấu hình, data model và support.
• Nhiều người nội bộ được đào tạo.
• Governance backlog và release nội bộ.

II. Vendor lock-in là một phổ, không phải có/không

Một hệ thống SaaS luôn có mức phụ thuộc vào nền tảng. Một hệ thống on-premise tùy chỉnh sâu cũng có thể lock-in cao hơn SaaS nếu không có tài liệu và đội ngũ.

Nên đánh giá theo mức độ:

• Thấp: dữ liệu mở, API rõ, cấu hình chuẩn, exit plan khả thi.
• Trung bình: có phụ thuộc nhưng được quản trị và chi phí dự báo được.
• Cao: dữ liệu/tích hợp/tùy chỉnh đóng, không có phương án chuyển đổi.

Không nhất thiết loại bỏ giải pháp có lock-in trung bình nếu giá trị và đối tác tốt; cần hiểu và chấp nhận rủi ro có chủ đích.

III. Checklist dữ liệu trước khi ký

• Dữ liệu thuộc sở hữu của ai?
• Có export toàn bộ record, relation và attachment không?
• Audit log, quyền và lịch sử version có xuất được không?
• Định dạng có tài liệu không?
• Có API đọc/ghi và bulk export không?
• Có thể chạy export định kỳ tự động không?
• Thời gian cung cấp dữ liệu khi chấm dứt là bao lâu?
• Backup tồn tại bao lâu sau chấm dứt?
• Nhà cung cấp xác nhận xóa dữ liệu bằng cách nào?
• Chi phí export/migration là bao nhiêu?

Nên yêu cầu demo export thật, không chỉ nghe cam kết.

IV. Checklist API và tích hợp

• Danh sách endpoint/use case được hỗ trợ.
• Authentication, rate limit và quota.
• Versioning và deprecation policy.
• Sandbox/test environment.
• Webhook/event và batch option.
• Error handling, retry và monitoring.
• API access có phụ phí không?
• Ai chịu trách nhiệm connector?
• Upgrade có ảnh hưởng tích hợp không?
• Có thể dùng đối tác tích hợp khác không?

Một API “có tồn tại” nhưng không đáp ứng bulk, latency hoặc quyền cần thiết vẫn có thể gây lock-in.

V. Kiểm soát customization

Trước mỗi yêu cầu tùy chỉnh, chấm theo bốn câu hỏi:

1. Đây có phải yêu cầu pháp lý/critical hay chỉ là thói quen hiện tại?
2. Có thể giải quyết bằng cấu hình hoặc thay đổi quy trình không?
3. Tùy chỉnh có dùng được khi mở rộng nhà máy khác không?
4. Ai sẽ bảo trì khi nâng cấp?

Nên duy trì customization register gồm owner, mục đích, code/config, dependency, test case và chi phí nâng cấp.

VI. Scoring model lựa chọn nhà cung cấp

Trọng số phải theo chiến lược; không nên chỉ dùng tổng điểm chức năng.

VII. Điều khoản nên làm rõ trong hợp đồng

Đây không phải tư vấn pháp lý, nhưng các chủ đề cần xem xét gồm:

• Quyền sở hữu và sử dụng dữ liệu.
• Data export, format, thời gian và chi phí.
• API/connector và tài sản tùy chỉnh.
• SLA, support và escalation.
• Security, incident notification và subprocessor.
• Model/AI data usage nếu có.
• Backup, retention và deletion.
• Renewal, price increase và termination.
• Transition assistance.
• Documentation và knowledge transfer.

Pháp chế và mua hàng cần phối hợp IT/nghiệp vụ để điều khoản phản ánh rủi ro kỹ thuật thực tế.

VIII. Bài test portability trong pilot

Trong pilot, yêu cầu:

1. Xuất master data, transaction, attachment và log mẫu.
2. Đọc export bằng công cụ độc lập.
3. Gọi API cho một workflow thật.
4. Thay đổi một form/danh mục bằng admin nội bộ.
5. Tạo một dashboard hoặc report mới.
6. Mô phỏng thu hồi quyền và người dùng nghỉ việc.
7. Xác định effort nếu chuyển 1.000 record sang hệ thống khác.

Pilot nên kiểm tra khả năng rời đi, không chỉ khả năng bắt đầu.

IX. Dấu hiệu nhà cung cấp đáng tin

• Minh bạch về giới hạn và chi phí.
• Sẵn sàng demo API/export.
• Có tài liệu và roadmap sản phẩm.
• Phân biệt rõ cấu hình chuẩn và customization.
• Chấp nhận khách hàng giữ bản sao dữ liệu.
• Có kế hoạch chuyển giao năng lực nội bộ.
• Hỏi kỹ quy trình, dữ liệu và KPI thay vì chỉ demo chức năng.

Một đối tác tốt không cần giữ khách hàng bằng cách khóa dữ liệu.

X. Nếu đã bị lock-in, bắt đầu giảm rủi ro thế nào?

• Lập inventory dữ liệu, API, customization và hợp đồng.
• Thiết lập export định kỳ.
• Tài liệu hóa mapping và business rule.
• Giảm customization không cần thiết.
• Đào tạo thêm admin nội bộ.
• Tách integration qua layer trung gian nếu phù hợp.
• Đàm phán quyền, giá và transition trước renewal.
• Thử migration một phần dữ liệu.
• Xây roadmap thay thế theo giai đoạn, không “big bang”.

Không nên chờ đến lúc hợp đồng kết thúc mới kiểm tra khả năng lấy dữ liệu.

XI. Những sai lầm thường gặp

• Chỉ đánh giá tính năng và giá năm đầu.
• Tin vào câu “có API” mà không xem tài liệu.
• Không test export trước ký.
• Tùy chỉnh quá sâu theo từng người dùng.
• Không tính chi phí mở rộng và exit.
• Để nhà cung cấp sở hữu mọi connector/tài liệu.
• Không xây đội nội bộ.
• Không review hợp đồng trước renewal.

XII. Câu hỏi thường gặp

Phần mềm SaaS có luôn bị vendor lock-in cao không?

Không. SaaS có phụ thuộc nền tảng nhưng có thể quản trị tốt nếu dữ liệu xuất được, API rõ, cấu hình chuẩn và hợp đồng minh bạch. On-premise tùy chỉnh sâu cũng có thể lock-in cao.

Có nên yêu cầu mã nguồn không?

Không phải lúc nào cũng cần hoặc khả thi. Quan trọng hơn là quyền dữ liệu, API, tài liệu, cấu hình và continuity. Với phát triển riêng critical, có thể xem xét escrow hoặc điều khoản phù hợp.

Export Excel có đủ không?

Thường chưa đủ nếu mất quan hệ, attachment, log, version và metadata. Cần xác định dữ liệu nào phải portable để tiếp tục vận hành hoặc migration.

Chọn công ty lớn có giảm lock-in không?

Không tự động. Quy mô nhà cung cấp không thay thế việc kiểm tra dữ liệu, API, hợp đồng và khả năng chuyển đổi. Cần đánh giá giải pháp cụ thể.