Salesforce RFP로 훌륭한 구축 계획을 받아 내고도, 첫 번째 쟁점 결정에서 무너지는 딜리버리 모델을 떠안을 수 있습니다. 중요한 결정은 공급사 견적보다 먼저 옵니다. 누가 결정하는지, 누구와 협의해야 하는지, 오픈 이후 플랫폼을 누가 책임지는지, 어떤 근거가 나오면 결정을 바꾸는지입니다. 이 내용이 거버넌스 슬라이드 한 장, 인력 구성 부록, 계약 조항 한 줄에 흩어져 있으면 승인은 쉽고 집행은 어렵습니다. 솔루션 설계의 일부로 다뤄야 합니다.
의사결정 권한은 착수 보고서가 아니라 RFP에 넣습니다
프로그램이 멈추거나 갈라지는 지점마다 의사결정 권한을 기술하도록 입찰사에 요구해야 합니다. 일반적인 RACI로는 부족합니다. 책임 임원의 이름은 적혀 있어도, 그 사람이 글로벌 데이터 표준, 현지 영업 요구사항, 공급사 의존성 사이의 충돌을 실제로 정리할 수 있는지는 비어 있기 쉽습니다.
처음부터 의사결정 대장을 요구합니다. 항목마다 결정 내용, 책임자, 참여자, 필요한 근거, 기한, 에스컬레이션 경로, 지연 비용을 적습니다. 이 대장이 있으면 거버넌스가 실제로 작동하는 통제 수단이 되고, 스폰서는 진짜 의존성과 공급사의 선호를 구분할 수 있습니다.
시나리오로 검증합니다. 구축이 시작된 뒤 한 사업부가 공유 Account 모델 변경을 요청합니다. 연동 담당자가 Salesforce 팀이 제안한 API 계약을 거부합니다. 보안 통제가 릴리스 일정과 충돌합니다. 믿을 만한 답변은 누가 어떤 근거로 결정하는지 밝힙니다. ‘운영위원회에서 조율하겠습니다’는 답이 되지 않습니다.
의사결정 권한에는 경계도 필요합니다. 구축 파트너는 설계를 권고하고 납품 약속을 책임집니다. 발주사의 데이터 정책, 목표 운영 모델, 위험 수용을 최종 결정하는 주체가 되지는 않습니다. 내부 책임자가 없으면 계약서가 그 공백을 메우지 못하고, 공백을 기록할 뿐입니다.
발주사가 무엇을 직접 결정할지 일찍 알수록 RFP가 정확해집니다. 2022년 Disneyland Paris에서 저는 통합 파트너를 고르기 전에 B2B 프로세스를 진단하고 Salesforce 목표 모델을 정했습니다. 그래서 파트너 선정은 공급사 주도의 탐색 단계가 아니라 문서화된 범위에서 출발했습니다. 문서화된 범위를 받은 입찰사는 그 범위에 가격을 매겨야 합니다. 열린 요구서를 받은 입찰사는 범위를 대신 써 줍니다.
설계 권한과 딜리버리 관리를 분리합니다
많은 RFP가 프로그램 매니저, 설계 책임자, 딜리버리 팀을 요구하면서, 이 역할 사이에 의견이 갈릴 때 어떻게 정리하는지는 묻지 않습니다.
설계 권한(design authority)은 설계의 일관성을 책임집니다. 데이터 모델 경계, 연동 계약, 보안 제약, 비기능 요구사항, 표준 예외가 여기에 속합니다. 딜리버리 관리는 일정, 의존성, 전망, 놓친 약속의 만회를 책임집니다. 현업 책임자는 결과가 여전히 비용과 변화 부담만큼 가치가 있는지 판단합니다.
두 역할은 겹치지만 서로 대신할 수 없습니다. 딜리버리 책임자는 늦어진 설계 결정의 영향을 드러낼 수 있지만, 마일스톤을 지키려고 그 결정을 조용히 내려서는 안 됩니다. 설계 권한자는 현지 구성이 공유 역량을 왜 위험하게 만드는지 설명할 수 있지만, 책임 있는 현업 책임자 없이 업무 우선순위를 정해서는 안 됩니다.
양쪽 모두에 이름이 명시된 설계 권한자를 요구해야 합니다. 발주사 쪽 권한자는 현업 스폰서에게 직접 닿을 수 있어야 하고, 현지에만 편리하면서 공유 역량을 해치는 설계를 거부할 권한이 있어야 합니다. 공급사 쪽 책임자는 초기 워크숍과 막판 에스컬레이션에만 등장하지 않도록 인력 계획에 충분한 시간이 잡혀 있어야 합니다. 이 책임자가 설계 선택 하나를 책임자, 전제, 인수 기준, 기록된 결과를 갖춘 결정으로 정리하는 방식도 입찰사에 보여 달라고 요구합니다.
인계를 인수 기준으로 삼습니다
Salesforce 프로그램은 배포로 끝나지 않습니다. 상업 모델은 대개 인계를 전제로 하지만, 발주사가 딜리버리 팀 없이 무엇을 운영할 수 있어야 하는지 RFP에 적는 경우는 드뭅니다.
기능 인수 기준 옆에 운영 모델 인수 기준을 둡니다. 책임자가 있는 의사결정 기록, 연동과 핵심 메타데이터별 지정 책임자, 릴리스 프로세스, 지원 요청 분류 경로, 백로그 책임 모델, 주요 설계 선택의 기록이 여기에 들어갑니다. 목적은 공급사의 역할이 바뀌기 전에 책임 소재를 눈에 보이게 만드는 데 있습니다.
오픈 이후 어떤 책임이 입찰사에 남고, 어떤 책임이 내부 팀으로 넘어가며, 어떤 책임에 유지보수 서비스가 필요한지, 각 이전을 무엇으로 믿을 수 있게 만드는지 묻습니다. 회의 일정만 나열한 전환 계획은 약합니다. 새 책임자, 그가 내려야 할 결정, 필요한 근거, 권한을 넘겨받는 날짜를 적은 계획은 검증할 수 있습니다.
플랫폼이 여러 사업부나 여러 파트너에 걸쳐 있을수록 이 문제가 커집니다. 공통 관심사의 책임자가 없으면 팀마다 자기 백로그만 최적화하고 데이터 정의가 서로 어긋납니다. 이런 공통 관심사를 어디에 둘지는 Salesforce CoE 노트에서 다룹니다.
상업 모델을 통제 모델과 함께 평가합니다
단가와 속도 추정치도 중요하지만, 어떤 결정이 상업 계획을 바꿀 때 공급사가 어떻게 움직이는지는 보여 주지 않습니다.
어떤 사건이 범위를 바꾸는지, 어떤 사건이 전망 수정을 촉발하는지, 비용·일정·설계 일관성 사이의 절충을 누가 승인하는지 입찰사에 묻습니다. 답변은 계약상 변경 관리를 프로그램 의사결정 대장과 연결해야 합니다. 그렇지 않으면 프로젝트에 두 가지 현실이 생깁니다. 딜리버리 계획과 상업 프로세스입니다.
인센티브도 견적만큼 꼼꼼히 봅니다. 가동률로만 보상받는 공급사는 어려운 설계 작업을 비싼 예외가 될 때까지 미룰 수 있습니다. 속도로만 보상받는 공급사는 위험을 지원 팀에 넘기는 릴리스를 내보낼 수 있습니다. 어느 쪽도 악의가 있어야 생기는 일이 아닙니다. 품질과 만회를 상업 논의 밖에 둔 계약이면 충분합니다.
최종 후보 입찰사마다 짧은 시나리오 검토를 진행합니다. 모든 팀에 같은 사례를 줍니다. 연동 의존성이 늦어졌고, 스폰서가 새 우선순위를 요청했고, 원래 오픈 일정은 경영진에게 그대로 보입니다. 복구 프레임워크가 아니라 앞으로 2주 동안의 결정을 요구합니다. 그런 다음 각 팀이 문제 삼는 전제, 참여시키는 사람, 요구하는 근거, 승인 없이는 하지 않겠다는 약속을 비교합니다.
첫 한 달로 RFP의 약속을 검증합니다
RFP 답변은 가설의 묶음입니다. 설계와 구축이 되돌리기 어려운 단계에 들어가기 전에, 착수 기간에 이 가설을 검증해야 합니다.
지정된 역할이 이끌기로 한 회의에 실제로 참석하는지, 의사결정 대장의 에스컬레이션이 일정 잡음으로 변하기 전에 결정에 이르는지 확인합니다. 여러 팀에 걸친 설계 결정 하나를 요청, 근거, 승인, 기록, 공유까지 끝까지 통과시켜 봅니다. 결과가 공급사 임원 한 명과의 비공식 연락에 달려 있다면, 그 모델은 제안서가 보여 준 것보다 약합니다.
작은 실제 결정 하나로도 발주사의 권한, 공급사의 방법, 상업 통제가 서로 맞물리는지 알 수 있습니다. 맞물리지 않는다면 범위가 아직 작을 때 운영 모델을 고쳐야 합니다.