A short introduction to BPM: Design & Analysis

Business Process Management

Business process management, abbreviated as BPM, provides the surrounding and the toolbox required for the precise definition of business processes:

A business process is a process that creates a value or result for a customer.

The scope of BPM is quite wide, since it reaches from theoretical economists over practitioners up to computer scientists. Throughout this introduction, we stick to the following definition:

Business process management refers to an integrated set of activities for designing, analyzing, deploying, enacting, managing, evaluating, and optimizing business processes.

The different activities of business process management can be brought into a lifecycle, depicted in the following figure:

The lifecycle is entered in the design and analysis activity. Inside this activity, business processes are designed from scratch or derived from existing sources. Existing sources include for instance best practices, unstructured work descriptions, or observations of the daily work. As a result, the business processes are made explicit so that a thorough analysis can take place. Business processes can be validated regarding their meaning, e.g. discussing the right order of activities. They can be verified regarding formal criteria, e.g. proving if every execution of the business process provides a result. And they can be simulated, e.g. using graphical step-by-step visualizations. In the deployment activity, systems are selected and the business processes are implemented and tested. Software packages provided by particular vendors are used to realize the BPM solution. The business processes are enacted by a BPM engine and the people working thereon in the enactment and management activity. The management part refers to monitoring and maintenance. Reports can be created and subtle changes can be made. After a series of processes have been executed, they are evaluated and optimized. Evaluation includes things like throughput times, discovery of bottlenecks, or the verification of conformance with updated requirements. During the optimization, solutions for the evaluated problems are provided. These are used as an input into the (re)-design of the business processes, which closes the lifecycle's cycle.

Design and Analysis

This article focuses on the design and analysis activity. We assume the business processes to be already present---either only as a vision, powerpoint slides, a set of notes, or inside the minds of people that daily "live" the processes. The design of a business process contains the following important aspects:

• The goal of the business process.
• The contained activities.
• The dependencies between the activities.
• The "executors" of the activities.
• The input data required to perform a certain activity.
• The output data produced by certain activity.
  

The goal of a business process is the most important aspect. Each process has to have a qualification for its existence. A decision chart for helping you classifying your business processes is shown below:

In the horizontal the occurrence of the business process to be designed is depicted. Will the process occur often or rather seldom? In the vertical the importance of the business process is shown. Does it represent a rather low value that can be easily replaced? Or is it of high importance to the goals of the company? Business processes which are of high importance and occur often are first class citizens that in any case should be designed and specified. The fortune of the company is depending on them. Business processes which are of low importance but occur often should be considered for design and specification since they simplify everyday business life. The same holds for seldom but highly important processes. Due to their seldom occurrence it cannot be guaranteed that people are available who know how to handle them. Even processes with low importance and seldom occurrence might be suited for design and specification, especially to fulfill conformance with business standards.

Activities

Each business process is made up of activities that denote the tasks that have to be executed to deliver its goal. The achievement of the goal is denoted by a special activity that is executed once (if multiple goals are required, either the business process has to be executed more than once or different processes have to be used). Examples for activities are phoning someone, writing a letter, making a decision, or invoking a computer program. The first two examples are denoted as manual activities, since they are executed by humans. The last one is an automated activity, since it is executed by a machine. The third activity can be of both kinds. During the execution of a business process, its activities are instantiated. This simply denotes the actual occurrence of an activity, e.g. actually phoning Mr. Smith, actually waiting if more passengers will arrive, or updating a database. An activity that is instantiated is called an activity instance. An activity instance can have several stages during its life:

Exemplary, this means for an activity instance of phoning someone: Discover the idea to phone Mr. Smith (created), fulfill all preconditions as finding phone number, get relevant documents on your desk (ready or activated), make the call (running/executing), and finally you're done (finished). At all stages you have the possibility to cancel your activity instance (cancel). When phoning Mr. Smith is on your to-do-list (created), you can remove this item, e.g. if you have not all documents at hand. After you have prepared everything (ready), you can decide to cancel the call. Even while phoning with Mr. Smith (running) you can cancel by hanging up in the middle of the call. We will use the states of an activity for the specification later on.

Dependencies

The activities of a business process are related in causal and temporal orders by dependencies. Some activities have to be executed in sequence, whereas others can be worked on in parallel. Furthermore, some activities depend on the results that other activities produce. Again other activities have to make decisions if one or the other activity should be executed next. An example is given below:

The business process shows the dependencies between activities found in a typical order-to-cash process. Activities are denoted as circles, whereas dependencies are shown by arrows. An activity with no incoming arrow is an initial activity. It can start immediately since nothing needs to be done beforehand. An activity with no outgoing arc is a final activity. It usually concludes the execution of a business process. A well designed business process has always one initial and one final activity. The figure shows activities that need to be executed in a certain order. Before an order can be processed ("Process Order"), it needs to be received ("Receive Order"). Hence, an arrows goes from the latter to the former, denoted as a sequence of activities. Moreover, for optimization issues, items can be packed ("Pack Item") while the invoice is created ("Create Invoice"). The flow of the business process is said to be split in parallel beforehand. This is done after the order has been processed. Regarding the packing of the items, this can only be done one after the other. Hence, after an item has been packed ("Pack Item"), it has to be checked if there are more items to include ("More Items?"), denoted as a choice. If so, the "Pack Item" activity is executed again. This repetitive construct of "Pack Item" and "More Items" is called a cycle. Somewhat later, all items are packed and the invoice is created. Due to the requirement that the invoice should be shipped with the order, the parallel flow of the business process has to be joined. This is done before the "Ship Order" activity. "Ship Order" is also the point in the business process, where the goal of the customer is satisfied, i.e. she receives her order. Nevertheless, from the companies point of view, the business process can only be terminated after the payment has been received ("Receive Payment").

Roles

The "executors" of the business process's activities are the people or computer programs that actually work on them. While it is common to directly name programs, people are assigned differently to gain greater flexibility. Instead of stating that an activity is executed by, let's say, John, a role is assigned instead. A role is a placeholder for a set of people who can execute certain activities. Thus, if John is unavailable because he's ill or working on some other activity, we can look up another employee which has a role that is required for a certain activity. This concept is added to the example as follows:

We assigned four different roles to the sample order-to-cash business process. Each activity belongs to a certain role. The roles are resolved to actual employees such as given in the following table:

	Sales	Fulfillment	Distribution	Accounting
John	+			+
Clark		+
Alice			+

Each row contains the name of an employee. Each column shows the corresponding role. We can see that in our case John is responsible for two roles, "Sales" and "Accounting". Clark is responsible for the "Fulfillment" and Alice for "Distribution". If we would drop Clark and make John also responsible for "Distribution", the items could no longer be packed in parallel with the creation of the invoice. This is due to the fact that we would not have enough "manpower", since John can only work at one activity at a time.

Inputs and Outputs

The last aspects that need to be covered are the inputs and outputs of the activities. While one kind of constraints is given by the flow dependencies between the activities and another by the availability of people that can work in a certain role, this one considers the "data" or "material" viewpoint. Each activity needs some input, either from process-internal sources, such as preceding activities, or from external sources, such as customer requests. For now we only consider the first kind of input. We can define different kinds of input, such as an order, an invoice, or the shipment. These are depicted for the sample order-to-cash business process:

The input of each activity has to be produced as the output of some other activity. Consider for instance "Process Order", that requires an order beforehand. The order is also required to produce the invoice within the activity "Create Invoice". Its input is an order and its output an invoice. In our example the outputs are directly related to follow up inputs. This is not necessarily the case. An output of one activity can also be connected to the input of another activity that is further downstream the process flow.

Specification

Thus far we only talked about the "visible" design aspects. What differentiates them from a complete specification? While the design focuses on these aspects regarding human understanding, a specification has to be complete and unambiguous. While the latter can also be done using the same techniques as the former, we want to make a differentiation. The difference is based on the way humans communicate. Humans like to discuss about drawings, or graphical models (diagrams), of the business processes they have in mind. Since these drawings have to have a limited size, they can only contain a limited viewpoint of the different aspects. This can already be followed from the order-to-cash example. If we combine the activity dependencies, the roles, the people behind the roles, and the data dependencies in one diagram, even this small example fills a full page and is thus difficult to comprehend. A sound specification has to use the power of mathematics to provide an unambiguous description of the business processes.

The importance of a formal specification can already be motivated from the order-to-cash process. While we might have an intuitive knowledge about how the different kinds of splits and joins found in the process might work, this is indeed not enough. From which fact do we know that after "Process Order" both parallel flows of the process are activated? Is there only one instance of the "Pack Item" activity or one for each iteration? While both activities, "Pack Item" and "Ship Order", have two incoming arrows, their behavior differs. The former waits only for one of the preceding activities to finish, whereas latter waits for two.

Verification

Furthermore, a formal specification opens the door for proving facts, denoted as invariants, of the business process model. It might be obvious that under some fairness assumption, i.e. the list of items to be packed is finite, the order-to-cash process will always end with the Receive Payment activity. Hence, it contains no dangling situations, which are denoted as deadlocks or livelocks. A deadlock occurs if a business process cannot continue while the result is not yet provided. A livelock occurs if parts of a business process are in a loop that cannot be exited (The loop in the order-to-cash process has always the choice to continue with "Ship Order"!). However, more complex business processes might contain millions of possible execution dependencies between the contained activities. Hence, the proof for deadlock and livelock freedom is not trivial.

Interactions

The situation gets more complex by looking at interactions between business partners. An example is:

The figure shows two participant roles, i.e. representatives of two different companies. In the upper part is a shop, which has implemented the order-to-cash process. In the lower part is a customer, which likes to place orders at the shop. The interactions between both participants are denoted with dotted lines that represent the exchange of messages or material. As can be seen, the order-to-cash process now requires some input denoted by an order. Furthermore, the "Ship Order" activity actually sends something to the customer. However, a misunderstanding might arise from the existence of two "Receive Order" activities, one at the shop and one at the customer! In a formal specification both need to be different, e.g. by unique identifiers. In a graphical view, some people might argue that receive order is what both activities do, and hence should be named the same (of course, both have different understandings of "offer"). An interesting questions that arises is that of compatibility between both business processes. Compatibility discusses the successful interaction of business processes, e.g. showing that no deadlocks or livelocks occur. While the customer might be completely satisfied with the shown interaction, the shop might disagree. Of course, the customer never pays for the delivery. Hence, it is a goal of the shop to avoid interacting with customers that behave as shown. Using a formal specification, also these kinds of issues can be tackled.