IT시스템 구축에 대한 제안서를 쓴다는 것에 대해 필자의 경험을 바탕으로 몇 자 적어보려 한다. 다시 말하지만 이 글은 필자의 개인적인 경험과 지식을 바탕으로 쓰는 글이다. 독자들 중에 해당 분야에 종사하면서 '어, 우리는 저렇게 안 하는데..' 라는 생각이 드는 사람도 있겠지만, 필자가 모든 케이스를 완벽하게 섭렵하고 있는 건 아니니, 이런 경우도 있나 보다 정도로 이해하시라.
IT시스템 구축 사업은 사전 조사를 거쳐 입찰공고 또는 사업설명회 ▷ 제안요청서 배포 ▷ 제안서 및 견적서 제출(입찰) ▷ 제안 발표(프리젠테이션) ▷ 제안 평가 ▷ 우선협상대상자 선정 및 발표 ▷ 우선협상 및 계약 ▷ 사업착수 와 같은 순서를 대략 따르게 된다. 본 글은 이 중 제안서를 작성하는 부분에 대해 살펴볼 것이다.
1. 제안요청서 받기
IT시스템 구축을 위해 공공기관이나 기업체에서 입찰공고를 하고 사업설명회를 하고 제안요청서(RFP: Request For Proposal. 제안을 해달라고 요청하는 것)를 배포하면, 그 사업을 하고 싶은 IT업체들은 제안요청서를 받아 와서 제안서를 만들어서 제출하게 된다.
물론 아무한테나 다 제안요청서를 주는 것은 아니다. 발주처에서는 사전에 구축하고자 하는 IT시스템과 관련된 업체가 어떤 데가 있는지 조사하고 그 과정에서 각 업체의 영업 담당들이 발주처 담당자들과 만나 미리 이야기도 하고 접대도 해 주는 등의 과정을 거쳐 발주처의 낙점을 받은 업체들만이 제안요청서를 받아 그 사업에 참여할 수 있는, 즉 제안서를 내고 평가받을 수 있는 기회를 갖게 된다.
이렇게 사업공고가 나기 이전의 치열한 물밑작업은 각 업체의 영업맨들의 영역이다. 사업 규모나 내용, 그리고 발주처에서 사업결정에 대한 권한을 가진 사람의 스타일에 따라 다를 순 있겠지만 어찌 보면 제안요청서를 받기 전에 이미 어떤 업체가 수주할 것인가 하는 대략의 윤곽이 정해져 있는 경우도 많다. 그만큼 사전영업(전문용어로 프리세일즈 Free Sales 라고 하면 되겠다.)이 중요한 요소가 되는 것이다.
다만, 본 글에서는 영업적인 부분은 언급하지 않고 기술적인 측면에서 제안서를 만들고 제출하고 발표하는 과정을 서술해 보려는 것이니 혹여 영업 쪽의 역할이 왜 빠졌을까 하는 생각은 접어두시라.
2. 제안팀 구성하기
일단 제안요청서를 받은 업체는 회사 내에서 이 제안 작업을 총괄할 제안PM을 선정하고 일을 도와줄 사람들을 골라 제안팀을 꾸린다. 말이 제안팀이지 규모가 작은 업체의 경우엔 한두명이 몽땅 다 맡아서 하는 경우도 많고 일이 몰릴 경우 심지어는 혼자서 여러 개의 제안서를 동시에 써야 하는 경우도 허다하다.
제안PM을 선정하는 것도 대기업 계열의 대형SI인 경우에는 해당 분야의 경험자로 골라서 하겠지만 작은 업체의 경우엔 그냥 시간 남는 사람이 하거나 (그런 사람이 있을 리 없겠지만..) 아니면 대개 제안작업 하는 사람이 몇명 정해져 있기 마련이다. 보통 이런 사람들은 제안작업 뿐만 아니라 프로젝트 나가서 PM도 하고 프리세일즈도 하고 접대도 하고 하는 올라운드 플레이어인 경우가 많다. 작은 업체에서는 어쩔 수 없는 현상이다.
3. 제안요청서 검토하기
이렇게 제안PM과 제안팀이 꾸려지면 우선 제안서를 어떤 내용으로 써야 하는지, 발주처에서 중요하게 생각하는 부분이 뭔지 등을 정확하게 파악하기 위해 제안요청서를 면밀하게 검토한다. 검토 작업은 제안PM이 혼자 하거나, 대규모의 경우 제안팀 팀원이 각 전문 분야별로 분담하여 검토하기도 한다. 예를 들면 인프라 부문(하드웨어, 네트워크), 사업관리 부문, 업무 부문, 개발 부문 등으로 구분할 수 있다.
해외와 달리 국내에서는 제안요청서에 실제 구축할 시스템의 구체적인 내용에 대해 자세히 설명되어 있는 경우가 드물다. 국내 IT사업의 제안요청서는 거의 대부분 사전에 접촉한 업체들로부터 제안요청서에 어떤 내용이 들어가야 하는지에 대한 의견이나 정보를 수집하여 그대로 짜집기하여 배포해 버리기 때문에 정작 발주처에서는 해당 시스템 구축에 대해 충분히 고민하여 그 내용을 제안요청서에 담아내는 경우가 거의 없다고 보면 된다.
어쨌든 이렇게 제안요청서를 검토하는 과정에서 미비하거나 앞뒤가 맞지 않거나 불명확한 부분이 발견되면 그에 대해 발주처에 확인하는 등의 과정은 제안작업 기간 내내 계속 일어나게 마련이고 또 그렇게 되어야 정상이다. (이런 식으로 표현하는 이유는 그렇게 하지 않는 경우가 더 많음을 의미한다.) 그건 뒤에서 다시 언급하기로 하고 일단 다음 단계로 넘어가자.
4. 제안목차 정하기
제안요청서를 검토하면서 제안서를 어떤 내용과 순서로 작성할 것인지를 정하게 된다. 이를 위해 가장 먼저 제안서의 목차를 정의한다. 일반적으로 제안요청서에는 개괄적인 목차를 제시되어 있는 경우가 많으며 업체에서는 이 목차를 기준으로 하여 보다 상세한 세부 목차를 정의하게 된다.
IT시스템 구축을 목표로 하는 제안서의 경우, 대개 제안 목차는 다음과 같은 내용으로 구성된다. 순서가 바뀌거나 세부 내용에서의 가감은 있을 수 있으나 거의, 대부분의 목차는 이런 식으로 만들어진다. 이때 목차를 정하는 주체는 업체 규모나 조직에 따라 다를 수 있지만 대개 앞서 언급한 제안PM이 주도하여 담당자를 지정하거나 아니면 직접 정하게 된다.
제안서 목차 예시 펼쳐보기
이렇게 목차가 정해지면 각 항목별로 내용을 작성할 담당자나 업체를 지정하여 제안서를 작성하도록 할당한다. 이 때 제안서를 작성하기 위해 공통적으로 사용할 템플릿을 같이 배포하는데 주로 파워포인트로 양식을 만들어 사용하게 된다. 대형SI 업체의 경우 자체적으로 제안작업을 전담하는 팀이 따로 있어서 제안작업이 시작되면 PD(파워포인트 디자이너)가 제일 먼저 템플릿을 만들어서 제안팀에 배포하게 된다. 소형업체의 경우에는 제안담당자가 직접 만들거나 외부 전문PD에게 의뢰하여 작업하기도 한다.
5. 제안품목 정하기
제안요청서를 검토하고 목차도 정했다. 이제 제안서만 열심히 쓰면 게임 끝나는 건가?... 그럴 리가요. 남의 돈 먹는 게 그리 쉬운 일이 아니다. 제안을 할 때 구축 방안에 대한 내용을 만드는 것도 중요하지만 비용에 대한 부분도 중요하다. 그리고 비용은 크게 인건비와 하드웨어, 소프트웨어 등으로 구분된다.
제안작업을 할 때 가장 초반에 결정되어야 할 것 중의 하나가 바로 하드웨어와 소프트웨어 등 시스템 구축에 필요한 품목들을 어떤 걸로 제안할지 결정하는 일이다. 제품과 모델명 등을 결정하고 그다음엔 이 제품을 어떤 업체를 통해서 얼마에 공급받아서 발주처에 제안할 것인가 하는 걸 결정해야 한다. "제품 공급업체 선정 및 견적 작업" 이라는 우아한 전문용어를 사용하면 그럴 듯하게 정리된다.
시스템 구축을 위해 필요한 기간과 투입인원 등은 제안서를 작성하는 과정에서 결정되겠지만 전체 비용을 결정하기 위해 이 제안품목에 대한 결정은 반드시, 그리고 가능한 빨리 이루어져야 한다. 같은 사업에 입찰하는 경쟁업체가 많을 경우 이런 품목 결정 과정에서 업체들 간의 이해관계가 복잡하게 얽혀 복마전을 방불케 하는 더럽고 치사하고 황당한 꼴들도 많이 보고 당하고 저지르고 하게 된다. (난 보기만 했다..진짜로.. 영업 아니거든..) 그에 대한 비화는 나중에 심심하면 한번 알려 줄 수도...
6. 제안서 쓰기
본 글의 제목이자 가장 중요한 내용인 제안서를 드디어 쓴다. 근데, 이 제안서 쓰는 게 사업마다 내용이 다 다르기 때문에 어떻게 쓴다 라고 정해져 있는 게 없다. 그냥 제안요청서 보고 어떤 내용을 집어넣어야 고객이 감동 먹고 점수를 후하게 줄까를 고민하면서 있는 말 없는 말 다 때려넣어서 무조건 다 하겠습니다. 라는 취지로 쓰면 된다.
사실 제안작업을 하는 과정에서 개인적으로 가장 고민스럽고 짜증나고 번뇌를 느끼는 부분이 이거다. 체질적으로 거짓말하는 걸 무척 싫어하는데, 제안서를 쓸 때는 진실만을 말해서는 제안서를 제출할 수조차 없는 경우가 발생한다. 예를 들어 제안요청서에는 A라는 요건이 필수라고 되어 있는데 업체는 사실상 이 요건을 하는 게 불가능한 경우가 있다. 이럴 때 못한다..라고 하면 그냥 스펙아웃이 되어 버린다.
되든 안 되든 제안요청서에서 요구하는 내용은 일단 무조건 '할수있다' '해주겠다' 라고 제안서에 쓴다. 아니 써야 한다. 그렇게 강요받는다. 이 지점에서 내 자존심은 구겨지고 정직한 양심 따위는 개나 줘버려야 한다. (개는 무슨 죄냐...미안..)
급 마무리...
이렇게 해서 제안서를 멋지게 잘 만들어서 발주처가 정한 방식대로 기한 내에 무사히 제출하면 기술 파트 입장에서의 제안 작업은 일차적으로는 마무리된 것이다. 간단히 "제안작업"이라는 네 글자로 부르지만 막상 누구도 말해주지 않고 책에도 안 나오는 IT 제안서 쓰기에 대해 표현하려다 보니 애초 필자가 예상했던 것보다 내용이 매우 많이 늘어나야 할 것 같다.
그래서 일단 본 글은 이쯤에서 급 정리하고 다음 글에서 계속 살펴보기로 하겠다. 긴 글 읽어내리느라 고생들 하셨을 테니 맛있는 거 사 드시고 푹 쉬시라.
댓글 없음:
댓글 쓰기