1 개요

2 비즈니스 가치 소통하기

3 이해관계자

4 프로젝트 정의서 작성하기

5 참여자 조정과 작업 개시

6 데이터 요구사항을 통한 실현성 확보

7 요구사항 종합

8 실현성 확보와 다음 단계로 진행하기

MDM은 기업 전체적인 투자와 참여가 필요한 전사적인 계획이다. 그러므로 이해당사자를 파악하고 그들의 자원을 이끌어내며, 협력을 유도하고 요구사항을 수립한 후 지휘 및 책임을 적절히 분배하는 것등의 조정작업은 프로젝트의 성공 여부를 결정한다고 해도 과언이 아니다. 고품질의 마스터데이터를 확보하려면 누군가는 조직 내 주요 이해당사자를 파악하고, 어떤 이들이 마케팅, 교육, 관리책임, 프로그램 설계, 구현, 유지보수를 하게 될지 조사해야 하며, 이해당사자가 당면한 문제와 요구사항을 파악해야 한다. 그러므로 MDM환경을 구축하고 설계하기에 앞서 팀 구성원들은 다음을 위한 작업을 수행해야 한다.

• MDM으로부터 이득을 얻을 수 있는 이들이 누구인지 알아보기
  
• MDM의 비즈니스 가치를 설정하고 정당화하기
  
• 데이터 요구사항 수집, 우선순위 결정, 기본적인 MDM인프라 설계 및 개발방향 정하기
  
• 새로운 경우에 애플리케이션 인프라를 위한 MDM 환경을 설계 및 구축하기
  
• 기업 데이터 통합 계획 세우기
  
• 관련 어플리케이션의 마이그레이션 계획 마련하기
  

이를 위해서는 많은 이해당사자와 첩촉하고 적절히 기대치를 조정해 프로젝트 라이프사이클 전반에 걸쳐 점진적으로 마스터 환경을 확장해 나가면서 가치를 창출할 수 있어야 한다. 마스터데이터 관리에 개입하는 구성원의 역할과 역할의 책임 및 의무를 살펴보고, 마스터 리파지토리 설계에 앞서 선행되어야 하는 데이터 요구사항을 알아보는 방법을 학습한다.

비즈니스 사례와 의미 전달에는 차이가 있다.

• 고위 임원들에게는 성공사례와 효과들에 대한 설명이 적절하다.
  
• 고위 임원을 제외한 다른 이해관계자들에게 실질적인 가치 제시는 미흡하다.
  
  

초점

• 전체 조직 수준
  
  • 고위 임원 - 비즈니스 가치에 초점
    
  • 참고: 비즈니스 가치
    
    • 비즈니스 사례
      
    • 생산성 향상
      
    • 비즈니스 기회에 빠른 대응 능력 배양 등
      
• 부문/부서/개인
  
  • 직무 수행자의 능률향상
    
  • 참고: 능률향상
    
    • 질적으로 향상된 데이터 이용하면서 제약받지 않기
      
    • 시스템 간 합치 과정 줄이기
      
    • 작업 복잡도 줄이기
      
    • 애플리케이션 설계 및 구현 단순화
      
    • 수월한 통합 과정
      
      

비즈니스 가치 소통

• 데이터 품질 제고
  
• 시스템간의 합치 문제 줄이기
  
• 운영 복잡도 줄이기
  
• 설계와 구현 단순화
  
• 통합문제 완화
  
  

데이터 품질 제고

• 중복된 데이터를 중앙 집중화하면서 제거함으로써 데이터 중복으로 인한 오류를 줄일 수 있다.
  
• 데이터 재작성이나 잘못된 데이터에 대한 대응 노력을 줄일 수 있다.
  
• 급한 불끄기를 하는 대신 생산적인 개발과 운영에 투자할 수 있다.
  
• 장기적으로 데이터에 대한 신뢰도 향상
  
  

시스템과의 합치 문제 줄이기

• 데이터가 복제되는 시점, 시스템간의 데이터 불일치 문제를 해결
  
• 마스터 데이터로부터 바로 보고할 수 있다면 데이터 불일치 문제를 해결 할 수 있음
  
  

운영 복잡도 줄이기

• 시스템간의 연계 문제
  
• 엔터티의 개념확장(인수합병, 부서통합 등)
  
• 동일한 표현 방법에 기반해 인터페이스를 표준화하면 단순해짐
  
  

설계와 구현 단순화하기

• 어플리케이션 개발 단순화
  
• 엔터티의 고유 식별성
  
• 위 2가지는 여러 다른 마스터 데이터 서비스를 정의하고 표준화하는 문제로 귀결됨
  
  

통합문제 완화하기

• 모델의 단순화
  
• 메타데이터와 접근 서비스를 표준화
  
• 이렇게 하면 애플리케이션 간에 데이터를 더욱 수월하게 교환할 수 있음.
  
  

잠재적인 이해관계자

• 비즈니스 고객
  
• 애플리케이션 담당자
  
• 정보 아키텍트
  
• 데이터 거버넌스와 데이터 품질 관리자
  
• 메타데이터 분석가
  
• 시스템 개발자
  
• 운영요원
  
  

임원

• 임원의 지원 없이는 어떤 기업활동도 수행하기 어려움.
  
• 임원은 비즈니스 목표 달성에 자신이 얼마나 기여했는지 보이고 싶어함.
  
• 마스터 데이터 환경으로 전환은..
  
  • 현존하는 App 및 시스템 수행결과의 예측 가능성 확인
    
  • 새로운 비즈니스 계획을 지원하기 위해 App을 수정/보완 하는 것이 더욱 민첩해짐.
    
• 조직 내 구성원 참여를 유도하는 중요한 역할
  
• 마스터 데이터 환경은 장기적인 가치와 단기적인 전술적 비즈니스 계획과 충돌 -> 조직에게 행위적인 변화를 준비시켜야 함.
  

비즈니스 고객

• 애플리케이션에서 사용하는 데이터가 고객의 기대치를 충족하지 못하고, 프로세스가 데이터의 활용도를 떨어뜨리는 경우에만 고객에게 정당화 될 수 있다.
  
  • 하지만, 데이터 통합을 통해 의도치 않았던 데이터 품질 향상으로 인한 새로운 가치 창출
    
  • 마스터 데이터 서비스를 통한 효율적인 애플리케이션 개발
    
• MDM팀은 고객의 기대치를 모아 문서화하고 기대치를 충족시킬 것이라고 고객을 설득해야 한다.
  
• 마스터 객체를 사용하는 방법에 대한 큰 그림을 이해햐는 것이 중요 -> 그렇기 때문에 기술팀에서는 어떤 데이터가 어떤 비즈니스에 사용되는지 검증해야 함.
  
  

애플리케이션 담당자

• 중요 이해당사자
  
• MDM환경에 통합해야 할 데이터를 사용하는 모든 애플리케이션은 마스터 데이터를 사용하도록 수정해야 함.
  
• 예측 가능한 결과(애플리케이션이 사용하는 데이터가 MDM환경으로 통합되었을 때의 결과)
  
  

정보 아키텍트

• 요구사항 정립에 포함시켜야 함.
  
• 현재와 미래의 요구사항을 모두 만족시켜야 함.
  
  

데이터 거버넌스와 데이터 품질

• 전사적 관점에서의 데이터는 생성, 접근, 수정, 삭제가 많은 제약을 갖게 된다.
  
• 제약을 위반하지 않기 위해서는 데이터 거버넌스와 데이터 품질 관리자가 책임, 소유권, 관리 정책, 모니터링 수단을 정립해야 한다.
  
• MDM계획에 참여자가 많을수록 성공 가능성은 높아진다.
  
• 더 많은 현업들이 참여할수록 MDM이 창출하는 가치는 확실해진다.
  
  

메타데이터 분석가

• MDM과 거버넌스 작업에 꼭 필요
  
• 메타데이터 관리는 정보 및 어플리케이션 아키텍처, 데이터 거버넌스와 연계되어야 함.
  
• 메타데이터는 데이터 요소와 그에 대응하는 정의, 형식, 크기, 구조, 데이터 영역, 패턴 등에 대한 융합뷰다.
  
  

시스템 개발자

• MDM은 새로운 개발 프로젝트, 어플리케이션 프레임워크가 데이터 자산을 사용하는 방법에 대한 변화를 준다.
  
  

운영요원

• MDM 공용 리파지토리를 사용하려고 할 때 잘 드러나지 않는 위험요소 중에 하나는 운영요원들의 작업이 종종 표준프로토콜을 벗어난다는 것이다.
  
  

• 비즈니스 사례 (MDM 정당화를 위한 비즈니스적 동인)
  
• 주요 프로젝트 후원자 인식
  
• 현재 상황 기술
  
• 원하는 목표 기술
  
• 대안 - 해결책으로 조사했던 대안들
  
• 제안된 해결책 - 선택의 근거
  
• 산출물들 - 수행할 일들
  
• 예산과 자원할당
  
• 위험
  
• 프로젝트 계획
  
• 프로젝트 감독
  
  

기본원칙이 없이는 서비스 정의가 옳은 것인지를 두고 험한 싸움을 한다. MDM은 이런 통합문제를 어떻게 조정할 것인지를 해결한다.

• 참여에 관한 기본 규칙을 정하기 전에 협력 프로세스와 절차 정하기
  
• 감독을 위한 RACI 모델 도입하기
  
• 비즈니스 절차 모델 이용하기
  
• 마스터 메타데이터 제공하기
  
• 데이터 거버넌스 수립하기
  
  

협력 프로세스와 절차 정하기

• 이해관계들이 모이면 용어, 정의, 데이터 출처, 옳은 사용법 등에 대한 의견이 달라진다.
  
  • MDM 이전 - 용어를 통합하여, 다른 뜻으로 사용하지 못하게 한다.
    
  • MDM 이후 - MDM은 용어들의 기본 정의, 사용법 등이 같은 때와 다른 때를 알아내고 모든 용법 차이를 존중하는 수단을 마련하는 것이다.
    
• 이해관계자 간의 차이점을 알아내는 것을 출발점으로 한다.
  
  

감독을 위한 RACI 모델 도입하기
RACI모델

• R - Reponsible, 수행 책임, 작업 완수에 관련된 직무 수행에 대한 책임을 가지는 사람.
  
• A - Accountable, 소명 책임, 작업 산출물과 마일스톤을 성취했는지 여부를 책임지는 사람.
  
• C - Consulted, 의견 개진, 작업 완수를 위한 의견 개진과 컨설팅을 담당하는 역할.
  
• I - Informed, 정보 파악, 관련 정보와 작어 진행 상황을 파악하는 역할
  

구분	MDM관리	비즈니스고객	APP담당	정보아키텍트	데이터거버넌스	메타데이터분석	시스템개발자	운영요원
데이터 조화 프로세스 개발	A	C	C	R	R	R		C
데이터 요구사항 분석	I	C	C	A	R	R
메타데이터 분석	I	C	C	R	R	A	C	C
마스터데이터 분석	I	I	I	A	C	R	C	I

작업당 하나의 소명 책임 역할이 할당되어야 하며, 이는 RACI 행렬 한 행에는 오직 하나의 A가 존재해야 함을 의미한다.

비즈니스 절차 모델 이용하기

• 사용가능한 도구, 구현 제약, 기술적 의사결정은 비즈니스 어플리케이션의 설계, 구현, 실무 배치 작업을 어떻게 진행할 것인지 결정한다.
  
• 기술적 제약에 따라 구현 방법을 결정하면 구현한 어플리케이션 컨텍스트를 중심으로 비즈니스 프로세스가 이행하는 방식이 바뀔 수 있으며 그러다 보면 구현은 비즈니스 프로세스를 똑같이 만드는 것이라고 생각할 수 있다. 데이터를 MDM 환경으로 합병하는 죅은 비즈니스 프로세스가 어떤 것이고 여러 데이터 객체들이 그 안에서 어떻게 쓰이는지 확실히 이해할 수 있다.
  
• 궁극적인 흐름은 실세계 엔티티 간에 이루어지는 상호작용 안에서 되풀이 된다.
  
  

마스터 메타데이터 제공하기

• 용어의 불일치는 비즈니스 흐름에 따른 직무 분배의 산물
  
• 무엇이 마스터데이터 객체이고, 이들을 어떻게 정의하고 사용할지에 대한 의견 수렴해야 함.
  
• 의견 일치를 위한 프로세스와 합의된 정의를 공표할 메타데이터 카탈로그를 만들면 공유 데이터 객체와 요소 의미 일치를 조정하는 관리 플랫폼을 구성할 수 있음.
  
  

데이터 거버넌스 수립하기

• MDM에서 얻는 데이터는 모든 고객 어플리케이션의 요구사항을 만족한다는 것을 보장해야 한다.
  
• 데이터 거버넌스 - 데이터 품질, 표준, 의미, 검증, 정책순응여부 -> 이들에 대한 보고서를 포함.
  
• 임원급 이해관계자들은 데이터 거버넌스, 보호, 스튜어드십을 위한 기능적 관리 레이어 구조를 만드는데 참여시켜야 함. -> 충돌 문제 해결 보장을 위해
  
  

실현 가능성에 대한 2가지 근본적인 의문

• master repository 지원 여부
  
• 효과적인 객체 통합
  
  

실현 가능성 평가는 구현 전에 데이터 및 프로세스 모델 요구사항을 수집하는데 초점을 맞춤.

비즈니스 컨텍스트 파악

1. 관련 이해당사자 식별
   
2. 문서 획득
   
3. 프로그램의 목표와 목적 문서화
   
4. 시스템의 기능 범위 요약
   
5. 관련된 시스템적 영향 요약
   
   

이 프로세스를 마치고나면 3가지 환경적 측면이 문서화되어 있을 것임.

1. 환경과 컨텍스트를 기술하는 다이어그램(비즈니스가 시스템 자원을 어떻게 사용하는지..)
   
2. 잠재 시스템적 영향에 관한 정리(MDM전환에 따른 영향도 파악)
   
3. 마스터 통합 제약사항(시스템 의존성, 표준 등)
   
   

이해당사자 인터뷰

1. 인터뷰 후보자들의 역할과 책임을 검토하고 시스템의 상황에 맞는 질문에 집중
   
2. MDM관점에서 정보 소비자의 역할, 책임, 요구를 잘 이해할 수 있는 인터뷰 질문 고안
   
3. 임원, 고객 -> 사용자 -> 개발자 -> 관리자 순으로 인터뷰 진행. 임원들과의 만남에서 얻은 정보를 이용해 다음 인터뷰에서 쓰일 질문을 바로 잡을 수 있다.
   
4. 인터뷰전 질문 재검토와 자료 준비. 주차장에서까지 토의를 하고 싶어할 만한 주제를 정리해 제시한다.
   
5. 인터뷰 수행
   
   • 시스템 목표에 대한 간단한 설명
     
   • 데이터 요구사항 수집 과정 설명
     
   • 준비한 질문 및 답변 필기
     
   • 인터뷰에 대한 감사인사 및 검토와 검증을 위한 인터뷰 요약에 대한 정리일정 제시
     
6. 인터뷰 참가자 목록, 일반적인 기록, 특정 질문에 대한 답변등의 기록을 검토 후 재구성. 비즈니스 정의 중 시간, 워크플로우, 상태 등과 관련된 명확해진 것 정리
   
7. 다음 인터뷰를 위한 추가적인 정보 파악(추가 질문, 강조해야 할 부분 정리)
   
8. 데이터 요구사항을 통합, 요약 및 정리하고, 요구사항들에 대한 평가 준비
   
   

• 인터뷰에서 얻은 정보를 토대로 비즈니스 컨텍스트와 통합.
  
• 목표: 인터뷰를 통해 가장 자주 파악한 데이터 객체와 비즈니스 프로세스 작업에서 가장 많이 사용된 데이터 객체가 어떤 부분에서 겹치는지 파악.
  
• 결과: 마스터 데이터가 될 후보군들을 볼 수 있음.
  
• 요구사항 종합 단계
  
  1. 비즈니스 프로세스가 데이터를 생성, 관리, 사용하는 방법들을 나타내는 참조 워크플로우 모델 생성. 워크프로우의 어떤 부분에서 중요한 데이터 객체와 개게의 속성에 접근하는지 파악.
     
  2. MDM으로 통합될 후보군 목록 작성. 워크플로우 모델에서 가장 적합해 보이는 모델들.
     
  3. 후보군에서 식별자를 찾아냄.
     
  4. 워크플로우 모델에서 비즈니스 수행에 꼭 필요한 데이터가 무엇인지 정리.
     
  5. 이해당사자들과 후보군에서 주요 속성 검증.
     
  6. 용어 표준화(출처 기록).
     
  7. 소스 시스템 후보 파악.
     
  8. 용어집을 만듬. 워크플로우에서 쓰이는 용어, 분류체계 등.
     
     

• 예비작업을 마치면 실현성에 대한 답을 찾아야 함.
  
• 데이터 후보군을 정리해야 함. 이는 비즈니스 가치와 함께 MDM 프로젝트의 실현성을 확보하는 근거로 쓰임.