brunch

You can make anything
by writing

C.S.Lewis

by 정재헌 May 29. 2020

PM 컨버팅 #27

#27 인프라 제안서의 핵심내용

#25 운영사업에 이어서 ITO사업 제안에 주의하여야 할 사항에 대하여 기술하겠습니다. 개인적으로 가장 운이 많이 작용하는 사업에 인프라 유지보수 사업입니다. 속된 말로 잘걸리면 어느정도의 회사이익과 다년간의 장기사업이 가능한 영역이지만 잘 못 수주하게 되면 회사에 큰 손해를 입힐 수 있는 사업영역이기도 합니다.




유지보수 지금은 유지관리란 용어를 사용한다.

SW사업대가산정 가이드에 따르면 유지관리사업은 크게SW유지관리와 상용SW 유지관리, 보안성 지속서비스 3가지 사업으로 분류가 된다.


각 사업의 업무정의는 다음과 같다,

1) SW유지관리

소프트웨어 유지관리는 사용자에게 인도된 소프트웨어에 대하여 오류를 수정하고, 환경 및 사용자 요구사항 변화에 따라 소프트웨어 성능 및 사용성 향상을 위하여 소프트웨어를 수정하는 활동을 말한다.


2) 상용SW 유지관리

상용소프트웨어 유지관리란 구매한 소프트웨어를 최적의 상태에서 활용·유지하기 위해 제공되는 제품지원, 기술지원, 사용자지원 등의 서비스를 말한다.


3) 보안성 지속서비스

정보보호제품을 활용하여 정보의 훼손, 변조, 유출 등을 방지하기 위해 지속적으로 요구되는 기술 기반의 서비스를 의미한다.


그리고 인프라 유지관리가 있다.



단순하게 SW만 유지관리하는 사업 여기서 SW란 일반적인 SW가 아니라 SI 개발사업을 통하여 만들어진 서비스 또는 시스템으로 보는게 타당할 것이다. 수행하는업무는 워낙 다양해서 일단 제안서 작성관점과 원가 또는 비용관점에서 유의할 점 위주로 정리하면 다음과 같다. 통상적으로 상기에 구분된 사업이 각각 분리되어 발주되기 보다는 통합적으로 발주되는 경우가 많고 사업의 특성상 다년사업으로 나오는 경우가 많다.


하드웨어 유지관리사업의 제안을 하기 위하여서는 가장 먼저 "인프라 내역"의 확인과 "인프라 구성도"가 있어야 한다. 대부분 발주기관에서는 제품도입 리스트와 도입년도 그리고 도입비용 등의 자료를 가지고 있지만 일반적으로 제안사에 공개하지 않고 수주후에 대부분 제공을 하는 경우가 많다.


충실한 제안서 작성을 위하여서는 위의 2가지 관련 내용이 기술되어져야 하며, 구성도의 경우에는 내부 엔지니어들이 별도로 분석을 하여서라도 구성도를 그려 넣어야 한다.


최근에 어느정도 규모를 갖추고 있는 기관들에서는 ITSM을 통하여 인프라를 관리하고 있어, 기본적인 ITSM 또는 ITIL v3.0이 무엇이고 어떻게 적용되는지에 대하여 인지를 하고 있어야 한다.




첫번째로 운영은 일단 본 장에서 내용 언급을 안하고 유지보수 관점만 기술하면, 인프라 유지보수에서 가장 중요한 부분은 "일점검", "주점검", "월점검", "분기점검"의 현실적인 적용장비와 점검범위일 것이다.

각 장비별로 점검범위 체크리스트가 있고, 만약 제안서에 일점검이라고 표기하면 실제 그 장비의 일 점검을 해야 한다. 현실적으로 이 부분에 대하여 정말 고민을 많이하여 제안서를 작성하여야 한다.


두번째로 장애에 대한 대응이다. 우선 예비부품을 현실적으로 확보하여야 하며, 두번째 발주기간이 명기한 시간의 범위내에 인력이 투입되어야 한다. 제안서를 작성할 때 이 부분은 정말 현실적으로 실행가능한 범위내에서 작성을 하여야 한다.


세번째로 벤더 또는 제조사에 주어야 하는 기술지원비의 정확한 파악이다. 일반적으로 공고에 기술지원 확약서를 첨부하면 문제가 안되지만 그러지 않을 경우에는 제안서 작성시기에 각 업체들을 컨텍하여 직접 견적을 받고 기술지원확약을 받는 일을 필수적으로 하여야 한다. 물론 많은 경우 수십개의 업체가 될 수 있다. 그러나 내부 원가검토 시 필히 이 부분을 확인하여야 하고, 이 비용이 프로젝트 전체 손익에 큰 영향을 미치게 된다.


네번째로 서비스수준협약(SLA)를 사전에 확보하여 검토해봐야 한다. 인프라 유지보수는 일반적으로 SLA를 통하여 관리 감독되어지고 있고, 월별 제출하는 SLA에 낮은 점수를 받을 경우 심한 경우 계약이 파기될 수도 있다. 제안서를 작성할 때 SLA를 분석하고 검토하여 SLA 범위 안에서 제안내용을 기술하여야 한다. 예를 들면 이런 거다. SLA에 장애가 날 경우 4시간 안에 엔지니어가 와야하고 24시간안에 조치가 되어야 하는데 제안서에 12시간안에 모든 장애처리를 하겠다고 하면 SLA가 12시간으로 변경이 될 수 도 있다.




가장 어렵고 전문적인 영역이 아마도 인프라 유지보수 제안서일 것이다, 그리고 경쟁평가를 할 때 얼마나 전문적으로 발주기관의 인프라를 잘 분석하여 작성했냐에 제안의 성패가 갈린다. 나머지는 경쟁평가에서 변별력을 확보할만한 부분과 내용이 거의 없다.  발표도 마찮가지다.


제안서를 작성하고 참여를 준비하는 입장에서 참 어렵고 난감하고 예측이 어려운 제안이 인프라 유지보수 제안이다.



지금 읽으신 글은 책으로 출판되어 있습니다.

내일부터 Project Manager가 되어야 한다.

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&linkClass=130509&barcode=9791165457037

http://www.yes24.com/Product/Goods/108921595

매거진의 이전글 PM 컨버팅 #9
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari