Sales PM의 고충

창업 이야기 2화

창업 이야기 1화

 SI(System Integration) 회사와 Solution 회사는 분명한 차이가 있다. SI 회사는 고객이 원하는 거 다 만들어주는 Total Solution이라면, Solution 회사는 본인들이 주력으로 삼고 있는 Solution이 확실히 있는 회사를 말한다. 하지만 이 역시도 고객의 요구에 따라 조금(?)의 커스터마이징이 들어가지만, SI 회사들이 하는 거완 하늘과 땅 차이다. 이 글의 주제는 바로 Solution 회사의 Sales PM 이야기다.

 Sales PM 조금 생소한 단어일 수 있다. 쉽게 풀어쓰면 영업건에 대한 Sales 담당자다.  퍼소나로 들어가면 이 브런치의 작가인 나의 이야기다. 창업을 결심하기 전인 2023년 1월까지 Sales PM으로서 국내와 외국에서 10년 이상 경험했던 이 업의 고충에 대한 이야기를 아래 주제별로 풀어보려고 한다.

1. 영업과 세일즈PM의 발전이 회사의 발전은 아니다.
2. 신입은 손도 못 대는 정보요청서(RFI) 

3. 본게임인 제안요청서(RFP)는 전쟁이다 

4. MZ세대. 주 52시간. 소는 누가 키우나?

5. 사건 사고의 집결지 - 컨소시엄

1. 영업과 세일즈PM의 발전이 회사의 발전은 아니다.

 영업은 고객을 만나고 이야기하고 밥도 먹고 술도 먹으며 그들이 준비하고 있는 IT 프로젝트를 미리 알아내는 네트워킹을 하는 사람들이다. 즉 여러 고객(회사)을 담당하고 영업 파이프라인을 만들어 가는 역할을 한다.

최민식의 유명한 대사. 사실 영업을 엄청 잘하는 사람인 것이었다.

 그렇게 영업이 고객관리를 해서 물어와 주면, 세일즈PM은 우리가 판매하는 솔루션의 기능과 특장점을 고객에게 설명한다. 세일즈PM은 제품과 고객 그리고 시장의 흐름까지 잘 알고 있어야 한다. 중견기업 이상에서는 이렇게 나누어져 있지만, 중소기업 등지에서는 특별히 나누지 않고 둘 다 하는 경우가 많다.  

 영업이 고객관리에서 가장 중요하게 여기는 것이 바로 네트워크다. 이들에게 자산은 바로 이 네트워크다. 회사를 떠나도 이 네트워크는 영업자의 자산이 되어 어디든 따라온다. 반대로 회사는 이런 네트워크가 많은 영업자를 놓치는 것은 네트워크를 잃을 가능성이 크기 때문에 굉장한 리스크로 다가온다.

 세일즈PM의 모토는 적을 알고 나를 알면 백전백승이다. 우선 고객의 니즈를 명확히 알아야 하고, 우리는 어떤 무기를 가졌는지 알아야 한다. 그래야 입찰에서 승리할 수 있는 전략을 세울 수 있기 때문이다. 하지만 여기서도 영업과 비슷한 문제는 너무 개인 능력에 대한 의존도가 크다는 것이다. 

 개발자도 물론 개인 능력 의존도가 크지만 최소한 Github 같은 개발 소스 코드 버전 관리를 할 수 있지 않은가. 영업의 Github를 들어본 적이 있는가? 

2. 신입은 손도 못 대는 정보요청서(RFI) 

 작년에 싱가포르의 영업팀에서 사전에 고객과 RFP를 만들기 위해 RFI를 긴밀하게 작성해서 줬다고 해서, 우리 솔루션 경쟁 우위가 많겠지 하고 RFP를 봤는데 적잖이 당황했다. 왜냐면 타사 대비 확실한 경쟁 우위에 있었던 우리의 특허 기술이 하나도 안 들어가 있었기 때문이다. 내가 왜 안 넣었냐고 물어보니 몰랐었다는 어처구니없는 답을 들었다. 왜 몰랐을까. 매 제안서마다 한 장을 할애해 가면서 이게 우리의 특화된 기술이다를 써왔는데, 이런 것까지 내가 말로 다 해줘야 하나. 싱가포르에 있던 영업 담당자는 그래도 우리 회사에 4년이나 다녔는데.. 대체 뭘 보고 뭘 하고 다닌 거지. 회사의 주요 기능들이 제대로 정리가 안 됐던 문제. 아카이빙 따위는 존재하지 않는 정보 공유 시스템의 부재. 

입찰 프로세스 정리. 출처 : https://blog.naver.com/wonselee/70048165137

 위 자료에서 보듯 RFI는 발주자에서 여러 공급자에게 RFP를 만들기 위해 요청을 한다. 그리고 그것을 취합해서 RFP를 만들어 다시 공급자에게 제안을 요청한다. 개인적으로 나도 RFI에 우리에게 유리한 인증서나 주요 기술등을 넣은 적이 있다. 물론 RFI를 하지 않고도 RFP를 잘 분석하고 제안만 고객들에게 잘해도 프로젝트를 수주한 케이스는 얼마든지 많다. 하지만 RFI에 주요 기능을 넣어 RFP에 반영이 됐다면 이건 이쪽 분야에서 말하는 작업이 다 된 케이스라 수주확률이 매우 높다. 그렇기 때문에 싱가포르의 케이스는 나와서는 안 되는 멍청한 실수였던 것이다. 4년이란 시간은 짧은 경력이 아닌데도 불구하고 못하는걸 보면, 주니어나 경력자라도 들어온 지 얼마 안 되는 분들에게는 감히 손도 못 대는 영역이다. 

3. 본 게임인 제안요청서(RFP)는 전쟁이다. 

 난 솔직히 RFI를 많이는 못해봤다. 하지만 RFP를 분석하고 제안과 발표를 통해 그 누구보다 높은 수주율을 기록했다고 자부한다. 그렇기 때문에 다른 부분에서 조금 미흡했다 하더라도 본게임인 RFP만 분석과 제안을 통해 고객의 마음에 들 수 있다면 충분히 경쟁입찰에서 승산이 있다. 하지만 RFP를 받아서 분석하고 제안하는 과정이 절대 녹록지가 않다.

쳐다도 보기 싫은 제안요청서

 큰 프로젝트인 경우 제안요청서 페이지 수만 200페이지에 달한다. 공공 입찰은 조달청 나라장터에서 공개 입찰 형태를 띄우고 있지만, 민간 입찰 같은 경우는 발주처에서 타 경쟁사에 노출이 될까 봐 가끔 하드카피로 주기도 한다. 파일로 준다고 해도 일단 프린트를 해서 밑줄 그어가면서 보는 것이 대다수의 세일즈PM이 RFP를 보고 하는 첫 번째 일이다. 공공기관 입찰은 또 짜증나는게 무조건 한글이다. 주로 외국 입찰건만 해왔던 나는 가끔 국내 입찰 세일즈를 할 때마다 이 한글 때문에 현타가 오곤 했다. 여자저차 분석을 하다 보면 우리 같은 솔루션 회사들은 주로 우리와 관련된 RFP만 받기 때문에 봤던 내용들이 상당수 많다. 그럼 또 고민하게 된다. 내가 이 요구사항을 어디서 작성했더라.. 아 작년 A프로젝트였구나. 그러면서 내 기억을 더듬고 올라가서 그 문서들을 일일이 살펴보고 일단 복사해서 가져다 쓴다. 그런데 문제는 내 팀원들은 모른다는 것이다. 나야 개인적으로 해왔던 것들이 많아서 기억이라도 더듬지만 내 팀원들은 눈만 꿈뻑꿈뻑.. 결국 내가 분석을 하고 그 친구들한테 미진한 작업들을 분류해서 일을 할당해야 한다. 이 일이 보통 귀찮은 게 아니다. 또 기술적인 요구사항들은 따로 분류해서 개발팀장에게 가서 물어보고 작성요청까지 해야 한다. 개발팀장은 개발하기도 바빠 죽겠는데 내가 영업까지 도와줘야 해?라는 입장을 취한다. 그럼 영업은? 사무실에만 있나? 맨날 고객이 쳐 부르면 밖에 나가서 고객 미팅 해야 하고 사무실 들어오면 영업 문서 분석해야 하고 저녁에는 고객과 저녁약속도 있는데. 이렇게 솔루션 입찰에 각 담당자들이 본연의 업무에 집중을 못하는 경우가 이 업계에서는 다반사다.

4. MZ세대. 주 52시간. 소는 누가 키우나? 

입찰 준비는 누가 하나

영업에서 주니어들이 할 수 있는 일은 보조적인 일이 대부분이지만, 그 보조적인 즉 반복적인 업무들을 처리해 주는 것만으로도 많은 도움이 되기 때문에 팀장들은 팀원들의 눈치를 볼 수밖에 없다. 특히 요즘처럼 MZ란 말이 유행처럼 번지고 있고 주니어들의 이직률도 빈번해서 더더욱 팀원 관리는 주요 이슈 중에 하나다. 

 그런데 정부에서 또 대한민국 사람들의 워라밸을 책임져 주겠다고 하면서 주 52시간제를 시행하기 시작했다. 과연 이 법안이 기업들 특히 중소기업들에게 현실적인 걸까? 나는 참고로 그 누구보다 야근을 안 좋아한다. 실제로 난 결과만 좋으면 과정에서 하는 척 따위는 하지 말자가 모토였다. 하지만 해야 할 때는 당연히 야근도 하고 집에 가서도 일을 하고 최선을 다했다. 주 52시간을 하면서 안 그래도 관리가 힘든 MZ에게 명분만 챙겨준 건 아닌지.. 그리고 위에 작성한 것처럼 입찰에서 RFP를 보통 최소 2-3개씩 쳐내야 하는 상황에서 경험도 없는 주니어들이 주 52시간 동안 커피 마시러, 담배 피우러, 머리 식히러 업무 중에 돌아다니고 칼퇴를 하면 정말 "소는 누가 키우나!" 재밌는 건 입찰 프로세스는 생산성 툴 따위도 없다. 그냥 사람 갈아 넣어야 하는 곳이 이 분야인데.. 이러니 입찰 분야가, SI가 평생 발전이 없었고 앞으로는 더더욱 비효율의 끝으로 달려갈 것으로 예상된다.

5. 사건 사고의 집결지 - 컨소시엄

 창업전 나의 마지막 프로젝트였던 스마트시티 사업. 큰 사업이었기 때문에 단독 입찰은 불가능했다. 대기업, 중소기업, 기관 등의 각 분야에서의 인증서, 사업 레퍼런스, 특장점등을 갖춘 업체들끼리 컨소시엄이 되어야만 수주가 가능했다. 입찰 준비 과정에서 대기업은 주로 PM 역할임과 동시에 이름만 빌려준다. 그리고 그 밑에 PL(Project Leader) 역할을 하는 중소기업이 있다. 그 기업에서 RFP를 분석하고 업무들을 컨소시엄에 할당하고 수주를 위해 피나는 노력을 한다. 모두의 목표는 같다. "수주" 하여 "매출"을 만들자. 하지만 그 준비 과정에서 시간이 없어 검증되지 않은 컨소시엄도 있을 수 있고 역할들이 불분명하지만 인증서만 빌려주기 위해 모인 컨소도 있다. 이 상태에서 일을 하면 99프로 사달이 난다. 내가 진행했던 스마트 시티는 제안서를 작성할 때 서로의 롤에 대한 지분율을 협의한다. 하지만 협의일 뿐 PM사의 일방적인 통보 형태로 가고, 나머지 컨소들에게 어차피 수주하면 지분율 다 변한다고 다 어르고 달랜다. 실제로 수주를 하면 지분율은 달라질 수 있다. 하지만 그 과정이 절대 투명하지 않다. 수주전에 입찰 과정에서 나왔던 달램들 즉 구두약속은 헌신짝처럼 아무 소용이 없다. 결국 마지막까지 좋은 관계로 남는 경우가 굉장히 드물다. 이랬을 경우 다음 입찰에서는 또 새로운 컨소를 찾아야만 한다. 악순환의 반복이다. 

 오늘 이 Sales PM들이 한 번쯤은 겪었을 일들을 내 경험담으로 작성해 봤다. 왜냐면 이 경험들이 내가 창업을 결심하게 된 이유들이었기 때문이다. 최근 문제정의를 하며 솔루션을 만들어가는 과정에 있는데 조금 더 문제들을 딥다운할 필요가 있다고 느껴져서 브런치에 글을 쓰며 정리를 해봤다. 마지막으로 이 글을 보시는 분들에게 한 마디 하고 마치면..

저희 팀이 이 문제 해결해 볼게요.