MDM #10. ERP 현대화에서 MDM이 실패하는 이유: SAP S/4HANA 전환의 BP·CVI·데이터 이관·Cutover 설계

SAP S/4HANA 전환 프로젝트에서 마스터 데이터 문제는 흔히 “데이터 이관”이라는 이름으로 뒤늦게 다뤄집니다.

하지만 실제로는 단순한 데이터 이동 문제가 아닙니다.

기존 ERP에서 고객과 공급업체가 어떤 기준으로 생성되었는지, 동일 법인에 여러 코드가 존재하는 이유는 무엇인지, 어떤 필드가 실제 업무에서 사용되는지, SAP Business Partner와 기존 Customer/Vendor를 어떻게 연결할 것인지, 그리고 Cutover 이후 어떤 시스템이 최종 기준정보를 생성하고 배포할 것인지를 다시 결정하는 작업입니다.

특히 SAP ERP에서 SAP S/4HANA로 전환할 경우 Customer와 Supplier/Vendor를 Business Partner(BP) 중심 구조로 전환해야 하며, SAP는 S/4HANA 전환을 위해 Customer/Supplier Integration, 즉 CVI가 적용되어야 한다고 명시하고 있습니다.

SAP Help — Business Partner Approach and Customer/Supplier Integration

SAP S/4HANA 전환의 마스터 데이터 문제는 “기존 데이터를 새 시스템으로 옮길 수 있는가”가 아니라, “새 ERP에서 신뢰할 수 있는 Business Entity를 다시 정의하고 지속적으로 유지할 수 있는가”의 문제입니다.

1. ERP Migration과 Master Data Transformation을 구분해야 합니다

일반적인 ERP 데이터 이관은 다음과 같이 설명되기 쉽습니다.

Extract
→ Transform
→ Load
→ Validate

그러나 마스터 데이터는 이것만으로 충분하지 않습니다.

고객·공급업체·자재·제품·조직 같은 마스터는 단순 레코드가 아니라 여러 업무 프로세스가 공통으로 참조하는 Business Entity이기 때문입니다.

보다 정확한 구조는 다음과 같습니다.

LEGACY MASTER DATA
↓
Entity Discovery
↓
Duplicate / Identity Resolution
↓
Target Business Definition
↓
Mapping & Transformation
↓
SAP S/4HANA Master Model
↓
Validation
↓
Post-Go-Live Governance

따라서 데이터 이관 프로젝트만 있고 MDM 설계가 없다면, 기존 ERP의 중복·예외·잘못된 의미를 새로운 ERP로 그대로 옮길 위험이 있습니다.

2. S/4HANA에서 BP와 CVI가 중요한 이유

SAP ERP에서는 Customer와 Vendor가 전통적으로 서로 다른 마스터 구조를 사용해 왔습니다.

SAP S/4HANA에서는 Business Partner가 주요 객체가 되고 Customer와 Supplier 역할이 BP와 연결됩니다.

SAP 공식 문서에 따르면 S/4HANA 전환을 위해 기존 Customer와 Supplier는 Business Partner로 변환되어야 하며, 관련 contact도 함께 검토해야 합니다.

SAP Help — Business Partner Approach

CVI는 단순 필드 복사가 아닙니다

Customer/Vendor Integration에서는 다음과 같은 설정이 서로 맞아야 합니다.

Customer/Vendor Account Group과 BP Grouping,
Number Range,
BP Role,
Customer/Supplier Role,
필수 입력 필드,
Address 및 Communication 속성,
Industry 및 기타 코드 매핑,
Customer/Vendor와 BP 간 Attribute Mapping.

SAP도 CVI 설정에서 BP Grouping과 Customer/Vendor Account Group의 key assignment 및 attribute assignment가 필요함을 명시하고 있습니다.

SAP Help — Customer/Vendor Integration Configuration

3. 가장 먼저 해야 할 일은 BP 전환이 아니라 Entity 정리입니다

기술적으로 Customer 10,000건을 BP 10,000건으로 변환하는 것은 가능할 수 있습니다.

하지만 기존 10,000건에 동일 법인이 여러 코드로 존재한다면 문제는 달라집니다.

예를 들어 다음과 같은 상황을 생각할 수 있습니다.

Legacy ID	Name	Tax Identifier	Migration Issue
C10021	ABC Korea Ltd.	123-XX-XXXXX	Customer
V07882	ABC KOREA	123XX-XXXXX	Supplier
C44201	ABC Korea Co.,Ltd	미입력	다른 영업조직에서 별도 Customer 생성

위 데이터는 설명을 위한 가상 사례입니다.

이 세 레코드가 실제로 동일 법인인지, Customer와 Supplier를 하나의 BP로 표현할 것인지, 별도 관계를 유지할 것인지는 업무 규칙을 통해 결정해야 합니다.

이것이 MDM의 역할입니다.

단순 Migration Logic

Legacy Customer
→ New BP

Legacy Vendor
→ New BP

보다 성숙한 접근은 다음과 같습니다.

Customer + Vendor + External Evidence
↓
Entity Resolution
↓
One Business Entity?
↓
BP Identity Decision
↓
Customer / Supplier Roles
↓
Target S/4HANA Structure

4. Number Range와 Identifier Strategy를 먼저 결정해야 합니다

S/4HANA 전환에서 자주 과소평가되는 문제가 번호체계입니다.

예를 들어 기존 ERP에:

Customer Number,
Vendor Number,
Global Customer ID,
Global Supplier ID,
CRM ID,
외부 사업자 식별번호

가 동시에 존재할 수 있습니다.

여기에 새로운 BP Number가 추가되면 소비 시스템은 어떤 번호를 계속 사용할 것인지 결정해야 합니다.

SAP CVI에서도 BP Grouping과 Account Group 간 number assignment를 설정할 수 있으며 동일 번호 사용 여부 역시 설계 대상입니다.

SAP Help — CVI Number Assignment

Enterprise Master ID와 SAP BP Number는 반드시 같은 개념일 필요가 없습니다

장기적인 MDM 관점에서는 ERP 기술번호와 enterprise identity를 구분하는 것이 유리할 수 있습니다.

Enterprise Supplier ID
Stable Business Identity

↓ maps to

SAP BP Number
ERP Identifier

↓ maps to

Legacy Customer / Vendor IDs
Source-System Identifiers

이렇게 하면 향후 ERP 또는 MDM 플랫폼이 변경되어도 기업 차원의 식별체계를 유지하기 쉬워집니다.

5. 한국 로컬 데이터는 Global Template에서 별도로 검증해야 합니다

글로벌 SAP Template을 적용할 때 가장 위험한 접근 중 하나는 Global BP Model이 확정되었으므로 국가별 마스터 데이터도 자동으로 해결된다고 보는 것입니다.

SAP는 South Korea를 별도의 localization 대상 국가로 지원하며, 세금 및 전자세금계산서 등 한국 고유의 업무요건을 별도로 제공합니다.

SAP Help — SAP S/4HANA Localization for South Korea

Tax Number와 Business Place를 별도 검증해야 합니다

SAP Business Partner는 국가별 Tax Number Category를 관리할 수 있으며 SAP의 현재 localized-country 목록에는 South Korea도 포함되어 있습니다.

SAP Help — Manage Tax Number Categories

또한 SAP의 한국 Localization에서는 Business Place가 VAT registration과 연결되는 조직단위이며, 사업장이 여러 개인 경우 개별 VAT registration이 존재할 수 있음을 설명합니다.

SAP Help — Business Place for South Korea

따라서 한국 전환 프로젝트에서는 단순 Name/Address migration 외에도 다음을 확인해야 합니다.

BP Tax Number Category가 올바른가?
세금 식별정보가 기존 시스템과 일치하는가?
Business Place와 VAT registration이 정확한가?
전자세금계산서 관련 master information이 유지되는가?
Customer/Supplier 통합으로 기존 로컬 필드가 누락되지 않는가?

6. Clean Core는 Clean Data와 같은 의미가 아닙니다

SAP는 Clean Core를 ERP를 표준에 가깝게 유지하고, 확장과 통합을 upgrade-safe하게 설계하기 위한 원칙으로 설명합니다.

SAP — Clean Core란?

SAP의 최근 Clean Core 관점에는 data quality와 data governance도 중요한 구성요소로 포함됩니다.

하지만 다음 두 문장은 서로 다릅니다.

Clean Core:
ERP의 기술적·프로세스적 복잡성을 통제하고 upgrade-safe한 구조를 유지한다.

Clean Master Data:
Business Entity가 정확하고 중복 없이 일관된 의미와 품질로 유지된다.

Clean Core를 추진한다고 해서 중복 Customer나 잘못된 Supplier identity가 자동으로 해결되지는 않습니다.

7. Migration Cockpit은 MDM을 대신하지 않습니다

SAP S/4HANA Migration Cockpit은 데이터 이관을 위한 중요한 표준 도구입니다.

현재 SAP 문서상 Migration Cockpit에서는:

Migration Project 생성,
Migration Object 선택,
Mapping Task 수행,
Migration Simulation,
Migration 실행,
Migration Status Monitoring

을 지원합니다.

SAP Help — Migrate Your Data: Migration Cockpit

그러나 Migration Cockpit이 다음을 결정해 주지는 않습니다.

두 Supplier가 같은 법인인지,
어떤 Source가 authoritative한지,
Customer와 Supplier를 하나의 BP로 볼 것인지,
어떤 중복을 병합해야 하는지,
Global Attribute와 Local Attribute를 어떻게 구분할지.

이것이 Migration과 MDM을 구분해야 하는 이유입니다.

8. Migration 전 Validation Rule을 먼저 만들어야 합니다

데이터를 옮긴 다음 품질검사를 하는 접근은 너무 늦습니다.

Migration 대상 데이터가 target model을 만족하는지를 사전에 검증할 수 있어야 합니다.

Validation Area	Example Rule	Failure Meaning
BP Identity	하나의 enterprise entity에 충돌하는 복수 BP 후보가 없는가?	Entity resolution 필요
CVI Mapping	대상 Account Group이 유효한 BP Grouping 및 Role과 연결되는가?	Conversion 오류 가능
Required Field	Target BP/CVI에서 필수인 속성이 모두 존재하는가?	Load 또는 Synchronization 실패
Tax Identifier	적용되는 Tax Number Category와 식별값이 정의되어 있는가?	세무·거래처 식별 오류 가능
Organization Extension	필요한 Company Code / Purchasing / Sales 조직정보가 존재하는가?	Go-Live 이후 거래 불가 가능
Reference Data	Country, Currency, Industry 등 코드가 target reference와 매핑되는가?	Transform 오류
Relationship	Parent/Child 및 Contact 관계의 모든 reference가 존재하는가?	Hierarchy 단절

위 검증 규칙은 Digital Future & Strategy practitioner framework이며 SAP 표준 Migration Rule 목록이 아닙니다. 실제 규칙은 기업의 SAP configuration과 데이터 모델에 맞춰 설계해야 합니다.

9. Record Count만 맞으면 Migration 성공이라는 생각이 가장 위험합니다

예를 들어 Source 100,000건이 Target 100,000건이면 숫자는 일치합니다.

하지만 다음과 같은 오류는 그대로 존재할 수 있습니다.

같은 법인이 두 개 BP로 생성됨,
Customer Role은 있으나 Supplier Role이 누락됨,
Tax Identifier가 잘못된 BP에 매핑됨,
Hierarchy가 누락됨,
Purchasing Organization extension이 누락됨,
Inactive Supplier가 Active로 전환됨.

따라서 Migration Validation은 최소한 다음 세 층으로 나눠야 합니다.

LEVEL 1
Technical Reconciliation
Count · Load Status · Error

↓

LEVEL 2
Business Validation
Attribute · Role · Relationship · Organization

↓

LEVEL 3
Entity Validation
Identity · Duplicate · Authority · Business Usability

10. Customer와 Supplier가 같은 Entity일 때 Migration 순서도 중요합니다

SAP의 현재 Migration documentation은 Business Partner가 Customer와 Supplier 양쪽에 연결된 경우 migration object 간 순서를 고려해야 한다고 명시합니다.

일부 S/4HANA migration scenario에서는:

Business Partner
↓
Customer
↓
Supplier

와 같은 의존관계를 요구할 수 있습니다.

SAP Help — Customer Migration Object and BP Dependencies

따라서 개별 migration object만 테스트해서는 전체 business entity가 제대로 전환되었는지를 판단할 수 없습니다.

11. Cutover에서 가장 어려운 문제는 마지막 변경분입니다

사전 데이터 정리가 완료되었더라도 Cutover 직전 Source ERP에서 Customer나 Supplier가 계속 변경될 수 있습니다.

SAP 역시 migration 과정에서 일부 master data object에 대해 change freeze 또는 double maintenance가 필요할 수 있음을 설명합니다.

SAP Help — What Data Can Be Migrated?

따라서 Cutover Plan에는 단순한 migration job 시간이 아니라 다음이 포함되어야 합니다.

Master Data Freeze 시점,
Freeze 예외 승인 절차,
Delta extraction 기준시점,
Delta load,
Source-to-Target reconciliation,
신규 BP 생성 재개 시점,
구 시스템 변경 차단 여부,
Rollback 시 데이터 처리방법.

12. Cutover Gate를 숫자로 정의해야 합니다

“데이터가 거의 정리되었습니다”는 Go-Live 판단 기준이 될 수 없습니다.

Cutover 승인에는 명확한 exit evidence가 필요합니다.

Gate	Evidence	Decision
Load Completion	모든 in-scope object가 성공적으로 load 또는 승인된 exception으로 분류됨	미분류 오류가 있으면 Hold
Critical Attribute	업무 Critical Field validation 완료	Critical 오류는 원칙적으로 Go-Live 전 해결
BP/CVI Integrity	BP-Customer-Supplier mapping exception 검토 완료	미해결 구조오류가 있으면 Hold
Duplicate	High-confidence duplicate 후보의 disposition 완료	업무영향도에 따라 승인
Reconciliation	Source와 Target의 주요 entity 및 조직단위 reconciliation 완료	설명되지 않는 차이는 Hold
Business Test	대표 Supplier/Customer를 활용한 실제 P2P/O2C 업무 시나리오 검증	Transaction 실패 시 원인 해결

구체적인 허용오류율과 threshold는 업무 중요도 및 회사의 Go-Live risk appetite에 맞춰 정해야 하며, 일반적인 글로벌 수치를 그대로 적용해서는 안 됩니다.

13. Test Migration은 한 번으로 끝나지 않습니다

SAP도 Migration Cockpit 절차에서 test system에서 migration project를 만들고 반복적인 test transfer 과정에서 발견한 correction과 refinement를 다음 migration project에 반영하는 접근을 설명합니다.

SAP Help — SAP S/4HANA Migration Process

MDM 관점에서 각 mock migration은 단순 기술 rehearsal이 아니라 데이터 품질을 개선하는 cycle이어야 합니다.

MOCK 1
Discover Structural Problems
↓
Cleanse & Correct Rules
↓
MOCK 2
Validate Entity & Mapping
↓
Correct Remaining Exceptions
↓
MOCK 3
Cutover Rehearsal
↓
Production Migration

14. MDM을 ERP Project 하위 Workstream으로만 두면 실패하기 쉽습니다

ERP 프로젝트는 Go-Live 날짜를 중심으로 움직입니다.

MDM은 Go-Live 이후에도 계속 운영되어야 합니다.

이 차이가 중요합니다.

ERP 프로젝트의 Data Migration 팀이 다음을 책임질 수 있습니다.

대상 데이터 추출,
Migration Mapping,
Load execution,
Technical reconciliation.

반면 지속적인 MDM 체계는 다음을 책임져야 합니다.

마스터 생성 정책,
Entity identity,
Duplicate prevention,
Data ownership,
Quality rule,
Change workflow,
Data distribution,
Post-go-live monitoring.

Migration Team과 MDM Team의 책임을 분리해야 합니다

ERP Migration	MDM
어떻게 Target으로 이동할 것인가?	어떤 Business Entity가 맞는가?
Migration Object Mapping	Enterprise Semantic Definition
Load / Simulation	Match / Merge / Survivorship
Cutover	Ongoing Governance
Project 종료	지속 운영

15. Go-Live 이후 재오염을 막는 것이 더 어렵습니다

Migration 과정에서 데이터 품질을 크게 개선했더라도 기존 생성 프로세스를 그대로 유지하면 품질은 다시 악화될 수 있습니다.

예를 들어 다음 문제가 반복될 수 있습니다.

사용자가 기존 Supplier를 찾지 않고 신규 Supplier를 생성,
필수 식별값 없이 임시 Customer 생성,
지역별 조직이 자체 local code를 사용,
수동 interface로 잘못된 값이 재유입,
Merge 후 downstream system이 다시 legacy record를 생성.

따라서 S/4HANA 전환의 MDM 성공조건은 Migration Quality가 아니라 Post-Go-Live Control까지 포함해야 합니다.

16. SAP S/4HANA 전환을 위한 MDM Control Architecture

LEGACY ERP / CRM / LOCAL SYSTEMS

↓

ENTITY PROFILING
Duplicate · Identifier · Quality · Relationship

↓

MDM DECISION LAYER
Enterprise Identity · Match · Merge · Ownership

↓

SAP TARGET DESIGN
BP · Customer · Supplier · Roles · Organization

↓

CVI & MIGRATION
Mapping · Simulation · Load · Reconciliation

↓

SAP S/4HANA
Authoritative Transaction Context

↓

POST-GO-LIVE GOVERNANCE
Create · Change · Quality · Duplicate Prevention · Audit

17. 프로젝트 착수 전에 확인할 15가지 질문

1. 기존 Customer와 Supplier 중 실제 동일 법인은 몇 개인가?

2. BP identity를 결정하는 기업 기준은 무엇인가?

3. Enterprise ID와 SAP BP Number를 동일하게 사용할 것인가?

4. Account Group과 BP Grouping mapping이 확정되었는가?

5. Customer/Supplier Role mapping은 완전한가?

6. 기존 필수 필드와 S/4HANA BP 필수 필드의 차이를 분석했는가?

7. 한국 Tax Number와 Business Place 관련 로컬 요건을 검증했는가?

8. Custom Field를 모두 이관할 것인가, 일부를 폐기할 것인가?

9. Parent/Child hierarchy와 Contact relationship을 어떻게 전환할 것인가?

10. Migration 전 duplicate disposition 기준이 있는가?

11. Mock Migration마다 품질 개선이 실제로 일어나는가?

12. Cutover 중 master-data freeze와 delta 처리 방식은 무엇인가?

13. Record Count 외에 business validation rule이 정의되었는가?

14. Go-Live 이후 master 생성·변경의 Owner는 누구인가?

15. ERP 프로젝트가 종료된 뒤에도 품질을 유지할 MDM 운영체계가 있는가?

ERP 현대화에서 MDM의 진짜 역할

SAP S/4HANA 프로젝트에서 마스터 데이터는 마지막 단계에 정리하는 데이터셋이 아닙니다.

ERP가 처리할 Business Entity를 정의하는 기반입니다.

Customer와 Supplier를 BP로 변환하는 것은 SAP S/4HANA 전환의 중요한 기술조건입니다.

하지만 기술적 CVI 성공이 곧 MDM 성공을 의미하지는 않습니다.

더 중요한 질문은 다음과 같습니다.

WHO IS THE BUSINESS ENTITY?
↓
WHICH RECORD IS AUTHORITATIVE?
↓
WHICH ATTRIBUTES MUST SURVIVE?
↓
HOW IS IT REPRESENTED IN S/4HANA?
↓
HOW WILL IT REMAIN TRUSTED AFTER GO-LIVE?

ERP Migration은 이 데이터를 새로운 시스템으로 옮깁니다.

MDM은 무엇을 옮겨야 하는지를 결정하고, Go-Live 이후에도 그것이 올바른 상태로 유지되도록 합니다.

SAP S/4HANA 전환에서 가장 위험한 데이터 오류는 migration job이 실패하는 오류가 아닙니다. Migration은 성공했지만 잘못된 Business Entity가 새로운 ERP의 기준정보가 되는 오류입니다.

Sources & Further Reading

Method Note
이 글은 SAP S/4HANA 전환에서 발생하는 마스터 데이터 문제를 MDM 관점에서 해석한 실무 프레임워크입니다. Business Partner, Customer/Supplier Integration, Migration Cockpit, South Korea localization 관련 제품 사실은 2026년 9월 기준 SAP 공식 문서를 중심으로 검증했습니다. 본문의 가상 레코드, Validation Matrix, Cutover Gate 및 MDM Control Architecture는 SAP 표준 방법론이 아니라 Digital Future & Strategy practitioner framework입니다. 실제 프로젝트의 BP Role, Account Group, Number Range, Tax Category, Migration Object, 필수필드 및 허용 오류기준은 각 기업의 SAP release, configuration, scope 및 법적 요구사항에 맞추어 검증해야 합니다.

Reviewed: September 2026

Global English Companion

이 글의 글로벌 관점 영문판은 아래 글에서 별도로 다룹니다.

MDM #10. Why MDM Fails During ERP Modernization: Lessons from SAP S/4HANA

영문판은 글로벌 ERP transformation 관점에 초점을 두고, 본 한국어판은 BP/CVI와 한국 localization 및 Cutover control을 보다 구체적으로 다룹니다.

이전 글: 한국 대기업 MDM 거버넌스의 현실

다음 글: How Cloud Platforms Are Reshaping the MDM Stack

Search This Blog

Digital Future & Strategy