SAP 구축 프로젝트를 제대로 시작하는 방법

SAP 구축을 제대로 시작하려면 누군가 트랜잭션 하나를 설정하기 전에 다섯 가지를 정해야 합니다. 배포 모델을 선택합니다. 범위와 의사결정 권한이 담긴 헌장에 서명합니다. 설계 워크숍에 실제로 참석할 비즈니스 오너를 지정합니다. 데이터와 컷오버 작업을 일찍 시작합니다. 현실적인 예비 기간이 들어간 일정을 짭니다. 첫 달에 이 다섯 가지를 바로잡으면 값비싼 실패의 대부분은 일어나지 않습니다.

저는 시스템만 제대로 설정하면 SAP 구축은 문제없이 굴러간다고 늘 생각했습니다. 블루프린트, 구축, 테스트, Go-Live. 수년 동안 그것이 제 머릿속 모델이었습니다.

저는 중동, 동남아시아, 유럽에서 25년간 SAP를 포함한 ERP를 구축해 왔습니다. 팀이 SAP Activate를 단계별로 충실히 따랐을 때도 프로젝트는 문제를 겪었습니다. 원인은 거의 기술적인 것이 아니었습니다. 부실한 오너십. 아무도 확인하지 않은 가정. 너무 늦게 시작한 컷오버 계획. 이런 균열은 처음에는 무해해 보입니다. 일단 번지고 나면, 일찍 보였다면 막을 수 있었던 문제를 뒤늦은 노력으로는 고칠 수 없습니다.

SAP 구축은 소프트웨어가 포함된 비즈니스 변화 프로그램입니다. 워크스트림은 프로세스 설계, 설정, 데이터 마이그레이션, 통합, 테스트, 교육, 변화 관리입니다. 각각 고유한 일정, 리스크, 오너가 있습니다.

구축을 설정 작업으로만 보는 팀은 설정이 아닌 모든 것에 예산을 덜 배정합니다. 제가 보아 온 어려운 Go-Live의 원인 중 가장 일관되게 나타나는 것이 이것입니다.

지금 시작하는 프로그램이라면 먼저 정해야 할 워크스트림이 하나 더 있습니다. 바로 배포 모델입니다. S/4HANA Cloud Public Edition(GROW with SAP), Private Edition(RISE with SAP), 아니면 온프레미스입니다. 이 선택이 다른 모든 워크스트림의 진행 방식을 좌우합니다.

SAP Activate는 SAP의 프로젝트 수행 방법론입니다. 여섯 단계로 이루어지며, 각 단계 끝에 품질 게이트가 있습니다. 아래는 단계별 목적과, 제가 절대 놓치지 않는 한 가지입니다.

단계	진행 내용	제가 확인하는 것
Discover	비즈니스 케이스, 상위 수준 범위, 배포 모델	낙관적인 수치가 아닌 현실적인 비용과 일정
Prepare	거버넌스, 헌장, 팀, 리스크 레지스터, 환경	실질적인 권한을 가진, 이름이 확정된 의사결정자
Explore	Fit-to-Standard 워크숍, 갭 결정, 설계 승인	IT만이 아니라 비즈니스 오너가 회의실에 있을 것
Realize	설정, 개발, 통합, 시스템 테스트	이미 진행 중인 컷오버 계획
Deploy	사용자 인수 테스트, 데이터 로드, 교육, 컷오버	최소 한 번의 전체 드레스 리허설
Run	Go-Live, 하이퍼케어, 지원 조직으로의 인계	첫 월 마감까지 인력이 배치된 하이퍼케어

일정 실패의 가장 흔한 원인은 Explore가 더딘 것입니다. Explore가 늦어지면 Realize가 압축되고, Realize가 압축되면 Deploy가 압축됩니다. 사용자 인수 테스트(UAT)는 단축되고, 데이터 리허설은 건너뛰며, 일정이 이미 공표되었다는 이유로 Go-Live는 그대로 진행됩니다. 그 대가는 Go-Live 후 첫 90일이 치릅니다.

1. 01Explore 지연Fit-to-Standard와 설계 승인이 밀림
2. 02Realize 압축구축과 테스트에 쓸 시간 감소
3. 03Deploy 압축UAT, 데이터 로드, 교육에 쓸 시간 감소
4. 04테스트 축소UAT 단축, 데이터 리허설 생략
5. 05공표된 날짜에 Go-Live날짜가 이미 공표되었기 때문

그 비용은 하이퍼케어에서, Go-Live 후 첫 90일에 치르게 됩니다

1. 비즈니스가 빠진 설계 승인

Explore의 산출물은 설계입니다. 그 설계의 질은 서명한 프로세스 오너가 자신이 무엇에 서명하는지 이해했는지에 달려 있습니다. 워크숍에 IT와 컨설턴트만 참석하면, 설계가 기술적으로는 맞아도 실제로 쓸 사람들에게는 낯선 것이 될 수 있습니다. 그러면 UAT는 검증이 아니라 발견의 자리가 됩니다.

간단한 테스트가 있습니다. 승인 석 달 뒤에 프로세스 오너에게 Go-Live 이후 구매 오더가 어떻게 흘러갈지 설명해 달라고 해 보십시오. 설명하지 못한다면 그 승인은 실질이 없었던 것입니다.

2. 서류상으로만 존재하는 거버넌스

거버넌스가 실제로 작동하지 않으면 범위는 비공식적으로 커지고 의사결정은 미뤄집니다. 좋은 거버넌스란 이름이 확정된 경영진 스폰서, 의사결정 권한이 정의된 운영위원회, 단계 게이트를 지켜 낼 수 있는 프로젝트 매니저, 승인자가 지정된 변경 통제 프로세스를 말합니다.

제가 맡은 대부분의 프로젝트에서 CFO가 프로젝트 챔피언 역할을 맡았습니다. 부서끼리 프로세스에 합의하지 못하면 CFO가 최종 결정을 내렸습니다. 덕분에 이슈가 해결되지 않은 채 쌓일 때 생기는 몇 주의 지연을 막을 수 있었습니다. 구성 방법은 SAP 운영위원회를 다룬 제 가이드에 있습니다.

3. 늦은 컷오버 계획

컷오버는 프로그램에서 운영상 가장 복잡한 부분입니다. Go-Live 몇 주 전에야 시작한 계획은 리허설을 거치지 못하고, 의존 관계를 놓치며, 실질적인 롤백 시점도 갖추지 못합니다.

컷오버 계획은 Realize 단계에서 시작하십시오. 작업 순서를 문서화하고, 전체 드레스 리허설을 최소 한 번 수행하며, 롤백 기준을 미리 합의해 두십시오. 스무 시간째 깨어 있는 사람들이 사전에 합의된 기준도 없이 압박 속에서 내리는 컷오버 결정, 거기서 Go-Live 이후의 재앙이 시작됩니다.

4. 밀려나는 통합 테스트

솔직히 말해 저도 테스트는 체크리스트에 있는 작업 하나라고 생각했습니다. 시스템을 설정하고, 테스트 케이스 몇 개를 돌리고, 다음으로 넘어가는 식이었습니다. 그러다 구매 승인이 재무 전기에 어떤 영향을 주는지 아무도 확인하지 않았다는 이유만으로 프로젝트가 무너지는 것을 보았습니다. 그 순간이 SAP 테스트를 보는 제 시각을 바꿔 놓았습니다.

단위 테스트는 트랜잭션 하나가 단독으로 동작한다는 것만 증명합니다. Go-Live 후에 큰 타격을 주는 실패는 전체 프로세스가 모듈을 가로질러 실행될 때 나타납니다. 구매 오더 상태 때문에 막힌 입고. 계정 결정이 누락되어 멈춘 청구 실행. 주문-수금(Order to Cash)과 조달-지급(Procure to Pay) 같은 전체 프로세스 체인을 테스트하고, 이를 UAT 직전 마지막 몇 주로 미루지 마십시오.

5. 과소평가된 데이터 마이그레이션

원천 데이터는 거의 언제나 첫 평가에서 보인 것보다 상태가 나쁩니다. 단순해 보이던 필드 매핑이 로드 단계에서 실패합니다. 레코드 수에는 비활성 데이터가 포함되어 있습니다. 정제 규칙에는 비즈니스 결정이 필요하고, 그 결정에는 시간이 걸립니다.

한 제조업체는 마이그레이션 중에 수천 건의 중복 고객 레코드를 발견했고, 이를 바로잡느라 Go-Live를 3주 미뤄야 했습니다. 처음부터 추가 로드 사이클을 계획에 넣으십시오. 자세한 내용은 SAP 데이터 마이그레이션이 실패하는 이유를 다룬 제 글에 있습니다.

6. 선택 사항으로 취급되는 변화 관리

시스템은 완벽하게 동작하는데도 사용자가 기존 프로세스를 놓지 못하는 프로젝트를 본 적이 있습니다. 사용자가 완고해서가 아니라, 아무도 전환 과정을 함께 짚어 주지 않았기 때문입니다. 변화 관리를 잘라 내면 첫 주부터 우회 방법이 생겨 그대로 굳어지고, 지원 티켓은 몇 달 동안 높은 수준을 유지합니다.

과도한 커스터마이징도 같은 범주에 속합니다. 한번은 시스템의 60퍼센트 이상을 커스터마이징한 고객사와 일한 적이 있습니다. 그 고객사는 나중에 업그레이드에 애를 먹었고 벤더 지원도 잃었습니다.

위의 기본 원칙은 달라지지 않았습니다. 오늘 프로그램을 시작한다면 처음에 세 가지를 정해야 합니다.

배포 모델이 먼저입니다. Public Edition은 커스터마이징 선택지가 가장 좁고 시스템 운영은 SAP가 맡습니다. RISE의 Private Edition은 여유가 더 있고 인프라 운영을 SAP가 맡습니다. 온프레미스는 통제권이 가장 크고 책임도 가장 큽니다. Discover 단계에서 결정하십시오. 결정을 미루는 프로그램은 Explore 기간을 그 논쟁으로 보냅니다.

Clean Core는 헌장에 들어가야 합니다. Public Edition은 릴리스된 인터페이스를 통한 확장만 허용하므로 Clean Core를 기술적으로 강제합니다. Private Edition과 온프레미스는 그렇지 않으므로 이는 거버넌스 결정이 됩니다. SAP는 이제 확장을 레벨 A(릴리스된 API만 사용)부터 레벨 D(수정)까지 분류하며, 이는 2025년 8월 Clean Core 업데이트에 정리되어 있습니다. 목표 레벨과 승인 포럼을 헌장에 명시하십시오. 그러지 않으면 파트너는 기본값으로 수정을 택합니다.

AI 도구는 첫날부터 방법론에 들어가야 합니다. Joule은 SAP Activate Roadmap Viewer 안에서 사용할 수 있습니다. Joule for consultants는 설정 관련 질문에 답하고, Joule for developers는 ABAP Cloud 코드를 생성합니다. 이런 도구는 초안 작성과 구축 작업의 속도를 높일 수 있습니다. 그렇다고 비즈니스 의사결정, 데이터 작업, 변화 관리 노력이 사라지지는 않습니다. 파트너에게 어디에 이를 쓰는지, 그것이 계획에 어떻게 반영되는지 물어보십시오.

접근 방식은 조직의 리스크 허용도, 복잡성, 변화 수용 역량에 따라 정해야 합니다. 일반적인 선택지는 다음과 같습니다.

접근 방식	의미	적합한 경우
빅뱅	모든 모듈과 법인이 동시에 Go-Live	표준 범위의 소규모 조직, 더 높은 Go-Live 리스크를 감수하는 경우
모듈별 단계적 구축	재무를 먼저, 이어서 공급망, 그다음 HR	모듈 간 의존성이 적은 경우. 단계 사이에 팀이 학습할 수 있음
국가 또는 법인별 단계적 구축	한 법인에서 템플릿을 Go-Live한 뒤 확산	글로벌 템플릿을 보유한 그룹
브라운필드 전환	기존 ECC를 S/4HANA로 전환	프로세스가 안정적인 성숙한 ECC
그린필드	신규 S/4HANA 구축	비SAP 레거시, 또는 기술 부채가 큰 ECC
선택적 데이터 전환	선택한 법인이나 데이터를 재설계한 시스템으로 이전	합병, 분사, 부분 재사용

소규모 롤아웃이 6개월 안에 Go-Live하는 것을 본 적이 있습니다. 반대로 의사결정이 제때 이루어지지 않아 2년 동안 질질 끈 프로젝트도 보았습니다. 첫 구축과 템플릿 롤아웃 중 무엇을 택할지 저울질하고 계신다면, 구축과 롤아웃의 차이를 다룬 제 가이드가 둘을 비교합니다.

첫 달, 설정을 시작하기 전에 이 목록을 사용하십시오. 각 항목에는 고객사 측 담당자가 있습니다.

1. 경영진 스폰서: 배포 모델이 결정되어 사유와 함께 기록되어 있어야 합니다.
2. 프로그램 디렉터: 범위, 명시적 제외 항목, 성공 기준, 의사결정 권한, 변경 통제를 담은 헌장에 서명이 끝나 있어야 합니다. 구두로 합의한 범위는 흔적 없이 사라집니다. 제 프로젝트 헌장 가이드에 템플릿이 있습니다.
3. 비즈니스 리드: 영역별로 프로세스 오너가 지정되어 있고, 워크숍에 참석할 시간이 실제로 확보되어 있어야 합니다.
4. 솔루션 아키텍트: Clean Core 목표와 확장 승인 포럼에 합의가 되어 있어야 합니다.
5. 데이터 리드: 설계 승인 이후가 아니라 Prepare 단계에서 데이터 프로파일링을 시작해야 합니다.
6. 컷오버 리드: Realize 단계에서 지정하고, 리허설 일자가 이미 계획에 들어 있어야 합니다.
7. 테스트 매니저: 승인부터 재무 전기까지 이어지는 구간을 포함해 전체 프로세스 체인 테스트 시나리오가 목록화되어 있어야 합니다.
8. CFO: 일정을 유사한 프로그램과 비교해 점검하고, 느린 Explore와 추가 데이터 사이클에 대비한 예비 기간을 확보해야 합니다. 모든 것이 잘 풀린다고 가정하는 계획은 계획이 아닙니다.

SAP 구축 프로젝트란 무엇입니까?

기업의 운영을 돌리기 위해 SAP 소프트웨어를 도입하는 프로그램입니다. 프로세스 설계, 설정, 데이터 마이그레이션, 통합, 테스트, 교육, 변화 관리를 포함하며, 보통 SAP Activate로 수행합니다. 법인, 국가, 모듈의 수와 기존 데이터의 상태에 따라 투입되는 노력이 크게 달라집니다.

SAP 구축은 어떤 단계로 진행됩니까?

SAP Activate는 Discover, Prepare, Explore, Realize, Deploy, Run의 여섯 단계로 이루어집니다. Discover에서 비즈니스 케이스와 범위를 정합니다. Prepare에서 거버넌스와 팀을 구성합니다. Explore에서는 Fit-to-Standard 워크숍을 열고 설계를 확정합니다. Realize에서 구축하고 테스트합니다. Deploy는 UAT, 데이터 로드, 교육, 컷오버를 포함합니다. Run은 Go-Live와 하이퍼케어입니다. 각 단계는 품질 게이트로 끝납니다.

SAP 구축에는 얼마나 걸립니까?

범위와 의사결정 속도에 달려 있습니다. 소규모 롤아웃이 6개월 안에 Go-Live하는 것을 본 적이 있고, 의사결정이 제때 이루어지지 않아 2년 동안 질질 끈 프로젝트도 보았습니다. 지연의 가장 흔한 원인은 이후의 모든 단계를 압축하는 더딘 Explore 단계입니다.

SAP 구축이 실패하는 가장 흔한 이유는 무엇입니까?

비즈니스의 실질적인 참여 없이 승인된 설계, 실행력이 없는 거버넌스, 늦은 컷오버 계획, 압축된 통합 테스트, 과소평가된 데이터 마이그레이션, 잘려 나간 변화 관리입니다. 여섯 가지 모두 대개 초기에 눈에 보이고, 그 시점에는 적은 비용으로 바로잡을 수 있습니다.

SAP 프로젝트 헌장에는 무엇이 들어가야 합니까?

측정 가능한 성과에 연결된 목표, 모듈, 법인, 국가, 통합별 범위, 명시적 제외 항목, 이름이 확정된 담당자별 의사결정 권한, 거버넌스와 에스컬레이션, 성공 기준, 변경 통제, 주요 마일스톤, 핵심 가정이 들어갑니다. 클라우드 프로그램이라면 배포 모델과 Clean Core 접근 방식을 추가하십시오. 설정을 시작하기 전에 스폰서와 비즈니스 리드의 서명을 받아야 합니다.

SAP Go-Live 이후의 하이퍼케어란 무엇입니까?

하이퍼케어는 Go-Live 직후 집중 지원을 제공하는 기간으로, 보통 30일에서 90일입니다. 프로젝트 팀과 현업이 나란히 일하며 이슈를 해결하고 운영을 안정시킵니다. 많은 문제가 처음 드러나는 시점이 첫 월 마감이므로, 최소한 첫 월 마감을 포함한 한 번의 전체 비즈니스 주기 동안은 인력을 유지하십시오.