Mở đầu:
Mô hình Design-Build (DB hay EP) trong lĩnh vực công nghệ thông tin là hình thức giao cho một nhà thầu duy nhất chịu trách nhiệm cả hai phần việc thiết kế và triển khai phần mềm. Khác với mô hình truyền thống phân chia giữa tư vấn thiết kế và nhà thầu triển khai, mô hình EP giúp rút ngắn thời gian, giảm rủi ro và tối ưu hóa khả năng tích hợp giữa thiết kế và thi công.
Nội dung:
Hiện nay, triển khai phần mềm theo mô hình EP (Engineering – Procurement) không phải là phương pháp phổ biến toàn cầu như trong lĩnh vực xây dựng hay công nghiệp nặng. Tuy nhiên, có một số quốc gia và tổ chức, đặc biệt là trong các dự án phần mềm chính phủ, quốc phòng, năng lượng, và công nghiệp lớn, đã triển khai phần mềm theo dạng EP hoặc mở rộng thành EPC/EPCM (thêm phần Construction/Management). Dưới đây là một số nước tiêu biểu áp dụng hoặc từng áp dụng mô hình tương tự.
Mô hình EP trong phần mềm thường chỉ được áp dụng trong dự án quy mô lớn, có nhiều nhà thầu tham gia, cần tách biệt rõ ràng giai đoạn thiết kế – mua sắm – triển khai.
Các nước phát triển (Mỹ, EU) thường không gọi là EP mà dùng các thuật ngữ như "Design & Build", "System Integration contracts", hay "Turnkey Software Projects", nhưng bản chất có thể tương tự EP.
Các quốc gia CÓ triển khai phần mềm theo mô hình EP (Engineering – Procurement):
|
Quốc gia
|
Ghi chú
|
|
Ấn Độ
|
Dùng phổ biến trong các dự án phần mềm chính phủ (Smart City, NIC, CSC) theo mô hình EPC
|
|
Trung Quốc
|
Một số dự án lớn (e-Government, AI quốc gia) áp dụng rõ ràng EP hoặc EPC
|
|
Việt Nam
|
Một số dự án đầu tư công nghệ thông tin theo Nghị định 73/2019/NĐ-CP triển khai theo hướng EPC
|
|
Ả Rập Xê Út
|
Dự án nền tảng dữ liệu, chính phủ số thuê đơn vị theo mô hình EPC
|
|
UAE
|
Triển khai phần mềm trong Smart Dubai và các IOC theo kiểu EPC
|
|
Indonesia
|
Các dự án tích hợp dữ liệu và quản trị công có hợp đồng chia giai đoạn tương tự EP
|
|
Kazakhstan
|
Dự án quản lý tài nguyên số quốc gia theo mô hình EP rõ ràng
|
Các quốc gia triển khai phần mềm theo mô hình TƯƠNG TỰ EP (không gọi là EP nhưng bản chất tương đương):
|
Quốc gia
|
Mô hình tương tự EP
|
|
Hoa Kỳ
|
Turnkey, System Integrator, Agile Acquisition (đặc biệt trong quốc phòng, chính phủ liên bang)
|
|
Canada
|
Design-Build IT systems; outsourcing toàn bộ quy trình từ thiết kế đến triển khai
|
|
Anh (UK)
|
GDS áp dụng mô hình “Digital Service Standard” theo hướng SI (System Integration)
|
|
Đức
|
Hợp đồng tích hợp theo phases: Planung – Beschaffung – Betrieb
|
|
Pháp
|
Dự án lớn về eHealth, eGov có mô hình triển khai phân tách thiết kế và mua sắm
|
|
Singapore
|
Dùng nhiều hình thức Public-Private Partnership + Design-Build
|
|
Nhật Bản
|
Triển khai phần mềm quốc gia theo lộ trình thiết kế – đấu thầu – tích hợp
|
|
Hàn Quốc
|
Áp dụng mô hình phân kỳ kỹ thuật – mua sắm – triển khai cho các hệ thống lớn
|
|
Úc
|
“Build & Operate” trong các dự án số hóa công; không gọi là EP nhưng có tính chất tương tự
|
|
New Zealand
|
Tách riêng giai đoạn thiết kế, xây dựng hệ thống số quốc gia
|
Các quốc gia KHÔNG áp dụng mô hình EP, mà sử dụng mô hình khác hoàn toàn (ưu tiên mô hình linh hoạt, thuê ngoài, phát triển nội bộ hoặc Agile):
|
Quốc gia
|
Mô hình chính áp dụng
|
|
Thụy Điển
|
Agile Development, Continuous Delivery, mô hình thuê ngoài không chia pha EP
|
|
Na Uy
|
Dùng Government as a Platform – không chia pha thiết kế/mua sắm độc lập
|
|
Phần Lan
|
Các mô hình agile, microservices, thiết kế - phát triển gộp trong 1 quy trình
|
|
Thụy Sĩ
|
Ưa chuộng hợp đồng linh hoạt, SaaS/GaaP, không chia giai đoạn EP
|
|
Hà Lan
|
Dùng mô hình hợp tác Agile – không tách rời kỹ thuật và cung ứng
|
|
Đan Mạch
|
Chính phủ điện tử phát triển qua mô hình co-creation, agile với SMEs
|
|
Bỉ, Áo, Tây Ban Nha, Ý
|
Các nước này phần lớn không triển khai mô hình EP cụ thể, thường tích hợp hoặc thuê ngoài toàn bộ giải pháp phần mềm theo mô hình đầu ra (output-based contracts)
|
EP (Engineering – Procurement) phù hợp với các nước có hệ thống hành chính tập trung, nơi nhà nước đầu tư lớn và muốn kiểm soát chặt chẽ quy trình.
Mô hình tương tự EP phổ biến ở các nước có yêu cầu cao về kiểm soát rủi ro, tính minh bạch nhưng vẫn muốn linh hoạt (Turnkey, SI).
Các nước không dùng EP thường theo đuổi tư duy hiện đại hơn: Agile, DevOps, Platform Government hoặc Open Procurement.
2. Quy trình thực hiện dự án phần mềm theo mô hình EP (Engineering – Procurement)
Các quốc gia thường áp dụng quy trình này bao gồm: Ấn Độ, Trung Quốc, Việt Nam, UAE, Indonesia…
Quy trình thực hiện có thể được mô tả trong 5 bước chính sau:
|
Giai đoạn
|
Nội dung công việc
|
Chủ thể chính
|
|
1. Engineering (Thiết kế kỹ thuật)
|
Phân tích yêu cầu, khảo sát hiện trạng, thiết kế hệ thống (kiến trúc phần mềm, sơ đồ nghiệp vụ, bảo mật, hạ tầng...)
|
Tư vấn thiết kế / Cơ quan chuyên môn / Chủ đầu tư
|
|
2. Thẩm định kỹ thuật
|
Cơ quan chức năng phê duyệt thiết kế kỹ thuật, lập kế hoạch đầu tư
|
Cơ quan thẩm định (CNTT/đầu tư công)
|
|
3. Procurement (Mua sắm, đấu thầu)
|
Soạn E-HSMT, tổ chức đấu thầu lựa chọn nhà thầu cung cấp phần mềm/hạ tầng
|
Chủ đầu tư phối hợp tổ chuyên gia đấu thầu
|
|
4. Triển khai (Triển khai giải pháp)
|
Nhà thầu triển khai phần mềm theo thiết kế: phát triển code, cấu hình hệ thống, đào tạo người dùng
|
Nhà thầu chính, đơn vị tư vấn giám sát
|
|
5. Nghiệm thu – Vận hành
|
Nghiệm thu kỹ thuật và tài chính, đưa hệ thống vào vận hành, bảo hành, bảo trì
|
Chủ đầu tư, nhà thầu, đơn vị vận hành
|
Đặc điểm của quy trình này là: Rạch ròi giữa thiết kế và triển khai; đấu thầu nhà thầu cung cấp dựa trên thiết kế đã có và phù hợp với các nước có mô hình đầu tư công hoặc quản lý tập trung.
3. Quy trình thực hiện theo mô hình tương tự EP (Turnkey, System Integration, Design-Build)
Các quốc gia thường áp dụng quy trình này bao gồm: Mỹ, Canada, Anh, Đức, Pháp, Nhật Bản, Singapore…
Quy trình thực hiện có thể được mô tả trong 4 bước có sự lồng ghép như sau:
|
Giai đoạn
|
Nội dung công việc
|
Chủ thể chính
|
|
1. Đề bài và mục tiêu (Requirement Definition)
|
Cơ quan quản lý đưa ra bài toán tổng thể, mục tiêu đầu ra (outcome), không thiết kế chi tiết
|
Cơ quan chính phủ / Chủ đầu tư
|
|
2. Chọn nhà thầu tích hợp tổng thể (System Integrator / Turnkey Contractor)
|
Đấu thầu chọn 1 đơn vị chịu trách nhiệm toàn bộ (thiết kế, phát triển, triển khai)
|
Cơ quan đấu thầu
|
|
3. Thiết kế + Phát triển (Design + Build)
|
Nhà thầu tự thiết kế chi tiết và phát triển phần mềm theo mục tiêu đề bài
|
Nhà thầu tích hợp
|
|
4. Triển khai – Đào tạo – Bảo trì
|
Nhà thầu triển khai toàn diện, đào tạo người dùng, chuyển giao hệ thống
|
Nhà thầu & bên giám sát
|
Đặc điểm của quy trình triển khai này là: Thiết kế và triển khai gộp lại, thường chỉ có một nhà thầu chịu trách nhiệm tổng thể; Đề cao kết quả đầu ra hơn là cấu phần kỹ thuật chi tiết; Phù hợp với quốc gia có mô hình quản lý linh hoạt hoặc muốn tiết kiệm thời gian điều phối.
So sánh 2 quy trình này cho ta thấy như sau:
|
Tiêu chí
|
EP (tách biệt)
|
Mô hình tương tự EP (Turnkey, SI)
|
|
Thiết kế và triển khai
|
Tách riêng, thiết kế trước
|
Gộp vào một nhà thầu tổng thể
|
|
Cách chọn nhà thầu
|
Đấu thầu kỹ thuật riêng, sau đó mới đấu thầu triển khai
|
Đấu thầu 1 lần, giao toàn bộ cho nhà thầu
|
|
Phù hợp với
|
Chính phủ kiểm soát chặt quy trình
|
Chính phủ linh hoạt, ưu tiên đầu ra
|
|
Ưu điểm
|
Kiểm soát chất lượng từng bước
|
Nhanh, gọn, tiết kiệm thời gian phối hợp
|
|
Nhược điểm
|
Phức tạp, thời gian kéo dài
|
Khó kiểm soát khi nhà thầu yếu hoặc thiếu minh bạch
|
4. Những lợi ích của mô hình EP và vai trò của chủ đầu tư
Những lợi ích của việc triển khai dự án phần mềm theo mô hình EP có thể được chỉ ra như sau: Đội ngũ tích hợp sớm (designer + builder) tham gia từ giai đoạn đầu, giảm tình trạng đổ lỗi sai sót giữa các bên; Thiết kế tối ưu theo ngân sách ("design-to-budget") thực thi bởi đội thiết kế – xây dựng giúp giảm chi phí đơn vị; Hoạt động song song giữa thiết kế và thi công giúp rút ngắn tiến trình thay vì phải đợi hoàn thành thiết kế xong mới thực hiện thi công.
Theo kinh nghiệm của các quốc gia triển khai mô hình EP thì chủ đầu tư không bắt buộc hoặc pháp luật không có quy định cứng rằng chủ đầu tư phải nghiệm thu thiết kế chi tiết của phần mềm trước khi nhà thầu bắt tay vào triển khai thi công. Tuy nhiên, chủ đầu tư thường có kiểm tra hoặc xác nhận thiết kế trước khi đưa vào thi công. Điều này phụ thuộc vào các yếu tố sau:
|
Yếu tố
|
Mức độ nghiệm thu
|
|
Quy định trong hợp đồng
|
Nếu hợp đồng quy định rõ “thiết kế phải được chủ đầu tư phê duyệt trước khi triển khai”, thì bắt buộc.
|
|
Mức độ rủi ro của dự án
|
Dự án càng phức tạp, càng cần bước phê duyệt thiết kế trước thi công phần mềm
|
|
Mức độ tin tưởng nhà thầu
|
Với nhà thầu uy tín, có thể chỉ yêu cầu “xác nhận kỹ thuật” thay vì “phê duyệt chi tiết”
|
|
Thời gian dự án
|
Các dự án theo mô hình progressive delivery có thể vừa thiết kế – vừa phát triển theo giai đoạn, không chờ nghiệm thu hoàn toàn trước thi công
|
Các hình thức phổ biến thay cho việc nghiệm thu cứng là:
|
Cách gọi
|
Mô tả
|
|
Design Review
|
Chủ đầu tư xem xét hồ sơ thiết kế để góp ý (không phải phê duyệt theo luật)
|
|
Preliminary Approval
|
Chủ đầu tư xác nhận thiết kế sơ bộ để nhà thầu triển khai tiếp
|
|
Stage-Gate
|
Kiểm tra định kỳ (checkpoint) trước khi chuyển sang giai đoạn tiếp theo
|
|
Concurrent Engineering
|
Thiết kế và triển khai song song – mỗi phần thiết kế được kiểm tra theo module
|
Một số ví dụ thực tế như:
|
Quốc gia
|
Cách thực hiện
|
|
Mỹ (Design‑Build)
|
DBIA khuyến nghị sử dụng “design review milestone”, không yêu cầu nghiệm thu chính thức
|
|
Anh (System Integrator)
|
Chính phủ kiểm tra qua GDS Assessment, không phê duyệt chi tiết thiết kế từng phần
|
|
Singapore (PSSCOC Design–Build)
|
Chủ đầu tư có thể yêu cầu phê duyệt thiết kế sơ bộ (preliminary drawings), nhưng không phải hồ sơ kỹ thuật 100% như trong EPC
|
|
Hàn Quốc (SI Projects)
|
Các dự án lớn thường có “kiểm duyệt giải pháp tổng thể” nhưng không bắt buộc nghiệm thu thiết kế toàn bộ trước thi công
|
Một câu hỏi cũng được đặt ra trong việc kiểm soát chất lượng thiết kế - thi công là nếu như không chờ nghiệm thu hoàn toàn trước thi công thì căn cứ nào để chủ đầu tư thanh toán cho nhà thầu?
Nghiên cứu kinh nghiệm của các quốc gia cho thấy rằng trong mô hình này, thanh toán được thực hiện theo milestone (mốc triển khai dự án) hoặc deliverable (sản phẩm bàn giao cụ thể), chứ không chờ hoàn tất toàn bộ thiết kế kỹ thuật. Các căn cứ chính để thanh toán cho nhà thầu bao gồm:
|
Căn cứ thanh toán
|
Mô tả cụ thể
|
Tài liệu đối chiếu
|
|
✅ Deliverable-based Payment
|
Thanh toán theo từng phần sản phẩm cụ thể được bàn giao (module, phiên bản beta, thiết kế sơ bộ…)
|
Danh mục deliverables được quy định trong hợp đồng
|
|
✅ Milestone-based Payment
|
Thanh toán theo các mốc tiến độ đạt được (ví dụ: hoàn thành thiết kế sơ bộ, triển khai bản demo, kiểm thử UAT xong...)
|
Kế hoạch tiến độ có xác nhận từ chủ đầu tư
|
|
✅ Time & Material (T&M)
|
Trả theo thời gian thực tế + tài nguyên sử dụng (nhân sự, giờ công, thiết bị…) – thường dùng trong giai đoạn thiết kế linh hoạt
|
Nhật ký công việc, bảng công log, báo cáo công việc định kỳ
|
|
✅ Agile Sprint-based Payment
|
Trả tiền theo từng Sprint (2–4 tuần), khi nhà thầu hoàn thành backlog đã cam kết
|
Biên bản xác nhận Sprint completion từ Product Owner
|
|
✅ Target Cost / Cost + Fee
|
Trả theo chi phí thực tế cộng với phí quản lý/lợi nhuận, có thể áp dụng giới hạn trần (cap)
|
Hóa đơn chi phí kèm báo cáo tài chính kiểm tra
|
Một số ví dụ về thanh toán theo từng giai đoạn:
|
Giai đoạn
|
Nội dung công việc
|
Tỷ lệ thanh toán
|
|
Giai đoạn 1
|
Hoàn thành thiết kế kiến trúc hệ thống sơ bộ + bản mô hình dữ liệu
|
15%
|
|
Giai đoạn 2
|
Phát triển và bàn giao module chức năng 1 + kiểm thử UAT
|
25%
|
|
Giai đoạn 3
|
Phát triển module 2 + tích hợp hệ thống
|
20%
|
|
Giai đoạn 4
|
Hoàn tất triển khai + đào tạo người dùng
|
30%
|
|
Giai đoạn 5
|
Kết thúc bảo hành 3 tháng
|
10%
|
5. Một số khuyến nghị cho Việt Nam
Tại Việt Nam, các quy định tại Nghị định số 73/2019/NĐ-CP năm 2019 và Nghị định số 82/2024/NĐ-CP năm 2024 của Chính phủ về quản lý đầu tư dự án phần mềm đã có quy định khuyến khích các dự án phần mềm nội bộ triển khai theo hình thức gói thầu hỗn hợp (EP, EC, EPC). Tuy nhiên, chưa có các quy định mạnh mẽ, cụ thể.
Trong tháng 6, 7/2025, Bộ Khoa học và Công nghệ đã tổ chức nghiên cứu, xây dựng Nghị quyết của Chính phủ về tháo gỡ khó khăn, vướng mắc trong triển khai các dự án, nhiệm vụ ứng dụng công nghệ thông tin sử dụng nguồn vốn ngân sách nhà nước. Theo báo cáo của Bộ Khoa học và Công nghệ thì quy trình thiết kế dự án đầu tư ứng dụng công nghệ thông tin được quy định tại Nghị định số 73/2029/NĐ-CP (được sửa đổi, bổ sung bởi Nghị định số 82/2024/NĐ-CP) gồm các công việc cơ bản sau: Chủ đầu tư thuê nhà thầu A tổ chức lập Báo cáo nghiên cứu khả thi, trong đó gồm Thiết kế cơ sở; sau khi Báo cáo nghiên cứu khả thi được cấp có thẩm quyền phê duyệt, Chủ đầu tư thuê nhà thầu B lập Thiết kế chi tiết và dự toán; Chủ đầu tư phê duyệt thiết kế chi tiết và dự toán, sau đó chủ đầu tư thuê nhà thầu C triển khai xây dựng phần mềm (thi công).
Tuy nhiên, theo ý kiến của các chuyên gia thuộc Hội đồng Tư vấn quốc gia: Quy trình hiện tại quy định phải xây dựng thiết kế chi tiết phần mềm rồi mới đấu thầu, ký hợp đồng, sau đó nghiệm thu quyết toán dựa trên thiết kế chi tiết ban đầu là không phù hợp với thực tế phát triển sản phẩm công nghệ thông tin vì hoạt động xây dựng phần mềm khó xác định chính xác yêu cầu của người sử dụng từ đầu, nên việc nhà thầu sau khi ký hợp đồng phải làm lại việc phân tích thiết kế và thay đổi để đáp ứng yêu cầu người sử dụng là cần thiết. Các nhà thầu có phương pháp, năng lực khác nhau nên cấu thành chi tiết dự toán tổng mức đầu tư khác nhau ở các thành phần, khó có cùng căn cứ so sánh.
Hơn nữa, đối với dự án phần mềm nội bộ, việc thiết kế và triển khai (coding) một phần mềm do 02 nhà thầu tách biệt chưa phù hợp với đặc thù của dự án phần mềm là đòi hỏi tính linh hoạt trong thiết kế để đáp ứng với thực tế triển khai là thiết kế phần mềm thay đổi liên tục trong quá trình triển khai. Do đó cần có quy định đột phá để triển khai các dự án phần mềm nội bộ.
Trên cơ sở ý kiến của các cơ quan, doanh nghiệp, chuyên gia nêu trên và tham khảo kinh nghiệm quốc tế, Bộ Khoa học và Công nghệ đã đề xuất phương án quy định như sau và được Chính phủ phê duyệt tại Nghị quyết số 04/2025/NQ-CP ngày 20/8/2025:
Đối với dự án xây dựng, phát triển, nâng cấp, mở rộng phần mềm nội bộ và dự án có hạng mục đầu tư xây dựng, phát triển, nâng cấp, mở rộng phần mềm nội bộ (trường hợp thiết kế 02 bước), quy định quy trình thực hiện là “một nhà thầu thiết kế và thi công” tại giai đoạn thực hiện đầu tư, trình tự thực hiện như sau:
+ Trong giai đoạn chuẩn bị đầu tư: Chủ đầu tư tổ chức lập Báo cáo nghiên cứu khả thi, trong đó gồm Thiết kế cơ sở (Nhà thầu A).
+ Trong giai đoạn thực hiện đầu tư: Sau khi Báo cáo nghiên cứu khả thi được cấp có thẩm quyền phê duyệt, nhà thầu triển khai tổ chức lập Thiết kế chi tiết và thực hiện (thi công) (Nhà thầu B).
+ Chủ đầu tư không phải tổ chức thẩm định, phê duyệt thiết kế chi tiết do nhà thầu triển khai lập, điều chỉnh, bổ sung;
+ Việc lập thiết kế chi tiết và triển khai được thực hiện đối với toàn bộ hoặc từng hạng mục công việc của dự án trên cơ sở thống nhất giữa chủ đầu tư và nhà thầu triển khai nhưng phải bảo đảm sự thống nhất, đồng bộ về nội dung và các cơ sở tính toán giữa các giai đoạn và với thiết kế cơ sở được phê duyệt.
+ Mẫu hồ sơ mời thầu đối với gói thầu thiết kế, cung cấp hàng hóa, xây dựng, phát triển, nâng cấp, mở rộng phần mềm nội bộ áp dụng theo mẫu hồ sơ mời thầu gói thầu EP của pháp luật về đấu thầu.
Quy định này nhận được sự ủng hộ của các doanh nghiệp công nghệ số và chủ đầu tư vì cắt giảm được khá nhiều thủ tục trong quá trình triển khai dự án phần mềm nội bộ; giúp đẩy nhanh tiến độ thực hiện và phù hợp với thông lệ quốc tế, phù hợp với tính chất đặc thù của sản phẩm phần mềm./.
Trịnh Thị Trang
Tài liệu tham khảo:
1. https://www.performanceservices.com/resources/10-reasons-why-the-design-build-delivery-method-works/?
2. https://dbia.org/wp-content/uploads/2019/01/DBIA-Data-Sourcebook-1.pdf?
3. https://dbia.org/?
4. https://dbia.org/best-practices/?
5. https://staging.dbia.org/wp-content/uploads/2018/05/Primer-Progressive-Design-Build.pdf?