SAP 구축 RFP: 무엇을 요청하고 어떻게 평가할까

SAP 구축 RFP는 파트너에게 약속이 아니라 근거를 요청해야 합니다. 비슷한 프로젝트의 레퍼런스, 투입할 사람들의 이력서, 귀사 범위에 맞춘 아키텍처와 계획입니다. 제안서가 도착하기 전에 정한 가중치로 평가하고, 제안 발표에서 수행팀이 계획을 설명할 수 있는지 확인하십시오.

짧게 답하면, RFP는 방법론 슬라이드가 아니라 사람과 계획을 시험하는 자리입니다.

이 글은 결정 과정 중 제안요청서(RFP) 단계만 다룹니다. 롱리스트부터 계약까지 전체 선정 과정은 제 SAP 구축 파트너 선정 방법 가이드에 있습니다.

제가 이끌었거나 구해 낸 21개의 SAP 프로그램에서 가장 크게 본 실수는 시작 단계에서 계획을 제대로 세우지 않는 것입니다. 자사 범위를 알기 전에 보낸 SAP RFP는 모든 파트너에게 빈칸을 자기 전제 조건으로 채우라고 권하는 것과 같습니다. 그러면 제안서를 비교할 수 없습니다. 제안서마다 서로 다른 프로그램에 가격을 매겼기 때문입니다.

그래서 순서가 중요합니다. 범위, 포함되는 프로세스와 제외되는 프로세스, 법인과 국가, 인터페이스, 데이터를 먼저 정의하고, 그것을 중심으로 RFP를 쓰십시오.

범위는 나중에 예산도 지켜 줍니다. 예산이 타격을 입는 곳은 SAP Activate의 Explore 단계로, SAP 방법론이 Fit-to-Standard 워크숍을 진행하고 갭을 백로그에 기록하는 단계입니다.

WRICEF 목록(워크플로, 리포트, 인터페이스, 데이터 변환, 기능 확장, 양식)이 늘어나는 곳이 바로 여기이며, 새로운 오브젝트 하나하나가 비용입니다. 귀사의 범위를 바탕으로 만든 RFP는 그 증가를 잴 기준선을 줍니다.

RFP는 최소 세 곳의 파트너로 이루어진 숏리스트에 보내십시오.

롱리스트는 SAP Partner Finder에서 만드십시오. SAP는 여기서 파트너가 SAP PartnerEdge에서 보유한 컴피턴시를 essential, advanced, expert의 세 단계로 보여 줍니다. 배지는 목록에 오를 자격을 줍니다. 계약을 따낼 자격을 주지는 않습니다.

전체 선정 과정은 처음부터 끝까지 약 12주가 걸립니다.

SAP RFP 단계의 진행 순서

1. 01

   범위

   어떤 파트너에게 보여 주기 전에 범위, 프로세스, 법인, 인터페이스, 데이터를 직접 작성합니다.

2. 02

   RFP

   평가 가중치를 미리 정해 둔 하나의 자료 묶음을 최소 세 곳의 숏리스트 파트너에게 보냅니다.

3. 03

   서면 제안서

   각 제안서를 가중치에 따라 채점하고, 일반론적인 답에는 표시를 합니다.

4. 04

   제안 발표

   제안된 수행팀에게 아키텍처와 계획을 직접 설명해 달라고 요청합니다.

5. 05

   레퍼런스

   귀사와 비슷한 프로젝트의 레퍼런스에 전화해 그 프로젝트에서의 파트너 경험을 묻습니다.

6. 06

   계약

   선정된 제안서의 공수, 지명 인력, 전제 조건을 작업기술서로 옮깁니다.

SAP RFP는 두 부분으로 이루어집니다. 귀사가 파트너에게 주는 것과 파트너에게 돌려받을 것입니다.

파트너에게 주는 것

모든 파트너에게 같은 자료를 같은 시점에 주십시오. 자료가 좋을수록 답이 구체적입니다.

1. 배경과 목표. SAP를 구축하는 이유, 구축 이후 비즈니스가 할 수 있어야 하는 것, 중요한 날짜입니다.
2. 범위. 포함되는 프로세스와 제외되는 프로세스, 법인, 국가, 그룹별 사용자, 사용할 것으로 예상하는 SAP 제품입니다.
3. 인터페이스와 데이터. SAP가 연결해야 하는 시스템, 이관할 데이터 오브젝트, 그 품질에 대해 알고 있는 내용입니다.
4. 귀사 자체 팀. 누구를 얼마만큼의 시간으로 프로그램에 투입할 수 있는지, 파트너가 어떤 역할을 채우기를 기대하는지입니다.
5. 응답 양식. 같은 기준으로 비교할 수 있도록 정해진 구조와 분량 제한입니다.
6. 평가 기준과 가중치. 파트너에게 어떻게 채점할지 알려 주십시오. 그래야 중요한 질문에 답합니다.
7. 일정. 질의 마감일, 제안서 마감일, 제안 발표 날짜, 결정일입니다.

파트너에게 요청하는 것

대부분의 SAP RFP는 파트너에게 자기 소개를 요청하고, 파트너는 그 일에 매우 능숙합니다. 대신 확인할 수 있는 것을 요청하십시오.

1. 비슷한 프로젝트의 레퍼런스. 같은 SAP 제품, 비슷한 규모, 비슷한 산업이며, 전화할 수 있는 연락처가 있어야 합니다.
2. 이름이 명시된 수행팀. 이력서, 각자가 맡을 역할, 귀사 프로그램에 쓰는 시간 비율, 귀사 일정에 맞는 투입 가능 여부입니다.
3. 확인할 수 있는 자격증. SAP는 자격증을 실시간 확인이 가능한 디지털 배지로 발급합니다. 회사의 자격증 보유 수가 아니라 지명된 사람들의 배지 링크를 요청하십시오.
4. 아키텍처와 계획. 귀사 범위에 대한 상위 수준 설계, 그리고 마일스톤과 의존 관계를 담은 SAP Activate 단계별 계획입니다.
5. 단계별, 역할별 공수. 총액만이 아니라 단계마다 역할별 예상 일수입니다.
6. 상세한 전제 조건과 제외 범위. 가격이 의존하는 모든 것과 가격이 포함하지 않는 모든 것입니다.
7. 상업 모델과 단가표. 역할별, 수행 지역별 단가, 출장비와 경비, 변경 사항의 가격 산정 방식입니다.
8. Explore에서 범위 증가를 통제하는 방법. 새로운 WRICEF 오브젝트를 다루는 방법과 누가 승인하는지입니다.

상업 모델은 공수를 정량화한 투입 공수 기반(T&M) 방식을 권합니다. 단계별, 역할별 예상 공수를 계약에 넣으면 매달 실제 공수를 그 기준과 대조해 추적할 수 있습니다. 이를 RFP에서 요청해 두어야 나중에 그렇게 할 수 있습니다.

단가는 귀사가 먼저 숫자를 제시해 파트너의 기준점을 정해 주지 마십시오. 파트너의 단가표를 요청하고, 제 SAP 프로젝트 자원 배분 계획 가이드에 있는 범위와 비교하십시오.

전제 조건과 제외 범위는 고객이 작업기술서(SOW)에서 가장 자주 빠뜨리는 부분입니다. RFP에서 이를 상세히 요청하면 협상 전에 손에 쥐게 됩니다. 이것이 계약으로 어떻게 이어지는지는 제 SAP 작업기술서 가이드에서 보여 드립니다.

가중치는 제안서가 도착하기 전에 정하고, 답을 읽은 뒤에는 바꾸지 마십시오. 나중에 가중치를 바꾸는 것이야말로 마음에 둔 후보를 고르고 사후에 정당화하는 방식입니다.

고객의 파트너 선정을 도울 때 가장 큰 가중치는 고객 레퍼런스에 둡니다. 총점이 얼마든 제가 입찰에서 돌아서게 만드는 것은 두 가지입니다. 제안된 인력의 수준이 낮은 경우, 그리고 아키텍처와 계획을 설명하지 못하는 파트너입니다. 평가에는 이 둘이 모두 반영되어야 합니다.

아래 표는 이 우선순위를 바탕으로 만든 가중치 예시입니다. 비율은 귀사 프로그램에 맞게 조정하되, 레퍼런스를 맨 앞에 두고 두 가지 탈락 기준은 유지하십시오.

평가 항목	가중치 예시	높은 점수의 모습	탈락 신호
레퍼런스	30%	비슷한 프로젝트, 연락 가능한 담당자, 파트너의 역할을 확인해 주는 레퍼런스	비교할 만한 프로젝트의 레퍼런스가 없거나, 파트너가 전화를 허락하지 않는 레퍼런스
인력 수준	25%	관련 이력서, 확인 가능한 자격증, 확정된 투입 가능 여부를 갖춘 지명 인력	이름 없는 역할, 빈약한 이력서, 또는 핵심 인력이 「투입 가능 여부에 따름」
아키텍처와 계획	25%	귀사 범위에 대한 설계와 마일스톤, 의존 관계, 리스크를 담은 단계별 계획	일반론적인 계획, 또는 제안 발표에서 설명하지 못하는 설계
상업 조건	10%	단계별, 역할별 공수, 명확한 단가, 상세한 전제 조건과 제외 범위	뒷받침하는 공수 없이 총액 하나만 제시
접근 방식	10%	범위 통제, 테스트, 데이터, 지식 이전에 대한 명확한 방법	귀사에 특화된 내용이 없는 방법론 슬라이드

각 항목은 1~5점처럼 간단한 척도로 채점하고, 서면으로 이유를 적으십시오. 평가자마다 먼저 혼자 채점한 뒤 평가단이 함께 비교합니다.

두 가지 탈락 신호는 점수가 아니라 관문으로 다루십시오. 상업 조건이 좋은 제안서라도 약한 팀을 만회할 수는 없습니다. 상업 조건의 가중치를 일부러 낮게 둔 이유는, 공수와 재작업에 비하면 일 단가는 작은 변수이기 때문입니다.

서면 제안서는 입찰팀이 무엇을 쓸 수 있는지 보여 줍니다. 제안 발표는 실제로 일할 사람들이 그 내용을 이해하고 있는지 보여 줍니다.

실제로 귀사 프로그램에 투입될 사람들을 이름으로 지정해 요청하십시오. 솔루션 아키텍트, 프로그램 매니저, 가장 큰 워크스트림의 리드가 그 자리에 있어야 합니다. 파트너가 다른 팀을 데려오면 점수에 기록하십시오.

그런 다음 가능하다면 슬라이드 없이 귀사 범위에 대한 아키텍처와 계획을 설명해 달라고 하십시오. 쓸 만한 질문은 다음과 같습니다.

1. 가장 복잡한 두 프로세스의 설계를 차례로 설명해 주십시오. 귀사의 프로세스 이름, 법인, 시스템이 나오는지 들어 보십시오.
2. Explore에서 WRICEF 목록이 3분의 1 늘어나면 어떻게 됩니까? 방법, 의사결정 회의체, 비용 논의가 나오는지 들어 보십시오.
3. 제안서의 어떤 전제 조건이 가장 큰 리스크를 안고 있습니까? 자기 계획을 아는 파트너는 즉시 그것을 짚어 냅니다.
4. 이 팀에서 누가, 어디에서 이 일을 해 봤습니까? 그 답은 레퍼런스 확인에서 검증하십시오.
5. 귀사 팀에게서 무엇이, 언제 필요합니까? 실제 계획에는 날짜가 붙은 고객 측 의존 사항이 있습니다.

회의실에서 자신의 아키텍처와 계획을 설명하지 못하는 파트너는 현장에서도 그것을 해내지 못합니다. 이것이 제가 입찰에서 돌아서는 두 번째 이유입니다.

저는 프로그램 도중에 파트너가 수준 있는 인력을 제공하지 못해 파트너를 바꾼 적이 있습니다. 서명 전에 가장 강하게 검증해야 할 것은 좋은 사람들을 실제로 투입할 수 있느냐입니다.

레퍼런스 확인

레퍼런스 확인은 중요한데도 형식적으로 진행되는 경우가 많습니다. 제대로 하십시오. 레퍼런스에게 제가 묻는 것은 귀사와 비슷한 프로젝트에서 그 파트너와 일한 경험입니다.

통화 전에 레퍼런스를 귀사 프로그램과 대조해 보십시오. 같은 제품, 비슷한 규모, 비슷한 산업인지 봅니다. 맞지 않으면 파트너에게 다른 레퍼런스를 요청하십시오.

통화에서는 파트너 측에서 누가 일을 이끌었는지, 무엇을 잘했고 어디에서 어려움을 겪었는지 물으십시오. 그리고 그 사람들이 귀사 제안서에 들어 있는지 물으십시오.

일반론적인 답을 가려내는 법

일반론적인 답은 어떤 SAP RFP에서든 경고 신호입니다. 어느 회사에나 보낼 수 있는 답은 어느 회사를 위해서나 쓴 답입니다.

가장 빠른 확인 방법은 답에 있는 귀사 이름을 경쟁사 이름으로 바꿔 보는 것입니다. 그래도 말이 된다면 그 답은 귀사를 위해 쓴 것이 아닙니다. 마이그레이션에서 이 확인 방법은 제 S/4HANA 마이그레이션 파트너 선택 가이드에서 더 자세히 다룹니다.

RFP 답변에서 일반론적인 답은 보통 다음과 같은 곳에서 드러납니다.

1. 범위 섹션이 귀사 RFP를 그대로 되풀이합니다. 귀사 프로그램에서 무엇이 어려운지에 대한 견해가 없습니다.
2. 계획이 모든 단계에 딱 떨어지는 기간을 씁니다. 귀사의 법인, 데이터, 인터페이스에 따라 달라지는 것이 하나도 없습니다.
3. 귀사 프로세스에 관한 질문에 액셀러레이터 이야기로 답합니다. 도구 이름은 나오지만, 귀사에 그것을 어떻게 쓸지는 나오지 않습니다.
4. 리스크가 업계 공통입니다. 「데이터 품질」과 「변화 저항」은 나오지만, 귀사 시스템에 특화된 것은 나오지 않습니다.
5. 팀 섹션에 사람이 아니라 역할이 나열되어 있습니다. 대개 약한 인력과 같은 문제를 다른 말로 한 것입니다.

일반론적인 답은 잘 쓰였더라도 낮게 채점하십시오.

파트너의 문서를 평가하는 일도 독립적인 시각이 도움이 되는 부분입니다. 입찰에 참여하지 않는 자문가는 설계와 공수 추정을 검증하고, 나중에는 산출물도 검증할 수 있습니다. 그 장단점은 SAP 파트너와 독립 컨설턴트를 비교한 제 글에서 다룹니다.

무엇보다 먼저 범위를 글로 적으십시오. 프로세스 영역마다 한 페이지씩, 포함되는 것, 제외되는 것, 관련 법인과 시스템을 적습니다. 이것이 없으면 제안서의 모든 숫자가 파트너의 전제 조건 위에 놓이게 됩니다.

등급별 파트너 이름은 제 미국의 등급별 SAP 구축 파트너 가이드를 참고하십시오.

RFP, 평가 방식, 받으신 제안서에 대해 독립적인 시각이 필요하시다면 제가 이 일을 돕고 있습니다. 여기에서 저에게 연락하실 수 있습니다.

SAP 구축 RFP에는 무엇이 들어가야 합니까?

파트너에게 배경과 목표, 범위, 인터페이스와 데이터, 귀사가 제공할 수 있는 팀, 정해진 응답 양식, 평가 기준, 일정을 주십시오. 그리고 비슷한 프로젝트의 레퍼런스와 이력서가 포함된 지명 수행팀을 요청하십시오. SAP Activate 단계별 아키텍처와 계획, 단계별, 역할별 공수, 상세한 전제 조건과 제외 범위도 요청하십시오.

SAP 구축 파트너의 제안서는 어떻게 평가합니까?

제안서가 도착하기 전에 가중치가 있는 평가 항목을 정하십시오. 레퍼런스, 인력 수준, 아키텍처와 계획, 상업 조건, 접근 방식입니다. 평가자마다 간단한 척도로 혼자 채점하고 서면으로 이유를 적은 뒤 평가단이 비교합니다. 약한 인력과 파트너가 설명하지 못하는 계획은 총점과 관계없이 제안서를 탈락시킬 이유로 다루십시오.

SAP RFP는 몇 곳의 파트너에게 보내야 합니까?

최소 세 곳입니다. SAP Partner Finder와 SAP 컴피턴시 단계로 롱리스트를 만들고, 관련 레퍼런스가 있는 파트너를 숏리스트에 올리십시오.

SAP 파트너 선정에는 얼마나 걸립니까?

롱리스트부터 계약까지 처음부터 끝까지 약 12주입니다. RFP 자체는 그중 일부일 뿐입니다. 제안 발표, 레퍼런스 확인, 선정된 제안서를 작업기술서로 옮기는 일이 대부분의 시간을 차지합니다.

SAP RFP에서는 고정가와 T&M 중 무엇을 요청해야 합니까?

저는 공수를 정량화한 T&M 방식을 권합니다. 모든 파트너에게 단계별, 역할별 예상 공수를 요청하고, 이를 계약에 적어 실제 공수와 대조해 추적할 수 있게 하십시오. 뒷받침하는 공수가 없는 총액 하나로는 비교도 추적도 할 수 없습니다.

SAP 파트너 제안서의 경고 신호는 무엇입니까?

어느 회사에나 해당될 수 있는 일반론적인 답, 역할은 있지만 지명 인력이 없는 팀 섹션, 다른 곳에서 본 것과 같은 기간이 적힌 계획, 제안 발표에서 파트너가 설명하지 못하는 아키텍처입니다. 레퍼런스에게 전화하지 못하게 하는 파트너도 또 하나의 경고 신호입니다.