SAP 구축 일정 계획: 피해야 할 5가지 실수

SAP 구축 일정은 Discover부터 하이퍼케어까지를 단계별로 짠 계획입니다. 퍼블릭 클라우드 프로젝트의 경우, 수백 건의 프로젝트를 검토한 SAP 제품 전문가는 일반적인 Go-Live 시점을 5개월에서 7개월로 봅니다. 프라이빗 클라우드나 온프레미스 기반의 엔터프라이즈 프로젝트는 1년을 훌쩍 넘깁니다. 계획이 지켜지느냐는 방법론보다 다섯 가지 계획 실수에 더 크게 좌우됩니다. 범위가 파악되기 전에 확정한 날짜, 뒤늦게 시작한 데이터 마이그레이션, 건너뛴 품질 게이트, 너무 이른 교육, 성수기 Go-Live입니다. 이 가이드는 계획을 세우거나 틀어진 계획을 되살리려는 프로젝트 디렉터와 스폰서를 위한 글입니다. 단계별 표를 뼈대로 삼고, 다섯 가지 실수에 비추어 점검해 보십시오. 지연이 한 달 늘어날 때마다 컨설팅 비용이 $100,000 이상 늘어날 수 있습니다.

제조 기업의 프로젝트 매니저 한 분을 만난 적이 있습니다. 그분의 SAP 프로젝트는 일정보다 6개월 늦어져 있었습니다. SAP Activate의 단계에 엄격하게 맞춰 계획을 다시 세운 뒤, 남은 작업을 4개월 만에 끝냈습니다. 그분의 말입니다. "단계마다 분명한 산출물이 있으니 모든 것이 달라졌습니다. 다음에 무엇을 해야 하는지 늘 정확히 알 수 있었습니다."

일정이 지켜지는 프로젝트에는 공통점이 세 가지 있습니다. 현실적인 버퍼. 확정 전에 검증한 가정. 하드 스톱으로 다루는 품질 게이트.

초과 사례 대부분은 다섯 가지 실수로 설명됩니다. 모두 예측할 수 있고, 각각 대응책이 있습니다.

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

제가 함께 일한 한 기업은 이사회에 버퍼 없이 9개월 만에 구축하겠다고 약속했습니다. 데이터 마이그레이션이 예상보다 오래 걸리자 마감을 3개월 넘겼고, 경영진은 팀에 대한 신뢰를 잃었습니다. 어드바이저로서 제 의견을 물었을 때, 저는 그 일정이 너무 공격적이라고 단호하게 말했습니다. 프로젝트 매니저는 그 일정을 받아들일 수밖에 없는 처지였습니다.

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

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

대부분의 팀은 데이터 마이그레이션 리드를 늦게 지정하고 인력도 부족하게 배치합니다. 초기 데이터 진단은 거의 항상 문제를 과소평가합니다. 그 뒤에는 운영 중인 시스템의 압박 속에서 3개월간의 정제 작업이 이어집니다.

해결책: 데이터 프로파일링은 Realize가 아니라 Discover에서 시작하십시오. 통합 테스트가 시작되기 전에 Realize에서 전체 모의 마이그레이션을 한 차례 수행하십시오. 모의 마이그레이션이 실패해도 그때는 고칠 시간이 있습니다. 컷오버 때 알게 되면 시간이 없습니다. 모의 로드 사이클은 SAP 데이터 마이그레이션이 실패하는 이유를 다룬 제 글에 자세히 나와 있습니다.

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

팀이 가장 자주 건너뛰는 게이트는 Realize와 Deploy 사이의 게이트입니다. "그냥 가동하자"는 압박이 가장 커지는 지점이기 때문입니다. "일정을 지키려고" 품질 게이트를 건너뛰면 나중에 더 큰 지연이 생깁니다.

해결책: 측정 가능한 종료 기준을 프로젝트 차터에 적고, 이를 운영위원회가 집행하게 하십시오. 재무 마감 리허설은 여기서 쓸 만한 게이트입니다. 재무팀이 마감을 깔끔하게 수행하지 못한다면 시스템은 준비되지 않은 것입니다. 게이트 설계에 대한 자세한 내용은 제 SAP 품질 게이트 가이드에 있습니다.

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

저는 Go-Live 두 달 전에 전체 사용자 교육을 마친 리테일 기업과 일한 적이 있습니다. 오픈 당일에는 모두가 시스템 사용법을 잊은 뒤였습니다. 현장마다 "복습용" 업무 안내 자료를 제공해야 했고 현장 지원 인력도 두 배로 늘렸습니다. 교육 비용 대부분이 낭비되었습니다.

해결책: 교육은 Go-Live 2-3주 전에 진행하십시오. 사람은 신뢰하는 동료에게서 배우기 때문에, 파워 유저를 강사로 쓰십시오. 복습 세션은 하이퍼케어 기간에 계획하십시오. 전체 접근법은 제 SAP 교육 전략 글에 있습니다.

실수 5: 성수기에 Go-Live 일정을 잡는 것

허시는 1999년 7월, 계획보다 석 달 늦게 SAP R/3, Siebel, Manugistics 시스템을 가동했고, 그 시점은 곧바로 핼러윈 주문 시즌과 겹쳤습니다. 당시 CEO는 애널리스트들에게 이 문제 때문에 허시가 1억 달러 규모의 핼러윈 주문을 배송하지 못하게 될 것이라고 말했습니다. 교훈은 분명한데도 여전히 무시됩니다.

해결책: 영향을 받는 모든 사업부의 성수기 주기를 월 마감과 분기 마감까지 포함해 파악하십시오. 6주가 밀리더라도 거래량이 적은 시기에 가동하십시오. 일정 이동은 만회할 수 있습니다. 성수기에 실패한 Go-Live는 만회할 수 없습니다.

SAP Activate는 예전의 ASAP 방법론을 대체했습니다. 여섯 단계는 클라우드든 온프레미스든 모든 S/4HANA 계획의 뼈대입니다. 아래 기간은 엔터프라이즈 프로젝트의 계획 출발점이지, 약속이 아닙니다.

1. 1Discover2주에서 4주. 종료 기준: 범위와 성공 기준 서명
2. 2Prepare3주에서 6주. 종료 기준: 차터 승인, 인력 서면 확보
3. 3Explore4주에서 8주. 종료 기준: 갭 결정의 담당자 지정, 일정 확정
4. 4Realize8주에서 16주. 종료 기준: 모의 마이그레이션 통과, 통합 테스트 종결
5. 5Deploy2주에서 4주. 종료 기준: UAT 승인, 마감 리허설, Go/No-Go
6. 6Run하이퍼케어 4주에서 8주. 종료 기준: 결함이 기준치 이하, 지원 이관 서명

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

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

Discover는 서둘러 넘어가기 쉽습니다. 팀들은 범위를 이해하기 전에 마감일부터 정하고 측정 가능한 성공 기준을 건너뜁니다. "월 마감을 3일 단축한다"와 같은 목표가 필요합니다.

Prepare에서 기술적 지연이 시작됩니다. RISE with SAP에서는 SAP가 인프라를 제공합니다. 온프레미스에서는 고객과 파트너가 직접 구축하며, 여기서 생긴 지연은 뒤로 연쇄적으로 번집니다. 인력 확보는 서면으로 받아 두십시오. 구두로 약속한 가용성은 사라집니다.

Explore에서는 기록이 중요합니다. 6개월 뒤에는 반품을 왜 특정 방식으로 처리하는지 아무도 기억하지 못합니다. 결정과 담당자를 적어 두지 않았다면 말입니다. 팀들은 갭의 수도 과소평가합니다.

Realize는 가장 긴 단계이고 초과는 대부분 여기서 발생합니다. 보통 Explore에서 낙관적인 갭 목록이 나왔기 때문입니다. 첫 모의 마이그레이션은 실패합니다. 그 실패가 운영이 아니라 테스트에서 일어나야 합니다. 주 60시간 근무가 이어지면 실수와 이직이 늘어납니다.

Deploy에는 정확한 단계, 시간, 담당자가 담긴 컷오버 계획이 필요합니다. "데이터 마이그레이션"은 단계가 아닙니다.

Run은 중요한 이슈가 사소한 이슈 뒤에 줄을 서면 틀어집니다. 도착 순서가 아니라 비즈니스 영향으로 우선순위를 정하고, 모든 수정 사항을 기록하십시오. 지원팀은 같은 이슈를 다시 만나게 됩니다.

저는 일정이 3개월 늦어지고 예산이 200만 달러 초과될 상황이던 의료 서비스 기업과 일했습니다. SAP Activate의 Fit-to-Standard 워크숍으로 계획을 다시 세웠습니다. 팀은 커스터마이징 없이 운영할 수 있는 재무 및 공급망 프로세스 28개를 찾아냈습니다. 프로젝트 매니저의 말입니다. "SAP가 이미 만들어 둔 것을 설계하느라 몇 달을 낭비했습니다." 팀은 6주 안에 일정을 회복했고 계획대로 가동했습니다.

저는 필요한 기능의 70%를 SAP 표준 프로세스로 충족할 수 있다는 사실을 발견한 리테일 기업과도 일했습니다. 그 기업은 시스템이 실제로 돌아가는 모습을 보기 전까지 대규모 커스터마이징을 계획하고 있었습니다.

클린 코어가 이 점을 더 분명하게 만듭니다. S/4HANA Cloud Public Edition에서는 표준 프로세스만 선택할 수 있고, 확장은 SAP BTP나 공개된 API에 둡니다. 프라이빗 클라우드와 온프레미스에서는 여전히 수정이 가능하지만, SAP의 클린 코어 지침도 같은 방향을 가리킵니다. 모든 갭이 비용이 붙은 BTP 확장 결정을 거쳐야 하면, 커스터마이징을 둘러싼 논의가 더 솔직해집니다.

배포 모델은 다른 어떤 선택보다 일정을 크게 좌우합니다.

1. 퍼블릭 클라우드(GROW with SAP, S/4HANA Cloud Public Edition, 현재는 SAP Cloud ERP로 판매). 수백 건의 프로젝트를 검토한 SAP 제품 전문가는 일반적인 Go-Live 시점을 5개월에서 7개월로 봅니다. 2026년 초에 출시된 SAP의 GROW Fast는 고정 범위에서 2개월에서 4개월을 목표로 합니다. 대규모 퍼블릭 클라우드 프로젝트는 12개월 이상 걸립니다.
2. 프라이빗 클라우드(RISE with SAP, 현재는 SAP Cloud ERP Private)와 온프레미스. 엔터프라이즈 범위는 보통 12-24개월이 걸립니다. RISE에서는 SAP가 인프라를 운영하므로 Prepare 작업 일부가 줄어듭니다. 데이터, 테스트, 변화에 들어가는 노력은 줄어들지 않습니다.

산업도 나름의 부담을 더합니다. 다음은 S/4HANA 엔터프라이즈 프로젝트 전체에 대한 일반적인 범위입니다.

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

AI 도구가 바꾸는 것과 바꾸지 못하는 것

SAP Joule for Consultants는 2025년에 정식 출시되었습니다. SAP Note를 포함한 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년 말에 종료되며, Business Suite 연장 유지보수를 선택한 고객은 일부 기능에 한해 2030년까지 연장 유지보수를 받을 수 있습니다. SAP Best Practices Explorer는 2023년에 종료되었고, 프로세스 콘텐츠는 이제 SAP Signavio Process Navigator에 있습니다.

2026년 기준 SAP 구축에는 얼마나 걸립니까?

배포 모델, 범위, 산업에 따라 다릅니다. 수백 건의 프로젝트를 검토한 SAP 제품 전문가는 S/4HANA Cloud Public Edition을 5개월에서 7개월, SAP의 고정 범위 GROW Fast를 2개월에서 4개월로 봅니다. RISE with SAP 프라이빗 클라우드나 온프레미스 기반 엔터프라이즈 프로젝트는 보통 12개월에서 24개월이 걸립니다. 공공 부문과 항공우주 프로젝트는 20개월을 넘기는 일이 흔합니다.

RISE with SAP는 일정에 어떤 영향을 줍니까?

RISE는 인프라 책임을 SAP로 옮겨 Prepare 단계 작업 일부를 없애 줍니다. 하지만 시간의 대부분을 차지하는 데이터 마이그레이션, 테스트, 교육, 의사결정은 줄여 주지 않습니다. 클린 코어 원칙을 지키면 커스텀 개발이 시작되기 전에 막을 수 있어 Realize 단계를 단축할 수 있습니다.

SAP 구축 마일스톤 계획은 어떻게 세웁니까?

여섯 개의 SAP Activate 단계로 시작해 각 게이트마다 측정 가능한 종료 기준을 적으십시오. 단계별로 크리티컬 패스 활동과 의존 관계를 파악하십시오. 게이트는 하드 스톱으로 다루고, 매주 계획 대비 진척을 추적하며, SAP Cloud ALM에서 관리하십시오.

SAP 구축 기간에 영향을 주는 요인은 무엇입니까?

가장 큰 요인은 범위(모듈, 법인, 연동), 커스터마이징 규모, 데이터 품질, 사용자 수와 지역, 의사결정 속도, 규제 검증입니다. 이 모든 위에 배포 모델이 놓입니다. 범위와 프로세스가 제한되는 퍼블릭 클라우드가 가장 빠릅니다. 커스터마이징이 많은 온프레미스가 가장 느립니다.

SAP 구축을 앞당기려면 어떻게 해야 합니까?

Fit-to-Standard를 엄격하게 수행하십시오. 커스터마이징을 하나 피할 때마다 몇 주가 절약됩니다. 데이터 정제는 Discover에서 시작하십시오. 비즈니스 인력은 파트타임으로 빌리지 말고 전담으로 배치하십시오. 승인 경로는 구성이 시작되기 전에 합의하고, 컷오버 계획은 Realize가 끝난 뒤가 아니라 Realize 중에 준비하십시오.

SAP 롤아웃은 빅뱅 방식과 단계별 방식 중 무엇을 선택해야 합니까?

빅뱅은 모든 것을 한 번에 가동합니다. 전체적으로 더 빠르지만 위험도 더 크며, 범위가 작거나 변화 관리 역량이 강한 조직에 적합합니다. 단계별 롤아웃은 모듈, 사업장, 사업부 단위로 진행합니다. 위험은 낮지만 기간이 길어지며, 법인이 여러 개인 대규모 그룹에 적합합니다. 중견 규모 프로젝트 중에는 하이브리드를 택하는 경우가 많습니다. 핵심 재무는 한 번에, 운영은 단계별로 진행하는 방식입니다.

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

통제되지 않는 변경 요청, 데이터 품질 문제의 뒤늦은 발견, 늦은 변화 관리, 서드파티 연동 실패, 프로젝트 도중 핵심 인력 이탈, 느린 운영위원회 의사결정입니다. 대부분의 팀이 가장 놀라는 것은 데이터 품질입니다. 다들 레거시 데이터가 깨끗하다고 가정합니다. 그런 경우는 거의 없습니다.

SAP Go-Live 이후에는 어떻게 됩니까?

하이퍼케어가 시작됩니다. 4주에서 8주 동안 현장 지원, 일일 이슈 분류, 성능 모니터링을 합니다. 그 뒤 시스템은 애플리케이션 지원팀이나 사내 CoE로 넘어갑니다. 첫 번째 개선 릴리스는 Go-Live 3개월에서 6개월 뒤로 계획하십시오.