Cover Story / BPM 시장 분석
상태바
Cover Story / BPM 시장 분석
  • 승인 2005.12.05 00:00
  • 댓글 0
이 기사를 공유합니다

사람과 기술을 하나의 팀으로

경기침체로 인해 효율성 입증 … 비즈니스 프로세스 최적화가 가장 큰 동력

효과적인 BPM(Business Process Managment)은 사람과 프로세스, 그리고 애플리케이션을 통합함으로써 회사 내의 갭을 메워주고 이익을 높여 준다. 하지만 100곳이 넘는 업체들이 각자 서로 다른 비전을 제시하고 있기 때문에 파트너를 선정하기란 쉬운 일이 아니다. BPM이 회사를 위해 무엇을 할 수 있는지를 분석하고, 업체들의 동향을 살펴봤다.

비즈니스 펑션(business function)의 기반을 이루는 논리적인 프로세스라는 개념은 분명 당신의 가슴을 뜨겁게 달굴 것이다. 우리는 모두가 ‘비즈니스 부문’에 보다 깊이 참여하도록 고무돼 왔으며 윤곽을 잡는 프로세스는 왼쪽 두뇌가 좋은 사람들이 능력을 발휘할 수 있는 작업이기도 하다.
비즈니스 면에서 보면 프로세스란 직원이 채용됐을 때 일어나는 일에서부터 고객이 주문을 할 때 취해지는 단계에 이르는 모든 것을 결정한다. 일부 조직에서는 완제품을 만드는 데 수반되는 단계를 자동화해주는 맞춤 소프트웨어에 있는 자사 프로세스에 특허를 내기까지 했다.
문제는 비즈니스 프로세스가 코드와 마찬가지로 부풀려질 수 있다는 사실이다. 조직이 성장함에 따라 유행에 뒤떨어진 프로세스를 고수하다 보면 수익성이 떨어지게 될 것이다. 프로세스는 비즈니스의 역동적인 필요와 함께 발전할 수 있으며, 그렇게 돼야만 한다.
비즈니스 프로세스를 자동화하게 되면 멋지고 새로운 비즈니스 프로세스 관리 이행에서처럼 최적화와 합리화라는 근사한 선물을 받게 된다. 예를 들어 BPM을 가동시키기 이전의 탐색 단계에서 비즈니스는 각각의 프로세스에서 단계들을 정의해야 하는데, 여기서는 종종 중복과 비효율성이 나타나게 된다.
자동화는 또한 그 나라의 언어로 ‘비즈니스의 민첩성(business agility)을 지원하는’ 비즈니스 조건에 맞게 프로세스를 신속하게 바꿀 수 있도록 해준다. 사실 이 기사를 위해 실시한 독자 설문조사에서 어떤 요소들이 BPM 수용을 주도하고 있는지를 묻는 질문에 비즈니스 프로세스 최적화가 응답의 1위를 차지했으며, 일관성 보장과 조잡한 수동 자동화가 바로 그 뒤를 이었다.

프로세스 지향형
대부분의 BPM 스위트들은 프로세스 지향형이며, 웹서비스를 통해 모델링 툴, 팻 클라이언트, 포털 및 프로세스 엔진들 사이에서 정보를 공유한다. 이 모델의 이점으로는 재활용, 상호 운용성, 그리고 보다 빨라진 배치시간 등을 꼽을 수 있다.
프로세스 지향적인 사고는 최소한 산업혁명 만큼 오래된 것이다. 이것은 헨리포드와 같이, 제조 공정을 별개의 작업 단계로 해체한 다음 각 단계의 효율성을 측정해 극대화하고, 병목을 피할 수 있도록 충분한 자원만(당시에는 주로 인력)을 할당하는 방식의 이점을 깨달은 기업가들에 의해 만들어진 예술의 한 장르라고 할 수 있다. BPM에서와 마찬가지로 이 개념은 일을 무리없고 효율적으로 진행되도록 유지하고자 하는 것이었다.
보다 최근의 역사를 보면 1990년대 초반 이 프로세스는 리엔지니어링 붐을 타고 기업의 신임장을 얻었다. 당시 많은 기업내에서 부서들은 기반 프로세스로부터 분리된 데이터 관리라는 영토를 가진 영주로 보수적인 체제를 갖추고 있었다.
비즈니스 프로세스 리엔지니어링(BPR)은 구매, 어카운팅, 생산 플래닝 등과 같은 화이트컬러 영토에 프로세스 지향적 원칙들을 적용시킴으로써 이러한 형세를 바꾸고자 했다. 불행히도 BPR은 열망이 지나친 비용 절감으로 이어지는 경우가 많았다. 바이인(buy-in)을 확보하거나, 이행을 감독하거나, 혹은 결과를 튜닝하기 위해 높은 곳에서부터 수고를 거의 들이지 않고 새로운 프로세스들이 전해져 내려왔다. 과도한 인력 절감은 내부의 파워 문제를 야기시켰으며, 제품과 서비스 품질에서 갭이 생기고, 결과적으로 효율성의 수명이 짧아지게 됐다.
ERP(Enterprise Resource Planning), CRM(Customer Relationship Management), SCM(Supply Chain Management), 그리고 스탠드얼론 워크플로우 이행이 1990년대 중후반 뒤따라왔다. IT 기반 자동화가 등장했지만, 이것은 프로세스 차원이라기보다는 기능적인 차원에서였다. 이러한 자동화 저장 창고는 불가피하게 병목과 에러, 단절을 야기했다. 나아가 대형 애플리케이션과 워크플로우 시스템에 하드코딩된 자동화는 값비싸고 시간 소모적인 통합과 맞춤화된 코딩이 없이는 조정이나 채택이 불가능했다. 그렇다면 이제 무엇이 와야 할까?

비용 절감 사실 입증
90년대의 자동화는 오늘날 BPM 시장으로 꽃을 피우게 된 비옥한 토양을 만들었으며, 이 시장은 100개가 넘는 업체들로 구성된 산만한 영역이 통합을 시작함에 따라 매년 20%씩 성장하고 있다. 시장조사기관인 IDC에 따르면 2004년 10억달러 매출을 달성한 BPM 시장은 2009년에는 30억달러에 달할 것이라고 한다.
이 시장의 수요는 2001년과 2002년 경기침체가 계속되면서 비용절감과 생산성 향상을 위한 이니시어티브에 의해 주도됐다. BPM은 ERP와 같은 애플리케이션들이 남기고 간 갭을 메워주는 통합과 자동화를 이용해 프로세스 순환 시간을 단축시켜 주었다. BPM 시스템은 또한 프로세스를 모델링하고 변경할 수 있는 보다 빠르고, 유연하고, 덜 비싸며, 보다 비즈니스 친화적인 환경을 제공해 주었다.
가트너 애널리스트인 짐 사이너는 “경기침체로 인해 BPM이 비용을 절감해준다는 사실이 입증됐다”며 설문에 응한 50개 BPM 이행자들 중 95%가 성공을 거뒀다는 2004년의 한 연구 결과를 언급했다. 응답자들이 보고한 회수율은 평균 15%에 달했으며, 55%가 매 프로젝트마다 10만~50만 달러를 회수한다고 답했다.

커튼 뒤 이야기
BPM 이행의 심장은 프로세스 엔진(process engine)이다. 이 애플리케이션은 비즈니스 규정을 해석하고, 작업을 어디로 할당해야 하는지를 결정해 준다(이들이 직원용인지 아니면 다른 기계용인지). BPM 엔진은 또한 프로세스를 모니터링하고, 인간의 개입이 필요할지도 모르는 예외 상황을 주시하며, 문제가 발생하거나 진행이 너무 느려질 경우 적절한 사람에게 경보를 보낸다. 이 엔진은 또한 작동상의, 혹은 비즈니스 척도를 모니터링하며, 작업이나 활동 기간과 같은 정보를 챙기고, 조직에서 프로세스 흐름을 통해 생성된 매출과 자원 비용을 계산함으로써 각각의 작업에 가치를 연관시킨다.
이것이 너무 엄청난 의무처럼 들린다면 제대로 들은 셈이다. BPM 이행은 애플리케이션 인프라와의 통합을 필요로 할 뿐만 아니라, IT와 비즈니스 쪽 모두 참가자들의 협력도 또한 필요하다. 우리는 본사 비즈니스 애플리케이션 랩에서 9가지 BPM 스위트들을 테스트 해보고, 이들이 얼마나 잘 돌아가는지를 확인해 봤다.
포털과 팻 클라이언트는 둘 다 참가자들이 프로세스를 상호작동할 수 있는 인터페이스를 제공할 수 있으며, 웹서비스, JDBC, ODBC, 애플리케이션 전용 어댑터, 그리고 물론 IT 스태퍼들이 개발한 맞춤 코드 등 다양한 기술에 애플리케이션 인프라와의 통합이 지원된다. 사람들은 포털이나, 이보다 드물긴 하지만 팻 클라이언트를 통해 이들에게 할당된 작업과 상호작동함으로써 시스템을 통합시킨다.

미래의 물결
BPM 수용의 제1세대 물결을 자동화와 통합이라고 한다면(테스트한 모든 제품에서 이 기능들은 성숙한 상태였다), 오늘날에는 규정 준수, 비즈니스 및 애플리케이션의 민첩성, 그리고 최적화로 점점 초점이 옮겨가고 있다.
사베인 옥슬리 법안(Sarbanes-Oxley Act)과 바젤 II(Basel II)와 같은 규제들의 영향으로 회사에서는 재정보고와 기타 회사 결산에 중요한 영향을 미치는 코어 프로세스 부문에서 정책과 프로시저를 이행하기 위해 BPM으로 몸을 돌리고 있다. 이것은 BPM이 프로세스를 문서화 및 모델링하고, 명시된 정책과 프로시저를 적용시키며(규정에 의해 시행되는 것처럼), 일관성 있는 불간접 형태로 실행되고, 그 결과와 인간적인 예외 상황을 추적하도록 고안된 시스템이기 때문에, 당연한 현상이다.
비즈니스 민첩성을 추구한다는 점에서 BPM은 SOA (Service Oriented Architecture)와 유사한 점이 많다. 둘 다 변화하는 비즈니스 필요조건에 대한 보다 빠른 응답을 목표로 하고 있으며, 준수에서부터 시작하지만 합병과 인수, 그리고 제품과 서비스 소개도 또한 포함하고 있다. 사실 에반스 데이터(Evans Data)의 조사에 따르면 웹서비스 통합 애플리케이션의 53%는 비즈니스 프로세스에 해당하는 것이라고 한다. 이에 따라 SOA는 BPM을 위한 중요한 기반이 되고 있으며, 프로세스 서비스들을 보다 큰 종단간 프로세스들로 신속하게 모으고 조화시키는 역할을 해준다.
또 한 가지 목표는 프로세스 관리를 다른 BPM으로 연결시킴으로써, 프로세스 향상을 통해 전략적 성능의 목표를 달성하는 것이다. 예를 들어 제품의 품질을 향상시키는 게 가장 우선 과제라면, 프로세서 관리 이니시어티브는 비용 절감과 순환 시간 가속화보다는 품질적인 척도에 보다 초점을 맞춰야 한다.
프로세스에 성능 목표를 접목시키기 위해서는 BAM(Business Activity Monitoring) 기능이 필요한데, 여기에는 측정기준(metrics), 주요 성능 표지기(key performance indicators), 임원진 대시보드(executive dashboards), 그리고 고급 보고 기능들이 포함된다.
이번 테스트에서 시뮬레이션은 중요한 차별화 요소였다. 모든 제품에는 기본 프로세스를 통과할 수 있게 해주는 ‘플레이(play)’ 버튼이 있었지만, 인간과 시스템 자원 필요조건을 예측할 수 있는 보다 깊은 시뮬레이션을 제공하는 것은 몇 되지 않았으며, 프로세스의 인스턴스를 시작하고, 진지한 진단 및 비용 플래닝을 하게 해주는 것은 이보다 더 적었다.
그리고 이보다 중요한 것은 하나 이상의 프로세스를 동시에 시뮬레이팅하는 게 몇 개 제품외에는 거의 불가능에 가까웠다는 사실이다. 이것은 문제가 된다. 사람들이 하나의 프로세스에만 전념할 가능성은 없기 때문에 단 하나의 프로세스뿐만 아니라 같은 사람을 포함한 모든 프로세스를 시뮬레이팅하는 게 중요하기 때문이다. 이러한 한계로 인해 BAM과 이력 분석(historical analysis)은 용량 플래닝과 프로세스 최적화에 있어 훨씬 더 중요해진다.
업체들은 이러한 한계를 잘 알고 있으며, 가트너의 사이너에 따르면 BPM에서 이제 보다 심도 깊은 시뮬레이션과 시나리오 플래닝, 그리고 예측 가능한 분석 기능이 실현될 날이 가까웠다고 한다. 그는 “운영적 및 전략적 차원에서 대시보드가 있을 것이며, 의사결정 최적화를 둘러싼 전체적인 시장이 형성될 것”이라며, “두 개의 노란 주의등이 켜지고, 세 번째 프로세스에서 붉은 등이 켜진다면 어떻게 대응하겠는가? 시나리오 플래닝이 이런 상황에 미연에 대비해 규정을 만들 수 있도록 도와줄 것이다. 잘못된 의사 결정이 생명을 위험에 빠뜨릴 수 있기 때문에 이러한 원리들을 현재 적용시키고 있는 화학 공장도 있다”고 말했다.
마치 회사에서 사람들에게 보안을 강화하기 위해 비디오 카메라를 보도록 하는 것과 마찬가지로, 직원들에게는 이러한 대시보드를 감시하는 일이 점점 늘어날 것이다. 게다가 예외 상황이나 스레숄드 초과에 대한 경보와 통보 기능도 폭넓게 사용되고 있다.

업체간 경쟁 과열
현재 BPM 시장에 참여하고 있는 100군데가 넘는 업체들 대부분이 워크플로우에 뿌리를 두고 있거나 순수 참여 사업자들로 시작한 곳들이다. 하지만 최근에는 부분적으로 EAI(Enterprise Application Integration), 애플리케이션 인프라 및 가장 최근에는 ERP 업체들까지도 이 시장에 뛰어들고 있다.
순수 BPM 사업자들은 두 가지 종류가 있는데, 한 부류는 스스로를 변모시킨 곳들이고 다른 하나는 처음부터 BPM으로 시작한 곳들이다. 전자 그룹에는 파일넷(FileNet), 메타스톰(Metastorm) 및 스태프웨어(Staffware: 지난 해 팁코에서 인수해 프로세스 지향적 기술과 전문성을 한층 강화시킴) 등이 포함된다. 이들은 전용의 하드 코디드 방안에서부터 가장 중요한 BPM 표준인 BPEL(Business Process Execution Language)을 기반으로 한 표준 준수 방안과 느슨하게 짜여진 웹서비스 통합을 수용하는 쪽으로 모습을 바꾼 곳들이다. 그리고 후자 집단에는 퓨고(Fuego), 롬바르디(Lombardi) 및 새비온(Savvion)과 같이 자동화를 처리하는 확고한 방안도 기존에 없었으며, 워크플로우에서 비롯된 대부분의 BPM 시스템들에게는 있는 문서 및 콘텐츠 관리 능력도 또한 없는 업체들이 포함돼 있다.
전통적인 상식으로는 순수 혈통의 제품들(워크플로우에 뿌리를 둔 곳들)이 인간 대 인간과 시스템 대 시스템의 상호작동을 통합하고 있는 프로세스를 처리하는 데 가장 적합하다. 만약 이러한 프로세스들이 렘딩이나 클레임과 같은 양식 주도형의 콘텐츠 집약적인 활동이라면, 얼티머스(Ultimus)나 팁코(Tibco)와 같이 콘텐츠 리뷰와 승인 단계를 쉽게 처리할 수 있는 제품을 찾는 게 좋다.
순수 BPM 사업자들과 마찬가지로, 팁코, 비트리아 테크놀로지(Vitri Tech- nology) 및 웹메소드(Web Methods)와 같은 EAI 업체들도 또한 플랫폼 업체들에 의해서만 제공돼 오던 것들을 비롯해 다양한 툴들을 자신들의 BPM 스위트에 포함시킴으로써, 주요 애플리케이션 인프라와 애플리케이션 플랫폼간 간격을 메우는 데 일조하고 있다. 하지만 BPM으로 이동하는 데 있어서 이들의 도전은 비즈니스와 IT 사용자를 모두 지원하고, 프로세스 관리에 역점을 두는 데 있다. 이들의 뿌리는 통합만 가지고 IT를 지원하는 것이기 때문이다.
이들이 비즈니스 애널리스트를 골치 아프게 하지 않을 디자인, 모델링 및 규정 환경을 만든다는 사실은 중요하다. 이를 위해 팁코는 SOA 모델을 채택해 이것을 자체 기술에 곧바로 적용시켰다. 모델과 워크플로우는 비록 팁코의 통합 제품인 비즈니스웍스(BusinessWorks)를 이용해 이행 가능하지만, 이것이 필요하지는 않다. 스태프웨어의 서비스 사용을 통해 어떠한 서비스든 프로세스에 삽입될 수 있는 개방형 환경이 제공되기 때문이다.
회사가 다중 이기종 애플리케이션에 의존하고 있고 이미 통합 서버들이 가득하다면, 이 투자를 BPM으로 확장시키는 게 효과가 있을 것이다. 하지만 이번 테스트에서 우리는 통합이 장애가 되는 경우를 거의 발견하지 못했다. 사실 모든 제품은 문제없는 통합을 제공했다. 이번 테스트를 통해 우리는 통합 기술의 범용화(commoditization)에 대한 소문은 결코 과장된 게 아니었음을 확신할 수 있었으며, EAI 업체들이 자신들의 통합 기술을 활용한 BPM 기능을 내놓음으로써 추가 가치를 제공하는 데 열을 올리고 있다는 사실을 명백히 알 수 있었다.

역할 커지는 인프라 사업자들
우리가 만나 본 애널리스트들에 따르면, 대형 애플리케이션 인프라 사업자들, 즉 마이크로소프트, IBM, 오라클, 그리고 보다 소규모의 BEA 등은 순수 BPM과 시장을 균등하게 나눠갖고 있다고 한다. 하지만 가장 최근에 본지에서 실시한 BPM 설문조사 결과를 보면 이들 대형 사업자들이 기술을 개척하고 있다는 생각이 들 것이다. 580명의 응답자들이 IBM과 마이크로소프트, 오라클, 그리고 BEA를 (이 순서대로) ‘BPM 솔루션의 선두주자들’로 꼽았기 때문이다. 순서는 약간 다르긴 하지만 거의 같은 수의 응답자들이 BPM 배치용으로 고려하는 우선 업체들로 역시 같은 업체들을 꼽았다.
사실 이러한 애플리케이션 인프라의 거물들을 BPM 시장의 개척자라고 할 수는 없지만, 이들이 시장 성장을 저해하지는 않을 것이다. 그 기술이 신속하게 커모디티제이션으로 되고 있는 통합 사업자들과 마찬가지로, 애플리케이션 업체들도 신호 소리를 듣고 있으며, 애플리케이션 서버의 커모디티제이션을 체감하고 있다. IBM, BEA 및 오라클은 자신들의 애플리케이션 플랫폼에 투자해야 할 이유를 제공하기 위해 발빠른 움직임을 보이고 있으며, BPM은 이를 위해 잘 맞는 보완물이다. 하지만 이들의 이러한 작업과 인수로 인해 초점을 두는 분야가 달라진 것은 아니며, 모두가 여전히 개발자를 주 타깃으로 삼고 있다. 예를 들어 오라클은 콜랙사(Collaxa)로부터 BPEL 엔진을 확보했으며, 전적으로 써드파티 모델링 툴에 의존하고 있고, 자사의 이행이 개발자 지향적이라는 사실을 인정하고 있다. 모델링과 시뮬레이션은 파트너들의 몫으로 남겨진다.
이러한 전략은 애플리케이션 인프라 사업자들만의 것이 아니다. 몇몇 순수 사업자들도 우리에게 표준 기반 모델링으로 인해 팝킨 소프트웨어(Popkin Software: 최근 텔레로직에서 인수)나 IDS 스키어(Scheer)와 같은 일군의 니치 업체들이 생겨날 것이며, 이들은 모델링에 중점을 두고, 서비스 이행과 규정 엔진을 향상시키는 데 집중한 다음, 마지막에는 자신들의 전용 모델링 툴을 단계적으로 중단해 갈 것이라고 밝혔다.
애플리케이션 인프라 사업자들을 최종 후보자 명단에 올려 놓고 있는 사람들은 우리 독자들뿐만이 아니다. 포레스터 리서치(Forrester Research)에서는 이런 업체들이 3년 내에 BPM 시장에서 가장 큰 몫인 30%를 차지하게 될 것이라고 전망했다. 그 다음은 애플리케이션 플랫폼 업체들로 25%의 시장을 차지할 전망이다. 자사의 비즈니스를 SAP, 시벨, 오라클 및 피플소프트를 기반으로 구축한 고객들은 이런 업체에서 BPM으로 가는 또 다른 경로를 제공하고 있다는 사실을 알고 있어야 한다.
인프라 및 엔터프라이즈 애플리케이션 업체들이 2008년까지 시장의 절반 이상을 차지할 것으로 예상되는 것과 함께, BPM 순수 사업자와 애플리케이션 통합 업체에게는 각각 20%의 점유율이, 그리고 나머지 5%는 다른 업체들에게로 돌아갈 전망이다. 엔터프라이즈 IT에게는 많은 선택의 폭을 열어주는 흥미로운 지각변동이 될 것이다.

Executive Summary
BPM(Business Process Management)

다른 태양계에서 온 방문객에게 팝콘이나 땅콩 버터 샌드위치를 만드는 법을 설명해야 하는 곳에서 논리를 갖추는 연습을 해본 사람이라면, 프로세스를 구축해 본 셈이다. 실제 세계에서는 효율적이고 지속적으로 업데이트되는 비즈니스 프로세스가 회사의 성공을 좌우하는 초석이 된다.
BPM 소프트웨어는 애플리케이션 인프라와 인력 자원(IT와 비즈니스 쪽 모두) 사이의 통합을 매끄럽게 해준다. 하지만 100곳이 넘는 업체들이 각자 BPM 비전을 선전하고 있기 때문에 파트너는 현명하게 선택해야 한다. 본고 제1부에서는 BPM이 회사를 위해 무엇을 할 수 있는지를 분석하고, 업체들의 동향을 살펴봤다.
제2부 리뷰 코너에서는 각각의 제품들에 초점을 두고, 9개의 BPM 스위트를 위스콘신 주 그린베이에 있는 본사의 비즈니스 애플리케이션 랩에서 테스트해 보았다. 블루스프링소프트웨어, 컴퓨터어쏘시에이트, 퓨고, 롬바르디소프트웨어, 오라블, 페가시스템즈, 새비온, 팁코소프트웨어 및 얼티머스 등의 업체들이 NWC의 주문 입력 및 풀필먼트 프로세스를 자동화하는 일을 해야 하는 시험대에 올랐다.
테스트를 하는 과정에서 우리는 일종의 정신분열증을 경험해야 했다. BPM 스위트는 IT의 개입이 많지 않은 상태에서 비즈니스 사용자들에게 액세스가 가능해야 하기 때문에, 우리는 비즈니스 애널리스트와 IT 스태퍼의 역할을 번갈아 가며 했다.
퓨고의 BPM 스위트가 양족을 만족시키는 점에서 가장 좋은 모습을 보여 주었다. 우리는 다양한 변수에서 그 풍부한 시뮬레이션들을 만지며 오랜 시간을 보낼 수 있었으며, 강력한 표준 지원도 함께 했다. 오라클의 표준 기반 BPEL 프로세스 매니저는 이에 근접한 2위를 차지했으며, 감사 능력이 필요한 조직에게는 매력적인 선택이 될 수 있을 것이다.

비즈니스와 IT,둘 다 만족시켜라

통합 능력·표준 지원 집중 평가 … 퓨고 최고 점수

BPM 스위트는 비즈니스 프로세스를 자동화하고, 인간과 기계 사이에 협업을 제공한다. 이번 코너에는 9개 참가자들의 능력을 철저히 검토하기 위해 이들을 위스콘신 주 그린베이에 있는 본사의 비즈니스 애플리케이션 랩에서 테스트했다. 블루스프링소프트웨어, 컴퓨터어쏘시에이트, 퓨고, 롬바르디소프트웨어, 오라블, 페가시스템즈, 새비온, 팁코소프트웨어 및 얼티머스 등의 업체들이 NWC의 주문 입력 및 풀필먼트 프로세스를 자동화하는 일을 해야 하는 시험대에 올랐다.

목표: 생산성을 향상시키고, 참가자들에게 프로세스에 대한 통찰력을 주며, 운영적·재정적 영향을 줄일 수 있도록 프로시저를 최적화해 줄 전문가가 가까이서 실시간으로 모니터링을 할 수 있는 최소한 하나의 비즈니스 프로세스를 자동화하라.
테스트에 앞서: 비즈니스 프로세스 전문가(저쪽에 있는)와 IT 스태프(지하실에 숨어 있는)를 선택하고 일에 적합한 툴을 고르라(전화 오퍼레이터들이 대기하고 있다).

준비됐는가? 출발하자. 준비가 되지 않았다고 해도 당신을 탓할 수가 없다. BPM(Business Process Management)은 최신 게임 이름이며, 이것을 마스터하려면 많은 것들을 배워야 한다. 앞서 1부에서 BPM에 대해 설명하고 업체들의 동향을 살펴본 데 이어 본고에서는 이제 툴들을 본격적으로 평가해 보기로 하자.

9개 업체 참가
위스콘신 주 그린베이에 있는 NWC 비즈니스 애플리케이션 랩에서 우리는 9개 BPM 소프트웨어 업체들로 드림 팀을 구성했으며, 참가자는 각각 블루스프링소프트웨어(Bluespring Software), 컴퓨터어쏘시에이트(Computer Associates), 퓨고(Fuego), 롬바르디소프트웨어(Lombardi Software), 오라클(Oracle), 페가시스템즈(Pegasystems), 새비온(Savvion), 팁코소프트웨어(Tibco Software) 및 얼티머스(Ultimus) 등 이었다.
우리가 초대한 업체는 20군데에 달했지만 상당수가 자격 요건에 맞지 않았다. BEA시스템즈, 파일네트(FileNet) 및 마이크로소프트는 참가를 거절했으며, 후지쯔와 메타스톰(Metastorm)은 너무 늦게 도착했다. 그리고 애피안(Appian), 코디언트소프트웨어(Chordiant Software) 및 비트리아테크놀로지(Vitria Technology)는 관심만 표시한 채 소프트웨어는 보내지 않았다.
우리는 각각의 소프트웨어 패키지를 이용해 NWC의 주문 입력 및 풀필먼트(order-entry/fulfillment) 프로세스를 자동화했다. 그리고 제품들로 하여금 우리의 오라클9i 고객 및 주문 데이터베이스를 통합시키고, 주문 입력용으로 이메일과 쌍방향 웹 요청을 둘 다 이용해 고객 서비스 담당자 및 고객과 상호작동하도록 했다. 이러한 시나리오를 통해 우리는 여러가지 기술처럼 보이는 제품들부터 다양한 사양과 기능성을 평가해 볼 수 있었다.
테스트를 하는 동안 우리는 IT 스태프와 비즈니스 애널리스트의 역할을 둘 다 했다. IT 쪽 사람으로는 플랫폼 지원, 아키텍처, 관리 능력, 그리고 애플리케이션 인프라와의 통합 및 아이덴티티 관리 시스템 등과 같은 사양들을 평가했다. 한편 비즈니스 애널리스트로서는 보고와 분석 기능, 그리고 프로세스 소유자가 프로세스를 모델링하고 시뮬레이팅하는 데 있어서의 편의성을 검토해 보았다.
우리는 워크플로우와 EAI(Enterprise Application Integration) 모두 유사성이 있다고는 했지만 그렇다고 오해해서는 안 된다. BPM은 결코 EAI나 워크플로우를 강화시킨 버전이 아니다. 비록 두 가지의 모두의 이점을 취하고 있긴 하지만, 성공적인 BPM 전략을 위해서는 이들에게는 없는 사양과 기능성이 필요하다. 이러한 차별 요소들로는 시뮬레이션, 보고 및 분석, 프로세스 관리, 모델링 및 규정 관리 등이 있다.

크로스 펑셔널(cross-fundtional) 전략
기업의 애플리케이션을 통합시키고 기존의 인프라 투자를 활용하지 못한다면 BPM을 달성할 수 없다. 우리 배치는 스탠드얼론이었지만 우리는 기업의 선택을 제한할 수 있는 구조적인 선택을 주의해서 보았다.
블루스프링의 BPM 스위트를 제외한 모든 제품은 다중 관계형 데이터베이스 관리 시스템을 모델과 측정기준을 위한 저장소로 활용할 수 있으며, 테스트에서 우리는 오라클이나 SQL 서버를 사용했다.
애플리케이션 서버 지원도 또한 포괄적으로서, 블루스프링을 제외한 모든 참가자들이 IBM 웹스피어(WebSphere)와 BEA 웹로직(WebLogic)을 지원했다. 블루스프링의 경우는 닷넷 기반 아키텍처로 인해 마이크로소프트의 IIS와 닷넷 프레임워크 1.1(.Net Framework 1.1)에 의존하며, 얼티머스는 스탠드얼론 윈도 기반 서버를 이용한다.
피플소프트, SAP 및 시벨과 같은 엔터프라이즈 애플리케이션과 RDBMS와의 통합은 매우 일상화돼 있다. 잘 정의된 API는 액세스를 제공하며, 많은 소프트웨어 업체들이 엔터프라이즈 애플리케이션 통합을 간편한 것으로 만들어 주는 사전 구축된 어댑터를 제공하고 있다. 그리고 이런 제품들 사이에서 가장 큰 차별화 요소 가운데 두 가지로는 어댑터의 가용성과 가격을 꼽을 수 있다. 오라클과 얼티머스, 그리고 롬바르디는 추가요금 없이 모든 어댑터를 포함시켰지만, 팁코를 비롯한 다른 업체들은 어댑터당 7만5천달러까지 나간다. 우리는 가격이 추가된다고 해서 기능성이 더해지는 것은 아니라는 사실을 알 수 있었다.
데이터베이스 어댑터 구성은 블루스프링 제품에서만 문제가 있었다. 블루스프링의 BPM 스위트는 마이크로소프트 SQL 서버로 연결될 때는 문제가 없었지만, 오라클9i 데이터베이스로 연결을 시도하자 막혀버렸다. 가장 마음에 드는 통합 메커니즘은 퓨고 BPM이 제공한 것으로, 여기서는 자바의 내성적인(introspective) 능력을 이용해 다른 시스템으로 연결되었다. 일단 오라클9i용 접속성을 제공하는 ojdbc14.jar 파일을 지정하자 퓨고BPM은 즉시 우리가 프로세스 안에서 쉽게 사용한 ‘객체(odject)’를 만들었다.
컴퓨터어쏘시에이트의 클레버패쓰 에이온 비즈니스 프로세스 매니저(CleverPath Aion Business Process Manager)는 모든 어댑터에 대한 코딩을 필요로 했다. 하지만 퓨고BPM이 우리 오라클 데이터베이스용의 범용 어댑터를 만든 곳에서는, CA의 아이온 r10이 우리 RDBMS와의 통합을 지원하게 하기 위해 개발자들을 휴게실에서 끌어내 각각의 질의에 맞는 코드를 쓰도록 해야 했다.
하지만 일부 J2EE 제품들(새비온 롬바르디, 오라클 및 퓨고 제품)은 다른 통합 방안을 제공했다. 즉 이들은 이것을 J2EE 컨테이너의 몫으로 넘겼다. 제품이 배치될 기존의 애플리케이션 서버가 어떤 것이든(웹 스피어와 BEA 웹로직 등) JDBC 데이터 소스로 구성이 된다는 가정이 정확하다면, 이들 제품은 이런 애플리케이션에 원래 있는 접속 풀링(connection-pooling) 기능의 혜택을 누릴 수 있으며, JNDI(Java Naming and Directory Interface) 이름만 지정하면 되는 통합을 제공한다. 우리는 이것이 마음에 들었는데 그 이유는 우리 인프라와 기술력을 사용하고 우리의 BPM 이행용으로 별도의 어댑터를 구입할 필요를 덜어줌으로써 TCO를 낮췄기 때문이다. 팁코는 저장된 프로시저로 자사의 디자이너(Designer)로부터만 액세스를 허용했으며, 다른 모든 액세스에는 팁코의 비즈니스웍스(BusinessWorks)를 이용해 RDBMS에 저장된 데이터로 액세스하는 서비스를 만들어야 했다. 블루스프링은 전통적인 윈도 기반 DSN(Data-Source Name)을 이용한다.
웹서비스는 모든 업체들에게 통합의 성배라고 불린다. 모든 제품이 웹서비스와 통합이 가능하지만, 테스트 결과 그 성공과 드는 수고의 수준은 다양했다. 롬바르디의 팀웍스(TeamWorks)는 처음에는 우리의 닷넷 기반 웹서비스와 통신하는 데 문제가 있었지만 회사에서 곧바로 패치를 보내주었다. 새비온은 아웃 오브 더 박스로 통신할 수 있었던 유일한 제품이었으며, 다른 모든 제품들은 얼마간의 스키마와 코드 조정작업이 필요했다. 비즈니스웍스에 있는 웹서비스와 같은 서비스를 노출시키는 데는 무거운 리프팅이 필요했기 때문에 부담스러웠다.
팁코의 경우 JMS(Java Message Service) 저장소가 서버에 구성돼 있어야만 웹서비스의 혜택을 누릴 수가 있었다. 공평하게 말하자면, 비즈니스 프로세스에서 신뢰성있는 전달을 필요로 한다는 팁코의 입장을 우리도 이해 못하는 바는 아니다. 이것은 웹서비스 모델 자체에서는 제공되지 않는다.

게임의 법칙
비즈니스 프로세스는 수많은 규정들에 의해 다스려지는데, 이들은 작업이 라우팅되는 방식, 다음에 실행될 작업, 그리고 프로세스가 다른 시스템이나 인간으로부터 응답을 기다릴 수 있는 시간의 길이 등을 결정한다. 규정은 주문에 할인율을 적용시키거나, 대출신청 승인 등과 같은 의사결정을 내려준다. BRE(business rule engine)은 비즈니스 애널리스트용으로 만들어진 것으로, 보통 스탠드얼론 서버로 배치가 된다. BRE는 입력을 받아들이고, 이것을 적절한 규정 세트를 통해 실행한 다음 응답을 내보낸다.
웹서비스는 BRE 통합을 위한 주 메커니즘이다. CA, 페가시스템즈, 그리고 블루스프링은 자체 BRE를 내놓고 있다. 팁코는 콘트리콘(Contricon)과 파트너십을 통해 제품을 내놓고 있으며, 오라클의 JSR 94 기반 BRE는 곧 출시될 전망이다. 다른 제품들은 비즈니스 규정을 독립적으로 이행하지 않으며, 대신 간단한 상황별 로직이나 코드를 이용해서 거의 모든 비즈니스 규정 기능성을 네이티브로 이행하고 있다.
CA의 에이온 BRE는 스스로를 웹서비스인 것처럼 나타내고 있다. 이 BRE는 우리에게 가장 인상적이었는데, 이것은 비즈니스 애널리스트를 타깃으로 하는(그리고 우리 생각으로는 이들에 의해 사용 가능할) 유일한 제품이었기 때문이다. CA에서 사용하는 아키텍처에는 SOA(Service Oriented Architecture) 개념이 들어가 있으며, 이런 규정을 이용해 비즈니스 프로세스를 재배치할 필요 없이 비즈니스 규정을 쉽고 역동적으로 바꿀 수 있게 해준다. 이것은 우리 애널리스트 사람들이 IT 사람을 부르지 않고서 진행 중 프로세스조차도 바꿀 수 있게 해주었다. 정말 멋진 일이다.
BRE를 사용하지 않는 참가자들 사이에서 비즈니스 규정 로직을 이행하는 방식은 큰 차이를 보였다. CA와 오라클은 자사의 인라인 비즈니스 규정 버전용으로 X패쓰(XPath)를 이용하는 반면, 롬바르디와 새비온은 자바스크립트에 의존했다. 얼티머스는 엑셀 메타포를 이용하며, 우리는 규정 이행을 위한 매크로를 만들었다. 팁코의 이행은 주로 자바다. 퓨고의 경우 전용 언어를 사용하지만 우리는 자바나 비주얼 베이식으로 규정을 ‘스킨(skin)’할 수 있었다. 여기서 기반 규정은 같은 것으로 남아 있지만 개발자가 가장 편안해 보이는 뷰에서 규정을 이행할 수 있다.
우리는 각자의 비즈니스 규정 메커니즘을 이용해 모든 제품에서 프로세스를 이행했다. 하지만 외부 BRE는 사용하지 않았기 때문에 간단한 값 바꾸기 외에는 비즈니스 규정을 바꿀 수 없었으며, 프로세스 정의를 변경하거나 재배치하는 것도 불가능했다. 우리는 최소한 스레숄드 변수(고객의 과거 주문 합계 등)를 정해 비즈니스 사용자가 값을 바꿀 수 있게 함으로써, 모든 상황에서 프로세스를 재배치해야 하는 문제는 덜 수 있었다. 하지만 CA, 페가시스템즈, 블루스프링 및 팁코 제품을 제외하고는 별도의 BRE를 구입해서 배치하지 않은 상태에서 애널리스트들이 IT를 포함시키지 않고 규정을 바꿀 수 있는 방편을 제공할 수가 없었다.

운영적 프로세스·BAM 관리
BPM은 두 가지 관리를 필요로 하는데, 하나는 운영적 프로세스 관리고, 다른 하나는 BAM(Business Activity Monitoring)이다. 전자는 예외 상황을 다루고, 프로세스의 현재 상태를 이해하며, 진행 중인 프로세스뿐만 아니라 장기적으로 돌아가는 비동기 프로세스들을 다루는 메커니즘을 제공한다. 그리고 후자는 비즈니스와 프로세스 효율성이 모두 관리되고, 최적화되고, 보다 잘 이해될 수 있는 수단을 제공한다.
프로세스 관리는 관리자와, 그리고 바라건대 비즈니스 프로세스 소유자들에게 무엇이 일어나고 있는지에 대한 통찰력을 제공한다. 우리가 테스트한 모든 제품은 현재 상태에서부터 어떤 단계가 시행 중인지에 이르기까지가 포함된 웹 지원 비주얼 뷰를 제공한다. 모든 제품이 프로세스에 연관된 다양한 데이터에 대한 적어도 최소한의 뷰를 제공했지만, 오라클은 이것을 놀라운 수준으로 끌어 올려, 각 단계에 수반되는 데이터와 트랜잭션에 대한 풍부한 세부 사항에 대한 완벽한 감사 추적 기능을 제공하고 있다.
모든 제품은 진행 중 프로세스를 방해하지 않으면서 새로운 프로세스 버전을 배치할 수 있는 메커니즘을 제공했다. 작동 중인 프로세스는 이들이 시작될 때 배치된 버전을 기반으로 계속 실행이 되며, 동시에 새로운 프로세스는 새로운 버전에서 실행이 된다. 새비온, 롬바르디 및 퓨고는 한 단계 더 나아가 사소한 변경에는 수동으로 거의 개입할 필요가 없이 진행 중 프로세스를 새로운 버전으로 마이그레이팅할 수 있는 수단도 제공해 준다.
BAM은 비즈니스 관점에서 운영적인 용어로 프로세스를 모니터링한다. 테스트한 모든 제품은 프로세스 실행 시간, 프로세스가 실행된 횟수, 그리고 어떤 사용자가 얼마나 많은 작업을 실행했는지 등과 같은 운영적인 측정기준 뿐만 아니라, 프로세스 데이터에 의해 결정된 프로세스의 가치 등과 같이 보다 비즈니스 중심의 통계들을 추적할 수 있는 수단을 제공했다. 하지만 비즈니스 데이터를 이용해 보고서를 만들고 프로세스의 효율성을 분석하려 하자 제품들간 차이가 분명해졌다.
실시간 데이터에 대해 우리가 요청했을 때 업체들의 반응을 보면 마치 우리가 달을 따다 달라고 한 것 같이 생각될 것이다. 결론적으로 말하자면 실시간 BAM에는 개발 및 통합 작업이 필요하기 때문에, 개발자들이 대시보드 구축 전문기술을 갖고 있기를 희망하는 수밖에 없다. 데이터는 모두 나와 있지만, 개발 작업이 없이 이것을 볼 수 있는 능력은 우리가 바라는 것만큼 발전돼 있지 못했다. 오라클이 이 수준에 가장 근접했으며, CA, 롬바르디 및 새비온이 그 뒤를 이었다.
CA를 제외한 모든 참가자들은 KPI(Key Performance Indicator) 결과를 프로세스에 다시 통합시킬 수 있게 해줬다. 이것은 비즈니스 의사결정이 운영 및 비즈니스 조건에 따라 실시간으로 이뤄질 수 있는 한 가지 방법이다. 왕복 시뮬레이션 능력이 없음을 감안할 때 이 기능은 깜짝 선물 같았다.
하지만 프로세스 최적화의 마무리를 완성하는 데 유용한 시뮬레이션 기능을 제공하는 곳은 새비온, 롬바르디, 그리고 퓨고뿐이었다. 세 곳은 모두 프로세스를 시뮬레이팅할 수 있는 다양한 방법을 제공하며, 새비온과 퓨고는 다중 시나리오와 프로세스를 동시에 돌릴 수 있게 해준다. 다른 제품들은 한정된 시뮬레이션 기능을 제공하는데, 어떤 것은 특정 자원에 얼마간의 비용을 할당하고 있으며, 작업 기간의 랜덤 배포를 허용하는 것들도 있었다. 시뮬레이션은 비즈니스 프로세스 소유자와 IT가 병목을 발견할 수 있게 도와준다.

최종 판정
퓨고 제품은 이번 BPM 게임에서 우승자임이 입증됐으며 새비온, 오라클 및 CA의 스위트들이 얼마되지 않는 차이로 그 뒷자리를 차지했다. 퓨고BPM의 시뮬레이션과 프로세스 관리 능력은 포괄적이며, 그 시스템 통합 및 수동 작업 기능은 폭넓고 재활용을 디폴트로 포함하고 있다. 그리고 그 BAM 능력은 여기에 포함된 툴세트뿐만 아니라 써드파티 툴들에게도 개방돼 있다. 새비온 비즈니스매니저는 BAM 이행이 보다 약하며, 통합 옵션이 적은 반면, 오라클 BPEL 프로세스 매니저는 시뮬레이션과 보다 협소한 프로세스 관리 능력으로 인해 뒤로 밀렸다. CA는 그다지 똑똑하지 못한 클레버패쓰 통합과 시뮬레이션으로 정상에 오르지 못했다.
롬바르디 팀웍스와 얼티머스 BPM 스위트는 강력한 경쟁자들이긴 했지만, 시뮬레이션과 통합, 그리고 폭넓은 프로세스 리스너들이 롬바르디의 성능을 저해했다. 얼티머스 고유의 엑셀 메타포는 리뷰에서 성적이 앞선 제품들의 우아한 규정 이행들과 경쟁이 되지 않았으며, 그 중세식 BAM과 보고 옵션 또한 걸림돌이 됐다. 페가시스템즈 페라룰즈의 독특한 규정 지향식 세상보기는 목을 배기 충분할 만큼 긴 밧줄을 주었다. 블루스프링은 위대한 비전을 갖고 있지만 그 BPM 스위트는 내비게이팅하기가 어려웠다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.