글로벌 패션 브랜드를 위한 Customer 360 아키텍처

상황

프랑스 패션 하우스 Lacoste는 Customer 360 비전을 중심으로 글로벌 CRM 아키텍처를 통합해야 했습니다. 모든 접점과 채널에 걸친 모든 고객의 단일하고 완전한 뷰입니다. 이 프로젝트는 200만 유로 이상 규모의 CRM 포트폴리오를 지휘하고, 이후 5년간 Lacoste의 Salesforce 활용을 규정할 5개년 디지털 로드맵에 대한 글로벌 이사회 승인을 확보하는 일이었습니다.

판돈이 컸습니다. 이사회 수준의 프로그램은 표준 인도 프로젝트와는 다른 질의 검토를 받습니다. 모든 아키텍처 결정이 예산과 일정, 그리고 진행 여부를 통제하는 사람들에게 보입니다. 구성 한 줄이 작성되기 전에 성공이 정의돼야 했습니다.

여섯 개 사업부가 프로그램 뒤에 있었습니다. 매장 리테일, 이커머스, 마케팅, 서비스, 멤버십, B2B 도매입니다. 각 사업부는 같은 고객의 자기 버전을, 자기 데이터 모델 위에서, 자기 갱신 주기로 만들어냈습니다. 아키텍처 기능은 여섯 곳 모두가 합의할 수 있는 “고객”의 정의 하나를 인도한 뒤, 그것을 떠받치는 데이터 레이어를 설계해야 했습니다.

과제

“Customer 360”은 엔터프라이즈 CRM에서 가장 많이 언급되는 목표이면서 동시에 실제로 구현하기 가장 어려운 목표입니다. 근본적으로 다른 시스템들이 생성하는 데이터를 통합해야 합니다. 매장 POS, 이커머스 플랫폼, 마케팅 자동화, 고객 서비스, 멤버십 프로그램, B2B 도매 계정입니다. 각 시스템은 같은 고객의 자기 버전을 생성합니다. 각각 자기 데이터 모델, 자기 식별자, 자기 갱신 주기로 작동합니다. 이를 통합하는 일은 구성 작업이 아닙니다. 아키텍처 문제입니다.

조직적 과제는 기술적 과제에 못지않았습니다. 여섯 개 사업부가 하나의 아키텍처 비전 뒤로 정렬해야 했습니다. 30명 규모의 전사 횡단 팀이 여러 워크스트림에 걸쳐 병렬로 실행해야 했습니다. 이해관계자 정렬에서 생긴 어떤 실패든 출시 실패로 나타났을 것이고, 이사회 수준의 가시성을 고려하면 이 프로그램에는 그런 결과에 대한 여지가 없었습니다.

리스크 프로파일 또한 구조적이었습니다. 이 규모의 프로그램은 통상 실패 조건이 늦게, 상당한 투자가 들어간 뒤, 범위 변경이 비싸지고 조직의 인내가 바닥난 시점에 표면화합니다. 아키텍처 기능은 이 리스크들이 인도 문제가 되기 전에, 그 이후가 아니라, 식별하고 해소해야 했습니다.

킥오프 검토에서 글로벌 이사회에 전한 말

우리가 인도에 깊숙이 들어갈 무렵이면 아키텍처 결정은 이미 굳어 있습니다. 데이터 레이어를 목표로 삼아 지금 의도적으로 내리거나, 아니면 여섯 개 사업부가 자기 시스템을 통해 기본값으로 내리게 됩니다.

실행

아키텍처 기반은 여섯 개 채널, 즉 매장, 온라인, 도매, 서비스, 멤버십, 마케팅에 걸쳐 아이덴티티를 해소하는 통합 고객 데이터 레이어였습니다. 기존 시스템 사이의 점대점 통합으로 빈틈을 메우는 대신, 아키텍처는 각 데이터 소스에 대한 명확한 인제스천 패턴을 갖춘 단일 고객 진실 레코드를 중심으로 설계됐습니다.

“고객”을 정의하는 일이 통합을 구성하는 일보다 더 오래 걸렸습니다. 각자 정당하지만 서로 다른 관점을 지닌 여섯 개 사업부가 Identity Resolution 규칙, 가구 관계, 제품 보유 속성, 참여 이력 구조에 합의해야 했습니다. 아키텍처 기능은 표준 모델에 대한 선을 지키면서, 각 사업부가 자기 채널이 정말로 현지 필드를 필요로 하는 지점에서는 그것을 확장할 여지를 줬습니다. 그 결과는 여섯 개 사업부가 소유하는 하나의 모델이었지, 아무도 존중하지 않는 타협안이 아니었습니다.

성과

200만 유로 이상 규모의 CRM 포트폴리오가 일정대로 인도됐고, Customer 360 아키텍처가 여섯 개 사업부 전반에서 가동됩니다. 사전에 식별한 50건 이상의 전략 리스크는 인도에 닿기 전에 해소됐습니다. 어느 것도 출시 차단 사안이 되지 않았습니다. 여섯 개 사업부 모두 통합 아키텍처 뒤로 정렬을 이뤘습니다.

글로벌 이사회는 5개년 디지털 로드맵을 승인하며, 다개년 아키텍처가 요구하는 조직적 약속을 제공했습니다. 30명 규모의 전사 횡단 팀은 다중 이해관계자 프로그램이 좀처럼 도달하지 못하는 목적의 명료함을 갖고 이 전환을 실행했습니다.

Customer 360 아키텍처는 또한 Salesforce가 향하는 방향을 내다보는 데이터 기반을 세웠습니다. Data Cloud는 Lacoste에서 설계된 바로 그 통합 고객 뷰를 인도하도록 목적에 맞춰 만들어졌습니다. 채널 전반의 Identity Resolution, 모든 활성화의 기준이 되는 통합 프로필, 배치 처리를 대체하는 실시간 세그멘테이션입니다. 구현이 커스텀 통합에 기반하든 Data Cloud에 기반하든 아키텍처 사고는 동일합니다. 차이는 실행 속도입니다. Data Cloud에서는 커스텀으로 짜면 몇 달 걸리던 Identity Resolution과 통합이 이제 몇 주 만에 구성됩니다. 고객을 무엇으로 정의할지, 채널이 어떻게 연결되는지, 활성화 모델이 무엇을 요구하는지에 대한 아키텍처 결정은 바뀌지 않습니다.

돌아보며

이 패턴은 검토가 엄격할 때, 사업부 간 정렬이 타협 불가일 때, 그리고 데이터 레이어가 하류의 부수 결과가 아니라 아키텍처 결정 그 자체라는 점을 경영진이 받아들일 때 통합니다. 이사회 로드맵이 걸려 있고 아키텍처가 당장의 구현 선택을 넘어 오래 버텨야 할 때 옳은 선택입니다.

사전 리스크 작업에 쓸 검토 예산이 없을 때는 효과가 덜합니다. 리스크 레지스터는 압박 아래에서 축소되고, 상시 통제가 아니라 일회성 산출물로 다뤄지면 가치를 잃습니다.

더 일찍 해두면 좋은 것은 표준 고객 정의입니다. 여섯 개 사업부는 인도가 시작된 뒤에는 그것을 몇 달이고 두고 논쟁할 수 있습니다. 킥오프 전에 못 박은 것이, 기반을 다시 다투지 않고도 이후의 모든 통합 결정을 가능하게 만들었습니다.

사용 기술: Salesforce Sales Cloud, Service Cloud, Marketing Cloud, 커스텀 통합 레이어, 데이터 아키텍처 설계, 이해관계자 로드맵 방법론, 리스크 관리 프레임워크