MDM #7. MDM 프로젝트는 왜 경영진의 지원을 받지 못하는가: 투자승인을 얻는 Business Case Playbook

MDM의 필요성을 설명하는 것은 어렵지 않습니다.

중복된 고객, 서로 다른 Supplier Code, 일관되지 않은 Product Hierarchy, 반복적인 수작업 보정, ERP 간 Master 불일치가 존재한다면 대부분의 경영진도 문제가 있다는 사실에는 동의합니다.

그런데 다음 질문에서 MDM 프로젝트가 멈추는 경우가 많습니다.

“문제가 있다는 것은 이해했습니다.
그런데 왜 지금 이 예산을 MDM에 투자해야 합니까?”

이 질문은 MDM을 부정하는 질문이 아닙니다.

투자 의사결정자로서는 당연한 질문입니다.

ERP 현대화, AI, Cybersecurity, Cloud, Regulatory Program, Digital Commerce 등 수많은 프로젝트가 동일한 예산을 놓고 경쟁하기 때문입니다.

이때:

“Single Source of Truth가 필요합니다.”

“Data Quality를 개선해야 합니다.”

“Golden Record를 구축해야 합니다.”

라는 설명만으로는 충분하지 않을 수 있습니다.

경영진이 MDM에 투자하는 이유는 Master Data가 중요하기 때문이 아니라, 신뢰할 수 없는 Master Data가 이미 중요한 Business Outcome을 방해하고 있기 때문이어야 합니다.

따라서 MDM Business Case의 출발점은 MDM이 아니라 경영진이 이미 중요하게 생각하는 Business Problem이어야 합니다.

1. MDM은 왜 다른 IT 투자보다 설명하기 어려운가

MDM의 가치는 대부분 간접적으로 나타납니다.

Duplicate Supplier 하나가 즉시 손익계산서의 비용항목으로 표시되지는 않습니다.

대신 다음과 같은 방식으로 영향을 미칠 수 있습니다.

Supplier Onboarding 반복,
구매실적 분산,
Risk Screening 중복,
Payment 또는 Tax 정보 불일치,
수작업 Reconciliation 증가,
Analytics에서 동일 업체가 여러 회사처럼 집계.

Customer Master 문제 역시:

고객 360 분석 실패,
Account Hierarchy 불일치,
중복 영업활동,
서비스 이력 단절,
마케팅 대상 오류

등의 형태로 나타날 수 있습니다.

즉:

MASTER DATA PROBLEM
↓
PROCESS FRICTION
↓
BUSINESS IMPACT
↓
FINANCIAL / RISK CONSEQUENCE

라는 중간단계가 존재합니다.

MDM Business Case가 어려운 이유는 바로 이 연결고리를 증명해야 하기 때문입니다.

2. “Data Quality 개선”을 Business Case로 제출하면 약한 이유

다음과 같은 Business Case를 생각해 볼 수 있습니다.

현재 Supplier Duplicate Rate: 6%
목표 Duplicate Rate: 2%
개선: 4%p

Data Management 관점에서는 의미 있는 목표입니다.

하지만 투자위원회는 다음 질문을 할 수 있습니다.

그래서 무엇이 달라집니까?

Supplier 중복 4%p 개선이
구매비용, 처리시간, Risk, ERP 전환 또는 AI에
어떤 영향을 줍니까?

따라서 기술 KPI와 Business Outcome 사이에 한 단계가 더 필요합니다.

MDM Metric	Operational Effect	Business Outcome
Duplicate Supplier 감소	중복 Onboarding·Reconciliation 감소	운영효율 및 Spend Visibility 개선
Product 필수속성 오류 감소	승인·게시 Rework 감소	Product Launch Lead Time 개선
Customer Identity 정합성 향상	Account 중복·수작업 통합 감소	영업·서비스 Context 개선
Master Creation Lead Time 감소	업무대기 감소	구매·생산·판매 Process 속도 개선

3. MDM에서 시작하지 말고 Business Friction에서 시작한다

예를 들어 Supplier MDM 투자를 설득한다고 가정해 보겠습니다.

MDM 중심의 설명은 이렇게 시작할 수 있습니다.

“Supplier Master가 여러 ERP에 분산되어 있으므로 Global Supplier MDM을 구축해야 합니다.”

틀린 설명은 아닙니다.

그러나 경영진 관점에서는 다음 설명이 더 직접적입니다.

현재 문제
같은 Supplier가 여러 ERP와 법인에 서로 다른 코드로 존재한다.

업무영향
Enterprise Spend가 분산되어 전략적 구매분석이 어렵고, Supplier Onboarding과 Risk Review가 반복된다.

원인
기업 공통 Supplier Identity, 핵심속성, 생성·변경 Rule과 Owner가 없다.

개선방향
공통 Identity와 핵심속성을 MDM으로 관리하고, 각 ERP의 로컬 Context는 필요한 범위에서 유지한다.

MDM이 Technology Project에서 Business Intervention으로 바뀌는 순간입니다.

4. Business Case를 “Evidence Chain”으로 만든다

MDM의 장점을 여러 개 나열하기보다 하나의 논리사슬로 만드는 것이 효과적입니다.

BUSINESS PRIORITY
↓
PROCESS FRICTION
↓
MASTER DATA CAUSE
↓
MDM INTERVENTION
↓
OPERATIONAL CHANGE
↓
BUSINESS OUTCOME

Supplier 예시는 다음과 같이 만들 수 있습니다.

단계	설명
Business Priority	구매효율과 Supplier Risk Visibility 개선
Process Friction	여러 조직에서 동일 Supplier를 각각 등록·검증
Master Data Cause	공통 Identity와 Classification 부재
MDM Intervention	Global Identity, Matching, 핵심속성, Governance Workflow 구축
Operational Change	중복생성·수작업 Reconciliation 감소
Business Outcome	더 나은 Spend Visibility, Onboarding 효율, Risk Control 가능성

마지막 결과를 일부러 “가능성”이라고 표현하는 것이 중요합니다.

MDM은 많은 경우 Business Outcome의 Enabler이지 유일한 원인이 아니기 때문입니다.

5. 경영진 설득에서 가장 중요한 것은 Baseline이다

미래의 효과를 크게 설명하기 전에 현재 문제를 측정해야 합니다.

예를 들어 다음을 측정할 수 있습니다.

월간 신규·변경 Master 요청건수,
Master 생성 평균 및 중앙 Lead Time,
반려·재작업 비율,
Duplicate 및 Duplicate Candidate 건수,
Critical Attribute 오류,
Manual Correction 시간,
동일 Entity를 독립관리하는 시스템 수,
Master 오류로 발생한 Business Exception.

Baseline의 목적은 거대한 ROI 숫자를 만드는 것이 아닙니다.

현재 문제가 실제로 존재한다는 것을 증명하는 것입니다.

6. 먼저 “아무것도 하지 않을 경우”를 보여준다

Investment Case는 투자효과만 설명하면 반쪽입니다.

경영진은 다음 두 선택을 비교합니다.

OPTION A
Invest in MDM

versus

OPTION B
Continue Current State

따라서 Business Case에는 Cost of Inaction이 들어가야 합니다.

예를 들어:

ERP Migration 때 동일 Data Cleansing을 다시 수행해야 함,
신규 AI Use Case마다 Customer/Supplier Identity를 다시 정리해야 함,
수작업 Reconciliation이 계속 발생,
Cross-System Reporting 불일치 유지,
신규 법인·서비스 연결 때마다 Point-to-Point Mapping 추가

등입니다.

단, “안 하면 큰 사고가 난다”는 식으로 과장해서는 안 됩니다.

현재 상태를 유지할 경우 확실하게 계속되는 비용·지연·제약과 가능성이 있는 Risk를 분리해야 합니다.

7. Sponsor는 MDM을 좋아하는 임원이 아니라 Outcome을 소유한 임원이어야 한다

Executive Sponsor가 필요하다는 말은 흔합니다.

그러나 아무 임원이나 Sponsor가 되면 되는 것은 아닙니다.

보다 중요한 질문은:

“이 MDM 프로젝트가 개선하려는
Business Outcome을 현재 누가 책임지고 있는가?”

입니다.

예를 들어:

Initial Business Problem	Sponsor 후보의 논리
Supplier Fragmentation	구매·SCM Outcome을 책임지는 Business Executive
Customer Identity	영업·Customer Operation 등 해당 Outcome 책임 임원
ERP Migration Readiness	ERP Transformation Sponsor와 Data Executive의 공동 Sponsorship
Enterprise Data / AI Foundation	CDO/CIO와 실제 AI Use Case Business Sponsor의 연계

CIO나 CDO의 Sponsorship은 여전히 중요합니다.

하지만 Business Outcome을 소유한 임원이 공동 Sponsor가 되면 Cross-functional 변화에 대한 권한과 책임이 더 명확해집니다.

Sponsor에게 필요한 것은 이름이 아니라 네 가지 행동이다

Sponsor 역할	실제 행동
Priority	MDM Outcome을 Business Priority와 연결
Decision	Cross-functional conflict가 해결되지 않을 때 결정
Resource	Data Owner·Steward·Business SME 참여를 확보
Accountability	구축성과가 아니라 Business Outcome을 Review

명목상 Sponsor가 Kick-off에 참석하고 이후 모든 회의를 PM에게 위임한다면 충분한 Sponsorship이라고 보기 어렵습니다.

8. 경영진에게 한 번에 Enterprise MDM 전체를 승인해 달라고 하지 않는다

MDM은 첫 투자부터 범위가 크게 보이기 쉽습니다.

Customer + Supplier + Product + Material
+ Global Governance
+ New Platform
+ ERP Integration
+ Data Cleansing
+ AI Enablement

투자 의사결정자는 아직 효과를 본 적이 없는데 높은 금액과 조직변화를 한 번에 승인해야 합니다.

더 나은 접근은 Staged Investment입니다.

PHASE 1
Prove the Problem

↓

PHASE 2
Prove the MDM Intervention

↓

PHASE 3
Prove Operational Value

↓

PHASE 4
Scale to Additional Domains

9. Pilot보다 Proof of Value가 더 중요하다

기술 Pilot은 시스템이 작동한다는 것을 보여줍니다.

Proof of Value는 이 투자가 Business Problem을 개선할 수 있다는 증거를 보여줘야 합니다.

Technology Pilot	Proof of Value
Matching Engine가 동작하는가?	중복 Supplier로 인한 실제 업무문제를 줄일 수 있는가?
Workflow가 동작하는가?	Master Creation Lead Time과 Rework가 줄어드는가?
API가 연결되는가?	Consumer가 신뢰 가능한 Master를 재사용할 수 있는가?
DQ Rule을 만들 수 있는가?	Critical Business Error 유입을 실제로 차단할 수 있는가?

10. 각 투자단계에 Decision Gate를 둔다

경영진이 신뢰하기 쉬운 Business Case는 성공만을 가정하지 않습니다.

확대할 조건뿐 아니라 변경하거나 중단할 조건도 제시합니다.

Gate	증명할 것	Decision
Problem Gate	Baseline으로 문제가 실재함을 확인	투자검토 지속 / 중단
Design Gate	Owner·Scope·Target Model·Operating Model 합의	Build 승인
Value Gate	선정 Use Case에서 측정 가능한 개선	Scale / Correct / Stop
Scale Gate	운영모델이 재사용 가능함을 증명	다음 Domain 확장

Decision Gate 모델은 Digital Future & Strategy practitioner framework입니다.

11. “Why Now?”에 답하지 못하면 Priority에서 밀린다

MDM 문제는 수년 동안 존재했던 경우가 많습니다.

따라서 경영진은 자연스럽게 질문합니다.

“10년 동안 있던 문제라면
왜 올해 해결해야 합니까?”

좋은 Business Case는 새로운 Trigger를 찾아야 합니다.

예를 들어:

S/4HANA 또는 ERP Transformation,
AI Agent Deployment,
Global Data Platform 구축,
신규 Digital Commerce,
M&A 통합,
Supplier Risk Program,
새로운 규제·통제 요구,
Legacy Platform 종료

등입니다.

MDM 자체가 Urgency를 만드는 것이 아니라 다른 전략과제에 필요한 데이터 의존성이 Urgency를 만듭니다.

12. “왜 MDM이어야 하는가?”라는 질문을 먼저 스스로 한다

모든 데이터 문제에 MDM이 필요한 것은 아닙니다.

이 점을 인정하는 Business Case가 오히려 더 강합니다.

다음 질문을 해봐야 합니다.

문제	더 단순한 해결방법은 없는가?
한 시스템의 필수값 누락	Source Application Validation으로 해결 가능한가?
보고서 Mapping 오류	Analytics Transformation 문제인가?
한 Process의 승인 지연	Workflow 개선만으로 해결 가능한가?
여러 시스템에서 같은 Entity를 서로 다르게 관리	Enterprise MDM 또는 공유 Mastering Capability가 필요한가?

MDM을 쓰지 않아도 되는 문제까지 MDM 범위에 포함하면 투자규모와 복잡도만 커집니다.

13. 경영진에게 제시하는 Value를 네 가지로 분리한다

모든 Benefit을 하나의 ROI 숫자에 넣지 않는 것이 좋습니다.

Value Type	예시	경영진 보고방법
Direct Financial	외부비용 제거, 실제 운영비 감소	근거가 충분할 때 금액화
Productivity	Manual Correction·Reconciliation 시간 감소	Cash Saving과 Capacity Release 구분
Risk Reduction	잘못된 Supplier·Customer·Product 정보에 대한 Control 개선	Exposure와 Control Improvement 중심
Strategic Enablement	ERP·AI·Analytics·Data Product의 공통 Master 기반	Guaranteed ROI가 아닌 Dependency로 설명

정교한 ROI·TCO·NPV 계산방법은 별도의 MDM #13 Business Case 글에서 다루는 것이 좋습니다.

MDM #13. Building the MDM Business Case: Baseline, Attribution, TCO and Realized Value

14. 경영진에게 절대 숨기지 말아야 할 것은 Uncertainty다

Business Case가 신뢰를 잃는 가장 빠른 방법은 추정치를 사실처럼 표현하는 것입니다.

예를 들어 ERP Transformation과 함께 Supplier MDM을 개선한 뒤 Supplier Onboarding Lead Time이 30% 줄었다고 가정해 봅시다.

그 효과에는:

MDM,
Workflow 재설계,
Approval 단계 축소,
신규 Procurement Platform,
정책표준화

등이 동시에 기여했을 수 있습니다.

따라서 경영진 보고에서 다음을 구분하는 것이 더 신뢰할 만합니다.

Directly Attributable
MDM 변경과 직접 연결되는 효과

Jointly Enabled
MDM과 Process Transformation이 함께 만든 효과

Strategic Dependency
Trusted Master가 필요하지만 현재 금액화하기 어려운 가치

Uncertainty를 밝힌다고 Business Case가 약해지는 것은 아닙니다.

오히려 어떤 부분이 측정값이고 어떤 부분이 가정인지 명확해집니다.

15. MDM 비용에는 Governance 운영비까지 들어가야 한다

MDM 투자비를 다음처럼 계산하면 불완전합니다.

Software
+ Implementation Partner

실제 운영에는 다음이 추가될 수 있습니다.

Initial Data Cleansing,
Integration 개발,
Data Model 및 Rule 설계,
Business SME 참여,
Data Owner / Steward Capacity,
Platform Operation,
Quality Monitoring,
Training 및 Change Management,
지속적 개선 및 Support.

Governance 인력과 운영비를 제외하고 계산한 ROI는 Go-Live 이후 유지할 수 없는 Business Case가 될 수 있습니다.

16. 경영진 1페이지에 무엇을 넣어야 하는가

40장의 기술자료가 있어도 경영진용 핵심 논리는 한 페이지에서 설명할 수 있어야 합니다.

1. Business Problem
현재 어떤 Business Friction 또는 Risk가 존재하는가?

2. Evidence
현재 문제를 증명하는 Baseline은 무엇인가?

3. Master Data Cause
왜 이 문제에 Master Data가 기여하고 있는가?

4. First Intervention
처음 해결할 Domain·Process·Scope는 어디까지인가?

5. Expected Outcome
무엇을 측정해 개선 여부를 판단할 것인가?

6. Investment
Technology·People·Governance를 포함해 무엇이 필요한가?

7. Uncertainty
현재 검증되지 않은 가장 중요한 가정은 무엇인가?

8. Decision Gate
어떤 증거가 나오면 다음 투자를 승인할 것인가?

이 Executive MDM Investment Page는 Digital Future & Strategy practitioner framework입니다.

17. 투자위원회에서 실제로 나올 다섯 가지 질문

① 왜 지금 해야 합니까?

MDM의 일반적 중요성이 아니라 올해 해결해야 하는 Trigger를 설명합니다.

② 하지 않으면 어떻게 됩니까?

현재 비용·지연·Risk·Transformation Dependency가 어떻게 지속되는지 설명합니다.

③ 꼭 MDM이어야 합니까?

Data Quality Tool, Application 개선, Process Change보다 MDM이 필요한 이유를 설명합니다.

④ 성공했는지 어떻게 알 수 있습니까?

Baseline과 Post-Implementation KPI를 연결합니다.

⑤ 첫 단계 이후 무엇을 보고 추가투자합니까?

다음 Domain 확장을 위한 Decision Gate를 제시합니다.

18. Sponsor를 확보한 뒤에도 지원이 약해지는 이유

MDM Sponsorship은 Funding Approval 순간에 끝나지 않습니다.

프로젝트가 진행되면 다음 이슈가 발생합니다.

Global Standard와 Local Requirement 충돌,
Business Unit 간 Owner 갈등,
기존 System에서 신규 MDM Process로 전환에 대한 저항,
Data Cleansing workload 증가,
예상 Benefit의 지연,
다른 Transformation Project와 Priority 충돌.

이 시점에서 Sponsor가 실제 역할을 하지 않으면 프로젝트는 다시 IT 중심 프로젝트로 돌아갈 수 있습니다.

Sponsor Review는 Project Progress보다 Business Evidence를 본다

경영진 Review를 다음과 같이 바꾸는 것이 좋습니다.

일반 Project Review	Value-Oriented Review
개발 진척률	Business Outcome Leading Indicator
Interface 완료건수	Consumer Onboarding 및 Reuse
Rule 개발건수	Critical Error 예방효과
Data Cleansing 건수	Duplicate / Rework / Exception Trend
Issue 수	미해결 Business Decision 및 Benefit Risk

19. 경영진에게 하지 말아야 할 세 가지 약속

“MDM을 구축하면 ROI가 X% 나옵니다.”

자사 Baseline과 Attribution Evidence 없이 외부 Benchmark를 그대로 적용해서는 안 됩니다.

“Single Source of Truth를 만들겠습니다.”

대기업에서는 Domain, Process, Lifecycle에 따라 여러 authoritative system이 존재할 수 있습니다.

목표는 모든 데이터를 한 시스템에 넣는 것이 아니라 어떤 정보가 언제 어디에서 authoritative한지 명확히 하는 것일 수 있습니다.

“MDM이 구축되면 데이터 품질문제가 해결됩니다.”

MDM 플랫폼은 Validation, Matching, Workflow, Quality Monitoring을 지원합니다.

하지만 지속적인 Owner, Stewardship, Root-Cause Remediation과 Process Governance가 없으면 품질은 다시 저하될 수 있습니다.

20. AI 시대에는 MDM Business Case가 어떻게 달라지는가

AI와 Agentic AI는 MDM에 새로운 설득논리를 제공하지만 과장해서는 안 됩니다.

“AI를 하려면 MDM부터 구축해야 한다”는 식의 포괄적 주장은 너무 넓습니다.

더 정확한 질문은:

“이 AI Use Case가 어떤 Business Entity에 의존하며,
그 Entity가 잘못되었을 때 어떤 Decision 또는 Action이 잘못되는가?”

입니다.

예를 들어 Procurement Agent가 Supplier를 조회하고 주문변경을 제안한다면 다음이 필요할 수 있습니다.

정확한 Supplier Identity,
현재 Active / Block Status,
법인·조직 관계,
Authoritative Attribute,
Agent가 사용할 수 있는 Governed API.

이 경우 MDM은 “AI를 위한 데이터 정비 프로젝트”가 아니라 AI Workflow가 신뢰할 수 있는 Business Entity Control로 설명할 수 있습니다.

21. MDM 투자승인 준비도를 점검하는 12가지 질문

1. MDM이라는 단어 없이도 해결하려는 Business Problem을 설명할 수 있는가?

2. 경영진이 이미 중요하게 보는 KPI 또는 Transformation과 연결되는가?

3. 현재 문제의 Baseline Evidence가 있는가?

4. Master Data가 문제의 원인이라는 인과관계를 설명할 수 있는가?

5. Application 수정이나 단순 DQ 프로젝트보다 MDM이 필요한 이유가 있는가?

6. 해당 Business Outcome을 책임지는 Executive Sponsor가 있는가?

7. 첫 투자범위가 독립적으로 Value를 증명할 만큼 완결되어 있는가?

8. People·Governance·Operation을 포함한 비용을 계산했는가?

9. 직접효과와 간접효과를 구분했는가?

10. 투자하지 않을 경우 계속 발생할 문제를 설명할 수 있는가?

11. 다음 투자로 넘어갈 Decision Gate가 있는가?

12. Sponsor에게 한 페이지로 설명할 수 있는가?

경영진이 투자하는 것은 MDM이 아니라 Business Outcome이다

MDM 팀이 흔히 하는 실수는 MDM의 중요성을 증명하려는 것입니다.

하지만 경영진이 결정해야 하는 것은 MDM이라는 개념이 중요한지 여부가 아닙니다.

이 문제가 지금 투자할 만큼 중요한가?

제안한 Intervention이 실제로 문제를 줄일 수 있는가?

첫 투자에서 무엇을 증명할 것인가?

증거가 좋지 않으면 무엇을 바꿀 것인가?

를 판단해야 합니다.

DO NOT SELL
MDM Platform
Golden Record
Data Quality

SELL THE DECISION LOGIC

Business Problem
→ Evidence
→ Master Data Cause
→ Controlled Intervention
→ Measurable Outcome
→ Next Decision

좋은 MDM Business Case의 목적은 MDM의 가치가 무한히 크다는 것을 증명하는 것이 아닙니다.

경영진이 불확실성을 이해한 상태에서도 첫 번째 투자결정을 합리적으로 내릴 수 있을 만큼 충분한 증거를 제공하는 것입니다.

경영진의 지원을 얻는 가장 좋은 방법은 MDM을 더 크게 설명하는 것이 아닙니다. 해결해야 할 Business Problem은 더 중요하게, 첫 투자는 더 명확하게, 그리고 다음 단계는 증거에 따라 결정하도록 만드는 것입니다.

Sources & Further Reading

Method Note
이 글은 MDM 투자승인과 Executive Sponsorship을 설계하기 위한 실무 프레임워크입니다. Informatica 및 Profisee 자료는 MDM 전략을 Business Goal, Executive Sponsorship, Stakeholder Engagement 및 measurable outcome과 연결해야 한다는 외부 참고자료로 활용했습니다. 본문의 Evidence Chain, Sponsor Action Model, Staged Investment, Proof-of-Value 구분, Decision Gate, Executive MDM Investment Page 및 투자승인 점검질문은 Digital Future & Strategy practitioner frameworks입니다. 특정 ROI, Payback Period 또는 MDM 실패확률을 외부 Benchmark로 가정하지 않으며, 실제 투자안은 각 기업의 Baseline, Finance Policy, Strategic Priority 및 Risk Appetite를 사용해야 합니다.

Reviewed: September 2026

Global English Companion

글로벌 독자를 위한 영문판에서는 동일한 문제를 Enterprise Investment 관점에서 별도로 다룹니다.

MDM #7. How to Build an MDM Business Case Executives Can Fund

영문판은 글로벌 투자논리와 attribution 중심이며, 본 한국어판은 Sponsor 확보, 단계별 투자승인, Proof of Value 및 Decision Gate를 보다 구체적으로 다룹니다.

다음 글: 국내 기업 MDM 도입 실패의 7가지 패턴