Trong lộ trình làm chủ CBI SIL4, chúng ta đã thấy Năm thứ nhất là năm của những quyết định. Bài này đi sâu vào quyết định đầu tiên và cũng là quyết định khó đảo ngược nhất: một quốc gia mới bắt đầu nên tiếp cận công nghệ CBI theo con đường nào?
Vì sao chọn chiến lược quan trọng hơn chọn sản phẩm?
Khi bắt đầu một chương trình CBI, sự chú ý thường dồn vào việc so sánh sản phẩm: hãng nào, tính năng nào, giá bao nhiêu. Đó là việc cần làm, nhưng nó đến sau. Bởi cùng một sản phẩm, được mua theo hai cách khác nhau, sẽ để lại cho quốc gia mua hai tình thế hoàn toàn khác nhau sau năm năm: một bên chỉ biết vận hành, bên kia hiểu để kiểm soát thay đổi.
Lý do nằm ở chỗ CBI là hệ thống mà an toàn không dừng lại ở ngày nghiệm thu. Mỗi lần mở rộng ga, sửa dữ liệu, thay module hay nâng cấp phần mềm, câu hỏi an toàn lại xuất hiện. Nếu chiến lược ban đầu không tính đến việc ai sẽ trả lời những câu hỏi ấy, quốc gia sẽ bước vào một sự phụ thuộc kéo dài mà không có ai chủ đích chọn nó.
Bốn con đường và điều mỗi con đường thực sự mang lại
Mua trọn gói là con đường nhanh nhất. Nhà cung cấp thiết kế, cấu hình, thử nghiệm và bàn giao một hệ thống chạy được, kèm hồ sơ an toàn của họ. Điều ta nhận được là một ứng dụng vận hành. Điều ta thường không nhận được là năng lực để tự chịu trách nhiệm cho ứng dụng đó, vì phần việc quan trọng nhất diễn ra trong tay người khác.
License và dịch vụ hỗ trợ đi một bước xa hơn: ta có quyền sử dụng sản phẩm và công cụ engineering, đội ngũ của ta tự làm một phần công việc ứng dụng, nhà cung cấp giám sát và hỗ trợ. Đây là con đường mà năng lực tầng ứng dụng bắt đầu thực sự hình thành, nhưng hiểu biết về bên trong nền tảng vẫn còn hạn chế.
Chuyển giao công nghệ nhằm chuyển kiến thức, tài liệu, công cụ và một mức quyền truy cập đã thỏa thuận từ nhà cung cấp sang đội ngũ của ta. Nếu làm đúng, đây là cây cầu từ tầng ứng dụng sang tầng nền tảng. Nếu làm sai, nó chỉ là một chồng tài liệu.
Tự phát triển cho quyền làm chủ cao nhất, nhưng cũng đòi hỏi toàn bộ chuỗi năng lực: safety process, phần cứng, phần mềm an toàn, V&V, Safety Case và đánh giá độc lập. Với một quốc gia chưa có kinh nghiệm CBI, đây gần như không thể là điểm xuất phát, mà là đích đến sau khi đã đi qua các bước khác.
Năm tiêu chí để so sánh
Bốn con đường trên nên được đặt lên cùng một bàn cân với năm tiêu chí, và điều quan trọng là phải cân bằng chứ không chọn theo một tiêu chí duy nhất.
Tiêu chí đầu tiên là thời gian: bao lâu để có một ứng dụng đủ điều kiện được đánh giá. Tiếp theo là chi phí, gồm cả chi phí ban đầu lẫn chi phí vòng đời, vì một hợp đồng rẻ lúc mua có thể đắt về sau nếu mọi thay đổi đều phải trả tiền cho nhà cung cấp. Tiêu chí thứ ba là rủi ro an toàn: mỗi con đường ảnh hưởng thế nào đến khả năng chứng minh an toàn của ứng dụng, đặc biệt khi có sửa đổi. Tiêu chí thứ tư là chủ quyền dữ liệu và mã nguồn: ta được truy cập gì, dữ liệu ứng dụng thuộc về ai, hồ sơ thiết kế nằm ở đâu. Tiêu chí cuối cùng là khả năng bảo trì độc lập: nếu nhà cung cấp không còn hỗ trợ trực tiếp, hệ thống có còn được duy trì an toàn hay không.
Tiêu chí thứ tư và thứ năm hay bị xem nhẹ ở giai đoạn đấu thầu, vì chúng chỉ lộ ra thành vấn đề nhiều năm sau. Nhưng chính chúng quyết định ta đang mua một sản phẩm hay đang xây một năng lực.
Ma trận quyết định trong khung 3 năm
Bảng dưới đây là đánh giá định tính để định hướng, không phải điểm số. Mức độ thực tế còn tùy vào điều khoản cụ thể của từng thỏa thuận.
| Con đường | Tốc độ | Mức làm chủ | Phụ thuộc nhà cung cấp | Phù hợp khung 3 năm |
|---|---|---|---|---|
| Mua trọn gói | Cao | Thấp | Cao | Có ứng dụng nhanh, nhưng ít xây được năng lực |
| License và hỗ trợ | Trung bình | Trung bình | Trung bình đến cao | Tốt cho tầng ứng dụng |
| Chuyển giao công nghệ | Trung bình đến thấp | Trung bình đến cao | Trung bình | Cầu nối sang tầng nền tảng, cần thực chất |
| Tự phát triển | Thấp | Cao | Thấp | Không phù hợp làm điểm xuất phát |
Đọc bảng này, kết luận rõ nhất là không có con đường nào tốt nhất cho mọi mục tiêu. Nếu mục tiêu là một ứng dụng vận hành nhanh, mua trọn gói thắng. Nếu mục tiêu là làm chủ tầng ứng dụng trong 3 năm, license kèm chuyển giao có tiêu chí thực chất là lựa chọn cân bằng hơn. Nếu mục tiêu dài hạn là sản phẩm generic, tự phát triển chỉ nên bắt đầu khi đã có nền từ hai con đường trước.
Chuyển giao hình thức và chuyển giao thực chất
Đây là chỗ nhiều chương trình vấp nhất. Một hợp đồng ghi “chuyển giao công nghệ” chưa nói lên điều gì về việc đội ngũ của ta sẽ thực sự hiểu.
Chuyển giao hình thức có dấu hiệu quen thuộc: nhận được tài liệu nhưng không có người nào trong đội có thể giải thích lý do thiết kế; đào tạo diễn ra dưới dạng lớp học, không gắn với dự án thật; nhà cung cấp vẫn là bên duy nhất thực hiện những việc quan trọng. Chuyển giao thực chất thì khác ở phương thức: đội ngũ của ta làm việc chung trên một ứng dụng thật, có lúc là người làm chính dưới sự giám sát, có lúc bị nhà cung cấp và assessor đặt câu hỏi, và có tiêu chí nghiệm thu kiến thức rõ ràng (chẳng hạn khả năng tự thực hiện và bảo vệ một thay đổi về dữ liệu ứng dụng trước bên đánh giá).
Một phép thử đơn giản: nếu nhà cung cấp rời dự án vào ngày mai, đội ngũ có thể xử lý một thay đổi an toàn nhỏ mà không dừng lại hay không? Nếu câu trả lời là không, thì chuyển giao chưa thực chất.
Những điều khoản hợp đồng cần lưu ý
Mình không phải luật sư, và các điều khoản cụ thể nên được xem xét bởi người có chuyên môn pháp lý và hợp đồng. Nhưng từ góc độ kỹ thuật, có vài chủ đề nên chắc chắn được nêu rõ.
Chủ đề đầu tiên là quyền truy cập và tài liệu: ta được xem mã nguồn, tài liệu thiết kế và bằng chứng an toàn đến mức nào, vì không có những thứ này thì không thể tự phân tích tác động của một thay đổi. Chủ đề thứ hai là phạm vi sửa đổi: theo tinh thần của họ tiêu chuẩn CENELEC, sửa đổi một sản phẩm đã được đánh giá đòi hỏi phân tích tác động an toàn và có thể phải đánh giá lại, nên hợp đồng cần nói rõ ai được sửa gì và ai chịu trách nhiệm cho đánh giá lại. Chủ đề thứ ba là quyền sở hữu và sử dụng application data, vì đây là tài sản mà ta sẽ tạo ra nhiều nhất. Chủ đề thứ tư là đào tạo và nghiệm thu năng lực, gồm cả tiêu chí đo lường, không chỉ số giờ học. Chủ đề cuối cùng là hỗ trợ dài hạn và kịch bản kết thúc quan hệ: điều gì xảy ra với việc bảo trì và cập nhật khi nhà cung cấp ngừng hỗ trợ một phiên bản.
Mô hình kết hợp theo giai đoạn
Nếu gom tất cả lại, một cách tiếp cận hợp lý cho quốc gia mới bắt đầu là đi theo giai đoạn thay vì chọn một con đường cho cả chương trình.
Ở giai đoạn đầu, nên mua hoặc license một sản phẩm đã được đánh giá phù hợp để có nền tảng an toàn, đồng thời ràng buộc chuyển giao thực chất ở tầng ứng dụng. Ở giai đoạn giữa, khi đội ngũ đã chịu trách nhiệm cho một ứng dụng pilot, mở rộng chuyển giao sang các thành phần nền tảng như I/O, giao diện và chẩn đoán. Chỉ ở giai đoạn sau, khi đã có năng lực tầng nền tảng, mới đặt câu hỏi nghiêm túc về việc tự phát triển từng phần của sản phẩm generic.
Ưu điểm của mô hình này là mỗi giai đoạn dựa trên năng lực thật của giai đoạn trước, thay vì dựa vào kỳ vọng. Nó cũng giữ được tính linh hoạt: nếu các chỉ số năng lực (xem lại phần cuối của bài hub) không tiến triển, ta điều chỉnh trước khi cam kết bước tiếp theo.
Kết luận
Chọn chiến lược tiếp cận CBI SIL4 không phải là chọn “mua hay tự làm”. Đó là quyết định ta muốn sở hữu cái gì sau khi hệ thống đã chạy: một ứng dụng, hay khả năng chịu trách nhiệm cho ứng dụng đó. Với quốc gia mới bắt đầu, con đường thực tế thường là một chuỗi các giai đoạn: nền tảng đã được đánh giá, chuyển giao thực chất ở tầng ứng dụng, mở rộng dần sang tầng nền tảng, rồi mới đến sản phẩm generic.
