Phụ lục D: Nội dung của RFP CNTT chất lượng
Phần | Phần | Mô tả nội dung |
---|---|---|
1 |
Giới thiệu |
Cung cấp tuyên bố về vấn đề và phải đủ chi tiết để nhà cung cấp nắm bắt được các vấn đề kinh doanh thúc đẩy RFP và các vấn đề kỹ thuật có thể gây ra vấn đề. |
2 |
Hướng dẫn đề xuất và quản lý |
Bao gồm tất cả các yêu cầu hành chính và thông tin mà nhà cung cấp phải tuân thủ để có thể gửi đề xuất được chấp nhận. Phần này bao gồm các quy tắc cơ bản cho việc mua sắm, từ khi nộp RFP cho đến khi trao hợp đồng và phải chứa các loại thông tin sau:
Nếu hướng dẫn không đầy đủ hoặc không rõ ràng, nhà cung cấp có thể bỏ qua các cuộc họp hoặc mốc quan trọng. Một số nhà cung cấp có thể coi việc thiếu hướng dẫn chất lượng là dấu hiệu của nhóm dự án yếu hoặc dự án có xung đột, điều này có thể ảnh hưởng đến các nhà cung cấp lớn trong ngành khiến họ không nộp đề xuất. Việc nhà cung cấp không tuân thủ các yêu cầu hành chính của RFP có thể dẫn đến việc đề xuất bị từ chối. Phần này sẽ trình bày các quy tắc rõ ràng để phản hồi RFP và thông báo cho nhà cung cấp về các hình phạt nếu không tuân thủ các quy tắc này. |
3 |
Định dạng đề xuất |
Cung cấp thông tin chi tiết về cách định dạng và đóng đề xuất cũng như phương tiện lưu trữ cần thiết (ví dụ: bản cứng, đĩa CD, v.v.). Sẽ rất hữu ích nếu có một bảng để hiển thị xem các phần đề xuất khác nhau có được nộp riêng hay không (ví dụ: kỹ thuật từ chi phí, biên tập, v.v.). Phần này không được trùng lặp hoặc xung đột với hướng dẫn đề xuất trong phần 2. |
4 |
Tình hình hiện tại |
Mô tả chính xác bối cảnh tổ chức của cơ quan và môi trường kinh doanh và kỹ thuật hiện tại của dự án để nhà cung cấp có thể đề xuất các giải pháp hiệu quả và chính xác nhằm thích ứng hoặc sửa đổi môi trường đó nhằm đáp ứng các yêu cầu mới. Mô tả về môi trường kinh doanh hiện tại phải bao gồm tất cả người dùng và người thụ hưởng của các dịch vụ và quy trình kinh doanh hiện tại bị ảnh hưởng. Mô tả về môi trường kỹ thuật hiện tại phải là một định nghĩa rõ ràng bao gồm tất cả phần cứng và phần mềm hiện đang được sử dụng, những gì có thể được sử dụng hoặc nên được sử dụng để giải quyết các yêu cầu của dự án, cũng như các giao diện hiện tại với các hệ thống/nền tảng và/hoặc ứng dụng hiện có khác. Giao diện quy trình làm việc và ứng dụng có thể được trình bày bằng hình ảnh. |
5 |
Yêu cầu chức năng và kỹ thuật |
Cung cấp các yêu cầu về chức năng và kỹ thuật cùng đủ thông tin để nhà cung cấp hiểu được các vấn đề và chuẩn bị đề xuất hoàn chỉnh và chắc chắn. Tổng quan này sẽ đề cập đến cả ứng dụng kinh doanh hiện tại và môi trường kỹ thuật (phần cứng, phần mềm, truyền thông). Các cơ quan được khuyến nghị không nên sử dụng các yêu cầu kỹ thuật “phải” và “sẽ” mà hãy cho phép các nhà cung cấp đề xuất cách họ sẽ giải quyết vấn đề như một phần của đề xuất dựa trên giải pháp. Phần yêu cầu kỹ thuật và chức năng bao gồm các câu hỏi mà nhà cung cấp phải trả lời, chẳng hạn như:
Yêu cầu quản lý dự án nêu rõ các điều kiện để quản lý và thực hiện dự án. Phần này sẽ cung cấp cho nhà cung cấp thông tin họ cần để xây dựng kế hoạch dự án, kế hoạch giảm thiểu rủi ro hoặc kế hoạch quản lý khác, tùy theo mức độ phức tạp và tính quan trọng của dự án, bao gồm xác định yêu cầu, triển khai, cài đặt, thử nghiệm, đào tạo, bảo trì và các giai đoạn khác của dự án. Kế hoạch dự án được đề xuất đảm bảo rằng nhà cung cấp có đủ nguồn lực cần thiết để thực hiện hợp đồng thành công. Kế hoạch quản lý dự án thường bao gồm những nội dung sau:
Các cơ quan nên nhớ rằng nhà cung cấp có thể đáp ứng các yêu cầu kỹ thuật nhưng không thể đáp ứng các yêu cầu quản lý như bằng chứng là phản hồi kém hoặc không đầy đủ của họ đối với phần này. Bộ phận quản lý sẽ giúp phân biệt các nhà cung cấp có năng lực quản lý trưởng thành hay chưa trưởng thành. Bạn có thể yêu cầu nhà cung cấp xác định mọi giả định và mọi rủi ro tiềm ẩn liên quan đến RFP và mục tiêu mong muốn của dự án; và/hoặc yêu cầu họ mô tả chi tiết về một dự án tương tự và cách họ giải quyết các vấn đề phát sinh trong quá trình thực hiện để làm hài lòng khách hàng. |
6 |
Các biện pháp thực hiện rõ ràng và riêng biệt và các điều khoản thực thi |
Các yêu cầu và hợp đồng IT đáp ứng định nghĩa về “rủi ro cao”, theo định nghĩa trong § 2.2-4303.01 của Bộ luật Virginia, phải bao gồm các biện pháp thực hiện rõ ràng và khác biệt cũng như các điều khoản thực thi, bao gồm các biện pháp khắc phục trong trường hợp Nhà cung cấp không thực hiện. Sử dụng các công cụ bên dưới để tìm hiểu thêm về các biện pháp thực hiện rõ ràng và riêng biệt cũng như các điều khoản thực thi, bao gồm các biện pháp khắc phục: Ma trận yêu cầu tối thiểu cho các hoạt động mua sắm IT lớn, mua sắm IT rủi ro cao và
|
7 |
Hồ sơ nhà cung cấp |
Các nhà cung cấp được yêu cầu mô tả hoạt động kinh doanh và trình độ chuyên môn của mình và cung cấp thông tin tham khảo. Họ nên được yêu cầu trình bày chi tiết về tình hình công ty và tài chính của họ cũng như những khách hàng sẽ làm người tham khảo về hiệu suất làm việc và tính chính trực của họ. Các ví dụ sau đây là những nội dung thường được yêu cầu trong phần này:
|
8 |
Phần SWaM |
Các nhà cung cấp được yêu cầu cung cấp “Kế hoạch mua sắm và thầu phụ của nhà cung cấp” trong đó nêu rõ tỷ lệ cam kết chung mà Nhà cung cấp dự kiến sẽ chi trực tiếp cho các nhà thầu phụ để thực hiện các yêu cầu của hợp đồng. Ngoài ra, Nhà cung cấp được yêu cầu cung cấp danh sách tất cả các nhà thầu phụ mà Nhà cung cấp dự kiến sử dụng để thực hiện hợp đồng. Danh sách các nhà thầu phụ phải chỉ rõ những nhà thầu phụ là doanh nghiệp SWaM cũng như những nhà thầu phụ không phải là doanh nghiệp SWaM. Trong trường hợp Nhà cung cấp DOE không dự đoán sẽ sử dụng các nhà thầu phụ khi thực hiện hợp đồng, Nhà cung cấp được yêu cầu nêu rõ sự việc này trong phản hồi của mình. |
9 |
Thông tin giá cả |
Chỉ định cách nhà cung cấp cung cấp thông tin về giá cả và cung cấp định dạng chi tiết để họ tuân theo khi xây dựng đề xuất giá của mình. Hướng dẫn phải đủ rõ ràng để đảm bảo giá đề xuất có thể được so sánh ngang bằng. Để tạo điều kiện thuận lợi cho việc so sánh này, hãy cân nhắc cung cấp một bảng tính mẫu chia hệ thống được đề xuất thành các thành phần như sau:
Bao gồm một lịch trình/kịch bản định giá làm ví dụ về cách thức nộp giá đề xuất. Nếu việc định giá trọn gói không có lợi, hãy sử dụng một kịch bản định giá để có được giá cho số lượng hoặc giờ không xác định. Yêu cầu phân tích chi phí định kỳ và không định kỳ. Biểu giá phải gắn liền với các sản phẩm được giao và phải trùng với phương thức thanh toán được quy định trong thư chào hàng. Khi xem biểu giá, hãy chú ý đến mức giá bao gồm chi phí một lần so với chi phí định kỳ. Giá ban đầu của một gói phần mềm là chi phí một lần; phí bảo trì hàng năm và phí cấp phép phần mềm là chi phí định kỳ phải được xác định để lập tổng chi phí vòng đời của một dự án. Giá cả thường không phải là yếu tố duy nhất quyết định việc trao giải, nhưng nên được sử dụng để phân định thắng thua giữa hai nhà cung cấp có đề xuất kỹ thuật và quản lý tốt như nhau. Đối với các dự án phức tạp, bạn cũng có thể yêu cầu nhà cung cấp gửi biểu giá mốc thời gian, trong đó có thể áp dụng tỷ lệ khấu trừ để thanh toán sau khi hóa đơn cuối cùng được chấp thuận. Điều này thúc đẩy các nhà cung cấp và tăng thêm sự bảo vệ cho cơ quan nếu việc chấp nhận cuối cùng bị chậm trễ hoặc có vấn đề. Nó cũng cho phép dễ dàng chấm dứt hợp đồng tại bất kỳ thời điểm quan trọng nào nếu nhà cung cấp không thực hiện nghĩa vụ. |
10 |
Thỏa thuận chuẩn của cơ quan (tức là mẫu hợp đồng) |
Bao gồm mẫu hợp đồng được đề xuất với các thỏa thuận không tiết lộ thông tin, yêu cầu về tính bảo mật, bảo vệ dữ liệu và an ninh, bảo hành, yêu cầu về thỏa thuận cấp phép và các điều khoản và điều kiện theo luật định, pháp lý và cụ thể IThoặc bất kỳ điều khoản liên bang nào có thể được yêu cầu. Nên yêu cầu các nhà cung cấp gạch chéo mẫu hợp đồng được đề xuất để làm nổi bật tất cả các trường hợp ngoại lệ mà họ không thể đồng ý. Các nhà cung cấp không nên sửa đổi điều khoản trách nhiệm pháp lý tại thời điểm này. Họ có thể nêu ra các vấn đề hoặc bình luận lần đầu tiên trong các cuộc đàm phán sau đó. Xác định các vấn đề gây cản trở trong giai đoạn đánh giá đề xuất vì có thể chọn phải nhà cung cấp không chấp nhận hợp đồng của công ty. |
11 |
Phần nhà cung cấp (tùy chọn) |
Cho phép nhà cung cấp đưa vào thông tin mà họ cảm thấy có liên quan mặc dù không bắt buộc hoặc không được yêu cầu trong RFP. Họ cũng có thể thảo luận các vấn đề tiềm ẩn có liên quan đến RFP và đề xuất của họ. Ví dụ, nhà cung cấp có thể có các tính năng sản phẩm bổ sung để chứng minh nằm ngoài phạm vi của RFP, đưa ra giải pháp độc đáo mà người mua không lường trước được hoặc có thể cung cấp giải pháp cho một vấn đề rõ ràng trong RFP mà các nhà cung cấp khác không xem xét đến. Ngay cả khi nhà cung cấp cụ thể này DOE không thắng kiện thì lời giải thích về vấn đề và giải pháp tiềm năng vẫn đáng để xem xét. |
12 |
Phụ lục |
Bao gồm thông tin cồng kềnh nhưng có liên quan như sơ đồ mạng, nghiên cứu yêu cầu kỹ thuật, phác thảo kế hoạch dự án và thông tin chi tiết khác. Các ví dụ bao gồm:
Sau đó, nhà cung cấp sẽ có được thông tin nhưng DOE không làm mất đi phần tường thuật của RFP. Lưu ý: Hãy cho nhà cung cấp biết liệu họ có phải sử dụng thông tin này khi xây dựng đề xuất của mình hay không. |
Tìm kiếm trên tài liệu hướng dẫn bằng từ khóa hoặc thuật ngữ thông dụng.