비즈니스 프로세스 관리(BPM)의 보급률이 서서히 높아지고 있지만 BPM이 무엇이고 어떻게 구동하는지에 대해 아직 제대로 파악하지 못하고 있는 기업들이 많다. 이를 위해 BPM의 개념과 BPM 제품 선택을 위한 여섯 단계의 가이드를 제시해보고자 한다.

거대 IT 업체들이 BPM 벤더들을 인수하거나 기존의 BPM 제품들을 확장하는데 적극적인 움직임을 보이고 있다. 비즈니스 인텔리전스 벤더들은 비즈니스의 연속성을 모니터링 하기위해 비즈니스 룰 벤더의 '조달자'처럼 BPM 벤더들과의 협력을 강화하고 있다. 많은 기업들이 BPM을 도입하고 있는 가운데, BPM이 무엇이며 관심을 끌고 있는 이유는 무엇이고 적합한 기술은 어떻게 선택해야 하는지에 대한 논의도 활발해지고 있다.

BPM에 대한 정의를 내리는 것은 비교적 어렵지 않을 것이라고 생각할지 모르지만 현재의 비즈니스 프로세스 관리 시스템(BPMS) 기능은 다양한 요구 사항을 해결하면서 진화하고 있음을 감안해볼 때 범위를 한정 짓기가 쉽지 않다. 따라서 BPM이란 용어는 다른 BPM, 즉 비즈니스 성과 관리인 BPM 등과의 용어 혼란을 비롯해 매우 모호하게 사용되고 있는 상황이다. 그럼에도 불구하고, 한 가지 확실한 것은 BPM의 관심도가 지속적으로 높아지고 있다는 점이다. 포레스터 리서치는 BPMS 라이선스와 서비스, 유지 보수 매출액이 2005년 12억 달러에서 2009년 27억 달러로 급성장할 것으로 전망하고 있다.

BPM과 관련, 가장 일반적으로 혼동하는 것은 1990년대의 워크플로우 시스템과 현재의 BPMS간의 차이점이라 할 수 있다. 과거의 배타적인 워크플로우 시스템은 사람들이 단계별로 실행하는 문서 기반의 프로세스를 관리했다. 현재의 BPM 시스템은 사람간의 작업 단계를 포함해 시스템간 커뮤니케이션이나 둘 간의 조합 모두를 아우르는 프로세스를 관리한다. 또한 BPM 시스템에는 진보된 휴대형 프로세스 모델링과 시뮬레이션, 코드 생성, 프로세스 실행, 프로세스 모니터링, 맞춤형 업계 특화 템플릿, UI 컴포넌트, 웹 서비스 등과 같은 통합된 기능이 포함되어 있다.

이러한 다양한 기능들은 BPM 제품에 대한 관심도를 반영한 것으로, 기업들에게 비즈니스 프로세스에 대한 더욱 높은 유연성을 제공하는 동시에 위험성과 비용은 낮춰줄 수 있다는 기대감을 불러일으키고 있다.

◆BPM Suite의 구성 요소=BPM 스위트와 관련된 또 다른 혼란 사항은 BPMS의 다양한 형태와 관련되어 있다. 예를 들어, 전적으로 비즈니스 프로세스 관리에만 초점을 맞추고 있다는 '순수한 BPM' 업체라는 용어를 쓰는 벤더라도 유사한 기능을 가진 솔루션이 증가하면서 이러한 용어는 조만간 사라지게 될 것이다.

비교적 가벼운 형태의 BPM 기능은 ERP나 CRM, 회계 소프트웨어 등과 같은 패키지 형태의 기업용 애플리케이션에서도 발견된다. 이러한 형태는 해당 애플리케이션의 영역 바깥에서는 사용되도록 개발되지 않았기 때문에 '내장된 BPM'으로 통칭된다.

또한 BPM 기능은 기업용 애플리케이션 통합(EAI) 벤더로부터 등장했다. 이는 엔터프라이즈 서비스 버스(ESB) 제품의 향상된 버전들이다. 이러한 시스템들은 시스템 사이의 디자인과 개발, 실행을 지원하며 웹 서비스와 동기식 메시징을 통해 통합을 지원한다.

간단히 말해서, BPM 솔루션은 크게 두 가지 범주로 볼 수 있는데, 하나는 프런트 오피스 BPM(FO-BPM)이며 나머지 하나는 백 오피스 BPM(BO-BPM)이다. 벤더들이 두 가지 형태의 BPM 솔루션 제공에 주력하고 있지만 각각의 영역에서의 기능이 성숙하기까지에는 시간과 경험이 더 필요할 것으로 예상된다.

사람 중심의 워크플로우 제품에 근간을 두고 있는 FO-BPM 솔루션은 '작업 아이템'이 생성되고 관련된 문서를 따라 이동하는 인간과 인간 사이의 프로세스를 위한 기능을 제공한다. FO-BPM 기능을 제공하는 대표적인 벤더들로는 팁코와 파일네트(FileNet), IBM, PegaSystems, Global360, 오라클, DST 시스템즈, BEA, 컴퓨터 어쏘시에이츠, Ultimus, Savvion, MetaStorm 등이 있다.

반면에 ESB 제품들처럼 백 오피스 지향적인 BPM 솔루션은 하나의 프로세스 작업이 완료될 때까지 여러 외부의 프로세스를 거쳐야 하는 시스템 간의 통합을 가능하게 해준다. 또한 이러한 제품들은 기업의 모든 서비스를 한데 모으고 관리한다. 이 분야의 대표적인 벤더는 IBM과 오라클, 팁코, 썬, 웹메쏘드, CapeClear, Fiorano Software, 소닉 소프트웨어, BEA 시스템즈 등이다.

비즈니스 프로세스 관리 제품에 대한 일반적인 구성 요소(흰색)와 프런트 오피스 지향적인 BPM의 요소(파란색), 백 오피스 지향적인 제품에서 발견되는 기능들.

프런트 오피스와 백 오피스 지향적인 BPM 시스템은 서로 다른 문제점 해결을 목표로 하고 있다. 예를 들면, 프런트 오피스 BPM 애플리케이션은 일반적으로 '짧게 구동하는(short running)' 트랜잭션을 처리한다. 즉, 내부 프로세스가 웹 서비스 기반의 프로세스(기업 외부에서 발생)와 통합될 경우 적합하지 않다는 의미이다. 여러 리소스 매니저가 개입하는 프로세스의 트랜잭션은 백 오피스 BPM에 적합하다.

BPM 스위트의 대표적인 차별점은 비즈니스 프로세스 라이프사이클의 지원이다. 따라서, 프로세스의 각 단계에서의 관련성을 이해하는 것이 중요하다. (그림 2)는 기본적인 BPM 라이프사이클을 도식화한 것이다.

◆프로세스 모델링=일반적으로 모델링 단계에서는 비주얼 프로세스 디자인 툴로 지원된다. 일부 벤더들은 자체 툴을 보유하고 있으며 마이크로소프트 비지오(Visio)나 이클립스(Eclipse) 기반의 모듈과 같은 제품이나 기존의 IDE를 확장하는 전용 플러그 인을 제공하는 곳도 있다.

프로세스는 여러 활동(단계나 업무 등)으로 이루어져 있다. 이들은 프로세스의 흐름을 형성하기 위해 서로 연결되어 있다. 언제 어떻게 활동하는지에 대한 정의는 모델링 단계에서 이루어진다. 프로세스 활동은 문서나 이미지 등과 같은 첨부물을 포함할 수 있으며 이는 관련 데이터와 함께 다음 활동으로 이동된다. 또한 프로세스는 병렬 실행 경로로 쪼개질 수도, 미리 결정된 단계로 합쳐질 수도 있다. 필요할 경우 이메일이나 메시지, 문서 도착과 같은 외부 이벤트에 의해 프로세스가 시작되도록 설정할 수 있다. 이러한 기능들은 동일한 비주얼 디자인 툴을 사용해 그래픽적으로 묘사가 가능하다. 한 프로세스 내에 있는 활동들은 사람의 개입을 필요로 할 수도, 또는 사람의 상호작용이 없이도 처리될 수 있다. 따라서, 모델링 툴은 인간과 인간, 시스템과 시스템간 프로세스를 지원해야 한다.

다양한 형태의 활동들은 활동 아이콘과 그래픽 등 자체 시각적인 표식을 갖고 있기 때문에 표준화에 대한 필요성이 제기되었으며 대표적인 표준으로 BPMN(Business Process Modeling Notation)이 받아들여지고 있다.

프로세스 모델링 단계에서의 결과는 BPM 엔진이 지원하는 실행 가능한 언어 포맷으로 변환시킬 수 있는 의사 실행(pseudo-executable) 프로세스 플로우이다. 따라서, BPM 엔진이 이해할 수 있도록 XPDL이나 BPEL 등 프로세스 실행 언어로 모델링 언어가 매핑되어야 한다.

비즈니스 디자인에서 기술 디자인으로의 전환을 효율화하기 위해, UML(Unified Modeling Language)에서 애플리케이션 디자인 다이어그램을 만들 수도 있다. 또한 향상된 모델링 툴을 통해 프로세스를 시뮬레이션하는 것이 가능하다.

대부분의 BPMS 벤더들은 자사 솔루션에 최적화된 모델링 툴을 제공하지만 IDS Scheer, Proforma, Mega, iGrafx, Telelogic, Casewise 등과 같이 프로세스 모델링과 분석에 특화된 벤더들도 있다.

◆프로세스 활동 구현=모델링된 활동의 비즈니스 로직을 만들기 위해서는 필요한 지침을 제시해야 한다. 또한 한 프로세스 내에서의 복잡한 활동은 아주 낮은 단계에서부터 프로그램이 되어야 한다.

개발 환경은 벤더 전략에 따라 다르지만 모델링 툴과 통합된 IDE나 별도의 IDE 형태로 출시되는 것이 일반적이다. 그럼에도 불구하고, 모든 벤더들은 비주얼 프로그래밍 환경을 지원함으로써 하드 코딩(hard-coding)에 대한 필요성을 최소화하려는 시도에 나서고 있다. BPM IDE의 가장 일반적인 특징은 메타 데이터 지향적인 개발과 도입 속도의 향상을 위한 코드 생성 기능이다. 사용되는 프로그래밍 언어는 추론을 토대로 한 비즈니스 룰 엔진이거나 자바 또는 C++과 같은 표준 언어가 된다. 보다 복잡한 비즈니스 로직을 구현하기 위해서는 또 다른 프로그래밍 툴이 필요하다. 유연성 보장을 위해 모든 벤더들이 API나 웹 서비스 인터페이스를 제공하고 있다.

인간과 인간, 시스템과 시스템 지향적인 BPM 스위트는 폐쇄형 비즈니스 프로세스 라이프사이클을 지원한다.

프런트 오피스 지향적인 BPM 시스템은 일반적으로 형식을 디자인하고 데이터 필드를 규정하며 프로세스 템플릿을 맞춤화하고 액세스 컨트롤 목록을 만들며 통합 기능을 구성하고 데드라인을 관리할 수 있도록 해준다. 백 오피스 지향적인 BPM 솔루션은 인간 중심의 워크플로우를 지원하도록 개발되지 않았기 때문에 백엔드 프로세스나 데이터/메시지 변환, 서비스 인터페이스의 자동 생성 등과 같은 기능에 초점을 맞추고 있다.

애플리케이션을 외부 시스템과 통합할 경우 추가 옵션을 먼저 살펴봐야 한다. 대개의 경우 벤더들은 문서와 컨텐츠 관리 시스템, 보안 레포지터리, 써드파티 패키지 애플리케이션 및 미들웨어 제품과 통합이 가능한 컴포넌트를 제공하고 있다.

일단 프로세스 활동이 이루어지면 애플리케이션이 구현 가능하며 J2EE나 닷넷 등 벤더의 플랫폼에서 실행이 가능하다.

◆프로세스 실행=BPMS 벤더의 서버에서 구동하는 프로세스 엔진은 프로그램된 활동을 위해 변환된 프로세스 모델의 실행을 담당한다. 일반적인 런타임 환경은 보안이나 트랜잭션 등과 같이 낮은 수준의 서비스를 필요로 한다. 트랜잭션이 여러 비즈니스 파트너에 연계되어 있을 경우 이러한 트랜잭션을 관리하는 데에 많은 어려움이 따르게 된다.

프로세스 활동의 실행을 제어하기 위한 접근 방법은 '관현악(orchestration)'과 안무(choreography)' 등 두 가지로 나뉜다. 내부 협력 프로세스의 '소유자'가 누구인지에 따라 다르다.
관현악적인 접근 방법은 프로세스의 소유주가 단일 개체로, 여러 행동들 사이의 모든 메시지 교환을 총체적으로 제어한다. 대표적인 예는 내부 대출 승인 프로세스용 워크플로우 애플리케이션이다.

반면에 안무 방식은 모든 참여자들이 공동으로 프로세스를 소유하는 것으로 상호 '계약' 형태로 여러 메시지 교환이 이루어진다. B2B 환경에서의 구매 주문 프로세스 실행이 대표적인 사례이다.

프로세스 실행 언어 중에서 BPEL은 관현악적 접근 방법과 가장 가깝다. 또 다른 표준인 WS-CDL은 안무 방식에 적합하다. 반면 XPDL의 경우 인간 중심의 워크플로우 툴/애플리케이션에 주로 사용된다.

◆프로세스 모니터링과 분석=비즈니스의 실적과 성과 메트릭스에 대한 리포팅의 중요성이 더욱 높아지고 있으며 BPM 제품군을 차별하는 대표적인 요인이 되고 있다. 프로세스의 효율성에 대한 엄청난 잠재력에 주목, BPM 벤더들은 다른 업체 인수나 협력, 기존 툴 향상 등의 방법을 통해 이러한 형태의 비즈니스 활동 모니터링(BAM) 기능을 자사의 제품군에 추가시키고 있다.

하지만 잠재 고객들은 BAM의 활용을 극대화하는 방법을 혼동하고 있다. 고객의 혼란을 야기하는 이유 중의 하나는 BAM의 형태가 하나가 아닌 두 가지이기 때문으로, 실시간 BAM과 히스토리컬 BAM이 바로 그것이다. 하지만 두 가지 BAM간의 차이점이 명확하지 않다는 데에도 문제가 있다.

실시간 BAM 컴포넌트들은 진행 중인 작업에 대한 메트릭스를 모니터링하도록 BMP 솔루션 내에서 긴밀하게 통합된다. 실시간 BAM은 리소스 활용도를 위한 워크 로드도 예측할 수가 있다. 비즈니스 이벤트에 대해 필터링하고 반응하는 것 역시 핵심 기능이다.

반면에 히스토리컬 BAM 컴포넌트는 이미 완료된 프로세스의 순수한 히스토리컬 실행으로부터 결론을 이끄는 분석 리포트를 제공한다. 프로세스 전용의 주요 성과지표(KPI)와 서비스 수준 협약(SLA)는 이러한 데이터에 대한 비교 자료 역할을 할 수 있다. 또한 이러한 툴들은 기존의 데이터웨어하우스와 통합이 가능하며 BPM 서버에 비해 다양한 서버 플랫폼을 요구한다.

◆현재의 위치=아래의 항목들은 완벽하지는 않지만 근접할 수 있게 해준다. 업계가 기본적인 부문에서 상당히 진보해있지만 아직은 유동성이 많은 편이라 할 수 있다.

• 사람간의 프로세스 관리를 위한 표준
• 시스템간 프로세스에 대한 메시지 보안과 신뢰성의 지속적인 변화
• 트랜잭션 확대 전달
• 비즈니스 활동 모니터링
• 여러 프로세스 엔진의 통합

인간의 상호작용과 관련된 프로세스를 지원하는 표준이 현재 마련되어 있지 않은 상황이다. BPEL의 경우 사람간의 프로세스를 처리할 수 없기 때문에 'BPEL4People'이라는 확장 표준이 제안되고 있으며 이와 유사한 기능이 XPDL에서도 진행되고 있다.

메시지의 무결성과 기밀성, 인증에 대한 보안 문제도 제기된다. SOAP 기반의 커뮤니케이션에서는 XML의 확장을 통해 사용자 이름과 인증서, SAML 등 메시지의 보안 토큰의 사용을 지원한다. 이러한 시도는 WS-Security 스펙에서 비롯되었다.

커뮤니케이션과 관련된 문제를 처리하기 위한 커뮤니케이션 표준 역시 우선 사항이다. SOAP 기반의 웹 서비스 통합의 경우 WS-RM과 WS-R이 표준 경합을 벌이고 있다. 두 가지 모두 XML 기반의 프로토콜로, 메시지의 송신자가 메시지를 보낼 때 수신자가 해당 메시지를 받았는지 여부를 확인할 수 있게 해준다. 현재 WS-RM이 더 많은 벤더의 지원을 받고 있지만 양자간 통합이 필수적이다.

또 다른 해결 과제는 웹 서비스와 관련, 시스템간 상호 작용이 발생할 때 트랜잭션을 관리하는 문제이다. BPEL과 WS의 확장판이 이러한 백오피스 BPMS에서 지원되고 있다. BPEL 워크플로우 트랜잭션의 경우 짧게 구동하거나 길게 구동할 수 있다. WS-Transaction과 WS-Coordination 서비스는 트랜잭션이 이루어지는 웹 서비스를 지원한다. 반면에 또 다른 표준인 BTP(Business Transaction Protocol)은 유사한 사항을 지원함에도 BPEL과 WS 확장판이 더 많이 사용되고 있다.

◆도입하기 전 고려 사항=BPM 시스템과 제품 선택시 고려해야 할 대표적인 사항을 살펴보면 다음과 같다:

1. BPM 시스템이 모든 애플리케이션에 필요하다는 것을 의미하지는 않는다. BPM 시스템은 모든 행동들이 미리 순서대로 결정되어 있는 프로세스에 특히 적합하다. 비즈니스의 문제점과 BPMS의 기능 모두를 심도 있게 이해하는 BPM 접근 방식을 채택해야 할 것이다. 프로세스에 대한 상세한 행동을 문서화하고 제품 선택에 앞서 BPMS가 핵심적인 요구 사항에 대응할 수 있는지를 확인하라.

2. 그 다음에는 필요한 BPM 솔루션의 형태를 생각한다. 인간 중심의 프로세스라면 프런트 오피스 지향적인 BPM을, 통합 중심의 프로세스라면 백오피스 지향적인 BPM을 고려한다. 도입 환경에 따라 두 가지 형태의 BPM이 효과를 거둘 수도 있다. 여러 벤더의 솔루션을 사용한다면 프로세스 모델링과 모니터링 툴, 서버 플랫폼도 그만큼 늘어나게 됨을 잊어선 안 된다.

3. BPMS의 형태를 결정한 다음에는 BPM 라이프사이클의 행동과 구조적인 컴포넌트를 고려해 필요한 요구 사항을 분석한다. 표준 지원 여부보다는 BPMS의 가치를 토대로 해서 제품을 선택해야 한다.

4. 프런트 오피스 지향적인 BPMS의 경우 맞춤화가 어느 정도나 용이한지, 통합을 위한 별도의 지원 프로그램이 있는지를 우선적으로 확인해야 한다. 동일한 벤더가 컨텐츠 관리와 협업 모듈을 함께 제공할 경우 레포지터리와 비즈니스 모델링 툴, 관리 콘솔이 이러한 컴포넌트와 통합이 이루어지는지도 점검해야 할 사항이다.

5. 백오피스 지향적인 BPM 제품들 중에서 BPEL과 WS 지원이 폭넓게 적용되어 있음을 알 수 있다. 따라서, 벤더의 방향에 대해 면밀히 주시해야 할 것이다. 벤더의 지원 메시지가 바뀌는지, 라우팅과 멀티 트랜스포트 프로토콜은 어떠한지 고려하라. 대부분의 프런트 오피스 지향적인 BPM 시스템은 애플리케이션 서버에 도입이 가능하지만 BO-BPM 서버는 그렇지 않을 경우가 많아 확인이 필요하다. 메시징 지향적인 미들웨어(MOM)나 애플리케이션 서버 등의 설치를 요구할 수도 있다.

6. 룰 엔진이 BPMS에서 어떻게 사용되는지도 고려해야 할 사항이다. 룰 엔진은 일반적으로 대부분의 BPM 제품에 옵션으로 제공되지만 특정 벤더는 반드시 룰 엔진을 요구하기도 한다.
BPM 솔루션은 다양한 기능을 번들로 제공하기 때문에 완벽히 활용하기까지 시간이 걸리게 된다. 따라서 적절한 교육 프로그램을 마련하고 최적 실행 방안을 구상하며 가이드라인을 설정해둘 필요가 있다. 프로세스에 최적의 BPMS를 배치시키는 것이 가장 중요함을 잊어선 안될 것이다.