BPM 도입 시 고려사항

- 아래는 2004년 2월, IT Business Journal에 기고한 내용입니다. --

 

1. BPM과 BPMS의 의미

   국내외적으로 비즈니스 프로세스 관리 (BPM: Business Process Management)에 대한 관심이 급속히 증대되고 있음에 반해, 그 영역에 대해서는 아직 일반적 합의가 이루어지지 않은 상태라 할 수 있다. 즉, 1993년부터 워크플로우에 대한 개념 정립과 기술 표준들을 정의해 온 WfMC (Workflow Management Coalition)는 프로세스 자동화 (BPA: Business Process Automation)와 프로세스 통합 (BPi: Business Process integration)에, 2000년에 설립된 BPMI (Business Process Management Initiative)는 프로세스 개선 (BPI: Business Process Improvement)과 BPA에 초점을 두고 있다. BPMI는 EAI와 B2Bi를 포괄하는 BPi를 BPM의 영역 바깥에 있는, 그러나 밀접한 관련이 있는 것으로 정의하고 있으나 필자는 BPM을 워크플로우 관리에 대한 새로운 명칭으로 간주하면서 BPI, BPA, BPi의 세 가지 구성요소를 모두 포괄하는 것으로 정의하고자 한다.

   BPM을 지원하기 위한 패키지 S/W인 BPMS는 일반적으로 (1) 프로세스 모델링: 작업, 사람, 시스템 등 대상, (2) 프로세스 실행: 사람/시스템에 대한 작업 할당과 실행, (3) 프로세스 모니터링: 작업/사람/시스템의 상태 추적, (4) 프로세스/애플리케이션 통합, (5) 프로세스 분석과 최적화 등의 기능을 제공한다. BPMS는 현재 두 가지의 유형이 존재하는 것으로 볼 수 있다. 그 한 부류는 전통적 WFMS, EAI S/W, ERP 패키지, BPR tool 등에 새로운 기능과 신기술이 반영된 제품들이고 다른 부류는 e-Business를 포함한 새로운 업무 요구사항을 감안한 가운데 웹 기반, 컴포넌트 기반으로 새롭게 개발된 제품들이다. Staffware와 Ultimus, eInsight (SeeBeyond사), SAP, ARIS (IDS Sheer사) 등이 전자에, BPMI의 창립 멤버 중 하나인 Intalio사의 n³가 후자에 속한다. BPMS 제품의 표준화는 좀 더 시간이 걸릴 것으로 예상된다. 이는 BPML, BPQL 등 핵심 tool은 물론, BPM 자체에 대해서도 관련 업계와 학계의 공감이 필요한 시점이기 때문이다. 그 한 예로서, 비즈니스 프로세스 모델링 언어만 해도 WfMC의 XPDL, BPMI의 BPML, OASIS의 BPEL4WS, 아인트호벤/퀸스랜드 대학의 YAWL 등이 제안되고 있다.

   그러나, 이제 대부분의 조직들이 데이터 관리를 위한 수단으로 DBMS를 활용하고 있는 것처럼, 프로세스 관리를 위한 BPMS가 기업 내부는 물론 기업 간 거래를 합리화하고, 자동화하기 위한 필수적 수단이 될 날도 그리 멀지 않은 것으로 보아야 할 것이다.

2. BPMS 도입/구축 절차

   BPMS의 도입은 해당 조직의 업무 체제와 기술 기반에 대한 상당한 변화를 요구한다. 업무 측면에서는 조직구성원의 사고가 ‘프로세스 마인드’로 바뀜은 물론 기존의 업무 절차와 문서, 조직 구조 등이 변하고 기술 측면에서는 기존 정보시스템의 응용시스템 부분은 물론 플랫폼 부분도 변할 수 있다. 이는 첫째, 프로세스는 (데이터와는 달리) 사람과 시스템 속에 녹아 있으며, 둘째, BPMS의 성격 자체가 미들웨어에 준하는 것이기 때문이다. 따라서, BPMS를 성공적으로 도입하기 위해서는 업무적/기술적 측면에서 체계적인 준비와 실행이 이루어져야 한다.

   우선, (1) 프로젝트 준비 단계에서는 BPR을 추진할 때처럼 최고경영자를 포함한 주요 의사결정자들의 호응이 있어야 하고, 조직 내부의 우수한 인재를 선발해서 프로젝트 팀을 구성하며 전 과정에 걸쳐 객관적인 조언을 해 줄 외부 전문가를 확보하는 등의 활동이 있어야 한다. (2.1) 업무 요구사항 정의 단계에서는 조직의 핵심 프로세스 중에서 BPM의 적용을 통해 큰 효과를 낼 수 있는 후보 프로세스를 선정하고 예상되는 위협요인, 기회요인 등에 대한 분석을 통해 시범 적용 대상 프로세스를 선정한다. 이 때, 정책적 긴요성은 물론, 프로세스 자체의 정형화 정도, 관련 임직원의 개선 의지 등이 고려되어야 할 것이다. (2.2) 기술 요구사항 정의 단계에서는 도입될 BPMS가 제공해야 할 기능적 요건은 물론 비기능적 요건을 정의한다. 기능적 요건이라 함은 프로세스 모델링, 실행, 모니터링 등의 서비스를, 비기능적 요건이라 함은 성능, 안정성, 확장성 등을 가리킨다. (3.1) 프로세스 모델링은 일관화(streamlining)나 재설계(re-design)를 통해 프로세스 자체의 개선방안을 찾아 낸 후, 새로이 적용될 프로세스의 세부 로직을 적합한 모델링 도구를 이용해서 정의하는 단계이다. 이 때, 프로세스 자체에 대한 변화의 폭은 조직의 역량에 따라 조절되어야 할 것이다.

   (3.2) 시장조사와 제품선정 단계에서는 조직 특성 (예: 정부/공공, 제조, 금융, 통신)과 대상 프로세스 특성 (예: 일반관리, 생산/운영, 협업)을 감안한 가운데 서너 개의 제품을 평가해서 그 중 하나를 선정한다. BPMS를 선정하는 기준으로는 우선 일반적인 패키지 S/W를 선정할 때와 마찬가지로 제품 자체의 기능, 성능, 업무 적합성, 기술구조의 안정성과 발전성, 설치/전환의 용이성, 사용자 편의성, 가격 등이 고려되어야 하며, 공급업체에 대한 시장/고객의 평판, 성공한 사이트의 수, 지원 능력 등이 고려되어야 한다. BPMS를 선정할 때 특히 중요하게 따져 봐야 할 것은 첫째, 비즈니스 미들웨어로서 기존 플랫폼과 응용시스템을 얼마나 효과적으로 통합해 줄 수 있는가 하는 점이다. 정보시스템에 대한 신규 투자는 기존 투자를 보호할 수 있을 때 증폭될 수 있다. 둘째, 도입될 BPMS의 업무적 요건과 제품의 초점 (즉, EDMS, WFMS, EAI, ERP, BPR 등)이 부합되는지를 살펴보아야 한다. 예를 들면, BPR에 초점을 둔 제품으로 EAI 중심의 BPM을 구현하고자 한다면 무리가 따른다. 셋째, 앞에서 언급한 것처럼 BPM 내지 BPMS 자체가 진화되고 있음을 감안해서 새로운 요구사항, 기술, 표준 등을 얼마나 기민하게, 잘 반영할 수 있을지를 따져봐야 한다. 2000년 이전에 개발된 제품들 중에는 클라이언트-서버 구조의 엔진 위에서 컴포넌트 화가 이루어지지 않은 것들도 있다. 또, web-based가 아닌 web-aware 제품 즉, ‘무늬만 웹 기반’인 제품도 있다. 비교적 최근에 개발된 제품은 컴포넌트 기반, 웹 기반임에는 틀림없지만 제품의 안정성이 아직 검증되지 않았다는 점이 문제가 될 수도 있다.

   (4.1) 워크플로우 모델링은 자동화 대상 프로세스의 처리 순서와 방식을 정의하는 단계이다. 대상 프로세스가 기 도입된 tool을 이용해서 이미 자동화가 되어 있는 상태라면 기존 시스템으로부터 필요한 형식의 프로세스 모델을 추출해 내는 작업이 필요하다. (4.2) BPMS 설치는 관련 H/W, S/W를 현장에 설치하는 단계이다. 클라이언트-서버 시스템이라면 서버와 클라이언트를 각각 설치하게 될 것이지만, 웹 기반 시스템이라면, 적정 수의 BPM 서버와, WAS(Web Application Server)를 설치 또는 튜닝하는 작업이 포함될 것이다. (5) BPM 응용시스템 통합은 인력/회계/영업/생산관리 등 기존 응용시스템과 BPMS를 통합하는 작업이 포함된다. (6) BPM 적용은 BPMS가 포함된 새로운 응용시스템을 실제 업무에 적용하기 시작하는 단계이고 (7) BPM 운영 유지는 BPM 적용 상의 문제점 해결, BPMS의 유지 보수, 프로세스/시스템 데이터의 획득과 활용 등을 실행하는 단계이다. (8) 프로세스 분석 및 최적화는 정기/수시로 수집된 데이터에 대한 분석을 통해 비즈니스 프로세스를 재설계, 적용하고 BPMS도 발전시켜 가는 단계이다.

3. BPMS 도입의 선행조건

   위와 같은 다소 기계적인 절차 외에도 BPM의 성공적 적용을 위해서는 다음과 같은 점에 대한 고려가 필요하다. 첫째, BPM의 도입, 적용과 관련된 이해당사자들이 BPM과 BPMS에 대해 정확한 이해를 갖는 것이 필요하다. 정보화 초기에 있었던 ‘맹신’이나 ‘과신’, 또 ‘불신’은 모두가 올바른 이해가 부족한데서 비롯된 일이었다. BPM은 개념 자체가 어려운 것은 아니지만 이를 변화관리 수단으로 쓸 수 있으려면 경영관리는 물론 IT 전반에 대한 폭 넓은 이해를 갖춰야 한다. 둘째, 모든 일이 그렇듯이 BPM 도입의 첫 단추를 잘 꿰어야 한다. BPM을 통해 얻고자 하는 변화의 범위와 깊이가 크면 클수록 정확한 초반 승부처를 잘 찾아서 확실한 성공 사례를 만들어 내는 것이 필요하다. 셋째, BPM의 도입에 따라 수반되는 변화의 역기능을 최소화하기 위해서는 타이밍을 잘 맞출 필요가 있다. 예를 들면, M&A 직후라든지 최고경영진의 변화, 메인 프레임 또는 기간 S/W의 도입 시기 등을 고려할 수 있다. 넷째, BPM 도입 관련 활동의 범위가 상당히 넓은 점을 감안할 때, BPMS 공급업체, 컨설팅 업체, 외부 전문가 등이 공과를 함께 나눌 수 있는 파트너가 되어야 한다. 끝으로, 모든 정보화 프로젝트의 성공요인 중 하나로서 큰 그림은 그려 둔 상태에서 시작은 작게 (‘Top-down design, bottom-up implementation!') 하는 것이 필요하다.