Designing Efficient BPM Applications

Chapter 1. Recognizing Your Business Processes

Monday Morning

“What d’you mean there’s no coffee? This place runs on coffee!”

“We ran out.”

“But I told you last week the stock was low. Did we forget to send the order?”

“I sent the order, but someone forgot to pay the previous bill. They won’t deliver until it’s settled. The person I spoke to was quite brusque...maybe they hadn’t had coffee either...”

Maybe your business does not run on coffee, but it certainly runs on something. Whether it’s parts for manufacturing, information, or simply money, if your processes are not efficient, you either need to keep a large surplus or risk running out.

This book is all about designing efficient business process applications. The first step is understanding what your business processes are. This chapter defines what a business process is, introduces the Business Process Model and Notation standard, and presents some examples of typical business processes. At the end of the chapter, you will be able to recognize the business processes that you use in your organization.

What Is a Business Process?

A process is a sequence of tasks. Every task is an action, and is carried out by a person or by some automatic system. All processes share certain characteristics:

Interaction over time

A chronological relationship between tasks, with due dates and sequencing, but not a schedule.

Multiple actors

More than one person or automatic system must complete tasks for the whole process to be successful.

Repetition

The sequence of tasks is repeated, either at fixed intervals or when triggered by a specific event.

A process-based application is composed of at least one process and some associated components.

What Is Not a Process?

The action of filling out a form is not a process. A form that has many pages and is filled out online is a single task for a single user. A form that can be filled out in more than one sitting is a single task for a single user. Even a form that has smart fields that depend on other fields, with conditional display, is a single task for a single user.

A state diagram is not a process. A process is constructed from actions. The things that are updated by these actions might have states associated with them, so you might create state diagrams as part of your process validation, but the state diagram is not itself a process.

A business application is not a process. In fact, most business applications contain several related processes, together with some other components. The next section describes some examples of process-based business applications.

Examples of Process-Based Applications

The following examples are familiar to most organizations.

Vacation Management

An employee asks a manager to approve a request to take some days of paid vacation. The manager approves or refuses the request. The employee needs to know how many vacation days are unbooked, and the manager needs to know the vacation plans of the team. Vacation plans change, so requests can also be modified or cancelled. 

This is the example that will be used in the rest of this book to guide you through creating a process-based application.

Recruitment and Onboarding

A manager gets permission to recruit, and gives the profile to HR. An HR administrator filters candidates according to the profile, then sends short-listed candidates’ details to the manager for review. The manager chooses which candidates to call for an interview. There are selection interviews. A decision is made, and an offer is sent to the selected candidate, who accepts or declines the position. If the candidate accepts, a start date is agreed upon, and the onboarding process is triggered. During the onboarding process, IT creates the user account, Facilities orders an access card for the building and confirms that an office is prepared, HR prepares a welcome pack, and the manager confirms that a ramp-up plan is prepared.

Procure to Pay

An employee raises a purchase order (PO) for new equipment. The employee’s manager reviews the purchase order, and approves it or refuses it. If it is above a given validation limit, it is automatically escalated to a senior manager for a second level of approval. After the PO is approved, it is sent to the purchasing department, which places the order. When the equipment is received, it goes to the employee, who checks that it is correct. The invoice is received by Purchasing, which checks that it is correct and initiates payment.

Build to Order

An automated production system receives an order. It checks whether the components needed are in stock, reserves those that are, and orders any that are not. The order is put on hold until the components are all available. When the ordered components arrive at the warehouse, the order is built, then packaged, and then shipped. 

Online Shopping

A user logs in to an online shopping site. Over the course of several visits, they assemble a shopping basket. Then they go to the checkout, review the basket content, and select the items for immediate purchase. They check the shipping cost for the selected items. After making a final selection of items to buy, they enter the delivery address and credit card details, which completes the purchase. In the warehouse, a robot collects the purchased items, packages them, and dispatches the order.

Business Continuity

A building surveillance system detects a power outage. It notifies the business continuity (BC) manager at the headquarters of a company with offices in the building. The arrival of the notification automatically starts a timer set for 15 minutes. If the power is still out after 15 minutes, the failover plans are put on standby. The BC manager investigates the cause and decides to declare an incident. This initiates the tracking process, which contacts the staff at the remote site. The managers in the BC team use the process to report their actions, and the process issues reminders or escalations if needed. The BC manager and the whole team can view the process status to get a snapshot of the actions that have been taken. All actions are under the control of the relevant person, while the process provides tracking and visibility for everyone. When the incident is over, a similar tracking process is used to manage the transition back to normal operation.

Document Approval

A technical writer issues a first draft for review. The technical experts review the draft and provide comments in a form. All reviewers can see all comments, which makes it easier to resolve conflicts. The writer produces drafts iteratively, and experts review until they approve the content. The final draft is then sent for proofreading, updated if necessary, then published.

Travel Management

An employee sends a travel request to the team manager. The manager gives provisional approval. The employee sends the travel request to the team administrator, who investigates flight and hotel pricing and availability, and suggests an itinerary. The employee reviews the itinerary, and works with the admin to finalize it. The final itinerary including pricing is sent to the manager, who approves the total cost. The admin books the travel. After the trip, the employee submits an expense claim, which is automatically checked against the expenses policy. If it is in policy, the claim is sent to the finance department for payment. If it is out of policy, it is first sent to the manager for approval of the exceptions and then sent to the finance department for payment.

Business Process Management

Business Process Management (BPM) is an approach to process improvement, like its predecessors Total Quality Management and Continuous Improvement. It is also a technology. Both are focused on improving the efficiency of a business by making processes more efficient, flexible, and dependable, and by reducing costs.

Business Process Model and Notation

Business Process Model and Notation (BPMN) is an international Object Management Group specification for describing a business process. The most recent version is BPMN2. It provides a framework that can be used to define a process so that it can be executed. The standard covers both the graphical representation of a process and the execution semantics. The graphical representation is the basis for communication between the business analysts who design the process and the development team who implement it. It is also useful for communication between the business analysts and the functional teams who are “customers” for the process.

There are BPMN software applications that can take the process definition and create an executable application directly from it. This enables a business process to be presented to nontechnical users in a way that is easy for them to use, efficient, and repeatable. It is therefore much easier to introduce “best practice” and improvements in workflow.

Process Automation

The first step in automating a process is to create a formal definition in BPMN2. This definition can be executed so, at a very basic level, your process is automated.

To transform a process defined in BPMN2 into a process-based application, you need to combine the following:

• Application components that are not part of a process; notably the user interface components, which are typically web pages
• The definitions of all the related processes 
• Forms for process tasks that require human interaction
• Data

There is an upfront investment in automating a process, so even if the downstream cost savings are obvious, you will not automate all your processes immediately—or ever. To get the greatest benefit from automation, you should automate a process if it has some of the following characteristics:

• Frequent use
• Approval tasks
• Multiple concurrent use
• Nonhuman tasks that currently require human supervision or intervention
• Strong need for consistency and measurement
• Criticality (for example, time, legislation, or financial risk)

Process Efficiency

The key to creating an efficient process is to start with the simplest case and extend or refine the application iteratively. You can start by automating a small part of the process, and then extend the implementation to cover the whole process, or you can start with a process containing vague or generic tasks and refine it to be more specific based on user feedback.

Summary

Now that you can recognize the business processes you already use, you can make decisions about where to invest in automation and improvements. The rest of this book takes an example that is familiar to all businesses, and shows you step-by-step how to automate it and turn it into a process-based application.