2013.08.16

칼럼 | CRM, 이제 '보조 바퀴' 떼고 페달을 밟자

David Taber | CIO
따로 코드를 개발할 필요 없이, 단일(Standalone) 시스템에 몇 가지만 설치하는 방식으로 패키지를 간단히 설치하면서 가장 기본적인 CRM을 도입할 수 있다. 하지만 이것은 가장 기본적인 CRM 도입에만 해당되는 이야기다.

좀더 야심찬 CRM을 계획하고 있다면 좀더 야심찬 맞춤화와 확장이 필요하다. 개발 전략을 진지하게 생각하게 되기까지 그리 긴 시간이 걸리지 않을 것이다. 잘못 선택하면 비용, 데이터 품질, 사용도 만족도에 있어 상당한 대가가 초래된다.

이런 문제들은 어떤 CRM 업체를 선택하느냐에 따라 크게 달라질 것이다. 필자는 세일즈포스닷컴에만 초점을 맞춰 이야기하겠지만 기본 원칙은 모든 CRM 업체에도 적용된다.

위험을 감수하고 '보조 바퀴'는 떼버려라
세일즈포스는 초기에 신속하게 CRM을 전개하는데 필요한 '보조 바퀴'에 해당하는 여러 기능을 제공하고 있다. 이해하기 쉽고, 코드 개발이 필요 없으며, 사용자 친화적인 기능들이다. 이는 소수 활용 사례를 대상으로 한 CRM 도입에서 필요한 기능 전부가 될 수도 있다.

그러나 정교한 활용 사례에는 적합하지 않다. 가장 쉬운 사례는 동일 객체(Object)에서 여러 룩업(Lookup) 필드를 사용하는 경우다. 예를 들어 모두 콘택트(Contact)에 해당하는 이사회 이사, 변호사, 감사자에 필드가 있는 경우다. 이는 '영향력을 행사하는 사람(Influencers)' 같은 접합점에 해당하는 객체를 사용할 때와 비교해 이해하기도, 보고하기도 쉽다. 임의의 사람(또는 직책)을 계정에 추가할 수 있기 때문이다. 다른 사례로는 캠페인에 리드 소스를 사용하는 것, 워크플로에서 많은 이메일을 발송하는 것을 들 수 있다. 이는 좋은 생각이 아니다.

평가 시 가장 중요한 항목은 사용자가 설정하게 되는 플로우, 워크플로우, 테스팅 규칙이다. 자동화가 맞춤화된 코드와 크게 상충될 수 있다. 이들 기술에서 가장 크게 상충되는 두 부분은 시퀀싱(경합 조건으로 유도)과 잘못된 에러 메시지(성과 없이 시간만 잡아먹는 상황으로 유도)를 완벽하게 제어할 수 없다는 것이다. 자세한 설명은 생략하겠다. 그러나 디버깅 과정에 이런 문제에 직면하면 애를 먹게 된다는 사실만 말해두겠다.


해결책은 뭘까? 특정 객체를 대상으로 아펙스(Apex)와 비주얼포스(VisualForce) 코드 작업을 시작한 즉시 모든 워크플로우와 검사 규칙을 아펙스 클래스의 객체에 맞게 교체하는 것이다. 이는 개발하게 되는 모든 테스트 코드와 함께 아주 중요한 작업이 될 수 있다. 그러나 복잡한 개발 작업이라면, 미래의 작업이다.

또 한 걸음 더 나아갈 수도 있다. 세일즈포스는 베스트프랙티스 가이드를 통해 객체당 트리거의 수가 한 개여야 한다고 설명하고 있다. 개발한 트리거 관련 작업 일체는 지원 클래스로, 해당 계층의 테스트 코드는 각자의 테스트 클래스로 이동이 된다. 이렇게 되면 이클립스(Eclipse)가 다소 도움을 주기는 하지만 코드 리팩터링(Refactoring) 작업을 해야 한다. 시간을 중시한다면, 이것이 지금 또는 나중에 대가를 치르는 상황임을 알기 바란다.




2013.08.16

칼럼 | CRM, 이제 '보조 바퀴' 떼고 페달을 밟자

David Taber | CIO
따로 코드를 개발할 필요 없이, 단일(Standalone) 시스템에 몇 가지만 설치하는 방식으로 패키지를 간단히 설치하면서 가장 기본적인 CRM을 도입할 수 있다. 하지만 이것은 가장 기본적인 CRM 도입에만 해당되는 이야기다.

좀더 야심찬 CRM을 계획하고 있다면 좀더 야심찬 맞춤화와 확장이 필요하다. 개발 전략을 진지하게 생각하게 되기까지 그리 긴 시간이 걸리지 않을 것이다. 잘못 선택하면 비용, 데이터 품질, 사용도 만족도에 있어 상당한 대가가 초래된다.

이런 문제들은 어떤 CRM 업체를 선택하느냐에 따라 크게 달라질 것이다. 필자는 세일즈포스닷컴에만 초점을 맞춰 이야기하겠지만 기본 원칙은 모든 CRM 업체에도 적용된다.

위험을 감수하고 '보조 바퀴'는 떼버려라
세일즈포스는 초기에 신속하게 CRM을 전개하는데 필요한 '보조 바퀴'에 해당하는 여러 기능을 제공하고 있다. 이해하기 쉽고, 코드 개발이 필요 없으며, 사용자 친화적인 기능들이다. 이는 소수 활용 사례를 대상으로 한 CRM 도입에서 필요한 기능 전부가 될 수도 있다.

그러나 정교한 활용 사례에는 적합하지 않다. 가장 쉬운 사례는 동일 객체(Object)에서 여러 룩업(Lookup) 필드를 사용하는 경우다. 예를 들어 모두 콘택트(Contact)에 해당하는 이사회 이사, 변호사, 감사자에 필드가 있는 경우다. 이는 '영향력을 행사하는 사람(Influencers)' 같은 접합점에 해당하는 객체를 사용할 때와 비교해 이해하기도, 보고하기도 쉽다. 임의의 사람(또는 직책)을 계정에 추가할 수 있기 때문이다. 다른 사례로는 캠페인에 리드 소스를 사용하는 것, 워크플로에서 많은 이메일을 발송하는 것을 들 수 있다. 이는 좋은 생각이 아니다.

평가 시 가장 중요한 항목은 사용자가 설정하게 되는 플로우, 워크플로우, 테스팅 규칙이다. 자동화가 맞춤화된 코드와 크게 상충될 수 있다. 이들 기술에서 가장 크게 상충되는 두 부분은 시퀀싱(경합 조건으로 유도)과 잘못된 에러 메시지(성과 없이 시간만 잡아먹는 상황으로 유도)를 완벽하게 제어할 수 없다는 것이다. 자세한 설명은 생략하겠다. 그러나 디버깅 과정에 이런 문제에 직면하면 애를 먹게 된다는 사실만 말해두겠다.


해결책은 뭘까? 특정 객체를 대상으로 아펙스(Apex)와 비주얼포스(VisualForce) 코드 작업을 시작한 즉시 모든 워크플로우와 검사 규칙을 아펙스 클래스의 객체에 맞게 교체하는 것이다. 이는 개발하게 되는 모든 테스트 코드와 함께 아주 중요한 작업이 될 수 있다. 그러나 복잡한 개발 작업이라면, 미래의 작업이다.

또 한 걸음 더 나아갈 수도 있다. 세일즈포스는 베스트프랙티스 가이드를 통해 객체당 트리거의 수가 한 개여야 한다고 설명하고 있다. 개발한 트리거 관련 작업 일체는 지원 클래스로, 해당 계층의 테스트 코드는 각자의 테스트 클래스로 이동이 된다. 이렇게 되면 이클립스(Eclipse)가 다소 도움을 주기는 하지만 코드 리팩터링(Refactoring) 작업을 해야 한다. 시간을 중시한다면, 이것이 지금 또는 나중에 대가를 치르는 상황임을 알기 바란다.


X