제 25 장 - IT 계약 체결

25.4.2 성공적인 IT 계약을 위한 일반적인 가이드라인

IT 계약을 성공적으로 체결하기 위한 핵심은 대행사의 비즈니스 요구 사항과 프로젝트의 기대치를 설정하고 이를 충족하는 것입니다. 이는 계약의 성공을 관리할 공동 운영위원회 지정, 프로젝트에 대한 책임을 질 양측의 개인 식별, 지속적인 대화와 문제에 대한 공개 토론, 효과적인 변경 관리 프로세스를 통해 계약의 최신 상태 유지, 돌발 상황을 최소화하기 위해 공급업체가 조기에 자주 진행 보고서를 제공하도록 요구함으로써 달성할 수 있습니다. IT 계약 전문가에 따르면 대부분의 IT 계약 문제는 다음 시나리오 중 하나에서 비롯된다고 합니다:

• 공급업체가 비현실적인 약속(예: 성과 보장, 달성 불가능한 일정, 필요한 분석이 없는 고정 가격 계약)을 하거나공급업체가 노동 시간, 비용, 위험을 과소평가하는 경우.

• 계약서에 명확한 계약 기준(예: 불명확한 요구 사항, 이용 약관 및 작업 내용)이 없습니다.

• 공급업체 DOE 는 대리점 관계를 관리하지 않습니다(즉, 업무 관계를 지속적으로 개선하고 문제를 숨기지 않아야 합니다).

• 계약 DOE 에는 변경 관리를 위한 절차 및 프로세스가 포함되어 있지 않습니다(즉, 공식적인 변경 관리 프로세스가 없음).

IT 계약을 체결할 때는 다음과 같은 업계 모범 사례 고려 사항을 사용해야 합니다:

• 성공적인 IT 계약에는 양 당사자의 모든 기술적 및 관리적 기대와 약속이 포함됩니다. 계약에는 품질 검토, 테스트, 진행 상황 측정, 성능 캡처 및 보고, 결함 관리, 변경 요청 처리, 업그레이드 및 문제 에스컬레이션을 위한 절차가 포함되어야 합니다. 기관은 공급업체의 신뢰성, 성능, 기능, 호환성, 수명, 보안 규정 준수, 지원 및 비용과 관련된 요구 사항을 고려해야 합니다.

• 실패 가능성을 줄이려면 계약서를 최대한 구체적으로 작성해야 합니다. 양측이 조달할 서비스 또는 시스템과 관련하여 공통의 서면 정의, 사양 및 시간표에 동의하면 계약 실패를 방지할 수 있습니다. 질문과 문제가 발생하면 양측 모두 문서를 참조하고 필요한 경우 수정할 수 있습니다.

• 공급업체는 계약상의 의무를 정의하고 대행사는 비즈니스 문제를 해결하고자 합니다. 이러한 관점의 차이를 다루기 위해 계약서에는 분쟁 및 변경 조항이 포함되어야 합니다. 예를 들어, 계약서에는 성과, 문제점 및 성공 여부를 검토하기 위해 매월 회의를 열도록 되어 있을 수 있습니다. 이를 통해 공급업체 관리를 장려하고 당사자들이 큰 문제가 발생하기 전에 문제를 처리할 수 있습니다.

• 기관은 모든 IT 계약, 특히 IT 서비스 계약을 주의 깊게 모니터링해야 합니다. 대부분의 IT 계약에는 서비스 또는 지원 요소가 포함되며, 공급업체는 초기 이행 기간 이후에도 계약상 보장된 성능/응답 시간 및 약속된 서비스 수준을 지켜야 합니다. 공급업체가 적절한 서비스를 제공하지 않거나 합의된 서비스 수준을 충족하지 못하는 경우, 제품이 약속한 대로 작동하지 않는 경우 또는 대리점 사용량이 예상보다 높지 않은 경우, 대리점은 일부 환불을 받거나 크레딧 또는 그 이상의 할인을 요청할 수 있습니다.

• 계약에 따른 공급업체의 책임이 정확히 무엇인지 확인할 수 있는 상세한 서비스 수준 계약(SLA)에 동의하는 것이 유리합니다. 좋은 SLA는 상식적인 프로젝트 논의를 반영하고 이해관계와 인센티브의 균형을 추구합니다.

• 가격은 서비스 변경, 선택적 서비스, 수정되거나 충족되지 않은 SLA 등 특정 계약 변경 사항에 따라 조정되어야 합니다. 또 다른 적응형 가격 방식에는 서비스형 소프트웨어 조달에서와 같이 종량제 가격(또는 확장 가능한 가격)이 가격에 포함되어 대행사가 실제 서비스 사용자 수에 대해서만 비용을 지불하도록 하는 구독 기반 서비스가 포함될 수 있습니다. 계약 가격이 일정 기간 동안 고정되어 있는 경우 가격 인상 및 인하를 고려해야 할 수 있습니다. 기관은 물가 상승률로 인상을 제한해야 하며 상한선(예: +/-3% )을 포함할 수도 있습니다.

• 양 당사자는 구체적인 기대치, 약속 및 우발 상황에 대해 계약적으로 동의해야 합니다. 예를 들어 시스템 사양에는 필요한 기능뿐만 아니라 성능 요구 사항이나 제약 조건, 호환성 요구 사항, 예상 수명, 허용 가능한 결함 수준도 명시해야 합니다.

• 양 당사자는 "베타 테스트" 의 의미 또는 대행사의 시스템 수용 여부 결정 기준과 같은 주요 용어, 조건 및 활동을 명확하고 모호하지 않게 정의해야 합니다. IT 업계에서 시스템 승인은 일련의 합의된 테스트("승인 테스트")를 통과하고 일정 기간 동안 심각한 결함 없이 운영된 경우 등 다양한 시점에 이루어질 수 있습니다. 모든 당사자가 수락을 기꺼이 정의하지 않는다면 분쟁이 발생할 수 있다는 강력한 경고 신호입니다. 그러나 SLA를 작성하면 계약, 결제 또는 배송 전에 잠재적인 문제 영역을 미리 파악할 수 있습니다.

• 모든 시간 참조는 특정 날짜여야 합니다. "합리적인 시간" 또는 "즉시" 사용을 피하고 계약에 따른 각 당사자의 요구 사항을 구체적으로 명시하세요. 즉, 계약 체결일로부터 3일 이내(특정 시점, 즉 계약 체결일)에 "."

• 계약 내에서 수식을 사용하는 경우 해당 수식이 작동하는지 확인하세요.

• "만족스럽게 준비됨," " 적시에," " 합리적으로 예상됨과 같은 모호한 참조를 사용하지 마세요." 공급업체( ")가 적시에 수행했는지 확인하기가 어렵습니다."

• 정의가 포함되지 않는 한 "materiality", "같은 단어는 사용하지 마세요".

• "은" (필수), "은" (허용)으로 신중하게 사용해야 합니다.

• 계약이 버지니아주 강령 2.2-4303.01 에 따라 "고위험" 으로 정의되는 경우, 계약에는 계약 이행 지표 또는 기타 조항이 충족되지 않을 경우 사용할 수 있는 명확하고 측정 가능한 성과 지표와 벌금 및 인센티브를 포함한 명확한 집행 조항이 포함되어야 합니다.

마지막으로, VITA는 모든 계약 문서가 필요에 따라 양측 조직의 지휘 체계를 오르내리며 모든 관련 담당자가 약속된 사항과 예상되는 사항을 이해하고 최종 계약서에 모든 내용이 포함되도록 할 것을 권장합니다. 또한, VITA의 프로젝트 관리 및 감독 부서는 영연방 전체에서 일관성을 유지하기 위해 기술 관리 용어집을 비롯한 영연방 프로젝트 관련 표준 템플릿과 도구를 제공하여 IT 기반 용어의 사용을 촉진합니다. (방문: https://www.vita.virginia.gov/it-governance/project-management/).