Phần A — Hồ sơ hành chính, pháp lý & năng lực

A1. Đơn dự thầu

ĐƠN DỰ THẦU

Kính gửi: [[CẦN ĐIỀN: Bên mời thầu]]

Sau khi nghiên cứu hồ sơ mời thầu (HSMT) gói thầu [[CẦN ĐIỀN: Tên gói thầu]] ([[CẦN ĐIỀN — chưa có văn bản HSMT chính thức tại thời điểm lập hồ sơ này]]) và trên cơ sở nghiên cứu hồ sơ năng lực và đề xuất kỹ thuật/tài chính trình bày tại các Phần B, C của hồ sơ này, Nhà thầu [[CẦN ĐIỀN: Tên công ty dự thầu]] cam kết dự thầu với các nội dung sau:

Nhà thầu cam kết thực hiện đầy đủ nội dung nêu tại hồ sơ dự thầu này (Phần B, Phần C) nếu được lựa chọn là nhà thầu trúng thầu, và tuân thủ các điều kiện nêu tại Phần A của hồ sơ này.

[[CẦN ĐIỀN: đính kèm bản đơn dự thầu đã ký/đóng dấu theo đúng mẫu HSMT khi có văn bản mời thầu chính thức]]

Nguồn giá: bid/estimate.computed.json → cost.laborTotal, cost.vat, cost.total (đồng nhất với Phần C5).

A2. Bảo đảm dự thầu

Bắt buộc: Theo HSMT (chưa xác định — không có văn bản HSMT).

[[CẦN ĐIỀN: đính kèm thư bảo lãnh ngân hàng / chứng từ đặt cọc bảo đảm dự thầu theo hình thức và mức bảo đảm HSMT quy định]] — trạng thái công ty: companyDocs.bidSecurity: missing.

A3. Giấy đăng ký kinh doanh & giấy ủy quyền ký hồ sơ

[[CẦN ĐIỀN: đính kèm bản sao Giấy chứng nhận đăng ký doanh nghiệp và giấy ủy quyền ký hồ sơ]] — trạng thái công ty: companyDocs.businessLicense: missing.

A4. Báo cáo tài chính

Bắt buộc: Theo HSMT (chưa xác định).

[[CẦN ĐIỀN: đính kèm báo cáo tài chính 2–3 năm gần nhất đã kiểm toán/xác nhận thuế]] — trạng thái công ty: companyDocs.financialReports: missing.

A5. Kinh nghiệm — hợp đồng tương tự

[[CẦN ĐIỀN: đính kèm danh sách hợp đồng tương tự (ưu tiên marketplace/TMĐT hoặc hệ thống có thanh toán trực tuyến quy mô lớn) kèm biên bản nghiệm thu/xác nhận]] — trạng thái công ty: companyDocs.similarContracts: missing.

A6. Nhân sự chủ chốt

[[CẦN ĐIỀN: đính kèm CV, bằng cấp/chứng chỉ và cam kết tham gia dự án của nhân sự chủ chốt — tối thiểu PM, SA, chuyên gia bảo mật, khớp bảng vai trò tại B8.2]] — trạng thái công ty: companyDocs.keyPersonnelCVs: missing; keyPersonnel hiện chưa khai báo tên nào.

A7. Chứng chỉ tổ chức

Nhà thầu hiện có sẵn các chứng chỉ tổ chức sau (companyDocs): ISO 9001 (available), ISO/IEC 27001 (available), CMMI (available).

[[CẦN ĐIỀN: đính kèm bản sao chứng chỉ còn hiệu lực (đã xác minh ngày hết hạn) cho cả 3 chứng chỉ trên]]

A8. Thỏa thuận liên danh / danh sách thầu phụ

Không áp dụng — Nhà thầu dự thầu độc lập (bid-config.consortium: []). Mục này sẽ được cập nhật nếu phát sinh liên danh trước khi nộp hồ sơ.

A9. Cam kết

[[CẦN ĐIỀN: đính kèm mẫu cam kết bảo mật, không vi phạm pháp luật, không xung đột lợi ích, tuân thủ pháp luật]]

A10. Tài liệu khác theo yêu cầu riêng của HSMT

Không áp dụng tại thời điểm lập hồ sơ này — chưa có văn bản HSMT. [[CẦN ĐIỀN: rà soát lại ngay khi nhận HSMT chính thức]]

Phần B — Đề xuất kỹ thuật

B1. Hiểu biết về yêu cầu & bài toán

B1.1 Bối cảnh và bài toán cốt lõi

Bên mời thầu cần xây dựng một sàn thương mại điện tử marketplace đa người bán (multi-vendor), nơi nhiều người bán độc lập cùng kinh doanh trên một nền tảng dùng chung. Bài toán là xây dựng hạ tầng giao dịch ba bên — khách hàng, người bán, và sàn với vai trò trung gian thu hoa hồng — trong đó dòng tiền, tồn kho và trách nhiệm giao hàng phải được phân định rõ ràng, kể cả khi một giỏ hàng chứa sản phẩm của nhiều người bán khác nhau.

• Một đơn hàng có thể phải tách thành nhiều đơn con theo từng người bán, mỗi đơn con có vòng đời xử lý/giao hàng riêng nhưng khách hàng vẫn trải nghiệm như một lần đặt hàng duy nhất.
• Dòng tiền đi qua cơ chế giữ tiền có kỳ hạn (payout hold) trước khi chi trả cho người bán, bảo vệ quyền lợi đổi trả của khách hàng mà không làm chậm trễ quá mức thu nhập người bán.
• Người bán phải được xác minh danh tính (KYC) trước khi giao dịch; sàn chịu trách nhiệm quản lý chất lượng catalog và xử lý tranh chấp giữa khách hàng và người bán thứ ba.
• Hệ thống phải chịu tải lớn ngay từ đầu vì các đợt flash sale tạo đột biến truy cập/đặt hàng.

B1.2 Mục tiêu

• Cho phép khách hàng (có tài khoản hoặc khách vãng lai) tìm kiếm, so sánh và mua sản phẩm từ nhiều người bán, thanh toán một lần cho giỏ hàng đa người bán.
• Cho phép người bán thứ ba tự đăng ký, được xác minh, tự quản lý sản phẩm/tồn kho/đơn hàng và nhận thanh toán định kỳ minh bạch.
• Cho phép Bên mời thầu thu hoa hồng theo cấu hình linh hoạt theo ngành hàng, kiểm soát chất lượng người bán, danh mục, khuyến mãi và xử lý tranh chấp.
• Đảm bảo nền tảng vận hành ổn định, an toàn dữ liệu và có khả năng mở rộng ngay từ ngày vận hành đầu tiên.

B1.3 Phạm vi

Phạm vi giải pháp bao gồm toàn bộ chuỗi nghiệp vụ lõi của sàn marketplace: danh mục & tìm kiếm đa người bán; giỏ hàng/checkout tách đơn theo người bán; thanh toán đa phương thức; quản lý vòng đời đơn hàng/đổi trả/khiếu nại; đăng ký/xác minh/quản trị người bán; cấu hình & chi trả hoa hồng định kỳ; khuyến mãi, đánh giá, chương trình thành viên; giao diện đa ngôn ngữ/đa tiền tệ; tích hợp đơn vị vận chuyển. Chi tiết tại B2.

B1.4 Đối tượng sử dụng chính

B1.5 Chỉ số thành công (định hướng KPI)

• Thời gian phản hồi nhanh cho duyệt/tìm kiếm và thanh toán, kể cả cao điểm khuyến mãi.
• Tỷ lệ sẵn sàng dịch vụ cao cho luồng giao dịch cốt lõi.
• Thời gian xử lý payout đúng chu kỳ cam kết, cân bằng bảo vệ khách hàng và dòng tiền người bán.
• Tỷ lệ xử lý khiếu nại/tranh chấp đúng quy trình, có dấu vết kiểm toán đầy đủ.

Nguồn: SAD §1.1, §1.2, §1.4.

B2. Phạm vi & Danh mục chức năng/tính năng

Cột "Giai đoạn": MVP (bàn giao đầu tiên), Tùy chọn (linh hoạt theo quyết định khởi động), GĐ2 (mở rộng sau go-live). Mã CN-nn dùng xuyên suốt hồ sơ; đối chiếu chi tiết tại Phụ lục D1.

Nhóm 1 — Khách vãng lai & Khách hàng

Nhóm 2 — Người bán (Seller)

Nhóm 3 — Quản trị & vận hành sàn

B2.2 Ngoài phạm vi (đề xuất giai đoạn 2)

Tiếp thị liên kết; bán hàng thuê bao định kỳ; ứng dụng di động gốc (giai đoạn đầu qua web responsive); tự động hoá hoá đơn điện tử cho người bán; hoa hồng theo hạng người bán; SSO doanh nghiệp.

Nguồn: SAD §1.1, §1.2, §2.1.

B2.1. Ma trận đáp ứng yêu cầu

Ghi chú phạm vi áp dụng: không có HSMT/RFP tại thời điểm lập hồ sơ. Bảng dưới là ma trận tự đối chiếu (giải pháp tự nhất quán với chính yêu cầu SAD đề ra), làm cơ sở để Bên chấm thầu xác minh mức độ đáp ứng.

Yêu cầu chức năng

Yêu cầu phi chức năng

Tổng hợp

Toàn bộ 27 yêu cầu chức năng và 8 nhóm yêu cầu phi chức năng đã được giải pháp đề xuất đáp ứng ở mức thiết kế chi tiết.

Nguồn: SAD §2.1, §2.2.

B3. Giải pháp kỹ thuật & sơ đồ hoạt động

B3.1 Kiến trúc tổng thể

Lựa chọn kiến trúc: mô hình dịch vụ hoá theo lĩnh vực nghiệp vụ (domain-oriented services) kết hợp xử lý theo sự kiện (event-driven) cho các quy trình nhiều bước sau khi đặt hàng. Mỗi dịch vụ sở hữu dữ liệu riêng, giao tiếp trực tiếp (đồng bộ) cho thao tác cần phản hồi ngay, và qua hàng đợi sự kiện (bất đồng bộ) cho xử lý phía sau.

flowchart TB
    subgraph L1["Người dùng"]
        Client["Ứng dụng khách hàng / người bán / quản trị\n(giao diện web đáp ứng)"]
    end
    Edge["Tầng biên: CDN + WAF + Cân bằng tải"]
    Gateway["Cổng API / lớp tổng hợp yêu cầu\n(xác thực, giới hạn tần suất truy cập)"]
    subgraph L2["Các dịch vụ nghiệp vụ cốt lõi (tự động mở rộng theo tải)"]
        Identity["Định danh & Truy cập"]
        Catalog["Danh mục & Tìm kiếm sản phẩm"]
        CartOrder["Giỏ hàng & Đơn hàng"]
        Payment["Thanh toán"]
        Seller["Quản lý người bán & KYC"]
        Commission["Hoa hồng & Chi trả (Payout)"]
        Support["Khuyến mãi · Đánh giá · Thông báo"]
        Shipping["Điều phối vận chuyển"]
    end
    EventBus["Hàng đợi sự kiện\n(xử lý bất đồng bộ sau đặt hàng)"]
    DataLayer[("Dữ liệu: CSDL theo từng dịch vụ,\nbộ nhớ đệm, kho lưu trữ tệp")]
    External["Đối tác bên ngoài:\nCổng thanh toán · Đơn vị vận chuyển ·\nNgân hàng · Email/SMS · Đăng nhập mạng xã hội"]
    Client --> Edge --> Gateway
    Gateway --> Identity
    Gateway --> Catalog
    Gateway --> CartOrder
    Gateway --> Payment
    Gateway --> Seller
    Gateway --> Shipping
    CartOrder <--> EventBus
    Payment <--> EventBus
    EventBus --> Commission
    EventBus --> Support
    EventBus --> Shipping
    Identity --> DataLayer
    Catalog --> DataLayer
    CartOrder --> DataLayer
    Payment --> DataLayer
    Seller --> DataLayer
    Commission --> DataLayer
    Payment --> External
    Shipping --> External
    Commission --> External
    Identity --> External

Giải thích: yêu cầu người dùng đi qua lớp bảo vệ/cân bằng tải trước khi đến đúng dịch vụ xử lý; các bước không cần chờ ngay (hoa hồng, thông báo, lịch chi trả) xử lý ngầm qua hàng đợi sự kiện.

B3.2 Sơ đồ ca sử dụng tổng quan

flowchart LR
    Guest((Khách vãng lai))
    Customer((Khách hàng))
    Seller((Người bán))
    Admin((Quản trị viên sàn))
    Ops((Vận hành kho))
    CSR((Chăm sóc khách hàng))
    UC1[Tìm kiếm & mua sắm]
    UC2[Thanh toán & theo dõi đơn hàng]
    UC3[Đổi trả & khiếu nại]
    UC4[Quản lý gian hàng & tồn kho]
    UC5[Xem báo cáo doanh thu/payout]
    UC6[Quản trị người bán & danh mục]
    UC7[Cấu hình hoa hồng & khuyến mãi]
    UC8[Xử lý tranh chấp]
    UC9[Đóng gói & giao hàng]
    Guest --> UC1
    Guest --> UC2
    Customer --> UC1
    Customer --> UC2
    Customer --> UC3
    Seller --> UC4
    Seller --> UC5
    Admin --> UC6
    Admin --> UC7
    Admin --> UC8
    Ops --> UC9
    CSR --> UC3
    CSR --> UC8

B3.3 Luồng nghiệp vụ chính

Luồng 1 — Đặt hàng & thanh toán đa người bán

sequenceDiagram
    actor KH as Khách hàng
    participant App as Ứng dụng mua sắm
    participant Order as Dịch vụ Giỏ hàng & Đơn hàng
    participant Catalog as Dịch vụ Danh mục
    participant Pay as Dịch vụ Thanh toán
    participant Gateway as Cổng thanh toán
    participant Event as Hàng đợi sự kiện
    KH->>App: Xác nhận giỏ hàng, chọn phương thức thanh toán
    App->>Order: Yêu cầu đặt hàng
    Order->>Catalog: Kiểm tra & giữ tồn kho từng sản phẩm
    alt Đủ tồn kho
        Catalog-->>Order: Xác nhận giữ hàng thành công
        Order->>Order: Tách đơn hàng theo từng người bán
        Order-->>App: Tạo đơn hàng thành công
        App->>Pay: Khởi tạo giao dịch thanh toán
        Pay->>Gateway: Chuyển hướng thanh toán
        Gateway-->>KH: Khách hàng hoàn tất thanh toán
        Gateway->>Pay: Xác nhận kết quả giao dịch
        Pay->>Pay: Kiểm tra tính hợp lệ, chống trùng lặp giao dịch
        Pay->>Event: Phát sự kiện "Thanh toán thành công"
        Event->>Order: Cập nhật trạng thái đơn hàng
        Event->>Catalog: Trừ tồn kho chính thức
    else Không đủ tồn kho
        Catalog-->>Order: Từ chối — thiếu hàng
        Order-->>App: Thông báo cần điều chỉnh giỏ hàng
    end

Luồng 2 — Xử lý đơn & vận chuyển

sequenceDiagram
    actor NB as Người bán
    actor Ops as Nhân viên kho
    participant Order as Dịch vụ Giỏ hàng & Đơn hàng
    participant Ship as Dịch vụ Điều phối vận chuyển
    participant Carrier as Đơn vị vận chuyển
    NB->>Order: Xác nhận đơn hàng của gian hàng
    Order->>Ship: Yêu cầu tạo lô hàng
    Ops->>Ship: Xác nhận đóng gói hoàn tất
    Ship->>Carrier: Tạo vận đơn
    alt Tạo vận đơn thành công
        Carrier-->>Ship: Trả mã vận đơn
        Ship->>Order: Cập nhật trạng thái "đang giao"
        Carrier->>Ship: Cập nhật giao hàng thành công
        Ship->>Order: Cập nhật trạng thái "đã giao"
    else Đơn vị vận chuyển không phản hồi/lỗi
        Carrier-->>Ship: Không tạo được vận đơn
        Ship->>Ship: Tự động thử đơn vị vận chuyển thay thế
        opt Đơn vị thay thế cũng lỗi
            Ship->>Ops: Đưa vào hàng đợi xử lý thủ công
        end
    end

Luồng 3 — Đổi trả & xử lý tranh chấp

sequenceDiagram
    actor KH as Khách hàng
    participant Order as Dịch vụ Giỏ hàng & Đơn hàng
    actor CSR as Chăm sóc khách hàng
    participant Pay as Dịch vụ Thanh toán
    participant Commission as Dịch vụ Hoa hồng & Payout
    KH->>Order: Gửi yêu cầu đổi trả cho đơn đã giao
    Order->>Commission: Tạm giữ khoản thanh toán liên quan
    Order->>CSR: Chuyển yêu cầu cần xử lý
    CSR->>CSR: Điều tra lịch sử đơn hàng
    alt Quyết định hoàn tiền
        CSR->>Pay: Yêu cầu hoàn tiền cho khách hàng
        CSR->>Commission: Loại khoản hoa hồng liên quan khỏi kỳ chi trả
    else Từ chối yêu cầu
        CSR->>Order: Từ chối, giữ nguyên trạng thái đơn hàng
        CSR->>Commission: Giải phóng khoản tạm giữ theo lịch bình thường
    end
    Order->>KH: Thông báo kết quả xử lý

Luồng 4 — Đăng ký & xác minh người bán (KYC)

sequenceDiagram
    actor NB as Người bán
    participant Seller as Dịch vụ Quản lý người bán
    actor AD as Quản trị viên
    participant Store as Kho lưu trữ hồ sơ
    NB->>Seller: Đăng ký gian hàng
    NB->>Seller: Nộp hồ sơ pháp lý
    Seller->>Store: Lưu trữ hồ sơ (mã hoá)
    AD->>Seller: Yêu cầu xem hồ sơ cần duyệt
    Seller->>Store: Sinh đường dẫn xem tạm thời, có hạn sử dụng ngắn
    AD->>AD: Đối chiếu thủ công từng hồ sơ
    alt Toàn bộ hồ sơ hợp lệ
        Seller->>Seller: Kích hoạt gian hàng
    else Có hồ sơ không hợp lệ
        Seller->>Seller: Từ chối, cho phép nộp lại
    end
    Seller->>NB: Thông báo kết quả xét duyệt

B3.4 Sơ đồ triển khai & môi trường

flowchart LR
    Dev["Môi trường Phát triển (Dev)\nDữ liệu giả lập"] --> QA1["Kiểm thử nội bộ"]
    QA1 --> Staging["Môi trường Kiểm thử nghiệm thu (Staging)\nDữ liệu ẩn danh hoá, quy mô gần Production"]
    Staging --> QA2["Kiểm thử tích hợp, hiệu năng, bảo mật, UAT"]
    QA2 --> Approval["Phê duyệt phát hành"]
    Approval --> Prod["Môi trường Vận hành chính thức (Production)\nDữ liệu thật, tự động mở rộng theo tải"]

B3.5 Mô hình dữ liệu khái niệm

erDiagram
    CUSTOMER ||--o{ ORDER : "đặt"
    SELLER ||--o{ PRODUCT : "đăng bán"
    PRODUCT ||--o{ PRODUCT_VARIANT : "có biến thể"
    ORDER ||--o{ ORDER_SELLER : "tách theo người bán"
    ORDER_SELLER }o--|| SELLER : "thuộc về"
    ORDER ||--o| PAYMENT : "được thanh toán bởi"
    ORDER_SELLER ||--o| COMMISSION_TRANSACTION : "phát sinh hoa hồng"
    ORDER_SELLER ||--o| SHIPMENT : "được giao bởi"
    ORDER_SELLER ||--o{ RETURN_REQUEST : "có thể có"
    RETURN_REQUEST ||--o| DISPUTE : "leo thang thành"
    SELLER ||--o{ PAYOUT : "nhận chi trả"
    COMMISSION_TRANSACTION }o--|| PAYOUT : "được gộp vào"

B3.6 Tích hợp bên ngoài

Nguồn: SAD §2.3, §3.1–§3.4, §5.1, §6.1.

B4. Tech stack & hạ tầng đề xuất

B4.1 Bảng công nghệ đề xuất

B4.2 Sizing hạ tầng theo môi trường

Nguồn: SAD §3.1–§3.3.

B5. Bảo mật & tuân thủ

B5.1 Cam kết chung

Áp dụng đầy đủ nguyên tắc OWASP ASVS/OWASP Top 10 trong toàn bộ vòng đời phát triển, phù hợp hệ thống xử lý thanh toán/PII quy mô lớn. Rà soát chéo độc lập trước khi triển khai.

B5.2 Xác thực & phân quyền

• Băm mật khẩu hiện đại (bcrypt/argon2id), chống dò mật khẩu tự động, khoá tài khoản theo mức rủi ro.
• MFA bắt buộc cho quản trị viên, khuyến khích cho người bán.
• OAuth 2.0/OpenID Connect xác thực đầy đủ phía server, chống CSRF, không tự động gộp tài khoản trùng email.
• RBAC kết hợp kiểm soát quyền sở hữu dữ liệu (chống IDOR) tại mọi điểm truy cập API.
• Khu vực quản trị giới hạn truy cập mạng (VPN/whitelist IP).

B5.3 Bảo vệ dữ liệu

• Mã hoá at-rest cho toàn bộ DB/lưu trữ tệp; dữ liệu nhạy cảm mã hoá bổ sung tầng ứng dụng.
• TLS bắt buộc cho mọi kết nối, kể cả nội bộ giữa các dịch vụ.
• Quản lý bí mật/khoá tập trung, không lưu trong mã nguồn/cấu hình.
• Che dữ liệu nhạy cảm (masking) trước khi ghi log.
• Hồ sơ KYC chỉ xem qua đường dẫn tạm thời, thời hạn ngắn.
• Quy trình xử lý quyền của chủ thể dữ liệu cá nhân (xoá/sửa/truy xuất), có xác thực danh tính người yêu cầu.
• Audit trail cho mọi hành động quản trị nhạy cảm.

B5.4 Phòng chống rủi ro bảo mật ứng dụng

Kiểm soát truy cập chặt ở cấp dữ liệu; truy vấn tham số hoá chống injection; xác thực chữ ký webhook chống replay; không tin dữ liệu giá/tiền từ trình duyệt; chuẩn hoá thông báo lỗi; quét thư viện/mã nguồn định kỳ.

B5.5 Kiểm thử bảo mật

• SAST/SCA tự động mọi lần build.
• Penetration test định kỳ hàng năm, ưu tiên thanh toán/KYC/webhook.
• Kiểm thử riêng: chống dò mật khẩu, giả mạo OAuth, replay giao dịch, rò rỉ PII qua log.
• DPIA trước khi vận hành chính thức.

B5.6 Tuân thủ pháp lý

Quy trình xử lý sự cố bảo mật: phân loại mức độ, cách ly phạm vi, thông báo theo thời hạn hợp đồng, đánh giá nguyên nhân gốc rễ. SLA chi tiết tại B9.

Nguồn: SAD §2.2 NFR-04/05, §8.1–§8.4.

B6. Phương pháp luận triển khai & quản lý dự án

B6.1–B6.2 Mô hình & vòng đời phát triển

Mô hình Agile/Scrum kết hợp (hybrid), bàn giao theo đợt (increment). Mỗi đợt: xác nhận yêu cầu → thiết kế/lập trình song song → kiểm thử nhiều lớp → demo/nghiệm thu → điều chỉnh → phát hành Dev→Staging→Production.

B6.3 Quản lý yêu cầu & thay đổi (Change Request)

Yêu cầu nghiệp vụ quản lý tập trung, truy vết tới thiết kế/kịch bản kiểm thử (xem B2.1). Mọi thay đổi phạm vi qua quy trình Change Request: mô tả → đánh giá tác động → phê duyệt song phương trước khi thực hiện.

B6.4 Chiến lược kiểm thử

B6.5 Quản lý cấu hình & CI/CD

Version control tập trung → kiểm thử tự động → SAST/SCA → Dev tự động → Staging sau kiểm thử nội bộ → phê duyệt thủ công bắt buộc trước Production, tách vai trò phê duyệt/triển khai. Rủi ro cao (thanh toán, hoa hồng): rollout tăng dần + rollback nhanh.

B6.6 Quản lý rủi ro dự án

B6.7–B6.8 Báo cáo, họp & tiêu chí nghiệm thu

Họp đồng bộ nội bộ ngắn kỳ; báo cáo tiến độ định kỳ; demo cuối mỗi đợt; họp rà soát rủi ro khi phát sinh. Đợt/hạng mục đạt nghiệm thu khi: (a) qua hệ thống/UAT theo kịch bản; (b) không lỗi nghiêm trọng ảnh hưởng giao dịch cốt lõi; (c) đáp ứng NFR liên quan; (d) tài liệu bàn giao đầy đủ (B9).

Nguồn: SAD §9.1–§9.5; bid-config.methodology.

B7. Kế hoạch triển khai

B7.1 Tổng quan

Tổng thời lượng 7 tháng, tổng nỗ lực 53,02 người-tháng (gồm dự phòng rủi ro), mô hình Agile/Scrum hybrid bàn giao theo đợt, đội ngũ lõi tương đương 9 vị trí đồng thời, đỉnh điểm 10 đầu người (9,5 FTE/tháng). Chưa có ngày khởi động/hạn chót chính thức (projectStartDate, projectDeadline để trống) — kế hoạch dưới là lộ trình cơ sở (baseline) neo theo ngày minh hoạ.

B7.2 Phân bổ theo đợt (Giai đoạn Phát triển)

B7.3 Gantt & mốc bàn giao

Ngày neo minh hoạ D0 = 2026-10-01 — sẽ dịch chuyển theo ngày khởi động chính thức khi có, số tháng/MM giữ nguyên.

gantt
    dateFormat YYYY-MM-DD
    title Kế hoạch triển khai (minh hoạ D0 = 2026-10-01)
    section Khởi động và Chuẩn bị
    Kick-off song phương              :milestone, m0, 2026-10-01, 0d
    Thiết lập môi trường & PMO         :p1, 2026-10-01, 15d
    section Phân tích và Thiết kế chi tiết
    Phân tích nghiệp vụ & thiết kế chi tiết :p2, after p1, 30d
    Chốt thiết kế (design sign-off)    :milestone, m1, 2026-11-15, 0d
    section Phát triển
    Đợt 1 - Nền tảng & tài khoản khách hàng :d1, after p2, 30d
    Demo đợt 1                        :milestone, m2, 2026-12-15, 0d
    Đợt 2 - Checkout, thanh toán       :d2, after d1, 31d
    Demo đợt 2                        :milestone, m3, 2027-01-15, 0d
    Đợt 3 - Seller/Admin/Tích hợp còn lại :d3, after d2, 29d
    Hoàn tất phát triển (code-complete) :milestone, m4, 2027-02-13, 0d
    section Kiểm thử hệ thống, hiệu năng, bảo mật
    Kiểm thử hệ thống/hiệu năng/bảo mật :p4, after d3, 30d
    section UAT và Đào tạo
    UAT cùng Bên mời thầu & đào tạo    :p5, after p4, 30d
    Nghiệm thu UAT                     :milestone, m6, 2027-04-14, 0d
    section Go-live và Hỗ trợ ổn định
    Go-live & hypercare                :p6, after p5, 15d
    Nghiệm thu tổng thể & go-live chính thức :milestone, m7, 2027-04-29, 0d
    section Bảo hành
    Bảo hành 12 tháng                 :warranty, 2027-04-29, 365d

B7.4 Phụ thuộc & đường tới hạn

• Đợt 1 phụ thuộc chốt kiến trúc/event backbone (WBS-03) và bảo mật nền tảng (WBS-05) — hạng mục phức tạp/rủi ro cao nhất, nằm trên đường tới hạn.
• Đợt 2 phụ thuộc Đợt 1 hoàn tất giỏ hàng; phụ thuộc tài khoản sandbox VNPay/Momo đúng hạn từ Bên mời thầu.
• Kiểm thử hệ thống phụ thuộc toàn bộ 3 đợt code-complete.
• UAT phụ thuộc đại diện nghiệp vụ Bên mời thầu tham gia đúng lịch.
• Go-live phụ thuộc kết quả UAT đạt và phê duyệt song phương.

B7.5 Deadline dự án

Chưa có hạn chót ấn định — kế hoạch cơ sở (7 tháng, 9 vị trí đồng thời, đỉnh 10 đầu người) áp dụng khi không có ràng buộc bên ngoài. Nếu có hạn chót, phương án tăng tốc (không đổi tổng 53,02 MM): tăng nhân sự song song ở nút thắt BE/FE/QA; thu hẹp phạm vi đợt đầu (lùi các mục Tùy chọn); chạy song song có kiểm soát kiểm thử/phát triển. Rủi ro: tăng chi phí phối hợp, giảm thời gian ổn định trước UAT.

B8. Tổ chức nhân sự

B8.1 Sơ đồ tổ chức

flowchart TB
    SC["Ban chỉ đạo dự án\n(đại diện Nhà thầu + đại diện Bên mời thầu)"]
    PM["Quản lý dự án (PM)\nphía Nhà thầu"]
    POC["Đầu mối nghiệp vụ\nBên mời thầu"]
    SC --> PM
    SC -.-> POC
    PM --> BA["Nhóm Phân tích nghiệp vụ (BA)"]
    PM --> SA["Kiến trúc sư giải pháp (SA)"]
    PM --> UIUX["Nhóm Thiết kế UI/UX"]
    PM --> BE["Nhóm Phát triển Backend (BE)"]
    PM --> FE["Nhóm Phát triển Frontend (FE)"]
    PM --> QA["Nhóm Kiểm thử (QA)"]
    PM --> DEVOPS["Nhóm Hạ tầng & DevOps"]
    BA <--> POC
    QA <--> POC
    PM <--> POC

B8.2 Bảng vai trò & trách nhiệm

B8.3 Staffing plan theo tháng (FTE)

Đỉnh điểm 9,5 FTE/tháng ở M3–M4, tương đương 10 đầu người. Từ M6, nhân sự phát triển giảm dần khi chuyển trọng tâm sang kiểm thử/UAT.

B8.4 RACI

(R = Thực hiện, A = Phê duyệt, C = Tham vấn, I = Được thông báo.)

B8.5 Họp/báo cáo/escalation

Đồng bộ nội bộ ngắn kỳ; báo cáo tiến độ tuần/2 tuần; demo cuối mỗi đợt (M2, M3, M4); họp Ban chỉ đạo [[CẦN ĐIỀN: tần suất chính thức]]; escalation sự cố nghiêm trọng theo B9.4.

Nguồn: computed (timeline, staffing) + bid-config.methodology, warrantyMonths.

B9. Đào tạo — Chuyển giao — Bảo hành — Hỗ trợ

B9.1 Đào tạo

B9.2 Tài liệu bàn giao

• Đặc tả kiến trúc & thiết kế hệ thống (kiến trúc, mô hình dữ liệu, API).
• Hướng dẫn sử dụng theo từng nhóm người dùng.
• Hướng dẫn vận hành hạ tầng, backup/restore, runbook sự cố.
• Mã nguồn & hướng dẫn triển khai/cấu hình môi trường.
• Nhật ký kiểm thử (UAT, hiệu năng, bảo mật) theo phạm vi đã bàn giao.

B9.3 Bảo hành

Thời hạn 12 tháng kể từ ngày nghiệm thu tổng thể. Khắc phục miễn phí lỗi thuộc phạm vi đã bàn giao (không gồm yêu cầu thay đổi/bổ sung — qua Change Request B6.3).

B9.4 Cam kết hỗ trợ theo mức độ sự cố

B9.5 Hỗ trợ sau bảo hành

Sau 12 tháng, sẵn sàng dịch vụ hỗ trợ vận hành/bảo trì dài hạn theo thoả thuận riêng: giám sát/xử lý sự cố, vá bảo mật định kỳ, nâng cấp nền tảng, tư vấn mở rộng tính năng (xem B2.2).

Nguồn: SAD §9.4, §9.5; bid-config.warrantyMonths.

B10. Giả định — Ràng buộc — Loại trừ — Trách nhiệm Bên mời thầu

B10.1 Giả định

• Nền tảng đầu là web responsive; mobile app native ở giai đoạn mở rộng.
• Thanh toán/vận chuyển theo danh sách đã thống nhất; đối tác khác cần thông báo sớm.
• Kỳ giữ tiền, hạng thành viên, công thức hoàn tiền xác nhận tại kick-off; kiến trúc đã hỗ trợ cấu hình linh hoạt.
• Hạ tầng cloud; không có hệ thống cũ cần tích hợp/di trú (greenfield).
• Không yêu cầu SSO doanh nghiệp ở phạm vi hiện tại.

B10.2 Ràng buộc

• Tuân thủ pháp luật TMĐT/bảo vệ dữ liệu cá nhân hiện hành — khuyến nghị xác minh hiệu lực tại thời điểm ký hợp đồng/go-live.
• Kiến trúc đáp ứng quy mô lớn ngay từ đầu, không mở rộng dần.
• Không ràng buộc công nghệ cụ thể — đề xuất theo thông lệ tốt (B4).

B10.3 Loại trừ

• Các hạng mục B2.2 (affiliate, subscription, mobile app, hoá đơn điện tử tự động, hoa hồng theo hạng, SSO doanh nghiệp).
• Chi phí hạ tầng/license bên thứ ba/phí giao dịch cổng thanh toán/vận chuyển — ngoài giá dịch vụ triển khai (xem Phần C).
• Thủ tục cấp phép/đăng ký hành chính nhà nước — trách nhiệm Bên mời thầu; Nhà thầu chỉ hỗ trợ kỹ thuật.

B10.4 Trách nhiệm của Bên mời thầu

• Xác nhận số liệu nghiệp vụ còn để ngỏ tại kick-off.
• Cung cấp hợp đồng/tài khoản đối tác bên ngoài hoặc uỷ quyền Nhà thầu đăng ký.
• Bố trí đại diện nghiệp vụ tham gia xác nhận yêu cầu/UAT/nghiệm thu (B6, B7).
• Thực hiện thủ tục pháp lý/hành chính thuộc thẩm quyền song song triển khai kỹ thuật.
• Xác nhận chính sách bảo mật/quy trình nội bộ riêng (nếu có) trước go-live.

Nguồn: SAD §1.4, §1.5; bid/00-bid-brief.md §0.1, §0.5.

Phần C — Đề xuất tài chính

C1. Cơ sở & phương pháp ước lượng

C1.1 Phương pháp chính — WBS bottom-up

43 hạng mục công việc, mỗi hạng mục ánh xạ tới một chức năng/nhóm chức năng hoặc hạng mục kỹ thuật xuyên suốt (môi trường, kiến trúc, bảo mật, hiệu năng, 7 tích hợp bên thứ ba, PMO, đào tạo, hypercare). Effort (MD, 8 giờ/ngày) theo từng vai trò (PM, BA, SA, UIUX, BE, FE, QA, DEVOPS), gắn complexity (S/M/L/XL) và risk (low/medium/high). Quy đổi 1 MM = 21 MD.

PM/BA phân bổ itemized theo từng hạng mục (không phụ phí % — overheadMD = 0). Dự phòng rủi ro: thấp 10%, trung bình 20%, cao 35% trên MD cơ sở từng hạng mục.

Giả định năng suất: QA ≈ 25–40% effort BE/FE mỗi hạng mục; đội có kinh nghiệm trung bình–cao microservices/event-driven trên AWS; dự án greenfield (không di trú dữ liệu); effort i18n chỉ tính kỹ thuật, không gồm dịch thuật.

Loại trừ khỏi giá: phí license/giao dịch bên thứ ba (xem C4, pass-through); mobile app native; affiliate/subscription/hoá đơn điện tử tự động/SSO doanh nghiệp; chi phí dịch thuật nội dung.

C1.2 Phương pháp đối chiếu — Use Case Points (UCP)

Đối chiếu độ lệch: MM cơ sở WBS (chưa dự phòng) = 42,48 MM so với 27,5 MM theo UCP — lệch 54,47%, vượt ngưỡng cảnh báo 25%.

Giải thích lựa chọn WBS: UCP tính theo số actor/use case tổng quát, trong khi phạm vi thực tế có mật độ hạng mục kỹ thuật xuyên suốt cao hơn (event-driven/database-per-service, 7 tích hợp độc lập, bảo mật XL/rủi ro cao, yêu cầu hiệu năng quy mô lớn) — được phản ánh trực tiếp trong WBS nhưng không tách biệt rõ trong UCP. Do đó C2–C5 dùng WBS bottom-up làm cơ sở chính thức; UCP chỉ đối chiếu tính hợp lý.

C2. Bảng effort theo hạng mục × vai trò

Đơn vị: MD. Cột vai trò chỉ hiển thị khi tham gia; ô trống = không tham gia.

Nhóm Xuyên suốt

Nhóm Khách hàng

Nhóm Merchant

Nhóm Admin

Bảng tổng hợp effort theo vai trò

Tổng nỗ lực dự thầu: 1.113,5 MD, tương đương 53,02 MM.

C3. Đơn giá & chi phí nhân công

Toàn bộ 8 vai trò đều đã có đơn giá xác định — không có placeholder đơn giá.

C4. Chi phí khác

Tổng chi phí khác hiện tại: 0 VNĐ — phản ánh trạng thái chưa có đơn giá, không phải kết luận miễn phí.

C5. Tổng giá dự thầu

Ghi chú bắt buộc: giá tạm tính — chưa gồm 8 hạng mục C4 (chưa có báo giá). Sẽ cập nhật khi định giá xong.

Tùy chọn: bid-config.options hiện chưa cấu hình hạng mục nào.

Mô hình giá: trọn gói (fixed) — chi phí khác (C4) là pass-through/định kỳ tách biệt.

C6. Điều khoản thanh toán & hiệu lực giá

C6.1 Mốc thanh toán

Tổng tỷ lệ các mốc phải bằng 100% giá trị hợp đồng nhân công (C5); tỷ lệ cụ thể [[CẦN ĐIỀN]].

C6.2 Điều kiện thanh toán

• Thanh toán bằng VNĐ, không quy đổi tỷ giá.
• Thời hạn thanh toán sau xuất hoá đơn: [[CẦN ĐIỀN]].
• VAT 10% cộng thêm theo quy định hiện hành — cần xác minh hiệu lực tại thời điểm ký hợp đồng.
• Chi phí C4 theo bản chất một lần/định kỳ đã nêu; đơn giá và điều khoản riêng [[CẦN ĐIỀN]].

C6.3 Hiệu lực báo giá

Hiệu lực 90 ngày kể từ hạn nộp HSDT. Sau thời hạn, nếu chưa ký hợp đồng, giá có thể điều chỉnh theo biến động chi phí.

C6.4 Thay đổi phạm vi

Yêu cầu bổ sung/thay đổi ngoài phạm vi Phần B qua Change Request (B6.3/B7.4); chi phí phát sinh ước lượng theo cùng phương pháp/đơn giá C1–C3, không tính vào tổng giá trọn gói C5.

C7. Biểu giá theo mẫu HSMT

Không có HSMT/RFP làm cơ sở cho gói thầu này. Do đó HSMT không quy định mẫu biểu giá riêng — bảng giá chính thức là bảng tại C5. Khi có mẫu HSMT bắt buộc, C7 sẽ được dựng lại theo đúng cột/định dạng của mẫu đó.

Phần D — Phụ lục

D1. Danh mục chức năng chi tiết

Mục duy nhất ngoài B2.1 trình bày rõ mối liên hệ 1:1 giữa CN và mã yêu cầu gốc, phục vụ kiểm tra chéo nội bộ và truy vết (xem D4).

Nguồn: B2 (CN-nn), bid/01-compliance-matrix.md (FR-nn), estimate.json (sources từng WBS).

D2. Bộ sơ đồ

D3. Ước lượng chi tiết

D3.1 Tham số Use Case Points

Use case: 4 simple, 13 average, 4 complex → UUCW = 210.

UCP = (25+210) × 1,13 × 0,87 = 231,03 → × 20 giờ/UCP = 4.620,6 giờ → 577,58 MD → 27,5 MM.

D3.2 Bảng hạng mục WBS đầy đủ (rationale & giả định)

Nguồn: estimate.json (rationale/sources/assumptions), estimate.computed.json (items/totals/ucp).

D4. Ma trận truy vết yêu cầu → chức năng → mốc bàn giao → hạng mục giá

Cột "Hạng mục giá" tham chiếu WBS đóng góp effort tại C2 (mô hình giá trọn gói — không tách giá riêng từng WBS).

Yêu cầu chức năng

Yêu cầu phi chức năng

Nguồn: tổng hợp từ B2.1, B7.2, B7.3, C2/D3 — không phát sinh số liệu mới.

D5. Thuật ngữ