Lộ trình triển khai hệ thống CSDL khoa học và công nghệ: từ khảo sát đến go-live
Lộ trình triển khai hệ thống CSDL khoa học và công nghệ gồm 6 giai đoạn: khảo sát và ký kết, thiết kế giải pháp, cấu hình và di trú dữ liệu, kiểm thử nghiệm thu (UAT), đào tạo và chuyển đổi (cutover), go-live và hypercare. Với đơn vị quy mô 100–300 nhà khoa học, toàn bộ lộ trình thường kéo dài 8–14 tuần nếu chọn giải pháp mua sẵn có tuỳ biến sâu — so với 9–18 tháng nếu tự xây dựng hệ thống in-house. Bài viết này trình bày chi tiết từng giai đoạn theo góc nhìn quản lý dự án: ai làm gì (RACI), rủi ro cụ thể ở mỗi bước và checklist nghiệm thu trước khi ký biên bản go-live.
Cập nhật: tháng 9/2026 — Biên soạn bởi đội ngũ Scibase, Metis JSC
Lộ trình triển khai CSDL khoa học và công nghệ gồm những giai đoạn nào?
Lộ trình triển khai là chuỗi các bước có mốc bàn giao rõ ràng, đưa hệ thống từ trạng thái "đã ký hợp đồng" sang trạng thái "vận hành chính thức, thay thế hoàn toàn cách quản lý cũ" — hiện thực hoá những lợi ích đã phân tích tại bài tại sao cần xây dựng hệ thống CSDL khoa học và công nghệ. Khác với bài tiêu chí chọn phần mềm CSDL khoa học và công nghệ — bàn về giai đoạn trước khi ký hợp đồng — bài này bắt đầu ngay sau khi đơn vị đã chọn được nhà cung cấp.
Lộ trình triển khai phần mềm là bản kế hoạch có mốc thời gian, vai trò trách nhiệm và tiêu chí nghiệm thu cụ thể cho từng giai đoạn, dùng để theo dõi tiến độ và tránh dự án kéo dài không điểm dừng — tình trạng phổ biến khi đơn vị triển khai theo kiểu "vừa làm vừa tính".
| Giai đoạn | Mục tiêu chính | Thời gian tham khảo |
|---|---|---|
| 1. Khảo sát & ký kết | Chốt phạm vi, ký phụ lục kỹ thuật | 1–2 tuần |
| 2. Thiết kế giải pháp | Lập kế hoạch dự án, phân vai RACI | 1 tuần |
| 3. Cấu hình & di trú dữ liệu | Cấu hình nghiệp vụ, làm sạch và nhập dữ liệu cũ | 2–4 tuần |
| 4. UAT & pilot | Kiểm thử nghiệm thu với nhóm nhỏ | 2–3 tuần |
| 5. Đào tạo & cutover | Đào tạo toàn đơn vị, chuyển đổi chính thức | 1–2 tuần |
| 6. Go-live & hypercare | Vận hành thật, hỗ trợ tăng cường | 2–4 tuần đầu |
Bảng trên là khung tham khảo cho đơn vị quy mô vừa (100–300 nhà khoa học). Phần Timeline tổng thể theo quy mô đơn vị bên dưới có số liệu chi tiết hơn cho từng nhóm quy mô.
Giai đoạn 1: Khảo sát nhu cầu và ký kết phụ lục kỹ thuật
Mục tiêu của giai đoạn này không phải bán hàng lại từ đầu — hợp đồng đã ký — mà là chốt phạm vi kỹ thuật (scope) để tránh tranh cãi "có nằm trong hợp đồng không" ở giữa dự án. Bốn việc bắt buộc:
- Xác nhận danh sách loại công bố và thuộc tính cần quản lý (bài báo, đề tài, sáng chế, sách chuyên khảo...), đối chiếu với cấu trúc dữ liệu hiện có trong Excel của đơn vị.
- Vẽ sơ đồ quy trình xét duyệt hiện hành thành lưu đồ cụ thể — bao nhiêu bước, ai duyệt bước nào — để đội triển khai cấu hình đúng ngay từ đầu, tránh phải sửa lại ở giai đoạn UAT. Tham khảo cách một quy trình xét duyệt đề tài, dự án, công bố khoa học vận hành thực tế để đối chiếu trước khi chốt sơ đồ.
- Chốt phạm vi tích hợp với hệ thống khác của đơn vị (nhân sự, đào tạo, cổng thông tin công khai) nếu có nhu cầu — xác định ngay từ đầu tránh phải bổ sung phụ lục giữa dự án. Xem kiến trúc và luồng dữ liệu cụ thể tại bài tích hợp CSDL khoa học và công nghệ với hệ thống hiện có của đơn vị.
- Ký phụ lục kỹ thuật (Statement of Work) ghi rõ phạm vi cấu hình, số lượng bản ghi dữ liệu cũ cần di trú, mốc thời gian từng giai đoạn — tài liệu này là căn cứ nghiệm thu, khác với hợp đồng thương mại chỉ nói về giá và thời hạn thuê bao. Phần giá, nguồn chi (Quỹ phát triển hoạt động sự nghiệp hay chi thường xuyên) và cách ước tính ROI được phân tích riêng tại bài chi phí đầu tư hệ thống CSDL khoa học và công nghệ.
Sai lầm phổ biến nhất ở giai đoạn này: đơn vị để phòng IT làm việc một mình với nhà cung cấp, không có cán bộ nghiệp vụ quản lý khoa học tham gia — dẫn đến phụ lục kỹ thuật đúng về mặt hệ thống nhưng thiếu quy trình nghiệp vụ thực tế, phải bổ sung giữa chừng.
Giai đoạn 2: Thiết kế giải pháp và phân vai trách nhiệm (RACI)
Trước khi cấu hình, cần thống nhất ai chịu trách nhiệm việc gì giữa ba bên: đơn vị (nghiệp vụ), đơn vị (IT nội bộ) và nhà cung cấp. Thiếu bước này là nguyên nhân phổ biến khiến dự án bị "đá bóng trách nhiệm" khi phát sinh vấn đề.
| Công việc | Nghiệp vụ đơn vị | IT nội bộ đơn vị | Nhà cung cấp |
|---|---|---|---|
| Cung cấp dữ liệu Excel gốc | R | A | C |
| Làm sạch, chuẩn hoá dữ liệu | A | C | R |
| Cấu hình quy trình xét duyệt | A | I | R |
| Cấu hình công thức tính giờ | A | I | R |
| Kiểm thử UAT | R | C | A |
| Đào tạo người dùng cuối | C | I | R |
| Phê duyệt go-live | A | C | I |
R = Responsible (thực hiện), A = Accountable (chịu trách nhiệm cuối), C = Consulted (được hỏi ý kiến), I = Informed (được thông báo).
Theo mô hình RACI tiêu chuẩn trong quản lý dự án, mỗi công việc chỉ nên có đúng một vai trò Accountable — nếu hai bên cùng "chịu trách nhiệm cuối" cho cùng một việc, khi có sai sót sẽ không ai thực sự xử lý.
Ở bước này, đơn vị cũng cần chỉ định một nghiệp vụ lead cố định trong suốt dự án — không đổi người giữa chừng — là đầu mối duy nhất quyết định các câu hỏi nghiệp vụ (ví dụ: hệ số vai trò tác giả tính thế nào, quy trình duyệt có bao nhiêu bước). Thiếu vai trò này, đội triển khai của nhà cung cấp thường phải chờ hỏi ý kiến nhiều người khác nhau với câu trả lời không thống nhất, kéo dài tiến độ đáng kể.
Giai đoạn 3: Cấu hình hệ thống và di trú dữ liệu
Đây là giai đoạn tốn thời gian nhất và cũng là nơi phát sinh rủi ro chất lượng dữ liệu nhiều nhất, chia làm hai luồng song song.
Cấu hình nghiệp vụ
Cấu hình cây tổ chức, loại công bố, luồng xét duyệt theo sơ đồ đã chốt ở giai đoạn 1, và công thức quy đổi giờ nghiên cứu theo quy định nội bộ đơn vị — nếu đơn vị chưa có văn bản quy định rõ ràng, đây là thời điểm bắt buộc phải hoàn thiện trước, tham khảo cấu trúc tại bài xây dựng quy chế nội bộ định mức giờ nghiên cứu khoa học.
Di trú dữ liệu (data migration)
Quy trình 4 bước cho dữ liệu cũ từ Excel hoặc hệ thống cũ:
- Trích xuất (extract) — xuất toàn bộ file Excel hiện có của các khoa/phòng ban về một nơi.
- Làm sạch (cleanse) — chuẩn hoá tên tác giả, tên đơn vị, loại bỏ bản ghi trùng lặp. Đây là bước chiếm nhiều thời gian nhất, thường 40–60% tổng thời gian của giai đoạn 3.
- Ánh xạ (mapping) — gán từng cột Excel vào đúng trường dữ liệu trong hệ thống mới, xử lý riêng các trường hợp không khớp 1-1 (ví dụ một dòng Excel ghi 3 tác giả trong một ô).
- Nạp và đối soát (load & reconcile) — nhập dữ liệu vào hệ thống, sau đó đối chiếu số lượng bản ghi và tổng số công bố với file gốc để phát hiện thất thoát.
Theo Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân, dữ liệu nhà khoa học (họ tên, quá trình đào tạo, đơn vị công tác) là dữ liệu cá nhân — quá trình di trú cần có văn bản uỷ quyền xử lý dữ liệu giữa đơn vị và nhà cung cấp, không chỉ là thao tác kỹ thuật thuần tuý.
Quyết định quan trọng ở giai đoạn này: di trú toàn bộ lịch sử hay chỉ 3–5 năm gần nhất. Di trú toàn bộ tốn thời gian làm sạch hơn nhiều nhưng tránh việc nhà khoa học phải khai báo lại thủ công dữ liệu cũ khi cần cho hồ sơ xét GS/PGS — cân nhắc theo mức độ đầy đủ của dữ liệu Excel hiện có.
Giai đoạn 4: Kiểm thử nghiệm thu (UAT) và chạy pilot
UAT (User Acceptance Testing — kiểm thử nghiệm thu người dùng) là bước nhóm người dùng thực tế của đơn vị (không phải đội kỹ thuật) thử toàn bộ quy trình trên hệ thống đã cấu hình, trước khi mở rộng toàn đơn vị.
Nhóm pilot nên gồm 20–40 người thuộc một khoa hoặc viện, đại diện đủ ba vai trò: nhà khoa học (nhập công bố), cán bộ quản lý đơn vị (duyệt hồ sơ), và một người có vai trò gần với quản trị viên. Kịch bản kiểm thử cần bao phủ:
- Nhập một công bố hoàn chỉnh, đúng loại, đủ minh chứng.
- Chạy toàn bộ luồng xét duyệt từ nộp đến duyệt chính thức.
- Xuất báo cáo tổng hợp giờ nghiên cứu và đối chiếu bằng tay với công thức quy định.
- Thử các tình huống biên: công bố nhiều tác giả nhiều đơn vị, công bố bị trả lại yêu cầu bổ sung.
Chỉ khi nhóm pilot xác nhận bằng văn bản (biên bản UAT có chữ ký) rằng các kịch bản trên chạy đúng, dự án mới nên chuyển sang giai đoạn đào tạo diện rộng. Bỏ qua bước ký biên bản UAT là sai lầm phổ biến — khi phát sinh lỗi ở giai đoạn go-live, không có căn cứ để xác định lỗi phát sinh mới hay đã tồn tại từ trước nhưng chưa được phát hiện.
Giai đoạn 5: Đào tạo diện rộng và chuyển đổi (cutover)
Cutover (chuyển đổi) là thời điểm hệ thống mới chính thức thay thế cách làm cũ. Có hai chiến lược, mỗi chiến lược có rủi ro khác nhau:
| Chiến lược | Cách làm | Rủi ro | Phù hợp khi |
|---|---|---|---|
| Cắt ngay (big bang) | Ngừng Excel, chuyển 100% sang hệ thống mới trong 1 ngày | Nếu có lỗi cấu hình chưa phát hiện ở UAT, ảnh hưởng toàn đơn vị ngay lập tức | Đơn vị nhỏ, quy trình đơn giản, đã UAT kỹ |
| Chạy song song (parallel run) | Duy trì cả Excel và hệ thống mới trong 2–4 tuần, đối chiếu kết quả | Tốn thêm công sức nhập liệu 2 lần trong thời gian ngắn | Đơn vị lớn, quy trình phức tạp, dữ liệu ảnh hưởng trực tiếp báo cáo Bộ |
Phần lớn viện, trường tại Việt Nam nên chọn chạy song song tối đa 1 tháng, không kéo dài hơn — chạy song song quá lâu khiến người dùng có xu hướng quay lại thói quen cũ, làm mất động lực chuyển đổi hoàn toàn.
Đào tạo nên chia theo ba nhóm với nội dung khác nhau, không dùng một buổi đào tạo chung cho tất cả:
- Nhà khoa học — tập trung vào nhập công bố, tra cứu hồ sơ, theo dõi trạng thái xét duyệt.
- Cán bộ quản lý đơn vị — tập trung vào duyệt hồ sơ, tổng hợp báo cáo.
- Quản trị viên hệ thống — tập trung vào cấu hình, phân quyền, xử lý sự cố cơ bản.
Giai đoạn 6: Go-live và giai đoạn hypercare
Go-live là thời điểm hệ thống chính thức vận hành thay thế hoàn toàn cách quản lý cũ. Hypercare (hỗ trợ tăng cường) là 2–4 tuần đầu ngay sau go-live, khi đội triển khai của nhà cung cấp duy trì mức hỗ trợ cao hơn bình thường — phản hồi trong vài giờ thay vì theo SLA tiêu chuẩn — vì đây là giai đoạn phát sinh nhiều câu hỏi và lỗi nhỏ nhất do người dùng chưa quen thao tác thật.
Checklist nghiệm thu trước khi ký biên bản go-live chính thức:
- [ ] Toàn bộ kịch bản UAT đã được ký xác nhận, không còn lỗi mức nghiêm trọng (blocker) chưa xử lý.
- [ ] Dữ liệu di trú đã đối soát số lượng bản ghi khớp với dữ liệu gốc.
- [ ] Toàn bộ người dùng đã hoàn thành đào tạo theo đúng nhóm vai trò.
- [ ] Văn bản quy định chính thức hoá việc sử dụng hệ thống đã được lãnh đạo ký ban hành.
- [ ] Kênh hỗ trợ hypercare (hotline, nhóm chat riêng) đã được thiết lập và thông báo toàn đơn vị.
- [ ] Đã thống nhất KPI đánh giá triển khai thành công (xem phần tiếp theo).
Ba chỉ số nên theo dõi trong giai đoạn hypercare để đánh giá mức độ áp dụng thực tế, không chỉ dựa vào cảm nhận: tỷ lệ nhà khoa học đã đăng nhập ít nhất một lần (mục tiêu trên 80% trong tuần đầu), số lượng công bố mới được nhập qua hệ thống so với cùng kỳ nhập Excel, và thời gian trung bình xử lý một hồ sơ xét duyệt so với quy trình cũ.
Timeline tổng thể theo quy mô đơn vị
Timeline thực tế phụ thuộc nhiều vào số lượng nhà khoa học và độ phức tạp quy trình xét duyệt, không chỉ vào năng lực nhà cung cấp:
| Quy mô đơn vị | Số nhà khoa học | Tổng thời gian tham khảo | Điểm khác biệt chính |
|---|---|---|---|
| Nhỏ | Dưới 100 | 6–8 tuần | Ít dữ liệu lịch sử cần làm sạch, quy trình xét duyệt thường 1–2 cấp |
| Vừa | 100–300 | 8–14 tuần | Cần pilot 1 khoa trước khi mở rộng, quy trình 2–3 cấp duyệt |
| Lớn | Trên 300 | 3–6 tháng | Nhiều đơn vị trực thuộc, cần đào tạo theo nhiều đợt, dữ liệu lịch sử lớn |
So với mốc 9–18 tháng để có một hệ thống build in-house dùng được ổn định — đã phân tích tại bài xây dựng CSDL khoa học in-house hay mua giải pháp có sẵn — lộ trình triển khai giải pháp mua sẵn có tuỳ biến rút ngắn đáng kể nhờ tận dụng cấu hình đã kiểm chứng từ nhiều đơn vị khác thay vì viết mã từ đầu.
Theo khảo sát của Cục Thông tin Khoa học và Công nghệ Quốc gia (2024), hơn 72% đơn vị nghiên cứu tại Việt Nam vẫn quản lý dữ liệu chính bằng Excel — phần lớn trong số này thuộc nhóm quy mô vừa và lớn theo bảng trên, nơi thời gian tổng hợp báo cáo thủ công kéo dài nhiều tuần mỗi kỳ báo cáo Bộ.
Rủi ro thường gặp theo từng giai đoạn và cách phòng tránh
| Giai đoạn | Rủi ro phổ biến | Cách phòng tránh |
|---|---|---|
| Khảo sát & ký kết | Phòng IT quyết định một mình, thiếu nghiệp vụ | Bắt buộc có nghiệp vụ lead tham gia từ buổi đầu tiên |
| Cấu hình & di trú | Dữ liệu Excel quá lộn xộn, làm sạch tốn gấp đôi thời gian dự kiến | Dành riêng 1 tuần đầu chỉ để đánh giá chất lượng dữ liệu trước khi cam kết mốc thời gian |
| UAT & pilot | Bỏ qua ký biên bản UAT, chuyển thẳng sang đào tạo diện rộng | Quy định rõ: không có chữ ký UAT thì không mở đào tạo diện rộng |
| Cutover | Chạy song song quá lâu, người dùng không chịu bỏ Excel | Giới hạn song song tối đa 1 tháng, có văn bản chính thức hoá ngày ngừng dùng Excel |
| Go-live | Không có kênh hỗ trợ riêng, người dùng nản lòng vì chờ phản hồi lâu | Thiết lập kênh hypercare riêng biệt với SLA phản hồi nhanh trong 2–4 tuần đầu |
Tình huống thực tế: đơn vị rút ngắn từ 6 tháng xuống 10 tuần nhờ tách riêng giai đoạn UAT
Một mô hình lặp lại ở một số viện nghiên cứu quy mô vừa: ước tính ban đầu cho toàn bộ dự án là khoảng 6 tháng, nhưng kế hoạch gộp chung giai đoạn cấu hình và UAT thành một bước, không có mốc ký biên bản riêng. Kết quả là đội triển khai vừa cấu hình vừa sửa lỗi phát hiện trong lúc đào tạo thật, khiến lịch đào tạo phải dời ba lần.
Sau khi tách riêng UAT thành giai đoạn độc lập với tiêu chí nghiệm thu rõ ràng — chỉ chuyển sang đào tạo diện rộng khi có chữ ký xác nhận — các đợt triển khai tiếp theo tại đơn vị tương tự rút ngắn còn khoảng 10 tuần cho quy mô 150–200 nhà khoa học. Bài học không nằm ở việc làm nhanh hơn từng bước, mà ở việc không cho phép một giai đoạn bắt đầu khi giai đoạn trước chưa có tiêu chí nghiệm thu rõ ràng.
Câu hỏi thường gặp
Đơn vị có cần thuê tư vấn quản lý dự án riêng ngoài đội triển khai của nhà cung cấp không?
Không bắt buộc với quy mô nhỏ và vừa. Với đơn vị lớn (trên 300 nhà khoa học, nhiều đơn vị trực thuộc), nên có một cán bộ kiêm nhiệm vai trò điều phối dự án phía đơn vị — không nhất thiết thuê ngoài — để làm đầu mối duy nhất giữa các khoa/phòng ban với đội triển khai của nhà cung cấp.
Nếu dữ liệu Excel hiện tại rất lộn xộn, có nên hoãn triển khai để làm sạch trước không?
Không nên hoãn toàn bộ dự án. Nên đưa việc làm sạch dữ liệu vào chính giai đoạn 3 của lộ trình, với thời gian ước tính riêng dựa trên mức độ lộn xộn thực tế — dữ liệu càng lộn xộn, thời gian giai đoạn 3 càng cần kéo dài hơn mức tham khảo trong bảng timeline, không phải lý do trì hoãn cả dự án.
Chạy song song Excel và hệ thống mới bao lâu là hợp lý?
Tối đa 1 tháng. Ngắn hơn 2 tuần có thể chưa đủ để phát hiện hết các trường hợp biên trong dữ liệu thật; dài hơn 1 tháng khiến người dùng có xu hướng ưu tiên công cụ quen thuộc, làm chậm quá trình chuyển đổi hoàn toàn.
Ai nên là người ký biên bản nghiệm thu go-live?
Người có thẩm quyền phê duyệt ngân sách và chịu trách nhiệm vận hành hệ thống lâu dài — thường là lãnh đạo phòng Quản lý khoa học hoặc tương đương — không nên chỉ là cán bộ IT, vì biên bản này xác nhận cả tiêu chí nghiệp vụ, không chỉ tiêu chí kỹ thuật.
Sau go-live bao lâu thì có thể đánh giá dự án triển khai thành công hay chưa?
Nên đánh giá ở hai mốc: cuối giai đoạn hypercare (2–4 tuần sau go-live) để xem tỷ lệ áp dụng ban đầu, và sau một kỳ báo cáo Bộ đầy đủ (thường 6 tháng đến 1 năm) để đánh giá liệu thời gian tổng hợp báo cáo có thực sự rút ngắn như kỳ vọng hay không.
Có thể triển khai đồng thời nhiều đơn vị trực thuộc cùng lúc không?
Không khuyến khích với lần triển khai đầu tiên. Nên chọn 1 đơn vị trực thuộc làm pilot đầy đủ (bao gồm cả go-live thật, không chỉ UAT), rút kinh nghiệm về thời gian và lỗi phát sinh, rồi mới nhân rộng theo đợt cho các đơn vị còn lại — cách này giảm rủi ro so với triển khai đồng loạt ngay từ đầu.
Tóm tắt
- Lộ trình triển khai gồm 6 giai đoạn: khảo sát & ký kết, thiết kế giải pháp, cấu hình & di trú dữ liệu, UAT & pilot, đào tạo & cutover, go-live & hypercare
- Timeline tham khảo: 6–8 tuần (đơn vị dưới 100 người), 8–14 tuần (100–300 người), 3–6 tháng (trên 300 người) — ngắn hơn nhiều so với 9–18 tháng của build in-house
- Phân vai RACI rõ ràng giữa nghiệp vụ đơn vị, IT nội bộ và nhà cung cấp giúp tránh "đá bóng trách nhiệm" khi phát sinh vấn đề
- Không cho phép giai đoạn UAT bị bỏ qua chữ ký nghiệm thu — đây là nguyên nhân phổ biến nhất khiến lịch đào tạo và go-live bị trễ
- Chạy song song (parallel run) tối đa 1 tháng; giai đoạn hypercare 2–4 tuần đầu sau go-live cần kênh hỗ trợ riêng với phản hồi nhanh
- Theo dõi 3 KPI sau go-live: tỷ lệ đăng nhập, số công bố nhập mới qua hệ thống, thời gian xử lý hồ sơ xét duyệt
Về nội dung bài viết
Bài viết được biên soạn bởi đội ngũ Scibase — Metis JSC, dựa trên kinh nghiệm thực tế triển khai hệ thống cơ sở dữ liệu khoa học và công nghệ cho các viện nghiên cứu, trường đại học tại Việt Nam. Khung RACI và các mốc thời gian mang tính tham khảo, cần điều chỉnh theo quy mô và mức độ phức tạp thực tế của từng đơn vị.
Nguồn tham khảo: Cục Thông tin Khoa học và Công nghệ Quốc gia, khảo sát hiện trạng quản lý dữ liệu KH&CN (2024); Khảo sát nội bộ Metis JSC với hơn 20 đơn vị nghiên cứu tại Việt Nam (2024–2025); Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân; mô hình phân vai trách nhiệm RACI theo chuẩn quản lý dự án phổ biến (PMBOK).
Bài viết liên quan
- Từ Excel đến hệ thống CSDL khoa học tập trung — Kinh nghiệm số hoá và những sai lầm cần tránh
- Tiêu chí chọn phần mềm CSDL khoa học và công nghệ: checklist trước khi đầu tư
- Xây dựng CSDL khoa học in-house hay mua giải pháp có sẵn: so sánh chi phí, thời gian, rủi ro
- Phân quyền quản lý dữ liệu khoa học theo cấp
- Tính năng chính của Scibase
- Liên hệ triển khai Scibase