2004년 컴퓨터 월드 기고 현 BEA 류윤상 팀장의 글

엔터프라이즈 포탈이란 무엇인가


개념 생성에서 현재까지 발전과정, 최신 EP 트렌드 분석


/재/목/차

1회 : 엔터프라이즈 포탈의 개념(이번호)

2회 : EP의 컴포넌트 및 연관 솔루션(5월호)

3회 : EP의 Critical Success Factors(6월호)

4회 : 글로벌 사례 및 경험 소개(7월호)

류윤상 한국Plumtree수석 컨설턴트


강좌 │ Critical Success Factors (3회)


---------------------------------------------------------------------------

3 EP Critical Success Factors – EP 프로젝트 기획, 이런 것들에 유의해야 한다.

 

4월호에서 살펴보았던 엔터프라이즈 포탈의 개념 설명으로부터 시작하여 5월호의 주제였던 다른 다양한 기업용 소프트웨어와의 보완성 및 차이점의 설명을 통해 이제 어느 정도는 엔터프라이즈 포탈이 어떠한 목적 및 가치를 가져다 주는 것인지에 대하여 조금은 이해가 되었을 것으로 생각한다.  물론 엔터프라이즈 포탈을 취급하는 벤더들마다 약간의 전략적 혹은 기술적 차이는 존재하지만 상당히 일반화하여 설명을 해왔기 때문에 그 사상을 이해하는 데는 부족함이 없으리라 생각한다.

 

이번 호에서는 조금 더 현실적으로 접근하여 엔터프라이즈 포탈을 실재 기획/도입하려 할 때 유의해야 할 사항들에 대한 제언을 하려고 한다.  이러한 제언들은 그 동안 EP프로젝트에 참여하는 동안 직접 경험했던 것들이나 다른 사람들에 의해 구축되고 운영되고 있는 다양한 포탈 프로젝트 들을 보아오면서 느꼈던 것 들을 정리하여 독자들에게 제공함으로써 다른 기업들이 그 동안 겪어왔던 실수를 반복하지 않도록 돕기 위함이 그 목적이라 하겠다.

 

제언 1. 엔터프라이즈 포탈은 프로젝트의 기획이 핵심이며 이 기획과정에는 현업(Business User)이 주도적으로 참여해야만 한다.

 

흔히 엔터프라이즈 포탈의 도입을 검토할 때 기업의 담당자 들은 컨설팅 회사나 SI 업체가 대부분의 일을 해줄 것이라고 믿고 있는 듯하다.  이 때문에 기업의 프로젝트 담당자 들은 EP 도입 초기에 어떤 컨설팅 회사에 컨설팅을 맡길 것인가, 어떤 SI 업체에 그 구현을 맡길 것인가, 또는 어떤 EP제품을 도입할 것인가에 자신들의 대부분의 시간을 소요하고 있는 것으로 보인다.

 

물론 이들의 도움이 전혀 필요가 없는 것은 아니지만, 그 핵심업무는 기업의 담당자들이 담당해야 한다.  외부업체가 해주는 일을 단순히 점검하는 것이 아니라 실제 주도적으로 그들을 리드해 나갈 수 있어야 한다.  컨설팅 회사나 SI회사는 그 기업이 자신들의 시간을 산 만큼의 서비스 만을 기업에 제공해 주며, 이는 대체로 그들이 수행하는 하나의 특정한 프로젝트에 한정되는 경우가 많다.  하지만 이제 여러분은 EP가 무엇인지 알고 있다.  EP의 구축은 단발성의 어플리케이션 구축 프로젝트가 아니라 앞으로 그 기반을 토대로 수많은 비즈니스 어플리케이션을 구현하게 될 기업의 기반구조를 재구성하는 것이다.  그 기반을 가지고 앞으로 어떠한 비즈니스 어플리케이션을 기획하는 가가 전체적인 EP의 성패로 볼 때 가장 중요한 요인이며 이는 분명히 내부직원들로부터 도출되어야 하는 것들이다.  이러한 지속적인 기획은 제3의 외부업체가 수행해주기에는 현실적으로 많은 어려움이 있기 때문이며, 한가지 더 덧붙이면 내부 조직 중에서도 IS조직 보다는 Business 조직에 의해 이러한 기획이 주도되는 편이 훨씬 더 바람직하다 하겠다.

 

Pratt & Whitney라는 항공기 엔진 제조회사를 예로 들어보자.  이 회사는 현재 임직원, 고객, 파트너를 포함한 그들의 모든 업무분야에 걸쳐 포탈을 운영 중이며 가장 포탈을 잘 구축한 기업으로 관련 Award도 여러 번 받은 기업이다.  이 대규모 포탈을 운영중인 포탈 팀의 정규 인원이 총 10명 정도인데 이중 70% Business Analyst이고 그 나머지가 IS Technologist라고 하니 성공적인 포탈을 지속적으로 운영해 나가는 데 있어 Business User 참여의 중요성은 이루 말할 수 없는 것이라 하겠다.  그도 그럴 것이 비즈니스 어플리케이션은 현업이 비즈니스를 잘 하는 데 필요한 하나의 도구가 아닌가?  이러한 도구를 만드는 데 있어 실제 사용할 사람이 그 기획에 참여하지 않는다면 이치에 맞지 않는 말이 아닐까?

 

<Business User 중심의 기획을 통해 비즈니스 어플리케이션을 포탈을 통해 지속적으로 공급하고 있는 Pratt & Whitney사의 항공사 고객 대상 Fleet Management & Benchmark 어플리케이션>

 

물론 이러한 포탈 팀은 지속적으로 기획과 구현과정을 주도해나가는 조직이 되어야 하기 때문에 단발성의 프로젝트를 위한 TFT가 아닌 영구적으로 지속될 수 있는 팀으로 구성되어야 하는 것이 바람 직 하다 하겠다.

 

제언 2. 조직 내에 비전을 확립하고 공유하라.

 

위의 제언과 같이 비즈니스 유저들을 위주로 구성된 영구적인 팀을 출범하였다고 하자.  이제 이 팀이 제일 먼저 수행해야 하는 일은 엔터프라이즈 포탈의 비전을 확립하고 이를 전사적으로 공유하는 것이다.

 

포탈을 도입하는 것이 앞으로 전사적으로 공유할 하나의 통일된 기반 프레임워크를 구현하는 것임을 명시하고 이를 경영진의 강력한 스폰서쉽을 바탕으로 전사에 공표 하여야 한다.  앞으로 이 공용 프레임워크를 통해 각 부서들이 어떠한 효과를 얻을 수 있는지, 또 이 프레임워크를 사용하기 위해서는 어떠한 과정을 거쳐야 하는 지 등을 체계적으로 정리하여 교육하여야 한다.  또한 다음 제언으로 이야기 하겠지만, Governance 체계를 초기에 확립하여 이러한 프레임워크를 전사적으로 공유할 때에 생길 수 있는 혼란을 최소화할 수 있도록 관리해 나가야 한다.  요점은 현재 중앙 포탈 팀에서 하고 있는 일을 지속적으로 홍보하고 교육하여 타 부서의 담당자 들이 이 중앙에서 투자된 자원을 지속적으로 재활용할 수 있도록 하는 것이다.  적어도 각 BU (Business Unit)에서 새로운 비즈니스 어플리케이션이 필요할 때 중앙 포탈 팀과 이를 먼저 협의를 해야 한다는 것을 누구나 알 수 있도록 교육이 된다면 이 포탈 프레임워크는 좀더 체계적이고도 실용적으로 관리될 수 있을 것이다.

 

엔터프라이즈 포탈을 도입하고 지속적인 ROI를 내고 있는 선진기업들의 예를 보면 얼마나 이러한 홍보 및 비전 공유에 노력을 기울이고 있는 지를 알 수 있다.

 

이러한 홍보의 도구로서 물론 공문이나 게시판 등의 일반적인 방법을 사용하기도 하지만 많은 경우는 포스터를 제작하여 주요 장소에 붙인다던가, 화면보호기를 제작하여 직원들의 PC에 배포한다던가, 게임이나 콘테스트를 사용하는 방법, 설문조사를 하는 방법 등 많은 다양한 방법들을 이용하고 있다.

 

<교사와 교장, 학생, 학부형 등이 이용하는 포탈을 운영중인 Ministry of National Education, Luxembourg mySchool! 포탈의 홍보를 위해 제작한 온라인 퀴즈>

 

제언 3. 복수개의 포탈은 실패의 지름길이다.  Governance 전략을 수립하라.

 

포탈 도입 초기에 홍보 및 비전 공유와 함께 꼭 수행해야 하는 것이 Governance 전략 수립이다.  Governance 전략이란 타 부서에 의한 불필요한 중복 투자의 가능성을 최소화할 뿐 아니라, 공유된 자원을 활용함에 있어 어떠한 절차 및 체계를 거쳐야 하는 지를 명시적으로 도출하고 이를 하나의 확립된 정책으로서 운영해 나가는 것을 말한다.

 

이러한 정책 없이 포탈을 운영하다 보면 다른 부서에서 현재 포탈에 구현되어 재사용할 수 있는 것을 또 독자적으로 구현하고 있는 경우를 발견하게 될 때가 있다.  이러한 중복된 투자의 원인은 여러 가지가 있을 수 있지만 홍보가 부족했거나 이러한 투자를 승인하는 정책의 부재가 가장 큰 원인일 경우가 대부분이다.

 

홍보와 더불어 이러한 정책은 엔터프라이즈 포탈 구축 전에 이미 정의되어 있어야 하며 유관부서의 동의를 얻어야 한다.  또한 정책이 정해졌으면 다른 부서가 중앙 EP에 구현된 기능을 재사용하여 그들이 필요한 어플리케이션을 만들어내기까지의 과정이 정확하게 정의되어있어야 하며 이 과정들이 여러 가지 매체를 통하여 각 부서에 전달되어야 한다.  또한 이러한 프로세스를 지원할 수 있는 어플리케이션을 첫 번째 포탈 오픈과 함께 제공하고 이를 지속적으로 운영해 나가야 한다.

<위의 그림에서 보는 바와 같이 Global Team은 전체 프레임워크 및 정책 등을 관리하고 각각의 비즈니스 어플리케이션은 각 BU의 담당자를 주축으로 구현되며 이렇게 구현된 어플리케이션이나 서비스는 전사적으로 최종사용자에게 공급된다.>

 

이러한 Governance의 중요성은 중복 투자의 방지 측면뿐만 아니라 최종 사용자 및 관리자의 혼란 방지차원에서도 중요하다.  EP가 조직 내에 자리 잡혀 나감에 따라 그 내부에는 수많은 비즈니스 어플리케이션 들과 그 어플리케이션을 구성하고 있는 수많은 서비스 (: 포틀릿)들이 생겨나게 된다.  이러한 것들이 기하급수적으로 늘어나게 되면 사용자들은 어떤 어플리케이션이 생겨나고 그 목적이 무엇인지 혼동하는 상황에 맞닥뜨리게 된다.  이러한 혼란을 방지하는 목적으로도 Governance에 대한 체계는 필수적이다.

 

이렇게 중앙 포탈 팀과 타 BU와의 협력 프로세스의 정의 및 홍보, 포탈을 기반으로 생성되는 어플리케이션 및 서비스에 대한 컨트롤, 또한 다양한 포탈관련 표준들을 알리고 관리하는 방법으로 선진 기업 들 중에는 이러한 포탈 Governance를 위한 어플리케이션을 포탈에서 제공되는 기반서비스를 이용하여 구현하고 사용하고 있는 곳들이 많으며, 이러한 기반은 필수적으로 첫 번째 포탈 오픈 전에 확립되어 시작과 함께 그 서비스가 제공되어야 한다.


<세계에게 가장 큰 광산 회사중 하나인 Rio Tinto는 그들의 포탈의 Governance를 위한 어플리케이션을 구현하여 운영하고 있다.>

제언 4. Big Bang vs. 반복적인 소규모 프로젝트

 

지금까지 전통적인 어플리케이션 개발 방법을 놓고 여러 가지 논의가 있어왔지만 어떤 IT프로젝트의 경우에는 한번에 모든 것을 구축하고 서비스를 시작하는 Big Bang 식 접근방법이 더 좋은 경우가 있는 반면에 엔터프라이즈 포탈의 경우에는 반복적인 소규모 프로젝트를 지속적으로 해나가는 모델이 절대적인 우위를 가진다 하겠다.  어떻게 생각하면 EP는 하나의 기반이기 때문에 그 위에서 구현될 모든 비즈니스 어플리케이션 들을 모두 한번의 기획으로 한방에 구현하는 것은 현실적으로 맞지 않는 것일 뿐만 아니라, 투자의 무리가 따르기도 하고 사내 자원의 불균형을 가져오기도 한다.

 

처음의 기반 구축에 2~3개월 정도의 시간을 투자하여 첫 번째 오픈을 3개월 이내에 하고, 그 이후에 6~10주를 주기로 반복적인 소규모 프로젝트를 운영하는 정책을 만들어야 한다.  물론 이러한 소규모 프로젝트는 Governance 체계를 통해 도출되어야 하며 타 부서와의 협력을 통해 구현되어 나가야 한다.  중앙에서는 그 여러 가지 소규모 프로젝트의 우선순위를 산정하고, 필수 기술에 대한 교육을 지속적으로 수행하며, 타 소규모 프로젝트에서 공유되는 기반서비스를 확충해 나가야 한다.

 

<반복적인 주기를 가지고 소규모 프로젝트를 지속적으로 진행하는 것을 골자로 하는 EP구축 방법론의 예>

 

엔터프라이즈 포탈은 살아서 계속 커나가야 한다.  항상 새로운 콘텐트, 어플리케이션이 개발되어야 하며 이를 통해 사용자에게 끊임없는 가치를 제공해야 한다.  그리고 이러한 살아있는 포탈을 만드는 것은 다른 부서들의 적극적인 참여이며 이러한 참여를 지원하기 위한 장치가 중앙에 마련되어야 함은 당연하다.

 

제언 5. 지속적인 펀딩을 받을 수 있는 체계를 마련하라.

 

지금까지의 내용을 보면 성공적인 엔터프라이즈 포탈의 관건은 현업에서 원하는 비즈니스 어플리케이션 구축을 위한 지속적이고 반복적인 소규모 프로젝트의 수행이다.  이러한 과정에서 필수적으로 필요한 것이 바로 예산이다.  중앙 포탈 팀은 프로젝트 별로 펀딩을 받는 것이 아니라 지속적으로 펀딩을 받을 수 있는 체계를 마련해야 하며, 이러한 펀딩 문제 때문에 시간에 민감한 비즈니스 어플리케이션의 구현이 늦어 불필요한 기회비용이 발생하는 일은 있어서는 안될 것이다.

 

제언 6. EP 구축 초기에 숨어있는 비용을 조심하라.

 

예산과 관련해 하나 더 제언할 것이 있다면 바로 보이지 않는 비용에 대한 것이다.  EP구축 초기에는 보이지 않던 비용이 전사적으로 그 활용도가 높아지면서 점차 확대되는 경우가 있다.  대부분의 경우 초기 포탈 구현에 서비스 비용이 높은 포탈 제품을 선택할 경우 이런 문제가 생길 경우가 많은 데 이런 경우 실제 총 소유비용 (TCO)은 운영해보기 전에는 드러나지 않는 경우가 많아서 주의가 요구된다.

 

예를 들어, EP도입 초기에는 그 첫 번째 프로젝트의 범위만 보고 특정 기술을 표준으로 하는 제품을 도입하여 프로젝트를 성공적으로 마쳤다 하더라도 전사적으로 그 사용이 확대되고 부문별로 새로운 시스템이 도입됨에 따라 그 통합 비용이 기하급수적으로 높아지는 경우가 비일비재하기 때문에 초기 EP제품 선택 시 장기적인 관점에서 특정 기술에 종속적이지 않는 제품을 선택해야만 진정한 TCO절감이 가능하다고 하겠다.

 

예상치 못했던 비용을 초래하게 되는 경우가 또 한가지 있다.  바로 비전과 현실을 제대로 구분하지 못할 경우 겪게 되는 문제이다.  솔루션 벤더들은 대체로 자신들의 현실보다는 비전을 세일즈한다.  이 비전 중에서 현재 어느 정도나 제품화가 되어 있는 지, 또 벤더가 주장하는 비전대로 실제 그 제품을 사용하는 곳이 있는 지를 확인해보아야 한다.

 

엔터프라이즈 포탈이라는 시장이 특히 국내에서는 신규시장이다 보니 본사에서 교육시킨 비전만을 가지고 세일즈를 하게 되는 경우가 많아 실제 구현이 가능한 기능과 많은 격차가 있을 수 있으며 담당자가 이를 제대로 파악하지 못했을 때에는 예상치 못했던 비용을 야기할 수 있다.

 

이를 확인하는 방법으로 제안하고 싶은 방법은 실제 구현되어 있는 국내의 레퍼런스를 방문하여 확인하는 것이다.  이때는 그냥 구경에만 그치지 말고 자신이 확인해 보고 싶었던 세세한 사항들을 목록으로 만든 후에 실제 어떻게 구현이 되어 있는 지를 확인해보는 것이 중요하다.  소프트웨어 세계에는 불가능이란 없다.  어떤 식으로든 구현은 가능하다.  다만 어느 정도의 노력을 해야 구현할 수 있는가가 차이 나는 것이다.  담당자들은 이것을 정확히 집어내야 한다.

 

실제로는 한 부문에서 사용하는 특정 목적의 웹사이트를 구축한 경험만 가지고 있는 업체가 엔터프라이즈 포탈을 구축해봤다고 주장하는 업체도 있고, 아니면 우리가 논의하고 있는 엔터프라이즈 포탈의 개념과는 다른 목적을 가지고 구현된 웹사이트를 UI가 포탈과 비슷하다는 이유로 엔터프라이즈 포탈이라고 주장하며 세일즈하는 회사도 있기 때문이다.  두 경우에 있어서 담당자 들은 이런 주장이나 비전 뒤에 숨어있는 현실을 볼 수 있는 안목을 보유해야만 한다.

 

제언 7. 미래의 흐름에 대비한 현재의 프레임워크를 구축하라.

 

포탈을 기반으로 비즈니스 어플리케이션을 구축할 경우 레거시 어플리케이션이나 레포지토리의 데이터나 로직을 사용할 필요가 있을 때에는 이를 포탈과 통합하는 일정한 노력을 했어야 했다.  또한 프로그램 내부 소스에 접근이 제한적인 SAP, Siebel, PeopleSoft, Oracle ERP등의 패키지 어플리케이션 들의 데이터나 로직을 통합하는 경우에도 (이러한 패키지들도 외부 API 제공 정도가 각기 차이가 있어 그 통합 난이도에 저마다의 차이가 있긴 했지만) 일정한 노력이 필요했던 것이 사실이다.

 

이런 경우 해당 기업은 그 레거시 어플리케이션에 대한 업무의 종속성을 고려하여 엔터프라이즈 포탈을 도입하려고 할 때 그 레거시 어플리케이션을 제공한 벤더의 EP 솔루션을 검토하는 경우가 많았다.  물론 이런 경우 해당 레거시 시스템을 제외한 타 시스템의 통합에서는 어려움이 많아 결국 기업은 여러 개의 Vertical 포탈사이트를 갖게 되는 결과를 일반적으로 낳아왔다.

 

그런데 이제 이 패키지 어플리케이션 들이 변화하고 있다.  웹 서비스라는 표준이 성숙되어 감에 따라 이 패키지들도 이 표준에 맞추어 개발되고 있으며 기업내부에서도 어플리케이션을 개발할 때 웹 서비스를 그 표준으로 선택하는 것을 적극적으로 검토하기 시작하고 있다.  물론 이렇게 개발된 서비스들의 통합 및 Delivery 채널을 포탈이 담당한다는 것이 업계의 공통적인 견해이다.  흔히 업계에서는 이러한 유명 패키지 어플리케이션 벤더들이 2005년을 기점으로 웹 서비스를 근간으로 구현된 제품을 내놓을 것으로 보고 있다.

 

따라서 지금 포탈을 선택하는 경우 이러한 웹 서비스 아키텍처 또는 서비스 지향적 아키텍처(Service Oriented Architecture: SOA)를 충실히 지원하는 있는 제품을 선택하는 편이 현재의 투자를 장기적으로 보호하는 방법이 될 것이다.

 

이번 호에서는 엔터프라이즈 포탈을 계획하고 있는 기업들이 프로젝트를 시작하기에 앞서 꼭 유념해두어야 할 사항들에 대해 설명하였다.  다음호에서는 지금까지 얘기했던 내용에 대한 보다 구체적인 예를 제공하기 위해 선진 기업들에서는 어떤 식으로 자신들의 엔터프라이즈 포탈을 이용하고 있는 지에 대하여 설명하도록 하겠다.

 

728x90
반응형

WRITTEN BY
bca (brainchaos)
언저리 - 블로그 = f UN + b LOG #BigData, #GrapDB, #Ani, #Game, #Movie, #Camping, 보드, 술먹고 떠들기, 멍때리기, 화장실에서 책읽기, 키스, 귀차니즘, 운동싫어, 버럭질 최고, 주경야독, May The Force be With You

,