Question

The general question of what a business process is cannot be answered easily because there is no uniform definition. But, as a matter of course, a certification program on business process management must ask this question. And it is important to have a uniform understanding of the meaning of the term, business process, not only in the certification program, but also in real life. Almost all subsequent concepts are based on it. And if the basis is fragile, many things can go wrong.

Answer: Real Life

But how do we get out of this dilemma? In real life, you should communicate your understanding of a business process and align it with your project team members and other contact persons. It is not important how you define the business process, but that all persons involved use the same definition.

Answer: OCEB2

The certification program OCEB2 has not decided on any definition of an author or standard, but created its own paper that describes typical characteristics of a business process and addresses the variety of definitions [30]. This much better reflects the goal of OCEB2, to certify business process management knowledge because this variety is part of real life.

Characteristics of business processes that you can find in many definitions include:

• They involve several actions, steps, and activities.

• They usually involve various organizational units (departments, enterprises, etc.).

• They are targeted.

• They basically describe an action, decision, and cooperation.

• The result represents a value for an (internal or external) customer.

Other critical characteristics of business processes can be as follows:

• They describe how the enterprise (or other organizational unit) operates.

• Actions can be assigned to organizational units or roles.

• The more branches a business processes has, the more complex it is.

Definitions of Authors

One definition is provided by the authors Geary A. Rummler and Alan P. Brache [29], who describe the business process as a series of steps designed to produce a product or service. If the result is directly of benefit for the customer, it is a primary process, otherwise it is a supporting process. Martyn Ould defines business processes as a coherent set of activities carried out by a collaborating group to achieve a goal [27]. The authors, Howard Smith and Peter Fingar, define the business process in a similar way and supplement characteristics [34]. According to this definition, a business process is complex, distributed, and long-running.

Definitions in Standards

The definition of business process in standards is similar to the definitions of authors. The glossary of Workflow Management Coalition (WfMC) describes the business process as a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships [8]. OMG also has its own opinion on the business process. In the Business Motivation Model standard (BMM), the business process is defined as an unit that implements strategies and tactics so that the enterprise achieves its goals [2].

Similarities and Differences

You possibly know many more definitions. But all of these definitions are essentially very similar. They describe how an enterprise works. The difference is in the limiting characteristics and the business process's level of detail. For example, the definition of BMM is very general and permits almost all business workflows as a business process. Geary A. Rummler and Alan P. Brache request a customer-related result, and Howard Smith and Peter Fingar characterize business processes as long-running. According to some definitions, a business process has a start and an end. According to other definitions, continuous activities, such as risk management, are business processes as well. For real life and for the certification, it is important to know this wide range of definitions.

Complexity

Business processes are complex according to Howard Smith and Peter Fingar [34]. The characteristic of complexity is often used if things get complicated. There are innumerous discussions on the difference between complex and complicated. If you're interested in this topic, simply browse the Internet. There are a vast number of different opinions on this topic. We'll only examine which characteristic makes a business process complex. Imagine the process operation in the form of a flowchart, for instance, in BPMN as shown in Figure 3.1.

Major Doesn't Mean Complex

You can see that it is not the number of steps that makes a process complex. Major, comprehensive processes can be very simple. The number of branches is decisive, which make the process complex and unclear for the persons involved. This particularly applies if the business process is not described.

Flexibility as a Success Factor

A very important, but not inherent, characteristic of a business process is the ability to be changed easily. Enterprises are subject to constant changes in the market and must adapt to those in a flexible way if they want to be successful in the long term. For example, SpeedyCar only had call centers and some subsidiaries as points of contact for its customers for many years. Market conditions have forced the enterprise to provide its services also via the Internet since the beginning of 2000. Currently, changes must be made due to the mobile computing trend. Customers surf the web anywhere and anytime via their cell phones and similar devices. This results in changed, and even completely new, business processes.

Active Business Process Management

To ensure that an enterprise can successfully respond to changes, it must actively run a business process management. In dynamic markets, a process-focused organization proves itself in contrast to a function-focused organization, which focuses on departments like finance, customer service, human resources, and so on (Section 4.2). A critical aspect is that business processes are considered and handled as assets within the enterprise (see also Section 4.1).

Role

Human beings are a central element in the world of processes. They invent processes, execute them, and they are made for them. But processes are not oriented toward individuals, but toward roles, in other words, there is no process that describes the tasks of Tim Weilkiens or Christa Preisendanz. But there are processes describing how Tim in the role of an author of this book cooperates with Christa as the editor. If these roles are assigned to other concrete persons, they follow the same process. The roles work together to fulfill the tasks. The activities cannot be viewed separately by roles. It is the interaction that provides added value.

Role descriptions exist at different abstraction levels and they can represent a different number of possible concrete persons. The role of the managing director at SpeedyCar stands for a concrete person (Mr. Speedy). The role of the call center agent is assumed by several persons and the role of the customer (hopefully) by a great many people. The role of the applicant has an abstract character, that is, the role can be assumed by another role, for instance, the customer, which is then occupied by a concrete person.

Process Steps

Another central element of a process involves the process steps, that is, the activities executed by the roles. Besides the sequence of steps, which is determined by the process, business rules must also be adhered to when they are executed. These include, for example, organizational policies and standards. Section 7.1 describes the meaning of these terms.

Process Topology

The explicit process is determined by its topology, that is, by the steps and their interrelations. Flowcharts—created using BPMN, for example (Chapter 6)—visualize this topology. So, one form of process discovery might be to work out the upstream or downstream step of an activity to compile the business process successively. Figure 3.2 shows the business process, invoice monthly services, as a flowchart in BPMN. Chapter 6 provides some charts that also describe the topic of monthly statements. A good BPMN reading exercise: What are the differences?

Horizontal versus Vertical

The flowchart shows the process topology in the horizontal level. Vertically, you can view the process hierarchy, which shows that processes can be part of a superordinate process. Process steps can be described in detail by processes until you come across activities or actions that can no longer be broken down to the lowest level. Note that the distinction between horizontal and vertical structures also exists for organization units and business processes, where they consider another aspect, however (Section 4.2).

For processes, the main focus is often on flowcharts. But there's additional information available for a business process:

• Process owner

• Goals of the business process

• The customer who benefits from the business process

• The stakeholders who can provide important information on the process

• A brief description of the process

The activities—the elementary steps of a process—also have characteristics such as

• Executing role (“work unit”)

• Necessary resources

• Data that is required or generated

• Duration

• Business rules that must be taken into account

• A brief description of the activity

Process Goal

As already determined in Section 3.1, a business process usually is not a random sequence of activities, but a sequence that pursues one or more goals. The term goal is a general word whose meaning we want to outline briefly here to avoid misunderstandings. A goal is a targeted, desirable state. In our context, we consider not only the final goals, but also goals—that is, states—which can also be achieved in the course of the business process. The goal can describe a unique state or a steady-state goal, for example, “the complaint rate must be below 0.5% of all bookings.”

At least one goal should be assigned to every business process. Start and intermediate states can also be described. It thus becomes apparent how the business processes change the states in the course of time, for example, from the state of “customer requests a service” to the state and goal of “customer is satisfied.”

This information on processes and activities seems to be easy and only needs to be written down. In real life, however, this is different. Frequently, knowledge only exists implicitly within the organizations and must be detected first. Section 3.3 discusses this topic in detail. The initial recording of business processes is also a manifestation that creates change requirements because the documentation reveals possible weaknesses of the business process. It is therefore also important to distinguish actual and target processes.

From Implicit to Explicit

Do you have a book in your desk drawer that describes the business processes of your organization? Probably not, and you presumably don't have a corresponding model or document in your IT department, either. But business processes definitely exist—frequently only as implicit, distributed knowledge within the organization. This becomes particularly apparent when persons take their knowledge when they leave the enterprise. The goal of process discovery is to detect implicit knowledge about actual processes and make it explicit.

Basis

The explicit knowledge on business processes forms the basis of process improvements. You cannot effectively improve or automate processes which you don't know. The supporters of Business Process Reengineering (BPR) object to this statement (Section 4.1). In their opinion, the documentation of actual processes takes too long and is too incomplete to provide valuable results. It would be more effective to redevelop the business process from scratch. In the 1990s, BPR was hailed as a revolutionary approach and an important driver of the BPM discipline; Currently, it is viewed more critically.

Business Process Analysis

The purpose of Business Process Analysis (BPA) is to provide explicit process knowledge. It serves to discover weaknesses and enables actual/target comparisons. In his article on process discovery, Laury Verner lists typical examples that require BPA [37]:

• Diagnosing the root cause for a known process problem, such as finding out why the warranty process takes so long

• Finding unknown weaknesses and bottlenecks in existing processes

• Understanding the interrelations and integration of hundreds of data and documents

• Creating standard processes for supply chain interactions, for instance, using SCOR (Section 7.2.2)

• Converging multiple parallel processes, performed by different departments, into a single enterprise-wide standard process

• Preparing for measure implementation, specifically to perform an analysis of the new measures on existing processes, for instance, the application of new business rules

• Generating functional requirements on an IT system

• Designing the business logic of a process that will be automated using commercial Business Process Management Suite product (BPMS)

BPA Process

Discovering and documenting are the first steps in the explicit consideration of the business process. This is followed by the analysis of the actual process; the process design of a new target process which erases the weaknesses of the actual process; the development of the target process; the introduction, implementation, and finally, the maintenance of the current process (Figure 3.3).

Roles

As described previously, a process also includes roles that execute the process steps. There are three roles involved in the process discovery:

• The sponsor who sets up the BPA project assumes responsibility for it and specifies goals.

• The Subject Matter Experts (SME) who provide the process content. They frequently come from the management level.

• The analysts who control and implement the methodologies of BPA.

Approach

Laury Verner differentiates three different ways to approach process discovery [37]:

Centralized

Centralized versus distributed approach—In the centralized methodology, the analyst assembles multiple SME's together for a series of workshop sessions. This merging of cumulative expert knowledge can lead to positive synergy effects. Predominate SMEs, however, can enforce their opinion toward less dominant persons and thus, distort the results. Organization-wise, however, this approach proves difficult, because bringing all SMEs together at the same time, particularly if they come from the enterprise's management, is a difficult task.

Distributed

The distributed approach is more democratic because the SMEs are interviewed separately by the analyst and consequently, all opinions can be handled equally. It is the analyst's task to bring all process fragments together and solve inconsistencies. A subsequent review conducted by the previously interviewed persons often reveals whether all findings have been recorded correctly and all inconsistencies have been removed.

Top-Down

Top-down versus bottom-up approach—The top-down approach is the classic method. The analyst starts with an enterprise-wide process with a low level of detail, for instance, car rental. He identifies the steps of the process and describes each of these steps with a more detailed process, and so on. This approach ensures that the context initially selected is kept. The disadvantage is that process steps which do not fit in the specified hierarchy easily remain undiscovered.

Bottom-Up

The bottom-up approach starts with the detailed activities. The SMEs report directly about their work steps. This results in a high level of detail. This advantage is a disadvantage at the same time. The analyst can easily get lost in trivial details. His challenge is to put the various pieces of information in the right context to illustrate the process hierarchy, and to determine whether the processes have been identified completely in compliance with the set goal.

Structured

Structured versus free form approach—In the structured approach, the SMEs answer predefined questions from the analysts. Ideally, this takes place interactively, but it can also be implemented separately, using questionnaires. The structured approaches lead to consistent results. But they can also be incomplete if the contents do not comply with the predefined questions.

Free Form

In the free form approach, the SME reports to the analyst without predefined specifications. The random degrees of freedom allow for the exchange of any information. It is the analyst's task to convert this unstructured information into a structured form.

Orthogonal Approaches

The tree approaches are not mutually exclusive, but are orthogonal. You can take the centralized, top-down, and structured approach or centralized, bottom-up, and free form, and so on. In the case of a newly conducted process analysis of the entire enterprise, Laury Verner suggests to first gain a rough overview of the process structure in a top-down approach. Details can then be supplemented bottom-up to check them for completeness and to remove inconsistencies in a third step (usually using a tool). Subject Matter Experts and the most critical stakeholders can then do a review to obtain a result that is accepted by the enterprise.

Descriptive

The descriptive level maps business processes in a high level of detail. It provides an overview of the process—usually in the best case—and of the organization units and roles involved. Simple diagrams, for instance, using BPMN, or text descriptions can be used for this purpose. The description's goal is to communicate business processes across organization units, for example, to the upper management.

Analytical

The analytic process description features a considerably higher level of detail. Not only the best case, but also the variants and exceptions of the business process are described here. The analyst must have advanced skills in modeling, for instance, workflow patterns, troubleshooting, and handling of events. The result of analytical modeling can be used to analyze the effectiveness of processes. This is also the level of detail that IT departments require to create an implementation that automates the business process completely, or in parts.

Executable

Executable modeling means that the process model itself is executable and can be directly used for automating the business process. This requires a very high level of detail and presents a corresponding challenge to the modeler. BPMN supports the creation of executable models, for example. In real life, however, the modeling tools often differ from the standard and use tool-specific concepts to enable feasibility.

The target group of a business process description is very heterogeneous. Therefore, it is not sufficient to just distinguish the form of presentation. Another view and distinction originates directly from the BPMN specification [4]: private, public, and collaborative business processes. Naturally, this differentiation refers to BPMN. However, this view can also be generalized and transferred to other description forms.

Private Business Process

Most business processes fall into the category of private business processes. They are representations of internal flows that are specific for the organization. Figure 3.4 shows the private business process, book car.

Public Business Process

Public business processes describe the interaction between a private business process and one or more parties involved. Only those process steps that are involved in the interaction of the private process are illustrated. The process steps of the interaction partners are not described. Figure 3.5 shows the interactions of the private process from Figure 3.4, with the group able to book a car of a partner in another city. Public business processes are also referred to as abstract business processes.

Collaborative Business Process

A collaborative process shows an interaction, just like the public business processes. However, you can now also include the detailed process steps of the parties involved and the exact sequence of information exchange. Figure 3.6 shows the business process of car booking as a collaborative model.

Mixing Aspects

The distinction between private, public, and collaborative business processes is independent of the previously described abstractions of descriptive, analytical, and executable modeling. For example, you can model private business processes as analytical, or describe public business processes.

Besides the level of detail of a process diagram, you can also distinguish between the actual and target processes. Actual processes describe the actual business process. They are usually described to make the enterprise's implicit process knowledge transparent and to serve as the basis for optimizations. Target processes describe the target condition of a business process after an analysis and optimization was made, for example. Target processes are used if they involve new business processes that must be integrated with the existing organization.

To design business process models meaningfully for others, Ould [27] suggests pursuing the following modeling principles:

• If there are abstraction levels, they should follow a purpose.

• Reality is chaotic.

• A diagram must have a clear meaning.

• Process diagrams are aimed at people and show what they do.

• On the one hand, they show what they should do and, on the other hand, what they actually do.

• People work in functions, but perform business processes.

• It is about what the people actually do, and not why they do it.