 |
 |
| |
| 1990년대 말 가트너를 비롯한 유력 컨설팅회사들에 의해 소개된 BPM(Business Process Management)은 전혀 새로운 개념이 아님에도 불구하고 IT 업계에 성공적인 데뷔를 거쳐 놀라운 속도로 시장에 진입하게 된다. 그 후 2006년 IDC의 보고에 의하면 전세계적으로 BPM 시장은 가장 빠르게 성장하는 시장 중 하나이며, 향후 5년간 연평균성장률(CAGR) 44%의 급격한 성장세를 나타낼 것이며, 2011년에는 55억 달러에 이를 것으로 전망하고 있다. |
|
 |
이러한 BPM의 출현은 전혀 새로운 것이 아니었다. ERP가 기업의 리소스를 관리해야 한다는 개념으로 킬러 애플리케이션이 된 후, ERP 도입에 대해서는 더 이상 ROI를 묻지 않게 되었다. 더 나아가 ERP 도입 여부가 그 기업의 수준을 가늠하는 잣대로 사용되기도 했다. 이러한 ERP의 큰 성공 이후, IT의 주관심사는 기업 내부에서 일어나고 있는 일과 그 절차에 대한 논의로 옮겨 갔으며 이것이 바로 BPM의 시작이었던 것이다.
이미 ERP를 도입한 기업들은, 내부적으로 어떤 일들이 벌어지고 있는가를 정의하고, 효과적으로 진행되는가를 관리하는 것이 ERP가 수행하는 일, 즉 이미 가지고 있는 리소스를 관리하는 것, 만큼이나 중요하다는 것을 인지하게 됐다.
국내 BPM 시장의 시작은 의외로 공공부분에서 2004년에 시작됐다. 물론 그 전에 PI, 파일럿 등 개념적인 시도는 대기업 중심으로 진행되고는 있었지만, 본격적으로 |
|
| 도입되어 활용되었던 곳은 의외로 공공부분이었다. 지금도 국내 BPM 시장은 매년 20% 이상 성장 진행 중이다. 또한 현재의 BPM은 최신 Enterprise IT Architecture로 각광받고 있는 SOA(Service Oriented Architecture) 개념 구현을 위한 프로세스 Layer 미들웨어로 인식되고 있어 향후 시장 전망은 더욱 밝다고 할 수 있다. 이 시점에서 BPM의 실체와 효과적인 구축을 위해 고려해야 할 내용들이 무엇인지를 점검해 보고, 향후 BPM 도입을 고려하고 있는 조직을 위한 실제적인 가이드를 제공하고자 한다. |
|
|
일반적으로 BPM은 초기 3가지 솔루션(개념)을 토대로 제안됐다(그림 1: 점선 박스 참조). (그림 1)은 연도 별 이슈가 되었던 기술과 그에 따라 유행했던 솔루션의 변화를 보여주고 있다. BPM은 Workflow, EAI 그리고 EDI를 계승한 B2B를 기술적 기반으로 삼아 제안됐으며, 이런 세가지 솔루션이 그 기반이 되었던 이유는 명확하다. BPM에서는 흔히 End-to-End Business Process Implementation 이란 용어를 자주 사용하는데 이 용어를 번역하면‘종단간 프로세스 구현’정도가 될 수 있겠다. 즉 업무절차를 시스템의 유무 및 같고 다름 등과 관계없이 일 중심으로 구현하는 것이 ‘End-to-End Business Process Implementation’ 이라고 볼 수 있다. |
|
|
이 개념을 구현하기 위해서는 무수히 많은 IT 지원 시스템 및 업무시스템들과 실제 작업자들이 필요하다. BPM은 이런 업무 프로세스를 가시화하고, 업무의 수행과 관련된 사람, 시스템을 프로세스에 맞게 실행/통제하며, 전체 업무 프로세스를 효율적으로 관리하고 최적화할 수 있도록 지원해 주는 것이다. |
|
|
이런 개념은 과거 Workflow, EAI 그리고, B2B 등 소위 Enterprise Process related solution 들을 통해 각각 부분적으로 수행됐다. Workflow는 사용자업무 자동화를, EAI는 시스템간 연계 구현을, 그리고 B2B는 업체 간의 데이터 교환 등을 담당 해왔다(표 1 참조). 하지만 BPM 이 주목했던 것은 일련의 나뉘어진 작업들이 반드시 실제 업무와 같이 단일 프로세스로 통합되어 관리돼야 한다는 것이다. 이를 위해 BPM은 업무의 시작과 끝을 연결하는 통합 프로세스 구현/운영 프레임웍을 제공한다. |
|
|
2003년 가트너가 제안한 BPM을 위한 5가지 기본 구성 요소 이다. |
|
|
2009년 현재는 SOA 등 서비스 표준을 위한 개념들이 요구되고 있고, 또한 보다 적극적인 모니터링 및 분석 방안들이 요구되어지고 있지만, 기본적으로 위의 5가지 큰 틀은 벗어나지 않는다. |
|
BPM 도입은 크게 다음과 같은 2가지 접근 방식을 취한다. 우선 BPM은, 신속하고 구체화된 경영을 위한 도구로 Top-down 방식을 취하며 일반적인 진행방법은 다음과 같다. 조직의 비전과 전략이 정해진 후 전략을 구체화 할 수 있는 프로세스들을 모두 도출한다. 다음으로 이 도출된 프로세스들을 선별 분류하고 우선 순위화해 BPM를 도입하는 방식이다. 일반적
으로 전사레벨에서 추진될 때 취할 수 있는 방법이다.
다음으로 고려될 수 있는 방법은 반대로 Bottom-up 방식이다. 이 방식은 BPM 도입 시 이미 세부적인 목적을 가지고 있는 경우이다.
예를 들어, 신제품 개발업무가 전혀 관리되지 않고 담당자들의 인지나 직관에 의해 진행되고 있다고 가정하자. 이 경우 업무 산출물의 재활용 및 각기 다른 상황 처리 후 각각의 효과 분석 등이 수행될 수 없고, 결과적으로 매번 같은 오류를 피할 수 없게 된다. 이런 경우 ‘신제품 개발업무’ 라는 구체화된 대상이 있고 이 업무절차를 관리하여 ‘산출물을 재활용’ 하고 ‘케이스에 따른 효과 분석’ 을 하겠다는 구체적인 KPI도 존재한다. 이 경우 BPM이 도입된다면 이것은 전형적인 Bottom-up 사례인 것이다. 이 두 가지 다른 접근 방식은 아래표(표2)에 정리되어 있다. |
|
|
Top-down 방식의 BPM 구현은 조직운영을 위한 다른 개념들과 상호 보완되며 병행운영 할 수 있다. 대표적으로 병행 운영되어 조직운영의 효과를 극대화 할 수 있는 개념으로 Six Sigma와 BSC 개념을 들 수 있다. 다음 그림(그림3)은 Six Sigma, BSC, 그리고 BPM을 통합하고 그 통합효과를 극대화해 조직을 운영할 수 있음으로 보여주는 다이어그램이다. |
|
|
이 모델은 각 개념의 단계들이 서로 상호 보완 할 수 있음을 보여 준다. 즉, BSC 의 KPI 를 위한 구체적 데이터들은 BPM의 프로세스로 정확히 수집이 가능함을 보여준다. 또한 6시그마의 개선과제 도출 단계는 BSC의 조직평가 및 BPM의 프로세스 개선 활동 단계와 구체적인 방법을 서로 보완해 활용할 수 있는 것이다. |
|
|
특히 Top-down 방식으로 구축을 진행할 때, 일반적으로 PI(Process Innovation) 을 선행한다. 이 절차는 기업 내 정해진 범위 안에 포합되어있는 모든 프로세스를 대상으로 한다. 범위에 따라 다르겠지만, 대상을 전사 전 조직으로 할 경우, 관리, 생산, 운영, 지원 등 기업의 거의 모든 업무절차를 대상으로 하게 된다. 이 때 식별되어 가시화된 프로세스들은 분석단계를 거쳐 개선사항을 포함한 TO-BE 프로세스 모델로 도출되게 된다. 이때, BPM 시스템의 초기도입 단계에서, 이 모든 AS-IS 프로세스들을 자동화 구현 대상으로 삼을 수는 없다. 조직의 프로세스에 포함된 업무들은 곧 기업의 업무수행 문화와 직결되기 때문에 이러한 프로세스들을 한번에 빅뱅 식으로 자동화 시켜서 진행하기는 어떤 조직이든 큰 부담이 될 것이다. 따라서 AS-IS 절차를 통해 식별된 프로세스는 BPM 시스템 탑재 후 자동화 도입효과 등을 고려하여 단계적으로 BPM 시스템 탑재를 계획하고 수행해야 한다. 즉, 각 단계가 마무리 될 때, 재무적 성과를 포함한 모든 성과들이 세심히 고려되어 다음 단계 진행을 위한 판단 근거로 활용되어야 한다.
단계적으로 자동화를 전개한다고 결정되면, 어떤 프로세스들 우선적으로 BPM 시스템에 탑재해야 하는가 에 대한 선정 방안을 마련해야 한다. 일반적으로 다음과 같은 기준으로 프로세스 자동화 도입을 우선 순위화 할 수 있다. (표 3, 4 참조) |
|
|
비즈니스 효과성은 프로세스의 정성적 및 정량적 적용효과를 말하며, 비즈니스 효과성이 클수록 Process 선정의 당위성이 크다고 할 수 있다. 또한 BPM 적합성은 한 개 이상의 부서가 연관되어 있는가, 관리되어야 하는 이유가 타당한가 등, 정형화시켜 관리하기가 적합한 업무인가를 판단하는 요소로, 클수록 BPM 도입의 당위성이 크다고 말할 수 있다. |
|
 |
|
이제 보다 구체적인 BPM기반의 시스템 구축을 위한 단계별 가이드를 알아보자. 일반적으로 분석/설계/구현/테스트/개선 등의 단계를 거치게 된다. 프로세스기반의 시스템 구축 역시 크게 다르지 않다. (그림 4 참조).
분석 및 설계를 위해 널리 사용되는 CBD방법론과 프로세스 방법론을 간단히 비교해 보면, 프로세스 기반의 설계 분석이란 무엇인지 보다 명확해 질 수 있다.
전사단위의 보안점검에서도 정해진 보안체크 리스트에 대해 모든 정보를 동일한 평가기준으로 진단하고 있지 않은지 의문시되기도 한다. 각 사업부, 부서단위에서는 핵심 정보자산에 대해 정의한 후 해당 자산을 보호하기 위해 수립된 보안관리 활동이 제대로 실행되고 있는지 진단을 하고, 그 결과로서 개선할 사항에 대해서는 적절한 보안시스템 지원활동이 필요하다.
컴포넌트기반 구현 방법론(CBD) 과 프로세스 기반 구현 방법론의 차이는 일반적으로 분석 대상에 대한 정의일 것이다. 즉 일반적인 CBD에서의 분석 및 추적대상은 기능이고 프로세스 기반 방법론의 대상은 프로세스 자체이다. 또한 분석방법에서도 두 방법론 간에 차이점이 존재한다. CBD방법론은 기능중심으로 활용 시나리오(유스케이스)를 분석하고 공통 기능(컴포넌트) 를 도출하는 것이 이 방법론의 기본 골격이다. 하지만 프로세스 방법론에서의 관리 대상은 프로세스이다. 즉 업무절차를 프로세스로 끌어내고 가시화 시킨 후 이 가시화된 프로세스를 놓고 기능을 도출하고 공통화된 기능을 컴포넌트로 묶어내는 것이 프로세스 기반 구축의 일반적인 절차이다. 이때 일반적으로 프로세스와 CBD의 유스케이스는 1:N 으로 연결될 수 있다.
표면적으론 이 두 방법론들은 분석 대상 및 절차상 분명한 차이점이 존재하고 이로 인해 서로 부조화를 이룰 것으로 생각되기 쉽다. 하지만 경험으로 비춰볼 때, 두 방법론은 서로 배타적으로 충돌하지 않는다. 오히려 두 방법론은 상호 보완하여 작용하여 보다 효과적인 분석/설계 방법을 제공할 수 있다. |
|
|
프로세스 모델이란 노테이션(Notation) 이라는 약속된 기호로 프로세스의 가시화시킨 업무 절차 흐름도를 일컫는다. 프로세스 모델은 AS-IS 혹은 TO-BE 단계에서 업무의 내용을 인식하고 가시화 시키는 도구로 사용될 수 있다.
프로세스 기반의 분석/설계 단계는 고객과의 인터뷰를 통해 고객 업무 흐름을 파악하는 과정부터 시작하게 된다. 이러한 과정에서 가시화를 가능케 하는 프로세스 모델링 도구는 매우 효과적으로 업무흐름을 고객과 공유할 수 있게 해준다. BPM 기반 시스템 구축에서 이러한 가시화된 프로세스 모델은 분석단계에서의 활용될 뿐 아니라 향후 설계 와 구현 과정에서도 왜곡 없이 일관되게 업무 흐름에 대한 시각을 유지해 준다.
이러한 프로세스 모델은 두 가지 레벨로 작성되는 것이 일반적이다. 우선 IT 적인 요소가 배제된 순수 Business 관점의 흐름정의를 레벨 1 정의라고 일컫는다. 이 레벨의 모델은 보통 업무담당자 나 수행자 혹은 프로세스 개선을 수행하게 되는 업종 컨설턴트들이 작성한다. 또 일반적으로 운영환경 등을 고려한 각 엑티비티에 대한 정규화나 역 정규화는 이 단계에서 수행되지 않는다. 따라서 이 프로세스 모델은 운영관점이 아닌 프로세스 정의 및 개선관점에서 작성되게 된다. |
|
|
다음으로 작성되는 레벨2 모델은 레벨 1을 기준으로 운영관점에서 각 액티비티에 대한 정규화 및 역정규화가 일어난다. 또한 프로세스 자체에 대한 정규화/역정규화를 통해 프로세스 자체를 합치거나 나누는 작업이 발생하기도 한다. 그밖에 레벨 2 모델은 실제 운영을 위한 모든 정보를 포함하고 있게 된다. 예를 들면 액티비티의 수행자, 역할, 수행시스템, DB와 관련이 있다면 대상 DB 스키마, 등 프로세스 운영을 위한 구체적인 설계서가 된다. 따라서 레벨 2 모델은 일반적으로 BPM 툴이 제공하는 모델러에서 작성되게 된다. |
|
| <그림 6>Operational Mode & Strategic Model |
|
프로세스 모델 작성에 단계를 두어 레벨을 관리하는 방식 이외에 프로세스 모델의 작성 목적 자체를 달리하여 프로세스 모델을 관리하기도 한다. 레벨 1, 레벨 2 식의 진행상의 단계분류가 프로세스 구체화 및 정규화 정도를 나타낸다면, 목적 별 구분은 그 활용목적이 다른 것이다. 이때 가장 흔히 구분하는 방식은 Operational Mode 과 Abstract 혹은 Strategic Model 이다.
(그림 6)에서 보는 바와 같이 Operational Model은 Process를 실행하기 위한 정보들을 포함한 실행 가능 모델이며, 과 Abstract(Strategic) Model 은 분석 및 모니터링을 위한 모델이다. 따라서 이 두 모델 들은 분명히 다른 존재 목적을 가지고 있으며 목적에 맞게 작성되고 사용되게 된다. BPM을 기반으로 하는 프로젝트를 수행하다 보면 이 두 모델이 서로 공존해야 하는 이유를 인정하지 않는 사례가 종종 있다. 이 두 모델 상의 액티비티들은 대부분 1:1로 매칭되지 않는다. (그림 7 참조) |
|
| <그림 7>Activities in Models |
|
즉, 두 모델의 수준을 한쪽 기준으로 맞출 경우 다른 한쪽 모델의 사용 목적에 어긋날 수 있게 된다. 따라서 두 모델은 각 모델의 목적에 맞게 활용되어야 하는 것이다. |
|
|
BPM 시스템을 활용하여 업무 시스템이 구성될 때 최종 사용자에게 제공되는 기능 중 기존 시스템과 가장 큰 차별성을 가진 부분이 업무의 접근 방식이다. 일반적으로 Menu Driven 방식으로 알려진 기존방식은 사용자가 미리 구성된 시스템의 메뉴체계에서 수행하고자 하는 업무를 찾아 들어가 해당 작업화면에 접근해 업무를 진행하는 형식이다. 그리고 다음 작업자에 의해 업무가 수행 될 때도 마찬가지로 작업자는 메뉴를 찾아 들어가 업무를 수행하게 된다. 이때 작업자들 간에 발생하는 커뮤니케이션은 일반적으로 기존의 여러 도구들, 예를 들면 전화, Instant Messenger, 메일 등이 활용된다.
BPM 이 도입되면 이러한 Menu Driven 방식이 Process Driven 방식으로 바뀌게 된다. 시스템이 Process Driven 방식으로 구축되면 작업자들은 각자의 업무 Tray를 할당 받는다. 이 Tray는 일반적을 To-Do List 라고 흔히 일컫는 작업폴더를 포함하고 있으며, 이 작업폴더를 기반으로 업무가 진행된다. 즉 작업자들은 수행해야 하는 업무화면을 수행해야 하는 정확한 시점에 이 To-Do List 폴더로 자동전달 받게 되는 것이다. 또한 작업 시 발생되는 작업자 간 커뮤니케이션은 BPM 이 제공하는 도구들로써 활용되게 된다. 이러한 작업방식의 변화는 다양한 형태의 업무생산성의 향상, 예를 들면, 업무처리의 정확성, 작업자 간 협업성 및 실시간 모니터링을 통한 신속한 업무진행 등으로 나타나게 된다. |
|
|
따라서 이러한 업무진행방식의 변화를 시스템 설계 초기부터 인지하고 전체적인 구조를 고려해야 한다.
그 외 기존 그룹웨어와 사용자중심의 통합작업 환경 구성 등 이미 사용자들이 익숙해진 작업환경을 적극적으로 수용하여 프로세스 기반의 업무시스템을 설계해야 한다. |
|
|
일반적으로 BPM의 도입효과는 Cost적인 측면 보다는 Productivity and Quality 에 관련된 측면이 강하다고 알려져 있다. 예를 들면, 의사 결정시간 단축, 유지보수 비용 절약, 인 당 생산성 향상, 인건비 절약, 품질향상, 오류감소 등. BPM의 구축 효과는 일반적으로 (표 6) 와 같다.
BPM 이 진정한 가치를 갖기 위해서는 도입초기부터 확실한 목표를 가지고 도입되어야 한다. 그래야만 BPM이 제공하는 여러 개념과 기능들을 사용하여 목표를 보다 구체화 시키고 실현시킬 수 있다. |
|
이상으로 BPM 도입 시 고려되어야 하는 몇 가지 주요 내용들에 대해서 언급했다. 최소한 일정 규모의 조직에서, 프로세스 관리의 필요성에 대한 이견은 없다. 이미 조직의 경쟁력은 그 조직이 가진 프로세스에서 나온다고 받아들여지고 있다. 과거 많은 기업들이 ERP를 도입함으로써 리소스 관리를 통해 원가 경쟁력을 확보했듯이 이제 많은 기업들이 BPM의 프로세스 관리/개선 기능들을 통해 조직경쟁력, 원가경쟁력을 확보해 나아가고 있는 것이다.
 |
|
“Enterprises that continue to hard-code all flow control, or
insist on manual process steps and do not incorporate BPM’s
benefits, will lose out to competitors that adopt BPM.”
- Gartner,
WSJ BPMR, June 2002 |
|
|
|
|
