프로젝트 성공률 30%, 고객이 원하는 것은 무엇일까?
2014.04.25 19:04
프로젝트 성공률 30%, 고객이 원하는 것은 무엇일까?
[출처] http://www.dbguide.net/knowledge.db?cmd=view&boardConfigUid=19&boardUid=178648
우리는 주변에서 시스템 통합, 차세대 시스템, 시스템 고도화 등의 여러 가지 이름으로 정보화 관련 많은 프로젝트를 접하고 수행하고 있다.
시스템 통합(SI : system integration)이란 단어를 찾아보면
① 시스템 구성 요소들을 순차적으로 결합하여 하나의 전체 시스템을 구축하는 과정.
② 정보 시스템을 기획부터 구축, 운용까지 필요한 업무를 일괄하여 제공하는 서비스라고 정의되어 있다. 정보 시스템을 이루는 구성 요소는 어떤 것이 있을까? 인력(People), 프로세스(Process), 기술(Technic), 방법론 및 도구 등이 있을 것이다. 많은 프로젝트들의 성공 및 실패, 그 원인들에 대해서도 다양한 의견들이 있다. IT 프로젝트의 30%정도 만이 성공을 한 것으로 알려져 있다. 
[Standish Group, Chaos Summary, 2010]
그런데 IT 프로젝트의 기술, 도구, 방법론 등이 발전하고 있음에도 불구하고 프로젝트의 성공률은 왜 낮을까? 그 원인은 무엇이고 원인들 중 일부분에 대한 해결책을 제시하고자 한다.
프로젝트의 성공이란 고객이 원하는 정보 시스템을 한정된 인력, 일정, 비용 내에서 고객이 원하는 데이터를 원하는 시점에 편리한 시스템을 통해 접근할 수 있는 것이라 할 수 있다. 그렇다면 ‘고객이 원하는 것’은 무엇일까? 사실 프로젝트를 수행하다 보면 고객은 자신이 무엇을 원하는지 알 수 없는 경우가 많다.
잠시 과거의 이야기를 한 번 해보면,1991년 미국을 포함한 연합군과 이라크의 전쟁이 시작되었다. 당시 미국은 육군, 해군, 공군이 동시에 투입되었으며 최첨단의 전자 무기가 투입되었다. 걸프전은 연합군의 승리로 끝이 났다. 이때 전쟁은 승리하였지만 큰 문제점이 발견되었다. 그것은 육해공군의 무기 체계가 달랐던 것이다. 전쟁 수행 중 적의 위치를 파악하고, 항공모함에서 미사일을 발사하고, 비행기에서 폭탄을 투하하고, 적의 피해 상황을 파악하고 공유하는데 상호간의 무기체계, 커뮤니케이션 방법이 상이하여 서로 공유할 수 없었던 것이다. 이 문제를 해결하기 위해 나온 방안이 기술 아키텍쳐 프레임워크인 TAFIM(Technical Architecture Framework for Information Management)이다. 즉, 상호 연동을 최적화하기 위한 것이다.
우리나라에서도 2000년대 중반부터 EA(Enterprise Architecture)를 공공기관 및 금융기관에서 도입하기 시작하였는데 우리나라는 상호간의 효율성을 높이기 위한 목적으로 EA를 도입하게 되었다. EA의 영역 중 한 부분이 DA(Data Architecture)이며 DA를 수행하는 목적이 효율성 및 상호 운용성을 높이고자 하는 것이다. 우리는 IT 프로젝트에서 어떻게 해야 상호 운용성과 효율성을 높일 수 있을까?
다시, 시스템 통합 또는 차세대로 돌아와 보자. 고객이 원하는 부분을 시스템에 적용하기 위해서는 ASIS 시스템의 현행화와 미래의 환경 변화에 유연하게 적용되고, 원하는 시점에 정확한 정보를 제공하는 적시성이 필요할 것이다. 차세대 시스템에서 고객이 원하는 요구 사항을 도출하기 위한 몇 가지 방안을 생각해 보았다.
1. 사용자인 본인도 요구 사항을 잘 모른다.
현업의 사용자는 업무의 프로세스에 대해서는 잘 알지만 프로세스 내에서의 데이터 관계를 잘 알지 못하는 경우가 있다. 전반적인 업무의 흐름은 이해하나, 데이터의 흐름도 같이 이해하지 못하는 경우가 있다. 이럴 때는 어떻게 해야 할까?‘데이터 모델링을 같이 수행’해야 한다고 생각한다. 현업의 사용자는 단순히 업무의 설명으로 끝나는 것이 아닌 데이터 모델을 같이 공유하면서 업무를 파악하는 것이 업무를 파악하는데 있어서 가장 효율적이라고 생각한다. 데이터 모델은 IT 기술이 아니라, 업무의 규칙을 표현하는 비즈니스 관점인 것이다. 또한, 프로젝트 산출물을 위한 문서화가 아닌 커뮤니케이션을 위한 문서 작성을 통해 업무 파악을 할 수 있다. 잘 만들어진 문서가 아닌 네모 박스, 동그라미, 텍스트 박스로만 이루어진 파워포인트 문서를 통해 현재 흐름, 목표 흐름, 문제점 등을 기록하여 커뮤니케이션을 하면 쉽게 원인을 파악하고 해결할 수 있다.
2. 고객을 만나기 전 데이터 프로파일링을 수행하자
프로젝트에 참여하게 되면 먼저 현행 시스템을 파악하게 되는데 어떻게 해야 짧은 기간 안에 효율적으로 현행 시스템을 파악할 수 있을까? 바로 ‘데이터 프로파일링’이 필요하다. 원래 데이터 프로파일링이란 데이터를 분석하고, 데이터의 품질을 진단하고, 비즈니스 룰(BR)등을 도출하는 것이다. 그러나 여기서의 데이터 프로파일링은 현행 시스템에 존재하는 모든 데이터에 대한 값, 패턴, 생성 주기를 파악하는 것이다. 값이란 시스템에서 관리되는 모든 컬럼들의 값을 기준으로 값의 종류, 값의 개수, 최소값, 최대값, 최소 길이, 최대 길이 등을 파악하는 것이다. 또한, 표준과 표준 편차를 통해 어느 부분에 값이 많이 있는지 파악한다. 패턴이란 컬럼에 존재하는 값이 패턴이다. 즉, 숫자로 이루어져 있는지, 숫자와 문자가 섞여 있는지, 한글이 포함되어 있는지, 영문 대소문자가 어떤 것에 분포되어 있는지 파악하는 것이다. 생성 주기는 데이터 생성의 분포도로 테이블의 값이 어떤 주기로 생성되는지를 프로파일링을 통해 구체적으로 생성한다.
프로파일링 데이터를 생성하여 고객과의 인터뷰에서 의미 파악이 모호하거나, 이해하지 못한 부분을 데이터의 값, 패턴 등을 보여주고 빠르게 업무를 파악할 수 있을 것이다. 또한, 데이터 프로파일링을 수행하면 테이블 내의 컬럼간의 의미뿐만 아니라 테이블과 테이블간의 관계, 업무와 업무간의 관계를 데이터 관점에서 도출, 업무 흐름을 파악할 수 있다.
3. 시스템 아키텍쳐를 이해하자.
프로젝트를 수행하면 많은 사람들이 모여서 수행하며 각자의 고유한 업무가 있다. 프로젝트 관리그룹, 분석그룹, 개발그룹, 아키텍쳐 그룹 및 다양한 이해 관계자가 있다. 아키텍쳐 그룹 중 시스템 아키텍쳐 그룹이 있는데 모델러, 개발자, 업무 설계자 중에 시스템 아키텍쳐의 구성을 이해하지 않고 프로젝트를 수행하는 경우가 있다. 이는 본인의 업무에 직접적인 역할과는 관계가 적어서 관심이 없으나, 전체 시스템 관점에서 모든 사람들이 시스템 아키텍쳐를 이해해야 한다고 생각한다. 고객이나 분석, 설계자와 업무 협의를 할 때 상당 부분이 이 시스템 아키텍쳐를 이해하지 못해 문제점을 파악하지 못할 때가 있다. 또한, 현업 TFT도 아키텍쳐를 이해하고 있어야 한다. 현업 TFT는 프로젝트가 종료되기 전에 없어지는 경우가 많은데 반드시 프로젝트가 종료되기 전까기 같이 프로젝트를 수행해야 할 것이다.
4. 정보 시스템을 분석하자.
업무를 파악하기 위해 가장 좋은 방법은 무엇일까? 해당 업무에 10,000시간을 투자하면 업무에 대한 전문가 될 수 있을 것이다. 10,000시간의 법칙이다. 커피의 전문가가 되려면 커피에 대해 10,000시간을 투자하면 전문가가 될 수 있다. 그런데 우리는 정보 시스템을 분석하는데 10,000시간을 투자할 수 없다. 그렇게 하려면 몇 년이 걸릴 것이다. 그렇다면 짧은 시간에 정보 시스템을 분석할 수 있을까? 위에서의 데이터 프로파일링을 이용하면서, ASIS 시스템의 화면, 테이블, SQL등을 같이 활용하는 것이다. ASIS 시스템을 보는 것만으로도 현행 시스템에 대. 어느 프로젝트에서는 보안이라는 이유로 ASIS 시스템을 보지 못하고 목표 시스템을 구축하는 것을 보았다. 현행 시스템을 분석하고 않고 목표 시스템을 구축한다는 것은 상상 속에서 상상을 하면서 시스템을 구축하는 것과 동일한데 프로젝트가 성공할 수 있을지 의문스럽다.
5. 자동화를 이용하라.
프로젝트를 수행하다 보면 비즈니스 도메인이 다르더라도 수행되는 업무가 비슷한 경우가 많다. 완전 자동화까지는 필요하지 않지만 단순, 반복적인 일은 반자동화를 통해 업무의 수행 시간을 줄여 주어야 한다. 엑셀을 이용하는 경우, VBA등을 이용하여 프로젝트 팀원들간에 반복적으로 수행되는 일은 자동화를 수행하면 업무의 효율성이 상당히 높아진다. 그러나 모든 것을 자동화 할 수 없으니 단순, 반복에 대해서 공통적으로 사용할 수 있는 부분에 대해서 자동화를 추천한다.
또한, 템플릿도 자동화에 포함된다. 템플릿은 업무의 노하우이다. 업무를 쉽게 파악하고 이해할 수 있는 템플릿을 이용하면 효과적이다. 데이터 모델에서의 DRM(Data Reference Model)도 템플릿이 될 수 있다. 업무 프로세스에서도 다양한 템플릿이 존재한다. 이를 지식화하면 프로젝트를 훨씬 안전하고 빠르게 진행할 수 있을 것이다. 정보화 프로젝트에서 DA(Data Architecture)에서의 논리 모델링은 프로젝트 성공의 가장 중요한 요소 중 하나이다. 프로젝트의 실패가 전체의 70%에 해당되는데 논리 모델링을 잘못하면 해당 프로젝트는 실패할 확률이 상당히 높아진다. 사용자의 요구 사항을 관리하는 프로세스가 있는 SWEBOK(SW Engineering Body of Knowledge)에 일부 표현되어있다. SWEBOK은 SW 공학에 대한 전반적인 지식 및 가이드 라인을 제공하고 있다. 우리는 고객의 요구 사항을 도출하여, 논리 모델에 반영하고, 향후 변화될 것에 효율적으로 대처 할 수 있도록 하여야 하는데 이러한 것을 성공적으로 이끌어 갈 수 있는 요구사항을 생성, 관리하는 것이다. 이러한 것을 수행하려면 반드시 템플릿과 같은 프로세스가 있어야 하며 다양한 경험과 지식들을 일반화한 것을 프로젝트에 적용해야 할 것이다.
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.
