범유럽 B2B Salesforce 전환

상황

Disneyland Paris는 유럽 마켓 전반의 파편화된 수작업 프로세스를 통합 플랫폼으로 대체하며, Salesforce 위에서 B2B 디지털 전환을 시작하고 있었습니다. 기업 그룹 영업, 여행사 파트너십, 투어 오퍼레이터 관계를 아우르는 B2B 사업은 20개가 넘는 유럽 마켓에 걸쳐 있었습니다. 각 마켓은 수십 년에 걸쳐 다듬어진 자기만의 영업 워크플로우, 파트너 관리 프로세스, 운영 관행을 갖고 있었습니다.

이 프로젝트는 설계 단계부터 아키텍처 우선이었습니다. 사업자를 먼저 고르고 구현 결정이 설계를 끌어가게 두는 대신, 본사는 아키텍처가 사업자보다 앞서기를 원했습니다. 명세는 선정된 구현 파트너가 설계 주변이 아니라 설계대로 구축할 만큼 정밀해야 했습니다.

테이블 위에 놓인 위험은 익숙한 것이었습니다. 20개가 넘는 마켓에 걸친 B2B Salesforce 프로그램을 기능형 RFP로 범위를 잡으면, 과도하게 표준화되거나(그리고 도입 단계에서 마켓을 잃거나) 명세가 부족해지거나(그리고 SI가 범위 변경 비용을 받으며 재설계하는 것을 지켜보거나) 둘 중 하나로 끝납니다. 본사의 과제는 사업자가 도착하기 전에 그 선택지를 테이블에서 치워 버리는 것이었습니다.

과제

유럽의 B2B 운영은 표준화에 저항합니다. 각 마켓은 로컬 비즈니스 문화, 파트너 관계의 역사, 규제 환경을 반영하는 업무 관행을 발전시켜 왔습니다. 프랑스에서 효율적으로 돌아가는 기업 그룹 예약 프로세스가 독일, 스페인, 영국의 대응 프로세스에 그대로 대응되지는 않습니다. 모든 마켓에 단일 템플릿을 강제하면 플랫폼은 기술적으로 작동하지만 로컬 팀은 조용히 그것을 우회합니다. 각 마켓이 한계 없이 커스터마이징하도록 허용하면, 전환이 대체하려던 바로 그 파편화된 상태가 곧장 되돌아옵니다.

아키텍처 문제는 올바른 추상화 계층을 찾는 데 있었습니다. 프레임워크는 거버넌스를 할 만큼 표준적이고, 진짜 마켓 차이를 흡수할 만큼 유연하며, 사업자가 구축 도중에 재정의할 수 없을 만큼 명확해야 했습니다. 그러려면 실제 운영상의 차이(아키텍처가 수용해야 하는 정당한 차이)와 일관성 없는 용어 및 문서화되지 않은 로컬 변형(표준화가 해소할 수 있는 수렴 대상)을 구분해야 했습니다.

사업자 인계 위험은 그 모든 것을 가중시켰습니다. 한쪽이 설계하고 다른 쪽이 구축하는 구현 프로그램은 매번 표류를 만들어 냅니다. 사업자는 요구사항을 자기 기존 납품 패턴의 렌즈로 해석하는데, 그것이 아키텍처의 의도와 정확히 맞는 경우는 드뭅니다. 유일한 보호 장치는 모호함을 제거하는 문서입니다. 사업자가 완성하는 상위 수준 설계가 아니라, 사업자가 실행하는 명세입니다.

감사 단계를 시작할 때 스티어링 위원회에 한 말

사업자는 결국 선정됩니다. 문제는 그들이 명세를 물려받느냐, 희망 사항 목록을 물려받느냐입니다. 어느 쪽일지 결정할 기회는 한 번뿐입니다.

실행

감사는 위에서 아래로가 아니라 아래에서 위로 진행했습니다. 본사 전략에서 바깥으로 설계하는 대신, 작업은 마켓 단위 영업 운영과의 직접 접촉에서 시작했습니다. 기업 어카운트가 어떻게 구성되는지, 여행사 관계가 어떻게 관리되는지, 예약이 문의에서 확정까지 어떻게 흐르는지, 마켓이 상부에 어떤 리포팅을 책임지는지를 보았습니다. 20개가 넘는 마켓을 평가하며, 통상적인 요구사항 수집 프로세스가 한결같이 놓치는 운영상의 미묘함을 포착했습니다.

감사는 진짜 마켓 요구사항(아키텍처가 수용해야 하는 것), 운영상의 불일치(표준화가 해소할 수 있는 것), 로컬 우회책(잘 설계된 플랫폼이라면 제거할, 과거 기술 실패의 증상) 사이를 구조적으로 구분해 냈습니다. 그 분리가 뒤따른 모든 설계 결정의 입력이 되었습니다.

커스터마이징 모델은 회의에서 가정되는 게 아니라 문서로 명시되었습니다. 각 마켓은 정의된 파라미터 안에서 설정할 수 있었고, 파라미터를 벗어나는 설정은 아키텍처 검토를 거쳐야 했습니다. 그렇게 해서 로컬 팀에 진짜 유연성을 주는 동시에, 과거 상태를 파편화시켰던 구조적 차이의 누적을 막았습니다.

RFP는 기능 설문지가 아니라 기술 명세로 작성되었습니다. 사업자의 답변은 플랫폼 전문성이나 레퍼런스 고객이 아니라 아키텍처를 기준으로 평가되었습니다. 아키텍처가 이미 무엇을 구축해야 하는지를 정해 두었기 때문입니다. 설계와 다른 접근을 제안하는 사업자는 단순히 대안을 내놓는 게 아니라, 그 차이를 설계를 끌어낸 요구사항에 비추어 정당화해야 했습니다.

선정된 사업자가 받은 것은 요구사항 문서가 아니라 완성된 아키텍처 설계였습니다. 데이터 모델, 오브젝트 구조, 연동 아키텍처, 커스터마이징 경계, 배포 순서. 구현이 아키텍처에 맞춰 범위가 잡혔지, 그 반대가 아니었습니다.

성과

범유럽 B2B 감사는 범위에 든 모든 마켓에서 완료되었습니다. 산출물은 이상화된 워크플로우가 아니라 운영의 실제를 포착한 요구사항·차이 분석이었습니다. Salesforce 솔루션 아키텍처는 다양한 유럽 업무 모델을 정당한 로컬 변형을 위한 정의된 유연성과 함께 하나의 일관된 기술 프레임워크로 통합했습니다.

RFP 절차는 선정된 파트너가 아키텍처 명세에 맞춰 범위가 잡힌 사업자 선정으로 이어졌습니다. 구현의 임무는 납품 도중에 무엇을 만들지 발견하는 것이 아니라 설계된 것을 구축하는 것이었습니다. 명세가 그것을 명시적으로 말해 두었기에, 인계는 무엇이 성공적인 납품인지에 대해 어떤 모호함도 만들지 않았습니다.

본사는 이제 획일화하지 않고 거버넌스하는 범유럽 프레임워크를 소유합니다. 로컬 마켓은 경계 안에서 설정하고, 마켓 간 리포팅은 동일한 데이터 모델 위에서 돌아갑니다. 내려앉은 플랫폼은 아키텍처가 명세한 그 플랫폼이지, 사업자가 진행 도중에 만들어 냈을 플랫폼이 아닙니다.

돌아보며

이 패턴은 10개가 넘는 마켓이 하나의 B2B 운영을 공유할 때, 본사가 사업자 선정에 앞서 감사 단계에 투자할 의지가 있을 때, 그리고 경영진이 아키텍처가 빌드보다 먼저 내려앉아야 한다는 것을 받아들일 때 작동합니다. 사업자 주도 설계 표류의 비용이 감사의 비용을 넘어설 때라면 언제나 옳은 선택이며, 대부분의 대형 범유럽 또는 범APAC 프로그램이 여기에 해당합니다.

명세 대 사업자 선택이 거의 존재하지 않는 단일 마켓 배포에서는 덜 작동합니다. 감사와 아키텍처의 부담은 단일 마켓 프로젝트에서 아무것도 벌어 주지 못하며, 기능형 RFP와 단단한 빌드 팀이 더 나은 성과를 냅니다.

더 일찍 했어야 할 것은 커스터마이징 경계 문서화입니다. 마켓이 표준화에 가장 크게 반발하는 순간은, 자신에게 필요한 무언가가 범위 밖이라는 것을 빌드 도중에 발견하는 때입니다. 경계를 RFP 이전에 적어 두고 마켓에 보이게 하면, 발견과 반발을 함께 제거할 수 있습니다.