연구기관이나 솔루션 벤더들은 각자 나름의 BPM에 대해 정의를 내리고 있다. 가트너 그룹은 '사람과 애플리케이션의 상호 작용에 대한 지원과 함께 명확한 프로세스 관리 기능을 지원하는 서비스 및 도구'라고 정의함으로써 서비스나 도구에 중점을 두고 있는 반면에 Ovum에서는 '조직 내외의 사람 및 시스템이 상호 작용하는 비즈니스 프로세스를 지속적으로 인지, 관리할 수 있도록 지원하는 변화/관리 및 시스템 실행 방법론'이라고 정의하여 방법론 쪽에 무게를 두고 있다.
한편 BPM 벤더들 중 Workflow 기반의 BPM 벤더인 H사는 '조직 내, 조직간, 인간과 시스템간의 상호작용을 하는 비즈니스 프로세스를 지속적으로 이해하고 관리하는 데 도움이 되는 변화관리 방법론이며 이를 구현하는 시스템'이라고 정의함으로써 시스템이라는 용어를 사용하고 있고, EAI 기반의 BPM 벤더인 M사는 '기업 내부에서 비즈니스 파트너의 영역까지 발생하는 모든 비즈니스 프로세스를 기술적인 측면이 아닌 비즈니스 관점에서 Discover, Design, Deploy, Execute, Operate, Interaction, Analyze하고 Optimize하는 것'이라고 정의하고 있다. 그러나 위에서 보는 바와 같이 BPM이 단지 방법론인지, 툴인지 아니면 시스템인지, Workflow인지 아니면 EAI인지 등 여러 가지 측면에서 혼란스럽고 모호함을 알 수 있다.
BPM은 방법론만이 아니며 툴이나 시스템의 도입만으로 구현할 수도 없다. 그러므로 IT 컨설팅 및 시스템 통합의 관점에서 BPM의 정의는 적절한 방법론을 사용하여 프로세스를 통합하고 관련 시스템을 도입하거나 개발하는 전 영역을 포함하여야 할 것이다. 그리고 고객의 관점에서는 BPM이 일회성 프로젝트가 아니라 지속적인 프로세스 개선활동이 되어야 할 것이다.
따라서 BPM에 대한 정의를 내린다면 '조직 내외부 리소스들간의 프로세스를 자동화/통합/최적화하기 위한 지속적인 활동'이라고 할 수 있겠다. 이 정의에서 중요한 점은 지속적인 활동이라는 점이다. BPM이 일회성 프로젝트나 시스템의 도입으로 완료되는 것이 아니라 [그림 1]에서 보는 바와 같이 프로세스를 정의하고 설계, 구현하여 프로세스를 수행하고 그 결과를 모니터링하고 분석하여 다시 프로세스 정의에 반영함으로써 프로세스의 지속적인 개선을 가능하게 하는 것이다.
BPM의 목적은 프로세스의 지속적 개선을 통해 생산성을 향상시키고 기업의 가치를 높이는 것이다. 이를 위해서는 프로세스가 자동화되고 통합되어야 할 것이며, 최적의 상태를 유지해야 할 것이다. 자동화는 사람이 자신이 할 일을 찾아가서 하는 것이 아니라 시스템이 할 일을 자동으로 할당해 준다거나 사람의 개입 없이 프로세스가 진행되도록 하는 것을 말하며, 통합은 프로세스와 관련된 데이터를 통합하거나 조직별, 시스템별로 구성된 프로세스를 전체적으로 통합하는 것을 의미한다. 그리고 최적화는 프로세스의 지속적 개선활동을 통해 항상 최적의 프로세스를 유지하는 것을 말한다.
BPM Framework
앞에서 내린 BPM의 정의를 가능하게 하는 기능들을 먼저 살펴보자. [그림 2]의 프리젠테이션 레이어는 사용자 화면에 비즈니스 프로세스를 연계시키기 위해 필요한 부분으로 기존의 포털이나 애플리케이션과 연동하기 위한 Portlet이나 API에 대한 기능이 있어야 한다.
첫째, 프로세스 레이어에서는 비즈니스 프로세스를 업무 담당자가 직접 정의하여 관리하고 다른 업무 담당자와 서로 이해하고 공유할 수 있어야 한다. 따라서 비즈니스 프로세스를 모델링하고 버전을 관리하며 공통된 저장소 기능을 가져야 한다.
둘째, 비즈니스 프로세스의 실행엔진이다. 모델링된 비즈니스 프로세스는 실행엔진에 의해 구동됨으로써 프로세스의 자동화를 구현한다. 이를 위해서 워크플로우를 디자인하여 실행시키고 라우팅이나 로드밸런싱을 수행하는 기능이 있어야 한다.
셋째, 시스템간이나 조직간의 데이터와 프로세스를 통합하기 위해 프로토콜의 정의, 데이터의 매핑 및 변환, 시스템 통합, 어댑팅 등의 기능이 있어야 한다.
넷째, 프로세스의 개선을 위해 수행된 프로세스를 모니터링하고 이미 정의된 성과지표와 비교하는 기능이 필요하며 개선 프로세스를 시뮬레이션해 보는 기능이 있어야 할 것이다.
다섯째, 비즈니스 룰을 프로세스나 애플리케이션과 분리하여 비즈니스 룰의 변경에 신속히 대응하기 위해 비즈니스 룰을 정의하고 관리하며 실행시킬 수 있는 기능이 있어야 한다.
여섯째, 원유값의 변화나 이자율의 변화, 천재지변 등과 같은 외부 환경의 변화에 신속하게 대응하기 위해 조직 전반에 걸친 주요 액티비티들에 대한 모니터링 기능이 필요하다. 프로세스뿐만 아니라 기존 시스템들로부터 데이터를 수집하는 데이터 수집 기능과 이를 정해진 룰에 따라 처리하는 기능, 그리고 그 결과를 보여주는 기능으로 구성된다.
BPM 프로젝트를 수행함에 있어 솔루션간의 연동, 관련자간의 의사 소통, 타 BPM과의 연동을 보장하기 위해서 BPM과 관련된 표준을 준수하느냐의 여부도 중요한 사항이다. 그리고 BPM 수행을 위한 방법론이 제공되어야 할 것이다. 이 방법론은 프로세스의 모델링, 솔루션의 적용, 시스템간의 통합, 시스템의 개발 등을 포괄할 수 있어야 할 것이다. 왜냐하면 BPM 프로젝트는 이 모두를 포함하기 때문이다.
위에 나열된 기능들은 이미 여러 솔루션에 의해 제공되고 있는 기능들이다. [그림 3]은 [그림 2]의 테크니컬 프레임워크와 대비된 솔루션 프레임워크를 보여주고 있다.
다양한 BPM 툴
업무 전문가에 의한 프로세스 모델링 및 공유를 가능하게 하는 비즈니스 프로세스 모델링 툴을 제공하는 업체 및 제품들로는 Popkin사의 System Architect, IDS Scheer사의 ARIS, CA사의 Allfusion BPWin, Casewise의 Corporate Modeler 등이 있으며, 국내 제품으로 Realweb에서 일부 기능을 제공하고 있다.
비즈니스 프로세스의 실행 엔진인 Workflow는 워크플로우 모델링, 워크플로우의 실행, 다양한 분기, 업무 부하 조정, 업무 흐름의 실시간 파악, 이력관리 및 통계 리포터 등을 제공한다. FileNet사의 P8 BPM, Staffware사의 Process Suite, Handysoft사의 Bizflow BPM 그리고 RealWeb사의 Real BPM 등이 있다.
애플리케이션간의 데이터 및 프로세스의 통합을 수행하는 EAI(Enterprise Application Integration)는 TIBCO, IBM, Miracom, WebMethod 등에서 제품을 출시하고 있으며, 데이터의 변환 및 라우팅, 기간 시스템 연동을 위한 어댑터의 제공, 애플리케이션간 프로세스의 자동화 기능을 제공한다.
성과지표를 정의하여 프로세스와 성과지표간의 차이를 분석하고 개선 프로세스를 도출할 수 있게 하며, 도출된 개선 프로세스에 대한 시뮬레이션 기능을 제공하는 BPA(Business Process Analysis)는 Popkin사의 SA SimulatorII, IDS Scheer사의 ARIS Simulation, FugoTec사의 Process Analyzer, FileNet의 Analyzer/ Simulator 등의 제품이 있다.
업무 담당자가 비즈니스 룰을 정의하고 변경하며 관리할 수 있도록 하며 공통 저장소에 관리함으로써 공유가 가능하도록 하는BRE(Business Rule Engine) 툴로는 Fairissac사의 Blaze Advisor, IDS Scheer사의 iLog Jrules 등이 있다.
마지막으로 기업의 주요 액티비티나 이벤트를 모니터링하고 신속하게 대응할 수 있도록 하는 BAM(Business Activity Monitoring) 툴로는 WebMethod의 Optimizer, TIBCO의 Business Factor가 있다.
위에서 열거한 툴들은 이제껏 그 영역에 한정된 기능들을 제공해 왔으나, BPM 시장의 성숙에 따라 타 영역으로 기능 확장을 시도하고 있다. 이미 워크플로우 업체들은 BPA의 많은 기능들을 보유하고 있으며, EAI 기능들을 보강하고 있고, EAI 업체들은 BAM 기능 확장에 발빠르게 대응함과 함께 Workflow 기능을 보강해 가고 있다. 한편으로 업체들간의 합병 및 전략적 제휴를 통해 부족한 기능들을 확보하고 있다. 예를 들면 TIBCO와 Staffware의 합병, FileNet과 iLog의 제휴 등을 들 수 있다.
BPM 구현 방법론
BPM 솔루션 벤더들이 제공하는 BPM 구현 방법론은 BPM 툴의 적용에 국한된 테스크들만을 제공하고 있다. 그러나 실제 프로젝트에서는 프로세스의 모델링을 위한 테스크들이 있어야 하며, 새로이 추가되어야 하는 애플리케이션의 개발을 위한 테스크들도 있어야 한다. 그리고 BPM 툴뿐만 아니라 관련된 시스템들을 아우르는 아키텍처의 설계도 포함되어야 하며 타 시스템들과의 인터페이스의 설계 및 개발 테스크들도 있어야 한다.
또한 프로세스에 대한 성과지표를 설정하고 프로세스를 모니터링하기 위한 방안도 제시하여야 하며, 프로젝트의 종료 후 고객사에서 BPM을 운영하고 지속적인 프로세스 개선활동을 수행할 수 있도록 하는 가이드의 제공과 같은 테스크들도 포함되어야 할 것이다.
이러한 방법론 요구에 따라 LG CNS 표준 방법론인 PPC를 근간으로 하여 BPR 방법론 및 BPM 툴 적용 방법론을 조합함으로써 [그림 4]와 같은 방법론을 수립하였다. [그림 4]에서 프로세스 정의, 시스템 분석, 아키텍처 정의는 BPM을 위해 수정하거나 추가된 테스크들이다.
위의 방법론은 PPC를 근간으로 하여 필요한 모든 스텝들을 보여 주고 있으므로 인해 주요 테스크간의 상호관계를 보기에는 부족한 감이 있다. 그래서 주요 테스크들간의 상호관계를 도식화한 것이 [그림 5]이다.
프로세스 모델링은 비즈니스 프로세스에 대한 분석을 통해 To-Be프로세스 모델을 도출하고 이를 표준화된 Notation에 따라 정의한다. 한편 성과관리 방안은 성과관리가 필요한 프로세스들에 대해서 성과지표를 도출하고 이 성과지표에 대한 측정 데이터를 언제, 어디에서, 어떻게 추출하여 비교할 것인가에 대한 방안을 수립하게 된다.
프로세스 모델 중 현행 애플리케이션이 지원하지 못하는 영역과 성과관리를 위해 추가로 개발해야 할 부분에 대해서는 추가 개발이 진행되어야 하며, 이를 위해 시스템 분석을 수행하며 이와 병행하여 필요한 솔루션의 선정 및 관련 아키텍처의 정의 작업을 수행한다. 프로세스 모델과 아키텍처를 반영하여 워크플로우 모델링을 수행하여 액티비티별로 필요한 애플리케이션, 데이터, 파라미터 등을 명세화하는 작업을 수행한다. 그후에 워크플로우와 인터페이스 그리고 시스템을 개발함으로써 BPM을 구현하게 된다.
댓글 없음:
댓글 쓰기