Tiêu chí lựa chọn hệ thống phân tích nghiên cứu

Mức độ phù hợp với mục tiêu và quy trình nghiên cứu

Tiêu chí đầu tiên không phải là “hệ thống có những tính năng gì” mà là “hệ thống giải quyết được những công việc nghiên cứu nào”. Một nền tảng có năng lực kỹ thuật mạnh nhưng không tương thích với câu hỏi nghiên cứu, nguồn dữ liệu hoặc cách tổ chức đang vận hành sẽ tạo ra khoảng cách giữa khả năng của công nghệ và giá trị thực tế.

Việc đánh giá nên bắt đầu từ các tình huống sử dụng cụ thể. Chẳng hạn, một tổ chức cần theo dõi hiệu suất nghiên cứu sẽ quan tâm nhiều đến dữ liệu công bố, trích dẫn, tác giả, đơn vị và các chỉ số liên quan. Trong khi đó, một nhóm phân tích dữ liệu nghiên cứu thực nghiệm có thể ưu tiên khả năng nhập dữ liệu thô, làm sạch, xử lý, chạy mô hình và lưu lại lịch sử phân tích. Hai trường hợp đều có thể được gọi là phân tích nghiên cứu nhưng yêu cầu hệ thống rất khác nhau.

Điểm quan trọng là phải đánh giá độ phù hợp theo quy trình đầu-cuối, thay vì xác nhận từng chức năng riêng lẻ. Một hệ thống có thể nhập dữ liệu tốt nhưng không hỗ trợ kiểm soát phiên bản, hoặc phân tích mạnh nhưng khó xuất kết quả sang hệ thống báo cáo. Những đứt gãy như vậy làm tăng thao tác thủ công, nguy cơ sai lệch và chi phí vận hành.

Vì thế, yêu cầu nghiệp vụ nên được chuyển thành các tiêu chí nghiệm thu có thể kiểm chứng. Tư duy này cũng tương thích với ISO/IEC 25010:2023: chất lượng không chỉ là tập hợp thuộc tính chung mà phải được đánh giá đối với yêu cầu và bối cảnh sử dụng xác định.

Chất lượng dữ liệu và khả năng truy xuất nguồn gốc

Kết quả phân tích chỉ đáng tin cậy khi dữ liệu đầu vào đủ đáng tin cậy. Vì vậy, một trong những tiêu chí lựa chọn hệ thống phân tích nghiên cứu quan trọng nhất là khả năng kiểm soát dữ liệu từ lúc được tiếp nhận cho tới khi trở thành kết quả phân tích.

Hệ thống cần giúp người sử dụng biết dữ liệu đến từ đâu, được cập nhật khi nào, đã trải qua những phép biến đổi nào và các trường dữ liệu có ý nghĩa gì. Nếu một chỉ số thay đổi nhưng người dùng không thể truy ngược về nguồn hoặc quy tắc xử lý, việc kiểm tra kết quả sẽ rất khó khăn. Vấn đề này đặc biệt quan trọng khi dữ liệu nghiên cứu được tổng hợp từ nhiều kho, nhiều nhóm hoặc nhiều hệ thống khác nhau.

Trong hạ tầng nghiên cứu, khả năng tái sử dụng dữ liệu còn phụ thuộc mạnh vào metadata và cách các thực thể được liên kết. Các nguyên tắc FAIR đặt trọng tâm vào việc làm cho tài sản số có thể tìm thấy, truy cập, tương tác và tái sử dụng. DataCite cũng nhấn mạnh rằng metadata nhất quán, quan hệ chuẩn hóa và các định danh bền vững giúp kết nối công trình, con người, tổ chức và những thực thể nghiên cứu khác giữa nhiều hệ thống.

Do đó, không nên chỉ kiểm tra xem hệ thống “có nhập được dữ liệu” hay không. Cần xem sâu hơn cách hệ thống xử lý metadata, định danh, dữ liệu thiếu, bản ghi trùng lặp, lịch sử thay đổi và provenance. Đây là cơ chế quyết định liệu kết quả phân tích có thể được kiểm chứng và sử dụng lại hay chỉ tồn tại như một đầu ra khó truy nguyên.

Năng lực phân tích phải đi cùng tính minh bạch và khả năng tái lập

Một hệ thống phân tích nghiên cứu cần có năng lực phân tích phù hợp với loại câu hỏi mà người dùng thực sự đặt ra. Tuy nhiên, “nhiều thuật toán hơn” không đồng nghĩa với “phân tích tốt hơn”. Giá trị của hệ thống nằm ở khả năng tạo kết quả phù hợp, giải thích được và có thể kiểm tra lại.

Khi đánh giá, cần xem xét toàn bộ chuỗi từ chuẩn bị dữ liệu, lựa chọn biến và thiết lập tham số đến thực thi phân tích và xuất kết quả. Nếu hệ thống tự động hóa nhiều bước nhưng không lưu lại cấu hình hoặc logic xử lý, người dùng có thể nhận được một con số mà không biết chính xác nó được hình thành như thế nào. Điều này làm giảm khả năng tái lập — một yêu cầu đặc biệt quan trọng trong môi trường nghiên cứu.

Tính minh bạch cũng cần được đánh giá đối với các chỉ số do hệ thống tính sẵn. Cùng một thuật ngữ như “ảnh hưởng nghiên cứu”, “hiệu suất” hay “mức độ hợp tác” có thể được lượng hóa bằng các công thức khác nhau. Vì vậy, hệ thống nên cho phép xác định rõ nguồn dữ liệu, định nghĩa chỉ số, khoảng thời gian, bộ lọc và phương pháp tính trước khi sử dụng kết quả cho đánh giá hoặc ra quyết định.

ISO/IEC 25010:2023 cung cấp một mô hình gồm chín đặc tính chất lượng để hỗ trợ xác định và đánh giá chất lượng sản phẩm phần mềm. Trong thực tế lựa chọn hệ thống, điều này cho thấy năng lực chức năng chỉ là một phần của chất lượng tổng thể; khả năng vận hành đáng tin cậy, tương tác với người dùng và các thuộc tính chất lượng khác cũng phải được xem xét trong bối cảnh sử dụng cụ thể.

Khả năng tích hợp và tương tác với hệ sinh thái nghiên cứu

Một hệ thống phân tích hiếm khi hoạt động độc lập. Dữ liệu có thể nằm trong kho nghiên cứu, hệ thống quản lý nghiên cứu, cơ sở dữ liệu công bố, nền tảng lưu trữ, công cụ thống kê hoặc các dịch vụ nhận dạng tác giả và tổ chức. Vì vậy, khả năng tích hợp quyết định trực tiếp lượng công việc thủ công cần thực hiện sau khi triển khai.

Cần xem xét cả tương tác kỹ thuật và tương tác ngữ nghĩa. Tương tác kỹ thuật liên quan đến API, định dạng nhập xuất và cơ chế trao đổi dữ liệu. Tương tác ngữ nghĩa sâu hơn: hai hệ thống có thể trao đổi được tệp nhưng vẫn không hiểu dữ liệu giống nhau nếu dùng schema, thuật ngữ hoặc quan hệ khác biệt.

Các nguyên tắc FAIR coi interoperability là một trong bốn trụ cột của quản trị tài sản số. DataCite cũng ghi nhận rằng sự khác biệt về schema và loại quan hệ giữa các hạ tầng nghiên cứu có thể cản trở khả năng tương tác; việc sử dụng metadata chuẩn và kết nối thông qua các persistent identifier giúp giảm vấn đề này.

Khả năng tích hợp cũng liên quan trực tiếp đến rủi ro khóa chặt vào nhà cung cấp. Nếu dữ liệu, cấu hình và kết quả chỉ tồn tại trong định dạng độc quyền mà khó xuất ra, chi phí chuyển đổi hệ thống trong tương lai sẽ tăng. Vì thế, trước khi lựa chọn cần kiểm tra không chỉ những hệ thống mà nền tảng có thể kết nối hôm nay, mà cả khả năng lấy dữ liệu và lịch sử phân tích ra khỏi nền tảng khi nhu cầu thay đổi.

Bảo mật, quyền truy cập và quản trị dữ liệu

Dữ liệu nghiên cứu có thể chứa dữ liệu chưa công bố, thông tin cá nhân, dữ liệu thuộc sở hữu của đối tác hoặc các tập dữ liệu bị giới hạn quyền truy cập. Do đó, bảo mật không nên là tiêu chí kiểm tra sau cùng mà phải được coi là một điều kiện nghiệm thu ngay từ đầu.

Một hệ thống phù hợp cần cho phép kiểm soát ai có quyền xem, sửa, phân tích, xuất hoặc quản trị từng nhóm dữ liệu. Quyền truy cập càng rộng hơn nhu cầu thực tế thì phạm vi rủi ro càng lớn; nhưng nếu kiểm soát quá cứng, quy trình nghiên cứu lại trở nên khó vận hành. Vì vậy, cơ chế phân quyền phải phù hợp với vai trò và cách cộng tác thực tế của tổ chức.

Khả năng ghi log và kiểm toán cũng có giá trị đáng kể. Khi dữ liệu hoặc cấu hình phân tích thay đổi, tổ chức cần có khả năng xác định ai thực hiện, thời điểm nào và hành động gì đã xảy ra. NIST SP 800-53 cung cấp danh mục các biện pháp kiểm soát bảo mật và quyền riêng tư cho hệ thống và tổ chức, đồng thời nhấn mạnh rằng các kiểm soát cần được lựa chọn và điều chỉnh theo rủi ro và yêu cầu của từng tổ chức thay vì áp dụng như một danh sách cố định.

Điều đó cũng có nghĩa là không có một chứng nhận hoặc danh sách tính năng bảo mật đơn lẻ nào tự động chứng minh hệ thống phù hợp. Mức độ bảo vệ cần tương xứng với độ nhạy của dữ liệu, nghĩa vụ của tổ chức và hậu quả nếu xảy ra truy cập trái phép, mất dữ liệu hoặc sử dụng sai mục đích.

Khả năng sử dụng, độ tin cậy vận hành và tổng chi phí sở hữu

Một nền tảng có chức năng chính xác nhưng chỉ một nhóm chuyên gia kỹ thuật có thể sử dụng hiệu quả có thể không phù hợp với tổ chức có nhiều nhóm người dùng khác nhau. Vì thế, khả năng sử dụng cần được đánh giá bằng công việc thực tế: thời gian cần để hoàn thành một phân tích, mức độ đào tạo cần thiết, khả năng phát hiện lỗi và mức độ dễ hiểu của kết quả.

Khả năng vận hành cũng phải được xem xét trong điều kiện dữ liệu tăng lên. Một thử nghiệm trên tập dữ liệu nhỏ chưa đủ để kết luận hệ thống sẽ hoạt động tốt khi số lượng bản ghi, người sử dụng đồng thời hoặc khối lượng công việc tăng mạnh. Những yêu cầu như hiệu năng, khả năng phục hồi sau lỗi và khả năng mở rộng cần được thử nghiệm trên kịch bản gần với tải thực tế thay vì dựa hoàn toàn vào mô tả của nhà cung cấp. ISO/IEC 25010:2023 được thiết kế chính để cung cấp một mô hình tham chiếu cho việc xác định, đo lường và đánh giá các thuộc tính chất lượng của sản phẩm ICT và phần mềm.

Chi phí cũng cần được nhìn theo toàn bộ vòng đời. Giá giấy phép chỉ là một phần; tổ chức còn có thể phải chịu chi phí tích hợp, di chuyển và làm sạch dữ liệu, hạ tầng, đào tạo, quản trị, hỗ trợ, phát triển tùy chỉnh và chuyển đổi khỏi hệ thống trong tương lai. Một nền tảng có giá mua thấp nhưng tạo nhiều thao tác thủ công hoặc phụ thuộc sâu vào dịch vụ độc quyền có thể trở nên đắt hơn khi vận hành dài hạn.

Cách lựa chọn chặt chẽ hơn là biến các tiêu chí quan trọng thành kịch bản thử nghiệm với dữ liệu và người dùng thật trước khi triển khai rộng. Các tiêu chí có thể được gán trọng số theo mục tiêu của tổ chức, nhưng những yêu cầu liên quan đến tính toàn vẹn dữ liệu, quyền truy cập hoặc nghĩa vụ bắt buộc nên được coi là điều kiện đạt hoặc không đạt thay vì dùng điểm cao ở tiêu chí khác để bù trừ.

Một hệ thống phân tích nghiên cứu phù hợp không phải là hệ thống có nhiều tính năng nhất mà là hệ thống đáp ứng được đúng mục tiêu nghiên cứu, đúng dữ liệu, đúng mức độ kiểm chứng và đúng điều kiện vận hành của tổ chức. Sáu nhóm tiêu chí cần được xem xét đồng thời gồm mức độ phù hợp với quy trình nghiên cứu, chất lượng và khả năng truy xuất dữ liệu, năng lực phân tích và tái lập, khả năng tích hợp, bảo mật và quản trị, cùng khả năng sử dụng và chi phí vòng đời.

Điểm quyết định nằm ở cách đánh giá: thay vì so sánh danh sách tính năng, tổ chức nên chuyển nhu cầu thành yêu cầu có thể đo hoặc kiểm thử, sau đó dùng dữ liệu, quy trình và kịch bản thực tế để nghiệm thu. Các mô hình chất lượng như ISO/IEC 25010, nguyên tắc FAIR, thực hành metadata của DataCite và các khung kiểm soát bảo mật của NIST có thể đóng vai trò tham chiếu cho từng nhóm yêu cầu tương ứng.