SAP 구축 vs 롤아웃: 차이점과 선택 기준

SAP 구축은 SAP가 없는 곳에 시스템을 새로 세우는 일입니다. 롤아웃은 그룹 내 어딘가에서 이미 운영 중인 SAP 시스템을 새로운 국가, 법인 또는 사업부로 확장하는 일입니다. 대부분은 롤아웃을 규모가 작은 구축쯤으로 생각합니다. 이 가정이 어떤 기술적 결정보다 이런 프로그램에서 더 많은 재작업을 낳습니다.

한번은 지역 SAP 롤아웃이 플러그 앤 플레이로 끝날 것이라고 CFO가 믿도록 그대로 둔 적이 있습니다. 위험은 설명했지만 강하게 밀어붙이지는 않았습니다. 글로벌 템플릿을 쓰고 있었고, 그는 모든 거점이 큰 노력 없이 따라올 것이라고 생각했습니다. 현실은 그렇지 않았습니다. 한 지역은 추가 세무 처리가 필요했습니다. 다른 지역은 현지 법률 때문에 직원 데이터에 필수 입력 항목이 따로 있었습니다. 복사해 붙이면 될 것 같던 작업에 실제 커스터마이징이 필요했습니다.

그래서 어느 쪽을 택하느냐에 따라 인력 투입, 예산, 일하는 방식이 달라집니다. 잘못 고르면 시스템은 가동되더라도 계획한 모습은 아닐 수 있습니다.

구축은 처음부터 시작합니다. 범위를 정의하고, 프로세스를 매핑하고, 구성하고, 데이터를 이관하고, 인터페이스를 만듭니다. SAP가 없는 조직이나 레거시 시스템을 통째로 교체하는 경우에 해당합니다.

롤아웃은 이미 잘 작동하는 설계를 재사용합니다. 프로세스, 구성, 마스터 데이터 표준입니다. 일은 그 템플릿과 새 거점이 필요로 하는 것 사이의 차이를 메우는 것입니다. 세금, 법정 보고, 통화, 언어, 현지 연동, 그리고 시스템을 쓸 사람들입니다.

1. 05현지 사용자현지 프로세스에 맞추고 현지 언어로 제공하는 교육
2. 04현지 연동새 국가의 은행, 세무 신고, 물류 시스템
3. 03현지 데이터글로벌 표준에 맞춰 매핑한 고객, 공급업체, 자재 데이터
4. 02현지 요구사항세금, 법정 보고, 필수 입력 항목. 선호가 아닌 요구사항만 해당
5. 01글로벌 템플릿이미 잘 작동하는 프로세스, 구성, 마스터 데이터 표준

실무에서 두 방식을 비교하면 다음과 같습니다.

영역	SAP 구축	SAP 롤아웃
출발점	SAP가 없거나 레거시 시스템을 교체하는 경우	본사 또는 다른 법인에서 SAP가 이미 가동 중
설계	신규 설계, Fit-to-Standard	통제된 현지 편차를 허용하는 글로벌 템플릿
일반적인 기간	12~24개월, 대규모 그룹은 더 길어짐	거점당 6~12개월
주요 위험	모든 워크스트림에 걸친 미지수	현지화와 현지 준비 상태
데이터	레거시 시스템에서 전체 적재	글로벌 마스터 데이터 표준에 맞춰 매핑한 현지 데이터
테스트	전체 주기: 단위, 통합, UAT, 성능	현지화, 현지 인터페이스, UAT
변화 관리	처음부터 전체 프로그램	기존 자료를 현지 팀에 맞게 조정

구축이 맞는 경우는 다음과 같습니다.

1. 조직이 SAP를 한 번도 써 본 적이 없습니다.
2. 현재 시스템이 제 기능을 못 하고 전체를 교체해야 합니다.
3. 합병, 인수 또는 새로운 운영 모델 때문에 기존 설계가 더는 맞지 않습니다.
4. 산업별 솔루션을 처음 도입합니다. SAP for Utilities나 SAP for Public Sector가 그 예입니다.
5. 필요한 범위를 다루는 기존 템플릿이 없습니다.

구축은 시간이 더 걸리고 초기 비용도 더 듭니다. 대신 사업에 맞는 설계와, 모든 선택의 이유를 아는 팀을 얻습니다. 요구사항을 서둘러 넘긴 기업은 나중에 실수를 바로잡느라 30~50% 더 쓰게 됩니다. 이런 일을 수없이 봤습니다.

롤아웃이 맞는 경우는 SAP가 그룹 내 어딘가에서 이미 잘 돌고 있고, 핵심 프로세스가 안정적이며, 템플릿이 구조를 깨지 않고 현지 요구사항을 수용할 만큼 유연할 때입니다. 셋 중 하나라도 불안하다면, 어디에든 롤아웃하기 전에 템플릿부터 바로잡으십시오.

기술 쪽은 대체로 일정대로 끝납니다. 지연은 사람에게서, 그리고 새 국가에서는 통하지 않는 가정에서 나옵니다.

현지 팀에 강요된 템플릿

북미에서 잘 통하던 방식이 아시아나 중동에서는 맞지 않을 수 있습니다. 세금 구조, 승인 워크플로, 데이터 입력 규칙이 다릅니다. 유럽 템플릿이 중동에서도 통할 것이라고 가정한 회사와 일한 적이 있습니다. 지연과 재작업이 이어졌고 긴장도 만만치 않았습니다. 비즈니스 프로세스가 그저 너무 달랐습니다.

해법은 새 거점에 의사결정 권한을 가진 비즈니스 오너를 두는 것입니다. 본사 팀이 잘 알지 못하는 지역의 프로세스를 결정하면, 현지 사용자와 부딪히는 순간 무너지는 설계가 나옵니다.

테스트 단계에서야 발견되는 현지화

세금 처리, 법정 보고서, 필수 데이터 항목은 설계를 시작하기 전에 확정해야 합니다. 한번은 세금 구성의 사소한 차이 하나 때문에 Go-Live가 한 달 넘게 미뤄진 고객을 지원했습니다. 기술의 문제가 아니었습니다. 현지 요구사항을 충분히 일찍 확인한 사람이 없었습니다.

맞지 않는 마스터 데이터

제품 코드, 고객 번호, 공급업체 분류는 글로벌 표준과 일치해야 합니다. Go-Live 이후에 발견된 불일치는 바로잡는 비용이 크고 연결 보고를 망가뜨립니다. 현지 데이터는 UAT가 아니라 설계 단계에서 글로벌 모델에 매핑하십시오.

현지가 아니라 글로벌 시스템을 설명하는 교육

롤아웃은 최초 구축 때의 교육을 그대로 재사용하는 경우가 많습니다. 그 자료는 본사에서 시스템이 어떻게 돌아가는지를 설명합니다. 현지 조정 사항은 설명하지 않습니다. 자기 쪽 버전이 왜 다른지 모르는 사용자는 우회 방법을 만들어 냅니다.

위의 틀은 그대로 유효합니다. 템플릿의 배포 모델은 경제성과 확장 규칙 일부를 바꿉니다.

RISE with SAP(Private Edition)에서는 새 국가마다 전체 사용자 환산 단위(FUE) 기준으로 가격이 정해지는 구독에 사용자가 추가됩니다. 비용을 예측하기 쉽고 인프라 작업이 줄어듭니다. 비용은 Go-Live 이후에도 계속 발생하므로, 첫해만 보지 말고 여러 해에 걸쳐 선택지를 비교하십시오.

GROW with SAP(Public Edition)에서는 먼저 SAP가 해당 국가용 현지 버전을 제공하는지 확인하십시오. SAP는 2024년 2월 기준으로 59개 국가와 지역의 현지 버전을 공개했습니다. 그 밖의 국가에는 셀프서비스 현지화 프로그램이 있어, 파트너가 Configuration Localization Tool로 고객용 현지 버전을 만들 수 있습니다. 현재는 얼리 어답터 경로로 제공됩니다(SAP Learning). 둘 다 해당하지 않으면 롤아웃이 아니라 범위 설정의 문제입니다.

Clean Core는 모든 현지 편차에 적용됩니다. Public Edition은 공개된 인터페이스를 통한 확장만 허용합니다. Private Edition에서는 거버넌스상의 선택이지만, 허용하는 현지 수정 하나하나는 업그레이드 때마다 다시 테스트해야 할 객체가 하나 늘어나는 것이고, 그것이 국가 수만큼 곱해집니다. 제가 밀어붙이는 원칙은 단순합니다. 세법, 법정 보고, 규제 의무는 편차를 정당화합니다. 현지의 선호는 그렇지 않습니다.

다음 국가의 일정을 확정하기 전에, 아래 항목마다 "예"라는 답을 받아 두십시오. 항목마다 담당자가 있습니다.

1. 현지 비즈니스 오너(신규 국가): 지정되어 있고, 현지 설계를 승인할 권한이 있습니다.
2. 세무 및 법률 자문: 세금, 법정 보고, 필수 데이터 항목이 설계 시작 전에 문서화되어 있습니다.
3. 템플릿 오너(본사): 제안된 편차 목록이 있고, 각 항목에 요구사항인지 선호인지 표시되어 있습니다.
4. 데이터 리드: 현지 고객, 공급업체, 자재 데이터가 글로벌 표준에 맞춰 매핑되어 있습니다.
5. 연동 리드: 은행, 세무 신고, 물류 등 연결해야 하는 현지 시스템이 파악되어 있고 범위가 정해져 있습니다.
6. 변화 관리 리드: 교육이 현지 프로세스에 맞게, 현지 언어로, 현지 사례와 함께 조정되어 있습니다.
7. 프로그램 디렉터: 한 번에 한 거점씩 진행하고, 지난 Go-Live의 교훈을 다음 거점에 반영합니다.

3번 항목에는 제 범위 템플릿 가이드가 도움이 되고, 프로젝트 헌장 가이드는 의사결정 권한을 문서로 남기는 방법을 다룹니다.

이집트의 그린필드 구축. 이집트에 본사를 둔 지역 제조 기업은 낡고 서로 연결되지 않은 시스템과 많은 수작업에 묶여 있었습니다. 공급망, 생산 추적, 재무 보고가 서로 연동되지 않았습니다. 이 기업은 SAP S/4HANA를 처음부터 구축해 재무, 구매, 생산을 하나의 시스템으로 연결했습니다. 공급망 계획을 자동화했고, Go-Live 전에 4개국에서 5,000명이 넘는 직원을 교육했습니다. 서두르지 않았습니다. 운영 비용은 25% 줄었고 예측 오차는 35% 줄었습니다.

15개 시장으로의 롤아웃. 한 유통 기업은 본사에서 이미 SAP S/4HANA를 운영하고 있었고, 15개 신규 시장에 도입해야 했습니다. 시장마다 세금 규정, 통화, 비즈니스 관행이 달랐습니다. 이 기업은 글로벌 템플릿에서 출발해 거점별로 조정했고, 한꺼번에 하지 않고 2년에 걸쳐 단계적으로 롤아웃했으며, 지역별 교육을 마련했습니다. 그 결과 재무 연결 결산이 빨라졌고, 매장 전체의 재고를 실시간으로 추적하게 되었으며, 그룹 차원의 보고 정확도가 20% 높아졌습니다.

하나는 존재하지 않던 것을 만드는 일이었습니다. 다른 하나는 잘 작동하는 것을 확장하는 일이었습니다. 어느 쪽도 플러그 앤 플레이가 아니었습니다. 첫 번째 유형의 출발점에 서 계시다면, SAP 구축을 제대로 시작하는 방법을 다룬 제 가이드부터 읽어 보십시오.

SAP 구축과 SAP 롤아웃은 무엇이 다릅니까?

구축은 SAP를 처음부터 만드는 일로, 요구사항, 프로세스 설계, 구성, 데이터 이관, 연동, 테스트, Go-Live를 포함합니다. 롤아웃은 이미 있는 SAP 시스템과 그 글로벌 템플릿을 새로운 국가, 법인 또는 사업부로 확장하는 일입니다. 롤아웃의 일은 템플릿과 현지 요구 사이의 차이를 메우는 것입니다. 세금, 법정 보고, 언어, 현지 연동, 교육이 여기에 속합니다.

기업은 언제 롤아웃이 아니라 구축을 선택해야 합니까?

확장할 SAP가 없거나 레거시 시스템을 통째로 교체할 때는 구축을 선택합니다. 비즈니스 모델이 바뀌어 기존 설계가 더는 맞지 않거나 필요한 범위를 다루는 템플릿이 없을 때도 구축이 더 나은 길입니다. 맞지 않는 템플릿을 억지로 롤아웃하면 깨끗하게 새로 설계하는 것보다 재작업이 더 많이 생깁니다.

SAP 롤아웃은 구축과 비교해 얼마나 걸립니까?

구축은 보통 12~24개월이 걸리고, 대규모 그룹은 더 걸립니다. 롤아웃은 현지화, 연동, 데이터에 따라 거점당 보통 6~12개월이 걸립니다. 가장 큰 변수는 설계를 시작하기 전에 현지 요구사항을 얼마나 잘 검증했느냐입니다.

다국가 SAP 롤아웃의 가장 큰 어려움은 무엇입니까?

네 가지가 되풀이해서 나옵니다. 현지 팀의 의견 없이 강요된 템플릿. 테스트 중에 발견되는 현지화 요구사항. 글로벌 표준과 맞지 않는 마스터 데이터. 현지가 아닌 글로벌 시스템을 설명하는 교육. 대부분 기술의 문제가 아니라 사람과 계획의 문제입니다.

SAP 롤아웃은 항상 전체 구축보다 저렴합니까?

대개는 그렇습니다. 설계가 이미 있고 검증되어 있기 때문입니다. 다만 세금이나 급여 규정이 복잡한 국가, 현지 연동이 여러 개 필요한 국가, 데이터 품질이 나쁜 국가에서는 절감 폭이 줄어듭니다. RISE with SAP에서는 새 국가마다 구독료가 Go-Live 이후에도 계속되므로, 비용을 여러 해에 걸쳐 비교하십시오.

SAP 롤아웃에서 글로벌 템플릿은 어떻게 작동합니까?

글로벌 템플릿은 그룹의 표준 프로세스를 문서화하고 구성해 둔 SAP 설계입니다. 롤아웃은 모두 이 템플릿에서 출발하고, 정말로 필요한 현지 변경만 더합니다. 편차 하나하나가 업그레이드 때마다 유지보수 부담이 되므로 통제해야 합니다. 세법 같은 요구사항은 편차를 정당화하고, 선호는 그렇지 않습니다.