|
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
In recent columns, we defined BPM (business performance management) and looked at the tangible benefits – quantifiable payback – it has delivered in practice. What follows is an overview of the steps you'll go through to bring performance management into your company.
Take a quick look at the project life cycle diagram in Figure 1. You'll find it reassuringly familiar, with project phases you'd expect to see – starting with requirements definition. However, before you call an information technology (IT) project manager into your office and ask him or her to give you BPM, you should recognize that performance management definitely packs some differences. This will not be your typical IT initiative.
Figure 1: BPM Project Life Cycle
It's instructive to look at what differentiates a BPM project from the software initiatives you have probably experienced in the last several years. With enterprise resource management (ERP) and customer relationship management (CRM), for example, the basic goals are well understood: you want to accurately record every transaction, customer, SKU (stock keeping unit) and shift of money. Because BPM is so young, there is no universal agreement on best practices, and simply deciding on the ideal functionality will trigger lengthy discussion. After assessing which business processes to engage with BPM, you'll then determine the number of existing systems in your company the BPM software will draw data from and what kinds of analysis will be most valuable.
You'll need to choose which department (s) to address and, in each of those areas, which business processes could have the highest performance improvement. It's typical to begin with the finance department, and finance is often the principal driver of BPM within a company. Often, the CFO's first priority is to focus on a thorny process such as budgeting. As was the case with ERP, it's important to pause and determine if the process itself is okay or needs reengineering. At most companies, of course, budgeting is regarded as broken at best, if not a perennial curse. Budgeting is also a logical starting point because it serves as the foundation for later analysis of performance against plan.
Other decisions that you'll make during requirements definition are rather strategic, such as whether to accompany the BPM project with a company-wide move to a unified chart of accounts. In multinational companies that have many subsidiaries and grew by acquisition, this can mean embarking on a major campaign of persuasion. In most BPM projects, the CEO is likely to get involved at some point. Whether or not your CEO takes a formal lead role, a BPM project needs a committed executive sponsor. The CFO may well be your overall project owner, and it's often necessary to involve other stakeholders at the C-level.
The requirements definition should lead to an effective request for proposal (RFP). It is important to address the requirements definition and prepare the RFP from three perspectives:
It's not a simple task to absorb what the different vendors offer. Vendors make claims that sound similar, and there are evolving differences of opinion on the definition of good and successful BPM. A balanced scorecard vendor could claim to have "full BPM," but might lack 70 percent of what you need. A tools vendor will naturally believe that the flexibility to program your own functionality is essential. Application vendors have their own prejudices. In the scramble to capture leadership, vendors are frequently updating and enhancing their product lines, and it's tough to stay current.
One major risk is that you'll end up buying from the vendor with the best marketing. There could well be vendors with outstanding products but mediocre marketing. As a result, you might overlook them and miss the best choice for your company. Another pitfall is buying more than you need. It's not unheard of for vendors to push their full suites into the initial sale or for a purchaser caught up in the excitement of BPM to load the shopping cart with all available options.
For these reasons, you can benefit from a methodical, structured approach to vendor selection that enforces apples-to- apples comparisons, not only of functionality, but also of architectural compatibility and the vendor's service and pricing fit. It's valuable to supplement your team with outside BPM expertise during the combined tasks of requirements definition and vendor selection because these phases are so critical to the overall success of the project.
Performance management projects have significant visibility and impact upon the enterprise. Because their dollar cost is typically less than that of most ERP projects, however, it is easy to underestimate their complexity. In our experience, performance management typically requires the implementation of multiple application components such as portals, planning and consolidation systems, and dashboards. The projects to implement these applications can overlap. To make things more complicated, the underlying technologies of OLAP, report and query, and ETL will need to be addressed along with creation of the BPM data mart – all in parallel with the applications you're implementing.
You can picture the range of personnel involved in these various activities and the management attention required. Your project teams within IT, departmental subject experts, staff from one or more vendors and external implementation and best practice experts from third parties may need to be meshed into the project task force.
All of these people and their projects must be coordinated in advance within a unified framework while adhering to a tight timeframe and budget and maintaining communications with your stakeholders. For overall management of the BPM initiative, you need someone who can step back for perspective while engaging with both the business and technology sides of the project.
There are risks in every IT project. However, it is asking a lot for even an experienced IT manager to arbitrate issues that can arise between the CIO, the CFO, the SVP of marketing and the CEO. Getting full ROI from the project may depend on insistence that every department, division and foreign subsidiary give up their treasured chart of accounts to adopt an unfamiliar new one that is company-wide. An outside expert in best practices or change management who is perceived as impartial and highly knowledgeable may be able to guide you and your team through the difficult phases.
The mechanics of piloting and parallel runs, training and evaluating the user reception are complicated by the fact that this will not be a single-department system. True BPM systems will be deployed across multiple departments, geographies and levels of users.
Successful BPM is heavily reliant on user acceptance and utilization, not only for data entry but for ongoing performance analysis as well. If not regularly used, your BPM project has likely missed the mark. When properly used, BPM lets the people who can exploit opportunities and respond to problems find them. That puts larger numbers of personnel in a position to improve profitability.
Craig Schiff, a pioneer in business performance management, helped create and define the space known first as analytic applications, then business intelligence and now BPM. He has published several articles, spoken at numerous BPM conferences. He is a recipient of the prestigious Ernst & Young Entrepreneur of the Year award. BPM Partners is a vendor-independent professional services firm focused exclusively on BPM, providing expertise that helps companies successfully evaluate and deploy BPM systems. Schiff may be reached at cschiff@bpmpartners.com or (203) 359-5677.
For more information on related topics, visit the following channels:
| [펌]SOA와 BPM, 그리고 플랫폼기반 BPM의 한계 (0) | 2008.03.13 |
|---|---|
| [BPM 컨설턴트 양성과정] (0) | 2008.03.12 |
| [펌]BPM 명확한 목표 수립에서 시작하라 (0) | 2007.12.06 |
| ALBPM 6.0 is Out (0) | 2007.08.23 |
| [모음]BPM 방법론 (0) | 2007.04.25 |
현재 BPM시장에서 SOA에 대한 관심이 뜨겁다. 주지하는 바와 같이 SOA는 느슨하게 결합될 수 있고, 재활용도가 높은 컴포넌트(서비스)에 기반하여 어플리케이션을 개발하고자 하는 아키텍처 모델이다. 기업은 SOA를 통해 솔루션들간의 상호운용성을 확보하고, 개발비용을 감소시키며, 비즈니스적인 요구에 대응하는 민첩성을 확보하고자 한다.
SOA가 애플리케이션들을 서비스로 추상화시켜 제공한다면, BPM은 SOA가 제공한 서비스들을 프로세스에 맞게 정렬하여 그 흐름을 통제하는 것이라고 둘간의 관계를 정의할 수 있다. 이러한 연관성 때문에 많은 전문가들이 향후 BPM시장에서의 화두는 SOA지원이라고들 한다.
여기에는 긍정과 부정이 교차한다. SOA기반으로 구축된 어플리케이션 요소들을 BPM이 그 흐름을 통제하고 자동화해야하는 점에서는 긍정적이지만, 가트너의 정의에서처럼 "BPM은 민첩성과 운용 효율을 증대하기 위해, 비즈니스 프로세스 환경을 통제하는 일상적인 경영 활동"이라는 점과 더불어, BPM이 아키텍처 모델로서의 SOA를 뛰어넘는 다양한 경영활동 프랙티스들을 제공해야 한다는 점에서 부정적인 것이다.
이것은 SOA가 새로운 애플리케이션을 구축하기 위한 기술 아키텍처의 개념인 반면에, BPM은 프로세스 기반의 경영을 지원하는 총괄 프레임워크라는 관점에서 조명되어야 하기 때문이다.
BPM과 SOA를 융합하고자 하는 다양한 시도가 이어지고 있다. SOA가 지향하는 저비용구조의 비즈니스 민첩성을 실현하기 위해선 무엇보다 SOA자원들을 관리하고 그 자원들을 프로세스에 맞추어 업무수행의 경쟁력을 확보할 수 있도록 하는 BPM의 중요성이 더욱 부각되고 있는 실정이다. 다시 말하면, BPM이 개입되지 않고서는 SOA는 막대한 전환비용만 소요될 뿐 단순히 개발비용 및 유지보수주기를 소폭 감소시키기만 하고, 프로세스 혁신을 통한 궁극적인 경쟁력 확보는 요원하게 된다.
SOA의 도입효과를 최대화하고, 성공적인 SOA기반 시스템 구축을 위해 BPM이 지원해야 할 특성들을 조망해보면, 다음 네가지로 압축시켜 볼 수 있다.
첫째, [시스템 커버리지]
SOA기반 시스템구축을 위해 SOA뿐만 아니라 Non-SOA도 수용이 가능하여야 한다. 역설적인 표현이나, 현재로선 파일럿 성격으로 제한된 범위 내에서 SOA를 적용하고자 하여도, BPM이 목적하는 End-to-End 프로세스 구현을 위해선 상당수의 Non-SOA 요소를 수용하지 않고서는 BPM 효과를 달성하기 어렵기 때문이다. 여기서 Non-SOA 요소란 현장 작업자들과 인터랙티브하게 작동하는 대다수의 어플리케이션들이나, 웹서비스로 전환하기 힘든 C/S기반 솔루션들을 일컫는다.
둘째, [플랫폼 중립성]
BPM은 플랫폼에 중립적이면서, 이질적인 플랫폼들을 통합할 수 있어야 한다. 플랫폼 기반의 업체들이 자사의 기존 제품라인을 SOA개념에 맞게 재정렬하여 수직일관 체계를 구축하였다고 하고, 해당 제품들간의 통합성을 자랑한다. 그러나 기업내 다양한 플랫폼이 상존해 있는 현실과, SOA를 활용하는 BPM의 역할이 다양한 IT자원들을 통합하고 조율하는 것임을 상기하면, 고객에게 독이 될 수 있는 처방을 제시한 셈이 된다.
셋째, [IT자원 재활용]
기존의 IT자원을 최대한 재활용 할 수 있어야 한다. SOA의 주요 역할자로 부상한 ESB는 기존의 EAI 솔루션의 새로운 마케팅 컨셉에 다름 아니다라고들 한다. 따라서 독자적인 ESB 솔루션도 제시할 수 있어야겠지만, 고객사에 기구축되어 있는 EAI 인프라를 SOA의 주요모듈인 ESB 백본으로 활용할 수도 있어야 한다.
마지막으로, [업무중심의 BPM]
SOA에서 파생된 BPEL 표준만으로는 기업현장 작업자들의 Task를 프로세스로 재편하는데 한계가 있다. 프로세스 관리의 핵심인 업무를 조정할 수 있는 BPM 모듈의 관리하에, BPEL은 시스템연계의 측면에서 활용되어야 한다. BPEL의 용도는 메시지연계 및 웹서비스 호출에 집중되어 있어 수년간 워크플로우 기반 BPM에서 축적해온 다양한 업무규칙, 작업환경 설정등을 지원하는 측면에선 한계가 있기 때문이다.
위에서 언급한 SOA를 지원하는 BPM의 특성을 면밀히 살펴보면, 플랫폼 기반의 BPM 솔루션이 가지는 한계를 발견하게 된다. 웹서비스 등 SOA 요소들에 편향된 채, Non-SOA에 대한 해결책을 제시하지 못하고 있는 점과 [시스템 Coverage], 자사의 제품라인에 속한 플랫폼만을 강조함으로써 전사범위의 통합 이미지를 제시못하고 있는 점과 [플랫폼 중립성], EAI솔루션 등 기존의 IT자원에 대한 재활용 전략을 제시하지 않은 채, 고객에게 막대한 전환비용을 제시하는 점과 [IT자원 재활용], 업무 프로세스를 관리하기엔 아직은 데이터 연계에 편향된 BPEL기반으론 어려운 측면[업무중심의 BPM]이 바로 그 한계이다. 그러나 이러한 기술적인 면에 집중하면서 우리가 간과하게 되는, 보다 근본적인 한계가 플랫폼기반의 BPM솔루션에 존재한다.
SOA와 더불어 격변하는 시장환경에서 경쟁사 대비 우위의 경쟁력을 확보할 수 있는 도구이자, 생존의 전략으로까지 제시되는 BPM의 가치는 무엇에 기인하고 있는가? 서두에서 밝힌 바와 같이 "BPM은 민첩성과 운용 효율을 증대하기 위해, 비즈니스 프로세스 환경을 통제하는 일상적인 경영 활동"으로 정의할 수 있다. 총론의 관점에서의 BPM의 가치는 전사 프로세스의 가시화, 자동화, 성과중심의 업무체계 정립, 부분이 아닌 전사관점의 최적화 등을 들 수 있고, 각론에서는 현장에서의 다양한 업무규칙, 일관된 작업환경, 동적인 작업배분, 전략실행단위로서의 KPI설정, 모델링에서부터 실행/모니터링/피드백에 이르는 통합운영환경의 구축 등을 들 수 있다.
단순히 기술적 접근만으로는 해결할 수 없는 다양한 담론들을 포함하고 있다. BPM솔루션은 경영활동과 관련된 다양한 Best Practice를 지원하고 있어야하며, 이러한 Best Practice들이 고객의 프로세스에 내재화되면서 그 고객사만의 고유한 프로세스로 지속적인 혁신이 가능한 기반을 구축할 수 있어야 한다.
단순히 트랜잭션과 데이터 연계, 기존의 컴포넌트를 웹서비스로 전환/배포하는 기능들에 집중된 플랫폼 기반의 BPM 솔루션만으로 BPM의 가치를 실현하기는 어렵다. 플랫폼 기반의 BPM솔루션은 지극히 트랜잭션 및 데이터연계에 편향적이고, 지극히 범용적이며 포괄적인 솔루션을 제시하고는 구체적인 시스템 완성의 책임을 고객에게 전가하고 있다. 우리가 플랫폼기반의 BPM업체들을 우려의 시각으로 바라보는 이유가 바로 여기에 있다.
<출처 : http://www.bloter.net/_news/8df427eb1c2ef70c>
| [펌]Getting Started: The BPM Project Life Cycle (0) | 2008.07.30 |
|---|---|
| [BPM 컨설턴트 양성과정] (0) | 2008.03.12 |
| [펌]BPM 명확한 목표 수립에서 시작하라 (0) | 2007.12.06 |
| ALBPM 6.0 is Out (0) | 2007.08.23 |
| [모음]BPM 방법론 (0) | 2007.04.25 |
 |
|
BPM 컨설턴트 양성과정 주요일정 | ||||
|
일시 |
강의 주제 |
주요 내용 |
시간 | |
|
1회 (4/10 목) |
Orientation 및 간담회 |
1 | ||
|
BPM과 경영혁신 |
2 | |||
|
2회 (4/15 화) |
BPM의 혁신 라이프사이클 | - BPM의 혁신 라이프사이클 - BPM의 혁신 라이프사이클을 지원하는 BPM 방법론 (Biz. Process Excellence Methodology) 개요 - 목표설정 및 추진전략의 수립 - 단계별 목표와 중점 추진 사항 - 추진조직 및 역할/책임 |
3 | |
|
3회 (4/17 목) |
프로세스 아키텍처 수립과 프로세스 개선 |
- 프로세스 아키텍처 개요 (정의, 요건, 목적) - 프로세스 아키텍처 수립 방안 - 프로세스 프로젝트 정의 - 프로세스 분석/개선을 위한 핵심 규칙 |
3 | |
|
4회 (4/22 화) |
비즈니스 프로세스 분석 | - 프로세스 정보 수집 기법 (인터뷰, 워크샵, 질의서 등) - 프로세스 모델링 개요 - 프로세스 식별 기법 |
3 | |
|
5회 (4/24 목) |
비즈니스 프로세스 분석 핵심 기법 |
- As-Is End-to-End 프로세스의 매핑 - 프로세스 분석 기법 - 프로세스 정의 양식 |
3 | |
|
6회 (4/29 화) |
비즈니스 프로세스 재설계 (I) | - 프로세스 분석 워크샵 - As-Is 프로세스의 문제 정의 - 프로세스 재설계의 범위 및 정의 |
3 | |
|
근로자의 날 휴강 (5/1일) | ||||
|
7회 (5/6 화) |
비즈니스 프로세스 재설계 (II) | - 프로세스 재설계의 기준 및 옵션 - 프로세스 재설계 워크샵 |
3 | |
|
8회 (5/8 목) |
프로세스 성과측정 및 지속적 프로세스 개선 |
- 프로세스 성과측정 개요 - 프로세스 KPI 정의 및 측정 기법 |
3 | |
|
9회 (5/13 화) |
프로세스 구현 및 실행 | - 솔루션 평가 기준 - 구현 준비 - 구현단계 핵심 이슈 |
3 | |
|
10회 (5/15 목) |
프로세스 운영 및 지속적 개선 | - 모니터링 절차 및 방법 - 프로세스 유지 및 변화 관리 - 지속적인 프로세스 개선 |
3 | |
|
11회 (5/20 화) |
성공 사례 분석 | - 업종별 국내 사례 소개 - 금융, 정부공공, 제조 등 |
3 | |
|
12회 (5/22 목) |
팀 프로젝트 발표 및 Wrap up |
3 | ||
|
(상기 일정, 내용을 기본으로 하며 강사사정에 의해 일부 일정 조정될 수 있습니다.) |
 |
| [펌]Getting Started: The BPM Project Life Cycle (0) | 2008.07.30 |
|---|---|
| [펌]SOA와 BPM, 그리고 플랫폼기반 BPM의 한계 (0) | 2008.03.13 |
| [펌]BPM 명확한 목표 수립에서 시작하라 (0) | 2007.12.06 |
| ALBPM 6.0 is Out (0) | 2007.08.23 |
| [모음]BPM 방법론 (0) | 2007.04.25 |
| BPM 명확한 목표 수립에서 시작하라 |
출발점이 다르듯 목표에 이르는 길도 여러 갈래이며, 그 방법과 방향은 오직 사용자만이 알고 있다. 기사 개요 ■ 최근의 BPM 도입 경향 ■ BPM 구축이 어려운 이유 ■ 주요 기업의 적용 사례 소개 ■ 성공적인 BPM 체계 구현 방법 기업들의 BPM 접근 방법이 예년과는 다른 양상으로 전개되고 있다. 기업내 일부 단위 업무 프로세스의 시스템화가 아닌 전사 업무 프로세스의 재정립을 통한 지속적인 프로세스 개선 활동에 초점을 맞추고 있는 것이다. 1990년대 중반 이후 기업들은 프로세스 경영을 외치며 ERP 도입과 함께 BPR과 PI를 위주로 하는 업무 효율화 작업을 반복적으로 수행해왔다. 하지만 최근 들어서는 업무 자체의 효율화보다 근본적인 전사 업무 프로세스의 재정립과 함께 이를 자동화하는 BPM 체계 구축에 더 많은 관심과 노력을 기울이고 있다. 이에 따라 여러 업종별 수위 기업들이 BPM의 가치에 새롭게 주목하고 있으며, 그 가치를 실현하기 위해 전사 업무 프로세스 표준화를 핵심으로 하는 다각적인 접근 방법을 선택하고 있다. 특히 최근의 추세는 기존 IT 조직 주도의 워크플로우 식 접근 방법과는 달리 현업과 PI 추진조직에 의해 업무 프로세스를 가시화하는 작업이 추진되고 있어 긍정적인 접근이라는 평가를 얻고 있다. 이들 기업이 BPM을 통해 얻고자 하는 궁극적인 목표는 경쟁력의 확보에 있을 것이다. 기업들은 오랜 기간 경쟁력 확보를 위해 자원의 최적화, 업무 효율성 제고, 전략경영의 실현 등에 주력해왔다. 여기에 BPM은 프로세스 중심의 업무 활동을 통해 최적화된 자원 배분으로 업무 효율을 높이고, 기업이 추구하는 경영 전략을 올곧게 실현할 수 있도록 해주는 여러 기능을 제공하면서 점차 중요성을 인정받고 있다. 그리고 BPM은 이러한 과제에 대해 기업의 모든 활동을 프로세스 중심으로 가시화함으로써 지속적인 변화 요구에 대응할 수 있도록 해주는 기본 틀이자 핵심 도구로 평가되고 있다. 여기에서 BPM이 기업의 변화 요구 대응을 가능케 한다는 것은, BPM을 통해 프로세스를 표준화하고, 유연한 프로세스 생성 및 변화 관리 구조를 갖춰 급변하는 경영환경에 대처할 수 있게 해준다는 다소 이상적인 의미일 수도 있고, 기존 업무 프로세스를 가시화하고 자동화함으로써 일하는 방식을 개선하고, 이를 통해 업무 효율과 생산성을 함께 높여 목표한 경영 성과를 달성하도록 한다는 현실적인 개선의 의미로도 해석될 수 있을 것이다. 하지만 분명한 것은 이 두 가지 모두 기업 경쟁력을 높이고 그에 따른 경영 전략을 실현하기 위한 핵심 도구로써 BPM의 가치를 인정하고 있다는 점이다. BPM 구축이 어려운 이유 최근 들어 각 산업별 수위 기업을 위주로 BPM 체계 구축을 위한 시도와 접근이 이뤄지고는 있지만 전사 차원에서 이를 구현하고자 하는 기업은 아직 손에 꼽을 정도에 불과한 실정이다. 대다수의 기업이 초기 상황에서 일부 단위 업무 프로세스에 대한 파일럿 프로젝트를 진행하거나 본격적인 프로세스 정립을 위한 준비 작업을 하고 있기 때문이다. 프로세스를 그릇에 담는 자동화 이전의 표준 프로세스 생성 및 가시화에 단계적인 목표를 두고 추진하는 기업이 대부분이라는 얘기다. 따라서 시스템 측면의 활동이 아닌 BPM 실행 전략 방법론이 중시되고 있고, 전문업체들도 과거 BPM 솔루션을 중시하던 상황에서 최근에는 BPM 수행 도구를 좀 더 강조하는 쪽으로 제품 전략을 수정하고 있다. 그렇다면 1990년대 프로세스 경영론이 등장하면서부터 회자되기 시작했던 BPM이 아직까지 기업 사용자의 지지를 폭넓게 받지 못하는 이유는 무엇일까? 이에 대한 해석은 사용자나 공급자 양측의 입장에서 살펴볼 수 있다. 우선 공급자 측면에서는 기업들이 추진해온 파일럿 프로젝트 결과가 상당 부분 만족스럽지 못했다는 점을 이유로 꼽는다. 리얼웹의 손정민 차장은 "지난 1~2년 사이 워크플로우 제품을 적용해 파일럿 프로젝트를 수행했던 많은 기업들이, 기대만큼의 성과를 거두지 못함에 따라 아직까지 전사 차원의 비즈니스 프로세스 혁신 작업에 나서는 기업이 생각 외로 적은 상황이다."라고 말했다. 손정민 차장은 그 요인으로 "기업들이 상대적으로 BPM 구축 효과를 보기 어려운 비 핵심 업무 위주의 파일럿 프로젝트를 진행해 기본적인 성과 개선의 한계가 있었기 때문이다."라고 설명한다. BPM의 성과를 극대화하기 위해서는 다양한 부서에 걸쳐 많은 사람들이 관여하는 중요도가 있는 업무를 대상으로 해야 하는데, 기존의 파일럿 프로젝트는 대부분 업무 중요도가 낮고 빈도수 역시 낮은, 그래서 BPM 툴을 적용하기에 쉬운 분야를 위주로 한 경우가 많았다는 것이다. 그러니 ROI가 낮을 수밖에 없다고 손정민 차장은 덧붙였다. BPM에 대한 분명한 도입 목적을 세우지 않고 접근해 실패하는 기업이 많다는 점도 문제로 지적되고 있다. 리얼웹의 전희철 연구소장은 "국내 대기업의 BPM 프로젝트를 여러 차례 수행하면서, 그때마다 BPM의 목적을 물어봤지만 대부분 업무 현황의 가시화라고 답한다."며, "하지만 이는 답이 아니다."라고 고개를 젓는다. "기업이 BPM을 통해 얻고자 하는 것이 무엇인지 구체적인 목적을 가져야 하는데, 이것이 명확하지 않기 때문에 대부분의 파일럿 프로젝트는 실패로 끝나고 만다. 접근 방식이 틀렸기 때문이다. 무엇을 얻을 지 정확히 파악해야 하며, 그러지 못하면 윗사람 설득도 힘들다."고 전희철 소장은 조언한다. BPM 접근 구현의 혼돈 반면 사용자 입장에서는 BPM 솔루션 벤더들이 제품의 기술과 기능에만 지나치게 초점을 맞춰 경쟁적인 메시지를 내보내다 보니 사용자들이 혼란을 겪게 됐다는 점을 지적하고 있다. BPM 분야 후발업체인 티맥스소프트의 김찬수 전략 마케팅 부장은 "워크플로우 기반의 BPM 진영과 EAI 기반의 BPM 진영으로 나뉘어 제품의 차별화된 기능 알리기에만 급급했지, 상대적으로 제대로 된 구축 방법론이나 접근 전략을 세련되게 가다듬는 노력은 부족했던 게 사실이다."라고 선발 벤더들을 질타했다. 한국CA 홍경효 수석 컨설턴트도 "사용자들이 그동안 BPM에 대해 접근 구현의 혼돈을 겪어온 것이 사실."이라며, "이러한 이유로 아직 대다수의 기업들이 BPM 도입에 주저하고 있다."고 의견을 더했다. GS홈쇼핑 PI팀의 김주연 과장은 "업무 프로세스 개선 효과를 올바르게 평가할 수 있는 방법이나 기준을 찾는 일이 쉽지 않다."며, "공급자 측에서 이러한 문제를 보완해 제품과 함께 제시하려는 노력을 해야 한다."고 주문한다. BPM의 ROI 효과를 명확히 분석해 내기가 쉽지 않으며, 공급자 측이 BPM의 구현 목적이나 방법에 따라 각기 상이한 결과가 나타날 수 있다는 점만 강조, 분명한 성공 방법론을 제시하지 못하는 점이 해결되어야 한다는 것이다. GS홈쇼핑 이창진 PI팀장도 "아직 국내 기업들이 BPM 구축 이후 활용 단계에 대한 고민을 크게 하지 않고 있는 것도 사실이지만 제품 공급사 입장에서 해외사례라도 발굴, 소개해 다양한 활용 방법을 제시해야 한다."고 요구했다. 결과적으로 단위가 아닌 전사 업무를 대상으로 한 비즈니스 프로세스 체계를 재정립하기 위한 방법론이 검증되지 않았거나 산업별, 기업별 고유 업무 프로세스를 표준화하는 과정이 쉽지 않다는 점, 이러한 여러 부정적인 경험을 바탕으로 경영진의 후속 투자를 이끌어 내기가 쉽지 않고, BPM에 대한 확신을 갖기 어렵다는 점 등이 아직까지 대부분의 기업을 초기 상황에 묶어 놓고 있는 이유라 할 수 있다. 하지만 한국CA 홍경효 수석 컨설턴트는 BPM이 IT와 비즈니스의 중간에서 이를 이어주는 도구로서 가치가 있다고 설명한다. 홍경효 수석컨설턴트는 "BPM의 가치는 프로세스의 자동화, 가시화뿐만이 아니라 현업 담당자와 IT 사용자가 같은 그림을 보면서 의사소통을 할 수 있게 해주는 유용한 도구라는데 있다."고 평가하고, "BPM의 필요성에도 불구하고 그 구현에 리스크가 크다는 점 때문에 시행착오를 줄이고, 적합한 방법론 찾아가며 단계적으로 접근하는 상황."이라고 현재의 상황을 설명한다. 이처럼 최근 기업들은 부분 업무에 대한 IT 차원의 접근 방법의 오류를 인정하고 전사 프로세스와 각 프로세스 간 연관 관계 분석부터 다시 시작해야 한다는 데 인식을 모으고 있으며, 따라서 이러한 추세를 반영해 올해가 전사 프로세스 표준화의 원년이 될 것이라는 전망을 내놓는 벤더 관계자도 나타나고 있다. 내년부터는 핵심 프로세스부터 BPM화하는 추세가 본격 확산될 것이며, 이는 전적으로 현업의 주도하에 이뤄질 것이라는 구체적인 전망도 대두되고 있다. 주요 기업의 적용 사례 그렇다면 실제 기업들은 어떤 도입 목적을 가지고 BPM 체계를 구축하고 있을까? 서두에서 밝혔듯이, 성공적인 BPM 체계 구축은 명확한 도입 목적을 세우는데서 시작되는 먼 여정과 같다. 각사별 경영 환경이나 고유의 업무 특성을 감안해 서로 다른 시작점에서 서로 다른 목적을 지향하기에, 그 목표에 이르는 길은 여러 갈래일 수밖에 없으며, 그 목적지에 이르는 방법과 방향은 오직 사용자만이 알고 있다. 이른바 BPM 전문가들은 기술적인 안내자일 뿐, 개별 기업의 고유 비즈니스까지 속속들이 알고 있기는 어렵다.(참고로, 최근 BPM 체계를 고민하는 기업 가운데는 외부 전문가나 컨설턴트를 영입하거나 아예 자체 컨설팅 역량을 키워 업무 프로세스의 지속적인 개선을 전담토록 하는 곳이 여럿 있다. 기업의 핵심 자산화 되고 있는 프로세스를 직접 관리, 운영하고자 하는 요구와 함께 업무 프로세스 개선을 위해 때마다 큰 비용을 들여가며 외부 컨설턴트의 지원을 받는 데 부담을 느끼는 기업이 늘고 있기 때문이다.) 하지만 앞서 BPM 체계 구축을 추진하고 있는 주요 사례를 통해 일말의 경험과 교훈을 얻을 수 있을 것이다. 최근 드러나는 주요 사례를 통해 기업들의 BPM 도입 배경을 살펴보면, △PI 프로젝트 이후 지속적으로 변화하는 프로세스의 시스템화 △표준 업무 프로세스를 정립해 비효율적인 업무 체계 개선 △비정형화, 비시스템화된 업무 프로세스를 자동화해 비용절감 실현 등에 대한 요구가 비교적 높다는 것을 알 수 있다. 프로세스 기반의 업무 개선 사례 국내 유통업계에서 가장 먼저 BPM 체계 구축을 추진하고 있는 GS홈쇼핑은 현재 전사 업무 프로세스의 가시화를 마무리한 단계에 있다. GS홈쇼핑은 ERP 시스템 구축에 이어 지난해 12월부터 전사 차원의 업무 프로세스 표준화 프로젝트를 추진하고 있다. GS홈쇼핑은 전사 업무 프로세스의 가시화를 통해 업무 지연이나 오류를 줄이고, 문제 발생 시 신속하게 대처할 수 있도록 한다는 데 일차 목표를 두고 지난 2월 MD 상품 소싱 업무에 파일럿 프로젝트를 실시, 전사 확대를 위한 기준을 만들었다. 이후 GS홈쇼핑은 전사 업무프로세스를 상위프로세스, 상세프로세스, 액티비티의 3단계로 분류한 후 이를 기반으로 상품을 고객에게 전달하기 위한 영업 관련 모든 업무 프로세스(상품 소싱, 구매, 영업, 배달, 회계)의 개선 활동을 진행, 프로세스를 업무 중심으로 재구축했다. GS홈쇼핑이 이처럼 프로세스 정립과 가시화에 초점을 둔 것은 홈쇼핑 전문업체로서 "속도 우선"이라는 고유 업무 특성을 반영하면서 업무 프로세스가 크게 복잡해지는 문제를 개선하기 위해서였다. 고객이 원하는 상품을 가장 빠른 시간 내에 전달해야 한다는 업무 특성상, 모든 판단을 거의 실시간으로 내릴 수 있도록 유연한 프로세스를 만들어 사용하다보니 프로세스의 복잡성이 상대적으로 높아졌고, 문제가 발생하더라도 원인 파악과 대처에 많은 시간이 걸리는 어려움이 상존해 있었던 것이다. 프로세스 가시화 프로젝트가 완료됨에 따라 GS홈쇼핑은 기존 ERP 환경에서는 단위 업무 안에서만 프로세스를 파악할 수 있었던 데서 연속적인 형태로 업무 프로세스를 파악할 수 있게 됐으며, 기존 방식으로 업무를 처리하되, 표준 업무 절차를 참고해 단계적으로 일하는 방식을 바꿔 나가도록 권고하는 체계를 갖췄다. 그 결과 업무 절차가 과거와 달리 가시화됨에 따라 직원들이 업무 방식의 개선에 관심을 갖게 됐고, 그 아이디어를 업무 프로세스에 바로 반영할 수 있게 되었다. GS홈쇼핑은 현재 1단계 프로세스 정립 및 가시화 이후 성과를 보아가며 내년부터 일부 프로세스를 자동화하는 방안을 고려중이다. 하지만 이미 프로세스를 정립하고 가시화하는 데 성공한 만큼 이를 관리하는 것은 물론 자동화하는 과정도 용이하게 진행 할 수 있을 것으로 보고 있다. 동부화재는 표준 업무 프로세스를 정립해 비효율적인 업무 체계를 개선한 사례로 볼 수 있다. 전사 차원의 경영 혁신 프로젝트를 추진하고 있는 동부화재는 그 일환으로 올 초부터 업무 프로세스를 새로 정립하면서 동시에 직무 분석을 실시했다. 이 회사는 BPM 툴을 이용해 4만 여 업무 프로세스를 모델링하고 매핑해 직무간 연관성을 분석한 결과, 직무 분석이 일차 완료된 상태에서 15%의 비 표준화된 직무를 발견했으며, 이를 줄이는 데에서만 30%의 비용 절감 효과를 기대하고 있다. 현재는 그 성과를 바탕으로 계열사의 업무 프로세스 분석 작업을 확대 추진하고 있다. 시스템 기반의 프로세스 개선 사례 포스코건설은 PI 이후 변화하는 프로세스의 시스템화를 추진하는 사례이다. 포스코건설은 지난 3년 동안 베어링포인트와 PI 프로젝트를 추진해온 데 이어 올 초부터 그 결과를 전사 프로세스에 적용하는 작업을 진행하고 있다. PI 결과 도출된 포스코건설의 프로세스는 건설, 지원, 하청업체 관리 등 총 4000여 개로, 이를 혁신하는 데만 꼬박 3년이 걸렸다. 하지만 이 회사는 PI 프로젝트 마무리 시점에서 초기에 작업한 프로세스가 바뀌어 현재와 맞지 않는다는 점을 발견, 프로세스를 모두 분석한 결과 그동안에 변화된 프로세스가 전체의 40%에 달한다는 것을 알게 됐다. 여기에서 포스코건설은 프로세스를 시스템화해 관리하지 않으면 쉼 없이 바뀌는 프로세스에 보조를 맞출 수 없다는 점을 깨달았다. 그래서 포스코건설은 올해 들어 프로세스 라이프사이클을 관리할 수 있는 시스템 구축을 추진하고 있으며, 일부 완성된 표준 업무 프로세스에 대해서는 내년부터 BPM 시스템으로 자동화할 계획이다. 포스코건설의 영향을 받아 포스코도 오랜 기간 심혈을 기울여 추진해온 PI 결과를 전사 프로세스 모델링 및 매핑한 후 중요 부분부터 BPM 툴로 자동화한다는 방침에 따라 현재 전사 업무 프로세스의 재정립 작업을 추진하고 있다. 피자헛은 프로세스 기반의 지식관리 환경을 갖춘 사례다. 피자헛은 신상품으로 스파게티의 개발에 나서면서 약 3개월 동안 사업 타당성에 대한 조사를 진행했는데, 조사 막바지에 이와 같은 조사를 3년 전에 이미 내부에서 실시했었다는 사실을 알게 됐다. 이 회사는 문제의 원인이 기존에 구축한 KMS가 일체 활성화되지 않는데 있다고 판단, BPM 툴을 이용해 표준 업무 절차를 만들고 이를 준수해 일을 하면 그 산출물이 자동으로 KMS에 반영이 되도록 시스템을 연동 구축했다. 이후 새로 업무를 처리할 때는 과거의 경험과 지식을 반영해 중복된 자원과 비용을 줄이도록 했다. 글로벌 경영전략 실현 사례 삼성전자는 전세계 70여개의 사업장을 대상으로 비정형화되고 비시스템화된 재무 및 물류 등의 업무를 표준화하고 이를 BPM 기반으로 전환하는 "e-오피스" 프로젝트를 지난 2003년부터 추진, 올해 말 완성을 목표로 하고 있다. 삼성전자는 이번 프로젝트를 위해 가장 먼저 비정형화되고 비시스템화된 업무를 자동화하기 위한 표준 템플릿을 BPM 솔루션 업체인 비투비인터넷과 공동 개발했다. 이어 지난해 2월부터는 전세계 법인을 7개의 권역으로 나누고 이를 2개의 전담팀을 동시 가동해 BPM 시스템을 구축하는 작업을 실시해오고 있다. 이 과정에서 구축 전담팀은 현지 법인 사용자들과의 면담을 통해 기본 업무 특성과 문제점을 파악, 표준 업무 프로세스를 도출하고 모델링해, 표준 템플릿을 기반으로 한 BPM 시스템을 구축하는 작업을 추진하고 있다. 삼성전자는 기본 템플릿 위에 현지 업무 특성을 고려한 프로세스를 디자인하고 분석 모델링하는 단계를 거쳐, BPM 엔진을 이용해 프로세스를 실행하도록 하고, 그 결과를 실시간 모니터링해 분기별, 반기별로 분석하는 새로운 사이클을 가동함으로써 지속적으로 개선 가능한 프로세스를 운영하고 있다. 삼성전자 경영인프라 T/F 민경기 과장은 e-오피스 구축 효과로 △현저한 대기 시간의 감소 및 일인당 생산성 향상 △제품의 질 향상 및 오류 감소와 수많은 업무 절차 단축 △필요 인력의 최소화와 관리 및 태스크의 자동화 △업무 처리 비용의 감소와 외부 사용자의 확장 가능성 △규정 준수의 증가 및 유연성, 민첩성 증가 △위험 요소 감소 및 불필요한 낭비 절감 등의 효과를 거두었으며, 글로벌 ERP 시스템 구축을 위한 사전 경험을 획득할 수 있었다고 말했다. BPM의 주요 기능과 개념 리얼웹의 전희철 연구소장은, 성공적인 BPM 체계 구축을 위해서는 전사 표준 업무 프로세스 맵을 먼저 만드는 것이 중요하다고 강조했다. 전사 업무 표준화부터 정립해야 어떤 업무에 우선순위를 둘 것인지, 어떤 프로세스를 먼저 개선할 것인지, BPM을 통해 얻고자하는 목표가 무엇인지 분명해지게 된다는 설명이다. 전희철 소장에 따르면 BPM의 적용 분야는 매우 다양하지만 기존에 적용되었던 BPM의 기능은 다음의 7가지 항목으로 요약할 수 있다. 1. 프로세스 성과 관리를 통한 프로세스 개선 : BPM의 프로세스 성과 관리 기능을 통해 프로세스/업무의 성과를 모니터링한다. 전략 실현에 문제가 발생한 프로세스의 성과를 적절히 통제하며, 현재의 프로세스로는 전략 실현이 불가능한 경우 프로세스 개선을 통해 전략을 실현하도록 한다. 2. 업무 프로세스 자동화 : BPM의 업무 자동화 기능은 업무 실행 시간(Cycle Time)을 기준으로 프로세스를 개선하는 방법론을 제시한다. 측정된 평균 수행 시간과 분산을 사용하여 병목구간을 분석한 후 개선안에 대한 검증은 실행 시간 시뮬레이터를 사용한다. 3. 프로세스 기반의 지식관리 : 전사 업무 프로세스와 전사 지식 맵간의 연계 정보를 작성한다. 작성된 연계정보는 기본적으로 웹상에서 공유되어 업무 중심의 검색이 가능하게 되며, 워크플로우가 적용된 업무의 경우 워크플로우 엔진은 업무 수행에 필요한 지식을 자동으로 공급하고, 업무 수행 결과인 산출물은 지정된 지식 저장고에 자동으로 보관된다. 4. 프로세스 표준화/업무 매뉴얼/변화 관리 : 표준 직무와 프로세스를 확립하고 업무 중심으로 타 정보를 모두 연계한다. 작성된 프로세스 리파지토리는 BPM 적용 시 효율적으로 활용될 뿐 아니라 IT 시스템 개발 및 6시그마, BSC, 품질 경영 등 타 경영 시스템에도 즉각 활용될 수 있다. 5. 프로젝트 업무 관리 : 기업내 R&D, 제품/서비스 개발, 투자, 수주 영업, 제품 제조와 같은 프로젝트 성격이 강한 업무에 프로젝트 관리 시스템(PMS)을 구축, 운용한다. 이러한 프로세스는 동적인 특징이 있어 업무 중심보다 산출물 중심으로 시스템을 구축, 운용한다. 최근 PMS에 BPM을 적용하는 추세가 늘고 있다. 6. Agile IT 시스템 개발 : 내외부의 환경 변화에 따라 기업의 프로세스는 변해야 한다. 기존의 IT 시스템은 이러한 비즈니스 변화를 수용하지 못해왔다. BPM을 통한 IT 시스템 개발은 이러한 단점을 극복하게 한다. BPM을 기반으로 개발된 시스템은 프로세스 변화에 따른 IT 시스템 변경을 매우 용이하게 해 IT와 비즈니스의 간격(Gap)을 효율적으로 해결할 수 있도록 한다. 7. 리스크/이벤트 관리 : 리스크나 이벤트 관리를 위해 BPM을 활용한다. 이 기능의 기본 개념은, 이벤트 관리를 위한 프로세스를 미리 표준화하여 특정 이벤트가 발생할 경우 실시간으로 관리 프로세스를 자동 실행시키는 것이다. 관리 프로세스 실행중의 업무 처리를 모니터링하는 것은 물론, 리스크/이벤트 관리 지표를 설정하여 처리 결과에 대한 성과 평가를 수행한다. 성공적인 BPM 체계 구현을 위한 경험과 교훈 BPM 체계를 성공적으로 구현하려면 그 목적에 따라 방법을 달리해야 한다. BPM의 개념 정의나 구현에 이르는 방법은 각 기업이 처한 비즈니스 환경이나 고유의 업무 프로세스를 반영하는 프로세스 정립의 목적에 따라 각기 다르게 표현될 수 있기 때문이다. 다음은 주요 전문가와 BPM 프로젝트 경험자가 들려주는 "성공적인 BPM 체계 구현을 위한 경험과 교훈"이다. 참고는 하되 창의적으로 적용해야 한다. 1. 기술, 기능 위주로 접근하지 마라 : BPM을 기업내 핵심 성과지표 달성을 위한 방법이자 수단으로 이해시켜라. 관리되어야 할 중요 업무 지표부터 선정하고 이를 효율적으로 지원하는 툴로써 BPM을 인식해야 한다. 아울러 성공 확률을 높이려면 현업부서가 먼저 고민해야 한다. BPM은 전략 실현을 위한 모니터링, 분석 툴일 뿐이다. 2. 각 기업에 맞는 도입 형태를 찾아라 : BPM 도입 단계에서 현업의 반발이 심하면 이를 수용할 수 있는 방법을 찾아라. GS칼텍스의 경우, 업무는 기존 방식대로 하되 표준 프로세스에 기반해 일이 제대로 됐는지 그 결과만 모니터링하는 방식을 택했다. 부분적인 개선보다 프로세스의 속도를 크게 중시한 경우다. 만약 원칙대로 현업의 모든 업무를 표준적인 BPM에 태우려고 하면 족히 3년은 걸릴 것이다. 이 회사는 애초부터 프로젝트의 목적을 프로세스 관리에 두었다. 시스템으로 돼 있는 부분만 관리하고 나머지는 모니터링만 하자는 것이다. 아울러 시스템화되어 있지 않고 부분적으로 효율성이 낮은 업무는 PI팀이 지속적으로 분석해 나가기로 했다. 3. 현업의 업무는 거의 대부분 모델링 가능하다 : 삼성전자 경영인프라 T/F 민경기 과장은 “현업 담당자들을 인터뷰해보면 자신의 업무를 과대 포장하고 어려운 용어로 표현하려는 특성이 나타난다.”면서, “하지만 경우의 수를 나눠가며 깊이 있는 질문을 하면 결국 모델링할 수 있는 수준의 업무임을 알 수 있었다.”고 경험을 전했다. 오히려 모델링이 되지 않을 경우 현업 담당자의 업무가 고유해서가 아니라, 경우의 수를 잘못 나눴거나 모델링 방법이 틀린 경우가 많았다는 것. 하지만 업무 정의가 표준과 호환되어야지 너무 독보적인 모델링은 곤란하다. 4. 핵심 업무부터 적용하라 : 여러 프로세스를 거치는 다중 업무에는 BPM 성공 확률이 높지만 권한과 책임이 불분명한 단위 프로세스에서는 효과를 보기가 어렵다. 기업내 핵심 프로세스는 생산, 구매, 영업에 걸치는 30~40% 정도이며, 나머지 60~80%는 특정 단위 프로세스거나 몇몇 사람이 주관하는 프로세스이다. 핵심 프로세스부터 BPM을 적용하라. 5. 프로젝트의 목적과 기대 효과에 대해 경영자와 충분한 공감대를 이뤄야 한다 : GS홈쇼핑 PI팀의 이창진 팀장은 경영진은 BPM 체계 구축을 전체 업무의 혁신으로 생각하기 쉽다. 기존 업무 프로세스의 가시화 작업을 추진했음에도 이를 통해 프로세스의 개선 효과가 엄청날 것으로 큰 기대를 품을 수 있다는 것이다. 따라서 사전에 도입 목적과 기대 효과에 대해 명확한 가이드라인을 제시, 공감대를 형성해야 한다. 6. 크게 그리고 작게 시작하라 : 처음부터 큰 욕심을 부리지 말라. 전체 환경에 대한 밑그림은 그리되, 일부 프로세스에 대한 파일럿 시스템 구축 후 확신을 가질 때 이를 확산할 수 있어야 한다. 초기에는 범위를 좁혀 시작하고 현업이 익숙해지는 정도에 따라 범위를 넓혀 가는 게, 현업과 눈높이를 맞추며 프로젝트를 성공리에 이끌 수 있는 방법이 될 것이다. 7. 미래 환경을 대비하라 : BEA시스템즈코리아의 김일교 플랫폼 사업팀장은 BPM의 도입 목표가 초기 업무 프로세스의 자동화에서 이후 업무 프로세스의 개선으로, 그리고 마지막에는 새로운 업무 프로세스/서비스의 혁신 및 창출로 이어져야 기업의 새로운 이윤을 창출할 수 있다고 말한다. 기존 환경의 개선만이 아닌 새로운 환경에 대한 업무 프로세스의 창출까지 고려해야 진정한 성과가 나타날 것이라는 얘기다. 경쟁사보다 신상품이나 서비스를 빠르게 만들어낼 수 있어야 타임 투 마켓을 단축할 수 있다는 설명이다. 8. 비즈니스 전문 지식의 연동을 고려하라 : 한국CA 홍경효 수석컨설턴트는 업무 프로세스 개선을 효율적으로 하기 위해서는 실제 해당 기업의 노하우가 담긴 비즈니스 전문 지식이 자동화되어야 하며, 이를 위해서는 BPM과 BRE(Business Rule Engine)를 연동 및 통합해 한층 더 진화된 비즈니스의 유연성과 민첩성을 확보해야 한다고 강조한다. 아무리 시스템의 처리 속도가 빨라도 사람의 머릿속에 있는 전문 지식에 대한 자동화는 BPM으로는 할 수 없기 때문에 프로세스 속도 개선에 한계를 가지게 되며, 이를 BRE를 통해 자동화함으로써 BPM 자동화에 따른 효과보다 훨씬 더 큰 효과를 기대할 수 있게 된다고 설명했다.  | ||
| 이상기자 | ||
| 출처 : Ciokorea.com. (무단전재 및 재 배포 금지) | ||
| <출처를 밝히지 않는 무단복사 및 재 배포는 법적제재를 받을 수 있습니다.> |
| [펌]SOA와 BPM, 그리고 플랫폼기반 BPM의 한계 (0) | 2008.03.13 |
|---|---|
| [BPM 컨설턴트 양성과정] (0) | 2008.03.12 |
| ALBPM 6.0 is Out (0) | 2007.08.23 |
| [모음]BPM 방법론 (0) | 2007.04.25 |
| [펌& 해석]BPM 2.0 is Middle-Out (0) | 2007.03.30 |
ALBPM 스튜디오 어플리케이션은 이클립스 기반으로 만들어졌다.
스튜디오는 현재 자동적으로 문제를 리포팅하고 Feed Back하기 위한 agent를 포함하고 있다. 스트디오 내에서 예상치 못한 에러가 발생하는 경우 분석을 위해 자동적으로 BEA에 리포팅한다. 스트디오는 해당 기능을 가능하게 하기전에 사용자에게 즉시 동의를 구하게 된다.
메뉴 옵션에 Help를 이용하여 Feedback을 보내도록 장려하고 있다.
ALBPM 스튜디오를 처음 시작할때, 사용자의 Skill Set에 따러서 가능한 프로파일을 선택할 수 있다. 예를 들면 비즈니스 분석가 , 비지니스 개발자, 개발자. ALBPM 스튜디오는 선택된 프로파일에 근거하여 다른조합의 특징을 보여준다. 정돈된 사용자 인터페이스를 유지하고, 필요하지 않은 것들은 숨긴다. 모든 사용가능한 특징들은 개발자 프로파일에서 보여진다. 스트디오 내의 온라인 문서는 활성화된 프로파일에 따라 필터링된다.
프로파일변경을 위해서는 Help > Welcome으로 이동한다.
새로운 릴리즈 프로젝트 변수의 개념을 소개한다. - 이전버전에서 비즈니스변수, 외부변수를 대신할 - 프로젝트 변수는 기능적으로 이전의 External 변수와 동일하다. 그러나 프로젝트 변수는 사용하기에 편리하다: 프로젝트 변수는 프로젝트 내의 모든 프로세스에서 사용가능하다. External로 부터 Instance에 추가할 필요가 없다. 프로젝트 변수는 새로운 프로퍼티인 Business Indicator가 활성화 되어 있으면 이전 비즈니스 변수처럼 움직인다.
ALBPM 프로젝트 디렉토리들은 .fpr 확장자를 더이상 사용하지 않는다.
조직정보와 시뮬레이션 정의들은 프로젝트 트리에서 노드로 접근 가능하다.
VSS와 통합은 이클립스 플랫폼 기반으로 재구현되었다. 이 재구현은 어떤 소스 콘트롤 시스템도 지원하기 위한 방법이다.
각 리소스는 ALBPM프로젝트의 파트로서 독립적으로 저장되고 , 에디터의 패널을 사용하여 수정되어 진다. 그리고, 반드시 파일과 함께 각 리소스에 변경내용을 저장해야 한다.
예를 들면, 이전버전의 스트디오에서는 추가 또는 수정할때 별도의 대화창을 사용했다. 이번버전은 편집영역의 새로운탭안에 특별한 참여자 에디터가 오픈된다. 이것은 각 리스소 별로 관리되어지고, 저장되기때문에 버전 컨트롤 시스템과 연계하기 쉽게 만든다.
pass
동시에 몇개의 프로젝트를 열수 있다. 프로젝트를 열기전에 스트디오 워크스페이스에 추가해야한다.
추가된 편집 : 스튜디오의 프로세스 엔진은 만들어진 코드의 변경을 바로적용한다.
추가적인 Publish와 Deploy가 필요하지 않다.
상호작용 액티비티의 새로운 타입 : 의사결정 액티비티. 이 액티비티의 타입은 인스턴스의 갑을 기반으로 다음 단계에서 가져갈 프로세스에 대해 최종사용자가 결정하도록 해준다. 프로세스 실행 엔진은 오버타임과 지난 경험치를 기준으로 결정할수 있는 것에 대해 추천하는 내용을 최종사용자에게 보여준다.
비즈니스 룰 : ALBPM 스튜디오는 어떤 코딩도 없이 그래픽 룰 에디터를 사용하여 비즈니스 룰을 정의 할수 있는 방법을 제공한다. 프로젝트가 디플로이된 이후, 프로세스가 수행되는 동안 인증된 최종사용자는 이러한 룰들을 수정할 수 있다. 이러한 일들은 ALBPM WorkSpace UI를 통해 수행할 수 있다.
왕복 시뮬레이션 : 주어진 시간동안 프로세스를 실제로 수행할 수 있는 시뮬레이션 모델을 생성할 수 있다. 이것을 사용하면 이상적인 시뮬레이션 모델을 만드는것도 쉬워진다.
프로세스 실행엔진의 디플로이먼트는 상당히 간단해 졌다.-J2EE 컨테이너 안에서 Engine EAR이 있어야만 했던 방식보다 -
| [BPM 컨설턴트 양성과정] (0) | 2008.03.12 |
|---|---|
| [펌]BPM 명확한 목표 수립에서 시작하라 (0) | 2007.12.06 |
| [모음]BPM 방법론 (0) | 2007.04.25 |
| [펌& 해석]BPM 2.0 is Middle-Out (0) | 2007.03.30 |
| BPM 기반 정보화 구현 방법론 (0) | 2007.03.27 |
출처 미확실
[SK C&C]
| [펌]BPM 명확한 목표 수립에서 시작하라 (0) | 2007.12.06 |
|---|---|
| ALBPM 6.0 is Out (0) | 2007.08.23 |
| [펌& 해석]BPM 2.0 is Middle-Out (0) | 2007.03.30 |
| BPM 기반 정보화 구현 방법론 (0) | 2007.03.27 |
| [스크랩]Business Activity Monitoring(BAM) (0) | 2007.03.27 |
Christopher Koch recently wrote a great article on CIO Blogs, which greatly contributed to fuel the BPM vs. SOA war that has been raging in the blogosphere recently.
Chritopher Koch 최근 CIO 블로그에 최근 블로그스피어에서 격렬히 논쟁되어 왔던 BPM vs SOA에 대해 기름을 붓는 대단한 글을 썼다.
BPM is presented as a top-down approach, while SOA would be a bottom-up one, and promoters of both approaches do not seem to be able to resolve their disagreements.
BPM은 top-down 접근방법으로 표현되어지고, 반면 SOA는 bottom-up 방식으로 표현되어지고,
두 가지 접근 방법의 프로모터는 그들의 논쟁을 해결할 수 없을 것으로 보인다.
Thing is, BPM — or rather BPM 2.0 — should not be a top-down approach, for we know that it does not work. Instead, I would characterize it as a middle-out one.
BPM또는 BPM2.0은 top-down 접근 방법으로는 안될것이다.(should not be)우리가 알고있는 바에 따르면 그것은 가능하지 않을 것이다(it does not work).대신에 middle-out 접근방법으로 간주할것이다.
Whether you go top-down or bottom-up to cross the business-IT divide, the gap remains the same. There is nothing magic in this, it’s just called Euclidian geometry.
Business와 IT 양쪽을 교차하기 위한 Top-down 방식 또는 Bottom-up방식을 취하던간에, 그 Gap은 같을 것이다. 여기에 마술은 없다. 단지 유클리드 기하학으로 불리울 뿐이다.
The main idea behind the promotion of a new type of developer known as Process Analyst is to provide a way to bridge that gap, in a middle-out fashion. Start from a middle ground that both business and IT can understand — I believe that BPMN is as good as it gets for this, then reach out to the business side through business metrics that business types love to play with, and to the IT side through BPEL as a way to embrace its newfound love for all things SOA.
프로세스 분석가로서 인식되어지는 개발자의 새로운 타입의 프로모션의 이면의 요지는 middel-out 방식에서 IT / Business간의 갭에대해 교량역할을 해주는 방법을 제공하는 것이다.
이것은 Business와 IT간 서로 이해할 수 있다는 중도에서 부터 시작한다. - 이것을 위해 BPMN이 그 목적을 얻기위해 아주 효율적일 것이라고 믿는다. 그리고,가지고 놀기 좋아하는 비즈니스 타입인 비즈니스 메트릭스를 통해 비즈니스 측면에 도달하려고 노력한다. 그리고 새로발견된 SOA의 모든일들을 포용하는 방법으로서 BPEL을 통하여 IT측면에 도달하려고 노력한다.
BPM and SOA are the two sides of the same BPM 2.0 coin. BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure. Try using BPM without SOA, and all you get is Business Process Reengineering or traditional workflow. Deploy SOA without BPM, and you’ll find it difficult to justify any Return on Investment to a business buyer. If there is a BPM vs. SOA war, it is fought by BPM vendors who cannot embrace SOA for they do not natively support BPEL, or SOA vendors who cannot embrace BPM for their products will always require coding. Take your pick
BPM과 SOA는 BPM2.0과 같은 두가지면이 있다. BPM은 SOA의 killer 어플리케이션이고, 반면 SOA는 BPM을 가능하게 하는 인프라스트럭쳐다. SOA 없이 BPM을 사용한다면, 당신이 얻는 모든것들은 BPR이거나 전통적인 워크플로우일 것이다. BPM 없이 SOA를 전개한다면 Business Buyer에게 어떠한 ROI도 주장하기 어려울 것이다.
만일 BPM vs SOA 논쟁이 있다면 본래 BPEL을 지원하지 못하기 때문에 SOA를 포함하지 못하는 BPM벤더에 의해서 논쟁이 될것이고, 또는 제품에서 항상 코딩을 요구하기 때문에 BPM을 포함하지 못하는 SOA 벤더일 것이다.
당신이 선택하십시요...
PS> 해석이 매끄럽지 못하고, 틀린 부분이 없나 걱정이 되는군여.. --;;
읽어 보시다가 틀린 부분이나.. 매끄럽게 수정되어야 할 부분.. 지적 및 추천 부탁드립니다.
<출처 : http://itredux.com/blog/2006/06/03/bpm-20-is-middle-out/ >
| ALBPM 6.0 is Out (0) | 2007.08.23 |
|---|---|
| [모음]BPM 방법론 (0) | 2007.04.25 |
| BPM 기반 정보화 구현 방법론 (0) | 2007.03.27 |
| [스크랩]Business Activity Monitoring(BAM) (0) | 2007.03.27 |
| BPEL의 활용 (0) | 2007.03.27 |
BPM 기반 정보화 구현 방법론
| [모음]BPM 방법론 (0) | 2007.04.25 |
|---|---|
| [펌& 해석]BPM 2.0 is Middle-Out (0) | 2007.03.30 |
| [스크랩]Business Activity Monitoring(BAM) (0) | 2007.03.27 |
| BPEL의 활용 (0) | 2007.03.27 |
| BPM is SOA’s Killer Application (0) | 2007.03.26 |
|
유형 |
BAM |
BI |
|
주사용자 |
출하, 고객, 구매, 생산, 판매 및 SLA를 가지는 운영 책임자 |
경영 분석가 및 C-level 중역, 전략적인 CPM유형 모니터링 |
|
정보 유형 |
운영 데이터, 실시간 계산, 이동 평균, 패턴 분석, 임계 값, 백분율 |
전략, 하이 레벨, 데이터 양, KPIs |
|
처리 이벤트 유형 |
복잡한 이벤트를 포함하는 이벤트 중심 |
데이터 중심, 완료 이벤트 |
|
경보 |
이벤트 발생에 따른 능동적인 경보, 의사 결정을 위한 actionable context 제공 |
내부에서 보이는 수동적인 경보, 전략 관리를 위한 historic context 제공 |
|
처리 방식 |
“등록된” 이벤트를 수신할 때 |
정해진 간격 혹은 요청 시 |
| [펌& 해석]BPM 2.0 is Middle-Out (0) | 2007.03.30 |
|---|---|
| BPM 기반 정보화 구현 방법론 (0) | 2007.03.27 |
| BPEL의 활용 (0) | 2007.03.27 |
| BPM is SOA’s Killer Application (0) | 2007.03.26 |
| Who is a Process Analyst (0) | 2007.03.26 |
BPEL 사용범위
^^; 조금 장난스러운 설명이다..
BPM의 주요 요소 중 하나인 Process Modeling Tool의 결과물로서 BPEL 표준을 제공하는 경우가 있다.
이 BPEL은 어디에 쓰일 것인가?
- 느슨한 형태로 연계된 여러 개의 웹 서비스들을 조합하여 롱-러닝 워크플로우(long running workflow)를 생성하고 이를 하나의 비즈니스 애플리케이션으로 통합하는 것을 주된 목적
위와 같은 목적으로 BPEL은 ESB의 표현 수단으로 활용된다.
IBM 제품의 경우 BPM Suite의 Lifecycle을 보면
WBM(Webspher Business Modeler) --> WID(Websphere Integration Developer) --> WPS(Websphere Process Server) --> BAM(Business Activity Monitoring)
위와 같은 라이프 사이클을 가지고 있어서, WBM에서 모델링한 결과물을 WID라는 Integration Tool에서 Import해서 해당 서비스들과 연결 작업을 한 후에... WPS에 Deploy하게 된다. 그리고 BAM에서 WBM에서 작성한 KPI를 통해서 모니터링을 하게 되는 것이다.
연관성 (일관성)이 있는 구조이다. 하지만..전적으로 프로세스 모델링을 위한 BPEL을 사용해야 한다.
또한 표현의 기준은 WBM에서 작성한 BPEL이다. ESB 즉, WID에서 작성한 내용이 더 복잡해 질 수도 있고, 추가되는 내용도 다양할 것이다.(Websphere의 경우 WPS는 표준 프로토콜에 대해서만 ESB 기능을 탑재했다. 만일 Adapter를 사용한다면.. Message Tranformation, Validation등이 추가되어야 할것이다.)
Integration 관점은 논 외로 하고 ....
위의 그림에서 보는 것처럼 모델링에 대한 결과물을 다시 BAM의 Input으로 들어간다.
BAM의 목적은 비즈니스 프로세스 모델링을 근거로 KPI 등 모니터링을 위함이다.
작년에부터 오라클, 핸디소프트 등에서 Stand Alone BAM 제품이 출시되기 시작했다.
출처 : 핸디소프트
| BPM 기반 정보화 구현 방법론 (0) | 2007.03.27 |
|---|---|
| [스크랩]Business Activity Monitoring(BAM) (0) | 2007.03.27 |
| BPM is SOA’s Killer Application (0) | 2007.03.26 |
| Who is a Process Analyst (0) | 2007.03.26 |
| [BPM 2.0] (0) | 2007.03.26 |
archidream's Blog is powered by Daum
