본문으로 건너뛰기

ERP 계약 협상: MENA 지역 CFO, 85만 달러 절감

MENA 지역 제조사 CFO가 받은 120쪽짜리 ERP 제안서는 탄탄해 보였지만, 그 구조에 리스크가 숨어 있었습니다. 3주간의 SOW 검토와 계약 수정으로 킥오프 전에 85만 달러를 피했습니다.

밝은 사무실의 흰색 회의 테이블에 노트북을 놓고 둘러앉은 전문가 다섯 명
목차
  1. 고객사
  2. 제안서에서 발견한 것
  3. 85만 달러는 어디서 나왔는가
  4. 고객을 지키는 계약 조항
  5. CFO가 계속 놓치는 것
  6. CFO를 위한 서명 전 체크리스트
  7. 자주 묻는 질문

ERP 구축 계약은 구조가 튼튼할 때만 예산을 지켜 줍니다. 구체적인 산출물, 이름이 명시된 인력, 승인된 결과물에 연결된 마일스톤, 상한이 있는 하이퍼케어, 통제되는 체인지 오더가 그 구조입니다. 이 사례 연구는 MENA 지역 중견 제조사의 CFO가 작업기술서(SOW)를 항목별로 분해하고 서명 전에 계약을 다시 쓰게 하여, 범위를 줄이지 않고도 킥오프 전에 85만 달러를 절감한 과정을 보여 줍니다. ERP나 SAP 구축 계약에 서명하기 직전인 CFO, 재무 이사, 구매 책임자를 위한 글입니다. 글 끝부분의 서명 전 체크리스트를 여러분의 제안서에 적용해 보십시오.

CFO가 120쪽짜리 제안서를 건넸습니다. 겉보기에는 탄탄한데 뭔가 이상하다고 했습니다. 그의 직감이 맞았습니다.

숫자가 문제가 아니었습니다. 구조가 문제였습니다. "표준 구성", "테스트 지원"처럼 어떤 작업이 들어가는지 설명이 없는 일반적인 표현. 같은 작업이 이름만 바꿔 여러 절에 나오는 것. 나중에 어떤 초과 비용이든 정당화할 수 있을 만큼 모호한 문장. 프로젝트는 시작하기도 전에 이렇게 궤도를 벗어납니다.

그가 느꼈지만 짚어 내지 못한 것이 제 눈에는 보였습니다. 그는 예산과 목표를 알고 있었습니다. 팀은 유능했지만 이 규모의 구축 SOW를 검토해 본 적이 없었고, 벤더는 이미 서명을 향해 움직이고 있었습니다.

3주간 작업한 끝에 계약은 근본적으로 달라졌고, 프로젝트는 킥오프 전에 85만 달러 가벼워졌습니다.

85만 달러는 어디서 나왔는가3주간의 SOW 검토와 계약 수정의 결과입니다. 범위나 기능을 줄여서 나온 금액은 한 푼도 없습니다.
$850K킥오프 전에 절감
  1. 범위 합리화부풀려진 공수 삭감, 중복된 교육과 테스트 제거, 테스트 주기를 4회에서 2회와 예비분으로 축소$340K
  2. 역할 및 단가 재배분시니어 대 주니어 구성비 관리, 문서화와 기본 테스트는 내부 인력이 담당$310K
  3. 계약 조건 변경산출물 기준 지급, 경비 상한, 하이퍼케어 기간 상한, 체인지 오더에 대한 CFO 승인$200K

국경을 넘나드는 사업과 중앙 집중형 재무 조직을 갖춘 중견 산업재 제조·유통 기업이었습니다. 사업은 개별 제조, 애프터마켓 유통, 공유 서비스 재무, 그룹 구매로 이루어져 있었습니다. 그룹은 5년간 빠르게 성장했고 이미 SAP를 선택한 상태였습니다. 벤더 선정과 구축 착수 사이, 큰 약속들이 곧 확정되려는 시점이었습니다.

SOW를 구성, 데이터 마이그레이션, 연계, 테스트, 교육, PMO의 여섯 범주로 나누었습니다. 그렇게 나누자 빈틈이 쉽게 보였습니다.

  1. 모호한 산출물. "표준 연계"라고만 쓰여 있고 시스템 이름, 데이터 양, 복잡도는 없었습니다. 구성은 공수(시간)로만 기술되어 있어 업무 프로세스와 연결되지 않았습니다. 문서 곳곳에 "워크숍에서 확정"이라는 문구가 흩어져 있었고, 하나하나가 앞으로 생길 체인지 오더였습니다.
  2. 리소스 피라미딩. 제안서에는 시니어 컨설턴트가 시니어 일당으로 명시되어 있었습니다. 계약이 체결되면 시니어는 사라지고, 주니어가 같은 단가로 일하는 경우가 많습니다. 거의 모든 프로그램에서 본 일입니다. 지정 인력 조항이 없으면 막을 방법이 없습니다.
  3. 중복 청구. UAT에서 교육하고 하이퍼케어에서 또 교육합니다. 테스트에서 데이터를 점검하고 컷오버에서 또 점검합니다. 지식 이전이 기능 팀과 PMO로 나뉘어 두 번 청구됩니다. 하나하나는 작은 중복이지만 합치면 심각한 초과 요인입니다.
  4. 고정 금액의 착시. 고정 가격으로 제시되었지만, "고정"은 모든 가정이 확정되어 있을 때만 성립합니다. 이런 문구들은 총액을 안정적으로 보이게 하면서 나중에 청구할 길을 엽니다.
  5. 약한 마일스톤. "9월까지 설계 완료"처럼 지급이 달력 날짜에 묶여 있었고, 무엇이 완료인지에 대한 정의도 인수 기준도 없었으며, 반쯤 끝난 작업에 대한 청구서를 보류할 방법도 없었습니다.
  6. 용도 미정 공수. "필요에 따라 사용"이라는 버퍼 항목이 근거 없이 잡혀 있었습니다. 일상적인 작업에 빠르게 소진되고 변경 요청으로 되돌아옵니다.

범위에서도 두 가지가 눈에 띄었습니다. 고객이 이미 사내 도구를 갖고 있는데도 데이터 마이그레이션 비용이 전부 벤더에 잡혀 있었습니다. 그리고 테스트는 결함 가정 없이 전체 4회 주기로 잡혀 있었습니다.

절감은 세 영역에서 나왔습니다.

영역절감액방법
범위 합리화34만 달러부풀려진 구성 공수 삭감, 중복된 교육과 테스트 제거, 테스트를 4회 주기에서 2회와 예비분으로 축소
역할 및 단가 재배분31만 달러시니어 대 주니어 구성비 관리, 문서화와 기본 테스트는 지정 인력 보호 조항 아래 내부 인력이 담당
계약 조건 변경20만 달러산출물에 연동한 지급, 사전 승인을 전제로 한 출장·경비 상한, 하이퍼케어 기간 제한과 KPI 기준 종료, CFO 승인으로 통제되는 체인지 오더

고객 자체 도구와 표준을 활용해 벤더의 데이터 마이그레이션 공수는 약 3분의 1 줄었고, 사내 주도 모델로 외부 교육 시간은 약 절반 줄었습니다. 이 중 어느 것도 범위나 기능을 줄이지 않았습니다. 프로젝트는 계획한 날짜에 시작했고, 첫 분기에는 체인지 오더가 한 건도 없었습니다. 보통 그 시점이면 몇 건은 CFO의 책상에 올라와 있습니다.

실질적인 차이를 만든 조항은 여섯 가지였습니다.

  1. 지정 인력. 핵심 컨설턴트는 모두 이름을 명시합니다. 교체에는 고객 승인과 단가 조정이 필요합니다. 이것이 없으면 제안서에 있던 사람이 현장에 있는 사람이 아닙니다.
  2. 산출물 기준 마일스톤. 마일스톤마다 결과물로 정의합니다. 서명된 프로세스 맵, 대사가 끝난 데이터, 완료된 인수 테스트가 그 예입니다. 날짜가 왔다고 지급하는 것이 아니라 기준을 충족했을 때 지급합니다.
  3. 체인지 오더 거버넌스. 모든 범위 변경에는 범위, 일정, 비용에 대한 영향 분석서가 필요합니다. 신규 작업 단가에는 상한이 있습니다. CFO 승인은 필수입니다. 체인지 오더는 수익 모델이 아니라 통제되는 예외가 됩니다.
  4. 종료 기준이 있는 하이퍼케어 상한. 기간을 6주로 제한하고, 종료는 벤더의 판단이 아니라 트랜잭션 안정성과 SLA 준수로 정의합니다. 연장에는 새로운 승인이 필요합니다.
  5. 출장 및 경비 상한. 정해진 한도를 넘으면 사전 승인을 받습니다. 그렇지 않으면 Go-Live 이후 출장비가 열려 있는 항목이 됩니다.
  6. 감사권. 청구 기록을 검토할 권리입니다. 한 번도 행사하지 않더라도 행동을 바꿉니다. 확인될 수 있는 상황에서는 부풀리기가 어렵기 때문입니다.

협상 전반에 대해서는 SAP 협상 자문과 SAP 라이선스 협상에 관한 제 글이 거래의 소프트웨어 측면을 다룹니다.

재무팀은 ERP 구축을 IT 프로젝트로 보고, 예산이 승인되면 한 발 물러서는 경우가 많습니다. 그렇게 해서 초과 비용이 쌓입니다.

계약은 재무 상품입니다. 마일스톤이 현금 흐름을 정하고, 인력 조항이 비용을 정하며, 체인지 오더 절차가 노출 규모를 정합니다. 서명 전에 재무가 이를 검토하지 않으면, 상업적 경험을 가진 사람이 아무도 검토하지 않는 것입니다.

세 가지 공백이 반복해서 나타납니다.

  1. 고정 금액이라는 통념. CFO는 상한이 있어 보이는 금액을 승인하지만, 가정이 모호하게 남아 있다면 범위는 고정된 것이 아닙니다. 범위가 늘어나고 비용이 청구되는 곳은 벤더의 워크숍입니다.
  2. 지연 비용 모델의 부재. 일정이 밀리면 컨설팅 몇 주 치가 더해지는 데서 그치지 않습니다. 사내 인력의 시간이 더 들고, 효과가 나타나는 시점도 늦어집니다. 대부분의 예산은 프로젝트 비용만 계획하고, 초과되는 매주의 비용은 모델링하지 않습니다.
  3. 상업적 역량이 없는 사내 PMO. 일정 관리와 보고는 있지만 상업적 반박은 없습니다. 벤더의 프로젝트 매니저는 계약 조건을 다룰 줄 알고, 고객 쪽에 같은 수준의 사람이 없으면 고객이 양보하게 됩니다. SAP 예산이 초과되는 이유를 다룬 제 가이드는 그 노출이 보통 어디서 비용으로 바뀌는지 보여 줍니다.

거래에 RISE with SAP가 포함되어 있다면 읽어야 할 계약이 두 개입니다. 고유한 서비스 설명서가 딸린 SAP 구독 계약과 구축 파트너의 SOW입니다. 둘 모두에 같은 원칙을 적용하고, 구독 비용이 1년 차만이 아니라 전체 계약 기간 동안 사용자 수에 따라 어떻게 늘어나는지 모델링하십시오.

ERP 프로젝트는 대개 수행 단계에서 실패하지 않습니다. 계약에서 실패합니다. 마일스톤, 인력 투입 약속, 인수 기준을 느슨하게 쓰면 초과 비용은 거의 확정된 것이나 다름없습니다.

ERP 구축 제안서에 서명하기 전에 다음 항목을 확인하십시오.

  1. SOW가 워크스트림별(구성, 데이터, 연계, 테스트, 교육, PMO)로 분해되어 있고, 각각의 공수가 있습니까?
  2. 모든 연계에 시스템 이름, 데이터 양, 복잡도가 명시되어 있습니까?
  3. "워크숍에서 확정"이라는 가정이 모두 종결되었거나 명시적으로 제외되었습니까?
  4. 핵심 컨설턴트가 지정되어 있고, 교체 승인과 단가 조정 조항이 있습니까?
  5. 모든 지급 마일스톤이 인수 기준과 고객 서명이 있는 산출물에 연결되어 있습니까?
  6. 영향 분석서, 단가 상한, CFO 승인이 있는 체인지 오더 절차가 있습니까?
  7. 하이퍼케어의 기간이 정해져 있고 객관적인 종료 기준이 있습니까?
  8. 출장과 경비에 상한이 있고, 청구된 공수에 대한 감사권이 있습니까?
  9. 자사 팀이 할 수 있는 일(사내 도구를 쓴 데이터 마이그레이션, 문서화, 기본 테스트, 교육)을 벤더 범위에서 뺐습니까?

CFO는 나중에 이렇게 말했습니다. "처음 제안서를 검토했을 때는 숫자가 합리적으로 보였습니다. 제가 놓친 것은 범위가 실제로 얼마나 모호한가였습니다. 항목별로 분해하고 보니 리스크 대부분이 작은 글씨 속에 있었습니다. 계약에 재무의 시각을 더하자 제게 없다는 것조차 몰랐던 통제력이 생겼습니다. 절감액도 중요했지만, 더 큰 성과는 명확한 상태로, 예상 밖의 일 없이 구축에 들어갔다는 점입니다."

그는 결과를 이사회에 공유했습니다. 절감액이 헤드라인이었습니다. 더 중요한 결과는 회사가 처음부터 통제할 수 있는 계약, 그리고 프로젝트였습니다.

ERP 계약에서 리소스 피라미딩이란 무엇이며 어떻게 막습니까?

제안서에는 시니어 컨설턴트와 시니어 일당을 제시해 놓고, 서명 후에는 더 주니어인 인력으로 수행하는 것입니다. 청구 단가는 그대로이고 품질은 그렇지 않습니다.

해결책은 지정 인력 조항입니다. 핵심 역할을 모두 실명으로 지정하고, 교체에는 고객 승인을 받으며, 대체 인력의 단가가 더 낮으면 청구액을 조정합니다.

ERP 청구 마일스톤은 어떻게 구성해야 합니까?

날짜가 아니라 산출물에 연결하십시오. "설계 완료"는 마일스톤이 아닙니다. "서명된 프로세스 맵과 재무·구매 영역의 검토된 구성"이 마일스톤입니다.

마일스톤마다 고객이 지급 전에 서명하는 인수 기준을 두십시오. 그러면 납품이 미완일 때 협상력이 생기고, 일부만 끝난 작업에 대한 청구서를 막을 수 있습니다.

ERP 구축 계약의 고정 금액 함정이란 무엇입니까?

고정 금액은 서명 전에 모든 가정이 확정되어 있을 때만 고정입니다. "워크숍에서 확정", "표준 연계", "현재 범위 기준" 같은 문구는 총액을 안정적으로 보이게 하면서 나중에 체인지 오더가 들어올 틈을 만듭니다.

서명 전에 가정을 종결하고, 제외 항목을 명시적으로 나열하고, 체인지 오더 단가에 상한을 두고, 고정 금액이라는 주장을 항목별로 검증하십시오.

ERP 계약에서 하이퍼케어는 어떻게 정의해야 합니까?

기간이 정해지지 않은 하이퍼케어는 벤더의 수익원이 됩니다. 보통 6주에서 8주 사이로 기간에 상한을 두고, 트랜잭션 안정성, SLA 준수, 티켓 건수 같은 객관적인 종료 기준을 두십시오. 연장은 모두 공식 승인을 받아야 합니다.

그러면 하이퍼케어는 인수인계 조건이 분명한, 기간이 정해진 안전망이 됩니다.

ERP 구축 계약에 서명하기 전에 CFO는 무엇을 검토해야 합니까?

최소한 마일스톤 정의 방식, 인력 교체 보호, 체인지 오더 규칙, 하이퍼케어 범위와 종료, 출장 및 경비 상한, 제외 항목 목록을 봐야 합니다.

조항 외에도 SOW를 워크스트림별로 분해하고, 공수 추정치를 사내 가용 역량과 대조하십시오. 자사 직원이 문서화, 기본 테스트, 교육을 맡을 수 있다면 계약에 그 내용이 반영되어야 합니다.

고정 가격 계약인데도 ERP 체인지 오더가 계속 생기는 이유는 무엇입니까?

고정 가격 계약이 모든 가정을 확정하는 경우는 드물기 때문입니다. 제안서는 개략적인 수준으로 쓰이고, 공백은 워크숍에서 드러나며, 공백 하나하나가 기술적으로는 범위 밖인 변경 요청이 됩니다.

패턴은 예측 가능합니다. 모호한 범위, 그것을 넓히는 워크숍, 그 공백을 수익으로 바꾸는 체인지 오더. 서명 전에 구체적인 범위를 요구하고, 새 작업이 시작되기 전에 영향 분석과 고위 승인을 요구하십시오.

Noel D'Costa

글쓴이

Noel D'Costa

항공, 정부, 금융, 유통, 제조 분야의 SAP 및 Oracle ERP 프로젝트에서 25년을 일했습니다. 재무 출신입니다. 경영진이 혁신의 범위를 현실적으로 정하고, 어려움에 처한 프로젝트를 정상화하며, 운영 첫해를 견뎌 내는 시스템을 구축하도록 돕습니다.

다음 단계

지금 ERP 프로젝트를 진행 중이십니까?

이 글이 지금 진행 중인 프로젝트와 맞닿아 있다면, 30분 대화가 일주일간의 내부 분석보다 대개 더 많은 진전을 가져옵니다.