지난 포스트 공공 IT제안서 접근전략은 예상외로 너무 많은 분들이 공감해주셨다. 난 어차피 그 분야에 종사하는 경험많은 선수(?)들에게 일종의 팁을 제공한거였다. 따라서 이런저런 앞뒤 사정은 제외하고 컨텐츠의 의미정의에 집중했는데 여러 질문을 받다보니 역시 해설이 조금 필요할 듯 싶어 다시 글을 쓰게 되었다. 그리고 해당 코칭의 당사자였던 A부장님을 다시 만나 코칭의 마지막 시간을 진행하면서 나온 반응도 있어 그 또한 기술하고자 한다.
A부장님의 결과물
A부장은 지난주 위 그림과 같이 설명했을때 무릎을 탁쳤다. 그제서야 감이 잡힌다고 하면서 말이다. 그러나 일주일 후에 만났을때 그는 다시 혼란에 빠져있었다. 결과물을 보니 여전히 ➊➋➌의 구분과 문법이 모호했다. 원인은 간단했다. 그는 RFP에서 고객이(정확히 말하자면 고객사 IT부서의 담당자가) 명시한 문구를 버리지 못하고 적당한 위치를 찾다 다시 혼란에 빠진 것이었다. 그걸 보면서 아마 나의 지난 포스팅을 읽었던 많은 분들도 그렇지 않을까 생각되었다. 그날 나는 A부장에게 다른 방식으로 그 문제를 바라보게 했고 그 방법이 더 쉽다는걸 알았다. 그리고 그 방법을 여기 다시 쓴다. 그리고 몇 가지 질문에 대해서 답을하겠다
다른관점에서 보자
나는 똑같은 얘기지만 표현을 좀 달리해서 설명했다. 아래와 같은 그림이었는데 현재 업무의 흐름에 의거해 주요 주체들을 표시해 놓았다. 각 주체들은 이 일에 대해 자신들만의 입장이 있다. 불만이나 요구사항 같은것들 말이다. 각 주체가 주절거리는 말풍선내의 내용을 정리한 것이 위의 다이어그램이다. 좀 더 정리가 쉽지 않은가? 아래 그림은 시사하는바가 크다. 오늘은 이 그림에 대해 좀 더 얘기하고자 한다
담당부서에 목매지 마라
담당부서(IT부서)만 설득했다고 제안에 승리하는 것은 아니다. 어떤 SI사들은 고객사의 RFP를 대신 써주기도 하고 그들의 프로젝트 기안서 작성을 돕기도 한다. 그러면서 담당부서에만 목을 매는데 조금 더 제안환경을 넓게 확장해서 봐야한다. 담당부서를 설득시킬 논리보다 담당부서가 내부고객(의사결정권자)을 설득할 논리까지 제공해야 이긴다. 거의 담당부서 입장이 되어 고민해야 한다. 그들과 친분이 있든없든 말이다.
시간이 지나면서 제안환경은 담당부서를 의사결정에서 제외시키는 쪽으로 변화해가고있다. 현업인원들 과 외부인사들이 대거 심사위원에 이름을 올리기도 한다. 그러니 포커스를 그쪽으로 이동시켜야 한다. 대대적인 전략수정이 필요하다. 일단 그들은 제안PT 자리에서 제안사의 프리젠터를 처음보게 될 가능성이 높다. 일단 심사위원은 프리젠터를 기본적으로 ‘장사꾼’으로 생각하고 약간 네거티브한 자세로 시작한다고 가정해야 한다.
그래서 처음이 중요하다
상황이 그렇기 때문에 제안사가 전체 비즈니스 상황을 제대로 정리하여 설명하는 것이 중요하다. 현업에서 왔거나 외부에서 온 심사위원이라면 제안사가 비즈니스도 제대로 모르면서 단지 시스템을 납품하려고 달려드는 것을 아주 못마땅하게 여기는 경향이 짙다. 그러므로 시작하자마자 그들의 마인드를 본론의 내용을 수용할 수 있게 ‘세팅’하는 것이 진짜 중요하다. 여기서 실패하면 사실 IT시스템 구축에 대한 내용은 듣지도 않고 자기들이 질문할 수 있는 가격, 유지보수, 비주얼 따위의 대결로 넘어가 버리는 것이다.
IT에 대한 얘기를 최대한 나중에 꺼내고 그들의 비즈니스적 목적에 집중해야 한다. 우리는 결국 그 비즈니스적 목적을 충족시키기 위한 수단으로 IT시스템을 제안하는 것이니 말이다.
RFP의 내용을 과감하게 버려라
고객이 RFP상에서 명시한 배경 및 목적에 대한 문구를 버릴 용기가 있느냐가 최대 관건이다. 사실 내가 구경한 대부분의 RFP는 말도 안되는 멋진 단어들의 조합일 뿐이다. 따라서 일단 RFP의 내용이 별로라면 고민하지 말고 제로베이스에서 시작해서 우리만의 논리를 갖춘다음 비로소 그들의 불편한 심기를 어떻게 달랠지를 (나중에) 걱정하라. A부장 역시 RFP문구를 버리라는 나의 조언에도 불구하고 고객의 심기를 건드리게 될까봐 선뜻 그러겠노라고 하지 못했다.
RFP 문구들의 특성은 수수께끼 같아서 배경, 목적, 필요성, 목표, 요건이라고 정리된 내용들을 사실 어디에 집어넣어도 묘하게 말이 된다. (지금 바로 RFP를 꺼내서 시험해보라) 그러니 ‘당신들이 준 RFP만 보고 쉽게 정리해봤다’고 뻔뻔스럽게 얘기하라. (그것마저 눈치채지 못할 것이다)
A부장의 경우 제안서엔 고객이 명시한 그대로를(왜냐하면 어차피 잘 안읽을 것이기 때문에), PT버전엔 우리의 논리를 들고가기로 했다.
꼭 이렇게까지 해야하나 ?
이 접근에 대해 회의적일 수도 있다. 꼭 그렇게해야 하나 ? 그렇게하면 승률이 높아질까 ? 난 두 가지 측면에서 긍정적이라 본다. 1) 뒤의 모든 내용에 정당성을 부여하여 튼튼한 논리적 방어벽이 된다. 2) 이 자체가 제안을 차별화 시킨다. 난 현재 은행원들의 업무공간이 비좁고, 메모는 거의 안하고 보기만하는 특성때문에 새로운 탁상달력은 공간에 최적화 되어야 하고 보는 달력으로서의 디자인을 가져야 한다는 두 가지 요건을 초반에 주장하고 그에 대한 공감을 얻어냈다. 후반부에 얘기할 디테일, 가령 탁상달력의 높이, 숫자의 크기, 메모공간의 축소, 폰트의 종류 등 세세한 스펙 하나하나는 그 두가지 요건의 통제하에 놓이게 되면서 청중의 챌린지를 방어하기 좋아진다. 숫자의 크기가 너무 큰거 아니냐는 질문은 ‘보는 캘린더로서 1미터 이상의 거리에서 평균시력만 가지고도 보여야 한다’는 초반 요건으로 버텨낼 수 있다.
제안의 차별화 측면도 크다. 거의 대부분이 시간에 쫓기는 상황에서 논리적 완성도와 단순함은 기대하기 힘들게 되었는데 우리는 의도적으로 이를 알기쉬운 논리대결로 몰아가야 한다. 전체적인 제안의 특성이나 구도를 다른 제안팀에서 파악할 수 있었냐고 (무언의) 압박해들어가야 한다. 디자인이나 스피치가 승리의 결정요건이 되는 것은 여러 제안사 전체가 특징없는 내용으로 일관했을때다.
원문 : 공공제안서 접근전략 2
관련 기사
