SAP 구축 일정 계획: 단계별 기간과 피해야 할 5가지 실수

제 경험상 SAP 구축은 GROW with SAP에서 6~9개월, RISE with SAP에서 9~18개월이 걸립니다. SAP ECC에서 벗어나는 데는 브라운필드 전환이나 선택적 데이터 전환으로 12~18개월, 그린필드 구축으로 18~24개월이 걸립니다.

짧게 답하면, 날짜는 킥오프가 아니라 Explore가 끝날 때 확정하고 벤더 추정치에 15~20%의 버퍼를 더하십시오. 데이터 작업은 Discover에서 시작하십시오. 데이터 마이그레이션이 구축 공수의 30~40%를 차지하기 때문입니다. 지연이 한 달 늘어날 때마다 컨설팅 비용만으로도 최소 여섯 자리 금액이 듭니다.

이 글은 계획을 세우고 있거나 계획을 되살리려는 프로그램 디렉터와 스폰서를 위한 것입니다. 어떻게가 아니라 얼마나 걸리는지를 다룹니다. 각 단계에서 무엇을 하고 누가 하는지는 제 SAP 구축 단계별 가이드를 읽으십시오.

2024년 유럽의 한 제조업 프로그램에서, 저는 SAP 프로젝트가 일정보다 6개월 늦어진 프로젝트 매니저를 만났습니다. SAP Activate의 단계에 엄격히 맞춰 다시 정비한 뒤, 그들은 남은 작업을 4개월 만에 끝냈습니다.

그의 말입니다. “구체적인 산출물이 정해진 명확한 단계가 있었던 것이 모든 것을 바꿨습니다. 다음에 무엇을 해야 하는지 우리는 늘 정확히 알고 있었습니다.”

SAP 구축 일정을 다른 어떤 선택보다 크게 바꾸는 것은 배포 모델입니다. 제가 계획의 출발점으로 삼는 범위는 다음과 같습니다.

출발점과 목표	일반적인 기간	속도를 정하는 요인
GROW with SAP(SAP Cloud ERP, 퍼블릭 에디션)	6~9개월	표준 프로세스만 사용, 확장은 릴리스된 API 기반
RISE with SAP(SAP Cloud ERP Private)	9~18개월	범위, 확장의 수, 데이터 양
ECC 브라운필드 전환	12~18개월	커스텀 코드, 단순화 항목, 테스트
ECC에서의 그린필드 구축	18~24개월	프로세스 재설계, 사용자에게 가해지는 변화의 부담
선택적 데이터 전환	12~18개월	데이터 범위 설정과 전문 도구

비교하자면, 퍼블릭 에디션 프로젝트를 수백 건 검토한 SAP의 제품 전문가는 일반적인 Go-Live 시점을 5~7개월로 봅니다. 2026년 초에 출시된 SAP의 GROW Fast는 고정 범위로 2~4개월을 목표로 합니다. 그래도 제가 GROW 프로그램을 6~9개월로 계획하는 이유는, 소프트웨어가 쓰지 않는 시간을 데이터, 의사결정, 교육이 쓰기 때문입니다.

RISE에서는 SAP가 인프라를 운영하므로 Prepare 작업의 일부가 사라집니다. 데이터, 테스트, 변화관리 작업은 사라지지 않습니다. 브라운필드, 그린필드, 선택적 전환 중에서 어떻게 고를지는 ECC에서 S/4HANA로의 마이그레이션 가이드에서 설명합니다.

출장 및 경비 제품인 SAP Concur는 자체 프로젝트를 가진 별도의 클라우드 제품입니다. S/4HANA 단계 계획 안에 넣지 말고, S/4HANA 재무와의 자체 연계를 갖춘 독립 워크스트림으로 계획하십시오.

예산과 날짜가 무너지는 곳

제가 보는 가장 큰 실수는 처음에 제대로 계획하지 않는 것입니다. 날짜와 예산은 Explore에서 초과됩니다. 워크플로, 보고서, 인터페이스, 데이터 변환, 기능 확장, 양식(WRICEF) 목록이 늘어나고, 범위를 고객이 아니라 벤더가 쥐게 될 때입니다.

그것이 어떻게 50% 초과로 번질 수 있는지는 제 SAP 구축 비용 분석에서 보여 드립니다. 지켜지는 일정에는 세 가지 공통점이 있습니다. 현실적인 버퍼, 확정 전에 검증된 가정, 그리고 반드시 멈춰야 하는 지점으로 다루는 품질 게이트입니다.

일정 초과의 대부분은 다섯 가지 실수로 설명됩니다. 하나같이 예측할 수 있고, 하나같이 대응책이 있습니다.

실수 1: 범위를 이해하기 전에 마감일을 정하는 것

2023년 GCC의 한 유통 프로그램에서, 고객사는 버퍼 없이 9개월 만에 구축하겠다고 이사회에 약속했습니다. 데이터 마이그레이션이 예상보다 오래 걸리자 마감을 3개월 넘겼고, 경영진은 팀에 대한 신뢰를 잃었습니다. 저는 단도직입적으로 말했습니다. 그 일정은 너무 공격적이었다고요.

대응책: 일정은 킥오프가 아니라 Explore 이후에 확정하고, 이를 처음부터 이사회에 알리십시오. 벤더 추정치에 15~20%의 버퍼를 더하십시오.

실수 2: 데이터 마이그레이션을 늦게 시작하는 워크스트림으로 다루는 것

대부분의 팀은 데이터 마이그레이션 리드를 늦게 임명하고 인력을 충분히 배정하지 않습니다. 초기 데이터 평가는 거의 언제나 문제를 과소평가하고, 운영 중인 시스템의 압박 속에서 3개월간의 정제 작업이 뒤따릅니다.

대응책: 데이터 프로파일링은 Realize가 아니라 Discover에서 시작하십시오. 통합 테스트를 시작하기 전에 Realize에서 전체 모의 마이그레이션을 실행하십시오. 모의 사이클은 제 SAP 데이터 마이그레이션이 실패하는 이유 글에서 자세히 다룹니다.

실수 3: 일정 압박 속에서 품질 게이트를 건너뛰는 것

Realize와 Deploy 사이의 게이트는 팀이 가장 자주 건너뛰는 게이트입니다. ‘일단 Go-Live하자’는 압박이 거기서 정점에 이르기 때문입니다. ‘일정을 지키려고’ 품질 게이트를 건너뛰면 나중에 더 큰 지연이 생깁니다.

대응책: 측정 가능한 종료 기준을 프로젝트 헌장에 적고, 운영위원회가 이를 집행하게 하십시오. 저는 모든 프로그램에서 3일간의 결산 리허설을 준비 완료 게이트로 씁니다. 게이트 설계에 대해서는 제 SAP 품질 게이트 가이드를 참고하십시오.

실수 4: Go-Live 두 달 전에 사용자를 교육하는 것

2024년 GCC의 한 유통 프로그램에서, 고객사는 Go-Live 두 달 전에 모든 사용자를 교육했습니다. 오픈 당일에는 대부분이 시스템 사용법을 잊어버렸습니다. 저희는 모든 작업대에 업무 매뉴얼을 두고 현장 지원 인력을 두 배로 늘렸습니다.

대응책: 교육은 Go-Live 2~3주 전에 마치고, 파워 유저를 강사로 쓰십시오. 사람들은 신뢰하는 동료에게서 배우기 때문입니다. 전체 접근법은 제 SAP 직원 교육 전략 글에 있습니다.

실수 5: 비즈니스 성수기에 Go-Live를 잡는 것

Hershey는 1999년 7월 SAP R/3, Siebel, Manugistics로 구성된 시스템을 가동했습니다. 계획보다 3개월 늦었고, 곧바로 핼러윈 주문 시즌에 들어갔습니다. 이 회사의 CEO는 애널리스트들에게 이 문제 때문에 Hershey가 1억 달러 규모의 핼러윈 주문을 납품하지 못할 것이라고 말했습니다.

대응책: 영향을 받는 모든 사업 부문의 성수기를 월말 및 분기말 결산까지 포함해 정리하십시오. 6주를 미루게 되더라도 물량이 적은 시기에 Go-Live하십시오. 미룬 일정은 만회할 수 있지만, 성수기에 실패한 Go-Live는 만회할 수 없습니다.

SAP Activate에는 6개의 단계가 있으며, 클라우드든 온프레미스든 모든 S/4HANA 계획의 뼈대입니다. 아래 기간은 단일 프로그램을 위한 계획의 출발점이지 약속이 아닙니다.

1. 1Discover2~4주. 종료 조건: 범위와 성공 기준 서명
2. 2Prepare3~6주. 종료 조건: 헌장 승인, 인력 투입의 서면 확약
3. 3Explore4~8주. 종료 조건: 갭 결정에 책임자 지정, 일정 확정
4. 4Realize8~16주. 종료 조건: 모의 마이그레이션 통과, 통합 테스트 종료
5. 5Deploy2~4주. 종료 조건: UAT 승인, 결산 리허설, Go/No-Go
6. 6Run4~8주의 하이퍼케어. 종료 조건: 결함이 기준치 미만, 지원 이관 서명

제가 모든 계획의 출발점으로 쓰는 단계 표입니다.

단계	일반적인 기간	하는 일	다음으로 넘어가기 전 종료 게이트
Discover	2~4주	사업 타당성, 범위, 배포 방식 선택(퍼블릭 클라우드, 프라이빗 클라우드, 온프레미스)	범위와 측정 가능한 성공 기준 서명
Prepare	3~6주	팀 온보딩, 거버넌스, 시스템 환경, 기준 계획, 리스크 등록부	헌장 승인, 모듈별 의사결정자 지정, 인력 투입의 서면 확약
Explore	4~8주	Fit-to-Standard 워크숍, 갭 로그, WRICEF 목록	갭 결정을 책임자와 함께 기록, 일정 확정
Realize	8~16주	설정, 개발, 단위 및 통합 테스트, 모의 마이그레이션	모의 마이그레이션 통과, 통합 테스트 종료
Deploy	2~4주	사용자 인수 테스트, 컷오버 리허설, 최종 사용자 교육, 최종 데이터 적재	UAT 승인, 결산 리허설 통과, Go/No-Go
Run	4~8주 하이퍼케어	현장 지원, 일일 이슈 분류, 지원 조직으로 인계	미해결 결함이 합의된 기준치 미만, 지원 이관 서명

시간이 실제로 어디에 쓰이는가

Discover는 서둘러 지나가기 쉽습니다. 팀은 범위를 이해하기 전에 마감일을 정하고, ‘월 마감을 3일 단축한다’ 같은 측정 가능한 성공 기준을 빠뜨립니다.

온프레미스에서는 기술적 지연이 Prepare에서 시작됩니다. 고객사와 파트너가 인프라를 구축하기 때문입니다. 인력 투입 확약은 서면으로 받으십시오. 말로 한 약속은 증발합니다.

Explore에서는 기록이 중요합니다. 결정과 그 책임자를 적어 두지 않으면, 6개월 뒤에는 반품이 왜 그런 방식으로 처리되는지 아무도 기억하지 못합니다.

Realize는 가장 긴 단계이자 일정 초과가 가장 많이 몰리는 곳입니다. 대개 Explore에서 낙관적인 갭 목록이 나왔기 때문입니다. 첫 모의 마이그레이션은 실패할 것이고, 운영이 아니라 테스트에서 실패해야 합니다.

Deploy에는 정확한 절차, 시각, 책임자가 담긴 컷오버 계획이 필요합니다. ‘데이터 마이그레이션’은 절차가 아닙니다.

2023년 미국의 한 헬스케어 프로그램에서, 고객사는 일정보다 3개월 늦어졌고 200만 달러의 예산 초과에 직면해 있었습니다. 저희는 SAP Activate의 Fit-to-Standard 워크숍으로 계획을 다시 세웠습니다. 팀은 커스터마이징 없이 운영할 수 있는 프로세스 28개를 찾아냈습니다.

그 프로젝트 매니저의 말입니다. “SAP에 이미 만들어져 있던 것을 설계하느라 몇 달을 허비했습니다.” 그들은 6주 안에 일정을 되찾았습니다.

2024년 유럽의 한 유통 프로그램에서, 고객사는 자사 요구의 70%가 SAP 표준 프로세스로 충족된다는 것을 알게 되었습니다. 시스템이 실제로 돌아가는 모습을 보기 전까지는 대규모 커스터마이징을 계획하고 있었습니다.

Clean Core는 이 효과를 더 뚜렷하게 만듭니다. 퍼블릭 에디션에서는 표준 프로세스가 유일한 선택지이고, 확장은 SAP BTP나 릴리스된 API 위에 둡니다. 프라이빗 에디션과 온프레미스에서는 여전히 수정할 수 있지만, 모든 갭마다 비용이 붙은 확장 결정이 필요해지면 커스터마이징에 관한 대화가 더 정직해집니다.

업종마다 고유한 부담이 더해집니다. 아래 범위는 여러 사업장에 걸친 S/4HANA 전사 프로그램 전체를 다루므로, 9~18개월인 단일 RISE 배포보다 깁니다.

업종	계획 범위	기간을 늘리는 요인
제조	14~20개월	BOM과 라우팅 품질, MRP 튜닝, QM 요건
유통 및 소비재	12~18개월	POS 연계, 마스터 데이터 양, 성수기 일정
제약	16~22개월	GxP 밸리데이션, 배치 추적성, 일련번호 관리
유틸리티	15~20개월	설비 관리, 요금 체계, GIS 및 SCADA 연계
공공 부문	18~24개월	기금 회계, 조달 규정, 승인 부담, 데이터 상주 요건
자동차	16~22개월	JIT 공급망, 설계 변경 관리
항공우주 및 방위	20~26개월	정부 보고, 프로그램 회계, 보안 공급망
석유 및 가스	18~24개월	합작 투자 회계, 자산 집약적 운영
금융 서비스	14~20개월	직무 분리를 반영한 역할 설계, 규제 검증

AI 도구가 바꾸는 것과 바꾸지 않는 것

SAP Joule for Consultants는 2025년에 정식 출시되었습니다. SAP Notes를 포함한 SAP 자체 지식 베이스에서 설정 관련 질문에 답하고 ABAP 코드를 설명합니다. 2024년 3월부터 정식 제공된 SAP Build Code는 Joule로 SAP BTP의 Java 및 JavaScript 확장 코드를 생성합니다.

둘 다 개별 컨설턴트와 개발자에게 도움이 됩니다. 둘 중 어느 것도 워크숍, 의사결정, 데이터 정제, 사용자 인수에 걸리는 시간을 바꾸지는 못합니다. 이 도구들을 감안해 계획하되, 귀사 팀이 직접 효과를 측정하기 전까지는 계획에서 몇 주를 빼지 마십시오.

제가 매주 프로그램 회의 안건에 올리는 리스크입니다. 하나하나가 월간 운영위원회까지 방치되면 날짜를 움직입니다.

1. 늦은 범위 변경. 범위는 Explore가 끝날 때 확정하십시오. 그 이후에는 변경 통제 위원회가 일정과 예산 영향을 첨부해 모든 변경을 승인합니다.
2. 데이터 품질. 대부분의 기업은 계획 단계에서 데이터 평가를 건너뜁니다. 나쁜 데이터는 모의 마이그레이션 실패의 가장 일관된 원인입니다.
3. 인력 병목. 부서장에게서 이름이 정해진 사람과 날짜에 대한 서면 확약을 받으십시오. 모든 핵심 역할에는 백업 인력을 교육하십시오.
4. 의사결정 지연. 범위에 관한 이견은 48시간 안에 상부에 올리십시오. 결정이 월간 검토를 기다리며 쌓이게 두지 마십시오.
5. 늦은 변화관리. 최종 사용자와의 대화는 Go-Live 2주 전이 아니라 Prepare에서 시작하십시오.

도구 측면에서 SAP Cloud ALM은 구축 관리를 위한 SAP의 플랫폼입니다. SAP Solution Manager 7.2의 메인스트림 유지보수는 2027년 말에 종료되며, 일부 기능은 2030년까지 연장 유지보수가 제공됩니다. SAP Best Practices Explorer는 2023년에 종료되었고, 그 프로세스 콘텐츠는 이제 SAP Signavio Process Navigator에 있습니다.

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

SAP S/4HANA 구축에는 얼마나 걸리나요?

제 경험상 GROW with SAP(퍼블릭 에디션)는 6~9개월, RISE with SAP(프라이빗 에디션)는 9~18개월입니다. ECC에서 전환할 경우 브라운필드 전환이나 선택적 데이터 전환은 12~18개월, 그린필드 구축은 18~24개월이 걸립니다.

SAP Activate 각 단계는 얼마나 걸리나요?

계획의 출발점으로는 Discover 2~4주, Prepare 3~6주, Explore 4~8주, Realize 8~16주, Deploy 2~4주, Run은 4~8주의 하이퍼케어입니다. 대규모 프로그램에서 가장 많이 늘어나는 단계는 Realize입니다.

RISE with SAP는 일정에 어떤 영향을 주나요?

RISE는 인프라 책임을 SAP로 옮기므로 Prepare 단계의 작업 일부가 사라집니다. 데이터 마이그레이션, 테스트, 교육, 의사결정은 줄어들지 않으며, 시간 대부분이 쓰이는 곳이 바로 여기입니다. Clean Core 규율이 커스텀 개발을 시작 전에 막는다면 Realize를 줄일 수 있습니다.

SAP 구축 일정에는 버퍼를 얼마나 두어야 하나요?

벤더 추정치에 15~20%의 버퍼를 더하십시오. 날짜는 범위와 갭이 드러나는 Explore가 끝날 때 확정하고, 이를 킥오프 전에 이사회에 알리십시오.

SAP 구축 일정을 어떻게 단축할 수 있나요?

Fit-to-Standard를 철저하게 진행하십시오. 피한 커스터마이징 하나하나가 몇 주를 아껴 줍니다. 데이터 정제는 Discover에서 시작하고, 현업 인력은 겸직으로 빌려 쓰지 말고 전담으로 배정하십시오. 컷오버 계획은 Realize가 끝난 뒤가 아니라 Realize 중에 준비하십시오.

SAP 도입은 빅뱅과 단계적 방식 중 무엇을 택해야 하나요?

빅뱅은 모든 것을 한 번에 가동합니다. 전체적으로 더 빠르지만 위험이 크며, 범위가 작거나 변화관리 역량이 강한 조직에 맞습니다. 단계적 방식은 모듈, 사업장, 사업 부문별로 진행하며, 위험은 낮고 기간은 길어서 여러 법인을 거느린 대규모 그룹에 맞습니다.

SAP 프로젝트 지연의 가장 흔한 원인은 무엇인가요?

통제되지 않은 변경 요청, 예상치 못한 데이터 품질 문제, 늦은 변화관리, 외부 시스템 연계 실패, 프로젝트 도중 핵심 인력의 이탈, 운영위원회의 느린 의사결정입니다. 대부분의 팀을 놀라게 하는 것은 데이터 품질입니다. 모두가 레거시 데이터는 깨끗하다고 생각하지만, 거의 그렇지 않습니다.

SAP Go-Live 후 하이퍼케어는 얼마나 하나요?

4~8주의 하이퍼케어를 계획하십시오. 현장 지원, 일일 이슈 분류, 성능 모니터링을 합니다. 그 이후 시스템은 애플리케이션 지원 팀이나 내부 Centre of Excellence로 넘어갑니다.