Getting Started: The BPM Project Life Cycle

Maximize Business Performance

• Craig Schiff
• DM Review Magazine, January 2004

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:

• Intimate knowledge of your company and its systems
• Specific understanding of how companies similar to your own have maximized the payoff from implementing performance management systems
• Up-to-date knowledge of the many software solutions currently on the market.

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:

현재 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>

BPM is SOA’s killer application, and SOA is BPM’s enabling infrastructure. We’ve used this tagline before, but simple truths are worth repeating, for their deceiving simplicity might overshadow their relevance.

On one hand, and to a large extent, the Service Oriented Architecture (SOA) is a solution in search of a problem, and the Return on Investment (ROI) customers can expect from any SOA initiative has been a hot topic of discussions as of late. In such a context, Business Process Management (BPM) might very well be the one indisputable reason why any IT shop should consider deploying SOA today.

On the other hand, the benefits BPM can offer to the business, in terms of agility, affordability, and accountability, cannot be gained without the proper underlying infrastructure. So far, BPM has remained a point solution, deployed through proprietary products. The emergence of SOA, and the establishment of industry standards that take advantage of it — BPEL being first among them — should lay the ground for BPM’s mainstream adoption.

BPM is SOA’s Killer Application
The problem with the Service Oriented Architecture is that it is exactly what its name implies, an architecture. It’s a set of guiding principles. It’s a philosophy. It can help an architect design a blueprint for something concrete, but nothing more. It is not the blueprint, even less the building. Architecting is not building, and if companies do just that, they’ll end up with very little in the end, after having spent a lot of time, money, and efforts getting there. SOA should not be seen as the end, but the means to the end. The challenge then becomes about finding what the end is that will justify the means.

Advocates of SOA have heralded the need for agility as the main business driver for deploying their architecture of predilection. Unfortunately, business types have found it difficult to understand how SOA could provide true business agility. The most litterate among them might have realized the benefits it could bring to their IT departments in terms of costs reductions, but the other quickly dismissed it as yet another IT fad.

From a business standpoint, a service is too small a unit to really appeal to the business side of the house. Its granularity is too fine. And it’s only when elevated to the level of processes that business folks usually start paying attention. Reusing a currency conversion service across multiple applications, and saving three man-month of development along the way, is one thing. Being able to shave three weeks in the overall order-to-cash process is another. Guess which of the two will get the CFO’s attention?

Once customers start putting a Service Oriented Architecture in place, the desire to tie their newly-available services together into coarser-grain services, or higher-level processes, is felt rather rapidly. This should not come as a surprise: services can be seen as neatly-packaged units of functionality, and the main reason for such a packaging is to enable their composition.

Now let’s make a little experiment: I suggest you draw a set of boxes on a white board, and give them names of ’services’ that make sense for the particular business you’re in. Then ask a colleague to ‘combine’ them into something useful. I bet you that what you’ll see being drawn on the white board is a set of arrows connecting the boxes, and resembling the flowcharts you used to draw when practicing the principles of the good old Business Process Reengineering methodology. Here you have it: a process!

But BPM would not be SOA’s killer application if it would work only after you get SOA, for, as we indicated before, you might never get it. Instead, BPM is SOA’s killer application because it will give you the reason for doing SOA at the first place. Without BPM, the main ROI for SOA is reduced IT costs. With BPM, you can directly link the ROI for your SOA project to the ROI you could get from any improved business process. All you have to do is ask the business which processes they’d like to fix first, put Return on Investment tags on them, and you’ll get the justification for your SOA initiative, with the budget to deploy it.

Better yet, deploying SOA in the context of BPM-powered process work will give you the right SOA. Here is why. SOA is more philosophy than religion. The book of SOA is more Tao Te King than Bible. For example, no consensus has emerged as to what the level of granularity of services should be. Some will say it should be at the level of fulfilling a purchase order, orders will advocate that it should be lowered to the level of recording the purchase order, yet others will recommend that it should be down to the level of creating the header for the purchase order, while using another service to record each line item. Who’s right? Nobody knows…

In reality, there is no absolute answer to this question, and the right answer will depend upon the business scenario — not to say business process — the question was asked in relation to. As a result, deploying SOA in the context of a BPM process will help you package services with the appropriate level of granularity, at least within the context of the business processes they’ll be involved in. Nothing will prevent you to compose coarser grain services out of smaller existing ones, or expose technical details of another into finer grain ones, but you will do it for a very good reasons, always justified by business requirements. Again, SOA is a means to an end, and the way this means is shaped usually depends upon the actual end that is sought after.

For all these reasons, BPM is SOA’s killer application.

SOA is BPM’s Enabling Infrastructure
One of the main ideas behind BPM is to abstract technical systems and requirements in such a way that new business processes could be designed, deployed, executed, monitored, and optimized, without having to write any software code, while most of the work would be done by non-technical folks — or at the very least less-technical ones.

This in turn would bring agility, affordability, and accountability to the business. Agility as in the ability to change the process as fast as the business itself is changing. Affordability as in the ability to deploy, in a cost effective way, a new process that could not have been deployed with any other technology before. And accountability as in the ability to prove, in a non-ambiguous way, that what your IT systems are doing in relation to your business processes is exactly what they were intended to do at the first place — in today’s SoX-constrained world, people are discovering this to be a lot harder than they initially thought.

To some, this idyllic scenario might sound too good to be true, and until recently, it really was. Without a way to provide the functional richness of existing systems packaged into reusable units, without having to expose their technical complexity, what could have been presented as a silver bullet actually turned into magic pixie dust, which is another word for vaporware. It just did not work, or at least not as advertised, and behind the neat little boxes and arrows, armies of developers would have to write arcane code, using languages such as C++, Java, or JavaScript.

Granted, there were some technologies that could have been used to make it work. CORBA was one of them. Problem is, as early incarnations of what we call SOA today, they were not ready for prime time, and more often than not turned out to bring more complexity, exactly where there should have been less. Again, it just did not work.

Then came XML, and the idea of using standard Internet protocols to connect all the pieces together. People called it Web Services, then started thinking about an architecture for managing it all, and SOA was born. It took some more years for the concept to mature, but it eventually reached a critical mass of adoption, making it the de-facto standard for any enterprise architecture today.

Of course, industry standards played a key role in this adoption process. By its very nature, SOA is all about enabling different actors (people, processes, and systems) to communicate with each others, and sharing a common language is usually a good way to foster communication. This lead to the development of specifications such as SOAP and WSDL, which today are the fabric of any new application being developed.

Right around the same time, industry standards for BPM started to coalesce as well. BPML got rid of proprietary languages — very few remember WSFL and XLANG today, and was eventually replaced by WS-BPEL — also known as BPEL, which took full advantage of the emerging stack of standards for Web Services — as well as IBM’s deep-pocketed marketing resources. But because boxes and arrows seem to be more pleasing to the eyes of most business analysts than angle brackets, BPMN was developed, and eventually established as the standard graphical notation for the modeling of executable business processes.

Ultimately, a stack emerged. WSDL for packaging services, BPMN for designing processes, and BPEL for executing processes built out of packaged services. All of a sudden, true BPM — what some call BPM 2.0 — became possible. It worked in a Zero Code manner, supported One Click Deploy for the most complex processes, and enabled a groundbreaking middle-out approach that empowered business analysts and less technical folks — called process analysts today — to work together on the same process, using the same tool.

Then BPM started to work, enabled by SOA

<출처 : http://itredux.com/blog/2006/08/13/bpm-is-soas-killer-application/>