Redesigning BPM

What is Business Process Redesign?

Business Process Redesign is "the analysis and design of workflows and processes within and between organizations" (Davenport & Short 1990). Teng et al. (1994) define BPR as "the critical analysis and radical redesign of existing business processes to achieve breakthrough improvements in performance measures."


How Does BPR Differ from TQM?

Teng et al. (1994) note that in recent years, increased attention to business processes is largely due to the TQM (Total Quality Movement). They conclude that TQM and BPR share a cross-functional orientation. Davenport observed that quality specialists tend to focus on incremental change and gradual improvement of processes, while proponents of reengineering often seek radical redesign and drastic improvement of processes.

Davenport (1993) notes that Quality management, often referred to as total quality management (TQM) or continuous improvement, refers to programs and initiatives that emphasize incremental improvement in work processes and outputs over an open-ended period of time. In contrast, Reengineering, also known as business process redesign or process innovation, refers to discrete initiatives that are intended to achieve radically redesigned and improved work processes in a bounded time frame. Contrast between the two is provided by Davenport (1993):





Process Improvement (TQM) versus Process Innovation (BPR)
From Davenport (1993, p. 11)
Improvement Innovation
Level of Change Incremental Radical
Starting Point Existing Process Clean Slate
Frequency of Change One-time/Continuous One-time
Time Required Short Long
Participation Bottom-Up Top-Down
Typical Scope Narrow, within functions Broad, cross-functional
Risk Moderate High
Primary Enabler Statistical Control Information Technology
Type of Change Cultural Cultural/Structural



What is a Business Process?

Davenport & Short (1990) define business process as "a set of logically related tasks performed to achieve a defined business outcome." A process is "a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization" (Davenport 1993). In their view processes have two important characteristics: (i) They have customers (internal or external), (ii) They cross organizational boundaries, i.e., they occur across or between organizational subunits. One technique for identifying business processes in an organization is the value chain method proposed by Porter and Millar (1985).

Processes are generally identified in terms of beginning and end points, interfaces, and organization units involved, particularly the customer unit. High Impact processes should have process owners. Examples of processes include: developing a new product; ordering goods from a supplier; creating a marketing plan; processing and paying an insurance claim; etc.

Processes may be defined based on three dimensions (Davenport & Short 1990):

. Entities: Processes take place between organizational entities. They could be Interorganizational (e.g. EDI, i.e., Electronic Data Interchange), Interfunctional or Interpersonal (e.g. CSCW, i.e., Computer Supported Cooperative Work).

. Objects: Processes result in manipulation of objects. These objects could be Physical or Informational.

. Activities: Processes could involve two types of activities: Managerial (e.g. develop a budget) and Operational (e.g. fill a customer order).

What are the Myths about BPR Created by the Popular Literature?

The popular management literature has created more myth than practical methodology reengineering. The concept of BPR has been with us since about 1990, however it is widely misunderstood and has been equated to downsizing, client/server computing, quality, ABC, and several other management nostrums of the past several years. Based on interviews and conversations with more than 200 companies, and 35 reengineering initiatives, Davenport & Stoddard (1994) identify seven reengineering myths.

. The Myth of Reengineering Novelty: Reengineering, although about familiar concepts, is new in that these concepts are combined in a new synthesis. These key components have never been together before.

. The Myth of the Clean Slate: Regardless of Hammer's (1990) exhortation: "Don't automate, obliterate!" clean slate change is rarely found in practice. Or, as Davenport and Stoddard (1994) state: A "blank sheet of paper" used in design usually requires a "blank check" for implementation. Hence, a more affordable approach for most companies is to use Clean Slate Design which entails a detailed vision for a process without concern for the existing environment. However, the implementation is done over several phased projects. Also supported by preliminary findings of Stoddard & Jarvenpaa 1995: their findings ran contrary to Hammer (1990): "although reengineering can deliver radical designs, it does not necessarily promise a revolutionary approach to change. Moreover, a revolutionary change process might not be feasible given the risk and cost of revolutionary tactics."

. The Myth of Information Systems Leadership: In contrast to the much touted leadership role, Information Systems (IS) is generally viewed as a partner within a cross- functional team that is generally headed by a non-IS project leader and a non-IS business sponsor who have better control over the processes that are being redesigned.

. The Myth of Reengineering vs. Quality: Unlike Hammer & Champy's (1993) call for all out "radical change," most companies have a portfolio of approaches to organizational change including reengineering, continuous improvement, incremental approaches, and restructuring techniques.

. The Myth of Top-Down Design: The implementation and execution of the redesigned processes depends upon those who do the work. Hence, the participation, and more importantly, acceptance and ownership, at the grass roots level is essential for successful BPR.

. The Myth of Reengineering vs. Transformation: BPR is a process that contributes to organizational transformation (OT), however it is not synonymous with transformation. OT is defined as, "Profound, fundamental changes in thought and actions, which create an irreversible discontinuity in the experience of a system" (Adams 1984). OT is generally about the emergence of a new belief system and necessarily involves reframing, which is a discontinuous change in the organization's or group's shared meaning or culture. It also involves broad changes in other organizational dimensions besides the work processes: such as organizational structure, strategy, and business capabilities.

. The Myth of Reengineering's Permanence: Davenport & Stoddard (1994) speculate that reengineering has peaked in the US in 1994 and would probably become integrated with much broader organizational phenomena: such as another synthesis of ideas that includes the precepts of reengineering; its integration into existing change methods; or its combination with quality and other process-oriented improvement approaches into an integrated process management approach.

What is the Relation between BPR & Information Technology?

Hammer (1990) considers information technology (IT) as the key enabler of BPR which he considers as "radical change." He prescribes the use of IT to challenge the assumptions inherent in the work processes that have existed since long before the advent of modern computer and communications technology. He argues that at the heart of reengineering is the notion of "discontinuous thinking -- or recognizing and breaking away from the outdated rules and fundamental assumptions underlying operations... These rules of work design are based on assumptions about technology, people, and organizational goals that no longer hold." He suggests the following "principles of reengineering": (a) Organize around outcomes, not tasks; (b) Have those who use the output of the process perform the process; (c) Subsume information processing work into the real work that produces the information; (d) Treat geographically dispersed resources as though they were centralized; (e) Link parallel activities instead of integrating their results; (f) Put the decision point where the work is performed, and build control into the process; and (g) Capture information once and at the source.

Davenport & Short (1990) argue that BPR requires taking a broader view of both IT and business activity, and of the relationships between them. IT should be viewed as more than an automating or mechanizing force: to fundamentally reshape the way business is done.

Business activities should be viewed as more than a collection of individual or even functional tasks: in a process view for maximizing effectiveness. IT and BPR have recursive relationship. IT capabilities should support business processes, and business processes should be in terms of the capabilities IT can provide. Davenport & Short (1990) refer to this broadened, recursive view of IT and BPR as the new industrial engineering.

Business processes represent a new approach to coordination across the firm; IT's promise -- and its ultimate impact -- is to be the most powerful tool for reducing the costs of coordination (Davenport & Short 1990). Davenport & Short (1990) outline the following capabilities that reflect the roles that IT can play in BPR: Transactional, Geographical, Automatical, Analytical, Informational, Sequential, Knowledge Management, Tracking, and Disintermediation.

Teng et al. (1994) argue that the way related functions participate in a process - - i.e., the functional coupling of a process -- can be differentiated along two dimensions: degree of mediation and degree of collaboration. They define the Degree of Mediation of the process as the extent of sequential flow of input and output among participating functions. They define the Degree of Collaboration of the process is the extent of information exchange and mutual adjustment among functions when participating in the same process. In their framework, information technology is instrumental in Reducing the Degree of Mediation and Enhancing the Degree of Collaboration. Also, innovative uses of IT would inevitably lead many firms to develop new, coordination-intensive structures, enabling them to coordinate their activities in ways that were not possible before. Such coordination-intensive structures may raise the organization's capabilities and responsiveness, leading to potential strategic advantages.

What is the Role of the IS Function in BPR?

Although, BPR has its roots in IT management, it is primarily a Business Initiative that has broad consequences in terms of satisfying the needs of customers and the firm's other constituents (Davenport & Stoddard 1994). The IS group may need to play a behind-the-scenes advocacy role, convincing senior management of the power offered by IT and process redesign. It would also need to incorporate the skills of process measurement, analysis, and redesign. The CIGNA IS group had to develop a new set of basic values that reflected a change in focus from technology to a focus on business processes and results (Caron et al. 1994). The specific business divisions led the BPR initiatives; IS groups served as partners in enabling the radical changes.

Is there a BPR Methodology?

Davenport and Short (1990) prescribe a five-step approach to BPR:

. Develop the Business Vision and Process Objectives: BPR is driven by a business vision which implies specific business objectives such as Cost Reduction, Time Reduction, Output Quality improvement, QWL (Quality of Work Life)/Learning/Empowerment. (cf: Shared Vision of Senge 1990, Ikujiro & Nonaka 1995).

. Identify the Processes to be Redesigned: Most firms use the High- Impact approach which focuses on the most important processes or those that conflict most with the business vision. Lesser number of firms use the Exhaustive approach that attempts to identify all the processes within an organization and then prioritize them in order of redesign urgency.

. Understand and Measure the Existing Processes: For avoiding the repeating of old mistakes and for providing a baseline for future improvements.

. Identify IT Levers: Awareness of IT capabilities can and should influence process design.

. Design and Build a Prototype of the New Process: The actual design should not be viewed as the end of the BPR process. Rather, it should be viewed as a prototype, with successive iterations. The metaphor of prototype aligns the BPR approach with quick delivery of results, and the involvement and satisfaction of customers.

BPR: All or Nothing?: Insights from CIGNA

At CIGNA BPR meant "breakthrough innovation focused on customer needs" (Caron et al. 1994). BPR was essentially driven by the senior management's strategic planning process that had concluded that the mix of business in its portfolio needed to change. It was viewed as a vehicle to realign strategy, operations, and systems to deliver significantly increased financial results. Caron et al. (1994) argue that the real life story of BPR at CIGNA represents a contrast to the general prescriptions of "radical" "all-or-nothing" organizational transformation. At CIGNA, BPR started out as an experimental pilot. The knowledge from the success of this initiative was disseminated for implementing other BPR projects. The BPR initiative was sustained "from the bottom up, with learning transferred "across."" At CIGNA, the prerequisite for BPR success was a corporate environment that promotes learning, especially learning from failure. Although, the process was initiated from the top, the ownership was moved down to the people who actually had to implement the changes and were affected by those changes. The BPR effort took into consideration the differences in management cultures in different countries. The BPR initiative started at the operational levels and was later moved to "higher forms" (strategic) of reengineering over time.

Why BPR Projects Fail? What Can be Done about it?

70% of the BPR projects fail. Biggest obstacles that reengineering faces are: (i) Lack of sustained management commitment and leadership; (ii) Unrealistic scope and expectations; and (iii) Resistance to Change.

Based on the BPR consultants' interviews, Bashein et al. (1994) outline the positive preconditions for BPR success as: Senior Management Commitment and Sponsorship; Realistic Expectations; Empowered and Collaborative Workers; Strategic Context of Growth and Expansion; Shared Vision; Sound Management Practices; Appropriate People Participating Full-Time (cf: CIGNA: BPR as a way of life); and Sufficient Budget. They also identify negative preconditions related to BPR as: The Wrong Sponsor; A "Do It to Me" Attitude; Cost-Cutting Focus; and, Narrow Technical Focus. The negative preconditions relating to the Organization include: Unsound Financial Condition; Too Many Projects Under Way; Fear and Lack of Optimism; and, Animosity Toward and By IS and Human Resource (HR) Specialists. To turn around negative conditions, firms should: Do Something Smaller First (CIGNA's pilot); Conduct Personal Transformation (CIGNA's change of mindset); and Get IS and HR Involved (CIGNA's CIO initiated the change and HR factors were given due emphasis).

King (1994) views the primary reason of BPR failure as overemphasis on the tactical aspects and the strategic dimensions being compromised. He notes that most failures of reengineering are attributable to the process being viewed and applied at a tactical, rather than strategic, levels. He discusses that there are important strategic dimensions to BPR, notably, Developing and Prioritizing Objectives; Defining the Process Structure and Assumptions; Identifying Trade-Offs Between Processes; Identifying New Product and Market Opportunities; Coordinating the Reengineering Effort; and, Developing a Human Resources Strategy. He concludes that the ultimate success of BPR depends on the people who do it and on how well they can be motivated to be creative and to apply their detailed knowledge to the redesign of business processes (cf: Davenport & Stoddard 1994, Markus et al. 1994).

Where is BPR Headed?

Over the last few years, the reengineering concept has evolved from a "radical change" to account for the contextual realism (Caron et. al 1994, Earl 1994), and to reconcile with more incremental process change methods such as TQM, towards a broader, yet more comprehensive process management concept (Davenport 1995).

Based upon a theoretical analysis and survey of literature relevant to reengineering, Kettinger & Grover (1995) outline some propositions to guide future inquiry into the phenomenon of BPR. Their propositions center around the concepts of knowledge management, employee empowerment, adoption of new IT's, and a shared vision. Earl et al. (1995) have proposed a "process alignment model" that comprises four lenses of enquiry: process, strategy, MIS (Management Information Systems, and change management and control, and used it for developing an inductive taxonomy of BPR strategies. Malhotra (1996) has developed the key emphasis on these issues based primarily on an integrative synthesis of the recent literature from organization theory, organization control, strategy, and MIS.

King (1994) believes that although the current fadism of BPR may end, however, process reengineering, in some form or known by some other name (cf: Davenport & Stoddard 1994) would be of enduring importance.

LATEST ARTICLE ON BPM

Two Out of Three Ain't Bad - Business process management takes aim at the triad of business change
Darwin Magazine


What if, at the conclusion of a meeting between the senior executives of two companies, the new alliance they had just formed could be implemented within days after each side returned to their respective offices? What if the world's most common excuse — "The IT department says it will take 18 months to implement" — was no longer heard?

Agility has been on the agenda of companies for quite some time, but inflexible technology and the lack of an ability to manage business processes has hampered efforts to achieve it. Now, however, it's time to remember the venerable proverb: "Be careful what you wish for, because you just might get it." [link to article]


BPM’s Underpinning: The Pi Paradigm
ebizq.net

BPM is rapidly proving popular, since it gives businesspeople control over the processes that make their companies tick. And it doesn’t hurt a bit that BPM is a winner in the ROI arena, according to BPM experts and champions Howard Smith and Peter Fingar. At the very heart of BPM is “an obscure mathematical theory” called Pi Calculus, literally an award-winner. Here, Smith and Fingar explain what Pi Calculus is, and how it forms the foundation for the hot phenomenon known as BPM: [link to article]

BPM's Third Wave
BPTrends.com

The first wave of business-process management, outlined in Fredrick Taylor's theory of management in the 1920s, suggested that processes were implicit in work practices, tucked away in policy manuals. Process management was called "methods and procedures analysis."

The second wave, ushered in over the past decade, suggested that processes could be manually reengineered through a one-time activity. Changes were made, but essentially cast in concrete in software, such as the feature-rich but rigid ERP applications. Even with document-centered workflow added to financial-management systems, for example, these applications rarely gave business managers full control over the process life cycle.

The third wave of BPM enables companies and workers to create and optimize new business processes on the fly. Change is the primary design goal. Through agile business processes, value chains can be monitored and continuously improved. The third wave is not business-process reengineering, enterprise application integration, workflow management, or another packaged application-it's the synthesis and extension of all these technologies and techniques into a unified whole. The third wave of BPM becomes a new foundation upon which to build sustainable competitive advantage. [link to article] [download as PDF]

IBM and Microsoft Messing with Process Standards?
ebizq.net

Consider carpentry as a field of human activity. “Hammering,” “sawing,” “screwing,” and “measuring,” using “hammers,” “saws,” “nails,” “screws,” “screwdrivers,” “glue guns,” “levels,” “measuring tapes,” and “carpenter’s pencils”: these words form a vocabulary describing the operations that can be performed in this field, and the means for carrying them out. Now consider business processes as a field of human activity. Processes, process data, activities, messages, rules, computation, process branching, compensating activities, exceptions, sequences, joins, splits, operations, assignments, transformations, schedules, rules and time constraints: These similarly form part of a vocabulary describing the operations that can be performed in the field of BPM. [link to article]


Don't Bridge the Business IT Divide: Obliterate it!
EAIJournal

This article examines the often uneasy relationship between business and technology and concludes that a new wave of BPM solutions will make talk of a divide appear anachronistic. From now on, BPM is THE enterprise application, while traditional applications will merely play a supporting role. [link to article] [download PDF]

Coordination, coordination, coordination
Darwin Magazine


In his landmark book, Process Innovation, Thomas Davenport defined a process as follows: Simply a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis upon how work is done within an enterprise, in contrast to a product focus's emphasis on what. A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure for action. This definition, although helpful, hardly begins to explain the true nature of collaborative and transactional business processes. At the very least, the word "coordination" is missing. Our definition: A business process is the complete and dynamically coordinated set of collaborative and transactional activities that deliver value to customers. [link to article]

Business Process Management From Now On
ebizq.net

The evolution of IT to what ebizQ columnists Howard Smith and Peter Fingar herald as the era of business process management systems came in distinct, logical steps, each built on the shortcomings of its predecessor. Here, Smith and Fingar trace those steps and in so doing, show why they feel so strongly that this era was worth waiting for. [link to article]

The Third Wave: Where will all this lead?
Darwin Magazine

Change occurs at many levels within an organization. Some change takes place on a grand scale, some on a small scale. Some change is gradual, some radical. Employees come and go, teams morph and take on new roles, existing processes evolve, new processes are introduced and the company responds to the market by honing its products and services to expand its market share. Change is everywhere. [link to article]

Tearing Down 20th Century Stovepipes With 21st Century BPM
ebizq.net

A not-so-funny thing happens when business users try to complete tasks or projects: the very applications created to help them do their jobs, get in the way. That’s because applications are, by-and-large, recluses, isolated from other software. The result? Those same users have to come up with workarounds to circumvent the obstacles put up by the applications, which slows down everyone and thing. Even EAI And B2Bi don’t respond to changing conditions and business processes. The solution, according to Howard Smith and Peter Fingar in their latest column for ebizQ? BPM, which enables the technology to change as needs do, offering the ultimate in helpful flexibility and connectivity. [link to article]


Business Processes: From Reengineering to Management
Darwin Magazine

Over a decade ago, two articles, one published in the Sloan Management Review in June of 1990 by Thomas Davenport and another in the Harvard Business Review in July of 1990 by Michael Hammer, reported on the growing wave of process innovation and radical business process change. Back then, established companies were in uncertain economic times and feeling great pain. They were besieged by better, faster and cheaper competitors from emerging markets. Globalization had been set in motion and there was no turning back—change was brewing but few could envision a solution that did not involve abandoning the past. [link to article]


The Humble Yet Mighty Business Process
Darwin Magazine

This is a column about business processes and their management, the intricate, dynamic, ever-changing manifestations of the economic activity of companies. Today, companies are looking for secrets, skills and tools that will enable them to create and mesh together business processes that are so outstanding that customers will pay to use them, time and time again. [link to article]

BPM’s Third Wave: From Modeling to Management
ebizq.net

In a research note dated December 5, 1997, the Gartner Group identified "Nine Reasons Why IS Organizations Do Not Do BPM." At the time, "BPM" referred to business process modeling rather than business process management. All that has changed. Today, process modeling tool vendors are forming alliances with companies that supply platforms for Business Process Management. [link to article]

BPM’s Third Wave: Build To Adapt, Not Just To Last
ebizq.net

While the vision of business process management or BPM is not new, existing theories and systems have not been able to cope with the reality of business processes - until now. Analysts report that BPM may provide the greatest return on investment of any software category on the market today. BPM gives companies the ability to cut operational costs at a time when the economic downturn makes it increasingly difficult to boost revenues. [link to article]


The Next Fifty Years
Darwin Magazine

For the past fifty years, computers have been seen as "data machines." But the demands of the new business process management are taking IT in another direction.

Back in the 1950s there was the myth of the great thinking machine. Later, the myth of MIS, the management information system, rose up to replace it. The reality, however, is that to this day, computers are record-keeping machines, not management machines. They can take in, chew up and spit out trillions of bytes of data, but where is the management insight, the actionable information needed in context, in real time at all levels of automated and human decision-making? The methods, techniques and mindset of IT today remain fixated on data—on its capture, storage and retrieval.

However, business processes of all shapes and sizes are the focus of management attention today—management wants to overcome the great "business-IT divide" and gain control over business processes. [link to article, or download PDF].

A New Path To Business Process Management - Not Just A Fad
Optimize Magazine - Business Leadership


Don't mistake BPM for the next killer app or fashionable new business theory. It's a foundation upon which companies can depend as surely as they depend on database management. BPM is based in mathematics, including Pi-calculus, the mathematics of computation that underpins dynamic, mobile processes.

On today's battleground for economic growth, corporate sustainability, and process innovation, companies like General Electric, with its Digitization Initiative, are chasing the goal of 100% digitization of front-room—not just back-office—business processes. They're seeking hyper-efficiency and the agility needed to make course corrections in days and weeks, rather than months and years.

Companies that recognize the power of business-process management are arming themselves with capabilities for digitally deploying, managing, and representing processes on a scale previously unimaginable. They are discovering that traditional application development is no longer the prerequisite for process implementation since the BPMS can deploy new process designs in one step, directly and immediately—and include any other applications within the process design if required. [download PDF]


New BPM Book Promises to Obliterate the Business-IT Divide
Computer Sciences Corporation

A revolution in the way enterprises use information technology for competitive advantage is on the horizon, according to the new book Business Process Management: The Third Wave. Co-authored by CSC's European CTO Howard Smith and noted industry expert Peter Fingar, the book details breakthroughs in process management thinking that promise to deliver significant business benefits.

The book describes the past, present and future of Business Process Management (BPM) and states that today a fundamental shift in business infrastructure services is taking place - from stovepipe applications and associated "data processing," to dynamic connected processes and associated "process processing." What this means is that the lag time between management intent and execution will be greatly reduced, as well as enabling the creation and manipulation of a raft of new processes, never before explicitly supported by IT automation. [link to article]

Making Business Processes Manageable
WebServices Journal
What hat has surprised everyone in the last few years is how challenging it has been to actually do e-business. One of the reasons why this is so is that companies have found it difficult to manage their business processes, especially when they stretch across multiple systems, software applications, companies, and countries. That s about to change. [download PDF]


Integrated Value Chain, Here's What You Need to Know
Internet World
The Business Process Modeling Language (BPML) is the next frontier destined to give companies competitive advantage in managaing their value chain relationships. Large companies currently spend more than 30 percent of their IT budgets integrating their business applications under the banner of enterprise application integration (EAI), trying to get their internal act together for yet another step, business-to-business integration (B2Bi). Why are they going to all this effort and expense? They are tying together fragments of their stovepipe applications to create end-to-end, multi-company business processes those activities that bring ultimate value to customers. It is indeed the entire value chain, not a single company, that delivers the goods or services. Value chain management is now clearly recognized as the next frontier for gaining new productivity and competitive advantage. If end-to-end business processes are the focus of internal and cross-company integration, why not deal directly with the "business process" instead of "applications?" [download PDF]


Business Process Management Systems
Internet World
Business process innovation and improvement are now recognized as the paths to huge gains in productivity something companies are desperately seeking in the current down-turned economy. Unfortunately, our current software architectures and application development methods pose technical hurdles that block the execution of the Business Process Management (BPM) vision they simply were not designed to take companies beyond where they are today. Undaunted by current limitations, resourceful business and technology thinkers and doers have been busy charting a new path to productivity and pushing the technology envelope by placing business processes, their representation, and surrounding software architecture on center stage in the world of information technology. [download PDF]


The Next 50 Years: A Brief
Internet World
There is something worng with IT. something dreadfully wrong that goes all the way back to the beginning, to the advent of business computing in the 1950s. For the past 50 years, computers have been data machines providing systems-of-record that record the after-the-fact results of business activity. [download PDF]


The New MBA Curriculum
Internet World
While e-commerce and e-business monikers may have been M.B.A. marketing ploys, the real "e" is e-process. BPM, along with hands-on automated tools and live case studies, should be integrated into the core curriculum, including courses on operations management, managerial accounting, marketing and production management. [link to article]

Business Process Management in the Finance Sector

Leveraging the power of processes for profit

Introduction

It is vital for financial services companies to ensure the rapid implementation of new processes to meet speed-to-market, service quality and compliance requirements.

This has to be done against a background of increased complexity. Financial institutions today combine a wide range of product and service offerings, across banking, insurance and asset management. They operate in global and cross border markets. They have increasingly sophisticated and mobile customer bases. Increased regulatory vigilance and new corporate governance rules have the potential to add new layers of complexity and cost. And there continues to be consolidation, merger and acquisition in the sector.

For all these reasons the effective management of complexity and change is a key determinant of future success. Those who automate and streamline their operations most effectively will gain significant advantage. Integration is now more than ever the key to efficiency, enabling lower transaction costs and increased sales volumes. This is true for capital markets, for retail financial services, and for the corporate sector.

An integrated approach to business processes allows products, processes, systems, data and the applications that underpin them to evolve quickly. Whether it’s providing a loan, setting up an insurance policy, or executing an investment instruction, optimising the sale-to-fulfilment process will always win new business, cement customer loyalty, and reduce costs. Lack of integration across lending, payments and trading, on the other hand, simply presents competitors who are more efficient with a huge profit opportunity.

Integration and process optimisation not only has to extend across the enterprise, but must also embrace third parties who often supply key components of today’s complex, multi-instrument financial products. A mortgage offer for example will typically involve underwriters, insurers, the customer’s bank, credit reference agencies and others, as well as internal approval, accounting, collections, credit control, risk management, commission payment, incentive management, and business intelligence processes. Improve all the connections between all the elements of a transaction and performance automatically improves.

The problem is that established financial organisations still have numerous, disparate, proprietary backoffice systems which cannot keep pace. These limit the capabilities of even the most advanced front-end systems. The remodeling and implementation of new processes to meet the demands of dynamic change are severely constrained.
There are three objectives to aim for:

• driving greater efficiency and value from existing systems and processes

• managing the risks associated with dynamic change

• achieving greater visibility and flexibility across complex operations

In this document we describe an approach to process management which delivers those aims.

We explore an integration layer that leverages the power of the latest business process execution tools, enabling business analysts and application developers to bridge the current process execution gap. We look at how this tool will allow the efficient re-use of existing process components and the applications that support them, to create new, more efficient processes, utilising a free flow of data and collaboration between all internal and external parties to a transaction.

At last financial institutions have a solution that allows them to cater for and anticipate change, allowing far greater operational and marketplace efficiency, while meeting regulatory and governance requirements.

Bridging the process execution gap

Traditional BPM systems have been designed to manage macro-level processes across multiple applications through hard coding or by use of proprietary tools. This involves teams of developers writing code within one application, which hands off the process to another application. So, on the one hand there’s a business analyst doing the actual process design, and on the other hand there’s a development team which undertakes the coding.

Therefore if a persistent difficulty remains there is still a gap to bridge between process modelling and IT provisioning to deliver new processes. No matter how powerful the resources on either side of the chasm, new or modified processes simply cannot be executed quickly enough to meet business need.

Closing this business process execution gap will be a key determinant of future enterprise success, because it supports the crucial ingredients of business velocity and agility.

As a Senior Executive at a leading health insurer recently commented during a conference on the issue:

“With compliance issues and corporate changes, we’re making process changes every four or five weeks.”

Such comments allude to the need for an extended time-frame to move from process design to process execution in order to gain real competitive disadvantage. But as this executive also commented, the execution of processes typically takes months rather than weeks:

“Right now it’s all done by coding. We are under the gun to deliver.”

In capital markets, the need to execute a new or adapted instrument can involve process change deadlines of days or even hours. Being able to assemble the building blocks of a new trade by treating processes such as pricing, settlement, reporting, reconciliation as commodities, allows a fast-moving trading floor to be even more responsive to the requirements of the market.

So making better connections, and closing the process execution gap, is key to every kind of financial service company.

Opening the BPEL conversation

On one side of the chasm there is the business need (and the process to satisfy it) as modeled by the business analyst. On the other side of the chasm is the application development resource needed to deliver a system solution.

The key is to create a conversation between the two sides. For a conversation to make sense you need a common language. The emerging standard for that language of process execution is BPEL - Business Process Execution Language.

BPEL allows an organisation to treat processes and the applications that underpin them as utilities: to define,translate and transpose a business process, and make the applications which Web Services expose available to build a new process. Using the BPEL tools within Oracle Business Process Manager allows an organisation to effectively orchestrate (or manage) Web Services and the integration architecture as a whole. A recent Forrester Research note crystallises why BPEL moves the integration story forward so significantly:

“BPEL will provide not only a way to integrate applications, but also a way to create services from them and put them into business processes”.

Just as HTML allows content to make sense and to be published and used by anyone who has a web browser, BPEL allows processes to make sense, and for new processes to be planned, developed and deployed with exactly the same universal simplicity and ease of use.

As Gartner recently commented:

“BPEL will emerge as the leading industry standard for Web service orchestration and coordination of business processes.”

More for less

For financial service companies with entrenched legacy systems, and departmental silos based around proprietary or highly specialised applications, the opportunity offered by BPEL has one other major advantage: it does not add more software to the inventory.

In fact, it enables the organisation to get more from its existing investment in applications and processes. Not only more value in terms of more process development potential, but more competitive benefit from faster time to market for new products and services through more effective service provisioning. Before we look at how Oracle business process management solutions enable BPEL to deliver on its promise, let’s examine an illustration in more detail.

Example of advanced integration in action

Let’s take the example of a loan procurement application implemented by a company named “AutoLoan.” Through its online portal, AutoLoan offers loans to consumers who apply for financing of used car purchases. The AutoLoan application will leverage several trading partners who provide the actual financing as well as existing information systems and legacy applications for customer information, credit ratings, etc.

In addition, AutoLoan needs the system to support interactions with people, such as customer service representatives.

The standards emerging around Web service orchestration such as SOAP, WSDL, XML Schema and BPEL enable AutoLoan to address their integration and business process management requirements in a vendor independent fashion.

It also makes sense for AutoLoan to build their system with a loosely coupled, service-oriented architecture so that they will be able to get the efficiency of highly integrated systems while minimising the cost, time and resources required to build and maintain them.

Using a BPEL approach allows AutoLoan to model this business process very quickly, connecting together the applications and partners that support it, and to deploy the process directly. They can then test and refine this business process more effectively. Finally using BPEL they can monitor the effectiveness of this process, and draw intelligence from the information running through it. In other words they obtain real time business intelligence to refine the process and validate it.

Note that this example requires both integration of existing functionality and new application development. It incorporates both internet/B2B (business to business) style integration and intranet/A2A (application to application) integration.

Implementing the system requires AutoLoan to integrate disparate developer skills, methodologies and infrastructures into a maintainable application.

The approach - using Web services as a standard service interface and BPEL for process orchestration – works equally well for enterprise-wide intranet-based integration or for collaboration beyond the organisation.

Key issues for financial services organisations seeking to leverage a

process-centric approach

• Extract functionality efficiently using web services

• Reduce the set up costs of new processes

• Bring new services to market as quickly as possible

• Increase standardisation and interoperability

• Enhance application reliability

• Ensure security

A vision of more effective process delivery

If business analysts can leverage the power of BPEL by operating a dashboard to control activities and create a new business process on their own desktop, they will be more productive and the business will be more agile. If at the same time if a developer can rapidly implement a new service using the building blocks of existing processes which have already been published as web services, or using other components and metadata within the Service Oriented Architecture, they will be able to deliver against demanding time and cost targets.

The challenge for financial services organisations is rapidly leverage their own applications, systems and processes, and also those of trading partners and customers, to bring about business process optimisation.

And as The Web Services Journal recently reported: “Oracle Business Process Manager is a very strong option formeeting this need.”

Oracle BPM supports each stage of the process optimisation lifecycle:

It provides business analysts with a GUI console to model new processes, referencing existing Web Services and applications.

This standard process model can then be run directly on any Application Server using the Process Manager Console. The process can thus be monitored, refined and re-run quickly and effectively

Business Process Management also allows the developer community to manage or ‘orchestrate’ the Web Services already being developed and which are available within and beyond the enterprise. Until now, these have been ‘hard wired’ together using traditional coding techniques.

The benefits are clear:

• Far shorter timescales to delivering and running processes

• Closing the communication gap between the business and IT

• Delivering a single consistent view of the process that both business and developers can understand

• Effectively orchestrating integration between services and applications within the enterprise.

The largest prize is that by adopting this approach to integration, organisations can start to understand their processes and applications far better. They gain visibility of the resources they need, of the efficiency of processes, and of the dependencies and constraints that make or break process effectiveness.

Finally organisations can start to track information flows within transactions and services, responding to events, applying current information to historic overviews, and delivering true real-time business intelligence.

Oracle BPM is the only solution of its kind that is completely application server agnostic: it simply provides a thin management layer above your existing server, minimising the need for new investment in infrastructure.

Conclusion

Success in highly competitive global financial services markets comes to those who are differentiated by virtue of their ability to innovate with new products, services and alliances, characterised by their speed to market, their responsiveness to change, their capacity to reduce costs, their excellence of customer service, and their control of risk and uncertainty.

Process execution underpins all those ambitions.

A process-centric approach to developing the business and its underlying information management systems and applications will pay immediate dividends. Performance will improve. Costs will drop. Profits will rise. Modelling and delivering new or modified processes becomes a single integrated corporate task. This is because there is a common standard language – BPEL – to support a unified conversation between the business need and the business solution. It ensures that delays and costs are slashed, while services and business activities in front and back office are optimised.

Oracle Business Process Manager is a key to winning the benefits of process execution speed and differentiation. Oracle BPM is itself unique. It is a completely open, server-agnostic technology. Unlike every other offering that requires additional infrastructure investment, it links seamlessly with your current web services and SOA approach to accelerate your business, to ensure you lead the pace in a dynamic, fast moving world.

Beyond the Basics: Emerging Web Services Standards for Business Process Management

By Kelli Wiseth

Basic Web services are now able to provide core capabilities such as integration of heterogeneous applications and data, interoperability across disparate platforms, and reuse of business functionality in large part because the standards have matured—and they continue to mature. In addition, the Web Services-Interoperability organization doesn't produce any standards but, rather, codifies the sets of standards produced through OASIS or the W3C and how they should be used. The WS-I publishes guidelines ("profiles"), conformance tests, and other tools to help not only vendors but also Web services implementers ensure that the business services they build will be interoperable with others, regardless of the underlying implementation platform—Java or .NET, for example.

The WS-I's Basic Profile 1.0 (released in August 2003) specifies a set of standards and versions, such as HTTP 1.1, SOAP 1.1, WSDL 1.1, and XML 1.0, as well as usage for a basic Web service. For example, a Web service can make the contract under which it operates available in a variety of ways, but the Basic Profile 1.0 states, "The instance must be described using a WSDL 1.1 service description, by a UDDI binding template, or both." Security and reliability are the next two profiles being developed.

The WS-I is gaining strength, says Gartner's Whit Andrews, and Gartner clients are increasingly turning to the WS-I to help ensure that they create successful Web services. Oracle's Mike Lehmann, principal product manager for Oracle Application Server Containers for J2EE, concurs that Oracle customers and developers are also taking the WS-I seriously.

Furthermore, as basic Web services have taken hold in the enterprise, the demand for higher-order functionality is increasing. "We're starting to see that the more organizations have success with basic Web services, the more they begin to see the need for Web services security, Web services management, BPEL—the higher-level enterprise Web service standards," says Lehmann. "They're getting successful with the basic Web services, and they're ready to go to the next step."

Ultimately, the next several steps will lead to two broad types of process management that are complementary: the intra enterprise notion of "orchestration" and the enterprise-to-enterprise notion of "choreography." Orchestration covers the realm of a private process (or "private workflow") and ties together multiple Web services to build an executable process, typically internal to a company, says Lehmann. For example, a business process for handling a purchase order could require interaction between an inventory system, a credit service, and a shipping service. Choreography operates at a higher, public process level, says Lehmann, and is "tackling how different businesses can define which message exchange patterns they will engage in before implementing the corresponding internal process."

Here are some of the emerging standards that will facilitate or support such scenarios:

Business Process Execution Language (BPEL) is an XML-based workflow definition language, like XML 1.0, XML Schema, and WSDL, that defines a set of constructs for implementing executable business processes that support interaction between Web services—in other words, BPEL is a language for internal process automation (a.k.a. orchestration).

Web Services Composite Application Framework (WS-CAF) broadly encompasses all areas required to handle transactions, including transaction context, coordination, lifecycle, and message delivery. WS-CAF will complement Web services orchestration and choreography technologies, including BPEL (among others), and will also work with existing Web services specifications such as WS-Security and WS-Reliability.

WS-Security was formally approved by OASIS in April of this year and provides specifications for SOAP, X.509, and Username token profiles. Oracle is building a WS-Security implementation into the next release of Oracle Application Server 10g and also integrating it into Oracle JDeveloper 10g and the management console.

WS-Reliability will provide a generic, open model for ensuring reliable message delivery—the ability to guarantee message delivery to software applications (either Web services or Web service client applications) with a chosen quality-of-service (QoS) level for Web services.

Web Services Distributed Management (WSDM, pronounced "wisdom") is a vendor- and implementation-independent management infrastructure designed to treat heterogeneous Web services as manageable resources. A Web services implementation that supports WSDM will provide a set of Web services and operations for configuration, monitoring, and other management tasks.

---

Kelli Wiseth (kelli@alameda-tech-lab.com) is technology director at Alameda Tech Lab and Research Center (alameda-tech-lab.com).

Managing Process Innovation

Applying performance goals to business-process management drives growth and innovation.

When image document routing first appeared in the 1990s, the idea of applying computer technology to this kind of labor-intensive business process was considered cutting edge. Everyone in IT understood the potential of centralized computing for numerical computation and transaction processing, but few envisioned that this type of application would fit a broader set of distributed business processes.

Today, leading companies such as Southwest Airlines, British Petroleum, and Bank of America, are finding more innovative ways to automate their business processes. E-forms, process modeling, simulation, EAI, integration services, rules engines, event services, real-time monitoring, and process analytics are among the systems being applied to processes that include order management, billing, financial reporting, credit-card issuance, product returns, and dispute resolution.

Although these companies are still in the minority, more IT and operations executives are beginning to understand that their current technology does little to link the processes that run their companies to the transactions that result from those processes—transactions at the heart of corporate growth and profitability. This disconnect is rooted in a basic misunderstanding of the purpose of enterprise resource planning and the role of business-process management—relationships that we're now examining more carefully.

It's no secret that work gets done by people through business processes and that technology only supports those processes. Whether distributing goods to customers, collaborating with suppliers, or coordinating employee efforts, business processes add value to products and brands.

Yet most ERP systems have a functional focus and lack process models that explain business operations. As a result, when managers try to innovate or solve business problems—customer satisfaction is one of the most widespread—the "fix" is often myopic and transaction-centric. What's missing is good business-process management.

Business-process management provides methods to automate and/or improve activities and tasks for particular business purposes. Its goal is not only efficiency and productivity, but also control, responsiveness, and improvement. Control assures that company resources are aligned to execute strategies. Responsiveness and improvement support the competitive differentiation that enables a company to excel.

IT executives can assert control by basing the direction and flow of transactions on a predefined set of rules and work flows—for example, determining how a purchase order is acknowledged or merchandise is returned. Responsiveness enables individuals to react quickly to business events and maximize interactions, as when expediting a critical customer order across the customer-service and warehouse teams. As for improvement, you want to systematically measure and monitor processes; doing so will lead to innovation and optimal performance.

An integral part of business-process management is performance management, which is intended to steer the organization and its partners toward corporate goals. Performance management focuses on the collaboration and empowerment of all individuals in the business network or value chain. It enables them to work across strategic, tactical, and operational levels to align actions that produce rapid, effective responses to business challenges.

In the same way you define and document processes, you need to detail performance-management objectives. These objectives are the analytics used to measure all process-improvement projects. The metrics will provide the basis for an ongoing cycle of measurement, evaluation, and improvement. It's also critical that your company tie these process-improvement metrics to high-level performance-improvement goals, not low-level or transaction-oriented metrics.

Done right, performance management should shed light on why some processes don't function well and how to go about improving them. During analysis, the tools will provide the project teams with data to assess the productivity impact of proposed solutions. That data should also help business and IT departments arrive at a common understanding of particular business needs and their solutions. Collaboration between these groups is particularly important in good business process management.

Once you've addressed the overall issue of performance management and built the framework for a sustainable business-process management practice, you can begin to assess requirements for the IT systems that will support it. For this part of the project, five components are necessary: assessing current systems, building a business case, developing and communicating the plan, evaluating software and architecture options, and, lastly, deploying the initiative. Here is further detail on each of the steps.

First, conduct an independent assessment of the process you want to innovate and the systems that currently support it. Establish a benchmark for the current levels of efficiency and effectiveness, and then identify areas for improvement. Of course, you'll need to evaluate financial and operational requirements in this approach, including ROI and total-cost-of-ownership calculations.

Next, build a business case to demonstrate the value and results that the project will deliver, citing clear definitions of the value and cost of your program, as well as compelling productivity and financial reasons for going ahead. Address the cultural, business, and technology barriers to ensure you have support for your initiative.

Third, create a well-defined program and plan, and communicate it to the process owners and participants. The program will have to be articulated at different levels of the organization, so make clear to all stakeholders what's in it for them. The program should also show how the effectiveness of operations will improve through this process innovation.

After that, architecture and software needs should be identified in several ways. First, evaluate solutions with appropriate criteria to ensure that the program is timely and responsive to the organization. Consolidation in the business software market has changed the landscape of business-process management systems significantly. Ventana Research recommends that you evaluate all viable options including service-oriented architectures, but be wary of promises from vendors of single solutions that do only business-activity monitoring (BAM) or only process modeling—these products may not be functionally rich enough.

During your vendor evaluations, keep performance management capabilities in mind. Good business-process management requires both simulation and BAM tools. Simulation aids process design and modeling by letting designers preview how a process flows and look at how the logic, events, and rules will work together—before the process is rolled out into a production environment. Using such a tool, you should discover and remove bottlenecks and accurately predict process performance. The best process models allow multiple simulation scenarios to be performed across subprocesses. The engine should be able to track resource usage, including cost and time analysis, and monitor usage that exceeds preset thresholds.

A robust simulation tool will allow you to deploy new versions of processes without interrupting those already in use and the best solutions allow controlled migration from old processes to new ones. This capability is critical not only for safety reasons but also for benchmarking and measuring results.

Business-activity monitoring aggregates, analyzes, and presents relevant and timely internal information as well as data involving your customers and partners. BAM solutions can alert individuals to changes in the business that may require action from them. Once again, the purpose is to produce rapid insight into process innovations by identifying issues in real time, improving process performance, and reducing operating costs.

Most BAM solutions provide postprocess metrics, such as when and how many times the process was executed and which user performed which tasks. Some go further to provide visual representations of business activity with maps, technical drawings, charts, blueprints, or graphs.

However, keep in mind that real-time process monitoring requires considerable development and integration work. Consider tying these activities to your company's performance management objectives, measuring and tracking them in an active, balanced scorecard. This may look like a project inside a project, but it's well worth the effort. After all, how will you know if you're aligning current process activities to your performance objectives if you don't properly score the results?

Once you've evaluated all software and architecture options, the fifth and final step is to roll out your solution and ensure widespread adoption of your business-process management initiative. To succeed, you must understand how to minimize interruptions to your current business processes, culture, and technology usage.

Make sure you don't skip any of these steps—especially the second, where you benchmark your current process performance and build a business case. Doing so will enable you to showcase the value of your innovation after adoption. Following these steps will increase efficiency and effectiveness, and improve the alignment of your operational processes. Through a simple organizationwide approach, you can transform your people, processes, and systems in an efficient manner that ultimately will be reflected on the company's bottom line.

Colin Snow, VP and research director for Ventana Research, is the leader of the company's Operational Performance Management practice.

What Matters Most

To measure and monitor business activities, software has to perform analysis and integration with underlying systems. Business-process management software must also allow for rules and definitions of business processes and for monitoring and leveraging work-flow exceptions. Findings from Ventana Research's recent Operational Performance Management Research Study indicate that all of these capabilities are critical.

In the survey, more than 1,300 business- and IT-management respondents were asked to rank in importance six major software capabilities for measuring and monitoring business activities and processes. The most highly valued capability was "integrate data and application sources," with 61% of respondents saying that integration is somewhat or very important. More than half the respondents scored all capabilities as important except "define work flow," which drew 48% of responses.

To determine what software capabilities are important to them, companies must know how specifically and widely to measure their business activities and processes. The level of sophistication required will determine capabilities such as work flow, rules, or defining and visualizing business processes. The basic set of software capabilities for integration and analysis are available in most enterprises with business-intelligence solutions, but the additional capabilities outlined in the survey must be included for successful business-process management.

What's Driving Process Innovation?

For many enterprises, the first driver of business-process innovation was the need to improve operational efficiency. Today, the focus has expanded in two directions.

First, regulatory-compliance mandates from the Sarbanes-Oxley Act and the European Union are forcing companies to document processes and procedures in financial reporting, product design, supply chains, and service delivery. In addition, companies are looking for ways to make operations more effective, particularly by automating operational decision-making. This requires systems that can analyze, select, and execute several courses of action. To perform such operations, the systems need to apply explicit policies and procedures—as enforced by rules engines—and execute in a hands-off fashion. Here are examples of how specific industries might deploy automated process innovations:

• Insurance: consumer underwriting, pricing
  
  
• E-commerce: promotional-offer personalization
  
  
• Retail: inventory replenishment
  
  
• Transportation: asset deployment
  
  
• Brokerage: trading, fraud detection, pricing
  
  
• Energy: service-delivery management
  
  
• Telecom: provisioning optimization
  
  
• Government: fraud detection, security

---

Action Plan

Achieving optimal performance from operational processes is essential to an organization's business-process innovation efforts. Follow these guidelines to align process with business objectives:

• To begin a process-innovation project, start with these performance-management principles:

• Develop a performance plan that describes how your operational processes contribute to strategic goals.
  
  
• Determine the key analytics that you'll use to measure all process improvements.
  
  
• Set priorities for improving operational processes that will advance your strategic objectives.

When these guidelines are in place, begin to assess requirements for the IT systems that will support your project. Ventana recommends taking the following five steps:

• Assess your core strategic and operational processes.
  
  
• Build a business case to demonstrate the value and results (through benchmarking) that the project will deliver.
  
  
• Create a well-defined program and plan, and communicate it to all process owners and participants.
  
  
• Evaluate solutions by considering both users' needs and performance management requirements.
  
  
• Model, simulate, and deploy your solution.

Once you've determined these requirements, continue to measure your process with a performance scorecard. Your metrics will compare the degree of improvement against the benchmarks and simulations. Applying the metrics rigorously will guide your ongoing actions toward greater productivity and stronger financial results.

---

http://www.optimizemag.com/

BPM For The Masses

Mariano Benitez12/13/2006

Abstract

A business process is a formal representation of the work done by people and systems of an organization and its partners, and is aimed at providing a product or service to internal or external customers. Business Process Management (BPM) is the art of formalizing and automating business processes. AquaLogic BPM Suite (ALBPM) is a Business Process Management system that allows the complete management of end-to-end business processes.
This article gives you an introduction to the functionality of the product, along with some very important things you need to consider when moving to BPM. It does not provide a complete description of the concepts of BPM, but it will give you the vision of BPM that the AquaLogic product proposes for it.
The article is aimed at anyone who wants to get an initial view of the product and the technology; it presents important information for solutions architects and for those responsible for designing software systems that are to be moved to BPM-based solutions. Developers and executives can benefit from the topics covered here as well.
Something to Do (Before You Start)
Before starting, I want you to ask yourself these questions:
What is BPM?
How do you think business processes get implemented in the real world?
Do you see the processes in your organization reflected clearly in your applications?
Can you easily follow the processes inside your organization?
Would using a BPM tool change the way people work in your organization?
When you’re done reading the article, ask yourself these questions again. Then look at the answers, and see if you may have a better way to tackle these issues. My intention is not to answer these questions directly, but to let you elaborate on them, drawing your own conclusions.
Policy of Truth (Let’s See Some Definitions)
A business process is a formal representation of the work done by people and systems of an organization and its partners, with the aim to provide a product or service to internal or external customers. In its simplest form, a process is a set of activities, representing different steps of the process, linked together through transitions. Activities can require human intervention or they can be totally automatic. For human interactive activities, you define a role in the process that identifies who is allowed to interact with the process at this point. The process acts as a definition, where instances of the process are the actual items moving through it, transitioning from activity to activity. Instances always start at the Begin activity of the process and finish in the End activity. The path the instances take depends entirely on the data of the instance and the external environment.
A transition is a directed link between activities, and many transitions may come in or out of an activity. Once an instance has completed an activity, the outgoing transitions are evaluated, and one is selected that will move the instance to the next activity. Conditional transitions contain a boolean expression that is evaluated and must be true to allow the instance to follow that transition. Some transitions are time-based, which means that they will trigger an automatic routing to the destination activity if the instance is still there at the due time. Processes can have state, too: You can define attributes to a process that will take a value for each instance, helping you keep the state of the instance, to transition to different activities (for example, if quote amount > X, then go to this activity).
This is what BPM is from a pure modeling perspective. This definition is not enough, however, to execute the process; you still need to talk to the other systems, reflecting the process into the infrastructure. Here is where integration comes into play. For each activity in the process, you can define tasks, which basically consist of code being executed when an instance reaches the activity. Tasks can be implemented in a variety of ways. When an instance reaches an automatic activity, the task defined for the activity will be executed, and, depending on the result of that execution, the instance can move to the next activity.
For human interactive activities, the execution of the task is triggered by the end user, from the client workspace. The AquaLogic product has built-in integration capabilities that can be used in the tasks code. (This feature is an important one in the product, which I will cover extensively in further articles.) Tasks update the process state, accessing and changing external systems, interacting with end users, and more. Tasks are what turn a simple process model into a process-driven application.
Business Process Management is the art of formalizing and automating business processes. To successfully evolve into a process-oriented organization, you need tools to design, execute, and monitor business processes. This is what Business Process Management Systems are built for. This is what AquaLogic BPM was designed for.
A Question of Time (Before You Move to BPM)
As organizations try to get more agile, they need to adapt the software they run their businesses with. From a conceptual point of view, the thing that changes most often is not the back-end applications, or the Web service definition to access a customer, or the location of the EJBs, or the version of ERP they are based on. The single most important thing that changes when businesses need to adapt is the process itself: Businesses must add a faster path to automatically approve orders based on some criteria, to modify a reference value that raises or lowers the approval rate. They need process approval and check activities in parallel, they need to change the role that performs an activity, they need to handle exceptions manually, and they need to enforce new business rules. Handling these kinds of changes is at the core of BPM, allowing modifications to be made in the business process without altering any of the underlying components.
In this next section I bring up some things that I consider very important to understanding the true value of BPM.
Behind the Wheel (the Process is in Control)
By embracing BPM, you are now externalizing one important piece of your business. The problem is that if your process model is not executable (it is a pure model), eventually you will have to map it to an application, transforming it, just like you did when moving from "analysis" to "design" to "implementation." This makes it really hard to map the business process to what really is being run in production. With AquaLogic BPM Suite, you build a complete process-driven application, attaching tasks to activities, which are the real operations that take place inside the process. A task is the code of the process and can be either user-driven or system-driven. The execution of tasks is the main driver of state changes in the process. So, the process really drives the application, directly enforcing the flow, tasks, and operations allowed on the process.
Writing process-driven applications does not change the way you write code or implement services; you will still write Java classes, Web services, and JSPs in the same way. The main difference is that the application is process driven. This means that all the code is triggered from activity tasks, so you just need to focus on the code for these tasks; the rest is handled for you. The basic process operations are provided out of the box, in the user workspace.
Walking in My Shoes (or in Your End User's Shoes)
The main shift for your end users (the users of the solutions you build) is that they have a single list of things to do. Users have an inbox where they see the pending instances and the tasks available to execute for each instance.
Before, they had to look on different pages, systems, and applications for actions to perform. Luckily, they received a notification that they had some new work to do, but it was very unlikely they would find it in a single view. BPM makes job assignment very intuitive for users.
The most important change for end users is that they are presented with a more task-oriented view of the work. They easily understand that they have a pending order waiting to be approved by executing the tasks enabled for that activity. By clearly defining the processes, you are creating a unit of work that is clear for all participating entities (other systems, other people).
With processes and instances, you need a user front-end for managing the instances (CRUD-like basic operations). For BPM, these operations would be create, search, execute, abort, delegate, and route. AquaLogic BPM Suite provides all these features out of the box, either from the HiPer Workspace (in any flavor) or directly, using APIs (Java- or Web service-based). You don’t need to build this functionality; it’s already there.
BPM is part of the big SOA movement and plays a very important role in this movement. Let me explain how.
World in My Eyes (the SOA World in the Eyes of BPM)
A number of well known people have defined how BPM and SOA relate to each other.
Bruce Silver’s BPMS Watch has a nice article on BEA’s take on BPM-SOA.
Alfred Chuang’s article on the Exec2Exec newsletter also provides a good description.
My view of SOA is that it is about building services that are encapsulated, reusable, and decoupled. SOA has two main "aspects"?: building decoupled services, and binding them together in a simple way. In a SOA enterprise, all services are ultimately linked together from top to bottom at different levels (otherwise they would not be used). Some bindings are pretty static, and others are very dynamic. BPM tries to provide a tool to model the level that changes the most—the business level. Processes use the SOA services as building blocks that will reflect your business process in the underlying systems. These core services are reused throughout all the processes, providing the real value of reuse. The processes bind the business, data, and presentation services into the value generator: the real business process.
Without a process layer, eventually you will wire the invocation of these services in the presentation layer or in the business layer, and some changes in the business logic will definitively imply finding what services to modify, and rewiring services to adjust to the new business definition. Let me elaborate with an example: You have a Web-application, with a two-tier architecture, with business components and presentation. Some presentation component contains the sequencing logic of the application. The business user decides to make a change in the business process, changing the order of some operations and the usage of a business component. How do you map the business requirement to the exact code you need to change? How do you know where to modify? Why do you need to know the implementation to change the process?
With the process layer, you have a clear space to make use of the available services, acting as the glue for those services, making them useful inside the scope of a business process. So, when your business changes, just one place changes: the process, not the services.
When talking about reuse in the context of BPM, multiple levels are open to consideration:
Low-level reuse of external systems, where many business processes will access the same Web service.
Medium-level reuse of BPM, where you can share process and component templates, reusing the best practices of the code and process models.
High-level reuse of processes, where you expose a process that can be used by other parts of the organization.
Now that I’ve painted a picture of what BPM is and how it fits in the new world, I'll go deeper into the product I want you to meet.
Something to Do (with AquaLogic BPM Suite)
AquaLogic BPM Suite is a product that embraces the whole lifecycle of business processes. It provides tools for all solution times: development time, runtime, and evolution time. For each stage, a number of tasks must be performed to complete the lifecycle, I will get into the tasks next, when I describe what can you do with ALBPM.
Enjoy the Silence (and What BPM Can Do for You)
AquaLogic BPM allows you to design, simulate, develop, execute, monitor, operate, and change business processes. I will explain what each of these things mean.
Development time
This is where you transform your ideas into an application, something executable that includes all things necessary to make it alive: presentation, processes, integration, everything all bundled in a BPM project source.
· Business Process Design—ALBPM Designer allows you to build in a graphical way the real business process, defining process roles, activities, and the flow between the activities. You can also document the operations that need to be performed on other systems. Here you are defining the way your business will work, establishing dependencies, SLAs, exception handling, and more. The result of the design is your business process model. This model will remain as the core of all other steps in the process lifecycle, even at runtime. This model can be visible to end users.
· Business Process Simulation—ALBPM Designer can simulate the execution of the business process. For each activity in the process, you can define resources, costs, times, and the distribution of the different transitions. The simulation will then use that information and generate information about times, bottlenecks, total costs, and so on. This allows you to understand where the process issues will be.
· Business Process Development—With ALBPM Studio you build a complete process-driven application. You define tasks for each activity in the process and what is executed on each task. Task implementations contain business process logic, integration code, and a presentation. The result of this is an executable application. This is where you declare and use the integration points to external system or resources that the process requires. You are defining here the application that will support your business process, the process UI, and the interaction with the external systems. Of course, you can use any component of your SOA infrastructure, including other BEA products. ALBPM has extensive integration capabilities that allow you to use any external software that has an interface to interact with. The result of the development is your business process-driven application. For simplicity sake, for the rest of the article I will refer to this as The Process.
Runtime
Once you have your application source, you can transform them into a living entity, exposing the BPM project to end users, creating instances, connecting with the other systems involved, and so on.
· Business Process Execution—ALBPM Enterprise is the runtime environment for business processes. It provides the process engine that runs the processes and a number of client applications that are the end user front end. This product is all you need to build a BPM environment, with running processes and users connecting to them. Infrastructure management applications are also provided. This is our core product—the "heart" of a BPM solution. The architecture of the product ensures that all enterprise-level features are provided, like scalability, performance, and availability. The product is built to support large-scale installations, with many users, processes, and more.
· Business Process Operation—The process engine keeps a record of the events that occur with each instance of the processes. It stores time, user, and results of any operation performed by users or systems. This information can be reviewed later to audit the steps that the instance has been through. This capability manifests cause/effect relations that, in many cases, were untraceable. You can also search for instances using flexible criteria to see the state of an instance at any moment, or you can override the default flow and grab an instance that is in a wrong state and send it to the proper place. Basic process-oriented operations are provided out of the box, like instance creation, cancellation, routing, delegation, and assignation. All these operations are enabled based on the permissions assigned to the users, and on the process definition.
· Business Process Monitoring—Based on the information available on the process engine, you can easily build dashboards that give you information that is relevant to the business process owner, in the owner's terms—like how much time the entire process takes, or how much money is pending to be collected because of delayed processing. For each process, you can define what measures are relevant to the business and what dimensions need to be defined to ensure proper drill down. All this information is used to build the dashboards that are later exposed at runtime, and provide information about the current state of the process.
Business process evolution
Inevitably, once your business process is alive, you will need to change it. The reason for change can be a result of changes in the market, or new business definitions, or you may have detected inefficiencies in the existing process. You go back to design and development, and implement the change in the process. ALBPM Enterprise handles multiple versions of processes, or replaces an existing process with another version. Different versions of the processes are kept isolated and don’t interfere with each other.
Business process management
Based on what I’ve described, you can manage the whole lifecycle of a business process, from inception to runtime. The ALBPM Product Suite was designed with this in mind. Its basic concepts have been there for more than 10 years and represents a pure BPM product.
Figure 1 provides an overview of the main components found in AquaLogic BPM Suite.

Figure 1. BEA AquaLogic BPM Suite components
Everything Counts (Even the Last Words)
If you are looking for tools to help you embrace a process-oriented way of building software for your organization, then ALBPM is the perfect way to let the tools drive you through the process lifecycle. ALBPM was designed from the ground up, with processes and integration being absolutely critical to a successful application. I want to emphasize two things that are fundamental to a complete understanding of BPM:
ALBPM transforms the way you think about solutions.
ALBPM transforms the way your end users work.
This article describes what BEA envisions as a fundamental piece in the software map of the future, about the way applications, development environments, and, most important, businesses will be driven in the future.
In further articles I will discuss the architecture of a BPM solution, including the product architecture, process modeling, and many other interesting topics. Stay tuned.