30. IT업체의 프로젝트 준비
IT업체의 프로젝트 준비와 수주과정
SI에 대한 온전한 이해
앞 글에서 시스템 개선 및 구축을 하려는 업무 담당자 관점에서 프로젝트를 만드는 과정을 알아보았다. 이번에는 여러분이 IT업계에 몸담는다면, 당사자가 될 IT업체 관점에서 프로젝트를 준비해서 프로젝트를 수주하는 과정에 대해 살펴보자.
개발 프로젝트를 수행하는 업체를 보통 SI업체라 부른다. SI라는 말은 시스템 통합(System Integration)의 영어 약자이다. 또 SI라면 개발 프로젝트에 투입되는 외부 개발자라는 것도 알고 있다.
그러나 엄밀한 의미에서 SI는 IT의 다양한 구성이 결합된 시스템 구축을 의미한다. 단순히 개발자 몇 명이서 프로그램을 개발하는 것도 개발 프로젝트일 수는 있지만, 엄밀한 의미에서 SI는 아니다. 여러 IT요소가 결하되어 하나의 시스템을 만드는 것이 SI다.
전형적인 SI프로젝트는 다양한 소프트웨어가 결합되어 개발자가 개발하고, 또 서비스에 필요한 사양의 하드웨어가 구성되는 사업이라 할 수 있다. 따라서 프로젝트에는 다양한 IT업체의 참여와 상호 간의 협력이 필요하다.
전형적인 SI사의 관점에서 인터넷 뱅킹 재구축과 같은 대형 사업을 예시로 해서 프로젝트를 준비하는 과정을 살펴보자.
사전 준비
은행 담당자는 인터넷 뱅킹 재구축과 같은 사업을 추진하기 위해 예산을 확보해야 한다. 예산 수립을 위해 관련 IT업체로 부터 예산 견적을 받아 예산 수립에 활용한다. 이런 과정에서 IT업체는 은행이 인터넷 뱅킹 재구축 사업 계획을 알게 된다. 굳이 이러한 과정이 아니더라도 은행 관련 IT업체는 영업 조직을 통해 고객사의 IT사업 추진 계획을 알고 적절하게 대응함으로써 은행과 같은 고객사와 밀접한 관계를 유지한다.
여기서 잠깐 IT업체의 조직과 역할에 대해 말씀드리고자 한다. 회사마다 다르겠지만, 일반적으로 SI사업을 수행하는 IT업체는 크게 영업조직과 개발조직(대기업은 컨설팅 조직이라고도 한다.)으로 구분된다. 영업조직은 대 고객 영업을 하는 조직이다.(대기업 고객을 담당하는 IT업체의 담당 영업 직원이 있다. 이러한 고객을 어카운트(Account)라 한다.)
따라서 대고객 접촉(어카운트 관리), 사업수주, 계약과 같은 주체는 영업조직이 한다. 개발조직은 컨설턴트나 개발자로 구성되어 있고 실제로 프로젝트를 수행하는 조직이다. 그래서 개발조직을 딜리버리(Delivery) 조직이라 하고 프로젝트를 수행하는 것을 'Delivery 한다'라고 말한다.
간략하게 말하면, 영업이 앞장서서 프로젝트를 물고 오면, 개발조직이 프로젝트를 수행한다라고 이해하면 된다. 그러나 영업조직은 프로젝트 영업 단계에서 부터 실질적인 기술을 보유하고 있는 개발조직의 협력을 받지 않을 수 없다. 따라서 상호 협력이 잘 되어야 좋은 결과를 낳을 수 있다는 것은 자명한 사실이다.
제안
｜제안 조직 만들기｜
고객사가 RFP를 발송하면, 본격적인 제안 작업에 들어간다. 인터넷 뱅킹과 같은 대형 사업인 경우, 영업담당자는 사전에 딜리버리 조직의 개발자나 컨설턴트를 이미 배정받아 고객과 지속적인 접촉을 하고 있는 경우가 많다. 공식적인 RFP가 나오면 제안을 위한 본격적인 제안 조직이 만들어진다.
제안조직은 제안 내용에 전문성이 있는 개발 조직의 인력으로 구성되며(현실은 프로젝트 안 들어가고 남은 인력이 하는 경우가 많다.), 가장 중요한 담당자는 제안 PM이다. 제안 PM은 제안만을 위한 경우도 있지만, 제안 이후 프로젝트가 수주되면 프로젝트 PM 역할을 하는 것이 일반적이다.
구성된 프로젝트 팀은 제안기간 중 제안 PM의 리더에 따라 제안작업을 한다. 보통 제안서 작성기간은 최소 1주일 이상이다. 프로젝트가 크면 더 길어지기도 하지만 고객사는 그렇게 넉넉한 제안 기간을 주지도 않는다. 어떤 고객사는 사업추진이 급하다며 제안 기간을 연휴가 끼는 날을 포함해서 1주일을 주는 경우도 있는데 이를 경우 제안팀의 불평은......(상상하시길)
｜협력업체 구성｜
제안과정은 프로젝트를 설계하는 과정이기도 하고, 또 프로젝트를 수행할 조직을 만드는 과정이다. SI라는 말을 다시 한번 상기해 보면, 시스템을 만들기 위해 많은 IT요소가 통합이 되어야 한다는 뜻이다. 따라서 SI업체의 제안은 단독으로 할 수 없고 많은 협력사와 같이 진행된다. SI업체는 혼자서 프로젝트를 못하기 때문에 같이 제안을 할 협력업체를 찾아야 한다.
RFP제안의 내용은 대개 업무 개발, 소프트웨어, 하드웨어 및 기타 부분으로 구성된다.
업무 개발 - 인터넷 뱅킹 개발 같은 경우는 업무 개발 범위를 말한다. 예를 들면, 수신, 여신, 외환 등이 여기에 해당된다.
소프트웨어 - 인터넷 뱅킹 구축을 위한 필요한 소프트웨어를 말한다. OS, DBMS와 같은 시스템 소프트웨어뿐만 아니라, 설루션, 보안 소프트웨어에 이르기까지 RFP 요구와 시스템 구축에 필요한 모든 소프트웨어가 검토되어야 한다.
하드웨어 - 인터넷 뱅킹 구축에 필요한 하드웨어 서버, 저장 장치, 네트워크 장비 등의 검토가 필요하다. 은행의 고객수, 접속자 수와 같은 자료를 바탕으로 서비스가 문제가 없도록 시스템 용량을 계산하여야 한다.
SI사는 제안기간 중에 각 부분별 수행이 가능한 협력사를 찾아서 협력관계를 맺고 각 협력사가 맡은 부분을 책임지고 제안을 할 수 있도록 하여야 한다. (SI사의 역할 중 가장 중요한 역할은 일을 쪼개고 할 수 없는 업체를 찾아서 맡기는 것이다. 빠지는 영역이 있거나 중복되는 부분이 없도록 관리하는 것이 중요하다.)
｜제안서 제출｜
SI사가 직접 작성한 부분과 협력사가 작성한 부분을 모두 합쳐 제안서를 완성한다. 협력사는 제안서를 SI사에 제출하면서 견적도 같이 제시한다. SI사의 영업과 제안 PM은 제안사에서 받은 견적과 합쳐 전체 견적을 구성한다.
고객사의 제안 평가는 제안 내용과 가격으로 구성되기 때문에 제안 가격은 매우 중요한 평가 요소이다. 협력사의 견적으로 전체 제안 가격을 구성하게 되는데 제안 가격이 너무 높으면 평가에 불리하므로 협력사와 견적 협상이 필요한 경우가 많다.
제안서의 내용은 법적인 효력이 있어, 제안내용에 신중을 기해야 한다. 구현이 불가능한 것을 제안한다던지, 또 시스템 구성에 필요한 부분이 누락되어 시스템이 제대로 돌아가지 못할 경우 그것에 대한 책임져야 한다. 제안 내용 하나하나를 꼼꼼히 검토하여야 한다.
전체적인 시스템 구성을 제대로 파악할 수 있는(업무적인 측면, 소프트웨어적인 측면, 하드웨어적인 측면, 또 이를 전체적으로 아우르는 통합적인 관점에서) SI사 내부의 전문가가 필요하다.(혹자는 프로젝트에서 SI사 인력 비중이 적은 경우, SI사가 하는 일은 별로 없고 대부분의 일을 협력사가 다한다라고 하는데, 이는 일부는 맞고 일부는 맞지 않다.)
제안이 완료되면, 제안서 제출 기한에 맞추어 제출한다. 제안서 제출이 완료되면, 고객사는 제안 발표일을 통보한다. 제안발표는 순서는 대부분 제안서 제출 순서와 반대로 한다. 제안발표 일을 통보받으면, SI사는 제안서를 기반으로 해서 제안 발표 PPT를 작성한다. 제안서가 내용 중심이라면, 제안 발표 PPT는 좀 더 발표에 적합하게 재구성한다.
제안발표는 제안 당락에 중요한 요소기 때문에 제안발표 준비에 만전을 기해야 한다. 제안 발표 당사자는 제안 내용을 잘 숙지하고 있어야 하며, 본인이 모르는 부분에 대해서는 협력사 담당자가 참석하도록 하여 고객의 질문에 답을 할 수 있도록 해야 한다. 사전에 질문지를 작성하고 협력사에게도 답변을 준비하도록 하여야 한다.
제안발표는 제안 PM이 하는 것이 보통인데, 고객사에서 프로젝트 PM이 제안발표를 하여야 한다는 요건이 있는 경우가 많아 이를 고려하여야 한다. 제안 당일은 프로젝트 규가 크면 SI사의 고위직(?) 임원과 협력사의 대표가 참여하여 프로젝트에 SI사가 많은 관심을 가지고 있다는 것을 고객에게 표명하기도 한다.
제안발표가 끝나고 나고 큰 변수가 없으면 1~2일 후 우선협상자 선정이 제안사로 통보된다. 본격적인 프로젝트 수행을 준비해야 할 시기이다.
계약
우선협상자 선정 이후 고객사와 SI사는 제안서를 기준으로 기술검토를 한다. 프로젝트에서 빠진 부분은 없는지 또는 제안사가 제안한 것이 적절한지를 꼼꼼히 검토한다. 이를 기반으로 견적을 다시 정리해서 가격협상을 한다.
가격 협상이 길어지면 프로젝트 추진 시기가 늦어져 문제가 되는 경우가 많다. 이런 경우 선투입하는 경우가 많는데, 최근 불공정거래로 문제가 되어 계약 이후 프로젝트 착수를 하는 것이 정착되고 있다.
고객사와의 계약이 끝나면, SI영업은 차례로 협력사와의 계약을 체결한다. 이러한 과정을 프로젝트 PM은 다 파악하고 있어야 한다. 고객과의 계약으로부터 수주한 금액과 협력사로 나가야 하는 금액을 파악하고 있어야 한다. 프로젝트 대금은 보통 프로젝트 착수 시 30%, 중간보고 30%, 완료 40% 비율로 결제된다. 영업과 별개로 프로젝트 PM은 전체 내용을 다 파악해야 대금의 수수와 지급을 결정할 수 있다.
프로젝트 착수
계약이 완료되면 프로젝트 인력들이 고객사 프로젝트 사이트로 투입이 된다. 프로젝트 투입 이전에 PM은 프로젝트 장소 및 프로젝트에 필요한 집기, 물품을 갖추어야 한다. 프로젝트 실, 집기 등을 고객사가 제공하는 경우가 일반적이나, 장소가 부족할 경우 사무 공간을 별도로 임대하여야 하는 경우도 있다.
(이런 경우는 사무실 임대 비용이 프로젝트 비용에 포함되어 있다.)
사전 계획된 프로젝트 일정에 따라 프로젝트가 진행된다. 고객사의 사정에 따라 프로젝트 Kick Off를 위해 프로젝트 착수보고회를 하는 경우가 많다.
체계적이고 보완된 내용으로 브런치 글과 같은 이름으로 출간을 하게되었습니다. 아래의 링크를 통해 자세한 내용을 확인할 수 있습니다.
교보문고
나에게 맞는 IT 직업 찾기
예스24
나에게 맞는 IT 직업 찾기
알라딘
나에게 맞는 IT 직업 찾기
똑같은 바둑 기보가 없듯 똑같은 IT프로젝트도 없다. 모든 프로젝트는 제각각의 범위와 요구사항을 가지고 있다. 단순하고 작은 프로젝트는 크게 문제가 되지 않지만, 은행이나 통신사의 차세대와 같은 1년 이상이 걸리는 프로젝트는 너무 규모도 크고 복잡해서 처음부터 가늠이 안 되는 경우가 많다. 따라서 경험이 많은 컨설턴트나 개발자의 역량이 필요하다.
프로젝트와 프로젝트의 시작에 대해 알아보았다. 이러한 과정에서 개발자, DA, DBA는 어디에 있는지 파악이 되는지? 아직 눈에 보이지 않을 것이다. 그러나 개발자도 프로젝트가 만들어지는 과정을 알아야, 내 일이 어떻게 만들어져서 내 앞에 떨어지는지를 알 수 있다. 최소한 이 정도는 알고 일을 해야 하지 않을까?
