Digital Future & Strategy

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에서 ...

기업의 Digital Transformation은 새로운 시스템을 도입하는 것에서 시작되는 경우가 많습니다. ERP를 교체하고, CRM을 통합하고, Data Platform을 구축하고, Digital Commerce를 확대하고, AI와 AI Agent를 업무에 연결합니다. 각 프로젝트는 서로 다른 기술과 목표를 갖고 있습니다. 하지만 실제 운영단계로 들어가면 놀랍도록 비슷한 질문이 반복됩니다. “이 Supplier가 저 시스템의 Supplier와 같은 회사입니까?” “CRM의 Customer와 ERP의 거래처를 어떤 기준으로 연결해야 합니까?” “Product Category가 시스템마다 다른데 어느 것이 기준입니까?” “AI Agent가 조회한 Supplier Status는 최신 정보입니까?” “조직개편 이후 어느 조직 Hierarchy를 기준으로 실적을 집계해야 합니까?” 이 질문은 특정 애플리케이션의 문제가 아닙니다. 여러 시스템과 프로세스가 공통으로 사용하는 Business Entity의 Identity, Definition, Hierarchy, Status와 Ownership 이 명확하지 않을 때 발생합니다. 바로 Master Data의 영역입니다. Digital Transformation이 새로운 기능을 만드는 작업이라면, Master Data Management는 그 기능들이 같은 Customer, Supplier, Product, Material, Location과 Organization을 보고 있다고 믿을 수 있게 만드는 기반입니다. 그렇다고 모든 DX 실패의 원인이 Master Data라는 의미는 아닙니다. Leadership, Operating Model, Process Design, Adoption, Architecture, Integration, Technical Debt, Skills 등 다양한 원인이 Digital Transformation의 성패에 영향을 줍니다. Master D...

기업의 마스터 데이터에는 같은 실체가 서로 다른 이름과 코드로 존재하는 경우가 많습니다. 예를 들어 한 공급업체가 여러 ERP와 구매시스템에서 다음처럼 표현될 수 있습니다. Supplier A — Hanul Tech Co., Ltd. Supplier B — 한울테크(주) Supplier C — HANUL TECH Supplier D — Hanul Technology Vietnam Co., Ltd. 앞의 세 레코드는 같은 법인을 가리킬 수도 있습니다. 하지만 네 번째 회사는 같은 기업집단에 속하면서도 별도 법인일 수 있습니다. 이 차이를 잘못 판단하면 두 종류의 오류가 발생합니다. 오류 의미 결과 False Non-Match 같은 Entity를 서로 다른 Entity로 판단 중복 Customer·Supplier·Product가 계속 존재 False Merge 서로 다른 Entity를 하나로 통합 계약·지급·리스크·분석 Context가 잘못 결합될 수 있음 전통적인 중복 제거 논의에서는 첫 번째 문제에 집중하기 쉽습니다. 그러나 Enterprise MDM에서는 두 번째 문제가 더 위험할 수도 있습니다. Entity Resolution의 목표는 중복을 0으로 만드는 것이 아닙니다. 동일 Entity를 최대한 찾아내면서도 서로 다른 Entity를 잘못 합치는 위험을 Business가 허용할 수준으로 통제하는 것입니다. Knowledge Graph는 이 문제를 해결하는 중요한 도구가 될 수 있습니다. 하지만 그래프를 사용한다고 자동으로 정확도가 높아지는 것은 아닙니다. 그래프가 제공하는 핵심 가치는 문자열뿐 아니라 Entity가 누구와 어떤 관계를 맺고 있는가 를 추가 evidence로 사용할 수 있다는 점입니다. 1. Entity Resolution은 Duplicate Detection보다 넓은 개념이다 Entity Resolution은 여러 레코드가 실제 세계의...