Therefore, it is always good to begin the introduction with an
overview of BPM fundamentals. Although 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, such as business process, business process management
versus workflow management, workflow, and business process
reengineering. The objectives of this guide are two-fold:
• To serve as an introduction for computer scientists to key terminologies and developments in the e-Business field, Business Process
• 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 definitions of business processes.
Definitions of Business Processes
Barring 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 1990s.
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 realistic permutations of business process flows. 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 optimization in business processes will easily be revealed.
According to another seminal work by Davenport [ 5], this struc-ure and an emphasis on the study of how work is done to fulfill 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.”
Although the first two definitions defined the goals, temporal,
ocation, 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)
ctors/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 my 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.
The level perspective classifies business processes into levels like
those of traditional organization charts. This perspective is mainly
influenced by Robert N. Anthony, who defines three levels of management activities [ 2, 3]:
1. 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.”
n my opinion, these three levels respectively form what is known today as operation-level business processes, management-level business
processes, and high-/strategic-level business processes, as shown (in
a high-level fashion) in Figure 1.
The three business process levels in Figure 1 focus on internal business processes. However, in my opinion, the very need for the formation of these three levels is usually triggered by an external business
process, namely, collaborative business processes (cBPs). Computer
scientists must understand that it is via cBPs that trade and the economy exist. Hence, cBPs define the business collaborations across entities and enterprises. Some examples are purchasing requests, shipments, outsourcing of services, etc.
Core Competency Perspective
The level perspective focuses on the breakdown of responsibilities.
The core competency perspective of business process groups business processes by their function, or more specifically, their core com-petencies . There are mainly three groups:
• Core Business Processes—These are the revenue-generating processes (e.g., the Software Development Department in IBM or Microsoft).
• Management Business Processes—These include the processes
that ensure efficiency, corporate compliance, and governance (e.g.,
Requests, notifications, etc.).