SAP 프로젝트가 예산을 초과하는 이유와 막는 방법

SAP 프로젝트가 예산을 초과하는 주된 이유는, 기업이 처음에 비용을 낮게 잡으려 하다가 탐색(Explore) 단계에서 Fit-to-Standard 워크숍이 실제 범위를 드러낼 때 타격을 받기 때문입니다. 제가 검토한 프로그램에서는 40~60%의 예산 초과가 흔합니다.

간단히 답하면, SAP 예산은 아무도 범위를 알기 전에 정해졌을 때, 그리고 그 범위를 고객사가 아니라 벤더가 통제할 때 초과됩니다. 탐색 단계 동안 WRICEF 수를 지켜보고, 범위를 직접 소유하며, 예비비 10~20%를 귀사 쪽에 두십시오.

설문 평균은 더 차분해 보입니다. Panorama Consulting의 2026 ERP 보고서에 따르면 ERP 예산을 초과한 조직은 4분의 1이 넘었고, 가장 큰 원인은 추가 기술 수요였습니다. 설문 평균과 결국 자문가 앞에 오게 되는 프로그램은 서로 다른 모집단이므로, 계획은 후자를 기준으로 세우십시오.

40-60%

제가 검토하는 SAP 프로그램에서 흔히 보는 예산 초과 폭

출처: Noel D'Costa, 공개된 관찰 결과

이 글은 출발 금액이 아니라 예산 초과를 다룹니다. 기업 규모별 비용 범위, 비용이 쓰이는 곳, 일일 단가, 예산 공식은 제 가이드 SAP 구축 비용은 얼마인가를 읽어 보십시오.

제가 이끌었거나 구원 투입되었던 21개 SAP 프로그램 전반에서 같은 원인이 반복됩니다. 그 대부분은 계약에 서명하기 전에 이미 보입니다.

1. 예산을 낮게 잡고, 탐색 단계에서 실제 범위가 드러난다

제가 가장 흔히 보는 이유입니다. 기업은 처음에 비용을 낮게 잡으려 하는데, 비즈니스 케이스에 이사회가 승인할 만한 숫자가 필요하기 때문인 경우가 많습니다. 그러다 탐색 단계가 옵니다.

SAP Activate에서 탐색 단계는 Fit-to-Standard 워크숍을 통해 SAP 표준 프로세스를 실제 업무 방식과 대조하는 단계입니다(SAP Learning). 그곳에서 발견된 갭은 모두 백로그 항목이 됩니다. 보고서, 인터페이스, 데이터 변환, 기능 확장, 양식 또는 워크플로입니다. 그 어느 것도 원래 가격에는 들어 있지 않았습니다.

예산이 틀린 이유는 누군가 계산을 잘못해서가 아닙니다. 범위가 존재하기도 전에 정해졌기 때문입니다. 가능하다면 최종 금액을 승인하기 전에 짧은 Fit-to-Standard 평가를 진행하십시오.

2. 벤더가 범위를 통제한다

서명 전에 제가 가장 많이 보는 비용 실수는 벤더가 범위를 통제하도록 허용하는 것입니다. 시스템 통합업체가 범위를 작성하면, 그 범위는 현업에 필요한 것이 아니라 통합업체가 납품할 계획인 것을 설명합니다.

그 갭은 나중에 변경 요청으로 드러나고, 모든 변경 요청의 가격은 같은 벤더가 매깁니다. 범위는 귀사가 직접 작성하거나, 구축과 독립된 사람과 함께 작성하십시오.

3. 비용 통제 없는 범위 변경

한 소매 체인은 500만 달러로 예산을 잡았다가 1,230만 달러로 끝났습니다. 요구 사항 수집이 부실해 범위 변경이 끊이지 않았습니다. 중간에 재고 프로세스가 SAP 표준 기능과 맞지 않는다는 사실을 알게 되었고, 대대적인 커스터마이징이 뒤따랐습니다.

레거시 시스템에서의 데이터 마이그레이션도 과소평가했습니다. 설계 단계에서 프로세스를 표준에 맞췄다면 훨씬 저렴했을 것입니다.

4. 경영진의 압박으로 정해진 일정

한 글로벌 제조 프로그램은 예산을 143% 초과했고(계획 580만 달러 대비 1,400만 달러), 가동은 11개월 늦어졌습니다. 원인은 경영진의 비현실적인 일정 압박, 인력이 부족한 내부 팀, 한꺼번에 너무 많은 모듈, 그리고 업계 전문성이 없는 최저가 파트너였습니다.

싸다고 무조건 좋은 것은 아닙니다. 가장 저렴한 구축 옵션을 고른 한 고객사는, 더 경험 많은 팀이었다면 피했을 문제를 고치느라 30%를 더 썼습니다.

5. 겸직 내부 인력

전담 프로세스 오너 대신 겸직 담당자를 배정한 프로그램은 모든 의사결정에서 며칠씩 잃습니다. 그 글로벌 제조 프로그램이 11개월 늦어진 이유 중 하나도 인력이 부족한 내부 팀이었습니다.

귀사의 최고 인재들은 몇 달 동안 업무 시간의 절반 이상을 프로그램에 써야 합니다. 그들의 시간도, 가동 전후의 업무 둔화도 벤더 견적에는 나타나지 않습니다.

6. 늦게 발견되는 데이터 문제

운영 전 단계에서 발견되는 데이터 문제가 가장 비쌉니다. 프로파일링은 구성 이후가 아니라 요구 사항 정의와 함께 진행해야 합니다. 운영 시스템의 압박 속에서 이뤄지는 3개월간의 정제 작업은, 예산을 초과한 프로그램에서 일관되게 가장 큰 지연 비용 항목입니다.

이 주제는 제 YouTube 채널의 영상(영어)에서도 다룹니다.

가장 분명한 조기 경고 신호는 탐색 단계 그 자체입니다. WRICEF 수, 즉 보고서, 인터페이스, 데이터 변환, 기능 확장, 양식, 워크플로의 수를 지켜보십시오. 워크숍을 거칠 때마다 그 목록이 계속 늘어난다면 예산은 이미 범위에 뒤처져 있습니다.

아래의 신호는 각각 위의 원인 중 하나를 가리킵니다. 대부분은 주간 프로그램 리뷰에서 확인할 수 있습니다.

경고 신호	보통 의미하는 것	해야 할 일
탐색 단계 내내 WRICEF 수가 늘어남	실제 범위가 가격이 매겨진 범위보다 큼	탐색 단계가 끝나고 실현(Realize) 단계가 시작되기 전에 예산을 재설정
갭이 기본적으로 ‘개발한다’로 처리됨	표준 프로세스에 대한 문제 제기가 없음	현업 오너에게 각 갭을 표준과 비교해 정당화하도록 요청
범위 문서를 시스템 통합업체가 작성함	무엇에 가격이 매겨질지 벤더가 통제함	범위의 주도권을 가져오고 독립적인 사람과 함께 검토
변경 요청을 월 단위로 검토하거나 가격을 매기지 않음	작은 변경이 보이지 않게 누적됨	모든 변경 요청에 가격을 매기고 매주 검토
탐색 단계가 끝날 때까지 데이터 프로파일링이 시작되지 않음	데이터 문제가 테스트나 컷오버에서 드러남	지금 요구 사항 정의와 함께 프로파일링 시작
키 유저가 여전히 겸직	의사결정이 느려지고 재작업이 늘어남	본업에 대체 인력을 투입하거나 일정을 조정

각 항목은 위의 원인 중 하나에 대응합니다. 사례는 제가 직접 참여했거나 검토한 프로그램에서 나온 것입니다.

1. 범위를 직접 소유하십시오. 범위는 고객사 쪽에서 작성하고, 탐색 단계가 끝날 때 동결하며, 이후의 모든 변경은 워크숍 메모가 아니라 가격이 매겨진 의사결정으로 다루십시오.
2. 표준 프로세스를 채택하십시오. 모든 커스터마이징은 두 번 비용이 듭니다. 만들 때 한 번, 업그레이드할 때마다 또 한 번입니다. 한 제조 고객사는 커스터마이징 대신 프로세스를 SAP 표준에 맞춰 80만 달러 이상을 절감했습니다. 일부 부서에는 고통스러웠지만 재무적 차이는 엄청났습니다.
3. 롤아웃을 단계적으로 나누십시오. 한 소매 고객사는 모든 것을 한 번에 하지 않고 18개월에 걸쳐 3단계로 롤아웃을 나눠 120만 달러를 절감했습니다. 초기 투자는 40% 줄었고, 1단계에서 얻은 교훈 덕분에 이후 단계는 더 빨리 진행되었습니다.
4. 낮은 일일 단가가 아니라 전문성에 돈을 쓰십시오. 한 화학 회사 고객사는 범용 SAP 파트너에서 업계 전문 파트너로 바꿨고, 시간당 단가가 더 높았는데도 전체 비용은 20% 줄었습니다. 전문가들은 더 빨리 일했고 실수도 적었습니다.
5. 예비비를 귀사 쪽에 두십시오. 예산 위에 10~20%를 확보하고, 명시된 리스크에 대해서만 집행하십시오. 파트너 가격 안에 든 예비비는 파트너의 우선순위에 쓰입니다.
6. 변경 요청을 매주 검토하십시오. 월말이 아니라 승인 전에 건마다 예산과 일정에 미치는 영향을 산정하십시오.
7. 회귀 테스트를 자동화하십시오. Tricentis Tosca나 SAP 자체 테스트 자동화 같은 도구는 테스트 사이클이 두 번을 넘는 프로그램이라면 어디서든 본전을 뽑습니다. 그리고 가동 후 업그레이드는 매번 또 하나의 사이클입니다.

계약 측면은 제 SAP 라이선스 협상 체크리스트와 CFO를 위한 계약 비용 검토에서 서명 전에 무엇을 밀어붙여야 하는지 다룹니다.

구독 모델은 지출을 자본적 지출에서 운영 비용으로 옮깁니다. 예산 초과 리스크를 없애지는 않지만, 리스크가 놓이는 위치를 바꿉니다.

GROW with SAP는 S/4HANA Cloud Public Edition에서 운영되며, 릴리스된 인터페이스를 통한 확장만 허용합니다. 그래서 WRICEF 목록이 늘어날 수 있는 범위가 제한되고, GROW 프로그램은 대개 6~9개월이면 끝납니다. 대신 특이한 프로세스에 SAP를 맞출 자유는 줄어듭니다.

RISE with SAP는 S/4HANA Cloud Private Edition에서 운영되며, 여기서는 여전히 코어를 수정할 수 있습니다. 클린 코어가 기술적 제약이 아니라 거버넌스 결정이므로, 탐색 단계의 리스크는 온프레미스와 같습니다. RISE 프로그램은 보통 9~18개월이 걸리며, 다년 구독 기간이 비즈니스 케이스에 드러나 있어야 합니다.

AI는 확보된 절감이 아니라 새로운 예산 항목입니다. 일부 Joule 기능은 SAP 클라우드 구독에 포함되지만, 프리미엄 AI 기능은 별도로 가격이 매겨집니다. AI 절감을 내세우는 파트너 단가표가 있다면 그 뒤에 있는 생산성 가정을 요구하십시오.

이는 대형 프로그램이 손익계산서에 어떻게 반영되는지와 관련이 있습니다. IFRS와 US GAAP 모두에서, 귀사가 통제하는 자산을 구축하는 비용은 자본화할 수 있지만 운영, 교육, 준비에 드는 비용은 자본화할 수 없습니다. 클라우드에서는 예산의 큰 부분에 대해 답이 달라집니다.

비용 요소	온프레미스 라이선스	클라우드 구독(RISE / GROW)
라이선스료 또는 구독료	무형자산으로 자본화	계약 기간에 걸쳐 비용 처리(서비스 계약)
구성 및 구축 서비스	직접 귀속될 경우 자본화	IFRS: 귀사가 통제하는 별도 자산을 만들지 않는 한 비용 처리되는 경우가 많음. US GAAP: 구현 비용을 자본화하고 호스팅 기간에 걸쳐 상각
구축에 투입된 내부 인건비	직접 귀속될 경우 자본화	위와 같은 구분
교육 및 변화 관리	비용 처리	비용 처리
데이터 정제	비용 처리	비용 처리
계속 보유하는 데이터 변환 도구	재사용 가능할 경우 자본화	사안별로 판단
하이퍼케어 및 지원	비용 처리	비용 처리

IFRS 입장은 IFRS 해석위원회의 클라우드 컴퓨팅 약정의 구성 및 커스터마이징 비용에 관한 2021년 안건 결정에서 나옵니다. US GAAP 입장은 ASU 2018-15에서 나옵니다. 특히 IFRS에서는 온프레미스식 자본화를 가정한 RISE 비즈니스 케이스가 첫해 이익을 크게 부풀릴 수 있습니다.

얼마나 지킬 수 있는지는 문서화가 결정합니다. 한 제조 고객사는 제대로 자본화해 당기 비용을 230만 달러 절감했는데, 그 방식을 방어할 수 있을 만큼 컨설턴트 활동을 꼼꼼하게 기록해 두었기 때문입니다. 다른 고객사는 자본화 결정을 입증하지 못해 고통스러운 재작성에 직면했습니다.

감사인은 대규모로 자본화된 프로젝트를 깐깐하게 봅니다. 정책은 연말이 아니라 프로그램이 시작되기 전에 감사인과 합의하십시오.

예산을 초과한 프로그램 대부분은 계획에 실패한 것이 아닙니다. 계획 단계에서 정직하지 못했던 것입니다. 적절한 예비비를 포함한 현실적인 계획을 승인한 CFO는, 예비비 없는 희망 섞인 계획을 승인한 CFO보다 돈을 덜 씁니다.

이 가이드는 비즈니스 케이스부터 가동까지 모든 주제를 연결한 SAP 구축 가이드의 일부입니다.

SAP 구축은 왜 예산을 초과합니까?

가장 흔한 경우는 처음에 예산을 낮게 잡았다가 탐색 단계에서 실제 범위가 드러나는 것입니다. Fit-to-Standard 워크숍을 거치며 갭이 가격이 매겨진 적 없는 보고서, 인터페이스, 데이터 변환, 기능 확장, 양식, 워크플로로 바뀝니다. 벤더가 통제하는 범위, 겸직 내부 팀, 늦어진 데이터 작업이 상황을 더 악화시킵니다.

SAP 프로젝트는 보통 예산을 얼마나 초과합니까?

제가 검토한 프로그램에서는 40~60%의 예산 초과가 흔합니다. Panorama Consulting의 2026년 설문에서는 ERP 예산을 초과한 조직이 4분의 1을 넘었습니다. 자문가에게까지 오는 프로그램은 그 모집단 가운데 문제를 안고 있는 꼬리 부분인 경우가 많습니다.

SAP 예산 초과의 조기 경고 신호는 무엇입니까?

가장 분명한 신호는 탐색 단계 내내 계속 늘어나는 WRICEF 수입니다. 그 밖에 벤더가 작성한 범위 문서, 매주 가격이 매겨지지 않는 변경 요청, 아직 시작되지 않은 데이터 프로파일링, 여전히 겸직 중인 키 유저가 있습니다. 목록이 늘어났다면 탐색 단계가 끝날 때 예산을 재설정하십시오.

SAP 프로젝트에서 범위 확대(scope creep)를 어떻게 막습니까?

시스템 통합업체가 범위를 작성하게 두지 말고 고객사 쪽에서 소유하십시오. 탐색 단계가 끝날 때 동결하고, 모든 갭을 SAP 표준과 비교해 따져 보며, 각 변경 요청은 승인하기 전에 가격을 매기십시오. 변경 요청은 월말이 아니라 매주 검토하십시오.

RISE with SAP는 예산 초과 리스크를 줄여 줍니까?

그것만으로는 아닙니다. RISE는 코어를 여전히 수정할 수 있는 Private Edition에서 운영되므로, 탐색 단계의 리스크는 온프레미스와 같습니다. Public Edition 기반의 GROW with SAP는 확장을 릴리스된 인터페이스로 제한하므로 범위가 늘어날 수 있는 폭이 좁아집니다.

RISE with SAP 구축 비용을 자본화할 수 있습니까?

일부는 가능하며, 적용하는 회계 기준에 따라 다릅니다. 구독료 자체는 보통 비용 처리됩니다. IFRS에서는 SaaS 약정의 구성 및 커스터마이징 서비스도 귀사가 통제하는 별도 자산을 만들지 않는 한 비용 처리되는 경우가 많고, US GAAP(ASU 2018-15)에서는 구현 비용을 자본화해 호스팅 기간에 걸쳐 상각합니다.