2012.04.25

CRM 데이터 정제가 필요한 이유

David Taber | CIO
의도가 아무리 좋아도 결과까지 반드시 좋으라는 법은 없다. 업데이트된 데이터를 저장하는 것이 바로 그렇다.

이론적으로 가능한 신속하게 데이터베이스 트랜잭션을 정제해 테이블을 최신으로 유지하게 되면 데이터 통합이나 시간을 잡아먹는 문제에 대해 걱정할 필요가 없어진다. 하지만 항상 그렇게 간단한 것은 아니다.

실제 클라우드 시스템에서는 느슨하게 연결된 수십 개의 데이터베이스를 가질 수 있다. 일반적으로 업데이트는 수 초에 한 번씩 이루어지지만 약화된 시스템, 새로 고침 또는 쿼터 종료(Quarter End) 보고 등 특정 조건에서 트랜잭션은 1시간 이상이 걸릴 수도 있다. 이것이 그 작동 메커니즘이다.

따라서 느슨하게 연결된 클라우드 시스템에서 가장 먼저 해 야할 일은 모든 시스템의 마지막 단계에서 트랜잭션이 시간순서에 따라 정리되도록 하고 비즈니스 로직이 실제로 몇 시간이나 늦은 ‘새’ 업데이트가 생겼을 때 무엇을 해야 하는지(또는 어떻게 조화를 꾀하는지) 파악하도록 하는 것이다.

자, 이것으로 트랜잭션 테이블(거래, 결제, 송금 등)에는 충분하다고 생각한다. 하지만 일반적으로 회계 콘텐츠를 그리 많이 가지고 있지 않은 CRM 시스템의 핵심은 어떠할까?

CRM 시스템은 다른 기업용 소프트웨어와는 다르다. 데이터 품질의 기준이 다르며 이는 데이터 입력 소스(고객 또는 판매 대리인)와 데이터 업데이트의 주기 때문이다. 일부 개별 기록이 하루에 몇 번이나 변경될 수 있다.

CRM에서 가장 위험한 테이블은 ‘영업 기회’와 ‘고객 계약’이다. 영업 기회는 계약이 성사되는 단계로 옮겨갈 수 있으며 고객 계약은 정보 피라미드에서 최상단에 위치하기 때문이다. 따라서 이런 테이블에 대한 업데이트는 접속 제어 시스템(영업 담당자는 이 기록이 특정 상태에 있을 때 해당 영역을 수정하지 못할 수도 있다)과 검증 규칙 또는 어떤 데이터가 변경될 수 있는 조건을 제한하는 코드화된 메커니즘을 통해 매우 조심스럽게 다뤄야 한다.

하지만 이런 제어는 그 트랜잭션을 정제할 필요가 있는 외부 시스템에 대한 응답의 필요성과 균형을 이뤄야 한다. 예를 들어 복잡한 판매 채널을 가질 경우, 이미 CRM 시스템 내에 존재하는 ‘새로운’ 계정을 생성할 필요가 있을지도 모른다. 외부 시스템은 계정을 상이한 이름(법인명과 주소지 이름), 상이한 도시, 이미 확보하고 있는 것과 다른 기타 핵심 정보 등으로 표시할 수 있다. 예를 들면, SK텔레콤과 에스케이텔레콤, SKT 또는 강남구와 강남 등으로 말이다.

같은 문제가 영업 기회 단계에서도 발생할 수 있다. 트랙잭션이 개입할 때는 어떤 버전의 데이터가 더 나은지 알 수도 없으며 차후의 통합을 위해 종종 두 가지 버전의 데이터를 보관해야 할 지도 모른다.

따라서 이미 있을 것으로 생각되는 기록에 대해서는 이를 복제할 것을 추천한다. 기록이 생성되면 후속 평가와 데이터 조화를 위해 영업부나 고객담당 부서에 알림 메시지가 전송돼야 한다. 일반적으로 새로운 기록은 마스터 디테일(Master Detail) 관계에서 기존의 기록을 하부 기록으로 만들어 외부의 시스템이 원하는 데이터의 ‘사본’을 지속적으로 업데이트 할 수 있으며 회계 시스템이 회계 장부를 결산하는데 필요한 모든 데이터를 얻을 수 있도록 한다.

이것은 고객명이 거의 동일할 때 내리는 꽤나 간단한 결정이다. 새로운 고객이 ESPN이고 기존 고객이 ABC네트웍스(ABC Networks) 또는 디즈니일 때는 결정을 좀 더 개인적인 판단에 맡겨야 한다. 이들은 모두 같은 회사에 속해 있지만 단일 계정으로 관리해야 할까? 아니면 각각의 계정으로 관리해야 할까? 이 모든 것들은 기업의 규정에 달려있다.




2012.04.25

CRM 데이터 정제가 필요한 이유

David Taber | CIO
의도가 아무리 좋아도 결과까지 반드시 좋으라는 법은 없다. 업데이트된 데이터를 저장하는 것이 바로 그렇다.

이론적으로 가능한 신속하게 데이터베이스 트랜잭션을 정제해 테이블을 최신으로 유지하게 되면 데이터 통합이나 시간을 잡아먹는 문제에 대해 걱정할 필요가 없어진다. 하지만 항상 그렇게 간단한 것은 아니다.

실제 클라우드 시스템에서는 느슨하게 연결된 수십 개의 데이터베이스를 가질 수 있다. 일반적으로 업데이트는 수 초에 한 번씩 이루어지지만 약화된 시스템, 새로 고침 또는 쿼터 종료(Quarter End) 보고 등 특정 조건에서 트랜잭션은 1시간 이상이 걸릴 수도 있다. 이것이 그 작동 메커니즘이다.

따라서 느슨하게 연결된 클라우드 시스템에서 가장 먼저 해 야할 일은 모든 시스템의 마지막 단계에서 트랜잭션이 시간순서에 따라 정리되도록 하고 비즈니스 로직이 실제로 몇 시간이나 늦은 ‘새’ 업데이트가 생겼을 때 무엇을 해야 하는지(또는 어떻게 조화를 꾀하는지) 파악하도록 하는 것이다.

자, 이것으로 트랜잭션 테이블(거래, 결제, 송금 등)에는 충분하다고 생각한다. 하지만 일반적으로 회계 콘텐츠를 그리 많이 가지고 있지 않은 CRM 시스템의 핵심은 어떠할까?

CRM 시스템은 다른 기업용 소프트웨어와는 다르다. 데이터 품질의 기준이 다르며 이는 데이터 입력 소스(고객 또는 판매 대리인)와 데이터 업데이트의 주기 때문이다. 일부 개별 기록이 하루에 몇 번이나 변경될 수 있다.

CRM에서 가장 위험한 테이블은 ‘영업 기회’와 ‘고객 계약’이다. 영업 기회는 계약이 성사되는 단계로 옮겨갈 수 있으며 고객 계약은 정보 피라미드에서 최상단에 위치하기 때문이다. 따라서 이런 테이블에 대한 업데이트는 접속 제어 시스템(영업 담당자는 이 기록이 특정 상태에 있을 때 해당 영역을 수정하지 못할 수도 있다)과 검증 규칙 또는 어떤 데이터가 변경될 수 있는 조건을 제한하는 코드화된 메커니즘을 통해 매우 조심스럽게 다뤄야 한다.

하지만 이런 제어는 그 트랜잭션을 정제할 필요가 있는 외부 시스템에 대한 응답의 필요성과 균형을 이뤄야 한다. 예를 들어 복잡한 판매 채널을 가질 경우, 이미 CRM 시스템 내에 존재하는 ‘새로운’ 계정을 생성할 필요가 있을지도 모른다. 외부 시스템은 계정을 상이한 이름(법인명과 주소지 이름), 상이한 도시, 이미 확보하고 있는 것과 다른 기타 핵심 정보 등으로 표시할 수 있다. 예를 들면, SK텔레콤과 에스케이텔레콤, SKT 또는 강남구와 강남 등으로 말이다.

같은 문제가 영업 기회 단계에서도 발생할 수 있다. 트랙잭션이 개입할 때는 어떤 버전의 데이터가 더 나은지 알 수도 없으며 차후의 통합을 위해 종종 두 가지 버전의 데이터를 보관해야 할 지도 모른다.

따라서 이미 있을 것으로 생각되는 기록에 대해서는 이를 복제할 것을 추천한다. 기록이 생성되면 후속 평가와 데이터 조화를 위해 영업부나 고객담당 부서에 알림 메시지가 전송돼야 한다. 일반적으로 새로운 기록은 마스터 디테일(Master Detail) 관계에서 기존의 기록을 하부 기록으로 만들어 외부의 시스템이 원하는 데이터의 ‘사본’을 지속적으로 업데이트 할 수 있으며 회계 시스템이 회계 장부를 결산하는데 필요한 모든 데이터를 얻을 수 있도록 한다.

이것은 고객명이 거의 동일할 때 내리는 꽤나 간단한 결정이다. 새로운 고객이 ESPN이고 기존 고객이 ABC네트웍스(ABC Networks) 또는 디즈니일 때는 결정을 좀 더 개인적인 판단에 맡겨야 한다. 이들은 모두 같은 회사에 속해 있지만 단일 계정으로 관리해야 할까? 아니면 각각의 계정으로 관리해야 할까? 이 모든 것들은 기업의 규정에 달려있다.


X