본문으로 바로가기

전에 기술지원조직의 업무관리에 필요한 간단한 프로젝트 및 일정관리 시스템 개발에 대한 포스트를 기록한 적이 있다. 그리고 시간은 흐르고 흘러 6년이 되어 간다. 지금도 그 시스템은 우리 부서 30여명의 엔지니어들이 잘 사용하고 있다. 비록 많은 버그와 부족한 점이 있지만 기본적인 프로젝트관리와 일정(캘린더)이 확실하게 연결되어 있어 기본기능만큼은 충실하기 때문이다. 그리고 영업부서로부터 엄청나게 밀려오는 신규사업과 유지보수사업 그리고 영업지원에 대한 요구로 인해 사용하지 않고는 못배길 만큼 엔지니어들이 관리해야 하는 프로젝트와 기술지원 일정이 넘쳐나기 때문이기도 하다.

* IT 솔루션 기업의 핵심 부서

내가 지금 근무하는 기업은 IT솔루션, 그중에서도 SW 개발 기업이다. 그리고 SW 중에서도 시스템SW이자 보안SW다. 그리고 SI 사업으로 고객의 요구에 맞춰 그때 그때 수정하여 제공하는 SW가 아닌 패키지 SW다. 즉 한번 만들어서 지속적으로 판매/설치/컨설팅/유지보수가 반복되는 상용SW다. 그리고 계속적인 버전 업그레이드와 재설치, 보안정책 수립에 대한 기술지원과 컨설팅이 이루어진다.

이러한 솔루션 기업(하드웨어도 포함)은 기업내의 여러 조직 중 세개의 조직이 핵심조직이다. 바로 영업-개발-기술지원/컨설팅 부서다.

영업조직은 IT솔루션 기업에서 가장 중요한 조직이다. 제품이 아무리 뛰어나도 영업력 부재라면 그 기업은 십중팔구 사라진다. 존재의 여부마저도 아무도 모르게 망해 없어지는 경우가 허다하다. 반면 제품의 수준은 형편없어도 오랜시간 생명을 유지하며 자신의 존재를 뽐내는 참 대단한 기업도 다수 존재하는데 이런 기업들은 확실한 인맥을 가진 영업맨이 한두명은 있게 마련이다. 제품의 기술력이 우수하고 시장에서 인정받아 수요가 꾸준한 제품이라면 직접영업보다는 간접영업을 하는 것이 보다 효율적이다. 이런 경우에는 직접영업조직과 인바운드영업을 담당하는 조직을 별도로 가져가는 것이 효과적이다. 그리고 매출규모가 더 커진다면 마케팅부서를 별도로 두거나 영업조직의 하위에 두는 것도 효과적일 수 있다.

개발조직은 SW개발자 집단이다. 제품의 품질을 좌우하는 무척 중요한 조직이다. 어느정도 영업이 이루어져 제품의 판매가 이루어지기 시작하면 개발조직과 영업조직간의 여러가지 갈등이 발생하기 시작하는데 이 싸움이 어떻게 진행되느냐에 따라 기업이 흥하느냐 망하느냐가 결정되기도 한다. 어느정도의 균형은 이루어야 하겠지만 일반적으로 개발조직의 제품개발 방향은 영업조직과 기술지원/컨설팅 조직의 요구에 맞추어가는 것이 바람직하다. 고객과의 접점에서 고객의 요구사항을 직접적으로 전달받는 즉, 시장의 요구사항을 피부로 체험하는 조직의 요구에 제품 개발 방향을 맞추지 않고 나름 개발자들의 "환상"에 방향을 맞춘다면 제품은 시장에서 점점 외면받게 되며 결국 도태될 가능성이 매우 높아진다.

기술지원/컨설팅조직은 우리나라에서는 그 중요성을 제대로 인정받지 못하는 조직이다. 우리나라의 IT솔루션 기업에서 기술지원을 담당하는 엔지니어들은 대부분 일정기간이 지나면 영업조직으로 옮기거나 조금 규모가 있는 SI기업으로 이직하는 경우가 많다. 그만큼 IT솔루션 기업에서 엔지니어를 우대해주지는 않는다. 때문에 훌륭한 솔루션을 개발하고 팔아 놓고도 제대로 기술지원을 하지 않아 나쁜 평가를 받게 되고 결국엔 그저그런 솔루션으로 시장에서 근근히 살아남아 겨우 명맥만 유지하는 경우가 너무도 많다. 그 이유가 바로 "엔지니어의 기술 수준이 형편없이 낮고 경험이 부족"하기 때문인데 기술자를 천대시하는 역사적 전통(?)이 현시대를 살아가는 사람들에게 영향을 주기 때문인 것으로 보인다.

나머지 조직은 영업-개발-기술지원 부서를 서포트(Support)해주는 역할을 수행해야 한다. 이 대목에서 많은 다른 조직의 직원들이 기분나빠할 수도 있다. 하지만 그럴 필요는 없다. 기업내에서 불필요한 조직(?)은 없다. 다만 이 세개의 조직은 기업의 근본적 가치인 "돈"을 버는데 필요한 업무를 수행한다는 의미에서 핵심부서라는 이야기이기 때문이다. 군대로 치자면 "전투병과" 라는 이야기다.

프로젝트관리


* 영업-개발-기술지원/컨설팅 부문을 아우르는 프로젝트 관리 방향 (CMMI)

보통 PMS(프로젝트관리시스템)를 개발할 때 보통은 사업수행의 관점에서만 생각하는 경우가 많다. 프로젝트를 수주한 이후 프로젝트가 시작되는 시점부터의 업무만을 프로젝트관리시스템의 관리 대상으로 보는 것이다. 하지만 프로젝트는 영업조직에서 고객사의 사업 준비를 포착하는 단계에서부터 이미 시작된다고 봐야한다. 그렇지 않고 사업을 수주한 시점을 프로젝트의 시작으로 보게되면 영업단계에서 소요되는 시간과 인건비를 고정비로 보게 되고 사업 수주를 위해 지출한 상당한 비용의 접대비와 인건비가 원가에 제대로 반영되지 않아 사업의 수익성이 왜곡되는 결과를 초래하게 된다.

또한 비록 패키지성 솔루션을 만드는 개발조직이라 할 지라도 특정 사업의 필요에 의해 특정 기능이나 모듈을 개발하는데 투자하는 인건비는 제품의 개발원가가 아닌 사업수행의 원가에 포함시켜야 하는데 영업단계의 비용과 마찬가지로 자칫 개발부서의 인건비를 고정비로 보게되면 프로젝트의 수익성이 왜곡되어 적자성 사업이 흑자 사업으로 둔갑하는 결과를 초래하게 된다. 

기술지원/컨설팅 조직 또한 마찬가지다. 한명의 엔지니어나 컨설턴트가 동시에 한개의 사업만을 수행한다면 인건비 산정과 프로젝트에 원가 반영이 쉽겠지만 한명의 엔지니어가 두개 이상의 사업을 수행하게 되면 어느 사업에 얼마만큼의 인건비가 소요되었는지를 제대로 반영하기는 사실상 어렵다. 

만약 프로젝트의 시작을 영업 초기단계로 설정하고 제품의 신규기능 및 수정될 기능에 대한 개발 과정을 프로젝트의 업무단위로 보며 개발자와 엔지니어/컨설턴트의 개발일정, 지원일정을 프로젝트의 수행과정으로 본다면 영업-개발-기술지원/컨설팅의 단계로 이어지는 하나의 프로젝트가 완성되며 제대로된 투입인력 산정(M/M)과 소요비용의 산출이 가능해진다.

또한 프로젝트별 인력투입현황과 현재 조직의 업무 포화도, 직원 개인간 업무 수행 시간의 비교와 업무 유형별 투입시간의 파악이 가능해지기 때문에 인력 부족 여부는 물론 앞으로의 인력 채용 계획을 수립하는데도 무척 효과적일 수 있다.

이렇게  IT분야의 개발단계를 명시하고 업무 프로세스의 관리 능력을 평가하는 평가모델이 바로 CMMI 다. 사실 서양 아이들(?)이 잘하는 것이 다양한 경험을 바탕으로 각 분야의 지식을 종합/정리하고 새로운 이름을 붙이는 짓(?)이다. ISO 모델이 그렇고 BS7799 등이 그렇다. 대부분 이미 수행하고 있는 세부 단계들을 하나로 엮어 체계화한 것이 이런 표준 모델이다.

정작 새로운 이름으로 표준을 정립한 서양 아이들은 조용한데 이러한 모델들이 우리나라에 도입될 때 마치 전혀 새로운 것인양 호들갑을 떨며 대단한 새로운 개념인것처럼 그리고 그것을 자신이 먼저 알고있다는 근자감에 사로잡혀 잘난체하는 일부 사람들을 보면 씁쓸할 따름이다.

연관포스트 : 프로젝트 및 일정관리 시스템 리뉴얼


신고

댓글을 달아 주세요