ACM / Crossroads / Xrds15-4 / A Computer Scientist's Introductory Guide to Business Process Management (BPM)

A Computer Scientist's Introductory Guide to Business Process Management (BPM)

Article Glyph

Abstract

Computers play an integral part in designing, modelling, optimising and managing business processes within and across companies. While Business Process Management (BPM), Workflow Management (WfM) and Business Process Reengineering (BPR) have been IT-related disciplines with a history of about three decades, there is still a lack of publications clarifying definitions and scope of basic BPM terminologies like business process, BPM versus WfM, workflow, BPR, etc. Such a myriad of similar-sounding terminologies can be overwhelming for computer scientists and computer science students who may wish to venture into this area of research. This guide aims to address this gap by providing a high level overview of the key concepts, rationale, features and the developments of BPM.

Introduction

Every human endeavour, from planning a holiday to managing complex manufacturing processes, is governed by processes. Processes can be optimised by either experience (e.g. planning a holiday) or by prudent scientific investigations (e.g. manufacturing processes). Likewise, there are business processes in business. Business processes (e.g. purchase orders, price negotiations, shipping management, request for quotations, merger-and-acquisition procedures, etc.) are commonly found in business organizations and across organizations. There are many types of business processes. Fundamentally, business processes are either private or public business processes. Private business processes are those internal to the enterprise and can be at the strategic, management or operational level. Public business processes involve external organisations, e.g. delivery of goods, ordering of materials, etc. Public business processes are also commonly known as collaborative business processes (cBP). With intensified globalisation, cBP’s are becoming more important because of (1) the rise in frequency of goods ordered, (2) the need for fast information transfer, (3) quick decision making, (4) the need to adapt to demand change, (5) a larger pool of international competitors and (6) shorter cycle time.

In a bid to deal with these challenges, Information Technology (IT) was harnessed to manage business processes. Previously manual hand-filled forms are increasingly being replaced by their “paperless” electronic counterparts. This eventually gave rise to Business Process Management (BPM). According to prominent BPM researcher van der Aalst [33], BPM is defined as “ supporting business processes using methods, techniques and software to design, enact, control and analyze operational processes involving humans, organizations, applications, documents and other sources of information.” Software tools supporting the management of such operational processes became known as Business Process Management systems (BPMS).

At the end of 2006, the BPMS market reached nearly US$1.7 billion in total software revenue [14] and began to exhibit the characteristics of an early mainstream software market, i.e. proven technology, stable vendors, vendor consolidation and rapid user adoption. The BPMS market is also the second-fastest-growing middleware (a type of integrative software) market segment; Gartner estimates that the BPMS market will have a compound annual growth rate of more than 24% from 2006 to 2011 [14]. Interest in BPM from among practitioners and researchers grew rapidly. A wide variety of paradigms and methodologies from organization management theory, computer science, mathematics, linguistics, semiotics, and philosophy were adopted, making BPM a cross-discipline “theory in practice” subject.

Background and Objectives

Perhaps because it is cross-disciplinary, BPM practice and research are fraught with duplication and possible misunderstandings. This does not help the computer scientists who are trying to understand this field. A common problem in BPM is the absence of universal terminologies [8,23,30,34,37]. Terms are used loosely to represent distinct scope and feature differences [15]. One example is the interchangeable reference between business processes and Web services. Another example is the confusion between business process reengineering (BPR), workflow management (WfM) and BPM. Such confusion has led to mismatched (or worse, wrong) BP solutions being implemented. The frequent mention of BPM in many information systems research such as the Semantic Web and Service Oriented Architectures may also be rather overwhelming to a beginner in the field and may be mistakenly passed off as another buzzword.

Hence, it is always good to begin the introduction with an overview of the BPM fundamentals. While it may seem unbelievable for a discipline with a history of about three decades, there is still a lack of publications clarifying definitions and scope of basic BPM terminologies like business process, business process management versus workflow management, workflow, business process reengineering.
The objectives of this guide are two-fold:

To serve as an introduction for computer scientists to the key terminologies and developments of the e-Business field, Business Process Management.
To address the current knowledge gap in BPM research by clarifying and distinguishing between key concepts and developments of business process management.

Let us begin with the definition of business processes.

Definitions of Business Processes

Baring the traditional process views of Frederick W. Taylor in the area of scientific management, modern and explicit definitions of the term business process can be traced back to the definitions by proponents in the area of business process re-engineering (BPR) in the early 1990’s. The seminal works of Hammer and Champy [9] defined a business process as “a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer. A business process has a goal and is affected by events occurring in the external world or in other processes”. This definition is strong due to its comprehensiveness despite its generic form, and it effectively sums up all possible permutations of business process flows in reality. However, instead of viewing business processes as a “collection of activities”, there is a need to view business processes as a systematic, ordering of specific work activities across time and place. With this structure, the areas needing optimisation in business processes will easily be revealed.

According to another seminal work by Davenport [5], this structure and an emphasis on the study of how work is done to fulfil the goals of BPR must be implemented with the support of information technology. Hence, in his book, a business process is defined as “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, 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.”

While the first two definitions defined the goals, temporal, location and the flow structure of a business process, there were two other important elements still missing in their definitions: the actors of the specific work activities and the collaborative nature of these actors. According to Ould [27], a business process can be viewed as:

Containing purposeful activity
Carried out collaboratively by a group (of humans and/ or machines)
Often cross functional boundaries
Invariably driven by the outside world

This description of business process introduced the elements of (1) actors/ roles and (2) collaboration between the actors/ roles involved. Hence, it is important to note that a business process, being a structured sequence of specific activities, is not only carried out by a single individual or department, but also involves many people/ machines/ systems from different organizations, working together to achieve a common business goal.
Hence, in the author’s own words, business processes would be “a series or network of value-added activities, performed by their relevant roles or collaborators, to purposefully achieve the common business goal”.

Types of Business Processes

To the author’s best knowledge, there is no agreed academic or industrial classification or taxonomy of the different types of business processes. From a higher level viewpoint, there are two main perspectives of business processes: the level perspective and the core competency perspective.

Level Perspective

The level perspective basically classifies business processes into levels like that of traditional organization charts. This perspective is mainly influenced by Robert N. Anthony, who defines three levels of management activities [2,3]:

Operational control, which is "the process of assuring that specific tasks are carried out effectively and efficiently"
Management control, which is "the process by which managers assure that resources are obtained and used effectively and efficiently in the accomplishment of the organization's objectives".
Strategic planning, which is "the process of deciding on the objectives of the organization, on changes in these objectives, on the resources used to obtain these objectives, and on the policies that are to govern the acquisition, use, and disposition of these resources".

In the author’s opinion, these 3 levels respectively form what is known today as Operation-Level Business Processes, Management-Level Business Processes and High-Level/ Strategic Level Business Processes as shown (in a high-level fashion) in Figure 1.

Figure 1: Examples of Strategic, Management and Operational Business Processes

The above three business process levels focus on the internal business processes. However, in the author’s opinion, the very need for the formation of these three levels is usually triggered by an external business process, namely Collaborative Business Processes (cBP’s). Computer scientists must understand that it is via cBP’s that trade and the economy exist. Hence, cBP’s define the business collaborations across entities and enterprises. Some examples are purchasing requests, shipments, outsourcing of services, etc.

Core Competency Perspective

While the level perspective focus on the breakdown of responsibilities, the Core Competency perspective of business process groups business processes by their function, or more specifically, their core competencies [29]. There are mainly three groups:

Core Business Processes- These are the revenue generating processes. E.g. Software Development Department in IBM and Microsoft.
Management Business Processes – These include the processes that ensure efficiency, corporate compliance and governance. E.g. Requests, notifications, etc.
Support Business Processes – These are non-revenue generating cost components which are nevertheless crucial to the fulfilment of business goals. E.g. Transportation business processes of a Manufacturing Firm, IT Department in a Retail Outlet Chain like Marks and Spencer.

Why is Business Process Management Necessary?

As the main people who design and maintain information systems to support BPM within and across companies, it is also beneficial for the computer scientist and practitioner to understand the rationale and benefits behind the BPM discipline.

Benefits of Adopting Business Process Management

It is an intrinsic characteristic for humans to understand an object or a phenomenon through models. Through models, one will be able to identify visibly the problems, and even point out the previously-unaware improvements needed to optimize the situation. The same applies for business processes. The modelling of the processes going on in a business or even across businesses can bring about instant problem identification and an important tool for the simulation of efficiencies of certain processes. Some of the prominent benefits of analyzing and modelling Business Processes are as follows:

Increased visibility and knowledge of company’s activities
Increased ability to identify bottlenecks
Increased identification of optimization-potential areas
Reduced Lead-times
Better definition of duties and roles in company
Good tool for fraud prevention, auditing and assessment of regulation compliance

Such practical benefits are well suited for real-life applications like conformance audits and the increasingly important Sarbanes-Oxley (SOX) audits of corporate IT processes following the infamous frauds detected in the WorldCom and Enron incidents.

Overlooking BPM: Barings Bank

Perhaps a classic example of the failure of business processes is the Barings Bank debacle [19]. The 233 year-old UK Barings Bank went bankrupt in Feb 1994 after it sustained losses of US$1.4 billion incurred in a matter of days by a single young futures trader Nicholas Leeson in the Singapore branch of the Bank. Because of inadequate process controls and other business process failures, Leeson’s unauthorized futures trading went undetected by the headquarters until the very end.

Reaping the benefits of BPM - Case #1: Toyota Motor Corporation

In the Toyota Motor Corporation, right manufacturing and service processes produce the right results. According to Toyota, business processes hide inefficiencies because few people are aware if a business process takes a few hours or a few days. In fact, Toyota claims that business processes are 90% waste (muda) and 10% value add! Consider the work of a typical design engineer in a company. We cannot measure value-added productivity just by looking at what he or she does. One has to follow the flow of information as the design evolves into the finished product. At certain points in time, tests or analyses are conducted that help engineers make decisions. The trouble is that these results of tests and analyses sit and wait in an information warehouse (inventory) until someone picks them up. Following this, the results could go through several more people and departments, adding to the delay. One can easily see that the problem is not unlike traditional batch-and-queue manufacturing and that the answer is flow.

The ideal workflow processing a customer order as though it were the only order, pre-supposes a continuous flow of information and materials. Although a one-piece order is idealistic, small lots are not. In small lot manufacture, by keeping the processes close together, the materials keep moving and waste is minimized. Toyota identified seven non-value adding wastes:

Over-production
Waiting
Un-necessary transport / movement
Excess inventory
Defects
Unused employee creativity

As a result, no one produces anything before it is needed by the next person or step in the process (i.e. no waiting, minimum over-production and transport/movement). Where idealized one-piece flow is not possible, inventory buffers are judiciously introduced (no excess inventory). This is Toyota’s secret that enables its engineers to make a car in one year when its competitors take two.

Reaping the benefits of BPM - Case #2: Ford Case

Another good example of the benefits of BPM is the classic Ford Case in Hammer and Champy’s seminal work [10]:

'When Ford's purchasing department wrote a purchase order, it sent a copy to accounts payable. Later, when material control received the goods, it sent a copy of the receiving document to accounts payable. Meanwhile, the vendor sent an invoice to accounts payable. It was up to accounts payable, then, to match the purchase order against the receiving document and the invoice. If they matched, the department issued payment. The department spent most of its time on mismatches, instances where the purchase order, receiving document, and invoice disagreed.

One way to improve things might have been to help the accounts payable clerk investigate more efficiently, but a better choice was to prevent the mismatch in the first place. To this end, Ford instituted 'invoice-less processing'. Now when the purchasing department initiates an order, it enters the information into an on-line database. It doesn't send a copy of the purchase order to anyone. When the goods arrive at the receiving dock, the receiving clerk checks the database to see if they correspond to an outstanding purchase order. If so, he or she accepts them and enters the transaction into the computer system. (If receiving can't find a database entry for the received goods, it simply returns the order.)”

According to Hammer and Champy, Ford opted by the chosen solution for radical business process change, and achieved dramatic improvement. To illustrate this, it was mentioned that initially there were 500 people working at the accounts payable department, and that a 75% reduction of this figure was achieved after the solution had been implemented.

Clarifying the BPM Terminologies

Having understood the rationale of BPM and the fundamental reason for its discipline, we will now clarify BPM terminologies. BPM is mainly, a cross-discipline “theory in practice” subject involving knowledge from organization management theory, computer science, mathematics, linguistics, semiotics, and philosophy. Because of its multi-disciplinary nature, it is often easy to find business process research materials across many subjects’ databases. To understand the terminologies and features of BPM, one must always start from an appreciation of the BPM Life Cycle.

The BPM Life Cycle

Figure 2: van der Aalst et al’s BPM Life [13]

There are many views of the generic BPM life cycle [33,8,36,11] but the author will adopt van der Aalst et al’s (See Figure 2) because of its succinctness and relevance. According to them, the BPM Life Cycle consists of [33]:

Process Design – In this stage, fax- or paper- based as-is business processes are electronically modelled into BPM systems (BPMS).
System Configuration – This stage configures the BPMS and the underlying system infrastructure (e.g. synchronization of roles and organization charts)
Process Enactment –Electronically modelled business processes are deployed in BPM Systems (BPMS).
Diagnosis – Given appropriate analysis and monitoring tools, the BPM analyst can identify and improve on bottlenecks and potential fraudulent loopholes in the business processes.

BPM vs. Business Process Reengineering (BPR)

Before the 1990’s, almost all practitioners and researchers were using the term workflow management (WfM) for what we call business process management (BPM) today. However in today’s context, many information system practitioners and researchers erroneously use these two terms interchangeably without consideration of their definitions and scope [8].

The influence of Information Technology (IT) in managing of business processes can be traced back to Hammer and Champy’s Business Process Reengineering (BPR)paradigm [9,12] and Davenport’s book [5] on how Process Innovation can facilitate BPR. However, BPM and BPR are not the same: whereas BPR calls for a radical obliteration of existing business processes, BPM is more practical, iterative and incremental in fine-tuning business processes.

BPM vs. Workflow Management (WfM)

Another two terminologies often used loosely are “Workflow Management (WfM)” and “Business Process Management (BPM)”. There are mainly 2 differing viewpoints. One viewpoint by Gartner Research views BPM as a management discipline with Workflow Management supporting it as a technology [15]. According to Gartner [15]: “Business process management (BPM) is a process-oriented management discipline. It is not a technology. Workflow is a flow management technology found in business process management suites (BPMS's) and other product categories.”

Perspectives on Workflow and Workflow Management

In an attempt to distinguish the differences between the two terms, M. Havey defines workflow as “a flow of work, encompassing the exchange and enrichment of information” [12]. In the past, workflow meant passing paper from person to person. Workflow technology improved things not only by managing the flow of work but also by digitizing the information, thereby making the process as automated and paperless as possible. [38]

The Workflow Mgmt Coalition (WfMC) defines workflow management as: “The automation of a business process, in part or in whole, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules” [38]. And in simple words, one can interpret this definition as a backing to the earlier argument of workflow as automation software packages enabling the office documents and business transactions to go from stage to stage of a business process in a “paperless” fashion.

In a highly-cited review paper on workflow management systems in 1995, Georgakopolous et al. [6] describes how workflow facilitates the business enterprises’ dealing with global competition, reduction of costs, and the rapid development of new services and products by “providing methodologies and software to support (i) business process modelling to capture business processes as workflow specifications, (ii) business process reengineering to optimize specified processes, and (iii) workflow automation to generate workflow implementations from workflow specifications.”. The list of features in Georgakopolous et al’s workflow is shown in Figure 3 .

Figure 3 : The Workflow Umbrella in the view of Georgakopolous et al.[6]

Table 1: WfM and BPM compared

BPM Life Cycle Stage	Workflow Management (WfM)	Business Process Management (BPM)
Process Design	Yes	Yes
System Configuration	Yes	Yes
Process Enactment	Yes	Yes
Diagnosis	Weak	Yes

Another viewpoint by van der Aalst et al is that the features stated in WfM according to [36] is a subset of BPM defined by [33] (Refer to Table 1), with the Diagnosis stage of the BPM Life Cycle as the main difference. To the author’s best knowledge (and industrial experience), many BPMS in reality are still very much Workflow Management Systems (WfMS) and have not yet matured in the support of the BPM Diagnosis. From the above categorisations in Table 1 and Figure 4 below, it is now obvious that workflow management is a logical subset of business process management.

Figure 4 : van der Aalst et al’s use of the BPM Lifecycle to Compare Workflow Management and Business Process Management. [33]

To ascertain the differences between WfM and BPM, one must always take into context the historical developments of IT advancement and organisation theories, and not view workflow management as a poor cousin of business process. Furthermore, workflow remains a useful word and is in fact more expressive than the term business process management [38]. Rather, we should view business process management as a progressive extension of the workflow management scope.

In recent years, the author has observed that many software vendors have updated their products’ names from “WfM” to the more contemporary “BPM”. One example is Metastorm’s product name change from Metastorm E-Work version 6 to Metastorm BPM version 7 in 2005 [22]. Noticeably, the change of name was not accompanied by a maturity of the Diagnosis portion of its suites (i.e. WfM to BPM). Instead, the visible changes from version 6 to 7 are their system’s adaptation of Microsoft SQL Server 2005, the obsolescence of simulation features and an aesthetically appealing GUI. In the author’s work experience and observations from technical forum contributors, many of these WfMS-turned-BPMS have yet to offer rich Diagnosis features. Although many software suites offer Business Activity Monitoring (BAM) dashboards (i.e. ready-made user interface programs), the creation of useful audit trails, and the churning of meaningful reports displaying process trends still requires external specialized reporting tools like Microsoft Reporting Server or Crystal Reports.

Limitations of “Workflow”

So why is the term workflow no longer in fashion in the industry? Across most arguments [13,22,36,38], workflow management systems are viewed to have the best ability to increase the efficiency of business processes in a confined domain (e.g. within a company) and have traditionally been based on the WfMC’s idea of a centralized enactment engine.

However, this architecture restricts the integration capabilities of workflow systems across companies, and across sites of a multi-national company. This inability to provide an easily integrated solution to the urgent needs of an internet-savvy and globalised business climate proved costly, and workflow management systems soon lost favour to business process management systems, many of which capitalise on the contemporary distributed environments of Web services and service-oriented architectures (SOA).

Another main gap in the workflow technology was the overlooking of the diagnosis portion in the entire business process management cycle. Despite their robust centralised engines and ease-of-use in their business process designers, many WfMS packages in the industry (e.g. Metastorm e-Work, Savvion, Ultimus, etc.) often lack inherent reporting and diagnostic tools that enable analysts to churn real-time reports to pinpoint process bottlenecks and business processes flaws.
With new research interests in the BPM Diagnosis sub-topics Business Process Analysis (BPA) and Business Activity Monitoring (BAM), the Diagnosis component of the BPM life cycle is starting to gain more attention from software vendors. This paves the way for the development of true BPM.

Limitations of the contemporary BPM definition

So far, the definition of BPM by [4,8,13,22,26] have emphasised on operational processes, and not on strategic-level, tactical-level or collaboration-level processes. This initial focus on just the operational processes is a prudent and very achievable one. However, in many business transactions in the current globalised business climate, we have business processes not only at the operational level, but also across all levels!

In recent years, there is a fervent increase in the interests of collaborative business processes. This is mainly triggered by the need to model and optimize business processes in business-to-business (B2B) collaborations [32].

BPM Theory vs. BPM Standards and Languages vs. BPM Systems

At the time of writing, there are more than 10 formal groups working on BPM standards [39], seven of which are dedicated to modelling definitions [7]. Hence, it is no surprise that the BPM landscape became very fragmented from the late nineties onwards. The confusion was so bad that even theory was confused for standards and standards for BPM Systems (BPMS), when the three are in a nested relationship as shown in Figure 5.

Figure 5 : The relationship between BPM Theory, Standards and Systems

As shown in Figure 5, BPM standards and specifications (e.g. Business Process Execution Language (BPEL) [1]) are based on established BPM theory (e.g. Pi Calculus [24,25] and Petri Nets [28]) and are eventually adopted into software and systems (e.g. Intalio Designer [17], KAISHA-Tec ActiveModeler [18], etc.). BPM Standards and BPM Systems are also what Gartner [16,36] describes as “BPM-Enabling Technologies”. The heterogeneity of business process modelling techniques is a notorious problem for BPM [23]. Table 2 attempts to simplify this by outlining for each modelling technique or standard, its applicability (BPM, B2B or SOA), background, its usage (e.g. execution), current status and if it is standardized.

Table2 : Prominent BPM Standards, Languages, Notations, and Theory and their status

	BPM/ SOA/ B2B	Background	Theory/ Graphical/ Interchange/ Execution/ Diagnosis/ B2B Info Exchange	Standardised?	Current Status
BPDM	BPM	Industry	Interchange	Yes	Unfinished
BPEL	BPM	Industry	Execution	Yes	Popular
BPML	BPM	Industry	Execution	Yes	Obsolete
BPQL	BPM	Industry	Diagnosis	Yes	Unfinished
BPRI	BPM	Industry	Diagnosis	Yes	Unfinished
ebXML BPSS	B2B	Industry	B2B Info Exchange	Yes	Popular
EDI	B2B	Industry	B2B Info Exchange	Yes	Stable
EPC	BPM	Academic	Graphical	No	Legacy
Petri Net	All	Academic	Theory/ Graphical	N.A.	Popular
Pi-Calculus	All	Academic	Theory/ Execution	N.A.	Popular
Rosetta-Net	B2B	Industry	B2B Info Exchange	Yes	Popular
UBL	B2B	Industry	B2B Info Exchange	Yes	Stable
UML AD	BPM	Industry	Graphical	Yes	Popular
WSCI	SOA	Industry	Execution	Yes	Obsolete
WSCL	SOA	Industry	Execution	Yes	Obsolete
WS-CDL	SOA	Industry	Execution	Yes	Popular
WSFL	BPM	Industry	Execution	No	Obsolete
XLANG	BPM	Industry	Execution	No	Obsolete
XPDL	BPM	Industry	Execution/ Interchange	Yes	Stable
YAWL	BPM	Academic	Graphical/ Execution	No	Stable

BPM vs. SOA

In the industry, there is a growing awareness of the emerging Service-Oriented Architecture (SOA). For example, SAP AG has migrated from the traditional ABAP-based R/3 system’s SAPGUI front end to the Java-based SAP NetWeaver Portal which is supported by SAP Web Dynpro technology in the design, configuration and the linkage of web services.

However, there is also widespread usage of the terms BPM and SOA interchangeably. It is thus important to note that BPM is a process-oriented management discipline aided by IT while SOA is an IT architectural paradigm. According to Gartner [13], BPM “organizes people for greater agility” while SOA “organizes technology for greater agility”. In other words, processes in SOA (e.g. linked web services) enable the coordination of distributed systems supporting business processes and should never be confused with business processes.

The Business Process Modelling Process

With an understanding of the terminologies, the reader can now appreciate the business process modelling process usually occurring in the industry. This process is usually undertaken by IT specialists within the company. From the author’s work experience in business process modelling, the BP Modelling Process starts from the initial business needs to the establishment of an automated business process can be viewed as 6 stages which align with the BPM life cycle’s stages of Process Design, System Configuration and Process Enactment.

Of these 6 stages, 2 of them are currently manual and the other 4 are currently supported by tools from BPM software vendors (See Figure 6). The BP Modelling process can be best described by the example of the purchasing request business process in fictitious company A.

Figure 6 : The business process modelling process: From goals to diagrams to executable processes

Explanation of the BP modelling process via an example

Company A recently purchased a BPM system and would like to automate its internal business processes. The management decided to pilot it in the Procurement Department and identified the purchasing request (PR) business process to be the most suitable BP to be modelled and implemented with the new system. The reason is that the PR BP is currently handled by the passing and signing of paper forms and are often lost or misplaced in the process. Also, it is currently the highest utilised business process in the department.

Step 1: Business Needs
With the identification of the need for the PR BP to be modelled, the management has triggered Step 1 of Figure 6. The high level business goal would be “to raise a PR”.

Step 2: Business Goal Definitions
After which, Step 2 will take place. The management will present its requirements and a high level overview of the steps in a PR process to a business analyst. This stage is still manually practiced in the industry and involves meetings and discussions in order for the business analyst to fully grasp the requirements of his client.

Step 3: Detailed Business Process Diagrams
With a reasonable understanding of the client’s requirements, the business analyst will model the business processes in an easily interpretable graphical standard (e.g. BPMN). The graphical details are aided by the BPMS’ designer tool. Specific details adhering to the company’s standard operating procedures (e.g. layout of the PR request form, different approving authority based on request amount, etc.) are also inputted.

Step 4: Translate Diagrams to Executable Code
With the BPMN diagrams in place, the business analyst will use a tool that supports interchange standards like XPDL to automatically translate the PR business process’ graphical model in BPMN standard into the very technical executable code in BPEL standard.

Step 5: Execution Code
An IT Specialist will check the code, make necessary adjustments, or add in more logical details into the BPEL standard code. After which, the IT Specialist will demonstrate a prototype of the business process to the management. Upon testing and approval, the PR BP code will be published into the BPMS.

Step 6: Executable Business Processes
The BPMS contains a component called the Engine, which is a software that manages the proper routing and running of all PR BP instances to the correct stages and persons. Once we hit Step 6, company A’s employees can now raise PR’s electronically via the BPMS.

Concluding Remarks

This guide has introduced to computer scientists and computer science students key terminologies and developments of the eBusiness field, Business Process Management. Some notable terminologies clarified included definitions of business processes, workflows, workflow management, the difference between WfM, BPR and BPM, and a clarification of the key differences between BPM and SOA. Perspectives of viewing business processes, the effects of neglecting BPM and common ways of business process modeling were also evaluated.

Together, these clarifications and definitions aim to reduce the current situation (in both industry and research) where many of BPM concepts and terminologies were mistakenly used interchangeably and without regard for their scope and developments. As a result of this guide, readers looking to explore business process management information systems research should now have a clear and fundamental grasp on the background and overview of the BPM subject.

References

1: T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, and S. Thatte, "Business Process Execution Language for Web Services, Version 1.1," Specification by BEA Systems, IBM Corp., Microsoft Corp., SAP AG, Siebel Systems, 2003.

Crossroads

The ACM Student Magazine