[SI이야기] 제안프로세스(RFI/RFP/제안서)

오늘은 제안 프로세스에 대해서 개략적인 설명을 하려고 한다. 전체 프로세스를 이해해야 SI에서 각각이 하는 일을 이해하기가 쉽다. 전체 프로세스에 대해서 가장 이해하기 쉽게 그려놓은 그림을 운 좋게 찾아서 이를 바탕으로 설명을 차근차근 진행해보겠다.(혹시 원문의 내용이 궁금하다면 아래 블로그 주소를 참고하기 바란다.)

 

출처 : https://blog.naver.com/wonselee/70048165137

제안 프로세스는 위의 그림과 같이 이루어진다.

 

0. 이해관계자

가장 기본적으로는 둘의 이해관계가 있는데 하나는 '발주자'라고 해서 흔히 우리가 말하는 '갑' 또는 '고객'이다. '공급자'는 발주자가 원하는 요구사항을 제공할 회사를 말한다. 이 '공급자'는 한 개의 회사일 수도 있고, 여러 회사로 구성될 수도 있다. 이는 발주하는 사업의 규모 및 특성에 따라 공급자가 결정하는 사안이다. 물론 때때로 발주자에 의해 제한이 있을 수는 있다.

* 이후 발주자는 고객사, 공급자는 SI회사라고 하겠다.

 

1. 발주준비 - 문제정의

고객사의 문제정의가 가장 먼저다. 쉽게 이야기하면 '무엇을 하려고 하는가?'의 질문에 대한 답이다. 예를 들어 "현재 우리 회사의 시스템이 너무 노후화되어서 대대적인 시스템 교체 작업이 필요해." 또는 "인공지능으로 사기를 잡아낼 수 있을까?"라는 질문이 되기도 한다. 여기에서 보통 고객사는 그 회사의 IT전략팀이나 IT팀, 아주 가끔 실제 업무를 수행하는 비즈니스팀이 되기도 한다.

 

2. RFI - 정보요청서(RFI) 작성

보통 고객사는 해결하고 싶은 문제가 있고 그게 IT 기술이 요구된다는 것까지만 알고 있다. 어느 회사의 무슨 기술이 어떤 솔루션이 있는지도 잘 모르고, 이 문제를 해결하기 위해 어느 정도의 예산이 필요하고 얼마만큼의 기간이 소요될지에 대해서 가늠하기도 어려워한다. 그걸 해결하고자 고객사가 가장 먼저 하는 일이 이 정보요청서(RFI)를 작성하는 일이다.

 

정보요청서(RFI)는 영어로 Request for Information이다. 뜻 그대로 정보에 대한 요청인 것이다. 이들은 이 요청서에 알고 싶은 내용을 써서 SI회사들에게 보낸다. 여기서 이 RFI를 받을 수 있느냐 마냐가 SI회사 측 영업에게는 매우 중요한 일이다. RFI를 받아야 자기 회사에 맞는 정보를 제공해줄 수가 있기 때문이다. 시장에 A 기술과 B기술 둘 다 핫한데, 만약 A 기술을 쓰는 회사는 RFI를 받았고 B기술을 쓰는 우리 회사는 못 받았다면 고객사는 우리 회사의 B기술보다 A 기술을 RFP에 넣을 확률이 매우 높다. A 기술을 쓰는 회사가 제공하는 정보에는 A 기술의 장점만 가득 적혀있을 것이기 때문이다.

 

3. RFI - 답변서 작성

SI회사는 RFI에서 요청하는 정보에 대해서 최대한 성실하게 답변을 적어서 제공한다. 제안서와 달리 이 답변서는 SI회사에서 자유롭게 작성해서 회신할 수 있는 편이다. 워드로 작성해서 많이 회신하기도 하고, 제출하고 별도로 설명회를 하거나 하지 않기 때문에 크게 부담을 갖지도 않는 편이다. 다만, 중요한 것은 정보를 제공함에 있어서 아이디어보다는 자기 회사의 장점이나 특별한 기능을 적어서 회신하는 게 유리하며 가격/견적을 제공할 때는 discount가 들어가기 전의 소비자가(?)를 적어서 보낸다. 그래야 고객사에서 예산을 충분히 잡을 수 있다. 그리고 그 예산은 SI회사가 적어서 낸 것보다 거의 항상 적기 마련이다.

 

4. RFP/제안발표 - 제안요청서(RFP) 작성

고객사는 몇 개의 업체를 통해 받은 정보를 바탕으로 제안요청서(RFP)를 작성한다. RFP는 Request for Proposal이라고 해서 뜻 그대로 제안에 대한 요청서이다. 고객사에서 무엇을 원하는지, 배경이 무엇이고 목적이 무엇인지 적고, 기본적으로 고객사에서 제공해줘야 하는 고객사 IT시스템의 정보를 적어준다. 여기에는 요구사항이 다 적혀 있는데 이 요구사항은 고객사가 본인이 요구하는 내용에 대해 잘 알면 알수록 구체적으로 명시된다. 그리고 여기에서 RFI에 제공했던 정보들이 나타나는데 경쟁사가 영업을 잘했다면 경쟁사에서는 기본으로 제공되는 기능이고 우리는 추가로 개발해야 하는 기능들이 들어가기도 한다. 우리 회사가 영업을 잘했다면 너무나도 쉽게 작성할 수 있는 요구사항들이 줄지어서 보이게 된다.

 

5. RFP/제안발표 - 입찰공고

RFP 공고 방식은 회사마다 조금씩 다르다. 대표적으로 공공회사는 나라장터에 업로드를 하는 편이다. 자체적으로 규모가 큰 회사는 고객사의 홈페이지에 자체적으로 업로드하기도 한다. 이 둘의 경우는 RFP를 구하기 다소 쉬운 편인데, 영업을 통해서만 구할 수 있는 경우가 있다. 고객사에서 자의적으로 정해서 본인들이 적합하다고 생각하는 3개 업체에만 골라서 주는 형식이다. 언제나 경쟁입찰이어야 하기 때문에 1개 업체에게만 주는 경우는 없다. 1개 업체를 마음속에 골랐어도 '들러리'라고 해서 떨어져 줄 업체가 들어오는 게 보편적인 문화다. '들러리'가 없는 경우 경쟁입찰은 유찰이 되며 재입찰의 과정을 거치게 된다. 

 

우리 회사가 들러리라는 걸 알면서도 제출하는 경우가 있다. 엄청나게 많은 노력과 시간이 들어가는 데에도 불구하고 그렇게 하는 데에는 이유가 있다. 고객사의 '보복' 때문이다. 들러리를 하지 않아서 유찰될 경우 프로젝트가 지연될 수가 있는데 이런 경우 들러리를 하지 않은 회사는 다음 기회에도 사업을 주지 않는 보복이 돌아온다는 두려움이 생기기 마련이다. 누구도 직접적으로 말하지 않는다. 하지만 그걸 감수하면서까지 제안서를 내지 않을 용기가 있는 사람은 없다.

 

참고로 들러리를 서달라고 고객사가 나이스 하게 부탁하는 경우도 있고, 들러리를 서달라고 경쟁사에서 부탁하며 제안서를 쥐어주기도 한다. 당연히 떨어질 제안서를 주는 거지만... 일단 제안서를 작성하고 제출하는 데에 리소스가 들지 않으니 해주는 회사들도 있다.

 

5. RFP/제안발표 - 제안설명회

제안설명회는 고객사에서 RFP를 한번 설명해주는 자리다. 안 하는 회사도 있고 하는 회사도 있는데, 이런 경우는 보통 RFP를 하드카피(종이)로 받아가는 형태이고 고객도 경쟁사도 모두 누가 이 제안에 참여하는지 알 수가 있게 된다. 이때 설명을 토대로 제안을 준비할 수 있고 또 이 자리에서 모두가 있는 곳에서 질문을 함으로써 Q&A에 대한 공정성도 가지게 된다. 이때 받게 되는 RFP는 외부 유출이 금지된 경우가 많다. 그렇기 때문에 하드카피로 받아와서 쉽게 복사/스캔을 해서 전달하지만 이 자료가 유출이 되는 경우 고객사에서 바로 알게 된다. 고객사와의 관계가 나빠질 수 있는 타이밍이 되기도 한다.

 

유출이 된다 하면 보통 기사로 나오거나, 소문에 소문을 타고 고객사 귀로 들어간다던가 하는 형태인데 하드카피에 고객사가 별도로 표시를 해두기도 해서 고객은 어느 회사에서 유출했는지 바로 알아낼 수 있다. (모두가 그런지는 모르겠으나, 그런 고객사를 보긴 했다.)

 

이게 민감한 이유는 나름 고객사에서는 야심 차게 준비하는 일인데 경쟁사에 그 정보가 빠져나가는 것도 싫은 거고, 어떤 기능을 갖춘 시스템을 만든다는 것도 비밀로 하고 싶어 하는 경우가 많기 때문이다. 그걸 베껴서 따라 하는 경쟁사는 너무나도 많다.

 

6. RFP/제안발표 - 제안서 작성

SI회사의 헬이 시작되는 순간이다. 보통 시스템 규모와 제안서 작성 기간은 비례하는 편인데 요즘 본 제안서는 14일 정도 줬던 것 같다(주말 포함). 악덕한 고객사는 연휴를 다 포함해서 14일을 주기도 하고, 꼭 연휴를 껴서 RFP를 발주하기도 한다. (어디인지는 비밀 ^^) 

 

이 제안서를 작성하는 것은 RFP에서 요구하는 사항에 맞춰서 작업하며 규모에 따라 다르지만 슈 과장은 가장 적게는 3명, 많게는 수십 명이서 작업했었다. 기간은 슈 과장은 짧은 건 3일 만에 쓴 적도 있고, 긴 건 3주.. 정도였던 것 같은데 3개월 정도 주는 경우도 많이 봤다.

 

사실 RFP를 읽고 제안서를 작성하는 부분은 나중에 더 다루겠지만, 처음이 도대체 뭔지 모르겠다는 생각이지 몇 번 해보면 또 이거구나 하면서 하게 된다.

 

7. RFP/제안발표 - 제안서 평가

제안서는 서면으로 대체되는 경우는 매우 드물다. 보통 제안서를 제출하면 설명회를 하게 된다. 제안 PT라고 보통 부르는 이 활동은 "너네 요구사항 잘 알겠고 그래서 우리가 어떻게 잘할게"를 발표하는 자리다. 제안서에서 요점만, 장점만 추려서 발표하는 자리로 보통 발표자는 그 프로젝트를 수행하는 PM이 하게 된다. 이 PT를 위해서 내부적으로 자료도 많이 수정하고 발표 리허설도 상당히 많이 하는 편이다.

 

참고로 제안서를 평가하는 기준은 보통 RFP에 다 명시되어 있다.

 

8. 업체선정 - 공급업체 선정

제안서, 제안 PT, 가격/견적 등을 토대로 RFP에서 명시한 기준으로 평가를 진행해서 공급업체를 선정한다. 근데 이때 '공급업체가 누구다!'라고 하진 않는다. '우선협상대상자'라는 표현을 쓰며 1순위 2순위 3순위를 놓고 차례대로 협상을 진행한다는 뜻이다. 1번 회사와 협상을 했다가 조율이 잘 되면 그대로 공급업체가 되는 것이고, 만약 협상이 잘 안돼서 무산되면 2번 회사에게 협상권이 넘어가는 것이다.

협상에서 기회를 날리는 회사는 거의 없다. 그럼에도 협상이 결렬되는 경우가 있는데 양쪽에서 절대 양보할 수 없는 무언가가 나왔을 경우다. 협상에서 회사 간 사이가 틀어지는 경우도 많이 발생하기 때문에 보통은 좋게 좋게 협상하고 넘어가는 편이다.

---

다음엔 각 단계별로 자세하게 쓸 수 있는 항목들을 뽑아서 추가로 적어보도록 하겠다. 제안 프로세스를 여러 번 경험해본 사람으로서... 이게 글로 써서 되지 않을 수도 있지만, SI회사에서 일한다면 제안을 피하기는 힘든 만큼 대략적인 감을 잡아보는 것도 좋을 것이다. 특히나 일하는 방식이나 체계에 있어서 많은 도움이 되었으면 한다.