2011.03.25

기고 | CRM: 사용자 식별 실수를 피하는 방법

David Taber | CIO

그 동안 조언했던 내용의 대부분은 리드(lead: 잠재고객)와 컨택트(Contact: 접점 잠재고객), 계정과 거래와 같은 고객 데이터에 대해서였다. 반면에 매일 로그인을 하고 데이터를 조작하는 사무원들이 고객일 경우에 대한 CRM 데이터는 대충 넘기는 편이었다.

 

사용자 정책(user policies)에는 사람을 끄는 면도 있지만 끔찍한 결과를 초래시키는 면도 있다. 여기에 우리가 가장 흔하게 저지르는 실수를 3가지 소개하겠다.

 

1. '이름'보다는 '직책(기능)'으로 사용자 설정

CRM 사용자의 기본 로그인 값은 사용자의 이름이나 이메일 주소이다. 하지만 실제 이름보다 그 사람의 직책으로 로그인 사용자를 정하고 싶은 경우가 있다.

 

같은 직책을 가질 수밖에 없는 사람들이 많다면(예를 들어, '고객 지원 오퍼레이터 13번), 세상에서 가장 어리석은 아이디어다. 사용자의 이름에서는 알 수 없는 정황에 맞는 정보를 제공해준다. 그러나 사용자의 개성을 무시한다는 단점이 있다. 무엇보다 HR 측면에서는 절대 바람직한 방법이 되지 못한다. 더 나은 방법은 사용자의 이름에 추가해 프로파일이나, 역할, 또는 다른 항목으로 정보를 제공하는 것이다.

 

2. 라이선스 신분의 재활용

세일즈 및 마케팅 부서의 하위직책은 이직률이 높다. 이런 이유에서 CRM 시스템은 다른 어떤 기업 소프트웨어보다 사용자가 바뀌는 빈도가 높다. 예를 들어, CRM 사용자의 평균 수명이 1년을 못 넘기는 부서도 있다.

 

사용자가 회사를 떠나면 가능한 빨리 라이선스를 해제해야 한다. 새로운 사용자가 이 라이선스를 쓸 수 있도록 하기 위해서다. 하지만 명심할 점이 있다. 사용자 라이선스를 이런 식으로 다시 쓰는 것과 라이선스 신분을 재활용 하는 것은 엄연히 다르다.

 

대부분의 CRM 시스템에서는 라이선스 신분(시스템의 사용자 '슬롯(slot)')을 삭제할 수 없다. 세일즈포스닷컴 같은 경우, 사용자 이름(예, dtaber@saleslogistix.com)을 단 한 번만 사용할 수 있다.

 

기존 사용자가 떠났을 때 새로운 사용자가 영구적으로 존재하는 슬롯을 재활용해 쓸 수 있도록 하는 관리자 정책에 관심이 쏠리곤 한다. 다시는 시스템에 돌아오지 않을 사용자를 위해 슬롯을 남겨두는 혼란을 피할 수 있기 때문이다. 그러나 이런 유혹에 넘어가서는 안 된다.

 

이유는? 시스템의 모든 기록과 감사 추적 정보가 여전히 그 슬롯을 가리킬게 분명하기 때문이다. 즉 과거 기록들이 새로운 사용자에 속해버리는 오류가 일어난다. 아마 6개월 정도가 지나면, 언제 새로운 사용자가 들어왔는지, 해당 조직에서 어떤 다른 역할을 수행하고 있는지 기억하지 못할 것이다.

 

또 기존 사용자의 역할이 무엇이었는지 기억할 사람도 없다. 최초 사용자의 영역이 무엇이었는지 기억하지 못한다면, 계정을 다시 할당하기란 정말 어렵다. 또 여타의 과거 리포트들이 전체 시스템 데이터의 신뢰성을 의심하도록 만드는 잘못된 결과를 생산해 낼 수도 있다. 쉽게 말해 좋은 계획이 아니다.

 

더 나아가, 슬롯을 재활용하면 두고두고 데이터 품질 문제가 발생한다. 사람들이 불분명한 사용자 신분을 조정하기 위해 데이터나 리포트를 '수정'할 것이기 때문이다.

 

결국 최선의 방법은 사용자 슬롯을 재활용하지 않는 것이다. 대신 기존 사용자들을 비활성화하고 새로운 슬롯을 만들어야 한다.

 

그렇다면 사용자가 회사를 떠났다가 몇 달 또는 몇 년 후 다시 복직하는 경우는 어떻게 해야 할까? 일반적으로, 사용자의 오래된 슬롯을 다시 활성화하고, 그 사람에게 속한 데이터를 새로운 역할에 맞춰 이행하는 게 최선이다. 하지만 새로운 역할이 기존 역할과 완전히 다르다면 (예, 고객 서비스 콜센터에 근무했었지만, 지금은 마케팅을 담당하고 있는 경우), 그리고 과거 식별 신분이 리포트상에서 혼동을 초래할 수 있다면, 새로운 슬롯을 사용할 수도 있다. 이 경우, 기존 신분에는 분명한 분리를 위해 새로이 이름을 붙여야 한다.

 

3. 클라우드 통합을 위한 라이선스 공유

CRM 시스템은 효과 증대를 위해 다른 기업 시스템 및 기반과 통합을 해야 한다. 클라우드 기반 CRM의 경우에는 더더욱 그렇다. 일반적으로 각 통합 지점은 안전한 데이터 공유를 위해 CRM 시스템에 '로그인'을 해야 한다.

 

CRM과 통합한 시스템이 여럿 있다면, 시스템들이 단일 사용자 라이선스를 공유하는 정책을 유지하고 싶을 것이다. 또는 각 외부 시스템이 사용자 로그인을 공유하는 것을 바랄 수도 있다. 하지만 설사 사용하고 있는 CRM 벤더가 이를 허용한다 할지라도, 이런 유혹을 거부해야 한다.

 

무엇보다 감사 추적과 데이터 포렌식(forensics) 문제가 발생한다. 만약 모든 시스템이 단일 로그인을 이용해 특정 활동을 한다면, 버그를 해결하기가 아주 어려워진다. 또 하나 이상의 사용자가 로그인한 상태에서 시스템이 특정 활동을 할 경우, 시스템 관리 보고서가 아주 복잡해지거나 오도될 수 있다.

 

잠재적으로 워크로드를 조율하지 못할 수도 있다. 통합한 외부 시스템은 비동기 상태로 운영된다. 그리고 아주 빠른 속도로 데이터를 업데이트해야 할 필요가 있을 수도 있다. 동일한 사용자 라이선스를 이용해 여러 통합 장치를 이용하면 CRM 시스템에서 자원충돌 문제가 발생할 수도 있다. 그리고 이는 해결이 어려운 성능 문제나 버그를 초래할 수 있다.

 

 * 데이비드 타버는 프렌티스 홀 출판사가 출간한 <세일즈포스닷컴의 성공 비밀>이라는 책의 저자이자, 세일즈로지스틱스의 CEO다.  ciokr@idg.co.kr




2011.03.25

기고 | CRM: 사용자 식별 실수를 피하는 방법

David Taber | CIO

그 동안 조언했던 내용의 대부분은 리드(lead: 잠재고객)와 컨택트(Contact: 접점 잠재고객), 계정과 거래와 같은 고객 데이터에 대해서였다. 반면에 매일 로그인을 하고 데이터를 조작하는 사무원들이 고객일 경우에 대한 CRM 데이터는 대충 넘기는 편이었다.

 

사용자 정책(user policies)에는 사람을 끄는 면도 있지만 끔찍한 결과를 초래시키는 면도 있다. 여기에 우리가 가장 흔하게 저지르는 실수를 3가지 소개하겠다.

 

1. '이름'보다는 '직책(기능)'으로 사용자 설정

CRM 사용자의 기본 로그인 값은 사용자의 이름이나 이메일 주소이다. 하지만 실제 이름보다 그 사람의 직책으로 로그인 사용자를 정하고 싶은 경우가 있다.

 

같은 직책을 가질 수밖에 없는 사람들이 많다면(예를 들어, '고객 지원 오퍼레이터 13번), 세상에서 가장 어리석은 아이디어다. 사용자의 이름에서는 알 수 없는 정황에 맞는 정보를 제공해준다. 그러나 사용자의 개성을 무시한다는 단점이 있다. 무엇보다 HR 측면에서는 절대 바람직한 방법이 되지 못한다. 더 나은 방법은 사용자의 이름에 추가해 프로파일이나, 역할, 또는 다른 항목으로 정보를 제공하는 것이다.

 

2. 라이선스 신분의 재활용

세일즈 및 마케팅 부서의 하위직책은 이직률이 높다. 이런 이유에서 CRM 시스템은 다른 어떤 기업 소프트웨어보다 사용자가 바뀌는 빈도가 높다. 예를 들어, CRM 사용자의 평균 수명이 1년을 못 넘기는 부서도 있다.

 

사용자가 회사를 떠나면 가능한 빨리 라이선스를 해제해야 한다. 새로운 사용자가 이 라이선스를 쓸 수 있도록 하기 위해서다. 하지만 명심할 점이 있다. 사용자 라이선스를 이런 식으로 다시 쓰는 것과 라이선스 신분을 재활용 하는 것은 엄연히 다르다.

 

대부분의 CRM 시스템에서는 라이선스 신분(시스템의 사용자 '슬롯(slot)')을 삭제할 수 없다. 세일즈포스닷컴 같은 경우, 사용자 이름(예, dtaber@saleslogistix.com)을 단 한 번만 사용할 수 있다.

 

기존 사용자가 떠났을 때 새로운 사용자가 영구적으로 존재하는 슬롯을 재활용해 쓸 수 있도록 하는 관리자 정책에 관심이 쏠리곤 한다. 다시는 시스템에 돌아오지 않을 사용자를 위해 슬롯을 남겨두는 혼란을 피할 수 있기 때문이다. 그러나 이런 유혹에 넘어가서는 안 된다.

 

이유는? 시스템의 모든 기록과 감사 추적 정보가 여전히 그 슬롯을 가리킬게 분명하기 때문이다. 즉 과거 기록들이 새로운 사용자에 속해버리는 오류가 일어난다. 아마 6개월 정도가 지나면, 언제 새로운 사용자가 들어왔는지, 해당 조직에서 어떤 다른 역할을 수행하고 있는지 기억하지 못할 것이다.

 

또 기존 사용자의 역할이 무엇이었는지 기억할 사람도 없다. 최초 사용자의 영역이 무엇이었는지 기억하지 못한다면, 계정을 다시 할당하기란 정말 어렵다. 또 여타의 과거 리포트들이 전체 시스템 데이터의 신뢰성을 의심하도록 만드는 잘못된 결과를 생산해 낼 수도 있다. 쉽게 말해 좋은 계획이 아니다.

 

더 나아가, 슬롯을 재활용하면 두고두고 데이터 품질 문제가 발생한다. 사람들이 불분명한 사용자 신분을 조정하기 위해 데이터나 리포트를 '수정'할 것이기 때문이다.

 

결국 최선의 방법은 사용자 슬롯을 재활용하지 않는 것이다. 대신 기존 사용자들을 비활성화하고 새로운 슬롯을 만들어야 한다.

 

그렇다면 사용자가 회사를 떠났다가 몇 달 또는 몇 년 후 다시 복직하는 경우는 어떻게 해야 할까? 일반적으로, 사용자의 오래된 슬롯을 다시 활성화하고, 그 사람에게 속한 데이터를 새로운 역할에 맞춰 이행하는 게 최선이다. 하지만 새로운 역할이 기존 역할과 완전히 다르다면 (예, 고객 서비스 콜센터에 근무했었지만, 지금은 마케팅을 담당하고 있는 경우), 그리고 과거 식별 신분이 리포트상에서 혼동을 초래할 수 있다면, 새로운 슬롯을 사용할 수도 있다. 이 경우, 기존 신분에는 분명한 분리를 위해 새로이 이름을 붙여야 한다.

 

3. 클라우드 통합을 위한 라이선스 공유

CRM 시스템은 효과 증대를 위해 다른 기업 시스템 및 기반과 통합을 해야 한다. 클라우드 기반 CRM의 경우에는 더더욱 그렇다. 일반적으로 각 통합 지점은 안전한 데이터 공유를 위해 CRM 시스템에 '로그인'을 해야 한다.

 

CRM과 통합한 시스템이 여럿 있다면, 시스템들이 단일 사용자 라이선스를 공유하는 정책을 유지하고 싶을 것이다. 또는 각 외부 시스템이 사용자 로그인을 공유하는 것을 바랄 수도 있다. 하지만 설사 사용하고 있는 CRM 벤더가 이를 허용한다 할지라도, 이런 유혹을 거부해야 한다.

 

무엇보다 감사 추적과 데이터 포렌식(forensics) 문제가 발생한다. 만약 모든 시스템이 단일 로그인을 이용해 특정 활동을 한다면, 버그를 해결하기가 아주 어려워진다. 또 하나 이상의 사용자가 로그인한 상태에서 시스템이 특정 활동을 할 경우, 시스템 관리 보고서가 아주 복잡해지거나 오도될 수 있다.

 

잠재적으로 워크로드를 조율하지 못할 수도 있다. 통합한 외부 시스템은 비동기 상태로 운영된다. 그리고 아주 빠른 속도로 데이터를 업데이트해야 할 필요가 있을 수도 있다. 동일한 사용자 라이선스를 이용해 여러 통합 장치를 이용하면 CRM 시스템에서 자원충돌 문제가 발생할 수도 있다. 그리고 이는 해결이 어려운 성능 문제나 버그를 초래할 수 있다.

 

 * 데이비드 타버는 프렌티스 홀 출판사가 출간한 <세일즈포스닷컴의 성공 비밀>이라는 책의 저자이자, 세일즈로지스틱스의 CEO다.  ciokr@idg.co.kr


X