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

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


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


/재/목/차

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

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

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

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

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


강좌 │ 글로벌 사례 및 경험 소개 (4회)


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

지금까지 EP와 관련하여 1 엔터프라이즈 포탈의 개념 - EP란 무엇인가? (개념 생성에서 현재까지의 발전 과정 및 트렌드 분석), 2 EP의 컴포넌트 및 연관 솔루션-EP 솔루션 선택, 우리 회사에 적합한 솔루션은?, 3 EP Critical Success Factors-EP 프로젝트 기획, 이런 것들을 유의해야 한다!를 통하여 EP와 관련된 여러 가지 사항들을 살펴 보았다. 이번 호에서는 마지막으로 글로벌 사례를 통하여 왜 글로벌 선진 기업들은 EP를 도입하고 어떻게 운용하며 어떠한 효과를 보고 있는 지에 대하여 살펴 보고자 한다.

 

EP를 구축하고자 하는 동기는 다음의 경우들로 요약할 수 있다

1.    Business Speed에 부합하는 IT의 신속한 응답성 확보와 그로 인한 수익의 증대

2.    고객 서비스의 질적 향상과 비용의 절감

3.    종업원과 조직 내 또는 조직 간 생산성 향상

4.    IT의 개발, 관리 그리고 유지 보수의 비용 절감

 

Business Speed에 부합하는 IT의 신속한 응답성 확보와 그로 인한 수익의 증대:

새로운 Business 목적에 따라 새로운 Web Application을 구축해야 하는 경우 이미 존재하는 Application System으로부터의 연동이나 필요한 부분만을 간편하고 신속하게 EP의 한 부분으로서 구축을 함으로서 새로운 개발이나 수정에 따른 시간의 손실을 최소화하고, 이미 개발된 다른 시스템의 Component를 그대로 재사용하며, 굳이 Programming을 하지 않더라도 시스템 내의 기능들로서 새로운 시스템의 Component들을 생산해 낼 수 있다면 이는 곧 시스템 구축에 소요되는 시간을 상당 부분 줄일 수 있다. 현재와 미래의 기업은 곧 시간의 싸움이다. 지금까지 Application System을 구축하는 데에는 전적으로 Coding에 의존할 수 밖에 없었지만 그 시스템에 기반을 두고 있는 Web Application까지도 매 번 새로운 Coding을 해야 한다면 이는 곧 Business 기회의 손실과 더 나아가서는 Business 기회의 상실까지도 감수해야 하는 경우가 있을 지도 모른다. 만약 Business가 요구하는 새로운 웹시스템을 예전에는 몇 개월 걸려서 개발하던 것을 1-2주로 줄일 수 있다면 이는 비용으로 환산할 수 없는 효과가 될 것이고 나아가 이러한 신속한 현업지원이 시장 선점으로 이어지거나 시장의 요구에 시의 적절하게 반응한 것이라고 하면 기업의 수익에도 상당한 기여를 할 것이다.

 

고객 서비스의 질적 향상과 비용의 절감:

고객 서비스는 모든 조직이 안고 있는 당면 과제이다. 고객의 서비스 내용과 질에 따라서 기업이나 조직행위의 결과가 좌우되는 만큼 그 중요도는 재론하지 않아도 누구나 알 수 있는 주제이다. 문제는 서비스의 질도 중요하지만 그에 소요되는 비용도 중요한 고려 사항인데, 가령 500개의 매우 규모가 큰 기업을 고객으로 가지고 있는 기업이 있고 이 기업이 전 세계에 있는 이 고객들을 각각 개별적으로 지원을 해야 하는 경우가 있다 하자. (이 것은 실제로 있는 경우이다) 이 고객들에게 방대한 량의 Contents를 포함하는 개별 Web System을 기존 Program Coding방식으로 개발한다고 하면 그에 소요되는 비용 또한 막대할 것이다. 그러나 이 회사는 하나의 Portal을 통하여 모든 개별 고객의 요구에 맞는 Web System을 구축하였고 이의 유지보수나 추가 개발을 위하여 많은 부분을 자동화하면서도 각각의 요구에 부합하는 시스템을 운영하고 있다. 이로 인하여 고객 서비스 비용을 대부분 절감하면서도 최상의 고객 만족도를 유지하고 있다.

 

종업원과 조직 내 또는 조직 간 생산성 향상:

기업의 가장 큰 자산은 종업원이다. 이들이 얼마나 생산성을 향상시키는 가에 따라서 기업의 성패가 좌우될 수도 있다. 물론 기업에는 종업원 이외에 다른 형태의 자원들이 많이 있을 수 있지만, 결국 그 자원들을 운영하는 주체도 종업원이다. 실제 종업원에 대한 급여가 기업이 지출하는 비용의 대 부분을 차지한다고 보아도 좋을 것이다. 이 종업원들이 많은 부분을 정보에 의존하여 업무를 수행하고 종업원들의 정보활용에 관한 생산성이 증가한다면 이는 기업으로서도 매우 유익한 일이 될 것이다. 최근 종업원 3,000명인 회사의 종업원의 생산성이 일인당 하루 10분씩 향상된다고 하면 연간 약 50억 원의 효과가 있다는 자체 조사가 있었는데 그 효과가 하루 30분 정도까지 향상된다고 하면 그 금액은 연간 약 150억 원에 이른다. 이는 초기 투자 비용을 감안하더라도 기업으로서는 매우 유용한 투자가치가 있는 일이라고 볼 수 있다. 또한 기업은 조직 내에 사업의 수행과정상 다양한 커뮤니티를 가질 수 있으며, 직접적인 관계를 맺고 있는 고객 및 파트너 또는 공급자와 다양한 관계를 유지하고 있습니다. 이러한 상호작용의 과정상 다양한 형태의 거래와 교감이 일어날 수 있는데 이 과정에서 종업원의 업무를 수행하는 품질과 생산성도 중요한 부분이지만 파트너와 공급자와의 유기적인 관계도 매우 중요한 것입니다. 고객, 파트너 그리고 공급자와의 MOT (Moment of Truth) 관리는 기업의 중요한 업무영역이며 생산성 향상의 대상인 것입니다.

 

IT의 개발, 관리 그리고 유지 보수의 비용 절감:

IT부서의 근본적인 Mission은 기업 또는 조직이 사업을 영위하는 데 있어서 현업의 사용자가 맡은 바 사업상의 결정을 내리기 위한 정보를 제공하고 이를 관리하기 위한 시스템을 구축하는 일이다. 이를 위하여 데이터의 처리와 축적을 위한 기간계 시스템을 구축하고 외부환경의 변화로 인한 현업 사용자의 변경 또는 새로운 시스템에 대한 요구를 수용하여 기존 시스템을 수정하거나 새로운 시스템을 구축하는 일이 주된 업무이기도 하거니와, 때로는 기업의 혁신을 위하여 새로운 Paradigm을 반영한 시스템을 통하여 현업을 Lead하기도 한다. 따라서 시스템을 구축하고 유지보수하며 그 과정에서 새로운 혁신의 주도자가 되기도 하는 것이다. 기업환경이 Global화하고 그에 따르는 Web 환경으로의 전이는 필수적으로 요구되는 상황에서 IT는 그 간 다양한 시도를 하여 왔고 앞으로도 그 노력은 계속될 것으로 본다.

그 동안 IT는 기존 시스템을 통째로 Coding을 통하여 Web화 하기도 하고 일부 WAS(Web Application Server)들을 통하여 특정 Application들을 새로운 Web Application으로 개발하기도 하였으며, EAI (Enterprise Application Interface)를 통하여 새로운 Application Web화를 동시에 추진하기도 하였다. 그러나 현실적으로 많은 이 기종 시스템에 산재하고 있는 시스템을 Web으로 개발하는 것도 어려운 작업이고 또, 한 번 만들어 놓은 시스템을    관리하거나 보수하는 일은 더 더욱 어려운 일이었던 것이 사실이다.  현실적으로 새로운 Portal 시스템을 구축하는 것은 웬만한 기술을 갖춘 업체는 다 할 수 있는 일이기는 하다. 단지어떻게개발하는 지가 개발에 소요되는 비용, 시간 그리고 노력을 결정할 뿐이다. 이는 특히 향후 유지 보수에 소요되는 비용과 시간을 결정적으로 좌우하는데 이들 개발과 사후관리의 수 작업을 최소화하고 시스템적으로 관리 함으로서 기업은 시스템의 개발, 유지보수 그리고 성능에 있어서 경쟁력을 갖출 수 있는 것이다. 예를 들어서, 이 기종 시스템으로부터의 Web 시스템 개발을 쉽고 편하게 하고, 새로운 기술을 습득하느라고 기존 IT 자원을 재교육할 필요가 없으며, 상당 부분 Coding이 필요 없는 시스템이 있다고 하면 개발에 필요한 시간과 비용을 상당 부분 절약할 수 있다. 또한 현업의 변경 요구를 시스템적으로 처리할 수 있다고 하면 관리의 대 부분을 간편하게 처리할 수 있으며, 새로운 시스템은 기존의 시스템으로부터 필요한 부분이나 시스템의 기능으로부터 제공되는 기능을 조합하여 구축할 수 있다면 IT 비용을 획기적으로 줄여나갈 수 있을 것이다.

 

이와 같은 목적으로 Global 기업들을 주축으로 다양한 형태의 EP가 구축되어 온 바, 각 산업별로 대표적인 사례를 소개하고자 한다.

 

항공 산업

 

Pratt & Whitney: 상업용, 군용, 민간 항공기 엔진, 우주선 추진체, 발전 시스템 등의 설계, 제작, 지원 분야의 최고 기업.

이용 대상: 전세계의 17,000명의 직원, 협력업체, 공급업체, 고객Pratt & Whitney는 엔진 유지보수와 수리에서부터 배상 청구 처리, 그리고 부품 조달에 이르기까지 모든 것에 대해 다양한 상용 플랫폼과 전용 플랫폼에서 웹 애플리케이션을 만들었다. IT 부서는 동일한 시스템 환경 내에서 직원들을 위한 내부 포탈과 고객, 협력업체, 부품 공급업체 등을 위한 개인화된 외부 포탈을 통하여 이질적인 정보 자원으로 연결되는 웹 애플리케이션을 구축하여 투자 수익을 증가시킨 경우임. 다중 사이트, 다자간 제안 협업 작업을 촉진시키기 위하여, Pratt & Whitney는 전세계적으로 분산된 영업 사원, 협력업체, 부품 공급업체 등이 공유하는 VPC(Virtual Proposal Center)를 만들었습니다. VPC의 핵심은 안전한 워크플로(Workflow)를 구축하여 VPC 사용자들로 하여금 간편하고 빠르게 프로세스를 진행시킬 수 있다. 이를 통하여 영업 주기가 한 달 이상 단축되었기 때문이다. 또한 Pratt & Whitney는 여러 가지 웹 서비스를 결합하여 맞춤형 업무 프로세스를 만들어서 포탈 내에서 애플리케이션을 생성하고 있습니다. 사용되고 있는 수 만 개의 엔진 컴포넌트에 대한 데이터를 관리하기 위하여, Pratt & Whitney는 독특한 SuperFinder Community를 개발했습니다. 이 커뮤니티는 사용자가 지정한 부품 번호를 중심으로 커뮤니티 내의 모든 포틀릿, 게시 자료, 검색 에이전트 등을 동적으로 재설정하여, 문자 그대로 모든 부품에 대해 고유한 하위 포탈을 만듭니다. Pratt & Whitney의 고객, 협력업체, 공급업체 등은 포탈에서 SAP의 계정 정보, 엔진 서비스에 대한 개인화된 데이터, 예비부품과 신뢰도에 대한 정보 등을 액세스하고 있다.


Pratt & Whitney 사의 Portal 

에너지 산업

 

Halliburton: Halliburton은 정유 산업과 에너지 산업계에 제품과 서비스를 공급하는 세계 최대 회사 중 하나임.

이용 대상: 전세계 30,000명의 사원들과 4,300개 이상의 고객사

Halliburton은 고객, 부품 공급업체, 직원 등을 위하여 다채로운 기술 컨텐츠, 대화식 툴, 협업 기능, 전자 상거래 기능 등을 전달하는 포탈을 구축했다. 시스템 구현 첫 해에, myHalliburton 포탈 솔루션은 매출에 1 5천만 달러의 영향을 주었다. 기업 효율성은 거의 500,000 달러 정도 향상시켰으며, 고객으로부터의 지불 주기가 단축되었다. myHalliburton 포탈에서는 고객들이 기술적 도구, best practice정보, SAP 계정 데이터, 프로젝트 관리를 위한 내부 포럼 등을 이용할 수 있다. 전세계의 Halliburton 고객들은 포탈을 통하여 제품 정보를 수집하고 송장 처리를 추적하고 기술 전문가들의 지식 베이스를 이용할 수 있다. 그리고, Halliburton 팀과 공동 작업을 하여, 능률적으로 계정을 관리하고 지불 주기를 단축하고 석유와 가스 유정의 수익성을 향상시킬 수 있다. 최근에 설문 조사를 한 myHalliburton 고객 사용자들의 40 퍼센트는 이 포탈이 Halliburton 제품과 서비스 구매에 긍정적인 영향을 주었다고 말했으며, 59 퍼센트는 이 포탈이 앞으로 구매하는데 영향을 줄 것이라고 말했다.

Halliburton 사의 Portal

 

제조 산업

Alcoa: 매출액이 203억 달러인 Alcoa 1차 알루미늄, 가공 알루미늄, 알루미나 등을 생산하는 업계세계 최고의 기업임

이용 대상: 전세계의 50,000명의 직원

Alcoa는 이 전세계적인 회사 전체에서 지식 공유, HR (Human Resources) 셀프 서비스, 웹 어플리케이션 개발 표준 등을 정착시키기 위하여 기업 포탈을 구축하였다. 50,000명의 Alcoa 직원들과 지식 작업자들은 사무실 데스크탑과 생산 현장 키오스크를 통하여 전세계적인 지식 베이스를 검색할 수 있으므로, 노동력을 절감하고 생산성을 향상시키는 지식에 대하여 가장 좋은 방법을 공유할 수 있습니다. Alcoa의 포탈은 전세계의 1,200개 이상의 인트라넷 사이트에 분산되어 있는 애플리케이션을 통합하고 컨텐츠를 인덱싱하는 프레임워크이므로, 협업을 촉진하고 개발 비용을 통제하여 생산 주기를 단축하는데 도움을 주고 있다

 

Ford Motor Company: Ford Motor Company는 세계에서 두 번째로 큰 자동차 제조업체임.

이용 대상: 전세계의 250,000명 이상의 직원들과 협력업체

Ford에서는 하나의 포탈이 1,500개의 사이트, 300,000개의 웹 페이지, 1백만 개의 문서로 구성되어 있다. 이것은 세계에서 가장 큰 상용 인트라넷 포탈이다. 사무실 책상과 조립 라인 키오스크에서, 전세계의 1,000개의 시설에서 일하는 200,000명의 직원들이 매일 my.ford.com을 방문하여, 작업 시간 기록, 텍스트 검색, 출장 예약, 봉급 명세표 확인, 수당 등록, 주문형 강좌 등을 이용한다. 하나의 데스크탑에서 일하면서 직무 훈련도 할 수 있게 함으로써 포드의 교육비는 처음 6개월동안에만 2백만 달러나 절감되었다.

 

포드는 미국과 유럽 19개국에 딜러용 포탈을 배치하고 있다. FMCDealer.com 포탈에서 딜러들은 영업 콘테스트나 인센티브와 같은 정보, 차량 주문과 가격 책정 지침, 새로운 제품 사양, 지역 관련 정보 전달, 서비스 부품 데이터, 현장 서비스 조치, 제품 보증, 고객 만족도 정보 등을 이용할 수 있으며, 부속품 주문을 위하여 Dealer eStore를 액세스할 수 있다. 포탈은 애플리케이션과 툴을 이용할 수 있고 대략 6,000명의 딜러, 수 백개의 부품 공급업체, 현지 직원 등의 협업 수단도 되므로 응답 시간을 향상시키고 있다. Ford FMCDealer.com 포탈에서 매년 3 5십만 달러에서 4백만 달러 정도를 절감하는 것으로 추산한다.

 

Ford 사의 Portal

 

Procter & Gamble

 

회사: Procter & Gamble (P&G) 140개 이상의 나라에서 거의 50억명의 소비자들에게 대략 300가지 브랜드를 판매하는 거대 기업임.

이용 대상: 회사 전역의 68,000명의 직원들

Procter & Gamble은 직원들과 일련의 시스템들이 기존의 업무와 테크놀러지의 한계를 넘어서 함께 일할 수 있는 개방적인 웹 시스템 환경을 만들었습니다. P&G의 포탈은 P&G의 전세계적인 네트워크에 있는 백 만개 이상의 웹 페이지와 수 천 개의 Lotus Notes 데이터베이스와 파일 서버의 컨텐츠를 통합한다. Procter & Gamble은 다양한 엔터프라이즈 애플리케이션을 포틀릿으로 포탈에 통합하고 있으며, 그러한 포틀릿 중에는 회사의 SAP R/3 ERP 시스템, 오라클 데이터 웨어하우징(Data Warehousing)과 비즈니스 인텔리전스 애플리케이션, Epiphany E4 CRM 서비스가 포함되어 있다.

 

포탈을 사용하면서 Procter & Gamble의 생산성 증가는 생산 현장에서도 나타났습니다. 예를 들어, 최소한의 시간과 비용으로, 한 생산 플랜트 (제지 공장의 경우 축구장 넓이의 몇 배가 되는 규모) IT 관리자는 이전에는 수동 프로세스를 사용하고 직접 만나 회의를 해야 했던 일상적인 프로세스를 웹에서 이용하게 만들 수 있었습니다. 그 덕분에 품질, 안전성, 실적 관리 등이 능률적이 되었고 연간 대략 32,000 작업-시간이 줄어들었다.


제약, 의료 산업

 

GlaxoSmithKline: GlaxoSmithKline (GSK)는 최고의 연구 중심 형 다국적 제약 회사임.

이용 대상: 전세계의 100,000명의 직원들과 주요 협력업체

GlaxoSmithKline은 다양한 종류의 시스템과 업무 부서가 포함되어 있는 다채로운 사용자 환경을 만드는 것을 지원하려 엔터프라이즈 웹 시스템을 구축하였다. myGSK 포탈은 5개 대륙에 흩어져 있는 지역 사무소, 다양한 업무 부서, 다양한 브랜드에 서비스를 제공한다. myGSK GlaxoWellcome SmithKline Beecham이 합병을 하여 GlaxoSmithKline이 된 이후 두 회사의 애플리케이션과 정보를 결합하는 온라인 정보 자원 센터 역할을 하고 있습니다.

 

Eli Lilly and Company: Eli Lilly and Company는 전세계 158개국에서 의약품을 판매하고 있는 제약 업계의 선두 기업입니다.

이용 대상: 전세계의 31,000명의 임직원들

Lilly는 포탈 프로젝트를 직원들의 협업 플랫폼으로 시작했습니다. myELVIS라고 알려져 있는 Lilly  포탈은 Semio corporation의 주요 테크놀러지를 통합하여 수 천 개의 Lotus Notes Documentum 데이터베이스의 컨텐츠를 분류하는 작업을 자동으로 처리하므로, 정보 검색 속도가 빠르고 Lilly global enterprise 전체에 전문 지식을 배포할 수 있다. 현재 과학자들과 영업 사원들은 동일한 포탈을 통해 시장 뉴스, 특허 서비스, 임상 실험 결과 등을 볼 수 있으며 프로젝트 관리와 운영 시스템도 공유하고 있다.

 

,소매 유통 산업

 

Staples: Staples은 사무용품업계에서 매출이 110억 달러나 되는 선도적인 유통업체임.

이용 대상: 회사 전체의 40,000명 이상의 직원들

1,400개의 매장에서 일하는 모든 사무직원과 현장 직원들에게 배치된 Staples@work 포탈에는 실적 척도, 홍보 자료, 매출 및 재고 보고서, 통합 계획 프로그램, 작업 관리를 위한 Reflexis, PeopleSoft 셀프 서비스 툴 등이 모아져 있으므로, 이 회사가 기업 내부 정보 전달을 능률적으로 수행하고 재고를 감축하는데 도움을 받고 있다. Staples은 포탈의 헬프데스크 애플리케이션을 통해 한 달에 40,000장 이상의 요구사항을 웹으로 처리하여, 직원들의 업무처리 능력이 강화되고 생산성이 증가하고 있다. 이 회사는 동료 직원이나 매장 관리자들이 매장에서 접근 가능한 포탈을 사용하기 때문에 매년 생산성 절감액이 2백만 달러 이상이라고 추산한다. 이 경우 포탈은 키오스크, "스마트 레지스터"에 존재한다.

 

Starbucks

회사: Starbucks Coffee Company는 세계 최고의 특수 커피 소매, 가공업체임.

이용 대상: 8,000명 이상의 사무직원과 매장 근무 직원들

Starbucks 직원 포탈은 지역적으로 분산되어 있는 Starbucks 매장들을 회사 홍보, 이니셔티브, 브랜딩 등과 관련된 협업 프로젝트 커뮤니티와 연결시키며, 가상 프로젝트 팀이나 업무 부서가 서로 공동 작업을 할 수 있도록 도와 주는 생산성 관련 커뮤니티와도 연결시킨다. Starbucks의 포탈은 개인화된 관련 정보와 애플리케이션을 모든 사용자 그룹으로 전달하며 분산된 조직의 생산성 향상을 목표로 구축되었다.

Starbucks 소매점에서 일하는 매장 지배인과 직원들은 포탈에서 마케팅 정보, 매출 보고서, 제품 시연, 지역별 달력, 멀티미디어 교육 툴 등을 접하게 된다.

Starbucks 사의 Portal

전문 서비스 산업

 

Fannie Mae Foundation: Fannie Mae Foundation은 저렴한 가격의 주택 공급과 지역 공동체 재생 사업을 전문적으로 수행하는 미국에서 가장 큰 조직체임.

이용 대상: 6,000명 이상의 정책 결정자, 실무자, 학자

KnowledgePlex는 저렴한 가격의 주택 공급 및 커뮤니티 개발 현장 내의 협업, 정보, 전문 지식을 중앙 집중식으로 처리하는 최초의 온라인 환경이다. 현재 사용자들은 지식을 공유하고 정책 문제를 공동으로 진행하고 보다 양호한 주택과 건실한 주변 환경, 그리고 보다 안전한 거리를 만들기 위해 최상의 관행을 연구한다는 한 가지 목표를 가지고 있다.

 

Fannie Mae Foundation Knowledgeplex 포탈을 이용하면 다음과 같은 방법으로 광범위한 정보 자원을 액세스할 수 있습니다.

l  검색이 가능한 지식 베이스에 기사, 사례 연구, 보고서, 저널, 300가지 이상의 뉴스 보도 자료 등의 수집 및 인덱싱

l  사용자들이 도시 개발이나 저소득과 농촌 주택 개발과 같은 매우 다양한 주제들에 대해 토의하고 문서를 공유하는 협업 그룹 구성

l  주택 공급 뉴스 기사를 매일 요약하여 전자 메일로 발송

l  사용자들이 자신과 가장 관련이 있는 컨텐츠, 토의, 사용자 커뮤니티 등을 선택하여 자신의 환경을 개인화할 수 있게 함

Fannie Mae Foundation KnowledgePlex 포탈은 2002 WebAward Competion에서 Best Portal Web 사이트로 선출되었습니다


Ketchum: Ketchum은 세계에서 여섯 번째로 큰 광고 회사임.

이용 대상: 전세계의 Ketchum 클라이언트와 1,500명 이상의 직원들

META Group의 투자 수익 연구에서는 myKGN 포탈에서 4년 동안 1 2 1십만 달러의 수익을 올린 것으로 나타났다. META Ketchum이 다음과 같은 방법으로 가치를 창출하고 있는 것으로 결론을 내렸다.

l 매출 증가: 포탈을 통하여 클라이언트와 협업을 하면서 경쟁력이 강화되어, 잠재적으로 매출 수입을 1 8백만 달러 이상 증가시킴.

l 생산성 향상: 평균적으로, 포탈을 이용하는 Ketchum 직원들은 언론과 미디어에서 다룬 내용, 사례 연구, 과거의 작업 등을 검색하는 시간을 일 주일에 1시간 정도 절약하여 5 3십만 달러 정도의 생산성 향상과 관련된 효과를 본다.

l 출장비 절감: 전세계의 Ketchum 직원들이 포탈을 온라인 협업 플랫폼으로 사용하면서 출장비를 연간 300,000 달러 이상 절감할 수 있었다. 


금융 산업

 

California Casualty

회사: California Casualty는 미국 내 29개 주에서 100개 이상의 단체와 가족 보험 및 자동차 보험 계약을 체결합니다.

이용 대상: 17,000명 이상의 고객 및 10,000명의 가망 고객

보험 업계에서 최상위 20개 웹 사이트 중의 하나로 꼽히는 California Casualty MyAPlus.com 포탈은 보험 계약자들이 실시간 자동차 보험 견적과 가족 보험 견적서, ID 카드와 배서를 포함한 보험 증권, 온라인 청구, 보상 청구 등을 이용할 수 있는 안전한 장소가 되므로, 널리 분산되어 있는 고객 기반에 e-비즈니스 서비스를 보다 신속하게 제공할 수 있다. META Group California Casualty MyAPlus.com 포탈에서 전체의 49%에 해당하는 투자 수익이 나오는 것으로 평가하고 있다. 이것은 지원 비용을 낮추고 고객 및 단골 고객 확보를 강화시키며, 매출 신장을 향상시키기 때문이다.

 

공공 부문

 

메릴랜드 주: 주민이 5 5십만명인 Maryland는 미국에서 18번째로 인구가 많은 주임.

이용 대상: Maryland 시민, 기업체, 방문객들, 그리고 메릴랜드 주에 관심을 가진 제3

메릴랜드 주는 포탈을 통하여 사용자들이 주 정부, 지방 정부, 연방 정부 등의 자원과 서비스를 이용할 수 있는 중앙 통로를 마련하고 있다. 메릴랜드 포탈이라고도 하는 Maryland.gov는 시민, 기업체, 방문객들이 메릴랜드에서의 매일매일의 생활에 관한 정보를 효율적으로 이용하도록 마련하고 있다. 그러한 정보의 일부는 다음과 같다.

l  주 행사 일정표

l  DMV 및 교통 정보

l  가족, 건강, 안전 정보

l  취업 기회 및 개발

l  정부 및 선거 뉴스

l  장애인 자원

l  여행 및 레크리에이션 자원

l  세무 정보

l  뉴스 및 경보

 

메릴랜드 포탈을 이용하면 대중이 관련 정보를 빠르고 쉽게 검색할 수 있으므로, 공무원 생산성을 증가시키는데 도움이 되고, 제한된 공공 자원을 절약하고 민원 서비스의 품질, 응답의 적시성, 정확성이 향상된다. 메릴랜드 포탈은 공공 익스트라넷이며 http://www.maryland.gov 에 있다. 

Maryland 주의 Portal

 

이상 다양한 산업별 사례에서 보듯이 다양한 목적으로 Portal이 구축될 수 있고 그 효과도 Portal Project 별로 다양하게 나타나는 것을 볼 수 있다. 이 글에 실린 화면만을 보면 일반적인 Web Application과 큰 차이가 보이지 않을 지도 모른다. 그러나 빙산의 밑 부분처럼 화면 뒤의 시스템과 그 기능들이 더욱 중요하다.

맺음말

이상 다양한 산업별 사례에서 보듯이 다양한 목적으로 Portal이 구축될 수 있고 그 효과도 Portal Project 별로 다양하게 나타나는 것을 볼 수 있다. 이 글에 실린 화면만을 보면 일반적인 Web Application과 큰 차이가 보이지 않을 지도 모른다. 그러나 빙산의 밑 부분처럼 화면 뒤의 시스템과 그 기능들이 더욱 중요하다. 따라서 이제까지의 내용을 마치기 전에 마지막으로 EP와 관련된 제품과 서비스를 고려할 때 반드시 검토해야 할 중요한 사항을 제시하고자 한다.

 

기간 계 시스템과 Portal IT 아키텍처상 다른 계층에 위치한다. 지금까지는 기간 계 시스템을 직접적으로 수정하여 어플리케이션 시스템의 연장선상에 위치하는 시스템으로 구성하였기 때문에 비즈니스 환경이 변화하고 그에 따른 시스템의 변경이 요구되면 또 재개발과 같은 방법으로 어플리케이션 시스템의 수정이 일어나기 때문에 현업의 요구에 대한 적시 응답 성이 떨어지며 비용과 노력이 과다하게 소요되는 경향이 있었다. EP는 어플리케이션 시스템의 상단에 위치하며 사용자의 요구가 있을 때 어플리케이션 시스템에 직접적으로 영향을 주지 않으면서 사용자의 요구 사항에 부응할 수 있어야 한다. 이 때 EP는 어플리케이션 시스템의 다양한 기종과 OS 그리고 각 어플리케이션 시스템의 특성을 간단히 통합하고 Java이든 .NET이든 최적의 시스템 구축에 필요한 개방성을 가지고 있으면 그것으로 족한 것이다.

 

결론적으로 각 제품 군은 각기 다른 특성이 있다. 그러나 일반적으로 EP를 논할 때, 다음과 같은 점이 중요하다고 생각한다. 첫째, 통합성이다. 기업의 시스템은 대 부분의 경우 이 기종 환경이다. 많은 기업들이 시스템 플랫폼을 인위적으로 통합하려는 시도를 했지만 대 부분의 경우는 얼마간의 시간이 지나고 나면 다시 이 기종 환경이 됩니다. 통합 당시 존재하지 않았던 시스템과 기술이 시간이 지나고 나면 개발이 되고 또 고객이 그 기술과 시스템을 필요로 하기 때문이다. 시스템을 개발하기 위하여 이 기종환경을 관리하는 노력이 얼마나 큰 부분을 차지하는 지는 쉽게 이해하실 것으로 생각한다. 둘째, 관리의 효율성이다. EP는 한 번 구축하고 평생 사용하는 시스템이 아니다. 살아 움직이는 시스템이 되어야 한다. 항상 변화하는 시스템이 매번 사람 손을 거쳐야 한다면, 그 부분에 소요되는 시간과 비용과 노력이 더욱 필요하기 때문이다. 한 기업 또는 조직 내에서도 조금 다른 Web System을 구축하기 위하여 똑 같은 시간과 노력을 기울이는 것이 일반적인 상황이다. 만약에 이미 구축되어 있는 시스템으로부터 부분 부분을 가져다 쓸 수 있고, Web Programming을 하지 않고 구축할 수 있는 부분이 있다면 생산성은 몇 배 향상 될 것이다. 이 개념이 Gartner사에서 말하는 Composite Application의 개념에 부합하는 것이다. 셋째, 개방성이다. () 기종 환경은 물론이려니와, IT 산업의 다양한 표준과 기술 그리고 보유하고 있는 인적 자원의 다양한 기술을 수용할 수 있다면 기업이 그 간 투자한 부분에 대한 그리고 앞으로 일어날 투자에 대한 보호가 가능하다. 만약 Portal 시스템이 Application System과의 호환성이 없어서 하나의 기술만을 선택해야 하는 경우가 발생하면, Application System개발 투자에 비해 상대적으로 시간과 비용이 덜 필요한 EP의 투자가 앞으로 있을 기간 계 시스템 구축에 있어서 제약이 된다면 이는 결코 바람직하지 않은 일일 것이다.

728x90
반응형

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

,

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

,

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

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


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


/재/목/차

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

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

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

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

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


강좌 │ EP의 솔루션 선택! (2회)


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

EP 솔루션 선택, 우리 회사에 적합한 솔루션은?

지난호에서 자세히 설명했던 바와 같이 근래 세계의 선두 기업들이 EP (Enterprise Portal)를 앞다투어 도입하고 있는 가장 중요한 원인은 기업이 전술상 또는 전략상으로 필요로 하는 업무용 어플리케이션을 적은 비용으로 빠르게 구현하여 비즈니스 유저들에게 제공함으로써 IT는 업무 어플리케이션 구축 비용 및 시간을 절약하고 비즈니스 유저들은 자신의 업무에 필요한 어플리케이션을 신속히 제공받음으로써 사업의 기회비용을 줄일 수 있는 가장 현실적인 대안으로 EP가 대두되고 있기 때문이라는 것을 다시 한번 유념해둘 필요가 있다.이렇게 EP를 기반으로 구현된 어플리케이션 들의 특징은 다음과 같다.

-       새로운 포탈기반의 어플리케이션을 작성함에 있어 기존에 기업이 보유하고 있는 데이터나 어플리케이션 로직, 서비스 등을 재사용한다.

-       검색, 협업, 웹퍼블리싱, 보안 등 어느 어플리케이션을 만들 때나 중복적으로 사용되어야 하는 기반서비스 들은 EP 프레임워크 단에서 제공되는 것을 재사용하여 중복투자를 방지한다.

-       이렇게 포탈과 한번 통합된 리소스는 다음 어플리케이션을 만들 때도 쉽게 재사용된다.

이러한 특징들에서 볼 수 있듯이 EP를 기반으로 한 어플리케이션 들은 해당 특정 목적의 어플리케이션을 구성하고 있는 거의 대부분의 서비스나 데이터를 이미 기업내부에 존재하거나 포탈 프레임워크에서 제공하는 것을 재사용하기 때문에 앞서 이야기 했던 EP를 도입하는 가장 큰 이유인 비즈니스 환경의 변화에 따라 다양한 전술/ 전략적 어플리케이션을 짧은 기간의 개발 기간을 거쳐 신속하게 제공받아 사업 기회비용을 최소화한다.”는 커다란 명제가 실현가능해지는 것이다.

자 그럼 A라는 기업에서 위에서 설명한 목표를 실현하기 위해 EP를 도입하려 한다고 가정하고 그들이 현실적으로 겪는 어려움을 이야기 해 보자.기업의 검토 담당자는 일단 기초적인 정보수집 차원에서 EP라는 솔루션이 어떤 것들이 있는 지 시장조사를 해보지만 접촉하는 거의 모든 소프트웨어 벤더들은 모두 그들의 제품군 안에 포탈이라고 명명한 제품을 가지고 있었다.그 솔루션 들간의 차이점을 파악해보기 위해 검토 담당자가 생각해 온 몇 가지 기능 요구사항이 그들의 제품을 기반으로 하여 구현가능한지 문의해보지만 모든 업체가 다 가능하다고 이야기를 하고 있어 서로간에 어떤 차이점 들이 있고 어느 정도가 사실인지 파악할 수 없는 상황에 빠져든다.

좀 과장된 면이 없지는 않지만 위의 이야기는 현재 포탈을 검토하고 있는 기업들에서 흔히 겪고 있는 현실을 이야기한 것이다.

왜 이런 혼란이 생기는 걸까?다른 소프트웨어들을 검토할 때는 특정 목적 별로 솔루션들이 구분되어 있어 선택할 때 혼란이 적었는데 왜 포탈 솔루션은 이렇게 다양하고 그게 다 그것 같아 보이는 걸까?

그 첫 번째 이유는 엔터프라이즈 포탈이라는 컨셉이 내포하고 있는 개념의 방대함이다.엔터프라이즈 포탈은 결국 기업이 보유하고 있는 많은 IT자원들을 통합하고 이 통합된 서비스를 조합하여 새로운 어플리케이션을 만들어내는 기반이기 때문에 기업의 모든 IT자원과 직, 간접적으로 관련성을 지닌다.예를 들면, 오늘의 주된 주제로서 설명하려고 하는 SSO, KMS, Workflow, Content Management 등이 결국 이 엔터프라이즈 포탈이라는 것에 통합이 되어 새로운 어플리케이션을 만들어내기 위한 부속품으로 활용되기 때문에 엔터프라이즈 포탈 자체가 SSO처럼 보이기도 하고, Content Management System의 성격도 가지고 있는 것 같기도 하고, Groupware의 기능도 하는 것으로 생각이 들 수 있는 것이다.

이러한 혼란을 부채질하고 있는 또 하나의 원인은 요즘 거의 모든 소프트웨어 회사들이 자신들이 원래 주력으로 삼고 있던 기업용 소프트웨어의 사용자 인터페이스를 포탈과 비슷하게 변경하여 제공을 하면서 제품명을 “XX포탈등의 형식으로 바꾸었거나, 포탈과 비슷한 사용자 인터페이스를 구현하는데 사용되는 소프트웨어 컴포넌트를 기존 소프트웨어 제품군에 포탈이라는 이름으로 추가적으로 포함시켰기 때문이다. KMS (지식관리시스템)를 예로 들어 보자.이 기업용 소프트웨어는 원래는 기업에서 생성되는 지식을 효과적으로 분류, 관리하기 위한 목적으로 개발된 제품이며 기본적으로 엔터프라이즈 포탈과는 기능상의 유사점이 거의 없는 소프트웨어이다.하지만 근래 들어 기업들이 포탈에 많은 관심을 갖게 되면서 이러한 지식관리소프트웨어의 사용자 인터페이스의 일부분을 포탈과 비슷하게 만들어서 제공하면서 이름을 “XX지식포탈로 개명하여 마케팅을 하고 있다.이러한 솔루션의 사용자 인터페이스만을 보면 엔터프라이즈 포탈의 그것과 너무도 유사하기 때문에 전문가들이 아닌 다음에야 겉으로만 봐서는 이것이 진짜로 자신이 원하던 포탈 솔루션인지 아닌지를 구분하기가 어려워지는 것이다.

이번 호에서는 엔터프라이즈 포탈과 흔히 관련되는 여러 가지 기업용 소프트웨어들을 살펴보고 이렇게 현재 시장에서 복잡하게 얽혀있는 솔루션 들의 상호 관련성, 보완성, 및 차이점을 설명하여 기업이 자신의 비즈니스적 문제를 해결을 하려 할 때 솔루션 선택의 가이드라인을 제시하고자 한다.

Portal & SSO (Single Sign On)

엔터프라이즈 포탈을 검토하는 고객들이 가장 기본적으로 생각하는 단위기능 중 하나가 바로 한번의 로그인을 통해 자신이 사용할 수 있는 모든 사내 시스템을 사용하도록 해주는 싱글사인온 (앞으로는 SSO로 표기) 기능이다.

물론 이러한 SSO이라는 것은 하나의 개념이기 때문에 이를 구현하는 데 특별히 어떠한 소프트웨어가 필수적으로 필요한 것은 아니며, 소프트웨어 패키지 없이도 어느 정도의 개발을 통해 구현할 수도 있고 또 국내에도 실제로 이런 방식으로 구현한 기업들을 몇 차례 경험해 본적이 있다.이렇게 개발을 통해 SSO을 구현한 기업들은 대부분 디렉토리 서버 (Directory Server)를 사용하여 사용자 정보를 한군데로 통합하고 사내의 어플리케이션에 접근 시 이 디렉터리 서버에 있는 사용자의 정보를 참조하여 해당 어플리케이션을 접근할 수 있는지를 판단하도록 해주는 방식으로 구현된 경우가 많다.이렇다 보니 이러한 디렉터리 서버가 SSO기능 자체를 수행해 준다고 오인하고 있는 사람들이 있는 데 이것은 잘못 알려진 내용이다. 실제 Directory Server는 일종의 데이터베이스일 뿐이다.단지 관계형 데이터베이스와는 그 구조가 다르고 정보 저장보다는 정보 검색에 특화된 설계구조 (Schema) 갖고 있는 데이터보관소 기능에 국한된 것이다. 이 정보를 참조하여 타 어플리케이션들에 대한 인증을 처리하고 SSO을 가능하도록 해주는 것들은 추가적으로 자체 개발하여 구현된 경우도 있고, 아예 이를 위해 전문 SSO 패키지를 구매하는 경우도 있다.물론 전문 팩키지를 사용하는 경우에도 디렉터리 서버와 같은 통합된 사용자 정보 보관소가 필요하고 또 일반적으로 함께 구현되는 경우가 대부분이다.

그러면 대부분의 SSO 패키지들이 공통적으로 가지고 있는 구조를 한번 살펴봄으로써 그 실체를 파악해보자.다음의 그림은 SSO 솔루션의 구조를 단순화하여 나타낸 것이며 어느 특정 제품을 표현했다기 보다는 상당히 일반화를 하여 그 구조를 설명하고자 한 것이다.


그림 1) 일반적인 SSO 솔루션의 구조

위의 그림에서 볼 수 있는 것처럼 SSO 솔루션은 주로 다음의 3가지 작업을 수행한다.

1. Authentication: 사용자가 진짜인지 그 진위여부를 가려낸다. (Are you who you say you are? - Authentication Server에서 수행)

2. Authorization: 사용자가 접근하려고 하는 자원에 해당 사용자가 권한이 있는 지 판단 (Are you allowed to access what you are trying to access? - Policy Server에서 수행)

3. SSO 토큰 (Token) 생성: SSO Interceptor가 현재 접근한 사용자가 인증 받은 사용자인지를 판단하는 기준인 SSO 토큰을 생성하고, 필요할 경우 여기에 부가적인 사용자의 정보를 추가적으로 담아 SSO 솔루션이 보호하고 있는 뒷 단의 어플리케이션에 추가적인 사용자 정보를 전달한다.

다시 설명하면 SSO 솔루션은 보호가 필요한 웹사이트 (즉 웹 서버의 특정 디렉토리)에 대하여 대개 ISAPI (Internet Server API)NSAPI (Netscape Server API)형태로 되어 있는 Interceptor (또는 필터라고도 함)를 올려놓고 이 Interceptor에서 토큰의 존재여부를 판단하여 토큰이 있으면 요청 리소스에 엑세스를 허용하고, 토큰이 없으면 인증창으로 퉁겨내어 인증을 받기 전에는 해당 리소스를 사용할 수 없게 하는 구조로 구현되어 있다.물론 각 솔루션 업체들마다 약간의 기능, 성능의 차이는 보이지만 대체로 이러한 구조를 공통적으로 가지고 있는 것이 일반적이다.

그럼 포탈과 SSO솔루션의 관계는 무엇일까?포탈만 사용해서 SSO을 구현할 수 있을 까?만약 그것이 사실이라면 포탈은 SSO 솔루션의 기능을 포함하고 있는 것인가?

결론적으로 말하면 포탈은 SSO 솔루션의 기능을 포함하고 있지는 않다.업체별로 하나의 제품군으로 SSO솔루션을 포탈과 같은 제품군에 포함시켜 놓은 경우는 있지만 두 가지 솔루션은 그 목적이 전혀 다른 솔루션이다.물론 포탈 소프트웨어만 가지고 포탈과 통합된 서비스나 어플리케이션들에 대하여 SSO을 구현하는 경우도 있지만 이는 SSO 솔루션을 사용하여 구현했을 때와는 그 구조가 다르며 일반적으로 권유하는 방법은 아니다.

그럼 SSO과 포탈은 어떤 관계가 있을 까?

포탈은 SSO 솔루션 입장에서 보면 그가 보호하는 많은 웹사이트 중 하나의 웹사이트일 뿐이다.

이를 이해하기 위해 다음의 그림을 보자.

그림 2) 포탈과 SSO 솔루션의 관계

SSO 솔루션은 자신이 보호해야 하는 웹 리소스 (웹 서버)들 상에 탑재되어 그 웹사이트에 대한 접근을 허가한다.더 정확하게 말하면 사용자는 SSO 솔루션을 통과하기 전에는 자신이 요청한 URL에 물리적으로 액세스 할 수가 없다.앞에서 설명한 토큰을 가지고 있는 클라이언트가 자신이 액세스할 권한이 있는 웹 리소스에 접근하여 할 경우에는 SSO 솔루션이 해당 요청을 통과시키며 그때가 되서야 그 해당 리소스에 물리적으로 접근한 것이다.포탈은 이렇게 SSO 제품이 보호하는 여러 개의 웹사이트 중 하나일 뿐이다.위의 그림에서 보듯이 노란색 포탈 웹사이트와 주황색 다른 웹사이트를 접근하기 위해서는 공통적으로 SSO 제품을 먼저 통과해야 한다.그때 필요한 것이 SSO 토큰이며 이는 그림의 파란색에 노란색 번개모양으로 그려져 있는 것들이다.보통 웹사이트와 포탈이 SSO 솔루션과의 통합에 있어 다른 점은 엔터프라이즈 포탈은 이 포탈에 통합된 뒷단의 많은 웹 리소스에 대해서도 같

SSO 기능이 제공되어야 하기 때문에 자신이 받은 SSO 토큰을 자신의 뒷단에 있는 웹 리소스 들에 전달해 줄 수 있는 기능을 가지고 있는 것이 차이점이라면 차이점이라고 할 수 있다.

Portal & EAI (Enterprise Application Integration)

엔터프라이즈 포탈이 시장에서 알려지기 시작하면서 이를 도입하고자 하는 기업들이 가장 혼란을 많이 겪었던 것 중의 하나가 포탈과 EAI가 어떻게 틀린 것이며 어떤 관련이 있는 지에 대한 것이다.

실제 포탈 시장 초기에는 EAI 벤더들을 중심으로 엔터프라이즈 포탈을 구현하려면 필수적으로 EAI를 먼저 수행해야 한다는 주장이 있기도 했다.이것이 사실일까?대답은 그렇지 않은 경우가 대부분이다.”라는 것이다.

EAI에 대하여 살펴보자. EAI라는 개념도 상당히 방대한 것이기 때문에 그 정의에 따라 상당한 차이가 있을 수 있으나 EAI 솔루션 들이 제공하는 주된 기능은 기업이 보유하고 있는 서로 상이한 다양한 어플리케이션이나 데이터베이스 사이에 서로 메시징을 할 수 있는 버스 (Bus)를 구현하는 것을 뜻한다.

그림 3) EAI 시스템의 구조

예를 들면, 기업의 인터넷 쇼핑몰을 통하여 카메라가 하나 판매되면 이 이벤트를 회계 시스템에서 받아서 매출로 기록하고 Inventory시스템에서는 재고를 하나 줄이는 일련의 작업이 자동화될 수 있다.물론 이러한 작업이 가능하기 위해서는 EAI 솔루션이 제공하는 메시징 버스의 표준에 맞도록 각 어플리케이션이나 데이터베이스의 정형화 (Normalization)과정을 거쳐야 하기 때문에 많은 비용이나 노력이 소요되는 것이 일반적이다.이러한 작업을 통하여 얻을 수 있는 부가적인 효과는 이 Message Bus에서는 일반적으로 웹 인터페이스를 제공하기 때문에 해당 버스와 통합된 어플리케이션이나 데이터를 웹단으로 끌어낼 수 있는 방법을 제공한다는 것이다. 가끔 EAI 벤더들이 기업이 가지고 있는 웹으로 구현되지 않은 어플리케이션의 웹화 방안으로 EAI솔루션을 제안하는 것이 이러한 이유 때문이다.하지만 역시 EAI 솔루션의 주된 기능은 서로 다른 다양한 시스템을 묶어 하나의 큰 줄기의 프로세스를 만들어 내는 데 있다고 할 수 있다.

그림 4) EAI 솔루션을 사용하여 구현한 여러 다양한 시스템을 통합하는 프로세스

엔터프라이즈 포탈을 구축함에 있어 EAI 솔루션이 필요한 경우는 위에서 보는 경우처럼 여러 상이한 시스템을 아우르는 프로세스를 포탈상에서 구현해야 할 경우에 한정되며 이러한 프로세스는 대부분 사용자들의 간섭이 없는 상태로 자동화되는 경우가 대부분이기 때문에 포탈에서는 이러한 프로세스를 일으키는 트리거 포인트나 결과 모니터링 화면만 통합이 되는 경우가 대부분이다.하지만 포탈을 구현함에 있어 이렇게 여러 시스템을 아우르는 복잡한 프로세스가 필요한 경우는 극히 제한적이며 많은 경우 전혀 필요 없는 경우도 많은 것이 사실이다.

결론적으로 얘기하면 EAI 솔루션을 사용하여 통합된 새로운 형식의 프로세스 (위의 그림과 같은)는 포탈과 통합되는 수많은 서비스 들 중의 일부이며 포탈 상에서 구현되는 업무 어플리케이션의 성격에 따라서는 전혀 필요 없는 경우도 있다.아래의 그림은 포탈과 EAI 솔루션과의 관계를 도식화하여 설명한 것이다.

그림 5) 포탈과 EAI

Portal & KMS (Knowledge Management System)

지식경영에 대한 필요성이 대두되면서 소프트웨어적으로도 이를 뒷받침하기 위한 많은 시도가 있어왔고 국내에서 이러한 시도의 결과물로서 대두되게 된 것이 바로 KMS라는 솔루션이다.물론 KM (Knowledge Management)이라는 것은 소프트웨어가 아니라 문화적인 측면이 더 중요한 것이 사실이지만, 보다 효과적으로 이러한 문화정착을 활성화하기 위해 IT기술을 접목한 것이KMS라고 할 수 있겠다.

품질이 높은 지식을 쉽게 등록하고 조회 할 수 있게 하고 또 그에 대한 평가를 통해 이를 활성화한다는 것이 기본적인 개념이며 이를 위한 일련의 지식 Screening 과정 및 분류체계, 지식등록 시 보상체계 등을 소프트웨어 적으로 관리할 수 있도록 구현한 것이 KMS시스템이라고 보면 되겠다.

이렇다 보니 이 시스템이 성공하기 위한 필수적인 조건은 앞으로 지식으로 분류될 만한 모든 컨텐츠 들은 KMS에 입력해야 한다는 데 있다.지금까지 현존해온 시스템에 있는 컨텐츠 중 지식으로 분류될 만한 데이터는 데이터 마이그레이션을 통해 KMS로 옮겨오고 앞으로 생성될 새로운 지식은 꼭 KMS에서 입력하자는 것이다.어떻게 보면 기업의 문서들을 체계적으로 관리하기 위해 중앙 집중적인 Document Management System (DMS)를 사용하는 것과 비슷한 개념이라 하겠다.

그럼 KMS와 포탈은 어떤 관련이 있을 까?많은 분들이 벌써 짐작하고 있겠지만KMS는 포탈에 지식이라는 컨텐츠를 제공해주는 하나의 통합대상이 되는 서브시스템이다.

사용자 입장에서 생각해보자.내가 어떤 정보를 게시판에 올리려고 한다.이러한 경우 내가 지금 올리려고 하는 컨텐츠가 단순 정보인지 지식인지를 판단하여 올릴 곳을 정한 후 그 해당 시스템에 입력해야 한다면 그 효율성이 과연 높아질까?

어떤 사용자가 정보를 찾으려고 한다.내가 찾는 정보가 단순 정보인지 지식인지 아니면 회계 어플리케이션 내에 저장되어 있는 현황 데이터 인지를 사용자가 일일이 판단하여 해당 시스템에 가서 조회를 해야 한다면 과연 

그 서브시스템들의 효용성이 높아질까?

이 두 가지 문제점을 포탈은 서브시스템의 종류에 상관없이 업무별 또는 목적 별로 조합형 어플리케이션을 만듦으로써 해결한다.사용자는 정보의 종류는 신경 쓸 수도 없고 신경 써서도 안된다.사용자는 그가 처리하고자 하는 업무에 관련된 중요한 정보, 지식, 컨텐츠 등을 하나의 논리적인 업무 어플리케이션에서 제공받고 해당 업무 어플리케이션을 구성하고 있는 단위 서비스들은 사용자의 액션에 따라 각기 자신의 레포지터리 (Repository)에 데이터를 저장하고, 그 레포지터리로부터 조회를 한다.이런 모든 과정은 사용자에게는 블랙박스형태로 표출되며, 사용자는 자신이 현재 입력한 데이터가 어느 시스템에 저장이 되며 나중에 조회를 할때는 어디로부터 해야 하는지를 전혀 신경 쓰지 않는 상태에서 업무를 처리하게 된다.왜냐하면 그가 데이터를 입력하고 조회하기 위해 접근하는 단 하나의 어플리케이션은 포탈을 기반으로 이러한 서브시스템들의 서비스들을 조합하여 만들어낸 새로운 형태의 업무 어플리케이션이기 때문이다.이러한 개념을 시장 조사 기관인 Gartner사에서는 Composite Application 또는 Service-oriented Application (SOA)라는 이름으로 명명하고 이를 새로운 어플리케이션 패러다임으로 소개하고 있다.이에 대한 자세한 설명은 지난호에서 자세히 설명한바 있다.

Portal & Groupware

흔히 그룹웨어를 기반으로 한 포탈을 얘기하는 경우가 있다.위의 지식관리시스템에 포탈 사용자 인터페이스를 입힌 경우와 비슷한 경우라고 할 수 있는 데 그룹웨어에서 다른 시스템들을 접근할 수 있는 링크를 모아서 제공하거나 가끔은 다른 어플리케이션의 화면도 포탈과 비슷한 형식으로 보여주는 경우도 있다.

한국 기업에 구축된 그룹웨어를 분석해 보면 많은 경우 불필요하게 비대해진 경우가 많다.다른 시스템에 대한 접근 통로뿐 아니라 목적, 업무별 공지, 게시판 등 그 업무의 복잡도에 비례하여 그룹웨어 시스템도

본연의 목적에서 벋어나 다른 목적으로 전용된 경우가 많다.왜 이런 일이 생겨났을 까?

그 이유는 그룹웨어가 기업의 전직원이 공통적으로 매일 접근하는 몇 안 되는 공간이기 때문이다. 전사적인 범위의 정보전달 매체로서 그룹웨어를 대체할 만한 특별한 대안이 없었기 때문에 그룹웨어가 필요에 따라 비대해지기 시작했고 그룹웨어를 이런 식으로 몇 년 정도 운영해온 기업들은 속도 저하, 정보의 산재 등의 어려움을 겪게 된다.본인의 게시물을 올려야 하는데 너무 게시판의 종류가 많다 보니 어디에다가 올려야 할 지 모르고, 그러한 콘텐트를 조회하는 사람들도 어느 게시판에 그 종류의 콘텐트가 올라올지 잘 모르는 상황이 되어버릴 정도로 정보 전달 통로의 심각한 왜곡이 있는 것이 현실이다.

이러한 문제는 그룹웨어가 포탈의 역할을 하려 했기 때문에 생겨나는 문제점 들이다.그룹웨어는 포탈에 그룹웨어가 제공하는 본연의 서비스 (메일, 결제, 수신문서 등)만을 제공하는 서브시스템일 뿐 포탈의 도입 목적인 다양한 업무별, 목적별 어플리케이션 구현 및 관리에 좋은 솔루션은 아니기 때문이다. 포탈 시스템이 제공하는 유연성은 그룹웨어를 이용하여 비슷한 목적을 이루려 했을 때 발생하는 문제점들을 근본적으로 해소해준다.

이 때문에 그룹웨어를 기반으로 포탈을 구현했던 많은 기업들이 다시 엔터프라이즈 포탈 솔루션을 도입하여 예전의 그룹웨어는 메일, 결제, 수신문서의 본연의 기능만을 남기고 나머지 역할은 모두 새로운 포탈로 옮기는 작업을 수행하게 된 것이다.

Portal & Search

포탈에 있어 검색은 필수적인 요소이다.검색이 없는 포탈이라는 것은 상상할 수도 없다. 포탈이라는 것이 기업이 가지고 있는 많은 서비스와 정보를 통합한 것이다 보니 그 종류와 양이 방대해 지게 된다.이를 효과적으로 사용자들이 찾아 쓸 수 있도록 해주는 것이 검색이다.

흔히 통합검색엔진이라는 이름으로 불리는 전문 검색엔진을 이용한 프로젝트는 문서들에 초점을 맞추게 된다.여러 시스템에 흩어져 있는 문서 및 콘텐트를 한번의 검색으로 모두 찾아주는 것이 그것이다.

하지만 포탈에서의 검색은 여기에 몇 가지가 더 추가된다.포탈에는 문서만이 통합되는 것이 아니기 때문이다.포탈에 통합되는 단위서비스들, 포탈을 기반으로 구현된 조합형 어플리케이션 들, 포탈을 사용하는 사용자 등 포탈에 통합된 모든 자원을 검색할 수 있어야 진정한 의미의 엔터프라이즈 검색일 수 있다.

따라서 엔터프라이즈 포탈 도입을 검토하는 기업들은 검색기능이 포

탈과 얼마나 타이트하게 통합되어 있는 지 확인하는 과정을 꼭 거쳐야 한다.문서만 검색하는 것은 기업이 가지고 있는 리소스 중 일부만을 포함하는 부분적 접근이기 때문이다.

Portal & Content Management, Portal & Collaboration

포탈에서 필요로 하는 여러 가지 기반서비스들 중에 대표적인 것이 컨텐츠관리와 협업기능이다.

기업 내외부에서 생산되는 각종 타입의 디지털 컨텐츠의 라이프사이클을 관리하는 CMS (Content Management System)은 크게 컨텐츠의 생성과 컨텐츠의 제공 (Delievery)을 관리하기 위한 솔루션이다.

1980년대 중반 무렵 소개되기 시작한 문서관리 (Document Management)에서 시작된 이 솔루션은 웹이라는 새로운 형태의 강력한 Delivery 채널이 부각됨에 따라 웹 페이지 형식의 컨텐츠를 관리하기 위한 Web Content Management의 영역으로 발전을 거듭해왔으며, 근래에는 웹 페이지 뿐만이 아니라 다양한 형태의Rich Media (동영상, 음성 등)까지도 그 영역에 포함시키고 있다.따라서 이러한 문서, 웹 컨텐츠, Rich Media 등 기업이 생성하고 사용하는 모든 컨텐츠를 관리할 수 있는 솔루션을 일컬어 엔터프라이즈 컨텐츠 관리 시스템(Enterprise Content Management System)이라고 한다.

그림) 엔터프라이즈 컨텐츠 관리 시스템의 구성요소

엔터프라이즈 포탈에서도 다양한 디지털 컨텐츠 들이 사용된다.그 중에서도 가장 대표적인 것이 웹 페이지 형식의 컨텐츠 들인데 CMS를 활용하면 이러한 컨텐츠 들이 생성되는 과정을 중앙에서 관리하여 정보가 퍼블리싱 되기 전 단계에서 컨텐츠의 내용 및 사용자 인터페이스 등의 품질 적합성을 확인할 수 있어, 현업에서 직접 컨텐츠를 작성하도록 할 수 있다.

이렇게 엔터프라이즈 포탈을 기반으로 만들어지는 업무별, 목적별 조합 어플리케이션 들에 이러한 CMS의 서비스를 사용함으로써 비즈니스 유저들이 직접 컨텐츠 생성에 참여할 수 있는 길을 제공해주는 것이다.

하지만 CMS도 역시 기업이 가지고 있는 많은 정보 모두를 관리할 수는 없다.아무리 CMS를 전사적으로 이용한다고 해도 이러한 디지털 컨텐츠 이외의 정보나 프로세스는 여전히 기존 어플리케이션이나 배후 시스템들에 남게 된다.결국CMS도 포탈과 통합되어 부분적인 서비스를 제공하는 부품일 뿐 엔터프라이즈 포탈의 역할을 대신할 수는 없는 것이다.

협업 (Collaboration) 소프트웨어는 사용자 들이 온라인 상에서 서로 함께 일을 할 수 있도록 도움을 주는 서비스 들을 제공해주는 기능성 어플리케이션의 집합이다.

이 중에는 일반인들도 친숙한 인스턴트 메신저나 게시판 등의 서비스뿐만 아니라 화상회의, 전자칠판, 프로젝트 관리 등 제품에 따라 다양한 형태의 기능들을 제공하고 있다.

그림) 협업 솔루션의 예

이런 협업 서비스 들은 엔터프라이즈 포탈 구현에 있어 상당히 중요한 기능을 제공한다.요즘 업무 어플리케이션 들은 단순 정보 조회뿐만이 아니라, 해당 주제의 업무를 중심으로 함께 온라인 상에서 작업을 할 수 있는 공간을 제공해 주어야 하기 때문이다.예를 들어, 세일즈맨의 업무 지원을 위한 Sales Productivity Application이 있다고 하자.이 어플리케이션 내부에는 세일즈맨 들이 보아야 할 상품 정보, 고객 정보, 매출 정보 등의 정보도 제공을 해주어야겠지만 세일즈맨 들이 서로 또는 전문가에게 상품에 대하여 물어보고 의견을 교환할 수 있는 게시판 형태의 서비스가 없으면 아니 된다.엔터프라이즈 포탈을 기반으로 하는 어플리케이션 작성시 이러한 협업을 위한 다양한 서비스를 제공하는 것이 Collaboration 소프트웨어이며 이 역시도 포탈에 통합되어 재사용되어야 하는 서브 시스템 중 하나이다.

이러한 CMSCollaboration의 두 가지 서비스는 어떠한 업무 어플리케이션을 구성을 할 때도 필수적으로 포함되는 것이 일반적이다.따라서 이렇게 기반이 되는 서비스들은 포탈 단에서 재사용이 쉬운 형태로 제공되는 것이 좋다.포탈을 검토하는 기업들은 이러한 기능들을 세부기능을 가지고 평가하는 것도 중요하지만 해당 기능이 얼마나 포탈과 타이트하게 통합이 되어 있는 지에 더 신경을 써야 할 경우가 많다.아무리 좋은 기능을 제공할 지라도 포탈과의 통합이 어렵다면 그 시스템은 재사용이 상당부분 제한될 수 있기 때문이다.

Portal & BPM (Business Process Management)

BPM(Business Process Management) 솔루션은 기업 내외의 업무 프로세스를 가시화하고, 업무의 수행과 관련된 사람, 시스템을 프로세스에 맞게 실행 / 통제하며, 전체 업무 프로세스를 효율적으로 관리하는 시스

템이다.

기업내부에는 수많은 비즈니스 프로세스가 존재한다.이러한 프로세스는 두 가지의 큰 형태로 구분될 수 있다.

1. Simple Workflow

2. Complex Workflow

1번의 경우에는 우리가 흔히 주변에서 볼 수 있는 형태의 프로세스이다.예를 들면 임직원이 휴가신청을 시스템을 통해서 하면 그 신청을 그 직원의 메니저가 승인하고 그 결과는 HR에 송부된다.이러한 간단한 워크플로우는 굳이 BPM 솔루션 기반으로 개발할 필요는 없다.물론 나쁠 것은 없겠으나 투자대비 효과로 볼 때 이렇게 단순한 프로세스를 위해 값비싼BPM 소프트웨어를 투자하는 것은 효과적이지 않다고 할 수 있겠다.

2번의 경우는 다르다.이 경우는 해당 비즈니스 프로세스가 일반적인 코딩의 형태로 구현되기에는 너무나도 변수가 많기 때문에 전문 솔루션 없이 구현했다가는 그 유지보수에 엄청난 비용을 초래할 수 있는 것들이다.

기업이 BPM 솔루션 도입을 검토해야 할 때는 2번의 경우이다.하지만 이 경우도 지금 현재의 프로세스를 그대로 시스템화 하기 보다는 프로세스 자체를 최적화 시킨 후에 이를 시스템화하는 것이 바람직하다.따라서 BPM 솔루션 구축은 기업의 업무 프로세스에 대한 정비가 동시에 진행되어야 그 진가를 발휘할 수 있을 것으로 생각된다.

그림) BPM 솔루션의 프로세스 모니터링 화면

이러한 BPM 솔루션과 포탈이 함께 구현이 되었을 때의 관련성은 다음과 같다.간단하게 말하면 BPM은 뒷단에 흘러다니는 프로세스의 과정을 관리하며, 포탈은 이러한 과정에 있어 각 사용자가 처리해야 할 작업 및 필요 어플리케이션에 대한 인터페이스를 제공하게 된다.즉 사용자는 자신의 업무 포탈에서 자신에게 할당된 작업을 확인하고 수행하게 되며 포탈은 이러한 사용자와의 상호작용이 필요한 부분만을 단위 서비스로 만들어 사용자에게 제공하게 되는 것이다.

아래의 그림은 미국의 회계관리를 규정하고 있는 Sarbanes-Oxley법안의 규정을 만족하고 있는 BPM과 포탈이 통합된 시스템의 예시도 이다.

그림) 포탈과 BPM솔루션이 통합된 모습

끝맺는 말

이번 호에서는 기업들이 엔터프라이즈 포탈 구축을 검토할 때 주로 겪게 되는 어려움 완화에 조금이라도 도움이 되고자 포탈 솔루션과 주로 혼동을 일으키는 여러 가지 기업용 소프트웨어 들과의 상호 관련성 및 차별성에 대해서 이야기를 했다.

다양한 기업용 소프트웨어에 대하여 이야기를 했지만 결론적으로 이러한 소프트웨어 들은 포탈에 통합이 되어 최종사용자에게 하나의 단위 어플리케이션이나 기능, 콘텐트의 형태로 제공될 단위 서비스 들을 제공하는 것이며, 엔터프라이즈 포탈은 이러한 단위 서비스들을 조합하여 비즈니스적 가치를 극대화 시킬 수 있는 새로운 형태의 업무 어플리케이션을 구현하고 관리하는 Service-oriented Application Framework인 것이다.

다음 호에서는 솔루션 이야기에서 조금 벗어나 실제 엔터프라이즈 포탈 프로젝트를 기획함에 있어 유의해야 할 여러 가지 유의점에 대해 설명할 것이다.


728x90
반응형

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

,