7.9

View in English

7.9 마스터 데이터와 참조 데이터 관리

개요와 동기

다섯 개의 시스템에 조직에 고객이 몇 명인지 물으면 다섯 개의 다른 숫자를 얻습니다. 하나는 이메일 주소를 세고, 하나는 계약을 세고, 하나는 로그인을 세고, 둘은 “Acme Corp”와 “ACME Corporation”이 같은 회사인지에 대해 의견이 갈립니다. 마스터 데이터 관리(MDM)는 비즈니스가 공유하는 핵심 엔터티, 곧 고객, 제품, 공급자, 직원, 위치를 모든 시스템이 신뢰할 수 있는 하나의 권위 있는 버전으로 조정하는 규율입니다.

데이터를 세 종류로 분류하는 것으로 시작하십시오. 필요한 처리가 다르기 때문입니다. 마스터 데이터는 비즈니스의 명사를 기술합니다. 많은 프로세스가 가리키는 사람, 장소, 사물입니다. 참조 데이터는 그 프로세스가 쓰는 통제된 어휘입니다. 통화 코드, 국가 코드, 단위 목록, 제품 범주입니다. 트랜잭션 데이터는 동사를 기록합니다. 주문이 들어옴, 결제가 이루어짐, 배송이 나감입니다. 마스터 및 참조 데이터는 트랜잭션보다 물량이 적지만 어디서나 참조되므로, 그 오류는 하류의 모든 것을 오염시킵니다.

이를 잘못했을 때의 비용은 구체적입니다. 같은 고객이 약간씩 다른 네 개의 레코드로 존재하면 카탈로그 네 부를 보내고, 지킬 가치가 있는 하나의 관계를 볼 수 없고, 고객당 매출 숫자가 조용히 틀립니다. 여러 원천에서 조립한 엔터티의 단일 신뢰 버전인 골든 레코드가 그 상충하는 사본을 대체하여, 모든 통합이 같은 매칭 문제를 다시 풀기를 멈추게 합니다.

수십 년의 성장과 인수로 쌓인 시스템을 조정하는 기업에게 MDM은 일관된 고객 뷰와 영구적인 조정 세금의 차이입니다. 정부에게는 판돈이 올라갑니다. 세 기관에 세 명의 다른 사람으로 나타나는 시민은 급여를 거부당하거나, 이중 과세되거나, 부서 사이에서 사라질 수 있습니다. 이 장은 소유권과 정책을 정하는 데이터 전략과 거버넌스(7.1장), 엔터티가 무엇을 뜻하는지 정의하는 데이터 모델링과 시맨틱 계층(7.7장), 레코드를 시간에 걸쳐 깨끗하게 유지하는 데이터 품질과 관측 가능성(7.8장)을 보완합니다.

핵심 원칙

  • 데이터를 마스터, 참조, 트랜잭션으로 분류하십시오. 각각 다른 처리가 필요합니다.
  • 실세계 엔터티당 하나의 골든 레코드를 우연히 발견하는 것이 아니라 의도적으로 조립하십시오.
  • 유행이 아니라 통제와 지연 필요에 맞게 MDM 아키텍처 스타일을 고르십시오.
  • 매칭과 생존은 비즈니스 규칙이므로 적어 두고 스튜어드가 튜닝하게 하십시오.
  • 참조 데이터는 공유 어휘입니다. API처럼 버전을 관리하고 공표하십시오.
  • 거버넌스와 스튜어드십이 MDM의 엔진입니다. 소프트웨어는 도구일 뿐입니다.
  • 하류 시스템이 낡지 않고 동기화되도록 골든 레코드를 이벤트로 전파하십시오.
  • 적재된 레코드가 아니라 개선된 결정과 제거된 중복으로 MDM을 측정하십시오.

권장 사항

마스터, 참조, 트랜잭션 데이터를 먼저 분류한다

분류하지 않은 것은 관리할 수 없으므로, 데이터 도메인을 분류하는 것으로 시작하십시오. 마스터 데이터에 대한 유용한 시험은 틀린 값이 전파되는가입니다. 잘못된 주소 하나가 청구, 배송, 법적 통지로 파급된다면 마스터 데이터를 보고 있는 것입니다. 이것이 투자를 이끕니다. 주문 품목이 아니라 고객 엔터티를 위해 매칭 엔진을 만듭니다. 도메인의 이름을 명시적으로 대고, 중복이 일으키는 고통으로 순위를 매기고, 가장 아픈 한두 개에서 시작하십시오. 보통 고객과 제품인데, 매출에 직접 닿기 때문입니다.

MDM 아키텍처 스타일을 의도적으로 고른다

흔한 아키텍처 스타일은 네 가지이며, 올바른 것은 얼마나 많은 권한을 중앙화할 수 있고 변경이 얼마나 빨리 전파되어야 하는지에 달려 있습니다. 레지스트리 스타일은 데이터를 원천 시스템에 두고 매칭된 식별자의 색인만 만들어, 데이터를 옮기지 않고 “이 다섯 레코드는 같은 고객이다”에 답할 수 있습니다. 싸고 위험이 낮지만 읽기 전용이라 원천을 고칠 수 없습니다. 통합 스타일은 사본을 중앙 허브로 끌어와 보고를 위한 골든 레코드로 병합하지만 수정을 되돌려 보내지는 않아 원천은 지저분하게 남습니다. 공존 스타일은 더 나아갑니다. 정제된 값을 원천 시스템에 다시 동기화하므로, 원천이 독립적으로 운영되면서도 시간이 지나며 개선됩니다. 중앙화 또는 트랜잭션 허브 스타일은 MDM 허브 자체를 기록 시스템으로 만들어, 엔터티가 거기서 직접 생성되고 편집되며 다른 모든 시스템이 그것에서 소비합니다. 가장 강한 일관성과 통제를 주지만 일이 일어나는 곳을 바꾸기 때문에 도입하기 가장 어렵습니다. 많은 조직이 가치를 입증하는 레지스트리에서 신뢰가 커짐에 따라 공존으로 나아가며, 도메인마다 둘 이상의 스타일을 운영합니다.

매칭, 병합, 생존 규칙을 명시적으로 정한다

MDM의 핵심은 두 레코드가 같은 실세계 대상을 기술하는 때를 결정하는 것입니다. 이것이 레코드 연결이며, 실제 데이터는 오타, 약어, 빠진 필드로 가득해서 정확한 키 일치만큼 단순한 경우가 드뭅니다. 결정적 매칭은 선택한 필드에 정확한 규칙을 씁니다(같은 세금 ID, 또는 같은 이메일에 우편번호). 확률적 매칭은 근사 문자열 매칭과 가중치로 많은 필드에 걸친 유사도를 점수화하여, “Bob Smith, 12 Main St”와 “Robert Smith, 12 Main Street”가 임계값을 넘으면 매칭일 가능성이 크다고 판단할 수 있습니다. 어느 레코드가 같은 엔터티를 가리키는지 결정하는 것을 신원 확인이라 하며, 고객 뷰에서 사기 탐지까지 모든 것을 움직입니다.

레코드가 매칭되면 어느 값이 골든 레코드에 살아남을지 정해야 합니다. 이 생존 규칙은 비즈니스 로직이므로 명시적으로 만드십시오. 전화번호는 가장 최근 값, 주소는 가장 완전한 값, 법적 이름은 가장 신뢰하는 원천을 선호합니다. 매칭이 자동 병합되는 임계 대역, 자동 거부되는 더 낮은 대역, 사람이 결정하는 중간 대역을 정하며, 스튜어드십이 사는 곳이 중간 대역입니다. 모든 병합을 되돌릴 수 있고 기록되게 유지하십시오. 두 실제 고객을 융합하는 잘못된 병합이 놓친 것보다 나쁘기 때문입니다.

참조 데이터를 버전 관리되는 공유 어휘로 다룬다

참조 데이터는 시스템이 말하는 공유 어휘이며, 표류하는 어휘는 조용한 불일치를 일으킵니다. 한 시스템은 ISO 국가 코드 “GB”를 쓰고 다른 시스템은 “UK”를 쓰면 조인이 실패하고 집계가 갈라집니다. 각 참조 목록을 한 거버넌스가 적용되는 곳에 유지하고, 모든 소비자를 위해 공표하고, 결정적으로 버전을 관리하십시오. 코드는 시간이 지나며 추가, 퇴역, 분할, 병합되며, 목록을 제자리에서 덮어쓰면 옛 코드 아래에서는 올바르던 과거 보고서가 깨집니다.

참조 데이터셋을 계약이 있는 API처럼 다루십시오. 소비자가 “이 날짜에 유효했던 지역 코드는 무엇이었나”를 물을 수 있도록 유효 날짜와 함께 공표하고, 퇴역한 코드는 삭제하지 말고 유지하고, 코드의 의미가 바뀔 때 매핑을 기록하십시오. ISO 국가 및 통화 코드처럼 인정된 외부 표준이 있는 곳에서는 선호하십시오. 표준은 공짜로 상호운용성을 주고 3.8장의 개방형 표준 규율에 연결되기 때문입니다.

평평한 레코드만이 아니라 계층과 관계를 모델링한다

마스터 데이터는 독립적인 행의 더미가 아니라 관계의 그물입니다. 고객은 가구와 모기업에 속합니다. 제품은 범주와 브랜드로 집계됩니다. 이 계층은 실제 비즈니스 의미를 지닙니다. 모기업으로 판매를 집계하면 개별 계정으로 집계하는 것과 그림이 완전히 달라집니다. 소비자가 각 팀이 자기 집계를 발명하는 대신 일관되게 순회하도록 이 관계를 명시적으로 모델링하십시오.

하나의 엔터티가 동시에 여러 계층을 필요로 하는 경우를 주의하십시오. 제품은 재무에서는 한 방식으로, 상품 기획에서는 다른 방식으로 집계될 수 있고, 둘 다 정당하므로 하나의 진짜 트리를 강요하는 대신 이름 붙은 여러 계층을 지원하십시오. 어느 공급자가 어느 제품을 제공하는지처럼 도메인 간의 관계도 중요합니다.

골든 레코드를 시맨틱 계층과 데이터 품질에 연결한다

MDM이 만드는 골든 레코드는 7.7장의 시맨틱 계층이 지표를 정의할 때 참조하는 신뢰할 수 있는 엔터티입니다. “활성 고객”은 “고객”이 모호하지 않을 때만 의미가 있습니다. 모든 지표가 같은 중복 제거되고 해결된 엔터티를 세도록 골든 레코드를 시맨틱 계층에 공급하십시오.

MDM과 데이터 품질(7.8장)은 한 동전의 양면입니다. 품질 검사가 중복, 널, 형식 위반을 탐지하고 MDM이 그것을 해결하며, MDM의 매칭이 검사가 놓친 품질 문제를 드러냅니다. 마스터 데이터에 특화해 지속적 품질 모니터링을 돌리십시오. 중복률, 매치 신뢰도 분포, 핵심 필드의 완전성, 리뷰 대기열의 크기로, 소비자가 보기 전에 드리프트가 드러나게 합니다.

이벤트로 골든 레코드를 전파한다

어떤 하류 시스템도 보지 못하는 골든 레코드는 아무에게도 도움이 되지 않습니다. 가장 강한 패턴은 이벤트 기반 전파입니다. 엔터티가 생성, 병합, 정정되면 MDM 허브가 변경 이벤트를 게시하고, 구독 시스템이 자기 로컬 사본을 갱신합니다. 이는 이벤트 기반 아키텍처와 7.2장의 스트리밍 패턴 위에 서서, 모두를 하루 낡게 만드는 취약한 야간 배치 동기화 없이 수십 개 시스템을 일관되게 유지합니다.

이벤트를 유용할 만큼의 맥락과 함께 게시하십시오. 엔터티 식별자, 무엇이 바뀌었는지, 새로 살아남은 값, 소비자가 갱신 순서를 정하고 놓친 것을 탐지할 수 있는 버전입니다. 이벤트를 재생해도 해가 없도록 소비자를 멱등하게 만들고, 구독할 수 없는 시스템을 위한 API를 제공하십시오. 데이터 아키텍처와 저장소(3.4장)의 원칙이 적용됩니다. 골든 레코드가 흐르도록 설계하십시오. 아무도 소비하지 않는 것은 그저 비싼 스프레드시트이기 때문입니다.

도구보다 먼저 스튜어드십과 거버넌스를 배정한다

MDM은 기술 프로젝트로는 실패하고 거버넌스 프로젝트로는 성공합니다. 핵심 역할은 데이터 스튜어드로, 특정 도메인의 품질과 규칙에 책임지고, 모호한 매칭을 해결하고, 생존 규칙을 튜닝하고, 두 부서가 “공급자”의 뜻에 대해 의견이 갈릴 때 중재하는 사람입니다. 스튜어드는 보통 엔지니어가 아니라 깊은 도메인 지식이 있는 비즈니스 사람이며, 권한 없는 파트타임 스튜어드십은 MDM이 막으려던 바로 그 드리프트를 낳으므로 실제 권한과 배정된 시간이 필요합니다.

스튜어드를 7.1장의 거버넌스 구조로 감싸십시오. 각 도메인에 책임지는 데이터 소유자, 도메인 간 분쟁을 해결하는 위원회, 누가 마스터 레코드를 생성하거나 병합할 수 있는지에 대한 분명한 정책입니다. 결정을 문서화하십시오. 고객을 매칭하는 규칙은 직원 교체를 살아남아야 하는 제도적 지식이기 때문입니다. 도구는 거버넌스에 봉사합니다. 스튜어드의 이름을 정하기 전에 MDM 플랫폼을 사는 것은 운전자 없는 엔진을 사는 것입니다.

장단점

MDM 스타일장점단점
레지스트리 (색인만)싸고 위험이 낮으며 원천을 건드리지 않음읽기 전용. 원천 데이터를 고칠 수 없음
통합 (중앙 사본)분석을 위한 깨끗한 레코드를 빨리원천은 지저분하게 남음. 되쓰기 없음
공존 (원천으로 되동기화)원천이 개선됨. 균형 잡힌 통제더 많은 통합. 관리할 동기화 충돌
중앙화 / 트랜잭션 허브가장 강한 일관성과 통제가장 높은 비용. 일이 일어나는 곳이 바뀜
결정적 매칭예측 가능하고, 설명 가능하며, 감사 가능오타, 변이, 지저분한 데이터를 놓침
확률적 매칭실세계의 변이를 잡음튜닝 필요. 부주의하면 잘못된 병합

MDM의 중심 긴장은 통제 대 혼란입니다. 가장 깨끗하고 일관된 데이터를 주는 스타일(공존과 중앙화 허브)이 바로 원천 시스템과 그 소유자의 일하는 방식에 가장 침범하는 것이고, 그 침범이 MDM 프로그램이 정체되는 곳입니다. 실용적인 길은 위험이 낮은 스타일로 신뢰를 얻고, 비즈니스 사례가 분명한 곳에서만 더 강한 통제로 옮겨 가는 것입니다. 매칭 트레이드오프도 나란히 갑니다. 결정적 규칙은 감사 가능하지만 취약하고, 확률적 점수화는 강력하지만 스튜어드십과 가끔의 잘못된 병합에 대한 관용이 필요합니다. 대부분의 성숙한 프로그램은 둘을 섞습니다.

팀과 논의할 질문

  1. 어떤 마스터 데이터 도메인이 실제로 고통을 주며, 모두를 한꺼번에 다루는 대신 비용으로 순위를 매겼습니까? 많은 MDM 프로그램이 자기 야심 아래 무너집니다. 조직의 모든 엔터티를 한꺼번에 마스터하려다 2년 동안 아무것도 내놓지 못합니다. 생산적인 수는 중복과 충돌이 실제 돈이나 신뢰를 치르게 하는 한두 도메인, 보통 고객이나 제품을 찾아 그 비용을 정량화하는 것입니다. 낭비된 우편물, 조정 시간, 틀린 매출 숫자, 감사 지적입니다. 같은 엔터티가 시스템 전반에 여러 방식으로 나타나는 구체적 예를 가져오고, 그 순위가 어디서 시작할지 알려 주게 하십시오. 좁고 측정 가능한 승리가 확장에 필요한 신뢰성을 쌓기 때문입니다.

  2. 각 마스터 데이터 도메인은 누가 소유하며, 스튜어드에게 실제로 일을 할 권한과 시간이 있습니까? 권한 있는 스튜어드십 없는 MDM 도구는 운전자 없는 자동차이며, 가장 흔한 실패 모드는 슬라이드에 스튜어드의 이름을 올리고 실제 권한도 배정된 시간도 주지 않는 것입니다. 모호한 매칭을 해결하고 “무엇이 고객인가” 분쟁을 정리하는 사람에게는 도메인 전문성, 결정 권한, 보호된 시간이 필요합니다. 조직도를 가져와, 가장 중요한 도메인에 대해 두 레코드가 같은 사람인지 정확히 누가 결정하고 영업과 재무가 의견이 갈릴 때 누가 중재하는지 물으십시오. 그 사람의 이름을 댈 수 없고 배정된 시간을 가리킬 수 없다면, 프로그램을 가라앉힐 간극을 찾은 것입니다.

  3. 두 레코드를 골든 레코드로 병합할 때, 결정을 설명하고 되돌릴 수 있으며, 살아남은 값은 어디서 옵니까? 생존 규칙은 대부분의 팀이 한 번도 적어 보지 않은 비즈니스 로직이어서, 병합이 적재 순서나 도구 기본값의 우연으로 일어나며 두 실제 고객을 융합한 잘못된 병합은 되돌리기 고통스럽습니다. 실제 병합된 레코드를 가져와 살아남은 각 필드를 그 원천과 규칙까지 추적하십시오. 왜 이 주소, 왜 이 이름, 왜 이 전화번호인지입니다. 모든 병합이 기록되고 되돌릴 수 있는지, 불확실한 매칭의 중간 대역이 자동 병합되는 대신 사람에게 가는지 확인하십시오. 특정 골든 레코드를 설명할 수 없다면, 스튜어드는 감사자나 피해 입은 고객에게 그것을 방어할 수 없습니다.

  4. 마스터하려는 각 도메인에 어떤 MDM 아키텍처 스타일이 맞으며, 원천 시스템 소유자에게 부과하는 혼란에 대해 그 선택을 방어할 수 있습니까? 고르는 스타일은 데이터를 얼마나 깨끗하게 할 수 있고 원천을 소유한 팀을 얼마나 침범하는지를 정하며, 통제 대 혼란의 현실이 아니라 유행이나 벤더의 제안으로 고르는 것이 프로그램이 중간에 정체되는 방식입니다. 레지스트리는 가치를 싸게 입증하지만 결코 원천을 고치지 못하고, 중앙화 허브는 가장 강한 일관성을 주지만 레코드가 생성되는 곳을 옮기며, 이는 기술적 변화로 위장한 조직적 변화입니다. 각 후보 도메인에 대해 원천 소유자에 대해 실제로 쥔 권한의 정도, 하류 사본이 얼마나 신선해야 하는지, 되쓰기가 기존 워크플로에서 무엇을 깨뜨릴지의 정직한 판독을 가져오십시오. 기업과 정부 환경에서는 기록 시스템을 옮기는 이전과 변경 관리 비용을 더하십시오. 일상 업무가 옮겨지는 팀은 자신들과 상의하지 않은 허브에 저항할 것이고, 정체된 공존 롤아웃은 출하되는 소박한 레지스트리보다 비싸기 때문입니다.

  5. 매칭 임계값은 어떻게 튜닝하며, 각 도메인에서 감당할 수 있는 잘못된 병합과 놓친 매칭의 비율에 합의했습니까? 모든 확률적 매칭 엔진은 잘못된 병합(두 실제 엔터티를 융합)을 놓친 매칭(하나의 엔터티를 쪼개진 채 둠)과 맞바꾸며, 그 균형은 누군가 도구에 남겨 둔 기본값이 아니라 비즈니스 결정입니다. 자동 병합과 자동 거부 대역을 너무 넓게 잡으면 골든 레코드를 조용히 오염시키고, 너무 좁게 잡으면 사람 리뷰 대기열이 스튜어드가 처리할 수 있는 것보다 빨리 커집니다. 현재 신뢰도 분포, 리뷰 대기열의 크기와 나이, 두 종류의 샘플 오류를 가져와 방이 각 방향의 실제 비용을 볼 수 있게 하십시오. 정부 신원 도메인에서는 놓친 매칭과 사람 리뷰 쪽으로 강하게 기울이십시오. 잘못된 병합은 급여를 거부하거나 한 시민의 데이터를 다른 시민에게 노출할 수 있고, 그 오류의 이의 제기와 감사 비용이 스튜어드가 다음 주에 해결하는 중복의 비용을 압도하기 때문입니다.

  6. 하류 시스템은 골든 레코드가 바뀌었음을 어떻게 알게 되며, 결정이 잘못되기 전에 각각 얼마나 낡을 수 있습니까? 어떤 시스템도 소비하지 않는 완벽하게 해결된 골든 레코드는 비싼 스프레드시트이며, 전파 메커니즘, 곧 변경 이벤트든, 구독 API든, 야간 배치든 모든 의존하는 결정이 얼마나 최신인지를 조용히 정합니다. 이벤트 기반 전파는 수십 소비자를 거의 실시간으로 유지하지만 멱등한 소비자와 버전 관리되는 이벤트를 요구합니다. 야간 동기화는 더 단순하지만 모두를 하루 낡게 하며, 마케팅 목록에는 괜찮고 사기 검사에는 위험할 수 있습니다. 소비 시스템의 목록, 각각이 실제로 필요로 하는 최신성, 오늘 갱신을 놓친 소비자가 어떻게 복구하는지를 가져오십시오. 크거나 공공 조직에서는 이 이벤트의 계약을 누가 소유하는지, 구독자가 떨어진 메시지를 어떻게 탐지하는지 이름을 정하십시오. 한 기관에 조용히 닿지 못한 엔터티 변경은 MDM에 자금을 댄 바로 그 파편화를 되살리기 때문입니다.

분야별 관점

스타트업. 엔지니어가 소수이고 낭비할 자금이 없다면 MDM 플랫폼을 사지 마십시오. 이미 운영하는 웨어하우스의 매칭 작업과 매주 불확실한 매칭을 리뷰하는 한 사람으로, 숫자를 오염시키는 한 엔터티, 보통 셀프서비스와 영업에 걸쳐 중복된 고객을 마스터하십시오. 나쁜 규칙이 고객 관계가 아니라 오후 한나절의 비용이 되도록 모든 병합을 기록하고 되돌릴 수 있게 유지하고, 수동 리뷰 대기열이 한 리뷰어를 넘어설 때만 더 무거운 도구를 다시 검토하십시오.

소기업. 데이터 스튜어드도 빠듯한 예산도 있을 테니 이를 만들기보다 사기의 결정으로 다루고 공짜로 얻는 표준에 기대십시오. 유지할 수 없는 맞춤 허브보다 이미 연락처를 중복 제거하고 ISO 국가 및 통화 코드를 쓰는 도구를 선호하고, 중복이 실제 돈을 치르게 하는 한 도메인, 보통 고객이나 제품을 고르십시오. 한 사람의 일주일 중 일부라도 지명된 소유자에게 책임을 배정하십시오. 아무도 지켜보지 않는 채 표류하는 어휘가 보고서를 조용히 깨뜨리는 것이기 때문입니다.

대기업. 인수로 쌓인 십여 개의 ERP와 CRM 시스템에 걸쳐, 일은 포트폴리오 거버넌스입니다. 중복의 비용으로 도메인의 순위를 매기고, 비즈니스에 권한 있는 스튜어드를 세우고, 그룹들이 같은 매칭 문제를 다시 풀기를 멈추도록 생존 규칙과 참조 데이터 버전 관리를 표준화하십시오. 통합과 영구적인 스튜어드십 비용을 명시적으로 예산에 잡고, 원천이 시간이 지나며 개선되도록 골든 레코드를 버전 관리되는 이벤트로 전파하고, MDM을 일회성 정리가 아니라 중복률과 리뷰 대기열 지표가 있는 측정되는 프로그램으로 관리하십시오.

정부. 조달 규칙, 엄격한 데이터 공유법, 공적 책임이 모든 선택을 형성합니다. 사람 엔터티를 거버넌스가 적용되는 국가 식별자로 키잡고, 과거 레코드가 올바르게 유지되도록 참조 데이터를 유효 날짜로 버전 관리하고, 신원 확인을 의도적으로 보수적으로 만드십시오. 잘못된 병합은 급여를 거부하거나 한 시민의 데이터를 다른 시민에게 누출할 수 있으므로 불확실한 매칭은 자동 병합이 아니라 훈련된 스튜어드에게 갑니다. 감사와 이의 제기를 위해 모든 매칭을 기록하고, 벤더에게 데이터 이식성과 공개된 매칭 로직을 요구하고, 전체 역량을 공공 부문이 이미 약속한 상호운용성 표준 안에 두십시오.

사례

스타트업. 빠르게 성장하는 한 소프트웨어 회사는 셀프서비스 가입과 영업 팀을 통해 팔고, 두 채널이 약간 다른 회사 이름으로 같은 고객을 두 번 만듭니다. 계정당 매출이 틀려 보이고 영업 팀은 기존 사용자에게 계속 콜드 콜을 합니다. 무거운 플랫폼을 사는 대신 가벼운 레지스트리로 시작합니다. 데이터 웨어하우스의 매칭 작업이 이메일 도메인과 정규화된 회사 이름으로 레코드를 연결하고, 한 명의 파트타임 스튜어드가 매주 불확실한 매칭을 리뷰합니다. 비용이 적게 들고, 보고 오류를 고치고, 성장하면서 더 많은 투자를 정당화하는 가치를 입증합니다.

기업. 한 글로벌 제조업체는 인수를 통해 성장했고 십여 개의 ERP와 CRM 시스템을 운영하며 각각 자기 공급자 레코드가 있어 같은 공급자가 열다섯 가지로 나타나고, 회사는 하나의 구매자로 협상하거나 실제 지출을 볼 수 없습니다. 공급자와 제품 도메인에 공존 방식 MDM 허브를 세우고, 세금과 등록 식별자에는 결정적 매칭을, 이름과 주소에는 확률적 점수화를 씁니다. 구매 부서의 지명된 스튜어드가 생존 규칙을 튜닝하고 리뷰 대기열을 처리하며, 골든 레코드는 정제된 데이터가 원천을 개선하도록 모든 ERP로 되돌아 흐르는 변경 이벤트로 공표됩니다. 통합된 지출 가시성이 더 나은 계약 조건을 열어 주고, 분기마다 재무를 소모시키던 조정 세금이 크게 줄었습니다.

정부. 한 국가 정부는 데이터 공유에 대한 엄격한 법적 한계를 존중하면서, 기관들이 모든 창구에서 낯선 사람을 만나는 대신 시민을 한 사람으로 다루기를 원합니다. 거버넌스가 적용되는 국가 식별자로 키잡은 사람 엔터티의 중앙화된 마스터 데이터 허브를 구축하고, 과거 레코드가 올바르게 유지되도록 참조 데이터를 유효 날짜로 버전 관리합니다. 신원 확인은 의도적으로 보수적입니다. 잘못된 병합이 누군가의 급여를 거부하거나 데이터를 노출할 수 있으므로 불확실한 매칭은 자동 병합이 아니라 훈련된 스튜어드에게 가고, 모든 매칭이 감사와 이의 제기를 위해 기록됩니다. 보답은 더 적은 중복 레코드, 쪼개진 신원에서 오는 더 적은 사기, 모든 문에서 자신이 누구인지 증명할 필요가 없는 시민이며, 3.8장의 상호운용성 표준 안에서 이루어집니다.

비즈니스 사례: 동기, ROI, TCO

MDM의 수익은 대부분의 조직이 이름 붙이지 않고 치르는 세금을 제거하는 데서 나옵니다. 중복되고 상충하는 레코드는 명백한 방식으로(같은 사람에게 다섯 번 낭비된 마케팅, 낡은 주소에서 오는 배송 오류, 놓친 대량 할인), 그리고 덜 명백한 방식으로(수를 조정하는 분석가, 조용히 틀린 숫자로 결정하는 임원, 어느 레코드가 진짜인지 풀려고 시간을 청구하는 감사자) 돈이 듭니다. 통합된 공급자 뷰는 더 나은 계약 조건만으로 프로그램 전체 비용을 내는 경우가 많습니다.

총소유비용은 세 부분입니다. 플랫폼 또는 구축, 원천과 소비자로의 통합, 그리고 시간이 지나며 가장 큰 지속적 스튜어드십입니다. 통합 비용은 과소평가하기 쉽습니다. 십여 개의 낡은 원천 시스템을 연결하는 것이 MDM 프로그램이 일정과 예산을 흘리는 곳이기 때문입니다. 스튜어드십 비용은 잊기 쉽습니다. 일회성 구축이 아니라 영구적인 운영 비용이기 때문입니다. 리더십을 설득하려면 MDM을 이미 추적하는 숫자, 곧 매출 정확성, 마케팅 효율, 구매 절감, 감사 비용, 규제 위험에 묶고, 좁게 시작해 고통이 큰 한 도메인의 측정된 승리가 확장에 자금을 대게 하십시오.

안티패턴과 함정

  • 바다 끓이기 범위: 모든 도메인을 한꺼번에 마스터하려다 몇 년간 아무것도 내놓지 못하고 첫 승리 전에 후원을 잃는 것.
  • 거버넌스보다 도구 먼저: 스튜어드와 소유자의 이름을 정하기 전에 MDM 플랫폼을 사서 엔진에 운전자가 없는 것.
  • 권한 없는 파트타임 스튜어드: 실제 권한이나 보호된 시간 없이 슬라이드에서만 스튜어드십을 배정하는 것.
  • 조용한 생존: 도구 기본값이나 적재 순서로 레코드를 병합해 서면 규칙도 골든 레코드를 설명할 방법도 없는 것.
  • 되돌릴 수 없는 병합: 되돌리기 없이 불확실한 매칭을 자동 병합해 두 실제 엔터티의 잘못된 융합이 영구적 피해가 되는 것.
  • 제자리에서 덮어쓰는 참조 데이터: 버전 관리 없이 코드 목록을 편집해 옛 코드 아래에서는 올바르던 모든 과거 보고서를 깨뜨리는 것.
  • 아무도 소비하지 않는 골든 레코드: 어떤 하류 시스템도 구독하지 않는 깨끗한 허브를 만들어 정제된 데이터가 결정에 닿지 못하는 것.
  • 표준 코드의 재발명: ISO 표준이 있는데 자체 국가나 통화 목록을 만들어 이유 없이 상호운용성을 잃는 것.

성숙도 모델

  • 1단계, 시작: 마스터 및 참조 데이터가 관리되지 않습니다. 같은 엔터티가 권위 있는 버전 없이 여러 번 존재하고, 코드 목록이 갈라지며, 매칭은 수동적이고 반응적이고, 아무도 문제를 소유하지 않아 핵심 엔터티의 수가 불일치하고 아무도 어느 것이 맞는지 말할 수 없습니다.
  • 2단계, 발전: 주요 도메인이 인식되고 누군가 보고를 위해 흔히 웨어하우스에서 그것을 중복 제거합니다. 기본적인 결정적 매칭이 존재하고, 참조 목록이 수집되며, 몇 사람이 비공식 스튜어드로 행동하지만, 실천은 팀마다 다르고, 원천은 지저분하게 남으며, 규칙은 종이가 아니라 사람들의 머릿속에 있습니다.
  • 3단계, 표준화: MDM이 조직 전체에 일관되게 적용되는 거버넌스가 적용되는 프로그램입니다. 마스터 도메인에 지명된 소유자와 권한 있는 스튜어드가 있고, 매칭과 생존 규칙이 문서화되어 시행되며, 골든 레코드가 생산되어 소비자에게 전파되고, 참조 데이터가 버전 관리되어 API처럼 유효 날짜와 함께 공표됩니다.
  • 4단계, 관리: 프로그램이 기준선에 대해 측정되고 통제됩니다. 중복률, 매치 신뢰도 분포, 잘못된 병합과 놓친 매칭의 비율, 핵심 필드 완전성, 리뷰 대기열의 크기와 나이가 지표로 추적되고, 임계값은 느낌이 아니라 그 숫자로 튜닝되며, MDM의 가치(매출 정확성, 구매 절감, 리뷰 비용)가 정량화되어 고정된 주기로 소유자에게 보고됩니다.
  • 5단계, 오케스트레이션: 골든 레코드가 거의 실시간으로 버전 관리되는 이벤트로 흐르고, 시맨틱 계층에 공급하며, 조직 전체에서 신뢰받습니다. 매칭은 측정된 성과에 대해 지속적으로 개선되고, 마스터 관리는 반복 가능한 역량으로 새 도메인으로 확장되며, MDM이 거버넌스 및 위험 계획과 통합되어 원천, 표준, 엔터티 지형이 이동함에 따라 프로그램이 적응합니다.

논의를 위한 아이디어

  1. 시스템 두 개가 고객이 몇 명인지에 대해 불일치한다면 어느 쪽이 맞으며, 어떻게 증명하겠습니까?
  2. 어떤 마스터 데이터 도메인을 먼저 마스터하면 가장 큰 측정 가능한 승리를 줄 것이며, 그 승리는 얼마의 가치가 있습니까?
  3. 오늘 확률적 매칭이 어디서 도움이 되겠으며, 그것이 함축하는 가끔의 잘못된 병합이 편안합니까?
  4. 참조 데이터의 버전을 어떻게 관리하며, 코드의 의미가 바뀔 때 과거 보고서에서 무엇이 깨집니까?
  5. 가장 중요한 엔터티의 지명된 스튜어드는 누구이며, 실제로 일을 할 권한과 시간이 있습니까?
  6. 골든 레코드가 바뀔 때 하류 시스템은 어떻게 알게 되며, 해가 되기 전에 얼마나 낡을 수 있습니까?

핵심 요점

  • 데이터를 마스터, 참조, 트랜잭션으로 분류하고 중복이 가장 많은 비용을 치르는 곳에 매칭과 거버넌스를 투자하십시오.
  • 명시적이고, 되돌릴 수 있고, 기록되는 생존 규칙으로 조립한 실세계 엔터티당 하나의 골든 레코드를 만드십시오.
  • 통제와 혼란에 대한 선호에 맞게 MDM 아키텍처 스타일(레지스트리, 통합, 공존, 중앙화 허브)을 고르십시오.
  • 참조 데이터를 버전 관리되는 공유 어휘로 다루고, 인정된 표준을 선호하며, 코드 목록을 제자리에서 덮어쓰지 마십시오.
  • MDM은 도구가 아니라 거버넌스와 스튜어드십으로 성공합니다. 골든 레코드를 이벤트로 전파하고 개선된 결정으로 프로그램을 측정하십시오.

참고 문헌과 더 읽을거리

  • David Loshin, Master Data Management
  • Alex Berson and Larry Dubov, Master Data Management and Data Governance
  • Dan Power, The Definitive Guide to Master Data Management
  • John Talburt, Entity Resolution and Information Quality
  • Peter Christen, Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection
  • Ivan P. Fellegi and Alan B. Sunter, “A Theory for Record Linkage,” Journal of the American Statistical Association
  • DAMA International, DAMA-DMBOK: Data Management Body of Knowledge
  • Ralph Kimball and Margy Ross, The Data Warehouse Toolkit