Knowledge Graph 활용 사례 - 고객 정의 연결

https://www.semanticarts.com/value-of-using-knowledge-graphs-in-some-common-use-cases/

We worked with a bank that was migrating to the cloud.  As part of the migration they wanted to unify their view of their customers.  They brought together a task force from all the divisions to create a single definition of a customer.  This was essentially an impossible task.  For some divisions (Investment Banking) a customer was a company, for others (Credit Card processing) it was usually a person.  Not only were there differences in type, all the data that they wanted and were required to have in these different contexts was different.  Further one group (corporate) espoused a very broad definition of customer that included anyone that they could potentially contact.  Needless to say, the “Know Your Customer” group couldn’t abide this definition as every new customer obligates them to perform a prescribed set of activities.

What we have discovered time and again is that if you start with a term (say, “Customer”) and try to define it, you will be deeply disappointed.  On the other hand, if you start with formal definitions (one of which for “Customer” might be, “a Person who is an owner or beneficiary on a financial account” (and of course financial account has to be formally defined)), it is not hard to get agreement on what the concept means and what the set of people in this case would be.  From there it is not hard to get to an agreed name for each concept.

In this case we ended up creating a set of formal, semantic definitions for all the customer related concepts.  At first blush it might sound like we had just capitulated to letting everyone have their own definition of what a “Customer” was.  While there are multiple definitions of “Customer” in the model, they are completely integrated in a way that any individual could be automatically categorized and simultaneously in multiple definitions of “Customer” (which is usually the case).

The picture shown below, which mercifully omits a lot of the implementation detail, captures the essence of the idea. Each oval represents a definition of “Customer.”

우리는 클라우드로 마이그레이션하는 은행과 협력했습니다.  마이그레이션의 일환으로 그들은 고객에 대한 관점을 통합하고자했습니다.  그들은 고객에 대한 단일 정의를 만들기 위해 모든 부서의 태스크 포스를 모았습니다.  이것은 본질적으로 불가능한 작업이었습니다.  일부 부서 (투자 은행)의 경우 고객은 회사 였고 다른 부서의 경우 (신용 카드 처리) 일반적으로 사람이었습니다.  유형에 차이가 있었을뿐만 아니라 그들이 원하고 필요로하는 모든 데이터가 서로 다른 상황에서 필요했습니다.  또한 한 그룹 (기업)은 잠재적으로 연락 할 수있는 모든 사람을 포함하는 매우 광범위한 고객 정의를지지했습니다.  말할 필요도없이 "고객 파악"그룹은 모든 신규 고객이 규정 된 일련의 활동을 수행해야하기 때문에이 정의를 따를 수 없었습니다.

우리가 몇 번이고 발견 한 것은 용어 (예 : "고객")로 시작하여 정의하려고하면 크게 실망 할 것입니다.  반면에 공식적인 정의로 시작하는 경우 ( "고객"에 대한 정의 중 하나는 "금융 계정의 소유자 또는 수혜자"일 수 있습니다 (물론 금융 계정을 공식적으로 정의해야 함)),  개념이 무엇을 의미하고이 경우 사람들이 무엇을 의미하는지에 대한 합의를 얻는 것은 어렵지 않습니다.  거기에서 각 개념에 대해 합의 된 이름을 얻는 것은 어렵지 않습니다.

이 경우 우리는 모든 고객 관련 개념에 대한 공식적인 의미 론적 정의 세트를 생성했습니다.  처음에는 우리가 "고객"이 무엇인지에 대한 자신의 정의를 모든 사람에게 제공하는 것에 항복 한 것처럼 들릴 수 있습니다.  모델에는 "고객"에 대한 여러 정의가 있지만 모든 개인이 자동으로 분류 될 수있는 방식으로 그리고 "고객"에 대한 여러 정의 (대개 경우)로 동시에 완전히 통합됩니다.

많은 구현 세부 사항을 자비 롭게 생략 한 아래 그림은 아이디어의 본질을 포착합니다.  각 타원은 "고객"의 정의를 나타냅니다.

우리는 클라우드로 마이그레이션하는 은행과 협력했습니다.  마이그레이션의 일환으로 그들은 고객에 대한 관점을 통합하고자했습니다.  그들은 고객에 대한 단일 정의를 만들기 위해 모든 부서의 태스크 포스를 모았습니다.  이것은 본질적으로 불가능한 작업이었습니다.  일부 부서 (투자 은행)의 경우 고객은 회사 였고 다른 부서의 경우 (신용 카드 처리) 일반적으로 사람이었습니다.  유형에 차이가 있었을뿐만 아니라 그들이 원하고 필요로하는 모든 데이터가 서로 다른 상황에서 필요했습니다.  또한 한 그룹 (기업)은 잠재적으로 연락 할 수있는 모든 사람을 포함하는 매우 광범위한 고객 정의를지지했습니다.  말할 필요도없이 "고객 파악"그룹은 모든 신규 고객이 규정 된 일련의 활동을 수행해야하기 때문에이 정의를 따를 수 없었습니다.

우리가 몇 번이고 발견 한 것은 용어 (예 : "고객")로 시작하여 정의하려고하면 크게 실망 할 것입니다.  반면에 공식적인 정의로 시작하는 경우 ( "고객"에 대한 정의 중 하나는 "금융 계정의 소유자 또는 수혜자"일 수 있습니다 (물론 금융 계정을 공식적으로 정의해야 함)),  개념이 무엇을 의미하고이 경우 사람들이 무엇을 의미하는지에 대한 합의를 얻는 것은 어렵지 않습니다.  거기에서 각 개념에 대해 합의 된 이름을 얻는 것은 어렵지 않습니다.

이 경우 우리는 모든 고객 관련 개념에 대한 공식적인 의미 론적 정의 세트를 생성했습니다.  처음에는 우리가 "고객"이 무엇인지에 대한 자신의 정의를 모든 사람에게 제공하는 것에 항복 한 것처럼 들릴 수 있습니다.  모델에는 "고객"에 대한 여러 정의가 있지만 모든 개인이 자동으로 분류 될 수있는 방식으로 그리고 "고객"에 대한 여러 정의 (대개 경우)로 동시에 완전히 통합됩니다.

많은 구현 세부 사항을 자비 롭게 생략 한 아래 그림은 아이디어의 본질을 포착합니다.  각 타원은 "고객"의 정의를 나타냅니다.

우리는 클라우드로 마이그레이션하는 은행과 협력했습니다.  마이그레이션의 일환으로 그들은 고객에 대한 관점을 통합하고자했습니다.  그들은 고객에 대한 단일 정의를 만들기 위해 모든 부서의 태스크 포스를 모았습니다.  이것은 본질적으로 불가능한 작업이었습니다.  일부 부서 (투자 은행)의 경우 고객은 회사 였고 다른 부서의 경우 (신용 카드 처리) 일반적으로 사람이었습니다.  유형에 차이가 있었을뿐만 아니라 그들이 원하고 필요로하는 모든 데이터가 서로 다른 상황에서 필요했습니다.  또한 한 그룹 (기업)은 잠재적으로 연락 할 수있는 모든 사람을 포함하는 매우 광범위한 고객 정의를지지했습니다.  말할 필요도없이 "고객 파악"그룹은 모든 신규 고객이 규정 된 일련의 활동을 수행해야하기 때문에이 정의를 따를 수 없었습니다.

우리가 몇 번이고 발견 한 것은 용어 (예 : "고객")로 시작하여 정의하려고하면 크게 실망 할 것입니다.  반면에 공식적인 정의로 시작하는 경우 ( "고객"에 대한 정의 중 하나는 "금융 계정의 소유자 또는 수혜자"일 수 있습니다 (물론 금융 계정을 공식적으로 정의해야 함)),  개념이 무엇을 의미하고이 경우 사람들이 무엇을 의미하는지에 대한 합의를 얻는 것은 어렵지 않습니다.  거기에서 각 개념에 대해 합의 된 이름을 얻는 것은 어렵지 않습니다.

이 경우 우리는 모든 고객 관련 개념에 대한 공식적인 의미 론적 정의 세트를 생성했습니다.  처음에는 우리가 "고객"이 무엇인지에 대한 자신의 정의를 모든 사람에게 제공하는 것에 항복 한 것처럼 들릴 수 있습니다.  모델에는 "고객"에 대한 여러 정의가 있지만 모든 개인이 자동으로 분류 될 수있는 방식으로 그리고 "고객"에 대한 여러 정의 (대개 경우)로 동시에 완전히 통합됩니다.

많은 구현 세부 사항을 자비 롭게 생략 한 아래 그림은 아이디어의 본질을 포착합니다.  각 타원은 "고객"의 정의를 나타냅니다.

오른쪽 아래에는 무료 신용 평가 서비스에 가입 한 사람들이 있습니다.  이들은 "계정"(신용보고 계정)을 가지고 있지만 금전적 의무가없는 계정입니다 (잔액이없고 인출 할 수 없음).  KYC (Know Your Customer) 요구 사항은 금융 계정을 가진 사람들에게만 적용됩니다.  중복은 일부 사람들이 금융 계정과 비금융 계정을 가지고 있음을 나타냅니다.  파란색 별은 KYC의 지침에 해당하는 금융 고객을 나타냅니다.  마지막으로, 상단의 긴 타원형은 고객이 될 수없는 사람과 조직의 집합을 나타내는 이른바 "제재 목록"입니다.  이 두 타원이 겹치지 않아야한다고 생각할 수 있지만, 제재가 지속적으로 변경되고 고객 관계에 대한 우리의 지식이 지속적으로 변함에 따라 현재 고객이 제재 목록에 있다는 사실을 알게 될 가능성이 높습니다.  우리는 이것을 금융 고객이자 동시에 고객이어서는 안되는 사람인 브라운 스타로 표현했습니다.

우리는이 접근 방식이 대기업과 고객 관계에 내재 된 복잡성을 고유하게 처리한다고 생각합니다.

또 다른 참여에서 우리는 유사한 접근 방식을 사용하여 공급 업체이기도 한 고객을 찾았습니다. 이는 종종 관심이 있고 일반적으로 일관되게 감지하기 어렵습니다.