부록 D: 품질 IT RFP의 내용
| 섹션 | 섹션 | 콘텐츠 설명 |
|---|---|---|
|
1 |
들어가며 |
문제에 대한 설명을 제공하며 공급업체가 RFP의 원인이 된 비즈니스 문제와 문제를 촉발했을 수 있는 기술적 문제를 파악할 수 있을 정도로 상세해야 합니다. |
|
2 |
제안 지침 및 관리 |
공급업체가 수락 가능한 제안서를 제출하기 위해 준수해야 하는 모든 관리 요구 사항 및 정보가 포함되어 있습니다. 이 섹션에는 RFP 제출부터 계약 체결까지 조달에 대한 기본 규칙이 포함되어 있으며 다음과 같은 유형의 정보가 포함되어야 합니다:
지침이 불완전하거나 불명확한 경우 공급업체는 중요한 회의나 마일스톤을 간과할 수 있습니다. 일부 공급업체는 품질 지침의 부족을 프로젝트 팀이 약하거나 프로젝트에 문제가 있다는 신호로 간주하여 주요 업계 공급업체가 제안서를 제출하지 않을 수 있습니다. 공급업체가 RFP의 관리 요구 사항을 준수하지 않을 경우 제안이 거부될 수 있습니다. 이 섹션에서는 RFP 응답에 대한 명확한 규칙을 제시하고 공급업체가 이를 따르지 않을 경우의 불이익을 인지할 수 있도록 해야 합니다. |
|
3 |
제안서 형식 |
제안서의 형식 및 제본 방법과 필요한 미디어(예: 하드카피, CD 등)에 대한 세부 정보를 제공합니다. 다양한 제안서 섹션을 별도로 제출해야 하는 경우(예: 기술, 비용, 편집 등)를 표시하는 표를 포함하면 도움이 됩니다. 이 섹션은 2 섹션의 제안 지침과 중복되거나 충돌해서는 안 됩니다. |
|
4 |
현재 상황 |
기관의 조직 배경과 프로젝트의 현재 비즈니스 및 기술 환경을 정확하게 설명하여 공급업체가 새로운 요구 사항을 충족하기 위해 해당 환경을 조정하거나 수정할 수 있는 솔루션을 효과적이고 정확하게 제안할 수 있도록 하세요. 현재 비즈니스 환경에 대한 설명에는 영향을 받는 현재 비즈니스 서비스 및 프로세스의 모든 사용자와 수혜자가 포함되어야 합니다. 현재 기술 환경에 대한 설명은 현재 사용 중인 모든 하드웨어와 소프트웨어, 프로젝트 요구 사항을 해결하기 위해 사용되었거나 사용되어야 하는 것, 다른 기존 시스템/플랫폼 및/또는 애플리케이션과의 현재 인터페이스 등을 포함하여 명확하게 정의되어야 합니다. 워크플로 및 애플리케이션 인터페이스는 비주얼을 사용하여 표시할 수 있습니다. |
|
5 |
기능 및 기술 요구 사항 |
공급업체가 문제를 이해하고 완전하고 확고한 제안서를 준비할 수 있도록 기능적, 기술적 요구 사항과 충분한 정보를 제공합니다. 이 개요는 현재 비즈니스 애플리케이션과 기술 환경(하드웨어, 소프트웨어, 통신)을 모두 다루어야 합니다. 기관은 "반드시"와 "해야 한다"는 기술 요구 사항을 사용하지 말고 공급업체가 솔루션 기반 제안의 일부로 문제를 해결할 방법을 제안할 수 있도록 허용하는 것이 좋습니다. 기술 및 기능 요구 사항 섹션에는 다음과 같이 공급업체가 반드시 답변해야 하는 질문이 포함되어 있습니다:
프로젝트 관리 요구 사항에는 프로젝트를 관리하고 구현하기 위한 조건이 명시되어 있습니다. 이 섹션에서는 프로젝트의 복잡성과 임무 중요도에 따라 요구사항 정의, 구현, 설치, 테스트, 교육, 유지보수 및 기타 프로젝트 단계에 걸쳐 프로젝트 계획, 위험 완화 계획 또는 기타 관리 계획을 개발하는 데 필요한 정보를 공급업체에 제공해야 합니다. 제안된 프로젝트 계획은 공급업체가 계약을 성공적으로 수행하는 데 필요한 리소스를 보유하고 있음을 보증합니다. 프로젝트 관리 계획에는 일반적으로 다음이 포함됩니다:
대행사는 공급업체가 이 섹션에 대한 부실하거나 부적절한 답변에서 알 수 있듯이 기술 요건은 충족할 수 있지만 관리 요건을 충족하지 못할 수도 있다는 점을 기억해야 합니다. 관리 섹션은 관리 능력이 성숙한 공급업체와 미성숙한 공급업체를 구분하는 데 도움이 됩니다. 공급업체에게 RFP 및 원하는 프로젝트 목표와 관련된 모든 가정과 잠재적 위험을 식별하도록 요청하거나, 유사한 프로젝트와 수행 중에 발생한 문제 또는 이슈를 고객이 만족할 수 있도록 어떻게 해결했는지 자세히 설명하도록 요청할 수 있습니다. |
|
6 |
명확하고 뚜렷한 성과 측정 및 시행 조항 |
버지니아주 규정의 § 2.2-4303.01 에 정의된 "고위험"의 정의를 충족하는 IT 요청 및 계약에는 공급업체 불이행 시 구제책을 포함하여 명확하고 뚜렷한 이행 조치 및 집행 조항이 포함되어야 합니다. 아래 도구를 사용하여 구제책을 포함한 명확하고 명확한 성과 측정 및 시행 조항에 대해 자세히 알아보세요: 주요 IT 조달, 고위험 IT 조달을 위한 최소 요구 사항 매트릭스 및
|
|
7 |
공급업체 프로필 |
공급업체는 자신의 비즈니스 및 전문 자격을 설명하고 참고 자료를 제공해야 합니다. 기업 및 재무 상태와 업무 성과와 성실성에 대한 참고 자료가 될 고객에 대한 세부 정보를 제시하도록 요청받아야 합니다. 다음 예는 이 섹션에서 일반적으로 요구되는 사항입니다:
|
|
8 |
SWaM 섹션 |
공급업체는 계약 요건을 이행하는 데 있어 공급업체가 하청업체에 직접 지출할 것으로 예상하는 전체 약정 비율을 명시한 "공급업체 조달 및 하청 계획"을 제공해야 합니다. 또한 공급업체는 공급업체의 계약 이행에 사용할 것으로 예상되는 모든 하도급업체의 목록을 제공해야 합니다. 하청업체 목록에는 SWaM 비즈니스인 하청업체와 비 SWaM 비즈니스인 하청업체를 지정해야 합니다. 공급업체 DOE 가 계약 이행에 하청업체를 사용하지 않을 것으로 예상되는 경우, 공급업체는 답변서에 이 사실을 명시해야 합니다. |
|
9 |
가격 정보 |
공급업체가 가격 정보를 제공하는 방법을 지정하고 가격 제안서를 개발할 때 따라야 할 세부 형식을 제공합니다. 지침은 가격 제안서를 동등하게 비교할 수 있도록 충분히 명확해야 합니다. 이 비교를 용이하게 하려면 제안된 시스템을 다음과 같은 구성 요소로 나눈 샘플 스프레드시트를 제공하는 것이 좋습니다:
제안서 가격을 제출하는 방법의 예로 가격 책정 일정/시나리오를 포함하세요. 일괄 가격 책정이 유리하지 않은 경우 가격 책정 시나리오를 사용하여 알 수 없는 수량이나 시간에 대한 가격을 구하세요. 반복 비용과 비반복 비용을 구분해 달라고 요청하세요. 가격 책정 일정은 결과물과 연계되어야 하며 제안서에 명시된 지불 방법과 일치해야 합니다. 가격 책정 일정을 살펴볼 때는 일회성 비용과 반복 비용이 포함된 가격 책정에 주의하세요. 소프트웨어 패키지의 초기 가격은 일회성 비용이며, 연간 유지 관리 및 소프트웨어 라이선스 비용은 프로젝트의 총 수명 주기 비용을 개발하기 위해 반드시 파악해야 하는 반복적인 비용입니다. 가격은 일반적으로 수주의 유일한 결정 요인은 아니지만, 기술 및 관리 제안이 동등하게 우수한 두 공급업체 간의 동점을 깨는 데 사용되어야 합니다. 복잡한 프로젝트의 경우 공급업체에 최종 인보이스에 최종 승인 후 지급할 홀드백 비율을 적용할 수 있는 마일스톤 가격 일정을 제출하도록 요청할 수도 있습니다. 이는 공급업체에게 동기를 부여하고 최종 승인이 지연되거나 문제가 발생할 경우 대행사를 보호하는 역할을 합니다. 또한 공급업체가 이행하지 않는 경우 어느 마일스톤에서든 계약을 쉽게 해지할 수 있습니다. |
|
10 |
에이전시 표준 계약서(즉, 계약서 템플릿) |
비공개 계약, 기밀 유지, 데이터 보호 및 보안 요구 사항, 보증, 라이선스 계약 요구 사항, 기타 법적, 법률 및 IT 관련 약관 또는 필요할 수 있는 연방 정부의 하위 약관이 포함된 계약서 템플릿이 제안되어 있습니다. 공급업체는 제안된 계약서 템플릿에 동의할 수 없는 모든 예외 사항을 강조하여 수정하도록 요청해야 합니다. 공급업체는 현재 책임 조항을 수정해서는 안 됩니다. 나중에 협상 중에 처음으로 문제나 의견을 제기할 수 있습니다. 대행사의 계약을 수락하지 않을 공급업체를 선정할 수 있으므로 제안서 평가 기간 동안 쇼닥터 문제를 파악하세요. |
|
11 |
공급업체 섹션(선택 사항) |
공급업체가 RFP에서 요구하거나 요청하지는 않았지만 관련성이 있다고 생각하는 정보를 포함할 수 있도록 허용합니다. 또한 RFP 및 제안서와 관련된 잠재적인 문제에 대해 논의할 수도 있습니다. 예를 들어, 공급업체는 RFP의 범위를 벗어나는 추가 제품 기능을 시연하거나 구매자가 예상하지 못한 고유한 솔루션을 제시하거나 다른 공급업체가 고려하지 않은 문제에 대한 솔루션을 RFP에 명시된 대로 제공할 수 있습니다. 이 특정 공급업체( DOE )가 이기지 못하더라도 문제에 대한 설명과 잠재적인 해결책은 여전히 고려할 가치가 있습니다. |
|
12 |
부록 |
네트워크 다이어그램, 기술 요구 사항 연구, 프로젝트 계획 개요 및 기타 세부 정보와 같이 부피가 크지만 관련성이 높은 정보를 포함하세요. 예를 들면 다음과 같습니다:
그런 다음 공급업체는 해당 정보를 사용할 수 있지만 DOE RFP의 설명 부분에서 방해가 되지 않도록 합니다. 참고: 공급업체가 제안서를 작성할 때 이 정보를 사용해야 하는지 여부를 알려주세요. |
키워드 또는 일반 용어로 매뉴얼을 검색하시기 바랍니다.